Email Etiquette

A while back I was talking about email etiquette. Here is a good resource, EmailReplies.com

I particularly like, 11. Don't leave out the message thread. Finally someone admits that top posting is a good thing.

Top Posting

The arguments against email top posting have never swayed me.

 Wikipedia tells me top posting on newsgroups is bad and I believe them. I don't use newsgroups so I don't know about that posting style. I can see the point since both news readers and web interfaces (Google Groups) group the threads together by default. I assume the feature works pretty good in those cases.

There is an RFC saying "When replying to a message, include enough original material to be understood but no more. It is extremely bad form to simply reply to a message by including all the previous message: edit out all the irrelevant material." Seems the problem top posting is trying to solve is "that top-posters often word their replies on the assumption that you just read the previous message, even though their perversity has put it further down the page than you have yet read". For email this seems like a valid assumption to make. And, like Raymond Chen points out if you add people to a thread you had better tell them why and what you want them to do. Corollary, "don't forget to ask your question." So really people need to learn to communicate better?

Email clients top post by default. Inboxes are sorted in chronological order. GMail is awesome and groups conversations and hides the redundant parts. Grouping seems to work as long as the subject and/or some magical included ID doesn't get removed. But we all know cases that client grouping fails. Worse yet, someone(we know who you are) wants to email you so they reply to any old email lying around with your name on it.

Every professional I have ever seen top posts. They seem to like having the entire email should I want to see it or forward the entire thread to some one. And don't get me wrong, quoting relevant portions in a top post, or inline responses are still good practices. This person, although not a fan, points out the benefits of Top Posting in a business setting. (See When Does Top Posting Make Sense?)

Since I spend most of my time in a business setting where top posting helps so I will keep going. We stopped being worried about the number of bits being transmitted and stored 10 years ago. Top posting can't be that confusing and at least in business the benefits outweigh the negligible costs.
7/10/08 Edit
EmailReplies.com agrees with me too.

Clipboard Problems

On Windows if your clipboard stops working it may be one of the following:

• Remote Desktop (see Summary for a trouble shooting guide)
• Virtual PC

As pointed out by Raymond Chen

Programming Pointers

I need to read up on C/C++ linkage and I came across embedded.com series called Programming Pointers by Dan Saks. Well written with examples and summary tables. I will be reviewing more of his work if/when the need arises.

Of interest to me were the following:
Linkage in C and C++
Storage class specifiers and storage duration

Over Constrained

My last post I mentioned I need a wiki.  I used WikiMatrix to evaluate a few solutions and none of them jumped out at me.  I realized my best bet is probably just to signup for a hosting service.  Jaimi likes BlueHost and they have Tikiwiki and Wordpress.  I could have everything in one place.

Then I over constrained the problem.  If I am going to get a hosting service I need a domain.  What should the domain be?  I have no idea, I have been toying with that idea for two years and I can't converge.  I tried NameBoy to get suggestions, and read the BLADAM post saying I should use a made up word that isn't too long, easy to spell, and doesn't sound like other words.  That just over constrained my over constrained problem.

I am not going to settle for scottherriman.com (17 characters) because unless you are an artist, using your full name is lame (sorry if yours is).  Herriman.com is taken.  I think I want the domain to be professional software related.  I am open to suggestions, you have any?

Wait, I need a Wiki

I decided that I would start writing a blog for two reasons. As an outlet for the thoughts on the project that I am working on and to capture details relating to problems that I come across or solve.

After leaving CallWave in September one of the many things that I miss is discussing software with people.  My team listened to me pontificate on software design, implementation and the engineering process.  That may not have been too much fun for them, but it was a good outlet for me.  Otherwise we went out to lunch and batted around the same topics asking questions and sharing.

Most people at CallWave, myself included, use(d) email to store all sorts of information not documented anywhere else.  After a few years it was obvious to me that this was a bad idea.  Email is tough to search, gets lots, "the guy" that always forwarded "those details" might leave the company.  I found that it was much better to dump those emails into a web page.  CallWave had MS Sharepoint for this purpose.  Not a lot of bells and whistles, but it did the job.  Things could be arranged hierarchically, edited, hyperlinks inserted etc.

For the Client team usage, we might just copy and paste an email into a page with no reformatting, just to capture the information.  I had a page for new team members.  Each time I sent the link to some one new I reviewed the page and added/edited a few details.  After a time I had a rather robust "new users guide".  That was the pain free way to have a living document.

I realized the stuff that I am likely to blog about, "hey look at me I figured something out", is the least likely to be read.  Just recently I wrote an entry about a problem I solved.  The information is useful, I am likely going to want to refer to it later, but the article sucks.  Not because the information is bad, just nobody is going to (or should) care.  Besides, blogs are good for capturing current ideas in chronological order.  They aren't meant to be a repository for information.  Searching them is a pain, sure there are tags and Google Site Search.  Still, if you can't recall exactly what you are looking for it stinks.

So, in the end it turns out I need a blog and a wiki.  The wiki should house those technical details that I want to find later.  The wiki is just for me, but none of the information is secret.  I may as well stick it out there.  If other people do find the knowledge useful they will appreciate that it is not buried in a blog.

Now I am in the process of selecting a hosted Wiki solution.  I asked a few friends and they mostly suggested Wiki software.  I need a service since I don't have any desire to be administrating servers.  Any suggestions?

Create A Library For Someone Else

A coworker commented that a customer was "Using code in a way I never imagined ... that will teach me to write better code." He is right.

Everyone should write code for some one else. The back and forth of hammering out interfaces is just a part of it. The real learning comes from the other person doing things you never thought they would. When the complaints and bugs come back you get the chance to figure out where you went wrong.

Here are my favorites from C++ Win32 programming:

• Misusing or not using an interface because they "didn't understand it"? "Then why didn't you ask", you mutter.
• Passing the wrong parameters, but somehow it "just works but I don't know how", they quip.
• Threading/Concurrency. This is the biggy. You probably never expected that object to be used on a different thread did you? Whose job was it to make this object safe, yours or mine?
• Blocking, a corollary to the above. Your method call blocks, but the caller doesn't want it to. They almost never do.

The point here isn't to point out all of the ways people can get confused by interfaces. When you create an interface for some one else you get in the habit of considering all of these things. After the third (or is it 10th) time you add a blocking API and some one complains you will get the hint. Finally you will consider that the caller probably doesn't want to put up with that. If everyone says your interfaces are confusing, you might want to consider what you can do differently, rather than convincing them that there is nothing wrong.

Your code becomes more useful because it is easier to use. It solves more people’s problems and they look forward to using it.

In the end you become a better programmer. You find even the interface that you create just for you are more useful. "Cool, I can use that same widget X in program Y without any changes." That is when you know you have got it right.

So, all I am asking is spend 5 minutes during the design and think, "How could someone else abuse this?" It will make for a better design. Besides, who knows, you might be the one that wants to "abuse" the interface later on. Let's make sure you don't have to.

Scrolling Windows

At GIPS, we have our own CWnd derived scroll bar. It is just a "regular old" window with the customary parts of a scroll bar. Up, Down buttons, track and thumb. You attach a window to a scroll bar (not vice versa as you would expect) and it forwards scrolling events to the attached window.

The problem is that scrolling performance is terrible when dragging the thumb
quickly. When you do so each WM_MOUSEMOVE message might span many (10's) pixels
equating to several (2 or more) scroll bar position changes. Root cause of poor
scrolling performance is we process each position change individually. For example if scrolling up we do the following.

    for ( UINT i = lastScrollPos; i > newPosition; i-- )
    {
        attachedWindow->SendMessage(
            message,
            MAKEWPARAM(SB_LINEUP,0),
            NULL );
    }

In my case the loop above was running 2-14 times. The solution was to change SB_LINEDOWN to SB_THUMBTRACK and remove the loop.

    m_slaveWindow->SendMessage(
        message,
        MAKEWPARAM( SB_THUMBTRACK, newPosition ),
        NULL );

I was still left with an additional problem. List-View doesn't seem to like to get SB_THUMBTRACK directly as noted on CodeGuru:

List control will call GetScrolInfo function to get the current scroll box tracking position, so it is necessary to set the tracking position before sending WM_HSCROLL/WM_VSCROLL(TH_THUMBTRACK) message to it.
Unfortunately, SetScrollInfo function does not work when using

Note that ListCtrl really likes to get scroll notification via LVM_SCROLL. However, the general purpose scroll bar doesn't want to track that level of details. SPY++ revealed that List-View sends a WM_SYSCOMMAND / SC_VSCROLL followed by WM_VSCROLL / TH_THUMBTACK. I tried to send WM_SYSCOMMAND / SC_VSCROLL to no avail.

To resolve the List-View issue I changed the scroll bar to take a boolean indicating if we should use line by line scrolling. So windows, that require line by line scrolling can get the original unoptimized version. By default others get the optimized version.

Related Links:
CListCtrl Scroll Messages
How to skin CListCtrl incuding scrollbars and column headers

Who Cares About Open Document Format?

I don't care about open document format.

Joel on Software has an article about the Microsoft publishing the file format for there office formats. He goes on to describe why they are so complicated, taking 300+ pages to document.

The complexity Joel describes and the ability to accurately reproduce the format quirks is why I don't care about document formats. I don't care how open the document format is, there are many more parts to the equation:

1. It has to be stored on media that your current computer can read. I am really enjoying copying the 100 floppies I have using the last remaining floppy drive in the house.
2. You have to have software your current computer can run to be able to view the document.
3. Moreover, that software has to be able to export it into something you can use.

Number 1 is a fairly obvious problem. The crux is 2 & 3. Just because the document format is open doesn't mean that 2 & 3 will be satisfied. Unless there is monetary incentive you probably aren't going to go about creating your own software to read your high school English papers. I do agree that open document formats make it more likely you can do what you want today and in the future. However, they aren't the magic bullet to always being able to use your content.

Today people tend to demand software that interoperates well. Because of this most programs can save in a variety of formats, proprietary and non. This allows you the most flexibility.

If you are really worried about your data and documents I suggest you worry about the big picture:

1. Use best practices for backup. Redundant, geographically diverse.
2. Save on media that can be read by most computers.
3. Save in several formats.
4. Save the reading/writing software with the documents.
5. Repeat steps 1-3 every few years as technology evolves, before you can't access the old data.

I hope the better way to solve the problem is through Virtualization. Save your documents and applications in a complete virtualized environment. Then make sure you can run that on the next generation of systems. This is what many in the Apple II (you remember from elementary scool, with the green triangle Logo "turtle") have been doing for years. Be careful with the DRM content, who knows if you will be able to access that a year from now.

My final suggestion is to let it go. Don't even waste your time trying to save a bunch of content you are never going to look at again. If you can't open the file you probably don't really need the content. Leave the time capsule of great works to the professionals. Your work and mine probably isn't going to be included.