New Selenemacs packages are here:

• selenemacs.js
• selenemacs.el

I fixed some of the more obvious and glaring bugs.

For now the Selenemacs main page will be Here. If/when there is more interest, I'll put up a proper SVN repository and a page on bunnywiki.

One of the biggest hassles with web development is the lack of any real test harness. I have lamented about this before, especially when it comes to testing such ephemerals as an elements height, width, etc. So far the best tests I have run into are your two eyes, which is fine when you are working and testing on one discreet component... but web sites, especially the ones I work on, tend to be more then just 1 or two discreet components.

Enter Selenium IDE. The Selenium IDE provides you with a method to record and execute automated tests of your website. It is easy to use, and hella cool. It can test things like the existence of an element, the text contained inside of an element, its width, height, position, etc. Using selenium, you can build yourself unit tests. This is especially useful and powerful if you happen to be one of the unlucky bastards faced with writing code in JSTL, SMARTY, or some other templating-language-that-needs-to-die. Now you finally have unit tests.

Using Selenium, the testing process is a little more automated. More importantly, you can build a series of regression tests, to ensure the stability of your web application.

There is another piece of the web-development puzzle here, and that is the Moz Repl. An REPL is a Read Eval Print Loop, basically an interactive command interpreter that you can feed commands to, and experiment with. the Moz REPL is a javascript version, that lets you inspect and modify any Javascript object in the browser. This REPL is telnet enabled, in fact, there is even a way to make Emacs talk to this REPL, so you can poke around the browser from within your text editor. This is amazingly powerful in two regards:

1. you can script your browser from emacs
2. you can edit code inside emacs, and send it right to the javascript interpreter for testing, and evn install it on the current page

The existence of this REPL is what finally pushed me to stop using Jedit and move to using Emacs incedentally enough.

So the final piece of the puzzle is something I call Selenemacs. It is a global emacs minor mode, in conjunction with some simple javascript that will script selenium, and provide you with feedback on whether or not its tests pass or fail.

Update 2007-07-09: new versions (Version 0.2) added
Here are the two files:

• selenemacs.js
• selenemacs.el

Here is how you use them:
First, download the MozREPL and Selenium IDE extensions for firefox
Edit selenemacs.el to make sure that the variable selenemacs-js-file points to selenemacs.js
Enable the MozRepl (Tools->MozLab->StartREPL)
Load up selenemacs.el inside emacs (load-file "path/to/selenemacs.el") works
Enable the minor mode selenemacs-minor-mode
Record your test in SeleniumIDE
Use the emacs command selenemacs-execute-test to launch the test, its shortcut is C-c C-s C-e
Emacs tells you if the test passed or failed.

The idea here is that you write your test, and stop using your eyes to test the results of your coding to the browser, but instead use Selenium. This is especially good if you are doing multi-stage and repetitive like testing logins, searches, etc. You can code and test right inside emacs, and only have to switch to the browser to verify that your tests actually passed.

These files also show an interesting way to script mozilla through emacs. The next step of course is to get emacs to start interacting with Firebug.

I found this group of icons at the bottom of my Firefox status bar, and it pretty much sums up my thoughts. I've been using GreaseMonkey to help out the team here at work. Small, simple little scripts, that seem to have a huge effect. It's fun to write these little scripts, and it's fun to take on a more "Research and Development" capacity. Maybe one day they will pay me to do that full time. That would be awesome.

Apparently there was some kind of PHP vs. Javascript fight, to see which language sucked the most. The results? Amazingly Banal, if not downright wrong. There is the list of topics, and their scores:

• Syntax: PHP - Sucks, JS - Sucks Hard
• Data Types: PHP - Sucks, JS - Sucks
• Scope / Namespaces / Packaging: PHP - Annoys, JS - Sucks Hard
• Standard Library: PHP - Sucks, JS - Sucks Hard
• Extension Libraries: PHP - Sucks, JS - Annoys
• Procedural Programming: PHP - Annoys, JS - Annoys
• Object Oriented Programming: PHP - Sucks, JS - Sucks
• Functional Programming: PHP - Blows, JS - OK
• Meta Programming: PHP - OK, JS - OK
• AOP: PHP - OK, JS - OK
• Networking: PHP - OK, JS - Sucks
• Error Handling: PHP - Sucks Hard, JS - Sucks
• Multi Tasking: PHP - OK, JS - Sucks
• Reflection: PHP - OK, JS - Sucks
• Garbage Collection: PHP - Blows, JS - Blows
• Security: PHP - Blows, JS - Sucks
• Garbage Collection: PHP - Blows, JS - Blows
• Security: PHP - Sucks, JS - Sucks
• Tools: PHP - Sucks, JS - Sucks Hard
• Server Side: PHP - OK, JS - Sucks
• Client Side: PHP - Sucks Hard, JS - OK
• Final Rave: PHP - Sucks, JS - Sucks

There are some real problems here...

Syntax: Sucks vs. Sucks Hard

I fail to see how Javascripts Syntax sucks harder then PHP. In fact, in a comparison against syntax, it is a lot like comparing whether dirt from your front garden or your back garden tastes worse. It doesn't matter, it is all dirt. For syntax to be not suck, I think it would have to be more like Scheme, where the syntax is very simple and gets the hell out of your way.

Scope / Namespaces / Packaging

The very idea that PHPs Scope just "Annoys" versus Javascript is laughable. Javascripts scoping is by far superior. Show me a closure in PHP, and then show me one in Javascript, and we will see which one sucks and which one doesn't.

The thing about Lexical Scoping and Closures, is that once you have them, then building packaging and namespaces is not too difficult. In PHP, scope is so horribly broken, that people are yelling about needing namespaces and packages, when if they fixed the scope problem, then these other problems are solved. For free.

Meta Programming: OK vs. OK

Now this I don't get, at all. Meta programming in either language involves using eval, along with string manipulation. This is not 'OK', this is definately on the 'sucks' end of the spectrum. To get an 'OK' in this area, you would at the very least, have low-level scheme-like macros, and be able to work with a data structure related to the parse tree. See Lisp and Scheme macros for a better idea of what OK actually means here.

I (sarcastically) love the idea of using Code Generation as Meta Programming (one of the 'perks' of PHP). Code generation should be your final line of retreat. If you are generating code, you may have lost the battle. It is a good tool to have in the toolbox, but it is not one I like to pull out that often.

AOP: OK vs. OK

Dead. Wrong.

Why? Because to get any reasonable AOP in PHP, you need to install an extension into the language. A fully functional AOP system in Javascript however, is painless and easy to write, what with first class functions and all.

Overall

The PHP slides are a bit of a larf. A language with 3080 built in functions is also easy? A language like PHP has a simple syntax? Umm.... No.

To be fair, Harry Fuecks probably had his work cut out for him. How do you explain the basics of a Closure to an audience who might not know what they are, let alone what you can do with them; all in the span of 60 seconds? (psst, objects are closures with syntatic sugar, but you can't "de-sugar" and object to get a closure). If an audience doesn't understand the idea of a first-class function, how can they understand how easy AOP is in Javascript?

Javascript is the most maligned, misunderstood language out there.

This should clear up any confusion. It is a series of slides from a talk about Javascript by Simon Wilson. Basically it is pure, unrelenting Javascript enlightenment inside of 111 well designed slides, occasionally punctuated with title-slides exhibiting excellent photography. It is delightfully focused on the language, and how to get stuff done with it. You won't find tutorials on how to make Javascript rollovers here. Instead, you will find tutorials on making Javascript LOVE... I mean... closures.

SexXxiest. Presentation. EVAR.

(Spellbound wanted to change SexXxiest to orthodoxies... fun!)

I figured out a bee in my bonnet. For awhile this error has been plaguing me:

Error: uncaught exception: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIXMLHttpRequest.status]" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: http://bunny.jonnay.net/projects/TileEditor/project.js :: checkStatus :: line 47" data: no]

Turns out It was because I wasn't sending an empty string after my XmlHttpRequest open. That empty send is important.

Two great tastes...

And by Ajax, I am not referring to a minty coloured and burning flavoured scouring powder, but instead some geek-shit.

AJAX is deceptively simple. It stands for Asynchronous Javascript and XML. The basic theory is that you can use Javascript to send 'sub-requests' to a webserver. You can use all your standard Javascript events. As an example, you could display the text of a webpage to a user, and allow them to edit it in place, and use AJAX to send the text to the server to update it, without having to do a page reload.

That is it. Its really easy to work with.. (check out My del.icio.us AJAX bookmarks for some examples).

REST, again seems deceptively simple... I say 'seems' because I haven't had much experience with it yet. REST stands for 'Representational State Transfer' and in my opinion, is really analogous to functional programming. The keys to REST are:

1. It is stateless.
2. It has a well defined set of operations.
3. A universal syntax.
4. Uses Hypermedia

So what does this all really mean?

Stateless

A RESTFUL application shouldn't depend on any state at all. This means no cookies, no sessions. Sounds painful? It really isn't that bad, it just means a subtle shift in how you code your application. In my app Fuchi (which is almost ready for its public alpha), I plan on using a hybrid REST/Stateful application.

See, just because you can't count on state, doesn't mean you can't handle authentication. HTTP has its own built in authentication mechanism (known as .htaccess, but that is a bit of a misnomer). This method just sends the username and password on every request, satisfying the statelessness requirement. Most alternate authentication mechanisms (such as cookie based, session based, etc.) ensure the password is only transmitted once, and use a token thereafter (the cookie or session). So building a hybrid system like this really isn't a problem.

Well Defined Operations

Not penis enlargement operations here. Basically this means using the HTTP request methods: GET, POST; and their redheaded stepbrothers PUT and DELETE, to their proper use. GET requests should only retrieve data and contain no side effects. POST should be used to insert data, PUT requests should be used to update data, and DELETE... well.. you know. It is very similar to CRUD.

Update: I originally reversed the meaning of PUT and POST. It's fixed now. The differences are deeper then 'create' and 'update'. See my entry about PUT vs. POST.

The good thing about using these methods in the way that they are designed, is that you won't run into issues like The Google Accelerator spidering, and activating your 'delete this content' links.

Universal Syntax

That is, everything is a URI. Logging in a user would be handled with the http://www.example.com/user/login URI. Showing a users bookmarks might be handled with the http://del.icio.us/jonnay URI. The great thing is that the URI's can have some really interesting semantic meaning. Take that bookmark URI. If you were to give it a GET request, it would show you all my bookmarks. If you give it a PUT request, it could add one. If you did a DELETE request on http://del.icio.us/jonnay/noparts, it would delete the noparts bookmark. (All this being hypothetical. del.icio.us has a different REST API, which by all accounts isn't actually RESTful. But that is another story. Do a websearch for REST and del.icio.us.)

Uses Hypermedia

No real mystery. If links to other URI's are applicable, use em and link em. thats basically what this means.

You can see how taking all of these pieces of the puzzle can make for a well factored, well defined web application. Each piece being a discreet unit, that has a well defined set of behaviours.

... That Taste Great together

So weaving these two techniques together, can really work well. Lets take the Fuchi app as an example. We could set up a URL called /ideas/idea as a representation of a single idea. A GET request would simply return a list of all ideas. The URL /ideas/idea/423 would return the idea with the ID of 423. A PUT to /ideas/idea would add a new one. A POST to /ideas/idea/423/rating would update the rating of an idea. You get the point.

With AJAX, we can set up a simple little Javascript slider interface, so that we could rate an idea. We can then use the REST API to submit our POST request and handle the update in a really simple way.

In part 2, I will flesh out this interplay a little more.