Another Data Point in the Ongoing Obamacare Debacle

We just got our insurance rate notices in for 2014. The policies which cover our small staff of young, male staffers now include statutorily mandatory (and quite useless) pregnancy coverage as well as pediatric dental care. Their premiums also just doubled. .

When I say “doubled”, I mean precisely that–almost to the cent. Technically, they went up 100.4%. In one year.

Thanks to the “affordable” care act, our overall insurance rates have gone up astronomically, our deductibles have massively increased, and for the first time ever, we’re giving very serious thought to dropping our employee health care altogether and hoping our employees do better than my own quote on the California “exchange”, where my new lowest-priced available plan for my family of four is an essentially worthless plan that charts in at over $1,000/month, with a $5,000 deductible and terrible choice of doctors. Like most other things in this damnable sham of a law, the promise that we would both save money on our premiums and be able to keep our doctors were transparent lies. Now it’s looking increasingly likely our employees may lose their insurance altogether. 

 

“Hey, I’ve got an Idea…!” The Secret Story of Sidekick

“Damn it! It just can’t read the update file any faster!”

It was late 2012, and I had a little bit of freedom after the launch of ComicBase 16 to try to take on some of the “Big Issues” for ComicBase’s future. High on the list was better mobile support (more on this in a separate article), a possible replacing of the underlying database technology, and possibly even facing down the prospect of completely rewriting in .Net.

“Dotnet” as it’s pronounced, is a Microsoft technology that had clearly been the future of the company’s development path for some time–but which promised to pose a monumental struggle for porting the mammoth code base behind ComicBase. We’d actually done an investigation of what it would take to make the move three different times over the years, but had to turn back each time when it became clear we’d have to essentially rewrite and refactor what had become a very large and complex program. Worse, if we somehow managed to rewrite ComicBase in .Net, our developers would get the benefit of much better build tools (albeit at the price of endless hours of programming and re-testing), but the customers would be unlikely to notice any difference at all.

Actually, that last part isn’t quite true: the progress bars in .Net are decidedly nicer. The rest of the changes would be technical and architectural in nature–which is to say, virtually invisible to the end user, unless we used the rewrite as an excuse to polish up various bits of the program using the newer technology.

But for today, I wasn’t worried about any of those things. I had decided that I wanted to see what could be done to make the weekly updates faster.

Introduced in ComicBase 10, the weekly updates did something previously unimaginable: the ComicBase staff had taken on the job of keeping all our customers updated with all new comic information the same week the comics appeared on the stands. We’d supply all the new data on every comic released each week–along with its artists, writers, storylines, and other special information–and our customers would be able to simply download it and have their database be instantly current, instead of adding all that data in themselves. All the customer had to do then was simply check off which books they had in their own collection, or better yet, use a barcode scanner to “bleep” them in to their own collection.

For understandable reasons, the weekly updates were a huge hit, but it meant that we had to take on the incredible amount of work to acquire several hundred new comics each week, as well as keeping up with the constant pricing changes that were happening in the world of comics. We opened up our own Diamond Comics account, and soon were ordering one copy of virtually every issue sold, which our indexers would scan and index within a day or two of their arrival so they could be part of the Friday update.

Later, we added in a “Submit new or corrected data” feature to ComicBase which allowed several dozen amazing customers to add to the wealth of knowledge we were processing, and the pace of additions to the database doubled, then doubled again. Soon we were processing thousands of new issues and additions each week, and the database grew to encompass virtually every English-language comic that had ever been printed–as well as hundreds of thousands of foreign books.

But now there was a new problem: the sheer size of the database was starting to make the process of downloading and processing the weekly updates an increasingly lengthy process for our customers. What once took them only a few minutes was starting to stretch on for 15 minutes or longer–sometimes much longer if they had a slower machine or were upgrading a very old version. If customers hadn’t been updating regularly, it was not unheard of for an update to contain hundreds of  thousands of  updates to everything from pricing to artist credits. Unfortunately, updating this much information meant that customers were spending too much of their time watching progress bars while they waited for all those changes to be incorporated.

So I had decided to take some time and really pound on the code for the updating process, trying to wring the last bit of performance out of it. Numerous late night hacking sessions ensued, but for every clever programming trick I came up with that saved a few ticks of the clock, the time savings soon vanished as the flood of new comics swelled the database to ever greater scope.

After yet another late night of coding, I was discussing the problem with my wife Carolyn as we walked over to Starbucks on our morning routine. “I think I’m at the limit–no matter how fast computers are going, it just looks like it’s going to take several minutes to even read–let along process–the update file. After all, it’s got something over 10 million distinct pieces of information in each one.”

“Can’t you cut it down?” she asked?

“Not that I can see. There’s no telling how long it’s been since someone updated, and we need to be able to catch them up to date even if they haven’t checked for updates all year long. We could cut down on the amount of data we offer, but a big part of the appeal of the program is that it’s the biggest database of comics in the world.”

“If only there was some way to have the updates happen automatically so that people weren’t standing around waiting for them each week–.”

“Hey, I’ve got an idea…”

(to be continued)

The Fine Line Between Inclusiveness and PC Crap: Starbucks’ “Holiday Blend”

ImageImage

Judging by my actual spending, I’m a huge Starbucks supporter, with more mornings than not starting with a walk down to the local to grab a mocha with my beautiful wife Carolyn. As the seasons pass, there’s a certain rhythm to their promotional calendar, which becomes in its own way, part of the way we mark the seasons: from the summer Frappuccino specials to the fall pumpkin spice latte introduction, to the eagerly anticipated–and all too brief–time when the eggnog drinks come out, marking the start of the Christmas season.

For the past 23 years or so, Starbucks has also done a special “Christmas blend” of coffee, and I’ll usually grab a bag or two during the holiday season to keep the coffee grinder at home supplied when I’m not slugging down caffeine in their stores. This year, however, I noticed something a little strange about their promotional schedule: the Christmas Blend coffee went on discount nearly the moment it was released, with the discounts increasing from “free beverage with purchase” to “25% off” then “30% off” in the space of just a few days at the local Starbucks. 

“What the heck is going on?” I thought–are Christmas sales really that soft? Had I inadvertently stumbled upon a hidden indicator of underlying economic weakness?

Today, I got my answer, as the shelves at the Starbucks appeared freshly restocked with new packages of something called “Starbucks Holiday Blend”. A quick check later confirmed that there was nothing different between this new “Holiday Blend” and the now outmoded “Christmas Blend” introduced just weeks earlier. Apparently, Starbucks had simply decided to cancel the Christmas Blend and rebrand it as the generic “Holiday Blend”–just in time for the Holi-… err… Christmas.

To Howard Schultz and Co.: I gotta tell, you, this sort of thing doesn’t leave me feeling festive–it just leaves me cold. Had you created a Hanukkah blend, it would have been kind of awesome, and I might have even picked up a bag or two to gift to my Jewish friends. By joining the spineless crowd of  marketers aiming at the elusive “Holiday-which-shall-not-be-named”, it robs the campaign of any genuine human warmth. Instead, it becomes one more tentative step in the tiptoe-dance around imagined slights and hypersensitivities that steal basic human kindness from something as simple as a Christmastime greeting.

So guys, I love your products, and I love that your business offers me a great way to take a few minutes each day away from my work to spend time with friends and loved ones. At the same time, I hope your “Holiday Blend” sales tank so badly that you drop the generic pablum and get back to selling products which relate to customers on a human level without kowtowing to the gods of PCishness which have done so much to keep people walking on eggshells around each other. 

Privacy Nightmares: Google Probably Knows your Wi-Fi Password

Thanks to a helpful “backup settings” option built into Android devices (default: on), the passwords used by any Android device to log into wi-fi networks are being sent to Google. Worse: Google can (and has) been compelled to share such information with the government.

Hey, why devote clusters of code-cracking hardware to penetrate network security when a simple subpoena lets you simply get Google to pass the keys straight over to you?

But no worries, right?

One for the Programmers: Daily WTF

If you’re not a VB.Net or C# geek, probably best to move on to the next post. But if you are, perhaps someone can explain to me the what the !@#%! is going on here.

While hacking away on a new code project which involved porting a routine from VB6 to VB.Net (4.5 framework), I discovered that my performance had gone completely to hell on a function which assembles a big text file from database values. In it, I tracked the trouble to a function checks to see if certain values from the database were null, and returns “safe” values in case they are. It also looks for telltale “null” date fields, with values like 12/31/1899 which–although not technically null, are acting as blank for these purposes.

Here’s code sample #1:

  Public Shared Function ConvertNulls( _ 
     ByVal theString As Object) As String
    ...
      If IsDBNull(theString) Then
        ConvertNulls = ""
      ElseIf theString = "12:00:00 AM"  OrElse theString = _
           "12/31/1899" OrElse theString= "12/30/1899" Then
        ConvertNulls = "" ' This is a null date string
      Else
        ConvertNulls = theString
      End If
     ...
  End Function

And code sample #2:

  Public Shared Function ConvertNulls( _ 
     ByVal theString As Object) As String
     ...
      If IsDBNull(theString) Then
        ConvertNulls = ""
      ElseIf theString.Equals("12:00:00 AM") _
         OrElse theString.Equals("12/31/1899") _
         OrElse theString.Equals("12/30/1899") Then
        ConvertNulls = "" ' This is a null date string
      Else
        ConvertNulls = theString
      End If
    ...
  End Function

Here’s the thing:

Code sample #1 was on track to take a hour or so to run through 100,000 iterations; code sample #2 did the same 100,000 iterations in about 20 seconds. And the only difference? Whether I used theString = “x” or theString.equals “x”

Luckily, I thought to try .equals pretty early on, or else I’d be pulling my hair out trying to figure out why there should be even a tiny difference between the two approaches. Can anyone out there give me a coherent explanation as to why using the “=” operator vs. the .equals method should yield such wildly different performance results?

More Pixels, More Weirdness: Retina Displays and the Sudden Importance of Resolution Independence

A buddy of mine who still works at Apple got me in on a deal for a new MacBook Pro with a shiny new “Retina” display. For those who’ve lived a charmed life immune from the Apple hype machine, “retina displays” are what Apple calls their ultra-high resolution (typically 220-330 DPI) displays, which come (somewhat) close to the human eye’s limit for ability to distinguish individual pixels. It’s a crazy sharp display, with a native resolution of  2560×1600 on a 15″ form factor. All told, it’s a ton of pixels.

I can tell you from firsthand experience that it makes for razor-sharp text display, and the sheer beauty of well-designed fonts on it has gone a long way toward rekindling my love of the fine points of typography. It’s also easily the nicest, lightest, and most capable laptop I’ve ever owned.

But–and you knew there was a “but” coming–all those pixels are causing me a lot of trouble when it comes to ComicBase, due to the insane ways which Windows deals with font scaling.

The problem comes down to this: if you actually try to run a MacBook Pro 15″ at its “native” resolution of 2560×1600, the pixels are so impossibly small that you’d need either the eyes of a teenager or a jeweler’s loupe to be able to read the type. To work around this, you have to tell Windows to scale the display to use a “custom text size” of 200% in the Display Control Panel. Windows then attempts to make all the application’s elements twice as large, solving the “tiny pixels” problem.

Unfortunately, it doesn’t do such a great job of resizing layouts which use graphics, leading to all manner of half-drawn screen elements and tiny pictures in the middle of what are now double-sized text layouts.  And of course, one of the biggest victims of this slapdash resizing is that old graphic-and-text-heavy app ComicBase.

In the past, we’d advise folks who ran into this problem to simply use “normal size” text, and run their displays at native resolutions. For better or worse, however, the advent of super-rezzy retina displays makes this advice no longer realistic. As such, expect yours truly to be devoting a lot of energy and special coding to ensure the next release of ComicBase looks terrific on even the most hardcore displays.

After all, what’s the point of having Really Shiny new tech toys, if your favorite programs aren’t going to look terrific on them?

Sim City V – The News Gets Worse

Image

Imagine a big-budget game–the crowning jewel of one of the most successful game franchises ever. Then imagine that in order to play it in single player mode, you need to be able to connect to the company’s overloaded servers, so that you routinely get 20-minute-long “waiting to connect’ messages whenever you launch the game on your own machine.

How could the situation possibly get worse? Release a “patch” which de-features the game in order to make it run. Then offer affected customers to file for a refund…but refuse to actually process any of those refund requests.

Unbelievably bad customer service. Read the whole thing.