There are lots of tools for doing diffs between two source files, but I'm not aware of any source control system (save Perforce, which we use at ArenaNet) that do a timeline view of all revisions since a file was first checked in, and none that store the entire revision history in a single, web-friendly format. This is a shame, because my goal for several parts of the textbook is to be able to "replay" the process of writing a script, to show how it develops from a few lines of simple code into larger and more functional units like functions and prototypes. It's possible that someone else has done something like this, but a cursory Google couldn't turn it up, so I made my own.
You don't have to write these files by hand, which is good, because they can get pretty nightmarish. Instead, I've written an authoring tool for putting in multiple revisions (or importing them, using the HTML5 file API), commenting them, and exporting them. Using Ace means the editor is friendly and includes source-highlighting, which is great. You also don't have to worry about writing an output parser: the TLPlayer module is not quite complete, but it's done enough to wire it up to a UI and let people flip through the file, with new lines highlighted in the output.
If you'd like to see a demo, I've started using it for the chapter on writing functions. My goal is to put at least one timelapse at the end of each chapter, so that readers can see the subject matter being used to build at least on real-world code script. By doing these as revision histories, I'm hoping to avoid the common textbook "dump a huge source example into the chapter" syndrome. I know when I see that, my eyes glaze over--I don't see any reason that it's any different for my students.
Although I don't have a license on the textbook files yet (they'll probably be MIT-licensed in the near future), you're welcome to use these two modules for your own projects, and feel free to submit patches (the serialization, in particular, could probably use some love with someone with a stronger parsing background). I'd love to see if this is useful for anyone else, and I'm hoping it will help make this textbook project much friendlier to new developers.
They always want the writer to work for nothing. And the problem is that there's so goddamn many writers who have no idea that they're supposed to be paid every time they do something, they do it for nothing! ... I get so angry about this, because you're undercut by all the amateurs. It's the amateurs who make it tough for the professionals, because when you act professional, these people are so used to getting it for nothing, and for mooching...
Last week, Nate Thayer wrote a well-linked post about being asked to write for The Atlantic for free--well, for "exposure," which is free in a funny hat. It's gotten a lot of attention in the journalism community, including a good piece on the economics of web-scale journalism by Atlantic editor Alexis Madrigal.
I read this kind of stuff and think that I have never been happier to find a niche within journalism that makes me marketable. I mean, not that marketable: I had to switch industries when I moved out of DC, after all. But inside the beltway, I didn't have to freelance anymore, and I would have had plenty of options if I decided to leave CQ and head somewhere else. Data journalism was good to me, and I can't imagine having to go back to the scramble of being just a writer again.
But beneath that relief, I feel angry. And the fact that Madrigal can write a well-reasoned piece about why they're asking people to write for free doesn't make me any less angry. The fact that Ta-Nehisi Coates, who I respect greatly, can write about how writing for free launched the best part of his career, doesn't make me feel any less annoyed. I'm getting older but I'm still punk enough that when someone tells me the system is keeping us down, my response isn't to say, "well, I guess that's just how it is." The system needs to change.
Let's be clear: I don't expect writers to make a lot of money. They never have. People don't get into journalism because they expect to be rich. But writing--serious writing, not just randomly blogging on your pet peeves like I do here 90% of the time--is hard work. The long-form pieces that I've done have been drawn-out, time-consuming affairs: research, interviews, collecting notes, writing, rewriting, editing, trimming, and rewriting again. People think that writing is easy, but it's not, and it should be a paid job. (Even when it's not paid, it's not easy: I've been editing this post for three days now.)
As Ellison says, when publications can get the work for free, it makes it really hard to be paid for your writing. I'm not sure I'd phrase it with the same antipathy for "amateurs" (let's be clear: Ellison is a terrifying human being that I happen to agree with in this particular case), but it's certainly true that the glut of people willing to write for free causes a serious problem for those of us who write (or have written) for a living. They're scabs, in the union sense: they take work that should be paid, and drive down the cost of labor (see also: unpaid musicians).
All in all, the creative landscape is starting to look more toxic than it's been in our lifetimes: Artists with million-dollar checks in their pockets are telling other artists that they shouldn't expect to get paid; publications are telling writers that they shouldn't expect to get paid, either; and meanwhile everyone wonders why we can't get more diversity in the creative ranks. One obvious way to reverse media's glut of wealthy white people would be to stop making it so few others but wealthy white people can afford to get into media. But in the age of dramatic newsroom layoffs and folding publications, nobody wants to hear that.When your publishing model depends on people writing for free, there are a lot of people who aren't going to get published. I couldn't afford internships during college, meaning that I had a hard time breaking in--but I was still relatively lucky. I worked in office jobs with flexible hours and understanding bosses. If I wanted to take an early lunch break in order to do a phone interview, I could. I had evenings free to work on writing and research. I could take jobs that paid 10¢ a word, because I only had a day job. A lot of people don't have that chance, including a disproportionate number of minorities.
It adds insult to injury when you look at some of the people who are published precisely because they could afford internships and writing for free. Sure, it's wrong to base an argument on a few highly-visible outliers. But it's hard not to be a little furious to see the NYT sending good money to Tom Friedman (the obvious travesty), or Roger Cohen, or David Brooks when the industry claims it can't offer new writers recompense. It burns to see The Atlantic insisting that paying people isn't sustainable when they gave Megan McArdle (a hack's hack if there ever was one) a career for years, not to mention running propaganda for the Church of Scientology. If you're going to claim that you're trying as hard as you can to uphold a long-standing journalistic legacy in tough economic times, you'd better make sure your hands are clean before you hold them out in supplication.
I am skeptical, personally, of claims that the industry as a whole can't afford to pay writers. I have heard newsroom financials and profit margins, both for my own employer and for others. The news is no longer a business that prints money, but it remains profitable, as far as I can tell--if not as profitable as management would often like. Perhaps that's not true of The Atlantic: I don't know the details of their balance sheet, although this 2010 NYT article says they made "a tidy profit of $1.8 million this year" and this 2012 article credits them with three years of profitability. That's an impressive bankroll for someone who claims they don't have the budget to pay writers for feature work.
That said, let's accept that I am not an industry expert. It's entirely possible that I'm wrong, and these are desparate times for publications. I can't solve this problem for them. But I can choose a place to stand on my end. I don't work for free, unless it's explicitly for myself under terms that I completely control (i.e., this blog and the others that I fail to maintain as diligently), the same way that I don't take gigs from paying musicians just because I like playing in front of an audience.
Coates may defend working for free, because it got him a guest spot at the publication where he now works. But to me, the most important part of the story is that he got that spot on the strength of his blogging, which drew the attention of other writers and editors. You want exposure? There's nothing wrong with making it for yourself. Please start a blog, and hustle for it like crazy. But don't let other people tell you that it's the same as a paycheck--especially when they're not working for "exposure." They're on salary.
Is there a chance that, as with Coates and so many others, that exposure could lead to better gigs? Sure, the same way that a musician might get discovered while playing folk covers at a Potbelly sandwich shop. But it's a lottery, and pointing to successful writers who came up that way ignores the order of magnitude more that wrote for exposure and promptly sank into obscurity. You can't pay your rent with publicity, and you never could. We're professionals, and we should demand to be treated that way.
I haven't had a chance to do more than plan a few topics to write about here, since I've been working hard on my textbook. You can now browse the built pages on GitHub without needing to check out the repo. This is a pretty handy way to publish a website. It's not particularly attractive yet, but there are two-and-a-half chapters up so far, and more on the way. I guess those long bus commutes are good for something, right?
In addition to the text, browsing the repo's /js directory will expose a few interesting AMD modules now that I've started building the interactive parts of the book as well. Given my plans for various visualizations and live quizzes, I suspect the script package may be as interesting as the book for a lot of people by the time I'm done. Here's most of what I've got so far:
In order to build the book, you'll also need NodeJS with Grunt, grunt-contrib-less, and grunt-contrib-watch installed. In addition to using LESS and RequireJS, I've written the World's Worst Template system to reduce boilerplate. The repo contains fully-built versions of the site, so you don't need to build it to read, but it would be helpful for pull requests and testing.
As I'm working on this project, I'll commit to the repo and update GitHub. If anyone wants to file pull requests for things that are technically wrong, confusing, or need more explanation, please feel free. Contributors will get their names in a credits section, although I will have to ask that copyright be assigned to me as a precaution, in case I ever wanted this to see print. If nothing else, I hope people find it to be useful as a resource. Teaching has become one of the most rewarding parts of our move to Seattle, and I don't see any reason that should be limited to just my classroom.
On Friday, Thao and the Get Down Stay Down played a show at the Sonic Boom near our apartment in Seattle. The shop was completely packed, which was a pleasant surprise. Seeing a Thao Nguyen concert, even in abbreviated record-shop form, is always a treat: live, she performs with a kind of abandon that privileges energy over accuracy, and you really get the full impact of her voice, which can veer from a mutter to a howl in the space of a beat.
The best parts of her new album, We the Common, are the songs that let that voice greedily cover its full range. The titular opening number is a stompy rallying cry that builds from a choppy banjo riff until it soars into a wordless chorus. "The Day Long" showcases the quieter, spookier side of the album, but is no less effective: it has a kind of marching melancholy that's weirdly danceable. In between, there's the jaunty swing of "The Feeling Kind," which wouldn't be out of place on the band's first album.
The production remains top-notch: they seem to have picked up a few tricks from Thao's collaboration with Mirah (especially the Tune-Yards'-produced "Eleven"), but applied it to her particular brand of indie rock. "Every Body" mixes a spiky ukelele with synth bass, and while it may just be that I've been listening to a lot of Stop Making Sense lately, I hear a touch of the Talking Heads in the punchy, over-distorted "City," probably in the call-and-response that closes it out. It's becoming one of my favorite songs on the CD, along with the boozy wall of sound that is "Age of Ice."
Fittingly, the most skippable tracks involve times when Nguyen's voice is either kept to a single mood (the dirge-like "Clouds for Brains") or, more bizarrely, paired with Joanna Newsom on "Kindness Be Conceived." Newsom's folky, child-like voice is an acquired taste I've never found appealing, and it tips an otherwise inoffensive song over into tweeness.
We the Common isn't as dark as Know Better, Learn Faster, but it's still not what I'd call cheerful. It's probably not as political as the title sounds, either, although with her elliptical lyrics that's hard to know for sure. But it remains tightly-crafted songwriting wrapped around a unique, powerful voice. I think it's a must-listen, but don't take my word for it: check out their short performance on KEXP and see what you think.
Last night I gave a presentation for Seattle Central's Byte Club (and other interested students) on using LESS to write better, easier-to-maintain stylesheets. The lecture was recorded in a Google Hangout, which means that you can watch it yourself, if you're interested in LESS or if you've ever wondered what it's like to be trapped in a classroom with me for an hour:
The audio is a little wonky, it's a little hard to see sometimes, and I don't know why the one guy in the classroom with me insisted on keeping his webcam on the entire time (if I'd thought about it, I would have had him turn the camera on me, instead). But all in all, I think it turned out pretty well.
Every year at the Super Bowl, for many years now, it's traditional for GoDaddy to remind everyone that they're a horrible company run by a creepy, elephant-hunting misogynist. This year was no different. The good news is that I was working on the Soul Society website on Sunday, so I didn't actually see any of their ads. The bad news is that Soul Society is hosted on GoDaddy (cue ironic record scratch).
The thing about GoDaddy is that they are fractally gross: everything about them gets more distasteful the more you dig into it. There is no part of their operation that does not make you want to take a shower after interacting with them--neither the advertising, nor the sales experience, nor the admin panels, and certainly not the actual hosting.
It should be enough that the company was run, for years, by a horrible, horrible person who kills elephants for sport, supports torturing Guantanamo Bay detainees, and is a relentless self-promoter. You should look no further than its incredibly sexist advertising, which manages to be both repulsive and badly produced. The fact that they originally came out in favor of SOPA just rounds out the list of offensive behavior.
But if, despite all those reasons, you go to sign up for an account (as many people, including many of my students, end up doing), chances are that you'll end up overpaying due to an intentionally-confusing sales process. The upsell actually doesn't stop at the first purchase. Every time I interact with the site, I'm forced to wade through a morass of confusing ads and sale links masquerading as admin panels. Everything on GoDaddy leads to a shopping cart.
GoDaddy also parcels up its crappy service into smaller pieces, so they can force you to pay more for stuff that you should get for free. As an example, I have an urbanartistry.org e-mail address for when we need a webmaster link on the site. For a while, it was a separate mailbox, which meant that I never checked it. Then I missed a bunch of e-mails from other UA directors, and decided to redirect the e-mail address to my personal account. On most mail providers, this is a free service. On GoDaddy, you can set up a forward, but an actual alias costs an additional fee (for all the disk space it... doesn't use?). Which means, technically, that my mail is piling up on their servers, and at some point they'll probably figure out some new reason to screw it up.
And let's not pretend the hosting you get after all this hassle is any good. The server is a slow, underpowered shared account somewhere, which means you don't get your own database (have fun sharing a remote MySQL instance with a bunch of other people, suckers!), and you can't run any decent versioning or deployment software. The Apache instance is badly configured (rewrite rules are overridden by their obnoxious 404, among other things). Bandwidth is limited--I have never seen slower transfers than on GoDaddy, and my SFTP connection often drops when updating the site. It's a lot of fun debugging a WordPress theme (already not the speediest of pages) when your updates get stuck in a background window.
I don't write a lot of posts like this, because I've got better things to do with my time these days than complain about poor service somewhere. There's a lot of repulsive companies out there, and while I believe in shame-and-blame actions, there's only so many hours in the day. I'm trying to have a positive outlook. But it is rare that you find something that's so awful you can't think of a single redeeming quality, and GoDaddy is that company. If you're in the market for any kind of web service, and you haven't already been convinced to go elsewhere, let me add my voice to the chorus. Lifehacker's post on moving away from the company is also a great reference for people who are already customers. I'm probably stuck with them, because Urban Artistry has more important things to worry about than their hosting, but you don't have to be.
Gun Machine, by Warren Ellis
Warren Ellis is a writer of a particular style, which can be polarizing. When it's good--as in Transmetropolitan, his frighteningly amusing riff on Hunter-Thompson-meets-Futurama political journalism--it's very good, but there are other times when it comes across as bluster. His first novel, Crooked Little Vein, was a good example: over its 200-odd pages the schtick wore thin, and the catalog of American fetish weirdness that was left (while funny) wasn't enough to carry it.
His second book, Gun Machine surprises on two levels. The first is that it pulls back substantially from Ellis' usual over-the-top dialog style. It still surfaces for comedic effect (Ellis gets a lot of mileage out of two manic CSI technicians), but most of the prose is written more restrained, or in another, Ludlum-like style entirely. This gives the book something Crooked Little Vein never really had: dynamics. The characters have room to breathe, and become a lot more sympathetic, when they're not all shouting in the same voice.
The other surprise is that the book actually works as the mystery-thriller it appears to be, since I was expecting something less traditional. It follows John Tallow, a New York City cop who is coasting along on his partner's graces when said partner is shot, simultaneously revealing a room full of purloined firearms arranged in complicated patterns--the "gun machine" of the title. Alternating chapters follow the room's owner, a schizophrenic killer for hire who's been working for influential New Yorkers over several decades.
It's not like Ellis is a stranger to mystery stories, or to conspiracy theories, but his usual M.O. tends to be more scattershot in scope, sprinkled liberally with Internet-age trivia. Gun Machine eschews this in favor of a lot of Manhattan history, and its relatively subdued narrative voice gives Ellis a chance to explore Tallow's gradual re-engagement with the world as he becomes more caught up in the case. It's a more thoughtful, sympathetic approach than I expected, in the best possible way.
Gun Machine has a few sections where it bogs down, and where it stretches across the line of plausibility, although it tends to skip past these deftly enough that they don't stand out until you stop and think about them later. But overall, it's a crackling little piece of genre fiction, paired with just enough in the way of characterization and unexpected turns to keep you turning pages without actually feeling guilty about it.
Rise of the Videogame Zinesters, by Anna Anthropy
Someone had to write this book. It was really just a question of who would get there first: someone from the maker/craft culture, or someone like Anthropy, a cranky member of the independent game design community. Zinesters is a book about democratizing gaming: the idea that anyone should be able to write a video game, the same way that anyone can paint a picture or write a story.
If video games can be art, what does "outsider art" in that medium look like? Where are the subversive messages? And how do we give a canvas to more people--people who aren't young, white men? As the creator of several adamantly non-mainstream works, like Dys4ia and Mighty Jill Off, these are not idle questions for Anthropy. So her goals are two-fold: to explain the ways that games can be more accessibly, and (more importantly) to convince readers that making them is something they should want to do.
I'm not sure it succeeds at the latter (to avoid tying her book too closely to any given tool, Anthropy basically lists a number of entry-level game engines and then gives readers a pep-talk), but the former is extremely well done. Starting from the definition of a game as "an experience created by rules," she uses that as a jumping off point to examine game design, its relationship to society, and "folk games."
Rise of the Videogame Zinesters is a very, very short book, and it often reads as a collection of blog posts instead of a single work, but it's an impressive tour of gaming at the margins of culture. If her argument has a weakness, it's contained in the title: considering the fade of zines (eclipsed by Internet blogging, now also on its decline), are there other models for DIY game creation that might need to be examined? How do independent games compare with indie films, or hackerspaces, or crafting?
It's not that Anthropy is wrong to pick zines as a starting point--given her emphasis on LGBT culture and fast/cheap creation, it's appropriate--but there's a lot of other creative philosophies that would be interesting to consider, and might result in very different interactive experiences. It may not be Anthropy's responsibility (or interest--it's a very personal series of essays) to present those, but in a book this brief, it couldn't hurt. As it is, we catch only a glimpse in her impressive citations, from the open-ended (ZZT) to the surrealist (La La Land 2) to the meta (Execution). The introduction to this diversity of gaming is intriguing, and it's a little disappointing when the corresponding analysis is relatively thin.
There's an ongoing discussion I'm having with the other instructors at Seattle Central Community College on how to improve our web development program. I come from a slightly different perspective than many of them, having worked in large organizations my whole career (most of them are freelancers). So there are places where we agree the program can do better (updating its HTML/CSS standards, reordering the PHP classes) and places where we differ (I'm strongly in favor of merging the design and development tracks). But there's one change that I increasingly think would make the biggest difference to any budding web developer: learning source control.
Source control management (SCM) is important in and of itself. I use it all the time for projects that I'm personally working on, so that I can track my own changes and work across a number of different machines. It's not impossible to be hired without SCM skills, but it is a mark against a potential employee, because no decent development team works without it. And using some kind of version control system is essential to participating in the modern open-source community, which is the number one way I advise students to get concrete experience for their resumes.
But more importantly, tools like Git and Subversion are gateways to the wider developer ecosystem. If you can clone a repo in Git, then you now have a tool for deployments, and you stop developing everything over FTP (local servers become much more convenient). Commits can be checked for validity before they go into the repo, so now you may be looking at automated code parsers and linting tools. All of these are probably going to lead you to other trendy utilities, like preprocessors and live reload. There's a whole world of people working on the web developer experience, creating workflows that didn't exist as recent as two or three years ago, and source control serves as a good introduction to it.
The objection I often hear is that instructors don't have time to keep up with everything across the entire web development field. Whether or not that's a valid complaint (and I feel strongly that it isn't), it's just not that hard to get started with version control these days. Git installs a small Bash shell with a repo-aware prompt. GitHub's client for Windows does not handle the advanced features, but it covers the 90% use case very well with a friendly UI. Tortoise has Windows add-ons for Git, SVN, and Mercurial. Learning to create a repo and commit files has never been easier--everything after that is gravy.
Last quarter, I recommended that teams coordinate their WordPress themes via GitHub, and gave a quick lecture on how to use it. The few teams that took me up on it considered it a good experience, and I had several others tell me they wish they'd used it (instead of manually versioning their work over DropBox). This quarter, I'm accepting homework via repo instead of portal sites, if students want--it'll make grading much easier, if nothing else. But these are stopgap, rearguard measures.
What SCCC needs, I think, is a class just on tooling, covering source control, preprocessing, and scripting. A class like this would serve as a stealth introduction to real-world developer workflows, from start (IDEs and test-driven development) to finish (deployment and build scripts). And it would be taught early enough (preferably concurrent with or right after HTML/CSS) that any of the programming courses could take it as a given. New developers would see a real boost in their value, and I honestly think that many experienced developers might also find it beneficial. Plus it'd be great training for me--I'm always looking for a good reason to dig deeper into my tools. Now I just have to convince the administration to give it a shot.
I used a Nexus One as my smartphone for almost three years, pretty much since it was released in 2010. That's a pretty good testimonial. The N1 wasn't perfect--it was arguably underpowered even at release, and held back for upgrades by the pokey video chip and small memory--but it was good enough. When Google announced the Nexus Four, it was the first time I really felt like it was worth upgrading, and I've been using one for the last couple of months.
One big change, pardon the pun, is just the size of the thing: although it's thinner, the N4 is almost half an inch wider and taller than my old phone (the screen is a full diagonal inch larger). The N1 had a pleasant density, while between the size and the glass backing, the N4 feels less secure in your hand, and at first it doesn't seem like you're getting much for the extra size. Then I went back to use the N1 for something, and the virtual keyboard keys looked as small as kitten teeth. I'm (tentatively) a fan now. Battery life is also better than the N1, although I had to turn wifi on to stop Locale from keeping the phone awake constantly.
I think it's a shame they ditched the trackball after the Nexus One, too. Every time I need to move the cursor just a little bit, pick a small link on a non-mobile web page, or play a game that uses software buttons, I really miss that trackball. Reviewers made fun of it, but it was regularly useful (and with Cyanogen, it doubled as a second power button).
The more significant shift, honestly, was probably going from Android 2.3 to 4.2. For the most part, it's better where Android was already good: notifications are richer, switching tasks is more convenient, and most of the built-in applications are less awful (the POP e-mail client is still a disaster). Being able to run Chrome is usually very nice. Maps in particularly really benefits from a more powerful GPU. Running old Android apps can be a little clunky, but I mostly notice that in K-9 Mail (which was not a UX home run to begin with). The only software feature that I do really miss is real USB hosting--you can still get to internal storage, but it mounts as a multimedia device instead of a disk, which means that you can't reliably run computer applications from the phone drive.
There is always a lot of hullaballoo online around Android upgrades, since many phones don't get them. But my experience has been that most of it doesn't really matter. Most of my usage falls into a few simple categories, none of which were held back by Android 2.3:
Compared to its competitors, Android was always been designed to be standalone. It doesn't rely on a desktop program like iTunes to synchronize files, and it doesn't really live in a strong ecosystem the way that Windows Phone does--you don't actually need a Google Account to use one. It's the only mainstream mobile platform where installing applications from a third-party is both allowed and relatively easy, and where files and data can transfer easily between applications in a workflow. Between the bigger phone size (or tablets) and support for keyboards/mice, there's the possibility that you could do real work on a Nexus 4, for certain definitions of "real work." I think it would still drive me crazy to use it full-time. But it's gradually becoming a viable platform (and one that leaves ChromeOS in kind of an awkward place).
So sure, the Nexus 4 is a great smartphone. For the asking price ($300) it's a real value. But where things get interesting is that Android phones that aren't quite as high-powered or premium-branded (but still run the same applications and OS, and are still easily as powerful as laptops from only a few years ago) are available for a lot less money. This was always the theory behind Nokia's smartphones: cheap but powerful devices that could be "computers" for the developing world. Unfortunately, Symbian was never going to be hackable by people in those countries, and then Nokia started to fall apart. In the meantime, Android has a real shot at doing what S60 wanted to do, and with a pretty good (and still evolving) open toolkit for its users. I still think that's a goal worth targeting.