Model and Entries classes need a rewrite

Any takers?

No?

Thought as much. I finally got myself working on the feared last ticket. I knew it would not be trivial, but I thought I'd get it done in a few hours, just as long as I would sit in front of the computer undisturbed (not a chance of that happening...). But I've come to realize that the whole architecture of the Model class is basically crap.

It's not all that much of a surprise, though – when I first started working on the ORM side of things, I had no idea where to start. So I added something here and another thing there and as a lump sum of chances I got something that worked fine in basic situations.

But now, looking at it a few months later, especially now that I've been working on the crazy tight typing and organized structure of Java code, what I've got here is something horrendously inflexible and clunky code. As the code stands today, implementing support for extracting parts of a time field (e.g. filtering by year from a timestamp) would make the code just even more ugly.

Normally I would keep this as secondary priority, just trying to deliver something that is nice and pleasant to use from the user's standpoint (spaghetti or no spaghetti). But the Model/Entries concept is something that I feel important to keep as maintainable as possible, even at the cost of some performance. I currently have no intentions of delivering an ORM system that would completely make manual SQL queries entirely obsolete. That would be just crazy. LightFrame is not, and does not contain, a complete ORM system and tries not to be like Propel.

Right now, I'm trying to build an open-ended framework that does something useful at the getgo. Sure, this will include an ORM system that is useful and not crippled. Displacing Propel might come in the future, but not in the first releases, not by a long shot. But the Model-system will evolve as needs grow and there's time to work on it, and there's lot that can be done in that aspect. That's why I probably need to rewrite model.php, because it currently can't grow much more than what it can do right now.

So, LightFrame Developer Release 1 will most probably be delayed a bit from my imaginary release date of 30.8.08...

Gotta Love Rands

I have a new love, and that's Rands in Repose. It's a blog about anything the character Rands thinks it's time to write about. In one post, he wrote about his coffee mug. A whole blog post! Whatever he writes about, he does it excellently. I envy those who can write about nothing in a brilliant way.

Today, he described what appears an excerpt of what I've been doing lately with LightFrame. Especially, mucking about in the Parking Lot. Head over and read about The Taste of the Day.

One ticket to go! I'm forecasting an upcoming milestone release within the month! After that, I'll probably start on another website based on LightFrame and do some documentation on the side, which is next to non-existent currently.

Finished Reading Peopleware

It was an interesting read. Very informative, amazingly insightful and overwhelmingly convincing (barring the example described in the previous post). But it was next to useless for me as a programmer.

The book goes to great lengths describing the ideal working place, which makes the prospect of how things could be seem like Utopia, where the working man has the best job ever, never wants to leave the company and everyone's just all smiles, just by looking less at the short term, and concentrating more on the long term.

This book is entirely manager-speak. Only managers, those who have the power and inclination to make the workplace a better place, can get anything out of this book. Me, as a programmer, read how wonderful things could be, can compare to what I have and that's about it. Sure, I could go to my manager and say "they have this, why don't we have it too?", showing an opened book and pointing my finger at a paragraph in a page, but it ends there. Not once did I get additional understanding to how managers work, making my own job easier by understanding motives behind managerial decisions.

In fact, the majority of the book is still irrelevant, even if I would get a couple of people working at LightFrame, even if I would pay them full-time. The first half/three-quarters of the book is essentially saying "it's wise to splurge on your employees, if you do it in the right way". This prerequisites capital. It doesn't mean anything to me to try to get everyone a phoneless working environment with a 3-meter-minimum cubicle walls, because I don't have office space to start with. I can't send my core developers to a hotel or a off-season ski-resort for a week to finish off the last sprint for the next milestone, as it would chew the current year's budget in one go.

So, while the book has my respect and awe for its thoroughness and amount of insight, the only people that can get everything out of the book are managers in a medium- to large-sized company, wielding a fair amount of control, respect and leadership skills.

Joel on Software was a lot more entertaining, interesting and useful for me.

Oh, and LightFrame moves on pretty well, all things considered. It's just that one little ticket I'm worried about...

Remember Critical Thinking

For the past month-or-so I've been reading the Peopleware: Productive Projects and Teams (a must-read, up there along with The Mythical Man-Month), which I've enjoyed reading. The book's authors have backed up their thoughts, reasoning and advice with years of consulting experience and extensive empirical research and I admire the effort they have put into the material.

One of these advice they infer has to do with a series of tests in the 60's conducted at Cornell University, researching the effects of listening to music while doing a programming exercise in Fortran. Encouraging you to buy and read the book yourself, I'll just say that the exercise concluded that listening or not listening to music (with headphones) while programming resulted in the same speed and accuracy for the finished result. But, those who did not listen to music (in the "quiet room") noticed, more frequently than those who did listen to music, a certain deliberately hidden gotcha in the test, where the specs of the task listed some operations that canceled out the effect of others (e.g. X=A+B-C, where C=A+B). A few sentences later, the book states that listening to music might hinder the developer of having a heureka! -moment, which might save the company "months or years of work".

So, music while coding equals bad, right? Sounds fair and logical. While the analytical half of the brain does the programming, the creative side is occupied listening to music, so we shouldn't do that, then. Today, I had a small epiphany. I understood that this conclusion needs to put this into context. Before reading on, I suggest you read my description of the test once again, with thought, and then return to the next paragraph.

The company I work for lets any and all employees order reasonably priced headphones in the company's expense (a great policy, if you ask me!). After a quick browsing, I chose mine to be Sony MDR-EX85LP. They arrived earlier this week, and since I started to listening to music with them, I noticed that my productivity has shot through the roof; the project I'm working on has not been advancing all that much recently, but now I write code nearly as fast as I can type, debug other people's code in the process, write tickets and just tackle everything between me and my goal for the project.

This event lead to the aforementioned epiphany: The key factors to take notice of in the test descriptions are "same speed and accuracy" and "creativity" and that they, in fact, are separate from each other. The test assumes that you do everything while listening to music, thus the creative side takes a hit. So, what happens if you plan ahead, do some thinking about the solution while not listening to music and then pushing play on your iPod while implementing those plans? You get to listen to music and have a fair chance of finding those mutually-voiding operations.

But I mentioned that my creativity curve went vertical, and the test in the book noticed no difference. That's because I don't work in a clean-room experiment settings. The book explicitly uses the words "quiet room" for the group that didn't listen to music. A room that is quiet. How many job environments are quiet? How many coding houses have absolutely no-one in any given employee's vicinity peer-reviewing one thing, or asking the other? Well, my work place fills neither slot (which is a good thing, open communication is healthy, as long as it doesn't get overboard). Have you already checked out the earbuds I mentioned earlier? They are noise-insulating. I hear absolutely nothing of my environment when I wear the 'buds and play music, even at low volumes. I live in my own bubble, oblivious to the outside world, to the point where those who stop by to ask me a quick question think it's funny.

This is the time when I really got some work done. Our workplace is quiet, but it's too quiet. There's no droning background noise that would drown the occasional shuffle of papers, cough, sneeze, distant conversations or the tapping sound of the keyboards. While they are not disturbing , they do get me out of Zone due to their haphazardness and suddenness. These earbuds provide me a precious bubble.

Also, me not being a native English speaking person helps while listening to music containing vocals, as I don't concentrate on the words as much as other people might.

So, remember critical thinking. While something you read might have valid backups, and, in fact, does not have a single factual error, it doesn't need to reflect the practical truth. Don't believe anything at face value and question most what you read, including my writings.

Especially my writings.

Aw, Crap

Assembla went down for a maintenance update and came back with neat upgrades to their UI and some feature upgrades aswell, and hopefully with some added server power as well. Assembla is now better than ever.

What better way to celebrate the update than with tackling another ticket for LF?! But, lo and behold, my LF installation is totally broken. All I get is a blank page on any page that LF should handle.

How convenient...

Now that I've been meddling with Java for the past three months, I've become very appreciative with how well Eclipse treats Java. Eclipse knows Java inside and out, helps the developer all the way through, has automatic everything and I sometimes wonder why not let just Eclipse code the Java I need. Strongly typed languages have their advantages, no doubt there.

One thing that I've learned to love is the built-in Java debugger. There's no faster way to track down the culprit of unexpected behavior than to place a breakpoint, run the code and step your way through the renegade code, seeing the list and respective values of each and every variable, all the time.

The way I've become accustomed to doing stuff in the PHP world is the good ol' var_dump($foo); die(); -routine. And it works most often just fine, as long as you keep yourself out of recursions and loops. It's then when the method gets ugly.

I can imagine someone already objecting, saying "but there are already several PHP debuggers out there!" It is true, there are at least two of which I've heard and tried: Zend Debugger and XDebug. I've never get them to work with Eclipse. Never. The plugins seem to think they work, but they debug nothing. They output nothing. They do nothing.

So, not knowing where to start debugging this regression, I won't. I had grand plans on getting much done this weekend, but I've lost my appetite. Better luck next weekend, I hope.