10 things I learned in my first hackathon

Or rather: 10 excuses why I failed.

So today I took part in (and I guess, ran) my first full hackathon - IWDev Crimbo Coffeehack. We kicked off at 9am today, and finished at 4pm and apparently threw some code together in the middle of it. We had a random theme which we announced shortly after getting together and then flew at it. Since it was our first hack day at a coffee shop - we rolled with coffee as the theme.

So I learned a few things, and thought that I'd dump them down here:

(for future reference - duh!)

Test-first F# with Acceptance tests and the REPL

Lunchtime blogging strikes again - this post has probably been brought to you over the course of a few lunch times.

Like most of my posts on the subject of F# there really isn't much I'm adding to the wealth of the community, but I feel as if contributing to the community in blog posts from an average .NET developer's perspective does have value. F# is pegged and marketed as a great language for niche problem domains (just look at the Try F#: Learn page) - but I'm all about using F# as a great general purpose language, instead of C# or VB.NET.

This post is probably a long time coming since I'm really enthusiastic about both test-first software development and F#. I've been mostly prompted to write my thoughts and findings down in response to seeing RobAston's blog post - On testing and the REPL in Clojure; who I've been following (which as I can see from Twitter, most of the developer community does!) while he adopts Clojure.

So what am I going to be writing about? Basically how using F# makes it easy for me to drop some of the dogma and get on with it. I've done a few projects now at work which involved writing F#, and this kind of outlines the how I work while doing it.

Adopting F#, Part III

Back in January when I blogged Adopting F# - I didn't really anticipate it being something of a series; but before too long I blogged again Adopting F#, part II. As it goes I think it is interesting to document the journey I've been able to take from C# to F# as my bread-and-butter language.

Since I started part II with a "...what has changed since...", I don't see much of a problem in doing the same again:

Continuous Deployment with FAKE and Octopus Deploy

It's a nice day today, and I've just sat outside for a short break while the other guys ate their lunch (I don't eat during the day, mostly). It struck me that I've not been blogging much of late, and that I've managed to use my lunch times to get some content out on the web before; so I'm back at my desk and hammering rake new_post again.

So in recent-ish times I've been evaluating Octpus Deploy:

Octopus deploy dashboard

If you're in the business deploying web/service based .NET systems to Windows environments - do yourself a favour and take a look; I think it is a really sound product.

Service Stack, with F# on Linux

Man am I busy right now! I've a todo list a mile long. Mosty self-inflicted, and entirely a life choice for me. I can't (won't, rather) go into it all - most of it has more to do with life than cutting code or lifting weights (not that I'm doing much of the latter, I can tell you!).

One thing that I have been doing is messing around with Service Stack some more - obviously using F#. Very nice.

There is a little guide for running Service Stack with fastcgi, mono hosted on nginx. But getting that up and running felt a little dirty.

So I needed to find some homeless guy to help me out...

F# Wsdl Type Provider and Untrusted Server Certificates

I came across something of a pain while using the Microsoft Wsdl Type Provider (Microsoft.FSharp.Data.TypeProviders.WsdlService) at work yesterday.

The problem that I was facing was that the Wsdl Type Provider just would not play ball with one of our web services. The reason as it turns out was the fact that it used https and the certification isn't properly signed.

So when working with the Type Provider in code - using the default method of just pointing at the service's Wsdl; just doesn't do the trick. Documentation for a fix was a little thin on the ground - and it wasn't until I did a #fsharp shout out on Twitter that I got some clues.

Fake it, until you make it! (or something like that)

This is a post that I've had floating around in my head for a long time. The title might be a little misleading, but I hope that the content remains somewhat relevant to it in some ways (that will hopefully become clear as you read through).

I want to talk (write?) about how similar powerlifting (or any strength sports, I guess) is to software development.

"You must be mad!", you're thinking. You might be right.

Read on if you dare care.

Code Comparison: C# v.s. F#

Since I found using yesterday's lunchtime to write a blog post so good - I'm following that up with another lunchtime blog post.

Yesterday I continued what I think will slowly become something of an anecdotal series on adopting F#, in which I briefly talked about a new service I'd worked on using F# (see Adopting F#, Part II).

Inspired by 'Does the language you choose make a difference?' by simontcousins I'm throwing up a comparison of lines of code.

Increasing agility (a process improvement brain-dump)

At work, I'm trying (where I can) to help push process improvement all the time. When things are slow, inefficient and painful I get grumpy. I'm not the only one, and I have the privilege to work with some great people with great minds and ideas. Together we are making, and have made some good progress.

I've been meaning to write something about continuous integration and/or delivery, agile methods etc. General development/software processes etc. How to do things right. But I don't think I am yet qualified to write with any authority on these subjects - so I am going to settle for this...

Adopting F#, Part II

This post has been a long time coming. I've a few floating around in various draft states and some that exist only in my head at the moment. But I've decided to use today's lunchtime to try and drive this one home.

I've previously talked about my journey so far with adopting F#, and have decided that as things for me have moved on some since then; it was worth me writing a follow-up.

So what has changed since January?

  • Written a new web service in F# and seen it deployed to a production environment
  • Spent a day doing some pair-programming to help a colleague learn some more about F#
  • Written a few more F# ETL processes that help us slice-and-dice data and move it around
  • Written a couple of very little tools in F# that help automate and/or provide self-serve functionality to others.