Thursday, July 10, 2014

First Steps into Agile and Kanban

My day job doesn't always involve a lot of new technology or techniques, but recently we have made a commitment to start using Agile techniques, especially Scrum and Kanban. So far this has involved projects already in the pipeline and designs I have (or should have) completed previously, but I have a small team now and we get together to do three week sprints to develop new software. Well, changes to an existing system.


Sprint Planning

To begin, we all get together (developers and testers, sometimes a business analyst) and plan the sprint. Again there is a more traditional plan already hanging around in the background with existing requirements which have become backlog items, but we still get together and discuss the requirements and assign a size to them. We're using scrum poker cards for this (either physical cards or apps for our phones). The item sizes are meant to be relative, but have no meaning by themselves. The idea is that you are not committing to work based on estimated time, but just a more vague idea on how big the task is. The reasoning behind this is that estimates are rarely accurate, so why waste time and energy coming up with hours when they will probably be wrong?


The Sprint

Once we have committed to our backlog items (or have them committed for us), then its time to create tasks and begin work. Tasks come first, and are easily broken down and shared out. This is where our time estimates come in, as each task has a remaining time in hours. Using TFS, this then drives the burn down.
It hasn't always been easy to come up with tasks up front. The first sprint took about a week to get everything in place, due to inexperience. This meant that we burned up for a while, not down. The second sprint was better. We got it all done on day one, and the burn down was a lot more helpful. This time around, the backlog items are not as good as last time, as we are using raw requirements from the customer without a lot of backlog grooming. This is partly due to the requirements being created before we started the Scrum approach, and also due to the lack of time spent working the requirements into backlog items. This is again partly due to inexperience, and also due to me not having a lot, or any, time to look at them seriously before the start of the sprint.


 Test Left

One goal we have which predates the move to Scrum by several months is known as Test Left. This means getting test done early with partial releases from development. Previously we could go through months of development before any real QA besides what developers do themselves, which isn't always adequate, to be honest, especially when it comes to testing freshly built and deployed software. It has been difficult to make sure the development branch is in a place where a build can be created and given to test, and that we know that the components will install ok, and work as expected. It's ok testing something on your own machine, but can you be sure it will work for someone else?
That's a challenge I'm still trying to work out, and probably my biggest problem at the moment.



Coding is nice, but I feel like I'm doing less and less of it. Once problem is that it requires a lot of concentration. One big complaint developers have is about interruptions.When you are in the middle of some gnarly code, you are thinking about that one thing only. Being interrupted at that point is annoying and very disruptive. That's something I try and keep in mind when working with other developers in my team. It doesn't work to well when I'm the one trying to avoid interruptions though.



Demos are hard. You get all your code working nice on your development environment. The test team get it working for them. You run through the demo at the office, and everything works fine. Then, when you're in front of the customer, it all falls apart.
Lessons from this: have complete control of your environment, and have a backup plan.


Control your Environment

Corporate networks are usually finicky things. Even if you manage to get to the outside world, it doesn't mean that something won't interfere with your communications. Best to host everything in one place, e.g. a VM on your laptop, or in the cloud, provided you at can at least fall back to mobile internet if the client's network fails you. Trying to connect a device over a network you've never used before is a recipe for disaster.


Backup Plan

Your demo isn't working. What do you do? Just sit there staring at your hands, hoping everyone will forget about you, get up, and leave? Being able to fall back on mobile networks, VMs hosted on your laptop, or even videos of the demo recorded previously enable graceful degradation of your demo.

There's nothing like a bad experience to make you help you learn the right way though.

Monday, May 19, 2014

Quick Non-update

It's been a long time since I've blogged anything. I've moved to the UK since then and turned 30. My main interests now are learning mobile development (as before, this doesn't include Window Mobile as that's the day job), web development, especially with things like Flask and Django because I like Python and its free, and making games, because that's why I got into the whole programming thing over 2 decades ago anyway.

Saturday, June 23, 2012

Lazy List in C#

I was playing around with some F# code and thinking about lazy lists in Haskell and how I could get them in F#. Well, since I know how to make an enumerable function in C# I decided to have a go making one in that instead.

void Main()
foreach (var i in LazyRange(1, (n) => ++n).Take(10))


var fizz = LazyRange(1, (n) => ++n)
.TakeWhile(n => n < 1000)
.Where(n => n % 3 == 0 || n % 5 == 0)


IEnumerable<T> LazyRange<T>(T start, Func<T, T> successor)
T value = start;
while (true)
yield return value;
value = successor(value);

To use it supply a starting value and a function to provide each successive value. Use Take or TakeWhile to limit the collection otherwise you will end up with an infinite list.

Friday, April 6, 2012

Long overdue update

I’ve had a lot going on in the past 18-months. Earthquakes in Christchurch for one, moving to the United Kingdom for another. Still, no real excuse not to be updating my blog, except maybe some programmers block.

While work sometimes sees me going weeks without writing much code, or even days without writing any, I try to keep myself busy with programming projects which I tend to pick up and put down again.

Learning new programming languages is an interest of mine, and one I’ve started using on a regular basis is D. It is a nice language to work in and feels to me to be most like a mix between C++ and C#, both languages I am quite familiar with. The D language seems to be quite mature, and the standard libraries are catching up, but the developer ecosystem isn’t anywhere near the more popular mainstream languages. Tools are a bit lacking right now too. This hasn’t stopped me on embarking on a few projects.

The first is Project Euler. The site contains a list of mathematical problems to solve, with the intention you write a program to do so. Going through these problems got me up to speed with D a lot quicker than just messing around with a tutorial. I haven’t been on in a while but I did get up to 63 problems solved.

The second project goes back to a long running interest of mine in ray tracers. Simply put a ray tracer renders a 3D scene by calculating a ray from a camera to a point on the screen (usually at least one per pixel), and determining what objects in the scene intersect with the ray. Then you perform some calculations based on the vectors at that intersection point to work out what colour it is. My first ray tracer was written about 6 years ago as part of a University assignment and I’ve been hooked ever since. Unfortunately I haven’t worked on a single program for 6 years, I’ve worked on several iterations of the same program over that time not really making much progress. My latest version is in D, and with a couple days of work taking the better C++ code I had and converting it to D I have yet another basic ray tracer. If I do more work on it more in the future it may become a topic for the blog.

More recently I have become interested in creating programming languages. It started with an idea on how you could turn a Reverse Polish Notation calculator into a language. The basic RPN interpreter is a typical student project. I know I made a couple during my study days. A bit of research on the idea lead me to Forth, which I ended up half (or a third) implementing in D. I then got a bit more ambitious and tried to come up with a more complex calculation only to get bogged down in details again. That design process is still on-going though so I might just make something of it yet.

With programming languages on my mind this put me in an appropriate mood to be receptive of the new project of Markus ‘Notch’ Persson, 0x10c. In summary it is an MMORPG set in the distant future in space. The most interesting part of this game is each player’s ship comes with a fully programmable computer, based on the fictional DCPU-16 chip. It is a very simple 16-bit processor and the spec is available so it isn’t surprising that emulators and assemblers are turning up everywhere. I’ve even written an emulator in D over a couple of nights and I’m planning an assembler next. It might even be interesting to implement a simple Pascal compiler for it.

Sunday, October 31, 2010

Playing with Minecraft levels

Minecraft is currently the only PC game I play these days. All my other games are on consoles. If you don’t know what Minecraft is, you can start here, but in a nutshell it is a freeform sandbox game set in a randomly generated world where you can mine and build.

Having spent some time playing I’ve built up a complicated network of structures and tunnels in search of those elusive diamonds (have not found them yet). It would be nice to have an alternative way of visualizing that world, so with that in mind I ignored the other mods and tools out there and set about writing my own.

The first tool is a NBT file to TXT converter. NBT stands for Named Binary Tags and is a format created by Notch for his Minecraft game. Following the documentation on the website I created a tool written in C# to read the compressed data files and turn them into a human readable format. The tool doesn’t understand what is in the files beyond the tags, which are essentially the metadata. The next step is to create something that understands the level format and is able to display the world in some way, such as a 2D map.

The tool is reasonably simple. It opens the target file into an uncompressing GZip stream and starts creating Tags. The Tag abstract class takes care of parsing basic data types and parsing the Tag Type to get the actual Tag derived object created. Each derived type parses its payload of data, which in the case of a List or a Compound will consist of other tags read recursively. Once that is done I write everything to another file by recursively calling the tree of Tags.

I should be doing some more Android programming but I have to admit little projects like this are more fun for me :).

Wednesday, October 20, 2010

Creating that first App

It is easy enough to pick up a new language or a new platform when you have been programming for awhile, but coming up with that killer app to publish and let people actually use is a lot harder. It is easy to do the actual publishing, which is something I will be attempting in the coming weeks. The hard part is going from playing around with code and making little demos to actually making a decent bug-free (mostly) piece of software that people will want to use, and maybe even pay for.

It is best to start with a simple idea, even if it is inspired by what is already out there. It’s nice to be able to come up with a great new idea and be the first to realise that idea, but you could be waiting a long time for that flash of inspiration. If there is an app you really like, but it doesn’t quite do what you want, or maybe it’s buggy, or not available for your chosen platform, you could create your own unique take on that idea.

One common type of app, one which I have tried a number different versions of is a task list or note taking app. It is always nice to be able to make a simple list you can take with you in electronic form, even if it is just for shopping. And since you have your phone with you all the time, pulling it out to make a note of something you’ve found out and about is also nice. Currently I have three apps that fit that criteria on my phone.

Evernote is a note taking app that keeps your account on the web so all your notes are available where ever you have Evernote installed. It’s a nice app but you don’t always need to have your notes on the web and sometimes waiting for them to download again on a spotty 3G connection is a bit of a pain.

Astrid Tasks is a task management app. It has lots of options for categorizing tasks and keeping track of due dates and reminders. It has a lot of depth but it can also be very simple by default. Just enter something in the text box at the bottom of the list and hit add, and there’s your task. I like this app but don’t find myself using it a lot. Most of my tasks are work related, and in that instance I have Outlook on my PC for that kind of thing.

Spring Pad is my latest download. It is a note taking app with some brains. There are different categories of things you can add from plain notes and tasks to restaurants and products you might be shopping for. It syncs to the web and apparently is able to organise your notes by matching up keywords and doing product searches on the Internet and things like that. I haven’t given it a good go yet, but it looks like it fits in well with what I’m looking for.

These apps have given me the idea to create a simple check list app. I actually came up with this idea based more on Astrid before I downloaded Spring Pad because what I wanted from Astrid was to create a simple list of items to check off that would remain separate from other tasks, a task with sub-tasks in a way. This would replace my current paper grocery lists which I sometimes take the time to write if I don’t want to visit the supermarket three or four times in a single week. It is a simple idea but I’ve decided to go ahead with it as my first app with an aim to publish. I won’t be selling it, and I don’t think it even warrants ads, but I will decide on those later.

Over the next few weeks I will post my progress on the development then the publishing on the Android Market.

Wednesday, October 6, 2010

Developing for Android

Mobile development isn’t new to me. I’ve been developing on Windows Mobile for three years now. Things have changed recently though. First there was the iPhone. It really started the consumer smartphone wave with its easy interface, big touch screen and most importantly, the App Store.

Now Android has joined the party. I have an Android phone, and HTC Desire, and I love it. It’s my first smartphone and I could never go back. The big advantage of Android for me is the freely available development tools and the open nature of the market. That said I also have an iPod Touch which is brilliant. After being a consumer of both the Apple App Store and the Android Market I have to say that Apple’s control doesn’t seem as bad as I first thought.

Over the past few months I have been taking my first tentative steps into Android development. I have eclipse, I’m picking up Java again, and I even have some Android books from Amazon. It’s time I get something published though. Watch this space.