Posted by Doug
Fri, 02 Dec 2005 16:09:22 GMT
It seems “tagging” is all the rage with new web applications. The idea is simple and powerful: add tags (aka keywords) to items in some catalog and then allow browsing by those tags. I humbly submit Del.icio.us as the best implementation of this idea.
If you’re thinking about adding tagging to your web application, I highly recommend you play with del.icio.us for a while to get a feel for how they do it. At first glance it looks the same as flickr, smugmug, and pretty much every other site that has tagging. After you use it for a while you realize it’s much smoother than any of the others. What makes it so nice? It’s kind of hard to pinpoint, but I’ll try.
Adding a new entry to the catalog and tagging it is very fast. Reasonable defaults are given for about half the inputs. All of the inputs are easy to keyboard navigate (that is, no select boxes that might not support tab selections). You can type in new keywords with AJAX suggest as you type. It’s also got a list of the tags that you can click on to apply. It makes handy suggestions about what tags it thinks you might want to apply. Of course, these recommendations might not be that easy to do for other applications.
Browsing the tags is also well done. As I write this I realize it’s another implementation of opinionated software. The tags are presented in a “cloud”. This is a somewhat common implementation. All the tags are in a filled paragraph sorted alphabetically. The tags are given a more weighty font based on how many records have that tag. I first saw this on smugmug. However, the assuption is that each additional tag you click on is boolean AND-ed with the other tags. “Show me all the records that have all these tags.” It’s a drill down from least to most specific. Once you’ve selected a tag, it becomes a “not-tag” in the cloud. This makes it easy to undo the selection of the tag.
I’m sure there are other implementations of tagging and tag browsing that are very similar to del.icio.us’. I don’t really want to argue which is best. I just wanted to say, “well done.”
Posted in Programming, Internet, Community | Tags del.icio.us, tagging | no comments
Posted by Doug
Wed, 30 Nov 2005 16:46:51 GMT
This Slashdot article made me laugh.
Should I write comments? What is a good comment? ... I instead suggest commenting in haiku.
I’ve actually been thinking about code comments lately. For starters, I hate those long journals in the top of source code that say what’s been done by whom; learn to use source control! Second, bad comments tend to live a long time. I recently went back to a project I had worked on five years prior. All my old comments were still scattered around the code like little essays on why I was doing what I did. Five years later, that stuff was meaningless. Comments typically don’t age well.
What I like about commenting in haiku is that it really makes you think about what you write before you do. You have to boil the essence of what you’re doing down to a few words. Of course, writing haiku is a good mental exercise in general.
So which is worse: comments about the code that don’t reflect all the changes that’s been made or unit tests that don’t pass?
I once dealt briefly with a development team that had an outstanding test environment. The lead programmer had a continuous build system that reported complete system test status. At the time that was pretty forward thinking and I was impressed. I recently visited with the same team and was disappointed the tests were being neglected. The new lead programmer had a printout pinned to his cubical wall from the last time all the tests passed like a trophy.
Maintaining tests can be cumbersome. I’m not going to deny it. I sympathize that the pressure of deadlines can tempt you away from tests. It can also be pretty annoying to have to make a bunch of tedious changes to bring your tests in line. I think of it like double-entry accounting though. All code has a test, all tests have code and the two should be in agreement. An accountant wouldn’t think of adding a credit to an account without adding a debit to the appropriate account. It’s how you know everything is in ballance. It’s comforting and reassuring to have a good test to code ratio that all passes. It gives you confidence to keep moving forward. When you leave tests that don’t pass, what’s a new guy to do? How’s he supposed to know which is right: the code or the test? I guess he needs to hope there are good comments about what the code is supposed to do. Of course, with my luck all three would be out of agreement.
I’d say about half of my debugging time on my Ruby on Rails projects is spent fixing tests. It’s an investment that pays off. I’m able to easily isolate the problems. Having the tests automated gives me pre-defined data to work with. I don’t have to spend a lot of time in setup to reproduce the bug; it’s right there in my test. Keep in mind that my overall debugging time with Ruby on Rails and TDD is much less than working non-TDD. I attribute my success with TDD and RoR to the high level assertion helpers. I find it much easier to write my tests in RoR because of the testing helpers.
For me, tests are better than comments. They properly demonstrate how the code is supposed to work. Tests make it easy to tell when they are out of sync with the code. Reading comments that disagree with the code can be a real stumbling block when trying to maintain systems. Sometimes comments and code are only subtly out of sync that may not show up for a while.
My suggestion is to always keep your tests at 100%. Don’t check in any code while tests pass less than 100%. If you have tests that don’t pass and don’t have time to fix the test I believe it’s better to delete the test. At least then a new guy can assume the code is correct until proven otherwise. I could be wrong about the deleting part. I just said that to be inflammatory! ;-)
Posted in Programming, Test Driven Development | Tags Rails, testing | 1 comment
Posted by Doug
Fri, 18 Nov 2005 21:06:22 GMT
I was recently asked how much data you can read from disk at once. In retrospect, I think it was something of a trick question. There are a couple of factors that affect this. First, the disk has a limit on it’s buffer sizes and how much it can read at once. Second, the system bus has some limit on how much data it can pass around. Third, the kernel probably has some limit on it’s buffer sizes too. Finally, your application makes a read(2) syscall with a buffer and buffer size. I wasn’t really sure which of these buffer sizes he was after and he wasn’t very forthcoming on what he was looking for.
Honestly, I didn’t really know the answer. I’ve done some kernel programming with mass storage devices; but that was over USB. That protocol isn’t really designed for mass data transfer that well. The max packet size is pretty low. At or below the kernel I don’t really have any good way of knowing what’s what and how large buffers are.
In userland I know you’re supposed to wrap your calls to read in a while loop capturing the return value of the number of bytes read. In practice, how much does a single read syscall read? I didn’t really know. Frankly, I’m not sure he did either. He was telling me it was probably something around 64KB. I was sure it had to be higher than that; at least in the MB range.
It was nagging at me so much, I decided to test and measure. I wrote this little blocksize.c program to try and figure it out. Basically, I tried different sized buffers and reading from various sources each time tracking how many times I had to call read and how much data was passed in each time. On my Mac with 1.25GB of real memory, I never could make it do anything less than a single syscall! I had a 1GB VOB file laying around that I had ripped from a DVD. Even in that case, my test program read the whole thing into memory! Of course, most of my system was swapped out. I make no claims for efficiency, but a single syscall is all that was required.
Posted in Programming, Hardware | 2 comments
