First up, a few things we need to be aware of before we begin:

1. The information in this post has only been verified on Linux (Mint to be exact). It should work just fine on Mac OSX. I'm almost certain that it won't work on a Windows machine. So if you're a Windows developer, you'll have to wait for another post down the track which covers off how to get your environment ready to rock.
2. We'll be downloading, building and installing Erlang, ErlyDTL, Riak and Webmachine.
3. Even though it's not yet recommended, I'll be using the latest version of Erlang to power Webmachine and Riak (R14A). If I were to build a production application I would follow the guidelines of the Basho guys and use R13B04. Since this application isn't a production application happy to take the risk
4. Rebar is the tool we'll be using to handle builds, but I won't be covering it in any depth.
5. You will need the latest versions of both Mercurial and Git so make sure they're downloaded and installed before you follow this article.
6. We'll be doing some interaction with Riak via curl, so make sure you have it downloaded and installed as well.
7. This is intended to be a step-by-step guide targeted at those who are very new to web development in Erlang. This may not be the most ideal set up, nor the best way of doing certain things. I am hoping that those people who are more experienced than I will be able to provide feedback and guidance in areas where I am lacking.
8. Over the course of this series I'll be attempting to build an Erlang version of the Code Smackdown site that I've been working on here and there with a mate of mine. You'll see that the sample application we're working on is called "csd" for obvious reasons.

OK, let's get into it. First up, Erlang.

Installing Erlang R14B

Download and installation is fairly simple. Right now we're not worried about enabling all of the features of Erlang, such as interfacing with Java and providing support for GTK. So the boilerplate functionality is enough. Here are the steps to follow:

oj@nix ~/blog $ wget http://erlang.org/download/otp_src_R14A.tar.gz
--2010-09-01 20:18:12--  http://erlang.org/download/otp_src_R14A.tar.gz
Resolving erlang.org... 193.180.168.20
Connecting to erlang.org|193.180.168.20|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 59641065 (57M) [application/x-tar]
Saving to: `otp_src_R14A.tar.gz.1'

  ... snip ...

2010-09-01 20:43:43 (38.1 KB/s) - `otp_src_R14A.tar.gz.1' saved [59641065/59641065]

oj@nix ~/blog $ tar -xvzf otp_src_R14A.tar.gz
otp_src_R14A/
otp_src_R14A/erts/

  ... snip ...

otp_src_R14A/system/COPYRIGHT
oj@nix ~/blog $ cd otp_src_R14A/
oj@nix ~/blog/otp_src_R14A $ ./configure
Ignoring the --cache-file argument since it can cause the system to be erroneously configured
Disabling caching
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for gcc... gcc

  ... snip ...

oj@nix ~/blog/otp_src_R14A $ make
test X"$ERTS_SKIP_DEPEND" = X"true" || (cd erts/emulator && ERL_TOP=/home/oj/blog/otp_src_R14A make generate depend)
make[1]: Entering directory `/home/oj/blog/otp_src_R14A/erts/emulator'
make -f x86_64-unknown-linux-gnu/Makefile generate
make[2]: Entering directory `/home/oj/blog/otp_src_R14A/erts/emulator'

  ... snip ...

=== Leaving application dialyzer
make[1]: Leaving directory `/home/oj/blog/otp_src_R14A/lib/dialyzer'
oj@nix ~/blog/otp_src_R14A $ sudo make install

  ... snip ...

oj@nix ~/blog/otp_src_R14A $

Done! Let's confirm that it has been set up correctly:

oj@nix ~/blog $ erl
Erlang R14A (erts-5.8) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.8  (abort with ^G)
1> q().
ok

Excellent. Next let's get Riak going.

Installing Riak 0.12

Considering the power of the software you are about to set up, it is absolutely insane how easy it is to get it running. If any of you have tried to get CouchDB running you'll no doubt have experienced a few quirks and a bit of pain getting it rolling. Not so with Riak. As mentioned at the start of the article, make sure you have a recent version of Mercurial and Git installed.

oj@nix ~/blog/riak $ hg --version
Mercurial Distributed SCM (version 1.6)

Copyright (C) 2005-2010 Matt Mackall  and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
oj@nix ~/blog/riak $ git --version
git version 1.6.3.3
oj@nix ~/blog $ hg clone http://hg.basho.com/riak
destination directory: riak
requesting all changes
adding changesets
adding manifests
adding file changes
added 1565 changesets with 4058 changes to 1225 files
updating to branch default
53 files updated, 0 files merged, 0 files removed, 0 files unresolved
oj@nix ~/blog $ cd riak
oj@nix ~/blog/riak $ make
./rebar get-deps
==> rel (get-deps)
==> riak (get-deps)
Pulling riak_kv from {hg,"http://bitbucket.org/basho/riak_kv","tip"}

  ... snip ...

==> riak_kv (get-deps)
Pulling riak_core from {hg,"http://bitbucket.org/basho/riak_core","tip"}

  ... snip ...

Pulling riakc from {hg,"http://bitbucket.org/basho/riak-erlang-client","tip"}

  ... snip ...

Pulling luke from {hg,"http://bitbucket.org/kevsmith/luke-mr","tip"}

  ... snip ...

Pulling erlang_js from {hg,"http://bitbucket.org/basho/erlang_js",
                           "erlang_js-0.4"}

  ... snip ...

Pulling bitcask from {hg,"http://bitbucket.org/basho/bitcask","tip"}

  ... snip ...

Pulling ebloom from {hg,"http://bitbucket.org/basho/ebloom","ebloom-1.0.1"}

  ... snip ...

==> riak_core (get-deps)
Pulling protobuffs from {hg,"http://bitbucket.org/basho/protobuffs",
                            "protobuffs-0.5.0"}

  ... snip ...

Pulling webmachine from {hg,"http://bitbucket.org/basho/webmachine",
                            "webmachine-1.7.1"}

  ... snip ...

==> protobuffs (get-deps)
==> webmachine (get-deps)
Pulling mochiweb from {hg,"http://bitbucket.org/basho/mochiweb",
                          "mochiweb-1.7.1"}

  ... snip ...

==> mochiweb (get-deps)
==> riakc (get-deps)
==> luke (get-deps)
==> erlang_js (get-deps)
==> ebloom (get-deps)
==> bitcask (get-deps)
./rebar compile
==> protobuffs (compile)
Compiled src/protobuffs.erl

  ... snip ...

==> mochiweb (compile)
Compiled src/mochifmt_std.erl

  ... snip ...

==> webmachine (compile)
Compiled src/wmtrace_resource.erl

  ... snip ...

==> riak_core (compile)
Compiling src/riak_core.proto

  ... snip ...

==> riakc (compile)
Compiling src/riakclient.proto

  ... snip ...

==> luke (compile)
Compiled src/luke_flow_sup.erl

  ... snip ...

==> erlang_js (compile)
Compiled src/js_drv_comm.erl

  ... snip ...

Running make -C c_src

  ... snip ...

==> ebloom (compile)
Compiled src/ebloom.erl
Compiling c_src/ebloom_nifs.cpp
==> bitcask (compile)
Compiled src/bitcask_sup.erl

  ... snip ...

==> riak_kv (compile)
Compiled src/riak_kv_wm_ping.erl

  ... snip ...

==> rel (compile)
==> riak (compile)
oj@nix ~/blog/riak $

I snipped a lot of the make output for obvious reasons. Let's build a few development nodes of Riak and cluster them together as indicated in the Riak Fast Track:

oj@nix ~/blog/riak $ make devrel
mkdir -p dev
(cd rel && ../rebar generate target_dir=../dev/dev1 overlay_vars=vars/dev1_vars.config)
==> rel (generate)
mkdir -p dev
(cd rel && ../rebar generate target_dir=../dev/dev2 overlay_vars=vars/dev2_vars.config)
==> rel (generate)
mkdir -p dev
(cd rel && ../rebar generate target_dir=../dev/dev3 overlay_vars=vars/dev3_vars.config)
==> rel (generate)
oj@nix ~/blog/riak $ cd dev
oj@nix ~/blog/riak/dev $ dev1/bin/riak start
oj@nix ~/blog/riak/dev $ dev2/bin/riak start
oj@nix ~/blog/riak/dev $ dev3/bin/riak start
oj@nix ~/blog/riak/dev $ dev2/bin/riak-admin join dev1
Sent join request to dev1
oj@nix ~/blog/riak/dev $ dev3/bin/riak-admin join dev1
Sent join request to dev1
oj@nix ~/blog/riak/dev $ curl -H "Accept: text/plain" http://127.0.0.1:8091/stats
{

  ... snip ...

    "nodename": "dev1@127.0.0.1",
    "connected_nodes": [
        "dev2@127.0.0.1",
        "dev3@127.0.0.1"
    ],

  ... snip ...

    "ring_members": [
        "dev1@127.0.0.1",
        "dev2@127.0.0.1",
        "dev3@127.0.0.1"
    ],
    "ring_num_partitions": 64,
    "ring_ownership": "[{'dev3@127.0.0.1',21},{'dev2@127.0.0.1',21},{'dev1@127.0.0.1',22}]",

  ... snip ...

oj@nix ~/blog/riak/dev $

As we can see from the curl output, we now have a 3-node Riak cluster up and running. Those three nodes have the following traits:

We can talk to any of these nodes and they will replicate their data to the other nodes. Nifty! Now that we have a Riak cluster running for development, let's get Webmachine ready.

Installing Webmachine 0.7.1

Again, the process is very simple:

oj@nix ~/blog $ hg clone http://hg.basho.com/webmachine
destination directory: webmachine

  ... snip ...

oj@nix ~/blog $ cd webmachine/
oj@nix ~/blog/webmachine $ make
==> webmachine (get-deps)
Pulling mochiweb from {hg,"http://bitbucket.org/basho/mochiweb",
                          "mochiweb-1.7.1"}

  ... snip ...

==> mochiweb (get-deps)
==> mochiweb (compile)
Compiled src/mochifmt_std.erl

  ... snip ...

==> webmachine (compile)
Compiled src/wmtrace_resource.erl

  ... snip ...

As you can see, Webmachine sits on top of the Mochiweb web server.

To create our own application which sits on top of Webmachine, we can utilise the new_webmachine.sh script. So let's do that to create our Code Smackdown (csd) site:

oj@nix ~/blog/webmachine $ scripts/new_webmachine.sh
usage: new_webmachine.sh name [destdir]
oj@nix ~/blog/webmachine $ scripts/new_webmachine.sh csd ..
==> priv (create)
Writing /home/oj/blog/csd/README
Writing /home/oj/blog/csd/Makefile
Writing /home/oj/blog/csd/rebar.config
Writing /home/oj/blog/csd/rebar
Writing /home/oj/blog/csd/start.sh
Writing /home/oj/blog/csd/ebin/csd.app
Writing /home/oj/blog/csd/src/csd.erl
Writing /home/oj/blog/csd/src/csd_app.erl
Writing /home/oj/blog/csd/src/csd_sup.erl
Writing /home/oj/blog/csd/src/csd_resource.erl
Writing /home/oj/blog/csd/priv/dispatch.conf
oj@nix ~/blog/webmachine $

Webmachine generates a fully functional website out of the box. So we should be able to build it, fire it up and see it in action:

oj@nix ~/blog/webmachine $ cd ../csd
oj@nix ~/blog/csd $ make
==> csd (get-deps)
Pulling webmachine from {hg,"http://bitbucket.org/basho/webmachine","tip"}

  ... snip ...

==> webmachine (get-deps)
Pulling mochiweb from {hg,"http://bitbucket.org/basho/mochiweb",
                          "mochiweb-1.7.1"}

  ... snip ...

==> mochiweb (get-deps)
==> mochiweb (compile)
Compiled src/mochifmt_std.erl

  ... snip ...

==> webmachine (compile)
Compiled src/wmtrace_resource.erl

  ... snip ...

==> csd (compile)
Compiled src/csd_app.erl
Compiled src/csd_resource.erl
Compiled src/csd.erl
Compiled src/csd_sup.erl
oj@nix ~/blog/csd $ ./start.sh
Erlang R14A (erts-5.8) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false]

  ... snip ...

=PROGRESS REPORT==== 1-Sep-2010::21:19:41 ===
          supervisor: {local,csd_sup}
             started: [{pid,<0.65.0>},
                       {name,webmachine_mochiweb},
                       {mfargs,
                           {webmachine_mochiweb,start,
                               [[{ip,"0.0.0.0"},
                                 {port,8000},
                                 {log_dir,"priv/log"},
                                 {dispatch,[{[],csd_resource,[]}]}]]}},
                       {restart_type,permanent},
                       {shutdown,5000},
                       {child_type,worker}]

=PROGRESS REPORT==== 1-Sep-2010::21:19:41 ===
         application: csd
          started_at: nonode@nohost

The application is now up and running. As you can see from the output, our csd application has been fired up and is listening on port 8000. Let's fire it up in a web browser to see if it works.

It's alive! We're almost done. Before we finish up, let's get set up our build to include some dependencies.

Adding ErlyDTL and Riak Client Dependencies

Rebar makes this bit a walk in the park (thanks Dave, you rock!). Just make sure you stop your Webmachine node before continuing by typing q(). into your Erlang console.

The rebar.config file is what drives rebar's dependency mechanism. We need to open this file and add the entries we need to include in our application. Webmachine's start.sh script by default includes all of the dependencies on start up, so after modifying the configuration, we don't have to do anything else (other than use the library of course).

Open up rebar.config in your favourite editor, it should look something like this:

%%-*- mode: erlang -*-
{deps, [{webmachine, "1\.7.*", {hg, "http://bitbucket.org/basho/webmachine", "tip"}}]}.

Edit the file so that it includes both ErlyDTL and the Riak Client:

%%-*- mode: erlang -*-
{deps,
  [
    {webmachine, "1\.7.*", {hg, "http://bitbucket.org/basho/webmachine", "tip"}},
    {riakc, ".*", {hg, "http://hg.basho.com/riak-erlang-client", "tip"}},
    {erlydtl, "0.6.1", {git, "http://github.com/OJ/erlydtl.git", "master"}}
  ]
}.

You'll notice that the erlydtl reference points at my own fork of the ErlyDTL project. This is because I have made it compile cleanly with rebar so that any dependent projects are also able to be build with rebar. Feel free to use your own fork if you like, but mine is there if you can't be bothered

Save the file and build!

==> mochiweb (get-deps)
==> webmachine (get-deps)
==> csd (get-deps)
Pulling riakc from {hg,"http://hg.basho.com/riak-erlang-client","tip"}

  ... snip ...

Pulling erlydtl from {git,"http://github.com/OJ/erlydtl.git","master"}

  ... snip ...

Initialized empty Git repository in /home/oj/blog/csd/deps/erlydtl/.git/
Already on 'master'
==> riakc (get-deps)
Pulling protobuffs from {hg,"http://bitbucket.org/basho/protobuffs",
                            "protobuffs-0.5.0"}

  ... snip ...

==> protobuffs (get-deps)
==> erlydtl (get-deps)
==> mochiweb (compile)
==> webmachine (compile)
==> protobuffs (compile)
Compiled src/protobuffs_compile.erl
Compiled src/protobuffs_parser.erl
Compiled src/protobuffs.erl
Compiled src/pokemon_pb.erl
==> riakc (compile)
Compiling src/riakclient.proto
Compiled src/riakc_obj.erl
Compiled src/riakc_pb.erl
Compiled src/riakc_pb_socket.erl
==> erlydtl (compile)
Compiled src/erlydtl/erlydtl.erl
Compiled src/erlydtl/erlydtl_i18n.erl
Compiled src/erlydtl/erlydtl_runtime.erl
Compiled src/erlydtl/erlydtl_scanner.erl
Compiled src/erlydtl/i18n/po_scanner.erl
Compiled src/erlydtl/i18n/i18n_manager.erl
Compiled src/erlydtl/erlydtl_compiler.erl
Compiled src/erlydtl/i18n/sources_parser.erl
Compiled src/erlydtl/i18n/po_generator.erl
Compiled src/erlydtl/erlydtl_deps.erl
Compiled src/erlydtl/erlydtl_dateformat.erl
Compiled src/erlydtl/erlydtl_filters.erl
Compiled src/tests/erlydtl_dateformat_tests.erl
Compiled src/tests/i18n/sources_parser_unittests.erl
Compiled src/tests/erlydtl_functional_tests.erl
Compiled src/tests/gettext.erl
Compiled src/tests/erlydtl_example_variable_storage.erl
Compiled src/tests/erlydtl_unittests.erl
Compiled src/erlydtl/erlydtl_parser.erl
==> csd (compile)
oj@nix ~/blog/csd $

Dependencies sorted. For the final part of this blog post, we'll include a basic ErlyDTL template and use it to render the page so we can see how it works.

Rendering an ErlyDTL Template

Rebar has built-in support for the compilation of ErlyDTL templates. It can be configured to behave how you want it to, but out of the box it...

• ... looks for *.dtl files in the ./templates folder
• ... compiles each of the found templates into a module called filename_dtl (eg. base.dtl becomes the module base_dtl)
• ... puts the module beam files into the ebin directory

Very handy. Let's create a very simple template by creating a templates folder, and editing a new file in that folder called sample.dtl

<html><body>Hello from inside ErlyDTL. You passed in {{ param }}.</body></html>

Then open up src/csd_resource.erl and search for the to_html() function. It should look like this:

to_html(ReqData, State) ->
    {"<html><body>Hello, new world</body></html>", ReqData, State}.

Modify it to look like this:

to_html(ReqData, State) ->
    {ok, Content} = sample_dtl:render([{param, "Slartibartfast"}]),
    {Content, ReqData, State}.

For now, don't worry about the content of this file. I will cover this off in a future post.

We need to include our template module in our application definition so that rebar doesn't complain at us. So open ebin/csd.app and add the sample_dtl module to the module list:

%%-*- mode: erlang -*-
{application, csd,
 [
  {description, "csd"},
  {vsn, "1"},
  {modules, [
             csd,
             csd_app,
             csd_sup,
             csd_resource,
 
             % ErlyDTL templates
             sample_dtl
            ]},
  {registered, []},
  {applications, [
                  kernel,
                  stdlib,
                  crypto,
                  mochiweb,
                  webmachine
                 ]},
  {mod, { csd_app, []}},
  {env, []}
 ]}.

We are done! Let's make, run and view:

oj@nix ~/blog/csd $ make
==> mochiweb (get-deps)
==> webmachine (get-deps)
==> protobuffs (get-deps)
==> riakc (get-deps)
==> erlydtl (get-deps)
==> csd (get-deps)
==> mochiweb (compile)
==> webmachine (compile)
==> protobuffs (compile)
==> riakc (compile)
==> erlydtl (compile)
==> csd (compile)
Compiled src/csd_resource.erl
Compiled templates/sample.dtl
oj@nix ~/blog/csd $ ./start.sh
Erlang R14A (erts-5.8) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false]

  ... snip ...

** Found 0 name clashes in code paths 

  ... snip ...

=PROGRESS REPORT==== 1-Sep-2010::22:37:59 ===
         application: csd
          started_at: nonode@nohost

Notice how ErlyDTL outputs some information to indicate that no template names have clashed with any other modules.

The application is now running, let's see what it looks like:

The End

We now have a working environment in which to do our development. In the next post, I'll cover some of the basics required to get Webmachine talking to Riak via Protocol Buffers.

Feedback and criticism welcome!

This month we have three speakers, and I am one of them! In my talk, "Erlang - Why should you care?", I will be giving a fairly non-technical introduction to Erlang. I'll be covering off the features of the language, some of its design goals and its history. I aiming to show that this language is not one that was spawned out of academia and that it has been applied in the real-world ever since its conception. If I have time, I'll also be giving a small demonstration of one of the neatest features of the technology.

I'll be posting the slides and demonstration code here on this blog as well as BFPG's home after the meetup has taken place.

Myself and my comrades, Tom and Tony, will aim to provide a fun and interesting evening at our new venue. Based on the RSVPs so far, it looks like we are going to have one of the biggest turn-outs to date. This is probably due to the exposure we got during last month's talk by Dave Thomas. There are still plenty of spots left, so if you're keen to come along, go and sign up. Bring your friends, your friend's friends and your mum.

I hope to see you there!

Update (6th July 2010): We had a fantastic turn-out of just short of 50 people (a record breaker for the group so far!). My talk seemed to be fairly well-received. No rotten tomatoes were thrown and the crowd seemed engaged through most of the talk. It felt good! I think many people wanted to see more code, but since that wasn't the focus of the talk they were a little disappointed. If people are keen for more Erlang goodness at future meetups, then I'll be happy to dive a little deeper.

As promised, here are the slides:

1. PPTX
2. PDF (Google Docs)
3. PPT (Google Docs)

If you have issues reading the slide deck, or would like it in another format, then please drop me a line.

The talk was covering Functional Programming and the NoSQL movement (which, as Dave himself puts it, should be called NoRDB). These are two areas of computing that are currently key interests of mine, so it won't come as a surprise to find that I thoroughly enjoyed the talk. I certainly wasn't the only one. Dave did such a great job of covering the positives of these two movements that we're already seeing more and more people signing up for membership to BFPG.

I'm not going to go into the gory details about what Dave covered in his talk as I don't want to spoil it for other people if he plans on doing it again elsewhere. There are a few things I would like to mention though:

• Functional Programming is here to stay. If you're not familiar with it, or haven't yet taken a look at it, I suggest you get started!
• If you're looking to get involved with FP and you're in or around the Brisbane area, be sure to come to one of our BFPG meetups.
• Don't fall into the trap of assuming that if your system needs a back-end data store that an RDBMS is the only option, because it's not!

This talk has inspired me to not only continue checking out the likes of Haskell, Erlang and Riak, it's pointed me at some languages that I never knew existed. Languages which are insanely powerful, very dense, yet still extremely useful. Some examples are J, K and Q. KDB+ in particular is very interesting as it ties in with the use of another type of technology that I was aware of but knew nothing about: Column Databases. Crazy stuff.

After seeing so many people excited by the prospect of Functional Programming after Dave's talk had concluded, I decided to set up a new website for BFPG so that we had a proper home rather than just a spot on Meetup.com. Check it out and feel free to send through some feedback if you have any, or drop us a line if you have any ideas for talks or would like to present something yourself.

That's it for today's brain-fart

As cheesy as it sounds, I'm going to start off with a definition ripped straight off Dictionary.com:

per·cep·tion

–noun

1. the act or faculty of apprehending by means of the senses or of the mind; cognition; understanding.
2. immediate or intuitive recognition or appreciation, as of moral, psychological, or aesthetic qualities; insight; intuition; discernment: an artist of rare perception.
3. the result or product of perceiving, as distinguished from the act of perceiving; percept.
4. Psychology. a single unified awareness derived from sensory processes while a stimulus is present.
5. Law. the taking into possession of rents, crops, profits, etc.

Take a moment to digest the meaning of the word. Can you see how subjective it is? One's perception varies greatly depending on the observer. The motivation of the observation is also going to skew how one is perceived. The relationship one has with the observer is also going to impact how that observer perceives you.

Finally, it's important to note that what was perceived and any point in time is not necessarily the same as what actually occurred.

Motivation for Writing

So why am I talking about this? Earlier this week, the team I am currently working with had its fortnightly iteration retrospective. Quite a few issues were raised. A few home truths were revealed. A few of the team members implied that there was a perception issue, in that what appeared to have happened in some cases is not actually what happened.

This whole issue of perception has come up on almost every job I have worked on. This time round it has motivated me to write about it as I feel that for some reason people don't really understand the core of the issue. Not only that, they fail to see that there is actually a great deal of value in learning how to manage it and use it as valuable feedback to improve yourself as a professional.

How are you Perceived?

The answer to this question will vary greatly depending on the situation, your relationship with those who are observing you and what lengths you go to in order to portray the right image.

People will look at you differently if you're a contractor compared to a permanent employee. Their expectations will be higher, and hence when you're being obvserved people will be a little more critical. The expectation is that you're there as a domain expert that is adding value directly proportional to the cost of the service that you provide. As a permanent, the expectation is that you'll do the job to a "sufficient" level, work "enough" hours and "care" enough to get things done... eventually.

There are many shades of grey within these two categories as well as between them. I won't be covering all of them, but I believe there are a few points which apply to all of them when it comes to have they are observed from the perspective of the man who is paying the bills (for example, the Project Manager).

How much time do you spend...

• ... reading and writing emails?
• ... on the phone?
• ... reading and writing blogs?
• ... talking about non-work related stuff?
• ... messing around with personal gadgets or laptops at work?
• ... going out for coffee?
• ... using some sort of instant messaging client and/or social network tools?
• ... actually at work, at your desk? (ie. do you get in late or leave early)?

Don't get me wrong here, everyone does a few of these things when at work, regardless of there position. The question is where to draw the line, to make sure you don't go too far.

Now compare these to how much time you spend...

• ... starting and/or participating in design discussions.
• ... at your desk actually doing the work you're there to do.
• ... helping others do the work they do.
• ... helper others improve the level of quality of their work.
• ... attempting to add value in areas you're not directly involved with.
• ... going above and beyond to highlight and rectify problem areas.

These are all time-based issues. There are others which relate to attitude as well. How about..?

• When participating in team discussions, stand-ups or retrospectives, how much do you get involved?
• What does your body language say about how you feel or what you're thinking about at any given time?
• Do you get involved in discussions that have nothing to do with you?
• When dealing with people who you consider to be bad at their job, or people who you either don't like or respect, does your tone of voice give away you feelings?
• Do you find yourself getting personal for any reason when discussing issues with other members of your team?
• Do you attempt to discuss things that you don't understand while attempting to make it sound like you're an expert in the matter?
• Do you attempt to abuse your position of power (if you have one) even if it's to the detriment of the project you're working on?
• Do you wear appropriate clothing to work?

There are so many more, but I won't list them all as it'd make this post even more boring

Don't underestimate how each of these things can make you look bad if you don't manage your percetpion properly. A few small things can have just as big an impact on how you are perceived as one big thing. This can be bad enough even when the observer is a friend, but it's substantially worse if the person isn't!

Skewed Perceptions

This is where it gets nasty. Skewed perceptions can have a drastic effect on the employer's view. Most of the time, the employer's view is made up of those from a selection of people including some which will work alongside you in the trenches every day. If one or more of those people have a reason to dislike you then you have to make extra effort to manage how you are viewed. The smallest things can be blown out of proportion in this situation.

People who have a reason to dislike you will make every little thing you do look worse than it actually is. A slightly delayed email response will "put them back a few hours". A broken build will cause "huge issues with the work they're doing". A controversial email thread will be considered "extremely offensive" and having a laugh with some co-workers will be seen as "highly distracting and obnoxious".

Bear this in mind while going about your daily work.

Managing Perception

Ultimately, the best way to manage perception is the most simplest way: do your job, and do it well! That's really what it boils down to. If you do your job while you're at work then by definition you're not wasting time. You're not on the phone, you're not reading blogs, and you're not wasting time at all because you're doing what you're paid to do. The only grey area here is email. There are always going to be a plethora of work-related emails, and it's important to manage those and respond to them in a timely manner. Just make sure you don't spend your day in front of *insert email client of choice*.

But let's say that for some reason you aren't doing your job for the full eight hours per day. This isn't an unrealistic scenario, because everyone has something else going on in their lives which can have an effect on them during working hours. What do you do then? How do you make sure that you're not unfairly perceived? Again, it's very simple. Here are some examples.

• Phone calls: Don't take personal calls during the day. If you have a wife/partner that you want to speak to then call them during lunch. Make sure that they only call you during lunch or when it's an absolute emergency. If you have some other high-priority thing going on (eg. you're buying a house and you have to make sure the solicitors are doing their job) then make sure that you inform your manager/workmates. Tell them that you're expecting to deal with this issue during the day and that you'll be making an effort to keep it to a minimum. This means that if you're on the phone, people won't be asking questions as to why. Also, when taking calls, do yourself a favour and move away from your desk. Your colleagues don't want to hear the conversation (especially if it involves sentences like "I love you baby. Kissy-wissy! Love you!"). Give your colleages the space they deserve and go outside or to a private room. But make sure you keep it short.
• Coffee: I can be bad for this one sometimes. In short, get your coffee before you go to work. Don't take trips out after arriving. This can apply to other things such as late breakfasts.
• Care-factor: So you're in a meeting and you're either pissed off because of something someone said, or you're just not interested. We've all been there right? Er... have we? Anyway, let's say we have. Sitting there looking very disinterested isn't going to do you any favours. Don't constantly look at your watch. Don't glare at people like a sourpuss. Don't check your phone every 60 seconds to see if something more interested has landed in your inbox or Twitter stream. Pay attention! Sit up. Contribute something. At least do your colleagues the justice of listening to them and see if you can add value somewhere.
• Passive-aggressive behaviour: This comes in so many forms. Via emails, via jokes, via general conversation. It's a bad thing to do. It can be as subtle as a comment like "You're the Lead now, it's your problem". Avoid the jibes. Deal with the situation in a professional manner instead of behaving like a petulant child.
• Personality clashes: Someone at work has an issue with you, or you have an issue with them. Rather than let things turn bad, nip it in the bud. Take the person to one side and have a constructive discussion with them. Find out what it is that pisses them off, and try to deal with it. Attempting to work alongside someone when the air not clear not only causes issues for the two of you but can also be very distracting for the rest of the team.
• Caring too much: The work means more to you than the other people you're working with. You care about quality, standards, managing costs and expectations and you make an effort to stay in touch with the world you work in. The fact that your colleagues aren't like you infuriates you. This becomes evident in everything you do purely because of the anger and/or dismissiveness that you display whenever you interact with them. This fits into the professionalism category. Deal with it like a professional. I'm not asking you to like them any more, nor to lower your standards in any way. I'm asking you to learn to work around them. There will always be people that you work with that will make you feel like this (especially if you work in the government or in enterprise software). Learn to manage it and deal with your anger.
• Proactivity: This is something that isn't only going to improve your perception but will ultimately make you a better professional. Demonstrate some forethought for the area you work in. Read up on things in your own time and share them with your colleagues when you get to work. Constantly review your work methods and see how you can improve. If you find a way of improving yourself, you can again share that with people, but make sure you emphasise that you got a lot of value of it first. Make an effort to preempt some issues and deal with them up front rather than putting them off. Try to look past today's work and see what's coming down the track. Don't just look at the current line of code, be aware of the bigger picture. Don't be constrained to your field. If you're a tester you can improve the life of a developer (and vice versa).
• Do your hours: While a bigger issue for contractors, this definitely applies to permies as well. It's simple: do your hours! You get paid to do around eight hours of work per day. Less if you're a government employee. Eight hours is not that difficult. Whether you like it or not, your hours will in some way be monitored, and the perception of you will change if you don't do what is expected. Getting to work earlier than other doesn't mean you have the right to do less hours. If you rock up earlier, yes you can leave earlier, but if you're taking a lot of time out for personal stuff or lunches, then you should make the effort to stay back longer and make up for the time you have lost.
• Punctuality: Get to work on time, especially if you're a contractor. Rocking up after 9am most days doesn't look good, especially if you leave before 5pm and take a full hour for lunch. Get to meetings on time. There's no excuse for tardiness and it makes you look very unprofessional while wasting other people's time.
• Deal with criticism/feedback: When people have the nerve to come to you and talk openly about issues, be open to them and don't get angry. Don't try and justify your position by pointing out the flaws in other people. Don't attempt to make it sound like you're no different to anybody else. Listen to what people are saying. Use that information to better yourself as a person and as a professional. The best thing to do is separate yourself from the rest by learning from what you hear.

Trying Too Hard

When the issue of perception raises its ugly head, most people attempt to solve the problem instantly. This cannot be done. Changing people's perception of you is something that takes a long time. It's not something that will happen within a day, a week, or even a month. Expect it to take quite a while.

Here are some sure signs that you're trying too hard:

• You email everyone every time you do something related to your job. You're attempting to demonstrate that you're doing your work, but all you achieve by doing this is annoying everyone. You don't need to email everyone all the time. Only when it's relevant should you make the effort. Don't add noise, just try to add signal.
• You get involved in discussions that are outside of your area of expertise. I don't think I need to elaborate here. (this post is a classic example ).
• You make a point of highlighting other people's faults.
• You take the time to add value to anything and everything you can, splattering your workplace with "look how good I am" propoganda.
• Including lots of people in email threads when they don't need to be.

Instead of putting effort into directly changing how people perceive you, the best thing to do is change the way you work. Focus on doing your job better.

By the way, please let me know if you know of any more signs!

Conclusion

Perception tends to be directly related to your quality of work, though it can sometimes be skewed by interpersonal issues. Managing how you're perceived is actually very simple. If you care about your job and you want to do well you'll find that the whole perception issue fades into the background.

If you're floating along in a job you don't like or with people you don't like, and you're not really giving it 100%, then chances are you going to face this problem sooner rather than later.

Step up. Improve yourself for your own benefit, and you'll find that the rest of the perception issues will go away.

Thoughts, feedback, abuse and cheap-shots are, as always, very welcome

"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!