Archive for September, 2006
Ivan Porto describes how he was getting crazy with WebForms when he decided to take another look at MonoRail. This time he “got it”:
Anyway my problem is that to do something that is more complex than just simply displaying one form on a page asp.NET gets pretty complicated. Events are firing all over the place. I have to take viewstate into account. (I turned viewsate off because it was about 50K half way through my app.) And then it became even more difficult to get stuff to respond the way I want them to respond. All in all it takes a really long time before I get something done properly. Where all it is actually doing is rendering small portions html out to the browser.
For me it was very difficult to admit that all the time I’ve spent studying WebForms by myself (and writing a book about it!) was down the drain after facing a medium complex web site. It took some minutes to get down the high horse and admit that the programming model was flawed. WebForms is amazingly good to get “developers” to build something without not much knowledge about the framework and I dare to say the language. MonoRail is not that simple, and I’m not sure it’s a bad thing. But it does require a programmer to think. At the same time it imposes some constraints so the developer can get things separated, and that’s the whole point about MVC.
Well enter the castle project. I looked at it before but never really saw the point. Yesterday I got down and dirty with it and let me tell you I DO see the point now. The way they built their framework resembles very closely how I was going to build ours. It provides a more natural way of creating webpages in my mind than trying to force a winform programming model into a stateless model. Not to mention the speed in which you get things done.
That’s the interesting aspect. Rails and MonoRail does not bring anything new. The shift is “back to simplicity”. While others are introducing lots and lots of layers, continuation and hard to grasp concepts, MonoRail paradigm is “stop! it doesn’t have to be that complex. You shouldn’t have to write that many repetitive code. You shouldn’t have to write that boring error prone code to bind form data to objects”.
If we were on Java world I bet we’d have plenty more users. But in the MS world people are just too afraid of leaving the standard way of coding applications. Hopefully this mindset will change in a near future, for the sake of .Net open source community. It would also be a good thing if MS stopped competing with open source, but I wont start this flame again.
On a somewhat related post, Josh starts an explanation on IoC and wonders if he’s late on start using it. I started using IoC on my Java programmer days back in 2002, and I thought I was very late at the time. :-)
Once upon a time I started to advocate the usage of IoC as I really believe in the concept and especially believe in MicroKernel architecture. Today I don’t do this anymore. Not because I ceased to believe in it, just because I’ve seen (and read mostly) people that weren’t prepared, didn’t get the concept, didn’t understand the problems IoC attempts to solve trying and failing to use it. If IoC didn’t spark for you any attempt to embrace it will be a headache, a waste of time and neurons. If you really want to embrace it, though, start with small projects or pet projects. I also recommend that you review projects that use it. For example netBpm and NProject.
Oh, and Josh mentions Mr Folwer article on IoC. In my not so humble opinion, mine is much better ;-)
Marc-AndrÃ© Cournoyer is a damn good hacker. Check his latest addition to his Generator project. I’m seriously considering dropping the “official” scaffolding support, and direct the users to the brand new Generator.
I’ve also checked the Streamlined last saturday. It’s cool but requires some aid. It’s fair as it cannot infer all you want from the scaffold support.
For those asking, demanding or just wondering, I have to honestly say that REST will not be part of MonoRail 1.0. The next version spiking should start shortly, though, and RESTafarians are welcome to lead the support implementation.
The reason for declining on the support for this version is simply: there’s too much to do already. Introducing a complex support would require time to mature, delaying even more the 1.0 release.
The funny thing is that REST is a hot topic everywhere, but not for MS plataform developers. But it will certainly turn into a hot topic whenever MS announces Microsoft REST Library. I can even imagine the package of UI Control giving your webforms REST semantics/support [sic]. That’s the weird thing on being on this side of the force…
Given this class declaration:
public class Some<TKey> where TKey: IComparable<TKey>
public static int Added;
public void Add(TKey k)
And the following usage
public class Driver
public static void Main()
Some<int> intSome = new Some<int>();
Some<string> strSome = new Some<string>();
What would be the output? Just a tip: check the C# language spec.
public class AdminController : SmartDispatcherController
public void Index()
public void DisableUser(int userId)
// Do something important here
public void ChangeUserPassword(int userId, String newPassword)
// Do something important here
Then on the view side, you include a call to GenerateJSProxies
The GenerateJSProxy call will generate a js block that uses Ajax.Request to make a remote invocation. Something like
var r=new Ajax.Request('/admin/DisableUser.rails',
parameters: '_=\x26userid=' + userId,
if(!callback) return r.transport.responseText;
function(userId, newPassword, callback)
var r=new Ajax.Request('/admin/ChangeUserPassword.rails',
parameters: '_=&userId=' + userId + '&newPassword=' + newPassword,
if(!callback) return r.transport.responseText;
As you see it supports synchronous and asynchronous calls. If you specify a callback function it will be asynch, otherwise synchronous. The use of the remote method becomes natural js code:
Ain’t this cool or what?
I’ve just watched this documentary and can’t help feeling shocked. I don’t think the movie was about the good guy vs the bad guy, instead about the censurable, despicable methods used, the transgression of laws, the use of police and fire department in politics activities. I can honestly say that Brazil is way more advanced on elections than US, maybe even – I dare to say – the rest of the world, at least regarding casting votes and couting them. It’s all eletronic, secure, reliable, fast and fault-tolerant. We have the results of an election in a couple of hours. You can even download a java application and watch and query the results being calculated. It’s fun.
The biggest difference is that here we are obligated to vote. Kinda of “enforced” democracy.
After writing a few tests cases for MonoRail’s ActiveRecord Integration using Watir, the only thing on my head is: why I haven’t used this before?
Starting with it is easy, although it could be made easier. I’ve installed it using Ruby Gems, and following the tutorial does not mention that require ‘rubygems’ is, well, required. Fortunatelly I’ve worked with Ruby in the past so that was easy put it together. Automating IE is nothing new. What makes Watir good is the simple API combined with the niceness of Ruby. It’s easy to navigate the dom, work on elements, populate forms, although there’s some missing things. For example, I couldn’t find a way to assert that some checkboxes were checked.
The API is so small that become easy to master it in a few minutes. There’s also a bunch of interesting assertions on Watir::Simple module, but I couldn’t use it for some reason and didn’t try hard, I confess.
If you’re wondering about trying it, don’t make the same mistake I made, try it now.
Update: Nick has kindly sent me an email showing how to test a checkbox state:
class CheckTest < Test::Unit::TestCase
$ie = IE.new
$ie.goto(Dir.pwd + '/demo.html')
Joel’s latest post is a gem. Of course, some people didn’t like it at all. Anyway, Dave Thomas (the pragmatic one) said something on the same lines not very long ago: the best tool for the job is the right one.