This leads to that I really like things like auto formatting because I strongly believe in that it will every now and then make different choices than humans since it always follows its own rules 100%.

When looking through the diff prior to committing the changes that an auto formatter has made to a file every now and then that will cause me to read functions that I've either never looked at before or just not looked at in a really long time.

Every now and then that leads to that I find a function where there is some really gnarly-looking code that I realise could be simplified a lot.

This is kind of like striking gold for the neatness-obsessed among us. My favourite git commits are the ones with a lot more minuses than plusses, shortening the code and making it more readable has an immense value when you are still supporting it five years down the line and you need to be able to glance at it and see what it does.

More than once this has even lead to me finding code that is actually wrong if given some specific input parameters that it has just never been fed before.

I do not agree with the notion that commits that are just whitespace changes should be avoided because of them "not actually doing anything" and "cluttering up commit history". There is more value to it than you may think.

Heck, goto fail was even a bug that would have been much quicker to spot with correct whitespace formatting.

Don't hate on whitespace commits, they may help you more than you think.

To get this out of the way: I have the 42mm space grey sport edition Apple Watch and I have the original Pebble (not the Kickstarter edition, the retail edition).

I was a Pebble user for almost two years, and now I've been an Apple Watch user for two and a half weeks and... (Spoiler Alert) I really wouldn't want to go back to the Pebble.

Don't get me wrong, I loved my Pebble. I wore it all day every day (and even most nights) up until the day I took my Apple Watch out of its packaging and put it on.

It's hard to tell from the photo at the top but my Pebble has some serious battle scars with deep scratches and a deep cut in the plastic on the left side, it's been with me for a lot.

It also has a weird metal link watch band which is too narrow for the watch that I put on after my original Pebble watch band broke and I didn't want to be without it for a day so I grabbed the band of an old Casio watch I used to wear back in the day and never got around to replacing it.

The Pebble has some amazing features: It lasts 5-7 days on a charge, the screen always shows something, it gets notifications, it has a ton of apps that do everything from fitness and sleep tracking to really basic games, it has a ton of watch faces (The one I really got stuck on is called "Revolution") and it has physical buttons for some controls so you can operate it without looking (something which may seem counter-intuitive for a watch).

The Apple Watch does... most of that. It gets notifications, there are already a ton of apps with watch extensions, and while there aren't any third-party faces some of the faces that Apple provided are really pretty (I'm using "Utility"). Part of me wishes there were more digital faces as years of wearing digital watches has made me slower at reading analog watches but there is something beautiful about an analog watch face.

The Apple Watch only does about a day on a charge. I tend to end even long days with about 40% left, so could probably do a day and a half but that would be kind of inconvenient to recharge in the middle of the day.

I initially thought I would really hate having to charge every day, but it turns out that just adding it alongside charging my phone is fine and I never really got into sleep tracking because if I know how poorly I sleep I'll just be kept up by the stress of that.

Actionable notifications on my watch is brilliant. Like for example getting a notification for an e-mail and if I don't really have to care about it just hit archive right away.

The watch apps for the Apple Watch are hit and miss. Apple's apps all work well, and some third party ones like Spark, Overcast, 1Password, Authy, MacID etc are brilliant but some are also completely useless. This is actually not unlike the Pebble where some watch apps just wouldn't work.

The Apple Watch has fewer physical buttons than the Pebble as it has a touch screen. I actually really like the combination of the touch screen and the digital crown for scrolling and the only instance where I think the Pebble was easier sometimes was that I could change to the next track without looking at the watch.

I never use the friends button on the Apple Watch, maybe I don't have enough friends but I just don't see the point. Hence it would be really nice if I could choose to remap that to something else or that apps could make use of it, so that is something I hope comes in eventual versions of watchOS.

Then comes the thing that everyone who hasn't had a smart watch comments on, the fact that the screen turns off when you don't look at it on the Apple watch.

I initially thought this would really bother me, but I realised after wearing the Pebble that it is actually kind of a feature. The Pebble automatically lights up the backlight when there is an incoming notification, which means it kind of calls attention to itself.

The Apple Watch does not, but rather just taps me on the wrist and then I can look at it when I want and it will only show it to me. This is actually something that is great because it makes me feel less self-conscious when receiving more personal notifications that I may not want other people to read.

I also realised that I don't care if when other people look at my watch they can't see the face of it like an ordinary watch. If they want to read the time then they can get their own watch after all...

After all that is said and you start looking at the things that aren't really easily marked up in a pros and cons tech specs table that is where I think the Apple Watch really shines.

Things like that the vibrator in the Pebble is so strong it feels like it's shaking your entire arm whereas the Apple Watch's Taptic engine is nice and gentle or that you really have to shake the Pebble watch to light it up and the Apple Watch just requires you to raise your wrist.

Combine this with that the Apple Watch looks like a piece of jewellery, the screen on it is gorgeous and the integration with iOS is much better than Apple will ever let the Pebble be and you have a pretty clear winner to me.

I do like the Pebble's "nerd retro feel" and it is a pretty cool "gadget watch", but the Apple Watch feels like a cool "real watch" that evokes similar feelings for me as wearing an Omega or a Breitling.

I do know of the Pebble Steel which do look more in the spectrum of "normal" watches, but I actually think that takes away a bit of the charm of the Pebble as then it kind of loses the "nerd retro feel" without really taking enough of a step towards the luxury sector. This kind of leaves it in an in-between area where it sadly doesn't really appeal to me at all.

In the end the Pebble kind of feels like the cheap Casio watches I wore for years when I was younger and the Apple Watch feels like a "grown up watch" which means it suits me very well at the point in life where I am at right now.

UPDATE: Turns out that the album recommendations from Apple Music are algorithmically generated but the playlists are only human created.

I also got some albums recommended now that were obviously algorithmic so it definitely works, so disregard my comments below that Apple Music doesn't do algorithmic recommendations.

I don't normally write reviews on my blog but I figured this was as good of a place as any to post my feelings.

I've used Apple Music since June 30th and today is the 4th of July so I've only really used it for about five days. It might seem like a short time but I already have some pretty clear opinions.

To give some back story I've used quite a few streaming services over the years along with also running iTunes Match. Most recently I've been an Rdio subscriber and a Google Play Music user.

Basically I like both but don't love either, and they both have things that I don't like. However in combination they do show some true greatness.

Now, looking at Apple Music in comparison basically it does everything Play Music does and has a better catalogue so there it is just clearly better.

Comparing it to Rdio is less of a 1:1 though as they have some different approaches to things.

In terms of catalogue they seem about the same, so there it is a draw I think. This might be a bit different in some way I haven't noticed yet as it hasn't been super-long. It is also nice to be able to cover holes in the catalogue with my own tracks in my iTunes library.

The way the different services do recommendations is very different. Apple Music goes for human curation and Rdio uses algorithms.

This means that Apple Music gets more cohesive playlists and they can solve problems in connections in ways computers can't based on what algorithms can automate today.

It also means that it's dependent on one person on staff having the same taste as you for the recommendations to be any good. As someone with a wide taste in music I've found that they are better within some genres than others, but in the genres where they are good they are really good.

As a related note to Apple; If you need someone to put together playlists for more extreme genres like Black Metal drop me a line and I can hook you up.

On the other hand Rdio does have all the issues that algorithms have over humans. It will sometimes think two artists are similar because a lot of people listen to both etc and will give some crazy transitions.

It will sometimes strike pure gold though when in truly obscure territory even when you're listening to stuff Apple is unlikely to ever hire someone who listens to enough to write manual recommendations about.

So, no obvious winner there, and neither is really a strong swaying argument either way.

I really couldn't care less about Connect or Beats 1, so those are a wash.

The Apple Music app is better in some ways and the Rdio Apple others. To me the biggest thing I wish Apple Music did better is last.fm integration. It sucks both in iTunes and on my iPhone.

The Apple Music app has nicer management of "up next" and doesn't use flash on the desktop which is huge.

The Siri integration on the iPhone is KILLER. It is amazing in the car, and except for a few problems with overlap in names it has pretty much been perfect.

So far Apple Music has been really great, and with some work from Apple and from the developer community to fill in any holes I think it will be near perfect eventually.

This is what it looks like:

It is definitely not clean enough to fit in on the more modern "setup" or "minimal" photo galleries, and while I would love to have a desk that looks like that, to the point where I can spend hours looking through the beatuiful photos, it has not really been practical due to my personal nature and the way I work.

With that note out of the way let's do the traditional run through of the stuff, starting with the desk itself. It is a sit/stand desk, I have no idea of model or even who made it but it is pretty sturdy and has been reliable for as long as I have used it.

I actually stand more than I sit now which is why I felt it more appropriate to show it raised, even if it exposes more of my horrible cable management.

On the right you see the same MacBook Pro as in my home office photo, it is not there every day though, so what occupies the stand there varies a bit from day to day.

The main workhorse is actually behind the right monitor. It's a "trash can" Mac Pro which is still so fast it is crazy. In the photo you can make it out behind the monitor stand and the Nuiteq mug with Yoshi in it.

Speaking of monitors, those are 2xDell UltraSharp monitors. Compared to 4k and 5k monitors they are nothing special, but I think they are comparable to Apple's 27" displays and they are matte so they don't blind me if I get a bit of sun in my office.

The menus on them are atrocious so you don't want to touch those and they don't like to be plugged in and out a lot so I would mostly recommend them for stationary setups.

Even with those drawbacks they are brilliant and they are about half the cost of Apple Thunderbolt displays.

Now, looking behind the left monitor you'll see a Mac Mini. It is a few years old and serves as the build machine for Snowflake for OS X. Basically it is the machine that stays back on an older version of OS X and that has all the packaging set up so I can reliably build new installers without having to spend a lot of time making sure updates don't break stuff.

I have meant to look into setting up a virtual machine to do this instead, but that old Mini has just been so solid I haven't really found the time to or really felt the urge to do so being that strong.

Since I just keep skipping around in random order on top of the left monitor you'll see a Logitech C920. One of the best webcams hands down. If you ever see any video of me from my office it is most likely shot on that webcam.

On top of the right monitor is a Star Wars bounty hunter miniature, just because I can.

Now we get to the stuff in front of the monitors, starting with that way out on the left you see my testing iPad. It's a 4th gen iPad at the base configuration. When I do iOS development that is my test device along with my own devices that I own.

Next to that is a roll of clear tape, surprisingly useful to keep nearby to work out more things than you would think.

Next to it is a cup with an old company logo on it with the name Harry on it. It is obviously not my name but it still functions as a container for liquid, most often water.

Next to that is a box of business cards turned sideways and some cards with NFC tags in them I've used for testing NFC stuff. They are basic enough that they are really easy to use as dummy tags and they are free as they are given to visitors at a museum.

To the right of that is my trusty Nokia N800. Sadly the charger is nowhere to be found so it is permanently out of power and more serves as decoration than as something actually functional.

In front of that is a bit of an unusual thing, a Tobii Rex/eyeX eye tracker. While I don't use it a lot it is a quite interesting piece of hardware and I have played around with the SDK for it to build some pretty fun stuff.

In front of that is a Lego X-Wing and its pilot.

Next is my Belkin iPhone dock, with no phone in it because I used the phone to take the photo, and behind that is a Lego Yavin 4.

Then to the right of that is a Lacie 1TB USB3 hard drive I use to fit stuff when space on my precious 256GB SSD fills up.

On top of that is an interesting bit of hardware, a CleverPad Android tablet. Overall it's a pretty average Android tablet in the "high end" segment, and for that tablet the lack of exotic hardware is what makes it a pleasure to use. Things just work as you expect on it with no surprises. It is just plain solid and reliable.

Next to that is the cup with the old company logo with my own name on it, which is home to my plush Yoshi.

Then just next to my laptop, in front is a snow speeder and the planet Hoth, with Kasuga "Osaka" Ayumu, Lonardo and an old fourth gen iPod Touch behind them. The iPod touch started life as a test device but by now it is too old to run newer versions of iOS so it mostly just sits there.

Now we get to the keyboard tray which is in front.

To the left is a pair of SteelSeries Siberia V2 Frost Blue. Just seeing those will make audiophiles recoil in horror as it is a gaming headset and not proper hi-fi headphones.

They have a few very notable features though which are why I use them, most importantly:

1. I got them for free, the best feature ever.
2. They are really light, so comfortable even after hours and hours
3. Incredibly sturdy, I've dropped them on the floor so many times and there hasn't been any noticeable effect
4. They have a built in mic which is retractable. It is not as good as the mics podcasters talk about but it is decent and tucks away really nicely.
5. It is USB, which means it works on any mac with both mic and sound unlike headsets which use 2x3.5mm cables as a lot of macs don't have 3.5mm in.
6. Hardware mute switch and volume control on the cable. Really convenient for conference calls.
7. They don't leak too much sound from the inside out, and they don't leak too much sound from the outside in.
8. Sound quality is not terrible. They have flaws but I have learned to live with them because of features 1-7. I've also found that it matters a lot less at work than at home as I rarely have time to focus on the details of what I'm listening to while working. So as long as it's not obviosly terrible it's fine.

Coming back to the tape as you'll see I have the place where you can separate the USB cable taped down on the desk so I don't accidentally unplug it and it keeps the cable from tangling.

Then is my Magic Trackpad, which I've come to use more and more as a way to make sure I vary my movements to make sure I don't make my RSI worse.

To the right of that is my keyboard. Up until a few weeks ago that spot was held by a Razer BlackWidow much like in my home setup, but due to some kind of short circuit or bad solder joint or something like that it started doing really weird things. Eventually to the point where it had to be replaced.

While I do like the original BlackWidow every generation after the first one have not been as good in my opinion. It seems that it is due to that Razer started making their own "Razer Green" switches instead of the Cherry MX Blue switches they had originally.

So, after some very minimal research I decided on the CM Storm QuickFire TK, the Cherry MX Blue version as MX Blues are my favourite Cherry switches.

It is a bit weird with it's very special numpad/arrow/home/end/delete etc combination keys, but overall it is a very nice keyboard. On OS X I can't activate the numpad without using a script, but I have found that it is fine as I don't really miss a numpad most of the time.

I really like the compact "tenkeyless" format, it really helps with keeping my mouse and my trackpad without having to make too big moves away from the keyboard.

The blue backlight is a bit over the top and I really wish it had a white backlight instead. Overall I would probably recommend trying out the QuickFire Rapid-i over the QuickFire TK, but the QuickFire TK is still a really nice keyboard if you don't care too much about aesthetics and you can learn to deal with the special numpad.

To the right of that is... my mousepad, a SteelSeries 4HD. It's hard plastic and more or less unbreakablle in my usage so far. It also doesn't require as much cleaning as the Icemat I use at home.

On top of that is my mouse, a QPad 5K. It is one of the nicest mice I've ever used. It fits my rather large hands really well and I like how wide it is so it keeps all my fingers off of the surface under it.

I also have some gel wrist rest on my mousepad, it was from some suply store. I use it a bit on and off. Sometimes it feels like it helps and sometimes it doesn't. Hard to tell how much is real and how much is placebo.

That is it for what is in the shot except that I have some small network switches on the back of the desk to deal with the wiring for three permanent computers and some occasional "guest computers", but they are just average cheap network switches so not really that interesting to talk about.

Also outside of the pictures is a desk on the side I tend to use as place to put temporary stuff, some pens, paper and a few books.

Partially outside of the frame in the top right is also one of my favourite things in my office. A photo of my now five-year-old son smiling. Something to give me energy when deadlines are tight and I'm feeling exhausted.

Then that is it, my work setup, in way more detail than anyone ever asked for. If you've read this far I hope it's been interesting and that it makes you feel better about your own messy desk and that whatever works for you is always good.

I had done very little development previously with just a little games hacking in BASIC and C (I'll write about my history with C at some point) so this whole web thing was brand new to me.

CSS was brand new and most people barely used it, and for the little things I did I just threw some small amounts of CSS into a <style> tag in the header of my file and never really thought more about it than that.

As I progressed I got more and more interested in the server-side development part and putting together the actual pages that the user saw was not really what I was interested in at all, so as time passed and the features of the web grew in terms of what you could do with CSS and JavaScript I only followed very reluctantly.

With the browser market getting more diverse it also started to feel like more and more of a slog to keep up with keeping any site I made look relatively the same across all the browsers that were out at the time and they would also keep breaking things with every new version.

It was also the era where somehow things would never quite scale right when someone showed up with an exotic screen resolution. At the time it was not uncommon to see "Best viewed in 1024x768" but I felt that it was a lame disclaimer and I did not want to keep someone from using a site just because their computer wouldn't do the resolution I was using.

By the early 2000s PHP had also grown some of the horrible appendages that make it the terrible beast that it is today, and at the time it was pretty much the only dominant server-side platform language. This also kind of lead me to not derive much joy from the server side part of development except when I happened to manage to figure out how to do something particularly "clever".

All of this put together lead to that by the time 2005 rolled around I decided I was out of the web development game for good.

From then I primarily worked on lower level code with things ranging from games to computer vision to OS kernel code and all kinds of things in-between.

Even though I did quite a bit of networking code and that I at some point even wrote my own web server for a rather "exotic" system I didn't really do any serious web development for the next 3 years.

Then in late 2008 I did some stuff for the iPhone and I needed to do some client-server stuff. Even back then it was pretty much "the standard" to do that through a HTTP API.

I started out doing little things in PHP as that was what I knew, but I quickly came to find Rails as that was what all the developers were talking about at the time.

At that point Rails felt amazing, especially for API development with the model system and the easy JSON serialization/deserialization and the much more structured approach than the PHP I was used to and even compared to the ASP.NET at the time.

I even dared to start venturing into basic websites combined with an API for native apps to interact with. But I felt far too disconnected from front-end development by being away from it so long that it felt like too much of a stretch to learn everything I needed to do "modern" web design and I just felt like I was fighting the system because I was trying to combine "new" things with the "old" way I had done HTML in the 90s.

Then I ended up getting a website design dropped in my lap and was told "build this". It was relatively clean and simple but still something that looked nice and modern, and because of how it was going to be used it needed to be responsive.

So I set out to build the page and I decided to really try to use the latest in what was considered to be good ways of doing things. So I threw out the idea of doing s or things like that and set about learning the new div way and how to do proper modern CSS, trying to drop bad habits like inlining style tags for random objects.

I had to fight a bit with some things but overall this was a pretty great experience, and one that made me learn things like media queries, how to set up divs that expand and shrink with proper limits, how to use webfonts etc etc.

I didn't end up with the cleanest code ever but it was something that was immensely educational and that page is still up and chugging along today getting a few visitors every day.

Then as a project under the initiative we have at work to do our own projects that we have I wanted to build a system that needed a server component, a mobile app and integration with a desktop app. Because I like native code the two apps were the interesting part, but I also felt like I wanted to do something new on the server side as Rails was not that exciting any more since I already felt like I knew most of what there was to know about it.

Hence I picked Node.js for my server component. Originally I started out just writing it in raw Node but I pretty quickly moved to using Express.

This was a big eye opener for me. Just purely how basic this was on the server side making me understand how much Rails really abstracts away and how much you can do when you even do things like setting up listening on a port as part of your code. For someone who has done a lot of network programming on the socket level this was amazing.

Also things like learning a templating language with Jade which was very different from something like ERB which we used with Rails where I could just not really learn a templating language but rather just use HTML. It actually gave me a new perspective on how HTML is supposed to be a structured document and then it is up to everything else to style it to look good. I had heard and thought I understood the term "semantic markup" before this but after using this I really got it.

It was also the first time I really got to do more complex JavaScript things with JQuery as I decided that the Web client also needed to be great to better show off the value of my idea and what was possible.

It was also around this time I started tinkering with the design of my personal site more and through that I came upon things like Bootstrap and started more understanding various tools to make writing CSS easier like SASS. I had for a few years prior to this been running my website on static site generators like Jekyll or Octopress etc (I've gone through quite a few by now), and this had helped with me feeling like I could actually do something about changing up styles in a way I never felt like I could when it was running on something big and complex like WordPress.

I also wrote more and more JavaScript running in the browser because of that I felt like I finally had a grasp on modern JavaScript again because of my work with server side JavaScript using Node.

During 2014 I even started exploring JavaScript frameworks like Ember and Angular. I have yet to build anything that has actually shipped with either but I think that when the time comes for me to build something where a lot of JavaScript would be necessary I would definitely want to try actually shipping an app using Ember.

I've also done things like experiment with new JavaScript technologies like WebGL, WebSockets etc and it is very interesting to see the technologies that I know from years of use in native code are now coming to the web as well and that all my experience of tuning things for performance on the computers from yesteryear are now really valuable again when trying to get things fast in JavaScript with the overhead that running in a browser brings.

All this said writing native code is still my first love, and I do not think that the need for that is going away anytime soon. I do think that the future is connectivity and integration as no device is an island any more and being able to interoperate seems to be key for the software of tomorrow.

That said I think that you also cannot have a poor web experience for a solution. There are things a native application can do better than a web application and there are things a web application can do better than a native application, so I think that the important thing is to recognize what the strengths of each platform are and play to those. The recipe for a slam dunk seems to be to tie in native apps and web apps into your solution in the best way possible.

So, after that rant then where does this leave us? Do I "love the web" as the title states?

The answer is... it's complicated. I don't really "love" the web but it feels like another tool in my tool belt now; something that I can do and something that I can be excited about doing instead of something I am forced to do.

So, basically, in my own pragmatic way I guess that means "yes".

Take this small C++ class as an example:

// ExampleClass.h
#pragma once

namespace MyApp  
{
  /// Example Class
  class ExampleClass
  {
  public:
    ExampleClass();
    ~ExampleClass();

  private:
    ExampleClass(const ExampleClass& that);
    ExampleClass& operator=(constconst ExampleClass& that);

  public:
    bool initialize();
    void deinitialize();

  private:
    QVector mObjects;
    float mSpacing;
  };
}

// ExampleClass.cpp
#include "ExampleClass.h"

namespace MyApp  
{
  /**
  * Default constructor
  */
  ExampleClass::ExampleClass() :
    mSpacing(0.5f)
  {
  }

  /**
  * Destructor
  */
  ExampleClass::~ExampleClass()
  {
  }

  bool ExampleClass::initialize()
  {
    QVector2D pos(0,0);
    for(int i=0; i<10; ++i)
    {
      Object obj;
      obj.setPosition(pos);
      pos.setX(pos.x()+mSpacing);
      mObjects << obj;
    }
    return !mObjects.isEmpty();
  }

  void ExampleClass::deinitialize()
  {
    mObjects.clear();
  }
}

In this class mSpacing is only ever used in the initialize function but it is still set up as a member variable. This is definitely a case where mSpacing could just be local to that function.

One could argue that keeping it a member of the class means that it could easily be used in any other function added, but that is a very weak argument. as adding a float spacing = 0.5f to the functions that need it is still a lot less potential cognitive overhead and it avoids that quick mSpacing += 0.1f thrown into one function using it that causes you to need to go into a multi-hour debugging session.

It also has the big downside of adding more complexity than necessary since it means it is one more thing you should keep track of the state of.

Reducing scope is one of the simplest way to reduce the amount of "global state" that a function has to take into account.

You might not think it's too bad, but then consider an example like this:

// ExampleClass.h
#pragma once

namespace MyApp  
{
  /// Example Class
  class ExampleClass
  {
  public:
    ExampleClass();
    ~ExampleClass();

   private:
     ExampleClass(const ExampleClass& that);
     ExampleClass& operator=(constconst ExampleClass& that);

  public:
    void calculateStuff();
    void calculateMoreStuff();
    int finish();

  private:
    int mStuff;
  };
}

// ExampleClass.cpp
#include "ExampleClass.h"

namespace MyApp  
{
  /**
  * Default constructor
  */
  ExampleClass::ExampleClass() :
    mStuff(0)
  {
  }

  /**
  * Destructor
  */
  ExampleClass::~ExampleClass()
  {
  }

  void ExampleClass::calculateStuff()
  {
    mStuff = 3;
  }

  void ExampleClass::calculateMoreStuff()
  {
    mStuff *= 2;
  }

  int ExampleClass::finish()
  {
    mStuff -= 2;
    return mStuff;
  }
}

// Example test
ExampleClass example;  
example.calculateStuff();  
example.calculateMoreStuff();  
int result = example.finish(); // returns 4  

In this example if functions would ever end up being called out of order so that calculateMoreStuff would be called before calculateStuff then your results would end up different. This is of course a very simplified example because I wanted to keep the code as short as possible so you will need to use your imagination a bit here as to why you would do this.

This could easily be rewritten like this:

// ExampleClass.h
#pragma once

namespace MyApp  
{
  /// Example Class
  class ExampleClass
  {
  public:
    ExampleClass();
    ~ExampleClass();

  private:
    ExampleClass(const ExampleClass& that);
    ExampleClass& operator=(constconst ExampleClass& that);

  public:
    int calculateStuff() const;
    int calculateMoreStuff(int inStuff) const;
    int finish(int inStuff) const;

  private:
  };
}

// ExampleClass.cpp
#include "ExampleClass.h"

namespace MyApp  
{
  /**
  * Default constructor
  */
  ExampleClass::ExampleClass()
  {
  }

  /**
  * Destructor
  */
  ExampleClass::~ExampleClass()
  {
  }

  int ExampleClass::calculateStuff() const
  {
    return 3;
  }

  int ExampleClass::calculateMoreStuff(int inStuff) const
  {
    return inStuff * 2;
  }

  int ExampleClass::finish(int inStuff) const
  {
    return inStuff - 2;
  }
}

// Example test
ExampleClass example;  
int result = example.calculateStuff(); // result = 3  
result = example.calculateMoreStuff(result); // result = 6  
result = example.finish(result); // result = 4  

If you call them out of order and pass along the values then it will obviously still calculate the wrong value, but in this way it is always visible to you what is going on, and now when making one of the functions you do not have to consider that some other function may have modified your input value as it only belongs to that function. This is usually one of the big benefits that are mentioned when talking about pure functional programming and it is something that I definitely believe in. Minimising the sideeffects from most of your functions will make debugging a lot easier.

This obviously doesn't only apply to member variables in objects, it applies to any variable. Take this for example:

// objects is an array of 10 Objects
int offset = 4;  
for(int i=0; i<10; ++i)  
{
  objects[i].setNumber(offset);
}

offset = 2;  
for(int i=0; i<10; ++i)  
{
  objects[i].setOffset(offset);
}

offset = 3;  
for(int i=0; i<10; ++i)  
{
  objects[i].setLimit(offset);
}

This is a bit scary as there is a big risk of accidentally leaking state by not resetting the offset variable, and if one function was to modify it internally based on loops etc you can get a bug with values which are very hard to follow, so a much "safer" way of writing it would be like this:

// objects is an array of 10 Objects
for(int i=0; i<10; ++i)  
{
  int offset = 4;
  objects[i].setNumber(offset);
}

for(int i=0; i<10; ++i)  
{
  int offset = 2;
  objects[i].setOffset(offset);
}

for(int i=0; i<10; ++i)  
{
  int offset = 3;
  objects[i].setLimit(offset);
}

This means that the variables are always limited in scope and can not be modified by code outside of where it is supposed to be used. Some old timers might think that "this is way too expensive, you should re-use variables to not have to allocate memory" and basically they would be right if we were talking about compilers from the 80s. In the modern era compilers will optimize this to the point where it won't matter and since the gains in terms of clarity are potentially huge it is clearly worth it.

All of these examples are C++, but this of course applies to any language. You would think some of it is code 101 but it is something we could all use a reminder about every now and then. If you can make something more narrow in scope you probably should

I believe most people who read this know what kind of development I do for a living, and I obviously put a lot of effort into improving my skill with the technologies related to that.

However, there would be a big problem if that was everything I was doing.

Continuously working on different things is what keeps the imagination fresh as it makes you view things differently.

There is nothing like doing a project in a completely new language or with a completely different major framework to make you think in new patterns.

Writing code in Haskell will inform how I write C++ and to think about what pure functions without side effects can bring. Working on things in Node can make me think more about how to write async stuff. Working in Io makes me think more about dynamicness and what function calls vs message passing actually means.

These are all just examples and there are more variants of this than I could ever think of. In fact, some of the situations where working on a certain technology helps with becoming a better developer overall will not necessarily be apparent but rather be a “back-of-mind” thing.

I also really don’t believe in that you have a finite number of programming languages that you can work well in. Learning a new programming language is not going to kill that 6502 assembly knowledge that you have been holding on to for 20 years more than not using it is already doing.

So, try new stuff… If you can’t for work then do so for yourself, just remember to make up reasonably sized projects because “just testing” languages tends to be very limited if you don’t have an actual project.

This is what I’ve been doing for a long time to keep evolving. I try to learn at least a few new languages every year and while not all stick they have all been valuable. It also really helps when I for whatever reason have to bring out something obscure and work some magic.

In any development team you will need to try to even out the differences somewhat to be able to work together successfully. You need to have some things you agree on to be able to build something maintainable.

This means that when you start working on an established project you will need to spend some time to change your ways to write code like the other developers that have worked on the project before you and as such give up some of your unique style for the duration of time that you work on this project.

Here comes the crux though. There has to be some reason why you specifically work on the project. There has to be something beyond you just being another cog in the machine who all churn out absolutely unique blocks of code in exactly the same timeframe.

Your unique talents and your methodology are some of your biggest strengths. This may sound like it is in strict opposition to what I said before and that is… because it kind of is, but yet it isn’t.

Basically, it comes down to that as long as you have a common frame then you are fully free to be as unique as you want within that. So the only way you can feasibly be as unique and as free as you want to be is to have very strict rules for which areas you need to always have in common.

The fact that Developer A != Developer B in the way they work is actually something which the team lead should keep in mind at all times when planning out projects to not “swim upstream” too much.

This is a lesson I have learned myself the hard way, and it has taken time before I’ve come to the point where I am now and I can properly play to the strengths of the people on my team and still have everyone get the variation they want to keep things interesting.

Not trying to make everyone work exactly the same way and not making everyone work on exactly the same delivery schedule for the same things will make it easier to see the value of everyone’s contributions and that is when you as a team can get stronger together.

gdocs2md - A script to convert a Google Drive Document to the markdown format: https://github.com/mangini/gdocs2md

This is quite useful if you have to collaborate on a document with non-techies but then you want to store your documents in plaintext with the wonderful markdown formatting.

10 very good reasons to stop using JavaScript: http://www.leaseweblabs.com/2013/07/10-very-good-reasons-to-stop-using-javascript/

Basically… I agree with this almost completely. A lot of sites today go overboard with JavaScript which makes them awful if you, like me, use NotScripts.

Anatomy of a pseudorandom number generator - visualising Cryptocat's buggy PRNG: http://nakedsecurity.sophos.com/2013/07/09/anatomy-of-a-pseudorandom-number-generator-visualising-cryptocats-buggy-prng/

Really interesting piece on how things were erroneously implemented in CryptoCat. Also a bit of a scary reminder of how you can overlook errors that seem really obvious in hindsight.

As an additional note this could have been found really quickly using tools that test random number generators, which is a reminder to always use all the tools that you can to ensure the quality of your code.

Kore is a fast webserver that facilitates creating dynamic websites in the C programming language: https://kore.io/

This is from the "Oh, that's cool, but probably pretty useless"-file. In theory compiled C should be about as fast as a webpage can get, but this would be pretty much coming full circle as (so far as I remember) Perl was invented to not have to write web CGI scripts in C as that was quite slow and potentially very insecure as things like doing good, secure string parsing in C is something only a select few can do reliably.

Guacamole - HTML5 Clientless Remote Desktop: http://guac-dev.org/

This is the most incredible example of what can be done with web technology today. It is pretty amazing in comparison to having to use Java for Logmein.

Probably the most futuristic thing I've seen so far on the web.

There were actually a lot of interesting things this week, so adding on some more ones without comments:

Why mobile web apps are slow: http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

Shit for making websites: http://shitformakingwebsites.com/

Library order in static linking: http://eli.thegreenplace.net/2013/07/09/library-order-in-static-linking/

Raspberry Pi Microwave: http://madebynathan.com/2013/07/10/raspberry-pi-powered-microwave/

Paper ROM: http://hackaday.com/2013/07/11/paper-rom/

Nonblocking Algorithms and Scalable Multicore Programming: http://queue.acm.org/detail.cfm?id=2492433

As usual these things are taken from my archive of Twitter posts from this week, so if you want to see these things live as I post them follow me over there.

Traditionally I haven't thought that much about what music I'm listening to, but recently I've started to realise that different music has different effects depending on what mental state I'm in and what it is that I have to do.

My taste in music is fairly broad as I believe that there are good things in pretty much every genre of music. This means that while doing development I've been listening to everything from metal to country, without really thinking too much about what I'm listening to at what time.

Lately though I've been on a run of trying to A/B test things for myself to squeeze out every possibly tiny bit out of every day, and while testing distractions I did come up with some (to me) very interesting things.

First thing I learned was that music with really engaging lyrics are only really good in some certain situations. Especially when doing mechanical repetitive tasks some of this is great since it keeps me from drifting off. An example of a task of mine where this has applied for me recently, is doing slicing/exporting of graphics from Photoshop and Illustrator for a project.

Second thing was that it depends if I'm really crunching hard on something or if I had more time to do something what kind of pacing feels most right. However, it is not an absolute indicator as I need to balance it with how I feel.

Sometimes when stressed it's better with something more downtempo to calm me a bit and keep me more focused to avoid mistakes and to lower stress level.

However, sometimes when stressed it's better with something with super-high energy to give me more energy to push faster and riding the wave of energy that comes with pushing towards a tight goal that you know that you can do.

Basically whatever music I can play to should only be a plus and never make me feel more stressed than I would be otherwise since if it does then that is only going to be detrimental. So while listening to Paganini is great when I feel like a virtuoso it is much better to listen to Gridlock when my stress level is too high.

Also, when slogging through something that is non-urgent but necessary to do I may also need to go either way as either way may be helpful depending on the situation. Sometimes it's good to stay mellow and sometimes you need a shot of energy.

I experimented for a while with focus@will that had claims of making you more focused and more productive. It has the weird business model of that it's free if you don't register an account, but is limited if you do register an account and don't pay for it.

The "Classical" and "Alpha Chill" stations were actually pretty good, but I think they are too wrapped up in hyperbole. I would recommend experimenting with listening to their music but I'm not convinced it's worth the price they charge.

Now I mostly use rdio to stream the stuff that is actually in their catalog which is, in my opinion, slightly better than Spotify but still only has a fraction of the music that I listen to. For the stuff that is in their catalog though their web player and player apps are great experiences.

I also have my own Subsonic server set up and I stream things from that using Thumper on the Mac and iSub on the iPhone. This I use for all music I can't find anywhere else.

Then I also listen a bit to Digitally Imported. Primarily to the Cosmic Downtempo, Space Dreams and ChillHop stations. This is mainly as sometimes it is nice to not have to decide what to listen to but rather to just to roughly pick a style of music to listen to and then let someone else do it for you.

Lastly I'm going to leave you with a random music recommendation which I find to fit almost every category and that is Shiina Ringo.

She is quite simply exquisitely brilliant in every way and I really love her music. If you have not listened to it before you really should... It may help you become a better developer, or it may make you smile as you rock out on a Saturday morning.

Game on ladies: http://flygirlgamers.com/game-on-ladies/

The story of a man logging into his wife's gamertag. I find it pretty scary that some game communities still have these issues. I have seen similar problems in some games I've played, but not quite as extreme as these. I think that the most interesting community to watch these days is the League of Legends community as Riot are doing very interesting things to fight harassment and bad player behaviour… and based on this I really don't want to get into Xbox Live.

Are pointers and arrays equivalent in C? http://eli.thegreenplace.net/2009/10/21/are-pointers-and-arrays-equivalent-in-c/

This was a quite interesting piece on those little technical details of C that I find so very interesting. The detail was pretty amazing and as such I think it was very educational.

What every web developer must know about URL encoding: http://blog.lunatech.com/2009/02/03/what-every-web-developer-must-know-about-url-encoding

I think this was very impressive, and I think that not only "web developers" need to read this, I think it applies to anyone who ever touches a URL programmatically.

Both true and false: a Zen moment with C: http://markshroyer.com/2012/06/c-both-true-and-false/

This was also an interesting study in how an uninitialized bool can be both true AND false at the same time in C.

jor1k: OR1000 Javascript Emulator Running Linux: http://s-macke.github.io/jor1k/

This is from the "Really cool that it is possible" file. Not super-useful but incredible in terms of the technology. It is a sure sign that Atwood's law still holds true.

These were my favourite things of the week. To follow these things live I would recommend you to head over to Twitter where I post these things as I find them.

If you throw something at me that I’ve never even been close to doing before and ask if I can do it then I will almost always answer with yes as that is the great thing with software… almost everything is possible given enough time and money.

This is what has let me work on some truly amazing projects with some really amazing results. It has let me do things that “can’t be done”, it has let me learn new technologies that have made me better at all kinds of development I do and it has let me stay ahead of boredom.

It has been the way I have always been, ever since first starting to learn to code… and I doubt it will ever change since my biggest asset as a developer is that I do pick things up incredibly fast and I almost always end up landing on my feet no matter how large the challenge.

As such my recommendation to developers out there would be to not fear doing the unknown… It will pay off eventually provided you make sure to learn the basics and you just go with it.

I think I first learned about it from some podcast that Brett Terpstra was on, and I bought it pretty much right away. Then I forgot about it forever until I needed a nicer way to do scp upload combined with opening a file on my home server than opening up a terminal.

After having gone through their very excellent API documentation I built my first version of UploadOpen in 5 minutes, and after another 5 minutes of debugging it worked perfectly exactly like I wanted with messaging etc.

With this success done I built scripts to upload images to my new moln.is server, scripts to paste to paste.pm and.. I'm still going.

This is something I've wanted for a really long time, a nice and easy way to put a basic UI on shell scripts, ruby scripts etc. Being able to process a file by just dragging it to a circle on the screen is so very nice and while I could build my completely own solution for it this saves me so incredibly much time.

I posted one script to Github, and I'm going to keep adding my scripts as I finish them hoping they may inspire other people.

It was once the big backbone of real-time internet communication, only second to e-mail in all communication, but then somehow it drifted into obscurity while still staying around. It is still quite popular in some circles such as for example among open source projects, but to the great masses it seems fairly superfluous with more "modern" IM chat systems readily available.

I've actually mostly stopped using IRC myself, but then again, I've mostly stopped using all forms of IM for personal use. Twitter is generally as instant as any discussion gets with me except for those few people who I allow to talk to me through iMessage.

Yet, I found myself setting up an IRC server for the company I work for last week. I had actually been thinking about doing so for a while, but a comment about missing our old old server from a colleague was what pushed me over the edge.

I think that IRC is underestimated as a protocol, and that it has some serious strengths that very few other protocols can match.

First of all, it supports incredibly low committal group discussions. People can easily flow in and out of the conversation and it doesn't feel as intrusive to throw something out to an entire group of people as it does when you open up a group Skype message for example. Especially for those questions that can be answered by multiple people, if someone has the time… they will most likely see it and respond and if they don't then they won't, or maybe they will do so later.

This really helps with productivity in a team as you can glance at what other people have been discussing to have an idea of what has been going on and it lets you have more open discussions on a distributed team as they are "public" much like talking to someone across the office is.

For those times when you do need to call the attention of someone in specific you can easily either start a private query, or just highlight them in a channel and usually their client will notify them. If you put in the text "ashaman" into a channel that I'm on I will most likely notice it as it will cause notifications to go off.

There are also tons of great clients for every platform for all tastes, from text-based to highly visual and from very basic to incredibly feature-rich. Even obscure systems such as Haiku have IRC clients, and as there are a plethora on more popular systems you can usually find something that fits all your needs (Personally I use Textual on OS X, Hexchat on Windows, Weechat on Linux/BSD and on iOS I used to run Colloquy when I was more active on freenode).

IRC is also a dead simple protocol, as should be apparent by doing something like this:

{%highlight bash%} ashaman@Yuki ~> telnet irc.freenode.net 6667
Trying 89.16.176.16...
Connected to chat.freenode.net.
Escape character is '^]'.
:wolfe.freenode.net NOTICE * :* Looking up your hostname... :wolfe.freenode.net NOTICE * : Checking Ident :wolfe.freenode.net NOTICE * : Found your hostname :wolfe.freenode.net NOTICE * :* No Ident response {%endhighlight%}

It doesn't actually finish connecting since it expects you to automatically pass an "Ident", which you can't due to how telnet works. If you run a raw socket, possibly using something like netcat it is easily doable, like in this example.

This, along with that there are easily usable libraries for handling IRC connections on Github or even in the standard language repositories for pretty much all languages means that it is great as an I/O protocol. You can easily write "bots" that sit in IRC channels and take commands or notify you of things.

At NUITEQ we currently have one of those that lets us keep track of what is happening. It does not yet do quite everything I want, and as such I'm constantly looking at adding more features to it. As it is written in fairly basic Ruby it is something which is really fun to hack on and easy to extend.

As such, for developers I think IRC is an underrated tool, and while it can be distracting at times if not managed properly I think the overall good that comes from it massively outweighs any negatives.

It may not be the only messaging protocol that has any one of the characteristics, but it is the only one that has all of them wrapped into one.

You probably have had the same experience more than once. You build a quick, hacky prototype to show something off, or to try out if something works. Then, rather than throwing the prototype out and plan things properly you use it as a basis for a real project.

This is only one of the cases where you start building on an unstable base. Then you end up bolting stuff on and hacking around problems as you don't really want to touch code that is technically working.

Do yourself a favor, don't use that code, just throw it out... Do it right away.

You may even have some code like that in a shipping product somewhere. If you do there is nothing wrong with just throwing it out. Provided that the parts of it are well encapsulated you should just be able to pull out the good parts and throw away the rest.

You may think I'm crazy, you may think you don't have the time to fix things, you may think it is a waste of money.... Trust me, pushing the cost into the future just makes it worse.

For example, the single most important Snowflake release for code quality, stability and performance to date in my opinion is 2.0 where we threw out a bunch of old code and re-wrote it. It was a massive task, but it was definitely worth it as in my mind it made it take a leap 10 years ahead of the competition in terms of just pure technical quality.

It was of course a risk, how much time would we spend on it? Would it even be feasible possible to do? Wouldn't we miss all that crazy stuff we spent hours on during a caffeine-infused night in 2008?

Based on the last few years I must say that it was clearly the right decision. It would not have been possible without the team being so incredibly experienced with doing what we do best.

As someone who has over the last 20 years written thousands of lines of code that now lives at /dev/null I must say that there are few things more liberating than deleting code. Less code almost always mean less problems.

So, build that quick prototype, take the experience... Then chuck it in the bin and start on planning out your real implementation.