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.
Sunday, June 29, 2008
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.
Subscribe to:
Posts (Atom)
Posts
