Isopods


This fish is interesting, but what is more interesting is the isopod clinging to it just below its eye. It looks like a parasite but in fact it is just hitching a ride, for life.

As juvenile isopod are free floating but as they mature they will ‘catch’ a fish, hook themselves into place and spend the rest of their lives there, feeding of whatever comes their way. Sometimes fish will have on on each side of their heads. Isopods also mate and spawn while on the fish but I am not sure about that.

While there is nothing parasitic about this relationship, there is nothing symbiotic either, the isopod is catching a free ride for life.

The interesting thing is that I had not seen them at all before diving this one site in Turks & Caicos and then saw quite a few. I caught another fish with one which you can see here.

Make it go faster!!

I have been enjoying listening to the StackOverflow podcasts by Jeff Atwood and Joel Spolsky. As a developer it is always good to get different (and sometimes controversial perspectives on things).

The last podcast, their 10th episode, covered a wide range of topics, the last one of which was about Ruby and its suitability for enterprise usage. The show notes on this subject are:

On Ruby performance, scaling, “enterpriseyness” and whether or not this is even the right question to ask. Shouldn’t we be thinking of this in terms of the solution first, and the language as a side-effect of that?

Which I think is right on, you need to look at the task you want to accomplish and choose the right tool for the job. The problem is that some people get ‘wedded’ to a single language and use that for every problem they encounter, winding up with some very good implementation as well as some very bad ones as well.

I tend to approach the language choice using a variety of parameters which really boil down to the suitability of the language for the task, looking at how well the language deal with the problem being solved (such as Perl for text processing), scalability & performance, maintainability.

One comment Jeff Atwood made about scalability was about looking at the number of machines you need to scale up your operation. If you can only run one process per machine, scaling by an order of magnitude will be a lot more painful than if you can run 10 processes per machine, which I think is right on the money as it were. It maybe much more cost effective to spend more time upfront developing your app in a language such as C (or derivative) than putting something together quickly in Perl or Ruby and having to buy much more hardware later on.

Twitter advice

I know that opinions are a penny a dozen on the internet and I generally don’t pay any attention to them unless they are informed opinions, and I generally don’t comment on them. But this post by Michael Arrington on TechCrunch about Twitter bugged me.

Here’s why:

Experts I’ve spoken with say these are reasonable precautions to take, although they question why more slave servers weren’t set up in the past (”it takes ten minutes,” said one anonymous source). But as a Twitter user, I’m glad to see they’re preparing for the surge.

Nothing ever “takes ten minutes”. You can’t just pick a server and bung it into production as a slave server without thinking about what you are going to do with it and hence what load you are going to place on it. Typically ‘lesser’ machines are co-opted into being slave servers and people expect them to be able to replicate, keep up with replication, and take a read load. Oh and not need any admin either. You can “take ten minutes” to do this and have the system bite back at the worse possible time, or you can think about your needs, do the right thing and have the system work properly for a long time, your pick.

The smartest thing Twitter could have done would be to hire former Chief Architect Blaine Cook back as a consultant to keep an eye on things for the day (he seems to be the only person that can keep his crazy architecture actually live). But from what we’ve heard that hasn’t happened.

No, the smartest thing Twitter could have done (and most probably did) would have been to make sure that there is redundancy in their engineering team so that things don’t come to a grinding halt if someone leave, goes on vacation, is fired, or gets hit by that bus-driving psycho. Having critical knowledge locked up in a single person is bad for that person, bad for their co-workers, bad for the company and bad for the shareholders.

Follow

Get every new post delivered to your Inbox.