I found this article via Architectures of Control from Adrian Short titled The Stepford Wives of Worcester Park which had a lot of interesting things to say about communities, curfews, and law and order. The real kicker is this paragraph:

I’ve long believed that the real cure for disorder on our streets isn’t to scour them clean of humanity, but to fill them up with people of all ages, classes and “lifestyles”, to encourage diverse activities and to promote the notion that we as citizens have equal responsibilities to be tolerable and to tolerate the reasonable behaviour of others. The notion is as old as cities themselves and defines the very essence of citizenship.

Which basically sums it up. Which then refers to the title of my own blog entry. You can't have a functioning community (a group of businesses and residences) without a community (a group of people working, interacting and living together). At the same time, an online community has similar, but different problems from a property based community. You have people interacting and possibly even working together, but they are so far removed from each other that arguments and misunderstandings run rampant. See the Internet Fuckwad Theory

The piece of social-software that can successfully solve for that would be a killer app.

And you don't even need a stamp.

First, go here: http://www.copyrightforcanadians.ca/action/firstlook/

Then fill out the form. Copy the preview result and print that out. Finish the groovy webapp, then send off the hardcopy.

Seriously, it takes 10 minutes. It it accomplishes nothing, then you've only lost 600 seconds of your life, 1 sheet of paper and an envelope (not even a stamp!)

But what happens if it could accomplish something?

If only I had a few bales of money... it appears that The catbus is (was?) for sale.

Damn.

Some Canadian researchers have gained insight into the nature of self control, and I find their conclusions fascinating. In a nutshell what they have found is that as humans, our capacity for self control is limited and shallow.

These researchers concocted an experiment where they made the subjects watch animal snuff movies, and one group was told to control their expressions and emotions, and another group was not directed in any way. Afterwards they were given a rapid colour matching test that requires a controlled response. What these researchers found is that the group that were told to suppress their emotions did poorly on the test, compared to those who simply watched the movie.

Apparently though, self control is like a muscle, and we can be trained to get more of it. Just like running a marathon might make it hard for you to walk right after it, it will have a positive effect on your overall endurance.

The interesting thing about this study implies about consumerism and addiction. In the case of consumerism, it suggests that marketers should work harder to test the limits of self control, and put people in a state of "self-control fatigue", as such people will be more prone to impulse buys. This then means that we can expect even more tests of our self control to happen as marketers use this to their advantage. The question then becomes: will we become stronger from a constant overload of self-control tests, or weaker? Sure a runner who runs every day will become stronger. But how about a runner who is forced to run all day, every day?

In the case of addiction this has all kinds of interesting implications. It means that one can work on the general case of self control through simple, measurable exercises, and then use that to apply to the task of overcoming ones object of weakness. This seems like a much stronger, and much more sustainable policy of dealing with addition, rather then through some kind of zero-tolerance style.

Finally, if self control is workable like a muscle, it means that if you work on it daily, you can increase your leel of self control. This of course, takes self control! It's a win-win proposition. Maybe in the future, I'll bblog about tools I have found that help one in such a venture.

(Source: The Futurist)

I've been playing with Cruise Control and Ant, trying to get a reasonable Continuous Integration server up and running. For those that don't know, a Cruise Control is a server that takes your source code, and tries to build it until you hit the big red stop button, or the heat death of the universe. Ant is a piece of software that performs the actual building of other software.

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.

This is my emacs.
There are many like this one, but
This emacs is mine.

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.