Thursday, April 7, 2011

Raven DB & ASP.NET MVC routing

I've experimented a little with Raven DB, and have done some integration with ASP.NET MVC 3 (cause it's so easy to get things started).

The first problem I came up against was the default way that RavenDB stores the object keys :
profiles / 3074 (Profiles)
This presents a problem when you want to work with the MVC routing, which uses the '/' symbol in the routing - {controller}/{action}/{id}.
public ActionResult Edit(string id)
MVC interprets this as wanting to send the id (id e.g. 3074) to the action (object e.g. profiles). Instead, we want to pass the whole string (profiles/3074) as the id to the controller action (Edit).

To start, we need to change the type of id to string, as it defaults to int. Secondly, we need to change the format of the object key - there are other ways of attacking this problem, but I found changing the default separator from '/' to '-', this happens when you initialize the document store shown below
var documentStore = new DocumentStore { Url = "http://localhost:8080/" };
documentStore.Initialize();
documentStore.Conventions.IdentityPartsSeparator = "-";
We end up with documents in our store looking like this, and passing through to the correct controller!
profiles-6146 (Profiles)


Tuesday, April 5, 2011

Stand up


Danielle on my Desk
Originally uploaded by riebschlager
A couple of weeks ago I experimented with a standing desk, which meant dragging my monitors onto a shelf, putting my keyboard up higher and generally shuffling my desk about. It wasn't to be a permanent solution, but more to see if I thought it would be worth getting a permanent setup.

The first couple of days were pretty painful, it's been a while since I've stood up all day, but after a weekend I was feeling good. I felt like I had a lot more focus and didn't waste as much time on facebook and twitter, which was nice to feel that I was getting more done. I think it's also great for programmers, as pair programming would work well as opposed to having a corner sitting desk (which is what I currently work at), allowing better access to swap the keyboard and improved screen visibility.

Unfortunately my wrists weren't a big fan of the awkward position that I'd placed my keyboard in - without a solid desk to rest on they just started to flare up. So, I'm back sitting down waiting for my wrists to recover, and hopefully get my desk setup properly.

If you're interested in standing desks, Lifehacker is a great place to check out to start with.

Do you have a non-standard workplace? How did you make it happen? Does your workplace encourage you to work in a way that helps you work best, or do they want you to just sit there and stick to the standard way of doing things?

Thursday, November 4, 2010

Web Testing

Have had a bit of fun doing some web testing over the last week. Mostly I work on internal systems, so don't get to have fun with user interfaces.

I've been using Selenium RC, with the aid of Selenium IDE in Firefox to figure out some XPath details.

A couple of things that I've learn't over the last couple of weeks:

  • Using XPath to get elements in Internet Explorer is super slow.
  • Selenium RC is great, but it's great to have the IDE just to test out roadblocks
  • The .Click event mimicks a keypress on an element instead of a mouse click - I found some screen reader popups that only appear with keypress.
  • You can't interact with Print / Save dialogs directly (although there are other tools for testing these components)
My tests are mostly checking that elements exist and have the appropriate classes / id's, so I'm yet to see how it works with positioning and styles being applied to the page. 

I'm also keen to use the css element locator - it's supposed to loads faster than finding elements with XPath.

If you're interested in Selenium, check out the proposed Stack Exchange site and give it an up vote. 

Thursday, July 8, 2010

Where does your seat sit?

At work today, we had a bit of a chat about our physical work environment. Currently we've got an open plan setup happening, everyone faces into their corner of the workspace, and we've got space for a whiteboard. One of the issues with the current setup is that pair programming and code reviewing is a bit hard - trying to fit 2 people into a corner doesn't really work very well, and we want to start doing more code reviews to up the quality of our work.

I know that some people are big advocates of the 'everyone get's an office' idea, and have been reading Joel Spolsky's blog - particularly about office space. I think it'd be great to have my own office, but we don't really have the space, so we're trying to think about how we can work better in the space that we've got.

One idea is to have a large table that we all work at in the middle of the area, with whiteboards around the outside so we can draw and discuss ideas. Another possibility is to all work around the edge of the area, facing the wall, but not have anyone sitting in the corners - which will help with pairing and collaboration. A space would be reserved for a whiteboard, and we could wheel in another whiteboard in and out when we needed.

Anyway, hopefully over the next couple of months we can figure out a way to work better together, which may include a redesign of our physical work environment.

How do you work best with your team? Do you sit near each other? How does working remotely affect your collaboration?

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?