How about scheduling this way? When you're in the SWAG (Scientific Wild-Ass Guess) stage (or even later), just pick one of the following for each task:
1 day
1 week
1 month
1 quarter
forever
Note that there is no "year" category. If you think something is going to take a year you're not scheduling at the right granularity (and maybe even a quarter is too much).
Monday, December 15, 2008
Sunday, October 12, 2008
C++ References "syntatic sugar" or not?
When I first learned about references in C++, I dismissed them as "syntactic sugar." That is, they are equivalent to
* const
See the Dan Saks article at http://www.embedded.com/story/OEG20010311S0024 for a good explanation. Lately, though, I've be re-thinking that stance.
I can now see how collapsing the * const into a & might make the code easier to understand. I say "might" because I can also see how it can cause confusion for beginners, since the "&" symbol is also used as the "address-of" operator. However, it does reduce the general confusion caused by pointers in more complex type declarations. such as
const SomeType* const varName
See Marshall Cline's article at http://www.parashift.com/c++-faq-lite/const-correctness.html#faq-18.5 for an explanation of how to actually read and understand these declarations.
The thing I still don't like about references is that they give no clue whether an object is a stack-based local object or a parameter passed into the method. I can always hope that whoever wrote the method kept it short enough so I don't have to keep scrolling up and down to look at locals and the parameter list. That doesn't, however, always happen. At least some Interactive Development Environments like Visual Studio allow you to hover over a variable to see its type. I haven't used Eclipse in quite a while, so I can't recall whether the various language plug-ins support it. I assume (or at least I hope) that it works for Java.
* const
See the Dan Saks article at http://www.embedded.com/story/OEG20010311S0024 for a good explanation. Lately, though, I've be re-thinking that stance.
I can now see how collapsing the * const into a & might make the code easier to understand. I say "might" because I can also see how it can cause confusion for beginners, since the "&" symbol is also used as the "address-of" operator. However, it does reduce the general confusion caused by pointers in more complex type declarations. such as
const SomeType* const varName
See Marshall Cline's article at http://www.parashift.com/c++-faq-lite/const-correctness.html#faq-18.5 for an explanation of how to actually read and understand these declarations.
The thing I still don't like about references is that they give no clue whether an object is a stack-based local object or a parameter passed into the method. I can always hope that whoever wrote the method kept it short enough so I don't have to keep scrolling up and down to look at locals and the parameter list. That doesn't, however, always happen. At least some Interactive Development Environments like Visual Studio allow you to hover over a variable to see its type. I haven't used Eclipse in quite a while, so I can't recall whether the various language plug-ins support it. I assume (or at least I hope) that it works for Java.
Thursday, September 18, 2008
Who's Fooling Who?
This morning our San Francisco Chronicle didn't arrive by its appointed time, so I called the Chron's 800 number. I got the usual voicemail with voice recognition and started answering the prompts as instructed. After a few prompts I realized there was a subtle difference about the system. Instead of "dead air" while the system was processing my replies, there was the sound of someone typing on a computer keyboard.
I was vastly amused. Then (per my usual "look on the dark side" view of the world) I started wondering how many people actually believe they are talking to a human being. Or did the human interface guru or gurus determine that (even if customers knew that it was a machine) the sound made the interaction more pleasant? As I said, it made ME grin...
It is P. T. Barnum's "there's a sucker born every minute" or actual useful social engineering?
I was vastly amused. Then (per my usual "look on the dark side" view of the world) I started wondering how many people actually believe they are talking to a human being. Or did the human interface guru or gurus determine that (even if customers knew that it was a machine) the sound made the interaction more pleasant? As I said, it made ME grin...
It is P. T. Barnum's "there's a sucker born every minute" or actual useful social engineering?
Sunday, September 14, 2008
Yesterday's Minor Victory
A few years ago (31.Aug.2004, if GMail remembers rightly), I switched from AOL Mail to GMail. I still have my AOL account, as that is still the primary email for my wife. I also still monitor my AOL account to see where that email address has gotten to, either through my own actions or someone else’s. After the first few months of using GMail I had cleaned out almost all references to that address, but a couple eluded me. I kept getting email from Dartmouth College, where I got my undergraduate degree. I followed their unsubscribe instructions, only to get an automated response saying that the AOL email address was not in their list.
Yesterday I remembered an incident from a few years ago. I manage the email list (using Google Groups) for the United Parents of San Leandro, the PTA equivalent at our local high school. As an aside, I still do this, even though my kids are years gone from the institution. I do try to be a good citizen. At one point I got a list of email addresses from a former member of United Parents, supposedly of individuals who would like to get our emails. I added all those email addresses to the list. Within a few days I started getting emails from one individual threatening us with a lawsuit for spamming her. I went back and reviewed the list of addresses in the Google Group, but couldn’t find the address that this person was sending from. The threatening emails kept coming.
I then realized that this person could have set up a forwarding mechanism from some other email address. I went back to the list and searched for email addresses that were (in any way) similar to the return address on the threatening emails. I found one that looked somewhat close, and took it off the list.
The threatening emails stopped, and no one else complained about not getting their emails.
Coming back to the more recent past, I began wondering if I had put that AOL address as a secondary (e.g., forwarding) address for any other email address. I realized that Dartmouth did provide an email address for alumni, and went to check that. Voila. There was my old AOL address. I don’t know how long ago I put there, but I’ve used AOL since before 2001. I lost my emails previous to that year, so I don't know how far back they really go. I do, however, remember trying to get onto AOL with a 2400K Baud modem, and that must be further back than 2001. In any case, I put that AOL address into the Dartmouth system many years ago.
I changed the reference from that old AOL address to my (no longer new) GMail address. We’ll see what happens, but I’m assuming (and hoping!) that I will not get any more emails from Dartmouth to that AOL address.
Now the only reference to my AOL address is from Pacific Bell (oops, sorry, now AT&T), and I can't get to their page where I (supposedly) can remove my old address from their list. One of these days I'll debug that problem.
Saturday, September 13, 2008
Six vs. Twenty-Four Jams: Too Many Choices
As much as I have fond remembrances of Perl, I'm glad languages like Python are around. As I mentioned in a previous post, one of the reasons I left Perl behind was TMTOWTDI. Note the reference in this Wikipedia article to the Python principle that espouses the opposite philosophy. I've now found more support for the idea that more is not more, and is sometimes less.
I've read a few articles that cited a study where consumers were presented with different numbers of choices for buying jam. Searching for those terms turned up this article. I found it interesting that more choices made more people stop and look, but more choices reduced the number of people that actually bought any jam. I, like many others, like to feel that I know enough to make an informed choice. I also realize, however, that I am just as happy to have someone (who I hope is more knowledgeable than me) winnow down those choices to a set to which I can actually give decent consideration. This also reduces the time required to make a choice.
I know that for Perl, once I figured out how to do something, I actively rejected trying to find other ways to do that same thing. I never felt the need. I also never had a case where performance was an issue (which would have forced me to look at other ways). I also, thankfully, never had a Perl prophet try to convert me to the "Many True Ways" of Perl.
This also makes me think of all the sales vice presidents that have touted their "pipeline," but weren't able to translate that into actual sales. It's the end result that matters (both the quality of that result and how long it took to get there), whether you're on the making, selling or buying side of things.
I've read a few articles that cited a study where consumers were presented with different numbers of choices for buying jam. Searching for those terms turned up this article. I found it interesting that more choices made more people stop and look, but more choices reduced the number of people that actually bought any jam. I, like many others, like to feel that I know enough to make an informed choice. I also realize, however, that I am just as happy to have someone (who I hope is more knowledgeable than me) winnow down those choices to a set to which I can actually give decent consideration. This also reduces the time required to make a choice.
I know that for Perl, once I figured out how to do something, I actively rejected trying to find other ways to do that same thing. I never felt the need. I also never had a case where performance was an issue (which would have forced me to look at other ways). I also, thankfully, never had a Perl prophet try to convert me to the "Many True Ways" of Perl.
This also makes me think of all the sales vice presidents that have touted their "pipeline," but weren't able to translate that into actual sales. It's the end result that matters (both the quality of that result and how long it took to get there), whether you're on the making, selling or buying side of things.
Thursday, August 21, 2008
XMLSerializer, part 2
After spending more time fixing bugs and digging into XMLSerializer (see my previous post), I've come the the following conclusions:
- I'm still satisfied with my design where I split the "data" into a separate class. It makes it much easier to quickly see what is being serialized and what is not. If I hadn't done this, I would have reorganized the fields in my objects to put all the serializable fields together, so I could put all the unserializable fields (with their corresponding noisy attribute tags) in a separate section of the class definition.
- I figured out my problem (mentioned in bullet item 3 in the previous post). I had not provided a default value for an enum in the class definition. Once I did that, the uninformative error message went away and my object was sitting happily on disk.
On to the next learning experience...
Friday, August 1, 2008
Dealing with .NET XMLSerializer
I've found that the clearest (e.g., fewest lines of code) and quickest (e.g., fewest surprises) way to deal with XMLSerializer is to create "data" classes. These instances of these classes are then owned and used by instances of "code" classes. This gets around the following issues:
- XMLSerializer will only serialize Public fields. It isn't good programming practice to have to declare fields as public. To reduce this ugliness, I moved the serializable fields down into the data class and made the reference to the data class Private. I then put Public Property(s) on the code class that reference the field in the data class.
- XMLSerializer doesn't support hashtables, which I find much more useful (and natural in many cases). I used hashtables on the code class. I then added code to a GetSerializable
method that sits on the code class that populate the corresponding array on the data class on demand. - XMLSerializer doesn't provide very good error messages. My first attempt at changing a class to user XMLSerializer hit many problems with many different fields in the existing class. Using a data class, I don't have to figure out all the problems all at once. I can move fields from the code class to the data class incrementally, and figure out the particular problem with that field before moving on to the next. One specific example of this are issues with using Public Property. I haven't figured out what they are yet, but I'm suspicious of either:
- Public Properties that aren't simple "return" and "assignment" Properties.
- Public Properties that wrap a field that is also Public.
The downside is that I have a few extra public fields on various objects that are only used for serialization. The upside is fewer lines of code and a (somewhat) straightforward paradigm for dealing with XMLSerializer.
Wednesday, July 30, 2008
Thank you, EasyBCD!
And I don't mean Binary Coded Decimal.
I recently set up a test machine with a dual-boot XP/Vista configuration. Being the cautious type, I went to make a disk image of the Vista side. That is the side I would be using for testing, and would need to be able to quickly and easily restore it to a clean state (e.g., not have to tediously reinstall Vista each time).
I first tried an old version of DiskImage. Nope, won't run off an NTFS drive and I have no floppy in that machine. Toss the CD and recycle the manual.
Next tried a 2003 version of Norton Ghost. Things seemed to go well for a while, but went south really suddenly. I believe that it choked when it tried to deal with the Vista BCD (Boot Configuation Data) stores. Toss that CD and recycle that manual.
Trying to then reinstall Vista failed repeatedly because the reboots kept trying to reboot a corrupted operating system. I couldn't get to the BCD data from the XP side until some Googling turned up EasyBCD, which saved my sorry butt. Now I'm re-installing Vista.
I think I'll next try Ubuntu with PartImage to back up the disk image. I've paid Symantec enough money over the past few years.
I recently set up a test machine with a dual-boot XP/Vista configuration. Being the cautious type, I went to make a disk image of the Vista side. That is the side I would be using for testing, and would need to be able to quickly and easily restore it to a clean state (e.g., not have to tediously reinstall Vista each time).
I first tried an old version of DiskImage. Nope, won't run off an NTFS drive and I have no floppy in that machine. Toss the CD and recycle the manual.
Next tried a 2003 version of Norton Ghost. Things seemed to go well for a while, but went south really suddenly. I believe that it choked when it tried to deal with the Vista BCD (Boot Configuation Data) stores. Toss that CD and recycle that manual.
Trying to then reinstall Vista failed repeatedly because the reboots kept trying to reboot a corrupted operating system. I couldn't get to the BCD data from the XP side until some Googling turned up EasyBCD, which saved my sorry butt. Now I'm re-installing Vista.
I think I'll next try Ubuntu with PartImage to back up the disk image. I've paid Symantec enough money over the past few years.
Friday, July 4, 2008
Cassandra, Take a Bow
I've always considered myself a realist. Some may call me a pessimist, but many of my predictions have turned out correctly. I don't like being seen as negative, so I do try to lighten up a bit. This led to an amusing incident at my current job.
After telling my boss a number of times that I thought an expectation was too optimistic, I decided to tell him the legend of Cassandra (because I was starting to feel like the prophet-not-listened-to). After I told him the story, I told him (jokingly) that I considered myself the Cassandra of my group.
A couple of days later, my business phone rang. I get very few calls on that line, since my group tends to use GTalk if possible. I therefore get a higher percentage than usual of wrong numbers. I was in the middle of debugging something, so I was focused on that task rather than the phone call. I picked up the phone and someone said, "Is Cassandra there?"
I almost hung up, but decided to be polite and ask the person what number they dialed (expecting that it was a wrong number).
It was my boss. Given my past history with him, I should be careful what I ask for, because he does have a keen sense of humor.
After telling my boss a number of times that I thought an expectation was too optimistic, I decided to tell him the legend of Cassandra (because I was starting to feel like the prophet-not-listened-to). After I told him the story, I told him (jokingly) that I considered myself the Cassandra of my group.
A couple of days later, my business phone rang. I get very few calls on that line, since my group tends to use GTalk if possible. I therefore get a higher percentage than usual of wrong numbers. I was in the middle of debugging something, so I was focused on that task rather than the phone call. I picked up the phone and someone said, "Is Cassandra there?"
I almost hung up, but decided to be polite and ask the person what number they dialed (expecting that it was a wrong number).
It was my boss. Given my past history with him, I should be careful what I ask for, because he does have a keen sense of humor.
Monday, June 30, 2008
A more reliable test bed
I've been working on putting together a test bed for the product that my company currently offers. My first cut at the test bed used AutoIt to drive the GUI and NUnit for the testing framework. This worked, but I felt it was too fragile (and perhaps too complex) for our QA folks. I therefore wrote an embedded test framework using my simple command parser that worked better.
First, it didn't require multiple executables (e.g., a separate application to drive the GUI using AutoIt). This reduced the complexity of the system, which was immediately reflected in the amount of documentation and support I had to produce.
Second, one can go off and do other tasks (e.g., read email) while the tests are running. This happened because the test bed no longer sent mouse and keyboard events to the application, so there was no contention for those resources. Responsiveness isn't what I would like, but that's the price I pay (until I get a machine with a multi-core CPU). Note that the window of the application running the tests may come to the top, so you may lose keystrokes if you are typing into another application. This shouldn't, however, interfere with the tests. E.g., the application with the embedded test-bed should ignore those keystrokes.
Third, I realized that this does away with synchronization issues. I am intimately familiar with the problems of dealing with variable wait times. For example, when using a GUI driver such as AutoIt or Silk, the testing application that drives the GUI may need to wait for a network to respond or for a long-running calculation to finish. It is usually unclear how long to allow the GUI driver to wait before assuming that something went wrong. Since this framework is "synchronized" with the application, this issue just disappeared. Admittedly, I should probably add some "time-out" feature (in the future) to handle any hangs, but I'll wait for the QA folks to ask for that before I put any effort into it.
Fourth, since there is no need for the test framework to wait, the test sequence will run faster.
The downside is that adding more tests requires some coding in the application. This, however, is usually straightforward. I find where the event from the GUI is handled and add a little hook function to call that same code, with parameters as necessary.
It's a pleasant suprise to have some positive unintended consquences, instead of (more common) negative side effects.
First, it didn't require multiple executables (e.g., a separate application to drive the GUI using AutoIt). This reduced the complexity of the system, which was immediately reflected in the amount of documentation and support I had to produce.
Second, one can go off and do other tasks (e.g., read email) while the tests are running. This happened because the test bed no longer sent mouse and keyboard events to the application, so there was no contention for those resources. Responsiveness isn't what I would like, but that's the price I pay (until I get a machine with a multi-core CPU). Note that the window of the application running the tests may come to the top, so you may lose keystrokes if you are typing into another application. This shouldn't, however, interfere with the tests. E.g., the application with the embedded test-bed should ignore those keystrokes.
Third, I realized that this does away with synchronization issues. I am intimately familiar with the problems of dealing with variable wait times. For example, when using a GUI driver such as AutoIt or Silk, the testing application that drives the GUI may need to wait for a network to respond or for a long-running calculation to finish. It is usually unclear how long to allow the GUI driver to wait before assuming that something went wrong. Since this framework is "synchronized" with the application, this issue just disappeared. Admittedly, I should probably add some "time-out" feature (in the future) to handle any hangs, but I'll wait for the QA folks to ask for that before I put any effort into it.
Fourth, since there is no need for the test framework to wait, the test sequence will run faster.
The downside is that adding more tests requires some coding in the application. This, however, is usually straightforward. I find where the event from the GUI is handled and add a little hook function to call that same code, with parameters as necessary.
It's a pleasant suprise to have some positive unintended consquences, instead of (more common) negative side effects.
Tuesday, June 10, 2008
Ageism?
Don't bother applying for a job at Facebook if you got your college degree before 1980.
The dropdown for "Graduation Date" on their job application doesn't go back that far.
Addendum:
In an industry survey, a majority of technology companies candidly said they would not hire anyone over 40.
The dropdown for "Graduation Date" on their job application doesn't go back that far.
Addendum:
In an industry survey, a majority of technology companies candidly said they would not hire anyone over 40.
New York Times, article in "This Week" section on June 22, 2008, titled "For a Good Retirement, Find Work. Good Luck."
Wednesday, June 4, 2008
Today's lesson...
I went searching for a line continuation character in DOS. I needed to make my CMD scripts more readable (if such scripts can ever be made readable - I'll use Ant next time). Searching around I found that the caret ("^") was supposed to be the continuation character. I tried it and it didn't work at first, until I realized that I was using it in the middle of a quoted string.
Re-jiggered the long command to put the caret(s) outside of quoted strings and it works like a champ. Not that I want to claim to be an expert in CMD scripts...
Re-jiggered the long command to put the caret(s) outside of quoted strings and it works like a champ. Not that I want to claim to be an expert in CMD scripts...
Tuesday, May 13, 2008
A Stitch in Time
I have written a bunch of multi-threaded code in the past few years. (I realize that a "bunch" isn't very quantifiable, but bear with me.) It seemed to work fairly well; the server product I worked on was able to make use of multiple CPUs whenever possible. I tested it on multiple CPU machines and saw all CPUs being fully used under load. Also, others used that product on 8-way boxes with good reliability. I have found and fixed threading bugs in my own code and in other's code. I still, however, find myself looking for patterns to help me deal with threading, to increase my confidence in my (and other's) multi-threaded code.
I don't know if it is the indeterminacy of it, or if it's that I don't feel I can hold a lot of multiple states in my head at once. I also know that the few times I've tried to have my threading code reviewed by others they gave up long before I got any feedback of any kind. I don't know if that was because the code was opaque (though there wasn't very much of it...) or because they weren't able to deal with multi-threaded code any better than I was.
I had a number of concerns about the use of mutexes in that product. My primary concern was the sheer number, both of types and of instances. I felt that I had to make sure that the whole system couldn't deadlock, but given those numbers there was no way that I (or anyone I know) could do that.
The principles I will follow in the future are as follows:
I don't know if it is the indeterminacy of it, or if it's that I don't feel I can hold a lot of multiple states in my head at once. I also know that the few times I've tried to have my threading code reviewed by others they gave up long before I got any feedback of any kind. I don't know if that was because the code was opaque (though there wasn't very much of it...) or because they weren't able to deal with multi-threaded code any better than I was.
I had a number of concerns about the use of mutexes in that product. My primary concern was the sheer number, both of types and of instances. I felt that I had to make sure that the whole system couldn't deadlock, but given those numbers there was no way that I (or anyone I know) could do that.
The principles I will follow in the future are as follows:
- Don't be afraid of multiple mutexes.
- Do as little as possible while holding locks.
- Never hold a lock infinitely.
I don't know if this will make it easier (and more comfortable and reliable) for me to work on multi-threaded code, but I know I can't go about it as I have in the past.
Wednesday, May 7, 2008
Visual Basic command parser example
OK, I left the Visual Basic version of this code as an "exercise for the reader," but it turned out that I needed it myself. I translated (by hand) the C# example but couldn't get the Visual Basic version to find the method in the InvokeMember call (even after the FindMembers call had found it). I poked around some more, thinking that once I had the MethodInfo I should be able to use it directly without having to use InvokeMember.
Sure enough, after poking around a bit I found Invoke (on the MethodInfo itself), and it works like a charm.
Maybe some day when I'm feeling more ambitious I'll go back and rework the C# example to match the Visual Basic example, but probably not until I really need to. I actually hope I don't, because that means that I will have a need to use C#, and I'd rather stay cross-platform with something like Java, C++ or Python.
Sure enough, after poking around a bit I found Invoke (on the MethodInfo itself), and it works like a charm.
Maybe some day when I'm feeling more ambitious I'll go back and rework the C# example to match the Visual Basic example, but probably not until I really need to. I actually hope I don't, because that means that I will have a need to use C#, and I'd rather stay cross-platform with something like Java, C++ or Python.
Friday, May 2, 2008
The Third Commandment of Blogger
Don't use Blockquote!
First, every time I try to use blockquote both browsers show succeeding paragraphs with a tighter line-spacing than the previous paragraph. This happens with the default font; I haven't tried other fonts because no one it paying me to test this stuff. This paragraph is an example of this effect. Secondly (because of its definition), blockquote takes line endings literally, making for some very strange line breaks as shown above. I like indention to set off text, but not when it comes with this side-effect.
For commandments One and Two, see my previous post. That post shows the same incorrect line-spacing in the numbered list. Also note the extra line-space above this paragraph, which seems be be caused by saving and then re-editing the post. Well, at least I'm not paying anything for these bugs.
I'm still struggling to figure out what Blogger is doing to my formatting. I'm
not sure if it's this particular template, or something deeper down in Windows, or perhaps some backwards compatibility issue.
I say "deeper down in Windows" because I see the same effect in both Internet
Explorer and Firefox on my Windows XP machine. I don't (currently) have any Linux desktop machines to test this.
First, every time I try to use blockquote both browsers show succeeding paragraphs with a tighter line-spacing than the previous paragraph. This happens with the default font; I haven't tried other fonts because no one it paying me to test this stuff. This paragraph is an example of this effect. Secondly (because of its definition), blockquote takes line endings literally, making for some very strange line breaks as shown above. I like indention to set off text, but not when it comes with this side-effect.
For commandments One and Two, see my previous post. That post shows the same incorrect line-spacing in the numbered list. Also note the extra line-space above this paragraph, which seems be be caused by saving and then re-editing the post. Well, at least I'm not paying anything for these bugs.
Thursday, May 1, 2008
We Don't Need No Stinking Comments
I am trying to put together some coding standards for the company where I currently work. Yeah, another exercise, but not (I hope) a futile one. As always happens, someone wanted to have a standard for comments.
My only answer to that was this: "If a program acts differently from the way the end-documentation says it should, which do you trust?" I feel the same way about comments. It's not that I don't appreciate them, but I just don't trust them as much as I trust the code. Admittedly it's usually a harder slog through the code, but once you've figured out what the code does, the comments are usually not useful.
As Kernighan and Plauger say on page 142 (1974 edition) of "The Elements of Programming Style:"
The problem with comments that do not accurately reflect the code is that they may well be believed subconsciously, so the code itself is not examined critically.
I wish I could come up with some good way to measure the effectiveness (or in-effectiveness) of comments, but I'm just going to have to go with my gut on this one. I don't think we can have any standard for comments that anyone will agree upon. We may be able to come up with some recommendations, but as for enforceable standards? In "The Practice of Programming" (Kernighan and Pike, 1999), page 24 generously says:
Comments can be useful, of course.
And the rest of the page goes on to show some good usages. This page, however, is surrounded by a list of things NOT to do with comments. Seems like it's easier to tell people what not to do, rather than what to do.
[If you don't know the American pop culture reference from the title, check here or here.]
My only answer to that was this: "If a program acts differently from the way the end-documentation says it should, which do you trust?" I feel the same way about comments. It's not that I don't appreciate them, but I just don't trust them as much as I trust the code. Admittedly it's usually a harder slog through the code, but once you've figured out what the code does, the comments are usually not useful.
As Kernighan and Plauger say on page 142 (1974 edition) of "The Elements of Programming Style:"
The problem with comments that do not accurately reflect the code is that they may well be believed subconsciously, so the code itself is not examined critically.
I wish I could come up with some good way to measure the effectiveness (or in-effectiveness) of comments, but I'm just going to have to go with my gut on this one. I don't think we can have any standard for comments that anyone will agree upon. We may be able to come up with some recommendations, but as for enforceable standards? In "The Practice of Programming" (Kernighan and Pike, 1999), page 24 generously says:
Comments can be useful, of course.
And the rest of the page goes on to show some good usages. This page, however, is surrounded by a list of things NOT to do with comments. Seems like it's easier to tell people what not to do, rather than what to do.
[If you don't know the American pop culture reference from the title, check here or here.]
Monday, April 21, 2008
Technology for Good and Bad
I closed an account at Bank of America a few months ago. After I showed my driver's license to the teller, he swiped it through the magnetic card reader at this station. Perhaps I haven't been dealing with banks and bank tellers much lately, but I was intrigued and amused.
Then, of course, he proceeded to try to sell me a Bank of America credit card. I told him I already have enough credit cards and he proceeded to enter that little bit of information into his terminal.
Perhaps the programming elves at Bank of America implemented the "read the DMV magnetic strip" as an ease-of-use measure, or perhaps they are trying to reduce the number of data entry errors by their front-line people. In any case, it certainly made it easier for me, since I wasn't carrying the bank card that came with the account.
This use of technology I appreciate.
I didn't, on the other hand, appreciate Bank of America making the teller try to sell me something, and I certainly didn't appreciate that they then make him record why. I've already had to deal with a number of telesales calls from them (until I told them to put me on their Do Not Call list). I wonder if my interaction with the teller just took me back off their Do Not Call list. If so, I'll just go through getting off it again.
Then, of course, he proceeded to try to sell me a Bank of America credit card. I told him I already have enough credit cards and he proceeded to enter that little bit of information into his terminal.
Perhaps the programming elves at Bank of America implemented the "read the DMV magnetic strip" as an ease-of-use measure, or perhaps they are trying to reduce the number of data entry errors by their front-line people. In any case, it certainly made it easier for me, since I wasn't carrying the bank card that came with the account.
This use of technology I appreciate.
I didn't, on the other hand, appreciate Bank of America making the teller try to sell me something, and I certainly didn't appreciate that they then make him record why. I've already had to deal with a number of telesales calls from them (until I told them to put me on their Do Not Call list). I wonder if my interaction with the teller just took me back off their Do Not Call list. If so, I'll just go through getting off it again.
Monday, April 14, 2008
Appropriate Technology
One of the side effects of having a Prius with the radio-key is that I sometimes leave the key in my pocket. When I leave the car I don't need to pull the key out of the slot, so I had a personal pattern set where I just get out, close the door and press the Lock button on the outside of the door.
Once (and only once) that got mixed up with my personal pattern for our van. I got out of the van, pressed the lock button on the inside of the door and merrily shut the door. It was only later that I realized that I had locked my keys into the van. What about the warning buzzer, you ask? Well, it has been malfunctioning for a number of years now, and always buzzes when the door is open (regardless of the state of the keys or the headlights). The van is old and I want to spend as little as possible keeping it running.
I called AAA and they sent one of their guys. He got out of his truck with a little pillow with an inflater bulb on it. I watched in fascination as he slid the pillow between the door and the pillar and inflated it to force the door open just enough so he could get a long plastic wand through the opening. He then used this wand to push the Unlock button on the door. Nothing electronic at all.
Much to my chagrin, I had to call AAA again later that day when I went to leave work and found that I had also left the lights on. I hadn't noticed it at lunch.
Maybe I should get that buzzer fixed.
Once (and only once) that got mixed up with my personal pattern for our van. I got out of the van, pressed the lock button on the inside of the door and merrily shut the door. It was only later that I realized that I had locked my keys into the van. What about the warning buzzer, you ask? Well, it has been malfunctioning for a number of years now, and always buzzes when the door is open (regardless of the state of the keys or the headlights). The van is old and I want to spend as little as possible keeping it running.
I called AAA and they sent one of their guys. He got out of his truck with a little pillow with an inflater bulb on it. I watched in fascination as he slid the pillow between the door and the pillar and inflated it to force the door open just enough so he could get a long plastic wand through the opening. He then used this wand to push the Unlock button on the door. Nothing electronic at all.
Much to my chagrin, I had to call AAA again later that day when I went to leave work and found that I had also left the lights on. I hadn't noticed it at lunch.
Maybe I should get that buzzer fixed.
Tuesday, April 8, 2008
What I Learned Today
I started using the Lightning calendar add-on with the Thunderbird email client a few weeks ago, and have been wondering what the "CW" stood for in its date display.
Country Western?
Conventional Wisdom?
Used Google search and after going through a few search terms that either gave me too much or too little, I used "calendar CW lightning," which turned up this:
https://addons.mozilla.org/en-US/thunderbird/discussions/comments.php?DiscussionID=7662&page=1#Item_0
Ah, "Current Week!"
... and today's rant...
If I had time, I'd love to work on the Thunderbird text editor. I've gotten to the point where (if I'm going to use any formatting) I just compose my emails in Word, paste them into Thunderbird and then clean up as necessary. I do this because I have not yet been able to figure out how Thunderbird stores its formatting, and I can't find any way to make the "markup" visible. Is this because Thunderbird uses some low-grade Microsoft editing control, or some other reason? (Not that the editor in OutLook Express, or whatever its current name is, is much better...)
Country Western?
Conventional Wisdom?
Used Google search and after going through a few search terms that either gave me too much or too little, I used "calendar CW lightning," which turned up this:
https://addons.mozilla.org/en-US/thunderbird/discussions/comments.php?DiscussionID=7662&page=1#Item_0
Ah, "Current Week!"
... and today's rant...
If I had time, I'd love to work on the Thunderbird text editor. I've gotten to the point where (if I'm going to use any formatting) I just compose my emails in Word, paste them into Thunderbird and then clean up as necessary. I do this because I have not yet been able to figure out how Thunderbird stores its formatting, and I can't find any way to make the "markup" visible. Is this because Thunderbird uses some low-grade Microsoft editing control, or some other reason? (Not that the editor in OutLook Express, or whatever its current name is, is much better...)
Friday, April 4, 2008
Maximum Method Magnitude
While I was roughing out a series of coding standards for the company I currently work at, I decided to quantify what I mean by "a method that is too long." I prefer to have methods (and functions, for the non-object-oriented among you, or you functional programmers) that I can see all at once. I don't like to scroll up and down (or left and right) to see the whole method. I therefore decided to quantify how much I could see on my screen at once so I could put some specific numbers in the standard.
Note that this restriction is relaxed for methods that are case statements with many similar, small cases, or other simple and repetitive structures. Since these are more "data"-like than "code"-like, having to scroll up and down doesn't interrupt my flow of thought as much as with regular code.
I currently have a Dell flat-screen that I measure at 22" (559 mm) visible diagonal size (regardless of what the Dell sales literature says...). I run it at its default resolution (1680 horizonally by 1050 vertically). I have a few icons on my desktop on the left (heavy use) and right (lighter use), so that reduces my available screen size a bit. I also like to leave room at the bottom of the screen for the taskbar.
I bounce back and forth between three editors, my old standby Epsilon, the Microsoft Visual Studio Editor and Eclipse.
I run Epsilon at 8-point Courier New, which gives me approximately 60 lines vertically and 200 characters horizontally. I spend more time in this editor than the others, so I've spent more time getting it to settings that work for me.
I never changed the default settings for Visual Studio. When I configure it as I usually work (one column of panes on the right), I get about 45 lines vertically and 150 characters horizontally. Note that this is reduced during debugging, because more panes appear. Tools, Options, Environment, Fonts and Colors tells me that I'm using 10-point Courier New.
I also never changed with the font settings in Eclipse. Preferences, General, Appearance, Colors and Fonts tells me that I'm using 10-point Courier New. This gives me 40 lines by 140 characters with the default set of panes on the right, left and bottom.
For Visual Studio and Eclipse, I could probably go back and change the font size to be closer to my Epsilon setting and get similar results (if I'm ever motivated enough).
One added restriction. I really don't like lo-o-o-ong lines. There is a reading phenomenon called "doubling" where, when lines are too long, you lose track of which line is the next one you need to go back to when you read to the end of the current line. This is less of a problem in code than in text, given the "poetic" (as opposed to "text") layout of code. I still, however, find it reduces readability for me, especially when I have to scroll a couple of screenfuls to the right horizonally and then jump all the way back to the left and locate the next line of the code.
Given all of the above, I'm going to put 60 lines vertically by 100 characters horizonally into the standards document. We'll see what my team members think of my numbers.
Finally, apologies for the forced alliteration of the title. I just finished reading a new translation of Sir Gawain and The Green Knight (by Simon Armitage), where there is heavy use of alliteration. If you like that sort of book, this one's a good read.
Note that this restriction is relaxed for methods that are case statements with many similar, small cases, or other simple and repetitive structures. Since these are more "data"-like than "code"-like, having to scroll up and down doesn't interrupt my flow of thought as much as with regular code.
I currently have a Dell flat-screen that I measure at 22" (559 mm) visible diagonal size (regardless of what the Dell sales literature says...). I run it at its default resolution (1680 horizonally by 1050 vertically). I have a few icons on my desktop on the left (heavy use) and right (lighter use), so that reduces my available screen size a bit. I also like to leave room at the bottom of the screen for the taskbar.
I bounce back and forth between three editors, my old standby Epsilon, the Microsoft Visual Studio Editor and Eclipse.
I run Epsilon at 8-point Courier New, which gives me approximately 60 lines vertically and 200 characters horizontally. I spend more time in this editor than the others, so I've spent more time getting it to settings that work for me.
I never changed the default settings for Visual Studio. When I configure it as I usually work (one column of panes on the right), I get about 45 lines vertically and 150 characters horizontally. Note that this is reduced during debugging, because more panes appear. Tools, Options, Environment, Fonts and Colors tells me that I'm using 10-point Courier New.
I also never changed with the font settings in Eclipse. Preferences, General, Appearance, Colors and Fonts tells me that I'm using 10-point Courier New. This gives me 40 lines by 140 characters with the default set of panes on the right, left and bottom.
For Visual Studio and Eclipse, I could probably go back and change the font size to be closer to my Epsilon setting and get similar results (if I'm ever motivated enough).
One added restriction. I really don't like lo-o-o-ong lines. There is a reading phenomenon called "doubling" where, when lines are too long, you lose track of which line is the next one you need to go back to when you read to the end of the current line. This is less of a problem in code than in text, given the "poetic" (as opposed to "text") layout of code. I still, however, find it reduces readability for me, especially when I have to scroll a couple of screenfuls to the right horizonally and then jump all the way back to the left and locate the next line of the code.
Given all of the above, I'm going to put 60 lines vertically by 100 characters horizonally into the standards document. We'll see what my team members think of my numbers.
Finally, apologies for the forced alliteration of the title. I just finished reading a new translation of Sir Gawain and The Green Knight (by Simon Armitage), where there is heavy use of alliteration. If you like that sort of book, this one's a good read.
Saturday, March 29, 2008
CSharp command parser example
I've added a CSharp example to the command lookup example code at http://code.google.com/p/dead-simple-command-lookups/. This, along with the C++ example, are as far as I plan to go. I (currently) don't use other langauges, and thus have no need to keep other versions readily available.
Ah, the truth comes out. I didn't really put this up for others to use (although they are certainly welcome to do so, given that the code is under the MIT license). I just wanted to have this code readily available when I needed to use it.
Ah, the truth comes out. I didn't really put this up for others to use (although they are certainly welcome to do so, given that the code is under the MIT license). I just wanted to have this code readily available when I needed to use it.
Wednesday, February 13, 2008
No Whining! (...at least not today...)
Rather than complain about something, today I want to contribute. I have been working on some very simple command lookup programs in various languages. I've finished most of them (one more to come - the C++ version). They are in Google Code at http://code.google.com/p/dead-simple-command-lookups/. Note that I've put the files into the download section as well as under Subversion for those that don't want to bother with getting a Subversion client running.
Wednesday, January 30, 2008
Cell Phones Are Still a Compromise
I have a cellphone but it's off most of the time. I've given out the number to very few people, and they know that I keep the phone off most of the time. Since I don't have call blocking enabled (that I know of!) anyone I call can grab my number. Since I don't, however, call that many people, I don't worry about who they are.
A number of months ago I interviewed at Google. I didn't get the job (sigh) but that's bits into the bucket. One of the pieces of information that came across in one of the emails (from their recruiter) was that they preferred that their interviewees NOT use cell phones during the phone screens.
This intrigued me. I'm not sure whether this is because cell phone networks in some countries aren't up to snuff or for some other reason(s). I do know from my own personal experience that about half the cell phone calls I make have dropouts or clarity problems, even in "civilized" places like the San Francisco Bay Area. Which actually is the primary reason I don't turn my cell phone on unless absolutely necessary.
A number of months ago I interviewed at Google. I didn't get the job (sigh) but that's bits into the bucket. One of the pieces of information that came across in one of the emails (from their recruiter) was that they preferred that their interviewees NOT use cell phones during the phone screens.
This intrigued me. I'm not sure whether this is because cell phone networks in some countries aren't up to snuff or for some other reason(s). I do know from my own personal experience that about half the cell phone calls I make have dropouts or clarity problems, even in "civilized" places like the San Francisco Bay Area. Which actually is the primary reason I don't turn my cell phone on unless absolutely necessary.
Thursday, January 24, 2008
JavaScript Strikes Again
In a recent job interview, I was asked how does one detect (in a JavaScript function) whether a parameter actually had a value passed to it. It's been a long time since I've done any JavaScript, so I answered that I assumed there was a way to test for "null". The interviewer said that I had the appropriate concept, but the actual language keyword to test against was "undefined". We then had a brief discussion about null versus undefined, but I wanted to find out more.
Google turned up this page which has some very concise and useful examples. I was not amused, however, to read that testing for null will return true regardless of whether the value is actually null or undefined. I would hope that testing for undefined doesn't return true for null, and I hope to have time to test this sometime in the future. This brought me back to the first time I realized that JavaScript didn't (in previous incarnations, anyway) syntax check code that was never executed. I'm used to that happening for shell script, but it brought me up short for a language that actually seemed to be used in many shipping products.
I guess one works with what one is given, but it doesn't make me any more confident in JavaScript as a robust language.
Google turned up this page which has some very concise and useful examples. I was not amused, however, to read that testing for null will return true regardless of whether the value is actually null or undefined. I would hope that testing for undefined doesn't return true for null, and I hope to have time to test this sometime in the future. This brought me back to the first time I realized that JavaScript didn't (in previous incarnations, anyway) syntax check code that was never executed. I'm used to that happening for shell script, but it brought me up short for a language that actually seemed to be used in many shipping products.
I guess one works with what one is given, but it doesn't make me any more confident in JavaScript as a robust language.
Thursday, January 17, 2008
Today's Formatting Hobgoblin
One of the little things that bothers me about some of the code I work with is the variation in handling of the "if" statement. In this code an "if" with a single statement in the "if" block (and no "else" block) will end up on one line:
if (condition) do_something_else();
I find this interrupts my reading of the code. I realize that putting brackets around the statement in the "if" block and putting the statement on its own line will add two lines to the code. I find, however, the consistency of formatting makes the code easier to read (for me, anyway).
This may be a foolish consistency or not. I looked back to my favorite coding standard for support. The Linux kernel coding style says "Don't put multiple statements on a single line unless you have something to hide." This doesn't mention brackets, but that follows from other standards.
At least I'm not the only voice crying in the wilderness...
if (condition) do_something_else();
I find this interrupts my reading of the code. I realize that putting brackets around the statement in the "if" block and putting the statement on its own line will add two lines to the code. I find, however, the consistency of formatting makes the code easier to read (for me, anyway).
This may be a foolish consistency or not. I looked back to my favorite coding standard for support. The Linux kernel coding style says "Don't put multiple statements on a single line unless you have something to hide." This doesn't mention brackets, but that follows from other standards.
At least I'm not the only voice crying in the wilderness...
Subscribe to:
Posts (Atom)