Using Mike Scott's old Netscape plugin SDK, I've been very successful in getting applications deployed with a variety of deployment options (thin client EXE, IE ActiveX/ActiveForm, and Netscape plugin). However, the Plugin SDK has been updated several times, and I haven't gone back to keep the original Delphi port up to date. Add to this mix the "other browsers" on the market that also need to be supported, and I was left wondering which direction to go.

The result was that I found the Netscape ActiveX plugin that allows ActiveX controls to be used inside Netscape-compatible browsers. So far, the results have been mixed, but I like the idea of having single-sourced code that compiles to the same deployment option (ActiveX), and let the browsers worry about how to handle it.

There are plenty of things that can be done to keep a developer from making repeatable and preventable mistakes. So the question really is: What kind of fines motivate developers? I look at fines as not only a deterrent but a way to help improve the talent of the entire development team and build team camaraderie. I've read that people at Microsoft that break the build take the build process until the next person breaks the build, but for me, nothing says "fine" like monetary punishment.

The fines listed below are not exactly going to break someone's pocket, but it does hurt to go into your wallet and pay up. The fines accumulate in a fine jar until there is enough to bring in doughnuts for the entire office.

So, what do you guys use for a fine system?

• Making wild claims without having or providing supporting evidence: $1.00
• Not writing a test case to isolate a bug: $2.00
• Checking in code that doesn't compile (including hints/warnings, and active database connections at design-time): $2.00
• Losing the IFDEFs in a DPR (typical when doing Add To Project in the IDE): $1.00 per DPR
• Checking in code that causes users not to be able to run (typically done when not testing first): $1.00
• Modifying editor options without prior approval: $1.00

Some of you may remember my post on AQTime back in December. At the time, I commented that there were some show-stopper bugs that were preventing me from using AQTime (D6 run-time package and leaked Delphi object names not reporting correctly were the main ones).

I'm happy to report that my first reason for sticking with AQTime (Support) has proven to be a good read. Running AQTime 4.40.469.0, coupled with a custom patch acquired from their support department, I now have AQTime 4 working in my environment. I like the GUI better in AQTime 4, and the service support is tons better. For example, I couldn't profile a COM service properly in AQTime 3 (using SvCom), but it works just fine in AQTime 4.

I'm looking forward to identifying all sorts of wicked issues now.

While I'm not exactly the first one to do so, I would like to throw my congratulations out there as well. I just listened to this interview about the creation of Delphi, and it definitely brought back memories.

At the time, I was working for Med Data Systems, Inc. out of San Diego in my first gig out of college. It was a great time of learning and finding out exactly what it meant to be a professional software developer. One of my tasks was to port our DOS codebase to a Windows application. Since we used Turbo Pascal for DOS since version 5.0, it seemed like a natural fit to stay with Borland. We looked at TPW and VB, but in the end, once we saw what Delphi was like, there was no need to look any further.

My boss, Steve Belkin, and myself ended up flying up to the launch event in San Francisco (try explaining to your girlfriend that you're heading up to San Francisco over Valentine's Day and see what kind of look you get ). It was every bit the event that you've heard it was. If anything, the reports don't do it justice. It was truly a once-in-a-lifetime experience to witness the event first-hand, from the initial technical session where we got free software, to watching the stampede of people on the floor clamoring for the trial copy. Not to mention, Borland throws the best parties in the industry, and this one was probably their finest ever. I do miss Cadillac Margaritas...

This is a quick followup on my post, HTTPSRVR with Apache. If you're using an older version of httpsrvr (e.g. from Delphi 6), then you need to add the following OnCreate/OnDestroy events for the main httpsrvr WebModule. The reason you need to do this is that each thread needs COM initialized, and Apache doesn't automatically do that initialization (whereas, IIS does).

procedure THTTPServer.WebModuleCreate(Sender: TObject);
begin
  { Each web module will be in a separate thread. We need to initialize
    the COM subsystem for each thread }
  if Assigned(ComObj.CoInitializeEx) then
    ComObj.CoInitializeEx(nil, COINIT_MULTITHREADED)
  else
    CoInitialize(nil);
end;

procedure THTTPServer.WebModuleDestroy(Sender: TObject);
begin
  CoUninitialize;
end;

I recently needed to get some simple XOR-type encryption. At first, I was led to TI2803 by Borland. However, that tech note has some problems with the strings having unprintable characters in it (specifically, #0 is troublesome when passing the string around).

I finally came across Peter Martin's solution, which solves all of my needs quite nicely.

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!