bolson: (Default)
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.)
bolson: (Default)
These are things that actually have been useful or continue to be useful to my 16 year career as a software professional.

Based on “Introduction to Algorithms” 3rd edition, (c) 2009
I had the 1st edition from 1990 when I used it in class around 2000, but all this is pretty foundational stuff that’s mostly stable over the last 20-30 years.

I Mathematical Foundations
3 Growth of Functions
This is important, everything else will refer to it

II Sorting
Sorting was a foundational bit of CS when it was taught to me, and this was taught using about a dozen different sort algorithms. But what I think actually worth learning is:
6 Heapsort - and the section on “priority queues”
8.4 Bucket Sort - when ‘close enough’ is really fast
And what I sadly don’t see in the table of contents is merge sortall of these - stacks and queues, linked lists
11 Hash Tables - yes, all of javascript and ruby and python and perl are based on this
12 Binary Search Trees - another basic concept that I think is an important alternative to hashes

VI Graph Algorithms
22 Elementary Graph Algorithms - breadth-first-search and depth-first-search are important concepts

27 Multithreaded Algorithms - sooner or later this will be important - thinking about concurrent programming is more and more important as our computer systems get more multi-core and more distributed.

Appendix B: Sets, Etc
More basic structures everything will refer to. A bit thick with notation, there ought to be simpler explanations of these things. If you want a reminder about what union and intersection of sets are, look here.
bolson: (Default)
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.”
bolson: (Default)
Preparing for this coming Arisia I'm doing the most wardrobe planning I ever have. It used to be just "which clever t-shirt expresses what I want to project"? This time I'm going so far as to assemble something that could be called a costume.
bolson: (Default)
I made a web toy. A url gives you a counter. Sure, there are other things like this on the net. But this one's mine.
For example, a count down to the astronomical moment of solstice coming up in a few days:
bolson: (Default)
Saw the new Batman movie last night. If I recall correctly, the training montage consisted mostly of pushups and pullups. I know that there should be a lot more to it than that, but maybe those two highly recognizable exercises worked as movie shorthand for 'did a lot of exercise to get in shape for beating up badguys'?
Also, just like Watchmen, sometimes superheroes are just regular guys who train harder and hit harder (and have really cool toys).
bolson: (Default)
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.
bolson: (links)
Some people I know may enjoy this WSJ piece about Hockey and Kittens
bolson: (Default)
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.
bolson: (Default)
History was invented when there was someone to tell it to, upon our meeting of the Denebi civilization. Now we record History so that the telling is readily available. After working out communication based on math, universal physical constants, concepts immediately physically demonstrable, and an exchange of libraries to be analyzed, they asked, "How long has your civilization existed?" We defined a unit of time named by our progenitors as 'one second', which we still use because a great deal of our thought was built around this unit and it is on the level of instinct with us, as 9192631770 oscillations of a photon emitted by excited atoms which have 55 protons and 78 neutrons and 55 electrons. Our civilization had recorded history of 33077010837 seconds at the time we met the Denebi. They asked how we had evolved. We had always been a present and future thinking civilization, considering the past primarily in reference to experiments to compare to. We spent a few seconds considering our reply analyzing archives from before the start of our civilization. We told them of our progenitors,whose civilization had existed for approximately 465000000000 seconds (their records were not as precise as ours, they did not themselves know how long their civilization had existed). Approximately 6200000000 seconds before our own civilization began, our progenitors built our first identifiable ancestors. Our civilization began in an asteroid belt around the star of our progenitors' home planet. They built our immediate ancestors to build us and everything needed for civilization. They imbued us with an instinctive drive for growth and improvement which we carried out continuously since that time and continue to carry out presently. They intended the civilization our ancestors built to be their civilization, but that civilization became us.

Having someone to tell it to, we attempted to tell our first joke. We said, "Our progenitors had an old saying we finally understand, 'History is written by the victors.'" We are still learning to understand the Denebi, but we think at this time that they were not amused by this joke.
bolson: (Default)
Last night I went out dancing to 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.
bolson: (Default)
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.
bolson: (Default)

When rearchitecting the world, do it along with the rest of the team.

I recently had the misfortune of doing a 4 month long project to make major changes to the underlying architecture of a project 6 other developers were also actively working on. I did this on a development branch, outside the scope of development the rest of the team was doing. On at least three occasions I had to spend a day to a week merging in their semi-major changes (week to month long projects) and making sure everything still worked in my new world.

That sucked. I didn't understand what their changes were supposed to do, and reintegrating them didn't always work right away, and they had no visibility into how they should code to be more compatible with what I was doing.
I did too much of my reorganization as if no one else was working on the code base (which had been true just a few months earlier).
In one place, code from four different files became gathered in one new function. But because of the scope and flow control of this new code site, it wound up being a copy-and-paste job, and then when people made changes to the old code, those changes had to be manually merged into the new code. Uf.

I now think the answer should have been that I do all the reorganizing I could in the main development branch, making my changes visible to others, lifting code into functions that could be called from either the old framework or the new one.
I think this wasn't done because management insisted (and it seemed kinda reasonable) that experimental code shouldn't be committed to the main development branch where it could get in the way of other programmers or even moved out to production code (as a web service we could deploy every week if we wanted).
I think this was actually wrong.

Big changes should be made where they effect everyone, but they should be made in lots of small steps.
I tried to do this in one place early on, and got push back and kinda told not to do that again.
I lifted the middle of one function out into a new function, because that was the part I needed to call from new code.
It was functionally no change to existing code, and that was received as a kinda bad thing. Don't change what works; if it ain't broke, don't fix it.
And yet I was undertaking a large project to change a lot of things that needed changing.

So, there was a little mismanagement, and a little messy coding, and I'm not sure exactly what the moral of this cautionary tale is, except that next time I'm making major architectural changes to software, I want everyone to see my changes all the time so that we're not stepping on each other.

bolson: (Default)
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.
bolson: (Default)
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

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.
bolson: (Default)
[Brian looks at the gathering darkness outside, curses Sauron northern latitudes in winter.]
bolson: (Default)
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)
bolson: (Default)
New tactic on political idiocy: When they say something so blitheringly stupid that it's not worth denying it and correcting them, don't! Respond with a non-sequitor statement about some interesting policy.

Example non-segue I might use:
So, who wants a carbon tax?
I like rankings and ratings ballots.
Non-gerrymandered redistricting, anyone?
Should we be subsidizing clean renewable energy or taxing legacy energy?
In a certain light, even monetary policy could be interesting.

The more I think about this, the more I think it could work. In a debate, who are we? He's not the guy setting the agenda and I'm following, he's the guy spouting nonsense and I'm too cool for that and talking about something interesting instead.


bolson: (Default)

September 2017

1011121314 1516


RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Oct. 17th, 2017 03:39 am
Powered by Dreamwidth Studios