CoolThePlanet.net has gone into softlaunch. Feel free to browse around, add things, use things and generally kick the tyres.
If you find anything leave us a message here
We'll be rolling out a second site on the platform, hopefully by the end of the week.
I don't know what it is but when there's a hard way or an easy way to solve a problem I generally want to have my cake and eat it, i.e. take the hard way. Fortunately I can restrict this urge and keep the habit out of my work as appropriate for the most part, but that just makes the itch even more in need of scratching occassionally.
Suddenly creating inbound email support was the tip of the iceberg - it was time to create the ability in Trac to have background tasks that don't require a page request to invoke code, in a cross platform way, which could ultimately be used to periodically trigger Trac code to check remote IMAP or POP inboxes for emails to tickets.
Read on to see how my pet project has turned out...
Ximon just found this very useful page of Unicode strings
http://trac.edgewall.org/wiki/TracUnicode
which will make breaking the software of potential suppliers that much easier. I think it's fair to say we could be using any of the languages on that list - and indeed we use most of them on a daily basis. The only one I don't think I've seen any need for in the last two years is Vietnamese.
Sadly lack of good UTF-8 support is one of the reasons we end up building so much software rather than taking off the shelf products. If it doesn't work in Rekjavik, Beijing, Hamburg and Bangkok it's just not that useful to us...
This morning I sat down with part of our research team to discuss how they can document their requirements for a new software system. We suggested they write user stories, and once they'd seen the spreadsheets for a couple of our existing projects they enthusiastically agreed.
Then I went to a meeting to discuss the development of a new discussion forum. The campaign team had already produced a set of user stories and we spent the time working through them, discussing some implications and generating the next set of requirements, again in the 'As a ', 'I would like to', 'so that' story format.
This afternoon has been spent working on the next round of stories for the write-a-letter application, work which was interupted to explain to the finance department how they might want to describe an IT project. Finally we just sent out tender documentation for a new co-location facility to handle our hosting and that too was in story format.
End result is one simple story
As a project manager I want to spend some time not working on stories so that I remember how to think without them
Slowly but surely we're moving our projects over to Trac and away from RT. So far I'm finding Trac much more flexible and much more in line with what I want to do. Gripes so far are...
I can construct a custom query, through a really nice interface, but I can't save it for later (although if I was a more technical boy I could write and save my own SQL, and if I was less lazy I could get to grips with their query language). My real gripe is that there's an interface that does everything I want except let me save - and there's a save function that saves all kinds of things except what the interface produces. Grrr.
I can get an RSS feed of new tickets, but not one that will include comments on the tickets
Supporting Trac is a spreadsheet for each project holding the stories we're working on. This morning the good folks at Fingertips made working with that a little easier by pointing me to their XL to HTML service. So you can see the latest stories for our write-a-letter tool in this format from a link, rather than having to click through and wait for a spreadsheet to open if all you want to do is read it.
While not an ideal way of doing things I thought I'd tinker with using Watir to drive Internet Explorer to scrape data from our Request Tracker instance then use Ruby code to generate SQL for import into our Trac PostgreSQL database, and low and behold it works a charm!
Martin and I have spoken before about setting up Trac but there didn't seem to be a good reason to do so at the time. Continuing frustration with RT plus a new project based in a vendors Trac application needing to be taken over by us have now given me more reason to setup Trac finally and so it's been done.
Read on for the nitty gritty of what still remains to be done...
Due to my having too much free time, a nerdy love of trying new things and a burning need from some of our users I tried my hand recently at writing an import mechanism to our cms, GCMS (internally known as Planet 2, an OpenACS based content management system also used by others out there -- but who are you??).
I tried many tools including Sahi, Twill, TestGen4Web, and Watir amongst others. I couldn't login to Planet 2 with Sahi or Twill (5xx error with Sahi, and Twill refused to accept there was a form on the login page). Using Watir to drive Internet Explorer via Ruby scripts however worked an absolute treat so I thought I'd share it with anybody out there who uses a GCMS based system, it might be useful to you (but not having seen other GCMS implementations its hard to be sure).
Grab the Ruby script from here.
Grab Watir from here. I tested it with Watir 1.4.1, Ruby 1.8.4 and IE 6.
A test script to drive the class can be found here.
You can also watch a Wink flash video here!
I just changed the Greenpeace instance of the latest Rhubarb code over from MySQL to PostgreSQL. I had a bit of trouble getting the existing instance to work with either suggested (by rails) PostgreSQL Ruby bindings, both gave errors about not being able to find PGConn. Eventually I just recreated the instance from scratch and it works now.
I tried exporting the data from MySQL and importing into PostgreSQL but even using the tools provided in the contrib/mysql directory of PostgreSQL (7.4.8) I kept getting syntax errors. Since the data was just test data I didn't bother trying to fix these. I recreated the user accounts so logins should still work but now theres no data in the system.
Oh, and it's deliberately configured NOT to send email at the moment.
There's a flash demo of Sahi up and running now at Sourceforge.
I really like the tendency of developers to produce these movies now, because it makes it a lot easier to understand not just what tool a b or c is supposed to do, but how you're supposed to use it. When so many tools arrive as not much more than a selection of scripts and a readme file a rich demo is the next best thing to having the developer next to you.
On which note we'll try and make one for Rhubarb...
Well, everyone's talking about Google Trends, so I may as well note that it's got a lot of folks here very excited. Take a look at this result for 'whaling', the big spikes are more or less centered on the IWC meetings, which are extremely dull meetings, where extremely important stuff gets decided amid diplomatic arm twisting, bribery and threats. We're there of course, lobbying, informing, discussing and drawing attention.
The smaller hump toward the end of every year is when the Japanese whaling fleet sets off and in 2005 when we also set off to confront it in the oceans. I'm not sure what this means for the various campaigns, but the sight of eyes lighting up around various departments as we showed this to people suggests that this is all going to prove very useful indeed.
Today development kicks off on 'Rhubarb on Rails' the project to turn our letter writing prototype into production standard code that can be used around the world. It's a short project - estimated at two weeks of development, and it's being carried out on our behalf by Fingertips, who will hopefully be posting about their experiences of the project on this blog.
Since the project is so short we've decided that we'll be working with Fingertips tools of choice. So that's BaseCamp for project management, and Trac for issue tracking and SVN access. (Copies of the work in progress will be moved to our public SVN server on a weekly basis.)
Within Greenpeace we use RT for issue tracking, largely because we've been using it for so long, and have so much stuff in it that moving away would be hugely expensive. By and large we're not that happy with RT, but finding an alternative that does what we want, the way we want it is proving much harder than expected. So trying out the BaseCamp / Trac combination is a good thing to be doing, if nothing else it might stop Ximon from writing a new bug tracker out of sheer frustration...
(I have been threatening to do that for some time, but 'learning to program' needs to come first...)
Some time soon I hope to setup selenium running on our dev server as an additional means of testing our applications that have instances on there. The dev server is headless (no X server) so there's a copy of FireFox 1.0.7 and a virtual framebuffer (Xvfb) which I hope to use instead. I haven't gotten that far yet but I did try a test yesterday using ImageMagick - I wrote a little bash script (shudder) to capture the front page of every instance of an application running on the server and present them as thumbnails in a HTML page. It works a treat! Let's hope I can get Selenium working as easily.
The core commands required if you want to try this on your own server are:
> Xvfb :1 -screen 0 1024x768x24 &
> DISPLAY=:1 firefox http://whatever.url.you/want/to/see &
> DISPLAY=:1 import -window root captured.png
> convert captured.png -resize 256 resized.png
> killall firefox
> killall Xvfb
The import and convert commands are part of ImageMagick. The resize will determine the vertical dimension automatically if omitted. It's a pretty dumb sequence of commands but you get the point.
I got the information I needed from this page on the semicomplete blog by Jordan Sissel.
I just noticed that it in our Rhubarb on Rails demo it is possible to submit a letter with a blank subject and/or body text. This shouldn't be possible but tthe functional tests are incomplete and the unit tests for the letter model don't exist. This is what happens when coding as part of an exercise when there are other things to concentrate on in the time available and the code isn't going to be deployed straight away, or perhaps at all. Still, habits are hard to shake and not writing tests is not a good habit, something we need to work on.
So, I added subject and body to the requires_presence_of validation but then find that (a) the fields in the form don't get the fieldWithErrors div treatment and (b) I can never submit the form because even with values the subject and body are thought by Rails to be empty. I also added test cases while I was at it. However I haven't committed these changes. Why? The functional tests fail thanks to the inability to submit the form even when the subject and body are non-empty.
I can see what is wrong, but I don't know the right way to solve it. It's to do with the fact that the form is populated from two different sources, a letter template and values previously entered by the user. Surely our code should not be manually remembering and populating the subject and body text fields? There is something quite wrong here.
Any thoughts? Take a look at the model, view and controller files in question.
A couple of minor commits occured tonight. Firstly the CSS upload feature turned out to be 99% complete but not committed so that was finished and committed - it needs more tests and more functionality but the basic idea is there and working. Secondly, a massive single character change - the intro text is no longer HTML escaped so that the intro can be formatted. These two changes combined mean the demo is now much cleaner!
Today alone I've had three requests for an online letter writing action to be setup, and more for next week!
Morning out there. Our shiny newly developed Rhubarb on Rails online letter writing action tool nearly saw its first deployment last night but I declared it not ready for use. Why?
* It's running on a development server
* It's running in development mode
* It's running against MySQL - typically we use and know more about PostgreSQL
* The participation page is not yet configurable enough and (as the demo shows) this means that even a basic action doesn't look correct in FireFox because the body text field is too wide.
* No decision has been made about which mail server should be sending the mails.
* The reporting functionality is extremely limited.
* And last but not least, our existing tool which RoR is to replace is currently capable of more and if problems arise is a better understood beast.
However, I do fully intend to use it as soon as possible, but wish to deploy it properly. Watch this space for the first deployment.