Here's a neat thing I made a long while back: the Bezier Playground. It was part of a general plan I had at the time to make a series of interactive explanations of concepts that are very had to explain algebraically, but easy visually and interactively.
The Bezier curve was actually the first moment it dawned on me that for some things symbols are just a bad way to think about them. I actually had to implement Bezier curves for a computer graphics course, and after staring for a while at the closed form in the textbook with my eyes crossed, I happened across this gif on Wikipedia. Everything became clear, and I put together my implementation based entirely on that one image.
Later on when I ran across Bret Victor's Kill Math and related work, it felt so right and so familiar that I went and threw together this playground as a tribute. Enjoy!
There's a difficult tradeoff when trying to shorten a feedback loop: if you take less time to do something, won't it be less good?
It's intuitively obvious that there's a tradeoff between time and quality: to make something good takes more time than making it mediocre. But there's a hidden "something" term in there that gives us an extra dimension to work with. A more complicated thing also takes more time than something less complicated. Perhaps a better way of thinking about it, then, is as a time-quality-scope tradeoff. I've come to think lately that the correct answer is to minimise that scope as much as possible.
Put another way, imagine you have a graph of your progress over time. When you're in the middle of working on something but not done yet, you can visualise it as a gap in that graph. When you finish, the progress goes up in one big jump. I think of scope, in this context, as that gap: the length of time where your progress function is undefined. If someone asks "how's the project going?" you don't really know the answer. And trying to estimate when you'll be finished halfway through a gap is basically impossible.
But you can decrease the size of the gaps in that function by just defining "done" differently. Maybe if you are clever about it, you can have twice as many done points while still achieving the same progress over time. The undefined gaps will shrink, you'll have better and more accurate information, and be able to make decisions more quickly.
It's interesting to consider the ultimate extreme of this philosophy: what if you could get to a point where there are no gaps, and your progress is defined on every time-scale? It would mean no git, no deployment system, no edit/save cycle: everything you do is immediately put into production. It would mean a keystroke is a function is a module is a project. It would mean your progress function is continuous everywhere.
I've been noticing lately that it's sometimes easy to lose track of the way my longer term goals connect with my shorter term ones. For example, I might decide at the start of the month that I want to work on some project, but then on a week-to-week or day-to-day basis I get distracted by other things or forget to put aside time for it. Prioritising day-tasks against day-tasks or week-tasks against week-tasks seems to be fine, it's just when the timescales collide that things go awry.
So here's my rough sketch of a system to fix it. I call it a scoping calendar. I'm a big fan of calendars and timetabling, but they only let you schedule things at an exact time. The scoping calendar lets you schedule something on any month, any week or any day, without needing to pick exactly when you'll do it. That means you can think about and plan your work on a very high level.
But the real beauty of the idea is that the different levels interconnect, and you can be high- and low-level at the same time. When you have more specific plans you can go back and add them in. Any time that you schedule on a per-day basis fills in progress for the week, and same for the week to the month. And the amount of time left unallocated in the month shrinks as the month goes on, letting you know if you've scheduled more than is possible.
Ultimately what you end up with is a view that shows you your goals, your commitments towards those goals and your progress on every time scale simultaneously, letting you bridge the gap between long-term and short-term planning.
I've been sitting on this bad boy for a while now but today I finally got a chance to set it up. Technically, its name is the NEXX WT3020H, but that's not particularly catchy so I've been calling it the Chinarouter. It's got two 300Mbps ethernet ports and 802.11n. It's tiny, it's USB-powered, and you can flash it so it runs Linux. The price for all this? Around US$15.
The OpenWRT wiki page was a little daunting but in reality it was just a matter of downloading the image, opening the web UI and hitting "upgrade firmware". I spent a bit of time messing around with settings, but the result is incredible. I now have a cheap, pocket-sized tool I can throw at any problem that has a vaguely networky shape.
I'm currently using it as an OpenVPN router after approximately following these instructions. One port is plugged into my regular network, and traffic from the other port and wifi are both put through my VPN before they hit the internet. No more messing around with client settings or draining extra battery on my mobile devices, I just connect to the "vpn" wifi network and my connection is secure.
I'm completely blown away by all the possibilities of this thing. You want to add wifi to a device that only supports ethernet? The Chinarouter can do that! You wanted that magical TOR-in-a-box that got shut down? It was literally just a Chinarouter with some custom firmware. I've even got a plan to use it to do network audits that I'll probably write about later.
Seriously, I am so in love with this thing. Between the Chinarouter and the new Raspberry Pi, the number of tiny Linux boxes in my house is getting ludicrous. If this is the future, I'm in.
When I was younger I always thought language was a set of rules you had to obey, a viewpoint I later learned was called prescriptivism, which is contrasted with its opposite, descriptivism. As I got older, my views mellowed away from the strict "what's in the dictionary is correct" school, but I've never found it in myself to go full descriptivist. Instead, I always thought of English as a standard, suffering from the same problem as any other standard.
When the web was first developing there were very few standards. Occasionally people published documents for one thing or another, but ultimately the standard was whatever got implemented. As time went on, standardisation did happen, but it was a largely descriptivist effort. Tags would appear in the browsers, then eventually those tags would appear in an HTML standard. It was a bit of a mess because the standard was constantly playing catch-up, and never seemed to quite cover the actual reality of the web.
For that reason the W3C eventually made a play at prescriptivism in the form of XHTML. Unlike HTML, which was fairly accommodating, XHTML was strict. If your webpage didn't adhere exactly to the specification, it wouldn't display at all. All behaviour was completely prescribed, specified and easy to predict. The standard was, of course, a complete failure. Nobody really used it because it was too different from what they were used to, which just worked.
So what we have now is HTML5, a kind of balancing act between the two which does a remarkable job of solving the standard problem. It clearly specifies a prescriptive standard, including what behaviour is required to be conformant. But the standard itself is mostly just a codified version of existing behaviour, so in most cases whatever you wrote before will still work.
You can kind of visualise it as a rubber band stretched around the space of existing implementations. If it's too loose, everyone can just do whatever they want. Too tight and it'll snap completely - everyone will ignore it. But if it's just tight enough, it will push the fringe non-conforming stuff back in line without inconveniencing the core features that everyone is pretty used to.
So I suppose that's ultimately become my model for languages. It seems clear to me that having no standard for English doesn't make sense, but neither would a standard handed down from on high that arbitrarily removed or renamed words in popular use. Instead it would have to play that same careful balancing act, trying to adjust behaviour without going too far and being ignored.
I'd sure hate to be the person tuning that rubber band.
