Yesterday myself, Don, D’Arcy, and Eric were wandering around Seattle, just checking out the sights after the MVP Summit. We took a break from the usual “run down D’Arcy and Manitoba” shtick, and actually had a serious conversation on the relevance of stored procedures for your typical database development/line of business app. D’Arcy blogged his take on it already. I was going to reply in his comments, but as the comments grew, I figured my own post was in order.
Thanks to Phil Haack’s online poll, there is a bit of controversy over where one’s unit tests should reside: should the unit tests be housed in a separate project and assembly, or do they shack up in the same project as the code that they are testing? Like Bil, I figured that rather than a big long blog comment, I’d be better of with my post.
Way back when I started out with TDD, I used to put the test fixtures in the same file as the class under test, sort of like:
Today I got a new hard drive for my web server, to replace the one that died back in February. Hopefully the new 750GB drive will serve me as well as (or better) the old 200GB WD Cavair. I must admit, I was a bit suprised at how cheap it was to get such a big HD.
The first order of business was to move my web site off it’s current home and onto it’s new, more permanent one. I went about installing Ubunutu 7.10 64 bit, and them VMware server 1.0.4 on the new computer. If you Google it, are a lot of articles on installing VMware on Ubunutu. However, I did run into one stumbling block: with 64bit Ubunutu you need one more dependency: ia32-libs
Last night I spent some quality time looking at vincent-vega, aka Continuous Database Integration for SQL Server. This is a pretty simple and handy task for Nant that helps bring continous integration to your databases. I use updateSqlDatabase like as part of my integration tests like so:
What this project will add a new task you: updateSqlDatabase. With this task, you can do one of three things: Add a database, Create a Database, and Update a database. updateSqlDatabase will look for SQL script files , and will execute those SQL scripts for you in the order they are found. Information about what scripts have been run are kept in a table that updateSqlDatabase creates for you when you create your database. This will allow you to see the history of when your database was updated, and with scripts. This
How to get started and use it? First, get the code from Google Code. Compile the code. Next copy the output of the build to your Nant bin directory. See the image below. You probably won’t need log4net.dll or Nant.Core.*.
Once again, appealling to the niche (non-existant?) market, I give you a quick run down on using db4o, and the Castle Windsor db4o facility. Yes, I know the link for the db4o facility link doesn’t work. That is what prompted me to do this blog post. This is because, a while ago, the db4o facility was pulled from the Castle Project. Apparently there was a licencing concern. It’s my understanding that this has since been resolved, and I seen now that there is again the db4o facility.
As most Resharpies know, when you’re using Resharper you can reformat your code. A nice feature is that you can use this reformat code to also organize and layout your code files the way you like it.
For example, Kyle Baley did post on how to how to use the format code to get rid of regions. His techique is a bit unrefined - his revolutionary, dogmatic zeal he will clobber all regions and do nothing else - but still handy. Myself, I’m a bit more compulsive / fussy when it comes to the layout of my code. Not only do I want regions gone, but I want the code to appear in a certain order. Lucky for me that Reformat Code does this for me. Here is the Type Member Layout pattern I use. If you want to use it, just paste it into the type member layout window in Resharper.
One of the biggest discussions that I typically get when I try to introduce things like NHibernate (i.e. OSS) on a new contract goes like this:
“We’re a bit reluctant to use that because it will introduce more code into our code base that isn’t ours. Because it’s OSS, there’s no support, and if there was a bug in it, we’d have to maintain it ourselves. That being case, we’d rather just write our own code, because that way we know what is going on with it and can maintain it better. We don’t want to have to figure out somebody elses code.”
The past week I’ve been dabbling with an open source program called Open Dental - mostly trying to see if can get it to compile under Mono, and running under Linux. I figure that this would be a good opportunity to and work with a cross platform application.
According to their website, Open Dental has been supported under Linux since v4.7. Here are some notes of my efforts so far.
You will need Mono v1.2.5. It seems that there is a problem with the Linux binary installer ( a known bug that will be corrected in 1.2.6). I used the OpenSUSE 10.2 VMWare image which had a 1.2.5 install all set up. That solved my problem of getting a current Linux distro with the most recent version of Mono.
One thing I noticed since I started doing ASP.NET programming back in 2002: I started using Javascript a lot less, and my copy of JavaScript: The Definitive Guide sits on the shelf gathering dust. I’ve noticed a lot of developers I’ve worked with are the same way. In fact, I’d say that most of the ASP.NET programmers I’ve worked with these days really don’t know much about Javascript.
I don’t blame Javascript itself for this - I blame ASP.NET. Developers just get used to dropping the server side controls on their WebForms, and then doing everything server side. I’ve also worked at clients which had a “no client-side javascript” rule. All of this combines to cause our (my) Javascript skills to atrophy and wither. Kind of shame, really. (note: to a degree, I think the same can be said about CSS).
Recently, on one of the mailing lists I subscribe to, a member starting bashing .NET. A bit curious as to why there was this strong hatred of .NET, I posed a simple question:
What is wrong with .NET?
The answer I got back somewhat suprised me:
I guess the standard reply is, what is right about .NET? .NET was invented so that M$ could provide software as a service. You would end up with a minimal OS on the disk, and no applications. When you turned your computer on, it would download whatever applications you needed, or did so on demand; if your subscription was paid up.
