This ran on Venus through the end of 1984. I had transferred to Alan Kotok‘s Simplified Architecture for Fast Execution (SAFE) project, where I was looking into VAX-11 emulation. Large VAX Engineering’s senior management called an “all hands on deck” emergency, and everyone needed do whatever they could to help Venus ship on time. So, I informally returned to work on Venus and ran one of the lab debug shifts. It was equally exhilarating and stressful… An, “I wouldn’t trade those memories for anything in the world,” and, “I hope I never go through something like that again,” experience.

This version ran VMS and oodles of VAX programs. I don’t know if there was a later version; if so, I never heard about it.

I’m off this week, and while loafing around the house I took an hour or so to search the web about Digital Equipment Corporation (DEC), a former employer. That was a mistake, because it got me thinking about my past. This was fun for a while, and then it got sobering.

I worked for DEC from February 1978 until August 1996. During the glory years (before 1986) it was an adventure. We were on a world-changing mission. The code I wrote would live on and the work I did was so cool. Working for DEC was like working for Microsoft in the ’90s or ’00s, except that nobody hated your company. It was like working for Google except that nobody thought you were evil. It was like working for Amazon but pretty much everyone loved working there and it seemed like the world rooted for you to succeed. Most of all, everything we did clicked. There were some bad decisions, but the company always recovered and went on to greater glory.

I wrote CPU microcode for the VAX-11/750 and VAX 8600, worked on some cancelled projects that nobody will ever know about (ECL microprocessors, large ECL mainframes, a new RISC architecture), and my last project was working on Windows NT at DECwest. In its day the VAX 8600 micropipeline was the coolest thing since sliced bread. How many people today know or care about it? Zip.

As part of setting up a home office for my work for Solinea, I needed a large display.

My go-to display has been Apple’s Thunderbolt Display. It’s got Thunderbolt integration, (somewhat dated) Apple design esthetics, and the right pixel count. But other aspects of this three and one-half year old display aren’t so good. It’s $1K, heavier and bulkier than other (newer) displays, and the dated panels and electronics have some attributes (like response time, meh color saturation, visual reflections, and an immobile stand) that compare unfavorably to new monitors.

I looked around, and the tl;dr is that I selected a Dell U2751H 27″ monitor. Dell sells a boatload of monitors with different specs, and if you need superb color accuracy for graphics work, or a gaming display, or a 4K display, it’ll cost ya. For run of the mill coding, this monitor is just what the doctor ordered!

A crisp display, swivel base, great ports (five USB 3.0, two HDMI, DisplayPorts, Mini DisplayPort, and no space wasted for VGA!). Its specs are great, with crisp 2560 x 1440 at 60Hz resolution. The price? $600 list. I bought it new for $555 from B & H Foto.

This is a better monitor than the Thunderbolt Display for 45% less cost.

Some fine print:

It took two weeks to arrive, vs. the four days it would have taken the Thunderbolt Display to arrive.

The packaging was OK, but not as slick as Apple’s packaging. Nobody does packaging like Apple.

The installation instructions weren’t as painless as those of the Thunderbolt Display. But they were OK.

It puts a DELL logo front and center. But this is easily fixed by a strip of black electrical tape. 🙂

I recently bought a Das Keyboard Professional S for Mac keyboard, to use at work. There are already many blog posts and articles about mechanical keyboards, keyboard switches, and the Das Keyboard product line. I won’t re-hash all that here. Let’s get right to my opinions.

tl;dr

My spouse traveled to Canada for a few days. She just went a few miles over the border into Vancouver, BC.

She neglected to add an international data plan to her mobile number before she left. Because of this, she racked up $300 of data charges in 24 hours.

Every wireless carrier has at least one, and you have to add it to your account before you travel outside the country, and then delete it when you return home. But, why? My carrier knows when I’m out of the country! In fact, multiple systems between my cellphone and my account know it!

We license a vendor’s services for corporate information, like annual revenue and office locations. Their name shall be kept confidential. I’ve written about them before.

About two weeks ago, we noticed a slowdown in our API calls into their system.

We asked them about it, and they replied that they would take a look. A bit later, they said they had found the problem and were working on a solution.

Today, after working on new code, I ran my unit tests. A few tests make calls to this vendor. (Yeah, I could have mocked out the calls. But there are good reasons to not mock out calls in unit tests.) I was surprised to see those tests now fail.

Curiously, they failed because the API calls returned the response, “Customer Disabled”.

Eh…. Wut?

I switched to a browser window and tried a part of our product that used their API. I found that our product now failed with the same error. Uh oh.

I e-mailed the vendor and asked what’s up. Their answer:

We found that our service was being slowed down by your API calls. So we disabled your API key.

I am not kidding. Continue reading after you’ve caught your breath.Read More

At IP Street, most of our technology stack is open-source. Something happened last week that threw our components’ different design philosophies into stark relief.

We use Solr (with Zookeeper) for many of our search and pivot tasks, and Redis as a Swiss Army Knife. They do different things and have different consistency requirements. You can easily critique any juxtaposition as comparing apples to oranges. I think it’s instructive, because Solr and Redis are both high-performance, production-quality, and powerful tools.

Working on them within the same day, I experienced exact opposites in configuration philosophy!

Let’s meet contestant number 1

Solr is a powerful search engine. Their Cloud feature lets you shard and scale your index, and Solr will do the internal shard and node routing. Or you can direct your queries to the appropriate node for a small performance win. Being short-handedunderstaffed frugal with our peonsworker bees people, we let Solr do the routing. “Here’s a document, store it.” “I want this document.” “Here’s a pivot within a search, do it and assemble the results for me, pronto.” Etc.

Solr nodes are peers, though internally there are leaders and replicas. Solr uses Zookeeper, an Apache technology for distributed persistent configuration. Nodes do the right thing when other nodes come and go.Read More