iPod Touch

Posted on by
2

Last weekend I bought an iPod Touch from the proceeds of the freelance work I have been doing recently, and thought it might be useful to share my experiences so far. I bought it from a high street shop, so didn’t get anything like the usual Apple Store service – I paid the money, somebody fetched the iPod from the back of the store, and warned me that as soon as I opened it, I couldn’t bring it back…

(this didn’t set out to be a review of the relative merits of the Apple Store experience versus the high street, but it is worth knowing about if you’ve never been in an Apple Store – Andy Ihnatko described it better than I ever could).

So – the iPod Touch. It’s thinner than the iPhone 4, and fresh out of the packaging has a mirror finish metal back. The mirror finish will never look as good again, so enjoy it. There is no electrical plug with the iPod Touch – but the wire is the standard Apple USB / iPod connector, so if you already have a USB plug around (from the likes of an iPhone, Macbook, or Kindle), any of those will work fine. The build quality is as good as we have come to expect from Apple (read: the best in the business).

The current version of the iPod Touch was delivered with iOS 5.0, which I upgraded to 5.1 before registering the device. This caused iTunes to error late in the process – disconnecting and re-connecting the iPod to the computer (running Windows 7 and the latest version of iTunes) fixed it.

It’s worth saying at this point that I’ve owned iPhones in the past, and we have an iPad 2 at home, so I’m completely at home with iOS. Given that my current mobile runs Android, I am perhaps better suited than most to judge on the merits or deficiencies of iOS versus Android. I like both, but if given the choice, I would choose iOS. Functionally they are very similar, but at least iOS devices get updates directly from Apple. Unless you root your handset,  Android mobiles have to wait for both the hardware manufacturer, and the carrier to prepare updates – which may take a year, or may never happen at all).

There’s really no point reviewing the applications on the iPod Touch, because they are identical to those on the iPhone, or iPod. I will make a few points about the hardware though;

  • The iPod touch is underclocked (on purpose), and has half the RAM of the iPhone 4, or iPad. The lack of memory becomes apparent when switching between, or launching applications – leading to lengthy pauses that are sometimes jarring.
  • When an iPod Touch is switched into standby, it really is asleep. It will not listen to the network, so no push notifications will arrive… or at least that’s the theory. I’ve had the iPod notify me while asleep from time to time of events occurring – I’m guessing there is a grace period before it properly hibernates all the processes.
  • Calendar events and reminders DO wake the iPod from sleep – so it’s a great alarm clock.
  • Because it does fall asleep when not in use, battery life is stellar compared to smart phones.

So – the only real detraction with the iPod Touch is that it hibernates nearly everything while on standby – which is also the main reason it has such good battery life. I can live with the slow launching and switching of apps. I’ve only had it for a few days, but am already carrying it everywhere with me, if only because there are a number of iOS apps that I love (the “Things” task list app, for instance).

p.s. Facetime works wonderfully, even on the iPod Touch. This evening I am hundreds of miles from home, sat in a hotel. I talked to my children just before writing this via Facetime – them on the iPad at home, me with the iPod Touch propped on the desk in my room, using the hotel wireless network. It worked flawlessly.

If you have a specific question, leave a comment!

Podcasts

Posted on by
Reply

In the spirit of sharing the source of much the the stuff I learn online (apart from the mighty Google Reader, and now Google+), here is a selection of the podcasts I try to listen to when I can.

I used to also listen to MacBreak Weekly (when I still had a MacBook, and an iPhone), mainly to listen to Andy Ihnatko, who remains perhaps my favourite panel member on any podcast, and a great journalist too.

If you’re wondering, I use GPodder on the desktop to fetch podcasts, and have Google Listen on my phone, which hooks up to a label in Google Reader called “Listen Subscriptions” – and downloads them to there too.

Buzz Out Loud

http://www.cnet.com/buzz-out-loud-podcast/
Features Molly Wood, Brian Tong and producer Stephen Beacham, along with CNET’s top tech experts reviewing the day’s tech news.

Friday Night Comedy from BBC Radio 4

http://www.bbc.co.uk/radio4/programmes/genres/comedy/satire/
Steve Punt and Hugh Dennis present the topical comedy gang-show.

Linux Outlaws

http://linuxoutlaws.com/podcast
Fabian Scherschel and Dan Lynch talk about the latest developments in free and open software and culture.

The Social Hour

http://twit.tv/tsh
Sarah Lane and Amber MacArthur have teamed up to create “The Social Hour,” your source for the best social tools, news, and fascinating folks building the next generation of the Internet.

Tech News Today

http://twit.tv/tnt
Tom Merritt brings you “Tech News Today” with co-hosts Sarah Lane (TechTV, Revision3), Iyaz Akhtar (PC Mag, TechVi) and others. Get up to speed, with a fun and friendly ride through the need-to-know tech news of the day.

This Week in Google

http://twit.tv/twig
Leo Laporte, Gina Trapani, Jeff Jarvis and their guests talk about the latest Google and cloud computing news.

This Week in Tech

http://twit.tv/twit
Join the top tech pundits in a roundtable discussion of the latest trends in high tech.

TuxRadar

http://www.tuxradar.com/podcast
News, reviews, rants, raves, chit-chat, geekspeak and more.

Google+, Twitter, Tumblr, Facebook, Blogger, WordPress, Posterous – where does it all end?

Posted on by
Reply

Is this a case of “too many Goliaths in the kitchen” ? – I’ve been thinking about the various social networks today; taking stock, and wondering what each might be useful for.

Google+

The answer to most of the problems of all the other platforms. It promises privacy nervana by asking everybody to label everybody else as “friend”, “foe”, “prat”, or whatever labels you might come up with. It all works wonderfully, as long as you don’t mind Google absorbing your DNA into the grid, and creating a real world basis for the plot of TRON Legacy.

Twitter

Quite possibly the most vacuous creation on the internet. Think of it as the perfect place to drip your meaningless content into a vast, fast flowing river. You are one voice among millions, and even if thousands follow you, nobody is listening.

Tumblr

While feeling good about yourself, Tumblr is the perfect place to invest time in order to realise that no, you don’t really matter that much. No matter how creative you think you might be, a photo of a kitten, or some girl’s ass is always going to attract far more attention than your thoughts about world hunger, or your insightful commentary about the day. Of course, taking part in Tumblr relies on the system being “up”, which tends to be rather rare.

Facebook

Best suited to family, friends, and psychotic people you once knew or went to school with who you will then “un-friend”, and receive hate mail from. Sharing anything invites long forgotten school friends to stalk the hell out of you, pass comment on everything you say or do, seek attention during the dead of night with sopporific sob stories.

Blogger and WordPress

Perfect for long rambling tomes of navel gazage. If you’ve always wanted to write a novel about yourself in 20,000 parts, this is the place to do it. You can enable all manner of social sharing gadgetary, but it will not be used because in reality you’re the only person remotely interesting in your own life.

Posterous

If you’ve ever wanted to build an online photocopier that could spam your crap across every imaginable other service out there, Posterous solves this non existent problem for you. It also purports to be super-easy to post via email – as long as you don’t mind it mangling the styling of everything you write in as unpredictable a manner as possible.

Postscript – Twitter bought Posterous a few days ago – meaning Posterous will now be left to rot, which is a shame. It was a pretty clever platform…

Thoughts about the Raspberry Pi

Posted on by
1

While reading various forum posts about Raspberry Pi supply chain issues, it got me thinking about the wider picture this evening. I guess for the benefit of the wider crowd, I need to fill in a bit of back story first.

The “Raspberry Pi” is a $35 computer that has been developed over the last few years to be sold into education, and the developing world. It uses off the shelf components to construct an extremely cheap, versatile platform through which it is hoped a new generation of software developers and hardware engineers will be fostered – in much the same way as the explosion that happened in the mid 1980s when 8 bit computers became affordable.

The idea seems to have worked and then some. For the first couple of days after launch, 700 people a second registered an interest with the production partners of the project. Over the first week, over 2 million people. It caught everybody off guard – including the respected partners who will be manufacturing the hardware. Websites went down worldwide.

Anyway.

The whole “Raspberry Pi” thing got me thinking about how we view computers today – how much we take for granted. We buy a mobile phone or a laptop, switch it on, and expect it to “just work”. We are not supposed to take an interest in what it’s doing behind it’s pretty icons and slick animations.

While this level of abstraction is wonderful from a corporate point of view (support is cheaper, brand lock in is easier, more manufacturing corners can be cut), in the longer term it’s a disaster. After a couple of generations, children come through college having no interest in the inner workings of their utility devices. All development becomes “higher level”. The lack of kids coming through means development atrophies, and price gouging starts to take place.

It’s already happening with mobile phones. Apple did well enough, quickly enough, and grew a big enough patent portfolio to essentially perform a “head shot” on the rest of the mobile phone market. Well done Apple. You can’t argue that they haven’t played their cards perfectly over the last decade – but where does it leave us?

It leaves us with a world where a few dominant players build computing platforms for everybody, can stop anybody else from building further platforms, and can control the price of their raw materials to such an extent that thousands of people work in deplorable conditions with little or no public appetite to cause change.

It’s happening right now.

That’s why Raspberry Pi is important. It doesn’t tip a balance, but it starts oiling the hinge that will be tipped by the next generation. It reminds us that we don’t have to purchase proprietary hardware at hugely inflated prices, built under awful conditions in third world sweat shops.

The Raspberry Pi indirectly reminds us that alternative computing platforms exist in the shape of the many and varied distributions of Gnu Linux, and that the damn fool crusade of Richard Stallman all those years ago – when the software he had collaboratively worked on became the intellectual property of a commercial rights holder – is about to pay off.

Raspberry Pi reminds us that when we work together, share, and only profit from our skill in providing a service, the world is suddenly a much better place.

Kerberos, the Many Headed Dog from Hell

Posted on by
Reply

If you’ve never heard of Kerberos, it’s named quite well actually. Wikipedia tells us the following;

Cerberus (Greek: , Krberos) is the name given to the entity which, in Greek and Roman mythology, is a multi-headed dog which guards the gates of Hades, to prevent those who have crossed the river Styx from ever escaping.

In computing terms, it describes a security handshaking protocol devised by MIT in the late 1980s and early 1990s to help computers persist trust relationships between each other.

Installing each server didn’t give any hints that anything was wrong – mainly because I had expertly (read: by total luck) avoided switching on the one thing that would have flagged the problems up in huge letters.

Here’s the classic Kerberos problem…

When you – as a client – ask for a webpage from a Windows intranet web server, the web server impersonates you in dealing with that request – “if I am Jonathan, what can I see…”. This first “hop”, and it’s associated delegation of authority to the webserver is preconfigured for us – without it, webservers would have a nightmare doing integrated authentication.

The problem comes when the webserver needs to ask another system to supply data, and for that system to also act as you – so in effect you have a machine telling another machine to pretend to be somebody… i.e. it’s not you telling the machine to pretend to be you. This is NOT ALLOWED.

The limits placed on the automatic delegation of authority are designed into all network operating systems on purpose – without them, all manner of fraud, misinterpretation and havoc could ensue. I’m not going to go into any great depth describing what kerberos actually does (there are whole books written about it) – - but I will explain in as simple a terms as possible.

Kerberos is an agreed protocol for servers to exchange secrets with each other, such that they can then trust each other – and if they trust each other, then allowing the delegation of authority between each other.

The penalty of Kerberos is that the handshaking process is slow; therefore the system keeps “tickets” describing the agreed trust relationships that are being upheld for however long.

I’ll close this post with a helpful hint learned last year while working on a multi-server system… If the users report some mornings that errors pop up announcing anything to do with “Anonymous user”, ask them if they logged their machine out the night before. Nine times out of ten, they didn’t and their kerberos tickets expired.

One day soon (when I’m not so tired), I’ll write a post about the actual mechanics of Kerberos – it’s fascinating, clever, and worth knowing.

The Business Process Management Conundrum

Posted on by
Reply

Over the last couple of years I have been working with a number of the industry leading business process management platforms. During that time, I have formed some pretty clear opinions on the decisions we will face when working with them. I thought it might be useful to share.

Things to Fear

Given the inquisitive nature of developers, and the lack of experience held by clients, it’s hard to quantify why something should be feared – often we don’t find out that something is a bad idea until we have experience – it’s the classic “chicken and egg”. These are the concepts I see as the most important;

  • Long processes
    If you have a really long process drawn out on a piece of paper, don’t imagine for a second that it will be implemented as you imagine it. You’re going to chop it up – even if you don’t think you need to. Deciding where to make the cuts typically comes down to two questions – “where does it loop”, and “where might it sit dormant for a long time”. Try to think of a process as something happening – not the entire model of the way your organisation works.
  • Beware enterprise-wide roles
    While developing a process, you will decide that various subsets of users need to have tasks delivered to them. The thing to remember is that each person in an organisation may have different roles for different aspects of their job – or between projects they work on. Therefore, think very carefully before implementing any kind of role discovery across the enterprise. What we’re really thinking about here is Active Directory, versus SharePoint Groups. Every sensible bone in my body tells me that workflow processes should be supported by SharePoint groups – which can be assigned on a site-by-site basis without impacting Active Directory business units.
  • Carrying data in the process
    I have touched on this before. Do not carry business data within the process if you can avoid doing so. Ideally, the process should manage routing, destination and delivery only. Storing business data inside the process causes a world of problems around data integrity and synchronicity. The basic rules should always be to look up only that which you need to know, and act on it immediately.
  • Implementing complex business rules in the process
    There’s a simple answer here. Don’t do it. Keep your process simple – and never, ever base the routing logic within the workflow directly on business data – always abstract it. Abstracting both the computation of business rule data, and the interpretation of results protects your process design from future changes.

The Integration Dilemma

Knowing that you can build rich processes that integrate with enterprise content management systems doesn’t answer how you should approach doing so – and it’s a surpringly difficult question to answer.

The following two considerations are important;

  • You need to decide if your content is going to support your process, or if your process is going to support your content. Which will be tailored to fit the other? Given the ease with which infrastructure within platforms such as SharePoint can be provisioned, it makes sense for specific areas to be designed around specific processes. Where process is being applied to pre-existent infrastructure, the process can of course be integrated appropriately. You may have a preferred approach, but I would argue that neither option is more “correct”.
  • Remember that location in an ECM system can carry meaning. Just as a document may be attached to a process at a certain stage (e.g. “Awaiting Approval”), a document can also be stored in an appropriately named place. It naturally follows that any library or folder may carry a meaning related to “state” through both it’s name and it’s location. It’s a simple, subtle concept, but surprisingly deep when realised.

Typically, your approach to solution design needs to be inventive – leveraging existing ECM assets becomes paramount (why re-invent the wheel?). When working on complex processes, you need to ask yourself serious questions about the point you will stop trying to bend the system to your process, rather than your process to fit the available technology – or perhaps buy the right tools for the job in the first place.

In many ways, working with restrictions can be useful – rather than perverting the various elements of the system to become a jack of all traders (and master of none), you are encouraged to offload specialist tasks to applications more suited to them.

The important thing to realise is your views will change as experience is gained, and you design, develop and implement real world processes.

A System for Everything

Posted on by
Reply

One of my oldest online friends commented last night that I have a system for everything. She didn’t mean it in a bad way; she was just making an observation. After thinking about it for a while, I realised she’s probably right.

Some examples;

  • My bookmarks bar in Chrome is filled with folders – for Google (Mail, Calendar, etc), Blogging (Posterous, WordPress, etc), Social Networks (Twitter, Facebook, etc), Social Media (Flickr, YouTube, etc), Tools (Netvibes, Instapaper, etc), Helpers (various bookmarklets), and Diversions (PopURLs, BuzzFeed, etc). They sync across the various computers I use.
  • I keep a “Journal” folder in Dropbox, with a text file for each month of the year. In markdown format, I write what I have been doing each day so when it comes time to fill out my time sheet, no guessing is needed.
  • I keep serial numbers and logins in a secure volume in DropBox, encrypted by TrueCrypt. The password is ridiculously strong.
  • I am pretty close to Inbox Zero in GMail – I star stuff I need to do, and delete everything I have done. I only archive emails I want to keep for posterity (photos from friends, for example). Typically there are only three or four emails in the inbox.

Yes, I am mad. I used to be a “Remember the Milk” fanatic too, but seem to have cured myself of that particular idiocy. I pretty much rely on Google Calendar these days to remind me I need to do things. If something’s not tied to a date, I don’t really need to know about it.

Software Development Methods

Posted on by
Reply

We all know that managers like to talk about models, methodologies, and methods. They like to sound clever, throwing acronyms around, and spouting catch phrases and buzz words as often as possible. No realm of information technology seems to display this mania quite so aptly as software development methodologies. Given the amount of hoodoo, fear, uncertainty and outright rubbish written about the various ideas, I thought it might be timely to write a post outlining what each one really means – both for my own reference, and my own sanity – if this is of any use to you, that’s a bonus.

What is a development methodology?

Broadly speaking, it’s the description of an approach to building software – the reason to have the description in the first place would be to get a team of developers to work in a similar manner to each other, and so that team leaders have a clue what’s going on.

Right. So what are the various well known methodologies?

Waterfall

The waterfall model is a sequential development process, in which development is seen as flowing steadily downwards – like a waterfall – through the phases of Conception, Initiation, Analysis, Design/Validation, Construction, Testing and maintenance. The process is followed with rigour, and loved by pedantic team leaders who like to tick boxes, and make everybody’s life hell. It’s incredibly expensive to do, and customers both love it and hate it – they love it because it can be run on a fixed price, but they hate it because a calculator application ends up costing as much as the space shuttle.

Iterative and Incremental

Iterative and Incremental development is a cyclic software development process developed in response to the weaknesses of the waterfall model. It starts with an initial planning and ends with deployment with the cyclic interaction in between. So, essentially, this is Waterfall where we admit that waterfall is idiotic, and we agree to go round and round in circles, until we’ve spent just as much time, effort and money as Waterfall. I guess brakes can be applied in the form of somebody in the middle of the mayhem who continually asks “is this good enough – will it do?”. Iterative development is often tied to the “Rational, Unified Process” – another meaningless description heard often, but understood by nobody.

Rapid Application Development

Rapid application development is a structured technique where early designs are turned immediately into prototypes, which are then iteratively evaluated, refined, redeveloped, ad nauseum until the finished product is produced. “RAD” was invented to combat the main problem of Waterfall based development methodologies – by the time anything got built, the requirements had changed – and by the time the redeveloped solution re-appeared, the requirements had changed again. Rapid application development became very fashionable in the mid 1990s with the advent of visual design tools such as Visual Basic and Delphi that allowed fast interface development. It also caused some of the worst spaghetti code in the known universe due to nobody paying their “code tax” and inviting developers to go back and clean up after requirements have changed.

Agile Development

If you are a fellow developer, you were expecting this one to be in the list – probably because it’s the fashion of the moment, and all managers in the known universe think Agile sounds cool when talking to clients. I expect they stand in a “ready for action” fake karate pose when they say it. In reality, the “Agile” label covers a swathe of similar methodologies – the Wikipedia description reads as follows;

Agile methodologies generally promote a project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.

Phew! So it sounds like it will save the known universe – and it’s growing popularity has resulted in more being written about it than any other method – meaning basically that Managers can now have big fat books about it on their shelves, and communicate in pure acronym when discussing project plans. In reality, all Agile really means is that you will communicate, you will try to make things work, you will be trusted (!?), and you will not blow a gasket when requirements change. Of course the customer also has to realise that change equals longer.

Extreme Programming

Quite unlike extreme ironing, extreme programming does not involve carting a laptop halfway up Aconcagua to write some C++. It is however similar in taking ideas from several flavours of Agile development, and constructing a set of “ideals”, or “expected behaviours” around them. I can only imagine the anal, ivory towered developers that dreamed up Extreme Programming as a methodology – whereas most of us might well follow a lot of the ideas anyway, there is a strict swathe of rules, behaviours, and guidelines that you can follow if you really want to be an extreme programmer. I’m guessing the people who like working this way also have 20 sided dice in their desk drawer. I’m being cruel, aren’t I. One of the ideas within Extreme Programming that I really like is working together so that one of you programs while the other thinks. Can you imagine – sit there, with your feet up, sipping coffee and spouting lofty ideas at somebody all day?

In summary…

I’m guessing this blog post is going to generate it’s fair share of laughter, snorts of derision, outright anger, incensed murmurs of “he didn’t get it”, and various other rumblings of discontent.

It’s worth remembering that 99% of development teams use elements of all the methodologies that have been written about in the text books. It’s also worth noting that all attempts to build software in a faster, more efficient, more responsive manner are eventually defeated by millions of words being written about them in textbooks, and managers applying so much structure, measurement and review that you may as well call them all Waterfall and have done with it.

Getting Things Done

Posted on by
2

In order to combat the endless torrent of tasks, requirements and commitments surrounding me throughout the past couple of years, I have been experimenting with the “Getting Things Done” methodology. I first heard about it while reading Merlin Mann’s 43 Folders website, and have since bought the book by David Allen, and found myself returning to it again and again.

“Getting Things Done” is based on a loose set of ideas – a toolkit to help bring organisation to your chaos. The tools are not specified – only the manner in which you might use them. Each person will prefer different tools, and each person’s chaos will be different.

My chaos consists of a demanding full time career as a professional software developer, a sometimes equally demanding “second string” freelance career as a web developer, and the remainder as the husband of an infinitely better half, and the father of three young children.

Central to the “Getting Things Done” or GTD methodology are three basic ideas;

  • If it’s on your mind, your mind isn’t clear. Anything you consider unfinished in any way must be captured in a trusted system outside your mind, that you know you’ll come back to regularly and sort through.
  • You must clarify exactly what your commitment is and decide what you have to do, if anything, to make progress toward fulfilling it.
  • Once you’ve decided on all the actions you need to take, you must keep reminders of them organized in a system you review regularly.

So the basic idea is to forget about everything you don’t need to be thinking about – to store it away somewhere – and to regularly pull tasks from that store as they need to be done.

The idea of freeing your mind from anything that doesn’t matter right now has been the most difficult for me to embrace. While listening to one of Leo Laporte’s podcasts recently, a rather novel nuclear tactic of sorts was put forward – if your desk has mountains of unknown “stuff” on it, get a great big box, and sweep everything into it – then mark the box “some day“. You will of course return to the box, but only to fish out things that need to be done as they crop up.

Over the past year I have experimented with a number of tools for my “trusted store”. Remember the Milk, Toodledo, GMail tasks, and a variety of quite brilliant iPhone applications. For several months I used (and loved) 37Signals Backpack - it was simple, flexible, and good enough.

After tinkering, playing, using, breaking, and misusing all manner of task list software, websites and services, I probably have more perspective than most about what I need in a solution, which it turns out is very different than what I would like.

The concept of an In-Box is perhaps the lasting influence Remember the Milk had on me – with the idea that you could throw any tasks immediately into an inbox to get them out of your way. It falls into the same paradigm as Inbox Zero (where you try to keep your email inbox empty as far as possible).

I was going to write about my specific solution, but I’m not so sure it’s really of much importance to you as a reader. The great thing about any productivity methodology is that you are free to modify and adapt it to the tools you have. It doesn’t really matter if you have a desktop computer, a laptop, a paper notebook, an iPhone or a Blackberry – it’s forming a regular habit of managing your store of notes that really matters.