Thursday, December 26, 2013

The Obvious Isn't Distributed Evenly Either

Disclaimer: I own a tiny quantity of Bitcoin. This is not investment advice. I do not have the power to see the future before it happens.

Bitcoin's been around for years. I built an hourly exchange rate updater for it in 2011, while having a conversation with a bunch of people at a JavaScript meetup at the Farmhouse. I think I had been persuaded to buy some Bitcoins a year or two earlier, in the same house, at a Ruby meetup where we paid for a pizza using Stripe and an iPhone. I think most people had paid by swiping their card, while somebody else offered to chip in a Bitcoin, and the conversation went on from there, but I don't really remember, because it was so long ago. And that's the point. In Internet years, Bitcoin's already ancient.

However, despite Bitcoin's relative antiquity, it's only seen a lot of discussion in Rubyist "thought leader" circles quite recently, thanks mainly to its recent surges and plummets in price (which have been its largest so far, but by no means atypical). Alex Payne contributed some well-intentioned but sadly irrelevant and intellectually dishonest criticism, which aimed for political significance, and certainly raised valid concerns, but in my opinion amounted to little more than a former banking CTO announcing a personal change in the direction of his own life. People I respect had praise for this blog post, but personally, it just reminded me of the people in 1994 who told me the Web was just a fad and AOL was the future of the Internet.

Anyway, Steve Klabnik also wrote some wonderful rambling nonsense about how great Dogecoin is. But the best remark, in my opinion, came in the form of a joking tweet from Phil Hagelberg. Take a second and THINK ABOUT WHAT THIS ACTUALLY MEANS:

Pretty sure the answer's no, but you could build that site today.

Update: that site now exists.

Here's why this matters.

Historically, the American people have had at least nominal control over financial policy, but that era's basically over. On the one hand, the Federal Reserve doesn't answer to the people at all, and on the other hand, government doesn't really control money any more anyway.

Control over money was a government privilege for a very long time, but Visa, MasterCard, and a few other corporations have basically built a private, corporate, money-like system on top of money itself, which these corporations own, control, and sometimes illegally misuse to further their own political agendas. Visa et al have used the classic Microsoft "embrace and extinguish" strategy to mostly replace cash with their own private infrastructure. (The "mostly" part is what that classic William Gibson quote really means.) Simultaneously, investment banks have used international currency trading to turn money from a bastion of governmental authority into a commodity like any other, thereby shifting power from governments to markets. On top of all that, it isn't really about the money supply any more, it's about the credit "supply," and the people who control that can basically use their control to extort governments.

The major dilemma in American politics is that we have excellent protections (at least on paper) against abuses of governmental power, and far weaker protections against abuses of corporate power. There's a danger there for the 99%, because in America, monetary policy has become something so similar to privatized that you need a constitutional lawyer, an economics professor, and an electron microscope to spot the difference.

Venture capitalists are undoubtedly going to build new corporations around Bitcoin and cryptocurrencies in general, but most people over-estimate the importance of venture capital in this equation. For one thing, Coinbase's use of Mongo DB makes me think they're trying to crowdsource eventual consistency by having their customers email them a screenshot of every transaction. More importantly, cryptocurrencies are fundamentally peer-to-peer and open source. They're not creating new proprietary tech, like old-school venture capital projects in the 1980s. Like many things venture capital does today, they're really just trying to capture and control the wealth generated by programmers sharing code for free, or at most add value on top.

In political terms, that makes Bitcoin far less a tool of corporate control than Visa, MasterCard, Wall Street, and the Federal Reserve combined.

If you can't see how open source, peer-to-peer currency can be revolutionary, you need to read Marshall McLuhan, Bruce Sterling, and William Gibson. Catch up with the 1970s and 1980s, in other words. For bonus points, read Here Comes Everybody, by Clay Shirky, and catch up with 2009 as well. (And it's kind of a joke if you're talking about Dogecoin but you've never read Down And Out In The Magic Kingdom.)

TLDR: Peer-to-peer and open source technologies give power to networks of people -- whether large or small, whether public or private -- without corporate or governmental control. That's what puts the punk in cyberpunk. To quote Bruce Sterling:

Bruce Sterling: Cyberpunks have been cyber for decades now. Our society is pretty much cyber-everything, nowadays. Some aspects of it are even post-cyber. That's okay, you get used to that process. "Normality" comes and goes for a sci-fi writer, but "eerie" you always have with you...

What film best represents your vision of a cyberpunk or high-tech dystopian future?

Bruce Sterling: As for the "cyberpunk" part, forget about "the movies." Abstract motion-graphics coded in Processing and posted on Vimeo, that's "cyberpunk." You don't wanna make movies that are about guys with computers. You want to use digital composition to seize control of the means of producing cinema. And then do it all yourself! That's "punk." Hollywood product is commerce, it's about fanboy culture.

While it's certainly very likely that monied elites will find ways to survive and even profit from this radical transformation, if it indeed goes forward, Bitcoin's designed to build an economy where we don't need governments and we don't need corporations. If you hope to do anything more punk rock than that, ever in your life, good fucking luck. Of course, the question of whether Bitcoin succeeds in practice is different from the question of what potential Bitcoin has in theory. However, at least in theory, Bitcoin attacks the two biggest necessary evils of economics and takes the "necessary" part out of the equation in either case.

And since it's open source, any corporate or governmental system set up to control it is inherently optional. Any group can fork an existing currency and create their own economy. Any ethnic group, any subculture, any open source community, yes, but note that I didn't even say "any group of people." Cryptocurrencies offer similar options to, for instance, any group of pieces of software. If you want to leverage the chaotic nature of market economies to manage some computational resource, you can. The bad news: chaotic systems are chaotic. But the good news is that the foundation for your software already exists, and will cost you nothing.

I'm not even saying all of this is good. I'm saying it's all a big deal. The question with Bitcoin is not "is this a VC fantasy or a way to make money?" The question with Bitcoin is "is this merely a way to make money, or will this become a bigger deal than the invention of the Web?"

If you enjoyed reading this, I am extremely happy to accept tips via Bitcoin (167E9cAhbsyMo2RNm1xUwSy8LseMnPct8M) or Dogecoin (DDG4FJFin5Sap4e872LWamvxWUcbMnoFte). And keep in mind how easy it would be to tip me, or anyone, if these addresses were not text to copy and paste, but <a href="btc://167E9cAhbsyMo2RNm1xUwSy8LseMnPct8M"> links to click instead.

Friday, November 29, 2013

New eBook: Hacking Music and MIDI (and Animation) with Node.js and Clojure

I've written a new ebook. It's a guided tour through four hacks. Two of the hacks are animation hacks which use music gear and a music protocol (MIDI). The other two are 100% music hacks, i.e., one of them is an algorithmic dance music generator in Clojure with Overtone -- which generates original bass lines and plays a standard drum rhythm -- while the other is a drum machine in Node.js and CoffeeScript, with some brief notes on how to modify it to make it algorithmic, and/or change it from a drum machine to a melody player.

Here's the Clojure animation hack:

This is the Node.js animation hack:

I originally started on the Node.js code for my Teaching The Robots To Sing video series. Here's a promo video for that, which demonstrates some of the basic Node.js code you'll see at the beginning of the book:

The book goes much further than that, though, even before it gets into Clojure and Overtone.

The most impressive music hack, I don't have video for, but it uses a simple Markov chain, a standard moombahton drum rhythm, code in Clojure using Overtone, and a corpus of funk basslines to craft unique permutations on a funk/moombahton idea every time it runs.

The book has example code in Clojure using Overtone (and Quil, which is a Clojure wrapper for Processing). It's also got example code in CoffeeScript using Node.js,, and CSS3 animation. There's also a few brief, random snippets in Ruby and Common Lisp. This isn't a book for beginners; I don't go through language basics or anything like that.

If you like making music with code, you're probably going to enjoy this book. :-)

There's two editions you can buy: the regular edition, which is a 96-page PDF ebook, plus tons of example code and a bonus guide on how to set up MIDI on Linux (the book assumes you're using OS X), and the deluxe edition, which gives you everything in the regular edition, and then adds on 8 videos (which explain the Node.js and CoffeeScript code in detail). These are my Teaching The Robots To Sing videos; it would cost $96 to buy all these videos individually. Both the regular edition and the deluxe edition have a special launch sale price until Monday: $23 for the regular edition (the 96-page ebook on OS X music/MIDI hacking in Node.js and Clojure, plus a bonus Linux setup guide), and $53 for the deluxe edition (which is the regular edition plus about three and a half hours of demented but informative video).

Regular edition:

Deluxe edition:

(Fair warning, the deluxe version is a colossal download!)

People typically like my products. Here's a bunch of positive feedback on my previous work:

(email from a happy customer)

If you want to see evidence of my knowledge when it comes to hacking music, check out these presentations.

I offer a 100% no-questions-asked refund on all my products. They can be returned for a full refund at any time for any reason whatsoever, or indeed no reason at all. I only want your money if you're happy with what you've bought.

Again, my new ebook, Hacking Music and MIDI (and Animation) with Node.js and Clojure, is on sale now, at special launch prices: $23 for the regular edition and $53 for the deluxe edition. Enjoy, and let me know how you like them!

Regular edition:

Deluxe edition:

Monday, November 25, 2013

Drum & Bass Track: Queen Bast

The name comes from the fact that I made one of the synthesizer parts in this track sort of meow like a cat.

Wednesday, November 20, 2013

Friday, November 1, 2013

Meatspace Jitter

        getScreenshot(function (pictureData) {

          $.post('/add/chat', self.serialize(), function () {

          }).error(function (data) {
          }).always(function (data) {
            posting = false;
            body.find('> img').remove();
-        }, 10, 0.2);
+        }, 2, 1);


  var getScreenshot = function (callback, numFrames, interval) {
    if (videoShooter) {
      videoShooter.getShot(callback, numFrames, interval);
    } else {

Tuesday, October 29, 2013

Enforce Your Western Bacon Cheeseburger

This is a track I made years ago, when I lived in Santa Fe, New Mexico. The style is a kind of Warp Records ambient techno vibe, like Speedy J, Autechre in a gentle mood, or Black Dog / B12. With the exception of a sample at the end, I made the entire thing on a Korg ER-1 as a kind of challenge, to see how many different sounds and textures I could get from it.

The sample begins at about 4:15. It's fun.

"It Feels As If It's Reading My Mind"

Wearable head-mounted camera reads your brainwaves and records whatever you're seeing if it estimates your interest level meets arbitrary 60% threshold.

Tuesday, October 22, 2013

New D&B Track: Maximum Bass

Wednesday, October 16, 2013

Saturday, October 12, 2013

New eBook: Software As A Disservice - Fixing A Broken Rails App

I wrote a new (e)book, called Software As A Disservice: Fixing A Broken Rails App. It's a caffeine-fueled foray into fixing legacy code. I wrote it partly because I have some Rails students who I'm training, and I wanted to show them the difference between bad Rails code and good Rails code. I also wrote it because I was a little bit outraged by somebody else's ebook.

I started with this open source Rails app, an allegedly good example of a subscription site using Stripe. The "allegedly good" part, btw, is not alleged by Stripe, but by the app's author, who also sells a subscription (using the app itself) to a site with tutorials on how to build Rails apps, including an ebook about building the subscription site app in the first place.

It's a wonderfully meta business model, and I love how it involves giving code away for free. But the code is, in my opinion, awful, and anybody who used it as an example of how to build Rails apps would be misled about how Rails apps should be architected and how Rails code should look. In my opinion, this app does you a serious disservice if you take it at face value, so I called my book Software As A Disservice.

In this book, I take this app's open source code, and work hard to make it suck less.

The book itself is only about 120 pages, which only gave me enough space to make significant progress in both re-architecting and refactoring the User model. If you've refactored and/or re-architected a bunch of legacy Rails sites already, you might not learn anything; this is probably not the book for you. You should buy this if you're new to Rails, and you want to understand the difference between good Rails code and bad Rails code.

Caveat: this book is full of foul language. One chapter is called "Why The User Model Is Fucked." There are also garish, violent, and sexual metaphors involving raccoons, bananas, anal sex, dangerous machinery, weapons, and tentacles. There's probably other disturbing and/or inappropriate stuff that I forgot about, and it's entirely possible that a reasonable person could read this book and worry about my mental health. However, as long as you learn something about writing good Rails apps in the process, I can basically live with that.

The book's crazy like that because I wanted it to be funny, I wanted it to be candid, and I wanted it to feel kind of live and real-time. I wrote it while fixing the app in question, and if you think it's possible to fix legacy code without swearing a lot, you're either some supernatural entity of the holy variety yourself, or you're fucking dreaming. Anyway, the benefit of the "live and real-time" factor is that the book's annotated with git commit hashes, so you can go through the code, do a git checkout xyz12345 to explore the code at every stage in the process, and/or see exactly how the code changes from moment to moment with git diff.

The book's only in PDF format; I've upgraded my toolchain to make mobi and epub output possible as well, but it won't be ready for a little while longer. I'm going to release both this book and Rails As She Is Spoke in Kindle format for sure, but epub format remains a maybe, and I'm not sure how many of my other books will also get converted. Anyway, Software As A Disservice is 122 pages long, it's aimed for newbie to intermediate Rails devs, and it's $23.

To buy Software As A Disservice: Fixing A Broken Rails App for $23:

To promote it, I'm also selling a bundle of Software As A Disservice along with my other two Rails books, Rails As She Is Spoke and Unfuck A Monorail For Great Justice. That's $61; the total to buy those books individually is $101. So you save exactly $40 if you buy the bundle.

To buy the bundle and save $40:

Wednesday, October 9, 2013

iOS Fucked Up My Brain

True story: I used to be pretty good about inbox zero. Then I started using iPhones and iPads. The email apps sucked compared to Gmail, so I got in the habit of leaving stuff in my iOS inboxes until I could go into Gmail on the web and clean them up. Then I got bad at inbox zero. Today I absolutely suck at inbox zero.

I also used to be great at browser tabs. I never left them open all day, never had more than three or four at any given time. I suck at that too now, and again I blame not only myself, but also iOS.

I'm dragging my feet on iOS 7 -- I don't want to deal with it until they've worked out the kinks, and really I don't ever want to deal with its text-only "buttons" ever in my life -- but previously, Safari on the iPhone has defaulted to opening your Bookmarks menu when you launch it without a URL already open. I found this behavior incredibly annoying, so I got in the habit of keeping URLs open. For obvious reasons, I wanted URLs that loaded quickly.

For years, the fastest-loading URL which sprang to my mind was my own mini-app, Hacker Newspaper, because it had a tiny DOM and zero dynamic elements. So I got in the habit of having that open in iOS at all times. Then I wrote another mini-app which loaded even faster, an hourly tracker for the Bitcoin exchange rate, and I got in the habit of having that constantly open on iOS instead. This habit made me a little money, but I didn't really want to be constantly aware of the Bitcoin exchange rate, and the Hacker Newspaper habit changed me in a terrible way. I read Hacker Newspaper all the time now. I used to only look at Hacker News when my own blog posts were on the front page.

Long story short, iOS fucked up my organizational habits through design fail -- and iOS is consistently regarded as one of the absolutely best-designed technology products available. As another example, some Palm Pilot users in the late 90s allegedly experienced weird personality change effects as a consequence of the Palm Pilot's writing system, which had users change their handwriting for the Palm Pilot, since that was easier than handwriting recognition. (Sorry, the obviously-needed citation's been lost to the mists of time.)

Interaction design has huge consequences, because interaction design is behavior design, and a lot of the behavior it governs is mental behavior like thinking, planning, and sorting. Among others, the sci-fi author Charlie Stross and the sociologist Amber Case have described various types of software as systems for externalizing consciousness, identity, and memory. While sci-fi's been forecasting the criminalization of specific thoughts since at least George Orwell, thoughtcrime is still at least a specialized problem. I don't think any science fiction author successfully predicted the aggravating ubiquity of thoughtfail.

This is, in my opinion, the strongest argument for seeing Unix and basic coding skills as fundamental required literacy today. As prostheses for memory and identity, computers are too useful not to use, but if you don't know how to craft your own code which gives you a UX which matches the way you think, you're doomed to matching the way you think to the available tools, and even the best available tools basically suck. Interaction design is not only incredibly hard to do well, it's also incredibly idiosyncratic.

Friday, September 27, 2013

Rubyists, A Non-Endangered Species

Picture a circle of chairs in a church basement, a small group of people, faces holding anxiety and shame, but also a quiet courage and determination. In the background, a cheap table, a big metal cylinder full of hot coffee, and a stack of paper cups. Everybody's quiet. I stand up.

Me: "My name's Giles, and I read Hacker News."

Everybody: "Hi Giles."

Due to my shameful addiction, which I struggle daily to overcome, yesterday I heard about a GoGaRuCo talk called "Why Hasn't Ruby Won?", and today I learned of a Wired article which will no doubt fuel plenty of Ruby FUD for months (and maybe even years) to come:

Twitter’s engineers came to realize that Ruby wasn’t the best way to juggle tweets from millions of people across the globe — and make sure the site could stay up during its headline moment with the president of Russia. The best way was a brand new architecture based on Java, a programing tool that has grown more powerful than many expected...

Originally, Twitter was one, monolithic application built with Ruby on Rails. But now, it’s divided into about two hundred self-contained services that talk to each other. Each runs atop the JVM, with most written in Scala and some in Java and Clojure. One service handles the Twitter homepage. Another handles the Twitter mobile site. A third handles the application programming interfaces, or APIs, that feed other operations across the net. And so on.

The setup helps Twitter deal with traffic spikes. Because the JVM is so efficient, it can handle much larger amounts of traffic with fewer machines. But the new operation is also more nimble. All these services are designed to communicate with each other, but if one goes down, it doesn’t take the others down with it.

I'm very happy to say I found out about this through a rant which raises the obvious criticism, which is that the article utterly fails to differentiate between Twitter switching languages and Twitter radically overhauling its architecture:

quite frankly the choice of language may not be all that important.

You could take a monolithic application written in any language, break it down so that it scales horizontally across servers and vertically to provide separate systems that communicate with one another in exactly the same language you started with and end up with a system that is… *drumroll* …faster, more scalable and less prone to crashing.

So I don’t buy the line that Java or the JVM saved Twitter. I would bet that a thorough re-architecting of their system saved Twitter. I’d be glad to update this based on Twitter devs first-hand knowledge but I’d already happily put some money on the architecture being more important than the language, it nearly always is.

I've written two books on Rails, and both of them discuss refactoring to service-oriented architecture. I'm writing a third, and the first thing I do in it is give a newbie-friendly demo of one such refactoring. I've worked on a large number of Rails apps, stretching back to 2005, and one very consistent theme I've noticed is that most sites use a more complex, service-oriented architecture than the "omakase" architecture which Rails assumes as its default. (And even 37Signals uses services for some things.)

Nonetheless, the past two days seem to hold a theme of skepticism about Ruby's future.

Time for a history lesson: around the same time Rails first appeared on the scene, proving that you could build a successful company with Ruby, Paul Graham wrote his book Hackers And Painters, which made many programmers aware that you could build a successful startup on Common Lisp (as Graham did with Viaweb). Another terrific company at the time, DabbleDB, demonstrated that you could build a great web app with Smalltalk.

All you really have to do is write good software.

However, if there's any extent to which this Ruby skepticism needs any response, I think the response should be a more honest appraisal of "the omakase stack," or the odd differences between Rails's official "conventions" and the standard deviations from those "conventions" which people who build Rails apps will make, as a matter of convention.

One of the weird things about the Rails community is that Rails's progenitor and overlord David Heinemeier Hansson gives out advice on infrastructure which is very hard to take seriously, and advice on business which very obviously works, yet people seem, to me, to ignore his opinions about business while imitating his infrastructure and finding that it doesn't work for them.

As an aside, I'd like to see people take Mr. Hansson's business advice more seriously. I said above that "all you really have to do is write good software," but really, there's more to it than that. Thinking about business is not always what programmers are good at, but if you want to be free of the danger that you might have to give up your favorite programming language because somebody read a poorly researched Wired article and failed to notice its deficiencies, then all you have to do is write good software, and turn a profit.

But if we're concerned about people with heavy-duty traffic needs taking Rails seriously, I think the Ruby and Rails culture(s) would be wise to acknowledge that most people who use Rails ultimately disregard the "omakase" stack, or at least customize it, in favor of a more service-oriented approach. We can't encourage people to think of Ruby and Rails as the same thing and then complain when they fail to differentiate them, just like we can't encourage people to think that everybody uses Rails the way 37Signals does, and then scoff when they point out that the "omakase" stack is not well-suited for the needs of a business like Twitter (or GitHub, another hugely successful company which uses Rails in the context of a significantly more service-oriented architecture).

Thursday, September 26, 2013

Nobody Will Ever Win

Sarah Mei gave a talk at GoGaRuCo entitled "Why Hasn't Ruby Won?" It's a trick question; I haven't seen the talk itself, but at the end of the slide deck, Mei concludes:

Ruby can't win, because language choices hinge on familiarity. And everyone who walks in Ruby's door has given their brain a different set of training data than you gave yours. So not everyone's going to be a match.

This is a game where there is no winning. But there is definitely losing.

Ruby could wither into a niche language like COBOL or Smalltalk. And none of us wants that.

Daniel Fischer followed up this line of reasoning:

We made our strides, and now we’re receding into history...

We’ve reached a point where the innovation trends are happening outside of our bubble. If we continue with settling with what we have then Ruby and Rails will recede into a comfortable zone and stay around just like PHP...

If you ignore Javascript you’re going to be left behind. Yeah, Ruby is amazing and we’re used to this beautiful syntax but the hard truth is that Javascript is here to stay and if you look at any Rails project that doesn’t take it seriously then you’re in a minefield of hurt. The modern web demands a high command of Javascript. Make your life easier by understanding it and embracing the innovation that is coming out of it. If you take anything away from this post, let it be to compel you to take Javascript seriously.

There's something very amusing about this to me. Last year -- closer to two years ago now, really -- I wrote a bit of a rant called Rails Went Off The Rails, about how I was seeing a lot more creative excitement in the JavaScript world than the Ruby world. Since then, I've been repeatedly heckled by Rubyists who apparently believed me to be a Ruby hater or somebody who had given up Ruby for JavaScript. But now, other voices in Ruby-land are saying the same thing.

Still, I'd agree with Mei that "winning" is a meaningless goal here. Why hasn't Spanish won? Why hasn't English won, or Cantonese, or Esperanto? We speak different languages with machines for the same reason that we speak different languages with each other. I love Ruby, and I think Python's OK. I love Ancient Greek, and I think Latin's OK. It doesn't take a rocket scientist to notice the theme. Languages reflect both culture and taste, both of which are inherently idiosyncratic, and always will be, from now until the end of time.

But I have a harder time with the idea that Ruby is in any danger of withering away. I started working with Ruby in 2005 or 2006, and by any metric, the language has grown. The number of available jobs has obviously increased by a huge degree. Same with programmers and projects. The language itself is faster and more sophisticated. In that context, the notion of Ruby withering away to nothingness looks pretty ridiculous.

It could be fair to argue that the increased popularity of Ruby has made the Ruby community less creative and more boring. There's less excitement and more corporations, or at least, there's less weird creative projects per capita -- there are a lot more pedestrian applications at cubicle-centric companies, sure, but your options for writing code which creates music and art are much better today than they were back in the days of Rails version 0.13. The average Ruby developer today is significantly less likely to be fluent in multiple languages and writing a language of his or her own, but the available tools for language design are much better. So even there, the wither-risk looks low.

I think the only way Ruby could be said to be withering away would be to assume that Ruby no longer holds the center spotlight in the endless fashion show that functions as the closest equivalent to a rational technology selection process for the rampaging herds of aristocratic nitwits who drive a lot of the Bay Area's technology economy. But I've believed for a long time that if you're in a position where you have to care what those people think, you've already lost whatever game you're playing. And sliding from Number One to Number Two in a high-stakes, big-money popularity contest is really not the same thing as withering away at all.

So I'm having a hard time seeing any serious merit to the fear of irrelevance which Mei's slide deck and Fischer's blog post both express. On the other hand, both the blog post and the slide deck (and presumably Mei's talk as well) advocate learning multiple languages, keeping your ear to the ground, and staying up to date on developments in other language communities. This has always been a core value of the Ruby community, and of course I absolutely agree with Mei and Fischer here. Ironically, the fact that this idea has to be explicitly stated is the only sign of Ruby's withering that I've actually seen.

It was the weirdest part of the reactions that I saw when I posted Rails Went Off The Rails back in February of 2012. Perhaps instead of "this has always been a core value of the Ruby community," I should say "this has historically been a core value of the Ruby community," and praise Mei and Fischer for bringing it back.

Friday, September 13, 2013

Dubstep/Chillout Track: Old City Streets

New track by me. Vocals by Veela.

Sunday, September 1, 2013

Privateers In The 21st Century

A theme I've noticed in recent reading:

Asset forfeiture gives cops financial incentives to drum up false charges and seize property from innocent people.

Anti-drug "task forces" throughout the country have very little supervision or accountability, yet receive federal money in proportion to the arrests they make, which functions as another set of financial incentives for the prosecution of innocent people and the seizure of their assets.

Additionally, in Russia, criminals are safe from prosecution for credit card fraud as long as their victims live in other countries. They are especially safe from prosecution if their victims live in the United States.

Meanwhile, a LulzSec hacker has claimed that the FBI used criminal hackers to break into private networks belonging to foreign governments.

For contrast:

A privateer is a private person or ship authorized by a government by letters of marque to attack foreign shipping during wartime... Privateers were part of naval warfare from the 16th to the 19th centuries...

Historically, the distinction between a privateer and a pirate has been, practically speaking, vague... The actual work of a pirate and a privateer is generally the same (raiding and plundering ships); it is, therefore, the authorization and perceived legality of the actions that form the distinction. At various times, governments indiscriminately granted authorization for privateering to a variety of ships, so much so that would-be pirates could easily operate under a veil of legitimacy.

Saturday, August 24, 2013

It's Not Militarization, It's Piraticization

Radley Balko's book Rise of the Warrior Cop outlines how, in only a few decades, the Fourth Amendment's been gutted, and the military-industrial complex has expanded into the criminal justice system. Between the so-called "wars" on "terror" and "drugs," police departments are buying so much military hardware that the Pentagon set up a special office to funnel materiel from the military to police agencies across the country. This office processes hundreds of millions of dollars in business per year.

The practical upshot is that practically every city of 25,000 people or more, anywhere in the United States, commands at least a small paramilitary police force, and larger cities like Los Angeles and New York control paramilitary forces equivalent in size to small armies, and structured like small armies as well. (By the way, "small" by the standards of a top international superpower like the United States is actually still kind of a lot of people.)

Rise of the Warrior Cop is a terrific book. I think everybody should read it, but that isn't the same as thinking it's correct in everything it says. If you saw the title of this blog post, you already know the big issue I have with Rise of the Warrior Cop: it says that it's about the militarization of the police, but that isn't strictly accurate, in my opinion.

Towards the end of the book, Balko interviews a senior military officer who objects to the term, because police tend to be less well-trained and less disciplined than the military. He also points out that when the American military conducted house-to-house searches in Iraq, as part of the recent war there, the military searches met a higher standard of Fourth Amendment compliance than most police actions in the United States do today.

Last but not least, there's the issue of asset forfeiture. Asset forfeiture gives cops incredible financial incentives to drum up false charges against anyone with valuable property.

You needn’t be found guilty to have your assets claimed by law enforcement; in some states, suspicion on a par with “probable cause” is sufficient. Nor must you be charged with a crime, or even be accused of one. Unlike criminal forfeiture, which requires that a person be convicted of an offense before his or her property is confiscated, civil forfeiture amounts to a lawsuit filed directly against a possession, regardless of its owner’s guilt or innocence.

One result is the rise of improbable case names such as United States v. One Pearl Necklace and United States v. Approximately 64,695 Pounds of Shark Fins. (Jennifer Boatright and Ron Henderson’s forfeiture was slugged State of Texas v. $6,037.) “The protections our Constitution usually affords are out the window,” Louis Rulli, a clinical law professor at the University of Pennsylvania and a leading forfeiture expert, observes. A piece of property does not share the rights of a person. There’s no right to an attorney and, in most states, no presumption of innocence. Owners who wish to contest often find that the cost of hiring a lawyer far exceeds the value of their seized goods.

There's an urban legend that, during the 1980s, trains would pass through Compton in the middle of the night and leave huge crates of assault rifles, pistols, and ammunition. Lurid and provocative though such a story may seem, there's enough research out there to make a serious person wonder. Nonetheless, my personal hope is that it proves an exaggeration.

Either way, however, there's no disputing the evidence raised in Rise of the Warrior Cop that the Federal government's been not just selling military-grade armaments and equipment to police forces throughout the country, but also giving these police forces the cash with which to buy that materiel. The good news is that the Federal government shows a near-total lack of followup, oversight, results, or concern with the lack of results in this matter, and Rise of the Warrior Cop assiduously documents it. That's right: that's the good news. It indicates that this massive, nationwide, systematic weapons-dumping is probably less a totalitarian conspiracy than a confluence of irresponsible, fearmongering politicking with ruthless and equally irresponsible domestic arms dealing.

However, the bad news is that the American criminal justice system has developed a near-total disregard for the Fourth Amendment, and a ridiculously unconstitutional legal framework, called asset forfeiture, which enables cops to simply take things from people with very little restraint. There are rarely any consequences for a police officer who abuses these privileges. Consequently, the criminal justice systems of entire towns -- police, judges, and mayors -- have been implicated in what is essentially highway robbery, not in the idiomatic sense but in the ancient, literal sense.

Rise of the Warrior Cop starts out with the Founding Fathers' historic distaste for, and grudging acceptance of, standing armies. The dangers of standing armies are a very well-known element of classical and European history, and the Founding Fathers were very aware of these dangers and very cautious of them. But what happens when you have both a standing army for the nation as a whole and a motley assortment of standing "armies," one for every city? The so-called "War on Drugs" created a large number of "task forces" which do not even have sufficient oversight that anyone in government can say for sure what they do on a day-to-day basis. These task forces are peppered indiscriminately throughout the country. Some police forces have rejected their new, unconstitutional powers, while most have embraced them, and many have seen serious increases in both corruption and recklessness.

This is not militarization; this is piraticization. It's true that police culture now fetishizes the military, and police departments now use military vocabulary, organizational structures, tactics, vehicles, and weapons. It's true that this is a very surprisingly recent and rapid development. But Rise of the Warrior Cop documents in detail the legal moves which made this possible, and those legal moves are not coherent or well-organized.

America is a very big country, so big that it's probably more honest to describe it as an empire. If you spend time in both Texas and California, for example, it's very hard to believe that the two places are not each distinct countries. Both states have been independent countries in their own right, in the past, and probably will become such again, whether it be in fifty years or five hundred. To me, personally, both states feel like different countries today. The difference between meeting a Texan and meeting a Californian is not as intense as the difference between meeting a French person vs. meeting a German, but it's easily more intense than the contrast between meeting an American vs. meeting a Canadian, or meeting an Australian vs. meeting a New Zealander.

Militarization would, to me, imply that the newly and excessively empowered police departments throughout the nation would be capable of unified military action. It would also imply a unity of purpose. But when you have a whole bunch of people who do have weapons, but don't have cohesion or any real strategic thinking, and the training they receive is shallow, that doesn't sound military to me. Most military action involves attacking people who intend to fight back; most "militarized" police action involves large numbers of heavily armed police using extraordinary violence against small numbers of unarmed people. That's less warrior and more thug.

Add in the asset forfeiture factor and what you have is a huge number of piratical "police" forces. I don't think they're a military, and I don't think they could ever become a military, at least not on a national scale. I could see a future Texan Caesar rallying Texan police/pirates around some warlike impulse -- I think anyone who's been to Texas understands this -- but it's hard to imagine their Californian counterparts joining the cause.

I also favor the term piraticization over militarization because militarizing the police implies order, and the changes Blako documents in his book are more chaotic. For instance, one major risk of standing armies is the military coup. An antidrug task force which answers to just about no-one and gets its budget from drug arrests is not going to be qualified to take over a government. That requires organization. But it would be ridiculous to say that there are no risks in having people running around with guns, no oversight, and strong financial incentives to arrest or harass innocent people.

Ever since the fall of the Soviet Union, which seemed too big to fail, I've wondered if America might fall apart too. I'm sorry to say that after reading this book, I'm certain it can, and if it happens, I think it'll be the piraticization of the police which does it. It's easy to imagine that there might one day turn out to be some significant downside in distributing massive amounts of military hardware throughout the country, so that each city has its own little heavily-armed pirate squad.

That's the bad news. The good news is that I highly recommend Rise of the Warrior Cop. It's well-written, well-researched, and even-tempered. It's also the kind of book which can tell you incredibly frightening, infuriating, and sad things without over-inflaming these emotions or callously disregarding them. Considering the provocative, serious, and deeply fucked-up nature of the topic that Rise of the Warrior Cop covers, that's a pretty impressive accomplishment.

Thursday, August 15, 2013

Friday, August 9, 2013

Book Sale Countdown (And Secret Project Prelude?)

I'm not only doing my current book sale just to pay the bills and buy cool stuff. In a sense, everyone who does any kind of work is either looking to pay the bills, buy cool stuff, and/or make cool stuff, and it's that third one which is on my mind right now. I have a particular cool thing which I want to build, although in order to build this one particular cool thing, I will actually need to build a variety of other cool things to support it. In fact, to make all this mysterious, unspecified cool stuff, I'll also need to buy some cool stuff.

For instance, I'll have to buy parts and instructions to build one of these robots:

I'm not ready to reveal my specific plans for this robot (or indeed, these robots; the optimal implementation of my plan requires multiple robots). But stay tuned, and in the meantime, did I mention my book sale? It's actually a books and videos sale, the discounts are insane, the products are popular, and it only lasts for a week. It started on Wednesday, so we're already a few days into it.

Thursday, August 8, 2013

My Simple Pricing Strategy For Information Products, And Why It Works

I make videos and ebooks, and sell them on my blog. People like Patrick McKenzie and Amy Hoy constantly reiterate the advice that you should raise your prices and charge more than you think. So I took this advice. I put my first video on sale for $39, even though I was initially thinking of $19. Then I got an email from a happy customer who bought at $39 and wanted to tell me that my video would be underpriced at twice the price, so I doubled the price, and then increased it a little further, to $97. The video continued to sell very well, so I was happy.

With subsequent products, I made it a rule to charge more than I thought was reasonable, and also, to increase the margin of unreasonableness with each new product. (I also made it a rule to always set my prices at prime numbers, with only one exception, but there's really no good reason for that, and it's probably not important in this discussion.) Some of my products did well, some of them didn't, but when products didn't do well, the reason always seemed to be content or marketing, not price. My pricing strategy did not seem to have any downsides at any point. In fact it worked so well that I now consider charging unreasonable amounts of money to be a major theoretical pillar of my business. But I also noticed that Amy Hoy's husband Thomas Fuchs frequently tweeted discount codes for his ebooks (in particular the Retina one, which is quite good), and I also got a few tweets and complaints that I was charging too much, so rather than say "well yeah, that's the whole idea," I decided to run a sale.

One caveat before the story proceeds: I have a 100% no-questions-asked refund policy. If you have the slightest dissatisfaction with your purchase, you can have your money back. I probably wouldn't implement this kind of pricing strategy -- "charge more than you could possibly imagine people being willing to pay" -- if I didn't also have this approach to refunds. Because with this approach to refunds, charging as much as you possibly can is pretty much just an honest exercise in not knowing what the correct price is, choosing a number semi-randomly, and finding out. If I had a whole bunch of rules and hoops for people to jump through in order to get their refunds, it would be less pleasant, less ethical, and also a much less reliable source of feedback. There would be too many variables involved with that type of feedback for me to call it useful information about price and only price.

Anyway, as you can probably guess by the fact that I'm running a new sale right now, my sale went well. I did several other sales and they all went well. In fact I did one or two which were based around live-tweeting quick runs to the grocery store. The sales began when I left the house and ended when I got home and unpacked my groceries. The first one I did as an experiment, because I couldn't decide if I should work on my business or buy some groceries, so I figured I'd just do both at the same time, and then I did the second one because the first one went well.

The reason my sales work well might be because I set high prices when I release my products. For instance, here's some feedback about my Ember book:

I actually agree with both these tweets, but the Ember book sells at its normal "too expensive" price, so after this sale, it will of course go back up to that price.

The thing is, if you're in a hurry to learn the essentials of Ember, because you're really excited about it, or maybe you've got a big new consulting deal which will net you thousands and thousands of dollars if you can produce results with Ember right away, then my Ember book is easily worth the $47 I first charged for it, on day zero. You'll make that money back before you've finished your first cup of coffee on the first day of the new project. But if you're a more cautious person, or you're just sort of curious about Ember, in an academic sort of way, with no looming deadlines, you might not want to pay that much, and you certainly wouldn't have the same immediate, compelling incentive that makes it an indisputably great business decision for other people.

But you might still be down to buy it if it's on sale.

This is basically the easiest form of customer segmentation ever. Your customers who are willing to pay top dollar will pay top dollar, and your customers who would only buy at a lower price will buy when you offer the lower price. Best of all, if you retain records of how many units you sell, and at what price you sell them, you can probably come up with some math which will tell you what your optimal price should actually be. It's good to be able to draw upon data when you want to answer a question like that.

Another caveat, however: discounts don't actually have a huge influence on the sheer number of products sold, for me. They drive short-term sales spikes, and they enable me to do price differentiation, but the majority of my products sell at their higher original prices. Probably one explanation is the fact that my discounts have narrow windows, like a week, a weekend, or even just the time it takes me to get to the grocery store and back. It's not a pure, scientific experiment, after all; there's no control group.

But there's another, simpler explanation: the "set high prices" advice from Hoy, McKenzie, and others is good advice. I follow it, and I recommend you do the same. My products are almost always about programming, so if you use the information in them well, you'll make enough new money to cover the purchase price very rapidly. This is what the brilliant information marketing pioneer Dan Kennedy -- who invented nearly all this stuff back when it was all mail-order and physical books -- calls "buying free money." Say your new Ember contract is worth $47,000 to your consulting business. Would you pay $47 to get $47,000? Of course.

PS: my sale's here.

Tuesday, August 6, 2013

More Praise For My Ember Book

Got this email the other day:

Hi Giles,

I just wanted to say thanks for writing your ember book. I didn't code for years but I learned Ruby on Rails a couple of years ago and now co-run a reasonably successful company building mobile and web apps, mainly to help businesses improve their internal processes.

My business partner started using Ember about 12 months ago and I had real difficulty getting my head around it. Your book massively helped me sort out my (mainly conceptual) difficulties and I'm getting pretty confident with it now. I'm in the process of building an ember app for a printer company you'd definitely have heard of and it's going really well, in large part because of your book.

Have you thought about doing a mobi or epub version of the pdf? I converted it using calibre but it's an arse getting the line breaks to format properly. I tend to read a lot of technical books in bed (once the girlfriend is asleep!) and having an ereader version is always useful.

Thanks again. We really enjoy your blog too.


David Moore - Operations Director
0121 314 3330 // 07500 898 460

Of course I told David I was glad he liked it. And a big thanks back to him for allowing me to publish the email.

(more info, table of contents, tweets)

Saturday, August 3, 2013

Lies And Propaganda



via boingboing, which also has this

Friday, July 26, 2013

New Dubstep Track: Otah-Kvo

Wednesday, July 24, 2013

Ember Book Table Of Contents

1. Introduction (pg 2)
2. "Hello World" in Ember (pg 7)
3. Ember Testing (pg 14)
4. A Simple GitHub Notifications Viewer (pg 19)
5. GitHub Notifications Viewer, Expanded (The HTML) (pg 27)
6. GitHub API Notifications Reader, Expanded (The JavaScript) (pg 34)
7. A Heretical Perspective On Ember MVC (pg 47)
8. Ember Chess: The Beginning (pg 59)
9. HTML5 Drag And Drop, Part 1 (pg 74)
10. HTML5 Drag And Drop, Part 2 (pg 86)
11. Finishing Touches (pg 94)
12. Conclusion (pg 107)

more info and buy link

Tuesday, July 23, 2013

Real Metaprogramming: Experimental Businesses As A Service

Writing code which modifies a running program is all well and good, but what Ruby offers you in that department is piddling and pathetic compared to the opportunities of any real Lisp. I struggled mightily to write tools for (semi-)automated refactoring, for example, while Clojure already has things like kibit.

But even Lisp falls short of the meta-tastic heights of meta (or should that be middles?) you can achieve when you get algorithms to cook up algorithms for you. It's a good way to win at Starcraft and a good way to handle network traffic as well. And with people using algorithms to fuck up stock markets and overprice books, it's only a matter of time before venture capitalists realize that startups don't necessarily have to involve humans at all.

So I'm looking for a technical co-founder. I want to build a system which reduces Y Combinator to a shell script. The recipe is basically HTTP APIs and genetic algorithms, but I'll need somebody to figure out the details. That'll be you. I'm an ideas guy.

Doom Bell: Synthy Chillout Dubstep

My Perspective On Ember And Backbone

I wrote better software with Ember than I did with Backbone, and it's taken me a long time to get comfortable with that -- even after writing my Ember book -- but I've figured out why.

I didn't want to admit to this fact because I didn't want it to be true. Backbone prioritizes simplicity and transparency, while Ember holds your hand through a lot of the scary parts of building an app. When I was first learning Ruby, a whole subgenre of "Ruby vs Java" blog posts argued over Java's limited feature set -- a deliberate attempt to hide the hard parts of development from junior devs -- vs. Ruby's "give them enough rope" attitude, where you can do almost anything. Paul Graham's writing on Lisp entered the discussion, and convinced me that it's better to work with ready access to all the hard corners and sharp edges.

In server-side frameworks, most of my experience is with Rails, and Rails takes a lot of stuff out of the picture, allowing you to focus on your application's logic. Ember does something similar, but where Rails takes stuff out of the picture, Ember takes stuff out of your control. If Rails whisks something backstage for your convenience, you can always follow it backstage and dive into any details you want. Once Ember takes something out of your eyesight, it's just gone.

You sacrifice both flexibility and autonomy when you let that happen, and I don't like sacrificing either of those things. Meanwhile, Backbone's philosophy is all about giving you enough rope. It's small, it's simple, and it does not come with batteries included. It's quick to read, and if you don't understand what you're reading, that's your problem.

So I felt like Backbone had a fundamental philosophical superiority, so if I wrote better software with Ember than I did with Backbone, that didn't say anything good about me as a developer. And for a long time I've been thinking that if I truly understood evented programming, GUIs, and browsers, I'd be better with Backbone than with Ember. (I might be overthinking the problem here, but that's kind of what we do.)

There's another reason I felt Backbone should have been superior, even though Ember got me better results personally, and it's this other reason which changed my mind.

Backbone was released in 2010. I first worked with MVC JavaScript in 2007 or 2008, when I built my own little experimental app. I did this because in 2005 or 2006, I had given a presentation at a little BarCamp in Albuquerque explaining why I thought MVC JavaScript frameworks would one day exist. The MVC JS app I built in 2007/08 was not amazing by any stretch of the imagination, but I can at least claim some foresight points here. And I've been working mostly with Ruby since 2005, so a lot of my energy in this little MVC JS experiment went into designing the right objects.

So when Backbone came along, one of the major things which impressed me is that it wasn't much more code than my little experiment, yet it did so much more, and its object structure was very tidy. Ember, by contrast, has a relatively convoluted object structure. In fact, in my book on Ember.js, I argued that Ember uses the wrong names for nearly all the major objects that an Ember developer will work with when developing an application. I argued that the Models are not really models, the Controllers are not really controllers, and the Views are not really views.

I still stand by that argument, by the way, although of course you'll have to buy my book to read it in detail. (For now, at least; I may blog it in the future.) However, what I realized in the course of writing this book was that Ember's KVO implementation is much more important than its MVC implementation.

If you're a web developer, chances are pretty good you understood every word of the MVC discussion this far, and you're now wondering what the fuck KVO is supposed to be.

That's the whole problem with the discussions which people have about JavaScript apps.

KVO stands for Key-Value Observing. It's a particular approach to live data binding. Ember provides live data binding, Backbone provides live data binding, Angular provides live data binding, and Knockout does too. It's basically impossible to implement an elegant or even useful JavaScript app framework for the browser without live data binding.

I obviously have a general interest in JavaScript app frameworks. I'm very interested to play in the near future with ClojureScript and Fay. ClojureScript is a subset of Clojure which compiles to JavaScript, and Fay is a subset of Haskell which compiles to JavaScript. In either case, if I'm writing an in-browser application with a functional programming language, I won't need MVC, because it won't be a meaningful or useful concept in the context of the functional paradigm, but I *WILL* need live data binding. This is because live data binding is, in my opinion, an essential, non-optional component of any useful JavaScript application framework, while the MVC design pattern might just be a nice thing to have.

After all, none of the MVC web frameworks actually use MVC. They all have their own MVC-ish variation instead. It almost seems that MVC isn't actually a perfect fit for the problem space, but people are trying to make it fit anyway.

I think people overvalue MVC, in the discussion about JavaScript web app frameworks, for two reasons. First, there's an old saying that generals are always fighting the last war, which basically means that strategic thinkers often fall in love with particular strategies, and fail to notice when there's been a major change in the criteria for evaluating those strategies. Second, there's a much more prosaic factor: David Heinemeier Hansson is an incredible salesman. He sold the entire web dev world on the concept of MVC, and did so with such effectiveness and thoroughness that web devs still frame questions in terms of MVC, even in situations where MVC is not the most important factor. I think this is one of those situations.

Backbone has a superior object design to Ember. I can barely even call it a matter of opinion. There's great clarity, great simplicity, and the objects are quite simply what they claim to be. I can't say any of those things for Ember. But Ember has a system for handling live data binding which is powerful and easy to use. Backbone's system makes you do a lot of the heavy lifting when it comes to handling events, and that's exactly the kind of lifting which is most likely to throw your back out. (At least, it was for me; your mileage may vary.)

Backbone has a much nicer learning curve than Ember, at least at the beginning stages, and I would still prefer a Backbone-esque level of elegance when building a browser app. But I found Ember's more graceful event handling made all the difference in the world when writing apps, while its confused MVC implementation was really just a speed bump for me. As for the things Ember hides from you, in theory I expected it to bother me a lot, but in practice, I got over it pretty fast.

Caveats: of course, this is all just my opinion. I only spent a few months building a few apps with each system. And speaking of "fighting the last war," I haven't yet seriously investigated Angular, Knockout, or any of the several other alternatives. There's always something new.

PS: Obviously, I want people to buy my book.

Monday, July 22, 2013

Picasso vs Stereotype

If, as Picasso said, art is the lie that tells the truth, it is hard to explain why artists evolved in the first place. Why would there be any evolutionary benefit in a subset of humans who spend their time telling lies in order to reveal truths? It is obviously more direct and efficient to tell a truth in order to reveal a truth.

One possible explanation: artists are an immune system against stereotypes. You can find an instance of any stereotype, whether it is a nasty stereotype or a flattering one, especially if you don't look very deeply. The problem with stereotypes is not that they represent pure fictions, but that they severely overgeneralize from genuine facts.

In other words, every stereotype represents a truth which tells a lie. Lies which tell the truth balance them out.

Feedback On My Ember Book

I wrote an ebook about Ember.js. Here's some feedback from Twitter:

There's also a nice review on the Ember Watch blog.

Sunday, July 21, 2013

Free Animated Typeface / Free Typographic Animations

We asked every animator to pick a glyph and animate it using no more than 4 colors, 25 frames and a 500 x 600 px canvas in Adobe After Effects. The animators had complete freedom to work their magic within those 25 frames. The result is a wide variety of styles and techniques. The color palette and letterforms tie it all together.

Lots more info (and a download link) at motionographer.

Saturday, July 20, 2013

Tuesday, July 16, 2013

Invalid memory access of location 0x160 rip=0x11f05c57c

If Overtone crashes and throws this error, use Audio MIDI Setup to verify that your sampling rate is set to 44.1kHz.

Wednesday, July 10, 2013

Yes We Scan

Wednesday, June 19, 2013

Heretical Guide To Ember JS

I've written a new ebook. It provides a detailed introduction to Ember.js.

One enormous caveat: it doesn't deal with the data layer at all. I think this is fine, because Ember Data hasn't gotten near 1.0 yet, and Discourse and some other Ember projects roll their own data layers anyway. Nonetheless, my new book's 108 pages long, with extensive code samples, because there's a lot of other material in Ember to cover.

The book covers a few different Ember "hello world" implementations, then shows you how to build a trivial GitHub notifications API reader, and then walks you through building a complete chess game, with HTML5 drag and drop, and similar user interface flourishes.

The gradually-increasing sophistication of these example applications helps me acquaint you with the Ember mentality. Ember's widely known to have a somewhat punishing initial learning curve. By starting out super easy and building more and more sophisticated code, my book can get you through that learning curve much, much faster.

My book also takes a critical examination of Ember's idea of MVC. Spoiler alert: I don't think Ember chose its class names perfectly. I don't think the Ember Controller really is a controller, for example. But I do think Ember is useful. In the same way that experienced Rails developers have to achieve a sophisticated and sometimes critical understanding of Rails in order to make subtle decisions about how to use Rails most effectively, I deconstruct Ember MVC and assemble a new way of understanding Ember which I think is much more effective than the default interpretation, and will make it much easier for you to reason about your Ember apps.

Basically, I figured out Ember so you won't have to. Many people who think Ember's Controllers are not real controllers are left helpless and baffled to explain what Ember's Controllers really are, but I think my book makes that question very easy to answer. So you can skip that whole confusion phase and jump right into building great apps.

Likewise, there are a few places in Ember where there's more than one way to accomplish a given task, and your job becomes to choose the right method. That can be hard without a good mental model, but not everybody learns well from a theoretical perspective, so, in the section on the {{action}} handler, I re-implement the same functionality several different ways, and compare the implementations.

My book about Ember is obviously the best book about Ember, because it's the only book about Ember, but people have told me that my book about Rails is the best book about Rails, and there are many, many books about Rails.

Update: my mistake, there's a book on Amazon and a book on the way from Manning also. My book might be the best book on Ember anyway, but it might not; I don't know yet.

Update: A review from Ember Watch says my book "is the best book on Ember.js, because it's finished, it's focused, it's fit for purpose, and it's fun."

Saturday, June 15, 2013

Tango Protest

Tuesday, May 28, 2013

Ember Animation Hello World

Ember Animated Outlet is a great little GitHub project with a simple demo which, as an Ember newbie, I nonetheless found a little confusing to implement, so I stripped it down to a "Hello World" use case to make the code easy to use and explain.

Friday, May 24, 2013

How Git's Smudge And Clean Filters Work

The technique is powerful but obscure, so I created a repo on GitHub which demonstrates it.

Basically, smudge is equivalent to "run this code whenever you check anything out," and clean is equivalent to "run this code whenever you check anything in." One major caveat to that overgeneralization is that git expects the code you run to be a filter. Because of this, it not only expects input from standard out and passes your code input via standard in, it also suppresses both standard out and standard error.

(Like git-bisect, git filters allow you to execute arbitrary Unix software in a very powerful context, opening up the possibility for other use cases, but firmly encourages a particular use case.)

Wednesday, May 8, 2013

Elektron Analog Four: Phenomenal Demo

One of the challenges I saw with Archaeopteryx: programmers got so excited about the code side of it, they distracted me from the actual instrumentalist aspect.

This is awesome. And so is this. But so is this:

Saturday, May 4, 2013

Stop Drawing Dead Fish

Another brilliant presentation from Bret Victor. The spirit of Xerox Parc remains alive, and then some; he transfers, to animation, the machine control as performance dynamic which characterizes DJing. Very highly recommended.

Tuesday, April 23, 2013

Music-Generating Swings In Montreal

Sunday, April 21, 2013

New Track On SoundCloud: "Willfully Obtuse"

It's a leftfield drum and bass track with an indie rock feel to it.

Probably very influenced (unintentionally) by this Diiv song.

Thursday, April 11, 2013

A Hello World In Ember.js

I saw several blog posts with inaccurate code for a 'hello world' in Ember. Here's code which actually works:

Loading this file gets you an "index" (default) view with a "hi" link, and clicking that link gets you to "hello world!".

I'm a little embarrassed about 'index' as a naming choice, because it's a bad habit, but I got it from the framework. Ember uses 'index' to mean 'default view,' the same way Rails controllers do. This probably came to Ember from Rails, and came to Rails from Apache, but it really has nothing to do with indexing whatsoever. It's one of the few completely cargo-cult elements in Rails, so it's not my favorite part of Ember either.

However, one thing I do want to give Ember credit for, which you can see in this example: this code's concise. In fact it could be a lot more concise; that 'index' route doesn't actually need to be there. Like a lot of things, Ember supplies it automatically.

So this is better:

And also:

Rewind: Analyzing Git History With Bash

Rewind is a small library of git analysis scripts in Ruby and bash. Its goal is to quickly extract meaningful context from the enormous amount of historical data which any git project provides.

One use case: you want to compare the respective authorship patterns of two forks of a library from GitHub. Maybe your company has a local gem forked from a popular gem, and you want to figure out how many unique changes your fork has.

Another use case: you're looking at a large library with a lot of files, and you've been told this library has a lot of technical debt. One way to track down technical debt is to find the files which a) have the largest number of lines of code, and b) have the largest number of commits. Conversely, if you see a very small file with a very large number of commits in its history, people have probably refactored that file a lot.

Rewind gives you numbers; you have to use good judgement to get useful insights from those numbers.

Saturday, April 6, 2013

Friday, April 5, 2013

Your Periodic Reminder That Silicon Valley's Perceptions Are Skewed

Earlier this year Chris Dixon wrote what is mostly a good blog post, but sadly also a classic of blind northern California arrogance:

What the smartest people do on the weekend is what everyone else will do during the week in ten years...

Engineers vote with their time, and are mostly trying to invent interesting new things. Hobbies are what the smartest people spend their time on when they aren’t constrained by near-term financial goals...

Today, the tech hobbies with momentum include: math-based currencies like Bitcoin, new software development tools like NoSQL databases, the internet of things, 3D printing, touch-free human/computer interfaces, and “artisanal” hardware like the kind you find on Kickstarter.

It’s a good bet these present-day hobbies will seed future industries.

This statement is true within a bounded territory, but it has two zones of epic fail.

If by "the smartest people" you mean "the smartest young, single geeks in Silicon Valley with time on their hands but no idea how to party," then it's basically true, or close enough. It can even stay mostly true when you broaden it to "the smartest geeks in Silicon Valley."

But if by "the smartest people" you mean "the smartest people in Silicon Valley," you quickly run into the first zone of epic fail. Steve Wozniak did it as a hobby; Steve Jobs did it as a business. So the idea can only be legit if we assume Wozniak was smarter than Jobs. This is not only a dickhead thing to say, it's also extremely debatable.

That same problem becomes much, much more serious in the idea's grander zone of epic fail, which is the world at large. If by "the smartest people" you actually do literally mean "the smartest people," this statement falls from a lofty status of near-flawless truism — which it achieves when isolated to a particular subset of Silicon Valley geeks — down to a nadir of useless and near-total inaccuracy.

It can only be true if none of the smartest people are also uneducated; if none of the smartest people work on the weekend, or go to school on the weekend; if none of the smartest people are beset by war, famine, illness, or other distracting, weekend-filling forms of misfortune; and if none of the smartest people, anywhere ever, like to spend their weekends making music, making art, making films, or volunteering their time to feed the homeless, end various injustices, or make the world a better place in any other non-commercial sense, or indeed just having fun.

For instance, consider the Oscar-winning actress and budding director Natalie Portman, who first published her scientific discoveries in peer-reviewed journals while in high school. If she spends her free time geeking out about Bitcoin, Dixon's rule applies to her. If not, then either Dixon's rule is silly, or she is not one of the smartest people out there. But that would mean winning the top award in one of the most competitive fields in the world, attending Harvard, and publishing in scientific journals while essentially still a child would not be reliable indicators of high intelligence, while selecting a hobby which went on to become a big business would be a reliable indicator of high intelligence.

It doesn't take long to find many similar examples; and, as an experiment, I just googled "Natalie Portman charity work." Turns out there's enough there to win her another award. I hope she did all that charity work during business hours, because if it happened on the weekend, she's off that genius list.

It's good to pay attention to what the startup community talks about. You just need to take it with a grain of salt.

Thursday, April 4, 2013

Snippet: Drum & Bass w/String Section

A little variation from the norm; more melody than usual for me.

Saturday, March 30, 2013

Music Theory As An Algebra

In the introduction to Charles Pinter's A Book of Abstract Algebra, he covers a very brief history of algebra, examines differences between matrix algebra, numeric algebra, and boolean algebra, and then says:

Other exotic algebras arose in a variety of contexts, often in connection with scientific problems... Today it is estimated that over 200 different kinds of algebraic systems have been studied, each of which arose in connection with some application or specific need.

As legions of new algebras began to occupy the attention of mathematicians, the awareness grew that algebra can no longer be conceived merely as the science of solving equations. It had to be viewed much more broadly as a branch of mathematics capable of revealing general principles which apply equally to all known and all possible algebras.

What is it that all algebras have in common? What trait do they share which lets us refer to them as "algebras"? In the most general sense, every algebra consists of a set (a set of numbers, a set of matrices, a set of switching components, or any other kind of set) and certain operations on that set. An operation is simply a way of combining any two members of a set to produce a third member of the same set.

Thus, we are led to the modern notion of algebraic structure. An algebraic structure is understood to be an arbitrary set, with one or more operations defined on it. And algebra, then, is defined to be the study of algebraic structures...

Any set, with a rule (or rules) for combining its elements, is already an algebraic structure. There does not need to be any connection with known mathematics. For example, consider the set of all colors (pure colors as well as color combinations) and the operation of mixing any two colors to produce a new color. This may be conceived of as an algebraic structure. It obeys certain rules, such as the commutative law (mixing red and blue is the same as mixing blue and red). In a similar vein, consider the set of all musical sounds with the operation of combining any two sounds to produce a new (harmonious or disharmonious) combination.

Pinter's definition is of course almost insanely broad. "Combining any two members of a set to produce a third member of the same set" describes sexual reproduction, the construction of sentences, software development, Borges's infinite library, and a huge variety of other things. As long as you can discover any form of predictable combinatorial patterns, you can infer rules exist. But I like this definition very much, because it is a really useful way to understand music theory, especially Western musical notation, which definitely qualifies as a sophisticated and deep algebra under Pinter's definition.

Of course, music theory is not everything. Orchestral musicians have a saying that "90% of the music is not in the score." (The term "score" refers to the written representation of the music.) The same is extremely true of my own long-term obsession, electronic dance music, where the number might be nearer 99%. It's very, very common in both techno and trance to play the same melody or bassline repeatedly, changing the timbre (or sound design) while leaving the motif unchanged.

Here are a couple of very illustrative examples. It occurs quite a lot in other subgenres as well, of course; the first example is from drum and bass. There's also good coverage of this in Unlocking The Groove, which despite its seemingly casual title is a thick academic book from a music theory PhD.

Anyway, although music theory is not everything, dance music is as hopeless without it as any other form of music. And speaking of challenging books, I'm only about 20 pages in — three appendices and half an introduction — but Pinter's book is so far the most entertaining book on math I've read in a very long time.