Showing posts with label DevDays. Show all posts
Showing posts with label DevDays. Show all posts

Tuesday, November 03, 2009

DevDays CountDown App: My Analysis

I promise, this'll be the last time* I post about my DevDays CountDown App.

Now it's all over, it seems a suitable time to do some analysis:
  • Why did I write it?
  • Why did it get picked?
  • What helped me develop the application?
  • What did I learn from the process?
  • What would I do differently next time?

Why did I write it?
 A few reasons:
  • I thought it'd be cool to write an app that got used in quite a cool, high profile event.
  • I had an idea that I thought was quite good.
  • I thought it'd be a good opportunity to build some experience with WPF and particularly with WPF animation.
  • To prove to myself that I was able to produce a good piece of software that meets a clients requirements.

Why did it get picked?
Officially:
"... because of the twitterfeed and because the graphics are actually appropriate"
I think there are several reasons:
  • Because I actually produced something that met the requirements. - I was surprised by the number of entries that didn't. (Users won't [usually] use[/buy] a product that doesn't meet their needs.)
  • Because I actually delivered something. - There were a lot of comments from people who said they were working on something but never posted anything. (There's no reward for not showing up.)
  • Because the graphics were appropriate. - While I also had some novel. alternative, ideas I knew these wouldn't tie in with the StackOverflow or DevDays brands. (A bit of marketing knowledge helps in software development.)
  • Because I did more than was asked. - The twitter element wasn't part of the original requirements. (Having something unique is always a good selling point.)


What helped me develop this application?
  • I made sure I understood what was wanted. - I read the requirements thoroughly. I asked questions and madde sure I understood the answers. I read other people's questions and answers.
  • I understood the domain. - I go to quite a few conferences and am keen on understanding their organisation and how they are put together. (This partly ties in with my experiences of organising DevEvening.) Knowing the application domain is essential to good software development!
  • I've seen lots of different ways twitter has been used at conferences and other comparable events. - This guided how I incorporated the twitter element.
  • I have a desire to only do things well, or not at all. - Loads of people can do average. Fewer people will put in more effort to make something really refined and polished. - Good enough isn't good enough!
  • I focused on my strengths, not my design skills. - By basing the design on an existing layout, colour scheme and images.



What did I learn from the process?
  • Make the first user experience great. Optimise for it. (User input handling wasn't brilliant in the first version.)
  • Visually stunning (slick?!) and different is good for creating a good first impression. Animation is a good way of adding something new, different and visually appealing to traditional desktop apps.
  • Make user input handling really solid, smart and tolerant.
  • People love seeing their own contribution/thoughts (tweets) on screen.
  • TweetSharp is cool (despite a few temporary problems) and fluent interfaces are really nice to use. 
  • There are a lot of ways user input can get into an application. Consider all of them and 3rd party libraries and APIs as external input and treat them with caution.

What would I do differently in the future?
  • Better caching of tweets retrieved from the twitter API. So can download many at once and then stagger their display.
  • Better error logging. - Currently swallowing quite a few exceptions with no logging. - It didn't really matter for this case but could help with debugging.
  • Better messages to display if no new tweets to show.
  • Add unique images for fake tweets.
  • Add processing rules for tweet inclusion. Possibilities to consider would include: ignoring retweets; profanity filtering; spam detection and ignoring.
  • Ability to play music?
  • Better validation of all input.

Right. Must be time to go back to some of my other projects.


*This year! - who knows about the future.

Saturday, October 31, 2009

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


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.



Thursday, October 29, 2009

StackOverflow DevDays - sad rant :(

Yesterday I was fortunate to be able to attend StackOverflow DevDays London.  I'm planning to do a detailed write up about the event shortly.  But just wanted to have a quick moan about a couple of bad points about the day.

Firstly, my phone did this very early in the day:

Phone = paper-weight!

Fortunatley I also had my blackberry with me so was able to take this picture but it only had a little bit of battery left to only allow me a couple of tweets during the rest of the day.  This meant I couldn't be my usual twittering self at a conference thereby missing out on what I find to be a useful part of such events.  This was further compounded as it meant I couldn't engage with helloapp.  I had heard about this when FOWA was on and was keen to see it in action.  On top of not being able to interact via twitter, I didn't take a laptop so couldn't use the web based site.  There was no dedicated mobile interface and the AJAX requirements of the site meant it was unusabel on mobile devices.  I noticed a lot of other people trying and failing to get it working on various mobeil devices. If Carsonififed are interested in adapting helloapp for greater mobile interaction and thereby allowing more people to use it and engage with other attendees I'd love to have that conversation.

Second issue of the day;
At the start of the lunch break I had a chance to talk to Joel about the CountDown app I wrote and he used at the start of the day and during breaks.
  • Yes this is the code he used in his Fogbugz/Kiln demo. I had a strong sense of Déjà Vu during this as I used FogBugz to track features and fixes during it's development and also hosted the source in Kiln, as an early beta user.
  • Yes this is the app I've written (banged on?) about before.
Anyway, because I was talking, I joined the lunch queue late. Before I got to the front of the queue we were told that food had run out but more would be available in 4 minutes. About 10 minutes later we were told some food would be available shortly. A few minutes later the lunch break was over and it was back to business - but still no food available.

Yes, I could have raced to get food when the lunch break started but that wouldn't have helped the 50 or so other people (my estimate) who were still queuing and also didn't get food during the break

I gave up waiting when Jeff came on to give his talk. I then skipped the Qt talk to get a sandwich.
All very disappointing.


Proper review and details of all the good bits will follow. Promise!


Note to self for future conference attendance:
1-Take loads of phones (not a problem - but must make sure they're charged!)
2- Get a netbook so can get online while there. This will allow doing things which don't have mobile support - (Boo!). Plus, anything larger than a 10" screen seems to big to carry around all day.

Thursday, October 08, 2009

Tuesday, September 29, 2009

My StackOverflow DevDays countdown app - Version 3

We'll now I'm at version 3.0 of my countdown app for DevDays it should be ready for use ;)

For reference:Version 1 - Version 2

This version was created to address the follwoing issues:
  • Optimized for screen resolution of 1024x768
  • Fixed issue with calculating displayed tweet display height
  • Removed hardcoding of sponsor images - they're now loaded from a 'Sponsors' folder on startup. This is to enable easily adding new ones.
  • Removed hardcoding of tweets displayed when nothing new tweeted or no internet connection available. - These are now loaded from an XML file. This allows customisation of the displayed messages.
  • Defaulted start time to countdown to 9am if started before then. If started after then the timer defaults to 5 minutes. (This only applies if no cmdline parameters passed.)
  • Fixed the order that tweets are loaded so oldest are shown first.
  • Fixed positioning of twitter profile images.
  • Also a few other minor fixes.

Source - Compiled binaries - Installer

Now it's even better, please vote for it. ;)

Wednesday, September 23, 2009

I should hope you think it's slick - I was aiming for F***ing Amazing!

WARNING - this is likley to be controversial. But I aim to promote discussion as much as anything else.


I responded to a request for an application to do a simple task.  One of the comments on my app was "Very slick".  This is of course flattering, but it says a sad thing about software development in general : mediocrity is standard. Fortunately this, hopefully, won't remain the case:





Why would I (or anyone) submit an application which was adequate? What would be the point of half hearted effort?
  • Seriously, I don't know.




Yes, with version 2 of my DevDays app, I've gone beyond the original requirements. But why would I (or anyone) do this?
  • Because just doing enough isn't going to stand out!
  • Because just doing what anyone could do isn't going to stand out!

But isn't that doing unnecessary extra work? Who's going to pay for it?
  • The trick is to provide a lot of value for a little extra effort. It's paid for when that work gets you great recommendations and future business.


In my app I've added 'Twitterfall' type functionality. This was relatively simple to add through the use of the TweetSharp library.  The value it adds to the application is great. It turns a passive application into an interactive one. Plus it's a boost to me: I got to try out a new library; I got to interact with Joel and received a boost in confidence that what I had created was good; plus I got some subject matter for a blog post.


Before I go on:
  • Yes, I know there are times when there really is no need to do more than the absolute minimum.
  • Yes, often there are other external pressures.
  • Yes, often a client may have a limited budget.
  • Yes, a client may want a very specific thing and not be interested in it being the best it can be.
  • Yes, there are probably lots of other resons not to do this - but I'm being idealistic and this is my blog so I'm allowed.




Anyway, what was the point of all this? Oh yeah.







I want to make applications that are truly great and people enjoy and want to use.


I want to immitate someone who was actually a master craftsman who worked with wood. (He was more than just a famous carpenter.)


I want to put effort into what I'm doing and do the best possible job.


I don't want to make software people complain about at work when they compare it to the software they use at home.


I don't want to make a second version of a piece of software for someone because there was a clause written into the original contract that means they have to come back to us for future versions. I'd much rather write the first version of a piece of software and hand over the source code to the client (so they can get anyone they want to make the second version) but still have them come back to me to make the second version because they were impressed with what they received the first time.


I don't want to make commodity software. I don't want to be a commodity developer!


I don't want to make average software. I want to make great software!




This isn't just idle claims. I've actually been putting this into practice with a recent project.  It was a common scenario: Large project and only a fraction of the time needed to complete it to a decent standard.
I saw two options: 1. Work at a reasonable rate and if everything went well end up with something that may be barely acceptable. or 2. Go above and beyond and create something I could be proud of.


Due to a unique set of circumstances (mostly my wife having arranged to visit her parents for two weeks with our son - so I was home alone) I was able to select option 2. Also, fortunately, the requirements of the project were an almost perfect fit with my skills (Windows Mobile, WinForms (desktop), ASP.NET & WebServices) so I stood a reasonable chance of being successful.
I decided that if I was going to undertake the project it was going to be as good as I could make it. This was as much to prove to myself that I could make some thing great in the time available as it was to deliver a great solution.


Yes - I made it very clear that the extra effort was a one off and not indicative of what could be expected in the future. That this was an exceptional level of effort was repeated back to me subsequently by the appropriate parties so I think I got this across.


I should also point out that the project (which I'm not allowed to talk about) was something very cool and something I wanted to see succeed.  The deadline was for a pilot/demo which would be visited by many potential customers. The purpose of the demo was to prove that the technology worked and win, potentially, very large contracts.


So for the 2 months up to the demo I lived the project. It seemed like every waking moment was spent thinking about it, and even now find myself thinking about the next stage - which isn't what I'm working on. And I did loads of overtime (over 100 hours - all unpaid). This included an all nighter after the event when the client moved the deadline for the post event data analysis. I worked through the night (well I had one hours sleep before going in to do anohter full days work) because I didn't see the point in goign to all the effort before hand to make the demo work only to not be able to prove what we'd done.  If you can't (accurately) report on what the system did, did the system really do anything? Was it all just smoke and mirrors?


When it came to the demo:
  • the customer was very impressed as what I delivered was better than they had hoped for.
  • there were a couple of minor bugs, but because I was there I managed to find workarounds - so no big deal, considering.
  • the users of the software were initially wary but after a short time prefered working with the application and didn't want it taken away after the demo.  They were also more productive with it.
  • the potential customer we wanted to impress, were very impressed.


So was it worth it?
  • I was happy with what I achieved.
  • The client was impressed.
  • The potenital customers were impressed (and some have already signed some big deals).
  • I think, my boss was impressed.


But was it worth it?
I think so. I wanted the project to succeed and was only interested in being involved if it could be really good. (In retrospect I think I only managed to reach the level of 'barely acceptable' by my standards - but these are very high.)  Yes I had to work very hard, but it was better (in my mind) than having just created something average - again.


What if I hadn't gone 'beyond the call of duty'?
- Because of the tight schedules I was keen to see how much I actually got done in a realtively short period of time. I was also keen to know exactly how much time I spent on the project. So I recorded (admitedly only in a basic way) how I spent my time.
In my estimation, if I hadn't put the extra time and effort in, the amount I would have got done would have meant that: there would have been some fairly essential functionality not there; the look and feel of the applications would have been much poorer; there would have been more bugs; the last minute changes that were necessary to actually do the demo couldn't have been made. All of which means (by my reckoning) that if I hadn't put the extra effort in the demo wouldn't have gone ahead.  This would mean that the sales people wouldn't have had anything to show. They would have had a much harder job convincing the potential customers to but their business in the hands of a system they couldn't even see demonstrated.


Yes, I'm sure that if it was necessary some kind of limited demonstration could have been put together - instead of the full working system I created.
No, this isn't a dig at the sales people - it's just an observation that it's much easier to sell something if you can show it working, and working well.




So what did I learn from this:
  • Making something great was worth it to the business.
  • I am actually very clever and can make the applications I always knew I could.
  • I REALLY don't want to work to that level again. (At least not without some serious reward* and only if the impact on family life can be minimized)
  • Some other things it doesn't make sense to talk about here.


* Part of the reward in this case is me being able to say "I made that". - At least I will be able to say that when I'm allowed to talk about the project. ;)

Other thoughts:
  • This is only possible if developing for someone who wants to make a great system
  • I suspect it would be MUCH harder to create a truly great system without a very itterative process.
  • Part of the reason that the client was so happy with what was delivered was "exactly what they wanted" not what they actually/initially asked for. I can see 3 reasons this was possible:
  1. I had good knowledge of the application domain. (Another reason I was excellently suited to the project.)
  2. I spent a lot of time talking direclty with the client to confirm exactly what they wanted and discussing possibilities.  I suspect that if these communications had gone through other parties at least some of information would have become confused or lost. (Time constraints meant that there wasn't time to formally spec everything prior to development. - For the demo version only. This isn't a good way to build large, long lasting, reliable software.)
  3. The original 'spec' had reporting as a 'wish list' item. My experience taught me that it was actually essential and internally I promoted this to an 'essential' deliverable.  - I was working on the basis that if you're going to be showing & trying to sell something to people who are only interested in the data that comes out the backend it helps to be able to show that data.  Not only did I show the data but also put it in nice graphs (which everyone deemed was more than they could hope for - I consider that a Saturday well spent).  As I sat in on some of the sales demos, I saw jaws drop in amazement and wonder as we were easily able to show and explain trends in data that no-one had previously been able to even capture.  - I suspect that making sales is much easier when you've been able provoke that response.



Side thought: Is making boring, unremarkable software one of the reasons that many developers don't stay in the industry for a long time?


Yes, I have been influenced by Hugh Macleod and his book.

My StackOverflow DevDays countdown app - Version 2

Based on the announcement that my devdays app will be used in an environment where there is internet access available, I've updated to include the TwitterFall-esque feature that I originally removed.

It now looks like this:



The difference is the twitter messages displayed at the side.  These are looked up based on a search term specified in the config file.  If there are no new messages to display or it's not possible to reach the internet (network down, etc.) then one of an assortment of programmer related quotes is displayed instead.

The processing of commandline parameters is also improved.

Now it's even better, please vote for it. ;)


Source - Compiled binaries - Installer

Monday, September 14, 2009

My StackOverflow DevDays countdown app


In response to Joel's request for an application to use as a countdown timer for StackOverflow DevDays, I have created this little app.

Here's a screenshot:



Obviously the design is highly inspired by the website. But I never claimed to be a great designer.

I had a couple of other thoughts about a screen design but liked the simplicity of this one and the ability to maintain the branding.

Obviously, I like the idea of this app being used at the conference but I also saw it as an opportunity to try and do some animation with WPF. (I've only written minimal XAML previously.) While I'm sure that this could be written in much less XAML I'm quite happy with it.

What the above image doesn't show is that the black and white city images scroll in the background and the sponsor images slowly fade in and out - showing one at a time. Also when it starts the different screen elements slide and/or fade into position. Then, when the timer runs out they slide back out as the screen fades to black.

Originally I was going to have a twitterfall type element showing latest tweets at the side of the screen where speakers are shown on the site. Unfortunately as there is no guarantee of internet access when used I left this out.

Here's a video of it in action:



Hopefully you like. If you do and are a StackOverflow user why not vote for it. ;)


Source - Compiled binaries - Installer