robkeeney

So I have to develop on a *nix box through a Windows desktop PC. Plain terminal emulation is no fun (who wants to develop in vi?). Through the magic of open source, I don't have to and neither do you! Here are the simple steps to follow:

1. Install Cygwin including Cygwin/X — download the installer, make sure the xinit package is selected in the things to install, and hit go!
2. Install PuTTY and enable X forwarding in your session settings. PuTTY will automagically set your DISPLAY environment variable correctly.
3. Start your X server (Start -> Programs -> Cygwin/X -> XWin Server ) — you may want to copy this to your Startup group so it runs whenever you log in.
4. Use PuTTY to connect to your *nix box and fire up an X Windows program — remember to "amp it off".

Your X program should pop up on your desktop and look just like it's running locally — the beauty of X!

Code clarity results in performance gains.

Code "optimizations" result in bugs.

Knuth was right.

The upcoming C++ Standard is pretty exciting! Especially lambdas and initializer lists. What's *really* interesting is that they're not adopting a lot of the C99 standard, willingly breaking compatibility in a fairly big way.

Joel Spolsky, in a post on how to be a program manager writes:

Writing a functional specification is at the very heart of agile development, because it lets you iterate rapidly over many possible designs before you write code. Compared to code, a written spec is trivial to change. The very act of writing a specification forces you to think through the design you thought you had in your head, and helps you see the flaws in it quickly so that you can iterate and try more designs. Teams that use functional specifications have better designed products, because they had the opportunity to explore more possible solutions quickly. They also write code faster, because they have a clearer picture when they start of what’s going to be needed.

I can testify from extensive personal experience that this is the absolute truth. The process of determining WHAT your software must do will pay off a million times over. Once you have a well-defined specification, the design just becomes obvious, because once you have your well-defined specification you KNOW without a doubt WHAT you must do.

You start with a general, high level view of WHAT your project must do. Break that specification into its natural divisions. They should be fairly obvious. Then for each of those natural divisions, you break that into more specific statements by asking yourself "what must be done to achieve this?" This process highlights the natural architecture of your software and helps you to structure it properly. Your end product should be a list, broken into natural sections, of specific, testable statements of functionality. Each should state one and only one thing — a single truth. If you can easily convert each statement to a simple yes-or-no/true-or-false question, you've done well. This process will raise a lot of questions for any non-trivial project. These questions are the holes in your understanding, which if left unanswered will cause your project to fail and make your customers unhappy. Finding theses gaps in understanding and getting them filled is where requirements specification shines.

While you're doing requirements specification, above all else YOU MUST NOT THINK ABOUT HOW TO IMPLEMENT IT! When you're writing requirements, you don't care HOW it gets done, just so long as WHAT you want done happens. Specifying HOW hides information. When you specify HOW, you hide WHY you did it that way and you remove the flexibility to use a better method to achieve the WHAT. Worst of all, you might specify HOW to do it, and end up doing the totally wrong thing. If your requirements have variable or class names in them, specific data structures or algorithms, they specify HOW. Throw them out!

Once you have your requirements complete, you understand WHAT must be done and the implementation will become fairly obvious. If it doesn't, then maybe you haven't broken it down well enough. After you've implemented it, you'll know your software is complete and correct because you can go through the requirements list testing each statement, asking yourself "Is this true of my software?"

Dr. Dobbs says:
Fatal error: Out of memory (allocated 30932992) (tried to allocate 84 bytes) in /home/dobbscod/public_html/includes/database.php on line 502

No project has EVER failed for lack of a coding standard! Not one ever! Coding standards are what you do instead of something. They do nothing to resolve the problems with the structure of the code, but they allow incompetent programmers to feel as though they are successful and have written good code because they've "followed the standard". I've seen plenty of code that was incomprehensible and wrong but followed the standard to a T. I've never seen a standard (and I've seen plenty) that does anything to enforce locality of reference, maintain cohesion, or reduce coupling. I've seen a couple that said anything about function length. I've seen lots that go on at length about commenting the code. Why isn't it obvious what is happening in the code that you feel you need to add explanatory text? A bad programmer will fill his code with pointless drivel that's at best redundant and at worst wrong. The best use of comments that I've found was to identify the requirement from the requirements document which the code fulfilled.

Here's about all the coding standard you need:

• No routines that won't fit on a single screen, unless you have a very, very, very good reason.
• Use descriptive names for everything.
• Try to maintain consistency with code that you're modifying.
• Comment where necessary and only where necessary.

.

So you know how global variables are evil and should be never used? Yeah, well I've discovered something that's maybe worse, and I call them semi-global variables. They occur in nasty languages that allow nested functions, like Pascal. In the nasty language, a nested function has visibility to all of the variables and arguments of it's containing functions. Yeah. So you have no idea what the scope of these things is, and what sort of side affects they cause, and how far they ripple out. Nested functions are a bad, bad idea.

Today's xkcd makes a good case for why I guess I need a Kindle:


I'd have to get a nice big bath towel also.

When you dereference a dangling pointer you'll get a segmentation fault (or in Windows an "access violation") which causes a core dump.

you've ever tried to learn a language by reading the BNF.

I was reading up on function attributes recognized by gcc and the entry on declaring a function as using the fastcall calling convention made me reflect. When I was a boy, computers were mostly 8 bit. Then they went to primarily 16 bit operating systems by the time I was in high school, and when I graduated from college, they were mostly 32 bit. Now, while most mainstream computers still run a 32 bit OS, we're seeing the steady advent of 64 bit operating systems (I'm writing this on RHEL 5 for x86_64).

I wonder how long it will be before 128 bit computers are common.

From my readings on it, it seems to me that most problems that programmers have with multiple inheritance stem from improper object composition and a lack of understanding of HAS-A vs. IS-A. The biggest point I hear and read in regard to multiple inheritance is the Diamond Problem. Frankly, this is way overblown. One, it's just not that common to inherit from two classes with a common base class. If you're doing so, you probably shouldn't be. I've been writing C++ code since about `93, and I've never encountered the diamond problem. Two, if you actually do need to inherit from two classes with a common base class, it's really not that hard to understand and deal with it (cf. Multiple Inheritance for C++). That's why we're programmers, right?

In the Wikipedia entry for the Diamond Problem, the example given at the beginning is a perfect example of improper object composition, attempting to implement a HAS-A relationship via inheritance (an IS-A relationship), which is not at all correct. Their example is:

For example, in the context of GUI software development, a class Button may inherit from both classes Rectangle (for appearance) and Mouse (for mouse events), and classes Rectangle and Mouse both inherit from the Object class. Now if the equals method is called for a Button object and there is no such method in the Button class but there is an over-ridden equals method in both Rectangle and Mouse, which method should be eventually called?

Wow. That's just wrong all around. Class Button shouldn't inherit from Rectangle or Mouse, because it IS neither of those things! It may HAVE them, but it IS not either. Class Button HAS-A Shape member, allowing it to hold a button shape. Class Button HAS-A input event reference member allowing it to take generalized input events from it's proper event source — but then again, no, it probably shouldn't have that. It should probably implement the Observer pattern, and register itself as an observer for input events within it's shape. It should inherit from neither of these classes. This I think highlights the problem of viewing inheritance as the only way of composing objects. The Wikipedia entry for Virtual Inheritance has the same sort of problem in it's example, where they give a base class Animal, derive a class Mammal from that, and also derive a class WingedAnimal from Animal, then compose a class Bat by inheriting from class Mammal and class WingedAnimal. You say, "but a bat IS A mammal and it IS A winged animal" to which I reply "yes, but it IS A winged animal because it HAS wings!" The proper composition is to inherit from Mammal and include an instance of class Wings as a member. And POOF! the multiple inheritance conundrum vanishes! If you're trying to inherit from classes with a common base class, examine your assumptions about how your object should be composed.

So where is multiple inheritance useful? When you need your object to be two entirely different things, maybe a waitable database record, or a singleton database connection. You inherit from the singleton class and from a database connection class and there you go, there's nothing more to do to make your database connection class a singleton. Interfaces try to give you this sort of thing, but you don't get to inherit the implementation. You have to re-implement everything yourself, throwing away the whole idea of inheritance and reuse.

... those who know binary, and those who don't, but I've come to find there are actually 11 types. Those who get the joke and think it's funny, those who get the joke but don't think it's funny, and those who don't get the joke.

What really happened to the rocket X-Wing fighter!

While I didn't install it, Ubuntu did help me diagnose the problem. After fighting with Windows all weekend, I stuck in an Ubuntu live CD to see if it would boot. I figured if I had a corrupted hard drive, the CD would be fine and help me figure that out. But I started by running the memory test. It was very informative. Almost every test failed with bad bits in the low word. What that told me was that the memory bus lines were flaky in those bits. What did that indicate? Re-seat the memory card. Yup, the solution to 90% of computer problems back in the `80s and early `90s. I can't tell you how many times I reseated a modem or video card in my 386 when things got flaky.

I went ahead and tried to boot into Ubuntu, but it wouldn't go. Meredith then tried using Windows and it Blue Screened. So I popped open the case, pulled the memory card out, re-seated it, closed it back up, and booted it up. No problems since.

If Windows had a real memory test, that would have been a great help, but I am unaware of it having one and the BIOS POST memory check is about useless.

Heisenberg used to house sit for Schroedinger, and would get annoyed when his buddy would call home from out of town and ask "Where is my cat? And how fast is it going?"

Two hydrogen atoms are walking down the street. Suddenly, one stops! "Holy bleep!, I've lost an electron!" says the first one. "Are you sure?" asks the other atom. "Yes! I'm positive!"

Heisenberg got pulled over by a highway patrolman. "Do you know how fast you were going?" "No, but I know where I am."

Author of Linux Patent Study Says Ballmer Got It Wrong:

The market needs to understand that the study Microsoft is citing actually proves the opposite of what they claim it does.

Best quote from the article:

Both Novell and IBM have publicly promised to use their extensive patent portfolios to protect Linux customers.

Following patrick___'s Eigenvector math revisited post, plus a problem report delivered this morning in haiku form, I felt inspired.

eigenvalue or
differential equation
the deep math is fun

A famous piece of geek poetry.

...but these are the things I think about.
( So, garbage collection. )