So without further ado, the big announcement is that I’m working on a new language called Seph. […] Why? I already have Ioke and JRuby to care for, so it’s a very valid question to ask why I would want to take on another language project […]. The answer is a bit complicated. I always knew […] that Ioke was an experiment in all senses of the word. This means my hope was that some of the quirky features of Ioke would influence other languages. But the other side of it is that if Ioke seems good enough as an idea, there might be value in expanding and refining the concept to make something that can be used in the real world. And that is what Seph is really about.
— Preannouncing Seph

This will be an informal, and highly technical, talk on a really interesting new language. Come along for a chance to ask your questions. Also, to enjoy some free beer and pizza. There’s a pretty good chance that Martin Fowler may be in the room, though I’m not promising anything…

Where?

ThoughtWorks Sydney Office, Level 8, 51 Pitt St, Sydney

When?

Wednesday, 8th Sept; 6pm for a 6.30pm start

Who?

You! Assuming you’re a developer interested in learning about languages.

How?

RSVP to Giles Alexander as I need some idea of numbers.

And that’s all you need to know, see you on Wednesday.

And these are all wonderful things. But, from the inside I think we forget the single best thing about agile software development:

Agile means your customers no longer want to throttle you.

Don’t forget this: it keeps everything in perspective.

My first real software development job out of Uni was at a small technology company. We had a core product, an expert system runtime, that the company was built around. We were organised into two major divisions: Products, who worked on the core technology; and Solutions, a traditional consulting division who delivered projects (usually) based around the core technology. Products would have been about 20% of the company’s employees. The rest, admin staff and Solutions.

I worked in Products. I like to think we did good work: during the four years I was there the product became much faster, finally ran on more than one OS, supported multiple platforms and countless other features were all delivered. Delivered on a three month release cycle. We had a roadmap of releases covering the next year and a half or so, with features allocated to each release. And every three months there’d be a new, mildly tested, release that had some of the planned features, some last minute features and a bunch of bug fixes and improvements for features from the last couple of releases.

At this point I would like to remind the uproariously laughing peanut gallery that this was my first job out of Uni and I knew no better. Clearly, neither did any of the managers.

I can still remember the moment of revelation when I discovered that all of Solutions hated us. Hated the Products staff, hated the product. One wag had joked that the company was divided into Solutions and Problems. How could this be? Our technology was great! Really! It was genuinely the best of its kind in the world. Why did they hate us so much? How could they hate us so much?

It’s obvious now: Solutions were trying to win new business and then deliver projects on time and budget. Invariably they’d find bugs in the product, or new features they needed. And our response? “It’s too late for this release; we’ll try to include it in the next one.” In four months time.

Now on an agile team what would I say? “OK, we’ll include that bug fix in the next iteration. You’ll have it Friday week.” That’s a bit glib of course. In reality there will have to be a discussion about what is going to get pushed out of the next iteration, and estimation of how long the new work will take. But when your answer can honestly be in terms of tested, working software and a couple of weeks delay, everyone is happy. And in particular your clients are not going to be frustrated and furious.

On only a couple of occasions since have I had to be the client to a waterfall team. And every time I’ve ended up wanting to throttle them: “How can it take as long to plan the work as it’s going to take to do, ferchrissakes?” And every time I have to remind myself that they’re not trying to be difficult — they genuinely want to help — it really is just this hard to turn the boat.

There was one aspect that Orwell did get glaringly wrong: the impact of technology. the limited technology shown in 1984 is all very much in the service of the state: the newspaper re-writing tools and the continuously broadcasting screens for example. But these two are both very poor predictions of how technology actually evolved over the three and a half decades between writing 1984 and 1984. Photocopiers deeply limit the effectiveness of re-writing newspapers – people would have their own copies, not much point in changing the centrally stored version then? And a network of screens continuously streaming into everyone’s homes? That’s just crying out to be subverted as a peer-to-peer network.

But these are just details and a symptom: Orwell got something much more fundamental, and surprising, wrong.

Technology is inherently liberating, not controlling; equalising not oppressive.

How is this possibly so? Modern history is replete with examples of dictators using weapons technology to do pretty horrible things in stamping out rebellion and even more recent history shows huge corporations attempting to do exactly what Orwell predicted, to their customers. But these are just anecdotes. Other anecdotes show mobile phones and hand-held GPS units being of incalculable aid to rebels. Corporations are trying to spy on their customers precisely because they were completely blind-sided by developing technology. I want to address a more fundamental point than these anecdotes.

Technology is probably reasonably described as the output of humanity’s tool-making instinct. No one really thinks of it as broadly as that, especially now. It’s inconceivable to regard the chair and the kettle as technology even though they were both once cutting-edge. Instead, technology is regarded as the recent output of our tool-making instinct. There is a question going begging here though: how do recent technological developments migrate into that background of things we just have?

Going back beyond the kettle and the chair, the spear would have once been cutting edge technology, developed after extensive R&D and in the face of punishing market conditions and intense competition by some family somewhere in the African savannah. The immediate effect of this new development within that family would have been stunning. Instead of only the elite runners capable of running down an antelope being the ones providing meat, anyone strong enough to wield a spear suddenly could. Given the very different physical requirements for the two hunting techniques this was certainly a different set of family members. And right there, the spear as a piece of technology has liberated some members of the family. Sure, hunting is still the domain of strong, young males, but this is the savannah of African a million years ago we’re talking about; it took until 1900 before we even gave women the vote. Equality is a luxury the ancient savannah could never afford.

This is still just a fascinating theory, but think on the implication: the spear was a valuable piece of technology because it helped overcome a physical limitation of the family. And this is generally true of all technology: it is valuable when it lets people do something they otherwise couldn’t. Technology is about placing the unobtainable within more people’s grasp – but not by devaluing the goal, instead by extending the grasp. As the spear placed more meat within the grasp of the family on the savannah, so the mobile phone places more of your friends within range of a chat or a helping hand now. Technology is leverage; it takes what you are already capable of and then by adding a little more in just the right way, makes you capable of something new. By it’s very nature technology is about raising the average standard of what can be achieved, leveling the field for all.

It is, in two words, inherently empowering. And to me, this is the answer to that question. When technology perfectly articulates its own empowerment it migrates into the background of society, no longer a big deal. Just there for everyone to enjoy.

Of course, that’s not to say all technological developments achieve this holy grail of leverage. Much development results in brand new technology that never sees widespread use. Many times this is the natural inefficiencies in a capitalist market. Frustrated technologists try to cope using open forums for ideas and development. Open source is a modern example, but public universities have always openly shared their work.

But still we see failures of technology.

Now, if you accept that technology has succeeded when it multiples out the abilities of humanity then the development of the technology is just part of the problem. Just as important is the interface between it and actual living, breathing humans. For technology to effectively leverage our abilities, it must become an invisible extension of ourselves; the interface, the line the technology draws around us, must be a perfect fit between humans and that goal, right there, the one they’re really after. Without something close to perfection, you’ve got just another disappointment, and worse: a waste of someone’s time spent thinking. There is a huge class of ignored and overlooked problems here in these interfaces. These are problems of design; not in the narrow ‘how-does-it-look’ sense, but in a much deeper ‘how-is-the-functioning-of-this-going-to-interact-with-a-human’ sense.

And I have come to realise that this is a question that I care deeply about. Technology is not an end-in-itself. It must be designed to be used. No, that’s too weak. Technology must be designed to make people’s lives better. When designing something don’t just think ‘how will this be used?’ Instead, think ‘how will this make someone’s life better?’ Don’t waste your life on simple, easy half goals: aim for the big one. Find your target market and work out how your idea will make their life better. And I mean, really make someone’s life better. Imagine your product fully integrated into their life. Can’t see it yet? Well, back to the design then. You’re aiming for a glove here. Accept nothing less.

Looking back at some of my essays I can see that I’ve been talking around this indirectly for some time. I recently listened to a podcast by Merlin Mann of 43 Folders and John Gruber of Daring Fireball that managed to crystallise my obsession for me. So I’m now planning of focusing on this idea. I want to see technology designed first and foremost to interact with humans, to fit into their lives invisibly and to thus make their lives better.

There will still be book reviews, because I love to read and writing those makes me a better reader, but I will be attempting to focus my other writing on this central idea: Technology Designed around People. I have no idea if I’m going to succeed, but at least focusing my rants might make me less annoying to be around. I also believe that society has a fixed amount of attention, this will be an attempt to focus some of that attention where I think it should be.

I’ll be keeping it in mind, I believe it will become more important.

Well, a script isn’t much use to me or anyone else: you can’t run a script on an iPhone. So like all software wants to be, this script is now a simple little web application: mutual. Please be gentle, and I know I’m not a designer.

This should be the start of more useful little applications like this appearing. I’ll blog about that. Also, for the programmers out there, this is written using the Sinatra Ruby web application framework. If you thought writing apps using Rails was fast, well, you ain’t seen nothing til you’ve seen Ol’ Blue Eyes take the stage.

I want to be able to ask the question ‘Who do we know in common?’, in short. A useful question, but one that can take quite a while to answer using the web site. I asked the lazy twitterverse if there was already an app for this, but my twitterverse is too small to get an answer. So, I wrote my own script. I don’t have any handy web space to run this from, so you’ll have to grab it and run it yourself. You will need to install the twitter4r gem first:

sudo gem install twitter4r

Then paste the following code into a Ruby file, and run. It takes two parameters, the names of the two users for who you want to find common ground.

require 'rubygems'
require 'open-uri'
require 'rexml/document'
require 'twitter'

class Twitter::User

  def all_friends
    users = friends.map { |f| f.screen_name }
    # If there's more than one page of users, we've already got the
    # first one
    page = 2
    found_users = friends.length
    while found_users >= 100
      found_users = 0
      open("http://twitter.com/statuses/friends/#{screen_name}.xml?page=#{page}") do |f|
        users_doc = REXML::Document.new(f.readlines.join(''))
        users_doc.elements.each('/users/user/screen_name') do |friend_name|
          users << friend_name.text
          found_users += 1
        end
      end
      page += 1
    end
    users
  end

end

def in_common(my_friends, other_friends)
  my_friends.select { |m_n| m_n if other_friends.member? m_n }
end

def main(me, other)
  c = Twitter::Client.new
  me_friends = c.user(me).all_friends
  other_friends = c.user(other).all_friends
  in_common(me_friends, other_friends).each do |f|
    puts "  #{f}"
  end
end

main(ARGV.shift, ARGV.shift)

Enjoy, and please let me know how it works out for you, or if you make any changes. And by the way, *this* is why RESTful APIs rock.

Short answer: yes, with an if. Long answer: no, with a but.

If you want to be working in computer science, you’ll probably be programming. A lot. And in fact, this is probably what you want to do. Like all professional skills, programming takes a large amount of practice before you become truly proficient. The commonly cited figure is 10,000 hours of practice to become proficient in your chosen profession. The sooner you get started on those 10,000 hours, the sooner they’ll be over.

Becoming involved with an open source project is a great way of getting your practice in. You could also practice on your own project of course. But, you’ll get more satisfaction from contributing to an open source project that others use. To become involved though, you’ll need some level of proficiency. So hack around with your own projects; write a game; then start reading the mailing lists of an open source project you use and pick a simple bug from the tracker. There’s lots of advice out there on how to become involved, I’ll leave that up to you.

That’s a pretty good reason to become involved with an open source project. And if that is your reason, head on out there kid, you’ll do great.

That’s the ‘if’. Now for the ‘but’.

Notice above that I referred to getting involved with an open source project? Not the open source community? If you’re a particularly bright kid in your class, then please let me beg you to think deep and long before becoming involved in the community.

Why are computers important? Step outside of your beloved field for a moment and ask yourself, why do you think computers have been an important and interesting invention? Why is writing software for expensive, abstract machines to be used by the middle-class of the first world a noble endeavour? How can better computer science help people? I mean really help people. Not allow them to quickly find a cheaper price on that expensive gadget they don’t need, but do the really important things: cure malaria, educate the third world, connect with strangers, fall in love. Whatever it is you think needs solving.

Personally, I do think computer science has the potential to make the world a better place. And I believe you don’t need to be working in some research lab to achieve that. My definition of making the world a better place is simple: find someone with a problem, solve it, and leave them to find other problems in need of solutions. As an organic, growing, network every individual has the ability to change the world for the better by focusing on this question: where do I see problems that my expertise can help solve?

And here lies my issue with the open source and free software communities: being able to recompile the kernel to your operating system is a problem that only other programmers have. The rest of the world see computers and software as tools to solve their own sets of problems. Anytime a computer or program does not do what they want, a problem goes partially unsolved. And that particular unsolved problem is a problem you’re simply unqualified to solve. You, as a programmer, can only ever indirectly help with those problems.

Lifting our heads outside of our insular worlds of programmers and computer scientists, we can see that the rest of the world has a problem with computers. These supposedly powerful devices, that the first world has invested a huge amount of resources in improving over the last 20 or 30 years just don’t seem to have reached their potential. Instead, rather than constant improvement with the goal of improving the lives of real people, computing has become insular. Insanely insular. Programmers either solve problems only other programmers have, or they simply duplicate the work of other projects, poorly. Very poorly. And this is most obvious in the free software communities. In my opinion, the world does not need another poor implementation of a 38 year old operating system. The world does not need another poor duplicate of photo editing software. The world does not need another poor duplicate of office productivity software.

The world needs the potential of computers applied to new problems. Or, at the least, original solutions to already solved problems. And in my opinion the free software community, in its current incarnation, will never deliver on either of those. The free software community is tackling what they see as a moral and ethical problem: source code wants to be free. Their current solution to this problem is to duplicate every popular piece of software with a suitably free license. So entrance into the free software community requires accepting this, and then duplicating existing commercial software. To me, that sounds like a complete waste of my brain.

And if you’re as bright as I think you are, then it sounds like a complete waste of your brain as well. Please, choose to advance our industry, take it in new and interesting directions. Start your own company, work for a large company. These are not immoral decisions. You will be advancing the sum total of human knowledge, you will be solving real problems of other people. People without the expertise to solve these problems. Expertise you have.

And this is without even getting into the ethics of duplicating someone else’s work.

The free software rhetoric can also damage both computing and free software. Personally, I found the moral aim of the One Laptop Per Child program repugnant. But, their efforts to re-imagine what computers could be was exciting and full of potential. But, eventually all for naught as the program has been tried, found guilty and executed in the court of free software. Why? Because they chose to use a non-free (gasp!) wireless network driver and because they chose to allow Windows to run on the device. The project was found wanting, and abandoned. Why does the choice of underlying operating system matter that much? If the project believes their new approaches were of value, why not try to improve Windows? It’s not as if these computers would be powerful enough to re-compile Windows anyway, even if the code was available.

You’re young, you have brains, you have energy. Please think about it before deciding that the free software community is where you want to devote your energy. Do not write off working for Google, Silverbrook Research, ThoughtWorks, or even Microsoft. There is nobility there, I dare say more than there is to be found in holding back our industry.

• When you are working on projects you will sit down with someone with a problem. You’ll get to know that person and their problem intimately and personally. Hopefully you’ll then solve their problem and leave them in happier and better place. All thanks to the expertise you have imparted.

• When you are working on products you will not have this personal connection with your customers. Instead you will attempt to imagine how all the possible customers in the world could potentially want to use your product. You’ll try to place yourself in an enormous range of situations and attempt to make each of those a bit better. Hopefully, if your product is completed and a success in the market then you will have made the world a better place for a huge range of people. None of whom you’ll ever know.

So… satisfaction from helping just a few people you know well, or satisfaction from helping a huge range of people you’ll never know? Of course, if you do choose to work on projects then you’re guaranteed to help people, whereas products succeed far less often.

We’re pretty happy with this set up. It’s already found a couple of bugs in some plugins we’re using. More on that in an upcoming post. Here’s how we made our automatic deployment work. We’re using Capistrano for our deployment scripts, we’re deploying to Phusion Passenger running under Apache on FreeBSD and our continuous integration server runs an Ant script.

These instructions describe how to set up a Apache 2.2 web server with Phusion Passenger on FreeBSD; the Ant script to automatically deploy and how to configure a Rails app to be deployed like this.

This will give you two new environments for your apps: DEVTEST and UAT. UAT is a user acceptance testing environment, our system testers and analysts use and own this environment. We don’t automatically deploy to here, we release to here. DEVTEST is the environment we automatically deploy to.

Setting up Your Server

Installing Phusion Passenger

Installing Phusion Passenger on a FreeBSD server is no different to installing anywhere else:

$ sudo gem install passenger
$ sudo passenger-install-apache2-module

Configuring Apache

At the end of the second step, the installer tells you to add some config to the end of your Apache config. On FreeBSD, edit this with:

$ sudoedit /usr/local/etc/apache22/httpd.conf

And then add the following at the end:

LoadModule passenger_module /usr/local/lib/ruby/gems/1.8/gems/passenger-2.0.3/ext/apache2/mod_passenger.so
PassengerRoot /usr/local/lib/ruby/gems/1.8/gems/passenger-2.0.3
PassengerRuby /usr/local/bin/ruby18
NameVirtualHost *:80
<VirtualHost *:80>
    ServerName devtest.example.com
    ServerAlias devtest
    DocumentRoot /usr/local/www/rails/devtest
    <Directory "/usr/local/www/rails/devtest">
        Options FollowSymLinks
        AllowOverride None
        Order allow,deny
        Allow from all
    </Directory>
    RailsEnv "devtest"
</VirtualHost>
<VirtualHost *:80>
    ServerName uat.example.com
    ServerAlias uat
    DocumentRoot /usr/local/www/rails/uat
    <Directory "/usr/local/www/rails/uat">
        Options FollowSymLinks
        AllowOverride None
        Order allow,deny
        Allow from all
    </Directory>
    RailsEnv "uat"
</VirtualHost>

Unless you want to use two different servers for the two environments, you’ll need to use named virtual hosts, and ask your friendly administrator to add CNAME records to your DNS server pointing devtest and uat at the same physical server. They’ll know what you mean.

Create a Local User

You’ll need a local user on your server. This is the user that will run the automatic deployments.

$ sudo adduser
Username: deploy-robot
Full name: Deployment Robot
Uid (Leave empty for default):
Login group [deploy-robot]:
Login group is deploy-robot. Invite deploy-robot into other groups? []: www
Login class [default]:
Shell (sh csh tcsh zsh nologin) [sh]: 
Home directory [/home/deploy-robot]:
Use password-based authentication? [yes]:
Use an empty password? (yes/no) [no]:
Use a random password? (yes/no) [no]:
Enter password:
Enter password again:
Lock out the account after creation? [no]:
Username   : deploy-robot
Password   : ****
Full Name  : Deployment Robot
Uid        : 1001
Class      :
Groups     : 
Home       : /home/deploy-robot
Shell      : /usr/local/bin/sh
Locked     : no
OK? (yes/no): yes
adduser: INFO: Successfully added (deploy-robot) to the user database.
Add another user? (yes/no): no
Goodbye!

Deployment Directories

Set up the directories to hold your applications.

$ sudo mkdir -p /usr/local/www/rails/devtest
$ sudo mkdir -p /usr/local/www/rails/uat

These are the web roots for each of the environments, but applications will not be deployed here. Instead, symlinks will be created from here to where the applications are actually deployed.

$ sudo mkdir -p /usr/local/app/rails/devtest
$ sudo mkdir -p /usr/local/app/rails/uat

These last two directories, and everything under them should be owned by the deployment user you created above.

$ sudo chown -R deploy-robot:www devtest uat

Gems

Finally, there are some gems you’ll need installed on the target deployment server. Some of these depend on FreeBSD ports.

$ cd /usr/ports/comms/ruby-termios
$ sudo make install clean

And then just a couple of gems.

$ sudo gem install termios
$ sudo gem install capistrano

And that’s it for initial server configuration. There will be some more configuration when first deploying an application.

Preparing Your Application

Capistrano Config

Capify your application:

$ cd app
$ capify .

Edit your capistrano rules in deploy.rb. You’ll want them to look something like the following. These rules use no source control system to get the code. Our continuous integration server takes care of checking out the code, so it’s easier to deploy from the local code copy. And, this way we can be sure each deployment only contains one changelist.

# Overall config
set :use_sudo, false
# Application config
set :application, "app-name"
set :default_env, "production"
set :rails_env, ENV['RAILS_ENV'] || default_env
# Deployment source and strategy
set :deploy_to, "/usr/local/app/rails/#{rails_env}/#{application}"
set :deploy_via, :copy
set :scm, :none
set :repository,  "."
# Target servers
set :default_server, "localhost"
set :dest_server, ENV['SERVER'] || default_server
role :app, dest_server
role :web, dest_server
role :db,  dest_server, :primary => true
# Phusion Passenger specific restart task
namespace :deploy do
    desc "Restart Application"
    task :restart, :roles => :app do
        run "touch #{current_path}/tmp/restart.txt"
    end
end

Environment Configuration

Set up the two new environments for your application.

$ cp config/environments/production.rb config/environments/devtest.rb
$ cp config/environments/production.rb config/environments/uat.rb

Somewhere inside both those files you’ll need to set the RAILS_RELATIVE_URL_ROOT as the application will be running at a sub-URI on your server and Rails needs to know that. Something like:

ENV['RAILS_RELATIVE_URL_ROOT'] = "/app-name"

The two new environments will also need to be described in your database.yml file. This of course depends on your specific database server setup, so I’ll leave that bit to you.

Server-side Application Setup

Apache needs to know about the applications, and there needs to be symlinks from the web root to the application deployment folder. This setup only needs to be done once for each application.

To add the application to Apache, edit /usr/local/etc/apache22/httpd.conf again, and in the VirtualHost section for the devtest environment, add a line like the following:

RailsBaseURI /app-name

Now, set up the symlink:

$ ln -s /usr/local/app/rails/devtest/app-name/current/public /usr/local/www/rails/devtest/app-name

And you’re done with the application configuration.

Ant Deployment Scripts

Our company has an in-house continuous integration server. We’d be too embarrassed at cocktail parties if we didn’t have our own. Yes, yes, I know this is completely ridiculous. And to make it even worse, it only runs Ant scripts. Sigh. Anyway, here’s how you make Ant automatically deploy an application to devtest.

In a file called definitions.xml:

<project name="definitions_rake">
    <macrodef name="rake">
        <attribute name="app" />
        <attribute name="target" />
        <element name="variables" optional="true" />
        <sequential>
            <exec executable="rake" dir="@{app}" failonerror="true">
                <arg value="@{target}" />
                <variables />
            </exec>
        </sequential>
    </macrodef>
    <macrodef name="capistrano">
            <attribute name="app" />
            <attribute name="environment" />
            <attribute name="task" />
            <sequential>
                <exec executable="cap" dir="@{app}" failonerror="true">
                    <env key="RAILS_ENV" value="@{environment}" />
                    <env key="SERVER" value="${project.server}" />
                    <arg value="@{task}" />
                    <arg value="-s" />
                    <arg value="user=${project.user}" />
                    <arg value="-s" />
                    <arg value="password=${project.password}" />
                </exec>
            </sequential>
    </macrodef>
    <macrodef name="deploy">
        <attribute name="app" />
        <attribute name="environment" />
        <sequential>
            <capistrano app="@{app}" environment="@{environment}" task="deploy:setup" />
            <capistrano app="@{app}" environment="@{environment}" task="deploy:migrations" />
        </sequential>
    </macrodef>
    <macrodef name="test">
        <attribute name="app" />
        <sequential>
            <rake app="@{app}" target="db:migrate" />
            <rake app="@{app}" target="test" />
            <rake app="@{app}" target="spec" />
        </sequential>
    </macrodef>
</project>

Ant macros, while quite insane, are generally a better way to define new tasks than the complete insanity of trying to write a whole Ant plugin in Java. These macros define low-level tasks to run rake and capistrano tasks, and then use these to build up higher level tasks like test and deploy. All these tasks assume that Ant has been run from the directory immediately above your Rails app directory.

In a file called project.properties, set your server, user name and password. Having the password here is unfortunate, but it is a local account, with limited privileges on an internal server. Your call.

user=deploy-robot
password=deploy-robot-password
server=deployment-server

In a file called build.xml:

<project name="aegean" default="build">
    <import file="./definitions.xml" />
    <property file="project.properties" prefix="project" />
    <!-- Sample application.
         To add a new application:
         1. Copy the following targets.
         2. Replace 'depot' with your Rails app name.
         3. Add the 'app name' target as a dependency of the target 'build'.
    <target name="depot.deploy.devtest">
           <deploy app="depot" environment="devtest" />
    </target>
    <target name="depot.test">
           <test app="depot" />
    </target>
    <target name="depot" depends="depot.deploy.devtest, depot.test" />
    -->
    <target name="example.deploy.devtest">
           <deploy app="example" environment="devtest" />
    </target>
    <target name="example.test">
           <test app="example" />
    </target>
    <target name="example" depends="example.deploy.devtest, example.test" />
    <target name="build" depends="example" />
</project>

The large comment block is just helpful for other developers trying to add another application. From here, to try this out:

$ ant

It should run the deployment, and then run the test suites. If that works as you expect, then just configure your continuous integration server to run Ant over that file on every submit.

Hopefully this is of use to someone. Though this is how our environment is configured, I have written this all from memory, so I might have missed a critical step somewhere. Please let me know if there’s anything that needs to be changed.

1. It refreshes the page after you close a tab. This is pretty irritating. Particularly if, like me, you only show unread items. Things disappear while I’m still reading them. Aargh!

2. The big one: they ‘mobilize’ web pages. That is, instead of linking to the original version of every item Google has decided to link to a rewritten version of the item. Supposedly this version will be more readable on the iPhone. Well, the iPhone actually has a really good browser. But they’ve actually significantly broken something: the iPhone web browser recognises YouTube URLs and opens them in the built-in YouTube app. Because the iPhone web browser can’t play YouTube movies. The rewriting means that this doesn’t work. Thank you Google, thank you.

Anyway, there is one feature that I miss from Google Reader: sharing items. But there’s the whole desktop application thing going on. I’m now posting items I would have shared to my Twitter feed: gga, look for items tagged #feed.

So how do I this? A pretty simple piece of AppleScript:

tell application "NetNewsWire"
        set t to title of selectedHeadline
        set u to URL of selectedHeadline
end tell
tell application "Twitterrific"
        post update t & ": " & u & " (#feed)"
end tell

A single click from NetNewsWire and I’ve posted an item to Twitter. If you think you might be interested in items I’ve previously shared, follow me on Twitter.