Tags related to tag code
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.
Tuesday, November 21. 2006
Bitterboy is frequented in the presentation—randomly generated angry geek goodness.
now I have all but given up on PHP (at the moment—I am anything but static) occasionally taking pot-shots from the sideline at what I consider to be silly or misleading statements. That being said, I still do see the beauty of PHP, and I may return to it once again.
Or my mad science project will be successful, and I will have created a wind-mill-destroying monstor!
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.
Friday, November 10. 2006
PHP has one major thing going for it - it's simple nature lets developers keep things simple, and simple is good.--PHP Developer
PHP is not simple.
PHP's Type System is complex. Sure, dynamic typing is easy, but weak typing is weird. 5 + "10 little piggies" -> 15?
PHP's Object System is complex. It is Javas OO system grafted on top of a really basic system. Ironically, this is where PHPs type System gets so strong to be a real pain in the ass. Ever had to cast an object?
PHP configuration is complex. 3 words: php dot ini.
PHP has complex syntax.
There is also a vast volume of built in functions for php, and an even larger body of extensions. This is not bad (its very good in fact) but it hardly makes the language simple.
There are plenty of reasons to like PHP, but simplicity isn't one of them.
Wednesday, October 25. 2006
This server, is called zen-garden. zen-garden is my pet project. It is my tilting at a windmill, and it is rapidly approaching a 0.1 release. The fundamental difference between zen-garden and most other webservers is that zen-garden is built, and based around simple rules. You want to log every request to a database table? Write a rule that acts on every request, and writes the request info to the table. You want to run all of your HTML files through Tidy and or gzip to compress them? Write a rule to act on every response that doesn't already have gzip encoding, and has a content-type of text/html. As you can see, the rule-based webserver is a very powerful concept indeed.
Now you might be asking "How do you handle a request for a single page, a single CSS file?" The answer is simple: a rule to output the page or CSS file when the request method is GET, and the URI is /path/to/your/file. But imagine this, instead of making the webserver find the file, load it, and send it across the network, what if you told the webserver it should compile the serving of that file into itself on deploy time? What if part of the deploy is taking a source file in XML and doing some transformations on it, and then compiling the transformations into itself before deploying? But what if all this was developer friendly so that when working in a development environment, you don't have to deal with the daily grind of compile-test-debug, you could make a change to your file, and test it on the spot? zen-gardens host language is Scheme on Gambit, so it is interpreted for a really fast development cycle, but Gambit can also be compiled to C (which of course can be compiled to native code) so when it is time to deploy, your server will be fast.
The crux to zen-garden is the request-chains and request-handlers. A request-handler is a data structure, with 2 important parts: a predicate stating whether or not the handler should execute, and the handler itself. Both of these are functions that return booleans. A request-chain is really just a series of request handlers that are executed in a particular order, split out into 4 convenient phases: initialization, handling, fallback and finalization. A request-handler can be bound to any one of these 4 phases. If a request is not handled during the 'handling' phase, the fallback phase is executed, otherwise it is skipped.
The real interesting thing about this structure is that a request-handler can spawn a new request-chain. So you can have a request-handler that executes when the 'Host' header is set to 'my.foo.domain.com' that spawns a new request-chain. On top of that, there is nothing stopping you from dealing with requests in other ways, in fact, any way you see fit. Don't like my method of predicates and request chains and what have you? Write your own method of doing things. zen-garden is modular in design. Pull out the routine that I use to handle requests, and install your own.
Oh, and it is all under a BSD License.
For now, everything is available in a subversion repository, svn://panda-ba.sanriowasteland.net/zengarden/trunk . You will need the Gambit-C compiler and interpreter as well.