« June 2009 | Main | September 2009 »
This are the rules I use to do the upgrades between major versions of Mac OS X.
You upgrade when:
I usually wait until the last item is true before doing the upgrade.
I have a love/hate relationship with Template systems for quite some time. The following is a brain-dump about where I stand right now regarding which system to use in the E5 project.
When I started using them at work (circa 1998 or 99) the goal was simple: separate programmers logic from the layout so that designers can tweak the templates without breaking the code.
It was a simple and very worthwhile goal. And for the most part, it worked. You still need to coordinate which templates will be created, and how will the page be broken up into pieces to enable reuse of common parts, but it mostly worked.
The template systems where designed to be used by web designers, and given that those where accustomed to HTML tags, the more powerful template system that needed loops and decision constructs opted to create those with a simple syntax. The template systems became domain specific languages (DSL).
But, with the improvement of the HTML, CSS and JS capabilities, I don't know if the designers are still the target audience of template systems. As I split a set of HTML pages into a set of reusable templates, I try to create blocks that make sense in terms of caching, data-store life cycles, and other subtle factors that a web designer just doesn't care about. The page breakout is becoming a engineering exercise.
As programmers/engineers, we don't need the comfy world of a DSL. We want to work in the same language that we use to code. Templates are, at most, a small macro language that gets compiled into source code, in the same language that we have the rest of the system.
So I'm starting to move away from Template Toolkit, my preferred template system, into something that uses native Perl as the DSL. I don't know where I'll end up yet. I'm looking at Tenjin, Text::MicroMason, and Mojo::Template. There aren't many template systems that use Perl as the control language, actually.
The first two should be the most stable ones, older ones. Tenjin is also the fastest template system I've tested, although speed wouldn't be a deal breaker.
But we can't judge template systems without considering where and how they will be used. In my case they will the last step of a web request, handled by a web framework.
I'll use a BBC site page to illustrate my current dilemma, an article about Wikipedia page controls. Things of interest to me:
The path for a typical request (like /2/hi/technology/8220220.stm) looks like this:
hi/low part to pick the version of the master template, the category (controls the right-hand side column) and the article ID;Pretty basic and straight forward. Steps 1, 2 and 4 don't pose to many questions, they are required on any pipeline I can think of.
But the proper way to do 3 is a matter of discussion. On one hand you can put enough information on the URL to decide what the right-hand sidebar needs and fetch it in with some calls inside the Controller (I'm assuming here a MVC-style framework). In this model the controller prepares everything that we need to display the page.
But this makes the view a bit inflexible because if we need to had another box the top or bottom of the page, we would need to tweak the controller code.
On the other hand if our template system is powerful enough, we can have a small API that we can call back into Perl land, and have these little reusable boxes generated for us. The view controls the entire process of display.
The advantage of having a decent view system, even a object oriented view framework, is the extensibility that you get. Imagine a Moose-based template system: view are classes that you can extend, override, add before and after processing. Rendering is just creating an instance and calling a small method, as_string() or even stream_to_socket().
A system that brings the full power of Perl to the template world is Template::Declare. It treats templates as classes that you can subclass and extend. It seems very similar to what I like but I have zero experience with it so far.
No decisions have been made yet. I need to evaluate Template::Declare and see if it really fits my brain.
A beginning is the time for taking the most delicate care that the balances are correct.
from Manual of Muad'Dib by the Princess Irulan
extracted from Dune, by Frank Herbert
In the next weeks I'll be publishing a series of articles about a new project that I'm starting. Actually, I started this project once already, but I didn't like the path it was taking, so I'm restarting it.
The new system will replace the current EVOLUI.COM code base. Why rewrite a system that is in production for 8/9 years and that works reasonably well? There are several reasons actually.
The first reason is code rot: the current system is spread across 3 code bases (called internally E1 through E3). E1 was the first stab (who would guess, right?), and grew organically inside the company, without much planning, and coded by several programmers. E2 added a better management interface, and E3 added a new LMS and forum system.
A lot has changed in the last 8 years. And my inexperience in certain topics shows by the lack of proper tests and documentation. Also, it has grown to 850 Perl packages. Yes, eight hundred and fifty packages. I expect that more than half of those are no longer in active use.
The second, and more important reason, is that the new business requirements require a deep restructuring of the code, but given that we don't have a decent test suite, it would be madness to change stuff in one of those 850 packages.
The way I see it, I can write the new system properly, using a test-driven methodology, making sure that all the business logic is properly tested.
I'm not starting from scratch, I plan to reuse certain small but critical parts of the old system, but going over them to add tests and documentation.
The failed attempt was called E4, so this new version will be called E5.
I plan to cover the following topics (not sure of the order yet):
Hope you enjoy the ride.
Today the sky was blue, without a single cloud. The kind of day that turns this little town into a small oven.
But at the place where I usually do my mid-day walk, near the see, there was a strong wind, blowing from north-west.
Just perfect to stretch the legs, listening to some music. Must find some time to go back there today.
The biggest advantage of having my own business with my wife, and having a site that uses laziness as a design principle (everything should be automated) is the possibility of taking about 8 weeks of cool-down time with the kids.
Thats what just happened around here, and I'm slowly returning to work.
Are you ready to be an Iron Man? Join the challenge and find out! (what is the meaning of this little man?)
