ONCE upon a time, I was a student that typeset things in LaTeX. Ha! Ha! How quaint! you may already be thinking, at which point I should point out I’m still typesetting things with LaTeX, and I probably will still be¬†typesetting¬†things with LaTeX whenever you read this. At any rate, I soon grew infatuated with the idea of cloud computing, and decided that I wanted my LaTeX to follow me everywhere I went: ‘like a Google doc’, I thought. I wouldn’t have to tote around a nearly gigabyte LaTeX install, meaning I didn’t have to carry a laptop OR a flash drive, which was somewhat significant since this was back when I regularly toted a flash drive around (ZOMG 4GiB).

Since the psychic overlords at Google seemed to fail to hear my strenuously thought pleas for a LaTeX addon to the Google doc system, I decided I might as well make one by myself, partly as a first project with Rails, and partly as a first large webapp project ever.

The Process

First, I checked the interwebs for people doing similar projects: it turned out that the only guys that were doing something like I wanted at the time were the guys running MonkeyTex. It seemed like a solid project, but the quality wasn’t that great, they didn’t seem crazy about upkeep, and no text wrap in the editor made it a deal breaker. Thus began my quest for an online LaTeX editing system.

I started coding near the end of spring semester, and got near feature completeness sometime at the beginning of the next fall semester, with feature completeness being whatever I thought was a good idea to have, among them image management (complete with on-the-fly image conversions!), chrooting of the LaTeX build process, and templates. I was being very loose with my development process, which boiled down to “code whichever feature I miss most right now”, which actually isn’t that bad for personal projects…

I should probably point out that EZLO was not the original name for the system. I’m terrible at choosing names for projects, either going for something way too flowery (ex. a long, long time ago (in high school!) (gasp!), I named one of my projects ‘Hammer of Dante’, and I don’t even remember what the project did. Something mundane and boring, I’m sure) or extremely utilitarian. In contrast to those, this one is just… weird. While trying to choose a name, I just asked one of my friends that happened to be in the lab for ideas, saw her keychain charm (which was named Orize, after the Japanese word for something beer related), flipped the word around, and got eziro, or ezlo. After coming up with that (which seemed unique enough), I only then came up with a backronym: EZLO stands for E-Z Latex Online. Then, I had a fun time renaming everything in the project to EZLO, and partially based my naming scheme around it (this ‘brew’ I reference in the code is in reference to the beer-related origin of the project name).

Eventually, new players started to come onto the field. Since I got to feature completeness, I had stopped working on EZLO, so by the time I found EZLO’s competitors, they were working better than EZLO was. I decided that it was time to kill EZLO, which was the only reason I was keeping a server in my room, and let others who had more time and experience take the field. EZLO hadn’t picked up any during her life, so it was easy to pull the plug and pack her away, along with the server that housed her.

Note, I whined about developing EZLO lots of times on my blog. Just saying, in case you wanted more.

The Code

Okay, enough talk, have some terrible code [0.8MiB]! BSD-licensed, go ahead and rip it apart. Do read the README (duh). Really, this was my first attempt at a large webapp, and the code not structured especially well. Heck, nothing is really good about it, which is partially why I stopped working on it. Of note, at least in my eyes, is the terrible design execution: if I haven’t learned anything else from EZLO, I should’ve learned that I should stop trying to design things.

Also note, the code last worked with Rails 2.2 and Ruby 1.8

The Post-Mortem

In retrospect, I did not put nearly enough effort into the project to make it a viable competitor in the space of webapps. Sure, it might’ve been usable/viable when I first released, but I didn’t advance it at all over the next year or so, when I discovered it had fallen quite a bit far behind the competition.

I probably should’ve also learned that if one wants to make some infrastructure, it needs to go up quick. For instance, one of the driving forces behind EZLO was a class requirement to typeset all lab reports with LaTeX, but I only started/kind-of-released EZLO almost at the end of the year, instead of near the beginning where it could have gotten some traction among, if no one else, my classmates, which probably would have gotten me to advance it faster, which would have made it better, which would have attracted more users, which would have gotten me to advance it faster…