Today I attended the Web Developer Makeover seminar put on by the gents from SoftiesOnRails. Both Jeff and Brain did a fine job of covering as much information on both Ruby and Rails that you can possibly muster for 12 hours on a Saturday. It was interesting being singled out as one of the Microsoft guys almost immediately (due to a slight snafu of running Ruby on Vista; turns out it was a Ruby configuration problem and not a problem with the OS). Joe Stagner from the DevDiv team in Redmond was also there.
I didn’t mind being singled out. I’m actually quite happy I was. It prompted some of the attendees to ask some great questions about Microsoft and the “So… why are you here? What do you hope to get out of this?” questions, completely in a non-confrontational way, of course. Believe me, if someone wants to have a religious conversation about programming languages, OS or Hardware, I move on my marry little way onto more important things I want to spend my time on. But, the question was a valid one. I was like every other person in there. I wanted to learn more about Ruby and Ruby on Rails. In my job I get the incredible opportunity to talk toa lot of developers. When Ruby/RoR comes up in a conversation, I want to make sure I can contribute in an educated fashion. I also want to understand what the allure is with Rails and try to understand how we can enhance our products to cover areas that we may be missing. I am quite disappointed that I forgot my Rails logo’ed mug that was given out to each attendee. I can rest any conspiracy theories in that the Microsoft guy wouldn’t take a Rails mug with him – he was just an idiot and forgot it.
One of the conversations I had with some of the attendees was how easy and productive Rails was. My comment was ASP.NET was easy and productive as well. The rebuttal was that ASP.NET was not. My counter rebuttal is in it all depends on what you’re trying to do, and that goes for both technologies. RoR certainly has it’s place in building web applications. So does ASP.NET. I have a feeling that people are being led to overly complicated ASP.NET “best practices” for the things they are trying to do. They turn to RoR because it’s “easy and productive”. I’m sure it is. But RoR has its faults just like any other programming language/framework. ASP.NET does as well. The thing to realize about ASP.NET is that you have many different ways to build your ASP.NET application, you just have to pick the best architecture for you and your application. Visual Studio .NET provides some facilities to create quick and dirty applications. That doesn’t mean it’s the best architecture or implementation for you. Take the scaffolding process in Rails. Same concept.
What I want to do is a) find out where we can improve our web development message and show the “easy and productive” parts b) become more acclimated to technologies like RoR and PHP to get a better understanding on what the pluses/minuses are compared to our technologies c) try and help deliver the message for both a and b.
There was a couple of links that I was discussing with some of the attendees today. The first isLINQ and the new language enhancements coming in Orcas. The second was is Blinq. I have to admit that I haven’t had time to dive into BLINQ just yet, but its something the RoR developers might want to keep an eye on. Also, check out Scott Guthrie’s series of articles on LINQ. These all provide some great insight into where we’re going. Hopefully we’re making improvements in both the languages and tools that’s going to continually lead to easy of use and developer productivity.
The class was great. It was a great opportunity to meet some new people who I wouldn’t have normally met and it’s always a great opportunity to hear how Microsoft can improve. Jeff and Ben didn’t have a formal eval form, they asked us to do what all good Web 2.0 users should do, blog about it. A couple of items for you, Jeff and Ben (all minor, but important)…
1.) Print out your slides and make them available or create a soft copy and handout to class prior to the start of the class.
2.) Create hard copies of your hands-on portion of the class and break up the class to include lab time. It was slightly difficult to follow Ben and his lightning fast fingers, especially when we missed a crucial piece or encountered an error. I know it’s difficult to take even more time away from the class to include lab time, but not impossible.
All in all, a great way to spend some time on a Saturday, Riding the Rails. Thanks, guys!
Dave Bost is a Technical Evangelist for Microsoft and co-host of the Thirsty Developer Podcast.
