Following Shadows of Steel is Fatal Terrain, a continuation of the Patrick McLanahan / Brad Elliot storyline.   The next in my quest to read all of the Old Dog series from Dale Brown.

This time, the conflict is in China.  Specifically centered on the "rogue province" of Taiwan.  The Taiwanese leadership declares independence from China, which is not received well.  Gen. Elliot (ret) is recruited by Sky Masters, Inc. to fly one of the EB-52 Megafortresses with McLananahan and crew on contracted Sig-Int recon missions in the Formosa Strait.  When a Taiwanese frigate is attacked by Chinese navy ships, Elliot launches against them, exposing the stealth missions and heating things up.  Major conflict ensues.  Nukes are used.  Fun by all.

I found it very helpful, and quite enlightening , to read up on Taiwan's real status in today's world.  Wikipedia's article on the Republic of China (Taiwan) is concise enough to get a feeling of the complexity of the situation over there.  While not one of Brown's best works, it was very entertaining, if a bit disturbing.  The portrayal of Elliot was a bit over the top, but worked for the story, and the reasoning why was evident in the end.

I had to hunt down my ICQ number the other day, which I seem to do occasionally over the years.  I use it for a few weeks, then delete it as useless.  I used to use it a lot, but email is much more useful, generally.  I even have an early number:  529564.  It is becoming more difficult to find it, so here it is.  Preserved until this fad wears thin too.  Of course, the client really stinks, since AOL bought them out, but the new Trillian client is pretty nice.  And it integrates Yahoo and MSN IMs too, which I have by default of possessing accounts there.   Let's see how long I use it this time...

A colleague and I were discussing desktop systems, and agreed in confusion about the seemingly typical cost-cutting measure of giving developers underpowered systems to work on.  This got me thinking:

First of all, with todays prices, how expensive would it be to really outfit a developer with a truely powerful rig?  You don't need tons of storage or a fancy 3D gaming card or high-end sound (unless, of course, that is your line of business) so you should be able to get a really powerful machine for under $2000.  It shouldn't be hard to do an ROI for that, just in productivity gains.

Second, it would make your true developers, the propeller-heads that love this stuff, very happy.  That is also a great productivity gain.  After all, a happy coder is a working coder, not one that is standing around bitching.

Finally, I always felt it a truism that it is worse to have a better system at home for development than at work.  This is more an intangible.  After all, you can't constantly be polling people about their personal systems; not to mention, most of us have more than one.  I have 4 functioning and a few not.  I personally will feel more compelled to work on the better system; for management's sake it ought to be on my desk at work.  

So, you management types:  we developers love the hardware, we want to play with it, we want to use it, we want to possess it.  It's a cheap win to give us toys to play with.  We will want to exercise them.  It's in your best interest.

Interesting problem:  I always use library functions in .NET apps to maximize code reuse, especially for Data Access calls.  So when I ran across the following error from Oracle when connecting to a server running 10.2, I was stymied.  Especially since it worked fine with a 10.1 server:

 

ORA-12571: TNS:packet writer failure

Looking this one up brings a whole lot of results, none of them helpful in this situation.  To make it worse, VS2005 ran the application just fine. 

The solution?  The server had the 8.1 connector installed, which for some reason connects to 10.1 just fine.  10.2 was different enough to through the error above.  We got IS to push the 10.2 client on the server, and everything is working.

I am not a great T-SQL developer, so I frequently struggle with some of the more advanced queries.  I spent some time building the query below, so I want to post it for future reference and the hope it may help someone else.

Say you have a dependant table for lookup values of status.  The status code in the primary table may be 1, 2, 3, etc., so the lookup table will define them as Open, Closed, Pending, whatever.  Now say for reporting you want to know how many Open or Closed items you have in the table.  The SQL query below will return each Status name with a count of items using the codes in the primary table:

SELECT OS.ObjectStateID, OS.Code, OS.Name,

    (SELECT COUNT(RS.ProductRequestID)

       FROM ProductRequestState RS

      WHERE RS.IsCurrent = 1 AND RS.ObjectStateID = OS.ObjectStateID

    )

FROM ObjectState OS

Where OS.IsActive = 1

The output will look something like this:

  OID Code              Name                              Count  
----- ----------------- --------------------------------- -----   
    1 WaitSubmit        Created                             154 
    3 Rejected          Rejected                           4785 
    4 WaitTSTechRvw     Waiting TS Tech Review               68 
    6 WaitGroupApprv    Waiting Cost/Labor/TS Tech Apprv    228 
    8 WaitExecApprv     Waiting Manager/Executive Apprv       0 
   13 Complete          Complete                          14433 
   14 WaitCostApprv     Waiting Cost Accounting Apprv         0 
   15 WaitLaborApprv    Waiting Labor and Supply Apprv        0 
   16 WaitTSTechApprv   Waiting TS Technologist Apprv         0

Sorry for the ugly formatting, WordPress is a bit limiting.