The Daily Parker

Politics, Weather, Photography, and the Dog

Detecting Alzheimer's in a novel

Researchers used the Iris Murdoch's last novel to quantify how Alzheimer's first signs show up in language:

As [neurologist Peter] Garrard explains, a patient’s vocabulary becomes restricted, and they use fewer words that are specific labels and more words that are general labels. For example, it’s not incorrect to call a golden retriever an “animal,” though it is less accurate than calling it a retriever or even a dog. Alzheimer’s patients would be far more likely to call a retriever a “dog” or an “animal” than “retriever” or “Fred.” In addition, Garrard adds, the words Alzheimer’s patients lose tend to appear less frequently in everyday English than words they keep — an abstract noun like “metamorphosis” might be replaced by “change” or “go.”

Researchers also found the use of specific words decreases and the noun-to-verb ratio changes as more “low image” verbs (be, come, do, get, give, go, have) and indefinite nouns (thing, something, anything, nothing) are used in place of their more unusual brethren. The use of the passive voice falls off markedly as well. People also use more pauses, Garrard says, as “they fish around for words.”

For his analysis of Murdoch, Garrard used a program called Concordance to count word tokens and types in samples of text from three of her novels: her first published effort, Under the Net; a mid-career highlight, The Sea, The Sea, which won the Booker prize in 1978; and her final effort, Jackson’s Dilemma. He found that Murdoch’s vocabulary was significantly reduced in her last book — “it had become very generic,” he says — as compared to the samples from her two earlier books.

Apparently there's a movie about Iris Murdoch too.

Standard, Core, and Framework

Let me elaborate on last night's post.

Microsoft has two flavors of .NET right now: the .NET Framework, which has been in production since February 2002, and .NET Core, which came out in June 2016. .NET Core implements the .NET Standard, which defines a set of APIs that any .NET application can use.

Here's the problem: The 18-year-old Framework has a lot more in it than the 2-year-old Standard specification or Core implementations. So while all .NET Standard and Core code works with the .NET Framework, not all Fx code works with Core.

Where this bit me over the weekend is dealing with Microsoft Azure Tables. I store almost all the data in Weather Now in Tables, because it's a lot of data that doesn't get read a lot—Tables' primary use case. There are .NET Standard implementations of Azure Storage Blob, Azure Queues, and Azure Files...but not Azure Tables. The latest implementation of Microsoft.Azure.CosmosDB.Table only supports the .NET Framework.

And that's a problem, because the new version of the Inner Drive Framework will follow .NET Standard 2.0 (or 3.0, if it comes out soon).

So yesterday I spent an hour going in circles before finally getting a definitive answer on this point.

Support for Azure Tables will happen soon enough, and I have a lot of documentation to write before the new Framework is ready for prime time. But I really wanted to tie a bow on it this weekend.

Waiting for an update

I'm mostly done with a major revision to the Inner Drive Framework, and I've discovered, to my horror, that one part can't be done yet. Microsoft Azure Table support doesn't work with .NET Standard yet.

This will make more sense at some point soon.

Stuff to read later

Of note:

Fun times!

My daily living hell

We've known this for 50 years: open-plan offices do nothing good for companies except reduce rent costs, but they do a whole lot of bad. They are not "fun;" they are not "collaborative;" they are not "start-uppy." They just suck:

Over the decades, a lot of really stupid management fads have come and gone, including:

  1. Six Sigma, where employees wear different colored belts (like in karate) to show they've been trained in the methodology.
  2. Stack Ranking, where employees are encouraged to rat each other out in order to secure their own advancement and budget.
  3. Consensus Management, where all decisions must pass through multiple committees before being implemented.

It need hardly be said that these fads were and are (at best) a waste of time and (at worst) a set of expensive distractions. But open plan offices are worse. Much worse. Why? Because they decrease rather than increase employee collaboration.

Previous studies of open plan offices have shown that they make people less productive, but most of those studies gave lip service to the notion that open plan offices would increase collaboration, thereby offsetting the damage.

The Harvard study, by contrast, undercuts the entire premise that justifies the fad. And that leaves companies with only one justification for moving to an open plan office: less floor space, and therefore a lower rent.

As an introvert in a field that requires concentration, minimal distractions, and time to reflect and think about what I'm doing—not to mention, a field predominantly comprising introverts—it's even worse.

I wish I had at least a cubicle.

The Big Disruption

I started reading Jessica Powell's online novel The Big Disruption last week. It's hilarious. And it has a lot to say about the archetypes of software development.

The premise is that the monarch of a fictional country has been exiled to California, where he found work first as a janitor at Stanford and then at a hot startup. He applies to a Google-like company and gets hired—but by accident, as a product manager.

Sample:

Arsyen washed his hands and returned to the cubicle, armed with his new vocabulary.

When Roni asked Arsyen about prioritization, Arsyen asked, “Is this on the roadmap?”

When Sven suggested adding images of attractive women to the car dashboard, Arsyen rubbed his chin.

“Does this align with our strategy?”

When all three looked to him for an opinion in how best to implement Symmetry Enhancement, Arsyen stood and put his hands on his hips.

“Does this align with the strategy on our roadmap?”

No one seemed to notice anything was amiss. If anything, it seemed like product managers just asked questions that other people had to answer.

“Good brainstorm, everyone. Let’s break for lunch,” Roni said. “Oh, and Arsyen, this is still very confidential, so let’s get this whiteboard cleaned off.”

Arsyen jumped up and began to wipe the whiteboard clean as Sven and Jonas scooted their chairs back to their desks. Arsyen was pleased that product managers seemed to have some janitorial tasks in their role. Maybe this wouldn’t be such a stretch after all.

I can't read it at work because I would have to explain why I'm laughing so hard.

Shut. The. Front. DOOR.

Via Raymond Chen, Eric Shlaepfer built a 6502 emulator out of full-size components:

The MOnSter 6502

A dis-integrated circuit project to make a complete, working transistor-scale replica of the classic MOS 6502 microprocessor.

How big is it?

It's a four layer circuit board, 12 × 15 inches, 0.1 inches thick, with surface mount components on both sides.

Can you hook it up inside an Apple ][ and run Oregon Trail?

No, not directly. It's neat to think of plugging the MOnSter 6502's in-circuit emulator (ICE) in-circuit replica (ICR) cable directly into a socket inside an Apple ][, but that wouldn't actually work. The Apple ][ design relies on a number of clever tricks that derive timing for video generation and peripheral control from the main clock signal — all of which will fail if you need to run at a slower speed.

Are you going to make one out of vacuum tubes next?

No.

Make sure you watch the 2-minute video.

Morning reading list

Before diving back into one of the most abominable wrecks of a software application I've seen in years, I've lined up some stuff to read when I need to take a break:

OK. Firing up Visual Studio, reaching for the Valium...

Lunchtime reading list

While trying to debug an ancient application that has been the undoing of just about everyone on my team, I've put these articles aside for later:

Back to the mouldering pile of fetid dingo kidneys that is this application...

The tragedy of Agile

Uncle Bob riffs on Martin Fowler's speech at Agile Australia this week. He is saddened:

It was programmers who started the Agile movement as a way to say: “Hey look! Teams matter. Code should be clean. We want to collaborate with the customer. And we want to deliver early and often.”

The Agile movement was started by programmers, and software professionals, who held the ideals of Craftsmanship dear. But then the project managers rushed in and said: “Wow! Agile is a cool new variation on how to manage projects.”

There’s an old song, by Alan Sherman, called J. C. Cohen. It’s about a subway conductor who did such a great job at pushing people into the train cars, that he pushed the engineer out. This is what happened to the Agile movement. They pushed so many project managers in, they pushed the programmers out.

The programmers continued to pursue Agile as it was originally conceived. Read the opening line of the Agile Manifesto: “We are uncovering better ways of developing software by doing it and helping others do it.” It is Software Crafts-men and -women who are continuing that work. It’s not the project managers in the Agile movement. They’re off pursuing something else?

He has hit on the sadness all us old craftsmen feel when we encounter Management.