Ages ago, back when httpsrvr first came out, I got it working with Apache for a client. Recently, I came across a post by Sydney Delieu in the borland.public.datasnap group outlining the steps needed to get this working today. It strikes me that things are quite a bit easier today than before to get this working, but I did test these directions, and they work well.
I use Apache 2.0.52 with httpsrvr.dll. To get it working:
1. Install Apache (I will assume default directory structure for 2.0.52).
2. Copy 'httpsrvr.dll' to your /apache2/cgi-bin directory.
3. In httpd.conf, change the 'Options None' (again assuming defaults for 2.0.52) in <Directory "C:\Program Files/Apache Group/Apache2/cgi-bin"> to 'Options ExecCGI'.
4. AddHandler isapi-isa .dll to your httpd.conf.
5. Restart Apache.
Surely, you've heard Larry Wall claim that the best traits a great programmer can possess are Laziness, Impatience, and Hubris. If not, stop right now, read the link, and come back here. I think it is brilliant analysis on Larry's part to tie all of that together, and I also believe it to be true.
In contrast, let me explain why the vice of arrogance can't actually be turned into a virtue for a programmer. I'll even argue that arrogance in a programmer is inversely proportional to their talent. Now, before the hate mail starts pouring in, I'm talking about extremes here. There is a fine line between self-confidence and arrogance. I think it is vital for a programmer to have an abundance of self-confidence. I'm sure there are some in my readership that would even claim I walk that fine line betweeen self-confidence and arrogance from time to time.  Self-confidence is good. Programmers can, and do, help shape the world. They build systems that catch criminals, thwart terrorism, pilot airplanes and rockets, map DNA, analyze stock markets, and many other potentially world-changing things. It's only natural to look at what you've created out of thin air and be proud of it, and by extension, gain self-confidence.
However, with apologies to Wall Street, Arrogance, for the lack of a better word, is horrible. It's especially troubling for a programmer to be arrogant while coding. Let's look at some of the main reasons for this claim:
- Arrogance leads you to not question your code. The more talent and experience that I obtain as a programmer, the more I look at my code as the source of the problem first. Most of the time, the problem is in my code. The times that it's a bug elsewhere, I've taken all of the basic steps to gather a test case to prove that it's not my bug. From there, I can either write a work-around, and/or report the bug to the responsible party in a way that allows them to fix the problem easily.
- Arrogance leads you to rely solely on yourself. After all, if you truly are that good, why would you want to take advice from anyone? As a programmer, I relish the opportunity to learn. It doesn't matter where the knowledge comes from. I'm just thankful to gain it. Arrogance closes your options, since the Arrogant Programmer refuses to accept that there are others with an alternative approach.
- Arrogance leads you to write "tricky" code. This make perfect sense, since it clearly demonstrates the superior intellect and raw genius of the Arrogant Programmer. Documentation? Comments? Meaningful identifier names? Pshaw. They're for mere mortals. The Arrogrant Programmer knows the ins and outs of every system, subsystem, and method, and knows that a call could never fail because it has been given life by the Arrogant Programmer. And heaven help the next programmer who dares disturb us to ask why they did such things! Clearly, they are not worthy to breathe the air of the Arrogant Programmer.
- Arrogance is most likely rooted in a false confidence. The Arrogant Programmer may be afraid of not knowing everything, and even more afraid that others will find out that they don't know everything. As a result, the typical mindset is to tear code and people down, instead of building themselves up. You should love working in a team full of great coders. If you want to rise to the top of the top (in anything, IMO), you need to be pushed and challenged. If you find yourself in an environment where you have others keeping you on your toes, it spurs you on to be better than you were before.
So, let's all strive to live by this motto: Friends don't let friends program arrogantly.
Let the flamefest and slashdotting commence!
I recently went to the state GoldenTee championship. It was a lot of fun, and I look forward to next year to improve on my finishes (I took 2nd in doubles and 4th in the open singles bracket). You can find a pretty good summary of what happened here. If anyone wants to inquire about the 3rd/4th place match, I'd be happy to relive the horror story for you in person - over a beer.
We now return to your regulary scheduled blogging lineup.
I wanted a way to name threads to make it easier to debug, but since I'm still using Delphi 6 for the next month or so, I don't have access to the named thread object wizard in the Delphi IDE (as can be found in Delphi 2005). The code that is generated in Delphi 2005 when adding a named thread uses the technique found here:
MSDN article on naming threads
There are some other options, too. See this Google thread for a link to a CodeCentral entry and a technique for making setting the name more flexible.
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.
|