So showing the contents of the “Boot Camp” app located under “/Applications/Utilities” will expose a “Contents” folder which contains the “Info.plist” file. Edit this file using the Dashcode app (I believe this installs with Xcode which is included on the Lion/Snow Leopard install media under the optional folder) and look for the “USBBootSupportedModels” setting in the left hand pane. Clicking the little triangle will expose/unfold a bunch of models that support USB booting. According to Apple, these are the only models that support the feature but you can alter this file to include the model of the Mac you currently use. Click the Apple icon in the top most menu and find the “About This Mac” option. click “More Info” then “System Report”. This is where you look to find your Model Identifier. Mine was MacBookPro6,2 which would translate to a MBP62 string. There is also a Boot Rom version in the same report a little further down that you should pay attention to. Mine was listed as MBP61.0057.B0C. I took this to mean that I should also include a MBP61 string in the list of supported models as well. Clicking the little plus icon next to “USBBootSupportedModels” will allow you to add strings for both your model and boot model. Save the file to your desktop. I was very carefully to rename the original file to something like Info.old.plist before copying the modified file back in place from my desktop. I also went in and changed the ownership of the file to “root:wheel” after copying. Follow these steps then when you restart Boot Camp the option should be available to you. Happy “Boot Camping!”

So I try building the static lib and forcing it. The first roadblock I hit was with the ${BUILD_STYLE} environment no longer being set. ${BUILD_STYLE} is changed to ${CONFIGURATION} in Xcode 4. The second bump I hit was with categories not loading from the static lib I generated. Setting “-ObjC” under “Other Linker Flags” solved this. Next I get OCMock to load but auto complete doesn’t work with the category methods added to “id”. (Eg. stub, expect, verify, etc.) I accidentally set my “Header Search Path” incorrectly. You have to set it to point to the folder that contains the OCMock folder with the header files in it, then you can successfully import in your test cases. Finally auto-complete works and things load but setting simple expectations on a mocked string appears to be broken. I’m now wondering if I should download source from the git repo instead of building the source included in the dmg. It’s late and I’m incredibly frustrated with not being able to write a single test all day…

To start, I went into edit mode on my Wife’s contact card and started fiddling. Eventually I noticed the “add field” button. Tapping this brought up a host of different things I could associate with a contact, most notably the “Related People” button. Tapping on “Related people” adds a custom relationship to a contact. I assigned a spouse relationship to her contact and linked it to my contact info. That got me thinking. How does Siri know who I am? After all, my contact info is just another card in my address book. There is no “me” card. I backed out of the address book and went into settings under general and found the Siri settings.

Under Settings -> General -> Siri I found the “My Info” button. Tapping this allowed me to link the contact card with my name to Siri which, in short, teaches her who I am. After that I went back into the contact card for my wife and found some more custom fields. The “Phonetic First Name” was particularly interesting since we (Siri and I) seemed to struggle a bit here. After I spelled things phonetically we started to get along much better. This should put an end to the disagreements we have on Hwy 101 when I say, “Tell Altaress I’m stuck in traffic and it’ll be while before I can get you.” Where Siri responds,

“Clifton, I don’t understand who ‘Ouch Therese’ is. I need a name, number or contact to send your message…”

“Ok, here’s your meeting.”

Siri found the calendar entry for our Halloween party and presented it to me. So I guess Siri is going to be a calendar for Halloween this year. I promptly launched the calendar app and plan to run it for the remainder of the day.

With WindScript you only need to use one of 2 recognized keys on your keyboard! See the sample enclosed in the root element of the XML document below.

<windscript>

</windscript>

codesign -f -s “iPhone Developer: Clifton Craig (DUWQRS4KP8BM9)” -vv MyCoolProduct.app

I’ve been attending a Srcum certification course led by none other than James Coplien. This guy is fantastic and I’ve already learned a great deal about the practice in the one day I’ve spent with him. Now here’s the controversial topic. Jim, is totally against TDD. If you know me, I am from the polar opposite camp. I had a breif dsicussion with Jim yesterday which I plan to continue today if he allows the time. In the interim I took the liberty of reviewing some of a standard email he sends to people like me who are unaware/unsure of his strong opposing position. The 1st link features Jim in a debate with a person I admire, Uncle Bob Martin from Object Mentor. This debate felt almost identical to my discussion with Jim yesterday and while both leave me unconvinced that TDD is harmful I remain open-minded. I am so open-minded to Jim’s position that I wanted to rush a quick post this morning to explain where I could potentially agree that TDD does more harm than good.

Testing at the wrong level

One of Jim’s primary arguments is that developers practice TDD at the wrong level, the class level that is not responsible for external features and contracts. This leads to code bloat from the test and gives you the wrong architecture from the onset. I whole heartedly agree with Jim on this point and it is something I still find myself doing from time to time. The practice requires a certain discipline and experience that you get only from making this and other similar missteps. In all, your design should come from your specifications or contracts and these should precede your implementation. I believe (without asking him) that Jim would agree with me here.

Poorly factored unit tests

One of the primary reasons TDD fails is because many miss the last R in the RGR cycle. RGR stands for Red Green Refactor. That means you write a failing test (reports red), make it pass (reports green), then you refactor both you system under test and your test code. I’ve made the mistake of not properly refactoring my test code in a hurry to move onto the next thing. Your test code should read like a contract or a usage guide for how to interact with your code. In practice the test code tends to grow rather quickly, which exceeds a developer’s ability to properly maintain it, which leads to the code bloat mentioned above. This step takes discipline and can be easy to neglect even for experienced developers.

Writing too much test or too much code

Following Uncle Bob, the TDD cycle is a tight and minimalistic cycle where you write only enough test to state or explore the current part of the specification you’re working on and only enough code to satisfy that test. Problems arise from writing too much test code without iterating over implementation code which is the inverse of YAGNI, YAGII! (You Ain’t Gonna Implement It.) Also you get into trouble from writing too much implementation code without a requirement or specification to justify it.  The power comes from the iterative approach to explorative development. As you iterate you uncover pieces of the spec that are not complete which might require discussion with your QA or business analyst and trigger discussions and that leads to an important distinction I’d like to mention. Many people make a distinction between bugs and features. I see them as one in the same. A bug is simply a non-feature or a hole in your spec. It represents some edge case or usage scenario that has not been explored which leads to errant unexpected or undefined behavior. You iterate on these the same as you do your features by amending your spec and filling in the holes in both the spec and your test cases which should mirror your spec.

I have to cut this short now since class is starting. It’s an interesting topic and I’d love to hear more about what Jim and others have to say on the topic.

Beginner

Basic concepts of 3D world and OpenGL – Any version
OpenGL ES 2.0 For iPhone Tutorial – OpenGL ES 2.0
Hello Triangle – (Windows) - OpenGL ES 2.0
Getting Started (iPhone) - OpenGL ES 2.0
What is OpenGL ES? (all) – OpenGL ES 1.x
Xcode Project Set Up (iPhone) – OpenGL ES 1.1
An Introduction To OpenGL (Google Android) – OpenGL ES 1.x
Setting Up Your Environment (Pocket PC) – OpenGL ES 1.x
OpenGL Window (Pocket PC) – OpenGL ES 1.x
Keyboard Input (Pocket PC) – OpenGL ES 1.x
Mouse Input (Pocket PC) – OpenGL ES 1.x
Viewports in Perspective (iPhone) – OpenGL ES 1.1
Drawing Primitives 1 – Triangles (iPhone) – OpenGL ES 1.1
Drawing Primitives 2 – Squares (iPhone) – OpenGL ES 1.1
Rendering (Pocket PC) – OpenGL ES 1.x
Orthographic Projection (Pocket PC) – OpenGL ES 1.x
Colour and Shading (iPhone) – OpenGL ES 1.1
Color And Shading (Pocket PC) – OpenGL ES 1.x
Window Resizing (Pocket PC) – OpenGL ES 1.x
Transformations (iPhone) – OpenGL ES 1.1
Transformations (Pocket PC) – OpenGL ES 1.x
Depth (Pocket PC) – OpenGL ES 1.x
Perspective (Pocket PC) – OpenGL ES 1.x
Solid Shapes (Pocket PC) – OpenGL ES 1.x
The Final Primitives: Points and Lines in a Stride (iPhone) – OpenGL ES 1.1
Objects in 3D (iPhone) – OpenGL ES 1.1
Translating Objects Independently (iPhone) – OpenGL ES 1.1

Intermediate

Texturing 3d Objects In OpenGL ES (iOS) – OpenGL ES 2.0
OpenGL ES 2.0 in depth (iOS) – OpenGL ES 2.0
Monkeys on Your Back and Geometric Shapes (iPhone) – OpenGL ES 1.1
Interleaving Per-Vertex Data (iPhone) – OpenGL ES 1.1
Landscape View & Handling Touches Part 1 – 2D World (iPhone) – OpenGL ES 1.1
Backface Culling (Pocket PC) – OpenGL ES 1.x
Lighting (Pocket PC) – OpenGL ES 1.x
Directional Lighting (Pocket PC) – OpenGL ES 1.x
Texture Mapping Our Square (iPhone) – OpenGL ES 1.1
Texture Mapping (Pocket PC) – OpenGL ES 1.x
Texture Functions (Pocket PC) – OpenGL ES 1.x
Multiple Textures, Repeating Textures, and the End of the Book Era (iPhone) – OpenGL ES 1.1
Blending (Pocket PC) – OpenGL ES 1.x
Transparency (Pocket PC) – OpenGL ES 1.x
Single Texture, Multiple Looks, Render to Texture, and Getting Inspired in Maths(iPhone) – OpenGL ES 1.1
Masking (Pocket PC) – OpenGL ES 1.x
Uncompressed TGAs (Pocket PC) – OpenGL ES 1.x

Advanced

Jedi skills in OpenGL ES 2.0 and 2D graphics (iOS) – OpenGL ES 2.0
Moving in 3D (iPhone) – OpenGL ES 1.1
Moving in 3D Part 2: Some Theory that I Should Have Explained (iPhone) – OpenGL ES 1.1
Draconia 01: Getting Started and Background Scrolling (iPhone) – OpenGL ES 1.1
Waving Flag (Pocket PC) – OpenGL ES 1.x
Blender Models Part 1: Learning Some Blender Internals (iPhone) – OpenGL ES 1.1
Blender Models Part 2: Loading and Rendering (iPhone) – OpenGL ES 1.1
Blender Models Part 3: Textures and UV Mapped Objects (iPhone) – OpenGL ES 1.1
Fog (Pocket PC) – OpenGL ES 1.x
Reflections (Pocket PC) – OpenGL ES 1.x
Collision Detection (iPhone) – OpenGL ES 1.1
Collision Detection 2: Moller & Trumbore’s Fast Triangle Ray Intersect (iPhone) – OpenGL ES 1.1

For a list containing specific sites with OpenGL ES tutorials please check out the original list creator’s Killer OpenGL ES Resources list.

Also there was specific mention of Ray Wenderlich’s Open GL ES 2.0 tutorial.

Introducing the Mac of 2012
I was going to begin by listing what the next Macs won’t have but actually it might makes sense to describe it in terms of what it will have because it will take far less words. You’re next Apple computer will be a screen hardwired to both your finger and a twelve core CPU. Apple plans to employ every human being on the planet in their factories, pay them zero wages while hardwiring each individual to the units it pushes out of its factories. After your unit is manufactured your position will be terminated at which point you are to visit yourself in your local Apple store and purchase your right to walk out with your new unit. Upon arrival you will have a choice among which model you wish to buy, though details are currently sketchy on how the selection process will work. Most individuals will likely opt for the lower models due to their current economic status but a certain amount are expected to buy into their more powerful product lines. Apple will still feature a 30 day customer satisfaction agreement which individuals can take advantage of should there device fail to perform to their expectations. Reimbursement would require customers to return the product to the original place of purchase so it (and the customer) may be sent off for refurbishing. This new process is referred to as the new Apple Care package which will come bundled with each device at rates forecasted to be competitive to the current warranties.

What you’re giving up…
Apple plans take the user computing experience to the next level by removing all legacy technology from its product lines. Optical drives are a thing of the past and will no longer be included. Gone also are the spinning hard drives, physical keyboards, track pads, power supply, speakers and camera. Indeed, expect your new Apple devices to be razor thin and ultra compatible with everything from the $4,500 Mac you’ll still need to return to the store and purchase to boot your new device to none of your thousands-of-dollars-worth of existing Apple equipment. Apple is removing all hardware compatibility from its stack in flavor of the new compatibility layer it has yet to complete at the time of your purchase. While most people value the ability to plug or wirelessly pair their mobile devices to things such as the stereo in the car Apple recommends you pair only with devices from their Apple certified product line which, at the time of this writing, excludes every vehicle, headset, speaker dock, television, or other electronic device manufactured and currently under manufacture at the time of this writing.

This has been a sneak preview reporting of what’s coming in tech. I’m your insider, Cliff, and I’ll catch you back here next time. For now, good night!