One Man’s Walk in work

Cards is a ruby gem that allows you to quickly capture a card wall into a spreadsheet then print it up using omnigraffle or export it to csv (or now tracker)

This release adds a couple really cool improvements in it :

1. Numbers ‘09 finally has applescript support, so Cards can finally reach into it and grab what it needs instead of requiring a csv export.

2. Pivotal Tracker now has a sweet RESTful api that we can use to throw stuff directly into it.

Wouldn’t it be cool if the next thing cards could do for you is update your spreadsheet to add the tracker ids for created stories? Then you could maintain the spreadsheet and tracker. Maybe even get 2 way syncing going or something…

To illustrate, Cards lets you take this spreadsheet from Numbers and turn it into the card walls in omnigraffle that created it.

[img:3330719206, small]

This is my latest OSS project. I started it to basically factor out what used to live in my own site into it’s own house.

It works very nicely with typo with the help of a couple typo macro’s I wrote for it. And thanks to rails, it’s a cinch to work on and add new features. I’m liking rails 1.0 a whole lot.
Noteable features are:

• It’s pretty
• It’s fast and lazy loading when it needs to resize stuff.
• To configure it, you point it at a directory with pictures in it, that’s it.
• Keyboard navigation
• Slideshow, though there’s still a lot missing from our slideshow

Coming up:

• AJAXy captions
• AJAXy ratings
• Favorites page
• Online editing (thanks to rmagick)

We’re still early days, but it’s defnitely useable, as you can see. Take a look at what we have planned or grab the source from rubyforge svn.

And definitely let me know if you wanna help out!

It had to happen sometime.

I finally got fed up with maintaining my own handrolled blog software. In the end, it was the spammers that did it, I just couldn’t be bothered to add all the features that were necessary to handle them correctly.

And then, a couple weeks ago, I did a Ruby on Rails presentation, and someone pointed me to Typo as an example app.
Typo

Typo is awesome. It has tons of features I want, tons more that I can play with (it’s like christmas), it’s fairly user friendly, all ajaxed up, and it’s on rails, so I can hack into it to my hearts content.

If you’re self hosting a blog and are at all familiar with rails, I give it several thumbs up. Shame I only have 2…

I feel like my priorities have changed as well. Using a 3rd party tool like typo will help me focus more on the content of my blog and less on the technology behind it. Though I will say I’ve already learned a lot by seeing how the Typo team has done things.
Shimmer
After looking into it a bit, I decided I still didn’t want to use Shutterfly or Flickr. So I’m starting a new project called shimmer that is yet another photo gallery on rails. I coded up a couple plugins for typo so that I can natively have code like :


<typo:shimmer img="2003/January/Europe/IMG300.JPG" float="right"/>


in my posts and typo just does the right thing.

More to come on Shimmer as I polish it a little.

This is the first release of AddressBook, a simple Address Book for windows inspired by OSX.

Give it a download here (you’ll need the .net 2.0 runtime)

Please send any comments or bugs or patches to redress-users@lists.public.thoughtworks.org. And if you have any experience skinning a .net app to make it look OSXy, that’s first up for next release, and I’d love a hand.

Download it here src=”!” alt=”” border=”0” />

Sorry for the delay, lot of moving across continents

With this release some other indispensible things for a text editor/ide, using Chizzle is actually fun at this point.

Look for the next release in a couple weeks

This release includes:

• Find
• Run (for ruby)
• Goto Line

Download it here src=”!” alt=”” border=”0” />

Charles and I are releasing Chizzle-0.01 today. This is a first peek, if anyone’s curious as to what we’re doing. It still has quite a ways to go; we have a table full of at least 30 index cards with stories on them. However, after a week’s worth of solid work, I think we acheived a pretty respectable amount for our first iteration.

We’re building it on top of wxWindows, which means we get cross platform native widgets. We’ve tested it on Debian Linux and Mac, and it looks quite sexy in both. Because we depend on wxWindows and wxRuby, the installs a bit a of pain, but hopefully we’ll be ironing that out soon.

Anyway, take a look. Charles and I will be using it, albeit a bit painfully, as of this release. Next release should be in a week.

Coding in ruby again, I have to say, it it very sweet.

This release includes:

*Open

*Save

*File Tree Pane

*New

*Ruby Content Colourizing

*Goto File

*Multiple Panes

I’ve always wanted to build an IDE. At the same time, Ruby, probably my favorite language at the moment, seems to be strangely missing a decent one even after being around for a few years. Charles got me all excited about writing one for it, and we’re currently starting some work on one.

Our vision is to eventually build an IntelliJ style IDE with tons of refactoring support on top of Parrot AST’s. This means that it in theory, with a few tweaks, it should support any language which can run on top of the Parrot VM. This includes ruby, python, perl6 and a ton of others. Pretty cool concept, yeah?

That said, I don’t know how far we’ll get, and I don’t know how long or how much work it will be. My personal shortterm goal is to write something that is better for editting ruby than IntelliJ (that’s right, I use IntelliJ to edit ruby code, which is sad).

We’re still evaluating packages and stuff, but right now we aren’t thinking of building it on top of !FreeRide, but instead building it on directly on top of wxWidgets and their Scintilla port. That way we get native widgets, not to mention Cocoa support for my mac :). We’ll write it in Ruby, but I smell a lot of C++ code in my immediate future as well… Oh well.

I’ll keep blogging our progress.

This is a pattern I first started using while working on rublog w/ Brian Marick et al. Dave Thomas gave it a better name when he checked it in, and I’ve renamed it since then. I think I like temp files. A second ago, I was working in nfit, and found myself writing it in c#. So I guess I like it.

Problem:

You want to test something that accesses files. Something that you want to do all the time for some apps.

Solution:

Create a class called !TempFiles, use it like this (for ruby):

def test_load
	files = TempFiles.new
	files.add('wiki/captions/2003_11-November_captions.txt', CONTENTS)
 
	files.create do |dir|
		captions = Captions.new(Wiki.new(dir, '/2003/11-November'), '/2003/11-November')
 
		assert_equal('Jilian', captions['apPle.JPG'])
		assert_equal('from the top', captions['bitter.jpg'])
	end
end

It can be used from any test, and makes creating a file easy. From ruby the blocks make it really nice. I often add files in the setup code, but always have the block in the actual test. The nice thing about this is it’s easy to add files in your test right before creating them.

I’ll add the c# usage tomorrow

• UPDATE *

this is now a gem called file_sandbox – sudo gem install file_sandbox – enjoy…

So I’ve started committing some of the tweaks I’ve made to the .net version of FIT into
the sourceforge project Steve Freeman and I started at http://sourceforge.net/projects/nfit/.
I’d like to talk about how my team structures its code around FIT.

For context, this is a c# project, and we’re using VS.Net, NAnt, and !SLiNgshot to build, along w/ the usual suspects:
NUnit, !CruiseControl.Net, etc.

Directory Structure——
We have a directory structure that looks like :

• doc/
• Iteration1/
• .html – all tests associated w/ a story
• .html
• Iteration2/
• .html
• Iteration3/
• stories.html – list of all stories in an !AllFiles like fixture
• lib/
• src/
• project 1/
• project 2/
• fit/
• run.aspx – copied from nfit
• custom fixture 1.cs – fixture used in a fit test
• custom fixture 2.cs
• project 3/
• foo.sln – solution file

We’ve argued a lot over what the structure of the source should look like on a .net project, and our current solution is a src dir, inside of which is one dir for each project and a solution file. It’s flat and easy to see where everything is.

All the FIT tests go into the doc dir. fit is a VS web project that references all the other projects, along w/ the FIT dll’s. It includes all the fixtures our tests will need and the run.aspx file from NFit.

Running FIT Dynamically——
We’ve found it totally necessary to be able to run fit tests dynamically in addition to
running them from command line. Ward has his run.cgi on http://fit.c2.com/ to let you click ‘run’ on a fit test. I’ve just checked in Run.aspx into NFit which will let you do the same thing.

This is how we use it:

We have 2 webshares. */doc* points to our ‘doc’ directory and holds all the tests. */fit* points to our ‘src/fit’ directory and holds our copy of Run.aspx along w/ all the code our tests run against. We put a run link at the top of each test that points to ‘/fit/run.aspx’, and when we browse our tests we do it through our local IIS using something like ‘http://localhost/doc/stories.html’.

Because fit is just another project along w/ all our other projects in VS, we get linking,
debugging, and building for free inside and outside visual studio.

Structuring FIT Tests——
When you’re writing so-called ‘acceptance tests’, it’s important to remember that there are several different missions of testing and types of tests to achieve them. The way you structure your tests should reflect this, see default.WhatAboutAcceptanceTesting

In the doc directory, we group our tests in files by the story they test against, and the stories by the iterations they are completed (or scheduled to be completed) in. This of course makes the assumption that all tests “belong” to one and only one story. Up until now that’s been okay, we’ll probably add another place to put tests when and if that becomes a problem. It has been good to teach our team to think about testing functionality in terms the customer can see.

Now we could just run all our tests automatically, but we wanted one page that everyone could
go to to see our teams status. So we take the spreadsheet of stories that our client keeps complete with
their points, their iteration, and their status (done or not). And we point to it with an aspx page to
provide an html view that fit can run against. So when you go to http://localhost/doc/, you see a table for
every iteration, each of which contains all the tests in that iteration. Only ones that have been marked
done in the spreadsheet get run.

So we have one page that tells you the status of all stories we’ve ever done. And it tells you how we’re doing
on the current iteration as well – along w/ our velocity of course ——How about if my return value is an XML document, how does FIT deal with that. How do I pass two parameters to a method.

TIA