Alpha 1 milestone is done. With four days to spare, all tickets are closed. It feels unreal. I can't even figure out what to write about it. It's done.
I guess the only way is onwards. There's tons of stuff that I haven't properly touched. There's the command line scripts, admin page/crud. Not to mention the proper website. Of course, I won't start on doing any of them, because I need to prepare some sample applications for the presentation I'll be having the 12:th. Hopefully it'll reveal some bugs in the software...
Oh, and I've been musing about registering the name Dogfood Software (or something similar) as the force behind LightFrame. Well, it was actually just a passing thought, that just didn't sound stupid one second later...
Saturday, December 27, 2008
Tuesday, December 23, 2008
Early Awesome Christmas Present!
WHOA! I just got the best Christmas present ever: lightframe.org. AWESOME! Thanks Ville!
A Tribal Manual
So, I finished reading Seth Godin's Tribes, meaning, it's time for yet another reviewlet.
For those who don't know Seth Godin, he's, among many things, a professional speaker. I guess I wouldn't make a great pigeon-holing error to call him a professional motivational speaker. He delivers great presentations. Some of his speaks are up on YouTube, and I highly enjoy watch him present whatever he has to say. Oh, and he has written some books, too.
In his latest book (Tribes, that is), he writes about how the world has changed, or is about to change, from ordering people to do your will to making people wanting to do what they want, making sure that, not incidentally, their want happens to coincide with your will. Converting from Bosses (those who boss people around) to Leaders (those who lead people around). Discarding the workforce and having instead, what he calls, a tribe.
A tribe, according to mr. Godin, is a collection of followers that authentically share your vision and idea. He brought up Steve Jobs a few times in his book, which, in my mind, is a prime example of a guy who has a big tribe – people that passionately, almost zealotously (no, that's not a real word), share and follow his vision.
As for the review: I must sadly say that I pretty much revealed the whole content of the book. Oh, I did leave one thing out. Instead of explaining it, let me just recite the subtitle of the book: "We Need You to Lead Us." Yup, that's pretty much it; after giving a definition to his meaning of "a tribe", he tells me that I can, and must, be a leader for my tribe. There's nothing in my way of becoming a leader, other than my own insecurities, fears and imagined hurdles.
In other words, this was a pep-talk book. I could easily imagine this book being a modified transcription of one of his gigs on stage. The book wasn't very organized and there was just header after header. Some longer and some shorter paragraphs. Endless examples of everyday leaders who were nobodies, just like myself, and became people who grew a tribe, and made a difference.
The problem is, I thought this was a book about how to grow a tribe, or even some hints towards that. Instead, this book was about how tribes are important, and that I, the reader, have no hindrances to growing one. The problem wasn't that I didn't buy every word he written – I did – but that I didn't need any convincing of becoming a leader. I also have grown a conscious resistance against motivational presentations (be it oral or written) for various reasons.
So, if you have a rebellious idea in your head, but don't know what to do with it, Tribes is the book I recommend for you. I, on the other hand, know exactly what to do with LightFrame (roughly meaning: working on it until either it takes off or I lose interest).
All things said, even if you don't need convincing, I wouldn't go as far as saying this book is unnecessary or even a bad buy. The 14€ I spent on this paperback were well spent, especially if I compare to the 55€ I spent on a book and a half. No, it's a useful book for everyone to read. It's just more effective on people who think something sucks, know exactly how it would be fixed, but don't fix it, for a reason or another.
PS: My cousin listened to the audiobook version of Tribes, and he liked it a lot. I believe him. Especially, when Seth himself was the narrator, I can believe that this book in a spoken performance would hit home in a much more effective way. Take this with a grain of salt, as this is the only book by Seth Godin that I have read, but he might be a better speaker than writer.
For those who don't know Seth Godin, he's, among many things, a professional speaker. I guess I wouldn't make a great pigeon-holing error to call him a professional motivational speaker. He delivers great presentations. Some of his speaks are up on YouTube, and I highly enjoy watch him present whatever he has to say. Oh, and he has written some books, too.
In his latest book (Tribes, that is), he writes about how the world has changed, or is about to change, from ordering people to do your will to making people wanting to do what they want, making sure that, not incidentally, their want happens to coincide with your will. Converting from Bosses (those who boss people around) to Leaders (those who lead people around). Discarding the workforce and having instead, what he calls, a tribe.
A tribe, according to mr. Godin, is a collection of followers that authentically share your vision and idea. He brought up Steve Jobs a few times in his book, which, in my mind, is a prime example of a guy who has a big tribe – people that passionately, almost zealotously (no, that's not a real word), share and follow his vision.
As for the review: I must sadly say that I pretty much revealed the whole content of the book. Oh, I did leave one thing out. Instead of explaining it, let me just recite the subtitle of the book: "We Need You to Lead Us." Yup, that's pretty much it; after giving a definition to his meaning of "a tribe", he tells me that I can, and must, be a leader for my tribe. There's nothing in my way of becoming a leader, other than my own insecurities, fears and imagined hurdles.
In other words, this was a pep-talk book. I could easily imagine this book being a modified transcription of one of his gigs on stage. The book wasn't very organized and there was just header after header. Some longer and some shorter paragraphs. Endless examples of everyday leaders who were nobodies, just like myself, and became people who grew a tribe, and made a difference.
The problem is, I thought this was a book about how to grow a tribe, or even some hints towards that. Instead, this book was about how tribes are important, and that I, the reader, have no hindrances to growing one. The problem wasn't that I didn't buy every word he written – I did – but that I didn't need any convincing of becoming a leader. I also have grown a conscious resistance against motivational presentations (be it oral or written) for various reasons.
So, if you have a rebellious idea in your head, but don't know what to do with it, Tribes is the book I recommend for you. I, on the other hand, know exactly what to do with LightFrame (roughly meaning: working on it until either it takes off or I lose interest).
All things said, even if you don't need convincing, I wouldn't go as far as saying this book is unnecessary or even a bad buy. The 14€ I spent on this paperback were well spent, especially if I compare to the 55€ I spent on a book and a half. No, it's a useful book for everyone to read. It's just more effective on people who think something sucks, know exactly how it would be fixed, but don't fix it, for a reason or another.
PS: My cousin listened to the audiobook version of Tribes, and he liked it a lot. I believe him. Especially, when Seth himself was the narrator, I can believe that this book in a spoken performance would hit home in a much more effective way. Take this with a grain of salt, as this is the only book by Seth Godin that I have read, but he might be a better speaker than writer.
Thursday, December 18, 2008
Moving to Github
Because I can't get Assembla's git repository being shown to the public, I've decided to give github a try. I've already put stuff up to the repository. For the less-than-24-hours that I've used github, the features it provides seem pretty neat, at least compared to those in Assembla. The Pull Request might become handy, should the project take off and get more developers.
You are free to look at the code, download it, poke at it, modify it, break it, port it to Haskell and then sell it, if you so want – it is, after all, licensed under Apache 2.0.
You are free to look at the code, download it, poke at it, modify it, break it, port it to Haskell and then sell it, if you so want – it is, after all, licensed under Apache 2.0.
Friday, December 12, 2008
More Book Reviews and Commentary
The two books I mentioned earlier have now been read: Presentation Zen and slide:ology.
Presentation Zen
A nice book that any and every person that has to do any kind of presentation or speech (be it a status report, or a full-fledged Jobs-can-kiss-my-ass-two-hour-keynote). This really teaches you how not to suck at giving an oral presentation. I can not emphasize this enough. This book doesn't mention much concrete stuff about doing public speaking, but rather talks about, as the author calls it, the zen of presentations (hence the name); the dos and don'ts of PowerPoint presentations. Hell, let me reveal the biggest and most important thing the book tries to get across: Avoid bullet points at all costs. If you absolutely-positively-my-life-depends-on-it must use bullet points, keep them at a minimum. Even then, use huge font sizes.
This book belongs almost to the practical psychology category of books, and actually makes you a more likable person around the workplace, or wherever you are going to do presentations. Can't argue with that, now can you?
slide:ology
You want to read this only after Presentation Zen. You do not want to read them the other way around, or you'll ruin Presentation Zen. These two books are tightly coupled. I'm not sure who copied which, but they share content. Let me rephrase that: A few chapters are more or less copy-pasted from one into the other. Both books quote each others' authors. Presentation Zen first, slide:ology second. Trust me.
While the first three chapters in this book made me want my money back, I was perhaps a bit hasty in that judgement. Slide:ology is more of a hands-on kind-of-book. While Presentation Zen was more about the philosophy and psychology of doing presentations, slide:ology tries to give you concrete examples for your slides. The first three chapters was Presentation Zen in a tight nutshell. Once you skip them, you start to get to the original material, which is pretty interesting, case studies and all. There is the occasional shared content scattered also later on in the book, but since you already have read Presentation Zen, you are safe to skip (i did say skip, not skim) those parts.
Slide:ology works best as a reference book. There's not much you need to ingest and understand, unlike with the other book. Read it through once, put it in the bookshelf and take it out again once you have PowerPoint (or, as in my case, Keynote) running in front of you. Slide:ology tells you how an ad agency does its slides, what elements they to convey which pieces of information, etc.
So, that's that. Mini reviews: Ingest and embrace Presentation Zen first, then use slide:ology as a reference to how to build your slides (if you use slides, that is).
Commentary
So, I first sat down in front of my computer, opened FreeMind and started plotting stuff about LightFrame. Three hours of in-the-zone mindmapping later, I had all features pinned down – in a nice hierarchical manner, no less. Time for slide-making, I thought and launched Keynote. I subsequently hit a brick wall.
I realized that all this knowledge of how to deliver nice speeches and design un-sucky slides was worthless, without interesting content. What I had written down were only features and facts, not content. I could of course talk endlessly about how LightFrame works, what technical decisions I've made with each part of the design, the history of it and such. But who's interested in that. The most common theme of all practical psychology books I've read thus far have touted one thing, over and over again, with little variation in wording: People are only interested in what they can benefit from you.
People aren't there because they want to listen to me (actually, half of my audience will show up only for the company's breakfast, and will be oblivious of my presentation intents) – people are there to listen to what I have to offer them. That's a tough question to answer. I probably will be unsuccessful in giving a good answer to that. So, I'll aim at getting a few laughs out of them. Wait, make that a few approving nods...
As some wise and famous guy once said (paraphrased): I can deliver a five hour speech with only five minutes' preparation, but for a five minutes' speech, I need at least five hours of preparation. I could almost swear it was Churchill, but I can't find anything to back it up. Anyhow; I know now what this guy's talking about.
Presentation Zen
A nice book that any and every person that has to do any kind of presentation or speech (be it a status report, or a full-fledged Jobs-can-kiss-my-ass-two-hour-keynote). This really teaches you how not to suck at giving an oral presentation. I can not emphasize this enough. This book doesn't mention much concrete stuff about doing public speaking, but rather talks about, as the author calls it, the zen of presentations (hence the name); the dos and don'ts of PowerPoint presentations. Hell, let me reveal the biggest and most important thing the book tries to get across: Avoid bullet points at all costs. If you absolutely-positively-my-life-depends-on-it must use bullet points, keep them at a minimum. Even then, use huge font sizes.
This book belongs almost to the practical psychology category of books, and actually makes you a more likable person around the workplace, or wherever you are going to do presentations. Can't argue with that, now can you?
slide:ology
You want to read this only after Presentation Zen. You do not want to read them the other way around, or you'll ruin Presentation Zen. These two books are tightly coupled. I'm not sure who copied which, but they share content. Let me rephrase that: A few chapters are more or less copy-pasted from one into the other. Both books quote each others' authors. Presentation Zen first, slide:ology second. Trust me.
While the first three chapters in this book made me want my money back, I was perhaps a bit hasty in that judgement. Slide:ology is more of a hands-on kind-of-book. While Presentation Zen was more about the philosophy and psychology of doing presentations, slide:ology tries to give you concrete examples for your slides. The first three chapters was Presentation Zen in a tight nutshell. Once you skip them, you start to get to the original material, which is pretty interesting, case studies and all. There is the occasional shared content scattered also later on in the book, but since you already have read Presentation Zen, you are safe to skip (i did say skip, not skim) those parts.
Slide:ology works best as a reference book. There's not much you need to ingest and understand, unlike with the other book. Read it through once, put it in the bookshelf and take it out again once you have PowerPoint (or, as in my case, Keynote) running in front of you. Slide:ology tells you how an ad agency does its slides, what elements they to convey which pieces of information, etc.
So, that's that. Mini reviews: Ingest and embrace Presentation Zen first, then use slide:ology as a reference to how to build your slides (if you use slides, that is).
Commentary
As with How to Win Friends..., the story doesn't quite end here. Once I had read these two books in three days, I was psyched. I was pumped. I was ready to Deliver A Presentation. I had the know-how, I understood the philosophy.
So, I first sat down in front of my computer, opened FreeMind and started plotting stuff about LightFrame. Three hours of in-the-zone mindmapping later, I had all features pinned down – in a nice hierarchical manner, no less. Time for slide-making, I thought and launched Keynote. I subsequently hit a brick wall.
I realized that all this knowledge of how to deliver nice speeches and design un-sucky slides was worthless, without interesting content. What I had written down were only features and facts, not content. I could of course talk endlessly about how LightFrame works, what technical decisions I've made with each part of the design, the history of it and such. But who's interested in that. The most common theme of all practical psychology books I've read thus far have touted one thing, over and over again, with little variation in wording: People are only interested in what they can benefit from you.
People aren't there because they want to listen to me (actually, half of my audience will show up only for the company's breakfast, and will be oblivious of my presentation intents) – people are there to listen to what I have to offer them. That's a tough question to answer. I probably will be unsuccessful in giving a good answer to that. So, I'll aim at getting a few laughs out of them. Wait, make that a few approving nods...
As some wise and famous guy once said (paraphrased): I can deliver a five hour speech with only five minutes' preparation, but for a five minutes' speech, I need at least five hours of preparation. I could almost swear it was Churchill, but I can't find anything to back it up. Anyhow; I know now what this guy's talking about.
Saturday, November 29, 2008
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.
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.
Thursday, November 20, 2008
Wednesday, November 12, 2008
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.
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.
Saturday, November 1, 2008
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 job1 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%2 done I have actually launched NetBeans, updated it to the latest nightly build and also written some code! Alas, nothing all the way the repository3, 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!
1) Which actually acted as a catalyst for starting LightFrame. But it's another story.
2) The added 1% from the last post represents that I assembled my Ikea-desk.
3) I really should start learning how to use Git, correctly.
and am using it.
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%2 done I have actually launched NetBeans, updated it to the latest nightly build and also written some code! Alas, nothing all the way the repository3, 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!
1) Which actually acted as a catalyst for starting LightFrame. But it's another story.
2) The added 1% from the last post represents that I assembled my Ikea-desk.
3) I really should start learning how to use Git, correctly.
and am using it.
Monday, October 27, 2008
Construction 70% Complete
LightFrame HQ has moved, and all the stuff has been transported from location A to location B. Unfortunately, all the stuff are in crates #0 through #59, including a new work desk that are in various Galant-labeled cardboard casings. Unfortunately LightFrame HQ will not be fitted with Aerons (the nearest outlet is about 200km away), although I would've loved some Hermann Meyer action over here.
Anyhow, the point remains that I have no place to work at, and the construction is not even complete (how I wish it would be C&C-easy). But, I'm certain that things settle in the nearest weeks. Until that, however, I probably still won't touch the codebase.
Anyhow, the point remains that I have no place to work at, and the construction is not even complete (how I wish it would be C&C-easy). But, I'm certain that things settle in the nearest weeks. Until that, however, I probably still won't touch the codebase.
Saturday, October 18, 2008
Hectoticket
Whoop whoop, LightFrame has got its hundredth ticket! Actually, I realized this a bit late, as there are already 107 of them. But better late than never, as they say. Hooray for me. I don't know where I got this inspiration to come up with and write new tickets, but it's never a bad thing.
This means first and foremost that I know that I have by work cut out for the future, and there's much to be done until I can claim it to be complete (whether it ever will become complete is an entirely different question).
We'll be moving to our new apartment next Friday. This means that I'm soon getting the time and space to actually code something new to LightFrame. Oh, god, how I've waited for that moment. Soon, soon...
This means first and foremost that I know that I have by work cut out for the future, and there's much to be done until I can claim it to be complete (whether it ever will become complete is an entirely different question).
We'll be moving to our new apartment next Friday. This means that I'm soon getting the time and space to actually code something new to LightFrame. Oh, god, how I've waited for that moment. Soon, soon...
Monday, October 6, 2008
Restate My Assumptions
To piggyback one of my favorite movies ever, here are some assumptions that keep me developing LightFrame (when I have the time and inspiration, naturally).
- PHP is the most popular language used for websites among non-corporate efforts (e.g. hobby projects).
- A considerable amount of PHP-based sites are not installed on freely manageable servers (e.g. webhotels).
- Developers like popular frameworks like Ruby on Rails, but find it difficult to find proper hosting for required technology stacks. (Ruby in this case.)
- In small-scale web projects, sacrificing some performance to gain convenience for the developer is an acceptable trade-off.
Saturday, September 27, 2008
Django 1.0
Would you look at that. Django has released the 1.0 at the beginning of the month. Congratulations to them and their community!
Tuesday, September 16, 2008
Mini Book Reviews
It's a wonder how much one gets read when one has two weeks of absolutely nothing to do – except of just lying under the sun, having the sea sloshing at your feet, and sipping on the Mai tai, blended in a carved-out pineapple, listening to tropical birds twittering around and feeling the gentle breeze in the stubbly hair I have.
Oh, right. The books.
Starting with the most off-topic book of the bunch: How to Win Friends and Influence People
by Dale Carnegie.
The title of this book is misleading. You are probably thinking that this book is about manipulating and hoaxing people into doing stuff they wouldn't normally do, and that would a wrong way to describe it. The "win friends" part should be read as "avoid pissing anyone off", and "influencing people" is more like "getting people seeing stuff your way". On the other hand, perhaps the book's title wouldn't be as marketable if it were "How to Avoid Pissing Anyone Off and Getting People Seeing Stuff Your Way". The book presents itself to be a lifestyle manual more than a book, and that's not necessarily a bad thing. This doesn't, by any means, mean that the book couldn't be read just for the entertainment, which I did. But I'll probably re-read it some day soon.
The book's main point seems to be that if you present yourself and your intentions in a positive way, be it criticism or praise, you will get more out of other people. It relies heavily on how the individual thinks in everyday situations, what I'd like to call practical psychology. People will think better of you, you probably will make more friends, and you are able to give constructive criticism to people, without them maybe even knowing you are criticizing them of anything.
There are literally dozens of pointers and one or two real-life (or so they are claimed to be) situations where these pointers have been applied, and described what really happened in those situations. These pointers are nothing magic and pretty forehead-slap-obvious, once you read about them. One of the on-going themes in the book is "be hearty in your approbation and lavish in your praise," almost to the point of it being a mantra. The only gotcha is, that you can't fake it. I mean, even if you have the ability to fake it, it doesn't count. You really need to truly mean it, sincerely. Faking praises is just synonymous to ass-kissing.
Much of the book makes perfect common sense. If you are polite, people will like you more than if you were an asshole about stuff. If you smile, people are less hostile against you. If you excuse yourself, people tend to excuse you. Etc. One thing that I thought about is that this book does not guard you from assholes, and almost assumes that people you interact with are civilized or even half decent human beings. If you say to your busy waiter in a busy restaurant "Excuse me. I hate to disturb you, seeing you are busy and all, but my soup is cold, and I wonder if you could heat it up for me" and instead of her being sorry for the mishap and returning promptly with the heated soup, she would just say "fuck you, sit the fuck down, eat your damn soup, you fucking whiner", there's nothing the book does for you.
And herein lies the twist. I'm sure that this book has exactly the effect as Carnegie thought it having in countries like, say, the US. But I live in Finland. Let me explain: I worked as a clerk in a computer hardware retail store, so I have seen my share of customers. As we sold, shall we say, high end hardware, when it comes to people buying computer hardware, our customer base was certainly more pleasant to deal with than the average. But still, when the occasional foreign customer walked into the store, the day was saved. No exceptions. Every single foreign customer more pleasant to deal with, than the best of our Finnish customers.
So, my point is, Finns (and, therefore, undoubtedly people from other cultures as well) might not understand the minute details of the messages given as per the book the way Carnegie has thought about it. I can easily think that if I was "hearty in my approbation" and especially if i was "lavish in my praise", people here would think I would condescend to them, patronize them. If people are nice to you for no apparent reason around here, they get suspicious. "What do you mean 'I look handsome today'? I was ugly yesterday, huh?"
The book is still interesting, and I find practical psychology very interesting. I just need to figure out how to apply it in a culture inherently hostile towards friendliness. Recommended read, if you want to become that much of a better person, while getting personal gain out of it too.
Next book (less off-topic): Don't Make Me Think
by Steve Krug.
While the previous book was originally written in 1937 and hasn't aged a bit, this book was originally written just before the dotcom bubble burst. While I read the second edition, published in 2005, much of the contents are from the original web1.0 era, with only three chapters compressed into one, and a few additional chapters. All examples are almost 10 years old, so the book looks outdated. But it only looks that.
The examples might be 10 years old, and while indeed current websites might be more interesting to dissect apart, it is not necessary. The point of this book doesn't rely on the newest web memes. Also unlike the former book, Don't Make Me Think is very easy to describe in only few words: It's a book for designing web sites and has one main message: don't make the user think. Everything should be stupid-obvious on your website. It's all about optimizing the user experience, avoiding to frustrate your visitor during the very short attention span she has. And the majority of it makes perfect sense.
There is a reason why Google is a perfect landing page for any browser. It's the same reason why iPods are dominating the PMP market. Everything you put into your website should be there for a specific reason, serving a specific purpose. Everything that looks clickable, should be clickable. Everything that's clickable, should look clickable. If the visitor wants to find the manual, you should be wise enough to provide the manual easily, and not try to sell "super deal discounts". And so on.
This is a must-book for all and every one that has anything to do with putting stuff up on the web. Hell, even if you don't buy the book, just remember "don't make me think", implement that in your site, and you are better off than many megacorporations' sites *cough*HP*cough*.
Naturally, this book should not either be taken as the holy bible. This is just one person's opinions. Sure, he has made a living out of usability testing websites, and he knows his stuff, but he still is just one person with an opinion. For example, I disagree that in a web store, each and every item should belong in exactly one category. If a product could belong in several categories, you should pick one of them, and stick with it, he implies. I, for one, think arbitrary tags are great, which, almost by definition, make items pop up in several contexts.
Then there's a more fundamental thing. It's not something I precisely disagree with, but I feel it needs to be said. This book advocates using web conventions. And I, too, think that web conventions are something that need to be taken into account. But the book also outright discourages you to go out and experiment with your design. Now, this book is all about making the site as effortless to use as possible, so I do understand where he's coming from, and it makes prefect sense; people know how to use the scrollbar, so don't force them in using Ctrl-Shift-Backspace-3-A to scroll down the page. I get that, and he has a point. But this, at the same time, makes the book uninteresting, perhaps even useless, for those people who want to do the bleeding edge, want to make the new GMail ("for godssakes, people expect the whole page to refresh when they open a new mail!") or Google Maps ("the users will never figure out that you can actually drag on a canvas. Use the traditional directional arrow navigation buttons instead").
The book will give you a complete tour around the safe comfort zone of proven site elements. If you follow the book precisely, I'm sure you will produce a website that works very well, is pleasant to use, and keeps the visitor's interest. But you probably won't get to introduce the next web convention, either.
The third book, another management book: Managing Humans
by Michael Lopp, aka. Rands.
Out of the three management books I've read (Joel on Software
, Peopleware
and this one), I must confess, this is the best of them.
Peopleware was very informative, credible and authoritative, but utterly useless for me as a non-manager. Joel on Software got me to understand the workings of a manager, what they do, how to interact with them, what to expect of them, and other more down-to-earth aspects of managers. Managing Humans is even more so.
As Joel on Software, Managing Humans is a compilation of articles from a blog. I haven't followed Rands in Repose so much that I could say whether everything is out of the blog, or if there is original text included too. But that doesn't matter. The book is excellently written, and there's really only one part that gives away the fact, that not everything is written for that book specifically.
Lopp has the ability to write as if the reader was his best friend. While you know he knows his stuff, and you respect his experience, he cuts the corporate bullshit, and tells how things really are, in a way no-one else would dare to confess to be thinking. He knows that most people don't actually enjoy meetings. He recognizes the existence of managementese, a modification of the language that sounds like real talk, but is nigh to unintelligible, and also feels ashamed of himself whenever he uses it.
He can play both sides of the board at the same time. First he describes a scenario in general, and then he goes inside each person's head present in that fictious setting. I stared in awe, when he described the Nerd in the Cave, a perfect description of my working environment, my mindset while at the computer and myself. He points out the (now) obvious existence of Incrementalists & Completionists (completionist here, hello!). I could go on and on.
If you work in a company, develop software, have a boss you want to understand, have a team to understand, or want to understand how you behave yourself, this is the book to have a look at. I guarantee that you will find yourself inside in more variants than you previously thought possible. And don't be scared, even this book is a management book. It's only partly so, and there's a whole chapter on being a normal employee. After all, managers all have managers of their own, and in the end of the day, we all come to work and leave work (sooner and later, probably respectively).
As a quick bonus, I'm in the progress of reading Made to Stick
by Chip and Dan Heath.
I'm not going to give even a micro review about this book, as I haven't yet completed it, and more because I started reading on it too long ago to remember detailed points about it. But, all in all, it's a book about how to make your points more memorable; if you have something to say, how to make people remember it better and longer.
This, too, has to do with practical psychology, and relates to both How To Win Friends and Don't Make Me Think. These three books actually overlap each other in some certain ways, and say the same things with different words and examples. For example, one statement that all three books make is the fact that your target audience (be it your friend, your website visitor or presentation listener) does not really care about what you care. They care about what they care. They are not interested in what you are interested in. They interest themselves in their own interests.
Anyhow: A book that I can recommend to anyone who makes a pitch, a presentation or gives any kind of information that you want people to remember even after the immediate moment they heard it.
I could've done separate posts for each book. But I couldn't be bothered.
Oh, and nothing new in the lightern front. It's still in a standstill. Our wedding preparations are all behind us, we're back from our honeymoon, but we now have an apartment that needs a monthful-and-then-some of fixing.
Oh, right. The books.
Starting with the most off-topic book of the bunch: How to Win Friends and Influence People
by Dale Carnegie.The title of this book is misleading. You are probably thinking that this book is about manipulating and hoaxing people into doing stuff they wouldn't normally do, and that would a wrong way to describe it. The "win friends" part should be read as "avoid pissing anyone off", and "influencing people" is more like "getting people seeing stuff your way". On the other hand, perhaps the book's title wouldn't be as marketable if it were "How to Avoid Pissing Anyone Off and Getting People Seeing Stuff Your Way". The book presents itself to be a lifestyle manual more than a book, and that's not necessarily a bad thing. This doesn't, by any means, mean that the book couldn't be read just for the entertainment, which I did. But I'll probably re-read it some day soon.
The book's main point seems to be that if you present yourself and your intentions in a positive way, be it criticism or praise, you will get more out of other people. It relies heavily on how the individual thinks in everyday situations, what I'd like to call practical psychology. People will think better of you, you probably will make more friends, and you are able to give constructive criticism to people, without them maybe even knowing you are criticizing them of anything.
There are literally dozens of pointers and one or two real-life (or so they are claimed to be) situations where these pointers have been applied, and described what really happened in those situations. These pointers are nothing magic and pretty forehead-slap-obvious, once you read about them. One of the on-going themes in the book is "be hearty in your approbation and lavish in your praise," almost to the point of it being a mantra. The only gotcha is, that you can't fake it. I mean, even if you have the ability to fake it, it doesn't count. You really need to truly mean it, sincerely. Faking praises is just synonymous to ass-kissing.
Much of the book makes perfect common sense. If you are polite, people will like you more than if you were an asshole about stuff. If you smile, people are less hostile against you. If you excuse yourself, people tend to excuse you. Etc. One thing that I thought about is that this book does not guard you from assholes, and almost assumes that people you interact with are civilized or even half decent human beings. If you say to your busy waiter in a busy restaurant "Excuse me. I hate to disturb you, seeing you are busy and all, but my soup is cold, and I wonder if you could heat it up for me" and instead of her being sorry for the mishap and returning promptly with the heated soup, she would just say "fuck you, sit the fuck down, eat your damn soup, you fucking whiner", there's nothing the book does for you.
And herein lies the twist. I'm sure that this book has exactly the effect as Carnegie thought it having in countries like, say, the US. But I live in Finland. Let me explain: I worked as a clerk in a computer hardware retail store, so I have seen my share of customers. As we sold, shall we say, high end hardware, when it comes to people buying computer hardware, our customer base was certainly more pleasant to deal with than the average. But still, when the occasional foreign customer walked into the store, the day was saved. No exceptions. Every single foreign customer more pleasant to deal with, than the best of our Finnish customers.
So, my point is, Finns (and, therefore, undoubtedly people from other cultures as well) might not understand the minute details of the messages given as per the book the way Carnegie has thought about it. I can easily think that if I was "hearty in my approbation" and especially if i was "lavish in my praise", people here would think I would condescend to them, patronize them. If people are nice to you for no apparent reason around here, they get suspicious. "What do you mean 'I look handsome today'? I was ugly yesterday, huh?"
The book is still interesting, and I find practical psychology very interesting. I just need to figure out how to apply it in a culture inherently hostile towards friendliness. Recommended read, if you want to become that much of a better person, while getting personal gain out of it too.
Next book (less off-topic): Don't Make Me Think
by Steve Krug.While the previous book was originally written in 1937 and hasn't aged a bit, this book was originally written just before the dotcom bubble burst. While I read the second edition, published in 2005, much of the contents are from the original web1.0 era, with only three chapters compressed into one, and a few additional chapters. All examples are almost 10 years old, so the book looks outdated. But it only looks that.
The examples might be 10 years old, and while indeed current websites might be more interesting to dissect apart, it is not necessary. The point of this book doesn't rely on the newest web memes. Also unlike the former book, Don't Make Me Think is very easy to describe in only few words: It's a book for designing web sites and has one main message: don't make the user think. Everything should be stupid-obvious on your website. It's all about optimizing the user experience, avoiding to frustrate your visitor during the very short attention span she has. And the majority of it makes perfect sense.
There is a reason why Google is a perfect landing page for any browser. It's the same reason why iPods are dominating the PMP market. Everything you put into your website should be there for a specific reason, serving a specific purpose. Everything that looks clickable, should be clickable. Everything that's clickable, should look clickable. If the visitor wants to find the manual, you should be wise enough to provide the manual easily, and not try to sell "super deal discounts". And so on.
This is a must-book for all and every one that has anything to do with putting stuff up on the web. Hell, even if you don't buy the book, just remember "don't make me think", implement that in your site, and you are better off than many megacorporations' sites *cough*HP*cough*.
Naturally, this book should not either be taken as the holy bible. This is just one person's opinions. Sure, he has made a living out of usability testing websites, and he knows his stuff, but he still is just one person with an opinion. For example, I disagree that in a web store, each and every item should belong in exactly one category. If a product could belong in several categories, you should pick one of them, and stick with it, he implies. I, for one, think arbitrary tags are great, which, almost by definition, make items pop up in several contexts.
Then there's a more fundamental thing. It's not something I precisely disagree with, but I feel it needs to be said. This book advocates using web conventions. And I, too, think that web conventions are something that need to be taken into account. But the book also outright discourages you to go out and experiment with your design. Now, this book is all about making the site as effortless to use as possible, so I do understand where he's coming from, and it makes prefect sense; people know how to use the scrollbar, so don't force them in using Ctrl-Shift-Backspace-3-A to scroll down the page. I get that, and he has a point. But this, at the same time, makes the book uninteresting, perhaps even useless, for those people who want to do the bleeding edge, want to make the new GMail ("for godssakes, people expect the whole page to refresh when they open a new mail!") or Google Maps ("the users will never figure out that you can actually drag on a canvas. Use the traditional directional arrow navigation buttons instead").
The book will give you a complete tour around the safe comfort zone of proven site elements. If you follow the book precisely, I'm sure you will produce a website that works very well, is pleasant to use, and keeps the visitor's interest. But you probably won't get to introduce the next web convention, either.
The third book, another management book: Managing Humans
by Michael Lopp, aka. Rands.Out of the three management books I've read (Joel on Software
, Peopleware and this one), I must confess, this is the best of them.Peopleware was very informative, credible and authoritative, but utterly useless for me as a non-manager. Joel on Software got me to understand the workings of a manager, what they do, how to interact with them, what to expect of them, and other more down-to-earth aspects of managers. Managing Humans is even more so.
As Joel on Software, Managing Humans is a compilation of articles from a blog. I haven't followed Rands in Repose so much that I could say whether everything is out of the blog, or if there is original text included too. But that doesn't matter. The book is excellently written, and there's really only one part that gives away the fact, that not everything is written for that book specifically.
Lopp has the ability to write as if the reader was his best friend. While you know he knows his stuff, and you respect his experience, he cuts the corporate bullshit, and tells how things really are, in a way no-one else would dare to confess to be thinking. He knows that most people don't actually enjoy meetings. He recognizes the existence of managementese, a modification of the language that sounds like real talk, but is nigh to unintelligible, and also feels ashamed of himself whenever he uses it.
He can play both sides of the board at the same time. First he describes a scenario in general, and then he goes inside each person's head present in that fictious setting. I stared in awe, when he described the Nerd in the Cave, a perfect description of my working environment, my mindset while at the computer and myself. He points out the (now) obvious existence of Incrementalists & Completionists (completionist here, hello!). I could go on and on.
If you work in a company, develop software, have a boss you want to understand, have a team to understand, or want to understand how you behave yourself, this is the book to have a look at. I guarantee that you will find yourself inside in more variants than you previously thought possible. And don't be scared, even this book is a management book. It's only partly so, and there's a whole chapter on being a normal employee. After all, managers all have managers of their own, and in the end of the day, we all come to work and leave work (sooner and later, probably respectively).
As a quick bonus, I'm in the progress of reading Made to Stick
by Chip and Dan Heath.I'm not going to give even a micro review about this book, as I haven't yet completed it, and more because I started reading on it too long ago to remember detailed points about it. But, all in all, it's a book about how to make your points more memorable; if you have something to say, how to make people remember it better and longer.
This, too, has to do with practical psychology, and relates to both How To Win Friends and Don't Make Me Think. These three books actually overlap each other in some certain ways, and say the same things with different words and examples. For example, one statement that all three books make is the fact that your target audience (be it your friend, your website visitor or presentation listener) does not really care about what you care. They care about what they care. They are not interested in what you are interested in. They interest themselves in their own interests.
Anyhow: A book that I can recommend to anyone who makes a pitch, a presentation or gives any kind of information that you want people to remember even after the immediate moment they heard it.
I could've done separate posts for each book. But I couldn't be bothered.
Oh, and nothing new in the lightern front. It's still in a standstill. Our wedding preparations are all behind us, we're back from our honeymoon, but we now have an apartment that needs a monthful-and-then-some of fixing.
Friday, August 29, 2008
Noselead
I'm probably the easiest person to be persuaded, given a good set of credible arguments. I think the culprit might be in that I try to be open minded by everything, and think about stuff from as many aspects as possible, and not taking a ridiculously hard stance about a thing, just because "it's my opinion".
I just read the blog post How To Launch Software. Unsurprisingly, it got me to Think about LightFrame's launch. I realize that I've thought of doing both – first showing (read: force) it to some people I know to get the initial wrinkles ironed out, and once this 'beta period' is complete, I'd go all out and try to get as much visibility as possible.
But, as I've also realized for myself, this is extremely stupid to do, since I'm doing this by myself right now, and can't assume that I'd get anyone else doing this with me without paying even a nominal amount of compensation. Assuming that LightFrame has a serious bug (wild imagination not required) and people start hitting on it. I'd need to fix it ASAP. But since my LightFrame-time is very limited, my response time is insufficient, so before I get it fixed, the eyeballs are gone, and LightFrame's back to obscurity, with added buggy reputation.
"Yeah, I tried LightFrame, but it was buggy, so I didn't bother. CakePHP works better for me" is a quote I don't want to see. I'm aiming more towards "Yeah, I tried LightFrame, but it was a bit immature. I like the ideas behind the O/R mapper, but I'll stick to CodeIgniter for now."
Resources (time and money mostly) taken into account, the natural growth path would serve me and my mental sanity better.
I just read the blog post How To Launch Software. Unsurprisingly, it got me to Think about LightFrame's launch. I realize that I've thought of doing both – first showing (read: force) it to some people I know to get the initial wrinkles ironed out, and once this 'beta period' is complete, I'd go all out and try to get as much visibility as possible.
But, as I've also realized for myself, this is extremely stupid to do, since I'm doing this by myself right now, and can't assume that I'd get anyone else doing this with me without paying even a nominal amount of compensation. Assuming that LightFrame has a serious bug (wild imagination not required) and people start hitting on it. I'd need to fix it ASAP. But since my LightFrame-time is very limited, my response time is insufficient, so before I get it fixed, the eyeballs are gone, and LightFrame's back to obscurity, with added buggy reputation.
"Yeah, I tried LightFrame, but it was buggy, so I didn't bother. CakePHP works better for me" is a quote I don't want to see. I'm aiming more towards "Yeah, I tried LightFrame, but it was a bit immature. I like the ideas behind the O/R mapper, but I'll stick to CodeIgniter for now."
Resources (time and money mostly) taken into account, the natural growth path would serve me and my mental sanity better.
Monday, August 18, 2008
Discrimination of Character
Java, if anything, is the spokesthingy for UTF8. NetBeans IDE is written in Java. So why the heck is the default character encoding for files in NetBeans anything other than UTF8 (I'm guessing ISO Latin 9 or something similar). In fact, you can't even change that in the settings. No, you have to go to a config file, and enter "-J-Dfile.encoding=UTF-8" by hand in a config line. WHAT!? WHY!? That's right. Monumental. Foundering.
Apart from that and the fact that scrolling the source code down with a scrollwheel is strangely slow, NetBeans 6.5 shows a lot of potential in the PHP front of things. Code completion, PHPDoc recognition, even code mistake hints, it's all good. Oh, but I do miss my Cmd-D and Alt-up/down, even if I can live without them.
LightFrame is in the back burner. Not forgotten, not suspended, but I'm simply not trying to find time/energy/inspiration for it. If I happen to find any of the three, I'll try to write a line or two, but it's not systematic. With a wedding coming up, in which I play a somewhat central role, the imminent honeymoon thereafter and an ensuing of reparations/restorations of a certain and recently aquired terraced house, I'm wondering whether the not-actually-at-all-official release date of 01.01.09 will hold.
But, once the fixer-upper is fixed-upped, I finally get my own study, with my own pseudo-privacy. Maybe that's when I start really churning forth the code.
Apart from that and the fact that scrolling the source code down with a scrollwheel is strangely slow, NetBeans 6.5 shows a lot of potential in the PHP front of things. Code completion, PHPDoc recognition, even code mistake hints, it's all good. Oh, but I do miss my Cmd-D and Alt-up/down, even if I can live without them.
LightFrame is in the back burner. Not forgotten, not suspended, but I'm simply not trying to find time/energy/inspiration for it. If I happen to find any of the three, I'll try to write a line or two, but it's not systematic. With a wedding coming up, in which I play a somewhat central role, the imminent honeymoon thereafter and an ensuing of reparations/restorations of a certain and recently aquired terraced house, I'm wondering whether the not-actually-at-all-official release date of 01.01.09 will hold.
But, once the fixer-upper is fixed-upped, I finally get my own study, with my own pseudo-privacy. Maybe that's when I start really churning forth the code.
Sunday, August 17, 2008
NetBeans 6.5
NetBeans 6.5 beta shows some promising stuff. The PHP stuff has taken huge advances since the 6.0.1 version I tested a few months back. For one, it's officially supported out-of-the-box, no 3rd party add-on required. Neat.
I'll start using it for the time being. There's one bug I've already noticed, but that's not too bad. I'll probably give my thoughts once the beta stops being beta.
Monday, August 4, 2008
Fixed Some Hosting
I just talked to our CEO and got fixed some virtual server hosting, all compliments of the firm. Nice.
I'm planning to set up a "community website" there. This would mean an online user manual, forums, some news and a blog replacing this temporary (*cough*) one. To give the NIH syndrome a whole new dimension, I'm planning to write these from bottom up on top of LightFrame. This serves a dual purpose: For one, it would showcase what the framework can do. I have even planned to have those components open sourced, providing them as "snap-in plugins". But this would also be (another) real world use case, making sure that LightFrame lacks nothing a non-trivial website requires.
After all, it would be quite hypochritical to claim LightFrame to be worthy of the developers' time, but not using it myself, should it suck.
But more on this later on. This is a totally separate project; I have 800 lines of PHP code to rewrite first.
I'm planning to set up a "community website" there. This would mean an online user manual, forums, some news and a blog replacing this temporary (*cough*) one. To give the NIH syndrome a whole new dimension, I'm planning to write these from bottom up on top of LightFrame. This serves a dual purpose: For one, it would showcase what the framework can do. I have even planned to have those components open sourced, providing them as "snap-in plugins". But this would also be (another) real world use case, making sure that LightFrame lacks nothing a non-trivial website requires.
After all, it would be quite hypochritical to claim LightFrame to be worthy of the developers' time, but not using it myself, should it suck.
But more on this later on. This is a totally separate project; I have 800 lines of PHP code to rewrite first.
Sunday, August 3, 2008
LightFrame Forever
I'm seeing (first hand) what kind of decisions has made the next Duke Nukem as late as it currently is.
Monday, July 28, 2008
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...
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...
Wednesday, July 23, 2008
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.
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.
Sunday, July 20, 2008
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...
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...
Friday, July 18, 2008
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.
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.
Saturday, July 5, 2008
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.
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.
Sunday, June 29, 2008
Assembla is Acting Up
Assembla is acting up. I keep getting, at random, certain server error messages about gateways running around, sheriking and holding their hats on their head firmly with their hands (or something).
This is why I would want a public server on my own, where I could do the development and also have a public facade on the side. And I will have one, once I get the code mature enough to do the public facade with it. Oh, and when I find one for next-to-nothing.
This is why I would want a public server on my own, where I could do the development and also have a public facade on the side. And I will have one, once I get the code mature enough to do the public facade with it. Oh, and when I find one for next-to-nothing.
Tuesday, June 24, 2008
The Discreetest of Hints
I got this link from one of my most reliable readers: http://diffle-history.blogspot.com/ (titled Diary of a Failed Startup). I wonder what he meant by that link...
On a more serious note, though, even after only hastily skimming through the posts, it points out many excellent topics. I felt a stab at my heart on numerous occasions, a majority of those related directly to my project.
Be how it may, I seriously believe that, while an educating tale, it doesn't predict anything of the fate of LightFrame. Without arguing it too deeply, the two main points should suffice:
1. I have no interests in building a start-up around LightFrame.
LightFrame is 'just another project' - if I wouldn't work on LightFrame, I would work on something other, something that would be more trivial, fun, and insignificant. If it succeeds, I'll buy everyone a round (from my own pocket, not from venture capital). If it doesn't succeed, it'll still look pretty in my CV.
To be honest, I'm probably as poor a businessman as they come. I have thought about it, but I still can't find a feasible business angle out of this. The only thing I've come up with is consulting gigs, but how fun would that be? Not very. No, I'll try the Google way; first I try to scrounge as many eyes as possible, and if I get them, only then (if ever) I'll start looking into possible business angles.
2. I have all the time in the world
The aforementioned blog's latest (and presumably last) post states the following: "If your idea starts with 'We're building a platform to...' and you don't have a billion dollars in capital, find a new idea. Now." It is mentioned later on that this refers to an estimation where start-ups have 6 months to make it or break it. I don't have that schedule. In fact, those 6 months have just about passed already, and I still don't have the bottom line in the red.
I'm not saying that I don't have ambitions towards LF. I've already gone through the stages in my mind that have lead to thoughts of world domination. Today, I'm back to where I'll settle for a handful of people interested in using it. I'm not in the search of billions of euros. I just want to do something that other people might find useful. Hell, when the time is right, I might even strive for some headlines for 15 blinks-of-an-eye of fame. But not today. Not even tomorrow.
I have no plans, no schedule and no budget. This, some people actually call a good place to be at.
On a more serious note, though, even after only hastily skimming through the posts, it points out many excellent topics. I felt a stab at my heart on numerous occasions, a majority of those related directly to my project.
Be how it may, I seriously believe that, while an educating tale, it doesn't predict anything of the fate of LightFrame. Without arguing it too deeply, the two main points should suffice:
1. I have no interests in building a start-up around LightFrame.
LightFrame is 'just another project' - if I wouldn't work on LightFrame, I would work on something other, something that would be more trivial, fun, and insignificant. If it succeeds, I'll buy everyone a round (from my own pocket, not from venture capital). If it doesn't succeed, it'll still look pretty in my CV.
To be honest, I'm probably as poor a businessman as they come. I have thought about it, but I still can't find a feasible business angle out of this. The only thing I've come up with is consulting gigs, but how fun would that be? Not very. No, I'll try the Google way; first I try to scrounge as many eyes as possible, and if I get them, only then (if ever) I'll start looking into possible business angles.
2. I have all the time in the world
The aforementioned blog's latest (and presumably last) post states the following: "If your idea starts with 'We're building a platform to...' and you don't have a billion dollars in capital, find a new idea. Now." It is mentioned later on that this refers to an estimation where start-ups have 6 months to make it or break it. I don't have that schedule. In fact, those 6 months have just about passed already, and I still don't have the bottom line in the red.
I'm not saying that I don't have ambitions towards LF. I've already gone through the stages in my mind that have lead to thoughts of world domination. Today, I'm back to where I'll settle for a handful of people interested in using it. I'm not in the search of billions of euros. I just want to do something that other people might find useful. Hell, when the time is right, I might even strive for some headlines for 15 blinks-of-an-eye of fame. But not today. Not even tomorrow.
I have no plans, no schedule and no budget. This, some people actually call a good place to be at.
Tuesday, June 17, 2008
A Bug as a Feature
The tip of the day: If you want your days to fly by, without noticing, without getting anything constructive done, go and buy yourself a current generation game console. I mean, sheesh. I bought a PS3 last Saturday, and all free time I've scrounged together has been spent on playing various games.
I finally got the annoying bug from my previous post fixed (unsurprisingly, this was actually before I bought the console). It turned out to be much less of a hassle than I thought, and the multitag code more elegant than I remembered. Maybe I should look at my old code more often, huh? But the bug was a huge weight off my shoulders. I can only guess why I took the bug so heavily. Perhaps I'm too set on working through tickets until I get to the first release. And I had a revelation.
Treating bugs as setbacks, mishaps or deviations from the normal programme is the wrong approach. Ever heard of the claim about there being one error in every thousand lines of code. After searching the vastness of reliable sources (read: googled about for a few minutes), I've noticed that this estimate seems to be a bit cautious. Some sources talk about 20-50 bugs per KLOC when doing your average coding, down to just below one bug per KLOC if doing stuff properly (formal methods and such) or even zero bugs in 500KLOC if you're NASA. But, take the very respective 1 bug/KLOC rule-of-thumb - LightFrame would have by that measurement alone around 7 bugs (which must be a dramatic underestimation). So, getting towards my point, it's pretty much inevitable, unless you are going to great lengths to counteract this, to have bugs in your code.
So why is it a blow to the head when a major (or even minor) bug surfaces? It should be treated as a speical kind of feature. A feature that just needs a little more tweaking. After all, everyone should take into account a testing period for any larger programming task. It shouldn't be regarded as a setback. It should be regarded as a chance to make your software that much better and take lesson of the bug, try to remember what went wrong for the next time when you're programming something similar. This isn't even all that big of a detour or "waste of time" when using the Zero Defects methodology.
Time for a shower and then some ticket-reaming!
I finally got the annoying bug from my previous post fixed (unsurprisingly, this was actually before I bought the console). It turned out to be much less of a hassle than I thought, and the multitag code more elegant than I remembered. Maybe I should look at my old code more often, huh? But the bug was a huge weight off my shoulders. I can only guess why I took the bug so heavily. Perhaps I'm too set on working through tickets until I get to the first release. And I had a revelation.
Treating bugs as setbacks, mishaps or deviations from the normal programme is the wrong approach. Ever heard of the claim about there being one error in every thousand lines of code. After searching the vastness of reliable sources (read: googled about for a few minutes), I've noticed that this estimate seems to be a bit cautious. Some sources talk about 20-50 bugs per KLOC when doing your average coding, down to just below one bug per KLOC if doing stuff properly (formal methods and such) or even zero bugs in 500KLOC if you're NASA. But, take the very respective 1 bug/KLOC rule-of-thumb - LightFrame would have by that measurement alone around 7 bugs (which must be a dramatic underestimation). So, getting towards my point, it's pretty much inevitable, unless you are going to great lengths to counteract this, to have bugs in your code.
So why is it a blow to the head when a major (or even minor) bug surfaces? It should be treated as a speical kind of feature. A feature that just needs a little more tweaking. After all, everyone should take into account a testing period for any larger programming task. It shouldn't be regarded as a setback. It should be regarded as a chance to make your software that much better and take lesson of the bug, try to remember what went wrong for the next time when you're programming something similar. This isn't even all that big of a detour or "waste of time" when using the Zero Defects methodology.
Time for a shower and then some ticket-reaming!
Sunday, June 8, 2008
Bug(ger)
I found a bug in the multi-part tagging. This isn't all that surprising, as multi-tags are just a big old ulgy hack. I should've incorporated native support for them to begin with and not just hack them together. These kinds of stupid mistakes make me always so deflated in this project. Would another remotely competent developer have taken a smallest peek at the code I wrote for the if-clause, they would've seen the problem.
But the problem isn't in the fact that I found a bug. Finding bugs are good (when the alternative would be to leave the bugs unnoticed. Not having bugs in the first place would be even better, of course). The bigger problem here is that I'm trying to get LF into a decent shape, so that I can show it to others. Naturally, I want it to be as good as I envision it to be and the only way I can be certain of how it really ends up feeling like, is by eating my own dog food. And, boy, have I been crunching that dog food, and, to be honest, LightFrame doesn't taste as yummy as I'd like it to. And this is what bothers me:
Since I've been working on this project for... I honestly don't know for how long. It's probably over half a year. So, I've worked on this for over six months, and I've seen the project mature and come this far. It has come so far, that it's beginning to become actually usable for something real. It's not quite there yet, but once it's there, I'm able to showcase it to people. The day I'm able to do so is drawing so near, so that I can see it. But setbacks like these - finding a bug that affects the overall usability, just push that date back by about a week. I'm only being realistic here, as I am able to work only a handful of hours a week on this project.
It would be so nice if I could just shove my fingers in my ears, shout "la la la" as hard as I can, continue to finish the rest of the tickets I have planned for the current milestone, put everything in a neat little package, and offer it to everyone I can find and urge them to test it out. But I can't do that. I can't do that, because the framework would be crap, nobody would use it, and the possible wow-factor is lost.
I see that LightFrame has only one chance to make a good first impression. The first impression needs to show clearly what it will be able to do. This absolutely does not mean that it can do everything then and now, from day one, but it has to be able to give a clear image of the future. Whatever the framework can do on day one, it needs to be spotless and damn nearly perfect. If it can't handle a many-to-many relationship between two models, it's fine. It will eventually be included. As LF already supports Models, it's not hard to imagine how it would feel like to use new relationships. But if a nesting error in tags occurs - well, that's just unforgivable. It's a half-assed job.
So, to draw the full circle here: I don't want to do a half-assed job with LightFrame. Half assing would basically mean leaving stupid bugs in the code. I am in the process of eliminating such bugs by using LightFrame myself for some of LightFrame's internal stuff, and this is probably the best way of finding the usability bugs - to use the product as it would normally be used. Each time I find a bug, I need to fix it. Fixing it, depending on how rooted in the system it is, takes a good amount of time. Fixing bugs is time off from finishing the current milestone, which, in turn, means more postponing. Postponing is something I can't bear to see happen, when the project is SO close to being worthy of showcasing.
Update 9.6.08: ok, so the problem isn't with the multipart tags, but with nesting any two kinds of a kind. It's kind of a relief - maybe.
But the problem isn't in the fact that I found a bug. Finding bugs are good (when the alternative would be to leave the bugs unnoticed. Not having bugs in the first place would be even better, of course). The bigger problem here is that I'm trying to get LF into a decent shape, so that I can show it to others. Naturally, I want it to be as good as I envision it to be and the only way I can be certain of how it really ends up feeling like, is by eating my own dog food. And, boy, have I been crunching that dog food, and, to be honest, LightFrame doesn't taste as yummy as I'd like it to. And this is what bothers me:
Since I've been working on this project for... I honestly don't know for how long. It's probably over half a year. So, I've worked on this for over six months, and I've seen the project mature and come this far. It has come so far, that it's beginning to become actually usable for something real. It's not quite there yet, but once it's there, I'm able to showcase it to people. The day I'm able to do so is drawing so near, so that I can see it. But setbacks like these - finding a bug that affects the overall usability, just push that date back by about a week. I'm only being realistic here, as I am able to work only a handful of hours a week on this project.
It would be so nice if I could just shove my fingers in my ears, shout "la la la" as hard as I can, continue to finish the rest of the tickets I have planned for the current milestone, put everything in a neat little package, and offer it to everyone I can find and urge them to test it out. But I can't do that. I can't do that, because the framework would be crap, nobody would use it, and the possible wow-factor is lost.
I see that LightFrame has only one chance to make a good first impression. The first impression needs to show clearly what it will be able to do. This absolutely does not mean that it can do everything then and now, from day one, but it has to be able to give a clear image of the future. Whatever the framework can do on day one, it needs to be spotless and damn nearly perfect. If it can't handle a many-to-many relationship between two models, it's fine. It will eventually be included. As LF already supports Models, it's not hard to imagine how it would feel like to use new relationships. But if a nesting error in tags occurs - well, that's just unforgivable. It's a half-assed job.
So, to draw the full circle here: I don't want to do a half-assed job with LightFrame. Half assing would basically mean leaving stupid bugs in the code. I am in the process of eliminating such bugs by using LightFrame myself for some of LightFrame's internal stuff, and this is probably the best way of finding the usability bugs - to use the product as it would normally be used. Each time I find a bug, I need to fix it. Fixing it, depending on how rooted in the system it is, takes a good amount of time. Fixing bugs is time off from finishing the current milestone, which, in turn, means more postponing. Postponing is something I can't bear to see happen, when the project is SO close to being worthy of showcasing.
Update 9.6.08: ok, so the problem isn't with the multipart tags, but with nesting any two kinds of a kind. It's kind of a relief - maybe.
Wednesday, June 4, 2008
Damnation and Pains
So, I have a slept myself a neck pain. It's not one of those *stretch* "ow!" *rub neck* *continue with breakfast* neck pains, but one of those that make you leave from work in the middle of the day to go "ow ow ow" at each body movement. Free hint: Muscle relaxants and ibuprofen painkillers do help - a bit.
Anyhow. While I've been taking a sabbatical from programming (more or less forced, I haven't had full nights to bother to start focusing on programming), I've been daydreaming about LightFrame's future. How I will get more than one developer to the community, how it might hit webmag headers after enough pleading, etc. I've come to the consensus that the next fancy step towards ubiquityare pens and letterhead is a logo.
So I fired up Photoshop (I don't know Illustrator well enough), stared at a blank canvas for a while and then started to do what I always do to get started: Write the name as a layer, scroll through different fonts and pick the one that seems to look the best while still 'looking the part'. Eventually, I came up with four variants of the same idea:
So these are just some rough black&white sketches, just to get an idea to get further with. Only later on would the colors and additional eye-candy would be applied. So, if you have an opinion, leave a comment. If you have ideas on how to modify these, leave a comment. If you have some spare time and feel like contributing, I'd be thrilled to get more ideas (and they don't need to be based on these sketches.
This was yesterday. Now I'll stop writing, and keep on stretching my neck, so that I can live through this day.
Anyhow. While I've been taking a sabbatical from programming (more or less forced, I haven't had full nights to bother to start focusing on programming), I've been daydreaming about LightFrame's future. How I will get more than one developer to the community, how it might hit webmag headers after enough pleading, etc. I've come to the consensus that the next fancy step towards ubiquity
So I fired up Photoshop (I don't know Illustrator well enough), stared at a blank canvas for a while and then started to do what I always do to get started: Write the name as a layer, scroll through different fonts and pick the one that seems to look the best while still 'looking the part'. Eventually, I came up with four variants of the same idea:
So these are just some rough black&white sketches, just to get an idea to get further with. Only later on would the colors and additional eye-candy would be applied. So, if you have an opinion, leave a comment. If you have ideas on how to modify these, leave a comment. If you have some spare time and feel like contributing, I'd be thrilled to get more ideas (and they don't need to be based on these sketches.This was yesterday. Now I'll stop writing, and keep on stretching my neck, so that I can live through this day.
Sunday, June 1, 2008
Finished the Book
I finished Joel On Software a few hours ago. If you haven't read it and are even the littlest bit interested in how software creation could be managed. It could even be a manual on how it should be managed, but don't take my word for it. Most of what he said (apart of the one-tester-per-two-developers ratio) makes very much sense to me.
But I won't go in to details, as I would only dilute the punchlines he has to offer. Great read and , unless you can't stomach the possibility that this book might give you the idea that the developers at Microsoft actually aren't total asshats, a very recommended read at that.
But I won't go in to details, as I would only dilute the punchlines he has to offer. Great read and , unless you can't stomach the possibility that this book might give you the idea that the developers at Microsoft actually aren't total asshats, a very recommended read at that.
Saturday, May 31, 2008
Coma, Books, Financial Freedom and stuff
I haven't got anything done for LightFrame in a while. Or, rather, the codebase has not been touched in a while, not to talk about the Assembla repository which has been outdated for about a month now. But I haven't neglected it entirely. I have done some ticket-management and updated the wiki. And then there's all kind of planning going when my brains go to idle-mode.
And then there's this damn book I've been reading - Joel on Software by the same Joel Spolsky I mentioned in my previous post, which just seems to suck in all the free time I have. The book is a collection of essays from his blog, which are great in their own right, but when collected in to a hand-held physical book, the information value is even greater than the sum of the parts.
The book is mostly about how not to create software, with a corporate angle. It might sound like a boring business manual for MBA's, which it absolutely is not. Anyhow, even though I have decided not to start a company for LightFrame (thanks to Ville for giving some precious insight about this!), I do feel that the book might help the project. Although I probably never will make any money out of LightFrame, I still want it to be successful and get adopted as widely as possible. It does have well-established competitive products that it has to better, and I would like nothing better to eventually have LightFrame as the PHP web framework (although I would be just as ecstatic to have LF recognized along with the other big boys).
Not having any money involved is probably one of the most liberating things possible - even if nobody would ever hear of LightFrame, I have not lost anything. I can't even say that I have lost my free time, because I would still have done my personal projects for myself, by myself. I might lose my face if I do some humongous mistakes somewhere along the way, but that requires LF to gain an audience first, which is already one of the primary goals. So doing this is not a very bad deal for me at all.
Then the LightFrame status report: As said, LF's code hasn't evolved that much during the past days. That's because I had to get the first real project based on LF done, as the deadline was closing in. I hadn't the time to get everything done properly via LightFrame, so I had to do some old-school PHP solutions at some places. But (once I finish reading the book, which should be any day now) development will once again ensue.
I'm franticly trying to get all the tickets done for the Development Release 1 -milestone, so that I can declare a feature freeze (which is just around the corner) and concentrate on churning the code to completion. Once the milestone is reached, I have some other plans, like taking a pause on coding on LightFrame, and doing some other things I have planned that hopefully benefit LightFrame.
But not this weekend. I'm going to take a weekend off of everything and anything and just have a jolly good time, enjoying the summer. I recommend you doing the same.
And then there's this damn book I've been reading - Joel on Software by the same Joel Spolsky I mentioned in my previous post, which just seems to suck in all the free time I have. The book is a collection of essays from his blog, which are great in their own right, but when collected in to a hand-held physical book, the information value is even greater than the sum of the parts.
The book is mostly about how not to create software, with a corporate angle. It might sound like a boring business manual for MBA's, which it absolutely is not. Anyhow, even though I have decided not to start a company for LightFrame (thanks to Ville for giving some precious insight about this!), I do feel that the book might help the project. Although I probably never will make any money out of LightFrame, I still want it to be successful and get adopted as widely as possible. It does have well-established competitive products that it has to better, and I would like nothing better to eventually have LightFrame as the PHP web framework (although I would be just as ecstatic to have LF recognized along with the other big boys).
Not having any money involved is probably one of the most liberating things possible - even if nobody would ever hear of LightFrame, I have not lost anything. I can't even say that I have lost my free time, because I would still have done my personal projects for myself, by myself. I might lose my face if I do some humongous mistakes somewhere along the way, but that requires LF to gain an audience first, which is already one of the primary goals. So doing this is not a very bad deal for me at all.
Then the LightFrame status report: As said, LF's code hasn't evolved that much during the past days. That's because I had to get the first real project based on LF done, as the deadline was closing in. I hadn't the time to get everything done properly via LightFrame, so I had to do some old-school PHP solutions at some places. But (once I finish reading the book, which should be any day now) development will once again ensue.
I'm franticly trying to get all the tickets done for the Development Release 1 -milestone, so that I can declare a feature freeze (which is just around the corner) and concentrate on churning the code to completion. Once the milestone is reached, I have some other plans, like taking a pause on coding on LightFrame, and doing some other things I have planned that hopefully benefit LightFrame.
But not this weekend. I'm going to take a weekend off of everything and anything and just have a jolly good time, enjoying the summer. I recommend you doing the same.
Monday, May 19, 2008
Stackoverflow
Now for something completely offtopic:
I just want to give a quick nod to Joel Spolsky (if only I had more time to concentrate on his essays) and Jeff Attwood and their stackoverflow.com 'podcast' (although it's just an mp3-file that is attached to a blog post). Highly recommended listening, by the way. There's worse ways of spending an hour (per episode) of your life.
Having the time (the insomniac that I am) listening through the latest entries, I get warm feelings when Spolsky is surprised that people actually are hired and paid differently at some places according to their degree. I mean, I couldn't agree more when Attwood mentioned that he didn't like college and the "learning how to learn" thing. Seems like both Attwood and Spolsky agree that, while degrees are not useless, what you actually are able to do plays a bigger role in what you are worth, careerwise.
I tip my hat to those words and feel delighted. I strongly recommend following the weekly entries. Also, if you for some strange reason haven't read articles on joelonsoftware.com but have managed to find this blog, you have got things totally backwards. Stop reading mine and start reading his. Now.
LightFrame is still alive and kicking. No worries there.
I just want to give a quick nod to Joel Spolsky (if only I had more time to concentrate on his essays) and Jeff Attwood and their stackoverflow.com 'podcast' (although it's just an mp3-file that is attached to a blog post). Highly recommended listening, by the way. There's worse ways of spending an hour (per episode) of your life.
Having the time (the insomniac that I am) listening through the latest entries, I get warm feelings when Spolsky is surprised that people actually are hired and paid differently at some places according to their degree. I mean, I couldn't agree more when Attwood mentioned that he didn't like college and the "learning how to learn" thing. Seems like both Attwood and Spolsky agree that, while degrees are not useless, what you actually are able to do plays a bigger role in what you are worth, careerwise.
I tip my hat to those words and feel delighted. I strongly recommend following the weekly entries. Also, if you for some strange reason haven't read articles on joelonsoftware.com but have managed to find this blog, you have got things totally backwards. Stop reading mine and start reading his. Now.
LightFrame is still alive and kicking. No worries there.
Sunday, May 18, 2008
Ads-Away
In case someone sees the difference, I've got rid of the ads from this blog. They were senseless from the start. I just wanted to check if adsense was a way to get rich without doing anything. Clearly, it wasn't.
Epic Update Fail
I seem to have neglected this blog, which has not been the purpose at all.
The downtime in activity on this blog is just a cause of time prioritizing. As I've started a day job programming stuff, my juices run low at the end of the day. So I squeeze everything I have into actually getting LightFrame some meat around its bones. In other words, the project is alive and pretty well.
To give a rundown of the recent events, I'm still working on the actual website that runs on LightFrame. Things go along a bit sluggishly, as I implement the missing stuff as I go. Currently I'm doing a generic CRUD that I could use as an admin page for the project, and it's coming along surprisingly nicely. The website is nearing completion, so once it is ready and out of my hair, I can concentrate on getting LightFrame towards Developer Release 1.
To see what I'm up to, you should take a look at the Assembla project space. What I'm doing there is posting tickets (todos mostly) and updating them as I make progress. The wiki is also something to take a look at, as I'm dumping my brain there as I see fit. It's not yet complete, and is still desynchronized with the Google Code wiki, which is a shame (and a low-priority, too). The Git repository found at Assembla is updated very rarely. I'll push something once I get something half-decent and working. Most probably after I clean up some code once I get some new features polished and done that have risen from the current web project.
To sum it up, the pace has slowed down a bit, but I'm still allocating everything I've got to LightFrame. It inches forward, and I have every intention to get it in a publishable shape.
I'm confident that once I get Developer Release 1 out, the framework gets its first group of persons I dare call an 'audience'. This leads to feedback, which leads to constructive development, which leads to better quality, which leads to a larger audience and we have a benign cycle on our hands here. But before I start conquering the world, I better start with my own back yard. Actually, I'll start with my bed.
The downtime in activity on this blog is just a cause of time prioritizing. As I've started a day job programming stuff, my juices run low at the end of the day. So I squeeze everything I have into actually getting LightFrame some meat around its bones. In other words, the project is alive and pretty well.
To give a rundown of the recent events, I'm still working on the actual website that runs on LightFrame. Things go along a bit sluggishly, as I implement the missing stuff as I go. Currently I'm doing a generic CRUD that I could use as an admin page for the project, and it's coming along surprisingly nicely. The website is nearing completion, so once it is ready and out of my hair, I can concentrate on getting LightFrame towards Developer Release 1.
To see what I'm up to, you should take a look at the Assembla project space. What I'm doing there is posting tickets (todos mostly) and updating them as I make progress. The wiki is also something to take a look at, as I'm dumping my brain there as I see fit. It's not yet complete, and is still desynchronized with the Google Code wiki, which is a shame (and a low-priority, too). The Git repository found at Assembla is updated very rarely. I'll push something once I get something half-decent and working. Most probably after I clean up some code once I get some new features polished and done that have risen from the current web project.
To sum it up, the pace has slowed down a bit, but I'm still allocating everything I've got to LightFrame. It inches forward, and I have every intention to get it in a publishable shape.
I'm confident that once I get Developer Release 1 out, the framework gets its first group of persons I dare call an 'audience'. This leads to feedback, which leads to constructive development, which leads to better quality, which leads to a larger audience and we have a benign cycle on our hands here. But before I start conquering the world, I better start with my own back yard. Actually, I'll start with my bed.
Monday, April 28, 2008
Holy Spaghetti Monster, Batman!
I must've been converted to a Pastafarian along the way, but I must say, my code looks and is 'orrible.
I thought to convert my SQL abstraction (not the ORM part) from native functions to PDO, which is PHP's own data-access abstraction. I simply noticed that Models and that sql.php is way too intertwined. But I'm the first to admit that my code is a mess, but I'm partly blaming the differences between RDMBS:es.
Nevertheless, I'm starting to think that I've chomped into something too big to swallow. If I ever want to release a first official release, even if it would be a developer release, I need to dumb down the framework - cut out features - or I'll end up rewriting the code 'till my fingers bleed. So, yes, despair is on the rise. It feels like I'm treading water but just sinking deeper by each kick.
It would be SO neat to get a release on LightFrame. A working release, that, while maybe crude, would be a working framework with a rigid set of features. UMTV, ORM, all kinds of buzzwords. Heck, maybe even get PHP's name out of the mud (although I might, now, have something to say about this).
Maybe a good pause in coding (again) would do the trick. I could browse the code, see what could be done better (yes yes, my coding methodology bit me in the ass. Har. Har.) and just post tickets for a while.
Crap. I need to be up in a few hours. I need an off-switch...
I thought to convert my SQL abstraction (not the ORM part) from native functions to PDO, which is PHP's own data-access abstraction. I simply noticed that Models and that sql.php is way too intertwined. But I'm the first to admit that my code is a mess, but I'm partly blaming the differences between RDMBS:es.
Nevertheless, I'm starting to think that I've chomped into something too big to swallow. If I ever want to release a first official release, even if it would be a developer release, I need to dumb down the framework - cut out features - or I'll end up rewriting the code 'till my fingers bleed. So, yes, despair is on the rise. It feels like I'm treading water but just sinking deeper by each kick.
It would be SO neat to get a release on LightFrame. A working release, that, while maybe crude, would be a working framework with a rigid set of features. UMTV, ORM, all kinds of buzzwords. Heck, maybe even get PHP's name out of the mud (although I might, now, have something to say about this).
Maybe a good pause in coding (again) would do the trick. I could browse the code, see what could be done better (yes yes, my coding methodology bit me in the ass. Har. Har.) and just post tickets for a while.
Crap. I need to be up in a few hours. I need an off-switch...
Sunday, April 27, 2008
OutOfJuiceException
Oh, gods. If you don't have a life, do yourself a favor and don't get one or at least postpone it as much as you can.
So, I started my new job on Wednesday. The great thing about this job is that we have no work horus. Sure, we have to clock in the usual amount of week-hours, but how and when and in what chunks we do them doesn't matter. So, I decided to be smart and do long days to start with, now that I still have the enthusiasm. Mistake. I've been quite dead since I started.
Not that it would matter. Once I get home, I unwind, get something to eat, act social and then it's already time for bed. Not that this would matter either, as I'm mentally spent after trying to get familiar with the new tools I'm going to fiddle with.
So, no, LightFrame has been at an stand-still for some time now. From what I remember, I'm trying to abstract a boolean datatype for the SQL, which, surprisingly, exists only in PostgreSQL natively. MySQL loves ENUM(), and SQLite doesn't seem to care much. And I've lived in a small fear of the vision of having to rewrite Fields. They're clunky, at best. But at least I can take some pride in having implemented a nicer O/R mapping than what Hibernate seems to be.
So, I started my new job on Wednesday. The great thing about this job is that we have no work horus. Sure, we have to clock in the usual amount of week-hours, but how and when and in what chunks we do them doesn't matter. So, I decided to be smart and do long days to start with, now that I still have the enthusiasm. Mistake. I've been quite dead since I started.
Not that it would matter. Once I get home, I unwind, get something to eat, act social and then it's already time for bed. Not that this would matter either, as I'm mentally spent after trying to get familiar with the new tools I'm going to fiddle with.
So, no, LightFrame has been at an stand-still for some time now. From what I remember, I'm trying to abstract a boolean datatype for the SQL, which, surprisingly, exists only in PostgreSQL natively. MySQL loves ENUM(), and SQLite doesn't seem to care much. And I've lived in a small fear of the vision of having to rewrite Fields. They're clunky, at best. But at least I can take some pride in having implemented a nicer O/R mapping than what Hibernate seems to be.
Monday, April 21, 2008
Character Sets are a Pain
I decided to give this a blog post of its own.
Time for another revelation: Charsets are really a pain in the ass. Correction: Multiple charsets are really a pain in the ass.
As I've mostly done single scripts for myself previously, it really hasn't hit me before. I guess my subconscious has always been aware of the problem, and naturally I've encountered some glitches when transferring stuff from a server to another, correcting them individually without giving it much thought. Only now have I started to realize its utter, shall we say, idiocy.
To give a brief and very redundant recap, charsets (or character sets) are (mostly) a set of mappings between zero/one combinations (bits) and symbols. Each charset has its own idea of which combination of bits represent each symbol. The de-facto charset in the HTML realm is called ISO-8859-1, and all documents are assumed to be of that charset, unless specified otherwise.
Figuratively speaking, the website throws the client a heap of bits, saying that those contain whatever you should read on a website. It also says which set of mappings you should use to interpret those zeros and ones to get the intended text.
So, it's easy to see that if you change either one, the contents of that website changes. If you alter the heap of bits, but still interpret it with the same charset, you get different characters where the bits have changed in the heap. If you change the charset, you change potentially the whole text, and most probably into garbage.
The obvious problems, like knowing which charset a document is, and telling it to the webserver, aside, there's one great problem that really could wreak havoc: If you blindly combine documents of different charsets into one, it's next to impossible to get sensible text out of that. It might sound like a far fetched scenario, but it's not all that obscure.
There are two prevalent charsets in use when it comes to web development, ISO-8859-1 and UTF-8, and those are totally incompatible. Now, imagine that I want to be future proof, and write all my code in UTF-8, as it's more expansive and includes more characters than ISO-8859-1. But then I get another developer that writes all his code in the old standard, ISO-8859-1. It takes only one include-statement, and that's it.
Contain the character set - obvious. Let's say that LightFrame forces everyone to use UTF-8. Ok, that's settled. Then, when LF ships, a user has ISO-8859-1 set, and all his templates look funny. Or vice versa, we use ISO-8859-1, and a user has UTF-8. Either way, it's screwed. If, miraculously, that gets a consensus, along comes a site visitor who's browser says "nuh-uh, I can't/won't read your character encoding". What then?
One solution would be to screw it all, and have the user keep the tabs on stuff. If it doesn't work, it's not my problem. But I wouldn't feel happy about that. LightFrame tries to be the magic wand that fixed the tedious. LF has abstracted SQL, it even has O/R mapping on top of that. It will have user authorization and authentication. In a nutshell, LF is designed to make the developer's life easier. Fixing charsets would definitely make a web developer's life easier.
So, now I'm forced to incorporate text normalization, somehow. Something that would make everything click. Let everyone make a mess out of their code, and still get everything look as it was intended from the start. There are no silver-bullets. LF requires a minimal feature set on the server side, while supporting a much larger feature set. So, PHP does provide two libraries, so a "if you have it, we support it. Otherwise, you're on your own"-approach might be a possibility. But then again, some servers might have one, but not the other. *sigh* I need a lie-down.
I hear that PHP6 is going to take a stab at fixing this, and I tip my hat off for that. But it won't help me, perhaps on the contrary. PHP5 barely has a foothold, as PHP4 still is the prevalent major PHP version out there, so there's no chance that PHP6 gets adopted as soon as I'd like. Not that I would know when PHP6 is scheduled for publication.
Time for another revelation: Charsets are really a pain in the ass. Correction: Multiple charsets are really a pain in the ass.
As I've mostly done single scripts for myself previously, it really hasn't hit me before. I guess my subconscious has always been aware of the problem, and naturally I've encountered some glitches when transferring stuff from a server to another, correcting them individually without giving it much thought. Only now have I started to realize its utter, shall we say, idiocy.
To give a brief and very redundant recap, charsets (or character sets) are (mostly) a set of mappings between zero/one combinations (bits) and symbols. Each charset has its own idea of which combination of bits represent each symbol. The de-facto charset in the HTML realm is called ISO-8859-1, and all documents are assumed to be of that charset, unless specified otherwise.
Figuratively speaking, the website throws the client a heap of bits, saying that those contain whatever you should read on a website. It also says which set of mappings you should use to interpret those zeros and ones to get the intended text.
So, it's easy to see that if you change either one, the contents of that website changes. If you alter the heap of bits, but still interpret it with the same charset, you get different characters where the bits have changed in the heap. If you change the charset, you change potentially the whole text, and most probably into garbage.
The obvious problems, like knowing which charset a document is, and telling it to the webserver, aside, there's one great problem that really could wreak havoc: If you blindly combine documents of different charsets into one, it's next to impossible to get sensible text out of that. It might sound like a far fetched scenario, but it's not all that obscure.
There are two prevalent charsets in use when it comes to web development, ISO-8859-1 and UTF-8, and those are totally incompatible. Now, imagine that I want to be future proof, and write all my code in UTF-8, as it's more expansive and includes more characters than ISO-8859-1. But then I get another developer that writes all his code in the old standard, ISO-8859-1. It takes only one include-statement, and that's it.
Contain the character set - obvious. Let's say that LightFrame forces everyone to use UTF-8. Ok, that's settled. Then, when LF ships, a user has ISO-8859-1 set, and all his templates look funny. Or vice versa, we use ISO-8859-1, and a user has UTF-8. Either way, it's screwed. If, miraculously, that gets a consensus, along comes a site visitor who's browser says "nuh-uh, I can't/won't read your character encoding". What then?
One solution would be to screw it all, and have the user keep the tabs on stuff. If it doesn't work, it's not my problem. But I wouldn't feel happy about that. LightFrame tries to be the magic wand that fixed the tedious. LF has abstracted SQL, it even has O/R mapping on top of that. It will have user authorization and authentication. In a nutshell, LF is designed to make the developer's life easier. Fixing charsets would definitely make a web developer's life easier.
So, now I'm forced to incorporate text normalization, somehow. Something that would make everything click. Let everyone make a mess out of their code, and still get everything look as it was intended from the start. There are no silver-bullets. LF requires a minimal feature set on the server side, while supporting a much larger feature set. So, PHP does provide two libraries, so a "if you have it, we support it. Otherwise, you're on your own"-approach might be a possibility. But then again, some servers might have one, but not the other. *sigh* I need a lie-down.
I hear that PHP6 is going to take a stab at fixing this, and I tip my hat off for that. But it won't help me, perhaps on the contrary. PHP5 barely has a foothold, as PHP4 still is the prevalent major PHP version out there, so there's no chance that PHP6 gets adopted as soon as I'd like. Not that I would know when PHP6 is scheduled for publication.
Change is Inherently Bad
I'm a lazy person. I always try to go the path of least resistance. I beg to notice that "least resistance" doesn't equal to "no resistance", but that's picky.
Anyhow. I'm partly glad that I chose Assembla (crap, I never remember the name). It has all kinds of tools that Google Code simply doesn't provide. But it's a bit messy with its features. Assembla has issues, tasks and a wiki. Now, if I think of something that I want to be done, it's a bit of a puzzle to know where to put it. It would be easy if the wiki would be reserved for brainstorming, issues are for reporting when something goes wrong and needs fixing, and tasks are just stuff to do. But it's not like that. Tasks are stripped issues, and always are associated with a milestone. Issues accept a markup language (think BBCode), but tasks don't. Tasks are easily marked and saved as 'complete' just by ticking a box, which makes tasks seem "light" and not noteworthy. Issues are commented upon, as tasks are replied to. Additionally, tasks are displayed in a "Flow"-section, which I think is supposed to be a list of various message. If you create a new entry in the Flow-section, you create just a message for others to read, with no magic abilities. Also, tasks don't seem to count towards milestone completion, only issues...
In a word, it needs getting used to.
Anyhow. I'm partly glad that I chose Assembla (crap, I never remember the name). It has all kinds of tools that Google Code simply doesn't provide. But it's a bit messy with its features. Assembla has issues, tasks and a wiki. Now, if I think of something that I want to be done, it's a bit of a puzzle to know where to put it. It would be easy if the wiki would be reserved for brainstorming, issues are for reporting when something goes wrong and needs fixing, and tasks are just stuff to do. But it's not like that. Tasks are stripped issues, and always are associated with a milestone. Issues accept a markup language (think BBCode), but tasks don't. Tasks are easily marked and saved as 'complete' just by ticking a box, which makes tasks seem "light" and not noteworthy. Issues are commented upon, as tasks are replied to. Additionally, tasks are displayed in a "Flow"-section, which I think is supposed to be a list of various message. If you create a new entry in the Flow-section, you create just a message for others to read, with no magic abilities. Also, tasks don't seem to count towards milestone completion, only issues...
In a word, it needs getting used to.
Tuesday, April 15, 2008
I'm Ditching Google Code
I'm currently checking out Assembla as an alternative to Google Code. Why? because they don't enforce any licenses upon the projects (although OSS seem to get more leeway when it comes to certain limitations) and most importantly, they support other version control products besides SVN. I'm giving Git a good look. While the tools seem a lot more rough and rugged than SVN's GUI:s, Git seems to get rid of most of the problems I have been having, but all that remains to be seen.
I'm still keeping the Google Code project for a while, and keeping the Assembla one under the cover.
Development updates continue to be posted here, no matter what - for the time being, that is *nudge*.
I'm still keeping the Google Code project for a while, and keeping the Assembla one under the cover.
Development updates continue to be posted here, no matter what - for the time being, that is *nudge*.
...But I'm Still Alive
(oh god, how I love the song)
So, development. It's there, although a bit weak at the time. Lots of non-coding stuff going on. We just got our second puppy (as in dog), which requires its fair share of the free time. Fortunately I've taken the exams I needed for now, so that's over with. Unfortunately, in two weeks, I'm starting my new full-time job. Becoming a code-monkey probably doesn't exactly strengthen the motivation to get your own projects done. I say "probably", but I don't know - time will tell. Oh, and then there's (for some god damned reason) a rekindled interest in Cyberpunk 2.0.2.0 (the pen & paper RPG) and the notice of horrible parts of the ruleset, 'forcing' me to rewrite e.g. the whole netrunning part. *blah blah personal stuff*
On the topic of monkeys, I'm getting one off my back. I'm skipping the rest of the blog project. I've proved myself that it can be done. I've also proved myself that LF needs quite a few more helper things to get the development with LF as smooth an experience as I've envisioned it to be. Instead, I'm getting done a website I actually have need for, that has been suspended for the duration of the development of LightFrame, but can't postpone it much longer. So, while I work on that project, I keep patching up LF where it needs it.
After that, I most probably sit down, take a deep breath, plan some features (mostly built-in views, helpers and either scaffolding or an admin panel) and call a feature freeze. Then begins the tedious task of realizing the missing features and polishing the existing ones. When that's done, some user documentation, followed by Publish! The timeline continues from there, but this is far enough already.
The first publication of LightFrame will be When It's done. I have no producer, therefore I have no deadlines, which leads to no schedule. Ultimate freedom!
But, now you know what to expect: today a measly website, tomorrow the world. Narf.
PS: Do not buy Nokia cellphones. My ~month-old E90 Communicator has been fixed twice and it's still broken.
So, development. It's there, although a bit weak at the time. Lots of non-coding stuff going on. We just got our second puppy (as in dog), which requires its fair share of the free time. Fortunately I've taken the exams I needed for now, so that's over with. Unfortunately, in two weeks, I'm starting my new full-time job. Becoming a code-monkey probably doesn't exactly strengthen the motivation to get your own projects done. I say "probably", but I don't know - time will tell. Oh, and then there's (for some god damned reason) a rekindled interest in Cyberpunk 2.0.2.0 (the pen & paper RPG) and the notice of horrible parts of the ruleset, 'forcing' me to rewrite e.g. the whole netrunning part. *blah blah personal stuff*
On the topic of monkeys, I'm getting one off my back. I'm skipping the rest of the blog project. I've proved myself that it can be done. I've also proved myself that LF needs quite a few more helper things to get the development with LF as smooth an experience as I've envisioned it to be. Instead, I'm getting done a website I actually have need for, that has been suspended for the duration of the development of LightFrame, but can't postpone it much longer. So, while I work on that project, I keep patching up LF where it needs it.
After that, I most probably sit down, take a deep breath, plan some features (mostly built-in views, helpers and either scaffolding or an admin panel) and call a feature freeze. Then begins the tedious task of realizing the missing features and polishing the existing ones. When that's done, some user documentation, followed by Publish! The timeline continues from there, but this is far enough already.
The first publication of LightFrame will be When It's done. I have no producer, therefore I have no deadlines, which leads to no schedule. Ultimate freedom!
But, now you know what to expect: today a measly website, tomorrow the world. Narf.
PS: Do not buy Nokia cellphones. My ~month-old E90 Communicator has been fixed twice and it's still broken.
Wednesday, April 9, 2008
My Head Explodes!
I wonder why SVN has been made so totally unintuitive and hard to use. Sure, it might be handling my versions, but it's hardly increased my productivity.
"What's wrong this time?" I hear you ask. Let me tell you. I've heard people complaining about some kind of nightmare when merging two branches together. Well. I can't do it, as in I am unable to do it. My skillset is not complete enough for that particular task. I can has stupidz syndreom! Perhaps I need to participate in a course on SVN and finally get a diploma with silver edges and nice italics to be allowed to use SVN, but then it definitely isn't for me.
"Merge branch1 into branch2." That's what I want to do. But, what does SVN? I have no. fucking. clue. It spat out a lot of text, finished, and I have my local files all fucked up. I'm not sure what (if anything) it did to the repository. I finally got the right files back from the repository. So, I tried another way. I get some checksum errors, and most probably my repository is totally fucked up.
While writing the code for LightFrame indeed is dull, boring and even frustrating at times, fighting with problems like these just don't help the matter. I fight with the code, not with the maintenance of said code.
Update: I virtually redid what I did the first time around. Now everything seems to be working just as intended.... *kaboof*
Update2: Nope. Close, but no cigar. *kablam*
Update3: Ok. I give up. I seem to have just deleted the whole trunk, when I just tried to reorganize it. fuck this. I'm doing my own backups...
Update4: Seems like I fixed it and Subclipse is not to thank for that one... I just copied over the template branch to the trunk, and now I have stuff in my trunk. *sigh* Where's that diploma...
"What's wrong this time?" I hear you ask. Let me tell you. I've heard people complaining about some kind of nightmare when merging two branches together. Well. I can't do it, as in I am unable to do it. My skillset is not complete enough for that particular task. I can has stupidz syndreom! Perhaps I need to participate in a course on SVN and finally get a diploma with silver edges and nice italics to be allowed to use SVN, but then it definitely isn't for me.
"Merge branch1 into branch2." That's what I want to do. But, what does SVN? I have no. fucking. clue. It spat out a lot of text, finished, and I have my local files all fucked up. I'm not sure what (if anything) it did to the repository. I finally got the right files back from the repository. So, I tried another way. I get some checksum errors, and most probably my repository is totally fucked up.
While writing the code for LightFrame indeed is dull, boring and even frustrating at times, fighting with problems like these just don't help the matter. I fight with the code, not with the maintenance of said code.
Update: I virtually redid what I did the first time around. Now everything seems to be working just as intended.... *kaboof*
Update2: Nope. Close, but no cigar. *kablam*
Update3: Ok. I give up. I seem to have just deleted the whole trunk, when I just tried to reorganize it. fuck this. I'm doing my own backups...
Update4: Seems like I fixed it and Subclipse is not to thank for that one... I just copied over the template branch to the trunk, and now I have stuff in my trunk. *sigh* Where's that diploma...
Tuesday, April 8, 2008
Google in the Web Framework Business
Google launched Google App Engine today. From the intro video, it's a Python framework that has some niceties like distinct separation of get and post requests (want!) and uses Django templates (nice choice).
But that's not what's interesting. The interesting part is that they provide free hosting. That's kind of a bummer and partly rains on LightFrame's parade, as LF is intended to work as hassle-free as possible on any existing hosting. But I guess it rains even more on Django's parade, as they both work with Python. But, then again, it seems that Google rains on neither's parade, as (from what I gather) you can't deploy the software on your own server, but are tethered to Google.
But that's not what's interesting. The interesting part is that they provide free hosting. That's kind of a bummer and partly rains on LightFrame's parade, as LF is intended to work as hassle-free as possible on any existing hosting. But I guess it rains even more on Django's parade, as they both work with Python. But, then again, it seems that Google rains on neither's parade, as (from what I gather) you can't deploy the software on your own server, but are tethered to Google.
Huh? That Was It?
It's always an anti-climax when you tweak something that might work, and it fixes the whole goddamn problem! As weird as it might sound, I feel always somewhat deflated when that happens - a bit of tweaking here, a bit of fixing here, and *boom* it works, entirely unexpectedly!
I'm used to big fights. Hunting that off-by-one error, tracing variables through recursions of calls back and forth between classes and finally finding that logical error where I took the value out of the wrong method. No, not this time.
I just rewrote about five lines of code and the whole heap of tests just flies through the tests, passes each and every one of them. So, yes, I have if-then-else with elseif completely working. But I got it working before I even started trying. I guess I should not be disappointed. Not when I got the routine halved by the amount of lines from the original implementation. I've almost done everything that I did the previous round, and I've got rid of about a third of the old LOCs.
I guess I should scoot onwards, then, start fighting with the foreach-loops.
Update: Safari really sucks when it comes to rich text editing, it appears.
I'm used to big fights. Hunting that off-by-one error, tracing variables through recursions of calls back and forth between classes and finally finding that logical error where I took the value out of the wrong method. No, not this time.
I just rewrote about five lines of code and the whole heap of tests just flies through the tests, passes each and every one of them. So, yes, I have if-then-else with elseif completely working. But I got it working before I even started trying. I guess I should not be disappointed. Not when I got the routine halved by the amount of lines from the original implementation. I've almost done everything that I did the previous round, and I've got rid of about a third of the old LOCs.
I guess I should scoot onwards, then, start fighting with the foreach-loops.
Update: Safari really sucks when it comes to rich text editing, it appears.
Monday, April 7, 2008
Unsexy Tags
The dreaded if-tag I mentioned in the previous post is here haunting me with its unsexyness.
Even though I have sexed up the template engine itself, the tags are not much better. Well, actually, the normal and simple tags, doing simple things like making text uppercase or lowercase - they are very nice indeed. But the more complex ones, like if-elseif-else will look horrible. I guess it's unavoidable, as the tags aren't actually designed to support multipart-tags.
Also, while I do get the foreach-loops done in an intuitive order, I fear the thought of how the variables will be implemented.
Be how it may, I'm somewhat convinced that the new template engine will be neater and perhaps a smidgen faster than the old implementation. Huzzah!
Even though I have sexed up the template engine itself, the tags are not much better. Well, actually, the normal and simple tags, doing simple things like making text uppercase or lowercase - they are very nice indeed. But the more complex ones, like if-elseif-else will look horrible. I guess it's unavoidable, as the tags aren't actually designed to support multipart-tags.
Also, while I do get the foreach-loops done in an intuitive order, I fear the thought of how the variables will be implemented.
Be how it may, I'm somewhat convinced that the new template engine will be neater and perhaps a smidgen faster than the old implementation. Huzzah!
Friday, April 4, 2008
Sexy Templates
Yes, my templates are going to be sexy! Full of sass!
If things go as planned (pfft, do they ever?) my renewed Template engine is going to be streamlined as hell. Filters' structure will most probably be untouched (what do you expect, they get a value in and they're expected to return a value). I still have the TOM (Template Object Model) class left, but it's a whole different story now. The old TOM is kind of integrated into Template and perhaps partly in the new TOM, but tags are also a part of TOM now.
Tags are now also classes, instead of functions. I'm not sure what kind of performance implications this will have, but the Template object is skinned to the bone now, so perhaps they counter each other. But yes. Tags are expanded TOMs, that have a special method evaluate() that actually does the stuff. But, instead of having a "here's the tree, have fun!"-approach, it's much friendlier this time around.
Dead easy, dead sexy!
What's un-sexy, however, is the fact that I have to rewrite all tags, including if-then-else :(
If things go as planned (pfft, do they ever?) my renewed Template engine is going to be streamlined as hell. Filters' structure will most probably be untouched (what do you expect, they get a value in and they're expected to return a value). I still have the TOM (Template Object Model) class left, but it's a whole different story now. The old TOM is kind of integrated into Template and perhaps partly in the new TOM, but tags are also a part of TOM now.
Tags are now also classes, instead of functions. I'm not sure what kind of performance implications this will have, but the Template object is skinned to the bone now, so perhaps they counter each other. But yes. Tags are expanded TOMs, that have a special method evaluate() that actually does the stuff. But, instead of having a "here's the tree, have fun!"-approach, it's much friendlier this time around.
- The template is parsed in an intuitive top-down-nested order - just as it should be!
- The aforementioned evaluate() that acts as your main method, and you write all the actions inside this.
- Auxiliary method step() advances one 'step' in the tree, and returns false if the tree is already at the end, or otherwise a string with the contents from the tree and advances one step.
- Auxiliary method evaluateVariable($var) is your holy grail of variable evaluation. If the tag accepts a variable, just put it through this method, and out comes the evaluated value - they are handled identically to the {{ var }} -variable tags, filters and all!
- Tags can expect either nodes (a block tag) or a tag (simple tag) explicitly, by just calling either the auxiliary methods expectsNodes() or expectsTag().
Dead easy, dead sexy!
What's un-sexy, however, is the fact that I have to rewrite all tags, including if-then-else :(
Thursday, April 3, 2008
Reverting to Old Stuff
I'm afraid NetBeans doesn't cut the muster when it comes to PHP development. It can be quite hot later on, but today the PHP extension seems a bit buggy. NetBeans is perhaps too Java-y.
On a unrelated note, I now that I started rewriting the Template engine remember why I disliked it so much...
On a unrelated note, I now that I started rewriting the Template engine remember why I disliked it so much...
Monday, March 31, 2008
Eclipse Eclipsed?
I have found a worthy adversary to Eclipse: NetBeans. Its PHP support is... I guess "heartwarming" would be a suitable word. It's even more Java-In-Your-Face than Eclipse, but I guess it's not a surprise, when put in the context that both IDE:s are kind of a marketing channel for Java. I guess there's some kind of a piss-fight between Eclipse and NetBeans going on - ironic, as NetBeans is based on Eclipse.
A very quick review based on a few minutes of playing around: It feels nice, although a bit rough to the edges. Eclipse seems clumsier and NetBeans more up-to-date. But on my Mac NetBeans seems inexplicably slow. It's not chewing on my CPU constantly, but the lag on most controls is mind-boggling (in the 1-second range). NetBeans has many things integrated that need to get installed as plug-ins for Eclipse (SVN, SQL support and SQL query dialogue(!), transparent uploading/copying of files to appropriate web servers via local filesystem or FTP).
Talking about plug-ins, the Eclipse plug-in system has always been more or less a laugh. I've compared it to the early RPM-craze with RedHat: endless dependency recursions, and you have to hunt them down mostly by hand. NetBeans has a working central repository of plug-ins, which just install on the computer and simply work.
Other than the mysterious sluggishness, I have one major gripe with NetBeans (thus far): There's too much chrome. I'm working on a MacBook Pro with a 15" screen and a code font size of 10 points (barely tolerable), and I still have way too little workspace for the code. While I do admit that 15" is not too much to begin with, but Eclipse's not-at-all-too-minimalistic GUI looks spacious when compared to NetBeans'.
If I can get to the root of the sluggishness of NetBeans, I most probably work with that for a while, to see if it would be a replacement to Eclipse.
In a nutshell: I get good vibes out of NetBeans and its young age shows in both positive and negative ways.
Update: I seem to have found a tweak that's plaguing more than me or even NetBeans. I needed to add the line "-J-Dsun.java2d.ddoffscreen=false \" to NetBeans.app/Contents/Resources/NetBeans/bin/netbeans on line 185, under "eval launchNbexec \". Smoother, but some actions (like tab reorganization) still take weird amounts of time.
A very quick review based on a few minutes of playing around: It feels nice, although a bit rough to the edges. Eclipse seems clumsier and NetBeans more up-to-date. But on my Mac NetBeans seems inexplicably slow. It's not chewing on my CPU constantly, but the lag on most controls is mind-boggling (in the 1-second range). NetBeans has many things integrated that need to get installed as plug-ins for Eclipse (SVN, SQL support and SQL query dialogue(!), transparent uploading/copying of files to appropriate web servers via local filesystem or FTP).
Talking about plug-ins, the Eclipse plug-in system has always been more or less a laugh. I've compared it to the early RPM-craze with RedHat: endless dependency recursions, and you have to hunt them down mostly by hand. NetBeans has a working central repository of plug-ins, which just install on the computer and simply work.
Other than the mysterious sluggishness, I have one major gripe with NetBeans (thus far): There's too much chrome. I'm working on a MacBook Pro with a 15" screen and a code font size of 10 points (barely tolerable), and I still have way too little workspace for the code. While I do admit that 15" is not too much to begin with, but Eclipse's not-at-all-too-minimalistic GUI looks spacious when compared to NetBeans'.
If I can get to the root of the sluggishness of NetBeans, I most probably work with that for a while, to see if it would be a replacement to Eclipse.
In a nutshell: I get good vibes out of NetBeans and its young age shows in both positive and negative ways.
Update: I seem to have found a tweak that's plaguing more than me or even NetBeans. I needed to add the line "-J-Dsun.java2d.ddoffscreen=false \" to NetBeans.app/Contents/Resources/NetBeans/bin/netbeans on line 185, under "eval launchNbexec \". Smoother, but some actions (like tab reorganization) still take weird amounts of time.
Subscribe to:
Posts (Atom)
Posts
