So I'm starting to play with PHP and working on rewriting my Movable Type templates as *.phtml.
Having never really payed much attention to PHP, I'm amazed at how close it is to Perl (obviously on purpose) yet how much effort has been made to sand off the rough bits. Not sure how much I like it yet, but at least it's a familiar tune they're playing. The mildly annoying thing is that it's familiar, but there are just a few things I would habitually reach for in Perl that I haven't sussed out yet in PHP. Like autovivifying data structures. I abuse those constantly. I really need to wean myself away from that, methinks.
One thing that I was pleasantly surprised to find is PEAR, "a framework and distribution system for reusable PHP components". Hello, CPAN, my old friend. :) Finding all kinds of things that are immediately useful, like a Cache I can use to more intelligently and easily do the output caching voodoo I do in the perl CGI widgets right now.
You know, a lack of a centrallized CPAN-like system is what has kept me from leaving Perl for many other technologies. I really wish Java (CJAN?) and Python (CPyAN?) had one supported by their respective communities. It's just so nice to do a perl -MCPAN -e"install Date::Parse" and get what I need. Maintaining CPAN bundles for my perl software is tasty, too. Single-command installation of all my app's requirements, and sometimes I can roll it right into the app's installation itself. Mmm.
Anyway, it's nice (to say it again) to have a running personal site to tinker with, now that I've gotten off my butt and done it. This laboratory is letting me manufacture reasons to play with tech I hadn't bothered with before.
I mean, I've used ASP and JSP, and for most of the things I've done, I've grown a severe dislike for them both. I left the "Hey, you've got HTML in my code!" paradigm behind, wandered through that "Hey, you've got code in my HTML" model, and eventually settled on my standard pattern now:
A central app logic controller takes in GET/POST data, dispatches to a method which processes the form data. That method then constructs data structures, which are in turn passed through a template engine to be rendered by a pile of templates independent from the controller.This, along with some very special self-assembling component-based automation sauce, is the core of what my employer's offerings run on. But, this has crystallized as a habit for me, and I've not even considered other possibilities for a long time. This of course has made everything look like a nail for this hammer I have.
For example, while PHP is not quite the right tool for the things we're doing at my day job, it seems like a perfect option to quickly and easily replace SSI pages on my site with something meatier yet still simple to maintain and doesn't stink like ASP or JSP. I've also been looking at Cocoon, which if I can ever quite get in a groove with it, looks like a highly refined instance of my standard hammer.
And then there's Radio UserLand. I love it and hate it. The hate mostly comes from the slower iBook on which I run it, I think. The bootstrappiness of it makes me itch sometimes, but other times that just makes it endearing. The whole self-contained development biodome it represents is pretty sexy, too. Speaking of autovivifying data structures... I just have to love a system which has a live, manually tinkerable giant outline/hashtree for a persistence mechanism.
Next, I really want to swing back around to playing with Flash. Last time I did something major with it, I was making a game for my employer which really wanted to use web services but I hadn't known it yet. The game worked pretty well, but I want to see what it can do since last we met. First thing in mind that seems mildly nifty might be a slick, live updating lil "Recent Visitors" app for my front page.
I'm really feeling what Jon Udell means when he writes about thinking by analogy. It's also something one of my favorite Comp Sci professors harped on, with regards to what makes a Computer Programmer versus what makes a Computer Scientist. A small part of his speech always pointed to the notion that a a programmer is almost always pragmatic, memorizing the patterns and greasy innards of whatever tool he or she uses daily. On the other hand, the scientist is an explorer and finds joy in confusing him or herself by finding the universals and generalities across a range of tools. In the end, the programmer becomes specialized in a limited domain, while the scientist knows can pick up just about anything that comes along. And sometimes, many times, the scientist makes new tools for programmers to specialize on. I want to be and am working toward being a scientist.
More soon.
shortname=oooaaf
Archived Comments