Dallas geek night

On August 18, 2010, in Dallas, Geeknight, ThoughtWorks, Uncategorized, by graham

Last week I happened to be in Dallas for a client and was invited along to the Dallas Geeknight held at the ThoughtWorks offices there.

The Dallas Geeknight is ‘oldschool’ which is not surprising since Paul Hammant informed me he formed the original Geeknight in the UK. The primary driver is producing code and committing that code to a repository.

At the start of the evening people offered up their current open source projects elevator pitch style. I pitched two projects bvira and Intercept. There was interest in both but as most people have their own web frameworks the consensus was to work on Intercept.

After some initial hiccups around the IDE files for the project we were up and running. For most of the evening we worked as a group of 3 or 4 on a single laptop. The discussion and engagement was great and I am deeply thankful for the interest in my pet project. A lot of my work at the moment is around talking, writing and generally I don’t spend enough time working with code to satisfy the geek side of my nature. It was a truly refreshing experience to spend a few hours having fantastic technical conversations — at the end of the evening I could not believe how great I felt about what had been achieved.

A big thank you to everyone who was there but especially those who gave their time to work on Intercept.

Dallas Geeknight is definitely an event I will be attending again when I am next in Dallas.

SociBook del.icio.us Digg Facebook Google Yahoo Buzz StumbleUpon
Tagged with:  

For sometime I have been wondering how best to manage all the information that collects in my laptop. I don’t even have to try to collect data it just arrives in an irregular stream of emails, instant messenger and other symptoms of this connected world. And then there are the other things I want to collect, data from websites, blog articles, eBooks, PDFs and other documents. Added to this meeting notes, observations, ideas for new projects.

All of this information is actually quite difficult to manage. For some time I have been organising things on the filesystem but this approach only captures data in a very structured way. It is not easy to cross link data from one point in the directory structure to another (I could use symbolic links but that would quickly breakdown with such a high maintenance load.

Last night I remembered that someone had suggested using a person wiki to help manage all this data so I thought I would give it a go. I wanted the system to run on my laptop. I am not always connected to the internet and a local installation helps when I am far away from wireless and 3G. This approach also minimises security concerns in case any sensitive data ends up on the site. I tried a couple of wiki solutions and decided on MoinMoin. Written in python this wiki server uses the filesystem to hold its pages – which helps with recovery if nasty things happen.

After some happy hours organising my data I have to attest that using a wiki for this is a liberating experience. I have not deleted the original files yet but being able to simply link information together, including journal entries, meeting notes to people, technologies. I have not settled on a structure yet. I am letting the data that I collect over the coming weeks guide its organisation before taking a careful look at how it could be organised. At the top level I have Work, Profession, Library and Incubator. The last is a bucket for any ideas that I come up with. If the ideas collect data then they might be worth pursuing – only time will tell. The Library is where I put all my PDF format eBooks which I can then cross link from pages related to their content.

If you have not tried it yet I recommend installing a local wiki to see if works for you.

Update:

For some time I have been collecting thoughts in an electronic journal using one file per day and naming the file based on the YYYY-MM-DD format. The following bit of ruby then generates a simple reverse chronological listing of those journal entries as a page called ‘Journal’. The regex is particularly lazy and could do with a cleanup but the script is functional for my immediate needs.

For this code to work you need to enable xmlrpc which appears to be off after a clean install. The simplest but least secure is to enable this in the wikiconfig.py file by adding the line

    actions_excluded = []
require 'xmlrpc/client'

server = XMLRPC::Client.new('localhost', '/?action=xmlrpc2', 8080)
journal_page = ""

result = server.call("getAllPages")
result.sort.reverse.each do |page_name|
  if page_name =~ /....-..-../
    journal_page << " * \[\[#{page_name}\]\]\n"
  end
end

puts journal_page  

server.call("putPage", "Journal", journal_page)
SociBook del.icio.us Digg Facebook Google Yahoo Buzz StumbleUpon
Tagged with:  

DRAFT

golf-putting-banner.jpg

Faced with the question ‘What do you do?’ from family and friends is more challenging than it should be. Most other professions have been around longer than a generation but writing software applications is different. Especially for my parents and so this is for the vast majority of people who don’t do what I do but would like some sort of idea of what I do.

But first a disclaimer – I don’t really know that much about golf. I have played a few rounds in the dim and distant past and watched a bit on the TV. My apologies in advance to golfers everywhere for the mistakes I am about to make.

Teeing off

Every project needs to start somewhere. If a round of golf were a project then it would start at the first Tee. Arriving with golf bag with an arsenal of clubs ready to begin. Even before arriving at the first tee there has been a bit of planning, appropriate clothing for the weather, umbrella in case it changes on the way, score card and pencil in hand it is time to start the project/game.

If the fairway does not stretch out in front of you then this is probably pitch and put and you are overdressed and equipped. Take a couple of clubs from the bag and put the rest back in the car. Pitch and put might be an appropriate metaphor for the support and maintenance phase of a software project but that is not the game for today.

So the first step is to work out how to approach the first hole. This is similar to planning the first release. If the hole is close by you might be able to reach it in one shot. Typically though the pin is some way off in the distance, perhaps behind some trees or lake and although you might have a general idea of where it is, trying to get there in a single stroke is very risky and could land you in a whole lot of trouble. The sensible approach is to work out how much of the course you do know about (the bit in front of you) and try to get the ball a far down the fairway as you can without hitting an unknown obstacle. Each shot can be compared to an agile software development iteration which takes on enough work to move the project forward and deliver value without putting the overall project at risk.

The drop shot

What makes golf and software development so interesting is all the factors that can affect the game/process. Weather, tools, mood, other people. Sometimes even the best players end up a long way from where they intended to be and have to take a drop shot to continue the game.

Sometimes development iterations don’t go as expected. There are so many variables that predicting the outcome of an iteration let a lone a full product release is not reliable.

SociBook del.icio.us Digg Facebook Google Yahoo Buzz StumbleUpon
 

Optimising build times

On June 28, 2010, in Build Times, C/C++, SSD, by graham

I just came across this post and want to remember it so posing here. http://doublebuffered.com/2009/02/11/optimizing-build-times-for-large-c-projects/. I am most interested in the uplift in compilation time based on unused #includes and build reductions for SSDs.

SociBook del.icio.us Digg Facebook Google Yahoo Buzz StumbleUpon
 

This is a very interesting article http://queue.acm.org/detail.cfm?id=1814327 which demonstrates that we should not take things for granted – including algorithms that have been around for a long time.

SociBook del.icio.us Digg Facebook Google Yahoo Buzz StumbleUpon
 

Blogging from emacs

On May 5, 2010, in Uncategorized, by graham

After installing
WebloggerMode some time ago I had not gotten around to trying it out so I thought I would take it for a spin with this entry.

Nothing earth shattering but the interface is clean and I have a personal commitment to reaquaint myself with the power of emacs.

Installation and setup is straightforward although I would like a little more 1,2,3 style instructions. But then there are only 3 basic instructions before this point:

1. Install
2. Configure
3. Create first entry

As an update the post is submitted as draft. I then pulled the entry back down with weblogger-fetch-etries which then provides a number of additional fields.

SociBook del.icio.us Digg Facebook Google Yahoo Buzz StumbleUpon
 

When performance testing a web application (as in raw operations per second) I have seem many people try to benchmark their new system against the agreed performance level right off the bat. The problem with this approach is that most applications need to be tuned to get the most out of them. Optimistically firing off 100s of requests will most likely cause the server to choke and if you are unlucky die in a gibbering heap.

A more successful approach is to establish the maximum load that the application can cope with and then looking for performance bottlenecks. When operating at peak load any measurements are more likely to indicate true areas for improvement. Overloading the server is more likely to show hot areas around resource allocation where each thread is fighting for survival. By resolving issues around the first constraint (memory, threads, database connections, cpu) and then moving on to the next is most likely to yield rapid results.

On a fairly recent project the performance environment was not available until late in the project cycle. I was pretty sure that we would see some horrific results from the first performance run although I was confident that the architecture would support the anticipated load we had not run in a production like environment with production volumes of data. Sure enough the first few runs were far from satisfactory but over the following few days transaction times were down by just over two orders of magnitude. When an application first experiences heavy load it is important to maintain perspective and work through the problem. It is also helpful for this first run to be private to the development team so they can tackle the problem without attracting too much attention – ideally performance testing would be happening throughout the build. Most of the time ideally does not happen that often.

SociBook del.icio.us Digg Facebook Google Yahoo Buzz StumbleUpon
 

ReleaseIt partial review

On April 10, 2010, in Uncategorized, by graham

I have been catching up on my reading recently and one of the books I have been trying looking forward to reading is ReleaseIt. I had heard very good things about the book and to my delight they are true. If you are a developer building almost any sort of application but in particular working on java based web applications you need to read this book! I wish it had been available years ago and that I had read it.

On the last couple if java web projects I have worked on we implemented a form of system health check which allowed us to interrogate the running application and retrieve data about it’s health. Implementing this sort of feature started (for me) as a way of knowing the properties a particular server was using. Production environments are particularly opaque for most development teams for good reasons but this makes problem diagnosis very difficult, especially when there are problems just following a major update and the pressure is on to find a solution. Tension is high and although everyone wants the problem found, everyone is also just as keen for the problem not to be theirs.

Having a page at lists the properties and their values (except passwords) available internally to the development team can really speed up problem diagnosis.

The problems we were seeing which led to the development of these status pages matched the recommendations of the book. As did an embarrassing number of other incidents. Reading the book will help me not experience the other situations that i have not encountered yet!

As a bonus it’s a really easy read. Highly recommended.

SociBook del.icio.us Digg Facebook Google Yahoo Buzz StumbleUpon
Tagged with:  

7 days with the iPad

On April 10, 2010, in Uncategorized, by graham

So it has been 7 days since buying an iPad. Has it been the life changing event promised by all the pre-launch advertising?

In my case I don’t think my life has changed but it has been enhanced by having one. In a similar way that the iPhone made many on the go tasks easier and in a lot of cases fun the iPad has made other tasks more engaging and fun. I wanted an eReader that would allow me to read technical books while on the go and was willing to pay for that facility. The iPad delivers. Reading is a pleasure and since I already had a nice collection of books from the pragmatic programmers who offer multiple formats for each of their books my bookshelf is nicely full. For other publications in PDF Calibri does a reasonable conversion.

Other things that I really appreciate:
* bulk email operations – but i am looking forward to the unified inbox and multiple exchange account.
* watching TED videos through iTunes
* reading tweets. The UI is just made for scanning and absorbing lists of data.

And just generally how the device has made a place for itself in my life. An idea pops into my head and I can capture it or dig deeper without bringing out the laptop.

SociBook del.icio.us Digg Facebook Google Yahoo Buzz StumbleUpon
Tagged with:  

Scraping Railscasts

On April 7, 2010, in Uncategorized, by graham

I had a few moments today to get reacquainted with Ruby and Rails programming. It has been a while but I have found time to watch the occasional Railscast. I want to watch these videos while on the move but unfortunately the iTunes podcasts are not compatible with the iPad/iPhone. Downloading each one is tedious so I came up with the following:

require 'open-uri'
require 'hpricot'

(1..6).each do |page|

  doc = Hpricot(open("http://railscasts.com/episodes?page=#{page}"))

  (doc/"a").each do |l|
    href = l[:href]
    if href =~ /.*ipod_videos.*/ then
      file_name = File.basename(href)

      unless File.exist?(file_name) then
        puts "Downloading #{file_name}"

        File.open(File.basename(href), "w") do |file|
          file.write(open(href).read)
        end
      end
    end
  end
end
SociBook del.icio.us Digg Facebook Google Yahoo Buzz StumbleUpon
Tagged with: