Mike’s Dump

May 27, 2005

Thieves are everywhere!

Filed under: Home — mikesdump @ 1:15 pm

I guess Isabelle thought better safe than sorry when she locked her new “princess” scooter to our banister

Isabelle locks scooter


May 26, 2005

Trip to Vancouver

Filed under: Home — mikesdump @ 3:19 am

We got back from Vancouver last night (actually Surrey) and it was a
pretty uneventful trip, which was nice. My brain has been telling me
for a while “be one with the vegetables” and that was the plan.

We left Friday morning at 4:15 am (hoping that the kids would sleep
more) from our house in Edmonton and arrived at my mom’s house in
Surrey at 4:32 pm. We followed our regular routine of only two stops;
get breakfast at McDonalds in Jasper and lunch at the Husky in
Kamloops. The kids did really well on the way there. Erika had a
tough time sitting just before we got to Kamloops and Surrey. We had to
let the kids get out in Kamloops to run around for a bit so they would
make it through the last leg.

I made the trip a little longer than I needed on the way there because
I didn’t look at the map very carefully. My mom lives just off of 152nd
street so I thought we’d get off of highway 1 at 152nd street. Well…
there is no exiting from highway 1 onto 152nd street. My first clue
should have been when I saw the sign “last exit to Surrey, 160 street”.
Oh well, we crossed the river made a u-turn and we were back on track.

If I was to pick a highlight while we were at my mom’s was probably
trying Grandville Island beer (I think that was the brand name). We
picked up a 12 pack with four different flavors, pretty good stuff.
Other than that we sat around visiting with family, ate, and I played a
little bit of game cube with my younger brother. I only logged into my
email once a day to delete all the viagra and Russian spam. The plan to
become one with the vegetables was all coming together nicely. Probably
the one exception to the vegetable plan was that I did manage to finish
reading Peopleware. Overall I thought it was a good book but I’ll save
the details for another post.

The trip home was a little more painful. Everyone was tired and we left
a lot later (9:00 am). Before we got to Kamloops Erika was looking kind
of pale and Isabelle said she felt like she was going to throw up.
Isabelle was ok but as soon as Sandy pulled Erika out of the van she
puked three times in the A&W parking lot. We got some more greasy
food into the kids along with some gravel and got back on the road. I
didn’t know it at the time but a nice side effect of gravel is
drowsiness. It knocked both kids out for a couple of hours.

We had a couple close calls with some animals. We had to stop to let
four mountain goats cross the road and a deer just about jumped in
front of us. Another bit of excitement was having a car driving the
opposite direction (at highway speeds) in our shoulder. They were
trying to pass a semi (based on the lines on the road they shouldn’t
have been passing there) but couldn’t do it. There were two vehicles
behind me as well. That was fun! There was also one time when there was
a convoy of about five big trucks going 70 km/h in a 90 zone. I tried
to pass them all but had to squeeze in between the first and second
because of an on coming vehicle. Slowing down from 120 km/h to 70 km/h
in between big trucks� more fun.

So, I have a few more days before I have to go back to work. The goal
is still to be a vegetable but I’ll have to see how that works out.

Erika in Orange
Isabelle sleeping in van

Google-fu and Book Reviews

Filed under: Links — mikesdump @ 2:57 am

“Shortcuts” for google over at Coding Horror

Joel Spolsky Book Reviews

May 19, 2005

Code Commenting Post

Filed under: Code — mikesdump @ 1:39 pm

I read this post tonight on comments in code. This article pretty much sums up my feelings on commenting code. Here are a couple of highlights:

In general, if a comment already describes what the code does, then the comment is redundant and should be removed. Otherwise, you risk creating a misleading comment, which is worse than no comment at all. As recommended in The Pragmatic Programmer (Addison-Wesley, 2000), strive to keep each piece of knowledge in one piece, as prescribed by the DRY (Don’t Repeat Yourself) principle:

Every piece of knowledge must have a single, unambiguous, and authoritative representation within a system.

Before writing a comment, try to make the code easy to understand so that you need fewer comments. Simple, safe refactorings such as renaming classes, methods, and variables, and extracting well-named methods go a long way toward removing duplication. Then, when all else fails, please leave us a good comment.

May 18, 2005

May 18th Links

Filed under: Links — mikesdump @ 2:29 pm

This looks good for VB.NET coding standards. Need to read through this.

Rands in Response is always good but “Don’t be a p-r-i-c-k” is a keeper.

define: Team

Filed under: Work — mikesdump @ 10:32 am

google define: Team

A team comprises any group of people
or animals linked in a common purpose. A group in itself does not
necessarily constitute a team.

I work with an excellent team of developers. But when I include Sales I
would classify this as a group. As a development team we have been
working to try and put on paper our vision/mission but I believe we
already share a common purpose. Some goals that the development team
shares: desire to develop high quality software, continuous self/team
improvement, and strive to provide excellent customer service to name a

Sales on the other hand have very different goals in my opinion. Their
task, a very difficult one, is to continue to find new customers in
order to keep the business going. I have been in commission sales and I
know the pain that if you don’t sell you don’t get paid. Perhaps there
are quotas that need to be met in order to keep your job. Even if sales
aren’t on commission it is in every business plan to continue to grow
and that challenge normally falls to the sales team.

If the sales team sells just what you have I think the two groups can
co-exist. But when new functionality is constantly sold with delivery
dates given before the development team gets a chance to review the
requirements there is no team. I have never heard from any developer,
anywhere, how great the sales team was. How they set realistic customer
expectations right from the start. An us versus them mentality
unfortunately is far too common.

Now it can easily be argued that my goals/mission are misaligned with
sales or perhaps even the company. Some days, after a self-evaluation,
I would even agree with that. But if all that was ever asked of
developers is to crank out code that was just good enough for today,
with no concern for maintainability or how the rest of the system would
be impacted, developers that care would be become frustrated. They
wouldn’t be able to improve their skills and ultimately would end up
providing poor customer service because these types of solutions are
generally pretty fragile. For the developers this pain would be
temporary because they would move on. In the long run the company would

So what is the happy ending? I think the only way for sales and
developers to become a team is to have a better understanding of each
other and have a common vision and mission. The vision will provide the
dream. It says this is where we want to go together. The mission
defines how we get there. It should define what should and shouldn’t be
done by both sides. It isn’t enough to produce a document that gets
hung on the wall, it has to be lived everyday and become part of the
culture. Sounds pretty simple don’t you think 🙂

May 16, 2005

Code Review Posting

Filed under: Links — mikesdump @ 11:28 am

Regular code reviews is something I’d like the team to get into. This
was an interesting posting on how the MSBuild team has implemented code
reviews. This process is close to the way we did them at net-linx.


May 14, 2005

When no does not mean no

Filed under: Home — mikesdump @ 7:21 am

Erika is just under two years old and her vocabulary is increasing on a
daily basis but for some reason she doesn’t like to use the word “yes”.
Any yes/no question I ask her she responds with no but she says it
differently. I started to think about the different ways she says no
and I think I finally figured it out.

Short No This is usually mean no. “No, stop trying to put food in my mouth”
Long No with whine This whiny no is like Isabelle’s no
when she doesn’t want to go to bed. With Erika this usually means “Yes,
why don’t you know that already”
Long No and run away This again is back to no but there can be an exception to this. “No, I don’t want my diaper changed”
Long No, run but check if I’m following Another
yes. She seems to do this when I ask if she wants a bottle. As she is
running away saying no she will make sure that I’m behind her actually
getting a bottle.

Programming is nothing compared to this stuff.

An interesting post on Scrum

Filed under: Links — mikesdump @ 2:02 am

What probably stood out the most to me in this posting was the “scrum
values”. The daily scrum sounds a lot like our daily standup meetings.
The team meeting to determine what would be completed in the next
sprint also sounds like a great idea. If our team wasn’t spread so thin
on so many different projects I would love to be able to try this
out… Maybe one day.


May 11, 2005

Error Handling

Filed under: Links — mikesdump @ 8:51 am

A developer at work posted a couple interesting threads on error codes vs. exception handling today.


Here is my take:

Handling errors is hard and takes discipline
matter what your approach to error handling is it is probably one of
the most difficult things to deal with when writing code (at least it
is for me). There are going to be some situations that are so serious
that there is no point in continuing the application so shutting down
is the best solution (network failure in a client /server application).
It is the errors that aren’t that serious or can possibly be recovered
from that are more challenging to handle. I believe handling these
situations well are one of the differences between an application that
is user friendly and one that is not. Based on past experience it is
these kinds of exceptions I see that are left with “todo” comments or
the exception is logged and the application continues as if nothing

What’s wrong with error codes?
biggest problem with error codes is checking them. I worked on a
project that it was part of the coding standards that every method had
a Boolean return value. Every time a method was called the return value
had to be checked. I think this was a bad standard but that is another
story. What ended up happening is people stopped checking the return
values. Why this happened I don’t know for sure but it was probably
related to time pressures and handling an error condition properly took
more thought and time.

What’s wrong with exception handling?
biggest problem I have with exception handling in .NET is if the
developer doesn’t know what exceptions are being thrown by a method
what typically happens is System.Exception is caught or exceptions
aren’t caught at all. Of course catching no exception at all isn’t a
good idea but if System.Exception is being caught the user probably
isn’t getting a specific error message that might help them resolve
their current issue (aka not so user friendly).

Java approach
not trying to start a language debate but one thing I really wished
that Microsoft had copied from Java was enforcing catching of
exceptions. Using Java with a good IDE the developer doesn’t have to
worry about looking up the specific exception that a method might
throw. Or you can use notepad and the command line and get good result
as well. This doesn’t make it is any easier to deal with an exception
once you have it but I think it is a step in the right direction.

Sample class
import java.io.*;
public class test
public void writeList()
PrintWriter out = new PrintWriter(new FileWriter(“OutFile.txt”));

Command line output
C:\>javac test.java
test.java:7: unreported exception java.io.IOException; must be caught or declared to be thrown

new FileWriter(“OutFile.txt”));


1 error

In my opinion there are issues with both approaches, if there wasn’t it wouldn’t be debated or would it?
If I were to pick one side of the fence I would go with exception
handling. Dealing with and exception class opposed to an error code
constant makes more sense to me. I think the industry has moved (if not
is moving) toward exception handling so instead of debating if error
codes are better we’d be better trying to figure out how to make
exception handling better.

Next Page »

Create a free website or blog at WordPress.com.