« May 2009 | Main | August 2009 »
Excellent article about Parrot, by Allison Randal.
Parrot’s record for a language implementation was a conference session where the speaker implemented the basics of the LOLCODE language from scratch as a live demonstration. It was a 5-minute lighting talk.
I have to get the time to implement a DSL for something on top of Parrot, to see how it works. Right now I only compile Parrot to run Rakudo.
Yesterday I saw a question by fREW Schmidt regarding where to place the validation code in your apps. I made a mental note to answer it, but as most of my mental notes, it was quickly forgotten.
Today, a new article describes the answer he got. In the end he decided to put the validation inside the model. I can only say: good for you.
But one of the reasons against the validation-inside-the-model that he received baffled me: Models don’t know about the current user (or other higher level information).
If your models don't know who is the person authenticated (and please read Yuval article about modelling identity to understand how complex it can become), then you are doing it wrong.
Models must know who is the authenticated user. They must know it because that is the only sane way to implement authorization inside your methods, and to generate a audit log of operations.
What I usually do is to create a Session class. For each request (be it Catalyst request, incoming email message, or XMPP request), I create a new Session instance initialized with the current user information plus some tidbits like channel (Web, email, XMPP) and IP address (if available).
Then all accesses to my API are either via the session object (create methods to access most important parts of your API), or by passing this session object to the API you are calling.
You should also use your Session as the access point to your logging and auditing capabilities.
The article mentions other issues like error messages. I haven't add the necessity of developing an application with multiple language support yet, but I think that the current throw-exception-objects strategy, with all the information (including the authorized user to figure our preferred language) will be able to deal with the problems that I can think of now.
In the end, I'm actually really curious about why would people think that putting your validation code in the controllers is a good idea.
Update: a lot of stuff in the comments if you care about this topic.
I like to tinker with hardware, specially old servers.
I spent an hour upgrading our office server this morning. In a world of Ghz speeds, be prepared to slow down a little.
The server was a dual-pIII (yes, Pentium III, Katmai generation) at 450Mhz (yes, mega) with 512Mb RAM (at 100Mhz, in 4 DIMMs). The upgrade replaced the CPUs with a pair of pIII 500Mhz (a 11% increase, not bad), and the memory to 1Gb at 100Mhz. Basically thats the best you can hope for with this Intel N440BX (aka Intel Nightshade) board.
I don't have the full specs for either of them but I would guess that the CPU inside the new iPhone 3GS is a little faster than the pair of pIII I'm using.
The obligatory Flickr set for enthusiasts of old hardware porn.
I also uploaded a small video showing the hardware boot up, but had to use Vimeo because Flickr limits video uploads to 90 seconds, and this server takes a bit more than that just counting the RAM...
I bought this server in 1999, to power the NFS server for the first launch of the mail.pt service. It was handed down through the times, from company to company, until it belonged to me after the demise of Prodigio. At the time it used two Mylex SCSI RAID controllers (I still have them, one of them in production) with 4 x 9Gb SCSI hard drives on each.
I have a quote for a €390 upgrade to a Core 2 Quad 2.8 Ghz with 8Gb RAM. I plan to do this sometime next month. But this old office server will not die. It will power a smoke server to test Perl modules with several releases of FreeBSD.
Are you ready to be an Iron Man? Join the challenge and find out! (what is the meaning of this little man?)
