Jay McGavren's Journal

I know that an analyst isn’t going to be able to discuss projects on the same technical level as the nerds she’s working with. But we’ve got one whose understanding is so poor, she can only speak in generalizations like this:

“What should I label your task as?” “Can I mark items 15-19 complete?” “Is everyone in the meeting in agreement?”

I thought it was just her, but then in this morning’s meeting a program manager (who I thought was more knowledgeable) was doing the same thing. Is this really adding value to the discussion?

Wow - let me see if I’ve got this straight. I’m being asked to tear apart multiple systems to change a client number “because the client is very superstitious and his numbers must start in the 800 series.”

If this guy’s complaining about this, what’s next? Storing all his records on paper because he has a fear of databases?

There’s this concept of “firing the customer” floating around, and I think this would have been a good time to employ it. Of course by now, I’m sure there are signed contracts and it’s too late.

Edit: A co-worker just pointed out this seems like an April Fool’s joke. I don’t think it is, since the e-mail chain started yesterday, but someone is in serious trouble if it is.

Client, server, client environment, server environment...

OK, here’s part of what I’m thinking…

#Ensure server is authority on object movement by default.
def test_server_movement_authority
	@server.start
	@client.connect
	@client_environment << @object
	server_object = find_matching_object(@object, @server_environment)
	#Move client object one way, server object another.
	@object.vector.pitch = 90
	server_object.vector.pitch = 180
	#Interact.
	@server_environment.interact
	#Ensure client location/vector matches server's anyway.
	assert_equal(@object.vector, server_object.vector)
	assert_equal(@object.location, server_object.location)
end

Basically the client runs its own environment to keep things looking smooth, but when the server finally gets back in touch with it (and it could be several seconds), any location and vector the server sends gets blown away on the client. (It won’t send all of them, just those within a given update area.)

iTunes-style folder organization...

Hrmmm, not bad:

irb(main):001:0>
Utility.cache(
	'foo',
	:creator => 'Jay McGavren',
	:title => 'Cache Test',
	:sort_order => 1,
	:parent_directory => '.',
	:extension => 'txt',
	:album => 'My Album'
)
=> nil
irb(main):002:0> puts find "Jay McGavren"
Jay McGavren
Jay McGavren/My Album
Jay McGavren/My Album/01 Cache Test.txt
=> nil
irb(main):003:0> puts cat "Jay McGavren/My Album/01 Cache Test.txt"
foo

[edited for legibility]

Delayed require statements...

I have a set of Ruby utility libraries in my home directory for my own use, and it’s nice not to have to care how bloated it’s getting. Except that it was taking up to 10 seconds for even basic operations.

The main problem was my strategy of “require libraries first, ask questions later” (which is the exact opposite of my strategy when I intend to distribute something). My goal was to load everything up so I didn’t have to think about which modules I needed (or type their names). But even if all I was calling was a little file slurping routine, I got date parsing and PStore and a bunch of other stuff I didn’t need.

Moving my require statements within the methods that use them alleviated things quite a bit. Ruby doesn’t care when you load your modules, so why take the hit at startup?

def Utility.clipboard
	require 'win32/clipboard'
	Win32::Clipboard.data
end

A similar strategy is working nicely with Rake. I want to offer amenities like rSpec and ruby-prof tasks, but don’t want to make them requirements. So I don’t even define the task until I load the library successfully:

begin
	require 'spec/rake/spectask'
	desc "Run user stories"
	task :stories do
		FileList["stories/*.rb"].each {|f| ruby f}
	end
rescue LoadError => exception
	warn "Could not load rSpec - it might not be installed."
end

I’ve encountered acolytes of various languages who like to declare their dependencies right at the top of a file for all to see, and that’s a good thing. But dependency declaration is starting to move into the package your source comes in (gems, POMs, etc.), so I don’t think it’s such a big deal to have it in the source any more. If anyone knows of a pitfall I’m missing, though, I’d be interested to hear about it.