We've been using Lighthouse from entp to track all the bugs and issues within Enhance 2 for quite some time. We've found it an excellent product that meets our needs perfectly without over complicating anything. The guys at entp spend alot of time making sure that the application does everything you want, without forcing you to do things you don't want. They've also provided a fairly comprehensive API so developers can integrate their own systems with it. We've used this to create a program which has dramatically sped up the time it takes to enter a bug. By reducing the interface down to a bug description with a submit button and then placing this on the desktop we enable users to enter bugs with a minimum of fuss. We've also added the ability to set a seperate title and enter tags for the issue, along with a simple clean interface which you can even set to always ontop. Even better than that we are sharing it for free with the community, so head over to the Bugger! page to download now.

Here at Enhance we are big fans of Object Relational Mapping (ORM) and have been using Entityspaces for a number of years. The main advantages of ORM for us include the faster development achievable with a well constructed ORM solution, the separation of concerns provided by a separate data access layer and the flexibility between different database vendors. While each of these can be found without using an ORM tool per se we have found that ORM and specifically Entityspaces integrates them all very cleanly.

What we haven’t found useful about ORM is actually the Object Relational Mapping itself. While this being auto generated saves development time, it’s how applications should be produced anyway. Having a layer which does this for you doesn’t give the benefit unless u lacked the ability to provide it in the first place. We build our business logic as a completely separate layer from the data access layer. The data access layer’s purpose is to provide a separation of concerns, so that no other code has to worry about how the data is stored. This includes different types of database or say differences in how databases represent types compared to the programming language of choice. If your lumping all this in with your business logic, then you’re doing something wrong.

When ORM has worked well for us was recently with the migration away from MySQL to PostgreSQL. By completely separating the database from our code we able to migrate to a completely different database vendor with practically zero changes to our code. This means our database choice can be re-evaluated as necessary and based upon changing business, performance and engineering reasons rather than being forced to stick with one particular vendor. Our code also benefits from a very clear separation of concerns provides us with a more extensible and maintainable solution. Overall we are very happy with ORM and specifically Entityspaces.

Recently I was struck with a problem that turned out to have a very obvious solution that I thought would be worth sharing, In the hope that Google might just return this result to someone with the same problem. The problem was uploading files without having a file upload control in ASP.Net. This was necessary for a particular project we working on. Using a literal control to output the file upload code was simple enough. Trying to get access to that was proving more difficult. Any search for information on the subject invariably returned information on the System.Web.UI.HtmlControls.HtmlInputFile which I could not use. Turns out .Net makes this very very easy for you with Page.Request.Files. This is a named collection of all the files which have been uploaded to your page. From here you can easily get access to the file names and even save the file directly to disk.

We have just finished migrating to an automated continuous integration work flow. This was required as our team expanded to include more developers. Using SVN and CruiseControl.net we quickly automated our entire build and testing process. Our current work flow on the trunk is something similar to this:

• Add a new feature to the trunk
• Check feature builds and works as expected locally
• Commit
• Do Other Work
• If CC.net build successful test feature on development deploy
• If CC.net build unsuccessful immediately stop other work and fix the build

Overall CC.net was quite easy to setup. The install was quick and configuration didn’t take too long though I did have to familiarize myself with writing batch scripts again when we had a few problems getting the automatic deployment working and had to script around it. We even got doxygen generating the documentation automatically after every commit to the SVN.

In the past I’ve found its very difficult to convince people to implement systems and procedure’s which at first glance don’t save them time. With CC.net you don’t have that problem; absolutely everyone saves time once it’s been setup, from the manager that can see a always working version of the new features to the developers that need quick feedback on their changes.