There are many template engines available for Python already; Mako, Tenjin, Evoque, Cheetah, etc.
Unfortunately, many of these do not support Py3k, and of the ones that do, none of them were building their template objects the way I felt it should be done: by using python’s AST [abstract syntax tree] objects directly.
So, I wrote Suba.
Any of the template engines worth their salt use the text template to create a python program, then compile that program to byte code. The byte code is typically cached, and exec() is used to run it for each rendering request. Outside this central theme are a few variations; some of the systems generate a module (instead of just a script) and then import it rather than exec(), some cache to disk, some to memory, etc.; but, none of them create an AST.
The difference in using the AST is that there is no initial text stage; the language objects are instatiated directly.
For instance, the following template in Suba:
Hello, %(name)!
Would produce the following AST tree (some arguments omitted for brevity):
FunctionDef(name='execute', ..., body=[
Expr(value=Yield(value=Str(s='Hello, '))),
Expr(value=Yield(value=Name(id='name')),
Expr(value=Yield(value=Str(s='!')))])
When combined with a post-process walk of the AST, this allows you to tune and manipulate the code generated from a template with precision that you can’t get when using code-strings. (As an aside: the python-savvy have noticed that all templates become a generator, the wiki has some discussion about why this works well).
For instance, suppose you want to filter whitespace from the output. We could wrap the output in a whitespace filter,or, we can walk the AST tree and edit all the Str() nodes before the code even compiles. So, when we cache the compiled bytecode, it doesn’t even contain the instructions that would emit the whitespace, meaning that we get this additional feature along with a reduction in run-time. This is something that would be very difficult to do quickly and cleanly on a code-string using regex and string.replace().
This produces faster templates than the fastest competitor libraries (at the moment, the pool of Python 3.0 supporters is small enough for this to be true).
Here is an example, using Tenjin’s own benchmark templates and data:
tenjin_test: 2864.37 pages/sec (in 3.49 seconds)
suba_test: 5801.79 pages/sec (in 1.72 seconds)
CEO Ben Elmore’s second installment of his four part series on building a a Flex Team was recently featured in InsideRIA. Read it here!
In our last post, I made the case for building out a Flex team and debunked the current misconceptions surrounding why companies choose not to: that the resources are too scarce, it’s too expensive, and you need a team of experts. With those roadblocks eliminated, the next step is to determine who you need and how to identify them. That’s what we’re going to address here.
Understanding Your Needs
It’s imperative to identify what your requirements are and the number of resources that you’ll need to address them. You must determine what your team needs to accomplish before you begin to assemble it, otherwise you risk redundancy, inefficiency, and slowed or stalled projects. It sounds elementary, but this step can save you a lot of headaches later on. Ask yourself these questions:
What is the size of the application(s) that you need built? You need to know this to decide the size of your team.
Are you building or augmenting your team? If you’re building, a senior resource along with two mid-level resources is ideal. If you’re augmenting, your decision will be based on the amount of work to be done.
Do you have time to train resources? If you do, consider hiring junior resources to pair with a senior resource who can provide mentoring and oversight.
How large and complex is your target application? This question will help you focus the size and needs of your team in direct relation to the duration of the project.
I want to emphasize a couple salient points about building your team. You likely don’t need a huge team (our experience has been that 3-5 resources are sufficient for most projects), nor must that team be comprised of experts with years of experience under their belts. We’ve found that mixed teams of junior and senior level resources are the most productive.
That said, there are times when experience does matter, which returns to my point about clearly delineating the task at hand before you select resources. The key is to realize that while you’ll need an expert to accomplish certain complex tasks like performance profiling an application for scaling or custom visualization, their skill set isn’t typically necessary throughout the entire project.
Here’s a handy categorization:
- Expert: min 2+ years experience with Flex. Built and produced highly available and/or interactive Flex application. Unique understanding of specific part(s) of Flex related to complex domain problem to solve. Not typically someone who will lead or grow a team.
- Senior: min 2+ years experience with Flex. Been on teams before, led a project, solid grasp of MXML and AS. Understands Flex in context of product life cycle. If ‘Designer’ then custom components and look/feel. Min 2 other languages. Performance best practices on Flex. Implemented min 2 Flex projects.
- Mid: 6m – 2yr working with Flex. Been on a team before, good grasp of MXML and AS languages. Has some understanding of performance related issues to actions.
- Junior: 0 – 6 months: One other language, preferably scripting language. Has been through training and/or read and walked through good Flex book.
The Hiring Process
The hiring process has three components: identification, qualification, and on boarding. The first step is to make a list of how many resources you want to hire at which level of experience (expert, senior, mid and junior), and what skill set is needed (architect, designer, developer). The next thing to do is to locate them. You can use personal referrals, Monster, or similar sites, user group manager/lists, or a corporate recruiter.
Once a candidate has applied there are some specific things I look for on the resume. The most important thing for me is that the languages listed on their resume are consistent, complimentary, and parallel to Flex. If I need a Flex designer, I look for Flash, CSS, JavaScript, or other visually expressive languages; if I need a core Flex developer, I look for programming languages like Java, Ruby, .NET, JavaScript or CF. I’m looking for consistency here. Too much variety is often an indication of lack of focus.
I also look at experience with Flex itself: the length of time working with it and whether it was used peripherally or as a project core. I want to ascertain how they became exposed to the language to understand how they’ll think when working with Flex If I am looking for a senior level developer or architect I look at frameworks, patterns, and methodologies listed on their resume.
The last things I look for are soft skills and overall work experience. I look for both variety and stability here. Were past jobs remote, on-site, or both? Also, speaking or writing engagements are a good indication of a potential team mentor.
Once you’ve found an applicant that you believe matches the criteria you’ve established, it’s time to move on to the interview. This is the “qualifying” component of the hiring process and, arguably, the most important. The interview is generally where the decision to hire is made, and this decision is critical. You need to hire the right people at the right time and understand that mistakes made here could potentially doom a project. Although that sounds scary, knowing what skills resources need and how to identify them will help you make the most informed choice and that’s what we’ll discuss in our next post.
Design Patterns have always made me bristle a little bit. Maybe it’s just my inner contrariness but I believe that each problem has it’s nuances and that too much faith in Pattern will make you graft simple pre-made solutions on to complex real-life problems. I’ve always felt that it’s necessary to know the patterns, to have them in your tool-belt as a starting point for ideas, but that to be insistent about, or dependent on, the Design Pattern, confuses Pattern with Solution; the Starting point with the Finish line.
Sadly, I am not so articulate as this guy when it comes to this issue: http://blog.plover.com/2006/09/11/
On the face of it, his claim is that Design Patterns represent “signposts to the failures of the programming language”.
I think his larger claim is about the evolution of languages; that each language should be looked at as just the middle ground on a long uphill climb toward more expressive power, and that each Pattern codifies the frustrations of the programmers using it to do these often-needed things. To drive innovation, he would say, one should always be looking for ways to take Design Patterns and co-opt their power by making them invisible.
I couldn’t agree more.
And the corollary of course is that Design Patterns should be bristled at, used grudgingly, and as the starting point for discussion. Another way to say it might be, compliance with a Design Pattern is not a very good measure of Quality.
