How Pentapedes See Themselves...

A Pentapede-inspired drawing from a Macaroni Grill doodle session. Enjoy!

Watch your booleans!

Here's a simple reminder that, whether you're coding or doing a code review (and you ARE doing code reviews, right?), double check your booleans.

private void EnableDisableFancySchmancyControl(bool enable)
{
    _fancySchmancyControl.ReadOnly = enable;
}

We have a piece of code like this in the software I work on daily. This tiny little piece of code, so minuscule, so obviously correct, caused an emergency promotion the day its bug was found because it didn't allow some users to do their work properly.

Why, you ask, do we have such a simple method? Wouldn't it do to just call

_fancySchmancyControl.ReadOnly = enable;

in the calling method? Yes, normally it would. The objective of this piece of code is to normalize the action with the question "Should I allow the user to edit the information in this control?", so that you don't end up with things like:

private void EnableEditing()
{
    _control1.Enabled = true;
    _control2.Readonly = false;
    _control3.Enabled = true;
}

but instead have:

private void EnableEditing()
{
    EnableDisableControl1(true);
    EnableDisableControl2(true);
    EnableDisableControl3(true);
}

Now, the error from our original snippet should be obvious when you're looking for it: the line should be

_fancySchmancyControl.ReadOnly = !enable;

That is, there should be a not (!) in front of enable; a control that is read-only is not editable by the user (which, remember, is our objective).

All of that to say: be extra careful with your booleans; even the simplest code can fall prey to this bug!

Partial Random Song about Data Conversions

(I'm gonna) Scrub that Data!

I'm gonna scrub that data 'til it's shiny and clean!
I'm gonna scrub that data 'til it says what it means!
It'll be so shiny when I give it to you;
But I know you'll mess it up in a day or two!

(That's how data is, baby. If it ain't messed up, it ain't bein' useful)

Concertmaster Auditions - Denver Pops Orchestra

The Denver Pops Orchestra will be holding auditions for Concertmaster for the 2009-2010 season at 7pm on June 3, 2009, at Emmaus Lutheran, 3120 Irving St, Denver, CO 80211. Contact Zina Richardson, Music Director, at 303-530-7633 for further information and to RSVP. This is a paid position.


View Larger Map

Livetweeting THX 1138

• Watching THX 1138: "It's in technicolor. And the color is yellow." "Wait. Now it's blue." "Maybe they could only afford one at a time."


• "That's not good. I think their yellow camera just exploded." EXPLOSION IN RED SECTOR "Oh, it was the red one"


• "Apparently they also couldn't afford skin for the extras"


• The church confessional, automated: "forgive me, for I..." "Please insert plenary indulgence token"


• "He's got a 12-sided die! He's a witch!"


• "Look, commentary on the 21st century" "yeah, little did he know he was making a documentary"


• "Look, it's just like Parker. The only black people you see are on TV"


• "I think I'm dying" "could you be more specific?" "Well, I'm coughing up blood and my heart just stopped."


• "Blessings of the state" "worst plenary indulgence token ever"


• "Apparently they couldn't afford brains for the extras either"


• We could be gone before the next series started. "Thank goodness. Most of the audience will be by then, too"


• "If I have nowhere to go, why are you picking me up?"


• "Dammit, they put the cards into the probulator in the wrong order. Now it's playing chess."


• "Oh, they're teaching him kung fu. *Drunken* kung fu"


• "The nice thing about the white camera is that it removes the walls." ... "What the heck, does it also remove their clothing?"


• "I think he's dead now." "Well, they'd better bring in another subjecte"


• Here, take a biscuit. "What would he want a biscuit for?" "He's all out of business cards."


• "What's with the inifinite featureless white plain?" "They ran out of money for sets"


• "So, basically, this is The Matrix, only more boring. And more kung fu."


• "I wonder if they're going to stop chasing him when they go over budget? You know, like they did with the writers for this movie"


• Stand down. We are here to help you. "You have exceeded the plot budget and are in violation"


• "I think he's trying to get to 88 MPH. That way he can go back in time and prevent this film from being made."


• So, to review, this movie had no plot, no character development or really characterization, no scenery and camera issues. 1.5 hours GONE!


• Just when you thought it couldn't get any more boring... a sound effects only track. Not that the dialogue added much anyway.

Twikus 1 & 2

Violist
----
Safely nestled in
the sweet harmonic bosom
of the orchestra.

(no title)
----
Knocking things over,
Galumphing through the condo.
Kitty is naughty!

R'thoria's Used Plot Elements: Disney Edition (Vol. 2, Ep. 002)

Ladies and Gentlemen, boys and girls, welcome to the special Disney edition of RUPE*! Citing financial difficulties, Disney recently announced a number of layoffs and general cutbacks, and has begun to sell off their back stock of plot elements to independent retailers, such as yours very truly, and which are now available directly to YOU at discount prices!

[* Definitely NOT G-Rated whenever we can avoid it!]

So, without further ado, let me introduce the best of the stock, everyone's favorite story: Sleeping Baby! Enjoy this touching, four-hour, continuous-shot adventure that critics have called the most nap-tacular event of the century!

Next, we have the cinematic masterpiece based on an ancient French fairy tale that dazzled audiences when it was first released. Integrating computer-generated graphics with Disney's classic hand-drawn style, Beauty and the Beet tells the touching story of a young woman who discovers that external appearances can be deceiving, and that a person's roots are more important.

Lilo and Stick was the last of the hand-animated films to come from Disney Studios. Set in the beautiful Hawaiian Islands and rendered in luscious watercolors, this refreshing tale shows how a young girl, and her best friend, can make a family in the face of difficulty.

Choose from these and many others, including The Cryin' King, The Emperor's New Boob and that fascinating medical documentary, The Sore and The Stone!

So remember: for ACTION, ADVENTURE, luscious watercolors and gratuitous boob jokes, visit us at RUPE, where our prices can't be matched!

Lest you should forget the beauty of the Universe

Difference in POV between Centralized VCS and Distributed VCS

'However, the total cost of branching is paid by reduced code velocity to main, merge conflicts and additional testing can be expensive. Throughout this guidance we ask the user to confirm that a branch is really needed and always ask the question "how does this branch support my development project?"'
-- from the TFS branching guide.

I came across this interesting passage yesterday, and I was struck by the profound difference in point of view between centralized version control and distributed version control.

In distributed version control systems (dvcs), branching is fundamental (in most scenarios): every "checkout" is really a branch of the repository, with full history. Therefore the focus in developing dvcs has been on making branching and merging as simple, quick and painless as possible.

Now, arguably, branching is also fundamental to all version control; after all, when you check out a copy of the code and modify it, you make a kind of lightweight, local branch for your changes that is quickly merged back into the trunk. But, with centralized version control, the focus is on control of the codebase, which is concentrated in the trunk. So, not only is branching not optimized (because of the lack of focus), but it is indirectly made more costly by the controls put on the trunk. And, because local checkouts aren't recognized as 'branches', you lack most of the usual tools for managing them separately from the trunk/server, like full history and an easy way to exchange patches with another developer.

Now, this isn't to say that the above advice isn't germane (PSP: take a shot!). If you are using a centralized version control tool, then you should absolutely consider the costs associated with branching, because it is quite expensive. And, arguably, you could go crazy with dvcs as well, but it takes a lot more work, I think. But the elaborate systems that the aforementioned branching guide mentions for scenarios just seem baroque and unnecessary when considered from the context of a dvcs.

"Poetry"

I once knew a young man of Ire
Whose toves, quite slithy, would gyre.
But of gimble they'd none;
Said he, "It's no fun!
And it's manxome how quickly they tire!"

Better diff/merge

Wouldn't it be nice if your VCS/SCM understood the code that was checked in, so that it could show diffs that were correctly contained?

For example, I modify a method and delete the method right after it. It shouldn't show that as a single change, but as two (one change for the modify, one for the delete). Or if I move a method in the source file but leave it otherwise unchanged (or even change it!): it shows as a 'move' (and potentially, then, a change as well!).

Some of this could be done without understanding the code much, eg, looking for identical blocks of text between the new and old files, which constitute 'moves'.

And it wouldn't have to happen when sending changes to the server, just when comparing the two versions for human consumption.

More googol fun

Earlier today I posted on twitter that you would need only 333 bits to store the value 10^100 (one googol), which is really just saying that there are about a googol states that 333 bits can be in (actually there are quite a few more ways, but to a rough order of magnitude it's accurate).

That, of course, got me wondering how many bits it would take to represent a googolplex, or 10^googol = 10^10^100. Actually, in my enthusiasm I asked my computer to display a googolplex, since it had so readily displayed a googol (which, written out, is really just 101 characters). But I realized my folly and quickly aborted that request.

But I was still wondering how many bits it would take. It turns out there's actually a straightforward way to solve this problem:

Let's start with the derivation for the number of bits needed to store the value googol.

x = 10^100 = 2^a , where a will represent the needed number of bits

log_10(x) = log_10(10^100) = 100 = log_10(2^a)

How to get the 'a' out? By remembering that log_w(s^t) = t * log_w(s); that log_w(w) = 1, and that we can convert bases as follows:

log_g(p) = log_h(p)/log_h(g)

Therefore,

100 = a * log_10(2)

100/log_10(2) = a * log_10(2)/log_10(2) = a * 1 = a

and so 'a' is ~332.1928 which we'll round UP (since we have to work in whole bits) to 333.

FINE AND DANDY SAYS I :-)

But what about our friend the googolplex?

We can use the same derivation as above, but substitute 100 for 10^100, so that we find

10^100 / log_10(2) = a

or, about 3.32 * 10^100 bits. That's right, we'd need 3 googol bits to store a googolplex. And there aren't that many bits. In the whole universe.

Now, of course, if we used something with more states, then we could represent a googolplex in fewer of whatever we're using; for example, with a three-state object would only need 2 googol of them; with a 60-state object, only 5.6 * 10^99, or about half a googol. Unfortunately, things don't improve very quickly due to that log_10. With a million-state object (10^6), we're only at 1/6 googol, which is still WAY WAY too many.

Anyway, there's not really a point to this rambling, I just think that really large numbers are cool.