For years we've lived with tablets that cost about the same or more than laptops. Interesting devices - the Microsoft Origami specification, the Microsoft Tablet specification - just too expensive to be practical as a sofa-ware, or potato-couch-ware device.

The brutally short history of tablet computing

For years, in my opinion, there have been two defining tablet computers:

• The Apple Newton (the 2100 models, not the 110 models which I felt were just underpowered). It actually worked with fingers, or any object with a non-destructive point.
• The HP/Compaq TC 1000 tablet with it's original dockable keyboard. I disliked the radio-based pen, but loved the almost seamless nature of it's pen-based interface (Windows XP Tablet Edition). But the pen always felt like an appendix and the hardware underpowered. (It was running a 1Ghz Transmeta)

Unsurprisingly I have both devices (amongst a plethora of touchscreen devices). Well, I actually have 4 Newtons, including the esoteric Newton eMate. And they demonstrate the state of the art for their time - or perhaps bleeding edge concepts.

Wishing for a revised Newton

I used to dream of a re-imaging of the Newton, but I suspect the enmity between John Sculley and Steve Jobs made such a device politically impossible (Jobs famously denigrating the Newton as the "scribbly little thing"). So I turned my attention to the Microsoft concepts. I loved the Origami concept, but the pricing was simply unacceptable.

The Sharp Zaurus SL-5500 came so close. It just needed some modern horse power. One of those in the same sliding thumb keyboard format with an X-Scale or similar processor could have done absolute wonders in that form factor. With an added bonus of being an open and hackable platform.

I had a semi-serious flirtation with the touch screen range of Fujitsu-Siemens Lifebook B series. From the 8.7 inch B-110, to my deep personal attachment to the B-2154, but the inevitable conclusion was that touchscreens and laptop clamshells don't work together in a non-table environment.

Apple made a fresh potential promise with the Macbook Air. Remove the keyboard, and that could have been the most beautiful tablet ever. But again, its the price barrier.

The Amazon Kindle looks decent, but unclear what it's capabilities are apart from displaying Amazon purchased ebooks. As a general (albeit transient) computing device, it seems woefully inadequate. And it's most redeeming feature of an online store basically useless for the UK market.

The iPhone reawakened the promise of the Newton, but O2's domination of cutting edge devices and monopolistic contract prices made the idea of owning a mini-tablet device just preposterous. Plus, for me, the iPhone is too small a device to be usable in a casual tablet form. Comfortably-sized text is essential, and that needs room.

The picture frame trinket

There is a strong market for transient computing devices. One of the Christmas gifts I gave my family in 2008 was a 7 inch electronic picture frame.

I distinctly recall a Bill Gates' forward-looking prediction about uploading pictures to a picture frame, and I thought that it was plain silly. Why would anyone waste computer cycles on a stupid picture frame? Just print out the picture and stick it in a proper wooden frame.

Over Christmas 2009 I realised how short-sighted that viewpoint was. Mom loved the picture frame, still using it a year later to cycle round batches of pictures she had imported over the year. My Flickr pictures, pictures from the extended family, pictures of friends, pictures she took over the course of the year. Each one provoking memories and observations.

What was a stupid waste of computer cycles became a talking point, a starting point of conversations about forgotten people, new stories. A better way to bond. Given that I spent three weeks a year with my parents, those three weeks are so precious - a simple picture frame made a positive difference. It added more value beyond being a minor novelty trinket.

Things make sense

Yesterday Apple made a brand new start to the tablet era. They got the price point spot on at under 500 US dollars. They got the size about right at 1024x768 at 9.7 inches. They got the use cases right - of a casual couch-based device, an information grazing device, a reference device. A device that's comfortable being more offline than online. A device that encourages a better relaxation posture than sitting in an office chair with hands chained to the mouse or keyboard.

It also makes sense to base the platform on the iPhone and scale it upwards, rather than take a full operating system and scale it downwards. The Newton was a from-scratch OS, built with revolutionary ideas. Microsoft's similar attempt with Windows CE died because CE sucked badly, and Windows XP never downscaled so became too bulky to power a casual device.

Re-connecting with history

I'm thankful that Steve Jobs has sufficiently exorcised the demons of the past and looked way beyond the Newton. I love the Newton - as retro-technology it is still, almost 20 years later, such a wonderful piece of hardware. And I believe the iPad to be the justified successor to that remarkable device; not content to be standing in the shadows of the giant Newton, but standing unashamedly in the sunlight as a well thought-out and modern implementation of the tablet concept.

Assuredly, I have issues about Apple's sharecropping model for their Apps store. I'm seriously contemplating overlooking those, or perhaps more logically embrace HTML 5 as the open alternative development platform.

I want an iPad.

Disclaimer: I received a review copy of this book from Packt Publishing in September 2009.

Symfony is a PHP5 framework for rapidly building dynamic web applications. This book is targeted at Symfony 1.3 when it hits production-ready status. At the time of writing the 1.3 version is still in alpha. Unfortunately this book suffers from the uncertainly as final decisions haven't been made. The major one is whether the default ORM will be Propel or Doctrine. The book flip-flops on which one is the default ORM. On the whole the book feels like a rushed job, trying to get to market before Symfony 1.3 hits production ready.

The Symfony project themselves have useful introductions to using Symfony, most particularly their Jobeet tutorial which covers Symfony through the practical development of a Job listing site. This new book by Packt attempts the same approach, building a website for a chain of milkshake restaurants. It is a decent example that covers many of the features of Symfony, and so comparing it to the Jobeet tutorial is a useful exercise.

The intended audience for this book are developers using older versions of Symfony as well as developers new to Symfony. I'm fairly new to Symfony and I've been developing with it for almost a year now.

Overview of the book

The first chapter of Symfony 1.3 Web Application Development covers getting and setting up Symfony. The next chapter sets out the skeleton of our application by defining the database schema, routing, actions and templates. This is followed by a chapter on adding business logic to to model and adding navigation. A chapter on building a simple form to email module takes us through Symfony Forms, and then takes us through converting it into a reusable plugin.

Then we create the administration interface through chapter 5, customising the admin screens as well as locking parts down through authentication. Chapter 6 covers adding Javascript to the admin interface by adding an image uploading widget, a date picker and rich text editing.

Chapter 7 shows off some of Symfony's internationalisation and localisation features. There follows a chapter on adding 3rd party libraries to symfony, and a useful chapter on various caching layers in Symfony. The final chapter talks about deploying your application to a production environment.

Building the skeleton of the application

The chapter on setting up Symfony and creating the skeleton of the application competes directly with the Jobeet tutorial, and unfortunately comes off second best. The approach the book takes to installing Symfony is to grab the current version from the Symfony SVN repository and then create a sandbox using that code. This is different to the preferred Symfony 1.2 method of doing an SVN checkout to the lib/vendor directory of each project.

What I found bizarre was the authors' preference for using the Propel XML schema format for defining the database instead of Symfony's consistent YAML methods. The authors state that they find YAML more difficult to read and with spaces instead of tabs this causes problems with large YAML files such as a database schema. I find this puzzling since all of Symfony's configuration is done with YAML, so it's impossible to avoid - the authors later have to teach the reader how to do YAML anyway, so introducing the XML way is just not efficient.

And introducing the XML vocabulary they don't. There's two pages of database schema in XML format, and they explain just 4 attributes of the entire document. No mention is made of the structure, or the purpose of the elements, let alone the various field types that are allowed. The whole XML way of defining a database schema looks left as an exercise for the reader.

The HTML in the code examples left me horrified. Essentially the page layout template is a set of divs with inline style attributes. Including the 5 item navigation list, each li having the same three lines of inline style properties. I'm astonished that in the 21st century we have such a poor understanding of CSS from people teaching development on the Web. Jobeet beats the pants off this section of the book by embracing the customisability and flexibility of CSS by creating a competition for skinning their application - that's perfect web standards evangelism. This Packt Press book however, shows a lack of modern web development techniques that have been prevalent over at least the last four years.

The attention to detail is lacking. There's no mention of how to configure the web server to serve content from the web directory. Considering that the book heavily uses the custom domain milkshake, leaving out the web server configuration is a disservice to the reader, since they can't really follow along with the book. Again, this seems to be another exercise for the reader with no clear guidance given of what needs doing. A passing mention of aliasing the Symfony assets directory is the closest the book comes to the web server configuration. Jobeet covers this particularly well in day one of their tutorial.

Dealing with business logic

The chapters covering adding in more complicated business logic are better, they feel that they hold together better than the previous chapters. It takes the reader through creating new modules and adding in custom logic, as well as getting hold of request-related information. The routing sections are decently explained. Particularly the explanation of pagination and partials were well written.

The next chapter on creating a newsletter signup script, so taking a form, adding the received data to a database and firing off an email is a good chapter, the plugin section being extremely useful. It introduces the Symfony Forms feature as we build the module from a database schema and generate the form classes before customising them in both the structure of the form and how it is rendered on screen.

As an accessibility practitioner, I'm noticing that there's no mention of explicit HTML labels and grouping by fieldsets, and the error handling on form validation leaves little to be desired. Still, it sounds like that these renderers can be rewritten to produce accessible markup.

Security is covered by the vaguest wave to a CSRF token (Cross Site Request Forgery), and that this hidden input field code snippet helps prevent this. Honestly, that is the coverage of security in its entirety. I understand that this book isn't about teaching security to web developers. The Jobeet tutorial is slightly better in this regard, but not by much.

There's no detail on where or how to use third party libraries involved in email delivery. The code example assumes that the library is already installed at the correct location and ready to be used.

The section of creating a plugin is perhaps the most useful section, taking the reader through the steps of creating a reusable plugin for modules. Perfect for isolating bits of code to use in other projects. The higher level process is easy to understand, but the actual implementation is under a cloud because of the setup concerns of the first chapter. I hope the actual step-by-step process is correct, and that really means this book needs to be properly tech-edited and proof-read by a hands on developer.

Configuring the Administration area

I struggled getting the admin area working through the Jobeet tutorial, so I'm happy to say that the process of customising the administration configuration makes a lot more sense after reading this chapter. Particularly, I found the Jobeet process of locking down access to the adminstration side of the application made even the login page requiring authentication before being accessed (possibly I needed to clear the cache?). This book makes a more determined effort to explain how the authentication system works and how it is configured, so that fills me with more confidence.

The chapter on enhancing forms with Ajax came as a surprise as they added the functionality to the adminstration area instead of a simple form outside. That shows the confidence of the author to pull this off. I hope it works.

Internationalisation

It's another useful chapter, this time on internationalising the application. The chapter takes the reader through extending the database schema to handle translations of each piece of content, and the changes needed to address the model to reflect the selected locale (the authors use the term 'culture' for locale).

For localising the templates and interface text the book steps through using XLIFF (XML Localisation Interchange File Format) which takes a text string as a key and returns a translation that's stores in the XML translation files. There are automated tools to extract existing text from templates to populate the initial files. And then filtering all static text through a special filter function produces the correct translations.

However, after being through an internationalisation hell for the latter half of 2008, I realise the book isn't anywhere near complete in it's internationalisation coverage. There's no mention of handling static text that contains request-variable information, like This is page 6 of 12, nor any mention of Symfony's ordinal and plural grouping of numbers which impressed me in its ability to handle Polish. Nor was there any mention of currency, number or date formatting.

Granted that translating plain text is a major step forward for being able to localise sites, but it's one step in a series of steps. (This is despite the code examples containing mojibake, presumably because the printing process of the book is at fault here)

Extending Symfony, Performance and Deployment

This chapter covers using other PHP5 libraries inside of Symfony. The demonstration of using ez Component's Pie Chart component inside a Symfony application impressed me, and again demonstrates the confidence of the authors. Unfortunately the followup about integrating Zend framework components is two paragraphs and feels completely unfinished.

The performance chapter covers the various cache levels of Symfony. Right from configuring gzip encoding within symfony, to template cache and data caches, and even when to avoid using the ORM when raw performance is necessary. The step by step guide is very useful, as we watch the load times of the page shrink drastically.

The chapter on deployment covers how to disable a Symfony application, enable outage messages, and then recommends using rsync to migrate code from the development environment to production. It's a very quick overview of rsync.

Conclusion

There is a fair amount of useful information in this book. I will be using it's plugins and administration chapters again fairly soon. But this book suffers badly, it really needs a solid technical review and a very sharp editor review. It needs a proper developer test - take a developer who has no knowledge of Symfony and get them to follow along with the book.

One serious issue was the Finishing off the location page section of Chapter 3 is supposed to cover adding in vacancies on the page, which is assumed to be there in Chapter 5's Handling foreign keys using admin generator.

My gripe against the use of XML will be alleviated by either explaining the XML syntax of the database schema, or switch back to YAML. (But it would also help having a typesetting review of the book, the indenting of the code examples - including the YAML code snippets - aren't correct or consistent.)

To be honest, I would wait for the second edition of this book; and only if it's strictly tech-edited, sternly proofread and typeset reviewed, after the first release of Symfony 1.3. It can be quite a good companion book to the Symfony framework, it's just not ready yet. When it is, it will be a useful guide to Symfony 1.3

Britain's best-kept secret

Bletchley Park is one of Britain's best-kept secrets of World War II, it was instrumental in shortening the duration of the War, being positively involved in every major conflict. It was a collection of talent and genius; staffed with mathematicians, engineers, linguists, chess players and demon crossword puzzle solvers. They quietly carried out their duty, careful never to break the seal of secrecy. And even twenty-five years after the end of World War II, the public still had no idea what happened at Bletchley Park. When the official secrecy expired and those records were made public for the first time in the mid 1970s we started to see the marvelous and ingenious work successfully executed by the collaboration of brains at Bletchley Park.

I think Bletchley Park exemplifies the quiet British determination and grit, its quirky inventiveness and eccentricities even at the most desperate of times. It's also a fascinating story of modesty, and so many of the people of Bletchley Park never received the recognition they so richly deserved - even today.

In war we glorify the conquerors - Eisenhower, Montgomery, Rommel, Doernitz - the people who made their names on the field of battle. We worship the political leaders Roosevelt and Churchill. Sometimes we remember the operatives working well behind enemy lines always in danger of being caught every moment of their lives. But for a few geeks sitting in wooden huts safely ensconced hours north of London, they are so easy to overlook, and yet their contribution to the defence of Europe is absolutely massive.

Bletchley Park was the center of Britain's intelligence war against the Axis powers. It principally was devoted to cracking and translating messages between the enemy military units, but it also ran counter-intelligence and special operations.

The main story of Bletchley Park is the story of Enigma and Bombe, and the codebreakers. Enigma, the machine that encrypted German military communications, and Bombe, the British machine that sought to break that encryption.

Cracking Enigma with Social Engineering

The breaking of Enigma wasn't all brute force. The codebreakers had a number of cribs - or techniques to reduce the possibilities - and many of them, as is thematic even in modern day codebreaking are down to social engineering. But in Bletchley Park's case it was reverse social engineering. Understanding habits of Enigma operators or message senders, and exploit it to reduce the possibilities.

One particular brilliant piece of social engineering was finding duplicate messages. If you have the entire encrypted message and you can with reasonably certainty guess the start of the message then we immediately narrow the possibilities of setup because we know how the first few letters are translated. That crib is then handwired into Bombe, and it spouts out possible starting settings that result in the matched combinations of letters.

There were a number of sources of these messages, the first was weather messages sent to U-Boats in the Atlantic, the German navy used standard weather reporting. So if the codebreakers could guess the weather pattern they could be reasonably certain of the decrypted message, so had a menu for the Bombe to process.

Why crack a message you already know? Well, the German military made one gigantic mistake - mainly out of confidence that Enigma was unbreakable. The Enigma start settings were the same for everyone in the same branch of the military, so breaking that one known message meant that they had the Enigma settings for all messages sent by the same branch of the military of that day.

The second piece of social engineering was a small German army unit in the middle of the North African desert. They sent virtually the identical message everyday reporting through their chain of command. Every day the message was "Nothing to report". That's enough of a menu for Bombe to brute force it's way to a solution. Now, what was utterly brilliant was Bletchley Park's request that the British Army in North Africa not send any of their units into the area this German unit was based. And so, the codebreakers virtually guaranteed that everyday they had the same message arriving ready for them to break the current day's settings.

Another source of repetitive messages were commands issues from near the top of the military hierarchy. They often started with the formal "Special Orders/Instructions" (out of habit essentially). So frequently the codebreakers guessed certain messages would start with the German word "Besonder".

I was amazed that social engineering was a critical part of breaking Enigma. Kevin Mitnick infamously demonstrated the power of social engineering in cracking computer systems, but the Bletchley Park codebreakers had already proved how effective it can be.

Chess and Bletchley Park

The 1939 Chess Olympiad in Buenos Aires was interrupted by the outbreak of World War 2. On the English team were Stuart Milner-Barry (later knighted), Conel Hugh O'Donel Alexander (or just Hugh Alexander) and Harry Golombek. All three left immediately and made their way back to Britain. Milner-Barry was the first to be recruited into Bletchley Park, and he in turn recruited both Alexander and Golombek.

So three of the best chess players in England were part of the Bletchley Park intelligence war. Each contributed substantially in their own way.

Milner-Barry headed up Hut 6 under Gordon Welchman, was later the person chosen to hand-deliver that petition to Winston Churchill begging for funding to keep the Bletchley Park operation going, which in turn Churchill became a staunch supporter of Bletchley Park's efforts. (Sir Stuart reprised that role by hand delivering a letter to John Major pleading for the preservation of Bletchley Park in 1992).

Hugh Alexander became the head of Hut 8 (the Enigma code-breaking effort), taking over from Alan Turing, becoming an instrumental part of the code breaking efforts. In Building B they recognise 4 individuals in particular for their efforts during the War. Turing was one of them, so was Gordon Welchman and Alexander was another.

After the war Alexander was recruited into GCHQ, and that basically killed off his chess ambitions. In a radio-match he beat the Russian champion Mikhail Botvinnik (who was regarded as the strongest player in the post-war world, and two years later becoming World Chess Champion). Unfortunately Alexander's commitments to the British intelligence community mean that playing international tournaments in the Soviet Block was far too risky to national security. So the British chess community were deprived of a potential World Championship candidate and potential grandmaster. His chess contributions were limited to local tournaments and writing chess books - including a memorable book about the legendary Boris Spassky - Bobby Fischer World Championship Match.

Alexander showed so much promise in the pre-war years, establishing himself in International tournaments like Nottingham 1936 where he placed respectfully despite having to face 5 World Champions. That promise and intellect was refocused into intelligence work through his experiences in Bletchley Park, so what was robbed from the chess world played a part in keeping Britain safe during the War and the subsequent cold war.

Harry Golombek continued being a chess correspondent, and a well recognised one. His book covering the 1948 World Championship Match Tournament is one of many splendid example of chess journalism.

Something to be proud of

I'm immensely proud of all the people who worked in and with Bletchley Park during the War. Every single one of them. I am still aggrieved however that Britain, or Churchill in particular, gave up its leading role in the computer revolution. I understand the political circumstances of the imminent threat of Communist Europe and Cold War threat provoked Churchill into hiding all evidence of the superiority of British Intelligence Services; but each time I see Silicon Valley herald itself as being the dog's bollocks, I wistfully remember that we handed that advantage over to them on a silver plate. And that is the nature of the British Spirit and stoicism.

I loved our big geek day out in Bletchley Park. I learnt far more than I imagined. Geekwise I'm satiated. But I know I want to go back and learn more. Thank you to the Bletchley Park staff for making us feel very welcome. Thank you for fighting hard to keep the story of Bletchley Park alive - the story of the British geeks and their phenomenal contribution to protecting our freedoms.

Bletchley Park - no movie can do it justice. Not even a blog post can convey just how instrumental they were. And I didn't even mention the working Colossus, the counter-intelligence operations, the pigeons, the D-Day involvement, the unheeded warnings, the Lorenz cipher, the Harrier Jumpjet, the amazing private tour we had, Alan Turing, the Computer History museum, the Churchill museum, the cipher museum... so much.