Tuesday, 28 January 2014

A lap around the "single page web app"...

What's this about then?

2014 will perhaps be the year of the "internet of things" - and the WWW will surely play a big part in that.
Front-end in WWW (HTML5 in particular) is rapidly becoming the vast majority for UI development - consider the fact that even many (most?) successful smartphone apps are running in HTML5 containers like phonegap: http://phonegap.com/ 
Having an understanding of the way the web works and what the state of the art is on the web today could save us (as in - software developers working with the WWW and their customers) a lot of time and money.
So I have written this post to help myself better understand. Perhaps you may also find it useful, dear reader!
Please just note that this post (or more accurately, links listed within) occasionally swings wildly from relatively simple to deeply technical...

The single page web app

According to @peterwayner, the JavaScript MV* framework and the single page web app are both now hot:
But web sites/applications used to have lots of HTML files, site maps, etc. So what what's happened? How does one write a web application on a single HTML page?
Basically it seems this trend is supported by HTML5, but has largely been enabled by the rise of the JavaScript async framework.
The evolution has more-or-less been like this:
[Bernard's Interpretation of the Evolution of the "Dynamic" Web Application]

In reference to the "XMLHttpRequest + JavaScript = RYO AJAX script" - if you interested in seeing some source code that does this, take a look at a previous post I made on this subject:

The JavaScript MVC

So let's take a closer look at JavaScript MVC. Basically these are frameworks that enable us to treat a web server and an appropriately designed suite of web services on that server, as an application back-end.
The following section of the (freely available) book "Backbone.js Applications" provides a more detailed overview:
These WWW client-side MVC frameworks have really taken off in popularity over the past couple of years - they are generally based on the likes of jQuery and provide beautiful functionality for UI and back-end integration development purposes.
The following article (I was referred to this compliments of @josh_robb) is what inspired me to write this post and provides an extremely interesting (IMHO!) overview of why JavaScript MVC frameworks like backbone.js' days may be numbered...
Perhaps this is the article to read if you are considering using a JavaScript MVC framework in a project currently: 

Some references

Get Backbone.js: http://backbonejs.org/
Get Knockout.js: http://knockoutjs.com/
Take a look at "Om": https://github.com/swannodette/om


Finally another interesting addition to the mix is node.js; this is not really a web development framework, but in-fact this is JavaScript turned into a server-side language. Indeed, a node.js program can initialize it's own self-hosting web server - i.e. a "node". 
Get node.js: http://nodejs.org/

The enabling substrate

And what does all of this jumble of stuff depend on for it's very existence? It is of course HTTP; currently in version 1.1, or 1.0, depending on which browser you are running. This year though, we will see HTTP 2.0 start to make inroads.
This event is a bit of a big deal and carries with it the potential to turn "conventional" web development on it's head...again. Take a look at this video for an overview:

["Making HTTP realtime with HTTP 2.0" - Source: Realtime Conf 2013]
This video referred to me via @petegoo. Here's the Wikipedia page for HTTP 2.0 also, for reference: 


Diagnostic tooling

What would an enthusiast of any genre - including web applications (or "internet of things") development - be without their tools? Probably not an enthusiast...
There are a range of diagnostic tools - that is, tools for analysing the performance/behaviour of your app, as opposed to developing it - available supporting web development. Tooling ranges from on-board (actually within the browser) to IDE integrated, to server-side diagnostics, to bits-and-bytes-over-the-wire-level. 

So here is a non-exhaustive list for your reading pleasure:

On-board: Chrome

Follow these links and update your instance of Chrome to the latest version to take a look at some of the newer tools available for this browser, including the fantastic "flame chart" for JavaScript performance analysis:

On-board: Firefox

Browser-independent: Fiddler

Bits-and-bytes: Wireshark


In summary - have fun!

Thursday, 9 January 2014

Software architecture; the lay of the land -


Given the plethora of genres of architect that are sought on [insert your favourite job search tool].com, I thought it would be worth writing a post on this subject, to help myself and anyone else who may be inclined to ponder software architecture, better understand the lay-of-the-land within and outside of their own organisation.
This post is actually a loose assembly of my own thoughts and previous posts that I have made on the matter of programming and architecture; I have copied/pasted, and stitched together to form a somewhat coherent document.


"An architect is a person trained and licensed to plan, design, and oversee the construction of buildings. [...]"
Here's a picture of a Saab – according to Top Gear, all construction type architects own one of these:

[A Saab]

But this post is about software architecture...

So how does architecture relate to programming?

To be clear, architecture is by no means a final or inevitable destination in the career of a programmer. It is more a way of thinking than a "job", and in-fact, a good architect may not necessarily be (or have been) a good programmer.
Architects like to think about the big picture – business implications, what the customer thinks, how a design will fit with company/product strategy, project scope, etc – hence their work is much "fuzzier" than the programmer's. By contrast, a programmer may love the intricacy and precision of their work; designing a complex system at the "nuts and bolts" level and seeing it come to life.
Fred Brooks puts it like this in his influential book The Mythical Man Month:
"[programming is] the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning. The programmed computer has all the fascination of the pinball machine or the jukebox mechanism, carried to the ultimate."
Neither programmer nor architect is "better" than the other, but they are different and can be expected to have different interests.
As the profession and industry of software development matures, we have an ever-increasing volume of historical accomplishments and/or issues to look back on and pat ourselves on the back about, or alternatively facepalm – depending on how you look at it!


We now understand that it's not how much code is written that is important; what's really important is the quality of the code and whether the code implements a product that meets the customer's requirements. Movements like Agile and Lean (as it applies to software development) reflect this thinking – but that's another story...
Successful software architecture is to a large extent guided by looking to and applying learning from our own history; certainly architecture is more about this, than it is about trying to find new and exciting ways to apply the latest/greatest technologies known to humankind.
Depending on the type of organisation, architecture may be more-or-less important. An organisation that aspires to be a product company for example, may put more emphasis on architecture than a services or utility type company (power, telecommunications, etc). 
To elaborate; imagine a suite of products with implementations geographically/physically distributed across many countries, sites and customers. Design decisions in this situation made around software development can have a far reaching impact. By comparison, "internal" software systems (the services or utility company, for example) maintained by an internal team of programmers, can be manipulated and modified with relative ease; the implication being, priority of design may be overridden by convenience in this situation.

Types of architect/ure

So what are the various "flavours" of architecture that we may come across, within and outside of the organisations we work with?

Solution architecture

The goal of solution architecture is to produce a customised solution for a specific customer. The solution may end up being part of a product, but initially at least, is tailored to a specific customer's (or group of customer's) requirements to solve a specific problem.
Wikipedia sum up solution architecture quite nicely: http://en.wikipedia.org/wiki/Solution_architecture

Product architecture

This is a relatively old discipline that is applicable to areas outside of software development.
One definition is as follows: "The arrangement of functional elements into physical chunks which become the building blocks for the product or family of products."
Here's a slideshow that Berkley provides online, relating to PA: http://best.berkeley.edu/~aagogino/Slides/11_SPD_platforms.pdf
Basically the role of the product architect is to think about the products in a company's portfolio and how they can be developed, improved and streamlined in order to make them more marketable, maintainable and effective.

Enterprise architecture (edited 20140714)

Enterprise architecture (EA) departs from other types of architecture in terms of definition and function - it is more of an introspective business discipline that leans on technology (business process design/mapping, automation/improvement, etc) than the other way around.
With the world becoming more-and-more interconnected and automated, and with new ideas being able to be brought to market faster and faster, there is a growing interest in EA as a means to improve internal business process. 
Several EA "frameworks" have sprung up in recent years - here's Microsoft's comparison:
Effective internal business process can be seen as a way to gain competitive advantage, since internal process is harder to imitate (by competitors) and easier to control (by the enterprise) than external factors. Examples of external business factors would be product marketing and development, price-based competition with other companies, etc.

EA's goal is to change and improve internal business process, which is in-turn expected to result in improved ability to successfully negotiate and manage external factors, thus enhancing and enterprise's overall competitive advantage.

Agile architecture

Another more recent addition to the list of types of architecture, and a growing movement, is the concept of "Agile" architecture:
The Agile architecture concept essentially says that architecture is a collective and emergent thing.
The role of the architect in an Agile team is one of bringing ideas together, making sure people feel comfortable sharing their ideas and then assembling the team's thinking to form a coherent "way forward" from a combination of the group's collective thinking and the architect's personal judgement. Sounds a bit "new agey"...but Agile is a bit like that.
Indeed, the role of "Agile Architect" in a team may not necessarily be held by an individual, but exist in the collective thoughts and opinions of the team, as a means to achieve a specific goal.

Concluding thoughts

Although we use titles to distinguish functions, within a single company/industry many of the above "flavours" of architecture may bleed into each other.
People's titles reflect their various backgrounds and interests, and what they are expected to be able to contribute in a team context. Despite this, we may find that the acting architect on a project/team may not hold the title of architect, but rather, be a senior developer, team leader (perhaps even a PM!), etc – essentially, someone who knows and/or has more experience than most about a particular problem/domain.
In Patterns of Enterprise Application Architecture (recommended reading for anyone who is in software development/design-esque line-of-work) Martin Fowler describes software architecture as being:
"The highest-level breakdown of a system into its parts; the decisions that are hard to change; there are multiple architectures in a system; what is architecturally significant can change over a system's lifetime; and, in the end, architecture boils down to whatever the important stuff is."
This seems to fit – basically, in order to deal with architectural decisions and problems, it helps to have the desire to be involved with this type of fuzzy stuff, and also the experience to be able to make informed/effective decisions in the face of fuzzyness – or at least, to get yourself (and the system) out of the schtuk if you make the wrong decision.

[Stakes is high: the "Ford Edsel" - http://en.wikipedia.org/wiki/Edsel]

Migrating (and Open-Sourcing) an Historical Codebase: SVN-to-Git

I have a SVN repo on my local machine that I have been shoving stuff into since before I knew how to use revision control systems properly (...