Our primary market is in Internet Business Applications. This market covers everything from professional business web-sites and commercial on-line catalogues to communication and productivity co-ordination systems. Virtually all of these sites run on some or all of the staples -- customer logins, employee logins, product or service catalogues, interactive elements, survey systems, account purchases, invoicing, media servers, scheduling, e-commerce, e-mail broadcast systems, and back-end administration systems.

Our chosen language is Perl -- for a great many reasons. If you agree with these reasons, then you already know what they are. More specifically, we base our systems on "raw" perl. What do I mean by "raw"? Great question. Raw means no modules. There are a few notable exceptions (LWP, DBI, ImageMagick), but the idea is that there is never anything beyond our control. We know every line of code that runs, and every reason for any bug, any feature, and any function. This allows us to speak with clients and be able to say "yes" without having to "look into that". It allows our clients to speak with their customers and say "yes" without having to "ask the developers what they think". More importantly, it never leaves us with the excuse of "it's a bug in the module, we can't control that". These are each inexcusable, and our clients have come to respect our confidences in these matters.

So, running with the assumption that every line of code that you write will be your own, the trick is to write them well. But hey, we're talking about Perl here. Perl, the most open-styled, non-conformist, potentially most cryptic syntax available. So we try to find excuses to keep things consistent. One of those excuses is JavaScript portability. We frequently need to move logic client-side into JavaScript and back. So we try to adopt a JavaScript-style Perl convention. The second thing we do is to maintain our injection points. This requires a certain level of expansion, as opposed to the typical compression of Perl code. So we sacrifice performance for legibility and injection points. So we don't optimize logic away.

Enter Pipelines -- our web-site development platform. Pipelines handles the task of abstracting away all of the standard aspects of web-sites that we used to have to deal with daily. Pipelines handles database access, cgi security, user access, e-commerce, template development, e-mail broadcast, audit trails, surveys, content management, multi-level caching, and site navigation. A couple dozen files and a hundred-thousand lines of perl code yield a system that simply does what it's told to do.

Pipelines is stable, reliable, and incredibly powerful, but like everything else we do, it's never quite complete. There's a list with dozens of planned features, upgrades, and enhancements, not to mention missing functionality. Pipelines is a next-generation system designed for the future. It needs to stay ahead of the game.

Responsibility; Accountability; Trust. +1 416-230-1410

Yup, you guessed it, programming in perl. Simple, plain, easy, loops, basic regular expressions, arrays, hashes, perl. Lots of it, incredibly well organized. And entirely procedural. This is string manipulation at its best -- no objects, no blessings, no content. Long chains of input and output, data structuring and restructuring, data caching, in-time retrieval, and storage.

Everything is incredibly tiny, no function is complete until it does nothing -- a company policy. Significant features are implemented in just a few lines of code -- the trick is to know exactly the right place. And that's the key. You need to be able to form a complete mental map of where exitsing features reside, and their positions within the flow of the page generation. The old engineering anecdote -- chalk to mark the "X", $0.50; knowing where to mark the "X", $49'999.50.

The guiding concept behind Pipelines is very simple -- the template language exposes absolutely everything to the developer as a native feature. Everything -- small things like the page name, big things like the navigation menu elements, huge things like the currently logged-in user-permitted articles. The guiding principle is to empower the developer into a god. So Pipelines takes care of security, navigation, database retrieval, user login/profile, user permissions/restrictions/relations/access, surveys, e-mail broadcast, everything. The trick is to have everything done automatically for the developer, while letting the developer over-ride everything.

So, think of how easy it would be to create a complete web-site, say a product catalogue, when you don't have to worry about the actual e-commerce, the navigation, the security, the database retrieval, and the e-mailing. The only thing left is to lay it out. That's Pipelines; and that's really cool.

Responsibility; Accountability; Trust. +1 416-230-1410

Ha ha, Perl. You need to know perl. You need to be incredible comfortable with perl -- but not the way that most people are comfortable with perl. If you can play with modules, we're not interested. If you can do powerful things with blessed objects, we're not interested. If you can do amazing things with regular expressions, we're not interested. If you can translate business logic into english-like logical perl, we want you.

The more optimized the code, the less flexible it becomes. Our goal is to write code that mirrors it's english description. It's that simple -- every sentence is one line of code. That way, when a client adds a sentence to their request, we add a line of code. That's what we mean by "semantic" programming. The structure of the code mirrors the structure of the request. Yes it'll be slower, yes it'll consume more memory. But it will be upgradable, logical, legible, explainable, and changable. Quick rule of thumb -- no map statements. Another? It's not done until it's a hashref.

If you just asked why we insist on procedural code when something-oriented meets so many of those requirements, then you probably won't believe this answer: procedural wins for one simple reason, it's easy to tell what's influencing a particular line of code. There's no magic. That makes debugging code, tracing functionality, and avoiding conflicts incredibly simple. Lace the world with print statements. When something doesn't work as expected, find the bad line of code, and put a print statement. Simply back-track, putting print statements at each point until you find where things went wrong. Understanding the flow becomes nothing more than monkey-work. And that means that anyone who can read perl code can find anything.

We aren't using modules, so you don't need to know any. SQL doesn't hurt, but it doesn't come into play either. HTML doesn't make it in. You've got to be comfortable with string manipulation. But even that is simplistic at its worst.

That leaves us with semantic data structures. Just like the code, your data structures need to be semantically organized. Basically, it works like this. The database is structured for computational efficiency. But your structures need to be organized the way that your brain is organized. This is particularly important when it comes to reporting systems. Clients ask for all kinds of weird summaries and analyses. If your data is structured the way the physical real-world items are structured, then you can necessarily answer any real-world questions.

A good example? A grocery store. In the database, a table of items, a table of shelves, items have a shelf_uid. In your perl structure, an array of shelves, each with a nested array of items. Why? For the database, there are two distinct things that exist -- items and shelves. The relation between them is either part of the item, part of the shelf, or a third table between the two. For reporting, in the real world, a person walks through the shelves, with each containing items.

Responsibility; Accountability; Trust. +1 416-230-1410

There may, at some point, be a fancy application here to walk you through the various inetrviews. However, priorities are elsewhere at the moment. Send an e-mail to employment@HolophrasticEnterprises.com. Be sure to include your telephone number, e-mail address, city, any initial questions that you may have, the term of employment that you desire, and why you think that you'll love our life-style -- keep it short for now.

(Yes, this shoud be a form.)