Nerding it up at The Big Nerd Ranch


In 2011, from September 16th through the 23rd, thanks to my employer Grassroots-Technologies, I attend The Big Nerd Ranch to take their "Beginning iOS" class.

Here is a description of my experience....

Background:

So that you can gauge my reactions to the class, here is my background.

I started programming when I was 13 or 14 on  an TRS-80 model II and quickly moved over to the Apple IIe.

My professional career started in 1995, in the early days of the internet. I have developed in a variety of languages, platforms and tools including Java, Javascript, Perl, Python, AS2/AS3/Flex, Tcl, Storyserver, HTML, CSS, XML, XSL/XSLT, Oracle, MySQL, SQL, and many more acronyms. Even though I have and continue to use Windows and Linux systems, my computing platform of choice is the MacOS.


Accommodations:

Big Nerd Ranch courses take place in a large, rustic B&B in the outsides of Atlanta called "Historic Banning Mills".  The site has many hiking trails and used to be the location of a series of mills (primarily paper and flour-related) of which there are now only ruins. Banning Mills' other claim to fame is the large number and length of their ziplines which criss-cross the property. According to the owners, they are the longest ziplines in the U.S.

Big Nerd Ranch staff takes care of transfers to and from the Atlanta airport. Our driver was Brooks, who was very polite and helpful and answered questions about BNR, Atlanta and Banning Mills. Everyone is asked to arrive the night before the class starts for orientation.

Banning Mills has cabins and rooms, which are like mini-cabins, built in the same rustic style. I was assigned to a room which had a king size bed (which seemed to be elevated 7 feet off the floor), a TV, clock radio and one of the well-known hot tubs.

The bathroom shower was basically a powerwasher. Some guests described it as a sandblaster and everyone had a different technique for dealing with the powerful flow of water. I'm not sure why they had so much water pressure, but you got used to it after a couple of days.

The Banning Mills staff was very friendly and helpful and the food was plentiful and delicious (so much so that I gained weight during my stay). Meals are at 8:30am, 12:30pm and 6:30pm.

Classes:

BNR markets their classes as being for anyone that wants to learn--programmer or not. In fact, in my class, we had 2-3 people with no programming experience at all including a construction worker and a mailman. The rest of the participants were from all over the country, with one developer from Canada.

At the time that I signed up, there were 2 iOS classes being offered: a 4.5-day iOS intensive and a 6.5-day iOS Bootcamp which is the 4.5-day class preceded by 2 days of Objective-C training.

Even though I'd done some work in XCode and was familiar with Objective-C, I opted for the 6.5-day class because I felt that my grasp of Objective-C was shaky. Plus, I was evaluating the class for my employer and I needed the full experience to know if it would be worth it for other developer at my company.

Both parts of the course (Objective-C and iOS) were run in similar fashion. We worked from a textbook and the instructor gave a 15 to 30-minute lecture prior to each chapter covered, followed by lab time. During lab time, students worked through the chapter, completing the exercises and optionally working on challenges at the end of most chapters.

Class ran from 9:00am - 12:30pm, then again from 1pm-6:30pm, with additional lab time every night until around 10:30pm.

Every afternoon we were taken on an hour-long hike through the woods on the Banning Hills property, with the option to enjoy the ziplines on Thursday. NOTE: I found 2 ticks on me, one of which bit me, though no one else complained about tick bites. I think it would be a good precaution to check yourself for ticks after hikes if you attend classes at Banning Mills during the summer months.

Objective-C portion:

The first two days of the bootcamp were taught by Mark Fenoglio with teaching assistants Juan Pablo Claude and Steve Marriott.

Prior to arriving, I read from Stephen G. Kochan's excellent "Programming in Objective-C 2.0", which was recommended by the BNR staff. That and my previous experience writing some iOS apps gave me a decent grounding in Objective-C.

The process of the class was to get a 15 to 30 minute lecture on a topic from the textbook we were given, followed by lab time were we went through the chapter and worked on the exercises within it. Mark was very knowledgeable and answered all our questions, no matter how off-topic they were.

Because of my prior experience as a programmer in general and with Objective-C in particular, I found the class to be a little slow-paced and easy. I got through the chapters and exercises quickly and had time left over to complete chapter challenges or experiment. However, I got to cement my understanding of some key concepts and had the opportunity to ask questions outside of the scope of the chapters. Given that there were students in class who were either completely new to programming, or to Objective-C, I believe the class went as fast as it could have gone. As someone learning iOS development, you have to understand the basics of Objective-C and be comfortable with the syntax of the language before you can move forward. All those square brackets take a little getting used to.


iOS Development portion:

On Monday morning, Mark handed the baton to Joe Conway who, along with Aaron Hillegass, is the author of "iOS Programming: The Big Nerd Ranch Guide". We were fortunate enough to be working from the as-yet-unpublished 3rd edition of the book.

The structure of the iOS development portion of the class was very much like the Objective-C part: a lecture followed by lab time where students worked through the chapter, exercises and challenges. Joe covered most of the book, around 85% I'd say. The chapters and the lectures themselves build on each other through the thread of applications to which students continually add functionality.

Joe's skill and style as an instructor is excellent. His pacing is carefully measured and he explains tricky concepts in a way that makes them accessible to non-programmers and programmers alike. He has a very deep understanding of the subject matter and is able to impart that information clearly. I noticed that he also paid close attention to the reactions of students, explaining topics in a different way when he sensed that not everyone was with him.

The pace of the instruction was unrelenting--much quicker than that of the Objective-C class. Even though no single topic was overly difficult, it became and more challenging by the hour to keep pace. By day two, I started not completing the challenges, then I had trouble completing the chapters and exercises themselves in the time given and needed to head down to the lab after dinner to finish my work.

I was not alone. That was the experience shared by practically everyone in the class--it didn't matter if you were a programmer with 15-years experience or not. There was one student who, especially after dinner, when we were all exhausted, grunted and sighed his discomfort with every page turn, echoing how we all felt.

That said, I wouldn't have wanted it any other way. I learned a lot from the class, not the least of which is a new comfort level and ease with the language and tools that comes from the intense immersion you undergo.


Conclusions:

No one should sign up for this class and expect to walk away an expert iOS software developer. It takes time for humans to learn new skills, even if you have years of relavent experience (actually, sometimes experience is a detriment).

A week of instruction like this is a fine balancing act between going over as many topics as possible, but without leaving people behind for the sake of keeping pace. You want to push them, but without knocking them over. You want students to learn the material, yes, but more importantly, you want them to acquire the skills and building blocks to manage their continued learning once they leave the class. In all these respects, I feel that The Big Nerd Ranch "Beginning iOS" course did that for me. I would recommend it to anyone looking to jump-start their iOS development goals.

Bosch Axxis washer "Door Open?" error and repair

Background:

My wife and I own a Bosch Axxis front-loading washer and dryer set (WFR 2450/2460 and WTA 4410US). One morning my wife informed me that the washer was not working. It was reporting that the door was open and wouldn't allow a wash cycle to begin. No matter how carefully we opened and closed the door, the washer beeped and displayed "Door Open?" on its LCD screen.

We had a house guest at the time who had been using the washer and dryer almost non-stop for 4 days, and who claimed to not know that the washer was no longer working. (The story of the house guest who broke everything she touched and overstayed her welcome is a topic for a different blog)

Several Google searches later and we were no closer to a solution. Some people reported needing to replace the door switch, others that a new door switch did not fix the problem. Many people also complained about not being able to open the door once the cycle was complete.

The solution in our case was probably the best possible outcome requiring neither a new switch nor removal of the washer.

Repair Summary:

The repair was very simple. The door latches into an electric lock, which keeps the door locked during a cycle.

Inside the washer, the door latch has two control cable bundles connected to it. One provides power to a solenoid (a magnetic plunger) which locks and unlocks the latch, while the second cable bundle is used by the washer to determine the state of the latch ("Is it locked?" "Is the door closed?").

Once I got to the latch I realized what had happened:

Due to someone (*cough* houseguest) repeatedly slamming the washer door shut, the second cable bundle had worked itself loose and was no longer connected to the electric lock switch. This caused the washer to no longer know if the door was closed or not.

Re-connecting all the cables to the electric lock fixed the problem.

Repair Step-by-Step:

Tools:
  • A pair of pliers.
  • A flathead screwdriver.
  • A 2.5mm (metric) hex screwdriver. (optional)
Steps:
  1. Remove the wire which holds the front of the rubber skirt in place.
    • There is a thin metal ring connected to itself by a spring which holds the front of the rubber skirt in place.
    • The spring is located on the left side of the door, right next to the hinge.
      retaining_wire_spring
    • Using pliers, grip the wire below the spring and pull down carefully, but with force. You'll need to stretch the spring enough so that you can pull the wire away from under the skirt (it's nestled in groove around the rubber skirt).
    • The flathead screwdriver might come in handy here, if you work it under the wire and pull it away from the rubber skirt.
      retaining_ring_removed
  2. Pull the rubber skirt away on the right side of the door, next to the latch lock switch and push it into the washer and away from the switch.
    rubber_skirt_groove
  3. Reattach both control cables to the bottom of the switch, making sure they are secure.
    cable_bundles
  4. Replace the rubber skirt to its original position.
    • There is a groove around the lip of the washer opening into which the skirt fits. When it's correctly seated, the rubber skirt will feel secure and won't have any play.
  5. Replace the retaining wire.
    • Similar to the rubber skirt, the retaining wire fits into a groove around the skirt itself.
    • I found it easiest to work the wire into the groove by first placing the spring back in its proper location, right by the door hinge and working the wire into place clockwise, using the pliers and screwdriver when needed.
Optional:

If you discover that you need to replace the switch or, like me, you were just curious and wanted to remove the lock switch and see how it works, do the following:
  1. Use the 2.5mm hex driver to remove the two screws which hold the switch in place.
  2. Carefully pull the switch out from behind the steel front of the washer.
  3. Carefully disconnect the two control cable bundles from the switch itself. The cables aren't very long and there isn't much room back there, so this part is a little tricky.
  4. Rotate the switch's bottom arm out of the flat plastic connector to which it's attached. That plastic connector goes to the bottom of the washer, behind a service hatch and can be used to manually unlock the door if the switch failed in the locked position.
    switch_with_connector
    latch_switch_front
    latch_switch_back
Switch information:

The switch is manufactured by EMZ Hanauer in Germany, though I can't figure out what the model number is. I've tried doing searches with all the numbers and inscriptions on the switch, but didn't find the actual part number. RepairClinic.com sells the switch, though they have their own internal part and manufacturing numbers, so comparison shopping would be difficult. If anyone knows the actual EMZ part number, please post it in the comments.

Firefox 4: Destroyer of Memory

I loved my Firefox 3.6, even though it wasn't the best memory citizen nor the fastest browser out there. However, because of its vast number of extensions, it was my preferred browser by several a long shot. What I liked the most was that it handled my 30-or-so perpetually-open tabs very well (with lots of assistance from Tab Mix Plus).

Firefox 4 is abysmal (by comparison or on its own). It has an enormous memory leak that renders my system unusable after an hour or two of using it. I checked memory usage with MacOSX's Activity Monitor and Firefox 4 was using more memory than Eclipse (a notorious memory hog) and had paged around 2 GB of virtual memory.

As much as I miss Tab Mix Plus and my other extensions, I had to switch to Chrome.  Yes, I could go back to Firefox 3.6...but I don't feel like Mozilla deserves it.

Please Mozilla, fix Firefox 4.0. I don't love using Chrome, but you leave me no other choice.