"We're very happy with the work you've done for us as a contractor. We want to keep you on, but would like you to take a job as a permanent employee and continue to work on the project."

Once they've made this point, they then feel the need to harp on about the good points of becoming a permanent employee. Things such as job security, sick/annual leave and better hours tend to get mentioned. All of them are complete bullshit of course.

There is no such thing as job security. Sick and/or annual isn't enough to make up for the difference in pay. Hours tend to always be worse when you're working for the man, because you're expected to do whatever needs to be done regardless of the hours. This is worse if you're working on mission-critical stuff.

Now I have no aversion to doing my fair share of extra work and mission-critical stuff is way more interesting. I often enjoy it. What I don't enjoy is the expectation for me to give away my free time to my employer for no reward. I don't get extra time off in lieu. I don't get overtime pay. I don't get ownership of the software. I don't get to see the result of the extra effort I put in. I'm just expected to do it. In other situations I'd be happy to do it, but 999 times out of 1000, the situation isn't right.

I've even worked for companies in the past who expect you to give up a lot of your personal time even if there isn't anything critical that needs to be done. I was expected to write small applications and create other assets that the company could use in future projects. At first this seemed like it could be fun. But the cold hard reality was that all of the effort was totally wasted, because none of the things that were created ever got used.

As a contractor, the view from the perspective of the client is different, especially if you're on an hourly rate. Everything boils down to a financial cost. You're more likely to get a fair deal as a contractor than you are as a permy (at least here in the Brisbane market) because you're entitled to make them pay for the time and effort you put in.

I realise that this makes me sound rather mercenary. In all honesty, I'm not mercenary. I love technology. I love building software. I don't go to work just so that I can get paid. In many ways I would work for less pay if the conditions were right. Unfortunately, I am yet to come across a job where those conditions are right. I've certainly given it a shot in the past. I took a substantial pay-cut to work for Electronic Arts back in 2005 so that I could work on something that I really wanted to work on. I thoroughly enjoyed it. As far as the technology and the challenges are concerned, it's the most fun I've ever had at work. Unfortunately, the experience I had there led me to believe that the lifestyle isn't sustainable (at least not for me and my family).

Would I do the same again for another job? Definitely. But the only company I would do it for would be Basho and my Erlang-fu is not yet up to scratch so I wouldn't be considered. Outside of Basho I'm not aware of any other company or work that excites me as much. So for now I will probably remain a contractor, and try to move around and add as much value as I can on a variety of projects, keeping up to speed on many different types of technology.

So if you're reading this, give me a few good reasons as to why permanent work is better than contract work. Why should I consider it? Would you consider it? If you're a permy, are you looking to go contracting, and why?

Feedback and comments are appreciated

This assumption was proved false a few days ago when I received an email about my Trac/Mercurial/SSH post not rendering properly in someone else's browser. Dammit!

So this time I actually did a bit of research by delving into the log files (yes, I know.. genius isn't it!) and determined that there was indeed a problem. Thankfully it was fairly simple to resolve. For some reason the fastcgi instances were failing to function periodically when attempting to access a folder on disk. In short, some of the temp folders were owned by the right user, and some of them weren't. After modifying the ownership of the appropriate folders, everything seems to be running nicely.

Yet more proof that the admin is an idiot.

If after I post this you notice any truncation at all across the site, please let me know! Cheers!

For some reason, it's a very common practice for those people who don't have expertise in a certain field to make decisions for people working in that field. The best example I can think of off the top of my head is the answer to the question: "Which technology should we use?"

Let me take a step back in time for a moment.

I applied for a job with a certain company (which shall remain nameless) that was looking for a number of C#/.NET developers of a certain level of experience. After confirming an interview date and time, I turned up to find myself facing a panel of 3 interviewers. One of those people held a technical position, though I found out later that the position he held was self-appointed and certainly not an indication of the person's level of technical knowledge or expertise. The other two were in non-technical positions.

During the interview we had the usual discussions and questions around technial knowledge, depth of understanding of certain areas of the .NET framework, views and approaches to dealing with people in teams, agile experience, etc. It all went very well. At the end of the interview I was given my chance to ask a few questions. The main one I wanted to ask was "Why did you decide to use .NET for this project?"

For the record, the previous version of the system was written using an older Microsoft technology stack. The decision had been made to go with .NET for this new version. Can you see the correlation?

The answer was quite stunning. The only reason the project was using .NET was because the previous version was a Microsoft-based solution.

The first thing I thought was "surely that can't be it?". As a matter of fact, that wasn't the only reason for it, but it was the main reason. The decision wasn't made by a technical person, it was made by someone in upper management.

Scary huh!?

In my personal opinion, there is one particular technology that I think would have done a much better job of solving this particular problem, and it's not a Microsoft solution. It's not a Sun solution, or any other mainstream option for that matter. In my view, Erlang would have been perfect.

I don't think that a company like that would have ever even considered Erlang as a viable option. Mainly for two reasons. The first is that the amount of skilled Erlang developers available on the East Coast of Australia is extremely small. The second is fear of the unknown/non-mainstream tech. That is, companies like to go with what other companies are going with.

The crazy thing about this scenario is that management go to market to hire people who are domain experts, and then proceed to tell them which technologies to use. Surely you would be better off hiring people to know how to solve problem X really well, and then listen to what they have to say about the technology stack that should be put in place? No, not in this industry. Probably not in my lifetime either!

So if you're a non-tech person leading a team of techies, please PLEASE listen to what they have to say. Ask them what they think is the right approach and the right toolset. Don't take control of the technical decisions. Let them do what you hired them to do: Solve the problem, and use the right tool for the job. If they don't know the answer, or the answer is always the same, then you've got the wrong developers.

Thanks for listening

I can thank Gabrielle Lana for this discovery, as it was his attempt at one of the katas that got me into it. He's also the reason I looked into Katacasts, which are simply screencasted recordings of people attempting to solve Code Katas.

This post is about my first Katacast, capturing my attempt at Code Kata #9 using Erlang and VIM with Rake as my build system. I've put the video up on Vimeo for the world to see/share. It's also embedded below for your convenience.

Before watching, I'd like to point out a few things about the video, and things that I have learned from the experience:

• I captured the video on my Linux Mint install. For some reason, capturing quality video in Linux is proving to be a bit of a pain for me. As a result, the video quality isn't that great. This partly due to the compression of the video, and partly due to the software failing to pick up some screen updates.
• I tried really hard to add a backing sound-track but all of my efforts failed in one way or another. If I did manage to get one to work it was either WAY too big (ie. > 1GB in size) or the quality was absolutely terrible.
• There were points during the process where I had to alt-tab out to a browser to do a bit of research on something that I didn't know (such as an Erlang syntax quirk). This resulted in a few points where I don't appear to be doing anything. In future, I'll remember to hit pause on the recording when this happens.
• I captured it in a non-standard resolution. I'm not sure if that's going to make it look bad or not. Feedback here is appreciated. I think in future I'll capture at a 800x600 resolution.
• This video is best viewed in full-screen mode.

So please excuse the lack of quality in this first Katacast. I'll be sure to improve when I next create one. That being said, on with the show!

As always, feedback/criticism/etc is greatly appreciated. I'd love to hear what you guys do and use to capture and edit your screencasts, particularly in Linux.

It's safe to admit that you just don't know! In fact, it's better if you do admit it. Pretending that you know what you don't not only makes you the butt of the jokes, but you end up being detrimental to the success of the project.

Stop trying to be a know-all. Let go of the idea that you need to be the one to approve everything. Take a step back and be honest to yourself and the rest of the team. You aren't a one-man-band. You aren't the technical guru that you think you are. You aren't even a specialist in a particular area, let alone a jack-of-all-trades.

When you attempt to do something and you fail, stop trying to make it sound like you haven't failed. Please stop yourself from trying to turn your wrong into a right. Everyone fails in one way or another during their working life, and as much as you don't want to admit it, it does include you.

Change your attitude. You'll be doing yourself a favour.

And while you're at it, how about you get up to speed with the technology you're working with. Then you won't have to pretend, and the likelihood of you failing will start to decrease.

Thanks for listening.

Remember, it's not about you, it's all about the software.

I know, this kind of thing happens thousands of times a day. Some arbitrary geek decided to build the next killer app and expects to make a crapload of cash out of it. While that would be nice, the ultimate goal isn't the cash. The goal for me is to build something that gets used, and for me to begin to master an area of technology that I've had a quiet passion for for a long period of time now.

My plan is simple. While learning the technologies that I will be using I'll be building another application and blogging about it so that all of you can learn with me. Meanwhile, I shall use my learnings to build this other application at the same time.

The final result should be a series of posts which help other people learn the technology stack, give better coverage and visibility to languages and technologies that a lot of the geek world doesn't know about (and really should!), and for me to carve myself a bit of a niche here on the East coast of Ozland. I am hoping to be able to consult my services out to other businesses as a result.

For those that are interested in following along, here is the full tech stack and toolset that I'll be using:

• Erlang - A fantastic cross-platform functional programming language that has some amazing features.
• Webmachine - A HTTP toolkit which sits on top of Mochiweb that makes it easy to build well-behaved HTTP applications.
• Nitrogen - An Erlang-based framework that makes it easy to build websites.
• Riak or CouchDB - Both of these amazing pieces of tech are potential candidates for the back-end storage. I'm not yet sure which one I'll go with.
• jQuery - A great JavaScript library for the front-end.
• VIM - My favourite text editor
• Xubuntu - Ubuntu Karmic Koala with XFCE as the window manager.
• Mercurial - My favourite version control system.
• Trac - A project tracking tool.
• VirtualBox - My choice for virtualisation. I tend to run Windows 7 as my primary OS, so most of my dev will be in a VM. When I get my desktop machine back up and running (with all three monitors!) it'll most likely multiboot Win 7 and Xubuntu.
• Google Wave - I'll be using this for communications with some really switched on people in the Erlang community who have kindly offered to help me with questions and whatnot specific to some of the areas of tech I've mentioned above.

During the course of my blogging/learning I'll be focussing on Webmachine, Riak/CouchDB, Erlang and Nitrogen. All the other tools will probably get mentioned along the way, but the primary goal is to focus on these things.

I'm really excited! I'm currently in the process of documenting my goals and the design for the main application. Once that's done, I'll get started with the fun stuff. I've got a lot to do and it should be a fun ride. I hope you enjoy following along!

After a year or so of serving up content, it managed to handle a couple of Reddit submissions without much of a bother! I was suitably impressed.

But there comes a time when you can't help but wonder what else is out there. For me, that time came a little while ago when I boosted the number of plug-ins that I use on this site. Litespeed took longer to serve pages up and I couldn't help but notice it. I'm certainly not blaming Litespeed, because the obvious solution is to remove the plug-ins! But I didn't want to do that as those plug-ins provide features for this site that I don't want to lose. So my quest to find another web server began.

Then recently I started researching ideas for developing software in Erlang. I've been reading up on the language for quite a while and I'm getting to the point where I intend to build something. My first effort is going to be a web application that uses Mochiweb, Webmachine and CouchDB. I know that at some point I'm going to want to have this thing run on the web so that other people can play with it and that would mean that I would have to have a web server available that could also route requests to my Erlang server. Of course, I want it to be quick.

So after a bit of deliberation and research, I followed the footsteps of some big players and ended up installing Nginx (which I believe is pronounced "Engine-X"). I kid you not, this thing is amazing! I'm not going to give a full review of it here because I haven't used it enough to know how good it is. But the speed-up for this site in particular is obvious (at least for me).

My mate Dan's site absolutely flies!

On the whole, Nginx gets a huge thumbs up from me thus far. If you're looking for a speedy web server that can do reverse proxying, dish up static content like a maniac and handle forwarding of requests to a variety of other servers then you should seriously consider taking a look at Nginx.

Thank you, Igor!

• Introduction to Functional Programming - by Brad Clow
• Haskell 101 - by me!

There are still spots available if you're keen to come along. It should be fun!

I'm always up for some public scrutiny, so come along and bring your rotten tomatoes.

If you can't make it, I'll post the slides for the talk on this site, and on Meetup.com, when the event has finished so you can see what was covered. Feel free to ping me or ask questions.

Update 19th Aug '09
The talk seemed to go quite well. I had to motor through the material quite quickly due to the late start, but on the whole I think it was well received. I haven't had any negative feedback so far

Slides/content are now up for grabs!

Communities are arguably the life blood of technology. Without a good community the likelihood of the technology catching on is drastically reduced. Those communities which lack individuals that are happy to put time and effort in to help get others up to speed tend to stagnate. Any community which involves members that are abrasive, rude and downright offensive is destined to suffer long term.

The level of suffering will vary depending on quite a few things. Those things include existing user base, the age of the technology and the number of different ways that a given n00b can get information about that technology.

IRC is a very common and popular means for members of communities to interact. It provides a real-time element that you don't get with blogs, forums and other media like Twitter. It satisfies every geek's desire to get the answer and get it now. Experiencing support in real time via IRC can be extremely helpful and rewarding. It can work wonders for the popularity and image of the community and the technology itself.

If you're interested in seeing some active and extremely helpful communities, you should take a look at #haskell and #mercurial. Both of these channels are generally very active. The people that spend time in them are both helpful and friendly. Both of these channels indicate to me that there is a very healthy and vibrant community behind each of these pieces of technology.

Unfortunately, this kind of communication also has a downside. The real-time nature of IRC allows people to vent anger on newcomers without any means of moderation. The net result of this is that other individuals become to scared to offer their view or provide support for fear of receiving the same treatment. This goes for members with any level of skill or knowledge. There are some community channels out there containing hundreds of people, and yet there is no conversation. When questions are asked, nobody responds.

After my recent experience in a channel that fist this description, it's easy to see why. In less that half an hour of asking for clarification on certain points, I received a barrage of abuse which, in my view, was totally unjustified.

But let's say, for the sake of argument, that it was justified. That for some reason I annoyed someone in such a way that bombarding me with many 4 and 5-letter expletives was acceptable. Do you think that it paints a good picture of the community?

I think not.

In less than half an hour I went from excited to deflated. I lost interest in the piece of technology and lost faith in the community around it. Was my response justified or understandable?

I'm not sure about the answer to this

I feel that it's the job of the community to moderate other members of their community. If people get abusive then other members should step in and prevent it. In my case this wasn't possible due to the fact that the person in question was abusing me via a private chat so that the channel couldn't witness his venting. I'm guessing this wasn't the first time that he's done this to someone, nor will it be the last. I wonder how many others have suffered the same fate? If the silence of the channel is anything to go by, I'm guessing quite a few.

I guess what I'm trying to say here is this: don't underestimate the value and importance of your community. It's one of the most frequented faces of your technology. If it's bitter, unwelcoming and unsupportive, you will not only lose valuable newcomers who come looking for information and support, you will also lose future users due to the poor reputation. Ultimately, your tech will suffer.

If you're part of a community, do your bit to police it. Help those who need help. Stop those people who are abusive.

.. and if you don't have anything nice to say, then don't say anything at all!

A little bit of history...

Recently I've been delving into Haskell quite a bit. It's part of my apparently never-ending quest to learn as much as I can about as many languages as I can (well, those that appeal to me at least :)). While I love playing around with a language, toying with ideas, writing small programs, reading books, blog posts, etc it's not really the same as having an on-call expert to help and guide you.

While I'm aware of, and frequently visit, the Haskell IRC channell I find that the level of understanding there is so great that my piddly noob questions tend to get lost amongst the bombardment of much more advanced & interesting discussions. In short, while I find it a great place to go, it's not a great place to find someone who's happy to help guide me through the maze and go over topics in quite a bit of detail while I annoy them with questions.

Haskell is one of those languages where having a mentor is really beneficial. So I set about finding myself one. Thankfully, I found a rather helpful chap based in the UK, (he shall remain anonymous, as I don't want to violate the man's privacy), Peter Marks, who has been very forthcoming with information. He's humoured me and been incredibly patient so far, and I'm very grateful for his time.

One of the questions that I asked him was:

Why is it that everyone seems to strive to get their code into Point-Free style? I can see how a lot of the implementations are more concise, but many of those lose readability.

What is so special about it?

The discussion that followed was really insightful. That is what has inspired me to write this post.

Please note, any errors in this post are totally my own. They are not the fault of my mentor

The purpose of the post: Why aim for Point-Free style?

So it is just me, or does anyone else out there feel that there's a bit of a "thing" going on for Point-Free style? Sometimes I share my terrible code with people and I get shunned when it's not Point-Free and it could be.

Anyone?

I hope it's not just me Let's start with taking a quick look at what Point-Free style actually is.

So what is Point-Free style?

If we take a look at the Wikipedia we can see that..

Tacit [point-free] programming is a programming paradigm in which a function definition does not include information regarding its arguments, using combinators and function composition (but not ?-abstraction) instead of variables.

Simple eh? In essence, it basically means that your function definition doesn't reference any of its arguments/variables. For a crass definition, think point == argument and it should make sense.

So we're writing functions without directly referencing its arguments. For those not familiar with Haskell or other languages that support this, let's take a look at an example:

-- sum : take a list of numbers and add them all up to get a total
-- start with the base-case: an empty list
sum [] = 0
sum (x:xs) = x + sum xs

We can see that the above function is written in such a way that the arguments passed into the function are actually referenced in the body of the code. This is how a standard imperative programmer would write this function if he/she was new to Haskell. If we instead used a fold, we could define it like so:

sum xs = foldr (+) 0 xs

This does exactly the same thing as the previous definition, but as you can see the grunt work is done by the fold function. Now that we have this definition, we can easily move to Point-Free style:

sum = foldr (+) 0

Here we can see that no reference is made to the arguments of the function. Since we haven't referenced any "points", we have a Point-Free implementation.

Awesome. Cool. Sweet. Nifty.

But what does it give me? Why is it better?

Why use Point-Free style?

This section is based totally on my own opinion and is not an official definition I think that Point-Free style fits in the same category as many other coding patterns and styles, and that it's usually down to the individual programmer to determine the when and the why. So take my view with a pinch of salt.

In short, Point-Free style let's you focus on the how rather than the what.

It might be just me, but imperative programs seem to have a large focus on the data. The code which operates on the data is lost within a plethora of code that isn't necessarily specific to what the program needs to do. I've found that functional programming tends to be very different, at least in Haskell. Haskell lets me focus on what it is I need to do, and I feel that Point-Free is another step in the same direction. Is this good? I think so But I'll let you decide.

As well as the focus on the what I've found that aiming for a Point-Free solution can aid in helping you understand your problem better. This claim sounds like fluff, so let's go through an example and hopefully you'll see what I mean.

Where Point-Free helped me get a better understanding

Haskell developers use the composition operator (.) a lot. It actually aids in creating Point-Free style. I love the irony here. We add points (.) to remove points (arguments).

Anyway, the composition operator's definition, according to Prelude is:

(.)       :: (b -> c) -> (a -> b) -> a -> c
(.) f g x = f (g x)

This operator takes two functions and produces a function which is composed of the two. This function takes the output of one function and sends it through as the input to another function, returning the result of that call.

This is really handy. We can do some interesting things like:

ghci> let doubleAndAdd5 = (+5) . (*2)
ghci> doubleAndAdd5 20
45
ghci> :m +Data.List
ghci> let sumColumns = map sum . transpose
ghci> sumColumns [[1,2,3],[4,5,6],[7,8,9]]
[12,15,18]

Very handy indeed. While handy, it doesn't necessarily allow us to do everything we might want to do. One example is handling cases where we want to compose a function where the right-hand function takes two arguments instead of one.

So if we wanted to create a function that would take two values, add them together and double the result, all while using Point-Free style, we'd like to do something like this:

ghci> let addAndDouble = (*2) . (+)

:1:20:
    No instance for (Num (a -> a))
      arising from a use of `*' at :1:20-21
    Possible fix: add an instance declaration for (Num (a -> a))
    In the first argument of `(.)', namely `(* 2)'
    In the expression: (* 2) . (+)
    In the definition of `addAndDouble': addAndDouble = (* 2) . (+)
ghci>

As you can see, ghci doesn't like it. And rightly so! This is because the composition operator's signature is:

(.) :: (b -> c) -> (a -> b) -> a -> c

That is:

1. It takes an argument which is a function which takes a value of type b which returns a value of type c
2. It takes a function which takes a value of type a which returns returns a value of type b
3. It returns a new function which takes a value of type a and returns a value of type c

This doesn't work in our case, as we want our right-hand function to take two arguments. That is, we want a type signature that looks like this:

foo :: (b -> c) -> (a -> a1 -> b) -> a -> a1 -> c

So everywhere we had (a -> b), what we really want is (a -> a1 -> b). Given that we don't have an operator that does that for us, let's define one. We'll start with the definition of the (.) operator and work towards a function that does what we need.

-- here is the composition operator again
(.) f g x = f (g x)
-- here's our new operator's definition
(.^) f g x y = f (g x y)

Simple! Let's see what ghci says about it:

ghci> let (.^) f g x y = f (g x y)
ghci> :t (.^)
a :: (t2 -> t3) -> (t -> t1 -> t2) -> t -> t1 -> t3

Looks good! This is exactly what we need. Now that we have a working function, let's aim to write this in Point-Free style. We do this by breaking down the function slowly and eliminating arguments by moving them to the far right hand side of the function definition.

The first argument to get rid of is 'y', as this is the last argument passed in:

-- start by moving y to the right
(.^) f g x y = f (g x y)
-- becomes
(.^) f g x y = f . (g x) $ y

These are functionally equivalent, and now that 'y' is out on it's own, we can drop it from our function definition:

ghci> let (.^) f g x = f . (g x)
ghci> :t (.^)
(.^) :: (b -> c) -> (t -> a -> b) -> t -> a -> c
ghci>

Excellent, we're a step closer. Now we need to do the same with 'x'. This takes a little more fiddling:

-- we need to take the original definition
(.^) f g x = f . (g x)
-- and change it so that it uses prefix notation instead of infix
(.^) f g x = (.) f (g x)
-- which is the same as
(.^) f g x = ((.) f) (g x)
-- what we're doing is calling g with x and applying the result to f
-- and hence we can compose the composition of f with the call to g
-- giving us the following
(.^) f g x = ((.) f) . g $ x
-- finally leaving us with
(.^) f g = ((.) f) . g

Phew I hope you can see the progression. We've managed to move x out of the picture, so now we're down to a fairly crazy looking definition. Let's see what ghci has to say:

ghci> let (.^) f g = ((.) f) . g
ghci> :t (.^)
(.^) :: (b -> c) -> (a1 -> a -> b) -> a1 -> a -> c

So we've got rid of two variables, but there are still two more to go! Remember, 'f' and 'g' are still variables, they just carry functions. So let's get rid of 'g':

-- start with what we had before
(.^) f g = ((.) f) . g
-- change to prefix notation again
(.^) f g = (.) ((.) f) g
-- and drop g
(.^) f = (.) ((.) f)

This is looking rather crazy Again, let's make sure we haven't done anything stupid:

ghci> let (.^) f = (.) ((.) f)
ghci> :t (.^)
(.^) :: (b -> c) -> (a1 -> a -> b) -> a1 -> a -> c

Excellent. We've still got what we need. One more point needs to be dropped, so let's get rid of 'f':

-- start with what we had before
(.^) f = (.) ((.) f)
-- which means that we're composing a composition with a
-- function composed of f and something else
(.^) f = (.) . (.) $ f
-- and we finally drop f
(.^) = (.) . (.)

Isn't that just crazy! Let's again check ghci:

ghci> let (.^) = (.) . (.)
ghci> :t (.^)
(.^) :: (b -> c) -> (a1 -> a -> b) -> a1 -> a -> c

So there we have it, our operator completely in Point-Free style.

This is where the penny dropped for me. The whole exercise of moving through to Point-Free made me really understand what it was I was doing in the first place. The final definition makes it very clear. We're composing two separate compositions.
Let's see if our function behaves itself using the example we listed above.

ghci> let addAndDouble = (*2) .^ (+)
ghci> :t addAndDouble
addAndDouble :: Integer -> Integer -> Integer
ghci> addAndDouble 10 15
50
ghci> addAndDouble 21 3
48

It does exactly what we need it too.

Conclusion

To sum up, Point-Free helps you tidy your code into more concise implementations which tend to aid you in understanding what it is you are trying to do. I feel it really helps you focus on what you're doing as opposed to what you're doing it to. It's down to you to determine whether you feel this is a good thing or not!

It is ultimately down to the developer to dictate when it should be used. There are definitely cases where the resulting function might not actually help in making things clearer. But on the whole, Point-Free style seems to help me understand what it is I'm doing (or, arguably, not doing).

Of course, you could just get sick and tired of trying to come up with variable names, in which case Point-Free is the bomb

Feedback of any kind is always welcome. Cheers!