Just finished my Lab 1 for Peter’s Mac class and I want to keep track of the little bumps along the way.

Things I learned:

1. If you want the keyboard to hide after you are finished inputting text into a field – basically once the field loses focus you need to do this:
   [txtControl resignFirstResponder];
   thanks to iCodeBlog for that one. That site also has the best tutorial that I could find for getting started on iPhone apps.
2. It’s much easier to do a View-based application with the iPhone SDK template, but this means you have fewer UI objects to play with. I still have not figured out why this is. In the regular application template there is a wide variety of inputs, pickers, etc. But in that template you have to create custom views and though I read up on this a bit, it seemed like overkill for Lab 1.
3. Looking at the existing apps in the iTunes store is a good way to see what UI designs are working already in the real world. I like to think I’m pretty good at laying out apps, but it’s amazing how much better they can be and it’s very helpful to look at what people are doing in the store since they have probably gotten a lot more feedback on their UI.

The amount of information out there about iPhone code, especially for beginners is really sparse still. It seems like every time I google about an issue I’m hitting the same few blogs/sites. I’ll post the code for my apps when the due date has passed so that there’s just a little more out there. Remind me if I forget.

Taking this from Dolske:

1. Open this link, select-all and copy it.
2. Open up the Error Console.
3. Paste into the Code field at the top, and click Evaluate.

10 random Wikipedia URLs out of 85…

1. Polaroid
2. Mötley Crüe
3. Letterpress printing
4. Morphology (linguistics)
5. Eicar test file
6. Settlers of Catan
7. The Wire (TV series)
8. Transport Layer
9. Explorers (film)
10. Jeremy Hammond

This morning was the culmination of months of work from RelEng. We have finally turned on unittests as well as a11y tests on the production Buildbot master which was already doing the nightlies and l10n builds.

Mostly this change is to make our lives easier. Now we have one instance of Buildbot to pay attention to (disk space, waterfall page) with one pool of slaves that can do several types of builds (nightlies, unittest, tracemonkey, l10n). This will make replacing burned out slaves incredibly simple. Doing this consolidation also led to a great unittest factory (thanks to catlee) that will make adding unittests to other branches much easier to deploy.

What does this mean for you? Well, if you are someone who looks at unittest output regularly you are probably familiar with something like this:

Where each unittest build has its own waterfall column and you can gauge how the unittests are doing by comparing them to each other (changeset, start time, colour).

The new way will be different:

There will only be one column on the waterfall, with no machine name since the unittest build will be coming from a pool of over 14 slaves for that platform. When you look at this waterfall column you will see the colour (thus result) of the most recent build, but there may be several builds that start within moments of each other.

More investigation will be needed to look at changesets and start times with this new method.

Hopefully people will adjust to this, and we welcome your feedback about the new setup.

It’s a very big step for us, one that leads to hopefully parallelizing the unittest steps for quicker unittest results, and eventually doing unittests on builds independently – where right now the unittest run includes a build step every time, we would like to get to a place where unittests can be run on a completed build so that the suite of tests could be run repeatedly on the same build for example.

We’ll wait a day or so to make sure that this consolidation is running smoothly and then the standalone production unittests will be turned off, the mac slave machines will be moved into the new pool and the linux/windows vms will be deleted and then new ones created for the production pool. Hopefully there won’t be too much of a backlog on builds pending while we wait to get those new machines added.