I am trying to find the perfect editor for OSX. Actually, I have been trying to find the perfect scheme editor for OSX.

On my windows machine at home i use UltraEdit, which at one point was the ultimate in text editors. At work, I use jEdit, which is excellent , and has a lot of potential. Both of these programs are good at editing source code for PHP, JSP, HTML and PL/B. But in my heart, I knew that when it came to programming Scheme, both of these solutions fell short.

So when I was faced with trying to find an editor I liked for OSX, I immediately jumped to jEdit (being cross platform and all) and I rapidly jumped back. jEdit, while good, just isn't great at editing scheme. Sure there is an R4RS implementation of scheme that hooks into its console, but lets face it, it isn't really that useful. On top of it, its console plugin does NOT like to play nice with the Gambit scheme interpreter. To make matters worse, working with jEdit on OS X didn't feel like working with it on WinXP.

Now let me take a little diversion here. Ever since I have gotten my new PowerBook, I have been sitting in this weird little zone. It is equal parts "Oh Ess Ex? More like Oh! Eh! Sex!" and sitting, quite firmly in the suck threshold. On one hand I am opening terminal windows and hacking like a power user, but on the other, I am running to my more seasoned mac friends to ask how I can use the tab key to switch focus to a button. The overall effect here is that for me to get the simplest jobs done (sometimes) involves a lot of pain and work; this being said, I can imagine switching from OS X to WinXP would be an even worse experience.

So I narrowed my choice down to either TextMate, or Emacs. Now TextMate is the ultimate in slick editors for OS X. It is slick, very OS X in its interface, easy to use... and an absolute pain to work with if you are editing Scheme. Basicly, TextMate has an active community of Ruby, Python and PHP developers doing Ruby, Python and PHP things for TextMate, not Scheme things.

With Emacs, it is quite the opposite. Emacs is de rigeur amongst Scheme developers, so obviously more effort has been made to make it scheme friendly (even allowing for the fact that there are many different implementaitons). The differences don't stop there. While TextMate is flashy, user friendly and OS X like, Emacs, even the latest build for OSX, is not.

So I was faced with inferior editing, in a comfortable (but yet new) OS X style with TextMate; or far superior editing with emacs, but faced with the prospect of not only sucking in OSX, but sucking in a completely different method of editing source code.

Now you might be asking yourself "How different can editing source-code be? Even across WinXP and OS X, its Control (or Command) U for undo, C for copy, X for cut, and V for paste. Right? Right?" Well. No. In Emacs, Undo is done with a Control-/. There is no redo. Instead, undo's are un-done by performing an action (like hitting space-bar), and undoing that, which forces the undo of the undo actions. Essentially every action (hitting a character, deleting a line, or even undoing) puts that action upon a stack, so every action is saved, even actions that were undone. This is a very powerful and slightly confusing concept, but it exactly illustrates emacs. Powerful and Confusing.

Overall my experience thus-far has been good. It is hard work, I still suck at editing Scheme in emacs, but the biggest thing here is that I am the one that is sucking, not my editor. Surely emacs could be built better, perhaps the Headrush folk could build an equally powerful but yet friendlier emacs. But emacs has already given me enough bones to keep slogging away at it. Knowing that I will stop sucking soon also helps.

When debugging an Ajax application, especially one that is talking to a REST API, especially especially if that REST API is one of your own building.

I was getting this strange error in the JavaScript console, NS_ERROR_ILLEGAL_VALUE 80070057. Something about an uncaught exception. Well, the solution was to stop using AJAX, and get right down to brass tacks: Telnet is your friend.

telnet bunny.jonnay.net 80
Trying 142.179.114.225...
Connected to panda-ba.sanriowasteland.net.
Escape character is '^]'.
DELETE /projects/TileEditor/tiles/tile.php?tiles=43c75444b6253 HTTP/1.1
Host: bunny.jonnay.net

If you just send raw request headers through telnet, it makes it a bit easier to understand what is happening. I will bet however, that if you are getting the NS_ERROR_ILLEGAL_VALUE messages, it means that you have some errant back-end code, and your error messages are none too friendly.

Better error messages will be a feature in meditation 0.2

Flagrant Disregard just made my RSS. Especially with this awesome entry titled Her teeth are the teeth of steel. John Watson is an excellent writer, and I only hope to one day match his skills in translating the mushy-goo-about-my-wife-and-daughter-inside-my-heart into such beautiful prose.

He also is a very competent and creative programmer, observe the FlickrToys. The Trading Card Maker is one of my favourites.

I'm Wiki Crazy. Everyone knows that.

For those that don't know what a wiki is (which rock have you been living under) Wikipedia will explain all.

So now, it is time to review some wiki software: DokuWiki. I've installed some wikis in my time. Some of them were okay, some of them were good, and lots of them were CRAP. Until I met DokuWiki, MediaWiki (the software that runs Wikipedia) was my all time favourite.

Was.

DokuWiki however is overtaking MediaWiki. DokuWiki is like MediaWikis faster cuter cousin. Installation isn't too difficult at all. About the hardest thing you need to do is make a few directories webserver writable.

The reason why a wiki does its thing so well is that it takes simple text, and transforms it into HTML, which, if you don't know, is the stuff that makes the web go.

Basically it lets you turn something like this:

== A big Title
This is some normal, **bold**, //italic// text

into this:

A big Title

This is some normal, bold, italic text

This conversion from somewhat normal text into the cryptic goblety-gook of HTML is what makes a wiki so good. This somewhat-normal-text is called "Wiki Markup" Hell, I know HTML like the back of me hand, but I still prefer using good Wiki Markup instead. DokuWiki has absolutely excellent wiki markup. It is simple enough to use, but is remarkably effective.

DokuWiki also has a good selection of plugins to extend what kind of syntax you can have in your wiki. This goes from the simple (plugins for displaying the date according to the users region) to the massively complex (a blog plugin, so that you can use your wiki like a blog). Programmers can easily write their own plugins, and the plugin API is pretty well designed.

There is also the option of adding different media types to DokuWiki, such as images, PDFs, and pretty much anything else you could imagine. This setup doesn't seem as powerful as MediaWiki's handling of ... well... media, but it is easy to use and elegant.

And unlike lots of other PHP projects, the directory structure is laid out properly. For most people this really isn't an issue, but as a programmer I respect the level of organization and detail. Another big plus is that it uses the PHP native templating engine. Which is to say, the writers of the software use PHP the way it is designed to be used, instead of writing (or using) massively complex parsing engines to display some HTML.

The code quality of DokuWiki is good. The code is done up so that there is no newline between braces, which I find annoying, but that is just a question of style. The code itself is well commented, both for each function and inline. I think that the variable names and function names could be a little clearer, and a little more modular, but the programmer at least knows what refactoring is.

So the verdict is... if you need a wiki installed, DokuWiki is the one.

Update: I linked up Dokuwiki. Duh. I also added my own wiki at wiki.jonnay.net.

Gaim is a multiple IM service client, like Trillian. It however seems to be pretty good. Half the memory footprint, and free + open source. I'll post a review in about a month when the honeymoon wears off.

There is a known problem when using Gaim with Cygwin (a linux environment for windows) if you have your system path set to the Cygwin bin dirs. The documentation for gaim actually hints at the fix:

If you have a Cygwin installation (with tcl 8.4), and have added its bin directory to your PATH, then WinGaim will crash on startup. The solution is to remove cygwin's bin directory from your path. Introducing Cygwin dlls into the native win32 environment is a very bad idea, and is likely to cause problems with other programs.

The fix is simple, instead of having the Cygwin paths on your global environment table, you just want it for your shell windows. Write up a simple little batch script to modify the path like so:

@echo off
set path=%PATH%;[Cygwin]\bin;[Cygwin]\usr\bin
echo This is my shell of DOOOOOOOOOOOOOM!

After that, setup a shortcut to: %windir%\system32\cmd.exe /K [your batch file]. The /K switch tells cmd to keep the shell window open. Bam. Cygwin and GAIM goodness.

Update: Sometimes Gaim will half-crash on startup. It won't actually die, but it won't do anything else either. This can happen if you install something like WinAVR which uses CygWin, and it adds itself to your path. If you find Gaim crashing all of the sudden, then check out each entry in your PATH environment variable and make sure there are no cygwin dlls.

This is part II of my series on Ajax and REST. For more info, see part I. In part I, I said that I would flesh out the AJAX/REST interplay. Unfortunately, before I am able to do that, I have to lay in some groundwork.

I'm good with the PHP. I know my way around the language. Because I want Fuchi to be coded up quickly, I am using PHP for it. Now, I would really rather do it in scheme, but there doesn't seem to be much in the way of intarweb scheme goodness.

So I tried to implement a PUT handler in PHP. My god. The pain.

Apparently PHP before 4.3 threw an HTTP error 405 (Request method not allowed) when it encountered a PUT or DELETE (or quite possibly an OPTIONS or TRACE). Post 4.3, PHP handles PUT and DELETE requests, but to tell you the truth, I don't know where it stashes the variables. I don't think that the superglobal $_REQUEST is populated. And I am sure that there is no $_PUT or $_DELETE. (Attn: PHP Devs. MAKE IT GO! ;) )

So I have had to build my own handler for PUT and DELETE requests. I'll be posting a link a little later on to the class. Its pretty basic, but that is the whole point, a basic, standard interface that you can use to write RESTful applications.

If you want to play with REST and PHP, and don't want to wait for me to post my code (or even just don't want to use it...) I'll give you a few pointers. Obviously there is the $_SERVER['REQUEST_METHOD'] superglobal that gives you, of all things, the request method. Form data from the request is sent in the body of the request, usually with an accompanying content-type. The input stream works for getting access to that data. According to the manual:

php://input allows you to read raw POST data. It is a less memory intensive alternative to $HTTP_RAW_POST_DATA and does not need any special php.ini directives.

Of course, the format of this data depends on the content-type. There really is only 2 applicable types. This should help you out in parsing the form data. So the trick is to open the php://input stream for reading, and parse the data.

Update: Fixed some bad markup. Sorry 'bout that.

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.