The reason I've done it this way is because I've only coded on LightFrame. Just cranked the code, and done some weak testing on the side. I'm now doing some actual demo projects with LF. Nothing hardcore, but still it has already revealed a few bugs (never mind the abysmal ticket descriptions. They're intended just as reminders for myself.)
So, what now?
I'm going to do a couple of demo projects. Eat some of the dog food. This reveals some facepalm-bugs, which get corrected ASAP. By the way, bugs have still the highest priority, and override any other tasks at hand. All*) known bugs need to be solved before new code is written. I have all intentions to keep it that way in the future, too.
*) Of course, the size of a bug will be taken into consideration. A bug that requires a complete rewrite, but has a known two-line workaround doesn't get too high in the priority of things from a sole developer.
Once I've got that alpha release covered, I plan on taking a look at documentation, but I have mixed feelings about this.
Naturally, documentation is many times what makes or breaks a software thingy. But the thing is, it's detached from the code. This leads to the fact that documentation will quickly become obsolete. Of course I have written PHPDoc all over the place, but an API documentation is not something you learn out of – it's a reference! (This reminds me of how much I generally despise JavaDoc, but that's another story.) No, I'm talking about a decent user manual, complete with tutorials, tips, tricks, and best practices. They are a must. But, since I lose my interest very quickly in products with outdated manuals, there probably are some people who think like me. The documentation quickly becomes the combined salvation and evil burden.
Be how it may, once I've got documentation covered, I'll probably get working on some administrative features in LF (eventually forming Alpha 2) as I try to get some sort of community website going on, with documentation, files to download, blue-collar-y news to give a professional face for people to get their impressions of and the like. These will be parked at the main website – lightframe.org, as soon as I figure out some kind of hosting solution (not a priority right now).
...which brings me to my last point: As a result of the mother of all christmas presents, there are some URLs that I intend to use in the future:
- (www.)lightframe.org – For general information about LightFrame. A portal to all LightFramey, including documentation, downloadable files, forum and the like. This currently points to the Assembla project page.
- blog.lightframe.org – The official blog of LightFrame. I hope that, in the future, it would not be just me writing here, but other notable contributors also. This currently points to this one, at Blogger.
- repo.lightframe.org – LightFrame's source repository. This is where the latest source can be fetched from. Currently, this means a git repository at GitHub.
NOTE: On 12.1 I'll switch the URL of this blog to actually be blog.lightframe.org. For now, that address has just been forwared to the Blogger subdomain, but that will stop working on that monday. Blogger is kind enough to give a notification about the move to browser visitors, but I can imagine that RSS readers can't follow that redirect. So: update your RSS readers on monday January 12:th to whatever is offered at blog.lightframe.org. Thank you.
No comments:
Post a Comment