XML Namespaces in a Nutshell
Permalink
Aug 05, 2016
Programming

I've said several times that XML Namespaces are simple, but I don't have a good proof document. So here it is.

Read the rest...


Permalink
Feb 01, 2016
Bloviation

Around about 1998, I was talking to my electronic music teacher and ethused about the day that would come when we could put, say, everything Mozart ever did on a single cube, holding my fingers up in the air separated by about an inch. "You know, not everything Mozart did was great." "No, I get it, I just mean him as someone who put out a lot of stuff. Everything the Beatles ever did would work, too."

Silly me. I thought it would take a cube.

For $3, you can get the Big Mozart Box and for another $1, the complete Mozart symphonies. This clocks in at approximately 2.6GB of reasonable quality MP3s. (Not the bestest possible, but certainly pretty good.) It's not everything he did, I don't think, so let's call it 4GB total. That's a mere 1/32nd of a 128GB SD card, which is very much an areal storage device and not a cubic one.

In other news, if you've been inclined to buff your classical music collection, it turns out to be really cheap to just buy the MP3s, even if you've already got Amazon prime.


Permalink
Jan 21, 2016
Bloviation

The generation gap just isn't what it used to be.

A couple of weeks ago I watched this video, a weird lip-sync riff on Star Wars. Fine. A moment's amusement, sure, and on I click.

Two days later I went to a birthday party with my kids, and as the older kids were running around I hear one of the 12-year-olds murmuring the lyrics of this song to himself.

Meanwhile, what are they playing on the computer? Minecraft. I play Minecraft on my tablet too. Maybe not as much, but, still.

Did I hear an acronym or slang term I don't understand? Pop out the smartphone, 5 seconds on Google, "oh, yeah, that makes sense".

The generation gap just isn't what it used to be.


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...


Past Posts ->

 

Site Links

 

RSS
All Posts

 

Blogroll