Technology Blog

As craftsmanship

Lately there has been a push of software into craftsmanship, nurturing the skill and giving value to building software for the sake of it.

Not a long time ago the main trend was design patterns, inspired by real life architecture the Gang Of Four tried to look for common problems and summarize it into common solutions but these tend to be taught too early and developers lack the knowledge to know how to use them.

So we found Katas and other procedures trying to compensate for the lack of experience that is needed to understand the design patterns but with the experience we obtain the faultier the design patterns seem.

The reason behind this is the clunkiness and the one size fits all approach which seems to fail.

So focusing back on practice we went to the software as a craft, with each person having it’s own technique and experience and expecting that to be enough.

Wikipedia defines craft as ‘…a profession that requires some particular kind of skilled work. In a historical sense, particularly as pertinent to the Middle Ages and earlier, the term is usually applied to people occupied in small-scale production of goods. The traditional terms craftsman and craftswoman are nowadays often replaced by artisan and rarely by crafts-person (craftspeople).’

That sounds very extreme to compare software with something pertinent to the middle ages, I feel that something was missed. We have our personal experience and we know the patterns but there is a lack of knowledge on the direction to which we should mould the patterns to adapt them to our current problem.

As design

In The same wikipedia page we find a reference to the industrial revolution: ‘The mass production of goods by large-scale industry has limited crafts to market segments in which industry’s modes of functioning or its mass-produced goods would not or cannot satisfy the preferences of potential buyers.’

So what did we miss? We have the design patterns, we have the craftmaship but we lack the very important intermedium steps which are represented by the appearance of industrial design.

And back to wikipedia for the definition of industrial design as ‘…the use of a combination of applied art and applied science to improve the aesthetics, ergonomics, and usability of a product, but it may also be used to improve the product’s marketability and production. The role of an industrial designer is to create and execute design solutions for problems of form, usability, physical ergonomics, marketing, brand development, and sales.’

It’s interesting how easy it is to miss these steps but we have to remember that software development is a very new area and in my opinion it’s not harder than any other engineering or design areas, we just didn’t have enough time for it to figure out the big picture.

What can we do

Focusing now on Industrial design, what can we get out of it? Surely all the lessons about turning craft objects into something that can be used and manufactured in a larger scale will be useful. I will now focus on one of my favourite parts which is Dieter Rams.

You might already have heard of his work with Braun as a huge inspiration for Apple’s design but it’s inspiring on how much of these guidelines might also apply to software.

Rams’s Ten Principles of “Good Design” (Link)

Good Design Is Innovative. The possibilities for innovation are not, by any means, exhausted. Technological development is always offering new opportunities for innovative design. But innovative design always develops in tandem with innovative technology, and can never be an end in itself.
My opinion: Try out new tools and techniques but don’t make it be the priority.

Good Design Makes a Product Useful. A product is bought to be used. It has to satisfy certain criteria, not only functional but also psychological and aesthetic.Good design emphasizes the usefulness of a product while disregarding anything that could possibly detract from it.
My opinion: Having too many features, the wrong ones or having them built in a way that seems complicated is much more likely to be a problem with its design and not with the users.

Good Design Is Aesthetic. The aesthetic quality of a product is integral to its usefulness because products are used every day and have an effect on people and their well-being. Only well-executed objects can be beautiful.
My opinion: In the same way as the mantra ‘Clean code is good code’ a design that is almost intuitive will ease the work of the developers and make it more pleasant. I consider in this case the beauty of code to be an appreciation and a feel-good attitude when studying it.

Good Design Makes A Product Understandable. It clarifies the product’s structure. Better still, it can make the product clearly express its function by making use of the user’s intuition. At best, it is self-explanatory.
My opinion: A well done product doesn’t need extensive documentation and preparation. A very good example is the horrific interface of VCRs in the 80s and 90s versus current TV boxes.

Good Design Is Unobtrusive. Products fulfilling a purpose are like tools. They are neither decorative objects nor works of art. Their design should therefore be both neutral and restrained, to leave room for the user’s self-expression.
My opinion: Funny inside jokes or features that are only useful for the team should be left aside to make the real behaviour bubble up. There is room for a brand but there is no room for clever features that only work for the developer’s ego.

Good Design Is Honest. It does not make a product more innovative, powerful or valuable than it really is. It does not attempt to manipulate the consumer with promises that cannot be kept.
My opinion: Build it progressively and organically, don’t think too far ahead.

Good Design Is Long-lasting. It avoids being fashionable and therefore never appears antiquated. Unlike fashionable design, it lasts many years – even in today’s throwaway society.
My opinion: Avoid new trends that have not proven themselves to be useful. Avoid re-inventing the wheel. Ask why the current solutions don’t work and remember that there are reasons why they’ve worked so far.

Good Design Is Thorough Down to the Last Detail. Nothing must be arbitrary or left to chance. Care and accuracy in the design process show respect towards the consumer.
My opinion: Don’t try to force a simplified design if that is not what the user needs, the hard part is making is simple but complete.

Good Design Is Environmentally Friendly. Design makes an important contribution to the preservation of the environment. It conserves resources and minimises physical and visual pollution throughout the life cycle of the product.
My opinion: Amount of data, resources like memory, disk space or hardware are all invaluable and should be taken into consideration even with the cheap price of components nowadays, a brute force approach is not a replacement for a well though design.

Good Design Is as Little Design as Possible. Less, but better – because it concentrates on the essential aspects, and the products are not burdened with non-essentials. Back to purity, back to simplicity.

More inspiration

You just read my thoughts about design, I hope this inspires you to learn more for this and reach your own conclusions. I leave you know with a list of resources which I think are invaluable.

When looking into architecture, design, psychology or any other subject don’t read a book about a developers point of view on the subject but just get to the source.

Objectified – Industrial/Product design (Link)

Urbanized – Urban design/sustainable design (Link)

EAMES: The Architect and The Painter – Post war industrial design and innovation (Link)

MoMa exhibitions about minimalism (Link)

The Coming-of-Age of Software Architecture Research (Link)

Blank City - ”Do it yourself” independent film making. This is more inspiring about the Do-It-Yourself atittude. (Link)

Punk and Minimalism – (fanzine, need to look for a reference)

Bill Cunningham New York – Fashion photographer in NY. Also an inspiration about his emmersive atitude towards his work. (Link)

An interesting parallel occurred to me the other day during a conversation with a colleague: the mood of a team is subject to changes, just as that of an individual, and sometimes depression can set in. So, just as we can learn techniques to fight of depression in ourselves, maybe we can do the same within our teams.

It became clear to me a few weeks ago that my team was in the doldrums: we had come to the end of several significant pieces of work, but had released this work with very little fanfare, which led to a feeling of deflation; furthermore, our future workload was both daunting in size and vague in scope, with few clear short-term goals, which gave us a sense of listlessness; in the past few months, several really talented team members had left us, and we hadn’t yet managed to to find a new dynamic for the team, so we had lost the buzz that comes when collaboration becomes second nature; finally, a raft of factors beyond our control meant that we kept finding our work blocked, which just added another layer of frustration.

I had recently taken on the role of team lead, which meant not only that these issues became a particular problem for me, but also that I had an opportunity as primus inter pares to do something about this. In working to find a way out of this morass, I came to a realisation: I had been here before, and I already knew how to deal with it.

A rich seam of depression runs through my family, and it has been part of my life since childhood. In the past few years I have pushed it into remission, and it rarely raises its head now. However, from time to time I do catch the onset of a spell of depression, and I have identified a set of first-aid techniques that I can use to stop it developing further. Many of these techniques—regular exercise and fresh air, early nights, cutting down on alcohol, making time to read and relax—seem simple and obvious, but these are just the habits that can get sidelined when depression sets in, so I have to treat them as a strict regime and push myself to follow them. The result of this is incredibly effectively for me.

Here are my key actions in fighting the signs of depression:

• I have identified and look out for the early warning signs, so I know when I need to take action
• When I spot these signs, I acknowledge that the situation warrants special behaviour, even if this means putting other priorities on hold
• I have identified specific behaviours that I know help me recover
• I stick with these behaviours until I am back on an even keel

This brings me back to my team’s situation. Of course, the ideal is to develop good everyday habits that keep depression at bay, but while we work on that, we may well find ourselves slipping into the doldrums occasionally. It seems to me that all four of these actions can apply to a team just as readily as to an individual.

I would be interested to hear other people’s experiences of dealing with lapses in team mood, as well as thoughts on how these ideas fit with various codified working patterns. Please share your ideas!

On joining 7digital a year ago I published a short blog on my first fortnight with the new team. Now that our Technical Academy has been running for 2 weeks I’ve asked our 2 apprentices, Chris and Dan, to write a quick blog post about their experience so far. This is our first point in a series of regular feedback opportunities from our apprentices so we’re hoping to tailor the rest of their time here based on their positive and negative experiences so far.

The 7digital Apprentice Developers

Chris posted his “My First Fortnight” post on his personal blog: http://c24w.github.com/blog/2012/09/7digital-Technical-Academy-My-First-Fortnight/

Dan opted to post on the 7digital developers’ blog and his post is here: http://blogs.7digital.com/dev/2012/10/04/my-first-fortn…hnical-academy/

More on the Technical Academy

In early 2012 we were in a position to expand the development team but found that experienced developers, and especially those experienced in TDD, Agile, Lean and XP, were difficult to find. We also found that we were speaking to an increasing number of graduates and under-graduates when publicising the development team at various events, but often noticed a gap between the skills they were learning at University and the skills we’d like them to have. There has been some coverage around this topic recently with opinions from well known UK Software Craftsman Jason Gorman and mainstream media coverage from The Independent and The Next Web.

We decided to attempt to satisfy this need to train inexperienced new starters with a defined programme of classroom based sessions mixed in with the usual “on the job” training. You can see what we originally proposed to teach our new apprentices on the Technical Academy Jobs page although we’ve changed what we are doing based on feedback from teams. We like to continually improve our teams by inspecting and adapting all the practices we adopt and the Technical Academy is no different. This means we’ve added additional sessions on topics we thought we may not need to cover until later, but noticed that the apprentices had been involved in during their day to day work. Our emphasis is still very much on ensuring that apprentices can add business value right from the beginning so being able to adapt in this way ensures they do not slow down development in their respective teams. More on that in a later post.

In addition to the ability to hire less experienced programmers the academy also allows us to hire more diverse people. A good example is our current apprentice Dan, who studied Physics and Systems Biology, which brings a different view point on some of the practices we use, our product vision and the way we approach analytical tasks.

I have joined 7digital as part of the Technical Academy about two weeks ago and I started working in the API team. This is an appropriate stage to write down my first impressions here.

Setup

Setting up my work machine was not always straightforward, mostly with regards to networking and graphics. This is probably because I am working from a laptop, unlike most other Devs who work on desktops. I have made notes on the issues I encountered and will post them on the internal wiki so that new starters don’t have to go through the same difficulties I did. This would be in the spirit of continuous improvement at 7digital.

Classroom sessions

The main difference between the Technical Academy and a normal junior software development role is the inclusion of classroom sessions on the tools (such as C# and ReSharper) and development methods (such as TDD and Kanban) used at 7digital. The best point with these classes is how they are always relevant to the work performed. For example the class introducing mocking happened just after my pair programming partner of the day used it in code we were working on.

Open to different solutions and helpful environment

The team I got assigned to just started making a new internal website. We started to build it using a web framework none of us were very familiar with but was used by some other teams. Unfortunately it proved too difficult to use so we restarted with more familiar technology. Currently I feel like I have gotten up to speed with this project. This is due to the helpfulness of more senior members and the solid tests present in the codebase which allow us to easily verify changes.  Through the rotation of pair programming doubles, I find it interesting to see the small differences in the way people code with the two invariants being rigorous TDD and willingness to help.

Rollback

In another project my team released, we didn’t perform testing as thoroughly as we should have. This broke some of our client’s apps and required a late night rollback. Most of the following day my team worked a retrospective of the rollback. This retrospective involved finding out what caused the issues leading to the rollback and how similar issues could be avoided in the future. I found it great that the focus was on problem solving and improvement and not shifting blame.

Friendly office

The general workplace atmosphere is important and in that aspect 7digital does very well. Everyone is friendly and approachable and most interactions are informal. Furthermore the pace is set to be sustainable so working long hours is discouraged (but it doesn’t mean we don’t work hard).

Dan Kalotay

The pain

As the Ops team grew and Devs teams grew, it became a recurrent task to be asked by the Ops team to test infrastructural changes.

This didn’t use to be a problem, the teams were smaller, we had less features and the infrastructure was much simpler but they became a blocker for both teams as they have to be working simultaneously on the same task.

Even though we have Unit Tests, Integration Tests, Acceptance Tests and Smoke Tests and they run every time there is a new build (Continuous Integration) we feel the pain of infrastructural changes as these tests are not run for every change done by the Ops team.

Also, Ops working with every single Dev team made the problem even more serious with Dev teams becoming blocked due to the infrastructural work of other Dev teams which might not be related as well as Ops being used as a shared resource.

Even when both teams are synced to test a change there isn’t the knowledge on the Ops side to know how much testing is enough. This is due to the fast pace of development and Ops needing to be up to date with the knowledge of how the features work – this is a nice problem to have but needs to be solved.

Metaphorical wall between devs and ops..

Our idea

In a perfect scenario we would have enough people on the Ops side so that they can run side by side with Dev and be up to date with feature changes but that doesn’t happen and we can’t expect Ops to know every single feature and application. So a second option is making this as automated as possible to make problems be caught fast as they do on the Dev side but without having Ops do extra work.

Our solution for this was adding infrastructure to the continous delivery system but as we don’t need to know when these changes are done we use an active wait to run the necessary tests.

TL;DR: We made Smoke tests more concise, running continuously over fixed periods of time and easily accessible by everyone.

Make it visible as fast as possible

How we got there

A common scenario to test infrastructure would be running Smoke Tests to make sure the end to end path for a feature works. In my current team, it would be something like Downloading a music album or Streaming a track.

Reviewing the current tests there were some issues trying to simplify and slim down the tests:

Large number of Smoke tests - Might be a smell that the application is trying to do too much and it will also slow down the overall time to assess the state of the application.

Ambiguity between Smoke tests and Acceptance tests – a Smoke test is a feature/edge case with a happy path. In my opinion, a Smoke test is a specific type of Acceptance test. Smoke tests shouldn’t do tests for parameter validation, missing data or other types of test that require very specific set-up. Even worse, having a specific set-up for Production Smoke tests means we’ll have static test data as we don’t want dynamic test set-ups in that environment.

Slowness to test – If we already have Smoke tests down to a minimum but running the suite still feels slower than it should then maybe it is a performance issue. Is the performance being tracked?

Using Continuous Integration software for Smoke tests means that Ops has to use yet another tool. They should be able to have information about the state of an application without needing to go to the team.

Configuration is within the application – It is not obvious that if an application’s stack is changed that we can try to Smoke test that variation without a new build.

Status of Ops changes is not visible – Until an environment’s Acceptance and Smoke tests are run, there is no information about external changes. This actually makes us lose the advantages of Continuous Integration and move closer to the concept of a Nightly Build…

Measure it before changing it

Some simple steps that are being done to try and fix it:

Review all Acceptance and Smoke tests to make sure they don’t overlap and that only essential Smoke tests are being performed.

Host information should be available in the runner so new variations can be tested within minutes. This also makes a case for keeping configuration outside a build.

Continuous run of Smoke tests in every environment including Production – it would be useful to know when a specific path breaks while working, giving all teams information about the stack as a whole.

Visibility of Smoke tests results - Moving closer to the concept of a status dashboard, the smoke tests should be able to be checked through an API and screen by all teams.

The increasing number of metrics being kept – Measuring API responses and number of errors will provide more information about response times, error baselines and more.

David Bowie knows about changes

What we have so far:

Ops changes can be more aggressive, they don’t have to wait and we’re not afraid to fail as this is done quickly and very early in the infrastructure.

This isn’t new but it was good to bridge concepts from the Dev team into the whole of the stack and it has allowed us to move faster to bring more servers up and add new tools without hurting current infrastructural dependencies.

Like many companies we’ve been struggling with a problematic pay review process. In our case the feedback mainly revolved around it feeling arbitrary and lacking transparency.

Around the time we were discussing this the Valve Handbook got posted, within which it talked about their peer review & stack ranking system:

“We have two formalized methods of evaluating each other: peer reviews and stack ranking. Peer reviews are done in order to give each other useful feedback on how to best grow as individual contributors. Stack ranking is done primarily as a method of adjusting compensation. Both processes are driven by information gathered from each other—your peers.”

Awesome, you get rated by your peers rather than a manager or HR person, who has no idea what you do (not that we did that anyway)! I liked this idea a lot and got to work on doing our own version.

I started with a trial peer review survey with one team. There were some positives, but it mostly went down badly. People really didn’t like the stack ranking and also that I only asked a few high level questions with the answer being a score out of 10.

So we went back to the drawing board. We got representatives from all our teams and held 4/5 sessions where we broke down the larger themes (Skill, Productivity, Communication, Team) into more detailed and objective questions. After a lot of persistence and effort we finally put this all together and we had the survey!

Which I promptly canned…

Trying to measure performance

The fundamental problem I was (naïvely) trying to solve with a peer review survey was to bring in a degree of measurement, which would hopefully mean people felt the pay review process had a quantifiable aspect and didn’t just come down to one person’s opinion. However we were getting into the terrain of incentivising our people based on individual optimisations (rather than organisational or team goals & objectives) and – most disturbingly – the anonymous feedback aspect just felt very wrong. It was and is completely contrary to our culture and the things we stand for. The trade-offs simply weren’t worth it.

Regardless of the unpleasantness of anonymous feedback, everywhere I’ve heard of using ranking/measurement schemes have really bad stories to tell, such as Microsoft and GE.

Warning signs everywhere.

Don’t mix pay reviews with feedback

Another problem is the survey would have been a kind of feedback mechanism. Imagine getting your results – all nicely presented in bar charts – and finding you scored really badly on one section. What the heck are you supposed to do with that?! I’m a really bad communicator? What do they mean by that? Who thinks that? Great, everyone thinks I’m rubbish but I’ve got no way of finding out why apart from going around everyone and asking them. Ouch!

I am a big believer in regular 1-2-1s (I’ve talked about them a bit here). As Head of Development I start every day with a 1-2-1 with one of my department (I see all 35+ people as regularly as I can). Each team also does 1-2-1s (usually with their Lead if they have one). Each new joiner gets a mentor who they have a monthly 1-2-1 with for their first 3-6 months.

By the time you get to a pay review their should be no surprises, no feedback that you haven’t already heard before.

Where we are now

Our latest attempt is heavily based (& in some parts very plagiarised, I have to admit) on the StackExchange compensation scheme.

The peer review survey wasn’t a complete waste. I adapted the themes and questions from the survey we built into a set of core values we desire from our colleagues to be used for guidance. This is still very new and as yet unproven, but it certainly feels a lot better than where heading previously. I could explain in more detail, but it would be duplicating what I’ve said in the document/guide, which you can download here:

7digital Dev & DBA Team Compensation

Finally, a word on annual performance appraisals

I’ve only been employed by one company who ran annual performance appraisals and was far from impressed. It’s something we’ve consciously avoided for our tech teams at 7digital. I could go into more details as to why they are wrong, but others much more qualified than me have already done so:

The Paradox of Performance Pay – a really great article/opinion piece by Dr Allan Hawke , a former chief of staff to Australian prime minister Paul Keating, a former federal departmental secretary and a former senior diplomat. http://www.canberratimes.com.au/national/public-service/the-paradox-of-performance-pay-20120430-1xtys.html

W. Edwards Demming talking about performance appraisals as one of the five deadly diseases of management. http://www.youtube.com/watch?v=ehMAwIHGN0Y&feature=youtu.be&t=5m

An article in HR magazine on a study of British workers showing huge dissatisfaction with how performance appraisals are run. http://www.hrmagazine.co.uk/hr/features/1015028/hr-directors-try-harder-engage-employees-appraisals-process

Over the last month we’ve started using ServiceStack for a couple of our api endpoints (go to the full ServiceStack story here) . We’re hosting these projects on a Debian Squeeze vm using nginx and Mono.

We ran into various problems along the way which we’ll explain, but we also managed to achieve some interesting things; here’s a summary. Hopefully you’ll find this useful.

Nginx

We’re using nginx and fastcgi to host the application. This is good from a systems perspective because our applications can run without root privileges.

For the communication between mono-fastcgi and nginx, we are using a unix socket file instead of proxying through a local port. This makes configuration much easier, as you map applications to files rather than port numbers, so the convention rules for this are much more straightforward. (Besides, you may be hit by a memory leak if you don’t use unix socket files.)

Furthermore, using files instead of ports has made our life easier for automated deployments because:

• We can just specify the socket file based on the incoming host header. This way you only need one app configuration in nginx for N sites. The key here is to use the variable $http_host in the fastcgi_pass setting of our nginx config file. Example:
• We can decouple deploy from release, and the latter will be an instant operation that doesn’t require a restart of the app or the webserver. The deployment procedure is therefore as follows:  
  1. Copy new release to servers.
  2. Start app server for new release listening on a different unix socket file than the current working release. i.e. /tmp/SOCK-myFqdn-newrelease. (We use nohup for this.)
  3. Do some test requests on the new release to verify that it works, using a custom host header that matches the unix socket file pattern used in step 2.
  4. Make a hard link (not symlink) on the current release to have a backup.
  5. Move the unix socket file of the new release into the the current release: i.e. “mv /tmp/SOCK-myFqdn-newrelease /tmp/SOCK-myFqdn”.
  6. Kill the old release.

The key step is (5) here. By moving the new release into the old release, without moving or removing the old release socket file before, we manage to decouple deployment operation from release, with an “atomic” mechanism which gives us zero downtime (we tested this with siege, a very interesting load testing tool, configured with 100 concurrent connections), without the need of adjusting load balancers as part of the deployment.

We’re still studying the best way to do step (6). For now, we just wait briefly to be sure the app has finished serving/processing the last requests. The problem with this approach is that we need to record the PID of the app to be able to kill it later (because lsof hasn’t worked in our scenario, after much testing, either after step 5, using the hard link, or before step 4, using the normal file; so we need to use pgrep after step 1 for now). We’re studying stopping the application via a final HTTP request (with the DELETE verb on the status endpoint maybe? sounds about right :) ), but calling Environment.Exit() from a web application doesn’t look right.

Capistrano

So, to be able to deploy to many servers at once, we use capistrano to launch the ruby scripts that control the 1-6 steps mentioned above. Another interesting thing we do with capistrano is configuration.

Many .NET developer teams are in the habit of managing configuration files at the app level, naming them with extensions that map to the environment. This is pretty handy because as a developer you have all the configuration values of all the environments right there in your IDE, in case you want to explore something.

But it has a big drawback: any configuration changes need to be done in the same repository as the code, which has the following consequences:

• Configuration changes end up in the long chain of continuous integration; you have to wait for building and testing infrastructure for your change to go through and be able to deploy it.
• Configuration ends up being mainly a developer-task. Sure, DevOps techniques now encourage this by trying to involve developers more in system administration and configuration, but in this case it is a drawback because it renders the systems team incapable of doing configuration changes because they are not normally familiar (and aren’t supposed to) know what’s the src/ sub-folder structure to locate the config files, and they don’t typically use the CI tool to see whether their configuration change has affected some test-suite.
• Sometimes configuration files end up being almost exactly the same between environments, only differentiated by one or two values. This makes locating errors in the config files a daunting task.

So we decided to implement the configuration at the deployment level: There is a base configuration file in the sources which contains default values. In a different repository, for each environment there is a ruby configuration file that only has the values that need to change, i.e.: production.rb, uat.rb, etc. This file simply contains variables whose name is the appSetting key and value needs to be replaced before deployment, or a hash map in which each key is an XPath expression to look for the proper node in the XML config file. Example:

This way we decouple implementation from configuration completely. If there are red builds all around your CI environment, you don’t need to do fancy things with stable branches to do configuration changes in production. Systems team could scale the application by adding new servers, without the developers knowing about it…

Mono

We’re using version 2.11.3. There are various bug fixes compared to the version that comes with Squeeze; namely, problems with min pool size specified in a connection string. Rule of thumb, if there’s a bug in mono then try the latest!

For build agents we use an even higher version, 2.11.5 (which has not been tagged yet and to get it, you need to clone the master branch), to be able to use xbuild with F#. There were some issues that we fixed to make this work both in the Mono repository and in the fsharp repository. (We found Mono to be faster than .NET when compiling builds and running tests!)

NB: Our systems team has helped a lot in ironing out the kinks of all this, kudos to them!

Over the last month we’ve started using ServiceStack for a couple of our api endpoints. We’re hosting these projects on a debian squeeze vm using nginx and mono. We ran into various problems along the way. Here’s a breakdown of what we found and how we solved the issues we ran into. Hopefully you’ll find this useful. (We’ll cover deployment/infrastructure details in a second post.)

Overriding the defaults

Some of the defaults for ServiceStack are in my opinion not well suited to writing an api. This is probably down to the frameworks desire to be a complete web framework. Here’s our current default implementation of AppHost:

For me, the biggest annoyance was trying to find the DefaultContentType setting. I found some of the settings unintuitive to find, but it’s not like you have to do it very often!

Timing requests with StatsD

As you can see, we’ve added a StatsD feature which was very easy to add. It basically times how long each request took and logs it to statsD. Here’s how we did it: It would have been nicer if we could wrap the request handler but that kind of pipeline is foreign to the framework and as such you need to subscribe to the begin and end messages. There’s probably a better way of recording the time spent but hey ho it works for us.

RestServiceBase, Exceptions and Error Responses

One of my biggest bugbears with ServiceStack was the insistence on a separate request and response object, the presence of a special property and that you follow a naming convention all in the name of sending error and validation messages back to the client. It’s explained at length on the wiki and Demis was good enough to answer our question.

RestServiceBase

The simple RestServiceBase that comes with provides an easy way of getting started, but there aren’t many hooks you can use to manipulate how it works. It would be nice if you could inject your own error response creator. We ended up inheriting from RestServiceBase and overriding how it works:

We basically chopped out the bits we’re not using and changed the thing that creates the Error Response:

This allows us to respond with an error no matter what the type is for the request or what response you are going to send back. It provides us with extra flexibility above what is provided out of the box. In a nutshell, if there’s an exception in the code we will always get a stack trace in the response if debug is on.

Validation

We had the same issue with the validation feature; if you don’t follow the convention you don’t get anything in the response body. So we followed the same practice and copied  the ValidationFeature and tweaked it how we wanted it.

Conclusion

I like ServiceStack; it’s really easy to get up and running and whilst it has it’s own opinions on how you should work, what framework doesn’t?

The article we posted on our development team productivity back in May got picked up by Derek Jones – a keen enthusiast of statistical analysis, R and how/if we can apply more empirical (and meaningful) measurement to software development, a worthy but daunting challenge! We were more than happy to give Derek the raw data behind our productivity stats and very keen see what he could do with it (particularly as my statistical analysis skills are questionable at best).

Derek has written up is findings on his blog, titled Descriptive statistics of some Agile feature characteristics. Some of this is pretty intense and will no doubt be causing flash backs for many (mild sweats & panic, recurring dreams of not having prepared for exams), however you can skip over the explanations for calculations (if you wish) and see some really interesting ways to model and represent the data. Unlike our report Derek has wisely chosen not to attempt to draw conclusions or make predictions, but merely pose data in interesting ways, allowing us to draw our own.

Derek’s analysis of our data will also be appearing in the book he is currently writing, Empirical Software Engineering with R.

If you have any comments please leave them on Derek’s blog – I know he’d really appreciate the feedback.

We’re hoping to keep the streak of awesome talks we’ve had at our previous two events going! We have our next event planned for the evening of the 13th September, which will feature a talk from Matthew Cooke on “DevOps, NoOps, UnrulyOps” (a very exciting topic these days!), and a second talk from our own Hibri Marzook on “Test Feedback”. There will also be beers, tea & coffee and some light nibbles.

Please sign up for the event on Meetup.

We also have a Twitter account from which we announce upcoming events – @DevsInTheDitch.