When attending a security training for developers last week, I was astonished to find a security professional without programming background as our trainer. He mostly talked in waterfallish terms, just as I had done a decade ago when I was more interested in IT security than the physics I studied at university. So I began wondering about the role of security in agile development.

Security on the product level

As agile developers, we optimize our code for flexibility, so we can change it easily at any point in time. In this world, security at the product level is nothing more than a feature to add whenever it makes sense. It becomes a matter of continuous risk management, which feature prioritisation is anyways.

We might start a new product without any security whatsoever, because who needs security when we have no clue how to solve our business logic problems in the first place? However, with each feature our risk profile changes and we have to reassess our situation. We better implement that login functionality before we go into public beta, but maybe it’s still ok to run without any encryption. Once we launch the product, we better protect our servers with TLS and encrypt sensitive data in the database.

Security on the code level

The story changes, however, when it comes to our daily coding practice. I consider security another code quality like good design or freedom from defects. Just as we use practices like TDD or Continuous Integration, we should use secure coding practices like input validation and output encoding. These practices need to be embedded in our daily practice. We have to make ourselves aware of the trust boundaries where we need to apply them.

What secure coding practices do you use? Let us know in the comments!

When I remodeled my flat 1 year ago, I chose to downsize my desk and put the PC in an underused corner of the living room. The problem there was, that the corner isn’t too wide, just 114cm. As most desks have a minimal width of 120cm, I was happy to find IKEA’s Vika line with the Vika Amon tabletop just 1m wide. Together with two Vika Lage legs and a Vika Annefors table leg with storage space to hold my PC it cost me just 43 Eur. As the Annefors is quite wide, I moved it a couple of cm to the side and gained some space to put small stuff like my mobile and wallet.

Every now and then I came across someone mentioning their move to a stand-up desk to counter the ill side-effects of sitting all day. One day I figured I’d give it a try, borrowed my girl friend’s ironing board, put some books on top and my laptop on top of those.

It didn’t take me much getting used to and I was quickly oscillating between ironing board and couch with my laptop. Happy as I was, at some point my girl friend needed her ironing board back, so I decided to upgrade to some kind of IKEA hack solution.

After discussing several options with my girlfriend, we settled on buying a second tabletop with some wooden legs to cut to proper length. While searching for the items, we came across the Lack side table for just 5 Eur. We quickly realised, that this was the perfect solution and bought two.

These side tables mix perfectly with my Vika table, but together they are 10cm wider than the Amon tabletop. As described above, this wasn’t much of a problem for me, as I had positioned the Annefors a little to the side. This gave me an effective width of about 114cm to work with. So we cut the side table’s legs, left 2 of them a little longer to compensate for the missing tabletop on the side and there was my new stand-up desk. This is how it looks:

Patrick Debois, the godfather of DevOps, recently posted an article called Puppet unit testing like a pro. This article spawned some discussion about cucumber-puppet usage and how to get started. As I wanted to develop some ideas about this anyways, I setup an example project on github. You can follow the commit history to see how the project evolved and how I currently think cucumber-puppet should be used:

• On a global scale, use a catalog policy to ensure all your node catalogs obey the same basic rules.
• Use module specific features to specify behaviour in manifests, templates, custom functions, etc.
• Don’t repeat your manifests in your features, however. There’s no value in it.

This exercise verified my thoughts on some technical aspects of cucumber-puppet. The goal of this project should not be to provide step definitions for all kinds of scenarios, but instead provide basic helper methods that empower people to implement the steps they actually need. I want you to implement step definitions on your own, however, you shouldn’t have to dig through the puppet source to do so.

This was a great learning experience for me.

What do you think, is this going in a sensible direction? Are there any specific things you would like to see in the example project? Let me know in the comments!

The other day I started programming a new feature which quickly turned into a major rewrite of some legacy code. As I am pretty new to programming, it took me several attempts writing tests and code to consolidate my ideas. The process was quite laborious as I only ever detected design flaws when I saw the code written in front of me. With each iteration I also adapted my unit tests, renaming methods and objects etc.

While doing all this, I wondered about the merits of test-driven development. Weren’t my tests supposed to drive the design of my code? How come I only ever figured out something was wrong, when I saw the final code and its usage pattern? At that time I shrugged these thoughts off and attributed my problems to poor design skills.

A couple of iterations and days later I had again read lots of stuff about object oriented design, the SOLID principles, Tell, don’t ask, Test-Driven Development, you name it. At that point I suddenly noticed a correlation between some idiom in my tests and a breakage of the Law of Demeter in my code. I didn’t really believe in a connection between the two, but still I tweeted it.

Luckily David Chelimsky, the author of RSpec, noticed my tweet and inquired about my code. When discussing the issue, he pointed out that my Demeter violation was actually hinted at by some other characteristic of my tests, I was using and_return() in combination with a message expectation. This conversation primed my interest in test smells and off I went for more reading and watching conference presentations.

Slowly it dawned on me, what these people meant, when they say “Listen to the tests”. Tests have a form of elegancy of their own. When they lose this property, they are telling you about some broken design principle. Combining a message expectation with a stub, like I did in my code, hints at a violation of the Law of Demeter and the Tell, don’t ask principle. The problem with elegancy, however, is that you have to learn to detect it.

What have I learned from all this?

It looks as if test elegancy is not just a matter of taste, but there seem to be certain patterns to it:

• having a message expectation return a value hints at a violation of the Law of Demeter and the Tell, don’t ask principle (“mock actions, stub queries”)
• the more collaborators an object has, the higher the chance it does too many different things
• test setup should be simple, too many test doubles hint at a method that does too many different things
• write tests with only minimal requirements
  • explicitly require necessary modules, the list should be short (don’t just include all Rails, for example)
  • use strings as identifiers for test doubles, not constants, to keep collaborators out of the list of modules to load
• when using external libraries
  • put an interface in front and test it with focussed, state-based integration tests
  • now you can mock this interface in your unit tests, don’t mock the external library itself

Where do I go from here?

For me, it’s time to go through Growing Object-Oriented Software, guided by tests again. This time I won’t just read it superficially, however, but instead work through the text and examples more intensely.

What do you think of this? Does it make sense? Do you have any test smells to share? Let me know in the comments!

When I began testing puppet catalogs with cucumber-puppet, I soon stumbled upon the problem of exported resources. As cucumber-puppet does not deal with database connections out of the box, it was at first glance impossible to test, e.g. if your nagios server was configured properly from a service module. This weekend I finally took the time to look at the way puppet uses exported resources and realized an easy way to make them work with cucumber-puppet.

The main trick is to use an sqlite3 in-memory database so that cucumber-puppet won’t have to connect to any external database or mess with the filesystem too much. With the database in place, you can access exported resources through their model class Puppet::Rails::Resource. I used database_cleaner to ensure empty databases between scenarios. The only nuisance so far is, that puppet will want to create several directories with storeconfigs activated, so we have to manage a temporary directory.

Here is a sample usage of exported resources with cucumber-puppet:

I plan to add proper support for exported resources to cucumber-puppet in the future, but this blog post should be enough to get you started.

Was this blog post helpful to you? Do you have any ideas on improving cucumber-puppet? Let me know in the comments!