JSLibBuilder

Unfortunately I've started yet another project to support development of Soashable--JSLibBuilder. Its purpose is to ease the creation of Javascript libraries, from development to testing to distribution packing. To use it, you create an Ant build file in your project's directory, create a few filesets, and import the jslibbuilder build file. It adds compile, jsunit, selenium and dist tasks to your projects build file, which then uses the filesets and things you have defined.

It is packaged with JSUnit and will have Selenium soon, which frees your project of having to care about them. Simply put JSUnit and Selenium tests in a known spot and run the Ant script--easy. It also lets your JSUnit files use tokens, such as jsunit-dir and test-dir, so that you don't have to worry about absolute paths.

The project isn't ready for a release, but it is in SVN in its current form. Beware, it has a lot of my workstation's paths hard-coded in. I'll try to make a release at some point; but if it sounds useful to you, feel free to do it for me :).

Cross Browser Support

Implementing cross browser support is bitch work. As if writing code that has full test coverage isn't enough work, now I have to go in and tweak it to work in 4+ different runtime environments.

Safari for Windows seems to have the closest resemblance to Firefox (which I develop in), so it doesn't usually need much changed. Opera seems to tell me when I am doing something stupid to begin with, and so I change it and those changes generally work in FF and Safari. Sometimes though, like now, it gets very irritating trying to cooperate with Opera.

I dread the day that I get around to the restoring IE compatibility. It's not that I'd purposely not support it, it's just a lot of work that I don't really want to do. Thank god for for all the unit tests I have written which will ensure regression when the task is undertaken. It gives me the idea to put "make this library IE compatible such that these tests pass in FF, IE6 and IE7" on RentACoder; that is, unless any of you want to do some bitch w...er, uh, help the project out :p.

On a lighter note, today (here in MN) shaped up to be a FANTASTIC day to work out on the patio. A perfect 75 with low humidity. It looked like rain in the morning, but it's been a gorgeous, mostly sunny day today.

I want... I want my H-T-T-P

Comcast has taken my livelihood away from me. I'm no longer able to run port 80 on my IP address. My room mate who is on the same account, with his own IP address, can still do it fine. And other ports like SSH work fine for me. Something about the nature of my site must have set off a flag that led them to enforce the policy about not running servers. It comes just days after talk of Comcast tiering their internet service began, and I don't want to do business with them anymore.

It turns out that DSL is not available at my location, so my only option for self-hosting is Comcast Business, which is $95/mo (vs $50 now) and doesn't include a static IP by default. Ouch. I called them up and there is a 3Q special that puts their plan at $59/mo until the contract is up (1yr). I may do that, and get a static IP address. The plan is 1mb/s up, so it would double my speed for not much more than I'm paying now.

I have no choice but to do business with them if I want broadband at home. As for serving, I could pay to host elsewhere, but I'd need to generate some revenue first since it's significantly more expensive given my special needs (JVM, daemons).

The good that comes of this is that I know I won't be cut off shortly after I demo Soashable (next MinneDemo, perhaps?).

A Brief History of Soashable

Soashable is a lot of things, depending on when you ask me. Chronology might be a bit off, but this is the gist of it.

IP Chat

It stems from the very first application I made beyond my "AOL Proggie" days (~1999)--an IP chat application. It was simple, you typed in the IP address of a friend's computer who was running the application, and it would connect and open a chat window. Eventually I added Rich Text and the ability for many people to connect to a single computer.

LoopyTOC

After that, I decided that a stand-alone, centralized server would be the way to go to avoid any confusion about what an "IP Address" is from my friends and their friends. I was armed with new knowledge of AOL's open TOC (Text to Oscar) protocol, and decided I would make my client use the AOL network. I carried on development and eventually released an ActivceX control called LoopyTOC, around the same time as another fellow by the name of "dos" released a TOC client that went on to win Planet Source Code's code of the month award. The timing led to accusations that I stole his code (I didn't), and me eventually being 'booed' off of Planet Source Code--the issue was cleared up with the other programmer, as I sent him my source code to examine the differences.

COSMACS

With TOC behind me, I started a new server that supported everything my original version did, but was also "open source"--a new term I heard about while I was changing from a flat-file database to MySQL. By this time I was 16 years old (2001), and the new project was called COSMACS--Community, Open Source, Messaging and Chat System (@archive.org). Around the same time, I had built a website called iSpooge which ended up taking most of my attention away from COSMACS, because COSMACS didn't give me instant gratification like running an "E/N" site did (Entertainment/News is what Blogs were called). My interest started drifting towards PHP CMSs (Content Management Systems) geared toward E/N sites.

iSpooge

iSpooge put me in touch with the more social aspects of the web, beyond just instant messaging and chat. The site had a variety of Javascript games to which I programmed a score-keeping backend, and "coolness points" that were gained for various actions on the site. It was a small community of friends from high school and unconnected circles of friends on the internet, but the comments gave people a place to chat and the coolness points gave them reason to interact. It excited me to come home at night and read all the new posts and comments on the site.

As iSpooge became more popular, I tried a strategy called uSpooge, which filtered blog posts by user, in essence giving them their own blog. I believe this may have been a reaction to LiveJournal, which was barely taking off around this time. The rise of LiveJournal, however, meant the downfall of i/uSpooge. My theory is that with more options, the novelty of my blog wore off :(.

Flirting with the Devil

Sad to say, at about this time I also started getting into girls and the project laid dormant until about 2 years ago.

OsSpace

The next incarnation was called OsSpace (Open-Source Space), a clone of the ridiculously crappy and proprietary, yet successful MySpace. It was slated to use open standards like OpenID, FOAF, RSS, xCal, Jabber and a slew of other technologies to form a federated social networking system. The principle idea was to give freedom to users and developers by allowing them to make friends with anybody on any network, and to move between networks without losing those connections. The open nature of it allowed different networks to cater to different demographics without isolating them. Sites could cooperate and have high levels of integration with each other, simply play nice without inter-operating anything more than identity, or completely isolate themselves (Intranet).

In order to make OsSpace real, I placed an ad on Craigslist searching for anyone interested in learning technologies X, Y and Z that I had planned to use, and enlisted a friend from high school to help out. We drew up a lot of plans, but our shortcomings caused the project to lose steam and eventually no more progress was made. From that experience, I learned that not everybody needs to (or should) be involved in every aspect of a project; perhaps they should only be involved in what they're good at. I also found that feature creep was a huge problem, because things would get partly done and then I wanted to change everything to incorporate new feature CX3750. As a programmer for a small web firm, I should have been more conscious of that, being that so many projects I was on ran orders of magnitude over budget and past deadlines due to feature creep.

Soashable

This time around, with lessons learned from OsSpace in mind and a network of people with diverse skills that I can identify, as well as potential business connections, I think Soashable can be as successful as I try to make it. The principles from OsSpace remain the same, but the limited scope is an important part of the grand strategy. A Meebo clone it is, and if I can stick with that then it might actually get done this time.

It's coming up on a decade in the making; it's time to rock.

Jabber DataForms

Last night I whipped up an implementation of Data Forms for XMPP (XEP-0004). My implementation includes a reusable class for manipulating a given Data Form, an XSL sheet that generates an HTML form directly from a Data Form element, and a DataFormWindow class to bind the two together.

The whole implementation is complete minus two parts: 1) the ability to intelligently populate "jid-single" and "jid-multi" fields, and 2) the ability to manipulate or render "data set" style results. The latter will be a shortcoming eventually, but the API is such that it won't be difficult to add. I admit, I didn't read the full spec at the time I started implementing, and that is why that functionality lacks. Another shortcoming is that as-of right now it only works in Mozilla (as does most of Soashable; I hate dealing with tedious cross-browser issues :\).

The XSL for rendering the form is pretty nifty, if I do say so myself. Basically it will transform this:



into this:



It still needs some work with things like selecting values and the like, but I may just delegate that out to the Javascript DataFormWindow where the Submit event is handled, etc. And to be structured more semantically so that CSS can make it look better. For now, I'm just happy that it works.

These forms are currently used for in-band registration as well as user search, but they can be put into any arbitrary message originating between any peer. Imagine configuring your server or sending your friend a quiz through messenger. Having a dinner party? Just multi-cast an RSVP form out to your roster. This could be tied in with a calendar application or anything. Sweet? sch'yea.

Lessons learned, etc? The XSL sheet took no more than an hour, an the Javascript behind it no more than an hour more. But somehow development ended up taking around five hours; why? As is often the case, documentation wasn't as clear as it could have been for my edge case. I was passing a DOM element into Gecko's XSLTProcessor.transformToDocument method expecting that it would be treated as a root element. Instead, only the child nodes were being processed and because of this the processor thought it was a "multi root node" document and added a root element which seemed to replace my root element. I was confused because the same XML with the same XSL worked using an xml-stylesheet processing instruction through the browser. It definitely shouldn't have taken as long as it did to solve, and actually I was in the process of putting together a stripped down example to share with the mailing list when suddenly it started working. "The best way to learn is to teach," yet again.

Soashable and XMPP4JS

Not much development in the past week, been busy with school work. But I did manage to reorganize Soashable a bit and pull the Jabber library out, here. I decided on the name xmpp4js.

It's far from production-worthy, but at least it's out there now :). IMO it's a great library, but there is some suckiness that I wish could be overcome; namely the same origin policy. Because of the policy one must set up a proxy on their web server (maybe firewall) to funnel http binding requests to the xep-0124 enabled jabber server, rather than connecting directly. There are no config examples in svn yet, but I can confirm that it works on both apache and lighttpd. I'll try to get those up soon.

As far as Soashable itself, there have been some interesting developments on the planning side of things. We have a couple new faces who are interested in helping out, and there are some interesting talks about more business-y things. I've experienced a lot of feature creep, and in-lieu of this we had a meeting to lay down some milestones. I'll summarize those when they're a bit more finalized, but at this point we're looking at a full Meebo clone with some extra features in six months. Extra features will be added beyond that, and we hope it will catch on and get some outside development contributing as well.

Non-Strong References in Java

I've always "sorta" known what a weak reference was in Java. I mean, it's common sense right? Sorta. I always figured it was a way to tackle the issue of circular references, but there is more to it than that. It turns out that there are actually 4 levels of references in Java: strong (implicit), soft, weak, and phantom, which the garbage collector (GC) handles in different ways.

The other day I encountered a SoftReference and wondered how it differs from WeakReference, so I decided to take a crash course on the subject; here is a nice (but long) article from Sun. Read on for my abridged version (teaching is the best way to learn, right?).

A strong reference is the default type and uses a counting mechanism to determine when it can be reclaimed by the garbage collector. When the counter hits zero, an object is reclaimed next time GC runs. Circular references mean that the counter will never hit zero, because none of the objects in the circle will be reclaimed first. The reason is that the GC doesn't determine when groups are no longer reachable, only individuals--this is how weak (actually soft, as you’ll soon see) references address the issue.

Encountering a SoftReference the other day is what made me question what I thought I knew about weak references. It turns out that a SoftReference is actually what I thought a WeakReference was. It is a reference that is held in memory until an OutOfMemory exception is about to be thrown, at which point the JVM must attempt to free softly referenced objects. SoftReferences are very useful for caches, because they allow a program to store things in memory that it can but would rather not recreate. For example, a web application that generates an image based hit counter could store the generated image data in memory using a SoftReference. Since the image can be recreated it’s no big deal if it’s lost, but since it costs (perhaps heavy) CPU time to regenerate, it would be beneficial to store it in memory as long as it has resources to do so.

A WeakReference is actually pretty useless for any kind of non-temporary storage. It works the same way as a SoftReference, except it is always reclaimed when the GC runs, rather than just when the system is out of memory. An interesting example that the article gives is to weakly reference a Thread object using a ReferenceQueue, which will notify the program when the Thread terminates (is no longer strongly reachable).

A PhantomReference is sort of tricky (I’ll have to work with it before I completely understand it), but it is an object that has been finalized, but not reclaimed. It becomes useful when used, in combination with ReferenceQueues to determine that an object has been reclaimed, to free up related resources (such as strong/soft references, etc).

For more info on ReferenceQueues, see the Sun article.