Leonard Axelsson

GroovyCSV updated to 1.1

2015-11-09T00:00:00+00:00

GroovyCSV updated to 1.1

It’s been a couple of years and it’s time for a small update to GroovyCSV. There’s a been a bug fix or two but the main news is the option to get a map representation of your csv’s line-data. A feature contributed by gmazelier. Thank you!

Example: Getting a map representation of a line

It’s now possible to get a map representation of your line data using line.toMap().

Example:

@Grab('com.xlson.groovycsv:groovycsv:1.1')
import static com.xlson.groovycsv.CsvParser.parseCsv

def csv = '''ProjectName,Version,Year
GroovyCSV,1.1,2015'''

def data = parseCsv(csv)
for(line in data) {
    println line.toMap()
}

Output:

[ProjectName:GroovyCSV, Version:1.1, Year:2015]

Getting GroovyCSV

GroovyCSV is available from Maven Central:

Group: com.xlson.groovycsv
Artifact: groovycsv
Version: 1.1

Or you can download it from Github:

More information

Deploying Minecraft.net in 14 minutes, no way

2012-04-25T00:00:00+00:00

Deploying Minecraft.net in 14 minutes, no way

Every time we deployed Minecraft.net it would take ~ 14 minutes, that’s a lot of time. During that time I would either do nothing or get started on something else, losing focus and probably missing any potential problems with the deploy.

That could not stand, especially considering the biggest reasons for the deployment times was easy to remove from the equation.

Reasons for our slow deploy

Uploading files from the Mojang office in Sweden to Amazon EC2 in America
Each server downloads its own dependencies

1. Location

Our build and deploy server was located in the office and was the culprit responsible for the first problem. Setting up a fresh Jenkins & Rundeck in the cloud was easy enough and fixed the problem for us, bringing down the deployment times to more sensible levels just by putting the servers closer to eachother. I’d say this probably took down the deployment times to 3 minutes or so, which is almost 5 times better than before.

2. Packaging

It’s not that I wasn’t happy with our new deployment times, but the second problem was in a sense more important. Each server was running the dependencies task of play (Play Framework) at application startup, fetching its dependencies and relinkling modules to where they were located on disk. This meant startup took a bit longer than strictly necessary, which in turn affected deployment times. More importantly, it meant that there was a risk that the libraries we used would change between application restarts.

A deploy should send out a self contained distribution to the server in question, anything else opens up the risk for unexplained problems during runtime. Now, there’s almost always some kind of moving parts like this, but they should be kept to a minimum. Dependencies should rarely be one of them.

It turns out Play 1 haven’t got a solution for packaging a self-contained distribution. Running play dependencies --sync --forProd will download all the needed libraries to the lib folder and remove some of the cruft that isn’t needed in production. It handles everything except modules, which for some reasons aren’t packaged with the application. Running the dependencies command actually links the modules with the location on disk where play itself is located, something that might differ from server to server.

I fixed this by packaging the modules with the distribution and adding a few extra lines to the start-script that would relink the module reference files to the once packaged with the distribution on application startup. This removed the ~20 seconds per server it took to run the dependencies command and pushed the deployment time down to ~1 minute.

Benefits and cost

It took me 2 days to do this, which is ~960 minutes (8 * 2 * 60). We do roughly 5 deploys each week, perhaps even more now that they are quicker. This means we’ll save roughly 65 minutes ((14-1) * 5) each week, or 292.5 minutes (65 * 4.5) in a month. Given this we can see that the time spent on making the deploys faster will be recuperated in ~3 months.

More importantly, I can now do deploys more lightheartedly as I know it will only take a short period of my my time. Deploying even the smallest of change becomes a no-brainer and features should no longer pile up into a big and scary deploy at the end of the sprint. Making deploys go faster might change the way I work and that’s the real advantage here.

Thanks goes out to my former collegaue Daniel Brolund who talked to me about team minutes and the way making something faster might affect more than the time spent on doing the task itself.

Releasing GroovyCSV 1.0

2012-02-22T00:00:00+00:00

Releasing GroovyCSV 1.0

When GroovyCSV 0.2 was released back in November of 2010 I thought it might actually be the final release, at the time I couldn’t think of anything else to add. Still, calling a first release 1.0 is the same as asking for trouble.

Now, 1 year and 3 months later, with no mayor issues and only few bits of new code I’m confident enough to call the next release 1.0.

Additions since 0.2

Support for guessing separator and/or quote character
Support for reading csv without headers
Support access of values by index instead of column names
Support for setting custom column names

A special thanks goes out to Antoine Roux for writing the autodetection feature!

Examples of the new features

Autodetection of separator

One of the new features in this release is the possibility to autodetect what separator and quote characters are used.

These chars are used for autodetection:

Separators = ,;:|
Quotes = "'%

Example:

@Grab('com.xlson.groovycsv:groovycsv:1.0')
import static com.xlson.groovycsv.CsvParser.parseCsv

def csv = '''Name:Lastname
Mark:Andersson
Pete:Hansen'''

def data = parseCsv(csv, autoDetect:true)
for(line in data) {
    println "$line.Name $line.Lastname"
}

Output:

Mark Andersson
Pete Hansen

Parsing a headerless file

Another feature in this release is better tooling to handle csv data without column names at the top, or with bad names. For example, if there’s no header line, you will probably wanna read the first line, do it by setting readFirstLine:true. After that you can either access the values using their index or by setting custom column names, both is demonstrated below.

Example:

@Grab('com.xlson.groovycsv:groovycsv:1.0')
import static com.xlson.groovycsv.CsvParser.parseCsv
def csv = '''Apple,2
Pear,5'''
 
def data = parseCsv(csv, readFirstLine:true,
                    columnNames:['fruit', 'qty'])
for(line in data) {
    println "$line.fruit ${line[1]}"
}

Output:

Apple 2
Pear 5

Getting GroovyCSV

GroovyCSV is available from Maven Central with the following information:

Group: com.xlson.groovycsv
Artifact: groovycsv
Version: 1.0

Or you can download it from Github:

More information

One last thing

I’d love to hear from you if you’re using GroovyCSV, especially suggestions on improvements and bug reports. Keep the feedback coming! :)

Rescuing my Macbook Pro's battery from Google Chrome

2011-06-16T00:00:00+00:00

Rescuing my Macbook Pro’s battery from Google Chrome

The story

I’ve been a Google Chrome user for a long time and even ran with Chromium for a while before Google Chrome was released on the Mac. There’s been problems with it now and then, but I’ve been a happy customer most of the time. That was until it started eating at the battery of my new Macbook Pro. But, I’m getting ahead of myself, let’s take it from the start…

This february I started working with a couple of great guys at the small Stockholm-based consultancy Agical. A couple of days into the gig my spanking new Macbook Pro arrived; I was giddy as a school-girl. The next monday I started working at a customer and haven’t really used the mac much since then; such is the life of the consultant. After a while I noticed that my mac always seemed to be out of power, even when it had been full when I last closed the lid. That was something I had never experienced with my old macbook, even when I had left it lying around for a week or so.

I was heading off to Gr8Conf in Denmark a couple of weeks ago and thought to myself: “it’s really time I figure out what’s wrong with the battery”. After some googling it turned out to be, not my battery, but instead Google Chrome. You see, Google Chrome uses a feature in OS X that turns on the more expensive Nvidia card, even if it really isn’t doing anything special. This in turn not only eat a lot of power, but also make it harder for the Macbook Pro to get some much needed sleep, hence the constant power-shortage.

The solution

There’s a free tool called gfxCardStatus which helped me figure my issue. Once installed I could see rightaway that the more expensive card was put into action as soon as Google Chrome was started. It also allowed me to setup so that the Nvidia card was never used while the computer was running on battery power. I guess it’s really more of a workaround than a solution, but it works and it’s now easy to know which card is used. It’s still a myster why the macbook had a hard time going into sleep mode but it seems to have been solved by not using the expensive card while on battery.

Problem solved, I’m back to using Google Chrome again, without any issues. Big thanks to Cody Krieger for the excellent gfxCardStatus app.

If you’re interested in gfxCardStatus you can find it here.

Update

There’s actually an issue about this on the Chromium issue tracker, it’s marked as “Won’t fix”. I can only summize that the Chromium guys doen’t care about their users. At the same time, neither Safari or Firefox has this issue so they can’t claim it to be unfixable.

I’m really dissapointed about how this has been handled and I really hope they come to change their minds.

Groovy/Grails developer wanted

2011-04-26T00:00:00+00:00

Groovy/Grails developer wanted

If you don’t live in Sweden and aren’t using Groovy the pic above won’t mean much to you. To me it means Groovy devs are wanted in Sweden. The message translates to:

Grails developers wanted, urgently.

When I started SweGUG two years ago together with Andreas I was hoping to see messages like this all the time. That hasn’t really been the case and this is the first time I can recall seeing someone ask for a swedish Groovy developer on Twitter. This of course calls for a minor celebratory blogpost :)

Hopefully we’ll see more requests like this in the years to come when developers everywhere realise there’s more to the JVM than pure Java.

References:

Out of Delicious and into your Couch

2011-01-13T00:00:00+00:00

Out of Delicious and into your Couch

During december of 2010 it seemed Yahoo was going to pull the plug on my favorite bookmarking service Delicious. It was later revealed that they are going to sell it instead. But, before that was known the web went into an uproar with blogs about how to salvage your bookmarks and move inte another service. Not only that, A LOT of developers have stepped up trying to fill the gap with new services such as liink.it.

Personally I’ve been wanting to try out CouchDB as a bookmark handler for some time. Couch with it’s ability to bundle a webapp with the database and simple replication (backup!?) seems like a potentially great fit for bookmarks in the cloud. Said and done, when it seemed like Delicious was going away I took the step out into the wild with Jan-Piet Mens CouchApp Scrumptious.

As the icing on the cake it’s possible to get the bookmarks back into the cloud using Scrumptious with a free hosted database from CouchOne. Read on to learn how.

Scrumptious

As it happens, I’m not the first person that thought CouchDB would be a good place to put bookmarks. Jan-Piet Mens has already created a CouchApp called Scrumptious. Scrumptious is a web-application that lives inside CouchDB.

Scrumptious features:

Bookmarklet for saving bookmarks
Listing bookmarks by date or tag
Export as bookmarks html for import into the browser of your choice
Inline-editing of bookmarks

A word of warning

Scrumptious is a cool app but it’s in no way ready for non-techies (as you will probably figure out during the install, if not earlier). The bookmarklet doesn’t work in Firefox 3.x currently and the search-functionality isn’t finished. Scrumptious also lacks all of the social functionality of Delicious. If this puts you off maybe you’d be better off looking at something like Pinboard or Tagli.us.

Getting started with Scrumptious in the cloud

You could go to Github and get the code for Scrumptious and install it into the CouchDB of your choice using couchapp, all of this is documented in Jan-Piet’s post about the tool.

But, there is an easier way. To get you started quickly, I’ve put up a clean Scrumptious app on CouchOne. The only thing you need to do is create your own database and replicate my clean install of Scrumptious. I’ve done one minor change in my version of Scrumptious to secure the bookmarks and that is to require that the user posting and updating bookmarks is logged into the CouchDB administration ui. This is just to add a little security so someone else cant come in and remove all your bookmarks.

Create an account on CouchOne’s free (and beta) hosting
Setup an admin-account for your CouchDB instance using the admin ui https://[chosen-subdomain].couchone.com/_utils] (important as your database will be completely open otherwise)
Create a database using the admin interface
Replicate my empty scrumptious database into your newly created database using the Replicator part of the admin ui
- On the left side you need to put the url to my clean install of Scrumptious: http://xlson.couchone.com/scrumptious-fresh
- On the right side you should choose your newly created database.
At this point you’re done and ready to head over to https://[chosen-subdomain].couchone.com/[newly-created-database]/_design/app/index.html

Take some time to play around with the ui, add the Bookmarklet to your bookmarks bar and try it out. One thing you should know about CouchOne hosting is that I don’t know much about it and what it will cost in the long run. At this point its free and completely without guarantees so I’d really suggest you install CouchDB locally to take backups of your database from time to time (once again using the replication feature).

But where’s my Delicious bookmarks?

Well, we still have one thing to do, and that’s to export our bookmarks from Delicous and move them into our cloud. We’re gonna use curl to get all your bookmarks, so open up your terminal and enter the following (replace username with your delicious account). curl should already be available if you run Mac OS X or a linux-flavor. If you’re stuck with Windows cygwin is problably your best option to get hold of curl.

Download bookmarks using curl:

curl -sf -u username -o mine.xml https://api.del.icio.us/v1/posts/all

After you’ve got your bookmarks you can either use Jan-Piet’s perl-script mentioned in his post or my groovy alternative available here (whatever floats your boat :)

To use my script you need groovy installed, available from Codehaus.

groovy del2scrumptious.groovy -in mine.xml -out mine.json

At this point we only need to push the bookmarks up to your couch in the cloud, once again using curl.

curl -u admin  -H "Content-Type: application/json" -X POST \ 
http://[chosen subdomain].couchone.com/[newly_created_database]/_bulk_docs -d @mine.json

Head back to the web application; you bookmarked it in the last step right? All your bookmarks should be available now. A word of warning though, it might take a little while for the page to load the first time you request it after uploading your bookmarks as that’s when CouchDB internally builds its view of the bookmarks that will be used to list them.

Good luck with your cloud-hosted bookmarks!

Further reading:

Speeding up your Gradle builds using the Daemon

2010-11-15T00:00:00+00:00

Speeding up your Gradle builds using the Daemon

Gradle 0.9 Release Candidate 3 is just out, and with it a bunch of changes. The main feature for this release is the new daemon that will help Gradle speeding up at startup. Also, it’s a step in the direction of a final 0.9 release.

Release notes:

New features since 0.9-rc-2:

This release includes the experimental build daemon. To use the daemon, add the –daemon option when you run Gradle. The daemon is started automatically.

The new command-line options are documented at: http://www.gradle.org/0.9-rc-3/docs/userguide/gradle_command_line.html#N153AB.

Some background information on the daemon is available at: http://docs.codehaus.org/display/GRADLE/Gradle+Build+Daemon

Upgraded the code-quality plugin to use Checkstyle 5.3 and CodeNarc 0.11.

Enter the Daemon

The daemon is basically a Java application that will run in the background and run your builds, thereby removing the initial cost of starting the JVM and load all the Gradle classes. While using it, my gradle clean went from 6 to 1 seconds. As you can imagine I will start using it extensively on my local computer, but, I wouldn’t go as far as enable it on our Continous Integration server yet, the feature IS experimental after all.

Using the daemon: gradle --daemon clean this will start the daemon in the backgrund if it’s the first time you use the --daemon flag. It stops automatically after a few hours it hasn’t been used. Unless you enable it globally you will have to add --daemon to the commandline on every call to use it.

Stopping the daemon: gradle --stop this IS an experimental feature and therefor you might have to stop it from time to time

Enabling the daemon for all builds: Add -Dorg.gradle.daemon=true to your GRADLE_OPTS, in my case this meant adding the following to my ~/.profile.

# Use Gradle daemon (experimental)
export GRADLE_OPTS="-Dorg.gradle.daemon=true"

This is the same as adding --daemon every time you run gradle. There is also a --no-daemon flag that you can use when you’d like to disable it explicitly.

Potential issues

I’ve already noticed that I have some builds that don’t use the projectDirproperty that is available in all Gradle builds and therefor (incorrectly) run tasks in ~/.gradle/ instead of the project directory. This is easily fixed but might be worth checking.

The latest release (0.9-rc3) is available over at gradle.org.

Getting started with GitHub Pages

2010-11-09T00:00:00+00:00

Getting started with GitHub Pages

Github Pages is something as simple as a GitHub service for serving up static HTML from a GitHub repository. It’s the perfect place for project documentation, like Javadoc, and that’s what I’ve been using it for. It can also be used for blogging with Jekyll or even a complete site for your project.

Tell me more!

GitHub Pages (hence called Pages) can be tied to a project by creating a special branch called gh-pages, or directly to your account by creating a repository called yourname.github.com.

Also, saying it only feeds static HTML is like telling only part of the story. Pages can be used together with a couple of different templating systems (like Markdown) or as I mentioned earlier, the static blog-generator Jekyll, to easily keep a web presence for yourself or your project. As every part of a Pages page is in a GitHub repository it’s really easy to update and work with.

Getting started

Creating your personal page

Pages is really quite easy to use. Wanna create a site for yourself? Follow this 5 step guide to get started.

Important: there’s currently an issue regarding Pages and pushing over http, which means, it just won’t work. So use normal Git over SSH instead.

Create a new repo named yournick.github.com (xlson.github.com in my case)
Create a simple welcome page to verify that it’s working (an index.html with Hello World is quite enough)
Verify that you’ve received a notification from GitHub that they’ve rebuilt your Page (normally within seconds)
Wait for your Page to be created (will take up to 10 minutes the first time, probably just seconds after that)
GitHub page will be available at http://yournick.github.com/ when it’s ready

Creating a project page

Creating the project page is about as easy as creating a personal page, but a little different. Instead of residing in a new repository it will live in a special branch (of your project repository) called gh-pages.

Go into “Admin” mode on your GitHub project
Click the GitHub Pages checkbox and then the “Automatic GitHub Page Generator”
Choose the options you’d like and hit the “Create Page” button after that (it doesn’t matter that much what you choose as you’ll probably remove the generated page afterwards anyway)
Follow steps 3-4 from the previous checklist for “Creating your personal page”
GitHub page will be available at http://yournick.github.com/projectname/ when it’s ready
Create a new local clone of your repository (check your GitHub project for links, in my case: git clone git@github.com:xlson/groovycsv.git groovycsv-pages)
Go into the new projectname-pages directory and checkout the gh-pages branch. (git checkout origin/gh-pages -b gh-pages)
Start working on the gh-pages branch and push to origin gh-pages

You could work with the gh-pages branch in your ordinary repository but I find it’s easier to manage when you have a separate folder for the page branch.

Templating using Markdown

We’re just about finished, but I’m going to cover one more thing, and that’s how to use the Markdown templating system.

Create a file named demo.markdown in your repo and add the following content:

---
title: This will be used as the title-tag of the page head
---

# This is a H1

[the clickable text](http://xlson.com/)

* Bullet lists are also easy to create
* One more

Important: the top part containing the --- and title segment is required and if you skip it, no conversion from Markdown to HTML will happen.

Try pushing the new file to your gh-pages branch, or personal repository. GitHub will turn this template into an ordinary HTML file named demo.html using the conversions specified in the sample. Pages supports a few other templating engines (like Textile) but Markdown is the only one I use.

There’s also support for the static blog generator Jekyll (which I’ve used to create this blog). Getting started with Jekyll is out of the scope of this article, but if you’ve gotten this far, getting Jekyll running should be no problem. Check the “Getting Started” instructions over at Jekyllrb.com to get started.

Rounding it off

I’ve had some problems with GitHub Pages and that’s where this guide comes from. I’m hoping this can help others to not make the same mistakes I did. But even with those problems I think the features GitHub provide via GitHub Pages is really great. It’s a simple way to put up both documentation and a project site, or even a blog without having to think about hosting at all.

So, in closing: Big thanks to they guys over at GitHub! :)

GroovyCSV 0.2 Released

2010-11-08T00:00:00+00:00

GroovyCSV 0.2 Released

The first final release of Groovys very own CSV parsing library is out. Also, it’s up on Maven Central which should make it a lot easier to get. There have been some minor changes to the API since I posted about csv-parser the first time but the biggest change is probably the new name and package structure.

Changes since 0.1

Project renamed from csv-parser to GroovyCSV (new package-structure com.xlson.groovycsv)
Explicit close() method has been addsed to com.xlson.groovycsv.CsvIterator

Example using @Grab and custom separator

Because GroovyCSV is now up on Maven Central it’s really easy to use in your Groovy scripts. This example shows how you can make GroovyCSV available using @Grab as well as how you can use custom separators and quote character.

@Grab('com.xlson.groovycsv:groovycsv:0.2')
import com.xlson.groovycsv.CsvParser

def csv = '''Name-Lastname
Mark-'Anderson-Nielsen'
Pete-Hansen'''

def data = new CsvParser().parse(csv, separator: '-', quoteChar: "'")
for(line in data) {
    println "$line.Name $line.Lastname"
}

Output

Mark Anderson-Nielsen
Pete Hansen

Getting GroovyCSV

GroovyCSV is available from Maven Central with the following information:

Group: com.xlson.groovycsv
Artifact: groovycsv
Version: 0.2

Or you can download it from Github:

More information

One last thing

I’d love to hear from you if you’re using GroovyCSV, especially suggestions on improvements and bug reports. Keep the feedback coming! :)

SweGUG is back!

2010-10-03T00:00:00+00:00

SweGUG is back!

Our little Groovy user group is finally back in action after being dormant for almost a year. 8 of us met at the Valtech offices here in Stockholm this thursday. We had some food, drank some beer and got lots of great discussions out of it.

I’m thrilled that so many took the time off to come to the meeting even though there was only a weeks advance notice. I’m even happier for the great discussions and talks.

The whole evening was driven by the attendees through lightning talks and open discussions. Niklas Lindström introduced Spock to the crowd and demonstrated how to use this powerful BDD tool to great effect. I have to admit that I still don’t know Spock as well as I’d like to and really wanna work with it more myself. Another highlight from the evening was when Eric Johansson talked about how he’s been using Groovy’s meta-programming to make an existing Java-API a lot easier to work with (should get him to blog about that).

We’re looking at November for our next meeting and will probably organize it the same way again. This means lightning talks and great discussions from the attendees, pretty awesome huh? :)

Big thanks to Valtech for food and housing but even bigger thanks to Niklas who helped me organize the meeting!

See you all soon!

More about the group:

SweGUG

Introducing csv-parser

2010-08-17T00:00:00+00:00

Introducing csv-parser

Not that long ago I found I had the need to parse some csv data. Well that’s easy - right? Yeah it is, most of the time at least. But what I found while surveying my options was that while it is easy, there really isn’t a Groovy way to do it. So with @goeh’s ExcelBuilder as inspiration I started hacking away at a new library.

For me there were 2 goals, first to get access to the csv data using header names and the second to be able to use the Groovy collection processing methods directly on the data to allow for some nifty parsing.

csv-parser is just that, a library to make csv processing just a little bit Groovier. The library uses opencsv behind the scenes and merely tries to add a thin layer of “Groovy-ness” to the mix.

At the moment there’s no official release but I’ll link a build at the end of this post. If you’re out to get the latest code it’s an easy match to get the source and build it with Gradle. I plan to get a 0.1 version out the door soon and get that up on a maven repo for easy access. csv-parser is pretty much feature-complete, so nothing big should change while moving from SNAPSHOT to the 0.1 release.

Features

Accessing values using header names
Iteration using the ordinary collection methods (findAll, collect and so on)
Support for custom separator, quoteChar and escapeChar

Usage

The parse method returns an iterator over the rows in the csv. This means we can use any of the default groovy ways to iterate. Here we’ll see an example of filtering data in the csv using the findAll method. : is used as separator to demonstrate how to use a custom separator.

import com.xlson.csvparser.CsvParser

def csv = '''Name:Lastname:YearBorn
Bette:Midler:1945
Roger:Moore:1927
Dan:Aykroyd:1952'''

def actors = new CsvParser().parse(csv, separator: ':')

// List all actors that was born after 1950
actors.findAll { (it.YearBorn as int) > 1950 }.each {
    println "$it.Name $it.Lastname was born in $it.YearBorn"
}

Output:

Dan Aykroyd was born in 1952

More information

For further information about the library I’d suggest you visit the project page on github. There you’ll find links to the source, build instructions and even current bugs and enhancements. If you’re interested in csv parsing and would like to delve deeper into the subject I’d like to recommend The Kaptain’s excellent article Groovy and CSV: How to Get Your Data Out?.

Latest build: csv-parser-0.1-SNAPSHOT.jar (depends on opencsv 2.0)

Many thanks to Glen Smith and the other’s in the opencsv team for doing all the heavy lifting.

One more thing

I’m thinking csv-parser is a pretty lousy name that doesn’t stand out at all. As I haven’t figured out a better name myself I’d love to hear your suggestions in the comments!

Giving Jekyll a try

2010-08-10T00:00:00+00:00

Giving Jekyll a try

Today I’ve spent some time fiddling with the static (blog-aware) site generator Jekyll and this blog is actually created using it.

Jekyll is interesting (in my opinion) in that it allows you to blog using a light weight template engine such as markdown and not much else. Wordpress is a nice and all but I can’t say I’ve ever had a really good time while using WYSIWYG on the web and Wordpress is no exception. Not to mention the complexities of using a big piece of software for something as simple(?) as a blog. Then we’ve got the issue of getting code examples into blog posts. There’s lots of solutions for all these problems out there and probably as many problems more.

Jekyll is different than a normal blog engine in that it takes the template files and markdown files and builds it all into static html complete with rss feed and related posts. That html is what you upload and show your users on your out-of-the-box web server. What it doesn’t do is things like comments, admin gui (duh..). You could go as far as to say that it’s strength lies in that it really doesn’t do anything advanced. It’s actually so easy to use that there’s no real template project to start with when you’re starting up an new site. Personally I did what many other have done: “stole” the design of it’s makers blog

Now don’t get me wrong, Jekyll isn’t for everyone and it’s no silver bullet. But it IS an interesting approach to blogging for us geeks and I’m going to give it a try for a while.

Let’s hope this get’s me blogging again. Been way to long since the last time. My old home was on QBRANCH:CODE and I’ll probably keep cross-publishing my stuff over there.