NSConference 5: Day One

This was my first NSConference and I was impressed. Three days of full-on sessions covering everything from deep technical gotchas, through brutally honest experience reports and even across to basic economics lessons. And the people… I’ve never met so many iOS and Mac developers in one room. Everywhere I turned, there was a developer of an app that I’ve used or know about and admire.

Thank you so much to Scotty and the team. Everything (apart from the wi-fi!) went swimmingly!

iOS performance testing

Bill Dudney @bdudney bdudney@me.com

• Double check performance even when you think you’re doing it right
• Watchdog gives you lots of time but user expectation is instantaneous
• You can use more time on suspend… but don’t go outside watchdog times otherwise app will have to start from scratch
• Use Time Profiler to check CPU usage on startup
• VM tracker tells you how much memory is dirty - most crashes come from here
  • Allocations can be low but dirty memory still high
  • e.g. Image allocations
  • Memory gets dirty as soon as you write to it
• ARC deals with most of issues for you but won’t deal with cycles
  • Can see in leaks
  • Deal with by using weak references
• Graphics
  • Quartz all happens on CPU
  • OpenGL happens on GPU
  • Separate processor - more power
  • CoreAnimation gives you access without writing raw OpenGL
  • It’s a compositing engine
• Offscreen rendering can take up lots of time
  • Check offscreen rendering highlight in instruments

searching for speedy searching

Simon Wolf @sgaw or @sw on ADN

• WWDC 2010 mastering CoreData suggests title contains[dc] $content
• Can use beginswith to improve speed
• Even faster use >= 'frog' and < 'froh'
• But doesn’t work for in-word searching
• SQLite with full text search FTS (or FTS3, older)
• Have to build own version of SQLite and include in your app
• And then can’t use with CoreData
• Use FMDatabase & FMDatabaseQueue to behave better with threads
• Use SQLite with FTS to create an index that refers to the Managed Object ID
• otsNormalizeString string category to remove diacritics (in blog post)
• FTS search is word based, * is wildcard
• Can also define “nearness” of terms
• Need to keep index in sync with CoreData

The ultimate developer toolchain

Richard Morton @richardmorton

• “if you have a machine and don’t buy it, you will ultimately find you have paid for a machine and don’t have it” — Henry Ford
  • buy a decent developer machine!
• iOS Support Matrix gives you a good way to find which test devices you need
  • see @isupportmatrix
  • written by Richard Stelling @rjstelling
• Injection for Xcode: restores “Fix & Continue”
  • uses bundles & method swizzling
• Xcoverage
  • LLVM provides build coverage
  • instrument program flow & generate test coverage files
• Mogenerator
• AppCode by JetBrains
  • would still do bulk of dev in Xcode but boot up AppCode to use refactoring & other unique features
• Jenkins
• PaintCode
• xScope
• ResourceHelper
  • extra QA for assets

Why making 12 Games in 12 months is a good idea

Matthijs Hollemans @mhollemans

• lots of game jams around
  • including #OneGameAMonth
  • http://compohub.net lists them all
• why?
• experimentation & innovation
• learning how to finish
  • often there’s a long hard grind to finish
• learn to limit your scope
  • one single thing
  • take idea and strip it to the core
• putting constraints on what you’re doing enhances your creativity
• also get experience in failing to finish games
  • good to find a way to fail faster!

UISS - UIAppearance on Steroids

Robert Wijas @robertwijas

• UISS available on github & CocoaPods
• UIAppearance & UIAppearanceContainer lets you set appearance defaults application-wide
• but need lots of code to do anything…
• UISS uses JSON syntax, similar to CSS
• lets you set styles for inner elements
• and also styles per device type (iPhone/iPad)
• lets you define variables
• easily disable bits by prefixing selector with “-“
• setup:
  • [UISSS configureWithDefaultJSONFile];
  • add uiss.json file
• debug: UISS status bar
  • tapping status bar shows errors in uiss.json
• works with live updates in uiss :-)
  • just make uiss.json available via HTTP
  • [UISS configureWithURL:url]
  • let’s you build the app and give it to your designer to adjust, even without Xcode
  • debug option lets you adjust URL
• generates UIAppearance code for you
  • you’ll want to do that before you create production code
• can use UIProxy to control your own custom views with UIAppearance
  • also allows you to adjust them with UISS
• other systems doing same thing:
  • NUI
  • pixate
  • both use traditional CSS - so heavier dependencies

Becoming a product company

Daniel Pasco @dlpasco daniel@blackpixel.com

• started in 2007 as contracting but aimed from the beginning to be a product company
• 6 people for 3 years, then doubled in size for 3 years
• operate as a remote company, HQ in Seattle, but spread over US, with a couple in France
• have shipped hundreds of apps, but all for other people
  • have a reputation for confidentiality
  • so can’t tell anyone about them…
• there’s an opportunity cost to do product development
  • in the presence of lucrative contracts, you take a risk and turn away money
• however, you get stability
  • find that contract work is busy Feb to July
  • occasional spike in November preparing apps for Xmas
• did client work until they had enough money
  • then did some product work until money ran out
  • then swapped back to contract
  • big gaps between product dev
  • when went back to code, there were lots of changes to make with all the new knowledge…
• initial product was Bistromath
  • massively over-engineered…
  • developed in a vacuum
• need to share app with people who know nothing about how the app works
  • tester should not share any of your assumptions
• life after being featured…
  • intense — but treat it as a bonus
  • people need to be aware of the app outside of the app store
• painful first product experience made them very gunshy
• learnings:
  • vet your ideas early on
  • get feedback on betas
  • no excitement? that’s an issue
  • if someone wants to extrapolate — that’s great! but leave those additional features for later
  • have a sustainable dev plan — through to the product release
  • check out marketing
• changed business model:
  • grew contracting team so could subsidise continuous product team
  • could keep momentum going
• got the chance to acquire three products from other developers (NetNewsWire, Kaleidoscope, Versions)
  • existing userbase
  • well-known brands
• products acquired through revenue-share
  • no money up front
  • revenue share decreases as time goes on
• wanted to share info & blog monthly, but…
  • have competitors: don’t want to reveal feature roadmap
  • no one knows if you miss a deadline: would have announced and missed three times!
  • no one knows if you drop a feature you promised
• Apple will not let you transfer an app between accounts
  • unless you get the keys to the old account, customers will have to buy the app over again…
  • trying out introductory pricing on upgrades to help people recover their losses
• iCloud sync issues with NetNewsWire
  • iCloud/Core Data: still unusable…
    • opening the iCloud container can take up to 25 minutes
  • iCloud/Key Value Store: works fine
  • iCloud/Ubiquitous Documents: has issues
• got creative tensions from people caring so much about their own products
• changed aim to be frequent, shorter, release cycles
• got lost with features — endless ticket list
  • @jury drew a line in the sand: ship by this date
  • focus accordingly
  • the plan:
    • 4 weeks for feature complete
    • then 4 weeks for no P3 bugs (fix or defer)
    • then 2 weeks for no P2s
    • then 1 week for no P1 bugs
  • there will always be another release
    • if that isn’t built into your plan — change your plan!
  • it’s ok to ship with bugs, as long as they’re not blockers

Software Architecture: what questions to ask?

Jacob Gorban @apparentsoft

A short list of questions to ask when adding a new feature to your project:

• good ideas are insidious: they increase scope
  • must definitely be worth adding…
  • here are some questions to think about before adding a new one to your project
• is it really a good idea?
  • is it good for your business?
  • it it good for your app in the long run
• is it DRY?
• is it orthogonal?
  • good to have smaller pieces joined than one big piece
• is it testable?
• is there another way?
  • when you see a good move, look for a better one — Emanuel Lasker
• what is the cost of changing this later?
• what would the architecture look like if I didn’t have this problem?
  • is this problem framed properly for my app?
  • perhaps we can change the problem…
• document the rationale
  • not just for later — helps you understand the problem
  • could also discuss with others
• what are the facts and assumptions?

Download from http://bit.ly/software_architecture_tips_pdf

WebKit UI Inspector Tips and Tricks

Daniel Jalkut, Red Sweater Software @danielpunkass

• use webkit inspector to fix a page for printing
• prototype app store previews
• can set inspector on in your own (Mac) app:
  • just add -WebkitDeveloperExtras YES argument
  • can add same preference on other apps
  • defaults write <bundle-id> WebkitDeveloperExtras -bool YES
  • or globally: defaults write -g WebkitDeveloperExtras -bool YES
• Dictionary app uses a WebView… so you can inspect it!
• preference key doesn’t guarantee that the “Inspect Element” menu item will be available
• Mail.app is a very good robust HTML editor using a WebView but it overrides the contextual menu
• for any process (even one that has custom contextual menu):
  • attach to target
  • break on [NSView menuForEvent:]
    • lldb: break set -r menuForEvent
  • ctrl-click in the suspected WebView
  • run code: [[[$rdi _webView] inspector] show:0];
    • event target is in $rdi
• iOS webkit inspector can inspect Safari or any UIWebView in an app that you own

The Invisible Interface — Adding offline speech UI to your app

Halle Winkler @politepix http://politepix.com

• large vocabulary tasks
  • use server-based speech recognition
  • UITextView, Nuance, AT&T, iSpeech
• command and control
  • can use offline speech recognition
  • e.g. OpenEars
• speech API dimension is time
  • make time, rather than just take time
• small steps through decision tree, means small steps backwards
  • trust & quickly verify
  • switch between small vocabularies
• watch out for “out of vocabulary”
  • what happens when people walk past talking loudly…?
  • it’s a solved problem in speech recognition, but deciding what to do is a design issue

iOSDev UK: Coding for your Future Self

Martin Pilkington, @pilky

• there are three you’s
  • now — doing the work
  • future — code guru
  • past — got let near your computer and vomited all over your code…
• consistent formatting — follow conventions
  • don’t fight the conventions
• composition vs subclassing
  • cocoa often better to use composition
• copy immutable classes — don’t use a reference
• don’t ship code with exceptions
  • in Objective-C they’re for invalid state — programming errors
  • use NSError instead
• naming
  • don’t abbreviate
  • no namespaces, so prefix all your classes, preferably with 3+ chars
  • prefix category methods on other classes too, e.g. abc_categoryMethod
  • capitalise acronyms
  • if last param is error return, should be error:
• if you comment every method then you’ll be in the habit of commenting when it counts
  • not sure I totally agree — comments can get out of date with the code. perhaps better to comment longer code pieces rather than each and every method
• large classes and large methods are unmaintainable
  • also splits out more stuff into back-end code
  • better for testing, better for multi-platform
• better to inject dependencies (tell, don’t ask)
  • or at least expose a property to set during tests
  • if do so, then either set default in init, or use lazy construction in the getter method
• notifications
  • can also be distributed to other devices
  • see kellabyte.com for continuous client
• regular refactoring:
  • always leave the campground cleaner than you found it
  • have spring cleaning days/hours
  • lots of little refactors mean less big rewrites!

iOSDev UK: Animation for Serious Apps

Neil Taylor, Aberystwyth University, @digidol

• CALayer is not actually the view — it’s the model
• Old-style UIView animations are now discouraged — start to use blocks instead
  • block-style also allows you to add further animations on completion
• CALayer animation is slightly different
  • animate position, not centre
  • bounds, not frame
  • values are animated, not changed
  • CAAnimation setFromValue:/setToValue:
• Keyframe animation lets you animate across a complex path
  • Core Animation will calculate intermediate frames
  • e.g. shopping cart items thrown into a cart at the bottom of the screen
• Other bits
  • can have transactions to tie animations together
• More useful references in slides…

iOSDev UK: Using TDD to write an iOS App

Graham Lee, professional in-betweener, @iamleeg

Or, “What is TDD and why should you use it?”

• discovering bugs is not the point of testing at all
  • instead, you are proving that there aren’t bugs
• once we’ve fixed bugs, we don’t want to see them ever again
  • tests can ensure that regressions don’t come back
• TDD allows us to prevent bugs from ever happening!
  • you won’t prove that the app works how the customer expects, but you will at least prove that it works how you expect it to work…
• TDD imposes black-box thinking for the developer
  • makes you think about how the code should be designed and scoped
• accurate planning: we know how much we’ve done
  • and we can be honest how much we have done
• TDD does not:
  • ensure that the developer understood the requirements!
  • ensure that the requirements remain static
  • ensure that pieces work together (unless you add integration tests)
• tests should be short and have descriptive, English names
  • e.g. testDatesOnTheSameDayAreConsideredSame
  • general pattern
• tests should be fast — well under a hundredth of a second each, so a second or so for all of them
  • avoid integration tests in unit testing since they take too long
  • don’t interrupt your concentration by waiting for tests
• as a result, your classes will be smaller and have obvious effects
  • any side-effects are few and easy to predict
  • if your test fixture gets big, then that’s a sign that you need to refactor (possibly including the tests!)
• TDD encourages “tell, don’t ask” configuration
  • inversion of control
  • pass in helper data rather than discover it internally
• avoiding testing everything at once:
  • use fake objects (with same interfaces) to provide simulated interactions
  • use mock objects to record and verify interactions
• Objective-C mock frameworks:
  • OCMock
  • Mocky
• Code coverage is useful for adding tests to an existing app
  • Not so useful for building new code
  • If you’re not covering code with TDD, then you’re kind of cheating yourself

Q&A

• @pilky knows about using the accessibility framework to write automated UI tests using javascript
• can use XCodeBuild to run unit tests from command line
• use GHUnit instead of built-in OCUnit to output JUnit XML reports
• iOS Enterprise Development — O’Reilly book by James Turner
  • includes lots of useful
• squish automated GUI testing?
• test code linking…
  • app should be plugin host, providing linked libraries
  • but it doesn’t work — have to link yourself from test code

iOSDev UK: Building Custom Controls with UIView

Rory Prior, ThinkMac Software, @roryprior

• generally subclass UIView directly
  • can subclass other controls, but things might not happen how you expect since lots of things happen in the background
  • and you may need to use private APIs…
• override methods:
  • initWithFrame for programmatic creation
  • initWithCoder for IB-created views
  • drawRect for actual drawing
• UIKit uses top left as origin
  • but CoreGraphics uses bottom left…
• adding UIImageView is easy
  • but quite heavyweight
  • instead can draw a UIImage directly
• similarly, can use UILabel or draw string directly
  • NSString drawAtPoint:withFont:
  • NSString drawInRect:withFont:
  • NSString sizeWithFont:
• drawing shapes:
  • CoreGraphics (nasty low-level C stuff :-) )
  • UIBezierPath (introduced in iOS 3.2)
• complicated graphics often still done better by using bitmaps — UIBezierPath can be processor-intensive for lots of lines
• UIColor can fill in patterns as well as flat colour

user interaction

• override UIResponder methods to detect touches
• you’ll need UIGestureRecognizers to detect swipes, pinches, etc
• but use sub-views of UIButton etc to make thins much easier
• see slides for nice example of adding UIResponder and UIGestureRecognizer
• use the delegate pattern to send feedback from your view to the rest of your app

iOSDev UK: Beyond NSLog

Tim Isted, @timisted

NSLog, XCode and gdb

• useful macros for logging:
  • __FILE__ (full path)
  • __LINE__
  • __FUNCTION__ (and __PRETTY_FUNCTION__)
• NSStringFromSelector(_cmd) gives you current message
  • Lots of these useful NSString functions, e.g. NSStringFromCGRect
• use macros in log define
  • non-debug version should be something like: TILog(...) do {} while (0)
• XCode preferences > Behaviours
  • Run starts — can choose what displays
• XCode also has a variables view, hidden in the next pane of the debugger
• add breakpoints for exceptions or non-source code by using little plus button at bottom of breakpoints pane
• breakpoints have really useful options
  • log to console on hit (with auto hit count)
  • continue automatically
  • only do stuff on conditions
• gdb commands:
  • s = step = Step In
  • m = Step Over
  • c = Continue
  • p = Print
  • po = Print Object
• debugging Core Data: use [self valueForKey:@"propertyName"]
• can use addresses instead of variable names in po
• can make breakpoints user-specific instead of project-specific

Instruments

• Time Profiler — great for catching infinite loops!
  • shows you time spent at certain places in call stack
  • tick the “Show Obj-C Only” checkbox
  • look for purple user symbols!
• Heap Shot tool find leaks
• quite a few WWDC videos on Instruments

iOSDev UK: Programming iOS Sensors

Alasdair Allan, Babilim Light Industries

http://programmingiphonesensors.com/

Magnetometer (it’s not a digital compass!)

• 4th gen iPod Touch doesn’t have magnetometer
  • so no outside AR apps without markers
• UIAccelerometer API newly deprecated for CoreMotion in iOS5
• if you want compass heading but not location, then just start up [locationManager startUpdatingHeading]
  • you won’t get location updates warning
• however, magnetic north varies across the world
  • there’s a big lookup table in the iPhone that can translate the magnetic heading into true north
  • so you need actual location to work this out
• watch out for device orientation: magnetometer always reports heading pointing out of top of device
  • need to rotate according to device orientation…
• local magnetic anomalies cause a fluctuating magnetic field — which is when it tells you to wave your device around
• Earth’s magnetic pole is a quadrapole, not a bipole — it swaps over every now and then and the north pole goes south

Gyroscope & Accelerometer (CoreMotion)

• iPhone 4 has more bits in its accelerometer sampler
• combining gyroscope and accelerometer provides very accurate device attitude
• if there’s no natural timer in your app, then you may have to use the push API
  • otherwise much easier to use pull API
• CMMotionManager should be treated as a singleton (but API allows you to create multiples…)
• monitoring does take a lot of CPU, so remember to stop it when you’re finished
  • device motion at 100 samples/sec uses 65% of iPhone 4 CPU
  • see “Pushing Device Motion” slide
• you can fetch a frame of reference and then work out attitude relative to that

AR Toolkits

• Marker based:
  • ARToolKit for iOS
  • Qualcomm AR Toolkit
• Location-aware
  • doPanic Toolkit
  • ARView — available from Programming iOS Sensors

External accessories

• Arduino for iPhone!!!!
  • Redpark Breakout Pack for iPhone
  • been going through Made for iPhone accreditation for the last 3 years

Over The Air Hack - a LEGO robot with an iPhone brain

As promised, here are the details of my Over The Air hack — The Eyes Have It — which won prizes for “Best Hardware Hack” and “Best Use of Other Features” in the overnight hack-a-thon competition. I also took it along to Mobile Monday London’s Demo Night on the following Monday.

The hack was a LEGO Mindstorms robot with an iPhone brain that followed faces in front of it and steered towards them. It performed well on stage, following me as I gestured towards it, just like a small pet.

The hack was composed of two parts: an iPhone app that detected faces in the video feed from the front-facing camera; and the LEGO robot that took instructions from the iPhone and steered accordingly.

Communication

Getting the two parts to communicate was one of the trickiest areas to get right, and caused extra headaches before each presentation. Both LEGO Mindstorms and the iPhone can communicate over Bluetooth, but Apple has restricted Bluetooth communication to companies that will pay the Apple “Made For iPhone” license fee or that use particular hardware. Bluetooth comms is not available through the standard SDK and apparently needs some kind of “secret handshake” to work.

Unfortunately, Mindstorms came out a while before the iPhone and uses a different Bluetooth chip; and LEGO and Apple haven’t managed to do a deal to provide Mindstorms access from the iPhone (perhaps because LEGO has open sourced much of their software?). LEGO has now released an Android app to showcase mobile phone integration, so let's hope Apple can work with them to get some iPhone apps too.

So no Bluetooth, and Apple won’t let you talk over the dock connector either… That left feeding information to the robot through one of its five senses — a touch-sensitive button, an ultrasound distance sensor, a microphone, a light sensor or the motors themselves (which can detect rotation).

A quick search on LEGO Mindstorms iPhone brought up the iPhoneRobot which used the light sensor to pick up different greys on the screen. This was a great start, but it wasn’t quite what I was looking for. For a start, it required the LeJOS firmware on the Mindstorms brick — this is a cut-down Java VM that replaces the built-in LEGO firmware. I’ve left my Mindstorms with the default LEGO firmware as I use it with my 7 year-old son. He’s not quite ready for Java, but can easily understand the Labview-based visual programming that comes with the Mindstorms kit. Secondly, the robot itself wasn’t quite suitable — I wanted a robot that would recognise faces, so I needed the iPhone to be pointing upwards towards people’s heads rather than along the ground.

Motor skills — building the robot

Designing a new robot from scratch takes quite a while and I only had overnight. Unlike normal LEGO with bumps and holes, the Mindstorms kit uses the new-style LEGO Technic, which is mostly holes and connectors. Also, LEGO’s own sample models are pretty complex, as they are built to look like animals or people as well as interact.

Fortunately, I found a great site with designs for quick Mindstorms models that are easier to hack to do what you want. Some of the ideas are amazing — especially a Segway that actually balances! I started with the 3-Motor Chassis and added the distance sensor on the front to prevent crashes. I also added the button sensor on the side to help with starting and stopping the program, as the iPhone was in the way of the program buttons on the Mindstorms block.

Here’s some pictures of the final result, holding the iPhone pointing upwards. I’ll try and generate some build instructions later.

Computer vision — the iPhone app

Humans are exceptionally good at seeing faces. Our brains have been trained from birth to detect and analyse faces very quickly. We can tell which way people are looking from far away and even see faces in random patterns.

Computers have a harder time of it, although recent developments have massively improved what is possible. Companies such as Polar Rose have shown demonstrations of both face detection (finding out where any faces are in an image or video) and facial recognition (matching the detected faces against a database of known images) running in real-time on mobile phones. Unfortunately, their code is not available to an overnight hacker, though they’ve recently been bought by Apple so we may see interesting capabilities in future iPhones.

However, Intel launched an open source project back in 1999 called OpenCV (for Computer Vision) and not only is it still going strong, but the library is easily compatible with the iPhone and has a git repository of a ready-built library. OpenCV is all about providing well-optimised functions for real-time computer vision, so that developers do not have to reinvent the wheel. It includes face detection algorithms and a guy called Roy has posted some examples of how to get face detection working on an iPhone video feed.

Roy’s sample code was written for iOS 3, and iOS 4 provides much easier methods for accessing the video feed from the device. I updated Roy’s code to use the new AVCaptureVideoDataOutput class that provides direct access to uncompressed video frames from any iPhone camera. This bit took a little while longer than it should have done, as the video feed is provided as landscape (you’re recording a video, right?) whereas its preview feed is oriented the same way as the camera. This was not obvious, and made worse by the fact that face detection algorithms do not work when the image is rotated by 90°… There was a point in the early hours of Saturday morning when I thought there would be no face detection at all!

Anyway, following Roy’s recommendations, I scaled down the input image and adjusted the parameters of the OpenCV face detection call. At the moment I transpose the image before sending it to the detection algorithm, but I suspect it would be faster to use a rotated Haar feature set (the bits that the algorithm picks out in each image to match faces). I also didn’t use Roy’s changes to use integer arithmetic rather than floating point — it turns out that the iPhone 4G has enough grunt to cope with the standard OpenCV code.

You can get the iPhone code from my github repository and try it for yourself. Note that it’s hardwired to use the front-facing camera at the moment. If you don’t have an iPhone 4 just change the AVCaptureDevice to point to the ID of the other camera and the rest of the code should still work (though possibly a little more slowly…).

Light and dark — the LEGO program

So now I had a robot base and an iPhone app that could see faces. The next step was to connect the two together using the light sensor.

LEGO provide a drag and drop programming interface for Mindstorms that lets you build up programs using blocks such as “move motor”, “wait for sensor input” and control logic of loops and if/else switches. It’s quite capable and makes simple programs relatively easy, but using variables and arithmetic can be a little cumbersome.

The main issue in getting the robot to drive was calibrating the light sensor, especially when each demo was under different lighting. After a fair amount of tweaking (some just minutes before presenting at Mobile Monday London’s demo night), the best results turned out to be when I crammed a small piece of cardboard into the hinge that held the light sensor onto the iPhone…

You can download the “.rbtx” file from my github repository, but for those who don’t have the LEGO software, the algorithm is essentially:

1. Calibrate the sensor when pointing at the black and white squares to either side of the control square on the iPhone screen
   • The robot prompts for each reading with its display and waits for you to press the button between each sensor reading
   • The program reads the raw values from the sensor and calculates its own scaling values, as the built-in calibration routines turn on the light on the sensor — this works for reading black lines on a white sheet of paper but isn’t so good at reading the backlit screen of the iPhone…
2. Wait for another button press to start the robot moving — so you can step back and make sure your face is in frame
3. Read the raw value of the light sensor, convert it into a value between -90 and +90, and then steer that amount, then repeat
   • The program checks that the light sensor value is within a reasonable range before steering, otherwise the robot tends to go round in tight circles and you have to run round it like a lunatic trying to get your face in the camera frame!
4. When the distance sensor picks up something closer than 6 inches, stop, play a sound and show a beating heart on the display (“I’ve found you!”)
5. Start moving again when the button is pressed

To give you an idea of what this looks like in the Mindstorms NXT software, here’s a picture of the program!

Prizes

Thanks to Monotype for the beautiful poster of Gill Sans Bold Extra Condensed. They were going to give me two, but were happy to swap one for a copy of FontExplorer Pro instead, so I can see my digital fonts presented almost as prettily. Apparently, it’s now available for Windows as well as Mac OS X.

Taking a day a week for yourself

More and more people I speak to are coming up with the same idea — that working one day a week for yourself gives you a better balance and loads more creativity and fulfilment. I ran a session at BarCampLondon6 on exactly this topic and it's good to hear more people starting to make similar changes to their lifestyle.

Here's Matt Webb's take:

Here’s my challenge. Right now, put aside 100 hours over this summer. Do it right now, in your head. Put that time aside. 100 hours. 8 hours a week for the next 12 weeks. One hour a day, or one working day a week. It’s one summer out of your entire life, it’s nothing. Okay, you’ve got that 100 hours?

Now for the next two days, go to talks and start conversations with people you don’t know, and choose what to spend your 100 hours on.

I guarantee that everyone in this room can produce something or has some special skill, and maybe they’re not even aware of it.

Ask them what theirs is, find out, because you’ll get ideas about what to learn yourself, and decide what to spend your 100 hours on. Do that for me.

Because when you contribute, when you participatein culture, when you’re no longer solving problems, but inventing culture itself, that is when life starts getting interesting.

I moved from taking one day off every other week to one day off every week at the beginning of June and even that has made a big difference. My personal project has been learning to build apps for the iPhone -- starting with the Stanford iPhone Application Programming course and Aaron Hillegass's Cocoa Programming for Mac OS X.

Through evenings and snatched half hours on the train, I've got through most of the course and am starting to explore other areas, such as adding hamcrest and OCMock to the built-in OCUnit iPhone unit tests. I still plan to build and release my own apps as I get more of an understanding of what's possible.

So Matt, I've taken up your challenge before you even issued it and I look forward to others doing the same!