Amazon.com Widgets Nick Hodges | A man's got to know his limitations

Flotsam and Jetsam #43

By Nick at September 12, 2011 17:15
Filed Under: Flotsam and Jetsam, Delphi
  • Is your currency the Euro?  Well, now you can buy your RAD Studio from the inestimable and indefatigable Dr. Bob.  Bob has expanded his reach of dedication to the product and the customer to the entire Eurozone.
  • You guys know that I don’t think that Simon Stuart is really human.  Instead, I think he is some kind of android, sent here from the future to code something (in Delphi) that we need to save the world, and he's just biding his time writing things for us in the Delphi community.   Simon has produced a prodigious amount of cool stuff for us Delphi developers, and is a tireless community member.   It doesn’t seem like too much to ask to help him release Lua4Delphi before Christmas.  I made a modest donation.
  • We homeschool our kids, and my wife came to me showing me the stuff for the starting school year.  It presented an interesting choice:  All things being equal, should our kids spend their time learning to write cursive, or to touch type?  I voted for touch typing.  It occurred to me that I can’t remember the last time I wrote anything more than a note on a ToDo list. I almost never write letters or anything involving using a pen or a pencil for extended periods.  And even when I do, I don’t write in cursive.  But I’ll tell you what – I type A LOT.  (I’m doing it right now!)  Anyway, I guess we’ll have to put cursive writing up there with reading the newspaper.  I mean who does that anymore?  Winking smile I realize that we could do both, but that would mean giving up something else, and I see the two as similar enough that we should choose between the two. 
  • The TIOBE Index is out for September, and Delphi comes in a #13 with three down arrows.  Interestingly, though, if you put "Delphi" and "Pascal" together, they are in the Top 10.
  • Embarrassed that I Didn’t Know it was There Class of the Week: TAggregatedObject – very cool little class

Limiting Scope

By Nick at September 10, 2011 01:02
Filed Under: Software Development, Delphi

As a general rule, developers should limit the scope of variables as much as possible.   Keeping the notion of limiting scope in every way possible, from the big things (never, ever, ever use global variables)to the subtle little things a language can do (declare const parameters whenever possible) all can contribute to clean, easy to test code. 

Limiting scope has all kind of benefits.  First, limiting scope of a variable reduces the number of places that a given variable can be modified.  The reason we rightfully abhor global variables is there is no telling where or when a given variable might be changed.  A global variable hangs out there like that last donut in the break room.  You know you shouldn’t touch it, but oh my, it’s so tempting, and it’s so easy to just grab that variable and use it for whatever you need to do.  Limiting the scope of a changeable thing reduces the chances that it will be changed in a way that it shouldn’t be, or worse – in a way that you don’t even know about. 

Limiting scope is also, by definition, a main feature of object oriented programming.  Encapsulation is probably the first thing you thing of when you thing of OOP, and it’s basic purpose – it’s whole reason for existing, really – is to formalize the process of limiting scope.  They don’t call it “information hiding” for nothing.    The term “information hiding” really means “Hide the scope of your variables so much that they can’t be changed except in the exact way you let them be”.  Encapsulation enables you to ensure that data you don’t want exposed isn’t exposed.  And if it isn’t exposed, it can’t be changed.

Limiting scope also limits the ability for people to depend on code that they shouldn’t be depending on.  Loose coupling – the limiting of the dependencies with in a system – is a good thing.  Tight coupling is a bad thing.  Limiting scope makes it harder for one class to latch on to another class and create dependencies that make code hard to test and hard to maintain.  It also makes it harder for changes in one area of code to have secondary effects in other, coupled areas.  There is nothing worse than changing code in (metaphorically speaking) New York City, and having that change cause a bug in code all the way over in Los Angeles.  (This is commonly called “Action at a Distance” and is something that should be avoided like a bad burrito.)  

There are big, well known ways of limiting scope – objects, making a variable local to a method, etc. – but there are a lot of smaller, more subtle ways to limit scope as well.  I’ve tried to list a number of ways that you can limit scope in your Delphi code:

  1. No global variables.  None.  Zero.  -- This one isn’t so subtle, but it’s really, really important.  It’s really easy to make sure that you never ever declare a variable as global.  In Delphi, you can do it, but you never should.  In languages like C# and Java, you actually can’t, strictly speaking, declare a global variable – everything has to be in a class -- but you can create a field on your main class that is pretty much the same thing.  Delphi is more flexible and will let you declare a global variable.  But just because you can doesn’t mean you should.  So don’t.
  2. Don’t create anything. Instead, ask for what you need.  This topic is a big one unto itself and gets into the question of dependencies and dependency injection.   But if you try to never actually create anything in the constructor of your class and instead, pass the constructor existing instances of what it needs, you can limit the scope of a given class.  Better yet, if you use a full blown dependency injection container, you can very severely limit the scope of your classes and still benefit fully from their functionality. 
  3. Put everything you can in the implementation section of your units.  The implementation section is the friend of a Delphi developer trying to limit scope.  Things in an implementation section can’t be seen outside the unit. If you can put a unit name in the implementation uses clause, do it.  If you can declare a class definition in the implementation section, do it.   Putting something in the implementation section of  a unit ensures that it scope doesn’t expand beyond that implementation section. 
  4. If a variable can be local to a routine, do it. This goes along with “No global variables ever”, but it needs to be said. If you can declare a variable in the scope of a single method, do it. 
  5. Use constants whenever possible.   If you are never going to change the value you assign to a variable, why make it a variable at all?  Get in the habit of making something a constant, and then only making it a variable if it needs to be.  Do this even inside your methods. 
  6. If you can declare a parameter as const, do it.  A const parameter can’t be changed, and thus declaring it as such means you are limiting its scope. 
  7. If you can make a variable private, do it.  If you can’t, make it protected. If you can’t do that, make it public.  Only make something published if it has a very specific reason to be.  This one is a little trickier, because there are OOP principles to be considered.  But generally, make field variables private, and give access to them through protected members.  This way, while the data can be changed,  the actual storage device itself is not directly accessible.  In addition, you can control the ability to change the internal data through a setter method.
  8. Provide notification systems in your setters to monitor changing data.  Sometimes, you might have data that needs to be changeable, but is sensitive for some reason.  As as result, you want to perhaps monitor and maybe even prevent the changing of your internal data.  You can use something as simple as an event in the setter method, or something more robust and flexible as the Observer pattern. 
  9. Don’t reach into another class.  Or even better, don’t create classes into which someone else can reach.  This gets into the Law of Demeter, which I’ve discussed before

That’s just a list I came up with this week while working on this post and thinking about this topic.  What are other little methods and techniques that you all use to limit the scope of your variables?

How Nice of Them to put an Extra Teabag in the Box!

By Nick at September 03, 2011 12:59
Filed Under: Personal, General

Anyone who knows me knows that I am, well, pretty much of a knucklehead.  And this little story just proves it once again.

So I drink a lot of ice tea.  And absurd amount, really.  Lots and lots of it.  A gallon a day kind of a lot.  And  naturally I have one of those simple, cheap, yet hopelessly useful ice tea makers.  I then buy boxes of Luzianne Tea in the “Ice Tea Bag” size.  Each of these boxes has 24 bags in it – says so right on the box --  and I use three of these bags every time I brew up a batch of that  magic elixir.  So that is eight batches per box, with no teabags left over, right?

But no, it’s not that simple.  I always end up with *one bag left over* when I get to the last batch.  Every time!  Huh?  I stand there and ponder it -- “Is this like a ‘Baker’s Dozen’ thing going on here with my tea bags?”

And then I take this mysterious “extra” bag, grab two out of the new box, and make the next batch.  And in a week, I’m wondering again.

See, I told you I’m a knucklehead.

Flotsam and Jetsam #42

By Nick at September 03, 2011 09:02
Filed Under: Delphi, Flotsam and Jetsam
  • Interesting Delphi XE2 Item of the Week:  TComponent now implements the Observer pattern. 
  • Very Cool Video of My Friends and Former Co-Workers of the Week: FireMonkey Developers Speak I have to say that:
  • I have fleshed out my Embarcadero Blog Content page that includes links to the two main series of articles that I wrote on my Embarcadero blog.  I still have some formatting to do, but the content should be all there.  I’m trying to grab all the content I can from my old Embarcadero blog, as they need to shut it down for legal reasons (as I understand….).  If you can think of anything I did there worth keeping (that might be be  hard, I know….. Smile) let me know.
  • "It is always painless to depend on interfaces."
  • Hey, I take my position as an Admin at the Delphi UserVoice page seriously, and I’ve been a bit busy.  The XE2 release has made things a little more fun there…
    • I just marked as "Completed" over 3800 votes on Delphi's UserVoice page. Not bad for a day's work.  And not bad by Embarcadero in delivering all that asked for functionality.
    • Now, with all those votes freed up, the most requested item is Better GUI separation and abstraction.  Is that really the thing that the community wants most?
    • I closed a bunch of “laundry list” items that would be impossible to close.  They were things like “Make the IDE Better” with a list of seven things they wanted to see.  How could you ever really close that as “Done”?  I encouraged the posters to create new requests for each individual request instead.
    • I’d recommend all you fine people go there and enter your requests as well as peruse the list and cast your votes.
  • I’ve been trying to build things with my son, and  being a boy, he likes weapons and destruction.  We started with a trebuchet.  I think it will likely be a while before we work our way up to this, but hey, we can dream. 

The Iron Triangle and Quality

By Nick at August 16, 2011 11:28
Filed Under: Software Development

More from my Embarcadero Blog.....


Another great article called "The Iron Stool" by Jeff Atwood, and on a topic near and dear to my heart these days.

I talk a lot about quality when I’m on the road and visiting with customers.  I consider the quality of the product to be the #1 feature going forward.  When I talk about "quality", I’m talking about speed, performance, and stability all wrapped up into one thing.  I know that no matter what the feature set for a given release, if the perception is that the product lacks quality, it will not be as well received as it might otherwise have been.  You all have been very clear that quality is important, and we are taking that very seriously.

Jeff’s article talks about the classic "Iron Triangle"of Time, Resources, and Features and how they interact to limit what you can do on any given software project.  Increase one, and the other two are affected.  Decrease Time, and you get fewer features.  Increase Resources and you get more features.  It’s a constant tug and pull between the sides of the triangle.  You have to keep the triangle balanced.  You can’t pad up features without adding in more resources or more time.

Well, actually, you can, right?  You can add features to a project, without increasing time or resources.  But of course, when you do, something else has to give, and that something is quality.  Give people a fixed feature set, limited resources, and a set date to finish, and you’ll probably get the product — but at the cost of that quality of the thing delivered (assuming that the time constraint is limted, of course).

Jeff then point’s out a co-workers analogy that it can be compared to a three-legged stool.  It took me while to figure out what she meant, but I stewed on it a while until I realized that if you shorten one or two of the legs of the stool, the "quality" of your sitting experience will be less than perfect.  To maintain a good sitting experience, you have to keep all three legs balanced.

But I don’t agree entirely with that analogy, because if you expand time, (that is, increase the amount of time allotted to complete the features even with fixed resources), you’ll get more quality.  Increased time is the one thing that should almost always improve quality.

One of the commenters to the post pointed out that some people view Quality as the area of the triangle. Pull on the corner of any triangle, and it’s area will increase.  Push on it and it’s area will decrease.  But that breaks down because adding more features will not help quality – doing so just creates more things to break and less time used up to test for and fix bugs.  Adding resources or time to a project will increase it’s quality, as long as the resources are added a the beginning.  Time can be added, well, any time.  ;-)

Another way to think about it is to make the three sides be Time, Quality, and Features.    Much of the time, resources are relatively fixed. That is the way we operate here — we have a team of developers, the size of which changes only marginally.  Brooks Law states that you should be less inclined to increase a team’s size the farther along the project is.  Since resources should only be altered very early in a project, Resources are to a large degree not a variable entity in the equation.  Features and Time are variables that can be adjusted much more easily along the way.

So it’ isn’t entirely clear how the "Iron Triangle" analogy holds.  I do know this — spend more time on quality and you’ll get quality.  And that is what we plan on doing for the Highlander release.

Greatest Blog Post Title Ever?

By Nick at August 15, 2011 12:51
Filed Under: Delphi, General, Software Development

Okay, more from my Embarcadero blog. This is kind of becoming a greatest hits combined with a trip down memory lane. I particularly remember this conversation-turned-blog-entry. It was the result of a late-night, late-in-the-development cycle conversation that had us all laughing very, very hard.


  • Okay — so I’m reading Steve Trefethen’s blog, and he links to what, in my personal opinion, is the greatest single title for a technical blog post ever —The Windows Shutdown Crapfest.  Doesn’t get any better than that.
  • So I read the thing, and it’s, well, amazing.  They have a whole team of people that do nothing but work on the Start menu.  That team had a whole team of people that works purely on the Shutdown experience. 
  • This fact above led to a discussion here on our release team about whether there is one guy on the C# compiler team who works only on the opening curly brace feature.  Does he have pair programmer that works purely on the closing brace?  When they work together, do they have to face each other? Does the Opening Curly Brace guy always have to sit on the left of the Closing Curly Brace guy? And what if Opening Curly Brace guy wants to keep working, but Closing Curly Brace guy wants to go home?  Does this result in a syntax error?  I have to know these things.
  • Now, if you think the above sounds ridiculous, then I think you’d should actually read the whole article.  It’s an amazing tale of Kafka-esque development processes.  Dude had to wait up to three months for his code to actually reach the product. 
  • And I thought that we had a convoluted release process here.
  • Yes, we are getting a little giddy.

(Note: this blog post was written by a committee).

My New Laptop Backpack

By Nick at August 14, 2011 17:37
Filed Under: General, Personal

More older content that I'm reclaiming from my Embarcadero blog. By the way, I still use the backpack every day, and it is still in as good a condition as the day I bought it.  I can and still do strongly recommend a backpack from Tom Bihn.


Sometimes you buy something and it just feels so good to use it.  Usually, something like that is a relatively expensive purchase.   Maybe you went ahead and spent the extra money for the nicer version or model, and you ended up getting more than your money’s worth.  Or you went ahead and bought from the vendor who has an FAQ page with questions like "Why are your products so much more expensive than the competition", and they have answers like "Well, we think the products are worth the extra price".  And very often they are, because if they weren’t, the company wouldn’t stay in business for very long.

My recent purchase like that was a Tom Bihn backpack.  I’ve long carried my laptop in a backpack, even before it was common.  I remember buying a nice one about eight years ago, and one of the selling points was that "no one will know  you are carrying a laptop in there!".   (I don’t think that would be the case anymore.)  I’ve never been a big fan of the briefcase or the over-the-shoulder strap.  Backpacks have always been the way to go for me.  So when my crappy, cheap Targus backback — that I never really liked anyway — started going bad ("started" is kind — in about two weeks every zipper on the thing basically went bad, I decided to make a move. 

A few of the guys around here have Tom Bihn bags, and they’ve raved about them.  John Kaster has had the same bag for as long as I’ve known him.  So I trekked on over to the website to poke around.  The first thing I noticed was that they weren’t cheap, to say the least.  It was clear that to get what I wanted was easily going to approach $200.  But as I looked around, it became clear that I was going to get what I paid for.

First, I noticed that they clearly had strong attention to detail.  Tom Bihn doesn’t sell laptop backpacks, they sell backpacks that comfortably and carefully integrate laptop carrying cases.  To get a "laptop backpack", you actually have to buy two things from them:  the backpack and what they call a "Brain Cell".  The latter is a very well designed, snug-fitting, and heavily padded and constructed cocoon for your laptop.  The Brain Cell integrates  perfectly into almost any of their backpacks, quickly becoming part of the backpack itself.  And it is clear when your laptop is nestled tightly in the Brain Cell that not much is going to happen to it in there. 

And here’s where the attention to detail comes in — they must have like 20 different sized Brain Cells, all fitting different kinds and sizes of laptops.  I have a Latitude D820, so I ended up going with a Size 1 Vertical Brain Cell.  (Yes, they have both Horizontal for briefcases and Vertical Brain Cells for backpacks).  It was pretty easy to find the rigth one on their website. 

Second, it was clear that a lot of thought had gone into the ergonomics of their products.  The zippers were all easily accessible and clearly heavy duty.  The pockets on the back of the bag make for easy access.  The bag has straps on the side that allow for expansion, keeping the bag "just the right size" while allowing for a lot of stuff to be put into it.  Overall, it was clear that this was a really, really nice product.  Add in the really nice website that made it easy to see exactly what I was getting, and it was a no-brainer to slap down the money for a Brain Bag with a Vertical Brain Cell. For those of you so desperately concerned about what colors I choose :-)  I got the Sapphire bag with the Crimson brain cell.  (I figure I can ask for the Snake Charmer or the Freudian slip for Christmas. ;-)

The backpack came in two days, and I instantly knew that it was money well spent, despite the $197 price tag.  This is a fine piece of gear, and one that clearly will last for years to come.  Highly recommended.

Added: Hey, the folks at Tom Bihn were kind enough to post a link to my blog.

The Programming Book Business

By Nick at August 12, 2011 21:29
Filed Under: TechBiz, General

More content from my old Embarcadero Blog.  I think this is even more true than it was when I wrote it a few years ago, especially with the rise of the Kindle and Tablets.  Those new devices are changing publishing, but I still think that what I wrote here is germane.


I’ve blogged about this before — the programming book industry continues to fascinate me. Jeff Atwood comments this week on it, talking about how "The Internet has rendered programming books obsolete."  Lately, there has been a resurgence of Delphi books, lead by Marco Cantu and others, but these guys are not using traditional book publishing channels.  Instead, they are taking advantage of the  budding "on demand publishing" industry, most notably on lulu.com.   I know that I first do a Google search if I have a programming issue, and if I want to learn to do something new, I tend look first to the Internet rather than for a book.  But that doesn’t mean that books aren’t valuable — they are.

I still buy programming books, but I find that I don’t buy the books that "teach you to program <insert language name> in <insert ever shrinking period of time>." Instead, like Jeff Atwood, I tend to buy books about the practice of software development — my latest is Facts and Fallacies of Software Engineering by Robert L. Glass.  This is a cool book. Easy to read, and full of terrific nuggets of wisdom.  Probably my all time favorite is The Pragmatic Programmer by Andrew Hunt and David Thomas.  Atwood makes a great, great point when he says, "If you feel compelled to clean house on your bookshelf every five years, trust me on this, you’re buying the wrong programming books."   I think he’s dead on about that.  (I’m happy to note that the two books I mentioned above are in his list of top five programming books. ;-) I need to get Peopleware and Don't Make Me Think .)

I have been involved with the publishing of a few books done in the "old-school" way, and I dare say it is really, really inefficient.  Really inefficient.  Really, really inefficient.  There were editors and more editors and them some other editors.  And they don’t know one thing about programming.  (I remember a book in the early days of Delphi where an editor decided that the word "Pascal" should be replaced with "Delphi" everywhere.  Or maybe it was the other way around.  In any event, it wasn’t pretty.)  You have to submit your work to them in a special MS Word template, and then they comment (generally very ignorantly), and then you do a huge back and forth with them.  Then of course, once the book fiiiinally gets past that treacherous gauntlet, they print up boxes and boxes and boxes of them, ship them all around the country, put them on shelves, sell a few, and eventually box the remainders up again and send them back to the publisher.  They pay the author a very small royalty relative to the book price. This whole thing simply does not make sense to me.

Marco Cantu was here last week — and he graciously gave me a signed copy of his new "Essential Pascal".  This book was printed on demand by Lulu, and is a nicely made and bound as any book I have.  Marco has been very pleased with the way his Lulu publishing as gone.  Julian Bucknall has said the same thing about his The Tomes of Delphi: Algorithms and Data Structures.  There is a nice collection of Delphi books on Lulu, including a number of them from Dr. Bob as well. (Ray Konopka, call your agent!)

On demand publishing is clearly the future.   It’s a classic case of cutting out the middle man.  A guy like Marco makes a lot more money per book sale, so he doesn’t have to sell as many books to make it worth his while.  This enables authors to publish books of smaller and tighter scopes — that is, books that the traditional publishing industry wouldn’t touch in a million years.  This is good for authors — they make money where they wouldn’t have been able to previously.

It is also good for customers — they get books that they want that would never have been published under the previous model.  Prices are lower, too, because with the overhead gone, authors can charge less and still make more.  It’s simply a vastly superior business model.  And the cool thing is that anyone can publish almost any book at all, and sell it to anyone.  You could, quite literally, take that paper you wrote for a conference a while back, work it up a bit, and be selling online in a week.  I don’t know why I haven’t done it.

Why haven’t you?  :-)

Pandora, RIAA, and Buying Music

By Nick at August 11, 2011 12:50
Filed Under: General, Tech Stuff, TechBiz

Another “reprint” from my Embarcadero blog.  Funny thing is, I was thinking of writing this exact blog post yesterday.  Right now, I’m doing something that would have seemed crazy ten years ago:  I’m listening to a wonderful personalized radio station on Pandora through my television via my Blu-Ray player.  I can honestly say that paying for Pandora was some of the best money I’ve ever spent.


I’m a huge fan of Pandora.  If you haven’t discovered it yet, Pandora is a music streaming service that has a terrific knack for playing music that you like.  You can create stations simply be telling them one of your favorite artists, and then they start playing music from that artist, and then music similar to that artist, based on the input of other users. As they choose different songs for you, you can give them the thumbs up or the thumbs down, and the  I have a great station based on the GooGooDolls, and something like 98% of the songs they play on that station I like.  After a little tuning, I only very rarely give the thumbs down to a song they play for me.

The service is free, and I will occasionally try to click on some of their ads in support of the service.  But maybe the best thing is the number of new artists that I’ve discovered.  If not for Pandora, I’d have never heard of Colby Caillat or Sara Bareilles or Matt Nathanson.  And because of Pandora, I’ve purchased many new CD’s that I otherwise would not have.  The same thing happened to Julian Bucknall when he discovered Pandora.

Now, given the above, you’d think that the music industry would be delighted with Pandora.  Sadly, the opposite is true.  They are putting the thumbscrews to Pandora.  Pandora is still on the air — I’m listening right now — and hopefully that will continue.  I’m not familiar with all the details — I gather that they may be working this out so Pandora and other broadcasters can stay "on the air".  I’m all for artists and the record companies getting paid, but it seems to me that this is another example of an "old economy" business not realizing how things work and how they can benefit from the "new economy".

Things I've been Watching, Reading, and Listening to Lately #1

By Nick at August 11, 2011 00:52
Filed Under: General, Personal

Calculating Pi

By Nick at August 10, 2011 11:36
Filed Under: Delphi

More Stuff I found on my Embarcadero Blog. I believe that my unusual use of the case statement caused a bit of a stir.  I still like using case in this way….


This was fun to write.  I read this interesting post on StackOverflow, which had an answer about asking interview questions, and this was the example he gave:

Given that Pi can be estimated using the function 4 * (1 - 1/3 + 1/5 - 1/7 + …) with more terms giving greater accuracy, write a function that calculates Pi to an accuracy of 5 decimal places.

Now, I don’t get to do much coding anymore, but hey, I’m not completely out of it, so I thought I’d try my hand at it. This is what I came up with:

function CalculatePi(aIterations: Cardinal): Extended;
var
  Counter: Cardinal;
  Denominator: integer;
begin
  Counter := 0;
  Denominator := 3;
  Result := 1;

  repeat
    case Odd(Counter) of
      True:  begin
               Result := Result + (1/Denominator);
             end;
      False: begin
               Result := Result - (1/Denominator);
             end;
    end;
    Inc(Counter);
    Denominator := Denominator + 2;
  until Counter >= aIterations ;

  Result := Result * 4;
end;

Now, again, I’m no Barry Kelly, and I’m sure that this could be optimized, but I was pretty pleased with that in a ‘that’s what I would have hacked out in an interview" kind of way.  :-)

The more iterations you pass in, the more precise it gets, obviously. I actually didn’t answer the full question (I skipped the precision part), but casual testing shows that about 10,000,000 iterations gets about 5 decimal points of accuracy. In fact, 10,000,000 iteration produces 3.14159275358978, which is pretty accurate.

Ten Things That Really Bug Me

By Nick at August 09, 2011 23:13
Filed Under: Software Development, General

I found this on my Embarcadero blog from 13 April 2009.  I wanted to preserve it here…


I was cleaning up my hard drive and I found lying around in an old HTML file.  The date on the file was from April of 2006, before I came to CodeGear.  I can’t remember if I ever put this up on a blog somewhere, but I thought it was a pretty good rant, so I’m posting it here. :-)

  1. Message boxes that ask a Yes/No question, but give you Ok/Cancel buttons. I mean, come on. If you are asking a "Yes or No" question, how tough is it to tell the dialog to have Yes and No buttons? Not tough at all, that’s how tough it is.
  2. Ok buttons that are enabled when a dialog is not properly filled in.   This is basic User Interface design. If pushing a button will result in an error message, don’t let the user push the button.
  3. Non-sizable dialogs.  Argh. This one drives me nuts. It’s especially galling when there’s a list box or something that is so small you feel like you are looking at it through a straw.
  4. Dialogs that don’t remember their size and position. Related to the previous item. Sometimes a dialog is too small, and when I size it, I want it to stay sized. Sometimes it blocks stuff I want to see. It should stay where I put it.
  5. Windows that insist on putting themselves in front when I am doing something else. This is absolutely, unequivocally the most irritating thing about Windows. I decide what I am looking at, not some shareware programmer from Wisconsin. If I am typing or otherwise working in a Window, no other application should ever be able to steal the focus, unless it’s warning me that my house is on fire or something.
  6. File directory trees the size of postage stamps. Related to the issue above. Ever get one of those slightly older applications that won’t let you size the directory lookup tree? With ever expanding hard drives and increasingly complex file directory structures, looking at your harddrive through a fixed size treeview that’s only 150 pixels square feels like being shoved in the trunk of a Yugo.
  7. Crappy error messages, especially when they are sentences and don’t end in a period. "Item not found". Great — which item? The name or even type of the item has got to be known by something in the app, otherwise, how could it be looked for?  Tell us for crying out loud! Or how about the old favorite "Error 332322". This isn’t a problem for me personally because I have, of course, memorized all the error codes for your application.
  8. CAPSLOCK keys. The person who thought putting the CAPSLOCK key above the SHIFT key and right below the TAB key should be rubbed vigorously with rough sandpaper and then placed in a bathtub full of lemon juice. [Ed:  Solution can be found here]
  9. Unnecessary modal dialog boxes that I have to click when it doesn’t make any difference. I love these. "You’ve done something really stupid. Press Ok to continue". Great. Thanks. I couldn’t have made it through the day without that totally, utterly meaningless and pointless message.
  10. Dialog boxes that have the negative answer on the left and the positive answer on the right. OK buttons go on the left. Cancel buttons go on the right. Don’t put the Delete button on the left and the Approve button on the right. It’s a gross violation of the laws of nature.

Nick’s Public Code Repository Update

By Nick at August 09, 2011 14:42
Filed Under: Delphi, Software Development

Some of you may remember the TextScrubber project I was writing about back on my Embarcadero blog.  (I’ll update that page really soon, like today…).  I’ve made two changes with that project:

  1. I’ve updated it to allow you to set it to run automatically on Windows startup.
  2. I’ve moved the repository from SVN and SourceForge over to Mercurial and BitBucket.

Now this may be a bit of an inconvenience to some of you, and I apologize.  First, if you don’t have the Mercurial command line tool installed, you should.  I’d venture to say that if you don’t have at least the command line tools for SVN, Git, and Mercurial installed, you can’t really call yourself a  true developer.  Second, I’m a Mercurial guy, and BitBucket is Mecca for Mercurial guys.  So you can get the code there.  Third, since I am now a Mercurial guy, SourceForge is no longer my cup of tea.  I’m going to move all my code there over to BitBucket.  (Note – this will not include the TurboPower projects, which I don’t consider “my code”….). 

My intent is to make my BitBucket page a central location for my code. I’ve created a “NickDemoCode” project to publish code I use to demonstrate things.  I’ve got a couple of other small projects there as well. I’d like to do what Marco did and have it be part of nickhodges.com, but I can’t seem to figure out how to do that.  (Anyone have any ideas? My ISP is pretty unhelpful, and this is not my area of expertise….)

So, if you are into great, awesome code, I’d recommend checking for updates to my public repository every 15 minutes or so.  You don’t want to get left behind.  Winking smile

Flotsam and Jetsam #41

By Nick at August 06, 2011 11:11
Filed Under: Flotsam and Jetsam

Flotsam and Jetsam #40

By Nick at July 27, 2011 16:50
Filed Under: Delphi, Flotsam and Jetsam, Software Development, TechBiz

My Book

A Pithy Quote for You

"Christianity, if false, is of no importance, and if true, of infinite importance. The only thing it cannot be is moderately important."    –  C. S. Lewis

Amazon Gift Cards

General Disclaimer

The views I express here are entirely my own and not necessarily those of any other rational person or organization.  However, I strongly recommend that you agree with pretty much everything I say because, well, I'm right.  Most of the time. Except when I'm not, in which case, you shouldn't agree with me.

Month List