Thursday, January 28, 2010

iPhone developers, welcome to some new headaches courtesy of the iPad

A, hopefully, slighlty different take on the bandwagon jumping and hype that is the iPad:

For a long time I (and many others) have been saying that developing for the iPhone is not the same as developing for what's commonly referred to as "mobile".

By creating something (app or website) that specifically targets the iPhone developers do not have to deal with many of the problems and challenges experienced when creating applications or websites which run on a wide variety of mobile devices.

Arguably the number of iPhones in use has meant that by targeting the iPhone you can still have the same number of potential users as if you targetted a number of different devices but without some of those headaches.

Of course, I'm not saying that developing an app that works on the various generations of iPhone and iPod Touch is without challenges due to variations in functionality available from the SDK or the actual device. e.g. not including 'phone' or camera related functionality on the iPod Touch.  It's just that as of today those challenges just got a lot bigger.

I'm not going to go into great detail here as I'm working on a larger, more complete discussion of the issues you may face. However, here are a few questions to get you thinking:

  • Do you dectect visitors to your web site using an iPhone and show them something different?
    Do you show them an optimised version? How will that optimised version cope with being displayed at 1024x768 (or 768x1024)? Are you sure that your detction can tell the iPhone and iPad apart? does it matter?
  • Do you not show some information on screen because of the limited available real estate? Could you redesign your pages/views to make better use of the increased space available on the iPad?
  • Can you display information in a better/clearer way with more space available?
  • With more space do you want to change what is displayed based on orientation? Possibly similar to the way the iPad email client does.
  • More space on screen means you can show larger, more detailed images. But how are you going to show an image of appropriate detail for different size screens? Can you afford just to let the browser resize larger images for you?  Is that what's best for the user?  What if the difference is in the resolution of dowloaded video? Does the increased time (and cost) of always downloading the larger file matter?
  • Can you do somethign new with the iPad which you weren't able to do on the iPhone? Maybe something that you considered for the iPhone but wasn't practical based on a restriction or limitation that doesn't apply to the iPad.
  • Does the size of the iPad mean it's likely to be used in differeent places/ways that the iPhone typically is? It's propbably to early to say for sure, but does this change in context mean that you wish to design your application or web site to be better suited to this different context?  This may mean making different features or options available.
And many more questions....

Can you afford to do nothing?
Despite what you may think of my opinion, what does the fact that Apple have redesigned all their apps for the iPad say?

If you are an iPhone developer the very next thing you should do is read Apple's "Introducing Universal Applications for iPhone OS" and start preparing for the new wave of challenges ahead.

I'm not in a position to pass judgement or share an opinion on the iPad at the moment as I haven't used one.  It sure looks interesting and I'd be keen to try one out though.

Wednesday, January 20, 2010

Code Offsets for bugs

I've written about code offsets previously and I think it's a noble idea.  In reality I don't find the idea of paying on a per Lines Of Code written basis practical.  Instead I'm keeping track of reported bugs I've introduced and offsetting each bug for a credit.
I see it as giving something back without going bankrupt.

Thursday, January 14, 2010

I don't know da time

Bad puns FTW!

When Jon Skeet announced his intention to port JodaTime to .NET I said I would be interested in helping in the process.

NodaTime was born and I have carefully following the discussions in the groups and seeing contributed code as it's checked in.

Unfortunately a number of other commitments and the realisation that I actually have only about 8 hours a week free time (for all my interests - not just writing my own code) have so far prevented me from making any kind of contribution to the project.

Despite my lack of involvement I've learnt some interesting and hopefully valuable things from looking at the code already contributed to the project and from reading the discussions around it's development.

Based on this experience I'd recommend that any developer follows the discussion and looks at the code from new open source projects.  It's a great way to see how other people work and solve problems. Of course if you have the time and opportunity to contribute also then all the better.

Tuesday, January 12, 2010

In my last project at work I used:

Technologies used in last project, in no particular order:
  • ASP.NET MVC (2.0)
  • SubSonic (3.0)
  • MvcContrib
  • Castle Windsor (for IoC)
  • PostSharp (1.5)
  • jQuery
  • NUnit (for unit testing)
  • T4MVC
  • T4 (for lots of things including managing multiple configurations)
  • m.spec (for integration testing)
  • (for acceptance testing)
  • dotLess
  • RhinoMocks
  • Yahoo YUI Compressor (for javascript compression)
  • Hudson (CI Server)
  • VMWare (for hosting CI & Test machines) SysAdmins choice

Technologies considered/evaluated but not used:
  • Spark View Engine (for ASP.NET MVC) - Some initial configuration options and hard for web designers to work with.
  • MongoDB (as an alternative database) - not used as deemed unsuitable for highly transactional nature of data used by system.
  • Visual Studio 2010 & .NET 4 - Reluctant to commit to using unstable betas. Didn't want to have to make a change part way through a relatively short and pressured development cycle.
This was all to produce:
  • Websites
  • Web Services
  • WinForms Apps
  • CF WinForms Apps
  • WPF Apps

Friday, January 08, 2010

Send details of SVN commit on windows using DOS/Batch script

At work we have a shared SubVersion source code repository.  At the moment we don't have a CI setup for every project and I got fed up of not always knowing that someone had also checked something in. (CI sends build/test notifications - success and failure- so I know if something has changed that way.)
So I could make sure I was always notified of when someone else had changed something in a project I'm working on I set up a post-commit hook to send me an email.

The following is a post-commit hook script that I have written to enable me to keep track of what others are checking in.  I publish it here as I couldn't find a good example of this for Windows machines.

Please note that paths and email addresses have been changed to protect the guilty. You'll want/need to change these if you use a copy of this script yourself.

rem This hook sends an email when something is checked in to this repository

set REPOS="%1"
set REV=%2

"C:\Program Files\VisualSVN Server\bin\svnlook.exe" author %REPOS% -r %REV% > D:\SUBVERSION\MISC\author%REV%.tmp


echo. >> D:\SUBVERSION\MISC\%REV%.tmp

echo Who: %AUTHOR% >> D:\SUBVERSION\MISC\%REV%.tmp

echo. >> D:\SUBVERSION\MISC\%REV%.tmp

echo Comment:  >> D:\SUBVERSION\MISC\%REV%.tmp
"C:\Program Files\VisualSVN Server\bin\svnlook.exe" log %REPOS% -r %REV% >> D:\SUBVERSION\MISC\%REV%.tmp

echo. >> D:\SUBVERSION\MISC\%REV%.tmp

echo Changes:  >> D:\SUBVERSION\MISC\%REV%.tmp
"C:\Program Files\VisualSVN Server\bin\svnlook.exe" changed %REPOS% -r %REV% >> D:\SUBVERSION\MISC\%REV%.tmp

D:\SUBVERSION\MISC\sendemail.exe -f -t -u "Check-in for REPOSITORY-NAME" -o message-file=D:\SUBVERSION\MISC\%REV%.tmp

del D:\SUBVERSION\MISC\author%REV%.tmp

I also use rule in outlook to ignore notifications of check-ins made by me.

This uses SendEmail by Brandon Zehm (available at: as a command line tool to send emails from the script.

Tuesday, January 05, 2010

Times are hard

Working with time is hard. Especially when working with multiple threads - which seem to have their own timers.
I just posted a reply to someone in Outlook 2007. Then, briefly my list of Sent Items looked like this:

It seems that even though I sent an email at what it knew was 00:00 which can (should) only ever be today something hadn't updated the date for the comparison of now and the date the messages was sent.

This is one of those issues which just looks foolish when you see it but very few people will ever see it.  It's also something that'd likely be very hard to test and unless you knew this sort of issue could occur you'd be very unlikley to look or test for it.

I guess this is merely just an observation. It's not like this would be easy particularly or worthwhile to fix.  I merely note this here so you might think about and avoid similar issues in any code you write.

Monday, January 04, 2010

A little blog post analysis


If you look over at the right hand side of this blog- and probably down a bit - you'll see links to the archive of my posts.  It shows I've made a lot fewer posts last year when compared with the two previous years.  In an attempt to try and encourage myself to post a bit more and with more frequency, I've committed to taking part in Project52. 

In simple terms, the project is simply to commit to publish a new blog post each week in 2010.

Find out more at: