Tuesday, May 24, 2016

Keeping up with Colony Collapse Disorder

It's now 10 years on, and we are still struggling to understand Colony Collapse Disorder.

Here's a Spring, 2016 update from a California-based honeybee expert, Elina L. Niño, who is Assistant Extension Apiculturist, University of California, Davis: Deciphering the mysterious decline of honey bees

Unfortunately, despite the article's optimistic title, there is not a lot of deciphering success to report. Parasites, viruses, and pesticides are all believed to play a certain role in the health of the honeybee ecosystem, and none of them are easy to fix.

Parasites are a big problem, literally:

Varroa feeds on hemolymph (the insect “blood”) of adult and developing honey bees. In the process it transmits pathogens and suppresses bees' immune response. They are fairly large relative to bees: for perspective, imagine a parasite the size of a dinner plate feeding on you.

Viruses are harder to study, but clearly important:

For example, deformed wing virus (DWV) causes wing deformities that prevent bees from performing normal work functions such as foraging for food. Viruses have been implicated as an important factor in honey bee health declines, but we are just starting to understand how honey bees' immune systems fight against them.

And pesticides have a significant role to play:

There are many gaps in our knowledge about neonicotinoids and other types of pesticides. We have little understanding about the impacts of pesticide combinations and how they affect developing bees and other pollinators. To fill some of those gaps, our lab is testing combinations of various agriculturally important pesticides on adult worker survival and queen development.

The U.C. Davis lab where Niño works is here: E.L. Niño Bee Lab (It's easy to remember, even if it has nothing directly to do with the movement of bodies of warmer-than-usual water in the Pacific Ocean.)

Way to go Alexi!

The ultra-achieving Girl Scout troop scores again: Alexi Pappas Seeks Competitive Opportunities As Greek Athlete

After her NCAA eligibility was up in 2013 at the University of Oregon, Alexi Pappas knew she wanted to continue running professionally. Her athletic goals have remained simple: to compete in as many major international competitions as possible and be at peak fitness for them.

Monday, May 23, 2016

Calling baloney

For whatever reason, I'm always tickled when somebody speaks up and says: "Hey, wait a minute, that's a bunch of hooey!"

So these all entertained me, more or less...

  • “Eat, sleep, code, repeat” is such bullshit
    It’s wonderful to be so dedicated to your craft that programming is all you ever want to do. I love that enthusiasm. It can carry you to great heights.

    But if you want to become the very best programmer you can be, make space for some non-programming activities. Let your brain stretch its legs and you might find a whole new level of flow.

  • Evaluating Delusional Startups
    If you’re in the market for a new gig at a hot startup, it’s worthwhile to spend some time thinking about if your sneaking suspicions are correct and the company you’re interviewing with might be full of pretty delusional people.
  • Myths of the Headless Company
    So when the founder tells you “nothing is going to change” it’s simply the guy who lacks enough business experience to actually run the business telling you his/her opinion.

    The reality is new CEOs are hired for a reason, they are hired to change things, that change typically involves a change in focus, and CEO changes are always risky. Sometimes they work out great. Sometimes the new person craters the company.

  • Don't quit that programming career yet because of AI
    Machine learning has been advancing at a tremendous rate, it's true. I hope it keeps up. But anyone who's dealt with ML in the real world can tell you that you're likely to spend more time cleaning and dealing with the data than the learning itself.
  • The fall of Rome and the ascendancy of ego and bluster
    Without measurement data researchers have to resort to bluster to hide the flimsy foundations of the claims being made, those with the biggest egos taking center stage. Commercial companies are loath to let outsiders measure what they are doing and very few measure what they are doing themselves (so even confidential data is rare). Most researchers moved onto other topics once they realised how little data was available or could be made available to them.
  • Proof of Concept Testing Should Never Happen
    If I am buying top quality equipment – why should I prove it works as its supposed to before I use the purchased product?
  • Can the Media Please Stop Referring to Company Size by Valuation?
    So why does the media do this? Why do they want to mislead readers by a factor of 20?
    • Because if makes the numbers bigger
    • And makes the headlines cooler
    • And increases drama
    In the end, because it (metaphorically) sells more newspapers.

Saturday, May 21, 2016

Things I'm reading, late May edition

So little time, so much to read ...

  • The day Google Chrome disables HTTP/2 for nearly everyone: May 31st, 2016
    Upgrading OpenSSL packages isn't a trivial task, either. Since just about every other service links against the OpenSSL libraries, they too should be re-packaged (and tested!) to work against the latest OpenSSL release.
  • What we learned from Google: code reviews aren’t just for catching bugs
    We’ve found that the most powerful benefits of code review are the subtlest to measure and describe. Code reviews have many important side effects – arguably, primary effects – that we discovered at Google and have continued to evolve at FullStory. For us, the practice of code reviews is a “bionic cultural hammer.” It’s a “cultural hammer” because it’s a tool that strongly shapes the way we work, and it’s “bionic” because it is more powerfully self-perpetuating than any passive “coding standards policy” could ever be.
  • Start-Ups Once Showered With Cash Now Have to Work for It
    The balance of power is shifting across tech start-up land. Not long ago, entrepreneurs had the upper hand. With investors eager to get a piece of the next Uber or Airbnb, entrepreneurs often just lifted their little fingers to get financing. Some investors let the entrepreneurs choose their own terms, while others gave multimillion-dollar paydays to start-up founders long before their companies were a success.

    Now investors have the advantage. Instead of venture capitalists begging to be allowed to invest, entrepreneurs are coming to them begging for cash. Investors are exerting their newfound power by asking more questions about a start-up’s prospects and taking more time to invest. Some are pushing for management changes or for financing terms that would help cushion any losses they might face.

  • Introducing Helix: Rust + Ruby, Without The Glue.
    Just like C (and unlike Ruby), Rust is a compiled, statically-typed language. Before your code can be executed, you must first run it through the compiler, which checks for and prevents a large amount of programmer errors. Instead of allowing them to bubble up at runtime and potentially crashing your program, the compiler would just refuse to compile your code.

    Unlike C, Rust has a sufficiently advanced type system (and a carefully designed set of features), which allows the compiler to guarantee runtime memory safety.

  • Let’s Talk About Amazon Reviews: How We Spot the Fakes
    The compensated-review process is simple: Businesses paid to create dummy accounts purchase products from Amazon and write four- and five-star reviews. Buying the product makes it tougher for Amazon to police the reviews, because the reviews are in fact based on verified purchases. The dummy accounts buy and review all sorts of things, and some of the more savvy pay-for-review sites even have their faux reviewers pepper in a few negative reviews of products made and sold by brands that aren’t clients to create a sense of “authenticity.” In fact, for extra cash, a company can pay one of these firms to write negative reviews of a competitor’s product.
  • A fundamental introduction to x86 assembly programming
    In this tutorial, I will help you gain a solid understanding of the x86 ISA from basic principles. I will focus more on building a clear mental model of what’s happening, rather than giving every detail precisely (which would be long and boring to read). If you want to make use of this knowledge, you should simultaneously refer to another tutorial that shows you how to write and compile a simple function, and also have a list of CPU instructions open for referencing. My tutorial will start out clear and simple, and add complexity in manageable steps – unlike other documentation that tend to lay out the information all at once.
  • NFL star Patrick Willis is thriving in retirement as a Silicon Valley tech worker
    Monday through Friday, Willis commutes to work at a Silicon Valley office park. He's got a list of favorite lunch spots nearby. Sometimes he takes video calls from home, or instant messages with colleagues after hours.

    Like so many people who share his age range and geographic area, Willis now works at a tech startup.

  • The Puzzling Plummet of RGIII
    The story of Griffin’s exit from Washington is much more complicated than the they-had-it-out-for-him thinking that has pervaded the team’s fan base. “It’s not a single-sided issue of victimization of RG3,” said sociologist Harry Edwards, who has spent decades advising the San Francisco 49ers and observing the NFL. “It’s a much more complicated and complex issue"
  • A Historical Tour of Silicon Valley - Slide Show

    I guess my favorite picture is the original Peet's location.


  • Klinsmann Names 23 Player Roster for historic Copa America Centenario
    The roster includes 15 players from the 2014 FIFA World Cup squad, and a total of 18 who have already appeared in Qualifying for Russia 2018. Veterans like team captain Michael Bradley and Clint Dempsey marshal the group boasting loads of experience. With an average of 37 caps, there are five players with 50 or more and an equal number with five or less. Meantime, John Brooks, Bobby Wood and DeAndre Yedlin lead a youth contingent that includes five players who are 23-years-old or younger

Lord Huron: a very short review

I wandered into Lord Huron the way many people probably have, via the soundtrack to A Walk in the Woods.

Trying to characterize them, I suggested that they were somewhere between Fleet Foxes and The Head and the Heart, with plenty of The Decemberists, some (early) Mumford and Sons, a bunch of The Lumineers, and perhaps even a little bit of Of Monsters and Men.

Anyway, even if it's well-trodden ground, Lord Huron do it well.

Quite well.

Cumulus: a very short review

I happened to pick up and read Eliot Peper's Cumulus.

For a book that is so trendy, so timely, so in-the-moment, it seemed somehow appropriate that I read it as an e-book. The transience, the evanescence of the e-book format just seems right for Cumulus. When everything is in the ("Cumulus") cloud, what even exists?

Anyway, back to the book.

Cumulus is set in Oakland, where Oakland resident Huian Li is the CEO of cloud computing giant Cumulus, Inc. She commutes to her office in the San Francisco Presidio by private helicopter, and lives in the "Green Zone," whose residents are transported, secured, monitored, landscaped, patrolled, and in general fully cared-for by its corporate owners.

Meanwhile, down in the Oakland flats, a loose collection of community organizers, hackers, artists, environmental activists, and others are trying to regain control of their lives in our modern over-surveilled world.

Like I said, it's trendy.

And it's written quite well, too. Here's a sample:

Vera still failed to understand how important Huian's mission was. The level of commitment required didn't leave room for fluffy concepts like work/life balance. Huian's calling wasn't a hobbyist fascination with macrame. Technology was the only scalable tool available to help shape a better future. The question was whether people chose to participate in that future or not. Huian was a harbinger of that new reality. She would stop at nothing to push forward the inexorable, beautiful, conflicted locomotive of human civilization. Dystopias were the province of the undisciplined.

"the inexorable, beautiful, conflicted locomotive of human civilization:" Peper's little capsule summary of Huian's motivation is actually a very nice assessment of both the appeal and the danger of the high tech lifestyle, and it well-encapsulates the addictive, seductive pull that Silicon Valley has upon the bright, young, aggressive, ambitious people who arrive here.

Being frank, Cumulus is a bit too pat. It follows a fairly obvious trajectory, with some other rather crudely-drawn characters who are not as interesting as Huian, and several times it seems to shy away just when it nears the brink of a true insight.

But Peper is talented, and alert, and interested in the ideas of the day. Cumulus is a fun and interesting start, and I hope he develops his story-telling skills in the future.

Friday, May 20, 2016

A catalog of potential hikes I'm investigating

There's never enough time to get up into the mountains, particularly since I don't get to go but once or twice a year.

So I spend a lot of my time dreaming about trips I might take.

I haven't taken any of these trips (yet), but I'm considering them.

If you know of anything about any of these trips, let me know!

Thursday, May 19, 2016

Quite the crew!

I had the opportunity recently to attend a reunion of a number of close colleagues of mine.

Over the years, I've worked with all of them, sometimes at multiple different companies.

Even though I've got 35 years of software development experience myself, among this collection I am still a junior programmer.

We didn't manage to get everyone who attended in the picture, unfortunately.

But at one point I was doing some back-of-the-envelope math in my head, and I computed that we probably had nearly 700 years of software development experience at this gathering.

Quite the crew.

I was a lucky fellow, to get to work with people like this.

Sunday, May 15, 2016

Oracle v Google, redux, redux

It's that time again.

The third round of the gigantic lawsuit between two of the largest corporations in the world over control of the Java programming language is underway here in San Francisco: Oracle America, Inc. v. Google, Inc.

Oracle America, Inc. v. Google, Inc. is a dispute related to Oracle's copyright and patent claims on Google's Android operating system. In May 2012, the jury in this case found that Google did not infringe on Oracle's patents, and the trial judge ruled that the structure of the Java APIs used by Google was not copyrightable. The parties agreed to zero dollars in statutory damages for a small amount of copied code. On May 9, 2014, the Federal Circuit partially reversed the district court ruling, ruling in Oracle's favor on the copyrightability issue, and remanding the issue of fair use to the district court. A petition for certiorari was denied by the United States Supreme Court on June 29, 2015. A second trial is scheduled for May 9th, 2016, in which Oracle is seeking $8.8B in damages.

Ugh, that's pretty dry.

So why do I find it so interesting?

Well, one reason is that it involves a lot of Silicon Valley corporate leaders, including a number of companies which I myself worked for, over the years: Oracle’s Suit Against Google Digs Up Old Bones

Java was a programming breakthrough, just as browsing the World Wide Web was becoming mainstream. The Java motto at the time — "Write once, run anywhere" — while always a bit of an exaggeration, pointed to the importance that software created by anyone working on anything could have. Without that notion, the Web would not work.

Sun, founded years earlier and best known for its powerful workstation computers, became one of the most influential companies of the first dot-com boom.

And those companies have a lot of history: Oracle vs. Google, Round 2: Trial begins over Java API copyright claim

A decade ago, Android developers built their OS with the help of Java APIs, which were developed by Sun Microsystems in the 1990s. When Google decided to base Android on Java, it began licensing negotiations with Sun but ultimately abandoned them. After Oracle acquired Sun in 2010, it sued Google for using the APIs without paying licensing fees. Google argued they were free to use because the Java programming language is open source, and the APIs are required to use the language.

Another reason is that the various industry titans who are being called to the stand are so wonderfully eccentric:

  • In Oracle v. Google, a Nerd Subculture Is on Trial
    Eric Schmidt sought to describe APIs and languages using power plugs as an analogy. Jonathan Schwartz tried his hand at explaining with "breakfast menus," only to have Judge William Alsup respond witheringly, "I don't know what the witness just said. The thing about the breakfast menu makes no sense."

    Schwartz’s second attempt at the breakfast menu analogy went much better, as he explained that although two different restaurants could have hamburgers on the menu, the actual hamburgers themselves were different—the terms on the menu were an API, and the hamburgers were implementations.

    No one bothered to challenge Schwartz's apparent belief that hamburgers are commonly featured on breakfast menus, as he had already moved on to confusing the jury on another front...

  • In a $9 Billion Trial, Google's Secret Weapon Is a Filing Cabinet
    During opening arguments, Robert Van Nest, the lead attorney for Google, trotted out a literal actual physical filing cabinet labeled "java.lang" for the benefit of the jury.

    A flimsy 8.5" by 11" piece of paper that says "java.lang" sits on the very top of this beige metal cabinet, which I guess indicates what the filing cabinet is even supposed to be? The first drawer is labeled "Math" in big bold letters. As Van Nest talked to the jury about what APIs were, he opened up the "Math" drawer, pulled out a file, and waved it around.


    After conferring with others, I have determined that Van Nest means to explain that the system of filing (the labels on the folders and the drawers) is the API, and that he waved around some empty folders to illustrate how Google wrote its own implementing code to "fill the folders" with, rather than "stealing" Oracle's intellectual property.

  • Top programmer describes Android's nuts and bolts in Oracle v. Google
    "This is me and my computer," said Bornstein, drawing a stick figure holding a laptop. He paused. "OK, now I've got a problem," he said, drawing a thought bubble above the stick figure to express his quandary. "Here are two numbers. Which of these two numbers is bigger?"

    Bornstein drew a book, presumably a book about Java, which would inform Stick-Bornstein how to use math.max, and the role of APIs in that.

  • The biggest problem for the Oracle v. Google retrial: Judge Alsup's reality distortion field
    The only way Oracle could counter such testimony is by calling Judges O'Malley, Plager, and Taranto as witnesses to tell the jury that the Court got it completely wrong, and in fact that the declaring code and SSO are copyrightable. But no judge should be a witness, pure and simple. And a judge should not become a witness inadvertently through the act of informing the jury of his views on a legal issue that already has been decided. Such testimony is inadmissible under Rule 605.

But anyway, behind all these corporations, and celebrities, and history, and flamboyance, what is really going on here?

Well, here's a quick summary:

  • The first trial was thought to be about patents.
  • The patent issue went nowhere.
  • But during that trial, what was thought to be a minor side-topic about APIs and copyrightability took center stage.
  • And it turns out that everyone's really arguing about two things:
    • What's an "API"?
    • How does U.S. Copyright Law apply to APIs?

So, what IS an API?

Well, it stands for "Application Programming Interface", but the most important of those three letters is 'I', for "Interface".

About 25 years ago, in the early 1990's, there was a major movement towards what became known as "Object-Oriented Computing". This was a collection of techniques computer programming which dramatically revised the entire approach to software.

Prior to object-oriented computing, people tended to think first about algorithms, and used those algorithms to guide the overall structure of their program designs.

Object-oriented computing, however, encouraged people to think about their data model, and in particular about the individual objects that their program was manipulating. Those objects might be:

  • Employees, departments, managers, and teams, in a Human Resources application
  • Drivetrains, suspensions, and tires, in a Racecar Design application
  • Missiles, warheads, and targets, in a Military Weapons application
  • Accounts and transactions, in a Banking application
and so forth.

The point is, there are particular objects, with certain behaviors, and your program is concerned with assembling those objects into higher-level applications which accomplish tasks.

And, in order to do that, your PRIMARY CONCERN has to be with the interface between those objects; this became known as the

separation of interface and implementation

The interface to an object describes what the object can do.

The implementation of the object, which is internal to that object's source code, and is not available to its callers, specifies how the object does its tasks.

Prior to object-oriented computing, people found that programs could only be built to a certain size, after which no amount of effort could improve or extend them.

Every part of the program turned out to be inter-connected to every other part of the program, a nightmare often referred to as "spaghetti code."

But object-oriented programming brought relief from that crisis, enabling the programming-in-the-large which made the industry what it is today. Here's a nifty summary from a Microsoft guide: Understanding Interface-based Programming

Getting a grasp of interface-based programming is really tough. To gain an appreciation for this style of programming, you must leave behind old habits and intuitions about writing code and look back at the evolution of object-oriented programming (OOP) and computer science over the past decade—a Darwinian saga of how the interface has made modern software designs more fit for survival. For software to survive in the ever-changing jungle of the production environment, it must have three distinct characteristics: reusability, maintainability, and extensibility. This article will provide a general overview of interface-based programming and examine these characteristics.

The Component Object Model (COM) is founded on the idea of interface-based programming; COM would have no meaning without the concept of the interface. If you are a Visual Basic programmer who is trying to understand how COM really works, you should spend the time to learn how and why interfaces are so valuable in object-oriented software design. An understanding of interface-based programming will make you a much stronger COM programmer. This, in turn, will prepare you for creating COM-based applications for distributed environments such as Microsoft Transaction Server (MTS).

Interface-based programming exists outside the world of COM. It is a programming discipline that is based on the separation of the public interface from implementation. It was pioneered in languages such as C++ and Smalltalk by software engineers who discovered that using distinct interfaces could make their software, especially large applications, easier to maintain and extend. The creators of Java saw the elegance of interface-based programming and consequently built support for it directly into their language.

If you don't know what APIs are, or what object-oriented computing is, I recommend that Microsoft article. It's extremely well-written, which is actually no surprise for Microsoft documentation (which is typically of very high quality). But many people forget that Microsoft itself was one of the true pioneers of object-oriented computing: their COM and OLE technologies are nearly 30 years old now, and still going strong.

So where does that leave us? Michael Byrne of Vice's Motherboard site tries to sum it up: What an API Is and Why It’s Worth Fighting For

We can as programmers just use Java's own implementations by referencing the Java core API, but we can also use someone else's implementation as well, or we can even write our own. We just have to make sure that the result meets the same specifications given by the Java API.

This is what Google did, roughly: It used an implementation of the Java API not sanctioned by Oracle/Sun. So, the question is whether or not that constitutes copyright infringement. It should be clearer now as to what is at stake: the fundamental divide between interface and implementation. It so happens that this divide is what much of the open-source software world revolves around, the ability to separate functionality from implementation, to build the same things in new and better ways. Watch Google v Oracle closely.

And the team at Programmable Web try to dig into it in more detail, with an excellent article from last summer: Will Oracle v. Google Mean The Death of the API economy?

Oracle's case sits upon the argument that the first and fourth fair-use factors that were mentioned before have not been met. It argues that the purpose and character of Google's use of the Java APIs is clearly commercial and that it negatively affected the potential market by creating an unlawful market domination that hurt companies that had Java licenses, while Google's Android was built without meeting Java licensing standards, namely its requirement for compatibility.

It's complicated, and not easy to understand.

And I'm not sure where I personally stand on it.

I do think that Google was wrong to take Java and change it: the programming environment on Android devices is very, very similar to a programming language called Java, but it is not Java, and perfectly reasonable Java programs (e.g., Apache Derby) do not run on Android devices, not because such programs break any of the rules of Java, but because Android's programming environment is not Java.

On the other hand, in my lifetime I have seen copyright law used as a blunt force by massive corporations to control human behavior to an absurd extent, and I'm no fan of extending the reach of such.

Certainly you shouldn't be allowed to copyright the notion of taking the maximum of two numbers. That's an abstract concept, and the fact that Java spells it

java.lang.Math.max( int a, int b);
should not be something that Oracle America, Inc., can own.

Either way, though, Oracle v Google is important, and worth paying attention to.

So there you go.

Thursday, May 12, 2016

Eurogames and Ameritrash

I guess I hadn't heard the term Ameritrash used in this particular context until I read Continental Divide: Board games reflect the culture that created them.

The article leads off with a nod to Pandemic Legacy:

Last winter, a new board game, Pandemic Legacy, did something quite rare: It became the No. 1 board game of all time on BoardGameGeek.com, beating more than 83,000 games. First printings of games usually run between 5,000 and 10,000; pre-orders of Legacy were an unheard-of 80,000 copies. But in some corners of the hobby game world, Legacy’s rise is controversial. One review said its popularity was proof that "all of these Euro lovers have secretly always wanted a taste of what Ameritrash games provide."

We haven't yet played Pandemic Legacy, but last winter my daughter introduced us to the original Pandemic game, and it has quickly moved to near the top of our regular games list.

My grand-daughter is particularly fond of Pandemic, and, I must say, is particularly good at it.

Pandemic is interesting because it is a very different sort of game:

The players are disease-fighting specialists whose mission is to treat disease hotspots while researching cures for each of four plagues before they get out of hand.


Taking a unique role within the team, players must plan their strategy to mesh with their specialists' strengths in order to conquer the diseases.


but the diseases are spreading quickly and time is running out. If one or more diseases spreads beyond recovery or if too much time elapses, the players all lose. If they cure the four diseases, they all win!

Either everybody loses, or everybody wins.

It's a very different experience than most board games, where one person wins while the other players lose.

We've tried a few other of the so-called "cooperative games," but none has been remotely as good as Pandemic

I think that means it's time to give Pandemic Legacy a try!

Tuesday, May 10, 2016

Marketing gone wild

REI, thoughtfully, alerted me to news that Merrell have released their latest hiking shoes: Merrell Capra Bolt WP Hiking Shoes - Men's

Embrace your inner mountain goat with the vegan-friendly Merrell Capra Bolt WP hiking shoes. Made for high-adrenaline hikes, their grippy outsoles let you move confidently on rough terrain.

Wait, what?


They do look like nice shoes, though, I'll give you that.

Sunday, May 8, 2016

How do you fix a bug in a building?

I happened to stumble upon a fun little essay: The Bug in the Physical Building, and I was intrigued, and it sent me on a bit of a treasure hunt.

The essay is about the building now known as 601 Lexington Avenue, and more specifically about a particular aspect of that building:

From the beginning, the Citigroup Center was an engineering challenge. When planning for the skyscraper began in the early 1970s, the northwest corner of the proposed building site was occupied by St. Peter's Lutheran Church. The church allowed Citicorp to demolish the old church and build the skyscraper under one condition: a new church would have to be built on the same corner, with no connection to the Citicorp building and no columns passing through it, because the church wanted to remain on the site of the new development, near one of the intersections. Architects wondered at the time if this demand was too much and would make the proposal unfeasible.

Structural engineer William LeMessurier set the 59-story tower on four massive columns, 114 feet (35 meters) high, positioned at the center of each side, rather than at the corners. This design allowed the northwest corner of the building to cantilever 72 feet (22 meters) over the new church. To accomplish this, LeMessurier employed a system of stacked load-bearing braces, in the form of inverted chevrons. Each chevron would redirect the massive loads to their center, then downward into the ground through the uniquely positioned columns.

It turns out that this alternate design introduced some subtle behaviors: The Design Flaw That Almost Wiped Out an NYC Skyscraper:

It was an ingenious, cutting edge design. And everything seemed just fine—until, as LeMessurier tells it, he got a phone call.

According to LeMessurier, in 1978 an undergraduate architecture student contacted him with a bold claim about LeMessurier’s building: that Citicorp Center could blow over in the wind.

The student (who has since been lost to history) was studying Citicorp Center and had found that the building was particularly vulnerable to quartering winds (winds that strike the building at its corners). Normally, buildings are strongest at their corners, and it’s the perpendicular winds (winds that strike the building at its faces) that cause the greatest strain. But this was not a normal building.

LeMessurier had accounted for the perpendicular winds, but not the quartering winds. He checked the math and found that the student was right. He compared what velocity winds the building could withstand with weather data and found that a storm strong enough to topple Citicorp Center hits New York City every 55 years.

But that’s only if the tuned mass damper, which keeps the building stable, is running. LeMessurier realized that a major storm could cause a blackout and render the tuned mass damper inoperable. Without the tuned mass damper, LeMessurier calculated that a storm powerful enough to take out the building his New York every 16 years.

The specific issue wasn't so much about the lead-bearing chevrons, or the winds, or the tuned mass damper, but about what seems like a much smaller issue: the bolts. Citigroup Center, Part 2. The disaster that almost happened relates how "original design's welded joints were changed to bolted joints during construction", and a more detailed report at CrossCurrents provides more information:

LeMessurier’s design and the tower’s construction drawings called for five, full- penetration welded joints in each of the eight-story-high diagonal steel members transferring loads from the tower’s corners to the columns at the center of each face. Offering Citicorp a credit of $250,000, the structural steel fabricator proposed substituting bolted joints. The proposal was accepted. Employing the loads at each joint calculated by LeMessurier’s firm, the fabricator designed bolted connections and prepared shop drawings that were then reviewed and approved by the engineers for fabrication and construction. Although less strong than welded joints, the bolted connections were entirely adequate for the designated loads.

But, at any rate, all this is about the bug.

In some ways, a bug is a bug. They happen.

What interested me about the story was: if you discover a bug in a building, how do you "fix" the bug?

Well, let's return to Chris's original essay:

When the error was discovered, a system was set up to make it possible to evacuate parts of New York City on short notice. Meanwhile, every night after the office workers of 601 Lexington Avenue had packed up, an army of welders opened the building up and welded over the bolted joints. They cleared out by morning when the first busy bees arrived back at their office. This was done in total secrecy. The corners are still the weakest part of the building, but the welded-and-bolted joints are now strong enough to bring the building back well above safety margins.

It's a lot easier with software; you can just issue a patch.

The line between software and hardware is blurring. I have a friend who has a beautiful high-end Fuji camera; he was telling me the other day how excited he was about a software update and how it would improve the autofocus speed and accuracy. I have another friend who has a Tesla Roadster; he was talking recently about the new software that was soon to improve his battery efficiency, cruising range, and acceleration.

But sometimes you have to go back in and repair the bolts: $1.1 million approved for plan to keep Bay Bridge bolts safe

Maroney and the seismic panel asked the committee to approve $1.1 million to design a dehumidification system to dry the rods in the foundation, come up with a grout, lubricant or chemical that will protect the rods and the holes they sit in from water in the foundation, conduct more testing to determine the dangers posed by microscopic cracking discovered in the rods, and purchase jacking equipment to test, treat and aid in future repairs to the rods.

It's just what engineers do: try to make the best design you can, build it carefully, test it, monitor it, and, if it should happen, go back and fix the bugs, er, I mean, the bolts.

Thursday, May 5, 2016

It's festival season!

OK, I clearly have not been paying close enough attention to what's going on in my home town.

Check this out: Oakland Book Festival

The Oakland Book Festival is a one-day, annual literary event. Dedicated to books, ideas, and the pleasures of literacy, it aims to serve the reading public, to encourage debate, and to celebrate the City of Oakland. It will host more than sixty writers in 2016 and is free and open to the public.

The Festival will be held at Oakland’s City Hall. Hearing rooms will be transformed into meeting halls in which journalists, fiction writers, historians, poets, editors, critics, and memoirists will convene on panels to discuss the challenges of gentrification, cosmopolitanism, diversity, tolerance, conflict, education, surveillance and security, labor, libraries, archives, magazine publishing, imprisonment, civil disobedience, whistle-blowing, prayer, food production and consumption, activism, and the future. Panels are moderated by experts and are oriented toward encouraging conversation with the audience. More than a literary trade show or a series of readings, the Festival asks authors to discuss ideas, to bring their expertise to bear, to share their experience: to challenge, elevate, and inspire one another and those in attendance.

Way to go, Oakland!

The full program is here.

Monday, May 2, 2016

Geez I don't know

Is Wright Satoshi? Or not?

Gavin Andresen says yes.

Dan Kaminsky says no.

Update: Then the story got more bizarre.

I believed that I could do this. I believed that I could put the years of anonymity and hiding behind me. But, as the events of this week unfolded and I prepared to publish the proof of access to the earliest keys, I broke. I do not have the courage. I cannot.

Sunday, May 1, 2016

What more can you say?

Here's how you know you've finally arrived.

You're taking it easy on a Sunday afternoon, leafing through one of your favorite books: Wild Northern California: A Guide to 41 Roadless Recreation Areas; Including the Entire Sierra Nevada, when you come across what might be the most perfect sentence ever to grace a guide to the wilderness:

The trail begins on the north side of the highway, several yards west of the trailhead parking area, and is indicated by a sign reading TRAIL.

Two gig just isn't what it used to be

The Apache Derby database system is now in its twenty-first year of existence, having been born in 1995 by a stealth mode startup named Cloudscape out of the ashes of a skunk-works project at Sybase to write an object-oriented database.

It turned out that the world didn't really want that object-oriented database, but the Cloudscape team wrote a fine modern database system, entirely in 100% pure Java, and although Cloudscape the company failed (sold to Informix who were in turn sold to IBM, who then donated Derby to the Apache Software Foundation more than a decade ago), Cloudscape the database (now Apache Derby) lives on.

One of the features that Derby has always had is the BLOB and CLOB datatypes.

Well, I happened to be working on a Derby bug this last month, involving the BLOB/CLOB support.

The bug shows up when you first export all of the BLOB or CLOB values in a single table into an external file, by calling SYSCS_UTIL.SYSCS_EXPORT_TABLE_LOBS_TO_EXTFILE, and then, subsequently, import those values back into the database by calling SYSCS_UTIL.SYSCS_IMPORT_TABLE_LOBS_FROM_EXTFILE.

For the bug to occur, at least one of the BLOB/CLOB values in the external file must begin at a location which is greater than 2147483647 bytes from the start of the external file.

The bug, of course, was simply that the Derby code was using a Java int variable for the file offset, rather than a Java long variable, and so I think I've nearly finished fixing it.

As part of the fix, I was looking at a companion variable in the code, which holds the length of the BLOB or CLOB, which caused me to go look up the maximum length of a BLOB or CLOB value in Derby. And, indeed, the maximum length of such a value is 2147483647, so I didn't need to change the length variable, just the offset variable.

Cloudscape was originally intended, in those heady days of 1995, to be run on mobile devices, which back then were things like the Apple Newton, or the Research in Motion Blackberry.

Those mobile devices typically had an ENTIRE STORAGE CAPACITY of, at the high end, 64 megabytes or 128 megabytes, so I'm sure that having a two gigabyte limit on the length of a BLOB or CLOB value seemed vastly over-engineered at the time.

But the original designers probably didn't anticipate that Derby would live for 21 years.

Today's generation of mobile devices routinely have 256 GB, 512 GB, and sometimes even more, for their storage.

I'm sure that, at some point, enough people will be impacted by the two gigabyte limit on BLOB and CLOB values in Derby that somebody, maybe even me, will change it.

But that time hasn't come yet. For now, I'll just fix the file offset, and move on.

Sometimes the news is that there is no news

Officials unable to locate source of strong gas smell throughout Alameda County

Alameda County Fire department and PG & E officials were unable to determine the source of a natural gas odor smelled by dozens of residents in Alameda, Oakland, San Leandro and Castro Valley on Saturday.

Dozens of residents in a three-mile radius in the area of Fiji Lane, Remmel Court and Melrose Avenue in Alameda called to report a strong natural gas smell around 7 p.m., said Alameda County Fire Capt. James Colburn. Although emergency responders also smelled the strong odor, they were unable to determine the source, he said.

The smell eventually disappeared. No residents were evacuated and the scene was determined safe and cleared.

But the smell appears to have traveled as it was then reported to have wafted east toward San Leandro and Castro Valley, said PG & E spokeswoman Libby O'Connell.

PG & E continued to investigate the odor using a sensitive gas-detecting equipment. No gas leaks were found

So there you go.