Yesterday we had another one of our programming sessions that I was talking about in my last post. The subject for the day was front end performance and what we can do to make our sites faster. The meeting was based on Steve Souders book High Performance Websites. He is the developer behind YSlow, a must have plugin for firebug when you are optimizing your front end.

Only about 5 - 15% of the load time from a common website is from the actual server side rendering. The rest of the time is spent downloading scripts, stylesheets, images etc. So, the question is, why do we spend so much time trying to fix our "slow" sql queries? Isn't there a way we can work on our front end so that the client doesn't have to spend that much time downloading all our resources? Well, of course there is. Steve Souders have developed 14 rules that will make your site load faster if you follow them. I will not go through them now, but you can see the whole list here.

I think this is a very interesting subject and there is so much more we can do to make our site faster, and a lot isn't hard at all. It can be as easy as changing a setting in your webserver. I have written about this before, and I think its very important. You do not only help then client to render your site faster, you are also taking a lot of the load away from your servers when they have to serve less and smaller files. I would like to recommend this page. There you have a number of great videos from the yahoo team that are very helpful.

Efter att ha startat och lagt ner ett flertal hobbyprojekt så börjar nu lusten att starta upp nåt nytt att leka med på fritiden komma tillbaka.

Efter att ha startat upp en budget-site, en e-shop lösning till min pappa och massa annat småpill utan att komma i mål med nåt av projekten så känns det nästan lite dödsdömt från början. Jag undrar varför det blir så? Varför kan jag inte slutföra mina hobbyprojekt?

Dels är det såklart tidsaspekten, jag orkar helt enkelt inte sätta mig vid datorn och fortsätta programmera när jag kommer hem. Som tur är har jag ett jobb där jag har möjlighet att utforska nya grejer på arbetstid. Samtidigt missar jag ju tekniker som jag inte jobbar med på jobbet, och om vi då bara snackar om .NET stacken så missar jag t.ex. Silverlight och WCF . Python och Ruby skulle vara oerhört intressant att lära sig mer om även om jag får sitta med Python ibland så vill jag gärna sitta mer med det för att komma in i det "dynamiska tänket"

Men de hobbyprojekt som jag ändå drar igång har en tydlig tendens att dö ut när jag kommer till design-biten. Jag är inte världens bästa designer och tröttnar lätt på nåt jag knåpat ihop själv, vilket får mig att tappa intresset för hela projektet.

Med denna kunskap i bagaget kanske man skulle ge sig på att bygga nåt utan ett alltför grafiskt gränssnitt.

Idag hade jag tänkt mig att bygga en "Nytt projekt mappstruktur" så att man slipper skapa mappar för lib, src, doc och att den automatiskt skapar en solution fil. Och allt detta ska skötas ifrån consolen :)

En annan tanke är att skapa ett väldigt lätt ramverk ovanpå .NET MVC. Det jag vill uppfylla är nåt liknande Django där modellerna och admingränssnitt autogenereras, samt att mycket av de kommandon man kör i Python-consolen har sina motsvarigheter i mitt proejkt (t.ex. startproject, syncdb etc). Alltså nåt som man lätt kommer igång med.

I guess that most developer have their favorite set of libraries that they use in just about every project. Atleast I have such a toolbox. They are tools that I find myself using constantly and that I feel help me in my development. Here comes my list.

1. Asp.Net Mvc

Well, I'm mostly a web developer so I need a nice web framework to start with. I feel that Asp.Net Mvc is the framework that I can be the most productive and have the most fun with at the moment. When I start a new web project in visual studio it's allways a mvc project.

2. NHibernate

If you have been reading my blog, you know that I'm a big fan of the OR/M NHibernate. I never build a web application without NHibernate as my data access layer.

3. Structuremap

Not to much to say here. I want to use a di/ioc container and structuremap is my personal favorite that is available for the .net framework.

4. Automapper

A great tool to map entities to viewmodels. It's easy to use and set up, and you will save a lot of left-to-right code by using it.

5. jQuery

If you want a nice looking UI at the client, a javascript library will help you a lot. My choise is jQuery. It's simple to use, has great support and there is a ton of great plugins.

6. NUnit

We need a testing framework if we should write test. My personal favorite is NUnit. It's simple and it works great.

7. Rhino Mocks

If we write tests we usually need a mocking framework as well. My choise here is Rhino Mocks. I have been using it for a while and it's working out great for me.

Those are the tools that I use in just about every web application I'm building. In my oppinion they make development a lot smother and more fun.

In just about every application I build that use a relational database, I also use a orm tool to handle my data access. The reason I do this is to save myself the time it takes to handroll a data access layer in ADO.Net and to eliminate buggs that can come from writing sql queries. I do have a few things that I look for in a professional orm that I think is important:

1. Transparancy
2. Extensability
3. Linq support
4. Preformance

1. Transparancy

The most important feature of a orm, in my opinion, is that it should be transparant. This means that you, as a developer, should not constantly be remindad what tool you are working with. The orm itself should sit in the background and handle the persistance without you noticing it. You should, in my opinion, have a clean domain model that has no direct dependency on you'r orm while the mapping itself should be seperated from the domain. You should be able to, freely, shoose the types all the types on your model and map it to the underlaying database.

2. Extensability

No tool work perfect for every solution out of the box. This is why it's important to have extensability points that the developer can use to make it fit his/her needs. With a good architecture a tool can give the developer a very free hand on how he/she want's to extend it and make it fit any application.

Many extensability points will also encourage developers to create third party tools to help development with a certain orm. And when you find those tools that you like, it will speed up your development process, and you can focus on some other part of the application.

3. Linq support

Linq support is allways a good thing to have in a orm tool, as it is built into the language we use and we are used to use it in our every day work. It makes us write strongly typed queries and we are not forced to learn a new API or querying language. A good linq provider can mean a lot to a orm and help the developer eliminate "magic string bugs".

4. Preformance

Preformance is, of course, a very important part of a orm as it will handle a lot of trafic between the database and the application. The reason I put it last on my list is that it will not be a huge difference between two professional tool on basic CRUD queries. Most orm's will send very similar sql to the database for 90% of your queries. A orm should, however, be cacheing your queries and make sure you don't hit the database more then necessary.

Those are the features I think is the most important once to have in a professional orm. My personal choice is NHibernate, which I think cover those points pretty well. The one thing I think need improvment in NHibernate is the linq provider. This provider is still under development. Other then that, I think NHibernate is the most complete orm for the .Net framework.

A few days ago I read this post, in wich Jeff Atwood writes about abstractions, and how they all "leak" in one way or another. This is true, as a abstraction solves the generic problem, not our specific one. One thing we seem to forgett, however, is that all code we write is acctually a abstraction. There is no way for a computer to understand a c# if statement. It has to be converted to machine code before the computer can execute the comand. There is alot of different abstractions, some good and some not quite as good. But they are all there for a reason.

Jeff had Linq-to-Sql as a example of a abstraction and showed that the sql query could be written in a better way. But so could the machine code that is acctually executing. The lower you go, the more you can optimize what your doing. But who would spend hour after hour writing code that solves a very small problem? The reason we use abstractions is to save development time. At a very low level you can optimize every part of a application, but in the end, it´s just not worth the time it took to develop the application. We should not be scared of new abstractions because then we will never move forward. Would you argue against me if I saied that I would use the .NET framework for my next web application?

Another good thing with abstractions like a ORM for example, is that they will give you alot more compilation error and alot less runtime errors. And everyone who has spent time debugging a application, knows that this is worth alot of time and patience. Even if you loose a few milliseconds in response time, alot of the time it is worth the time you earn not having to fix bugg after bugg after the application is released to production.

There is, of course, times when you should avoid specific abstractions. But as I wrote in my last post, I think we spend to much time optimizing the wrong thing. It´s better to find the real bottle neck and fix that issue first. When you think about using a tool, don´t just think about what you will loose in response time (this is of course important as well), but think about how much development time and maintenance time you will save as well. You will loose users if you have a slow web page, but the same will happen if the user sees a error page to many times. No developer writes perfect code, but the sooner we find our errors, the better. 

A very important task in just about any web application that you will build is data access. There is alot of opinions on how this is done the best way.  You can use inline sql statements in your code, you can use stored procedures or you can generate your sql using a OR Mapper. From the developers that use sprocs you will ofter hear arguments about preformance and security, while you will here arguments about managable code from the OR/M fans. I think that, depending on your architecture, every bit of code has it´s own place and that different concerns shouldn´t be mixed up. That is why I choose to use a OR Mapper when I start a new web application.

The thing with stored procedures is that they can often grow pretty big and handle alot of things. You might end up with a few "if" statements and alot of parameters. And why on earth would you force your database to handle your business logic? That is what the application does best. Why write business rules in  sql when you might just as well do it in a strongly typed fashion, using c# (or the language you prefere). A database, in my opinion, should be there to store your data, and nothing else.

So if we remove all the business logic from our sprocs and let them be responsible for simple CRUD operations only, then we are good. Right? Well, in my opinion, we are not there quite yet. We do now have a bunch of sprocs with simple CRUD statements that we need to manage. This can, as many of you might know, be one hell of a task. When you have a big database with lots of sprocs that contain about 2 rows of raw sql each and you need to add a field to a table that you forgott when you started the development. Imagine the headache you´d get when you realize that you need to change all sprocs accessing that table and add the appropriate parameters to the command that executes the sprocs. And all this just to add a fild to a excisting table. Simple CRUD operations is where a OR Mapper realy shines. That is the primary reason why developers choose to use them.

So what about the security and preformance then? Well, the chance of beeing a victime for a sql injection attack is the same for a sproc and a parameterized query (wich is what any good OR/M will use) is the same. You do not suffer a bigger risk for such a attack just because you choose to go with NHibernate (or any other OR/M) instead of sprocs. The only security gain that I can see using sprocs over generated sql is that you can control the database access so that you can allow the application to execute sprocs but not access the tables themselves. But in most cases you will trust your application to access your tables. There is, of course, times when you dont trust the application 100% and you would rather expose a api for the application(s). In those cases I would rather build a service thatprovides this API. Then you will have a strongly typed API that your applications can access in a secure way.

It is true that the preformance of a generated sql query can´t be better then in a sproc. But it can be equaly good. I hear many arguments like: "sprocs are pre-compiled sql queries that will run faster". That is false arguments as it is acctually not pre-compiled (in mssql server) at all. Sql server will, however, precalculate a execution plan for the query that will make it run a bit faster, but it will do the same for a query sent to the database. This means that you can get equal preformance with sprocs and generated queries for simple CRUD operations. When a query hits the database, sproc or string based sql, the database will check its cache and see if this query has been run before. If it has, the database will reuse the same execution plan as before and the query will run faster.

I feel that many developers, including myself, often focus on the wrong thing when trying to optimice a application. Instead of finding the real bottle neck we are working hours on optimicing the wrong part of our application. If you have a webforms application with a ton of viewstate. Then you should try to minimize that before going to your DAL and optimicing your queries. There is, of course, times when you need to work on that as well. But most of the time that is only one or two realy complex queries. In scenarious like that, I would probably write a sproc for that specific situation and use my OR Mapper to call it. But as long as we are talking simple CRUD operations I feel that the extra time it takes to write all those sprocs would be alot better spent on optimizing other parts of the application as the preformance of the modern OR Mappers is very high.

As for Jakobsson this is also my first blog post and I am a programmer through my whole heart and soul, which i think explains my headline. The Similarities between me an Jakobsson doesn't end there because I am also from the Varberg and we have gone to the same school and share the programming intrest.

So what is there to talk about except MVC the new big and fun thing out there to play with and I love it, But the biggest things about it, is not the MVC pattern. The things that are the most interesting from my point of view is the Routing. As you can see in the MVC FUBU project, because it's one of the things they kept. And i also love the binders they are going be very intresting to use :D I can't think of anything I don't like yet and i love that Microsoft opens up and share the source code.

So a really big thanks to the MVC team from me to :D

Hello!

This is my first blog post ever. I´m a swedish .net developer from a town called Varberg on the west coast. This blog will primary be a tecnical blog mostly about the .net platform. But I guess I´ll throw some other stuff in aswell from time to time.

Because the Asp.Net MVC framework went RTW today, I guess thats a good first topic. For those of you who doesn´t know what kind of a framework that is, you can just google and you will find out.

There was´t alot of changes from the earlier RC2 more then a few bugg-fixes. But it´s great that we now have a stable version of the framework to develop with. The installer and release notes can be downloaded here.

Finally I want to thank the whole MVC team at Microsoft for developing such a great product, and thats all from me for now.