UNIXDAEMON Small Mosaic

Categories:

/books
/career
/cloud
/events
/firefox
/geekstuff
/linux
/meta
/misctech
/movies
/nottech
/perl
/programming
/security
/sites
/sysadmin
/tools
/tools/ansible
/tools/commandline
/tools/gui
/tools/network
/tools/online
/tools/puppet
/unixdaemon

Archives:

September 20142
July 20141
March 20146
February 20141
January 20145
December 20135
November 20132
October 20134
August 20134
July 20132
June 20131
May 20131
Full Archives


Sun, 27 Jun 2010

The ThoughtWorks Anthology - Short Review

The ThoughtWorks Anthology is a collection of short articles and essays written by a number of their employees (some of who are now ex-employees) about software development with a heavily agile slant. The topics range from the very high level "Lush Landscape of Languages" and "What is an Iteration manager anyway" to the more technical and technique focused "Refactoring Ant Build Files" and "Object Calisthenics".

While the general quality of the writing is very good, especially my favourite - 'Object Calisthenics', the biggest problem with a book like this is that a lot of the essays authors, and some of their also knowledgeable co-workers, have personal blogs where this quality of information is available on a (near) daily basis, in both greater depth and more a conversational nature.

Posted: 2010/06/27 08:37 | /books | Permanent link to this entry


Sun, 06 Jun 2010

Netbeans vs Commandline

The last time we interviewed for Java developers (a couple of jobs ago) it came as quite a surprise at how few of them could function without their IDE of choice. A high percentage of the candidates struggled to compile using javac, had problems navigating the docs and made a large number of very simple syntax errors that they were obviously used to their editor dealing with.

At the time the more unix focused team, most of who were very long term vim and emacs users, had a number of discussions about how this should impact our rating of the candidates. One school of thought was that people should use the tools that make them most productive. The other was that people should understand their tool chain. How can you diagnose issues on a production server if you can't even compile a class on the command line? You can tell which side I was on.

I've recently joined a small Java project and after some awkward fiddling around with ant, junit and half a dozen other jars decided to give Netbeans a chance. I was pleasantly surprised at how quickly and easily I got the same project up and running in the IDE. I don't yet have a clue how it's storing the files on disk, constructs the build or test targets and a dozen other little details but at this stage in my basic use of Java it doesn't seem to matter.

It's strange how quickly seductive all the optional extras can be and how easy it is to lose track of what you don't know while adapting to the features they offer. I'm not sure how much of it is better tooling, benefits of a strongly typed static language or just having a dedicated team behind producing a consistent development environment but it felt very easy to take baby steps with. And I'm hoping the tool continues to show me more power as my needs when using it grow.

While I'm at no risk of giving up vim for my day to day work I think I'll be investing some time in to learning one of the big three Java editors (Eclipse, Netbeans or IntelliJ) for while I'm away in the strange world.

Posted: 2010/06/06 12:11 | /tools | Permanent link to this entry


Thu, 03 Jun 2010

Obese Provisioning - Antipattern

One antipattern I'm seeing with increasing frequency is that of obese (or fat, or bloated) system provisioning. It seems as common in people that are just getting used to having an automated provisioning system and are enthusiastic about its power as it is in longer term users who have added layer on layer of cruft to their host builder.

The basic problem is that of adding too much work and intelligence to the actual provisioning stage. Large postrun sections or after_install command blocks should be a warning sign and point to tasks that may well be better off inside a system like Puppet or Chef. It's a seductive problem because it's an easy way to add additional functionality to a host, especially when it allows you to avoid thinking about applying or modifying a general role; even more so if it's one that's already in use on other hosts. Adding a single line in a kickstart or preseed file is quicker, requires no long term thinking and is immediately available.

Unfortunately by going down this path you end up with a lot of one-off host modifications, nearly common additional behaviour and a difficult to refactor build process. A tight coupling between these two stages can make trivial tasks unwieldy and in some cases force work to be made to remove or modify the change for day to day operation after the build has completed.

A good provisioning system should do the bare minimum required to get a machine built. It should be lean, do as little as possible and prepare the host to run its configuration management system. Everything else should be managed from inside that.

Posted: 2010/06/03 21:37 | /sysadmin | Permanent link to this entry


Tue, 01 Jun 2010

PuppetCamp Europe 2010

To me puppet has always been a major evolutionary step up on the sysadmin tool chain. I consider it important enough to be ranked alongside version control systems and virtualisation as one of those mental leaps that leads to better management and enables more flexible solutions than you could offer before understanding it.

While I'm quite a long term member of the puppet community I'm no where near as active as I should be, but even I couldn't miss the chance to attend PuppetCamp Europe, and I'm glad I didn't! I finally got to meet some of Europes most prolific puppet module releasers in person, discovered that Brice is every bit as nice and as scarily smart in person as he is on-list and that the new PuppetLabs people are a very impressive bunch. Even I've still not had the chance to buy James some of those beers he's racked up over the years on the list.

Puppet may be an open source project but a very high proportion of its development and community support has always come from Puppet Labs, so it's critical to both the product and the users that their staff be as good with the community as they are with the code base, and having met half-a-dozen of them I can honestly say it feels like the project is in safe hands. Jeff gave an excellent talk on using Puppet in environments with strict compliance rules, Markus had a razor sharp grasp of what people were really asking (and gave the answer to what they wanted, not just what they asked) and Luke made the event for many of us, he very patiently gave a lot of advice and information not just about the now but also about the historical whys and theoretical hows.

I had an excellent time (Ghent itself is a lovely place to visit for a couple of days) so I'd like to thank Patrick for organising the event, Luke and Puppet labs for Puppet itself and the participants for making PuppetCamp Europe 2010 such an educational and enjoyable experience.

Posted: 2010/06/01 20:45 | /events | Permanent link to this entry


books career cloud events firefox geekstuff linux meta misctech movies nottech perl programming security sites sysadmin tools tools/ansible tools/commandline tools/gui tools/network tools/online tools/puppet unixdaemon

Copyright © 2000-2013 Dean Wilson :: RSS Feed