yobriefca.se

The Old "Agile is for Developers" Myth

2013-05-08T00:00:00+01:00

There is a common misconception among people who are just starting out on the agile path that the agile model favors developers and downplays other roles. While it is true that agile puts a greater focus and added responsibility on developers it also broadens the definition of developer from the niche of “people who write code” role to a more umbrella term of “people who deliver software”.

Another comment I heard being made, admittedly in jest, is that agile is “Disneyland for Developers” and honestly this couldn't be further from the truth. In fact agile methods typically expect people involved in delivery to be MORE responsible for delivery. Developers are no longer just mindless code monkeys banging out tasks against pseudo-code written in a document. No, developers are expected to DEVELOP a working solution. This includes analysis, design, architecture, development & testing. All of this is expected to be done with one eye on the “big picture”, they are expected to understand WHY they are doing something from, both, a technical and business perspective, they are expected to be at least understand how their code is deployed and often expected to be able to deploy it. You don't have the Java guys, the Web guys or the DBAs - no, a single person in a team should at least be capable of driving out a vertical slice of functionality from infrastructure to database to services to HTML and JavaScript. Of course the slice doesn't have to be, nor will be, perfect right now. There will always be space for specialists to come in and make their areas better, more secure, faster, whatever needs done. But at the very least when all but one person on the team catches some rare exotic disease on a team bonding night out that person can still deliver valuable working software until the rest of the team recovers.

Ultimately though the agile methods that are technically focused are about ensuring quality of delivery. Delivered features should be “done” rather than thrown together an handed over a test team to let them find the issues - a common side effect of time constrained, fixed scope, phased delivery. That practice is unacceptable even in plan based or phased models and regardless of the project approach a development team can and should be making use of practices often associated with agile.

But other roles necessary in the delivery of a project also benefit greatly from agile approaches. Just think of some of the things these other roles would do within more traditional project delivery models,

Who has to spend days or even weeks manually running the same few hundred scripted tests every few months to avoid regressions and assert correctness of the system? Not the developers thats for sure. Testers are often required to execute manual scripted tests which are slow, prone to error and have a relatively low ROI compared to other testing techniques. Manual tests check for issues you know will break your system, but its the unknown issues that typically kill your solution. Automation of these tests (by developers and testers) gives faster more frequent feedback and allows testers to actually do interesting, rewarding, more valuable testing such as Exploratory Testing. Testers should not be there to break things but to ensure we build the right thing right in the first place.
Who spends weeks going through multiple versions of documents that seldom get updated and go out of date shortly after sign off? Again, not typically the developers. Business Analysts and Solution Architects spend a long time producing documents that create a contract for all parties involved. Often, though, they are only pulled out during “disputes” around agreed functionality (between either developers & tester or customers & analysts). If that happens though, then who is actually reading these things properly? No matter how rigorous you make documents there will always be the problem of interpretation. You can't misinterpret a running solution.
Who is expected to “manage expectations” when delivery is slipping beyond the scheduled dates?. Long running projects that pin all their plans on up front estimates will slip. It's inevitable unless you've managed to overestimate everything but then I'd wonder why you are doing the work and not your more aggressive competitor. When this happens it's typically the job of the manager and senior technical folks to inform the customer in the best way possible, to “manage their expectations” (shudder). No one wants to do that. In typical agile models visibility is a key differentiator (another way to ensure quick and frequent feedback) which removes the need to for big bang disappointment. When things change or slip you know about them much quicker and can course adjust, the impact is significantly reduced.

All these (arguably wasteful) practices are typically the responsibility of people in non-developer roles. Now that we have reduced or removed these practices does that mean we've made the roles redundant? Not at all - as with the developer role increasing in scope so does the manager, analyst and tester. Testers no longer just “test”, they have a more important function - assuring that what they test is the right thing, they've become crucial to analysis. Analysts also need to understand aspects of project management and managers themselves can move to a more hands-off sales and account management role as delivery is managed by the team itself. What we will see is a reduction of specific titles on projects, most people no longer fit those niche titles.

Facilitators & Implementors

So, yes, agile approaches certainly favour working software over volumes of documentation describing what the system should do but heck - so does common sense.

Agile approaches flatten the role structure across the delivery of a project. You end up with umbrella terms like facilitators (who ensure the right thing is being built) and implementors (who ensure the thing is being built right).

You go from this,

To something more like this,

If you wanted to map these intentionally nebulous terms back to typical roles in a more traditional model you have,

Facilitators - Business Analysts, Solution Architects, Customers, Stakeholders, Users, Testers, Project Managers, Legal etc.
Implementors - Developers, Testers, DBAs, Designers

Its clear to see where the commonplace agile roles fall as well - Product Owner and Scrum Master would be facilitators and the team would be the implementors.

Already, even at this high level you're getting overlaps and in many ways everyone plays their part as both a facilitator and an implementor but its generally obvious what a persons primary function is and you can plan around that accordingly.

You don't need fancy, lofty titles because you have a single purpose. Titles only force attribution of responsibility to particular people, they enforce specialism and defensive attitudes. Titles shouldn't affect the delivery of a solution.

So, no, “agile” is not just for developers, it's for the facilitators, the stakeholder & the implementors, it's an all-encompassing first step on the road to refocusing our goals from following a process to delivering the right thing quickly and painlessly.

Micro Service Architecture

2013-04-29T00:00:00+01:00

Micro Service Architecture is an architectural concept that aims to decouple a solution by decomposing functionality into discrete services. Think of it as applying many of the principles of SOLID at an architectural level, instead of classes you've got services.

Conceptually speaking MSA is not particularly difficult to grasp but in practice it does raise many questions. How do these services communicate? What about latency between services? How do you test the services? How do you detect and respond to failure? How do you manage deployments when you have a bunch of interdependencies? So lets expand on some of these throughout this post and see if MSA really is worth the effort.

Anatomy of a Micro Service

First things first what actually is a micro service? Well there really isn't a hard and fast definition but from conversations with various people there seems to be a consensus that a micro service is a simple application that sits around the 10-100 LOC mark. Now I realise that line count is an atrocious way to compare implementations so take what you will from that. But they are small, micro even. This means you're not going to find hundreds of tiny services built on top of large frameworks, it's simply not practical. No, simplicity and lightweightyness ^{(not a real word)} is the order of the day here. Small frameworks like Sinatra, Webbit, Finagle & Connect do just enough to allow you to wrap your actual code in a thin communication layer.

In terms of a footprint these services will be small, you're potentially going to run a lot of them on the same machine so you don't want to be holding on to memory or resources that you aren't intending to use. Once again simple libraries over large frameworks will win out, you'll also find less of a reliance on 3rd party dependencies.

This decoupling at a service level also offers another interesting option. We've pushed a lot of the old application complexity down to infrastructure level. We are no longer bound to a single stack or language. We can play to the strengths of any stack or language now. It's entirely possible to have a system built out with a myriad of languages and libraries, though as we will touch on later this is a double edged sword.

You're also not going to find any true micro service based architectures that are hosted in an application server, that kinds of defeats the point. To this end micro services self host, they grab a port and listen. This means you'll lose any benefits your typical enterprise application server may bring and your service will need to provide some of the more essential ones (instrumentation, monitoring etc.).

Communication

This is an interesting one. How do your services communicate? There really isn't a single answer for this, even in a single solution. The most basic approach across the board would be to expose all services over HTTP and pass JSON back and forth. Service discovery (how one service knows where to find another) can be as simple as putting the endpoint details into a configuration file (or simply hardcoded).

You may discover, in certain circumstances, the cost of serialising and deserialising JSON payloads through an entire transaction is causing bottlenecks. Perhaps JSON isn't suitable at all (binary formats) and so you'll want to look at different protocols, like Protobuf

But hardcoded urls kind of imply a certain strict coupling and A-B-C workflow. In a layered application this makes sense but moving into a service based architecture means you're not bound by this (potential) constraint. Some communications between services can be completely decoupled, in fact some services could publish events or data blindly. They can just throw it into the ether (or at least a message bus) and maybe one day some service can come along and start listening. Alternatively maybe parts of your system could operate in a batch/offline process, feeding off a queue and flipping bits many hours later.

A micro service approach gives you this kind of flexibility without major architectural rework.

Monitoring & Metrics

Components of a monolithic, layered solution don't typically fail silently - it either fails to compile or throws exceptions when something is wrong (unless you go out of your way and silently swallow exceptions like some insane person). In a service based approach a service might drop off the face of the earth and it's very easy for no other service to notice (especially in a pub/sub model). This means it's imperative that services are properly monitored and orchestrated. In fact just knowing a service is alive is seldom good enough. Is it providing enough business benefit? Is it even being used anymore? Is it acting as a bottleneck for reliant transactions?

Monitoring is always important but more so in a service based architecture where failure is often less obvious. Good examples of this from the JVM world are Metrics and Ostrich these libraries not only allow for collection of metrics but provide a means of integrating and reporting that data into other services like Nagios or Ganglia.

Testing

There is nothing particularly special about testing services in a micro service based system but the point I want to raise here is that you've reduced the need to have a full suite of tests for every service. Because a service does one thing, and should do it well the risk of introducing a system breaking bug is significantly reduced thanks to the natural behavior of a service based system. Now writing tests for the sake of it, or just in case, holds little to no value but still require the same amount of care or attention during refactoring.

I'm not saying don't test but I am recommending you think before you use the old “No. of Tests” as a value of code quality.

In fact lets go one step further and change the way we test entirely. You've got monitoring in place, at any given time you can know what services are broken and recover. But also why not monitor key business metrics on each service and use them as indicators to know if we've broken something. This is commonly known as a production immune system. If conversions are dropping, or sales have halted then you can make it so your system rolls back to a known stable state and gives you nasty looks until you fix the problem. The same approach can be used for A/B testing and Dark Launching new features and services.

Micro Service Architecture actually makes a whole lot of sense when it comes to ensuring you have a stable system at any scale.

Applications of Micro Service Architecture

MSA has a number of interesting applications. Obviously green field solutions of a given size is an obvious use of this approach. Though I say “given size” because the cost incurred at an infrastructure level required to support micro services could outweigh the benefits and, for small systems, a simple web app would be totally acceptable.

Micro Services also have an interesting application in large legacy systems. Working with legacy code is risky at best. For systems that have been running for decades there is a chance there is limited knowledge in how the systems actually works internally. Working with this code can be like working with a house of cards and a simple mistake in one place can have adverse affects elsewhere. These systems are typically mission critical so mistakes can be costly. So just don't touch it. The micro service approach lets you do this. Rather than diving into the legacy code base, write a small service that does what you need (yes you may be duplicating legacy code) and proxy service calls through it (e.g. via nginx/apache etc or purely within code).

Now imagine doing this regularly as part of your maintenance and support program. You'll be turning off the old system bit by bit and perhaps eventually be able to turn it off completely.

Issues

Micro Service based systems aren't without their problems of course. For one there is a greater need to better understand non-development areas. In days of old before DevOps was a broadly misunderstood marketing term developers would deliver working systems over the wall to operations who would deploy it to production and everything would fail. Of course this was the ops team fault, don't they know anything? Jeez. It was entirely possible for a developer to know only code, running the entire application from their IDE without thinking about how this would work in real life. MSA forces the developers hand to actually be more responsible and actually get involved in scripting of deployments and understanding integration requirements etc.

Another issue that I touched on earlier is the fact, left unchecked you could have hundreds of small services written in hundreds of languages. Simply managing that sort of estate of languages and platforms with their different installations, package managers and requirements can stop a project dead in its tracks.

An anti-pattern has emerged from the MSA approach - often called the Nano-Service architecture. These are systems built on services that are so small that duplication of effort is prevalent and it becomes almost impossible to reason about any particular area of a system easily.

Macro Post for Micro Services

The irony of a large wall of text to introduce the concept of micro services is not lost on me but there is lots to consider. Micro Service based systems can produce scalable, fault tolerant systems on fairly low cost hardware. MSA promotes good practices of keeping things lightweight, emerging systems and business monitoring but as with everything should be approached with a rational mindset and solid understanding of what you need to achieve.

Rice

2013-04-21T00:00:00+01:00

Rice. A swamp grass that we consume, awesome. But how do you prepare rice? You could,

Buy it in pre-prepared microwave packets
Buy a rice cooker
Make it yourself using some water and a suacepan

Theres probably more but that would detract from my carefully constructed metaphor (I'm not drunk, honest). So whats the point? Well lets think about the pros and cons of each.

Buying In

You can buy these little pouches of rice that you pop in the microwave for 3 minutes and you've got hot steamy rice. Sort of. It's never perfect. The work involved in taking a perishable food stuff and making it “less” perishable, packaging it and shipping it around the world kind of degrades the product a bit. You ultimately have to trade off quality for convenience. You can certainly add ingredients to the rice to rejuvenate it but its never quite same and lets be honest the packet size is always either too big or too small and you end up wasting some.

Using a Rice Cooker

Rice cookers typically cook rice really well but they are an investment, you may only use it occasionally, some of them are a pain to clean and you've always got to find space for it in your kitchen (if you had a fancy tool for every type of food you'd need a much bigger kitchen). Plus these things don't really scale very well. They typically make a certain size and if you want more than that you need to start doing it in batches or invest in another rice cooker.

Make it Yourself

Rice can be a pain in the ass to cook, it sounds simple. Too little water and it burns and sticks to the bottom of the pan, too much and it boils over leaving starchy water everywhere. You can under-cook it, or wore overcook it into a stogy mess. If you get distracted or try to do too many other things its easy for things to go bad and you'll be left with a mess that needs cleaning up. Then theres the problem of judging the right amount of rice to cook. Eventually though, after a spot of trial and error, cooking rice without fancy tools becomes rather easy and predictable.

A Carefully Constructed Metaphor

I did mention previously that this was a metaphor and I wasn't lying. I've been mulling over this analogy for a while (while I was cooking rice for real). In software you've got similar approaches to delivery,

You can buy an off-the-shelf solution that accomplishes most things
You can use a framework with all the bells and whistles
You can roll your own solution

The all have their own trade-offs that align well with the rice metaphor.

Off the shelf products give you a certain level of convenience provided you are willing to live with that you are often compromising user experience to satisfy the view of a “typical user” that the product must adhere to to appeal to wide user base. And yes you can typically add your own ingredients through extra development work but it's never quite right.

By using a large framework you've got accept a certain amount of upfront complexity for the future promise of making the delivery of solutions easier. Much like the rice cooker, frameworks will invariably bring with them a slew of features that you'll never use. However there will always be the need to manage and cope with that extra complexity and often the cost of this complexity (setting up boilerplate for a new feature, writing a bunch of configuration to allow the framework to do it's magic etc.) could be greater than the value a small feature provides. Features users want will be deferred because of decisions they did not have a say in.

Finally the idea of making your own rice, or using a minimal set of common tools to deliver the right amount features. Yes it may seem initially daunting, you'll probably get it wrong a few times (do too much or not enough) but eventually you'll build up enough knowledge and skill that you can see that reliance on heavy abstractions is often more of a burden than a help. While rolling your own may appear as unnecessary risk - taking this approach in small steps is significantly less risky than pinning all your hopes in a frameworks sales pitch or the promise of buy-and-run COTS products.

Building your own stuff has the added future benefit of letting you make more informed decisions. Clearly there is no one right answer for every situation - sometimes you may just benefit from firing up a ready rolled WordPress site, or, perhaps Middleman or Jekyll would fit in well with the publishing strategy of the project, but sometimes a simple Makefile with a bunch of sed calls will do the job.

Finally the simple act of actually trying build your own solutions will give you greater clarity when you need to answer questions around build vs buy or technology choices. Just because frameworks, tools and products allow you to be ignorant of many things it doesn't mean you should be.

Hardening Sprints: Just Say No?

2013-04-18T00:00:00+01:00

I was recently asked by a PM in my company if “hardening sprints” are allowed in agile projects and I gave the very pragmatic answer of “you do what needs to be done”. I left the conversation not feeling right though and I've been thinking about the question ever since. To be honest my gut instinct is that, with certain exceptions, these sort of sprints are a smell and their origins are firmly rooted in phased/waterfall delivery. I'll address the “with certain exceptions” caveat a bit later but lets first dive into the idea of hardening sprints.

What is a hardening sprint?

A hardening sprint is a timebox or sprint reserved at the end of a group of sprints (usually prior to release) to allow testing or hardening of the release. This could mean extra testing, different types of testing, refactoring, reviews etc. It brings with it the rather bizarre concept of “Done Done” - i.e. features that have been delivered in previous sprints may be “Done” but not “Done Done”. So it may be coded and “kind-of” working and “kind-of” tested and people are “kind-of” happy with it and yeah its “kind-of” done but we'll wait until the end to know if we are really done.

So What?

It strikes me as “kind-of” odd that this sort of thing happens without people raising an eyebrow. For one thing there is no such thing as “Done Done” and if we don't admit it I fear that we'll see “Done Done Done” pushing its way into our process vocabulary.

The next thing that strikes me - there is absolutely no data available to predict how long this “hardening” process should take. If we take it at face value the term implies a single sprint. How can we be sure whatever unpredicatable stuff comes up during that sprint can actually be addressed and adequatley resolved in that sprint? Or, taking it to the other extreme (indefinite amount of sprints) how do we know when to stop - afterall nothing is ever perfect.

Undoing All The Good Work?

So we've spent X amount of sprints refining our approach to delivery, continually improving and learning and now we've thrown the project into this huge dark pit of uncertainty and “hardening”. Surely I'm not alone in thinking this sounds somewhat wrong.

Another risk is that this kind of strucutre will create is a potential reduction in ongoing quality. It could be argued that hardening sprints, much like the old phased/waterfall approach to delivery, removes a certain amount of responsibility from the delivery team. Now there is less of a desire for developers to apply as much rigour to their code as they may have - afterall “the testers will find the bugs so why waste my time being thorough?”. But if you are deferring your user or penetration testing a few months down the line there is always this notion that the team can just “throw it in and see what comes out in the wash”.

“With Certain Exceptions”

Of course, like every rule, there may be exceptions. One obvious exception is external penetration testing. There can be considerable cost and time assoicated with getting a third party specialist in and its certainly not viable to do it every sprint. So defering a full pen testing cycle until near the release is an acceptable and often necessary exception. But that doesn't mean the team should throw all care about security out the window - the goal of the penetration testing should be to validate that there are no vulnerabilities not to discover them.

Next Time Gadget… Next Time

So are “hardening sprints” a good idea? I'm inclined, as negative as it may be, to start with “no” and take it from there, afterall its better to start with discovering why we can't do certain things inside of a sprint rather than assume we can't and carry on ignorant of the potential benefits.

Teams or People?

2013-04-08T00:00:00+01:00

A team is much more than a group of people thrown together for the period of a project. This is quite common in a utilisation based business model where downtime is viewed, on the balance sheets at least, as money wasted. I'd call that myopic.

Putting aside other arguments for a moment (downtime is quite often good for allowing motivated people to learn and grow) lets think about Tuckman's Stages of Group Development.

Tuckmans model suggests that teams go through various stages of development, as denoted above. During these phases various things happen,

Forming - the team comes together shares their history and begins to develop an understanding of the problem to be solved.
Storming - after the gentle introduction people begin finding their place in the team. Dominant parties fight for control, less dominant sniff out their leaders and the power struggle kicks off.
Norming - the power struggle is over and people understand their place in the team. Less impediments occur through communication.
Performing - the team has gelled and is working effectively, everyone is in the role they need to be and everyone trusts each other.

There is a final stage - Adjourning where the team, as a collective whole, part ways - but I'll get to that later.

What does the y-axis in this pseudo-graph represent? I guess the obvious answer is team productivity but given the many factors that can affect team productivity/efficacy this isn't a realistic metric. No, the y-axis in this case reflects the teams focus on their goal of delivering the solution. In this situation it makes sense that a “team” become a staple unit of delivery vs the old resource rumble of “whoever is free”. Short-lived teams of randomly selected individuals are always going to be operating at sub-optimal levels due to the very nature of team dynamics. Now here's the rub - more often than not this performance is nigh on impossible to quantify. In fact if “people as units of delivery” has been a thing for a while you'll find people making excuses for inefficiencies by front-loading of estimates. What happens then in sales and bids, how can a company who's estimates are derived due to sub-optimal team output remain competitive but keep their process the same? One dubious tactic would be for sales team gently massaging numbers and rates to make them more appealing. This makes the entire delivery process from sales to final delivery of a solution highly inefficient and pressured and we haven't even touched on the evils of potential overselling and micromanaging!

So - the team a a unit of delivery makes sense IMHO, but it's not without it's problems. Moving to a team-based model requires a significant jump in company culture, accounting, sales and, if you'll let me use the word, resourcing. There are potentially huge visible risks in long stretches of downtime for teams. Arguably though large visible, almost predictable risks, are significantly better than unquantifiable consistent loses right? At least you can mitigate them.

Adjourning

A team can't stay a team forever. People get hit buses or worse get bored and a long lived team that refuses to change is simply another silo of knowledge that methodologies like agile try and crack open.

But adjouring the team isn't about throwing the core team to the wind. Too much team churn and you end up back a square one. Too little team churn and you've got the silo problem. Team members should be rotated to allow knowledge to propagate (inwards and outwards from the original teams perspective). However this clearly brings its own problems (is a person who's constantly rotated really ever part of a team) and the balance needs to be struck over time.

Spotify is decent example for this sort of cross-team knowledge sharing and I'd recommend checking out Scaling Agile @ Spotify

The team as a unit of delivery is certainly more suited to product based companies or large, long running projects because it feels more natural. In a services based outfit or consultancy house being able to ship people about at will is easier but thats not to say its actually beneficial. While it brings its own unique challenges team-based resourcing can allow organisations and project to greater realise their true potential.

The 'New' Value Triangle

2013-03-30T00:00:00+00:00

A projects delivery effectiveness can be affected by many things. There is, however, a baseline trade off on three core values and being aware of this trade off can help you make better decisions. The diagram above highlight these core values,

New Domain - this can be a new problem domain or new challenges within an understood domain. It may also be considered a new domain if a large proportion of team have limited or no experience in it. (e.g.coming into the health sector for the first time or possibly new legislation coming into effect).
New Technology - New technology can be either mandated (integration work) or just by virtue of the fact technology is always evolving. There are always new (and potentially) improved ways to solve common problems in solutions.
New People/Team - New people or teams occur when a large proportion of a team has never worked together or are changed between phases. Depending on the type of organisation you work within you may never work with the same person twice or for very short periods of time. This is common within utilisation focused service companies for example.

The “new” value triangle proposes that,

Given a new project you must only accept up to a maximum of two of the “new” trade offs.

Obviously the less the better but there will invariably be challenges outside of the project that will have an impact on these values. Having to cope with all three simultaneously will seriously impede successful delivery of a project and must be avoided at all costs.

Its worth noting that the term “new” when looking at each trade-off on its own merit isn't necessarily a negative thing. New blood on the team can inject fresh spirit and allow knowledge to propagate beyond the boundary of the team, new technology can speed up delivery of more robust solutions and a new domain can bring considerable business value. But at scale or combined these “new” values can become a hindrance on successful delivery.

Another consideration is that this is a general rule. You are not always going to be in a situation that mandates such trade-offs. Or perhaps you are in a situation that seemingly mandates all of them? It's possible, with careful thought, to slowly transition through all the “new” values over time but at any given point its always wise to keep tabs on what you are trading off to ensure you aren't holding back on the effectiveness of delivery.

So you've got to know when to trade off certain values and when you do what mediation patterns could be applied to prevent unnecessary waste

Standardise Technology (NPT/ND)

When a team (potentially new to each other) is kicking of a project in a new problem domain (to the team or the organisation at large) there is usually the greatest business risk and as such the team need to be ready for surprises as, and when, they happen.

One of easiest ways to achieve this is to reduce risk on the technology front. Standardising and using the most boring, non-shiny, well understood technologies removes any requirement for the team to learn new paradigms and principles while trying to wrap their collective minds around a new domain and potentially getting up to speed as an effective team.

Commoditise Solutions (NT/NPT)

From an organisational perspective when you find yourself consistently in a well known domain there is a risk you can begin producing extremely similar systems time and time again. This is isn't going to look terrible on the balance sheet but if you have a high team churn there is a lot time being wasted in getting people up to speed that could be avoided.

This is probably a very good opportunity to commoditise your solution, turn it into a product and sell it. That way you can establish a baseline consistency via a core team and established technology stack and focus even more on the adding true business value.

Iterate & Experiment (ND/NT)

Given an established team entering into new domains and technologies the simplest way to reduce risk is to iterate & experiment rapidly. If the organisation you work within delivers bespoke software its very likely that the work you do will be within a new domain or at least a new/different subdomain of a common domain you typically deliver into. When introducing new technology as well it's vital that teams work well and can begin delivering quickly and iteratively to understand both the new domain and any potentially how new technologies fit.

Having a largely consistent team as your unit of delivery allows us to focus on delivering the right tools to tackle the right problems which adds significantly more business value than the other trade-offs. Of course - changes are perfectly acceptable & encouraged as long as they aren't wiping out a large group of the core team in one fell swoop.

Conclusion

At any point in any project there will be trade-offs. Many of these trade-offs can be boiled down to something similar to this value triangle and knowing strategies for dealing with these situations allows the project to optimise for the most effective approach.

Uploading Files with Play! 2

2013-02-25T00:00:00+00:00

Source

A quick look at how to achieve file uploads with Play! 2 including other form fields and uploading more than one file

play-reactivemongo

2013-02-18T00:00:00+00:00

Source | Official Site

play-reactivemongo is a plugin for Play 2.1, enabling support for ReactiveMongo - reactive, asynchronous and non-blocking Scala driver for MongoDB.

In this episode we will retrofit the app from episode 003 to use Mongo, ReactiveMongo and the play-reactivemongo plugin.

ReactiveMongo

2013-02-11T00:00:00+00:00

Source | Official Site

ReactiveMongo is an asynchronous, non-blocking MongoDB driver written in Scala. This screencast will move quickly through the basic concepts that define ReactiveMongo and then show examples of the various basic operations you’d expect from a MongoDB driver

Starter for 10: Play! 2 - Part Three

2013-02-04T00:00:00+00:00

Source

Part three of the Introducing Play! 2 Series. Play! 2 is a Java/Scala framework based on a lightweight, stateless, web-friendly architecture for highly-scalable applications. This episode will introduce us to the concepts of

Play Forms for binding request data
View Helpers, and,
Form Validation

Starter for 10: Play! 2 - Part Two

2013-01-27T00:00:00+00:00

SOURCE

Play! 2 is a Java/Scala framework based on a lightweight, stateless, web-friendly architecture for highly-scalable applications. In this episode we will look at

Creating Controllers & Actions
Creating read-only views
Routes and URL matching

Screencasts with a JVM flavour

2013-01-21T00:00:00+00:00

Today sees the inaugural launch of a new project/passion of mine - yobriefcasts.tv. There is a launch post about it on the site as well as the first in a series of screencasts around Play! 2 (more being edited as you read this no doubt). Initially I never set out to focus on the world of the JVM but after building a list of potential topics and doing some research there is just so much there and so little audio/visual coverage of it that I think it deserves some attention.

As it stands right now there is an [optional] price associated with the productions - you can stream everything to your hearts content or you can pay a minimal sum to get a high quality download of the screencast - you can do both if you want. It took a while to come to an acceptable price point and structure because I have an end goal here - I want to feed any money earned back into the project to get better equipment and thusly produce better quality screencasts. Futhermore I'd eventually like to turn this into a (mostly) full time gig and move to a subscription model with frequent (weekly) releases - but thats a long way away yet - for now I want to see if I can build something people want and enjoy.

But hopefully the site can speak for itself - I've already got an extensive list of releases coming up over the next while so stay tuned, follow us on twitter as @yobriefcasts and enjoy the site.

Starter for 10: Play! 2 - Part One

2013-01-21T00:00:00+00:00

Play! 2 is a Java/Scala framework based on a lightweight, stateless, web-friendly architecture for highly-scalable applications. In this episode we will look at

Introduction to Play! 2,
Downloading & Installing Play!
Using PVM (Play Version Manager) to Install Play!
A brief tour of the command line interface.

Trello Cards: Materialising Trello Boards

2012-12-28T00:00:00+00:00

TL;DR I ported pivotal-cards to trello-cards

I recently did a spot of work with the awesome and brilliant people of the Government Digital Service and being big fans of getting stuff done they make use of whiteboards and index cards to visualise the flow of work on the various projects. Thats all well and good but it makes reporting to senior managers, stakeholders and remote people a bit difficult (and for the uber paranoid - what about auditing!!!). To that end this flow of work was also mirrored online - and in GDS's case the tool of choice was usually Pivotal Tracker. In order to bridge the gap between the online and “real” one of the smart chaps at GDS wrote pivotal-cards which lets you generate printable index cards from you pivotal board. Lovely stuff

Anyway - I spent some time today porting this little project to Trello. I have been using Trello more and more on recent projects but always miss the physicality of real index cards and I'm usually strapped for time to start writing them out myself.

So here it is - trello-cards, I've tried to keep it pretty much 1:1 with pivotal-cards but there are some TODOs still outstanding - the current card make up looks a bit like this.

So basically follow the instructions on the project page and hopefully it should all work out. If it doesn't - FORK IT 'N FIX IT or complain and I'll fix it for you :)

Some other points worth noting,

Currently tested on Chrome 25 (OSX)
Could do with some basic tests around it
Currently no markdown support for descriptions
Story points use the Trello Scrum Chrome Extension convention of (POINTS) at the start of the card name/title. If you use that plugin then good for you, if not you can still make use of the points convention
Tasks are derived from the first checklist on the card

Eg. Play 2.1 + Scala + Guice + GlobalSettings#getControllerInstance

2012-12-18T00:00:00+00:00

TL;DR Here is some sample code of how to use Play 2.1s GlobalSettings#getControllerInstance feature with Google Guice.

I've had the chance to take Play 2.1 RC 1 out for a spin recently and in a bid to make my project a bit more testable I decided to go ahead and give dependency injection a bit of a spin again. While things like the cake pattern and general dynamic composition are alright I've never been happy with the code that I produce using them. So I decided to give Guice a blast as it seemed very much aligned with how I approached DI in the .NET world.

My main need was to create instances of controllers and given Plays appraoch in the past (singleton objects for controllers) 2.1 new GlobalSettings#getControllerInstance feature was what I needed.

First things first we need to add a project dependency to Guice and while we could just add the Guice dependencies directly I went with a library that offered slightly neater syntax in Scala - SSE-Guice. In short this means instead of writing this sort of noisy code

bind(classOf[Service]).to(classOf[ServiceImpl]).in(classOf[Singleton])

We get to write it like this,

bind[Service].to[ServiceImpl].in[Singleton]

So lets add the reference to the Build.scala file (assuming we just generated a our Play project) for sse-guice

val appDependencies = Seq(
  jdbc,
  anorm,

  // Add your project dependencies here,
  "com.tzavellas" % "sse-guice" % "0.7.0"
)

Next up we need to modify the Application controller a bit

It needs to take a dependency
It needs to bo be instantiable (e.g. not an object - this might be doable but the default approach in Guice seems to conflict with Plays approach to defining an instantiable controller)

So we want to go from this,

object Application extends Controller {
  def index = Action {
    Ok(views.html.index("Some Message"))
  }
}

To this,

class Application @Inject()(val messeger: Messeger) extends Controller {
  def index = Action {
    Ok(views.html.index(messeger.getMessage))
  }
}

A few things of note here

We use the @Inject() attribute here to mark this constructor as our default one (need by Guice to satisfy constructor injection)
Application is now a class. Small change (a Levenshtein Distance of 6 even!) big difference. Rather than having a singleton we now have something we can construct when we want (even in tests) and set it up really simply. Construction and lifecycle can be handled via our DI library easily.
We are passing in some sort of dependency - in this case it's a simple string barfer (Messeger is a trait) and the impl looks like this

trait Messeger {
  def getMessage : String
}

object MessegerImpl extends Messeger {
  def getMessage = "The Best Super Message"
}

Then we need to create our Guice module that will wire up our dependencies,

import com.tzavellas.sse.guice.ScalaModule

class SimpleModule extends ScalaModule{
  def configure() {
    bind[Messeger].toInstance(MessegerImpl)
  }
}

The ScalaModule declaration is a Scala-fied version of Guices AbstractModule with some helper and whatnot. Guice applies some common sense to wiring so we don't need to declare each controller type here etc.

Finally we need to start the DI mechanism and provide a way to instantiate controllers. We do this via the Play feature of GlobalSettings. In our app package we just put a Global object and set it up as needed

object Global extends GlobalSettings {

  private lazy val injector = Guice.createInjector(new SimpleModule)

  override def getControllerInstance[A](controllerClass: Class[A]) = {
    injector.getInstance(controllerClass)
  }
}

We use a lazy val to instantiate the injector with our SimpleModule and override the getControllerInstance method of our GlobalSettings class to use Guices injector.

Oh one last thing. We need to tell Play what controllers we want to use this feature (it's not an all or nothing thing which I guess is good). We do this by marking the route declaration with an @ in the routes file. So it becomes this (notice the @)

# Home page
GET     /     @controllers.Application.index

Running the app gives us exactly what we expect but why stop there? We need to test this stuff right? Cool. Testing is made easier - we can simply make use of the various helpers in Play like FakeApplication and FakeRequest,

class ApplicationSpec extends Specification {
  "Using FakeApplication" should { 
    "get the default message" in {
      running(FakeApplication()) {
        val home = route(FakeRequest(GET, "/")).get
        contentAsString(home) must contain ("The Best Super Message")
      }
    }
  }
}

Or we can create a custom Global object with a FakeApplication

class ApplicationSpec extends Specification {

  object DummyMessenger extends Messeger {
    def getMessage = "Dummy Message"
  }

  "Using FakeApplication" should {

    object DummyGlobal extends play.api.GlobalSettings {
      override def getControllerInstance[A](c: Class[A]) = {
        new Application(DummyMessenger).asInstanceOf[A]
      }
    }

    "get the an injected message" in {
      running(FakeApplication(withGlobal = Some(DummyGlobal))) {
        val home = route(FakeRequest(GET, "/")).get
        contentAsString(home) must contain ("Dummy Message")
      }
    }
  }
}

And even lighter we can just test the controller as if it was just another class,

class ApplicationSpec extends Specification {

  object DummyMessenger extends Messeger {
    def getMessage = "Dummy Message"
  }

  "Using direct controller testing" should {
    "return the dummy message" in {
      val controller = new Application(DummyMessenger)
      val result = controller.index()(FakeRequest())
      contentAsString(result) must contain ("Dummy Message")
    }
  }
}

Hopefully this gives you a good starter for using the new Play 2.1 getContollerInstance feature along with Guice. As above you can find the code for this post on Ye 'Ole Github

Neo4J Talk: Using Graphs to Analyse Public Spending on International Development

2012-12-12T00:00:00+00:00

Better late than ever, right? So a few weeks ago I presented a bit of a case study on my use of Neo4J in a UK government project focused on increasing transparency around how the UK disburses foreign aid. This post is a collection of all the useful resources mentioned in the talk.

Plenty of acronyms were thrown about and here are the useful links to some of the key ones.

GDS (Government Digital Service)
DFID (Department for International Development)
IATI (International Aid Transparency Initiative) - Registry and Standard
OIPA (Open IATI Parser and API) - Open Aid Site and Source

MongoDB Basics

2012-12-06T00:00:00+00:00

Neo4J: A Case Study

2012-11-28T00:00:00+00:00

Vertical vs Horizontal Thinking

2012-11-17T00:00:00+00:00

I'm not quite sure were this ramble is going to lead, it's been a while since I've felt like writing something that hasn't been clearly defined by my half conscious brain but lets take the journey anyway shall we?

This is going to be loosely related to agility, not necessarily the “agile method or process” but more simply about adapting to change and embracing transparency in a software project. More often than not this can be simply referred to as “common sense” and it's a great thing.

But I digress,

In a vertical world you deliver features by implementing vertical spikes through each layer of the system architecture. It doesn't have to be right, but it does need to be good enough for now. Sure it may not deliver the best user experience or maybe there are more HTTP requests or database calls than necessary but it's useable. Its shippable.

In the horizontal world layers of the architecture are tackled by (possibly pseudo) specialists and delivered en masse. This is very typical of the Big Design Upfront, Plan Based, Waterfall approach to delivery but its visible in a lot of projects in various guises and it's rather natural to many people.

Now, on the surface, getting specialists to deliver what they know best and then smash them altogether actually sounds great. You know your DB person is going to produce a wonderful hyper-normalised schema for you, your UI/UX person will deliver a gorgeous mockup of the site and your middle layer app people will deliver the best truly ReSTful service layer known to man. But then you spend an insane amount of time (or many many little periods of time) doing the actual integration and making this vision a reality. The testing, the regressions, the edge cases the performance hits and sacrifices through integrating perfect works of horizontal art. Best case you get it done eventually, worst case someone else gets it done by layering hack upon hack at integration points just to get it working.

Now imagine your DB person gets eaten by a badger, or your UI person decides they've had enough and goes to live in a free-love commune and drink the spiked kool-aid? I've overly dramatised the Bus Factor here but the point is still made. You've lost siloed knowledge forever and you need to spend time building it up again, and time and quality slip.

Finally - projects that deliver horizontally are, more often than not, projects that have limited customer/stakeholder visibility. Sometimes even less for end-users. So delivering a mockup of the UI and a DB schema that can be exported as a nice UML diagram is enough to satisfy people that work is on-going and going well. Even if it isn't. It's not a lie but it is a false impression, and it's an impression that doesn't work for long especially if you have shorter release cycles with ongoing customer interaction. A page of beautiful buttons that don't do anything will create an impression that you are nearly done and can easily generate disappointment at subsequent demos. Is it worth it?

Don't get me wrong it is very possible to successfully deliver software in this manner, on time and on budget but so many things must fall into place and all the stars must be aligned that it's a rather big risk, but a risk that people seem to ignore.

So I'm saying vertical is better and there are many reasons for that and I'll touch on some of them here but there is one very fundamental reason it's better. Working and thinking vertically allows you to create a shippable product early. It's not all done, far from it. It probably looks like ass as well but still it's usable enough to get the job done, right? Imagine using a new product that looked amazing but only had 3 working features and the rest of the buttons and knobs didn't do anything. Wow factor is for kids and sales men.

Why else is vertical thinking better?

For one everyone on the team works across all layers of the solution. You don't have huge silos of knowledge contained in a single brain of some crazy bus magnet. Sure you may involve specialists to ensure you're not doing it totally wrong but at least you'd be working WITH them and picking up parts of the vast knowledge they may have.

By delivering something “good enough for now” you actually reduce waste. True you may re-write a few things to get it right but you haven't spent hours crafting perfection only to tear it apart. Even better the first iteration may make users realise - “Actually you know what? That super whizzy button thing - we don't need it”. Waterfall attempts to “manage change” because change in waterfall is scary expensive. Embrace it early and often and it much less costly.

Finally, the solution evolves rather than being dragged into existence from a 189 page document of business rules and textual assumptions. This allows you to experiment and try things, throw them away or discover a better way of doing things. You can adapt the solution at anytime to suit the changing nature of the environment it lives in.

Vertical thinking is a proven pattern in many other aspects of the software world. TDD for example. Rather than writing reams of code and testing it manually later, you create a solution bit by bit and adapt it fearlessly as you go. UI designers never just bang out one design and leave it there. Smaller feedback loops are essential to flow and success and vertical thinking gives you this. Break the habit of wowing people and replace it with the habit of delivering - it's a better, longer lasting feeling of win.

Technology Techsmology

2012-11-05T00:00:00+00:00

There is an old adage,

Projects don't fail because of technology decisions

The younger me would have got all uppity and defensive when he heard this statement. As a developer/architect type whose main goal is to make key technology decisions on a project (not to mention as a person who likes to grandiously consider themselves a craftsman) this does seem rather belittling. Are you telling me all my decisions are fairly irrelevant? I'll just stay in bed then shall I?

But you know what? The statement is also completely true.

But hey, wait - do you want to know something else? Yes? Good.

The world of technology is not black and white, projects aren't either a success or a failure, it's simply not a binary system. Projects may not fail, but they could be late. They could be well over budget. They could have code bases so toxic that you need to hire contractors to do the work because no one wants to touch it. They could be so overly laden in patterns and complex architecture that even small changes take weeks or months to implement (and who foots the bill for that?).

Technology decisions can indirectly ruin the morale of your staff, muddy the relationship with your customers and generate really high turnover of staff in your company (which may be a good fit for some companies but you can never foster excellence if you don't nurture talent).

This statement can also be used as a weapon - a weapon to excuse bad decisions and hold back change (both good and bad, in short it stiffles learning). People cling to technologies that they used in the past, for fear of more pain with other technologies. They shoehorn their existing skillset into problem domains that aren't a good fit. When this happens, at the extreme you end up with specialists that simply can't adapt to shifts in technology fast enough.

So yeah, projects don't fail because of technology decisions. But you know what - if your dentist turned round to you with an evil grin and a rusty chisel and Maslow's Hammer citing - “No surgery ever went wrong because of a lack of anesthetic” - you're not likely to get in to that chair and open wide. And even if you did (maybe, you're drunk, maybe people keep telling you this dentist is the best, whatever) the experience would be painful, recovery time would be longer and subsequent treatments would probably be more painful. A rather shambling metaphor I admit but I write what my brain dictates - I have not choice in the matter.

Finally, I fully accept that many of these decisions are out of our control. Customers, especially big ones, generally have the final say, they've potentially invested a lot of time on a certain stack and have a lot of legacy (read: code that still works) solutions in play. True, but one of our goals is to at least inform these people of the alternatives and let them make an informed decision - maybe not today but soon enough the cost of developing and maintaining new systems built on out-of-support JDKs will come under scrutiny and they'll need to consider alternatives, alternatives that you've already enlightened them about.

Neo4J Talk in November

2012-11-02T00:00:00+00:00

Its been rather quiet around here of late, truth be told I've been rather busy with my work (this peak is a rather large one). Being busy for me usually implies I'm not getting bored on cookie cutter, by the numbers web apps, being busy means I'm doing new interesting stuff. I've been doing a bit of work with the UK Government, specifically DFID (Department for International Developement) around the nobel goal of transaprency and open data. The project involves interrogating a lot of highly connected data in weird and wonderful ways which can mean only one thing - Graph Databases. We tried the relational database route early on and it was causing too much pain to get the data we wanted,

So having recently been enlightened by Jim Webbers talk on Neo4J I decided to try the Graph Database appraoch and it paid off, in spades. Then one humble brag on Twitter later and I get asked to present a case study on Neo4J at the London User Group - and I'm stoked. This is the first talk I've ever given that I don't have to pretend to know what I'm talking about - awesome.

If you're in London on the 28th of November come along and see how I've (probably incorrectly) used Neo4J.

CASE STUDY: using graphs to analyse public spending on international development
Wednesday, November 28, 2012
6:30 PM To 7:30 PM

Skills Matter
The Skills Matter eXchange
116-120 Goswell Road
London EC1V7DP

RSVP

Learning Resources for Scala, Play! and Mongo

2012-10-06T00:00:00+01:00

I've been asked a lot recently for some resources on various technologies, namely Scala, Play! (2.0) and Mongo so I thought I'd share the wealth (so to speak).

Got any good resources that I haven't listed here? Let me know.

Scala

Official Site
Screencast
Various Links from the official site
Scalatron - learn Scala by programming a game
Scala School - Twitters learning resource
Scala for the Impatient - excellent “lite” version of a great book.
Scala Videos
Coursera Course - Scala course on Coursera by Martin Odersky. Only good for five weeks or so but during that time anyone can sign up and download the video lectures and materials.

Play!

Official Site
Official Docs - Excellent resource
Scala Code Samples - Some nice examples from the official Github repo.
Scala, Play! and Mongo - Blog post on writing a simple app using all those technologies.
Getting Started with Play! 2, Scala and Squeryl
Play! 2 Getting Started

Mongo

Official Website
Try Mongo - A Tiny MongoDB Browser Shell (mini tutorial included)
Little Book of Mongo (epub) - Book about Mongo
Mongly - Various tutorials and essays on MongoDB
Presentation

StackMob: Baas meets PaaS (Lightning Talk)

2012-09-13T00:00:00+01:00

StackMob Lightning Talk

2012-09-13T00:00:00+01:00

So I finally found an opportunity to deliver a quick lightning talk on StackMob at our monthly CodeSlice sessions in work. Knocked it up today over lunch and presented it tonight. Would like to pull this one out into a more in depth and interactive look… just waiting for someone to ask :)

Securely Serving Static Files on Heroku

2012-08-21T00:00:00+01:00

More than once I've had a need to host what is essentially static content on Heroku. For example when building a simple internal web app for my company that used an existing API or Parse. Invariably in this situation I have also needed to secure this app - nothing to drastic, no need for multiple user accounts or roles or any such nonsense (we generally run our non-essential systems on the honour system). Basic auth is more than enough.

So, static content plus basic auth. Heroku itself doesn't offer basic auth as an option (why would it?) and so you'd need to roll it into your app. Once I hosted my static stuff inside a Scala/Play! app, once a Sinatra app and the other a Rails app - variety is the spice of life. But each time I did it I felt a little dirty - it was noticeably slower serving this content from within an app and it seemed rather wasteful. So, in a bid to stamp out technical debt, I've ripped out all those web frameworks an replaced them with good old Apache.

Now anyone with any knowledge of Apache will already be able to deduce the steps required here - but I want to note it for posterity, for myself, when I forget, in about a week.

BuildPack

First things first you'll want to get your hands on a custom Heroku BuildPack - these are the things that prepare your app instance with all the software and support it needs to run.

I recommend you fork and clone the heroku-buildpack-static buildpack available from pearkes on GitHub.

.htpassword

Next you need to generate your .htpasswd file that will serve as your store for your Basic Auth credentials. The two simplest ways to generate one of these is to either use htaccesstools.com's htpasswd generator or generate on via the command line.

The simplest command to generate one is this,

htpasswd -cb <password_file> <username> <password>

For example,

htpasswd -cb .htpasswd james password

Will generate a file in the current directory called .htpasswd (the standard name for these files) with a single entry of username = james and password = password.

Updating the BuildPack

Either run the above command in the heroku-buildpack-static/conf folder or move your .htpasswd file into the that folder.

Next up you want to configure apache to authenticate against that generate password file. Adding the following lines to the httpd.conf file in the heroku-buildpack-static/conf will lock all assets under your apps site down,

    AuthType      Basic
    AuthName      "Authentication Required"
    AuthUserFile  "/app/apache/conf/.htpasswd"
    Require       valid-user

This block should be added to the configuration section starting <Directory /> i.e.

  <Directory />
      Options FollowSymLinks
      AllowOverride None

      AuthType      Basic
      AuthName      "Authentication Required"
      AuthUserFile  "/app/apache/conf/.htpasswd"
      Require       valid-user

      Order deny,allow
      Deny from all
  </Directory>

You'll notice the AuthUserFile points to the correct absolute path for our custom .htpasswd file. If you called it anything else please update this line accordingly.

Commit and push that to your forked repo.

Using the BuildPack

Finally we need to tell Heroku to use the custom buildpack. If you have yet to create an app then you can specify the buildpack during creation,

heroku create <app name> --buildpack <url to your repo>

If you have created you app already you can add the buildpack through an additional config setting

heroku config:add BUILDPACK_URL=<url to your repo>

Push your new or updated site to Heroku and watch in awe as your site is that bit more secure.

Dependencies in JavaScript: Constructor, Setter or Global

2012-08-21T00:00:00+01:00

There has been an interesting conversation on Twitter over the last number of hours between @derickbailey and a number of other people and it all started with this tweet,

anyone have links to articles on why setter injection is evil? /cc @jbogard @jeremydmiller @jflanagan @chadmyers
— derickbailey (@derickbailey) August 20, 2012

The conversation has been around using DI and IoC in JavaScript (yes I know they are not one in the same, and I know a Container is not a necessary part of DI or IoC thank you very much). Simple answer is this - good patterns have a place in any language provided they aren't abused mercilessly. But lets get back to the discussion - why would you use constructor injection over setter injection? Is setter injection evil? Obviously no strategy is actually evil per-say - just used in the wrong place at the wrong time. So lets go back to the first question - constructor injection vs. setter injection.

Constructor Injection or Setter Injection

The simplest answer to this was one I gave @derickbailey earlier,

@derickbailey resolve mandatory dependenciesvia constructor injection, optional dependencies via setter. This is a common convention.
— James Hughes (@kouphax) August 21, 2012

This little bit of knowledge I've had since living down in the guts of Spring MVC about 5 years ago and it makes a lot of sense regardless of how those dependencies are getting in there.

Fail Early

When your code goes into an invalid state you want to fail as quickly as possible, this makes debugging much easier and prevents an avalanche of unexpected behaviour. Using constructor injection (and asserting the existence of dependencies) gives you this ability.

    var MyThingy = function(requiredA, requiredB){
        if(!requiredA) throw "Missing Dependency"   
        if(!requiredB) throw "Missing Dependency"

        // rest of my code
    }

    MyThingy.prototype.doAThing = function(){
        return this.requiredA.magic() + this.requiredB.beepboop();
    }

    var thing = new MyThing(); // FAIL FAIL FAIL
    thing.doAThing();

If you tried to achieve the same thing with setter injection you would be failing much later in the proceedings,

    var MyThingy = function(){}

    MyThingy.prototype.setRequiredA = function(requiredA){
        this.requiredA = requiredA;
    }

    MyThingy.prototype.setRequiredB = function(requiredB){
        this.requiredB = requiredB;
    }

    MyThingy.prototype.doAThing = function(){
        if(!this.requiredA) throw "Missing Dependency"  
        if(!this.requiredB) throw "Missing Dependency"

        return this.requiredA.magic() + this.requiredB.beepboop();
    }

    var thing = new MyThing(); 
    thing.doAThing(); // FAIL FAIL FAIL

Now imagine that the last two lines are miles apart in code-lines, you've gone and lost all context when debugging. Sure in this trivial example it would be fairly easy to resolve this but if you've gone and lost the plot and created a heavily nested object graph you'll be crying before they day is out.

Now setter injection does have it's place - for optional dependencies,

    var MyThingy = function(requiredA, requiredB){
        if(!requiredA) throw "Missing Dependency"   
        if(!requiredB) throw "Missing Dependency"

        // rest of my code
    }

    MyThingy.prototype.setOptionalC = function(optionalC){
        this.optionalC = optionalC;
    }

    MyThingy.prototype.doAThing = function(){
        if(this.optionalC) optionalC("doing a thing...")
        return this.requiredA.magic() + this.requiredB.beepboop();
    }

    var thing = new MyThing(a,b);

    thing.setOptionalC(function(s) { console.log(s) });
    thing.doAThing(); // logs "doing a thing..."

So the extension of the rule is that

Anything injected via setter injection needs to be either defaulted initially or checked for existence before use.

Readability

By following this convention, heck by following any agreed convention, you get better visibility of the expected behaviour of your code. You know what the object needs to get the job done. That feels like a poor argument but I think it still warrants a mention here.

Over Engineering and Deep Graphs

Obviously if you've over-designed your classes or it has grown out of control this approach becomes difficult to manage. I've seen something akin to this in some projects,

    var x = new CoordinatorOfAllTheThings(a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p....)

Someone has decided to make every bit of functionality it's own little class or module and so the dependency graph has become incredibly broad. In fact this might suggest they are creating a deep graph as well and simply passing the dependencies down the chain. If you have a lot of dependencies then there is something wrong with the object you are creating.

For fine grained, inter-object communication dependency injection is fine but when you are scaling up to more coarse, inter-module or component communication an evented or message based approach is almost always a better option.

    // rest of previous code

    MyThingy.prototype.doAThing = function(){
        EventStream.trigger("doneathing");
    }

    var EventStream {
        trigger: function(){ /* ... */ }
        on: function() { /* ... */ }
    }

    var OtherThing = function(requiredD){
        EventStream.on("doneathing", requiredD)
    }

    var thing = new MyThingy(a,b);
    var other = new OtherThing(function(){ console.log("stuff done"); });

    thing.doAThing(); // logs "stuff done"

This is a rather contrived example but it should server a point.

The Global Issue

You'll notice the EventStream object in the code above is global, you'll also notice I have skipped part of this posts title (… or Global). Lets come to that now. It is possible to achieve the same results as constructor/setter injection using global scope,

    var MyThingy = function(){
        if(!global.requiredA) throw "Missing Dependency"    
        if(!global.requiredB) throw "Missing Dependency"

        // rest of my code
    }

    MyThingy.prototype.doAThing = function(){
        return global.requiredA.magic() + global.requiredB.beepboop();
    }

    var thing = new MyThing(); // FAIL FAIL FAIL
    thing.doAThing();

So rather than inject the necessary dependencies in we are relying on the fact they exist in global scope. This works fine in some situations. The EventStream object above is a global hub that can be used throughout the application. I'm ok with that. The risk of global scope is that it's easy for objects to be redefined by other actors in your system so existence or behaviour is never guaranteed. So use sparingly.

Moptional

The other alternative approach would be to make everything Moptional. That is, anything mandatory should be instantiated with a default and provide setter injection for changing default behaviour.

    var MyThingy = function(){
        this.requiredA = new DefaultRequiredA();
        this.requiredB = new DefaultRequiredB();

        // rest of my code
    }

    MyThingy.prototype.setRequiredA = function(requiredA){
        this.requiredA = requiredA;
    }

    MyThingy.prototype.setRequiredB = function(requiredB){
        this.requiredB = requiredB;
    }

    MyThingy.prototype.doAThing = function(){
        return this.requiredA.magic() + this.requiredB.beepboop();
    }

    var thing = new MyThing();
    this.setRequiredB(new CustomRequiredB())
    thing.doAThing();

You kind of get the best of worlds here - not having to worry about default behaviour but have the ability to override this (for example in testing). But then you need to think about this. Why are you providing this sort of strategy? Are you simply hiding all implementation for an object but providing setters and getter to simply aid testing? If that's the case - STOP. Your code should be testable but you should not change your code to simply aid testing. Perhaps its time to go back and re-think your strategy? Also, for testing - it's entirely possible, given the dynamic nature of JavaScript, to redefine the internal dependencies prior to them being instantiated in your object anyway. Don't add features or behaviour that you don't actually need to deliver the solution.

Wrap Up

This was playing over and over on my ride into work this morning (I cycle I have a lot of thinking time) and I wanted to get it out there. Hopefully be useful to people asking some questions on this topic.

Oh and IoC Containers in JavaScript…… don't.

My $0.02

Backend as a Service - Part One

2012-08-08T00:00:00+01:00

I recently wrote an article for CloudSpring (a part of the SitePoint family) around what you can expect and what you should think about when going for one of the “Backend as a Service” offerings on the market.

The article is now live.

CloudSpring: Backend as a Service Part 1

Part 2, the one where I look at whats actually out there, will be ready within the next week.

Fear of Code

2012-08-05T00:00:00+01:00

More silly wishy washy nonsense - take what you will.

Recently Thomas Fuchs has this to say on twitter,

As a programmer, you should be afraid of code, and eliminate as much as possible.
— Thomas Fuchs (@thomasfuchs) August 2, 2012

Its great, I love this stuff and it got me thinking and I thought why not put my thoughts up here, right? After all this is what this place is all about.

Rather than describe the emotion as fear (“be afraid of code”) i'd posit that, as a programmer, you should be respectful of code. Rather than eliminate as much as possible you should conserve it as much as possible - don't write it in the first place.

A while back I posted something similar on Twitter - I can't find the tweet right now but it went a little something like this,

Adding code is great, removing code is greater but not writing the code in the first place is greatest

As a developer it is very easy to fall into the trap of creating some sort of highly reusable complex masterpiece that is going to change the way we write code forever. But down that road, madness lies. Desigining too much, adding too many features, creating too many abstractions, handling every single edge case, writing too many tests - all this stuff is just extra complexity, extra code that simply muddies the solution and makes it harder for someone to understand the solution. More code doesn't solve the problem faster, more code doesn't make things easier, more code doesn't help.

In other words - writing too much code, regardless of quality is just a selfish act. That goes for 3rd party code too.

Quit it.

expect.kt - Testing Library for Kotlin

2012-07-25T00:00:00+01:00

In a bid to delve into the language a bit further than a rake of tiny console apps I decided to do something “real” with Kotlin. With that in mind - welcome expect.kt.

It started purely as a learning venture but I think there is a certain usefulness in the library so its probably worth sharing :). Now it's worth noting that kotlin already has a number of testing statements that you can achieve a lot of this stuff with - this library gives you a few things over and above these statements

Alternative syntax. Testing is quite a personal thing and some people like to write things in different ways.
Descriptive assertions. Some would say expect(2).toBePositive() reads better than assertTrue(2 > 0) or expect(2 > 0) { true }. Again its all about taste, and variety is the spice of life.
Chained assertions. See later

Rather than some campaign to replace the inbuilt expectations and assertions this library intended to complement them.

So what is expect.kt?

Expect.kt is a set of (growing) assertions/expectations that you can use in your kotlin based tests. It gives you a number of ways to assert your expectations and gives you quite descriptive methods in which to do it.

Expect Syntax

The expect syntax is the default way to assert things,

package tests

import org.junit.Test as test
import kotlin.expectations.*

class StringExpectationTests {
    test fun testHelloWorld () {
        expect("Hello World").toStartWith("Hell")
    }
}

Most of that is boilerplate JUnit testy things but the key line is

expect("Hello World").toStartWith("Hell")

Reads quite nicely IMHO.

Should Syntax

The should syntax offers a more fluent syntax if you want to call it that, if we wanted to write the same test above using the should syntax we could do this,

"Hello World".should.startWith("Hell")

So rather than wrap your target with an expect you get and extension function to fluently assert it.

Chaining

Sometimes making a single assertion on a result isn't enough and rather than write assertTrue(...) multiple times you can use extpect.kt's chaining support.

expect("Hello World").toStartWith("Hell").and.toEndWith("rld")

Or, with the should syntax,

"Hello World".should.startWith("Hell").and.endWith("rld")

It's a bit more readable than expect after expect, right?

So thats it for now - there are a number of assertions implemented already on the useful types (Strings, Ints, Doubles, Dates, Booleans for example) and there are more planned on the way. Currently you'll be wanting to build from source (or copy/paste what you need).

Finally - A shout out to .NETs FluentAssertions where a lot of the assertions found their origin!

expect.kt.

Kotlin: Nullable Extensions

2012-07-18T00:00:00+01:00

Haskell doesn't have if statements - that blew my mind the first time my old Scala mentor told me it. ifs just don't work with a strong function approach. Plus you know what - ifs are rather ugly especially when you need to wrap ALL THE THINGS in a null check. Scala has a type called Option. An Option is essentially a collection of none or one instances of a type. If everything returned an Option nothing would be null and you don't need to do any null checks (they are much more powerful than I am making out but for now this is all that is necessary).

Kotlin doesn't have the Option type but it does have two things that allow you to act like it does,

Nullable types - e.g. String vs String? , and,
Nullable Extension Functions

Remember the brief definition of an Option - it's a list of 0 or 1 instances of a particualr type and as such we can treat it a bit like a list. Now once we get functional with our badselves this makes null handling unnecessary. We can use all those nice little functional methods that you get with collections - map, forEach, filter, fold etc.

This means you're less inclined to use ifs and, more importantly, less inclined to use mutable variables which is great for building performant, scalable soltions.

Lets take a really contrived example to show you what I mean. OImagine this bit of code….

   val auth = authenticate(username, password)
   var view : View = null

   if (auth == null){
        view = views.html.login("Invalid Username or Password")
   }else{
        view = views.html.index(auth)
   }

   return view

We want to authenticate a user and return a certain view. Now yes we could refactor this down into something more bitsize but this is a very common state to find code - so bare with me for demonstration purposes.

authenticate returns a user if the username and password was correct otherwise it returns null. With our nullable extensions (by importing kotlin.nullable.*) we can reduce this into something more Scala-like,

return authenticate(username, password).map {
    views.html.index(it)
} ?: views.html.login("Invalid Username or Password")

So what we have done here is basically take an object (the user), if it exists, and transform it to another object which we return. Otherwise we return something different. This is much simpler and avoids having to create a mutable var (yes we could have avoided that in the other example but in many cases its very difficult to achieve this). In fact I am not even a fan of the elvis operator there (?:) and have a Scala-like syntax pull request open for getOrElse. A small syntactic change that I think allows you create a much neater, chainable block of code.

Thats only the tip of the iceberg on Nullable Extensions - those of you with a functional mind will be able to put these collection-like extensions to great use I reckon. Not quite Scalas Option type but good enough at providing the common features for me.

Kotlin: Extension Functions

2012-07-16T00:00:00+01:00

In any language (that supports the concept) extension functions are nothing more than syntactic sugar. Instead of writing,

StringUtils.encrypt(mystring, "salt")

Extension functions allow you to write,

mystring.encrypt("salt")

Once you start moving into the world of chaining things get much cleaner.

encrypted = StringUtils.encrypt(mystring, "salt")
encoded = StringUtils.encode(encrypted, "UTF-8")

or worse,

StringUtils.encode(StringUtils.encrypt(mystring, "salt"), "UTF-8")

I've seen this done a few times, it happens. But with sugary sweet extension functions (Extension Methods in C#, Implicit Conversions in Scala) you could just do this,

mystring.encrypt("salt").encode("UTF-8")

Much nicer.

Kotlin, unlike crusty old Java, supports extension functions. Here is how you'd implement the methods above

fun String.encrypt(salt: String): String {
   return StringBuffer(this).append(salt)?.reverse().toString()
}

fun String.encode(encoding: String) : ByteArray {
    return this.getBytes(encoding)
}

And we can use these, as you'd expect, like so,

fun main(args: Array<String>) {
    val mystring = "james"
    val encoded = mystring.encrypt("salt").encode("UTF-8")
}

So what identified those functions as Extension Functions? Simple - the prefixing of the method name with the type String.encode. No need to create implicit wrappers (Scala), no need to create loads of static classes (C#). And yes it's possible to use generics in these methods as well,

fun <T> T?.getOrElse(t: T) : T {
    return this ?: t
}

This can be applied to any nullable type.

Literal Extension Functions

An interesting little feature that Kotlin has that makes it a bit different is the use of function literal extension functions. Basically where you can declare a function as a literal (a lambda method if you will) you can also make that literal an extension function,

So we could take our methods we wrote above and bring them right into our main

fun main(args: Array<String>) {
    val encrypt = { String.(salt: String) -> StringBuffer(this).append(salt)?.reverse().toString()}
    val encode = { String.(encoding: String) -> this.getBytes(encoding) }

    val mystring = "james"
    val encoded = mystring.encrypt("salt").encode("UTF-8")
}

This may seem quite unnecessary at first glance but it become quite powerful when creating DSLs - as demonstrated in the docs around the Groovy Style Builders

So Kotlin has extension functions that don't require a load of boilerplate (C#) or rather odd implicit syntax (Scala) - cool, right?

Kotlin: Here's What I Think (For Now)

2012-07-15T00:00:00+01:00

Before I go shooting my mouth off here - a word of warning - I haven't really done anything with Kotlin. I've read the docs, played with the Kotlin 101 samples and written a few small console type apps. So take what you want from this post.

Want to hear something zany? There actually are people - real living people, with a fully working brain, many much smarter than me - that are “happy” with Java.

Seriously.

I made a move from Java to .NET about 5 years ago and have dipped back in a few times over that period. Trying new languages is a sure fire way, for some at least, to make you realise Java is not a language that makes coding fun, or productive. Java put me right of the JVM. Any language that makes woking with collections (something you'll do alot) so long winded and noisy deserves to be shunned. But this isn't a Java rant - the JVM is great but it's just marketed badly because of Java.

But all the JVM-hate that Java instilled in me 5 years ago; the last 6 months of working with Scala has replaced with love. So I've been looking around the JVM world and discovered Kotlin a new JVM based language from JetBrains. Its much closer to Java than what Scala or Clojure is (intentionally).

One main thing that Kotlin brings to the table is pragmatism. Without trying to belittle Kotlin - it's almost like CoffeeScript for Java (yep kind of like what Xtend is. Kotlin removes all those annoying necessities in Java that make your code verbose (checked exceptions, semi-colons, null reference checks etc.). It also adds things that make your life much easier (extension methods, functional collection manipulation etc.).

When you write Ruby for the first time you notice that many things just work out like you'd expect, the syntax is quite natural. The same cannot be said for Java - there is just way too much boilerplate. Kotlin helps reduce that boilerplate. So, by extension, it could be said that Kotlin makes you more productive. A person who knows Java will find Kotlin no challenge to start using - the syntax is nicely aligned, just without the noise.

Many people, when trying to get their team to adopt Scala, use the “you can use Scala like Java til you get used to it” mantra. I don't agree with that. Academically it's true but the minute you start working with other peoples Scala code - you've just gotta know Scala and when they have a slew of Implicits thrown in your Scala as Java stuff goes out the window. Kotlin, on the other hand, has some of the nice functional patterns from Scala but none of the “magic-to-a-newcomer” features that can make grown men weep. Now the Kotlin docs themselves even go as far as stating

If you are happy with Scala, you probably don't need Kotlin.

But I think they are selling themselves short - I think plenty of people use Scala but could easily use Kotlin in its place and find themselves in a better place (easier upskilling, less cryptic codebase).

Anyway this is a bit of a ramble, what I'm saying is - Kotlin has some really rather nice features (Groovy Like DSL Builders, Pattern Matching, the when expression, lambdas, Kotlin to JavaScript compilation(!) etc.) and people happy with either Java OR Scala should give it a go.

Azure Website Workflow for Bosses

2012-07-12T00:00:00+01:00

So consider my indefinite hiatus suspended definitely. I suck at quitting! But we wont dive into the whys and wherefores around that now.

I've a confession to make, the “new” Azure, I like it. Yeah I do, s'nice. I like the way it blends PaaS with IaaS (though I do feel that adding 1st class node.js and PHP support is a bit of a tacked on marketing ploy). So you dont have the “Add-On” model you get from Appharbor and Heroku but thats fine because this blending of “as a Services” gives you an alternate approach. For a start you can just use the external services without them having to be “Add-Ons”. Sure you lose out on the nice automatic integration points for managing your services but it's not the end of the world and what happens when you want something that isn't available as an Add-On or worse not available as a cloudy SaaS thing? Well I guess you need to go off to EC2 or similar and host your own (assuming you want to stick with the cloudy infrastructure). But with Azure you also get another option - you want to use Mongo or some huge enterprisey platform that isn't SaaSified? Stick it on an Azure VM. Everything managed under one cloud provider. Thats such a nice thing to have at your disposal.

But thats not the point of this post. Most posts out there cover a workflow for Azure WebSites that make use of the portal to provision new sites (and then usually git to deploy) but that's weak sauce (the portal part at least - gits still aces). No, no no - You want hyper-productivity, you want automated provisioning, you want to be hip; node.js hip; and you want to feel like a boss hanging out on your command line while other “lesser people” click stuff with a silly little rodent. I just read your mind, didn't I? Well then - you got that with Azure.

Setting Up

First things first you need to install a few things.

Installing node.js + NPM

Download

The tools are built and deployed in node via NPM, the node package manager so just run the one click installer and you'll be all setup.

Installing Azure CLI Tools

Install these via NPM so fire up your terminal/command prompt/whatever and type

npm install azure -g

Then let NPM install all the dependencies and what not (the -g option just tells NPM to install the tools globally so they are accessible from the command line)

Adding your account

Next up you need to tell azure what account to use so fire this command into you command line

azure account download

You'll then be taken to the Azure website and it should (assuming you're logged in already) download a publishsettings file. Next up you need to import this file into your azure toolchain.

azure account import YOUR_DOWNLOADED_FILE.publishsettings

After some scrolling text you'll be all set up and ready to deploy. You'll be asked to delete the file you downloaded - probably best to do this :)

Creating the app

OK then lets create an app - what we create is irrelevant here so lets just create the default ASP.NET MVC website and use that as our sample app. Remeber though, if you're a cutting edge awesome-addict to switch from .NET 4.5 to 4 or else you'll get some issues when deploying your site to Azure.

UPDATE : The next few steps can be condensed, thanks to the feedback from Glenn Block (@gblock),
@kouphax oh dude, you don't need all those steps! Do “azure site create my site –git” It will create the repo for you and add the remote!
— Glenn Block (@gblock) July 16, 2012
This sets up your git repo during creation of the site, adds the remote endpoint and even generates a .gitignore file (which you need to edit yourelf for .NET projects. WIN!!!!

Anyway…. on with the old post.

Once you've created you app and saved it then you'll want to intialise an empty repo at the root of the solution,

git init

Then we need to create a site on Azure we can push to.

Creating a new site

Back to the command line now,

azure site create SITE_NAME

If we execute this, again at the root of our solution, it will do a number of things,

Validate the request (site name availability and what not)
Create a new site on Azure
Add a new git remote to your .git\config file

Pushing site

As I've said the last command actually added a remote repo to our git configuration so if we do the usual gitty stuff (you'll want to, for neatness sake, set up your .gitignore but we can skip this for brevity),

git add -A
git commit -m "Boring commit message"

Now we push,

git push azure master

Done!

Viewing your site

You could just browse to your new site but thats just not hip enough, hell no. Instead lets launch it from the command line…

azure site browse

That will launch our new site without having to touch a silly old, out of date rodent.

Wrapping up

Ok so thats the basic workflow for using CLI tools to manage Azure sites. You can do this with most of the Azure services (VMs, Certs, Cloud Services etc.) aswell.

So apart from making you look all hackery working in the terminal it does have other uses, specifically around the fact terminal command can be easily executed in a headless automated environment. Think of creating new sites as part of your CI's deployment pipeline, or as part of some disaster recovery process. The possibilities are endless… heck even write your own UI for managing sites or deploying new sites/VM/whatever!

So lets see -

CLI hackery coolness… ✓
Node.js hipster bragging rights… ✓
Azure website created and deployed with about 6 commands… ✓

Not bad for a few minutes work!

Technology in the Cloud

2012-07-12T00:00:00+01:00

The Cloud. As much as the term has been pummelled into meaningless marketing sputum by the guys in expensive suits and fake smiles it does exist and is distinct from a typical “throw all your stuff in a data center” setup.

The Cloud is distinct, as well, in terms of how you think about your solution architecture. The typical old school approach would be to just create big monoliths to process your data but that doesn't work out so well in the cloud. Of course the considerations for the cloud aren't new, hell no - things like SOA have been around for an age, but if you want to harness the benefits of the cloud as the internet intended you will be narrowing your options. No more just cobbling common bits together and crossing your fingers.

So fine - architecting for the cloud has some special considerations but thats not what I want to talk about - there are better people than me to cover that.

What I want to talk about is use of technology within that architecture. I've never been a fan of the one-size-fits-all-painful-or-not technology stack driven almost solely by a need to avoid unnecessary education of developers. And, now I feel the cloud is strengthening my view that a default stack is more trouble than it's worth. More importantly it's really adding momentum to the whole polyglot architecture, or simply using the right tools for the job.

Let me explain. Any default stack, by definition, needs to cater to many user cases and as such brings a certain amount of sacrifice with it. Sacrifices come in many forms but usually in performance, memory footprint and/or verbose configuration. In the cloud you are, in essence, in a Pay-As-You-Go model, every clock cycle and every bit of storage costs. Now that heavy ORM with its less than ideal queries and slow relationship mapping is starting to cost you money EVERY request. In fact, it's probably backed by that storage heavy relational database for all your non-relational data. Same for that rather large web framework you've got there…. every time to deal with a spike and scale that badboy out and you're having to use medium instances rather than small. That SOAP based webservice that requires triple the bandwidth to service a request… ugh you get the point.

In the cloud the default stack can easily bleed money.

I guess this is less about the default stack and more about just using the right tools to get the job done in the most effective manner - afterall you're paying for this stuff now. You kind of were before but in such a coarse grained manner it didn't matter - it does now.

In summary - the cloud has started to make technology decisions more accountable and we need to ensure that those decisions aren't costing our stakeholders more money than necessary.

PS.

I'm not going to sit here and preach about the which specific technologies to use but come on - if your storing Session State in a Oracle database, switch to Riak, or Redis. If you're building a nice scalable API then use something like Scala which promotes immutable state and concurrency out of the box over something like vanilla Java (or perhaps just a better framework Spring-WS vs Dropwizard for example). JSON over XML or a binary format (Protobuf for example) for machine to machine communication. A small node.js web site over ASP.NET Webforms for simple sites. The list goes on. That is to say consider this advice against the other factors driving technical decisions - dont JUST go for the smallest, lightest tools because it MIGHT be cheaper. Do the research.

Finally, perhaps you've got another IT team needing to support this new solution? Bring them along this journey too, educate them as you educate yourself, dont just throw the finished thing over the wall with a 1 week handover and a pat on the back.

Don't be afraid - it's a super fun world we live in!

Quitsies, Well Sort Of

2012-07-03T00:00:00+01:00

You know when you start to question why you write these things it's probably time to quit, or at least take a break.

~ me, just there now

This more of an FYI to anyone who may read this blog than a horrible diatribe about how I am wasting my life with meaningless exercises or technologies I'll never get to use to a bunch of people that don't really care, what would be the point? Plus - it's probably not even true.

So rather than pottering on about cool and interesting technologies that will make everyones (read, developers) life infinitely better 100% guaranteed I've decided to devote my time to,

Working on some startup-py type things that have been milling around the back of my head for some time, and,
Generally getting stuff done

Yep, like a hipster band, this little testament to bike-shedding is going on indefinite hiatus.

[Quick and Dirty, Super Ugly,] Starter for 10 - Dropwizard

2012-07-03T00:00:00+01:00

So once again I'm writing Java without a gun to my head, and once again I'm finding it enjoyable. Don't get me wrong Java as a language feels very long winded, old and cumbersome but the frameworks and stuff that exist around it actually make those issues, less prominent, so much so I think I could easily live with the noise that Java brings.

Anywho.

Dropwizard is a framework for creating very simple ReSTful Web Services in Java. Not just that but it also bundles some nice best practise in with it as well. Things like pluggable health checks, logging, configuration, content negotiation etc. And, because it's fairly lightweight its fast. Very fast.

In fact you can think of Dropwizard as a collection of pre-existing tools glued together with some simple features to create a cohesive stack for HTTP+JSON web services. You've got Jetty, Jersey, Jackson, Metrics, Logback, JDBI and more. Dropwizard give you the glue that binds these along with a simple pipeline that makes use of these technologies.

Simple Todo

I had intended to do something a little more substantial but I am about to make a small annoucemnet that has kind of effectivley stopped me expanding this app much further. So lets create a simple Todo App.

pom.xml

As with most Java projects lets start with the pom.xml which is effectively our project definition. I'll not show you my entire POM, at least not on the first date, but let me reveal the important parts.

Beause it's awesome I want to include WebJars so I add my repository,

    <repositories>
        <repository>
            <id>webjars</id>
            <url>http://webjars.github.com/m2</url>
        </repository>
    </repositories>

Next I add my dependencies,

Dropwizard Core which has everything you'll need for this
jQuery from the WebJar repository

    <dependencies>
        <dependency>
          <groupId>com.yammer.dropwizard</groupId>
          <artifactId>dropwizard-core</artifactId>
          <version>0.4.2</version>
        </dependency>
        <dependency>
          <groupId>com.jquery</groupId>
          <artifactId>jquery</artifactId>
          <version>1.7.2-1</version>
        </dependency>
    </dependencies>

I also add the shade plugin which will let me build a Fat Jar (a jar with all my dependencies and what not in it).

    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-shade-plugin</artifactId>
        <version>1.6</version>
        <configuration>
            <createDependencyReducedPom>true</createDependencyReducedPom>
            <filters>
                <filter>
                    <artifact>*:*</artifact>
                    <excludes>
                        <exclude>META-INF/*.SF</exclude>
                        <exclude>META-INF/*.DSA</exclude>
                        <exclude>META-INF/*.RSA</exclude>
                    </excludes>
                </filter>
            </filters>
        </configuration>
        <executions>
            <execution>
                <phase>package</phase>
                <goals>
                    <goal>shade</goal>
                </goals>
                <configuration>
                    <transformers>
                        <transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>
                        <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                            <mainClass>se.yobriefca.TodoService</mainClass>
                        </transformer>
                    </transformers>
                </configuration>
            </execution>
        </executions>
    </plugin>

Configuration

Dropwizard has the ability to map configuration options (from a YML or JSON file) into concrete classes that can be accessed by your services. So first I created a todo.yml at the root of the project (beside the pom.xml) with some basic configuration

http:
    rootPath: "/app/*"

This configuration tells Dropwizard that my services are located at a url starting with /app - eg /app/todo. This is necessary as I want to create an asset later that maps to the root url / that is the default of Dropwizard. At this point I haven't needed any of my own configuration but if I did I could create a POJO that maps to proeprties in this file. The official guide has more on this. For now I will create an empty Configuration class in case I want to extend it later (yeah I know YAGNI YAGNI KISS YAGNI - shutuppayourface!)

package se.yobriefca;

import com.yammer.dropwizard.config.Configuration;

public class TodoConfiguration extends Configuration {
}

Service

The service is the core class in our solution. It's the thing that has the main as an entry point. The thing that “set us up the resouces” and registers healthchecks and controls our service lifecycle. You'd think there would be loads of code here? Right? Wrong!

package se.yobriefca;

import com.yammer.dropwizard.Service;
import com.yammer.dropwizard.bundles.AssetsBundle;
import com.yammer.dropwizard.config.Environment;
import se.yobriefca.resources.TodoResource;

public class TodoService extends Service<TodoConfiguration> {
    public static void main(String[] args) throws Exception {
        new TodoService().run(args);
    }

    private TodoService() {
        super("todo");

        addBundle(new AssetsBundle("/assets", "/"));
        addBundle(new AssetsBundle("/public", "/public/"));
    }

    @Override
    protected void initialize(TodoConfiguration configuration, Environment environment) {
        environment.addResource(new TodoResource());
    }
}

So all services extend Service and have a Configuration type (FYI these config types can be nested so its not as restrictive as I first thought). Basically what we have is a main method that create an instance of our service and runs it. Upon creation we add two bundles to the service. A bundle is bascially a bit of functionality and in this case we create two AssetBundles which can be used to serve static content (embedded resources) upon request to a specific URL (think things like CSS, JavaScript, HTML etc.) You'll notice I am mapping 2 things bundles here and this is because I need to map to the WebJars directroy as well. So when I got to localhost/index.html it will match the url pattern in the first AssetsBundle and look for a file src/main/resources/assets/index.html.

Finally we have the initialize method that allows us to decare mutliple resources and healthchecks against our environment. We also get handed our configuration class we decalred in advance.

A bit about healthchecks

Healthchecks are little classes that perform some sort of test on a part of your solution. For example we could have a database connectivity check. These healthchecks are made available on the admin section that is bound to another port when your app starts.

Now I didn't define any for this example and for that I feel absolutely terrible. Seriously I kind of feel sick thinkging about it. And whats worse Dropwizard kindly reminds me everytime I start the app - using LOTS of exclamantion marks and CAPS!!! IRL you should really not follow my example here.

Resources

Resources are resources as they are identified in ReSTy things. For example a User is a resource or an Order etc. These things will respond to HTTP requests matched against the URL and the HTTP Method used. In my example I have defined a resource Todo that can be used to list, create and delete (I didn't need anything else for this).

@Path("/todos")
@Produces(MediaType.APPLICATION_JSON)
public class TodoResource {
    private static final ArrayList<Todo> todos = Lists.newArrayList();

    @GET
    public Collection<Todo> list() {
        return todos;
    }

    @POST
    public Todo add(@Valid Todo todo){
        todos.add(todo);
        return todo;
    }

    @DELETE
    @Path("/{id}")
    public Todo delete(@PathParam("id") final LongParam id){
        Todo todo = null;
        List<Todo> todoCopy = Lists.newArrayList(todos);

        todos.clear();

        // loop past all items in the list and replace the changed one
        for (Todo element: todoCopy) {
            if(element.getId() != id.get()){
                todos.add(element);
            }else{
                todo = element;
            }
        }

        return todo;
    }
}

Again not a great deal of code and what code that is there is fairly straightforward - some would say boilerplate. We use annotations to map our HTTP Methods @GET, @POST and @DELETE as well as a @Path(...) annotation to specify what url this resource resonds to. Another nice feature we can see annotated here is we get both validation (via the @Valid annotation which is based on Hibernates Validation framework) and JSON model binding via Jackson and model annotations (get to that in a minute).

For this simple demo I am storing a list of Todos in an ArrayList in memory (top of the class).

Model

The model is, bar all the annotations to enable serialisation, fairly POJO-like,

public class Todo {

    // Not So Universally Unique!
    private static final AtomicLong NSUUID = new AtomicLong();

    @JsonProperty
    private final Long id;

    @NotEmpty
    @JsonProperty
    private final String content;

    @JsonCreator
    public Todo(@JsonProperty("content") String content) {
        this.id = NSUUID.incrementAndGet();
        this.content = content;
    }

    public String getContent() {
        return content;
    }

    public Long getId(){
        return id;
    }

}

I've put this in more for completeness as there is little involved in this.

index.html

I am not going to create some elaborate over architected front end here - just a few lines of JavaScript (ignoring the rather large jQuery library included of course) and not styling.

<!DOCTYPE html>
<html>
  <head>
    <title>Demo</title>
  </head>
  <body>
    <div>
      <input type="text" id="task" /> <button id="addTask">Add Task</button>
    </div>
    <ul id="todos"></ul>
    <script type='text/javascript' src='/public/jquery.min.js'></script>
    <script>
      $(function(){
        // load and replace the list
        $.getJSON("/app/todos", function(todos){
          for(var i = 0; i < todos.length; i++){
            $("#todos").append(
              "<li><input type='checkbox' data-id='" + todos[i].id +"'/>" +
                todos[i].content +
              "</li>"
            )
          }
        });

        // manage adding a new task
        $("#addTask").click(function(){
          $.ajax({
            url:         "/app/todos",
            type:        "POST",
            data:        JSON.stringify({ content: $("#task").val() }),
            contentType: "application/json; charset=utf-8",
            dataType:    "json",
            success:     function(data, textStatus, jqXHR){
              $("#todos").append(
                "<li><input type='checkbox' data-id='" + data.id +"'/>" +
                  data.content +
                "</li>"
              )
            }
          })
        })

        $("#todos").delegate("input[type=checkbox]", "click", function(){
          var chk  = $(this),
          item = chk.parent("li"),
          id   = chk.data("id");

          $.ajax({
            url:         "/app/todos/" + id,
            type:        "DELETE",
            contentType: "application/json; charset=utf-8",
            dataType:    "json",
            success:     function(data, textStatus, jqXHR){
              if(data.id === id){
                item.css({"text-decoration": "line-through"});
                chk.remove();
              }
            }
          })
        })
      })
    </script>
  </body>
</html>

And thats it. Oh wait I also added a boot command that peforms the maven packing and starts the jar.

mvn package;java -jar target/todo-0.1.jar server todo.yml

Just run ./boot (assuming you've chmod'd the file to be executable) and you'll have, assuming I (or you) haven't made any mistakes, a Todo service running on port 8080 (with admin/diagnostics stuff on port 8081).

As always the example code is available on Github. Sorry for the rushed nature of this post, I'll hopefully keep tweaking the example on Github till it's a bit nicer - perhaps even with tests and comments (YEAH RIGHT!!!!)

In short - Dropwizard - simple ReST services, very little config, very nice.

Super Basic Trello API Wrapper for Scala and Play

2012-06-25T00:00:00+01:00

So I am currently doing a bit of work with using Trello as a kind of data store and decided to write a litle app in Play! (the Scala variety of course). There didn't appear to be a library out there to handle some of the basic Trello stuff so over the past 20 minutes I put one together.

import play.api.libs.ws.WS

case class Trello(key: String, token: String) {

  val host = "https://api.trello.com"

  def get(uri: String, query: (String,String)*) = request(uri, query:_*).get()
  def post(uri: String, query: (String,String)*) = request(uri, query:_*).post("")
  def put(uri: String, query: (String,String)*) = request(uri, query:_*).put("")
  def delete(uri: String, query: (String,String)*) = request(uri, query:_*).delete()

  private def request(uri: String, query: (String,String)*) = {
    WS.url(host + (uri.startsWith("/") match {
      case true => uri
      case false => "/" + uri
    })).withQueryString(query ++ Seq("key" -> key, "token" -> token): _*)
  }
}

Yep it's very basic and all but the get is untested (it's all I've needed so far). But in the spirit of shipping early this is a good start. The class makes use of Play!s uberflexible WS class and returns Promise[Request] so you can use it like so (just an example)

A simple API object to wrap the Trello class instance to load cards and map them into my expected objects

object Api {

  val api = Trello(KEY, TOKEN)

  implicit object CardFormat extends Format[Card] {
    def reads(json: JsValue): Card = Card(
      (json \ "name").as[String]
      (json \ "due").as[String]
    )
    def writes(card: Card): JsValue = throw new NotImplementedException()
  }

  def getPastTalks = {
    api.get("/1/lists/_____", "cards" -> "open", "card_fields" -> "desc,name,due").map { res =>
      (res.json \ "cards") match {
        case JsArray(cards) => cards.map(_.as[Card])
      }
    }
  }
}

And calling this bad boy from a controller.

object Application extends Controller {
  def index = Action {
    Async {
      Api.getPastTalks.map { talks =>
        Ok(views.html.index(talks))
      }
    }
  }
}

So - lots of work to do around this - I want to move away from a thin wrapper to something a bit more robust with strong classes for the different entites.

Also if you want to find out where to get the API keys etc. go read the decent API docs from Trello.

Two Hidden Gems in Play 2's Template Engine

2012-06-17T00:00:00+01:00

Poking around some Play 2 samples today I came across some little bits of sugar. I haven't seen mention of them in other places (they must be well hidden) but they are two very common things I've implemented in less elegant ways in the past. That was reason enough for me to throw a quick post up about them.

Prepare to have your minds blown. Well not blown - gently nudged probably.

String.when

"somestring".when(predicate: => Boolean) allows you conditionally spit out the value of the string it is called on (otherwise returning and empty string).

"returned_string".when(true)      // returns "returned_string"
"nonreturned_string".when(false)  // returns "" (empty string)

So in the context of views what is this good for? Lots of things but the most clever use for this little function is conditional css. Imagine you've got a block of HTML that represents a message area. These messages can be either good or bad and so we need to add the css class of message-bad depending on an argument passed in to the view. A very quick and dirty way of handling this would be as such

@(message: String, successful: Boolean)

<div class='message @if(!successful){ "message-bad" }'>
  @message
</div>

Grand, fine. It's a bit noisy but it works. when() makes this a bit neater IMHO.

@(message: String, successful: Boolean)

<div class='message @("message-bad".when(!successful))'>
  @message
</div>

Yep the line is the same length but it looks more like a single block of conditional code, it flows much better and, I think at least, is much more readable.

Date.format(“<date-format>”)

new java.util.Date().format(pattern: String) allows you to specify how a date should be formatted in the rendered HTML. It's essentially shorthand for the noise-fest that is SimpleDateFormat

new java.text.SimpleDateFormat(pattern).format(date)

In the past I've added transient properties to models for displaying the date, or written my own methods on those models. Both of those approaches should have had me taken out into a field and shot. format makes things much more straightforward,

@(importantDate: java.util.Date)

<p>
  @importantDate.format("dd-MM-yyyy")
</p>

And the output will be along the lines of “29-01-2013” or whatever the date was.

OK so neither of these are ground breaking or earth shattering (wait they mean the same thing really dont they???) but they are neat to enough to warrant a shout-out here. Anyone else have any little nuggets in Play 2 they want to share?

Agile Practices

2012-06-08T00:00:00+01:00

.NET On a Diet

2012-06-08T00:00:00+01:00

Git Basics

2012-06-08T00:00:00+01:00

MongoDB

2012-06-08T00:00:00+01:00

MonoTouch - C# + iOS = Good Times

2012-06-08T00:00:00+01:00

Ruby on Rails

2012-06-08T00:00:00+01:00

Ruby by Example

2012-06-08T00:00:00+01:00

Mobile, How Do I Develop Thee? Let Me Count the Ways (Long Version)

2012-06-07T00:00:00+01:00

Slides

Description

Mobile development is a bit like writing web apps back in the browser war days - full of decision anxiety, volatility and platform specific issues. There is no one true answer yet most people think there should be. This talk will cover the popular(ish) options from native all the way to web solutions (and all the mashup magic in-between). Oh yes and some opinion as well.

This is the longer more up to date version of the previous talk.

Monotouch: C# + iOS = Good Times

2012-06-07T00:00:00+01:00

Slides

Code

https://github.com/kouphax/monotouch-samples-ndc2012

Description

MonoTouch allows you to harness all those C# skills and most of those handy .NET/Mono libraries to create truly native apps for iOS with a sprinkle of cross-platform support. But why not just use objective-c you cry? Choice is nice, so is C# and so is the range of libraries available for mono!

In this talk I will dive in to what makes MonoTouch so compelling for .NET developers wanting to break into iOS development and even how these skills can be harnessed to create cross platform native applications for iOS, Android and WP7 through a shared codebase.

.NET on a Diet

2012-06-07T00:00:00+01:00

Slides

Description

There are plenty of framework options in .NET. We have the big mainstream web frameworks like ASP.NET WebForms and MVC, the ORM abstractions and DataMappers in the form of Entity Framework, NHibernate and iBatis and services such as WCF requiring large amounts of careful configuration to get right. Unfortunately these frameworks can get in the way, abstractions breakdown and leak and eventually we end up fighting against the frameworks limitations.

This session will take a look at the feature-fit lightweight alternatives and how they can be used to compose a technology stack that is cruft-free and fit for purpose.

Mobile, How Do I Develop Thee? Let Me Count the Ways (Long Version)

2012-06-06T00:00:00+01:00

5 Years

2012-05-26T00:00:00+01:00

So I am sitting here, here being London - 315(ish) miles away from my family, halfway through the NHS Hack Day and having a bit of a personal crisis. I often have these little episodes but this one has been languishing in my dusty old head for a good while - refusing to go away, nagging me every time I have a chance to ponder things. It's the same old thing - why am I doing any of this stuff I do? I don't generally get a great amount of opportunity in work to really stretch my creative urges. That sort of thing happens on my own time and therefore given my other responsibilities (my wife, family and lifes associated activities) is done under a fairly tight deadline. Add this to the fact I bore easily of things that aren't really benefiting people immediately - I tend to flit, easily, between little unfinished projects. But wait…. I did it again. You see back there, about 2 sentences ago I just sidelined my entire life. Thrown between two looming brackets I relegated my wife and family to a byline yet again. Oy vey.

And this brings me, neatly enough, to the point of this entire ramble.

Five years ago I married my awesome wife and in that time I've done a heap of things - relocated twice, had two kids bought a house, got promoted, pissed everyone off, seen a few countries and bought/traded three cars (which get smaller every time oddly enough). And through all this hopping around my wife has been the one true constant. She thinks, most of the time, I don't care about her - after all I'm in London participating in a hackathon on our 5th wedding anniversary because I stupidly didn't put two and two together and notice the clash. So yeah it may damn well seem like she comes in a close second to my hobby/career stuff (you know the stuff I already mentioned was pulling into crisis mode). But it's not true. I can't help the fact I am “emotionally retarded”, as my sister once called it, but perhaps once in a while I really should let her know that she means more than she thinks she does. And here it is. A little bit of emotional letting if you will.

Dear Emma - happy anniversary, I hope we have plenty more, thank you for putting up with me, you're aces.

Starter for 10 - Scala, Play 2 and Mongo

2012-05-08T00:00:00+01:00

This post is going to cover the whole “getting up an running” for a simple Scala stack - namely Scala, Play 2 and Mongo. 2012 has been the year of the polyglot for me. I've been working on projects with .NET, Node.js, Ruby and Scala in the mix. I've seen how Rails can really boost developer productivity (compared to the likes of ASP.NET MVC or other, less opinionated, frameworks) but I must say - In terms of developer productivity, at least for me, nothing has come close to the Scala/Play/Mongo combo. I hadn't touched functional programming since SML in university but I found Scala allowed me to express myself in a very terse manner. Combine that with Play and its straightforward, uncomplicated approach to building web apps and Mongo with its schemaless nature then its productivity++ all the way.

It's worth pointing out right away that James Ward already has a similar post and a (currently Java only) tutorial. These are much better but they dont cover the Mongo/Caabah/Salat side of things (not that it is particularly difficult) so at least I've got a leg to stand on.

Installing

Versions used in this post

Scala (2.9.1)

Play (2.0.1)

Mongo (2.0.4)

I'm going to assume that you are capable of installing software (by following basic instructions) so I won't waste your time covering this. Here are some links to kick you off,

Scala
Play 2 (it just goes on your PATH)
Mongo

Alternatively if you are on OSX - Homebrew has got everything you need at the time of putting this together.

Generating your Application

Play is a command line tool and can be used to generate your basic app skeleton,

play new <project name>

Just fill in the project name and you will be guided through the basic generation of the project, e.g.

→ play new sampleapp                                              
       _            _ 
 _ __ | | __ _ _  _| |
| '_ \| |/ _' | || |_|
|  __/|_|\____|\__ (_)
|_|            |__/ 

play! 2.0.1, http://www.playframework.org

The new application will be created in /Users/kouphax/Projects/temp/sampleapp

What is the application name? 
> sampleapp

Which template do you want to use for this new application? 

  1 - Create a simple Scala application
  2 - Create a simple Java application
  3 - Create an empty project

> 1

OK, application sampleapp is created.

Have fun!

Indeed - fun you shall have.

Dependencies

Working with Mongo directly is all well and good but it can be made a bit simpler with a few dependencies. Namely Casbah and Salat. Casbah is the official Scala Toolkit for MongoDB and Salat allows you to map to and from the generic Mongo object classes into more concrete case classes.

To add the dependencies you need to update the Build.scala file in the generated project directory. Firstly you need to update the appDependencies to create the dependency on the new two libraries,

val appDependencies = Seq(
  "com.mongodb.casbah" %% "casbah" % "2.1.5-1",
  "com.novus" %% "salat-core" % "0.0.8-SNAPSHOT"
)

Then you'll need to add the resolvers to the main project declaration,

 val main = PlayProject(appName, appVersion, appDependencies, mainLang = SCALA).settings
   resolvers ++= Seq(
     "repo.novus snaps" at "http://repo.novus.com/snapshots/")
 )

UPDATE: Since this article is a bit old but still getting plenty of hits I have noticed that people are having issues resolving dependencies on salat and casbah - this is because of a reporsitory change. Simple fix just add the following line to the resolvers Seq above,

"casbah" at "https://oss.sonatype.org/content/groups/scala-tools/"

This should be enough to get you going with the rest of this article however there will be some major changes expected in Scala 2.10 that may well fundamentally alter the need to use Salat etc. Be warned.

And thats the project set up with all its dependencies ready to hack on. So lets drive a spike through this stack and see what it looks like shall we? Yes why not, tallyho old bean!

The Model & Data Access

First things first lets create our model. So we are going to write a very basic registration app. People “register” on the site, for fun or something, I dunno as our stakeholders - I just write the code.

Our model is super simple,

case class Registration(
  username: String, 
  password: String, 
  confirm:  String, 
  realName: String
)

Now to the interesting part. To persist this in a Mongo data store we need to make use of the two libraries we imported previously,

import com.mongodb.casbah.Imports._
import com.novus.salat._
import com.novus.salat.global._

object Registrations {
  val registrations = MongoConnection()("sampleapp")("registrations")

  def all = registrations.map(grater[Registration].asObject(_)).toList
  def create(registration: Registration) {
    registrations += grater[Registration].asDBObject(registration)
  }
}

First things first we create a connection using the MongoConnection class and grabs the registrations collection from the sampleapp store. Now it's worth noting that provided Mongo is up and running we don't actually need to create either the store or the collection - the act of acting on a collection is enough to create both.

Next up I defined two methods all and create.

all simply pulls out all the collection data using Casbah, performs a map over the collection (which is a collection of MongoDBObject/DBObjects) and uses the grater object provided by Salat to map from these generic objects to our Registration case class.
create simply adds an element (cast from a Registration class to an acceptable DBObject) to the collection.

Now isn't that a nice terse data access layer? Yes it is. You want to make changes? Go ahead - the fear of change is gone or much reduced compared to the typical approach.

Controllers

Next up we want to add a register controller and update the existing Application controller.

object Application extends Controller {
  def index = Action { implicit request =>
    Ok(views.html.index(Registrations.all))
  }
}

The only difference here is the Registrations.all so we can list the registrations in the UI. Lets jump over the the register controller

object Register extends Controller {
  def registrationForm = Form(
    mapping(
      "username" -> nonEmptyText,
      "password" -> nonEmptyText,
      "confirm" -> nonEmptyText,
      "realName" -> text
    )(Registration.apply)(Registration.unapply)
      verifying("Passwords must match", fields => fields match {
        case Registration(_, password, confirmation, _) => password.equals(confirmation)
      })
  )

  def index = Action { implicit request =>
    Ok(views.html.register(registrationForm))
  }

  def register = Action { implicit request =>
    registrationForm.bindFromRequest.fold(
      form => BadRequest(views.html.register(form)),
      registration => {
        Registrations.create(registration)
        Redirect(routes.Application.index()).flashing("message" -> "User Registered!")
      }
    )
  }
}

OK thats a lot to take in so lets break it down a bit.

The Form

def registrationForm = Form(
  mapping(
    "username" -> nonEmptyText,
    "password" -> nonEmptyText,
    "confirm" -> nonEmptyText,
    "realName" -> text
  )(Registration.apply)(Registration.unapply)
    verifying("Passwords must match", fields => fields match {
      case Registration(_, password, confirmation, _) => password.equals(confirmation)
    })
)

The Form concept in Play is a bit like a ViewModel of sorts. It defines validation and mapping rules and allows you to pass a structured object between the controller and the view (inluding error information etc.). In fact you aren't even obliged to bind this to a class, they can exists as themselves. My example above shows you how to bind to and from our Registration class as well as some field and crossfield/global validation.

Model Binding

registrationForm.bindFromRequest.fold(
  form => BadRequest(views.html.register(form)),
  registration => {
    Registrations.create(registration)
    Redirect(routes.Application.index()).flashing(
      "message" -> "User Registered!"
    )
  }
)

This little functional approach allows us to bind a request to our registrationForm and react to invalid input. In the case of an invalid bind the first argument into fold is executed which returns a bad request with an instance of the form. In the case of the happy path we simply push our registration instance into the data store and redirect to the index action along with a flash message.

Flash

Flash is like a carefully curated session variable that exists only for the next request. This allows you to pass messages or some very transient data between requests. This is also accessible in the view which is handy.

Routes

Routes in Play are written into the config/routes file and this is used as a basis to generate reverse routes (this gives is us statically typed routes via the routes object).

# Routes
# This file defines all application routes (Higher priority routes first)
# ~~~~

# Home page
GET     /                           controllers.Application.index
GET     /register                   controllers.Register.index
POST    /register                   controllers.Register.register

# Map static resources from the /public folder to the /assets URL path
GET     /assets/*file               controllers.Assets.at(path="/public", file)

So I added two new routes for register that allows us to view and submit our registration form.

The Views

Right lets do something a little neat - remember I mentioned James Ward earlier? Well he curates a little project called webjars which allows us to add client side resources as managed dependencies to our project. So lets prettify our UI with a bit of Twitter Bootstrap love.

First thing we want to do is update our Build.scala file with webjars resolver and our bootstrap dependency

val appDependencies = Seq(
  "com.github.twitter" %  "bootstrap"  % "2.0.2",
  // other deps...
)

val main = PlayProject(appName, appVersion, appDependencies, mainLang = SCALA).settings(
  resolvers ++= Seq(
    "webjars"          at "http://webjars.github.com/m2",
    // other resolvers...
  )
)

Then in our main.scala.html we can reference the bootstrap assets in the normal way,

<link rel="stylesheet" media="screen" href="@routes.Assets.at("stylesheets/bootstrap.min.css")">

Index (index.scala.html)

Here we simply list the current registered people,

@(registrations: List[Registration])(implicit flash: Flash)
@main("Super Simple Sample") {
  @if(flash.data.contains("message")){
    <div class="alert alert-success">@flash.get("message")</div>
  }
  <a href="@routes.Register.index" class="btn btn-primary">Register</a>
  <table class="table table-bordered">
    <thead>
      <tr>
        <th>Username</th>
        <th>Real Name</th>
      </tr>
    </thead>
    <tbody>
      @registrations.map { registration => 
        <tr>
          <td>@registration.username</td>
          <td>@registration.realName</td>
        </tr>
      }
    </tbody>
  </table>
}

The interesting thing about Play 2 views is that they are just Scala. Yep neat. In fact any .NETters will feel quite at home as they are reminiscent of Razor views too.

Register (register.scala.html)

@(registrationForm: Form[models.Registration])(implicit flash: Flash)

@import play.api.i18n._
@import views.html.helper._

@input(field: Field, label: String, fieldType: Symbol = 'text) = {
  <div class="control-group @if(field.hasErrors) {error}">
    <label class="control-label" for="@field.id">@label</label>
    <div class="controls">
      <input type="@fieldType.name" value="@field.value" name="@field.id" />
      @if(field.hasErrors){
        <span class="help-inline">
          @Messages(field.error.head.message)
        </span>
      }
    </div>
  </div>
}

@main("Super Simple Sample") {
  @form(action = routes.Register.register, 'class -> "form-horizontal") {
    <fieldset>
      <legend>Registration</legend>
      @registrationForm.globalError.map { error => 
        <div class='row'>
          <div class="alert alert-error">@error.message</div>
        </div>
      }
      @input(registrationForm("name"), "Username")
      @input(registrationForm("password"), "Password", 'password)
      @input(registrationForm("confirm"), "Confirm Password", 'password)
      @input(registrationForm("realName"), "Real Name")
    </fieldset>
    <input type="submit" class="btn" value="Register"/>
  }
}

You can see from the source there that I've crafted my own helper function to keep things nice and DRY and avoid having to write out the twitter bootstrap required structure over and over.

Running and Wrap Up

Right about now the solution is done so with a simple play run you should be able to register and view current registrations. Excellent. If you want to skip everything and just get my code you can clone the Github Repo.

OK so it's not the most useful app in the world - that was never the intention. But look at the code - it's very terse and the time required to write this post was considerably more than the time required to implement the solution. Joy!

The Little Sacrifices

2012-04-29T00:00:00+01:00

Late night ramblings…

Productivity can plateau very quickly - especially in a technical process. No matter how good you get at the process or approach, if you keep doing the same thing you can only get so good at it or do it so fast. It's possible, however, by sacrificing some of your precious time to go beyond that plateau. There are things we, the developers, do as part of our development process that are so small and insignificant that we do them without thinking

Clearing down the values in LocalStorage when debugging a web app
Copying assets from one folder to another (aka the macgyver deploy)
Navigating to http://localhost:8000 or 9000 or some other port
Typing rake generate preview into the terminal about 20 times an hour
These are but a few things I've had to consider today alone

Generally these things are so small we'd just do them by hand, right? But if you take the time to automate these processes or even just refine them in some way it can do wonders for you productivity going forward.

For example the clearing of LocalStorage in Chrome - spent a few minutes writing a bookmarklet that you can execute with 1 click. The macgyver deploy? Write a rake/make/jake/psake/cake task for it. Better yet use Guard or Watchr and perform the deploy on save! Navigatin to various different localhost ports? Try my alfred script to minimise the keystrokes. rake generate preview - alias that bad boy to rgp! Save yourself those extra keystrokes - you might need them later.

Listen - specifics aren't important here. You'll have your own small repetitive tasks and you'll be able to find your own ways to automate, improve or refine them - but this is the point. You probably don't. At least not as often as you should. Losing a second here and there on one task means very little in the small. In the large, across many of these tasks, well thats a different story. It's hard to justify spending 10 or 20 minutes on something to automate a task that takes 5 seconds to run but even if the time doesn't repay for a while then the fact you have less of a cognitive shift between your primary task and this secondary one should allow you stay in the highly effective, productive mindset to get the job done.

So give it a go, even as a thought experiment - think about the habitual development tasks you do and how you could automate them - you could well suprise yourself (like I have been recently).

Infoshare 2012 Talk

2012-04-20T00:00:00+01:00

Slides

Resources

I mentioned a lot of technologies during my talk so here are the ones I mentioned

Web Frameworks

Design

Web Containers

Cross Platform

Server Platforms

Parse
Kinvey

Cloud Services

Testing & Debugging

Beta Testing

Comments

So how did it go? From my perspective it could have been better - I'm not sure why started “ummmmming” all the time - I had plenty to say (and I think I talked too fast as well). I just started in a semi-flustered state for reasons unknown. I seen a few decent comments on twitter so I guess it was fairly well received thats what matters. If anyone has any other observations, no matter how harsh, let me know.

One more note - Gdasnk is awesome - the technical people are so engaged and enthusiastic, the place itself is really interesting and I managed try my new favourite shot - Mad Dog. Thanks for the opportunity Gdasnk and Infoshare. Hopefully I can back here and spend more time in the city soon.

Na zdrowie

Mobile, How Do I Develop Thee? Let Me Count the Ways (Short Version)

2012-04-20T00:00:00+01:00

Strapping Young Lad v0.1.2 Released

2012-04-20T00:00:00+01:00

I have just released version 0.1.2 of Strapping Young Lad. Now we are getting to something that works a bit better across different platforms (now I just have to prove it to you). This release sees the inclusion of multiple token replacement. For example if I create a .ladconfig in the source repo with an array of tokens

token: ['__NAME__', '__NAMESPACE__', '__AUTHOR__']

The user will be prompted to specify the values for these tokens before the engine goes off and does the replacement. The __NAME__ token is a bit special - you still need to specify the project name as part of the command line call so if SYL come across this token in the the list of configured tokens it will allow you to default that value without having to type it again, e.g.

lad git@github.com:strapping-young-lad/Loam.git laddy

  Cloning git repository                OK
  Loading configuration                 OK
  Parsing tokens and stuff              
    name (laddy): 
    namespace: test.lad
    author: kouphax
                                        OK
  Processing files                      OK
  Processing directories                OK
  Moving project files                  OK

  Done processing 137 file(s)
  Done processing 22 directories(s)

Notice I didn't need to specify the name of the project again and then I was prompted for the second and third token values. Simple stuff.

Next up

So there are a few outstanding efforts to go in now. Namely push some more templates into the SYL repo and spin up a site that lets you search said templates and document all the little features of SYL. They will come in time.

This is the life!

Strapping Young Lad - Project Template Token Replacer and Bootstrapper

2012-04-17T00:00:00+01:00

Today I have released the super simple, rough-as-hell, barely MVP Strapping Young Lad(Source). It's fulfils a need I keep having but never really fixing.

Evelvator Pitch

SYL, or lad for short, will take a git repo, clone it and replace a bunch of tokens in it with the values you've supplied.

Say Wha?

This means you can create a bunch of base solution/project types for any language and SYL will simply do some basic file/folder renaming and file content replacing for a given token. For example doing the following,

lad /path/to/git/repo MyNewProject

Will do the following things,

Clone the repo at path/to/git/repo into a temporary folder
Remove the .git folder from the repo
Check for the existence of a .ladconfig in the freshly cloned repo
- If one exists it loads the config setting
- Otherwise it falls back to the defaults
Replace all instances of the configured token (eg. __NAME__) in all files, directories and file contents with the project name (in our case MyNewProject)
Copy the new folder over to your current working directory (./MyNewProject)

What this allows you to do is have a standard project template for pretty much anything (.NET, Ruby, Scala - listen I mean anything - if it a collection of folders and files in a git repo then you set) and create a new instance with a few keystrokes - saving you time and potential RSI.

SYL was inspired by WarmuP which is itself a gem but it requires you to be running .NET which for a lot of my requirement isn't going to cut it.

If you want to see what a typical template project looks like try Amir's Loam repo. This is a WarmuP project but works just fine. With SYL you can create a .ladconfig file to override some of the conventions - get the source README linked above.

Whats Next

Yep it's pretty damn basic right now but it satifies most of my needs right now. There are a few things I want to add for myself but I didn't release this for ME, I am pretty sure this will be of use to someone in some community in some shape or form. With that in mind here are some features I think would take this to the next level,

Specifiying multiple tokens e.g. __NAME__ and __NAMESPACE__ and __YEAR__ etc. etc.
Post processing actions (e.g. bundle install or npm install or sbt compile or something like that)
A catalog - I have a github organisation with no repos setup right now but this would be a brilliant place to hold a load of templates compatible with SYL, don't ya think? Then I could roll a site like rubygems or npmjs.org and make the projects searchable etc. If you build it, they will come. Maybe, who knows.

So if you like it - HIGHFIVE - if not - it's all good. Now go break it and criticise me.

So we'll criticise him, because he can take it…. [The Dark Knight, Approx.]

Scala - A Tragedy in Two Parts - Part 1

2012-04-13T00:00:00+01:00

The tragedy being we don't use it all the time!

This presentation is the first part in the 2 part series “Scala - A Tragedy in Two Parts”. In this presentation I go fast and dive into a range of Scala code snippets pointing out some of the weird and wonderful features of the language.

Recorded Session

Scala - A Tragedy in Two Parts - Part 1 - The Language from James Hughes on Vimeo.

Slides

Scala - A Tragedy in Two Parts

2012-04-12T00:00:00+01:00

Alfred Hack for Web Developers

2012-04-03T00:00:00+01:00

I've been a fan of Alfred for some time and use it to make pretty much everything a keystroke away. I've thrown a very small little extension that reduces the time to jump between console and newly started web app. Generally during development we need to run our app jump to localhost:PORT and make sure it's working. If, like me, you have a lot of different apps and platforms (Scala, Jekyll, Rails, Sinatra, Express to name a few) then PORT becomes the one thing you always need to type and the browsers auto predict is generally not that helpful in this situation.

Alfred to the rescue here, just create a script as shown below and then running alfred and typing l 9000 you can launch your default browser at http://localhost:9000. Very simple but saves me heaps of time at the minute.

Rails is not a gateway drug

2012-04-03T00:00:00+01:00

WARNING!!! - a negative opinion on Rails lies ahead. Everything here needs to be taken with an IMHO and, if you feel so inclined, tell me to go mind my own business.

I know I'm stepping into very dangerous territory here but I've come to the very solid conclusion that Rails, Ruby's heavily opinionated web framework, is not the gateway drug people claim. I've heard the claims that if you give Rails a try, coming from some other web stack on any other language, you'll fall in love with Ruby and Rails and write a big long blog post about how you are leaving .NET (or Java or whatever) behind. I really dont get it…. the only feeling that Rails leaves me with - having been using it in anger for about a month now - is frustration. But before you drive rusty nails into my hands and feet let me at least explain where I am coming from.

Previous attempts

I've been binging on Ruby for the last few months but this hasn't been my first time - it's been my only successful time but certianly not my first. A year previous I had given Ruby/Rails a shot and it never stuck (in fact not once but at least twice). Coming from a predominantly .NET/ASP.NET MVC background I decided the best approach would be to cut my teeth on a medium sized web based project and therefore jumped right into Rails. It only took a short time before the whole effort felt like a slog full of weird semi-magic behaviour. I gave up.

Doing things differently

This time around I decided to do things a little differently - rather than run with a web project I just tinkered with the language and eventually tried porting a .NET project over to Ruby. Fair bit of Ruby code and a small sinatra app later - it clicked. I got the whole Ruby love affair, it was lovely and I was three lines into my “F**k you .NET, you're worse than Java and I hate you and you smell” blog post (not factual!!) when I realised I needed to give Ruby more time to bed in and, out of fairness, I had to at least experience Rails.

Present Day

And with that I discovered that Rails had been my problem. I find it incredibly frustrating. I don't want to dive into bashing Rails, thats not my intent, - I'm sure people find it really productive - but it's not for me. So here is a very high level executive summary of the problems I've had with Rails

The Command Line Interface

The CLI stuff has just a little bit too many features and options that make it a difficult thing to approach without extensive research. When I watched some of the Railscasts I found myself going “wait, HOW did he do that?” more than once. Choice is good but surely Rails is supposed to be easy for the beginner? Yet I feel the default options are not the ones I would have picked. You know what - I want to be hand-held once in a while, I'm proud to admit that.

Too Much Magic

Rails is very heavily convention based but often there is simply too much convention and I've been left baffled a few times. Some of the convention is well documented and some of it less so. When a convention is not obvious it becomes magic and it really feels Rails has a lot of “magic”. Thats not something I want. To be honest I'd rather write the same 2/3 lines of boilerplate if it meant that, to a new developer, they could understand the convention better. Take this very trivial example,

class HomeController < ApplicationController
  def index
  end
end

And the same in ASP.NET MVC

public class HomeController: Controller
{
    public ActionResult Index()
    {
        return View();
    }
}

To me that one line return View() tell me that this action will return a View, and now I can infer the convention of home/index.cshtml that wee bit easier. When you start adding in more conventions, a little bit of extra code makes all the difference. Conventions don't scale unless clearly marked IMHO.

Bloatyness

When you generate scaffold in a Rails app, as a typical new developer would, you end up with a awful lot of files. If I generate a new entity for example this is what I am greeted with,

→ rails generate scaffold MyEntity name:String age:Int                         !6580
      invoke  active_record
      create    db/migrate/20120403130542_create_my_entities.rb
      create    app/models/my_entity.rb
      invoke    test_unit
      create      test/unit/my_entity_test.rb
      create      test/fixtures/my_entities.yml
       route  resources :my_entities
      invoke  scaffold_controller
      create    app/controllers/my_entities_controller.rb
      invoke    slim
      create      app/views/my_entities
      create      app/views/my_entities/index.html.slim
      create      app/views/my_entities/edit.html.slim
      create      app/views/my_entities/show.html.slim
      create      app/views/my_entities/new.html.slim
      create      app/views/my_entities/_form.html.slim
      invoke    test_unit
      create      test/functional/my_entities_controller_test.rb
      invoke    helper
      create      app/helpers/my_entities_helper.rb
      invoke      test_unit
      create        test/unit/helpers/my_entities_helper_test.rb
      invoke  assets
      invoke    coffee
      create      app/assets/javascripts/my_entities.js.coffee
      invoke    scss
      create      app/assets/stylesheets/my_entities.css.scss
      invoke  scss
      create    app/assets/stylesheets/scaffolds.css.scss

Don't get me wrong - it's nice to be given all these things for free, but it's ultimatley stuff I end up ripping out anyway. In .NET there is a running joke that the “Empty ASP.NET MVC Project” Template is anything but. To me this is the same issue except it's something that I'd have to clean up everytime I use the generate scaffold command. This seems worse to me.

Current Thoughts

I'm not sure were Rails is supposed to stand. I hear it's great for beginners or for big sites but I couldn't recommend it for either right now. I realise I should really give it more time before rejecting it entirely but I feel that would be more time wasted. Rails doesn't make me more productive, at least not right now… perhaps once I repeat the same steps over and over and they become natural I'll see a greater boost in productivity (Ruby on the other hand felt natural and great right away). Perhaps if I shun the generators and roll my own stuff then I'll be more productive - but then why not use another framework that comes without all the gubbins I don't need? Sinatra is nice and simple and I can build upon it rather than breakling it apart. Ramaze seems like a great “next step up” from Sinatra but without as much (perceived) bloat as Rails. I've also followed the recent Kickstarter debacle from Yehuda - and I agree with him and his mission.

So what I am trying to say is - if you are a person wanting to give the Ruby world a fair shake - DONT start on Rails. Start simpler and later, if you want, when you've been throughly sold on the Ruby way, try Rails to see what you think. Start with Ruby, port some code, write a Sinatra app, watch the Railscasts as they are amazing then consider immersing yourself in Rails.

Educate Me

Finally - educate me. I'm not some sort of oracle proclaiming the death of a framework that thousands of people love. I'm not going to make anyone stop and think “I've been doing wrong all my life - screw Rails”. If I'm wrong - tell me. If you think I need to give Rails another look - tell me why, tell me how. If you care - show me what I'm missing.

Setting the Selected Option in a Select with Selenium in Scala

2012-04-02T00:00:00+01:00

Almost a perfect bit of alliteration there in that title - right? Anyway I've been doing a bit of work with bare-metal Selenium stuff in Scala recently and one of the things that kept me stumped for a while was setting the selected option for a particular select element.

I looked around the interwebs and didn't really find anything - now I'm not saying it isn't out there, I am certain it is, but I couldn't find it. So I decided to document how I did it in case any lone sole is stuck in a similar situation…

  driver.findElement(By.id("year")).
    findElements(By.tagName("option")).
    get(2).
    setSelected()

So here I am simply finding the second option of the “year” select element and setting it selected. I know it looks obvious now but trust me I was scratching my head for an age on this one.

I hope it helps some one, eventually :)

Done Spoked at DevWeek

2012-03-28T00:00:00+01:00

So I made it through my talk at DevWeek which might sound a little odd but it took a whole bottle of cough syrup to do it. Not having been sick for most of the winter my body decided a day before DevWeek to go into shut down. I spent Tuesday in bed with very little voice. Thankfully the head colds hold on my vocal chords relented this morning and I think I managed to project as best I could.

So initial thoughts of how it went? I honestly think I'm getting better at this presenting thing so that must be a good thing, unless I was TERRIBLE before. The 2 main annoyances that have been raised thus far have been

1. Too Short

I did my usual “talk really fast and finish earlier than planned” thing I sometimes do. But there was plenty of discussion afterwards which I tought was interesting. FWIW when I present this to myself it takes longer. My internal monologue must be slower than the way I speak. Apologies to anyone that felt it was “too short”.

2. Not enough Visual Studio

I opted to play it safe end embed code into my slides rather than code live - I didn't go unnoticed and I had a few comments that “moar codez” would have been good. Totally agree.

Other Stuff

I opted to change my slide deck between submitting them for print and presenting. I did it out of desire to devlier a better, more structured, talk (my first set being quite short as I was going for a “free-form” type of presentation). Probably not the most professional approach to do this but at least I can say my heart was in the right place :) Here are offending articles BTW

Code that was presented is available, as always, in/on my Github Repo. Thanks to all who attended and any other feedback you have throw it my way so I can get better at this talking malarky.

Also thanks to the folks at DevWeek for the opportunity - hopefully you'll have me back at some point.

Behaviour Driven (Development|Design) in .NET

2012-03-28T00:00:00+01:00

rbenv and CodeRunner

2012-03-22T00:00:00+00:00

You know CodeRunner right? If not maybe you should go check it out. It's and aptly named little tool for running code snippets in various languages much like what LinqPad does for the .NET folks. I've been using it extensivley recently to test out little Ruby and Scala snippets. Thing is though - I hit a snag. By default CodeRunner will run the system ruby executable (1.8 in OSX) and I generally use rbenv along with version 1.9.whatever so some of my scripts started behaving a little… odd.

But hey it's an easy fix,

Open your CodeRunner Preferences
Select the Languages tab
Select Ruby in the Language List
Change the run command from ruby $filename to ~/.rbenv/shims/ruby $filename

Before

After

Blam - global rbenv version is now the goto version for CodeRunner. OK so it won't work with rbenv locals but I am sure you can tweak it to make it work (I haven't needed it so never looked).

Slim Generator for Octopress

2012-03-22T00:00:00+00:00

So I've been overhauling my web site, which is based on Octopress, lately and have had to jump into the working of Octopress/Jekyll. It's obviously not the most complicated system in the world but hey it was new to me.

Anyway my current setup features a lot of html based pages (the default markdown approach didn't fit due to styling needs) and it was getting rather noisy. So I wrote, as there didn't seem to be one out there, a Slim generator. And here it is, step back it's VERY COMPLEX….

module Jekyll
  require 'slim'
  class SlimConverter < Converter
    safe true
    priority :low

    def matches(ext)
      ext =~ /slim/i
    end

    def output_ext(ext)
      ".html"
    end

    def convert(content)
      begin
        Slim::Template.new { content }.render
      rescue StandardError => e
        puts "!!! SLIM Error: " + e.message
      end
    end
  end
end

Just drop this file (call it anything) into your plugins folder in Jekyll/Octopress and any file with the slim extension will use this converter to generate HTML. No more noisy HTML for me!

Tinkering with Spark: A Micro Web Framework for Java

2012-03-20T00:00:00+00:00

You can't call yourself a language these days without having your own Sinatra clone. Not even, it seems, if you are Java. I know - it sounds odd that Java, the language that turns XML into stacktraces, has a micro web framework of it's own - Spark. I'm well aware as of JRE 1.6 has a built in HttpServer class but there is such as thing as too close to the metal :) Also Sparks logo is fairly epic.

Spark's site has a great little piece about the “why” and that is what stuck with me. Especially this bit,

Its intention is to be used by Java developers that want or are required to develop in pure Java.

I know a few people who are “required” to develop in pure Java and anything that might make their lives easier would be welcomed. Being completely out of loop with Java since before Maven made an appearance I had a lot of catching up to do just to get the project running. In fact I went with SBT as it made things a lot easier for me and my mavenless brain. I did have to tinker with the dependencies in the ivy2 directory due to a known issue but if I can do it anyone interested in this can to - if not give me a shout.

App.java

A Spark app simply uses main as an entry point. Within the method you can call certain methods to set up routes and filters and whatnots that your app will respond to. For example

import static spark.Spark.*;
import spark.*;
import java.io.*;

public class App {

  public static void main(String[] args)  {

Standard Java stuff here, bringing in some of the necessary spark resources,

    before(new Filter("/") {
      @Override
      public void handle(Request request, Response response) {
        boolean authenticated = request.queryParams("password").equals("secret");
        if(!authenticated){
          halt(403, "Incorrect password, hacker alert, hacker alert!!!!");
        }
      }
    });

Spark allows us to define filters that run before and after requests. It is also possbile to restrict them to certain routes or simply catch all routes - for example my filter only matches the “/” route. A couple of other things are worth mentioning here,

The Request object gives you access to many things you would expect i.e. the query parameters. It gives you so much more than this but I'll leave the docs to describe this.
Just like in Sinatra it is possible to simply halt the request chain at any time. Here I am halting execution unless the request conforms to my very strict and highly secure authentication scheme.

    get(new Route("/") {
      @Override
      public Object handle(Request request, Response response) {

        // extract the name from the request
        String name = request.queryParams("name");

        // set the response type
        response.type("text/html");

        // return some html
        return "" +
          "<DOCTYPE html>" +
          "<html>" +
          "  <head>" +
          "  </head>" +
          "  <body>" +
          "    <h1>Hello " + name + ", Spark here.  Howrya?</h1>" +
          "  </body>" +
          "</html>";
      }
    });

  }
}

Finally I am defining a route (“/”) that responds to the GET verb and introspects the query parameters returning a very complex view. Routes can also be parameterized (/user/:name for example). Even given the slightly verbose nature of Java syntax this example seems clean enough (albeit a rather simple example).

SBT Build File

For the curious among you (you got this far so you must be slightly curious… and rather odd) the SBT file required to get this bad boy running is nice and simple,

resolvers += "Spark Repository" at "http://www.sparkjava.com/nexus/content/repositories/spark/"

libraryDependencies ++= Seq(
  "spark" % "spark"  % "0.9.9.3-SNAPSHOT" exclude("org.apache.commons", "commons-io")
)

A quick sbt run command and we are running a standalone Spark app (powered by an embedded Jetty server). Aces.

Mopping Up

OK so thats the basics of the framework but then again there really isn't much other stuff besides picking a port and redirecting. This means there is some things still missing that would really make this framework really stand out,

View rendering. Even if it is just plain HTML it would be a big leap forward (turns out an issue is already open too).
Static Content. Would be nice to define a rule for serving static content without having to define a route or filter manually
Session support. Again an issue and pull request is already available for this.

Good work perwendel keep it up :)

As always my code samples are available on Github.

Speaking at NDC Oslo

2012-03-19T00:00:00+00:00

Mike Cohn, Dan North, Robert C. Martin, Udi Dahan, Gojko Adzic, Billy Hollis, Laurent Bugnion, Venkat Subramaniam, Brad Wilson, Phil Haack, Rob Conery, Greg Young, Zach Holman….. and then me. So someone was drinking when deciding the line up for NDC Oslo right?

Seriously though I've been given one of the best opportunites of my career to talk alongside some of the shining lights of our industry at NDC Oslo so I better not drop the ball. Thank you to whoever gave me the opportunity. But hey if I mess up I've got another 2 shots at it… thats right I'm speaking not once, not twice but thrice.

Still blown away by this, if you can't tell - given the calibre of people talking this is going to be a highlight of the year for sure. Also it couldn't have come at a better time - there is so much I've wanted to say about things like the OSS world in .NET, Mono and mobile development. Now I've got the perfect opportunity.

Now whats this .NET thing I keep hearing about :)

sentimentalizer: A Ruby port of Sentan

2012-03-12T00:00:00+00:00

In a bid to be at least 1% less stupid I decided to jump into Ruby. Properly this time, no tinkering with Rails or watching a few videos. So the first thing I did was take @martinrue's Sentan project, fork it, made it run on mono (just because), ported it over to Ruby and renamed it sentimentalizer (but keeping all necessary attribution to Martins work in the README of course).<!– more –> I did this for two reasons,

I wanted something fairly meaty to actually port over to Ruby in an effort to get a more-than-superficial feel for the language
I might have a need for such a service in an upcoming hackathon (though the original .NET version would have been fine too)

This is in no way some sort of new project or intended for some production environment.

So what is it? sentamentalizer is a quick and dirty sentiment analysis tool. With it you can loosley class statements as either positive or negative (and get a breakdown of how that classification was derived). You “train” it with datasets for both negative and positive control statements and then feed it sentences you want analysed. At the minute the engine sits behind a super super super, did I say super already?, simple sinatra app that you submit statements to and it returns a simple JSON response with the sentiment result (negative, positive, neutral) and probability. If you want to train the bitch you've got to change the api.rb file or update the files in the data\positive and data\negative folders.

Plans? Yeah I might poke around some more, make into more of a standalone learning service or something (again another feature I might need soon anyway). But for now - feel free to review my shitey code Rubyists (I assume there are better ways to do things, standard appraoches that I'm not using etc.) and offer suggestions.

Once again thanks to @martinrue for doing all the hard-work on Sentan

Tinkering with minion.js

2012-03-08T00:00:00+00:00

Yay a technical post…

minion.js is a micro framework providing classical inheritance strategy for JavaScript plus many other goodies. It can be used in both browsers and node.js.<!– more –> Now I don't want to get caught up in any of this classical inheritance for JavaScript is an anti-pattern stuff so just take this framework for what it is - a decent way to define both client and server side models for you JavaScripts!

I've already said it has a host of goodies that can be useful for creating a nice flexible set of models and associated helpers. This includes,

Class and inheritance support
Modularity
A cross model pub/sub mechanism
Statics, Singletons, static methods and properties
Dependency management
Some other stuff I've yet to touch upon…

The code will more or less speak for itself here so lets dive in (the full suite of tests and sample node.js/express implementation can be found on my GitHub thingy).

Classes

One of the first things I did was try out the whole inheritence thing. I create a Fruit base class and provided a Strawberry implementation on top of it.

minion.define("fruit", {
  Fruit: minion.extend("minion.Class", {

    isInSeason: function(){
      return this.inSeason;
    }
  })
});

minion.define("fruit", {
  Strawberry: minion.extend("fruit.Fruit", {
    inSeason: true
  })
});

Using the Strawberry class is pretty damn simple. First thing you need to do is a one off simple configuration of minion,

minion.configure({
  classPath : "js"
});

This just tells minions dependency manager where to start looking for your class implementations. We can then start using the Strawberry class easily using minions require method

minion.require("fruit.Strawberry", function(Strawberry){
  expect(Strawberry).to.not.be(null);
});

Static Objects

Static objects are pre-initialised Singletons in minion.js and that makes a lot of sense. I created a Grocer static by simply extending another minion type Static.

minion.define("fruit", {
  Grocer: minion.extend("minion.Static", {

    init: function(){
      this.stock = 0;
      this.subscribe("purchase", this.buy);
    },

    sell: function(){
      this.stock--
    },

    buy: function(){
      this.stock++
    },

    checkLevels: function(){
      return this.stock;
    }
  })
});

Pretty unsuprising but minion will new up a shared instance of this class the first time it is called. You'll see a little hint of the pub/sub mechanism in the init method as well so lets jump on that.

Pub/Sub

So minion has a nice little pub/sub mechanism built right into the classes as well. So lets say a customer buys stuff from the grocer by publishing his/her request - sure beats just taking it without asking!!!

minion.define("fruit", {
  Customer: minion.extend("minion.Class", {
    buy: function(){
      this.publish("purchase")
    }
  })
});

Minion once again handles all the internal wiring up of this stuff and it just works. Nice.

The Rest

There is more to minion.js, I've just given you a very high level view but you should dive a bit deeper by looking at the official docs. There is a few bits of handy sugar sprinkled on the minion types (proxy, scoped setTimeout and setInterval). The pub/sub also goes a bit further provinding Notifications that allow a sort of async callback/response mechanism which can be handy.

Now I've never been a fan of these sorts of Class frameworks - I've never really seen the need but I must admit minion appeared at about the right time. I've been playing with a nice way of structuring mongoose Schemas/Classes and I think minion here might be a nice fit.

Anyway check it out. Yay a technical blog with more to come!

minion.js

Sample Code

Taking the Stairs

2012-03-06T00:00:00+00:00

Ya'll about ready for another silly analogy? I sure am….

I work on the 6th floor and recently decided to start taking the stairs. Mostly because I've let myself go and I really need to drop a few pounds and those stairs are a bit of a hard slog. But it's worth it. <!– more –> It's funny how much of a better understanding of the building layout I get by just putting in the extra effort and going up the stairs. The stairwell itself is pretty bland but I see extra doors, and I now know were many of doors could lead.

So the analogy… Taking the stairs is a bit like the whole software craftsmanship thing. Sure I could just take the prescribed route, the default stack so to speak, and as with the stairs I'd probably get where I was going for a lot of the time. But you know what? I'd not know much more than the average person. What if that lift was over capacity, out of order or just smelling of urine - I'd be able to manage just fine without getting stranded on a random floor wondering what to do next, if that door I never tried went were I wanted. Imagine the stress involved if I was already late for a meeting. Crickey!

So I put the extra effort in to understand things, and it's already given me a better perspective on things. It's shown me other options, the ability to decide if the what I am doing is a good approach or perhaps there is a quicker, better, healthier route.

How does that grab you?

I really need to get off this analogy trip I'm on FFS!

The Estimation 4x4

2012-02-12T00:00:00+00:00

This post is dedicated to one of the most influential managers I've ever had the pleasure to work with.

I'm of the opinion that the moment you start trying to apply complex mathematical rigour and time to estimation you've entered into a broken system. <!– more –> You're wasting time trying to protect yourself from finger pointing managers or getting a kicking from old school “us or them” lawyer types. None of that adds anything to the project except a big stick to beat people with and make sure they work themselves to death based a a random stab in the dark that is somehow made more realistic by the application if science. Ultimately though if the initial guesswork is wrong, and it's seldom on the nose, the science means sweet FA. So why bother? You're pleasing the wrong people. But then those people hold a lot of power. So as long as we can keep them happy with the minimum of effort life should be sweet.

The Answer

Ladies and gentlemen I bring you the Estimation 4x4 - guaranteed to knock those super science estimation techniques out of the park.

The Science Bit

Got a project to estimate? I've done your homework for you - 4 people, 4 weeks. BOOM! Mind Blown! Now get on with delivering that project bro. Oh wait it's a big ass project - 4 people, 4 months. Oh wait you're limited by deadlines and/or resourcing - adjust as needed (3 people, 5 weeks or 5 people, 3 weeks).

Balancing Act

Careful now, 9 women dont make a baby in 1 month so don't assume that scaling one side up to cater for the other will get the same results. Theres a balance that needs addressed. This is real science after all - repsect the rule and the rule will respect you.

You Gotta Be Kidding Me

Dont believe me? Try it out next time. Do your pseudo-scientific enterprise-ready finger in the air analysis. But hey see when that project is finished see how close the 4x4 would have brought you to the real result. I bet 9 times out of 10 it was as accurate as your real estimate, except you could have started much sooner….

#winning

Caveat Abstractor

2012-02-09T00:00:00+00:00

Ramblings from 30,000ft. The word abstraction is starting to sound odd.

Every time you create an abstraction there is a very good chance you've introduced unnecessary complexity into a solution. It should never be done alone - it should be a team decision. The goal of an abstraction is to simplify but in its untamed natural form an abstraction will only add complexity.

As programmers it's easy to fall into the trap whereby we want the code that we write to be the last time anyone ever has to write that code again. We dream of creating reusable works of art that ever other developer will use and never be concerned with the low level implementation ever again.

This is wrong and impossible. An anti-pattern even!

It baffles me that anyone would create an abstraction that they didn't have a need for at the time. It's wasteful and degrades the readability, grokability and all those other good “ilities” we use. Of course I say this like i don't do it myself but I'd be lying to you and myself.

An abstraction, by definition, is an intentional hiding of implementation and knowledge but surely understanding of these things will lead to a higher chance of success in a project? The person that created the abstraction has that understanding but it's like they dont want anyone else to know how it works. They're ready to take that secret to their grave.

When you start to abstract you need to remind yourself you are building a specific solution and not a framework (unless you are of course). Abstractions should be done only within the scope of the project and you should have a strong case to back up its creation (make the decision a team effort). This may sound like overhead but if you find it difficult to justify the creation odds are the abstraction is unnecessary.

Abstractions should not be grand, they should be light and convey their intent clearly by other people (pair programming and peer review will help weed out any verbose abstractions).

If you are creating an abstraction for anything other than DRY, odds are youre probably creating it for YAGNI. You'll start considering irrelevant use cases and having to cater for insane edge cases. This will happen even if you are taking a strong test driven approach - you'll concern youself with the workings of the abstraction rather then the problem you are solving and begin creating endless “what if” tests to cater for all those “0.00000001% chance of happening” edge cases. When this happens youre going to end up in mediocrity. Mediocre abstractions attract more abstraction. Even in a shared codebase bad abstractions create a certain amount of implied ownership to the person that created it. Inevitably someone will come along and create an abstraction around your abstraction (even if they have access to the original source). This in turn will likely become YAMA (Yet Another Mediocre Abstraction) attracting yet more abstraction…. You can guess where I am going with that one… Its abstractions all the way down and everytime you abstract you've decreased system comphension and likely destroyed another future developers soul.

In the same way guns dont kill people, people do - Abstraction dont kill projects, developers do. You've only got yourself to blame (been there done that, will be again). A nice simple abstraction, at the right time (e.g. When needed) can be expressive and helpful but too often we put the abstraction before the need.

So consider abstractions as “guilty until proven innocent” not the other way around. Solve YOUR problem - not every other problem, not until you need to.

On Craftmanship and Understanding, I Guess

2012-01-31T00:00:00+00:00

You can stand at the station and wait for the train. You know the one. It's the one that's always late, always packed with people, head down staring at the ground. Or, you can walk the tracks with your own two feet. When you walk the tracks you take in your surroundings, you understand the route and you see the alternatives. You wont beat the train everytime but when you walk the tracks you'll have better stories to tell when you get there.

Enterprise Scale

2012-01-26T00:00:00+00:00

Enterprise. What a broken, misued term. Its meant to sound big, huge even. I guess many years ago it used to mean big, huge, big business serious work.

But when you think about it, its none of those things really, not any more. <!– more –> Even the biggest multi-nationals entire enterprise backbone throughput is probably a small fraction of Lady Gagas Twitter feed. Enterprise is just that - one enterprise. Social is global, its all of us at anytime and that is so much bigger than some old enterprise. So if you try and pimp out your CV by using the term enterprise - the only people who are probably going to care are the managers and execs that think their little boring legacy system is unique and special… Do you really want to be sold that sort of job? All bytes are equal, some are more equal than others - Pah! Some are more mired in unnecessary abstraction, contracts and unread, out-of-date doucmentation but they are still bytes.

Using Parse in .NET and WP7

2012-01-05T00:00:00+00:00

UPDATE: Being completely wrong in assuming WP7 supports dynamic which apparently it doesn't the current build wont run in WP7. So another item on the list is a version that doesn't rely on dynamic I guess. Sorry for misleading anyone on that front - I did say it was rough and mostly untested right?

Parse is a site aimed at providing a simple service for pushing and pulling data on mobile devices. You can create applications and store your mobile data there, create users, provide logon/off mechanisms and even achieve push notifications. There are 2 ways to access Parse

Via its natively compiled binaries (on iOS and Android)
Via a its Rest API (for all non iOS/Android devices and desktops)

Now I wanted to try and create bindings for the iOS library so I could use it for a Monotouch application I've been playing with but truth be told the whole process confused the hell out of me. Thing was the REST API gave me everything I needed so I started recently to write a dynamic wrapper around the API. Currently built on .NET in Visual Studio (Mono on my list) with a few sanity tests it works well enough to put it out there incase anyone was wanting to do something similar and could extract value from it.

It's pretty early at the minute - in fact all you can do with this first spike is basic object CRUD. No querying yet, no special user management features etc. But they will come. So what could you use it for? Well a number of things,

WP7 Cloud Storage
Monotouch (and Monodroid) storage until someone smarter than me creates proper bindings to the actual iOS frameworks
It's an object store so why not use it to store data on any web app?
Just for tinkering.

It makes use of dynamic from .NET 4 so you can kind of pass it arbitrary stuff and get arbitrary stuff back (Parse is schemaless so this makes sense for me). It also means you wont have to create concrete classes for every single thing you want to store.

If you want to run the tests you'll need to sign up for Parse, create an app and update the consts in describe_Parsely to point to your new app (and authenticate).

Sample Uses

// create your parsley API
Parsley parsley = new Parsley(applicationId, masterKey);

// create new class
dynamic response = parsley.Create("MyClass", new { CoolProperty = 1  });

// do other cool stuff
parsley.Update("MyClass", response.objectId, new { CoolProperty = 4});

dyanmic myObject = parsley.Retrieve("MyClass", response.objectId);

parsley.Delete(myObject.objectId);

Outstanding Tasks

Lots. But here is the main ones I see right now.

Compile on Mono and show MonoTouch some Parse love.
Samples (for WP7, Monotouch, possibly Monodroid)
Add Queries
Add User Management

It's probably fairly rough right now and could do with some TLC if anyone wants to pitch in? I've given it a name (Parsley) but that in no way implies this is going to be a long running project or anything. I just like naming things. Get it while it's hot, the code is in my usual place.

Pre-Post Update

Rather than update this blog post I decided to tack this on here. With BitBucket experiencing some issues at present I spent about 10 minutes hacking in the user management features. No tests written yet (oh no I have broken all the rules and must be beaten with oversized crayons) so lets just say that it's very edge, very experimental at the minute. Also bonus - returning a collection of objects is implemented as Query but again totally untested (fast and loose - it's how I roll son). There be dragons there therebe!

Happy hacking.

Can I have my WP7 MVP now please? Kidding

Standing at the cusp of 2011... WTF?

2011-12-30T00:00:00+00:00

I'm not sure where this post is going to go in terms of content. I'm thinking a bit of full disclosure might be quite cathartic but at the same time do you really want to know the ins and out of my somewhat awful 2011? Compromise - I'll keep it short. Possibly.

2011 (The Bad Parts)

2011 was a pretty terrible year if I'm honest. It was the year my wife suffered two miscarriages, I got into my first car accident, stuff kept breaking and I totally dropped the ball in work when I burnt out (I'm certain I'm still feeling the effects of that). Oh and yes on top of all that I was diagnosed with severe depression for which I am now fully medicated. But you know what? I'm not alone - I know a ton of people for whom (look at me I said whom - how posh) 2011 was grim.

So lets cast aside all the personal stuff, we've all had our problems, and let me talk about the burn out. Long and short of it was that I took too much work on and eventually delivered unacceptable results for them all. I have something akin to ADD when it comes to work and unless I am suitably challenged or stimulated my productivity drops to pretty much nil. 2011 was full of time consuming mundane boring work for me and as I tried desperately to pull personal value from the work (or hobbies) I started making mistakes, over committing and generally under achieving. Lesson learned - I need to learn to say no and sometimes I just need to suck up the fact that we can't all be doing the best part of our jobs ALL THE TIME. Sometimes we need to just knuckle down and get on with it. Just not for a full year…

Anyway I became somewhat disillusioned with my employer and, truthfully, Northern Ireland. I like other people to be excited about the stuff I preach but I felt there was a lot of disinterest and empty words. This annoyed me and I guess I just started pushing harder, which I guess made me look quite angry and pushy. This obviously wouldn't help. When I looked outside of my company - Northern Ireland didn't seem that much better. So I felt a bit out of place and I had 2 choices ahead of me.

Up sticks and go somewhere that I felt would be more receptive to my extreme nerdyness and desire to share it.
Stick around, my company and Northern Ireland and try and make a difference.

I chose the second, not being to be hero or anything but for more pragmatic reasons,

My wife got pregnant again (due soon yay!), the economy is terrible and it would be too much of a risk right now
If I stayed in Northern Ireland, or even Ireland, I don't believe there is any other company that would support me (aka let me get away with) the things I do. I'm not the most predictable of sorts. I work weird hours and do strange things. Kainos have always been there for me and supported me. Having done interviews with people from various levels from various other companies the state of other IT firms makes me seethe with anger.

It is better to invest in people and risk them leaving than to not invest in them and risk them staying

So I start 2012 with a big challenge set for myself. That sounds about right. The more I think about Kainos, my employer, deserves more credit than I give it. We have been in a space thats been all about big business types with big enterprisey solutions and delivered well. It's not an area that exactly screams enthusiasm and I think it will take a while to draw people out of that kind of insular thinking. Kainos certainly seems to be better than most in this area. Now enough gushing about Kainos (who are hiring BTW)

2011 (The Good Parts)

OK OK 2011 wasn't all sob stories and dullness some really cool things happened.

My CodeSlice initiative in work (meet at least once a month, talk nerdy things, get Kainos to pay for free pizza) didn't die. In fact in the hands of one of my colleagues, Jonny Holmes, it flourished. Attendence was never HUGE but it was consistent and varied. May long this tradition continue and hopefully we can expand it..
I organised and participated in not one but two hackathons (internally). Once again Kainos covered the costs for our weekend long hack sessions. Turnout was decent (about 8-12 people) with all types turning up - managers, placement students, technical architects etc. The experience was enough for me - which is a clever way of saying the end products weren't as good as envisaged. But we drew so many valuable lessons that the second one was infinitely more successful that the first - live and learn! And, oh lord, the plans I have for the first half of 2012 around hackathons are going to be legendary!
I talked, and not just to myself but to real people, real people who were not paid to be there! I talked, outside of work, a total of three times. I know the number isn't huge but it was late on in the year before I decided to get out there. Already topped that number for 2012 and the year hasn't started. Double figures would be good next year thank you.
I attended GOTO Amsterdam were I got to meet a lot of people I have deemed awesome (because they are). Being in rooms with like minded people (who are generally much smarter than me) saying things that make you realise you are not insane for thinking things could be better really strengthens your beliefs!
Shared more. All the stuff above I did because I wanted to get my thoughts out there - I wanted to be educated as well as educate. I was happy to look like a fool if it meant I didn't look like a fool later. Thats hard for an introvert but damn it I gave it my best shot. I know people, the one who only know me through my writing on Yammer or half-read blog post, think I am a purist (I'm not - perfect is the enemy of better), or angry (not me, frustrated at times but never angry), or opinionated (openly opinionated perhaps) or even annoyed that everyone isn't dancing the happy geek dance like myself (as long as I'm not dancing alone on the dance floor like a sleazy old man stalking girls half his age I'm happy). Thats fine. People reckon I risk detracting from the message I am trying to communicate. Fair enough. Perhaps I need to tone it down sometimes - but I can't see that happening - it's no in my nature. I think it's better that people see me as a purist and take some of my ideas away rather than being half-assed and them not taking anything on board! It's inevitable that when I try and challenge peoples conceptions of technical things, especially in the open, it's going to leave a sour taste in some peoples mouths. But thats how I roll and thats how it should be. Sorry but there is more on the way. But I take as good as I give so come at me bros!
Won a years to subscription to Tekpub on Christmas Day thanks Rob 'Santa Clause' Conrey.
Put my foot in it a few times. Yeah sounds odd I am classing this as a good thing but Scott Hanselman gave me permission, and I quote

Chris Sells told me once, If you’re not getting in trouble with your boss at least twice a year, you’re likely not pushing the envelope hard enough. Two slaps a year might be the cost for 10 successes. If you’re not moving forward, well, you’re not moving forward.

2012 (More like 20AWESOME! AMIRITE!)

So enough dwelling in the past - how am I going to make 2012 be the awesomest? Well thats easy - set some real fecking goals. I failed to do that last year (outside of my typical career goals during my annual reviews of course) and ended up coasting in parts. Not next year - hells no. I got me a bucket list (stuff to do before the year dies - not me - unless that comes first - oh god I never thought of that). TO THE LIST!

2012 Bucket List (In No Particular Order)

Release a screencast
Release a game
Appalachian Trail
GiveCamp NI
Talk/Present as often as possible
Learn a new language
Contribute more to OSS

So let me explain some of these, as I am sure they mean sweet FA to some of you.

Release a Screencast

A lot of my blog posts last year were a kind of “Introduction to Technology X” and I think that sort of knowledge can be better shared via video and real coding. Coupled with my desire to go a bit deeper in my technical posts but always getting distracted with other blog posts I think 2012 is the year I try my hand at producing a real life proper screencast (or perhaps a series). With decent production values and what not. The topic? Well I am currently thinking Nancy but I need to really get my head around it a lot than I already do - but thats fine. Time will tell on that one.

Release a Game

Game programming is an area I've failed to venture into and I feel it is about time. I wan't to do something really simple, something mobiley possibly using ImpactJS because it interests me. I'd like to release said game into an app store as well - just to watch it get flamed and to say “I've done it”

Appalachian Trail

This is a codename for a current unfunded project of mine. The goal is to get a more fuller understanding of the spectrum of mobile development approaches, platforms and technologies. So simply put generate a bunch of super simple (though still useful) app ideas and using every conceivable type of technology from native to web and all in-between deliver decent quality apps across all the major platforms through hackathons, team challenges, school and university outreach, app camps etc..

Sounds awesome doesn't it?

GiveCamp NI

GiveCamp was founded by Microsoft Developer Evangelist, Chris Koenig, in Dallas, Texas in 2007. His vision was to bring together passionate developers and local charitable organisations for an entire weekend, and see what would happen.

In late 2012 GiveCamp is coming to Northern Ireland.

Thats what the official site says (I should know I put it there). So late next year we will run GiveCamp for the first time in Northern Ireland. A weekend long charity focused public hackathon. It's going to be a belter!

Talk/Present as often as possible

I enjoy talking about nerdy things. I got a taste for it last year when I went public (having been talking internally to Kainos staff for years) and in 2012 I really want to get out there as much as possible. I find it an amazing way for me to learn as well as understand whats going on in the industry. So far I am speaking in Dublin in January, Devweek in London and a few other un-announced venues.

BTW if anyone can recommend conferences I should pitch for, or want me to come over and talk about anything in the .NET/JavaScript/Mobie world(s) (see my blog for the kind of thing I know about) - let me know!

Learn a new language

Everyone says this one right? Yeah so I spent last year looking at node.js and Ruby and I think it's time to get out of my safe - I'm thinking F# - yeah that sounds sweet!

Contribute more to OSS

I head-dived into OSS .NET last year and loved it. Many people see .NET as a very restricted, Microsoft led platform were every modern web-app is MVC3 with Entity Framework and WCF rules the web service world. Thats total bull. .NET has a very vibrant, very active OSS community. There is almost no need to use any MS technology ever. But lets not forget MS have really started to embrace and support OSS in a big way. Lets hope that trend continues!

In Summary

Boooo to 2011, Yay to 2012. See you around the same time next year when I have another failful year and promising myself a better one in 2013 :-P

A Nancy Module that Behaves like a Rails Controller... Mother of God

2011-12-30T00:00:00+00:00

If Nancy is inspired by Sinatra I thought I'd have a little fun a create an abstract class that created modules that kind of mimic the behaviour of Rails controllers. Code first, ask questions later…

public abstract class RailslikeControllerFor<TEntity> : NancyModule where TEntity : class
{
    public RailslikeControllerFor() : base("/" + typeof(TEntity).Name + "s")
    {
        Get[@"/"] = Index;
        Get[@"/new"] = New;
        Post[@"/"] = Create;
        Get[@"/(?<id>[\d])"] = Show;
        Get[@"/(?<id>[\d])/edit"] = Edit;
        Put[@"/(?<id>[\d])"] = Update;
        Delete[@"/(?<id>[\d])"] = Destroy;
    }

    protected virtual Nancy.Response Index(dynamic context) { return 404; }
    protected virtual Nancy.Response New(dynamic context) { return 404; }
    protected virtual Nancy.Response Create(dynamic context) { return 404; }
    protected virtual Nancy.Response Show(dynamic context) { return 404; }
    protected virtual Nancy.Response Edit(dynamic context) { return 404; }
    protected virtual Nancy.Response Update(dynamic context) { return 404; }
    protected virtual Nancy.Response Destroy(dynamic context) { return 404; }

    protected Nancy.Response AsView(object model = null)
    {
        string method = new StackTrace().GetFrame(1).GetMethod().Name;
        string entity = typeof(TEntity).Name;

        return View[string.Format("{0}/{1}", entity, method), model];
    }
}

To use it you just subclass the class and override the necessary methods. Like so.

public class QuestionModule : RailslikeControllerFor<Question>
{
    IQuestionsRepository questions;

    public QuestionModule(IQuestionsRepository questions)
        : base() { this.questions = questions; }

    protected override Response Index(dynamic context)
    {
        return AsView(questions.GetAll());
    }
}

What the base class does is create the necessary CRUDdy urls with a base route starting with the name of the entity you pass in, pluralised in the easiest way possible. In this case /questions. The rules match what you wold get for a controller in Rails.

Verb	Path	Action
GET	/questions	index	display a list of all questions
GET	/questions/new	new	return an HTML form for creating a new question
POST	/questions	create	create a new question
GET	/questions/:id	show	display a specific question
GET	/questions/:id/edit	edit	return an HTML form for editing a question
PUT	/questions/:id	update	update a specific question
DELETE	/questions/:id	destroy	delete a specific question

There is a teeny-tiny bit of sugar in the AsView method that will look up the corresponding view. So the module above would resolve its Index method to questions/index and the view engine would find the correct file (eg. for Razor - questions/index.cshtml).

I've already said it's a bit of fun but I have actually used this at least once - there is probably more that could be added but it'll do for a first spike at least. Any use to anyone?

Code Coverage and the Forces of Good

2011-12-27T00:00:00+00:00

Code coverage often does more harm than good. It removes the focus from testing the expected behaviour of the code to just writing tests to make sure all your code is hit (gamifiying the process to its own detriment). People will bend tests, often in a way that no typical use case could, just to make them run as they want. This is unrealistic and paints a false picture of the behaviour of your code.

That being said - code coverage is a tool and it shouldn't be blamed for enabling bad habits (a bad workman always blames hi… well, you know the rest). So can code coverage be applied in a less obvious way? Indeed it can.

Business users invariably end up using things like Google Analytics, Gauges or Flurry to discover the most valuable areas of the solution and tailor accordingly. Makes perfect sense, right? So why not use code coverage, during development, as a mechanism to identify redundant areas of code, or discover feature hotspots that could benefit from refactoring or performance tweaking? Why not indeed?

As any system evolves there will be behaviours that simply don't need to exist to satisfy the overall behaviour of the system. Some code and it's related tests will still hang around. It happens and with the right tools you'll be able to see those areas - MightyMoose will show you hit counts for lines of code for example. So by ensuring tests are reviewed as part of your code review process (or refactored during pairing) you'll also get reporting of redundant code or feature hotspots for free.

So if your project is already reporting on code coverage thanks to some great architectural mandate why not at least use it for something more positive?

Ugh. He's on about something mobiley again. Lord save us all!

2011-12-13T00:00:00+00:00

Good timing right? Fresh of the wave of my “lets have a natter about mobile” blog posts HP went and did something good (for a change, right?). After the hash that was made of the TouchPad HP went and open sourced the webOS software. <!– more –> Bundled with this software is Enyo a mobile framework for WebKit browsers. Enyo was to be one of the main development platforms for webOS - JavaScript on the front end with node.js services for the backend. The future was bright. Then the TouchPad flopped. Ack well.

On the other hand Enyo is a very nice little framework and in the hands of the Open Source community could be a real winner. I've had a chance to tinker with over the last few days and thought I'd help get the word out by outlining how to write the obligatory by law ToDo app. It is currently somewhat similar to the official FeedReader tutorial but it could be easily extended to add more features. I recommend you look at the original tutorial for more info about how the project is structured as there are certain conventions that may seem odd to your typical web framework.

The entire application, which looks like this (yeah yeah it's not the most beautiful thing on the planet - I suck at design).

Was knocked together with the following bit of code

enyo.kind({
  name: "TodoApp",
  kind: enyo.VFlexBox,
  components: [
      {kind: "PageHeader",  components: [
        {kind: "VFlexBox",  flex: 1, align: "center", components: [ {content: "Todos"} ]},
        {kind: "Button", caption: "Clear Complete", onclick: "clearComplete"}
      ]},
      {kind: "RowGroup",  components: [
        {name: "newTask", kind: "Input", hint: "Enter new ToDo here..."},
        {kind: "Button", caption: "Add", onclick: "addTask"}
      ]},
      {kind: "Scroller",  flex: 1,  components: [
        {name: "list", kind: "VirtualRepeater", onSetupRow: "getTask", components: [
          {kind: "Item", layoutKind: "HFlexLayout", align:"center", components: [
            {name: "taskStatus", kind: "CheckBox", style: "margin-right:10px;", onChange: "completeTask" },
            {name: "taskDescription" }
          ]}
        ]}
      ]}
  ],

  create: function(){
    this.todos = [];
    this.inherited(arguments);
  },

  addTask: function(){
    var task = this.$.newTask.getValue();
    this.todos.push({ description: task, done: false });
    this.$.list.render();
  },

  getTask: function(sender, idx) {
    var todo = this.todos[idx];
    if (todo) {
        this.$.taskDescription.setContent(todo.description);
        return true;
    }
  },

  completeTask: function(sender, evt){
    this.todos[this.$.list.fetchRowIndex()].done = sender.getChecked();
  },

  clearComplete: function(){
    var buffer = [];
    for(var i = 0; i < this.todos.length; i++) if(!this.todos[i].done){
      buffer.push(this.todos[i]);
    }
    this.todos = buffer;
    this.$.list.render();
  }

});

Those of you with some experience in Sencha Touchwill notice that the declarative syntax is quite similar to STs except slightly simpler. So lets break out some of the features that brought this example together.

{kind: "Button", caption: "Clear Complete", onclick: "clearComplete"}

This is one of the component declarations that make up the suite of components that form the “kind” (Enyo speak for component or object). This is somewhat similar to the DOM (COM anyone? Component Object Model) except in JSON form. You can specify a component type (kind) and apply properties (which may or may not do something depending on the kind). Events are also declared inline (see onclick) and map to function names within the main kind declaration. Obviously if this declaration started getting too big and bloated I could decompose it into smaller components all handling their own stuff.

One other thing not highlighted in my demo is that backend service calls can also be defined within this component model and then called programatically. While this felt alien to me initially it is pretty similar to the way inline stores are declared in Sencha - except slightly less engineered.

{kind: "Scroller",  flex: 1,  components: [
    {name: "list", kind: "VirtualRepeater", onSetupRow: "getTask", components: [
      {kind: "Item", layoutKind: "HFlexLayout", align:"center", components: [
        {name: "taskStatus", kind: "CheckBox", style: "margin-right:10px;", onChange: "completeTask" },
        {name: "taskDescription" }
      ]}
    ]}
]}

The scroller definition above has a few nice features. The use of “flex” to manage different screen sizes or viewport resizes and create very nice flexible layout. The VirtualRepeater which is a templated control that generates items from a collection based on the defined template. The Virtual part is useful for large lists and ensures that only the minimum amount of items are rendered (just before they are needed).

create: function(){
    this.todos = [];
    this.inherited(arguments);
}

Create is essentially our component constructor and allows us to set some things up in advance. Notice the use of the inherited() method - this ensures the superclasses create method is also called (inheritence chaining)

this.$.list.render();

this.$ is a handy property. It is essentially a hash of all the named components that are direct and indirect children of the defined component. This makes it very easy to access a certain component if you want to manipulate it.

getTask: function(sender, idx) {
    var todo = this.todos[idx];
    if (todo) {
        this.$.taskDescription.setContent(todo.description);
        return true;
    }
}

getTask is the method responsible for populating an Item template in the repeater for each row. This is where I bind the values of the current collection to the Item kind.

There you have it - yet another ToDo app spat out into the world! Just what we needed :)

It not all Unicorns and Rainbows

Yeah Enyo isn't perfect (shock horror). There are some quite annoying and some serious bugs that I have noticed in my hacking.

Data Association

When rendering the Repeater I can't see a way to easily attach data items to that item instance. I worked it out eventually by using this.$.list.fetchRowIndex() but I think you would need to then manage your own data association. Not a big issue but it didn't feel right to me at the time.

iPad/iPhone issues

The one big issue I had with the iPad was that text fields often didn't bring the keyboard up (more often than not). Obviously this could be a bit of a deal breaker but there could be a simple fix. Some other minor quirks included scrolling issues when multiple scroll areas existed and choppy animations in the kitchen sink style demo (Sampler).

The example apps display and work on the iPhone but they are super tiny. I am not sure if this is just a lack of correct formatting within my HTML or if Enyo is purely designed for larger screens.

Events

At one point I wanted to bind to an event of a component programatically (rather than declaring it inline). I still can;t find a way to do this and I wonder if this could be a bit of hindrence when you get into a truly dynamic application. Thought this could be me being a bit stupid as usual.

Conclusion

Enyo v1.0 is still young in the hands of the OSS community but it's started out strong and could well be a strong competitor to something like Sencha Touch if it keeps up this pace. Hopefully the community embraces it and allows it to grow. It could well be great.

So yes, so far I like it but I've only been hacking a few days. Hopefully I get to spend more time with it over the next few weeks.

The sample project is available on my BitBucket Repo if you want to tinker.

Rolling Your Own PhoneGap with MonoTouch

2011-12-05T00:00:00+00:00

PhoneGap is a clever little idea. Take a transparent native wrapper for a mobile platform, stretch a 100% x 100% web view and provide a JavaScript API that acts as a bridge to native methods that control the device features such as cameras, GPS and Contacts. It brings all those lovely web people into the mobile space. Truth be told PhoneGap isn't powered by flaked unicorn and rainbow essence - it's fairly simple to achieve yourself.

So I was thinking, as I do when I am bored, that it would be super awesome if MonoTouch could do the PhoneGap. Turns out there have been some attempts in the past to create bindings but I barely understand the posts so I felt disappointed. Then curious. Then I started hacking. Then happy. Then bored again. The happy once more. Then slightly frustrated. Finally I started writing this post and I think I feel a bit tired because it's late an I've had a hard day.

Anyway what follows is a very primitive start to what is essentially a PhoneGap, possibly NimbleKit, for MonoTouch. Thats cool becuase not only would you be saying “Screw You Objective-C!!” by using MonoTouch but you'd be sort of saying “Hey MonoTouch - HTML5 just had your mum, twice” as well. Hey I'd use a NimbleKit/PhoneGap-like framework for MonoTouch if it was available and offered a clever way of mixing Native with Web but thats just me. Hence I am writing this post.

The Recipe

There are various components that would make up a framework like this.

A fullscreen Web View (lets call it the webside)
A controller that handles requests from the webside (lets call it the nativeside)
A JavaScript API on the webside that talks to the nativeside

Simple enough so lets start proving things.

The Webside

Using a simple Single View iPhone Project in MonoDevelop I added some local resources.

    |
    |_ www
    | |_ index.html
    |
    |_ AppDelegate.cs
    |_ MainViewController.cs

For now the index.html file has some basic content

<!DOCTYPE html>
<html>
    <head>
        <title></title>
    </head>
    <body>
        <h1>Hello UIWebView</h1>
    </body>
</html>

Next up I created a full screen UIWebView and asked it to point to the index.html I just created in wwww folder (which by the way should be set as “Content”.

public override void ViewDidLoad ()
{
    base.ViewDidLoad ();

    using (UIWebView view = new UIWebView(new RectangleF(0f, 0f, 320f, 460f)))
    {
        // obtain path to actual content file
        string path = NSBundle.MainBundle.PathForResource("www/index", "html");

        // create an address and escape whitespace
        string address = string.Format("file:{0}", path).Replace(" ", "%20");

        // create url and request
        NSUrl url = new NSUrl(address);
        NSUrlRequest request = new NSUrlRequest(url);

        // load request and add to main ?view
        view.LoadRequest(request);
        this.View.AddSubview(view);
    }
}

Running this gives us what we would expect (I hope you expect this otherwise I'd be worried).

Webside more or less spiked for now. Next up the nativeside.

The Nativeside

So how is the native stuff supposed to respond to requests made via the mysterious JavaScript API from the webside. The approach that makes the most sense here is to set up an internal HttpListener that reacts to web requests. This means we can, thanks to the lack of a Same Origin Policy in UIWebViews via the file:// protocol, make Ajax requests to said listener to do stuff and return appropriate responses.

In the AppDelegate class I created a basic HttpListener that simply returns a simple JSON response of true if a request is made.

public HttpListener listener;

public void HandleRequest (IAsyncResult result)
{
    //Get the listener context
    HttpListenerContext context = listener.EndGetContext(result);

    //Start listening for the next request
    listener.BeginGetContext(new AsyncCallback(HandleRequest), listener);

    string response = "true";
    byte[] responseBytes = System.Text.Encoding.UTF8.GetBytes(response);

    context.Response.ContentType = "text/json";
    context.Response.StatusCode = (int)HttpStatusCode.OK;
    context.Response.ContentLength64 = responseBytes.Length;
    context.Response.OutputStream.Write(responseBytes, 0, responseBytes.Length);
    context.Response.OutputStream.Close();
}

public override bool FinishedLaunching (UIApplication app, NSDictionary options)
{
    window = new UIWindow (UIScreen.MainScreen.Bounds);

    viewController = new JsBridgeViewController ();
    window.RootViewController = viewController;
    window.MakeKeyAndVisible ();

    listener = new HttpListener();
    listener.Prefixes.Add("http://*:30001/");
    listener.Start();

    listener.BeginGetContext(new AsyncCallback(HandleRequest), listener);

    return true;
}

The Final Step - The Bridge

So we need to talk to this “server” from our JavaScript. Easy stuff - for now we just make a simple ajax call to our endpoint in the index.html (synchronous for code simplicity).

<script type="text/javascript">
    var request = new XMLHttpRequest();
    request.open('GET','http://127.0.0.1:30001/', false);
    request.send();

    if(request.status == 200){
        alert(JSON.parse(request.responseText));
    }
    else{
        alert("Error");
    }

</script>

Running this once again reveals that all is sweet…

Now What?

Well thats about as far as I've actually gotten but this is far enough to satisfy myself that it's possible to talk between the web view and the native stuff. Yeah I know it's not rocket science but I needed to prove this to myself. So whats next? Well I want see what I can do with regards to making real calls to real things, perhaps even venture into NimbleKit territory and generate native elements such as ViewControllers and Tabs - who knows!

(MYSTERIOUS EXIT MUSIC)

(FADE TO BLACK)

To Be Continued…

(EVIL CACKLE HEARD IN THE DISTANCE)

(END SCENE)

So This Mobile Stuff Then... (Techologies)

2011-12-05T00:00:00+00:00

Do you have your mobile strategy yet? Do you have your “one true way” to cater for every mobile application need? If not, the world will suddenly end and you'll never get anywhere in the mobile market. Seriously. Well not seriously. Obviously that’s a pile of sheep.

To be blunt the best “mobile strategy” is the obvious one. Do whatever suits the project best. Yeah, yeah your company or your presales guys may not like that, no prepackaged waffle to fill document with or spew out in front of customers. The easy route is seldom the best route. Seriously though if your playing it safe with web just in case that iOS project you've gotten involved in goes Android you'll be compromising all the way.

Just In Case

Ahhhh good old “just in case”. Nothing produces more mediocrity through compromise than “just in case”. It's up to you to use your head when it comes to deciding what is the best fit for the project but as long as all the stakeholders are aware of the constraints those choices put on the project then those “what if” scenarios can be dealt with later. We need to stop treating “mobile” as if it was a technology decision. Web vs Native is not the same as saying Entity Framework vs NHibernate. It's so much bigger than that.

Weighing up the options

So you got a killer mobile project and you want it to be awesome - just like all your projects. Before we pull out the “Native, Hybrid or Web” question we need to know what is out there. What tools, technologies or languages can we use to make the best solution we can?

Going Native

The problem with the native moniker is that people assume it means a different code base per mobile target and therefore crazy expensive, difficult to handle change, and very time consuming but that isn't always the case. It is entirely possible to produce truly native apps without having to have an expansive code base in every language possible.

Appcelerator Titanium

Appcelerator's Titanium is a good example of a platform that provides an abstract API via a common meta language (in it's case JavaScript) that allows you to build directly to native apps for each target platform. You write your code and send it off to the cloud for compilation (AFAIK there currently isn't an in-house option for building but happy to be corrected). So you've got a middleman that you have no control over. What happens if your app gets rejected due to some low level issue in the compiled code? What if the cloud service goes down when you really really gotta build? What if Appcelerator goes bust? I dunno maybe that’s just mostly FUD but these are the questions that customers ask and they are difficult ones to answer. I realise I've lambasted the use of too much “what if"s in decision making but I've come up against these ones and they directly affect the current solution rather than only the future scope. They need addressing and that’s difficult.

Having said the a brilliant example of Appcelerators usefulness is Wunderlist - available on a ton of mobile and desktop platforms and built with Titanium the whole project shares, AFAIK, a common code base.

MonoTouch, Monodroid etc.

MonoTouch and its ilk take a slightly different approach to the meta-language. MonoTouch, for example, isn't, as many believe, a cross-platform tool for building native apps. No, MonoTouch simply compiles to native code through direct bindings to Objective-C code. You are simply using the C# and the powerful features of the Mono/.NET Base Class Library. In fact it's even possible to bind to third party Objective-C code like Flurry, Three20 etc. (and many are made available by other developers).

The ability to share a common codebase comes from the fact that the same platform is available in MonoDroid (C# and Android) and Silverlight (Windows Phone 7). So sharing comes down to architecture. You can share code provided your code doesn't touch and platform specific code. You can create your own abstraction layer and work it into your build process or you can use MonoMobile.Extensions which gives you a common API already.

So in one way the MonoTouch stuff is simply the same as writing Objective-C but simply doing it using C#. This is nice for a number of reasons.

Mono has some very nice features like LINQ and Parallel programming.
Plenty of nice compatible frameworks - sqlite-net, catnap, restsharp and plenty more.
Syntax that is less noisy and easier to read

There are of course issues. Assuming most people who use MonoTouch will come from a .NET background and want to use those skills - when you start you'll realise just how nice Visual Studio is. MonoDevelop isn't terrible, it's just fine, but it's simply not on par with Visual Studio (would you expect it to be?). With the way MonoTouch works your are kind of stuck with MonoDevelop too. Your average VS2010 developer might easily get frustrated with MonoDevelop. An aesthetic concern but one that can put people off easily. That said XCode is equally as infuriating at times (bugs and quirks abound!).

It's not all roses though. What if Xamarin, the commercial sponsor of MonoTouch, pull the plug? What if Apple decide, as they tried to before, to ban the use of any intermediary language? These are questions that people will ask but again the immediate and real advantages always trump theoretical risks. One other thing worth thinking about - If you came from a Ruby background for example I'm not sure why you would use MonoTouch over Obj-C. Will this niche have an affect on Mono* in the long term? Who knows.

Mixing It Up aka (cough)Hybrid(cough)

So maybe you're a web guru/ninja/hero/wizard type person and you want to make use of those powers/skills in your mobile development but you want to get market visibility by creating a presence in the app stores. Perhaps you want to have some sort of reuse across platforms but aren't a .NET dev and Titanium isn't appealing. There a number of options in this area already.

PhoneGap/Callback

PhoneGap is easily the most technology in the hybrid space. It is exactly what you expect. A fullscreen UIWebView in which resources embedded in the application package are executed. These resources are given access to native device features such as device access etc. via a JavaScript API that hooks into native function calls. There are wrappers for numerous platforms (iOS, Android, Bada, Blackberry, WP7 etc.) but your code calls the same adaptive API. Things start to veer off course when you need to introduce custom plugins as these are native and so you need to target all your platforms. Not much PhoneGap can do in that case of course but worth pointing out.

With PhoneGap it is up to you to create the experience. Even if you want a simple straight forward native look and feel you'll need to simulate it. Results may vary depending on how good you are at that sort of thing. Of course something like Sencha Touch could be used to fake native but again what is native on one platform is weirdly alien on another and if you are targeting one platform only why not just man-up and learn that platform in the long term? At least give yourself that option.

NimbleKit

NimbleKit is in some ways a bit like MonoTouch meets PhoneGap . You can use it as you would PhoneGap as a transparent API the bridges native and Web Technologies but you can also create real life native components such a Navigation Controllers and Tabs. Currently iOS is the only supported platform (more support for iPhone than iPad) though an Android version does exist in beta.

The interesting thing about NimbleKit is that it allows you to make use of a range of technologies to create a really native application while at the same time making use of HTML5/CSS3 features to create a more compelling experience that becomes very difficult in native platforms (see my previous charting example in my last post).

Plugins are extremely simple as well. Just register the Obj-C class and call it from JavaScript. Very nice, very simple. This allows third party extensions to be bridged very easily too (Flurry for example).

The slightly annoying thing about NimbleKit is that it is currently very quiet. There is still activity but it's certainly not on par with the likes of PhoneGap. There are also some issues around stability. It's not falling over all the time but there are somethings that need to be done in a certain order that aren't properly documented. There is some minor speculation that Sencha have acquired NimbleKit and I'd welcome that with open arms because I like the philosophy around NimbleKit and it could do with some money behind it.

Options for Using Web Technologies

Be it hybrid or simply a mobile targeted web site/app there are a ton of options out there. An absolute TON!

Native look and feel, ultra rich frameworks
Truly cross-platform progressively enhancing frameworks
Frameworks for creating structure in your apps like MVC, MVVM etc.
Frameworks for offering responsive designs

Mind boggling choices that change and evolve on a near hourly basis. Here are just a few

Native Look and Feel - Sencha Touch

Sencha Touch targets high end iOS and Android devices and creates native-esque UIs (WebKit only). It's can be patchy on Android at times but the results you can get on iOS are very appealing. Version 2.0 is seeing massive improvements in performance across the compatible platforms. People who have experience in ExtJS will really feel at home here - other people will struggle with the short but steep learning curve (as with all Sencha frameworks).

Bear in mind that Sencha Touch is a framework not a product so there will be work involved in getting it to behave exactly how you want but the available architecture options such as the MVC approach and the Data Stores make it very powerful.

Cross Platform - jQuery Mobile

jQuery Mobile lives at the opposite end of the mobile framework spectrum. It takes the philosophy of jQuery UI (Progressive Enhancement, accessibility, themeability etc.) and put it into a mobile framework. So you construct a purely functional purely HTML application or site and with data annotations you let jQuery Mobile make the site as rich and functional as it can. This means provided your mobile device can render HTML the site or app will at least be functional. Butt ugly but functional.

This carries a penalty though. Even when used on the top of the line device there are some trade offs that need to be made. The experience is not as polished as it could be. It is possible to tweak it yourself and cater to the high end devices only but there is extra work involved. Again the result is still very nice and generally smooth but it is easy to nitpick little quirks in the navigation or styling.

MVC Frameworks - Backbone, Spine(Mobile), Sammy etc.

If you want to roll your own UI entirely but still need to create a scalable and proven foundation Backbone and Spine are two very interesting projects. It's worth noting that Sencha Touch has a powerful MVC architecture built into to and it is somewhat similar to these frameworks.

These sort of frameworks offer base classes for your typical project structure - Controllers, Models and Views. They provide the wiring between these abstract classes allowing the developers to focus on the important stuff. The controllers allow you to specify custom routing in your single page apps, the models give you structured persistence and sometimes relationships and the views give you a nicer lifecycle around page components and custom event handling.

It's often said these frameworks take some time to "get” - some people can use them with ease while others just think they introduce unnecessary complexity. I think they come into their own in the mobile app space but I do still struggle with the concepts at times.

Responsive Design - Skeleton

There are grid and UI toolkit frameworks out there that are aimed at creating a responsive design. Got a large screen? Make use of the better horizontal space and stack elements horizontally. On a small mobile device with tiny viewport? Stack the elements vertically. Skeleton is the perfect example of this using media queries to layout a grid system depending on available space. It also has a few nice widgets like Tabs and Buttons. Geared more around the web site rather than the app these frameworks are a handy addition.

Run out of things to say

I've covered a lot there but I wanted to get my thoughts out there in the world and hopefully educate and be educated. My tools of choice right now? Well RIGHT NOW I am tinkering with Obj-C and iOS as well as MonoTouch and did some NimbleKit hacking at the weekend. To me this sort of understanding is important and that’s why I do it. You may argue that it makes you a jack-of-all-trades but I don't think so - this I merely trying to better understand the mobile ecosystem in the same way I try and grok the entire .NET ecosystem.

To me if you want to embrace mobile you need to understand it properly. If you're just sticking with a particular stack because it's familiar to you you are doing yourself and the project a dis-service. As many articles before me have said - you are not the programming language you code in - you need to embrace the polyglot nature of a good developer and do what is right for that project.

Hope you enjoyed this. That’s me for December I think :). I have other things to do.

So this mobile stuff then... (Hybrid)

2011-12-03T00:00:00+00:00

It's fair to say over the past year or so I've dabbled in a bit of mobile development. I've been involved in a number of projects (from a technical perspective),

Web Based, Tablet Focused Analytics Dashboard (Custom HTML and HighCharts)
Web Based, Tablet Focused Data Capture application (Sencha Touch)
Hybrid application for a teleco (jQuery Mobile and PhoneGap)
Mobile Hackathon (jQuery Mobile and PhoneGap and Parse)
Hybrid Application for a Bank (Sencha Touch and PhoneGap)
Various iPhone and iPad POCs for a health based project (MonoTouch, XCode)
Technology evaluations (Native Apple Development, Parse, Sencha Touch], PhoneGap, NimbleKit, jQuery Mobile, Backbone, Spine.js, Appcelerator, MonoTouch, Monodroid and plenty more…)
Consulted on various projects around the whole “native vs hybrid vs web” thing

That Hybrid Word

One thing I've found is that many clients are using the old “a web app will never be as polished as a native app” argument but TBH that really isn't the case. This is down to a lack of real understanding and abuse of the word in the industry. A bit of hybridism can go along way in creating a rich experience.

A Rose By Any Other Name…

Many people break mobile applications into 3 VERY distinct areas,

Native - app installed on the device, written using the default toolkit for that platform.
Hybrid - consists of a transparent “native” layer and a Web View into which HTML, JavaScript and CSS is loaded (generally stored within the native package). The nativelayer provides and API for the JavaScript model in the Web View to call. Think PhoneGap.
Web - HTML, CSS, JavaScript assets hosted on the web and accessed from a mobile device. Possibly some native-like features such as icons and removing the browser chrome.

The problem with the hybrid definition there is that it is, well, wrong. There isn't a clear distinction between the native and hybrid and there shouldn't be. If I spun up a Silverlight app that put a Web View in the middle to display some HTML I wouldn't call it hybrid. If I wrote an Android app that used a library written in Scala it wouldn't be hybrid. Or even if I wrote a Monotouch app using some bindings to the Flurry framework - nope not hybrid.

The Charting Example

A good example of “hybrid” is charting. There aren't a great deal of nice flexible charting libraries for iOS, but there is for JavaScript/HTML5. So some of our projects have made use of HighCharts and Sencha Charting inside a transparent UIWebView to render charts that are flexible and rich. I wouldn't bother pinning the hybrid tag to that app - it's simply making use of whatever technologies helped us get the job done in the best way possible.

I understand the use of hybrid in sales pitches or to simply convey meaning to people who are less technical but the problem is people are starting to develop opinions based on these words alone which is disatorous. I've had customers tell me that they want native because that hybrid stuff is ugly. True some hybrid apps are ugly as sin (Aer Lingus iPhone app for one) but then so are some native ones. It's unfair to collectively throw away and entire type of app because of poorly misunderstood words.

But, But, But… Reusability

People use the hybrid term to show that they have thought about portability. Write once, run anywhere. In that sense I guess using hybrid makes sense (but that sort of talk is really part of the sales talk right?). But then it would be just as easy to say that “elements of the solution will be written in a platform agnostic language to minimise code rewrites on different devices” - or something like that. In fact that would be better. That way you cover off more than “hybrid”. You've included the things like MonoTouch or Appcelerator as well. You've moved away from implementation specifics at the point where they shouldn't matter anyway! Thats got to be a good thing.

Ah ha but what about Skills?

People go “hybrid” for another good reason - because they have no experience in the native platform. I used to be one of those people but I'm not convinced that this is a good reason on its own. If you want to make a compelling experience your limitation should never be your lack of skill. Get skilled. Obj-C isn't as scary as it seems - in fact I'd rather write Obj-C than Java. Dig deep - thats what we've got the internet for - understanding and learning (well that and porn).

Awareness and Education

So what am I saying? Well for a start I'm not saying we totally abandon the word hybrid and mock anyone who uses it. Hells no. It's still useful as I've already mentioned above. All I ask is that you make sure you know what you are talking about and that the people you are talking to know what you are talking about. That and don't just take the easy route because it's easier for you.

Chutzpah 1.3 Released

2011-11-27T00:00:00+00:00

I missed the announcement last week the Chutzpah 1.3 has been released. This is a big release as it brings support for Jasmine - my BDD framework of choice for JavaScript.

Chutzpah is available as a plugin for Visual Studio but more importantly as a command line runner which allows us to integrate JavaScript testing into our continuious integration builds. Excellent stuff!

Out with the old...

2011-11-25T00:00:00+00:00

… in with the new. So I've started rolling out my new site, expect somethings to be slightly broken as images and whatnot have been moved around. Spent a day or two designing a new site that was similar to the old one but slightly better. Eventually got frustrated at my inability to do any sort of graphical design and went the Octopress.

Still a few things to tweak, possibly add a splash of colour around the place and give it a bit more life. Also apologies to people who subscribe to my feed - looks like the new feed has pushed all the old posts out as new. But hey they are worth reading twice!

Speaking at DevWeek 2012

2011-11-17T00:00:00+00:00

So it's been officially announced that I am talking at DevWeek 2012 in London (26th - 30th March). Looking at the names on the billing it's quite weird seeing my name thrown in there, perhaps some one made a mistake :-P

BDD and .NET

Behaviour Driven Design/Development is an interesting premise, but does it really work? What benefits does it offer and how can we successfully apply its principles in the .NET world? We can answer these questions by reviewing the principles around BDD and diving into the technologies that exist in the .NET world that support these principles.

From low-level unit focused testing technologies all the way up to the more abstract integration and acceptance level suite of specifications, automated testing and continuous integration, we will see that .NET isn’t lacking in choice. As a bonus we will address the oft ignored testing of our JavaScript project components using tools such as Jasmine and QUnit.

The brief was written in haste and sounds a bit boilerplate but I will be giving it my all and really pull off an engaging session. I've been at the attendee end of a few bad sessions and I will do my damnedest not to put anyone through that kind of ordeal.

The line-up for DevWeek looks excellent and the pre/post conference workshops all look stellar - so much choice, I just need to find a way to clone myself.

If you're going - see you there, catch up with me and come throw tomatoes and/or abuse during my session. If you're not going, well sucks to be you then!

Wednesday Tip: C# Type aliases

2011-11-16T00:00:00+00:00

Ever written code that looks quite like this?

Dictionary<string, KeyValuePair<string, string>> cache = new Dictionary<string, KeyValuePair<string,string>();

I have. Ugly and noisy isn't it! <!–more–> OK you could make it slightly less noisy by using var

var cache = new Dictionary<string, KeyValuePair<string,string>();

Or I suppose you could ahead and create yet another random type to abstract the implementation out of the way but thats just too much work for something internal to a class.

Turns out you can make use of alises. I've always known about using alises for namespaces to either resolve possible type conflicts or to make code a bit more understandable

using CoreWeb = System.Web
...
var x = new CoreWeb.Request()

So this works with namespaces AND types.

using Cache = Dictionary<string, KeyValuePair<string,string>();

This allows us to make the declaration above in a much nicer manner,

Cache cache = new Cache();

OK so there are way to many uses of the word cache there but you get the gist. Handy to know. Never knew this until today #youlearnsomethingneweveryday

Innovation Waffle

2011-11-09T00:00:00+00:00

There has been a lot of internal chatter at my employer around innovation. A recent internal Hackathon produced some interesting, innovative stuff for using a Kinect in one of our projects and piqued peoples interest. Oddly enough my dad reminded me of a quote the other day.

“If I had asked my customers what they wanted they would have said a faster horse” - Henry Ford

Creating a faster horse is considered sustaining innovation - you're pushing boundaries but you aren't breaking into new markets. Instead, what Ford did was create the Ford Model T, the first affordable automobile. This disruptive innovation changed everything, breaking into new markets and created value where once no value existed.

To be truly innovative you need both a need and the technology to achieve it. The need doesn't even need to be particularly complex (in Fords case it was the need to go faster), the technology doesn't even need to be revolutionary - just applied in a different manner (in my employers case the Kinect).

But to really succeed in this innovation you need the ability to marry these with something. That something is a vision. Ford realised the need and he was capable of harnessing technology to address that need in such a way as to disrupt the market. This wouldn't have been possible without Fords vision. In fact he didn't even really need to understand the detailed nuances of what the public needed, all he needed to know was the basic premise. Arguably, even if he wasn't the engineer, he could have got someone else to manage the technology. Admittedly this opens up another avenue of discussion - the whole nature vs nurture aspect of innovation - but with a strong enough vision I'm not sure that matters as much.

Vision is the Glue of Innovation

It's great to have a need you want to address, it's even better to be able to apply all sorts of technology to that need but odds are it will all come to nought without a strong vision. Vision is the glue of innovation, while you need both need and technology they'll never really stay together without that binding vision.

GiveCamp Northern Ireland 2012

2011-11-03T00:00:00+00:00

http://givecampni.org.uk/

Aint no backing out now son! In 2012 there is going to be a Northern Ireland based GiveCamp. The “Register Your Interest” placeholder site is now live at http://givecampni.org.uk/ so if everyone can start spreading the word and getting excited that would be super awesome.

Any tips, advice or help at this point is also really welcome.

Let the fun begin….

Nancy JSONP Hook

2011-11-01T00:00:00+00:00

3 Nov 2011: As of Nancy v0.9 this is part of the core (same logic applies)

I needed to write a simple JSONP capable service recently and decided to run with Nancy. Turns out Nancy doesn't give us a way to do JSONP so I set about creating something that fitted my use case. The fruits of my very very short labour (thanks to the super-hyper-flexible-powerfulness of the Nancy Pipeline) can be seen here. The full source is available in the Github repo and hopefully we can get this pushed into the core of Nancy shortly (or at least part of the official repo one way or another) - just for the geek cred of course :)

Implementation Rundown

I took the same approach as the existing hooks (using the SassAndCoffee one as my implementation pattern) so created a static Hooks class with an Enable method that simply adds a new item to the end of the pipeline

/// <summary>
/// Enable JSONP support in the application
/// </summary>
/// <param name="pipeline">Application Pipeline to Hook into</param>
public static void Enable(IApplicationPipelines pipeline)
{
    pipeline.AfterRequest.AddItemToEndOfPipeline(PrepareJsonp);
}

The meat of the work lies in the PrepareJsonp method

/// <summary>
/// Transmogrify original response and apply JSONP Padding
/// </summary>
/// <param name="context">Current Nancy Context</param>
private static void PrepareJsonp(NancyContext context)
{
    bool isJson = context.Response.ContentType == "application/json";
    bool hasCallback = context.Request.Query["callback"].HasValue;

    if (isJson && hasCallback)
    {
        // grab original contents for running later
        Action<Stream> original = context.Response.Contents;
        string callback = context.Request.Query["callback"].Value;

        // set content type to application/javascript so browsers can handle it by default
        // http://stackoverflow.com/questions/111302/best-content-type-to-serve-jsonp
        context.Response.ContentType = "application/javascript";
        context.Response.Contents = stream =>
        {
            // disposing of stream is handled elsewhere
            StreamWriter writer = new StreamWriter(stream)
            {
                AutoFlush = true
            };

            writer.Write("{0}(", callback);
            original(stream);
            writer.Write(");");
        };
    }
}

Let me highlight a few of the key areas here.

Determine if Response need JSONP Padded

I decided to take a basic approach to determining if the request should return a JSONP response,

If the content type of the current response is application/json
If there is a query string parameter called callback

Here is what we need to satisfy that,

bool isJson = context.Response.ContentType == "application/json";
bool hasCallback = context.Request.Query["callback"].HasValue;

if (isJson && hasCallback)
{

I am sure this could be refined and open to suggestion (perhaps more applicable content types or extra possible configuration for the callback parameter). I wonder if it is a bit safer to restrict requests that are GET requests seeing as that is the only way to do JSONP? Hmmmm.

Next thing I set the content type to application/javascript as that makes perfect sense

context.Response.ContentType = "application/javascript";

Finally I wrap the original responses content in the JSONP “padding” (the callback function) and write everything out.

context.Response.Contents = stream =>
{
    // disposing of stream is handled elsewhere
    StreamWriter writer = new StreamWriter(stream)
    {
        AutoFlush = true
    };

    writer.Write("{0}(", callback);
    original(stream);
    writer.Write(");");
};

So all in all very simple but damn I'm proud that I got off my arse and contributed to such a stellar community. hopefully someone finds this useful.

Tinyweb.FluentSecurity v0.1 Released

2011-10-19T00:00:00+01:00

Slight change here - FluentSecurity is now FluentAuth to avoid any confusion with a similarly named product of which there is some inspiration taken. Anyway on with the original post….

I have procrastinated long enough on this and it was blocking some of the other work I wanted to get on with. I have just pushed v0.1 to Nuget and launched the site sans documentation.

Not a great deal has changed since my last announcement, well it has but it hasn't been documented as it should be backwards compatible. Just a few more configuration options that I'll explain once I get the documentation rolled out.

Install-Package Tinyweb.FluentAuth

So go check it out and hopefully you'll find it useful - plenty of plans for expansion to other frameworks and some more API changes coming too. Now back to procrastinating.

refORM: Death to ORMs in .NET

2011-10-17T00:00:00+01:00

CoffeeScript the Awesome

2011-10-10T00:00:00+01:00

refORM: Death to ORMs in .NET

2011-10-10T00:00:00+01:00

refORM: Death to ORMs in .NET

2011-10-10T00:00:00+01:00

Data Access is a difficult area to master. There are plenty of frameworks such as Entity Framework, NHibernate, i/myBatis. These frameworks attempt to make data access simpler but while these products are widely used they can lead to leaky abstractions forcing us to work around constraints of the technology or introduce the nightmare of trying to figure out what is happening deep down in the frameworks internals.

In this session we will look at the various lightweight alternatives and the advantages they offer as well as provide rationale about why the more heavyweight approach isn't always the best approach.

Demo Code and Examples

CoffeeScript the Awesome

2011-10-10T00:00:00+01:00

CoffeeScript - “a little language that compiles into JavaScript” has been making a lot of noise in the web community with its inclusion in Ruby on Rail v3 and its swift rise in popularity on Github.

This session will look at the benefits this language brings over the native JavaScript alternative, the syntactical double rainbow it creates, the problems you'll face and of course how you can actually use it in different technology stacks such as Ruby, node.js, .NET and Java.