Sunday, June 27, 2010

Short sighted learning


Focus
Originally uploaded by Dani Ihtatho
I've been enjoying learning about a number of aspects of the .net world over the last year or so. Recently, I've been creating WCF Services - being new to the service creation world, I had to start from scratch, which is always a good place to start.

My problem, however, is that I wanted to learn enough just to get something up and running. I find that the problem with learning by google (or Stack Overflow, MSDN, blogs) is that there's no one pushing you to get the complete view of a topic - not that people don't offer the information up, it just seems irrelevant at the time when you're working so hard on the basics.

My lack of understanding was highlighted when doing some performance testing. I thought the service would create threads per call, but there are limits to the number of threads (which, of course, makes sense) - but what happens with those that don't get through to the service? Do the requests time out? What happens when the requests are being pased through from a DMZ? A standard request that worked normally as a one off test starts failing under load. None of these issues are problems within themselves, but a lack of understanding about how services generally work, how to queue up requests, how to handle concurrent requests all come crashing back to bite when you get an unexpected problem.

Talking about a different project (one that I wasn't involved in), I was saying to my colleague that I think it's not wise to check something in if you don't understand what it's doing - which I still think is right - but I didn't even know that I didn't know what I was doing!

To help my shortsightedness, I think I need to define some kind of learning plan that outlines all the parts of a new topic that I'm working on, even if it's just a quick read over a msdn article to see what 'bits' are talked about so I'm aware of their existance. I've even been considering buying books! The more I look at it, the more I think a good book is a great basis for learning a new topic - they're usually comprehensive in covering a topic, even if they don't touch on the detail of all aspects - google can come into help then.

Tuesday, June 22, 2010

Planning to test


Traffic Lights
Originally uploaded by Roo Reynolds
When I code, I want to have confidence that my code does what I'm intending, and not being the most self confident coder in the world, writing tests boosts my confidence (except when they all break). Part of this is writing tests that are true to life examples of how the system will be used.

I'm not quite on the test driven development bandwagon yet - I would love to be, but I think I need to be more disciplined to make it work, and really need to learn more about mocking - and properly interfacing out my objects.

For my projects there are a few types of test that I'll write:
  • Integration tests that are testing a few components, for example creating a new object, validating the data and then saving to the database.
  • Story based integration tests - usually testing the API or services that are available, ensuring they correctly accept data, validate, save and return.
  • Simple database connectivity tests - to ensure my NHibernate mapping is correct.
  • Unit tests to test a single method.

There is probably a wide range of scenarios that I'm not checking, which is where working with a tester to manually write up the scenarios and work through them really helps. Over the last couple of weeks I've been working with a colleague, and have found this to be really useful.

Now we've got into our 4th round of testing, and testing is really starting to become labor intensive, which brings me to the question of how do I automate all these tests? To me, I would be confident building the tests in code, but how do you help others build confidence in your coded tests?

How does traditional test planning fit into an agile type development project? As I've written a large number of tests, where does the need to manually test come in?

For the continuing development, testing will obviously need to continue, and we'll need to keep automated tests up to date, which is a subject for another post.

Managing connectivity in a slow, slow world


Day 43
Originally uploaded by ClawzCTR
My last couple of weeks has been taken up with integrating an internal system to our CRM software, which is all hosted in a datacenter far far away. For each request that comes in, there can be up to 4 incidents created, all of which need to happen in real time so the request can be confirmed. The connection to the CRM is slow, both in the application and when developing against the software, but I didn't really give it much thought until I started running a few queries together.

My starting point was to use an external project with a utility to create a single incident with a number of settings. This worked fine until I needed to create 3 incidents, as each request was managing it's own connection, setup of fields, and submitting the new object to the server. At this stage my connection was timing out, there had to be a better way!

First thing to do was extract some of the common functionality - I wanted to create a base incident, which I could just tweak for each scenario. This was great, because most of the fields stayed the same (each field change required a query to get the database id based on the string I had). So the first incident takes a bit to setup, but each subsequent incident may not require any further database interaction until all process are ready to submit.

Initially, I had ruled out using threads, as there is one process that can break all other process, but I may be able to extract this out, and thread the remaining process - which could give a bit of a performance boost.

Another option to consider - should I hardcode all the Id's so I don't need to do so many queries - if so, how do I manage the config for different environments (part of a bigger question). This would save some time, but perhaps present some issues down the track when the system changes.

It's pretty interesting thinking about performance optimization, and this has got me thinking about where I could do things better in my own code, where the time taken may not be so noticeable, but all up could be better managed.

Do you develop against external systems that are a bit on the slow side? How do you manage multiple requests? How do you ensure you can provide a prompt response to your user, while ensuring all requests complete successfully?

Friday, June 11, 2010

Delivery is near!


"Tiny" Delivery Truck
Originally uploaded by El Struthio
The last 6 months or so has been rather hectic, and very unstructured, but the end is in sight!

This month I've committed to delivering 'complete' software by the end of the month, so the last week or so has been bug fixes and working with a colleague to do a variety of tests on the software I've written or integrated with.

Testing has been going pretty well overall, I've got a suite of unit / integration tests that I run myself, but just having someone else go over my project, confirming what I've tested and what's in my head has been great. It's enabled me to sit back a bit, release some of the unnecessary information from my head and prepare for handover.

There is still a lot of work to do (see my previous post about builds), integration that is yet to be fully tested, but it has been a great relief, and one of the reasons I'm keen on moving towards an agile work practice - handing over a tested and complete piece of software every cycle will hopefully allow me to leave work at work more effectively.

Thursday, June 10, 2010

Simple NHibernate mapping and the power of documentation


On the Road Manuscript, #1
Originally uploaded by Thomas Hawk
In an effort to clean up my code (long overdue), I've decided to change all my char types to bool's. At the moment I've got char's in my database, and was simply lazy to map directly to a char in my objects.

In an effort to fix my problems, I did some googling and unbelivebly came upon the NHibernate documentation that I obviously didn't read properly the first time. The section was 5.2.2 - Basic Value Types and the type was 'TrueFalse'.

Who would have thought that documentation could have been so useful - big thanks to those at NHibernate Forge for doing a great job on documentation.

Saturday, June 5, 2010

Work, life and distractions all about

I read a great blog the other day that my colleague sent to me - all about the reasons for working, particularly on a shared project - check it out at coding horror, but in particular the reasons that drive you to do good work, and keep on going at getting better.

Then, this morning I watched this video:

3 Barriers To Help Block Consumerism from Adam Baker on Vimeo.

Along with a pay review at work, it all got me thinking about why we go to work. Thankfully I live in a country where there's good employment, and I can choose what sort of work I do, but we have an endless array of stuff that we can keep searching for. I get paid fairly for the work I do, but there is always more to spend it on, which makes me think that I'm getting ripped off.

How hard it is to be content, and to be thankful for the many good things I've got at the moment! How do you go at being content with what you've got? What do you find satisfaction in?

Tuesday, June 1, 2010

Builds, dependencies and testing



Originally uploaded by +fatman+
Over the last few weeks I've been moving back and forth between testing on my computer and deploying to our test environment. I did another build this afternoon, thought everything was good, and deployed to the test server at about 430 for my colleague to test. Well, after he tried to run the test it turns out that I forgot to change a section of my config.

I watched an interesting video on infoq today about the deployment from dev to production, which has encouraged me to investigate the process a bit more. At the moment I've just got sections in my config for each environment, and I comment out sections when not needed.

So, there's much to do, including getting a build server up and running, so hopefully I'll be writing about that soon, and a whole lot of research about deployment.