The MDN Show
I’m going through a bunch of queued of podcasts, this post is about four episodes of The MDN Show.
Starting at the 11 minute mark they talk about how to survive WWDC, but some apply to any conference.
- Avoid the food – Sugar highs and/or carb induced comas don’t help you learn
- Take a walk – Let your brain absorb what you just learned
- Don’t plan on going to every session – If you try to make every session, you will fry your brain. (This of course works best if sessions are recorded.)
- Plan ahead – Know which sessions you want to be in ahead of time. As well as a backup for each time block.
- Take notes – The chances that you are going to remember something you heard on the first day is minimal. It best.
- Don’t be afraid to leave a session – As someone who has started to speak more, it is not offensive. I would rather you be somewhere else and learning than in my session and bored
- Arrive to sessions early – at least for the ‘hot’ sessions
- Don’t do work at the conference – You paid to be there, do you work at work.
- Socialize – With people you meet, or track down people you want to meet. Put your twitter name on your badge to help facilitate this.
After the opening preamble there is an interview with Dave Dribin about unit testing. Its kinda from the perspective of never having heard about how unit testing works, but here are the sound clips I liked.
- It is part of a strategy
- Answers the question ‘Does it do what I think it should do?’
- Do it at the method / class level
- OCUnit – xUnit framework for Objective C
- XCode has support for OCUnit built in
- If your unit tests take a long time to run, they aren’t defined as well as they should be
- Have your main build target depend on the unit testing target. That way the build always have to pass
- If you depend on the database or Core Data in your unit tests, then that will slow down your unit tests. Get our your test doubles.
- The Three Rules of TDD
- At around the 33 minute mark there is a discussion of dependent vs. independent test bundles. I don’t know enough about OC development and so it went right over my head; sounded important to know though.
- Adding unit tests to an existing project is tricky
- Side effects of unit testing
- Forces you to design for testability
- Better separation of concern
- Smaller classes that do one thing, and do it well
- Less singletons and global state
- Cleaner code overall
- CoverStory – UI for analyzing files using gcov on the Mac
- OCMock
- Use an in-memory store for your Core Data tests to avoid hitting the disk
- If global variables are bad, well, so are singletons. Use the dependency injection pattern instead.
- You really cannot refactor code unless you have unit tests. If you don’t have them you are redesigning
And then at the 1h8m point, the second interview starts in which Joachim Bondo talks about ‘simplicity’ in Mac applications.
- Myth: The more features, the better the product
- You can’t compare the value or enjoyment or productivity of an application, so they choose features and price
- It is not easy to find the balance between the core features for the application to work, and for it to sell
- If you want a simple interface, you have to work hard to put it. Putting everything in on-by-default toolbars is a cheat
- Have a product statement. Everything else falls out from there.
- Only expose things to users that are relevant right now
- Don’t stick anything into anything unless you have gone through a total process of justification.
- There are many different ways to measure success
- Write applications you would want to use
- You can’t separate design and implementation
The big draw of this episode is the interview with Wil Shipley.
- Find a crowded product area, and then become the most outstanding, most user friendly, most approachable product in it
- Two ways to make software friendly
- Make the software seem like it doesn’t do much
- Come up with a core innovation (or two) – and be really willing to work on it
- ‘Just add a button’ is a synonym for ‘Just stab a kitten’
- People use more features if you give them less features because they can actually use what you give them
- Only add features to major releases. Not point releases. You can charge for major releases.
- (Major) Releases should have a theme
- You don’t want to be a pioneer [of a graphics library]
- advertising idea – showcase the features that are not in the product
And then Matt Gemmell provided some little cliches
- Simplicity is the ultimate sophistication
- Designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away
And then he had some thoughts on how to achieve the concept
- The overall set of features should be as small as possible
- Design a 2.0 application, and then cut it down to 1.0
- Do the most wanted thing; please the bulk of people
- Options are a failure to simplify or focus your feature
- Spend more time designing apps that do less
And finally, episode four.
It starts with an interview with the guy behind a Cocoa REST framework, but the 13 marketing tips was more interesting (start at 39m). Rather than write down notes, here are links to part 1, part 2 and part 3.