I went to a talk last night by John Allspaw at Etsy, about alerts and how they are hard to get right.

The short story is, signal-to-noise. Most alerting systems don’t alert, because they are largely false-positive. Due to sheer volume, the recipients of those alerts start inventing their own subjective algorithm as to what deserves attention.

Those human factors are the hard part. Alerts require serious design, and need to be designed with the knowledge that they will be consumed in the context of several other alerting systems.

(By my definition, anything feed-like is an alerting system if you let it be. Error logs, emails, Twitter.)

If an alert does not require action, why was I alerted? It’s literally spam at that point.

It’s understandable why we put up with this. A false positive is low cost, but a false-negative (the alert you needed but didn’t get) is high cost. So we err on the side of more.

See the problem? Bad alerts become non-alerts, but there are some we can’t afford to miss. Conundrum.

Solutions include semi-obvious things like improved UI, where the alert tells you why it alerted and what it expects you to do. Graphs. Sounds. There are interesting ideas.

My idea is that change is what we care about, and what we should work to define. That means calculating not just levels of (say) RAM usage, but velocity, acceleration, and even jerk.

I also think there is an opportunity for ML-type learning within the alert system. Every alert you get, you respond ‘useful’ or ‘not’. Then you classify. Not unlike spam.

discuss on hacker news

At the risk of revealing my lack of a CompSci degree: what if ‘source code’ were replaced by serialized syntax trees?

What if the canonical ‘source’ of an application were not source code, as created by humans, but rather a serialized format of the syntax tree?

The workflow would go like this. You check out the repository. You make changes, and debug, to your satisfaction. Your local changes are still ‘source code’ as we currently understand it.

Then, instead of committing your changes, you feed your source code to the complier/interpreter, which creates a naive syntax tree. This syntax tree preserves the names of your symbols, and does no optimization.

The syntax tree is then decompiled into new source code, and written out. It is logically and semantically the identical to the original text, but style choices you may have made are swept away.

The generated source code is still meant for human consumption. It would need to preserve things like names and comments.

Among the things that are obviated: formatting, obviously, but also storage. The serialization includes rules for how the tree is persisted to disk.

It also means that changesets consist solely of logical & semantic changes. Syntactic and formatting changes are eliminated. IDE’s could facilitate a lot of this. Heck, perhaps this process could happen right inside source control, with the appropriate plugins.

The idea would be to eliminate a class of friction within teams. Fewer subjective decisions.

(This might remind you of whitespace-significant languages, which are good for disposing of formatting arguments among programmers.)

I don’t doubt this would require a fair amount of work so that it functions for humans. My question is, is there a logical dealbreaker in this idea? I suspect it’s been attempted, and would love to hear stories.

discuss on hacker news

Addendum: it didn’t take long for it to be pointed out that this is a thing, and that Lisp is the canonical example. So a further question: what human factors prevent it from becoming common?

I use CoffeeScript here and there. And JavaScript everywhere else.

Depending on the scenario, and this is a matter of taste, CoffeeScript is more elegant, readable, and usable.

When offering this notion, inevitably there is a complaint about “debugging.” CS is generating code, it’s a layer of abstraction, which will lead to frustration, etc.

The question is, compared to what? When JavaScript is not behaving as you wish, what do you do?

You debug it. You log, you hit breakpoints, and most importantly, you build a mental model of how the program is behaving.

Did you learn about truthiness and ‘this’ in JS by logic? Ex post facto maybe. But you debugged your way to that understanding.

CoffeeScript is identical in this regard. It has syntax, and semantics. You write code, see what it does, change it, see what it does. You build a mental model.

CoffeeScript doesn’t make a program easier to debug; it also doesn’t make it harder. Semantics. Behavior. Mental model. Rinse and repeat.

What CoffeeScript does do, in my experience, it make trivial debugging less likely.

Because it’s whitespace-significant, you are unlikely to miss a closing brace. Because it has sensible iterators, you are not going to fuck it up Google it for the 50th time. Because it has ?, you are not going to choose among false, falsy, null, undefined, typeof, instanceof. For the 50th time.

Maybe I’m projecting. I am sure you’re adept with the above issues. You’ve memorized them over time, hammered JS’s behaviors into your head, experimented and built a robust mental model. Which is great!

But there might be a bit of challenge accepted in there, if we’re honest. JS is tedious and idiosyncratic — which is how normals see programming in general. Our ability to reason through that stuff to make something useful is where we derive our reward.

For me, and more so over time, shipping is where I derive my reward. Correctness is rewarding. Code that looks like what it does, is rewarding. So CoffeeScript, for me, is rewarding.

–

A couple of addenda — in terms of the ‘taste’ thing, I’ve settled on CS on the server (if using node) and plain JS on the client. The difference is that the latter requires a build step while the former does not. coffee app.coffee just works, no hint of JS.

And source maps are a nice tool, so I can imagine that objection to the CS abstraction. Looks like CS got support for that as well, but haven’t yet tried it.

Amtrak is improving its wifi, it claims. Fine. The problem is, it’ll never be faster than your phone’s 4G connection.

Why? Because Amtrak’s wifi uses the same 4G network. So take your 4G, send the bits through an additional router, contend with your neighbors’ bits, and you’ve got Amtrak wifi. (This is true of the wifi on the bus too, it’s not about Amtrak specifically.)

Now, in theory, there are some decent reasons to use their wifi. If you’ve got a cap on your data plan, you can offload some of it to Amtrak. The train should have a big-ass antenna which might get a better signal that your device. Whether these things overcome the other issues, YMMV.

Wifi is really designed for small, controlled spaces, like apartments and offices. The telecoms’ stock in trade is data over large, uncontrolled areas. If you’re on the train, just use your phone.

A French ISP has started blocking ads at the router level for its customers, enabled by default. Advertisers are, not surprisingly, upset.

What Free.fr is doing will probably not turn out to be legal. It’s clearly meant as a poke in the eye to content-driven advertisers like Google. It ensures a re-arguing of net neutrality.

What I haven’t heard is any objection by users. The move is, politics aside, a differentiator for the ISP’s service. It’s a product decision.

If consumers aren’t objecting, that tells me ad-blocking is an economic positive as judged by the market. It’s not unlike music piracy in the days of Napster: illegal, damaging to suppliers, but desired by consumers.

So a reasonable analysis would be not unlike Steve Jobs’ understanding of music piracy: a huge market signal to offer a better product.

Sadly, I am sure regulators will not allow it to stand. That’s a shame — I’d rather see customers vote with their wallets, and let Free and Google fight it out, ie, negotiate.

The Internet works because it is a voluntary system. Big ISPs peer with one another, often without money changing hands.

It’s inevitable that “peering” arrangements will also need to be made between content providers and ISPs. I’ve said in the past that the distinction between “content” and “infrastructure” is spurious, an accident of history.

Let’s have them sort it out. That’s what progress looks like.

discuss on hacker news

That Apple, and other companies, are deciding to move manufacturing back to the United States is evidence of the diminishing importance of labor costs in decision-making. This implies several things.

Labor is around 4-5% of the retail cost for a computer, according to the article, and will continue to fall as automation increases. Labor costs are a bottom-line decision: a way to extract profit from a sale that has already happened.

As labor costs become less important, companies will instead look for gains on the top-line: competitive advantage that results in the sale being made in the first place. Shipping more quickly, customizing for local markets, and “Made in [your country here]” branding are aided by manufacturing locally.

Another way to think of it is a move up Maslow’s hierarchy. The basic need of manufacturing is satisfied at a low cost, such that it is no longer a focus of companies. Looking up the hierarchy, firms appeal to their customers’ more refined concerns.

Further, one hopes this change will obviate complaints that China and low-wage countries are “stealing jobs”. On the one hand, it neutralizes nativist, uneconomic arguments — a good thing. On the other, low-wage manufacturing is a large part of Chinese citizens’ enormous move up from poverty in recent decades — if “low-wage” is no longer a competitive advantage, the bottom might drop out.

Our assumptions about “cheap” Chinese manufacturing and its role in the world economy are likely to change more quickly than we realize.

This article offers a lot of sound advice on hiring a designer. As techies, we’re often out of our depth in knowing what a good designer is — often, we hire a decorator instead (or as the article calls it, a stylist).

Style is important, but it’s not the main goal of design. Design encompasses the user’s whole experience. Design is the product.

The designer is the user’s advocate. I mean that in the full political sense: they are a public defender making the case for a client.

It’s a political hire, because the interest of many employees is not aligned with the user — more so in a larger company.

Techies, for example, often want to build what’s most technically interesting. Or, we want the design to be decided, so we can implement, which we’re good at. These aren’t bad things! But they are orthogonal to the user’s needs, or worse.

We’re unlikely to question the utility of a screen, or a button, or a set of fields. We’re unlikely to say “this whole chunk of code does a disservice to the user”. Someone needs to be focused on optimizing those things, and they need to be persuasive.

Make your design hire about not just taste (which is critical) but for their ability to articulate the user’s point of view. And put them in a position to argue.

discuss on hacker news