Sunday, August 10, 2014

Hosting an Ubuntu VM on Windows 8 for Web Development

The VM

After a little bit of playing around, I managed to settle on Ubuntu 13.10 running under VirtualBox. Unity is the default window manager for Ubuntu, and is a little heavy for a VM, but it runs ok. The host is Windows 8.1 which is my preferred desktop. I've tried Linux as a desktop OS in the past and I always found reasons to go back to Windows (such as Steam, and RAW handling for my Canon). I'm used to working on servers running Windows Server, but I don't have to pay for them, so Linux is a nice alternative to get used to, especially for web development, which is outside of my normal experience.

Networking

The main thing I wanted working was networking. The VM needed to reach the internet in order to download new packages etc, and I needed to access the VM from Windows. Accessing the Windows host from the Ubuntu guest was less important, but I got that working too.

The default network adapter is a NAT setup. This allows access to the outside world, but there is no connection between the guest and the host. The first promising one was the Bridge network. I could access the VM from my Windows PC, but the VM couldn't access the host or the Internet. Luckily a reboot of the VM fixed that. Bridge networking now gives me host to guest, guest to host and guest to Internet.

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

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

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.