By Jim, on June 3rd, 2011 Salad claws are implements used for tossing or serving salad. They come in many different forms.
These claws are about four inches long and three inches wide, and are carved from two different pieces of yellow poplar. As you can see, one piece has a lot more of the greenish color that the wood is sometimes known for.
I cut the lighter-colored one out on my bandsaw several months ago. Actually, I cut two from the same board but then I made a big mistake carving one of them. I finally got around to cutting out another (this time with a coping saw), and finished both with a lot of hand carving and sanding.
Debra used them for the first time last night. Her report: they feel good in the hand and do a nice job tossing and serving the salad. The only drawback is that they’re a little too short, so she ended up getting salad dressing on her fingers.
I’ll make the next set a bit longer.
By Jim, on May 23rd, 2011 It surprises me how often I run across programming language elitists who express opinions such as those found in sizeof(char) is 1. The prevailing opinion here is that if you write extraneous code, it’s obvious that you don’t know enough about the language.
The author’s primary rant here is that the C standard defined sizeof(char) as 1. So writing (sizeof(char) * StringLength) is the same as writing (1 * StringLength), and that’s just silly. After all, everybody knows that 1 * x == x.
Whereas he’s right in saying that writing sizeof(char) is unnecessary, his assertion that doing so shows a lack of understanding is complete and utter bullshit.
Computer programming is in large part an exercise in applying familiar patterns to solve unfamiliar problems. We benefit from using patterns, and the general pattern for using malloc is malloc(size_of_thing_to_allocate * number_of_things_to_allocate). Why change that pattern just because you know that the size of the thing you’re allocating is 1? It’s not like it matters in terms of performance. The compiler is going to output the same code, regardless of which way you wrote it.
At the end of the article, the author points out that there are two forms of sizeof. When the argument is a type, then the syntax is sizeof(type). When the argument is an expression, you can write sizeof expression. That is, you can eliminate the parentheses. He goes on to say:
If you don’t need the parentheses then don’t use them, it shows that you know the syntax of sizeof and generates confidence that you know what you’re doing.
I suppose, then, that all extraneous parentheses should be removed from all constructs? After all, by removing the parentheses from this code:
if (((x == 22) && (y == 33)) || (z == 15))
You have:
if (x == 22 && y == 33 || z == 15)
Never mind that by removing the parentheses you’re losing contextual information that actually helps in understanding the code. Sure, the minimal version works just as well. But the first version groups the expressions and shows me explicitly what the code is doing. I don’t have to dredge the operator precedence chart out of my brain and apply it. I can look and know. The “extraneous” version takes less effort to decipher, and I’m more likely to understand it correctly. More importantly, I’m more likely to write it correctly the first time around.
The things that the language elitists complain about are legion. C programmers often write if (!count) in place of if (count == 0). Why? Because it’s less code to type. They’re adamant that writing == 0 is something that only the uneducated masses would do. As one person put it, “every time you type ‘== 0,’ God kills a puppy.” Idiots. Never mind that by writing if (!count), you’re implying that count is a Boolean value. If you want to check to see if something is zero, write code that checks it against zero!
C#, of course, eliminated a lot of that madness. You can’t write if (!count) if count is an integer. That doesn’t stop the language elitists, though, from complaining if you write if (Char.IsDigit('0') == true). The problem? “== true" is unnecessary. Perhaps it is. But it’s also completely unambiguous.
By the way, it’s amazing how many of those who “know everything” about the C language end up writing return (1);, even though the parentheses are not required. The syntax is return expression. The parentheses are allowed, but not necessary.
Adopting patterns frees our minds to worry about applying the patterns to solving the problem rather than spending brain cycles thinking like a compiler so that we can write the tersest possible code. Asserting that somebody who writes verbose but readable and correct code is somehow less knowledgable only shows your ignorance of what’s important. Why spend brain cycles on irrelevant stuff like that?
I freely admit that I don’t have the C# precedence of operators table memorized. And you know what? I don’t have to memorize it or even consult it. Because I know that if I fully parenthesize my expressions I’ll never be wrong. I even use { and } to enclose single-statement blocks. Terribly inefficient of me, don’t you think? And when I was writing C, I did indeed write sizeof(char) in my calls to malloc.
The language elitists would have you think that doing those things makes one less of a programmer. I, on the other hand, think that it makes one a better programmer. Why? Because the programmer who adopts such patterns spends his time solving the problem at hand rather than trying to make his code show that he knows and understands every nook and cranny of the language specification. The kind of elitism espoused in the linked article and by others of the same ilk is fine for college students and hobbyist programmers. But those of us who are paid to solve problems don’t have time for that kind of bullshit.
By Jim, on May 19th, 2011 The whole idea of using exceptions is to catch and handle unusual situations that could crash your program or corrupt state such that the results your program produces are incorrect. In modern programming languages, exceptions have been perverted and are used in place of normal everyday error handling. But that’s a rant for another time.
One of the basic tenants of exception handling is catch only what you know how to handle. For example, in .NET the File.Open method can throw any one of several different exceptions. When writing code that opens a file, you have to handle those exceptions. So, for example, you’d write:
FileStream f;
try
{
f = File.Open("filename", FileMode.Read);
}
catch (FileNotFoundException)
{
// code to handle file not found
}
catch (DirectoryNotFoundException)
{
// code to handle directory not found
}
// other catch statements for other exceptions
You do not want to write this:
try
{
f = File.Open("filename", FileMode.Read);
}
catch (Exception ex)
{
// handle all exceptions
}
Why? Because there may be exceptions there that you don’t know how to handle. Sure, you can check the type of exception and re-throw those you don’t know how to handle, but then you’re defeating much of the purpose of exception handling and you’re also losing information.
Failing to handle exceptions is bad, but it’s not the worst thing. The worst thing you can do is catch an exception you don’t know how to handle, and fail to pass it on. Doing that masks bugs. For example, imagine your program does some calculations using a shared variable:
public int NumberOfItems;
private double GetAverage()
{
double total = GetTotal(); // gets the total of something
double avg = total / NumberOfItems;
return avg;
}
If NumberOfItems is zero, the code above would throw DivideByZeroException. That’s right and proper, since the result of dividing by zero is undefined, and you don’t want your program producing the wrong answer. That could be disastrous. It’s better that the exception escape and potentially crash your program, the idea being that no answer is better than an incorrect answer.
Now, suppose somebody comes along much later and decides to “fix” that crashing program. He writes:
// For some reason this code sometimes crashes the program.
// This will fix it.
try
{
CallMethodThatCallsGetAverage();
}
catch
{
// Squash that pesky exception
}
That very effectively prevents the GetAverage method from crashing the program. It also very effectively prevents any other catchable exception from crashing the program. It “fixes” the symptom (the program no longer crashes), but it doesn’t fix the problem. The programmer who writes that should be … “counseled.”
And don’t think I’m making this up. I’ve seen such code.
It’s one thing for a programmer to make a “fix” like that. It’s another thing entirely to create a Framework component that works that way. A case in point is the .NET System.Timers.Timer component. The documentation for the Elapsed event says:
The Timer component catches and suppresses all exceptions thrown by event handlers for the Elapsed event. This behavior is subject to change in future releases of the .NET Framework.
This is terrible! Imagine that your Elapsed event handler encounters corrupt data and wants to throw an exception so that the program will crash. It can’t! Try this:
static void MyTimer_Elapsed(object sender, System.Timers.ElapsedEventArgs e)
{
Console.WriteLine("Badness! Throwing exception");
throw new ApplicationException("something bad happened");
}
The exception will never escape to the main program. The timer handler in .NET does essentially this:
try
{
MyTimer_Elapsed(sender, args);
}
catch
{
// Why would anybody want to know that something bad happened?
}
System.Timers.Timer is a bug hider, and for that reason shouldn’t be used.
Unfortunately, that’s not the only component in the Framework that squashes exceptions. It seems like any event handler that executes on a non-UI thread will squash exceptions. I don’t know if that’s globally true, but it sure seems that way. I always check the documentation these days, just to be sure.
By Jim, on May 18th, 2011 I’m really enjoying the spoon carving. I finished three more spoons the other night, all of which are eating utensils rather than decorative or serving spoons.
The spoon on top is from a piece of mesquite left over when I cut out the big soup ladle a couple weeks ago. I picked up a scrap to whittle on while I was waiting for the finish to dry on something else. The bowl is about the size of a half dollar, and not very deep. Maybe I could use it for eating a container of yogurt.
The maple spoon in the middle is the size of a normal breakfast spoon. I didn’t get it perfect, but it’s usable. Although you can see one spot where the wood is paper thin. I got a bit too aggressive with the gouge. I used that spoon at dinner last night. The slightly fuzzy feel of newly finished wood is oddly uncomfortable when you’re used to the perfect smoothness of stainless steel. I’ve heard that spoons used for eating get smoother with use. I hope so. In the future, I’ll use a finer sandpaper before finishing.
The spoon on the bottom is carved from a piece of fig. I should be a good spoon for soup or stew.
By Jim, on May 13th, 2011 I’ve been on a spoon kick lately. I’m enjoying spoon carving so much that I actually ordered some tools made specifically for spoon carving. They haven’t come in yet, so I continue with what I have.
This rectangular scoop was an experiment. I purposely left it a little rough to see how it would look. Some people like it, but I don’t care much for it. I think I want my spoons to be smooth. I think the wood is spalted maple. I picked it up from a scrap pile at the local Woodcraft store. I think I prefer rounded shapes, too. The rectangular bowl was difficult to carve.
The coffee scoops are kind of fun because they’re simple to carve and don’t take very long. And people really seem to like them. I thought I’d try another experiment: a scoop with a side handle.
The spoon is about four inches long, total. The bowl is about an inch in diameter. I still haven’t decided whether I like the side handle thing. The wood is yellow poplar.
This last is a two-teaspoon measuring spoon. I suppose I should have made it one and a half teaspoons, which would make one half tablespoon. The wood is from a fig tree in the back yard. I love the way it looks, except that it cracked.
I saw the crack in the wood before I started carving, but it looked like the crack wasn’t that deep. By the time I discovered the full extent of the crack, I was well into carving the spoon. I finished it, anyway. With the crack, there’s too much chance of stuff getting in there and staying. So this won’t be used as a measuring spoon, but rather decoration. It’s five or six inches long, and the bowl is a bit over an inch in diameter.
I have a couple of other spoons in various stages of completion. When those are done, I’m going to try making spoons for eating. Might even try a fork.
By Jim, on May 8th, 2011 I had planned to take more in-progress pictures, but then got involved in finishing the spoon. So all you get are the finished pictures. See Part 1 for photos that show the carving progress.
The spoon turned out much more beautiful than I thought it would. I knew that the mesquite is beautiful wood, but I had no idea it would look like this. I definitely have to make more of these.
Click on any picture to see the full size image.
By Jim, on May 7th, 2011 One benefit of all the tree pruning I did last month is I got a lot of potential carving material. I also got a lot of firewood and an impressive collection of smaller stuff that I need to burn or mulch, but like anything else I have to take the bad with the good.
As I was cutting up the bigger pieces for firewood, I put several aside for potential carving projects. This one said “spoon” to me.
It’s a piece of mesquite, about 12 inches long and around two inches thick down there at the left end. The limb it came from had been hanging dead on the tree for a couple of years.
The first step in making my spoon involved removing the bark. I did that with my Buck hunting knife, since that’s what I had at hand.
One of the things I like most about “found wood” projects (as opposed to buying a block of kiln dried wood from a store) is trying to make use of the log’s features: knots, worm holes, rotted sections, grain, coloring, etc. This piece has a lot of irregularities that make it quite interesting. Unfortunately, my photography doesn’t do justice to the potential I could see in this piece of wood.
With the bark off, I went inside to draw a rough outline of the spoon on the wood. This doesn’t have to be real detailed and I don’t have to set the final shape in stone right now. But it’s good to get a better idea of what I’m aiming to create.
That was a pretty poor picture in bad lighting. I enhanced it as well as I could. It gets the point across. The bowl of the spoon will be on the left in this picture. I’ll take off that protruding limb. The handle, too, will be trimmed quite a bit.
I rather like whittling sometimes, but when I want to create something, I don’t much like spending my time whittling away many cubic inches of waste wood. That’s what saws are for. A bandsaw would make quick work of cutting away the excess, but it takes a bit of time to pull it out and set it up. Especially since right now I have a very large and aggressive blade on it. I opted to use the coping saw with a coarse blade.
Here’s the spoon cutout to its (very) rough shape.
I goofed a bit with the saw, cutting away a little more than I had planned where the handle meets the bowl. It shouldn’t cause a problem. This spoon is intended to be a bit irregular anyway, so I can probably hide the goof as part of the “primitive” look.
The rest is edge tools: knives and gouges. Shaping the outside of the bowl always takes longer than I expect because a lot of it involves cutting the end grain. And I always end up taking away more wood than I thought I would have to in order to make it look right.
This isn’t the final shape, but it’s close. Note that the bowl is considerably smaller than what I drew. I’ve rough shaped the handle, but there’s still quite a bit of work left there. Still, the major work on the outside of the bowl is done.
The above, from when I took the first picture until the last, was about four hours’ work–most of it spent shaping the bowl after cutting the rough outline with the coping saw. That mesquite is pretty hard wood, which means taking small bites and stropping the knife blade very often.
The fun part (for varying definitions of “fun”) is hollowing out the bowl. I have a couple of small spoon gouges that are great for small spoons and detail work for the larger spoons, but the only tool I have for taking big chunks is a #9 gouge that’s about 3/8″ wide. It’s a good sharp tool, though, and it makes pretty quick work of the roughing out the bowl. I’m ordering a hook knife, which should speed the process quite a bit and also allow me to do a somewhat better job.
Hollowing the bowl took a lot of time. I spent two to three hours on it over a 3-day period. I finished that last night, and also put the final touches on shaping the handle. Here’s the result, ready for sanding.
Finished, this spoon should be quite beautiful with the different colors and the grain. It will make a nice serving spoon for soup, or perhaps a scoop for dry goods. I’ll post better pictures once it’s finished.
Photos of the finished spoon are here.
I’ve been told that scrapers are a good alternative to sanding. I haven’t tried them yet, but I’ve been impressed with the results I’ve seen from others. I think a set of scrapers will be my next purchase after the hook knife. Assuming, of course, that I continue making these larger spoons.
By Jim, on April 28th, 2011 Adding a feature to the crawler today, I ran across this line:
if (!(entry.IsGood && entry.LastStatus != StatusCodes.SpeculativeAdd))
Now what idiot would write something like that? Oh, wait. I’m the only one who’s ever worked on this program.
There are two serious problems with that conditional. First, it’s incredibly difficult to keep the truth table for that expression in my head. Every time I look at that expression, I have to figure out again what it means.
The second and more serious problem is that once I’ve fixed the meaning in my head, I have to figure out if that’s what I really meant to say. And that entails looking through other code and documentation. If I’m lucky I won’t lose my tenuous hold on the expression’s meaning before I tie all the ends together.
I should know better than this. I do know better than this. I cannot imagine what I was thinking when I wrote that expression. What bothers me is that it seems to work, as the code has been in production for months. But it’s going to take me 30 minutes or more to prove that it’s really doing what I want it to do. Believe me, it’s tempting to say, “Well, it seems to work,” and just go on.
Keep your code simple. Otherwise the maintenance programmer who comes by six months later will not be happy with you. And it’s likely that you will be that maintenance programmer.
By Jim, on April 23rd, 2011 Something today reminded me of the time my older brother was practicing the song Hava Nagila on his trumpet. I guess I was 9 or 10 years old. A catchy tune, that. I of course had no idea what the title meant or what the lyrics were, but when he started playing the refrain, I started bouncing around the room singing:
Have a banana
have two bananas
have three bananas
walk around the room once more!
As I recall, we both thought that was the funniest thing ever, and we laughed for what seemed like hours. It’s such a strong memory that I often smile whenever I see a banana.
By Jim, on April 19th, 2011 When I got back into ham radio in 2003, Debra bought me a Yaesu FT-90R dual band mobile radio for the truck. I’ve used it quite a bit over the years and have been really happy with its performance until recently.
I noticed a couple of weeks ago that the plastic or vinyl covering on the microphone cord is coming apart. It’s falling apart at both ends, revealing the individual wires. I’ve taped it up temporarily, but in the near future I’ll need to replace that cord. That’s disappointing, as the radio is less than 10 years old and it’s not like I’ve been using it excessively. For sure, being in the truck all the time during the hot summers can’t be especially good for the cord, but I’ve seen much older radios handle that for many decades. It looks to me like Yaesu used substandard materials for their microphone cords.
The microphone cable is a relatively minor problem. This past weekend I discovered a much worse problem: the squelch stopped working. If I turn the squelch up so that I don’t have to listen to the background static, I’m unable to hear transmissions from others. Sometimes this manifests as total silence, and other times it’s an intermittent reception. It sounds like somebody is turning the speaker off and back on a few times per second. It makes the signal almost intelligible.
As it so often turns out, I’m not the only one who’s experienced this problem. In fact, it appears to be relatively well known. Evidently the problem only manifests when the frequency step is set to 5 KHz. Or perhaps if it’s set to anything except 10 KHz. It’s interesting that one site says that the problem is more prevalent on UHF (440 MHz), and others say that the problem is primarily on 2 meters.
I’ve experienced trouble on both bands.
Apparently this is a software problem rather than a hardware problem. The only solution I’ve seen is, “don’t use the 5 KHz step.” That’s easy enough to change from the radio’s options menu, but then I won’t be able to access some repeaters. This morning, for example, there was an emergency situation (toxic fuel spill) and hams were called out to help with notifying residents. The coordinating repeater frequency is 441.625. If I forego the 5 KHz step, I would not be able to hear or transmit to that repeater.
The problem appears to be heat related. Some have said that a second cooling fan helps, and still others have recommended removing the radio’s case and cleaning out any accumulated dust. I’ll definitely try cleaning the thing, but I won’t be installing a fan in the truck to blow across the radio or, as somebody suggested, change the air conditioning ducting.
I’m a bit disappointed, because I really like this little radio. It’s small and yet powerful, with a good signal and a good receiver. Some people complain about the fan noise, but I rarely hear it. But if my only options are to live with no squelch or not use the 5 KHz step, I’ll have to find a new radio for the truck and either sell this one or keep it for an emergency backup.
I wonder what dual band mobile rigs are going for these days . . .
By Jim, on April 11th, 2011 Debra and I bought a new TV last week, along with a computer and other accessories required to launch us into the wide world of Internet TV. Installation went pretty much as expected, with only minor problems, and now we can get all the online offerings on our new 42″ LCD television. Including, I might add, Podly TV. I’m workng on a series of blog entries that outlines what we got and how we set it up. I’ll post here when it’s ready.
The biggest problem we had was with the Internet connection. It would be exceedingly difficult to get an Ethernet cable from the router to the living room where the television is. I figured that wouldn’t be a problem, as we do have wireless and we’ve been able to use it in the living room. And although I did get a signal when I hooked everything up, it was very weak and unreliable.
To solve the problem, I first went and bought a new wireless router, since somebody convinced me that it would produce a better signal than the old Linksys WRT54G that I’ve had for years. It didn’t. And although I’d heard that it’s possible to use the Linksys as a repeater, I certainly couldn’t figure out how to do it. Besides, I don’t know how well that would work with such low signal strength, and there wasn’t a good place in between to place the repeater.
So I took it back to Fry’s and exchanged it for a Hawking HAWNU2 adapter, which I connected to the computer in the living room. The adapter is your basic USB network adapter with a directional antenna (they claim 13dBi gain) and a built-in power amplifier. That thing works like magic. My signal strength went from almost nothing (I didn’t have a measuring tool at the time) to three or four bars (out of five). The wireless signal was strong and reliable.
This morning, I learned of cheap wireless extenders. Specifically, how to build a parabolic reflector that dramatically improves wireless signals. The Linksys has two little “rubber duck” antennas that are omnidirectional. The joke in the ham radio community is that vertical antennas (which these are) radiate equally poorly in all directions. The idea of the reflector is to turn those vertical antennas into directional antennas, increasing their effectiveness by directing more of the signal to where we want it. In my case, directing the signal that would go across the street to the new houses being built so that it goes instead to my living room.
If you can download and print an image, and have even a little skill with a glue stick and a knife or scissors, you can make one of these antennas. Or even two or three, if your router has more than one antenna on it.
Directions for building the Windsurfer. That includes the template image that you need to download and print.
I downloaded the image, printed two copies, and glued them to a manila folder. (Click on any picture below for a larger image.)
Then, using my trusty Stanley No. 199 utility knife (also makes a great wood carving tool, by the way), I carefully cut out the pieces.
A couple of notes here. First, I didn’t do the cutting on that nice laminate. I used a scrap piece of wood for backing. Also, the six horizontal lines on the bottom piece are intended to be cut so that the tabs on the other piece can fit into them. But just slice along the center of the line. Don’t actually cut out a hole, because then the tabs won’t stick in there. Also, it’s probably best if you wait until after the next step before cutting those slices. Finally, cut vertical and horizontal on the “+” signs on the top piece and then push a pencil through them to open the holes. The antenna will slide through those holes.
More fun with the glue stick. Cover the back side of the lower piece with glue and then attach a piece of aluminum foil. Cut along the outline and slice the horizontal lines:
Then, fold the top piece and fit the six tabs into the six slots you cut in the rectangular piece. As an added precaution, I used some packing tape on the back to hold the tabs down. Here are the two reflectors, ready for installation:
The Linksys router sits on the top of a bookshelf, about six feet off the ground. Here are pictures before and after installing the reflectors.
 
So how well does it work? I measured the signal strength in the living room with NetSurveyor before I installed the reflectors. The becon quality fluctuated between 48 and 50%, and gave a becon strength value of between -61 and -59 dBm. It rated the signal quality as “Very Good.” With the reflectors installed, becon quality is between 52% and 55%, with a becon strength value of -59 to -55 dBm. Again, signal quality is “Very Good.” So the reflectors seem to work, but the change isn’t terribly large.
Just for comparison, becon strength here in my office, with the router just a few feet away, is -46 dBm, quality is 70%, or “Excellent.”
The measurements above were taken with the Hawking directional antenna installed.
If I disable the directional antenna and remove the reflectors from the router, the signal ranges from non-existent to “Poor.” When I installed the reflectors, signal strength was consistently “Very Low,” but it was reliable. Strength was about -87 dBm.
Conclusion: the reflectors work, but not nearly as well as I had hoped. They do make the difference between no signal and a weak but usable signal, but I was hoping for something better. I think more experimentation is required: either two slightly larger reflectors, or one much larger reflector that sits behind the router rather than attaching it to the antennas. Until then, the USB directional antenna remains connected to the computer in the living room.
By Jim, on April 7th, 2011 I updated my WordPress installation the other day, and also the Atahualpa theme. The updates installed without a hitch, but the updated theme breaks some of my posts. Specifically, those that have images.
 For example, my Bears! post has two images. The size of the first one is set to 780 by 429 pixels, and that’s the size it displays if your browser window is wide enough. If you narrow the browser window, the image is automatically scaled to fit. In Chrome, the scaling appears to be correct. |
 The results with Internet Explorer 8 aren’t anywhere near as pretty. IE narrowed the image, but for reasons unknown to me decided to maintain the original height . Nice. It’s like a circus fun house mirror.
I spent a little time with the browser’s developer tools (debugger) trying to trace the styles. Somewhere in the stylesheet there’s something that tells the browser to scale the box. It looks like Chrome is scaling in both directions to maintain the aspect ratio, but IE is only scaling the width. I don’t know enough about CSS or this particular stylesheet to say who’s interpreting the CSS incorrectly.
Fixing the error should be fun. My experience with CSS and WordPress themes is that trying to edit somebody else’s theme is like trying to modify an APL program. “Good luck.” |
By Jim, on April 7th, 2011 In How constant is a constant?, I explained how constant values are hoisted from the .NET assembly they’re defined in and at compile time “baked in” to the assembly that references them. The result is that constants are forever. If the value of that constant ever changes then the referencing assembly will have the incorrect value unless that referencing assembly is recompiled.
C# 4.0 introduced Optional Arguments, a feature that has existed in many other languages. With optional arguments, you can write a method such as this:
public void MyMethod(int required, string optional = "default value")
{
Console.WriteLine(optional);
}
You can then optionally include the optional parameter when you call the method:
MyMethod(1, "hello, world); // outputs "hello, world"
MyMethod(1); // outputs "default value"
Remember, though, that the default values you supply for your optional arguments are constants. If you change the default value to, say, “goodbye cruel world”, that changes the constant in the defining assembly, but the previous value is still stored in any programs that referenced the older version. You’ll have to recompile those programs in order to get the new default value.
By Jim, on April 5th, 2011 When announcing the U.S. involvement in the U.N. approved action in Libya, the President stressed that we would not be sending ground troops. Now, we have a diplomat on the ground discussing possible humanitarian and financial assistance to the Libyan rebels. I suspect that soon there will be U.S.-based aid organizations in Libya, funded in large part if not entirely by the U.S. government.
That’s mostly good, I suppose, but when members of those organizations become casualties you will hear many in this country crying out for us to “send in the troops.” I’m not convinced that President Obama (or any other President in recent memory, come to think of it) has the strength to say no to those cries if it looks like sending in the troops will help him win re-election in 2012. The same goes for every Congressman and Senator who will be standing for re-election.
I supported President Bush and Congress when we sent troops to Afghanistan. I thought the idea was to remove the Taliban, who openly assisted the terrorists who carried out the 9-11 attacks, and to dismantle al Qaeda by arresting or killing its leaders and support network. For reasons that aren’t clear to me, we’ve not been wholly successful in that. However, I still believe that supporting the action was correct.
I also supported us going into Iraq because I believed in the President’s assessment that there was a clear and present danger. I also thought that we had a plan. It turns out that the “clear and present danger” was most likely inferred by selectively paranoid interpretations of incomplete intelligence reports, and our “plan” consisted of “kill the bad guys and gather everybody else around the campfire to sing Kumbaya.” I was wrong to support our involvement in Iraq.
I won’t say that our action in Iraq has done nothing positive, but the most important and visible outcome is that we created a power vacuum in the region and there’s only one country with the power to take advantage of it: our good friends in Iran. The Iranian leaders curse us publicly, but I have to believe that in private they thank us every day for removing any possible regional threat to their power. We’re the best friends the Iranian leaders ever had.
We should not be getting more involved in Libya. There is even talk of providing arms for the rebels. Of course, with those arms will almost certainly come “advisors” to show the rebels how to use the weapons. But I suppose those aren’t considered “ground troops,” any more than humanitarian aid workers are. Right? I predict that, if the conflict in Libya draws out, those “advisors” will soon be augmented by other special-purpose personnel who are also, ostensibly, “non-combat troops.” Interesting, though, how often those “non-combat troops” are carrying weapons and actually firing them. Must be one of those definitions of “non-combat” that I’m not aware of.
Let the people of Libya figure it out for themselves. Yes, Gadhafi and his henchmen are slaughtering civilians and armed rebels alike. The same has been happening throughout Africa, Asia, and parts of South America since I can remember, and rarely do we do anything about it. It’s a tragedy, but it’s not our place to stop it. The U.N. seems to think that they have the responsibility to prevent these kinds of atrocities, but the organization is so hampered by politics and bureaucracy that it’s amazing they ever get anything done, even as ineffectively as they do.
If it is our place to stop these kinds of atrocities, then we should stop them: quickly and decisively. Otherwise, we should stay the hell out of it because when we go in pussyfooting around, we invariably make things worse than they would have been had we stayed out of it. Since we don’t have the political will to take decisive action, we should keep the troops–all the troops–at home.
President Obama, now that you’ve shown the world that you have the balls to commit troops and drop bombs, show us that you have the brains to bring the guys home before you get us stuck in another conflict from which we have no good way to extricate ourselves.
By Jim, on April 4th, 2011 I just spent an embarrassing amount of time wondering why my Web application wasn’t displaying things the way I thought it should. When in desperation I made a totally outrageous change to the stylesheet and the display didn’t change, I finally figured out the problem. In my stylesheet, the class name was newVidPreviewImg. In the JavaScript code, it was newvidPreviewImg.
Yes, I had a case problem. My mistake, true, and I’ll own it. But I’ll also say that making names case-sensitive is perhaps the dumbest design decision I’ve seen in CSS–a language that’s chock full of idiocy. The entire language, if you can call it that, is so full of exceptions, limitations, and inconsistencies that it’s pretty obvious the thing is the result of a failed design that was repeatedly patched to handle special cases rather than redesigned to make logical sense. It’s a kludge of the highest order.
Case sensitivity in file names or in programming language identifiers causes an incredible amount of confusion. Development environments that include features such as Intellisense lessen the impact, but don’t eliminate the problem completely. When you’re coding HTML, for example, and you write something like:
<div class="myCoolDivName">
There’s nothing that checks your CSS stylesheet to make sure that “myCoolDivName” is in fact defined. If the name is instead “myCoolDivname”, you’re in for a bit of confusion. The same kind of thing happens in JavaScript.
I’ve yet to see a good argument in favor of case sensitivity in identifiers. Certainly, a programmer would be foolish to define two identifiers in the same scope that differ only by case. It can only cause confusion and lost productivity, especially when you’re working with tools that can’t tell you that you’re making a mistake.
There are many programming language features that, over the years, have been found to be more trouble than they’re worth, and they’ve been eliminated or restricted. Modern languages, for example, restrict the use of the goto statement to prevent you from jumping into the middle of a function or a control structure (you can’t jump into the middle of a loop, for example). C# disallows the shorthand if (a = b) (combined assignment and conditional) because it’s entirely too easy to mistakenly type that construct when you really meant if (a == b) (simple conditional, without assignment).
Case sensitivity is one of those “features” that should not have been included in the C# language, and I suspect it would not have been if the designers weren’t concerned with making it easier to port existing C and C++ code. At least C, C++, and C# have the benefit of a compiler that will tell you when you’ve referenced an undefined identifier. Try working in JavaScript, where identifiers are defined on first use and they’re case-sensitive.
Case sensitivity: evil incarnate. I would suggest that you avoid it if at all possible. It can only hurt you.
By Jim, on March 30th, 2011 I haven’t had a lot of time for carving lately, what with home repair projects and Springtime yard work. When I have had time, I’ve been working on these little guys.
They’re supposed to be bears. Some say that they look like dogs. I don’t much care what other people think they are. They’re cute.
From left to right, the woods are sycamore, sycamore, Bradford pear, and apricot. Pear bear is right at three inches tall.
By Jim, on March 22nd, 2011 After 10 years and 20,000 miles, the bike had some rust spots and lots of scratches from where I’d laid it down a few times. My first inclination was to sand the areas and primer/paint them myself. But the more I got into it, the more convinced I became that I wouldn’t be able to do a good job and the result would look terrible.
I disassembled as much as I could, paid the bike shop $20 to do what I couldn’t (several things require the use of some very expensive tools), and took the frame to Accent Powder Coating. Then back to the bike shop for reassembly. For less than $500, I have what is essentially a new bicycle.
Can’t wait to go for a ride. You can click on the picture below for the full-size image.
By Jim, on March 22nd, 2011 I learned today that there is a memory leak in the .NET 4.0 ConcurrentQueue class. The leak could explain some trouble I was having in December with a program running out of memory. I didn’t know about this bug at the time, but reducing the sizes of several of my queues seems to have made the problem go away.
I know some of you are thinking, “A memory leak in .NET? I thought the garbage collector was supposed to prevent that!” The garbage collector collects garbage–memory that’s no longer referenced. It can’t collect something that’s still being used. Let me explain.
The ConcurrentQueue class uses an array as its backing store. When an item is added to the queue, a reference to the item is placed in the array. As long as an item is in the queue, there is an active reference to it–some part of the program is depending on that item to be good. In garbage collector parlance, the item is “rooted,” meaning that the garbage collector can’t collect it.
When an item is removed from the queue, that item’s slot in the array is supposed to be cleared–set to null. Since the item was removed from the queue, it makes no sense to keep a reference to the item around. And as long as the queue keeps the reference, the garbage collector can’t collect the object.
Problem is, the code that removes items from the queue doesn’t clear the item’s slot in the array. The result is that stale object references remain in the queue’s backing array until one of the following happens:
- An item added to the queue overwrites that slot.
- There are no more references to the queue (i.e. it goes out of scope).
- The array is resized. This happens automatically as the number of items in the queue grows and shrinks.
There might be other ways, but those are all that I can think of at the moment. The point is that items “live” in the queue longer than they absolutely have to, which is a potentially serious memory leak.
I say “potentially serious” because it’s not like the queue grows without bound. At least, it shouldn’t. If your program allows for unbounded queue growth, then you have a more serious problem than this memory leak. That said, with the existence of this bug you have to assume that your queue will always have worst-case memory usage. That is, for the purpose of computing memory consumption, you have to assume that the queue is always full, even when you know that all items have been removed.
This can be a real problem if you use a queue to hold input items, for example, and a separate collection to hold items that have been processed from the queue. For example, imagine a loop that does this:
QueuedThing queued = GetNextItemFromQueue();
ProcessedThing processed = ProcessThing(queued);
AddProcessedItemToList(processed);
Your expectation is that, within the limits of the garbage collection interval, the amount of memory used is:
(sizeof(QueuedThing) * queue.Count) + (sizeof(ProcessedThing) * list.Count)
But with this bug, you have to design for the worst case memory usage, which is:
(sizeof(QueuedThing) * queue.Capacity) + (sizeof(ProcessedThing) * list.Count)
So if QueuedThing and ProcessedThing are the same size, then your worst case memory usage is double what it should be.
Microsoft says that the fix for this will be in the next version of .NET. Considering that .NET releases are typically every two years or so, that means at least another year before this is fixed. Until then, the workaround is to be more careful with the way you use ConcurrentQueue (and BlockingCollection, which uses a ConcurrentQueue as its default backing store). In particular, you should be careful to limit the size of your queue and limit the scope in which the queue is active.
By Jim, on March 17th, 2011 I’ll admit up front that I know very little about CSS–just enough to be dangerous. As a result, I’ve been struggling with creating the layout for a new Web site. I’ve been doing everything else possible, but today I just had to do something to rationalize things. So I sat down with a book: CSS The Definitive Guide.
If this is the “definitive” guide, we’re in trouble. CSS is confusing, and this book doesn’t do much to lessen the confusion. I don’t have the time or the inclination to write a full review of a book that was published in 2006. Suffice it to say that I very highly recommend that you find some other book to get your information from.
One thing I’ve had a lot of trouble with in CSS is positioning elements on the page–making things appear where I want them to. So I turned to the “Floating and Positioning” chapter of the book, which appears to have a reasonably good discussion of the topic. I say appears because it turns out that the book’s description of the offset properties in the “Basic Concepts” part of the chapter is completely misleading:
[The offset] properties describe an offset from the nearest side of the containing block (thus the term offset). For example, top describes how far the top margin edge of the positioned element should be placed from the top of its containing block.
Whereas that’s true for absolute positioning, it’s not at all true for relative positioning. The offsets for relative positioning, as the book points out 30 pages later, are offsets from where the element would normally be positioned. With relative positioning, the offsets have nothing to do with the edges of the containing block.
It’s nice that the book eventually points out the difference, but failing to call out the difference in the overview discussion is a grave omission.
The implementation of CSS falls far short of the goal of creating a robust, easy to use, and easy to understand language for specifying the layout and appearance of Web pages. There are times when I think that the whole of CSS is a joke perpetrated by people who are laughing at those of us who try to use it.
By Jim, on March 4th, 2011 Life is funny. So are home repair projects. At least that’s what I tell myself. Otherwise I’d just go crazy.
Last weekend I had a friend come over and help me with replacing the … whatever it’s called … that goes on the bottom of the outside door. It’s the thing that closes the gap between the bottom of the door and the threshold. I went to Home Depot and, although I couldn’t find exactly what I wanted, got something close. Mike came over and helped me take the door off (it’s a heavy door and a two-man job). We took off the old strip, screwed the new one on, and re-hung the door.
Satisfied with a job well done, we grabbed a couple of beers and went to sit outside. Debra came out a while later to inform us that there was a “huge gap” under the door. Sure enough, the thing I picked up at Home Depot wasn’t big enough to cover the space between the door and the threshold. Debra picked up a new one at Lowes, so I’ll have to install that one this weekend.
Yesterday afternoon, Debra noticed that one of the valves outside had a pinhole leak. We’ve had trouble with this valve freezing before. It’s on the north side of the house and if we get a few days of freezing temperatures in a row, the valve freezes and cracks. We’ve tried lots of ways to prevent that, none of which have worked well. So one of the things I’ll need to do before next winter is build a box with a little heater (probably a 100 watt light bulb) in it. But that’s next year. The valve needs to be replaced now.
The intent was for me to take the valve off this morning, go get the replacement, and install it. But then my truck started running rough last night when I was on my way home. So the plan this morning was for me to turn off the water, remove the valve, have Debra to follow me to the shop where I’d drop off my truck, and then have me drop her off at work so that I could have the car to go back home and install the new valve. A little wrinkle but simple enough, right?
At first light this morning I walked up to the meter (about 300 feet from the house) and turned off our valve. I went back to the house, turned on the faucet to drain the lines, and … the water kept running. Looks like my water shutoff valve at the street is broken. Okay, so it’s 20+ years old. I’ll have to replace that next. But there’s another valve: the service valve on the other side of the meter (the one that the water company can use to shut off my water and then lock).
So back up to the meter to turn off the service valve. I really need to get one of those keys, because turning the thing with a pair of pliers is a pain. I turned it perpendicular like I’m supposed to, trudged back to the house, turned on the faucet and … the water kept running. Great. I can slow the water flow, but can’t stop it.
With no way to turn off the water, we took the truck to the shop and then headed out to take Debra to work. I called the water company to inform them of the broken valve. They didn’t believe me, but agreed to send somebody out “sometime today.”
Debra works for a pipe company, so I talked to one of the guys in the warehouse. After a bit of discussion I hit on the idea of taking the valve off (with the water still on) and then capping the pipe. Should work, provided I can reduce the water flow enough so that the pressure doesn’t prevent me from putting the cap on.
Back at home I turned off both valves at the meter, attached a hose to the faucet that’s also attached to where the valve is (there’s a “T”), ran the hose to the middle of the yard, and turned on the water. Then, armed with a pipe wrench, I began removing the broken ball valve, knowing full well that I was going to get wet. And I did. Drenched. But I was successful in removing the valve and attaching the cap. So at least now there’s no leak.
What was going to be a simple 1-hour job (including running for parts) turned out to be about three hours, and I’m only half done. Plus, there’s another job I have to do–replace the valve at the meter. On the plus side, if my valve hadn’t gone out I wouldn’t have discovered that the service valve was faulty.
The water company guy called me this afternoon to say that their valve at the meter was indeed broken, and that he’d replaced it. It was nice to know that I’m not totally crazy. And there really was something wrong with the truck. One of the ignition coils went out, so only half of the cylinders were firing. I had them replace both coils, figuring that if one went out after 15 years then the other is likely to go soon, too. Most of the cost is labor, anyway, and most of that is removing all the shrouds and such so you can get to the dang coils.
So, yeah, I laugh. I could get angry or sad, but that wouldn’t help anything. At least laughing means that something good comes from these unexpected events.
|
|
|
Comments are closed 
