[maemo-developers] Liqbase GSoC Proposal Rought Draft.

[From: Sebastian 'CrashandDie' Lauwers]

2009/3/23 Zach Habersang <zachhabersang at gmail.com>:
> Here is a rough draft of my Google Summer of Code liqbase proposal. Please
> feel free to comment, recommend additions or subtractions, or just let me
> know what you think! I took out the biography information for personal
> reasons.

Hi Zach,

Interesting read. Before going into any more detail, may I suggest not
saying things like "The code base is quite messy at the moment" when
trying to sell a project/product. First of all, you're hurting lcuk's
ego (I'm sure he would say:
http://img.thedailywtf.com/images/mfd/2/03_jfjez.png), secondly it
makes you sound condescending.

In lcuk's defence, I think I can safely say that he never took the
time to write pleasing-to-the-eye code because he never anticipated
having to share it. Any coder with a tiny bit of experience knows
there's two ways of coding, quickly, or publicly. Also, I think I can
safely assume he has done quite a huge amount of work on cleaning up
the code already. I remember the days ;).

Quite frankly, I don't think documenting the code itself is going to
help a whole lot. Either you understand the code, and you don't need
the comments, or you don't understand the code, and thus you don't
care about it what it means (to the line) anyway, you just need to
know what it does. Proper function naming and high level function
documentation will achieve this goal as well. On a second note,
developers who will want to use the liqbase framework will not require
to dwelve into the liqbase code base (now that sounds redundant). As
such, a good API documentation, will, IMHO, prove to be a lot more
beneficial than to-the-line documentation.

"Check for security vulnerabilities and memory leaks"

Again, arrogant and condescending (I'm starting to like you). You're
not here to judge lcuk's work. In management terms, you would say
"Create Quality Assurance procedures and regression testing scripts".
I truly believe this is something that would be more needed than just
going through the code once and eliminating possible bugs. Bugs will
be bugs, and you will always have them. Believing you can simply spray
to the code and remove every bug is about as great as believing you
become a super hero by wearing your briefs over your trousers. I would
rather see some time being invested in creating ways of approving new
code, and testing it doesn't break functionnalities. Long term idea
over short term bling.

"Develop server/client programs using the TCP/IP sockets API."

Which API? One that has to be coded into the liqbase API or raw C sockets?

"Write functions for retrieving systems information."

Part of your project, that will run atop of liqbase. Please make sure
you make this clear, liqbase will not include, per se, such specifics.

Overall, great initiative, thanks for the time you're going to invest
in this. I'm happy to see it going forward and seeing lcuk's going to
get some help.

S.


-- 
question = ( to ) ? be : ! be;
      -- Wm. Shakespeare