Getting Right Back on Track and Fulfilling a Promise

I love coding!

I'm not sure why, but I've had the easiest time to just sit down and crank out some code. And I love it! The tickets are just flying by as I whack them one after another. I've also actually done a commit for the longest time. This reminds me: I should study Git more closely.

The ORM is rewritten from scratch, and I'm back about where I was when I first started, with a much better architecture underneath than the last time around. Boy, the old "hack now, fix later" really bit me in the butt, huh? I'm feeling that each remaining part of LF (namely the 'core' and Response) could do well with a rewrite, or a code review at the least. But they seem to be working, and, as they say; le mieux est l'ennemi du bien (very freely translated: Perfection is the enemy of good enough), so I probably will let those ones rest for now and concentrate on actually getting the product out.

---

To go off in a tangent and filling in an earlier promise, in Restate My Assumptions, I said: "In small-scale web projects, sacrificing some performance to gain convenience for the developer is an acceptable trade-off." I'd like to now clear up what I meant by that:

Call me unambitious, but I'm not targeting the corporate world with LightFrame. The big-bucks corporate world probably uses Java for their web projects anyways. No – I'm after the home users, who have their great projects they want to do for their own, including perhaps a few friends', pleasure. A personal website, blogging engine, photo gallery, calendar software... That's my targeted audience.

With this in mind I'm giving myself a bit less hard of a time when it comes to performance optimizing. When facing a decision between convenient and efficient, I always choose the former. The convenience is for the user, mind you. The user who codes against LightFrame. This very same decision is also a decision between more work and less work, respectively. The fact that I consciously choose more work for me doesn't bother me the least bit, because this leads to less work for the developer. And that's what frameworks should be all about - less work for developers. This would go all to waste, if the configuration would cause a noticeable overhead, even if the coding part of things would be minuscule.

Anyhow. This convenience often requires some computational overhead. To figure out the current Model's SQL table counterpart takes some string manipulation, which inevitably takes some time. Sure, I could force the developer to explicitly tell me what table name she would use for each Model, but that quickly becomes tedious. (NB: You do have the freedom to define a custom table name, but you're not required to.)

But I'm convinced that this overhead makes no practical difference. With modern processing power, running even a complex script takes no time at all. That, added to the limited visitors expected for LightFrame applications, this becomes a non-issue. Think about it: I would consider 1000 daily visitors a successful website. This divided evenly across 8 hours translates to roughly two visitors a minute, or, put in another way, there's a 30 second window to cater the webpage to a visitor. Your visitor probably loses interest if the page doesn't load within five seconds anyhow, so, again, visitor density isn't an issue.

I even did some fancy mathematical calculations for this post, but I then erased them all, because once I noticed that it's probably trivial to achieve 100 000 PHP instructions per second on a modern setup, I stopped. Let me put it this way: once you have a LightFrame site that runs on half-decent hardware and acts slow down due to the framework's overhead, contact me at henrik paul at gmail, and I'll optimize either your project or LightFrame for you.

The fact remains: LightFrame makes the developer experience a higher priority than performance. That's a fact, and it won't change. That isn't to say that performance isn't a priority - it is. It's just not as critical one as ease of use. Besides, let's face it: if PHP is your language of choice, then performance probably isn't your number one priority to start with. LightFrame is, and will be, fast enough.

NetBeans 6.5 released

It's out! Highly recommended. Grab 'em while they're hot.

A decent blog post coming some day soon...

The Game's On

I'm doing a presentation on LightFrame in January in the office. For the presentation to leave people with a positive impression, I need to have something impressive to show. In order to show something impressive, LightFrame needs to be in working order. This means, I now have an actual deadline, not a made-up it-would-be-nice-if-I-could-make-it-deadline. So, yay, maybe I get something actually done!

I plan to have for display a bare-bones, minimally feature complete version by January 12:th. This means: the URL dispatcher, template engine, view mechanics and all model-related stuff would be complete (i.e. Alpha 1 release). Everything else will build on top of the core modules, and nothing substantially new would be added - at least for a while, not during Alpha 2. The emphasis, therefore, would be on getting a solid and rigid base to build upon. LightFrame will never be completely finished, but there will always be a potential for improvement. This is what I'll try to convey to people, the image of what LightFrame will become, and for this I need to show something convincing, even if it would be incomplete.

Good news: I have good faith in the current design of the Model-Entries-Field triad. It should be flexible enough to be able to grow. I don't know how I'll do implicit joins with join tables, but that won't make it into the Alpha 1 anyhow, so I won't bother myself with that right now. I have every reason to believe that during these two months I can get LightFrame into ship shape (poor pun intended).

I guess I need to make some time for reciting Made to Stick some day. And oh, would you look at that, I just ordered Presentation Zen and slide:ology.

Depressing, Good News

LightFrame is gaining a year sometime around now. I have just a smidgen of a problem: I honestly don't know exactly when. The first blog post was entered in February earlier this year, and I had already done stuff for LF at that time, so that's an end limit to the guesstimate. I got turned down from a job¹ the 23:th of November last year, so I'm guessing from the beginning of December to the end of January. It might actually be during the Christmas holidays when I first started doing stuff... Nah, I'll just decide that LightFrame turns one at 1.1.2009, and be done with it. It's easier to remember, too.

But, it's sooo depressing. I've done this project for a whole damn year. At the same time, though, I'm excited in that I have had the patience of keeping the project up for this far, as my earlier projects have been in the lines of about 30 days before total interest-flaccidation. But, still – damn, I'm getting nowhere. An average of just over 15 lines of code per day. OTOH, I've soon written the whole thing twice already, so it might be a whooping 30 LOC/day. *sigh*

All that is going to change, however! While our apartment's construction is still only about 71%² done I have actually launched NetBeans, updated it to the latest nightly build and also written some code! Alas, nothing all the way the repository³, but I'm having a smooth-take-off thing going on; I'm currently having a break from designing something to be easy to use and, boy, does PHP do its best to hinder designing clean code.

PS: Wow. I just read that first blog post. I've really come nowhere!

¹⁾ Which actually acted as a catalyst for starting LightFrame. But it's another story.
²⁾ The added 1% from the last post represents that I assembled my Ikea-desk.
³⁾ I really should start learning how to use Git, correctly.
and am using it.