Nuclear Rooster

After developing, using, and babysitting a production Rails application for a few months now, I have come across this not-so-juicy tidbit: if you use a dynamically typed language, you better use some ‘real’ tests. This may seem obvious, but I think that this is one of the reasons that the Rails community has put so much into Test Driven Development. When you’re writing Java, you (and all the developers on your projects), have a bit of testing baked in to every expression of code; the first gauntlet of tests your code passes is the compilation.

Writing Ruby, however, you can monkey-patch and duck-punch to your hearts content. And maybe even you have a ton of unit tests for the business logic, regression tests and integration tests. You need some detailed unit tests to test any core features you are extending. Just because you can write something in a few expressive lines of code doesn’t mean there can’t be dozens of edge-cases. In a fast-paced work environment, my teams tend to rely on a small set of general tests and a solid QA pass, rather than marching in the face of the 80/20 rule and trying to test each little bit. Or at least that is how we did it. Now we’re gonna have unit tests for core extensions, no matter how trivial.

Because you might try to execute the “foo” method on the “bar” object, which is totally loco, and something won’t work, or it will error, and why would you ever try to run bar.foo? Fine. Sometimes, though, if you are extending functionality around generic or common methods (”each”, “flatten”, “to_s”, “nil?”, “blank?”) you can find some edge-cases that still work and produce passable output, until you start digging in.

I haven't yet delved into the real practices surround Getting Things Done, but I have come across a principle that can be applied to a variety of different things. I call it "Remember Less." The basic idea is to put less pressure on your self by organizing and writing things down.

I found recently that this principle definitely applies to writing software. By writing clean, organized, self-documenting code and focusing on the real issue (rather than implementation details) there is less pressure on you as a developer to remember the intricacies of your codebase. This also decreases the need for you as a developer to communicate and document your code, and speeds up ramp-up time for new developers.

For example, when making a web form, it is better to check the type of request rather than to look for a specific variable that might indicate that the form was submitted.

This brings me to my next point, which is that nice frameworks decrease developer stress by providing convenient syntax and logical concept-models for interacting with the code workflow. For example, using Rails'

is way easier to understand and conceptually consistent than a similar expression in PHP (okok, i'm comparing a language to a framework, bear with me):

So go the extra mile and write good clean, self documenting code. Also, distill the problem down to it's most basic form, without getting confuse.d by the implementation, and you'll make it easier on yourself.

Check it. This is a great quote from Brooks' "The Mythical Man-Month". Completely un-technical, and yet it could have helped prevent several technical mishaps my teams have coded themselves into. Moral integrity vs. conceptual integrity, now there's a question.

I contend that conceptual integrity is the most important con-
sideration in system design. It is better to have a system omit
certain anomalous features and improvements, but to reflect
one set of design ideas, than to have one that contains many
good but independent and uncoordinated ideas.

Frederick P. Brooks, Jr., The Mythical Man-Month: Essays on Software Engineering,
Addison-Wesley, 1975. Second edition 1995.

Do it!

Yeah, that's right, and it finally got me peeved enough to do something about it. Digging around through google's documentation I found this google help page:

The POP server 'pop.gmail.com' rejected the password for user 'username.' Please re-enter your password, or cancel.

Verify your password and then clear the captcha. If you're a Google Apps user, visit https://www.google.com/a/yourdomain.com/UnlockCaptcha. Be sure to replace 'yourdomain.com' with your actual domain name.

Bing!

SCPlugin adds handy subversion tools to your OS X context menu. Its great for PM's, designers, moms (really? no) or anybody else who doesn't grok dot grok dot com the efficiency of the command line.

Or, at least, its great until you install it and it doesn't work for a... well it just doesn't work, something about "PROPFIND Server certificate verification failed: issuer is not trusted". Ok, granted I didn't update the self-signed SSL in a year, but its perfectly secure, and I'm not going to pay for this.

This little trick will get you going:

That helps, but also run that for root, which I think is what SCPlugin is using at some level:

Ok, lets start at the beginning. Nice, freshish RHEL 5.2 box. Try to install mysql gem...

Yikes! Look familiar? Bummer. First step, brute force install everything I could think might be missing

Turns out, the gcc was having some issues:

Googling around a little, I found this helpful page which indicated that the default RHEL yum configuration excludes updates from the kernel. That is probably good practice in general, but right now it is preventing us from doing what "needs to be done."

Looking at my /etc/yum.conf file, indeed the kernal was excepted from updates:

So I commented out that line, yum installed gcc, and then off to the races. My googling also noted that passing the --with-mysql-config saves you some trouble, essentially letting it configure itself.

Just in case, you might want to uncomment the kernal extension from your /etc/yum.conf file!

I've just started playing around with Hadoop, Apache's implementation of Google's MapReduce paradigm. I can feel the power that MapReduce brings to the table, but I have had trouble trying to describe it to other people. Here's a nice quote from google's whitepaper:

Most such calculations are conceptually straightforward. However, ... the issues of how to parallelize the computation, distribute the data, and handle failures conspire to obscure the original simple computation with large amounts of complex code...

So MapReduce doesn't help you solve really difficult problems, it effectively manages simple problems with a teeny dataset, or a ginormous one. Its as if it was equally effective for one pointy-haired boss to manage a team of 5 as it was a team of 5000. Combine that with Cloud Computing's ability to reduce the cost of acquiring new processing power, and you have quite a bit of power at your fingertips.

I just ran into a little issue setting up a MySQL slave. I have done this a least a have dozen times before, and it is always pretty painless, but this time, I kept getting hung up on error that looked like this:

071118 16:44:10 [ERROR] Failed to open the relay log './-relay-bin.003525'
(relay_log_pos 22940879)
071118 16:44:10 [ERROR] Could not find target log during relay log initialization
071118 16:44:10 [ERROR] Failed to initialize the master info structure

Googling a little turned up this mysql forum,

http://forums.mysql.com/read.php?26,112490,223025#msg-223025

Which then led me to this mysql doc page
http://dev.mysql.com/doc/refman/5.0/en/replication-howto-additionalslaves.html

This was confusing, and didn't really seem like it got to the root of the problem. Why would one slave care about another, if they were both reading from the master? I think that article would more accurately be called "Making a slave of a slave" or some such, because "Introducing Additional Slaves to an Existing Replication Environment" does not convey that they are talking about a slave of a slave (which I think they are).

Anyway, long and short of it, I removed the 'master.info' 'mysqld-relay-bin.*' 'relay-log.info' 'relay-log-index.*' from the MySQL data directory, restarted mysql ('/etc/init.d/mysql restart'), and off to the races.

Sometimes, depending on the order you do edit the configs or restart mysql, you can get bad data in those files, and it can lead to crpytic errors. Remove those, and you can always start fresh.

We ran into a permission error using the 'paperclip' plugin. It had something to do with moving a tmp file into the rails public directory. The odd thing was that it could create the appropriate directories in the rails public directory, but it couldn't copy the file.

Digging around the web, I found this group about this exact problem.

http://groups.google.com/group/paperclip-plugin/browse_thread/thread/4a0a97a08929d3a5

I found that I had all of the patches, but it still didn't work. Most of the people on the group were complaining it that it didn't work on Windows, and maybe had something to do with file handles, etc. We were trying to get this working in JRuby on a Joyent Solaris Accelerator, each of which can make things a little different than a MRI Rails app on Linux.

Following a tip from a user on the group, simply changing the way the move happens fixes this problem. I would like to fix the root cause, but I got it working for me, and (*open source sigh*) don't want to isolate the exact problem.

After that, i made some change in storage.rb#flush_writes.
It's a short workaround for
FileUtils.mv
Simply replace it with

FileUtils.cp(file.path, path(style))
FileUtils.rm(file.path)

Currently, it works for me. But please consider, it isn't checked
against a well written
test or any other platform.