Permalink
Dec 13, 2015
Bloviation

In the last few years, there's a really good metric for "movie will be bad" that I've noticed: If Subway gets the license for their kids meals, it's not going to be a very good movie.

I first noticed this when Subway got the Brave movie license. By then Pixar had repeatedly fooled me with trailers that didn't seem all that great, but turned into fantastic movies, so even though the Brave trailers didn't wow me, I was open-minded about it. But then Subway got the license, so I put off viewing it. It turned out to be the almost worst Pixar movie to that point, though it narrowly beat the previous year's Cars 2 on metacritic. And I still haven't seen it. (Or Monsters University or The Good Dinosaur.)

Why do I mention this? Well... guess what license Subway has now? Star Wars: The Force Awakens. (That link will rapidly decay, of course, so you'll have to take my word for it in the future.)

That's... uhh... surprising... and probably not a good sign. Personally I'm generally with "Plinkett" on the Star Trek movies that J. J. Abrams made; certainly very fun, felt like a demo reel for Star Wars more than Star Trek. As long as I didn't try to pretend it was Star Trek, it's at least fine entertainment. So I actually expected the new Star Wars to turn out OK.

But the Subway Movie Metric says it's not going to be good. Well... time will tell. I won't call this a "prediction", but it's at least something to keep an eye on.


Avoiding Reflection (And Such) In Go
Permalink
Dec 03, 2015
Programming, Golang

So, as previous posts show, I like Go well enough. But as a computer-language polyglot, "Go programmer" is not part of my identity, and I try for a balanced view. It is very human to go overboard in both praise and criticism, both easy to find online.

I open with this because this post will take a, ahh, let's say nuanced position on Go, in that it is going to agree a bit with both sides. Go's type system is weak and there are cases where you can only accomplish something via interface{}, reflection, copy/paste, or code generation... but in a rush to talk about what Go doesn't have, what it does have is too often neglected. When using a tool to solve problems what matters is whether there exists a good solution with that tool, not whether a direct port of a good solution from some other tool works. There certainly are real problems that lack good solutions in Go, but that set of problems is smaller than is sometimes supposed.

Some languages provide many power tools, and it is easy to use a bit of one and a bit of another without ever using any individual tool very deeply. Go provides you only a few tools, so you should use each fully.

If your Go code is a horrible copy/paste disaster, you must figure out whether it is because you are not using tools fully, or if you are missing tools. If you are missing tools, use another tool set. I do not consider that any sort of "concession", because I'm not too interested in whether you use Go; I'm interested in showing people how to fully use tools. All of these techniques will work in other languages as well, with varying degrees of convenience.

Read the rest...


Permalink
Sep 15, 2015
Not too long ago, flying could be a relatively pleasant experience, but executives focused on cutting costs have stripped away everything flyers associated with luxury or even dignity. Food, baggage handling, boarding in a logical manner: Things once taken for granted now must be paid for or done without. Flights are more crowded than they’ve been since World War II, when they were carrying troops. And on a recent Ryanair flight, I discovered that not even water was free. - Why
Does Air Travel Make People So Grumpy?

There's a lot of money out there for someone who solves one of American-style capitalism's core problems... how do I signal to a corporation that I'm willing to pay slightly more to get service that doesn't have all the corners filed off? And how do we make this palatable to people?

I don't mean premium service. I mean just that... service without every corner cut. If I'm buying a $100 item, I'd rather pay $110 for something where they used metal for the critical component instead of plastic, or quality metal instead of cheap metal. I'd rather pay the pennies more for quality screws that won't rust closed in a year.

In theory, airlines have solved the problem. With many companies you can easily pay another ~20% of the ticket price for "enhanced economy" seating, with more legroom and better seats. But that's obviously not preventing the stream of complaints, so obviously it's not a palatable solution.

Is there a solution at all? If consumers at scale simply pick the cheapest option regardless of anything else, the answer is no. The market can only go in one direction, and given that that leaves the service providers with no other option, it is hard to blame them in good faith. But I'm not ready to make that call.

There are some other ways that seem to at least partially work. You can go to Wal-Mart and get something with all the corners cut off, plus a few bits of the core product, but you can also go to Target and get something that is cheap, but not quite that cheap. Supermarkets also now have so many products on the shelves that you can almost always either buy the cheap olive oil, or a more premium option.

But there's still a lot of markets where price is relentlessly driven downward at all costs (pun half intended), and it would be great if there was some reliable way at scale to coordinate a difficult-to-forge signal of quality that said "This has been made cost-effective, but not actualy 'cheap'".

Solve that to make a lot of money.


Permalink
Jan 23, 2015
Bloviation

It is impossible to deeply understand a solution before you have the problem.

Let me give you an example that probably all my readers can relate to: Mathematics education. Do you remember first seeing the quadratic equation and wondering why you should care? Or even if you were a math nerd like me, can you understand why someone would be asking themselves that at that point?

Read the rest (1132 words)


It's 2015. Why do we still write insecure software?
Permalink
Jan 19, 2015
Programming, Golang

I've read a lot of programming blogs, and if you're reading this, you probably have too. So let me tell you up-front this is not your usual security rant that boils down to "just try harder!" Let's talk about smart, experienced programmers who are trying to write secure code, even if they are not security "experts" per se. This is an important set of people, because there is more security-related software in the world to write than can be written by security experts.

In a perfect world, setting that as the target audience would conclude this essay. As your browser's scrollbar shows in the full view, this essay continues on for quite a while. Alas, decades of experience and a trained reasonably high intelligence are not sufficient to write secure software in the current coding environment.

That's also the highest amount of qualifications that can be feasibly brought to bear at any reasonable scale, so in practice that's equivalent to saying it's impossible to write secure software in the current coding environment.

Let's talk about why it's so hard. My thesis is simple:

We write insecure software because our coding environment makes it easier to write insecure software than secure software.

But exploring what it fully means can lead some surprising places. Please join me on a journey as I try to show you why that is not trivially true, but in fact, profoundly true. We do not occasionally pick up insecure tools, like a broken encryption routine or misusing a web framework; we are fish swimming in an ocean of insecurity, oblivious to how steeped in it we are.

Read the rest...


<- Future Posts Past Posts ->

 

Site Links

 

RSS
All Posts

 

Blogroll