Stack Overflow Dev Days: London

As promised previously here's my review/notes/random thoughts from DevDays London.  Plus I'm keeping this positive this time.

As I was slightly invested in seeing the countdown app in all it's massive screen glory. I was trying my best to arrive in plenty of time.  Unfortunaltely my 3 year old son had other thoughts on me leaving early.  Fortunately I arrived in the "great hall" with a sign on the screen saying "Dev Days starts in 43 seconds". Nothing like cutting it fine!  Seeing all the elements on the screen slide out during the fade to black on a screen the size of my house was definitely cool.

In good tech conference tradition the day started with a comedy video.   I lost count of the in jokes and I've never seen a punchline coming from so far off as the 6 to 8 week deadline estimate.  Plus I'm looking forward to HTML6 and the tag.  Hopefully they'll post the video somewhere, but in the mean time you'll have to make do with this: http://www.youtube.com/watch?v=H3slPNJdbF4.

Pair programming: "You're born alone. You code alone. You debug alone. You die alone."

The first session of the day was Joel (complete with Union Jack flag and I <3 London tshirt) Initially I was concerned that this was just going to be the same presentation he gave at Business Of Software last year. Fortunately there were some new twists on things and some new ideas. My notes:

• Always search everywhere. Never ask the user to say which fields to search.
• Decisions are about balancing simplicity and power.
• Do you do one thing well v/s have lots of features
• More features mean more choices.
• Choice is attractive but too many choices prohibit purchases.
• "The paradox of Choice"
• Less features v/s a defining sense of self
• Don't ask questions the user can't answer.
• Users blame themselves when selecting the wrong option.
• Most people need more than simple.
• Sales increase when features are added
• Power = features; options; capabilities; $
• What do users really care about? - Make something that responds to that. Either directly or indirectly.
• Computers shouldn't set the users agenda.
• Not all features are created equal. There are good & bad features.
• Good features come from or are the result of good design.
• Help users achieve goals v/s interrupt users
• Elegance: don't go on about how good/clever you are.
• [Having to make] decisions waste[s] users time.
• Elegant code is not the same as clean code.
• Elegant code is more than clean. If elegant it "doesn't look like there's enough code".
• Elegant UIs take more work.
• Not requiring user confirmation requires users be able to 'undo' the decisions you make for them.

Didn't pay much attention to the Python talk as it didn't seem that appealing and I was exploring helloapp. - Until my phone died that is.

Due to a last minute reorganisation of speaker order. Joel was back with the rundown on FogBUGZ 7. I already use this at work and for my personal projects but was prompted to investigate some features I wasn't using: integrated crash reporting; the backlog plugin; subcases & tags.  Joel also introduced Kiln.  I'm a beta user for this already but it was nice to see someone else using this.  The surreal side to this whole presentation was that Joel was using the example of developing the countdown app used at each devdays and how you could use FogBUGZ in that process.  I did. Very Deja Vu.

Android
Things that caught my attention:

• No app review process - suprising!
• Home screen widgets
• Background services
• Interprocess comms 
• Universal (in app) search
• 2.0 introduces:
• Bluetooth support
• Integrating contacts from multiple accounts
• Camera APIs
• Device targeting via custom device specifying via IDE plugin - create your own emulator
• Tried to claim that a slow emulator is a good thing. - It forces you to make it fast on the emulator thereby ensuring that it's definitely fast on an actual device
• Form/window/control layout is XML based
• Activities = forms
• Intents (really must find out what these are)
• Native support for SQLite - can share stored data with other apps via a content provider
• New GoogleMobile Analytics tools can be included in apps
• Registered developers can buy developer phones (fully unlocked and available with no contract.)

jQuery

• Uses TestSwarm - for cross browser testing
• Find something > do something
• Create something > do something
• $ is an alias for jquery method
• test code at jsbin.com
• Don't select by just a class name as very inefficient in older browsers (which are slower anyway)
• It fails silently - so if it seems to be doing nothing...
• use single methods for setter and getter
• .live() - allows updating selector for changed/added DOM element
• a plugin is a custom function that's reusable and distributable
• Mobile version coming

Jeff Atwood

• Be willing to fail!
• Read Coders at Work
• SO users are muppets ;)

Qt

Note. Ducked out of demo (second) part of this session to get some lunch/

• Nokia's solutions for native development
• "Being able to debug is the most important thing for developers" - the reason for the need for Open Source
• Lowering the entry barrier for developers is the key for driving adoption
• Success comes from 3rd party Innovation
• Claims to be "the Java we never got"
• Less code needed to achieve the same as lower level languages (C) - Saving money in maintenance phase
• FREE
• Has it's own IDE - QtCreator

Jon Skeet (& Tony the Pony)

• Users want programs that do what is simple and obvious to them, at that particular time.
• Architects design/create systems that are just as complicated as the real world but slightly different.
• Evolution has cheated us by not giving us 16 fingers. I would have made us better at counting.
• We (developers) struggle with the difference between continuous and discrete numbers.
• We (developers) struggle with Text: multi-byte chars; combining chars; Turkish
• We (developers) struggle with Time: 12/24 hours; date formats; timezones; Daylight Savings Time.
• Know a bit more than you need to. What problems are you likely to have if the app/code was extended.

iPhone

• Objective-C is like marmite.
• "and that's why we have to say the same words twice" - WTF?!?
• Obj-C is opinionated and includes a lot of historic baggage. :(

How not to design a scripting language

• Don't read the dragon book. Recommended alternatives: Engineering a Compiler and Modern compiler implementaion in X
• Foreign Function Interfaces: bad in principle but allow calling out to C libraries when need code that executes faster.
• "A good rule for life in general: Don't expose yourself!"
• Things that are bad: eval() and dynamic include/import

Yahoo! Developer Tools

"every browser is a bastard"
Some browser are "differently-abled"
JS Libraries are edge cases
YUI - looks useful, especially CSS grids
YQL - WOW! (see http://www.youtube.com/watch?v=SA4Et1DiVbE)

MISC

A couple of quick notes on the organistaion of the event and applicable to any such event:

• Have a countdown that the speaker can see so that they know when they running out of time, or out of time.  - This is always preferable to someone coming on to the stage to tell them they have X minutes left.
• Have a backup microphone on standby.
• There's no excuse for having unprepared speakers.
• There's no excuse for having unreheased speakers. Speakers need to know how long they will take and what they can do in the time they have.
• Text and code must be visible on the screen to everyone watching (if that's what you're trying to show) - zooming in is fine to highlight a specific thing. Staying zoomed in and having to keep scroll around while zoomed in is not good for anyone. 
• If doing a talk introducing a subject cover:
• 
  
  • What can you do?
  • What do you need to do it?
  • What are thre fundamentals people need to know?
  • What gotchas should people be aware of?
  • What recommendations/tips should people know about?
  • What are the answers to the frequently asked questions?
  • Show a few cool and easy examples.