Friday, 23 May 2014

My story so far...

I always like to know what influences someone I am reading has, it helps me to understand their position and how they have come to their opinions.  To that end the following blog is a brief overview of my software development journey so far.

My name is Klee Thomas and I'm a Software Developer and aspiring Software Craftsman. I'm passionate about Software Development and use words like craftsman and clean code, possibly a little to, often.  I only started developing professionally a few years ago and am lucky enough to work with people who share my drive towards self improvement.  I am a regular attendee and occasional presenter at the Newcastle Coders Group.

I am not one of those people who started developing at a ridiculously young age.  When I was in primary school and early high school I played the occasional computer game and made one or two Power Point presentations.  I had no idea what Software Development was, let alone how to do it.  I did a little programming in the later years of my high school career.   My teachers did a great job in teaching me how to find answers to my questions online and taught me some basic algorithms.  But the programming I did was really just enough to pass my assignments.

Through University I started to be a bit more interested in development, but still after the assignments were finished I didn't do a whole lot of self improvement.  With the help of my lecturers and tutors by the end of Uni I did have an idea that there was such a thing as good code and such a thing as bad code, but looking back I certainly didn't know the difference.

Towards the end of Uni I picked up a job doing some Tech Support for some local(ish) primary schools and there I had my first experience writing a piece of software that actually solved a problem for someone.  It made me feel pretty good and I realised then that where I wanted my career to head was towards writing software not doing IT support.

At that same time that I had that job I was working on my honours project at Uni writing some software that solved Ordinary Differential Equations using Python.  The code wasn't complex, in fact the main outcome from my honours project was how easy it was to solve relatively complex mathematical problems using Python.  Despite it's lack of complexity it gave me something to hold up in my next job interview.  As I was finalising my thesis I had a chance to showcase the code in a job interview. I proudly stood at the front of the room with my code displayed on the projector and showed it off.  A month later I would look over that code in embarrassment.  Fortunately though my employers thought that it was good enough to get my foot in the door.  I'm so glad that they saw potential beneath that code.

The software development team I worked with taught me about craftsmanship, clean code, automated testing and well architected software.  They changed the way that I thought about software, from something that is there just to get the job done to something that should be well crafted and maintainable.  The introduced me  to podcasts, presentations, blogs and books.  They had me consuming work by names I had never heard before, like Martin Fowler, Kent Beck, Eric Evans and Greg Young as well at this oddly named Uncle Bob. These people now strongly influence my coding style and opinions.  Clean Code, is compulsory reading for any new developers starting with us. I just wish it was compulsory at Universities and Colleges as well.

While working in this job I have worked on two separate teams, within the overarching product development team.  Both teams work in the same general domain but solve very different problems. The first team I worked built a client server application built on top of a CQRS architecture using version 1 of the Axon framework.  This was a steep learning curve from where I started.  Before this I had never touched C# and WPF, never heard of CQRS or event driven programming and had only the Java knowledge that I had learned at Uni.

The team I now work on an in vehicle interface that still needs to be responsive while running on dedicated, but memory and performance constrained hardware.  This brings with it a set of challenges, problems and solutions that are unique.

Outside of work I now strive to improve my skills.  Focusing on areas outside of that which I cover each day in the course of my job.  I doubt I make up the 20 hours a week suggested by Uncle Bob but I get in at least a few.   Hopefully having somewhere to document them will help with that.

To finish this blog I'll finish at the start. My name is Klee and I'm a coding addict.  It has been mere hours since I last coded and I have no intention of stopping now.  Expect to hear from me again as I intend to use this blog to document my experiences on my journey. 

Wednesday, 14 May 2014

NuGet Productivity Hack

This article explains how with a couple of quick hacks you can gain a little extra productivity when using NuGet.  The hack it's self is simple, Just add NuGet's local cache as a feed.  It turns out this can save you time, keep you team mates on side and even improve your presentations.

Originally I did this to help with development of API's that develop and use in house.  We were facing a problem with rapidly increasing version numbers when initially developing an API for the business logic of our product.  Each developer was working on one vertical slice of the product meaning that they may have to tweak the API if they found something that they hadn't considered in one of the layers of the application.  The simplest way to develop the package dependent on the API is to update it with NuGet. 

Our process for getting packages into the shared NuGet repository is simple.  We publish packages to NuGet after a build on our Continuous Integration server.  That way we know that each build has passed tests and that each package is as stable as it can be.  We follow Semantic Versioning and our rule is once it's in NuGet it's published.  So any change to the interface after that point means that the version number needs to change.

So in order to include a package into the dependent project without first pushing it through the NuGet process I needed to publish it locally.  I had to pick somewhere so I thought why not into the local cache. This way I don't need to keep tabs on somewhere else in the system and as long as the version of the package that I finally pushed to CI was the same as the last one I pushed locally or had a higher version number then NuGet would take care of making sure that what I was developing against was the same as everyone else. Unless of course it explicitly wasn't.

Great, with this I was able to develop an API, change it as often as I wanted while making sure it integrates smoothly with the dependent package and not ramp the version numbers up needlessly.  Awesome! that's some productivity bonuses right there.  No more waiting for the slow build server to build and publish the package.  No more annoying the rest of the team with increasing versions and breaking APIs.

But this is all expected, it's the desired outcome of the problem I had.  I got a pleasant surprise as I kept working.   With the local cache at the top of my NuGet repositories list it was loaded up first when I went to add a new package.  Because it's accessing the local disk, an SSD, it was almost instant to load the add packages dialogue.  I'm not sure if serving the package list is universally slow or if it's our internal infrastructure but I found that this saved me several seconds and a fair bit of frustration when going to add commonly used internal and external NuGet packages. This may not save too much time but it does save a little frustration waiting for the NuGet dialogue.


The other day while attending the local Newcastle Coders Group we had Internet access issues, rather par for the course at the University of Newcastle.  These issues inhibited the presenter from being able to add the packages he required in order to do his demonstrations.  This might normally have stalled the presentation.  Instead I was able to get him to hook up his local cache as a repository and continue with the presentation.

So there we have it.  Publish packages to a local NuGet feed and avoid annoying your team members.  Make that feed  your local cache to speed up your daily development in adding regularly used packages to projects.  Use the local feed to have access to regularly used packages when for some reason you have no internet access.