Friday, January 16, 2009
#
So I was at CodeMash last week. The first thing I did at the pre-compiler was go to the Ruby 101 session presented by Jim Weirich and Joe O’Brien. The way the session worked was that they gave people everyone project code which contained a customized unit test suite that would stop running at the first failure and a set of unit tests that were all failing. Each test was intended to teach one aspect of the language.
I have to say, I thought it was a great way to learn a programming language. It got me reading, modifying and writing my own quickly. It’s a pretty novel idea in my opinion and it worked really well. It was definitely worth heading down to Sandusky a day early. Expect to see me at CodeMash and the pre-compiler again next year.
Anyway, from the perspective of someone who has worked in C# basically my entire professional career, learning Ruby is a big change of pace. After I finished the unit tests that Joe and Jim had prepared for the Ruby 101 session I started working on the “extra credit” they provided, which was to implement a version of the game Greed.
As the post suggests, ruby is weird. Take this code, for example..
turnNumber = 1
until last_turn?
single_turn turnNumber
turnNumber += 1
end
Let’s see.. I created a variable without specifying a type or even var. I’m using a control flow statement called “until”, a question mark in a method name, two method calls with no parentheses and no semi-colons or curly braces. The same thing in C# would look something like
int turnNumber = 1;
while (!IsLastTurn())
{
SingleTurn(turnNumber);
turnNumber++;
}
Obviously ruby’s syntax doesn’t get as hung up on ceremony as C# but that’s not what’s really interesting about the language to me.
What I find really interesting is the way that classes and methods work in ruby. The method_missing allows some really interesting behavior. While I think RhinoMocks is a great piece of software, it seems like it would be pretty trivial to write a mock in ruby. And you don’t even need an interface.
Starting to learn ruby has reminded me how much I enjoy learning a new language. I' think I might start playing with ruby on rails. As a professional web developer, I feel like I’m missing something but not knowing much about rails.
If it’s as great as everyone says it is I need to learn it so I can steal as many ideas as possible.
Tuesday, June 24, 2008
#
I can't quite remember what possessed me to do so, but I started testing Resharper recently. A lot of .NET engineers are familiar with Resharper and/or CodeRush/Refactor!. It seems that both products have a loyal following.
So my trial of Resharper just ended. What are my impressions? It's great, actually. Since my trial ended and I haven't purchased the product (more on that later) I've really missed Resharper and it's instant feedback. The product's two best features are live compilation and markers in your code to let you know about tips, suggestions and warnings. There's also a bar along the right side of a code file that shows where in the file there are problems or tips on how to improve your code.
So why didn't I buy the product? I've heard a lot of good things about CodeRush as well and wanted to give their product a try before dropping my hard earned cash on Resharper. I actually saw someone (sorry, can't remember a name) demo CodeRush and Refactor! at last year's Ann Arbor of Day of .NET. I was intrigued by the product. If you haven' seen it the UI for CodeRush is pretty impressive. It includes a lot of animations and effects that are intended to make it easier to visualize things.
So I've started working with CodeRush and Refactor! So far my experience is positive. At first I didn't particularly care for them. Resharper's main advantage is obvious. As soon as you type some code with any of the problems that Resharper can point out you will know. CodeRush isn't quite as approachable in my opinion, despite the animations.
A great feature of CodeRush is CodeRush's much improved version of code templates. As an example, if I wanted to declare and initialize a list of integers I could type nl.i followed by a space to produce List<int> list = new List<int>();. That definitely saves some typing. nl.b would turn into List<bool> list = new List<bool>(). There are verbs such as n (for new instance), p (for property) and then you can apply those to various types. It's really quite slick.
Anyway, my main point wasn't to argue for either of these products. I'm currently undecided about which of the two products I would rather purchase, so I can't really advocate either one of them.
What I'm getting at is that if these kinds of tools can really make developers more productive, why aren't we all using them? On a regular basis I spend $60 on a new video game. For a $60 videogame I would hope to get 20-50 hours of playtime. On the other hand, every single week I spend dozens of hours in Visual Studio .NET. Yet it's much harder to convince myself to spend the $150 on Resharper or the $250 on CodeRush/Refactor! than it is to buy a few video games that I won't spend nearly the same amount of time using.
This seems like a problem, and I'm going to try to fix it. Once I decide which one I like the most I'm going to get myself an actual copy of Resharper or CodeRush and make an investment in making myself more productive. Hopefully it pays off.
Tuesday, February 26, 2008
#
I mentioned Linq to SQL in a previous post and from that post it probably sounded like I wasn't a fan. For creating business objects I'm not sure if Linq to SQL is a great solution. Linq to SQL isn't very flexible when it comes to configuring your mapping. Plus there's the general uneasiness I've been feeling with ORMs lately.
When it comes to LINQ on the other hand, I'm a huge fan. I've been working on a couple of things that are written using .NET 3.5 and the times that I've gotten to use LINQ I've come away really impressed. So far I've had the opportunity to use Linq to SQL, Linq to XML and Linq to Objects and all of them are great technologies in my opinion.
LINQ to XML makes reading simple XML documents completely trivial. I was going to post an example of how you could read in a collection of objects, and even populate collections on those objects using a sub-query using only a few lines of code, but then I realized there's no sense doing something Scott Guthrie already did much better than I could.
LINQ to Objects is big too. LINQ to Objects doesn't do anything that you couldn't do by writing your own loop, but it allows you to do things in a much more concise and more importantly, readable manner.
Let's say I have a collection of Account objects representing bank accounts and I need to print out a list of reports that are older than a year and report some statistics on those accounts and sort the list:
decimal averageBalance = 0;
decimal averageTransactions = 0;
List<Account> oldAccounts = new List<Account>();
foreach (Account account in accounts)
{
if (account.AccountOpened < DateTime.Today.AddYears(-1))
{
averageBalance += account.Balance;
averageTransactions += account.Transactions.Count;
oldAccounts.Add(account);
}
}
averageBalance = averageBalance / oldAccounts.Count;
averageTransactions = averageTransactions / oldAccounts.Count;
Comparison<Account> sortMethod = delegate(Account a1, Account a2)
{ return string.Compare(a1.Name, a2.Name); };
oldAccounts.Sort(sortMethod);
Or we could do the same thing with LINQ:
var oldAccounts = from account in accounts
where account.AccountOpened < DateTime.Today.AddYears(-1)
orderby account.Name
select account;
decimal averageBalance = oldAccounts.Average(a => a.Balance);
decimal averageTransactions = oldAccounts.Average(a => (decimal)a.Transactions.Count);
Which of those two blocks of code would you rather write or have to maintain? The LINQ version saves several lines, but more importantly, it's much more readable. The easier code is to read the faster someone modifying the code can understand it and be ready to make improvements. To me this is the real value of LINQ. It's ability to create extremely readable and flexible queries.
I think it's going to be important for every .NET developer who wants to stay on top of their game to have a solid understanding of LINQ, extension methods and predicates going forward. These concepts are very different from what the average C# developer is used to but they can really improve the way they work, so any developer who can incorporate the new technologies in .NET 3.5 into the way they way they think about code is going to be at a big advantage.
Monday, February 18, 2008
#
As most developers do (I would hope) I think a lot about the best tools for getting my job done. I’ve been really interested in ORMs lately. Linq to SQL is really exciting. ActiveRecord is really easy to get working. Nhibernate seems to be the most full featured (as long as you don’t care about stored procedures). The Entity Framework seems like it might be the best of the bunch. But of course, there is always the option of doing data access the good old fashioned way with ADO.NET calls.
So what’s the right tool for the job? Linq to SQL’s big advantage is Linq. ActiveRecord is really easy to use and more flexible when it comes to the types of relationships that it allows (basically, it allows many to many relationships). Nhibernate is very flexible and I understand Linq support has been added recently. Entity Framework, unfortunately, hasn’t actually been released.
But Linq to SQL, ActiveRecord and NHibernate are all fairly similar. They allow you to map your database tables directly to objects. If your Customers table is related to your Orders table you can just add a collection of Orders to your Customer object and a Customer object to your Order object, and it works like magic. And all three of those technologies will produce nice clean SQL for accessing those two tables.
But what happens when you go from a few tables to a few dozen tables? If you aren’t extremely careful when creating your objects you can find yourself in a performance nightmare. You get your Order object and that automatically gets your Customer object, which automatically gets your CustomerAddress object and your CustomerPreferences object. And the only data that you wanted to get was the Order itself.
So a fan of ORMs could argue that such a situation would only arise from poorly planning your objects. Fair enough. But here’s the problem I have with ORMs. It’s not just that it is possible to do things the wrong way and kill your performance. ORMs actually encourage you to do things this way. ORMs make it really easy to shoot yourself in the foot.
This relates to something else I’ve been thinking about a lot lately. I frequently read Ayende Rahien’s blog and he was talking about how a project should be setup so that it is easy for a developer to do the right thing. I think ORMs do the exact opposite. I’m starting to think that they make it too easy to do the wrong thing.
Friday, February 08, 2008
#
Okay, maybe I do know C# a little bit. In fact, I think I'm fairly decent at it. But I've got a lot to learn. I don't even know all of the language features of C# it seems, and that's just the language. There's also the entire .NET library and the countless third party libraries to learn about.
But what made me feel like a newbie recently was somethig I read on a link from Scott Guthrie's blog yesterday morning. I was checking out one of his regular link posts. One of the posts that caught my eye was The Power of Yield by Joshua Flanagan. Yield is a cool feature that allows you to write a method that returns IEnumerable or IEnumerable<T> and the method will execute as you are enumerating through the list instead of building the entire list first and then returning it and enumerating through it. And it will only run the method until you stop enumerating through the list. I'm not going to write a demo because the post above already has an excellent demonstration. But it's a very cool feature of C#.
The fact is that before I read that post I was completely unaware of the yield keyword in C#. I always try to keep up on the new features of the language and the framework but I miss things. I don't see how anyone could keep up with all of it, though some people certainly seem to always be on top of the latest developments.
It makes me wonder, how much of the .NET framework is the average engineer really famliar with? My guess is the average developer is familiar with less than half of the classes in the .NET framework. I've been working with ASP.NET my entire professional career but there are still a number of built in ASP.NET controls that I've never used. I'm competent when it comes to WinForms but to do anything advanced I'd have to have to do some serious research. I haven't even started digging into WPF yet.
So while most of my blog posts will be about about sharing knowledge, I thought I'd start by commenting on how much I don't know.