January 2006 - Posts
I came across this nice little “About box” on Scott Watermasysk’s blog:
Scott is an employee of Telligent Systems. Most of his work time is spent trying to make Community Server (the application behind this blog) just a little better than the day before.
Rather then getting overwhelmed with all you have to do with your application keep it nice and simple. Make your software a little bit better then it was yesterday. Now repeat.
Make your code a little bit better. Make your process a little bit better. Make your team a little bit better. Make small achievable goals. Now make them better.
What did you do to make things a little bit better then they were yesterday?
It looks like we have another Ajax library for .NET. It turns out Community Server 2.0 uses Anthem as well as some of the controls from Component Art. I was planning on doing some experimentation with Ajax.NET Pro but now I’ll have to checkout Anthem.NET as well. 
Now we just need someone to make is super easy to integrate Ajax into ASP.NET like those crazy Ruby on Rails folks have. Any takers?
I’m thinking about moving my feed over to FeedBurner. I’m also thinking about starting to tag my posts and link them over to technorati. Thoughts?
Some good stuff from around the blog world that I wanted to share. Not interesting enough on their own but maybe as a group they’ll be worth something.
If only I didn’t have such a headache perhaps I could read some of them 
Jason from 37signals has a post today about product roadmaps and why they’re dangerous.
Our answer: Product roadmaps are dangerous. They close your eyes and often put you on the wrong path.
The question boils down to this, if a product roadmap is out of date the minute it hits the “printer” what value does it provide? It’s nothing more then a long list of items that seemed like a good idea at the time the roadmap was written. As time passes by the items that seemed important a couple months, weeks, or days ago may no longer be relevant. The beauty of Agile development is that it allows you to stay flexible, and allows you to change your roadmap at any moment. Since the roadmap isn’t etched in stone the team won’t feel bad ditching it for what’s most valuable now. An important note to make is that while a roadmap may not be necessary a vision is absolutely required.
Brian pointed to an experience report from last year's agile conference that a number of people at our office have talked about since we started pairing a couple months ago. One of the points that Brian highlighted was:
- After experimenting with pairing time periods from 30 minutes to a full week before swapping pairs, 90 minutes proved to be the most productive.
My question is this, how is it possible to switch pairs every 90 minutes and still stay productive? We try to switch every 4 hours or so but we often end up going longer because people are about to finish something and in order to get a new person up to speed we'd have to spend a bunch of time reviewing what was already done. Hrm, perhaps that is point. If you spend too much time working on a single thing with a pair it takes too long to get someone else up to speed. If, however, you only spend 90 minutes there is much less to get the pair up to speed on. The other advantage is that if you force yourself to switch every 90 minutes there is less likelihood of a pair getting stuck on something since a fresh set of eyes will roll into the pair. Don't you love when you start a post with one intention but end up with something completely different?
One of the changes that was made between beta 1 and recent CTP's of Indigo (WCF) was the way svcutil generated proxies. Within our service layer we have several services that return a generic list to the client. In beta 1 the proxy class generated by svcutil used generic lists. When we migrated over to the Nov CTP (back in November) this behavior changed. Rather then using the List of<T> the proxies were using an array of T. At the time I figured they didn't want to be serializing information about the fact that the service was returning a generic list, since that isn't very interoperable, however as I thought about it more I started thinking I must be missing something. There is no reason that the proxy couldn't still use a generic, Since Indigo is handling the serialization and deserialization it could just as easily deserialize the message into a generic list as it could an array since they are wire compatable.
With this though in hand I jumped to a command prompt to look at what options were available for svcutil. That's when I discovered the /rct command line switch. I tried a couple different variations to try and get svcutil to pick up that I wanted to use System.Collections.Generic.List<T> but I wasn't having much luck. That's when I headed over to the
WCF Forums on MSDN to look for an answer.
Yes - /rct switch is what is needed.
If you are looking for a way to replace all collections with
List<T>, you need to specify that type via /rct using the fully
qualified type name (assembly-qualified name is needed if the assembly
is not loaded via /r; mscorlib is always /r by svcutil).
Ex. /rct:System.Collections.Generic.List`1 should work.
This setting will apply across all your services during code generation.
We allow users to customize this further if they want to map to
different collection types based on the element type T. This can be
done by providing multiple /rct parameters - we will use the most exact
match.
After a quick switch from /rct:System.Collections.Generic.List<T> (which was bombing) to /rct:System.Collections.Generic.List`1 svcutil was once again generating proxies with the generic list!
Simon Stewart’s “The Simplest Thing” is a good read for those doing Agile development and trying to get what “do the simplest thing possible” means. Just a another reminder that The Simplest Thing != The Easiest Thing.
I’m officially unsubscribed from the main MSDN feed. Does anyone have an OPML file of bloggers from the MSDN feed that they recommend? Or perhaps just a nice list?
Thanks!
In my “Why all the hype over Ruby on Rails?” post I mentioned that one of my favorite features within Ruby on Rails is migrations. Since migrations seems to be one of the features within Rails that many of my .NET buddies don’t know about I figured I’d post about them to not only help expose people to what migrations are but also to help make sure I can explain them in a coherent way.
What’s a migration?
As we develop applications we continuously refactor our code and database to add new functionality as well as to clean up what is already in place. As we add features to our applications we modify the schema of the database that we use to house our data. I’ve used many different methods for managing this process with varying degrees of success.
When modifying a database schema developers often create SQL files that perform the necessary operations on their database. The SQL file is meant to take a previous version of a database up to a subsequent version. Since SQL files usually have keywords specific to a database platform they are not re-usable for other database platforms. If you support more then one database platform this can result in multiple SQL files for a single change. What ever happened to that DRY principle that the Pragmatic Programmers advocate?
One of the other problems that we face is the process is rolling out the changes we make to the other members of our team. At my old place of employment we used a DTS package to copy the current “checked-in” version of the database to each developers local machine. Although the process worked it wasn’t as smooth as one would hope.
Ruby on Rails migrations is meant to solve the problem of rolling out changes to your database. By defining the changes to your database schema in Ruby files development teams can ensure that all changes to the database are properly versioned. Additionally migrations help to ensure that rolling out changes to fellow developers as well as other servers (development, QA, production) is handled in a consistent and manageable fashion.
What are we migrating?
Before moving onto a definition of how migrations work I’d like to overview what types of changes we as developers make to our database.
- Adding a new table
- Removing a table
- Adding a column to an existing table
- Removing a column
- Renaming a column
- Renaming a table
- Adding an index
- Adding a primary key
- Adding a foreign key
Defining a change in Ruby
One of the nice things about Ruby is that it can feel very much like a domain specific language. By using ruby as a domain specific language we can define the changes we make to our database in a way that abstracts that change away from a single database platform. This allows the change to be applied to not only other databases but also to completely different database platforms. For example to create a new table using migrations you can create the following migration file:
class AddUserTable < ActiveRecord::Migration
def self.up
create_table :users do |table|
table.column :name, :string
table.column :login, :string
table.column :password, :string, :limit => 32
table.column :email, :string
end
end
def self.down
drop_table :users
end
end
As you can see the migration file above has two methods, up and down. Migrations not only support migrating a database from a previous version to the current version but it also supports rolling back database changes. So if I was currently on version 5 of our database and the above migration was to move to version 6 I could very easily roll back the version 6 change by saying “yo give me version 5 fool!”. When moving up a version the logic within the “up” method is called, and when rolling back to a previous version the “down” method is executed.
Migrations also support other changes such as:
class MakeAllKindsOfChanges < ActiveRecord::Migration
def self.up
add_column :users, :phone_number, :string, :limit => 20
remove_column :users, :email
change_column :users, :name, :limit => 10
drop_table :some_old_table
rename_column :users
rename_table :users, :myCoolUsersTable
end
def self.down
#undo all that stuff I just did above
end
end
By utilizing migrations I can define every database change in an abstract fashion and then rely on the various connection adapters to convert my change into the SQL necessary for each database platform (MySQL, PostgreSQL, SQLite, SQL Server, and Oracle).
Applying a change
After I’ve defined all my changes in my migration files I can then update my database by using the “rake migrate” command. I can tell migrate to use a specific database and I can tell it what specific version I want my database migrated to by adding the VERSION option:
rake migrate VERSION=5
Summary
There is actually a lot more that could be said but this post is already longer then I wanted so let’s wrap up. Rails Migrations allow developers to define the changes to their database using a domain specific language that abstracts the change away from a single database platform. It tracks the changes using versions and allows for developers to migrate a database to any given version. Additionally migrations can be used to update both developers workstations as well as to apply changes to production databases.
Command reference:
dumps an existing database to a Rails schema file which allows you to port an application to different database platforms.
rake db_schema_import – imports the schema dumped using db_schema_dump
rake migrate – migrates a database to the current version
rake migrate VERSION={X} – migrates a database to a specific version
rake environment RAILS_ENV=production migrate – migrates the production database to the current version
rake schema_generator – products a .SQL file for each supported database platform (not everything is currently supported)
I just added a couple books to my “to be read” stack. I wonder if I’ll ever get to the bottom?
Agile Estimating and Planning (Robert C. Martin Series)
Micro-ISV: From Vision to Reality
The January CTP of WinFX has been released, and along with it a Go Live license for WCF and WWF. This is great news for those of us building software using these bits.
Additionally now that there is a go-live license I can start building some personal projects using these bits. Although my personal projects usually aren’t all that exciting I often get a chance to iron out some ideas and thoughts I have with regards to particular technologies so a go live license for Indigo and Workflow is most excellent. Maybe I’ll even get to include some nice Indigo/Workflow “goo” in ActiveType?
After considering a couple evil alternatives Sam Gentile has decided to join the illustrious bloggers over on CodeBetter.com. Best of luck at your new home Sam.
Dual Core MacBook Pro.
Anyone want to buy me one?
I’m finally getting back to work on ActiveType and have a couple features that I’d like to utilize Ajax for. Has anyone had any luck with the various Ajax libraries out there for .NET?
Over the last year I’ve become increasingly interested in Ruby on Rails. Although Rails has many technical reasons to peak my interests what interests me most is the passion that those using Rails have for it. Over the last couple weeks I’ve started experimenting with Rails. I have a small application that I’m planning on writing in Rails if I ever stop playing around. During my experimentation I’ve taken notice of the following things:
- The design of the domain model in Rails is right up my alley. The entity framework that I developed at my last company (as well as the one I wrote for my own projects/products) was based on the ActiveRecord pattern. Although the ActiveRecord pattern isn’t the purist approach I think it is very pragmatic. I like pragmatism.
- Rails validation is similar in concept to the attribute based validation I’ve implemented so again I’m a fan
- Built in support for AJAX is nice. Prototype and http://script.aculo.us/ (see demos) are very powerful javascript libraries that we could all benefit from learning and exploring.
- The focus on MVC for building Rails applications does a nice job of ensuring presentation logic is clearly seperated from business oriented logic. Nice.
- The implementation of views gives me bad flashbacks to my classic ASP days, yuck. Server controls in Rails would be sweet.
- Migrations in Rails is awesome. I’ve had a lot of frustrations with managing database migrations for applications and while migrations in Rails doesn’t solve them all it’s very nice to have something to use for managing this process.
- A lot of the common scenarios for domain objects have nice support. For example we have built in support for things such as tracking created on dates, treating a collection of objects as a list (or a tree), providing built-in support for tagging, and more.
I’m sure I could think of a lot more things that one could, or I should, dig within Rails, however that’s not really the point of this post. What has made Rails so successfull? Is it all these cool features? Is it cool editors like TextMate?
I think it’s the fact that Rails hasn’t tried to be everything to everybody. In desiging Rails David has embraced constraints. He didn’t set out to use every pattern in the book. He didn’t worry about trying to be a purist he focused on being pragmatic. Pragmatism is where it’s at.
A practical, matter-of-fact way of approaching or assessing situations or of solving problems.
Ruby on Rails has become very popular over the course of the last year. The popularity of Rails has meant very good things for TextMate which appears to be the text editor of choice for the members of the Rails core team. David (the guy who wrote Rails) recently posted on the release of version 1.5 of TextMate and encouraged those who haven’t yet converted to do so, even if it means picking up a Mac to run it on. As ridiculous as that sounds it looks like a lot of people have in fact decided to buy a Mac Mini so that they can do Rails on a Mac with TextMate. I don’t know about you but my favorite text editor isn’t quite worth the $500+ that is required to get a new Mac as well as a license for TextMate. Of course you could just get a Free Mac Mini instead.
PS: If your using TextMate checkout Jusitin’s Vibrant Ink theme.
For those in the .NET world that like the stuff that’s going on in Ruby on Rails land checkout the following Castle Projects:
Also of interest may be:
Inspired by those wonderful folks over at 37signals.
At work
- For programming I use VS.NET 2005
- Tools: CC.NET, MSBuild, Resharper, Reflector, CodeSmith, NUnit, Nant
- For text editing I use Notepad2
- For bug tracking we use our wiki (just migrated to FlexWiki)
- For version control we use VSS (hopefully not for much longer)
- For a computer I use an IBM Thinkpad
- For planning we use a Whiteboard + Index Cards
At “Home”
- For programming I use VS.NET 2005, TextMate, RadRails, and Eclipse (mostly VS 2005 )
- Tools: Resharper, Reflector, CodeSmith, NUnit, Nant
- For text editing I use Notepad2
- For bug tracking I use a pad of paper
- For version control I use Subversion
- For accounting I use Excel
- For web hosting I use Evenlink
- For instant group communication I use a mirror
- For designing logos and documents I use someone else
- For running this blog I use a homegrown CMS called ActiveType.
What do you use?
That’s right, my new hot rod is sweet!
Sad isn’t it?
Over the course of my software career I’ve worked hard to make myself a better developer. These 7 tips have helped me along my way. What tips would you offer aspiring software developers?
1. Read. Read. Read. Books are a great resource for gaining new knowledge, enhancing existing knowledge, and forcing yourself to grow into new areas. Although I’ve been lazy with my reading lately I think the books that I’ve read over the course of my career have greatly enhanced my ability to grow professionally.
2. Write lots of code. If you want to get better at something you need to practice. This applies to coding just as much as it does to anything else. As you work through problems you’ll learn new ways of doing things, realize how stupid you were in the past, and you’ll begin to see common problems and scenarios. Get coding!
3. If someone asks you a question that you don’t know the answer to find the answer. I’ve always made it a habit to find the answer to questions that colleagues have asked. If someone is asking you for the answer and you don’t know it there’s a decent chance it is worth knowing. Do a quick google search, or send yourself an email reminder to find the answer. Not only will your colleague appreciate you finding out the answer for them but you’ll also have gained some new knowledge that you won’t have to go searching for next time around.
4. Blog it up. Reading blogs as well as writing blogs can be very helpful to your career. By reading blogs you’ll keep a good handle on what’s going on in the tech world and be able to identify areas that you may need to increase your knowledge and skills. By writing a blog you’ll open yourself up to new opportunities. Obviously you need to be able to make the commitment to writing solid content but if you can make the commitment do it.
5. Remember that your job is to make the users of your software kick ass. It’s not to write some really snazzy class that uses all the latest language features, its about creating kick ass software.
6. Learn something new. Learning is one of the most important aspects to becoming a solid software developer. There is way too much out there to know it all. Make it a habit of learning something new. Whether it’s a new class, a new framework, or a completely new language. Just remember to continuously learn.
7. Read code. One of the things that I enjoy is checking out other people’s code. By examining how someone else solved a problem you often times learn new ways of doing things. I’ve checked out a lot of code and learned a lot of things from it. When someone posts a code sample, or open sources a project they’ve been working on crack open the code and take a look, chances are you’ll learn something new.