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!)
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.
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
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:
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:
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.
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!).
There is a little guide for running Service Stack with
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...
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.
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
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.
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...
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?
F#and seen it deployed to a production environment
F#ETL processes that help us slice-and-dice data and move it around
F#that help automate and/or provide self-serve functionality to others.