bolson

Just finished reading "V for Vendetta" and an article by Moore about the creative process and having just read a good piece of art I wonder if my mind is just too rigidly practical to make good art.
The world needs practical people, that's good in it's way, but, I do sometimes daydream and wish I could create good art that moved people.
(yeah, lots of practice, making lots of bad art, hundreds and thousands of hours etc.)

We were driving to DefCon. We were somewhere around Barstow when the network went bad. Someone was war-driving us, right there in traffic, one of the other cars next to us, was sniffing and spoofing the cell net and advertising about a dozen honeypot wifi nets. I saw about a hundred attacks going out, looking for the last couple years worth of exploits in iOS, Android, and Windows. Of course I know this because I was pretty live-wired myself. I was working up a suite of attacks and countermeasures for the capture-the-flag competition when I noticed all this. “Fuck”, I said. “all these fucking packets.”
“What?”, j33 said from the driver’s seat.
I told him. “Some fucker’s trying to hack every phone on this highway.”
j33 pulled over. “Your turn to drive.” he said. “I gotta pwn this guy.”

I went out of range of my phone net some time Friday afternoon, and didn't come back until about 1:30 Monday. I didn't implode. I was busy doing awesome things with awesome people, and probably most of the technology being used was cameras. I managed to borrow a phone that worked to send one email; forgot until too late to send another email (sorry R); but probably everything turned out fine.

Programming almost isn't about performance anymore. Performance has to be good enough, but most problems are small enough that's pretty easy. Most of the programming problems at my current and previous job are about managing complexity. We have to write a big complex piece of code that manages lots of attributes and has lots of rules and does lots of actions. We have to do that in a way such that it works in the short term of days or weeks for whatever feature we're adding this time, and we have to do that in such a way that we can come back to it next month or next year and do something completely different.

Last night I went out dancing to jiveboston.com electro-swing.
The music was too loud (good thing I had earplugs) and the DJs put on a good continuous mix, but the monotonous techno thump-thump beat drown out any jazzy syncopation from the source material. On the up side, it was actually pretty fun to do some straight stepping swing and blues to that music and when people were aghast at what horrible noise they were playing I just laughed and grooved to the dub-wub-wub.
I had talked to three people about maybe being there, and none of them came, but I had unexpected fun and excellent dances anyhow.
I wish it was less loud, and earlier (10pm - 2am is not my prime time) and I wish I could have the fun I had there in an environment with those modifications.

In about a week I'm going to start a new job and it will be the first time I've worked for a company that was about making things and selling them. I've always been doing pure tech where the software itself or the service it provides is the business and I'm making it directly. I mentioned this to one of my future coworkers and he recommended to me the book "The Toyota Way". Okay, I'll take that as a book about manufacturing I should read before going into that.

The book is written by an obvious Toyota fanboy. If you removed the word 'Toyota' from the book throughout it would set off my faddish-thinking and cultish-thinking bullshit detectors a little less, but on the other hand it's reassuring that all of these stories are backed by actual functioning companies that make billions of dollars of real successful stuff. You could very nearly call the book 'Wholistic Manufacturing: Putting Human Values into Making Things'. This isn't actually that book, but maybe in five or ten years someone will write that book. Bonus points if it includes the "Cradle to Cradle" book team.

None of the book is about nuts and bolts and assembly lines and welding. It's really about people and management and philosophy and how to build a group of people and organize them such that they can effectively execute manufacturing. Having had some suboptimal experiences with management in the last few years, it's fascinating to read about a (perhaps utopically optimistic in some points) description of what a good management process can be. It occurs to me that since I never got a class in it and haven't quite picked it up organically, maybe I ought to read some more books on how management and workplace teamwork are supposed to work. "The Toyota Way" has a lot of good sounding points on philosophy and practices and work distribution and rewards and communication; but it admits that it's no recipe for instant success and there's still lots of personal hard work to be done implementing and learning and understanding how to actually make the system happen. (But really! You can make your workplace better by organizing it this way!)

A practice somewhat synonymous with the Toyota way is 'lean' manufacturing, with smaller inventories and smaller lead times and just-in-time flow and some characteristic signaling systems. The low-inventory efficiency focus of it reminds me of some of the personal minimalist/simplification philosophies I've heard lately. It may also be prompting me to actually clean up my home office space.

The part I'm most skeptical about is about the interplay of standardization and innovation, and I think that deserves a post all to itself.

At Arisia, Sunday at 1pm I'll be taking part in "Arisia Lightning Talks" in which Arisians distill down something they find fascinating and wish to share into the essence that fits in 5 minutes. I'll be talking about elections, two notably messy elections, a better way, and a false better way. This may be review for anyone I've talked to, ever, but I still hope to make it a good punchy five minutes.

I wish the go language had subclassing or macros or templates or something. These are all ways of reusing code without copy and paste. A macro or a template can be applied by the compiler to apply the same code pattern to different data. Subclassing can make things applied to the old data also apply to a new expanded version of that data.
Right now this lack is making me kinda hate writing a container/collection class in go. If I write a LRUCache class, but then want to extend it to be an LRU cache which also expires cached elements by HTTP rules (a normal pattern of thinking for class design in Java or C++) in go I'm going to wind up copy and pasting the entire implementation in order to make an extended version of it.
In Java (or very nearly C++) I'd write:

class LRUCacheEntry {
	Object it;
	int foo, bar; // some metadata to track
}

then

class LRUHttpCacheEntry extends LRUCacheEntry {
	long age; // more metadata to track
}

The subclass gets all of the members and functions of the superclass, and a little bit more. Go is missing this kind of composition or extension.
If the LRU cache behavior was written as a template or a macro, it might be applied to anything that had the right set of fields.
Instead, Go is advocating that classes implement interfaces of accessors. I'm annoyed at having to write lots of accessors, and I'm annoyed because I wanted to come to Go to write efficient and fast code which would compile and compete with the runtime speed of C or Java. Sure, requiring a virtualized function call to access a variable isn't the slowest thing ever, but do a few billion of them and I'll still be annoyed that other languages have good ways around requiring that.

The Porter Square strip mall has a strip of solar panels along the facade, but as shown in that Google Maps aerial view, most of the roof is not covered with solar panels.
What if it was covered with solar panels? Rough measurement from that map says the roof is roughly a rectangle 600ft by 87ft. Wider in some places, probably obstructed in others, I'll go with that and say its 52200 sq ft. Multiply that by the cosine of 40 degrees to account for the amonut of roof shaded by a tilted panel. 39987. There's a rather economical Kyocera KD235GX panel which puts out 13.35 watts per square foot. (13 * 39987) = 519831 watts of peak power. Half a megawatt! I heard on the radio that the biggest solar installation in Massachussetts is two-point-something megawatts.
With big flat roofs like these covered in solar we could have substantial generation in our cities. No transmission losses. No new transmission capacity to build. I think the economics for it are almost here, and they would be if we taxed pollution properly.

(yeah, I posted about that solar facade in Porter square before)