JS Library DevelopmentThis is a featured page

Much Frustration And Fury!

So, after creating this page, I spent about two hours typing up my grand vision and the back-story of how I got into JavaScript development... and I hit "CTRL+R", in blind stupidity thinking it would "Redo" something I'd just "Undo'ed". Much to my dismay, "CTRL+R" gladly performed the action I knew that it would want to do... Reload the page... with all my text disappearing into JavaScript heaven (or hell, nobody every got to read my incomplete prose, so for all I know, it could have been absolute shit).

After cursing my own stupidity for an hour (after first sobbing like a child for about 3 hours), I decided to re-write the damn thing from scratch...

... some other time. When I'm not still pissed. Just be aware that at some point, some truly beautiful piece of work will come through the pipe for your reading pleasure. For now, I'm just going to jot down some of my thoughts on what I'm doing and why.

I Need a Better JS Library

I've been using Prototype.js happily for a long time now, but I just can't shake the feeling that there has got to be a better way for me to work with objects and inherited objects. I've also been dying for effective library compartmentalization in as clean a fashion as possible and have finally realized that what I really want is CPAN for JS. After realizing I just wanted CPAN for JS, I also realized that the object orientation scheme I really wanted was Perl’s Module/Package design. I also wanted Perl’s syntactical goodies. I wanted Perl... as JavaScript.

"But Eric, That's Ri.dic.ulo.us," You Say.

While it may be a stupid idea and seem like a waste of my time all together (which you may be completely correct about), I'm determined to give it a serious attempt and just felt like posting stories and what-not on the web for the world to read will only help me solidify my library design abilities. I've been a programmer for a long time, but I've worked solo for longer than most and have been coming to terms with the fact that I often am doing the coding right, but only after first designing the actual program quite poorly. I've been getting better... but everything is a learning experience. So follow this journey if you are so inclined, and if not... well, click on some of WetPaint's Google ads on the right side of this page.

What I Want

My goal is not to replicate Perl, because that is something only a parsing Artificial Intelligence version of Larry Wall, developed by a community of developers porting Perl6 onto the Parrot stack using Python written by Guido SomethingOrOther ( who shot first, by the way ), can actually do. Since I'm giving up all my wild-eyed visions of how awesome JavaScript would be if it wasn't anything like JavaScript at all and was more like some other language, I'm just going to try to write a useable ( and hopefully useful ) API from which useful JavaScript objects and libraries can be developed and used in a more developer friendly fashion.


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
    1. Sun
    2. Mercury
    3. Venus
    4. Earth
    5. Mars
    6. Jupiter
    7. Saturn
    8. Uranus
    9. Neptune
    10. Pluto
    11. Planet X
      • Understood by developers to mean 'LAST CHANCE TO GET SOME CODE IN THIS BOOK BEFORE WE CANONIZE!@$$!@!#!' at which point everyone will finally realize that they're really late on stuff they promised their users and that they don't have much time before we Canonize the Book.

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.
  1. dawn
  2. morning
  3. noon
  4. afternoon
  5. evening
  6. dusk
  7. twilight
  8. 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

  1. Alabama.Matthew.Sun['dawn'] - 15 July 2006 - Private Release
  2. Alambama.Matthew.Sun['morning'] - 27 July 2006 - Initial Preview Release
  3. Alabama.Matthew.Sun['noon'] - 15 August 2006 - Developer Test Release
  4. Alabama.Matthew.Sun['dusk'] - 15 September 2006 - User Test Release
  5. Alabama.Matthew.Sun['midnight'] - 1 December 2006 - Last Minute Lockdown Before 'Atmospheric Re-Entry'
  6. 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
blister
Latest page update: made by blister , Jul 27 2006, 8:35 AM EDT (about this update About This Update blister Updated release information... - blister

12 words added
2 words deleted

view changes

- complete history)
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
2  out of 2 found this valuable. Do you?    
Keyword tags: None (edit keyword tags)

Anonymous  (Get credit for your thread)


Showing 1 of 1 threads for this page

Related Content

  (what's this?Related ContentThanks to keyword tags, links to related pages and threads are added to the bottom of your pages. Up to 15 links are shown, determined by matching tags and by how recently the content was updated; keeping the most current at the top. Share your feedback on Wetpaint Central.)