The Castle Project - Rails for .NET

The Castle Project is an interesting open source alternative to ASP.NET / ADO.NET. Among other things, the Castle Project provides a Rails-like development framework for .NET. It has an ActiveRecord implementation built on top of NHibernate, a very Rails-like MVC setup called MonoRail, and uses NVelocity for template style views. It's worth checking out. This screencast gives a bit of an overview.

There's tough competition around the corner though, with Orcas already in beta, providing XAML, LINQ and O-R mapping.

Is .NET or Java dying?

Are C# and .NET losing ground as Martin Fowler suggests? Or is Java's market share dropping? What about Ruby? And what about the Australian market in particular?

Here's what I've been able to find.


Job Trends
Which technologies have the most demand for people?

From Indeed.com, which claims to search "millions of jobs from thousands of job sites", but I suspect may have a USA focus:




"Best Talent Index May 2007" from Best People Solutions gives an Australian perspective:



Here's job counts from the (largest?) primarily Australian job search site Seek on 5 June 2007, 3pm (today):

Keyword(s)	Number of positions found
Java	3,414
".NET" or "dot net"	2,744
"c#" or "c sharp"	1,722
ruby	100

As an aside, I remember doing a search on Seek for "ruby" about 6 months ago, and getting under 20 jobs mentioning it.


Search Engine Number of Hits

Extract from the TIOBE Programming Community Index for June 2007:

Position Jun 2007	Position Jun 2006	Delta in Position	Programming Language	Ratings Jun 2007	Delta Jun 2006	Status
1	1		Java	20.025%	-1.10%	A
2	2		C	15.967%	-2.29%	A
3	3		C++	11.118%	+0.45%	A
4	4		(Visual) Basic	9.332%	-0.85%	A
5	5		PHP	8.871%	-0.72%	A
6	6		Perl	6.177%	+0.17%	A
7	8		C#	3.483%	+0.25%	A
8	7		Python	3.161%	-0.30%	A
9	10		JavaScript	2.616%	+1.16%	A
10	19		Ruby	2.132%	+1.65%	A

I think this gives a good idea of web buzz, but suggest that most non-IT companies do not publish information about their projects and chosen technologies and languages on the web.


Conclusion
The data collected suggests that:

• Both .NET and Java are major players in the job market with thousands of positions advertised, implying wide industry adoption of both.
• Neither .NET nor Java seem to be undergoing any significant decline in jobs.
  
• Java has much more information about it on the internet, although .NET is slowing gaining ground and Java slowly losing it.
  
• Ruby is comparatively tiny but growing rapidly in terms of jobs and information on the internet.
  

Thanks
Thanks to Jason Yip and Suzi Edwards for their help finding/sourcing information.

Using floating point variables to represent money => not a good idea!

I was reading through some code the other day and was surprised to find that it was using doubles to represent dollar amounts. Reason for the alarm bells is that doubles and floats cannot accurately represent many decimal fractions (eg, 0.1), since doubles and floats internally work with powers of 2 rather than powers of 10. These inaccuracies are likely to lead to significant errors, especially when performing arithmetic (eg, adding up a table of dollar amounts). See this IBM article for a more in depth explanation and examples. The solution is to use types that work with powers of ten internally. In C#, you can use 'decimal' and in Java or Ruby, 'BigDecimal', to avoid these problems.

AntiPattern: BusinessObjects in the driving seat

When you have a rich domain model with a business object centric design, and a Windows forms GUI, it can be very tempting to start putting significant process logic in the business objects. After continuing along this path a little further, you may realise that the process needs some sort of user input, and you use events or some sort of notifier pattern to gain user input required by the process, while still maintaining layering in terms of referencing. Then additionally you may need to access some sort of external service.

Here is an example:

class Order : BusinessObject
{
 public void SendOrder(INotifier notifier)
 {
   if (ReadyForDelivery ||
       Confirm("Are you sure you want to send order lines?"
             + " They are not ready for delivery."))
   {
     OrderLine[] orders = GetLinesToSend();
     foreach(OrderLine line in Lines)
     {
       SendLine(line); // send line using a web service?
     }

     Notify("Lines sent successfully.");
   }
 }
}

interface INotifier
{
 void Notify(string msg);
 bool Confirm(string msg);
 OrderLine[] GetLinesToSend();
}

I would like to suggest that this is an anti-pattern and a trap. Although there is no direct reference from the Business Layer to the GUI layer (INotifier is implemented in GUI and passed down), the Business Layer now requires the ability to stay instantiated, pause while waiting for responses from the notifier, and then continue execution. This will work for rich client applications, but not in a stateless web environment. The ideal of being able to swap in/out the GUI layers on top of the Business layer is now compromised.

Instead, it would be possible to drive form the GUI layer, and call a service to send the Order Lines. In pseudo code below:

void SendMenu_Click(...)
{
 if (Order.ReadyForDelivery ||
     MessageBox.Show(...) == DialogResult.Yes)
 {
   using (ChooseLineForm chooseLineForm =
            new ChooseLineForm(Order))
   {
     chooseLineForm.ShowDialog()
   }
   SendingSevice.SendLines(chooseLineForm.selectedLines);
   ...
 }
}

If the logic in the GUI layer became much more complex, it may be a good idea to pull it out into its own class (eg, LineSender). This class would be a type of GUI level controller, responsible for orchestrating the send process.

Using this approach, there are a number of benefits:

• BusinessObjects have no reliance on GUI implementation, so can be used for Rich Client and Web Client indiscriminately.
• Web developers are free to implement the user input process in stateless way more appropriate to their platform.
  
• Functionality for sending Order lines (some sort of integration with a web service?) is pulled out into a service class which can be reused elsewhere (potentially sending other types of objects?) and unclutters the Order business object and removes its dependency on an external service.
• Code is simpler and easier to follow.