Tuesday, January 15. 2008
And by the time the heat death of the universe arrives, I think I may have it all working, and in a semi intuitive way.
To set up Cruise Control, and Ant for that matter, you need to use XML. XML is an alright, if not exceedingly and outrageously verbose method for describing in excruciating detail data, as well as meta-data—which is to say—data about data. (Whew!) The thing with XML, is that it is a flaming shit sack of metric fail when it comes to describing processes. Processes like the building complex bases of source code, executing them on very finicky server software stacks, launching automated functional tests against them, with each process (build, execute, test) running in its own separate virtual machine are a royal pain in the ass to describe in XML. Again with the flaming sack of fail.
I find it very fitting that in the top 10 search results for fail, Ant documentation comes up.
Ant was built to fulfill a very specific need, which is, to help the process of compiling and bundling Java software together. It does an alright job at this, not stellar mind you, but alright. If you happen to be doing exactly what most other Java programmers are doing, deploying roughly what they are deploying, then you could do a lot worse then Ant. But the second you add any kind of complexity into the pile, it starts to show its warts. It's like playing with a plastic lightsaber; it looks great when you are just waving it around in the dark, but once you actually hit something, sparks don't fly, it just goes snap and it ceases to be any fun. Now you just have broken plastic.
The problem with Ant, Cruise Control and building software in general, is that the process is not linear. While it may be useful to have a descriptive language like XML to describe dependencies between Java files, it is absolutely horrific if you need to do things like conditions (if the build failed, then send a nasty gram to the developer and a 50K volt shock to his chair) or do complicated actions (munge this file to make it actually XML).
A lot of its complexity lies in its dependence on XML as a Domain Specific Language. To make a human languages analogy, it's like learning to speak Esperanto in order to practice Zen Buddhism—one perhaps feels that if they just took up Japanese instead, they might have gotten the job done a lot quicker, with less mucking about.
What strikes me as absolutely insane about Ant, is that when you have a reasonably hard job of working some behavior into your build script, solutions like "run XSL transformations on your Ant Script to give it behavior" are floated about, all with seemingly a straight face.
All in all these are good tools if you want to look like you are working, and enjoy tinkering around with XML, but if you are working towards the goal of building rock-solid, stable, testable software that in any way deviates from the norm, with the intent of releasing a maintainable, easily understood system in a reasonable amount of time, well, that tool isn't built yet (to my knowledge). Rake, being a ruby build tool written in ruby, might be close though.
A good Build Tool would be one that looks similar to, or is just an extension of the language you happen to work in, thus making the entire concept of a separate integration server redundant. Instead of having to bundle the build tool with the integration server, you end up allowing the user to write (in relatively few lines of easily abstracted code) the loop which is the crux of the Continuous Integration server inside of the build tool.
I bet it's built in Scheme.
Monday, July 9. 2007
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.
Tuesday, July 3. 2007
In my previous entry, I described how one could set up selenium to runs tests from emacs, via the Moz REPL. The most painful part of all of that is setting up the REPL to run. After every firefox startup, you have to manually go to tools menu, and manually select 'MozLab' and then 'Start REPL'. YUCK.
Enter UserChrome.js. With a little more polish, some documentation, and something more then a MozillaZine forum posting for a website; this little extension is poised to become the new GreaseMonkey. It will be the GreaseMonkey for the hard core.
Monday, June 25. 2007
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.
- you can script your browser from emacs
Update 2007-07-09: new versions (Version 0.2) added
Here are the two files:
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.
Wednesday, June 13. 2007
Snarf this, and toss it in your .emacs.
;;;;;;;;;;;;;;;;;;;; ;; set up unicode (prefer-coding-system 'utf-8) (set-default-coding-systems 'utf-8) (set-terminal-coding-system 'utf-8) (set-keyboard-coding-system 'utf-8) ;; This from a japanese individual. I hope it works. (setq default-buffer-file-coding-system 'utf-8) ;; From Emacs wiki (setq x-select-request-type '(UTF8_STRING COMPOUND_TEXT TEXT STRING)) ;; MS Windows clipboard is UTF-16LE (set-clipboard-coding-system 'utf-16le-dos)The part about the clipboard-coding-system is essential for MS windows users who want to transfer content back and forth between windows apps and Emacs.
Saturday, March 31. 2007
Really this project was the project that I "Grew up on.". This was really the project that turned me from a Junior Web Developer to a Senior. It feels good to have something this big, and this significant (at least, to me) out the door.
So, if you read French, German, Spanish, Portuguese, Russian or Japanese (or are just interested) check the site out.
Wednesday, November 15. 2006
Click here to download the tar file
Here is the documentation
I am currently working on a set of macros as a sort of object-relational layer between the DB and scheme. Obviously this not a true object relational... anything, because there are no real (native) objects in scheme. More info forthcoming.