The last week of work is a strange affair. Time assigned for finishing off work, writing that “What’s wrong with the company and Here’s How To Fix It” document inevitably vanishes amidst joking with friends, telling people how you REALLY feel about other people (behind their backs of course), performing the inevitable countdown performed by all men previously thought condemned but who’ve now been reprieved (“This is the last Monday at 1:56pm I’ll ever have to worry about”). And that’s cool and all, but I’m already bored by it! I want out! All the actual and metaphorical debriefing that could be done has been done, and all I’m left with is an increasingly small amount of time left in which to get something done – or should I say something I actually want to do. Its only Monday afternoon and already my apathy has soared to new heights. Next thing you know I’ll be turning up to work in my dressing gown. Roll on next week…
Continuing in my brief series of posts on the wonder of @sed@, this time we will be looking at using @sed@’s addressing features to generate code.
For years now I have extolled the virtues of the SuSE Linux distribution on the basis of it coming with every application under the Sun (yes, including a JDK!) and the fact that YaST is an excellent install and administration program, far better than any other distributions (this was certainly the case a couple of years ago, I’m not sure about now). Therefore the news that Novell are to “open source YaST(Novell management tool going open source)”:http://news.com.com/2100-7344_3-5175682.html?tag=nefd_top does leave me with mixed feelings – on the one hand you’ll now have no problems downloading SuSE with “YaST”:http://www.suse.de/en/private/products/suse_linux/i386/yast.html for free, on the other hand other distros are now free to include it therefore potentially reducing the target audience for what is an excellent distribution. Either way an open source YaST can do nothing but promote Linux as a whole.
I had the pleasure of chatting to Jon Tirsén last night. Amongst one of the many topics we discussed, was his Ruby-based Continuous integration build tool “DamageControl”:http://damagecontrol.codehaus.org/builds/damagecontrol/docs/index.html. Designed as the replacement for “CruiseControl”:http://cruisecontrol.sourceforge.net/, DamageControl offers much more flexible framework, and has been running the “codehaus”:http://www.coudehaus.org builds for some time now.
“Continuous Integration(Continuous Integration by Martin Fowler and Matthew Foemmel)”:http://www.martinfowler.com/articles/continuousIntegration.html is the development practise whereby each CVS checkin results in the code being built and tested automatically – in this way encouraging frequent checkins and resulting in people having the most up to date code, and reduces integration issues.
After asking how development DamageControl was going, it turns out that Jon is looking to re-implement it in Groovy. Given that Jon seems to be such a fan of Ruby (I’ll stop short of saying ‘zealot’ as I don’t know him that well) this was a surprising admission. The main reason cited was that Java-based programs have nicer deployment mechanisms than Ruby’s (or most scripting languages) text files. Personally, the reason seems to have a lot more to do with the current mind share of groovy, and the fact it is based on a far more popular platform, in the form of Java.
A Continuous Integration tool is (potentially) such an important part of an Agile development methodology, that a well-maintained, flexible tool is very important. By basing it on the Java platform the number of developers available to help develop and maintain a system must surely outweigh the number of Ruby developers out there. Also the fact that the majority of agile development itself is done using Java, means that those companies using a Java-DamageControl are more likely to have the expertise in-house to administer, support and extend the program, and would therefore be more willing to use it. I would also hazard a guess that movement from Ruby->groovy, with groovy’s Ruby-like features would be much less work that a move from Ruby->Java language.
We also briefly discussed the recent “Groovy JSR(JSR 241: The Groovy Programming Language)”:http://www.jcp.org/en/jsr/detail?id=241, and agreed that the important point wasn’t that it was groovy itself that was being submitted, but that another language based on the Java platform was being submitted. .net has stolen a march on Java, basing multiple languages on its common-runtime (C#, VB, J# etc). Java is just as suited to this kind of approach as .net, and it is time we started seeing Java as a platform rather than a language. This is certainly something MS has achieved quite well (in marketing terms if nothing else) and is definitely something Sun et al can learn from. Hopefully we’ll start to see other languages being submitted to the JSR in this way – I just hope that they won’t have to have the backing of big name companies to achieve this (groovy is backed by the Apache Software Foundation, BEA and ThoughtWorks).
Following up my “previous post(A brief history of ed, sed and Regular Expressions)”:http://www.magpiebrain.com/archives/000199.html on @sed@, I thought I’d post a little tutorial on using @sed@ and @grep@ for the purposes of cleaning up logfiles. To follow the examples you’ll need @sed@ or @grep@ for your platform.
As “promised(A brief history of ed, sed and Regular Expressions)”:http://www.magpiebrain.com/archives/000199.html, I’ve found a nice script which will allow you to edit the original files using @sed@, making running @sed@ on multiple files much more useful. The script come from O’Reilly’s excellent “UNIX Power Tools”:http://www.oreilly.com/catalog/upt3/ (which is probably the most useful book on actually using Unix/Linux/cygwin that I’ve ever read), and can be viewed on the “UNIX Power Tools Examples(http://examples.oreilly.com/upt3/#runsed, 3rd Edition – runsed)”:http://examples.oreilly.com/upt3/#runsed site.
The shell script @runsed@ was developed to make changes to a file permanently. It applies your @sedscr@ to an input file, creates a temporary file, then copies that file over the original. @runsed@ has several safety checks:
- It won’t edit the @sed@ script file (if you accidentally include @sedscr@ on the command line).
- It complains if you try to edit an empty file or something that isn’t a file (like a directory).
- If the @sed@ script doesn’t produce any output, @runsed@ aborts instead of emptying your original file.
@runsed@ only modifies a file if your @sedscr@ made edits. So, the file’s timestamp (Section 8.2) won’t change if the file’s contents weren’t changed.
Also of possible interest is “checksed(http://examples.oreilly.com/upt3/#runsed, 3rd Edition – checksed)”:http://examples.oreilly.com/upt3/#checksed, which unlike @runsed@ simply provides a @diff@ allowing you to check the changes your @sed@ commands will make. Very handy before you start thinking about running @sed@ on several thousand files!
I was about to post some helpful tips on using @sed@ to generate code, but thought a brief introduction of @sed@ was in order.