I’ve officially left Enovation Solutions as of 1700 on Friday, and as of 0900 on Monday, I go to work for dotMobi as a senior software engineer, to work on some more technically-oriented stuff. More specifically, I’m working with Andrea Trasatti on the new Device Database project announced recently (more here). I’ve been trying to get into more and more technically demanding roles over the past two years, but I’ve always been split between sysadmin and development roles; I still like both sides of the house, but it’s going to be interesting pursuing the development side alone for a little while, especially in this area, where I’m basicly writing tools for other developers.
Not a fan of the name. But, I’ve got that X server memory hole in Feisty on my machine and Gutsy supposedly has the fix. Tried it at home last night on my dual-booting laptop (XP and Feisty until last night). Insert CD, reboot off CD, let it run.
Perfect installation. Haven’t had time to play with the neat cool 3D stuff yet, but the successful autodetection and the full setup was very impressive, especially compared to the bad old days when autosetup was a fast way to lock your machine up or worse, but nothing more! Have to say, I still like Debian for servers, but for desktop machines, I’m sold on the Ubuntu model. I don’t install my desktop often enough to become an expert on the process, so an idiot’s interface is a good thing for that for me. On a server, it’d be unacceptable but that’s a different gig alltogether. And the degree of polish is nice as well. There’s something very satisfying about pointing to your desktop as being more bling, bling than a windows users’ and also knowing that it’s a stable unix system underneath. It’s no wonder people love Macs these days.
On a seperate project from the PEAR work I’ve been doing of late, I’ve just rewritten an earlier project to use the Prado framework. I spent some time a while back looking at various frameworks, and in the end came down to a choice between Symfony and Prado. Because of the way this current project works, I thought Prado’s event-driven model was an easier fit than Symfony’s MVC model. Mind you, for other projects (including the one I was using PEAR for), I think Symfony would be ideal (and I didn’t use it earlier only because of time pressure).
Happily, the front-end of the project I was refactoring into Prado had no work done on it at all (the previous version was effectively a proof-of-concept with all the work in the back end). Still though, if I had to do it over, I’d probably quote an extra week and rewrite the whole thing from scratch using ActiveRecord instead of the custom database interaction I had in this version.
Some of the stuff in Prado isn’t quite as optimal as I’d hoped, mind. For example, nesting templates in Prado doesn’t work fully in that if you have Template C nested in Template B nested in Template A, then a variable in Template A is not visible at all to Template C, and the code attached to Template C can’t change it. So you have to have a TContentPlaceholder in Template A and a TContent linked to that in Template B, containing a TContentPlaceholder which a TContent in Template C links to and that TContent in Template C contains the actual content. It’s suboptimal and messy, because you’re effectively doing inheritance on a pseudo-object by hand, and typos can waste lots of your time, not to mention the headache of keeping it all straight as you code.
And there’s no tree control. And there’s no built-in menu control (though that is up for the next version to be fair, but still, it’s a right pain in the touche to code a fake menu using and CSS, and it’s such a basic kind of control that I thought it bore mentioning in a complaint!).
However, little bits like this are, in the end game, just niggles. Compared to trying to do what Prado does for you out of the gate, you’re light years ahead of the curve when using the framework. Yes, I know, that’s a well-established fact for frameworks and noone’s learning anything new from it, but I thought I’d just point out that it holds for Prado and that Prado’s approach of an event-based model as opposed to an MVC model means that it’s a more comfortable fit for something with a lot of user interaction like the last project I was on.
I mean, for an example, you can build your pages in Prado with no backing PHP code whatsoever, show it to the client for a scratch-n-sniff test, and if it gets their okay, you go code it up; if not, you edit what is pretty close to HTML code and try again. Very fast turn-around that way.
I’m looking forward to v3.1.2 and the new tree/menu control, and once that comes out, I’ve got that little RCMS project I’ve been meaning to write for a few years now that should make for a nice little testbed…