I came across this post today, talking about names as viewed from an intercultural perspective. It was a good read, but it triggered something in me that I knew I had to blog about, namely a quote that bites me time and again: "Writing the code is easy. Naming it properly is hard.".
I'd say this problem is pervasive, based on my experience. How many times have you seen code that does "for i:=0 to Count-1 do"? OK, maybe that's a stretch. Counter variables don't exactly require great names. But still, the point remains. Badly named variables, methods, components, etc. are very common. I find that when this happens in my code, it's due to a failure in my understanding of exactly what the code is meant to do. In the old days, you just had to change things around until they make sense. Today, it's called Refactoring. 
My advice is that when you find yourself starting to have to do mental gymnastics to keep track of what a variable/method/etc. is used for, it's time to immediately change either the purpose or name of the variable (or both). It may be a minor inconvenience now, but it will pay major dividends the next time that code is looked at.
I just put the Delphi 2005 version of MIDAS.DLL up on my web site.
I kept both the D7 and D2005 versions up on that page. If you have any problems using this newer version, please post a report to QC.
Sorry to do this, but the spam was getting to be too much (at least 7-10 per day), so I went ahead and password protected the ability to post comments. It seems pretty unobtrusive to me, but if you have major complaints with it, please let me know, and I'll keep digging for a better solution. I really value the feedback I get here, and I don't want to lose it, but I also have to balance that out with making my life easier by not having to delete a deluge of spam.
For those of you that are interested, I ended up using Miguel Jimenez's approach to solve this. I had some initial problems viewing my blog in a browser after implementing this, but it sounds like my ISP fixed that by adding specific permissions to that DLL. One other note: add the httpHandler section BEFORE the .Text entry where they try to take over verb="*" and path="*", otherwise you will never let the HIP generator get processed.
All in all, I would say that the entire upgrade was rather easy. Now let's see if my spam problem goes away.
2 interviews on BDNradio interviews with Ramesh Theivendran are now available. If you use Borland tools to access databases, you should definitely listen to these interviews.
It's been a while since I blogged a "pet peeve", and I know you're all anxiously awaiting the next entry in the series.
When you see code like this, run like mad!
try
DoSomething;
except
end;
Note: You can have the same bad code in C#, and other languages, too.
The problem with this code is that you are swallowing ALL exceptions in this code block. For example, you now won't be notified of Access Violations, Out of Memory conditions, Invalid Pointer operations, or other system-level problems. If DoSomething is throwing an exception of a known type, handle it in the except block explicitly. If you don't know what exceptions can come back, don't handle them. It's really that simple. You can't count on your program working correctly from this point forward if you use this type of construct.
Now, I can think of some very rare places where you need this type of logic (e.g. if an exception leaks out, it will crash a poorly written host process, like IIS and ISAPI). But even then, it would be best to at least log the error somewhere (e.g. file, EventLog, whatever).
I'm almost done writing a very exhaustive paper on exception handling that I titled "Hitch Hiker's Guide To Exceptions". With any luck, I'll publish it to BDN. Stay tuned, and I'll certainly blog about that when/if it gets submitted and accepted.
The problem I described earlier about w.bloggar not handling Edit Post/Publish cycles was not accurate. The problem was a .Text problem, where the editpost method for the MetaWeblog API was returning an Invalid TypeCast exception.
After posting a message on the w.bloggar forums, someone responded with a link to the solution. From there, I followed some more links, and found exactly what I was looking for. At the end of the day, I'm irritated with myself for not finding this earlier. Scott had a fix out for this problem since at *least* July, 2004. Live and learn.
Fixes for the editpost exception in .Text 0.95.2004.102:
If you're not using .Text 0.95.2004.102, or if you've modified .Text in some way, then you'll need to take a look at the source fixes and figure out how you want to handle things. I tested the binary fix, and things work fine for me.
OK, so my blog is turning into a bunch of upgrade announcements. However, this is the much anticipated release of w.bloggar 4.0.
I blogged about w.bloggar before, and it's only gotten better. It even has .Text support right out of the box now. Plus, the upgrade was extremely painless, as it kept all of my old settings. The one bad thing is that the bug with getting Last Posts from .Text is still there. I'll work with the people at w.bloggar to resolve that.
Update: It looks like the Last Posts bug has been fixed in w.bloggar 4.0. Perhaps you need to post first with 4.0 in order to get things working, because last night - before I posted this blog entry - I was still getting the error. Today, I can retrieve all of the posts that I want without problem. However, you can't actually edit a post and publish it back. (I'll update this entry again if I get it working!)
Updated 1/11/05: I think I have the fix for the Edit Post problem. New blog entry to follow.
Trillian just released a new version of their software. If you follow the link, you'll see that it's an IM client that works with all of the major IM vendors (AOL, MSN, Yahoo, etc.). The new version definitely feels slicker and faster. I also love that they insert wikipedia links right into the text. I may get annoyed with that later, but right now, that's awfully cool.
I used Trillian .74 off and on for a while, so with the release of version 3.0, I decided it was time to use it full-time and get the Pro version. $25 is rather cheap for the utility it provides. And yes, I looked at GAIM before, but I just wasn't impressed.
I love consistency. I believe it is one of the primary reasons I was predisposed to be a programmer. Input X into a function and get Y in return - and get the same result every single time forever. Which leads me to the topic of the day: How do you upgrade software that you write? Releasing updates is a fine balance. Too many releases cause pain, and too few releases cause pain - just in different ways.
Let me start with my premise: All software is released with bugs (I'll concede that zero defect software exists, e.g. medical devices, NASA, etc., but that is not even close to the norm in the business world today). Some bugs are small, some are huge. Some you can work around, some cripple the usefulness of the application. Some are known, some are yet to be discovered, but the bugs are there. How do you address getting fixes to these bugs to your customers?
One method is to have rapid patches, addressing the most severe bugs first. I love this approach. It does come with some extra burden to make sure that your software is up to date with the latest and greatest software, and you may need to install several patches over the course of time, but I like the incremental approach.
Another method is to roll as many bug fixes into a patch and deliver less frequent updates. This is certainly better than no updates, but the end result as an end-user is that I end up living with bugs on my computer even though the vendor has fixed the bug ages ago (comparatively speaking).
So, the logical conclusion is that you like one approach or the other. If you like the first method, it is illogical to then turn around and question why this is being done (i.e. "What's wrong? Is the software too buggy?"). Of course it has bugs. See my premise earlier if you don't believe me. But the fact that the vendor is taking quick steps to address the bugs is a great thing. If, on the other hand, you prefer the second approach, then it isn't fair to criticize the length of time between the updates. Both of the complaints above are just a matter of degree. It is impractical, and dare I say, impossible, to do both approaches simultaneously.
Borland has moved from lengthy, all-inclusive patches to a model closer to the rapid patches. I see countless examples of people who used to deride Borland for adopting the all-in-one patch model now complaining that they are releasing too frequently, and that, somehow, it reflects on the quality of the application. Unfortunately, in business, money matters. Schedules are set, profit targets are projected, books are balanced, and goals are measured against the bottom-line. Rarely does a software product ship "when it's ready". It ships when management says it must ship. The developer's job is to make it as good as they can in that time-frame. I wish that would change, but that's not going to happen until the entire software industry realizes how that can impact their bottom line. So, my bottom line is this: While software from any company is not perfect, I love the fact that Borland is releasing frequent patches.
I just read this post on how Ancient Egyptians must have understood Object Oriented systems by Rockford Lhotka. Rockford has (arguably) the book on Business Objects in .NET. He's also been on DotNet Rocks.
After reading his blog entry, I found myself truly laughing out loud. I was imagining a bunch of Council Leaders in ancient Egypt sitting around in a meeting trying to capture all of this in UML. Maybe you could draw a correlation to UML and hieroglyphics. Perhaps they were sitting around in a JAD session trying to fine-tune the roles and responsibilities. Which leads to the real question: Who was the PHB in this scenario? At any rate, it's definitely worth a read.
|