Sign in or 

Imagine...
If Prototype.js allows developers to write code to easily make use of rich JavaScript capabilities, then my new library will hopefully be a library that allows developers to write rich JavaScript libraries that allow them to make use of whatever the heck they want. In a nutshell, what I am developing will allow developers to write quick little modules and objects that may or may not inherit from other objects and will be easily accessible and referenced from actual front-end script that they write.
The modular design will function somewhat like dojo in behind the scenes access to modules and libraries, but hopefully be more perlish in style and syntax capabilities. Instead of the java inspired 'import' function, more perlistical 'use' will be provided. I've developed some early mockups already of various core language bits that I really want (or have found out that I'll need) and learned that a lot of what I want to do is possible, at least from how things are looking right now. I'm having minor problems with package instantiation and I'm trying to make the package declarations as powerful as possible for module developers, but am having issues with how I want to handle scoping and object creation. I'm certain that it'll all work out, but that's what I'm working on now.
Release Information
I'm tired of all software products being released in the same fashion. I'm not going to do traditional 'version' releases and release candidates and all that boring old nonsense. The administrator in me is sick and tired of tracking down stuff like Marco.Polo.major-1.2.3-_bugfix2_patch0_rc3. That makes my brain ache. I'm going to try doing something completely new and original with this project.
ENTER: Named Releases (w/ Loud Knock)
The 'Named Release' concept is loosely based on something that I always love about most large commercial projects. In the spirit of 'Chicago','Revolution', and other sweet code-names, all releases of this library will be named.
Major Releases (The "Here's What We've Been Working On" '#.0.0’ Release)
A major release is a breakthrough or massive reworking of the project's code base. Major releases will be planned and will hopefully follow a development timeline of some type. I'll announce that the major release will be done on 15 June, 2006 and hopefully have all kinds of new stuff added to the library by then.
Major releases will be named after States in America, starting from 'Alabama' and ending with 'Wyoming'. This gives us 50 major versions before we have to go on to provinces or something. To be honest with you, I'm not all that worried.
Minor Releases (The "Check This New Feature Out" 'x.#.0’ Release)
Minor releases will come out as development progresses towards 'State Date' (my clever term for "pushing a major release”). New features will be rolled out once they're found to be complete and functional. Minor releases will be named after books in the New Testament of the Bible (Matthew - Revelations). There are 27 books here to choose from, and if we make it to Revelations before reaching 'Statehood' (clever term for "branch to lock for 'Ratification'" (term for "the development team accepting a code branch for major release”)), I fully expect the second coming of Jesus, called 'The Christ', to arrive.
Revision Releases (The "Ok, This May Have Fixed All Your Bugs" 'x.x.#’ Release)
While 'writing our next Bible book' (clever term for 'coding for minor release’), each new change to the core trunk will be provided as Revisions. Revisions are not developmental code to be kept from production servers. Our 'Revision' releases merely denote trustworthy code that is gearing up for 'Canonization' (clever term for (I’m sure you've already guessed) "combining revision changes into a 'Book'" (term: "a minor release”)). Revision releases will be named after the major bodies in our solar system
Bug Fix Releases (The "Sorry We Fscked Up Your Server" 'x.x.x-fix#’ Release)
All stupid puns and terms aside, Bug Fixes will be named after major environmental disasters. The rule of thumb here is, the cooler the name, the cooler the developer is. Stuff like 'HurricaneKatrina' gets bonus points.
- [MAJOR TODO ITEM = build and implement some sort of bug system]
Natural Disasters (bug fix release) should be a release of a fixed version of a planetary release and rushed immediately into recommended use. Natural Disasters only occur when a release has been made of harmful or totally nonfunctional bits of code. Fatal errors in core functions and building blocks warrant Natural Disaster releases. Everyday bug fixes like "Your stupid object doesn't work in Netscape 7.1 and has some stupid exception being thrown about how much Eric Harrison Likes Peanut Butter!" should be fixed during the day (‘Dev Branch').
If the problem requires minimal changes, the developer closing the Bug Tracker's Ticket can send an appropriate fix to the user for manual application if requested, but hopefully developmental releases will happen with enough frequency that hopefully the target user-base will become accustomed to frequent lib updates.
- [FEATURE = assuming an effective modular package management system is implemented, it may be useful to push automatic updates down to the various web servers in a configurable fashion (i.e., "Auto-download and Rebuild World Planetary Entry", "Manual Environment Processing", "Watch the developers very closely" (follow the CURRENT branch explicitly ), "Make sure the developers don't break my shit." (If it's the afternoon, auto-download and test until midnight)) ]
The Developmental Branch (The "Please Don't Look At My Code and Hate Me" 'x.x.x_AA#’ Release)
This branch is the only place new code is integrated into the branch outside of 'Natural Disasters'. Each dev branch is named after periods of the day. I have arbitrarily chosen 'daytime' descriptors for the Developmental branch because the daytime is ( to me ) a cruel, horrible joke played upon mankind by a malicious deity who's only function in eternity is to make sure that every morning I wake up tired and miserable and every night I feel glorious and wish that I didn't have to wake up in 3 freaking hours to go to work at which point I lay in bed for a long time ( which always feels like a month ) and then miserably drift off to sleep 32.4 seconds ( on average ) before my alarm goes off, alerting me to the fact that A) Daytime is a cruel joke by an evil deity, and B) If there is a Heaven, when I get there, it will be Nighttime.
- dawn
- morning
- noon
- afternoon
- evening
- dusk
- twilight
- midnight
As I hope you would have already surmised, this mechanism lets the developers all comprehend just where we are in terms of preparation for moving work off-world to the next planet in line ( Gosh, someone remind me to buy a beer and a jelly donut for the person who invented 'The Pun' next time I see him. Endless fun, I tell you... Endless Fun! ) As we approach midnight, all features should be checked and tested and ready for atmospheric reentry.
In the perfect world, everyone testing our software and providing feedback on bugs and feature requests inside the daytime branches would serve best by picking things up after noon ( or 'afternoon' ( GET IT?!@ HAHAHAHAH!!! ) ). New features and additions to the branch would be best implemented in the early stages of the day and will hopefully be most defined by noon. Everything afternoon until dusk should be driven by user feedback driven: features to add, performance requests, strange bugs, fatal errors, use case submissions, and other things of this nature. Hopefully by twilight, the code will be tested in as many different user environments as possible to attempt to remove as many fatal Bug
Tentative Milestones
- Alabama.Matthew.Sun['dawn'] - 15 July 2006 - Private Release
- Alambama.Matthew.Sun['morning'] - 27 July 2006 - Initial Preview Release
- Alabama.Matthew.Sun['noon'] - 15 August 2006 - Developer Test Release
- Alabama.Matthew.Sun['dusk'] - 15 September 2006 - User Test Release
- Alabama.Matthew.Sun['midnight'] - 1 December 2006 - Last Minute Lockdown Before 'Atmospheric Re-Entry'
- Alabama.Matthew.Mercury - 5 December 2006 - Planetary Release( hopefully not too hot for human habitation )
If You're Gay...
... and you think something I've said was stupid, short-sighted, naive, or just plain Ericicitous of me, by all means, please don't hesitate to send me your rants via email to blister@gmail.
If You're A Genius...
... and you wish to tell me how insightful and wondrous my unique thoughts are, please send me your outline and PowerPoint presentations detailing my brilliantly intricate mind and your creative interpretation of it's power and capabilities at the email address blister@gmail.
Everything Else...
Just send me an email already... blister@gmail is my address... clicky-click this link right here --> "Hello sir! I am a link! Why don't you make us both happy and click me! Yay! Tuna Fish tastes best when wrapped in underpants and left in the cellar to ripen! Yay! Balogna smells my feet!"
|
blister |
Latest page update: made by blister
, Jul 27 2006, 8:35 AM EDT
(about this update
About This Update
12 words added 2 words deleted view changes - complete history) |
|
Keyword tags:
ajax
dhtml
framework
javascript
js
lib
library
perl
xmlhttprequest
More Info: links to this page
|
| Started By | Thread Subject | Replies | Last Post | ||
|---|---|---|---|---|---|
| blister | WetPaint Has Some BIGGGG Problems | 0 | Jun 22 2006, 4:33 AM EDT by blister | ||
|
Thread started: Jun 22 2006, 4:33 AM EDT
Watch
No Auto-Save killed me about 20 times tonight. What a pain. If they don't add this feature and I continue to use this page instead of going elsewhere, I'm going to start writing everything in MS Word and pasting it here when I'm done. I lost literally about 2 hours of work tonight... :/
WetPaint Dev's... if you ever see this message... please add Auto-Saving of work in progress as soon as possible. Without auto-save features kicking in frequently, editing pages is similar to playing kickball in a minefield. One other crucial problem is 'CTRL+R'. The usability problem is that you've replicated just about everything from a WYSIWYG perfectly, right down to the hot key... However, you aren't capturing CTRL+R. I'll hit CTRL+Z to undo until I find where I want to be and then spam CTRL+R to go back one undo and resume work. CTRL+Z works fine, but CTRL+R == total loss of data on page reload. At the very least attach an event to that key to ask for confirmation and return false if I select cancel. And I'd also recommend attaching an onunload event to window that checks to see if you're in edit mode. If you are, it should ask if I want to save my changes before leaving the page. I've got a few more UI complaints that I'll actually send to you guys later, but for now I just wanted to jot this all down in comments so that I don't forget how unhappy I was with losing all my work tonight. Other than these major quirks though, this is exactly what I've been looking for in a lightweight web page solution. Great job. -E |
|||||