A single test failure, after all this time!!

OK, so I have just checked back on the project, and it actually looks like there is only a single test failure at the moment. The incorrect password count is not resetting when the user successfully logs in. This could be a quick win, so I think I will stick with this, debug it and then try and get my head back into the rest of the code.

Holidays

Next week, my partner and I will be venturing oversees on a long awaited holiday. It has to be said that, although I am looking forward to the holiday, I think I will find it a little difficult to shut down and stop thinking about this project. I guess that's one of the traits of a software developer, all of those little projects will follow you around wherever you are and whatever you are doing. I shan't let it spoil the holiday by any means, and there is a possibility, due to the nature of the holiday, that I may get time to dabble in coding while I am away, but I don't want to spend too much of my time thinking about it.

The project is starting to take some real shape, and although it is nowhere near releasable yet, I have some screens designed, and the back end is working okay. There is still plenty more to be done, and with each passing day, another idea comes into play that could change the amount of time it takes to get the website online.

For now, though, I need to relax and enjoy my time away. Exciting things await me on the other side, I'm sure!

Running StyleCop for all projects in Visual Web Developer 2010 Express

In my previous post, I hinted at a method of getting StyleCop to run under the free versions of Visual Studio, particularly Visual Studio 2010 Express and Visual Web Developer. Getting this tool to run is remarkably simple, although there are some differences between running under this environment and running under the paid for Visual Studio editions.

Although these differences mean that StyleCop does not seem as embedded in Visual Studio as previous environments that I have worked with, I have become used to working in a certain way, and it no longer bothers me that my work environment is a little different to my home working environment.

What is StyleCop

For those who are not already using this fantastic tool, StyleCop is a Visual Studio plugin which enforces certain rules against how code is formatted, code location, and where and when documentation headers are used. Of course, if you have never used StyleCop before, this doesn't seem like that much of a big deal, and can even seem like a waste of time. I fully admit that, when I first came to using the tool a few years ago, I was a little sceptical at first. Implementing the rules became a little bit of a hassle, especially as I always left the enhancements until last thing, resulting in potentially hundreds of "errors". It wasn't until I moved to a new company that had never used the tool that I realised how much easier code that has followed the rules is to pick up and find your way around. It is true to say that StyleCop will probably not enhance any of your actual code, but if it means that you need to think about what a method does in order to decorate it with a documentation header, then that can't be a bad thing, can it?!

Installing StyleCop

Back to the main purpose of this post, how to go about installing StyleCop on a Visual Studio Express environment. First things first, you will need to download and install the MSI, which can be found on the CodePlex website. Once the installation has finished, you will need to find the .Targets file. This should be located in the MSBuild folder C:\Program Files (x86)\MSBuild\StyleCop\v4.7\StyleCop.Targets. Move this file to the following folder (you may need to create this folder if it doesn't already exist!) C:\Program Files\MSBuild\4.0\Microsoft.CSharp.targets\ImportAfter\.

That's it, it really is that simple. You will need to restart Visual Studio, but from now on, every time you build a project, StyleCop will run.

Happy Coding :0)

Patterns and Practices

In a previous post, I mentioned that I had written the bulk of the database that will drive the website. This is still true, but after reading a few articles on the Code First pattern, I have decided to leave the database portion of the website alone for the time being and concentrate far more on the API using the code first and repository patterns. This is something new for me, as in previous projects, I have always had a database to read everything from before doing anything by way of front end testing. The pattern is made really simple when using Ninject to create a mock data store from which to read the data, and I have to say that I am really enjoying coding this way.

Generally, when using the code first pattern, a developer will allow the Entity Framework to go ahead and create the database for them when they run the project. I'm not sure I quite agree with doing it that way. I might allow it to create the database when I need to, and see what it comes up with and how it fits in with my knowledge of database schema design. To be honest, the bulk of it should be OK, but I like to be more in control of my own indexes and foreign key constraints as part of the database design which is why I am a little reluctant to have the database generated. Time will tell as to whether this works out.

In the meantime, I now have a fully working setup of Visual Studio Express which works a lot more like the professional setup that I use in my day job. It takes a bit of hacking around, but getting things such as StyleCop to run under the environment is very important to me. I admit that using StyleCop to evaluate code structure is something that a lot of developers don't like, but it is something that I find extremely useful as it helps the navigation of the code, and makes me a little less lazy with the documentation of the project. Getting StyleCop to run under Visual Studio Express for all projects can be a little fiddly, but a little research led me to a really simple solution which I will share in my next post.

In the meantime, it's back to the coding for a little more of my Sunday afternoon, after which I need to go and find a replacement for my broken kettle (one of the most important tools in any developers armoury!)

Happy Sunday :0)

Coding on a Sunday night

It's a quarter past twelve on a Sunday evening and I'm sitting here blogging and coding. I really should be in bed right now, my alarm is due to go off in a little over 5 hours. But the fact is that I am enjoying myself. The database for the new website has had a few minor changes this evening. Most of this is not because of any redesign as such, but because of me forgetting to include a few key parts of the website. I should have done a proper project plan before starting, but hey, I'm a developer, not a project manager. I know this is completely the wrong attitude if we look at all the books on building websites. There are certain rules that everybody is supposed to follow. But the fact is that many of the websites that we use on a day to day basis do not follow this. They are the sorts of projects that are developed in code as fast as they are developed in the head of the person that is coding them.

So where are we at? I have the database there, with a few parts still missing (the scripts are coded, but the columns and tables themselves are not there yet. I will be putting them in later, and they are definitely in mind when I'm working on the front end!). I also have a few pages, and parts of pages for the new site.

The security has been taken care of, although at this time I am not entirely sure whether I am going to rebuild the security side of things myself. At the moment, I am reluctant to do so, as the project already has the standard MVC security there and I have no users on the site. It may be changed in the future, but not now. The pages I do have are slowly taking shape. I am concentrating on the front end user interface at the moment. The CSS is taking shape and I am testing against Google Chrome and Internet Explorer just to make sure that it all works. Of all of the Internet browsers, Internet Explorer is the one that I have had the most trouble with during my career. IE has always had trouble keeping up with certain Internet standards which have been adopted early by the likes of Google Chrome and Firefox, so much of the front end testing will be against IE. Looking at the stats from my other blog, I will be needing to make sure that I have tested against several versions of IE. For this, I am using IETester, a great program that allows you to test the front end of a site in multiple versions.

I am also thinking about the front end from a mobile browser perspective. Any site these days needs to have mobile support as many of the potential page hits will be from a mobile source. This needs a little more investigation as it is not something I have really had to deal with before.

Back to the coding!

As a side-note, I am leaving the Foo Fighters alone for tonight, and using one of the other motivational tools that I have to hand... I don't know quite what it is about The Social Network that gets me motivated, but it never fails to get me in the mood to create something!

Weekend Working

It is 7:30 on a Saturday morning and I am about to delve into coding. It's been a fair while since I have been able to say that!

In my last post, I said that I would be creating some of the tables in my database ready for the front end code. Well, the operation went well, and I now have many of the tables that I will need. Not all of them, but I am still more inclined to get some of the basic functionality done before I begin adding things all over the place.

I briefly toyed with the idea of creating my own tables for the security features of the site such as user logins and admin updates. Having thought about it for a few minutes I decided to stick to the Microsoft security features available in .Net. Using these features means that I have more time to concentrate on the bulk of the actual site without worrying about the things that are in the background. So my database is now fully equipped with the various aspnet_* tables as well as the tables that I had created.

The next step is to begin coding the actual site. I have decided to go down the MVC route to create the site, mostly because it is quick and simple. I don't use MVC that much in my day job, but have come to be quite fond of the concept from messing around with a few other projects that I have delved into.

Anyway, I must get started with the actual coding. Time to break out Visual Studio, and the Foo Fighters (awesome to listen to when coding!).

Making A Start

I am a very firm believer in building a website from the ground up. It's all well and good having a really good front end but if the back end code doesn't work, a pretty site is as good as useless. That's not to say that some of the design work shouldn't be done before hand. You couldn't, after all, build something without having some idea of what you are wanting it to do. But I have seen websites before that I can tell the developers have spent a lot of time designing a pretty user interface but not a lot of time on the background code. These sites look really pretty, but as soon as more than ten people are using it, the site slows considerably, or the Javascript doesn't work, or updating data will take too long.

For this reason, I have decided that I am first going to concentrate on the database. I need somewhere to store the data and content that I am hoping the users of the site will provide. I have some ideas in mind of what is going to be in the database, how much data there will be, and what the common searches will be, so it shouldn't be too difficult to get the first few tables with their relevant indexes, constraints etc in place. I am concentrating on the basic functionality to begin with, but will try to leave the tables open to the more complex functionality that will come later.

Time to start writing some table definitions. I know that there are many other ways of creating a data store these days, but for some reason when it comes to creating a database, I like to do things by hand. I have a very specific way of writing database creation scripts that I have been using for many years now. Certain parts of the way in which I write the scripts have changed over the years, but the basis of it remains the same. I feel a lot happier writing the scripts by hand as I find it easier than relying on the overly fiddly user interfaces that some database builders will use.

Time to break out SQL Server Management Studio and get to work