It’s now confirmed that, in 1968, Nixon sabotaged the Paris Peace Talks in order to beat Humphrey.
I find it hard to understand why LBJ sat still for it. Yes, it would have been a fantastic mess. Yes, it was a volatile time. Yes, he might have made another Checkers speech and won anyway.
But — seriously. Good grief.
The prototype of the modern Republican party wasn’t AuH2O after all.
It’s going to be April 13-14, 2013.
It’s going to be great. (Early registration this weekend only will save you some money.)
We’re going to focus on breaking down barriers. Are you stuck with a Tinderbox project? Have you never felt you really got the hang of Tinderbox? We’ll get you sorted out in no time.
We’ll also have the first public look at Tinderbox Six.
Join us!
My mailbox has been filled lately with queries from happy Web Science authors. They are happy but few: our acceptance rate is going to be around 35% if you include posters (which you should) or 15% if you don’t (and various grant agencies and provosts and pointy-headed bosses do not).
Some people want to know if they can publish their paper without attending the conference. Some people want to know when they are scheduled to speak, so they can rush off to another city after they’re done.
This is wrong. If we wanted to publish a bunch of papers, we’d do that. That’s called a book. I’ve seen books before. So have you. A conference is not a book.
More than fifteen years ago, I was at a hypertext conference. There was a big demo session, and Norbert Streitz, already a big wheel at GMD, was personally demonstrating his group’s SEPIA. One of the details of its hypertext map was that, when you moved a note, the links moved while you dragged.
I’d assumed that we couldn’t do that, that the performance would be too slow. “I don’t think it will be too slow,” Dr. Dr. Streitz reassured me.
“What if we want to use the Nanards’ lovely curved links?” I asked. Marc and Jocelyn Nanard were demonstrating, too, and their demo introduced Bezier curve links. Before then, links had always been straight lines.
“That might be slower.” Dr. Dr. Streitz admitted. “You’ll have to find out.” Streitz and company were using workstations, while we were tied down to slower personal computers. When I came home, I decided that we needed the curved links and discovered that live updates were going to be painful to do with the old Macintosh operating system.
And so we’ve had curved links for fifteen years, and we won’t have live link updates during Tinderbox drags until Tinderbox Six ships. You see, I didn’t forget, and so fifteen years later we finally get the feature out to everyone.
It’s a small feature. You couldn’t write a paper about it – not today, anyway, because the reviewers would want evidence that the new way is better. It’s obvious that it is better, but proving it with the blunt weapon of clinical psychology is another matter.
Every system has lots of these details, and every system is the result of lots of design decisions. There’s lots to learn from sitting down with the people who do work like yours and finding out what went well and what didn’t. You won’t get that from the digital library, and you won’t get it from books. That’s what you do at conferences.
It won’t work if you aren’t there, or if the other people aren’t there, or if only students do posters and demos. It’s hard to size people up quickly. If a student tells you “we tried this and it was too hard,” you have to find a quick and polite way to learn whether it was hard because the student had never done that before, or whether it was hard because the task was basically impossible. If you’re talking to the principal investigator and she says it was hard, you can probably assume it’s hard.
It won’t work if the audience doesn’t listen. I’ve been glum lately because I wrote a few papers to which nobody seems to have paid much attention. But it’s not just me: I’m not sure anyone is really paying attention these days. Lots of computer science papers right now seem timid to me, as if their authors were chiefly worried about rejection and would rather be forgettable than rejected. Lots of eLit papers seem obscurantist, as if their authors were chiefly worried that to be understood is to be found out. And everybody seems in a terrible rush to get to the next conference or to get home.
Passivity is the curse of a bad economy. This isn’t just a moral failing, but a symptom of the gradual drift of the CHI branch of computer science toward psychology and sociology. If we’re passively studying observed phenomena, then your results may not carry much urgency for me. You’re studying Scarlet Tanagers and I’m studying Fritillaries and, while your results may be very interesting, nothing you learn about birds is really going to change my plans for next week’s butterfly experiments. Back in the day when we were all building systems, your curved links and your animated drags became next week’s development agenda.
Dave Winer has a new little company and a new little product. It’s called Little Outliner, and it’s a big deal.
Lots of books about the practice of programming are written for raw beginners, for people who don’t know what they’re doing, who need their hand held gently, and often for people who don’t want to be studying this topic. They spend a lot of time coaxing and cajoling and telling little jokes to keep the kids from getting scared.
A second strand of recent books about programming, starting from Fowler’s Refactoring and Beck’s Test-Driven Development By Example, aren’t written for beginners but, like the children’s stories, they move in tiny steps and chiefly address topics that seem fairly simple. I read Refactoring from start to finish and, the whole time, I was convinced that the next chapter was going to get interesting. I finished it, shrugged, and a couple of weeks later I began to realize, “Hey! That was sort of interesting!” This predilection for great care in taking tiny steps is partly the result of the modernist preference for tiny-methods style, partly a matter of temperament, and (I suspect) partly the result of careers spent consulting for software managers who don’t really know what they’re doing but who hold the checkbook.
xUnit Test Patterns fits solidly in this tradition. It’s exhaustive and fairly exhausting, laying down the law for unit testing and showing in detail exactly how each step can be taken without fear of fouling everything up. Much of what’s covered here is probably already part of the working vocabulary of any programmer with enough experience to read the book, but because Meszaros gives names to stuff you already do, he makes it easier to talk about those things and to justify them.
I took away three things.
Everyone knows that unit tests really need to be fast. Meszaros puts a number on it: 100ms per test is not fast. Meszaros spends pages showing why 100ms is not fast. It’s overkill, presumably aimed at giving you lots of information to vanquish your pointy-haired boss, but it’s good to know.
Second, shared fixtures are a pain. I knew that. I’d developed a test style that returned fixtures to their proper state after I used them. Meszaros argues that it’s better just to make fresh fixtures if you can manage that, and this seems to me a big win.
Finally, there’s a fine paper on Humble Object by Mike Feathers that I’d missed. It’s a good reference to have.
So yes, it’s made a concrete difference in Tinderbox Six. I’m not sure this needed to be a book, and there’s another book about refactoring practice that’s trying to bust out of this one. But it’s certainly worth having and browsing this book, and you could do worse than to spend a few evenings working through it in detail.
I saw this on Nate Matias’s bookshelf when I was stowing conference supplies in his office at MIT. Nobody tells me about good books in my field, so I take note of what people seem to be reading. Finally, I found some time.
It’s a good book. Debugging is a skill; half the questions I see at StackOverflow could have been resolved fairly quickly if the writers had better debugging skills. Butcher walks through the basics with patience and tact, showing inexperienced programmers how to find bugs and pointing out some kinds of problems that are tricky to find.
This is a book for the inexperienced, and it stops when things are getting interesting. Yes, asynchronous and multithreaded code is hard to debug. We knew that! And yes, doctor, we know that if it hurts when we do that, it might be a good idea to avoid doing that. Sometimes we can’t avoid it. Sometimes, the bugs appear when we’re already hip deep in the Big Muddy. Sometimes, the Big Fool says, “Management decided to architect it this way. Fix the damn bug.”
There are two kinds of tricky bugs. The first is the masquerade party: something is going wrong, it’s clear what the problem is, but that can’t happen. I had one of these publishing this post. A newly-rewritten method, ConstantTextSize, was crashing because when it called CreateAttributedString because, whatever it was getting from CreateAttributedString wasn’t an AttributedString. That’s nice, but it turns out that CreateAttributedString only returns AttributedStrings. I spent a lot of time proving that it could only create an attributed string. And then proving that the object it was complaining about was, in fact, an attributed string. So, why the crash? Because the text encoding was fouled up and we were looking beyond the end of the string, and an attributed string made up of garbage is not an attributed string as far as the system is concerned, no sir! So, we marched out of that river and now, when you use a whole slew of mathematical symbols in a post, Tinderbox won’t holler at you the way it hollered at me.
Masquerade parties take time but they’re kind of fun. The other tricky bug is the Epic Storm, and it’s no fun at all. Debug It! book avoids bogging down in war stories, but in a way that also falsifies the experience of debugging. I really hated Ellen Ullman’s The Bug, but it did get one thing right: an epic bug is a terrible thing. Everyone is screaming and shouting and generally emoting all over the place. Survival depends on finding the thing. Somehow, whatever is wrong keeps going wrong. You think it’s fixed, you pop the corks, you ship. And then it happens again. And again.
Over the years, we’ve had some awful epic bugs. They had names. Storyspace Ate My Links was the worst, but the Tinderbox unit tests have plenty of methods named for the great customers who filed the reports. I think we’ve only had two category five epic bugs in the last few years, though; test-driven development has helped, and perhaps experience and whisky have helped keep things calmer than in the old days. (One is fixed, the other is still open but we think it lies deep in the Carbon libraries where no program went before, and where no program is ever going to go again.)
One of the great contributions of Martin Fowler’s Refactoring was that it gave a name to one of the best approaches to addressing an intractable bug. If you can’t find the problem, and localization strategies can’t quite pin it down, you can just refactor the hell out of the neighborhood. This may or may not fix the bug, but at least it improves the code. Before refactoring, bug hunts left tracks all over the program in the form of hooks and temporaries and diagnostic writes. Nowadays, bug hunts leave mown lawns and cleaner design.
Kent Beck (the Agile fellow) urges presenters to start their talks on the second slide.
Beck does this on Facebook, which seems bizarre to me. Who uses Facebook for broad-audience blogging? And why? I must be missing something big.
I’ve been seeing some mail lately from researchers who don’t see much point in going to a conference if they don’t have sufficient time on the stage.
I used to go to conferences to learn things I needed to know. This wasn’t student learning — things I could get from books — because those books hadn’t been written yet. I went to conferences because, at the conference, you’d hear what the best people were working on, and how it was going.
There’s a picture in the lobby of the Hotel Metropole in Brussels of the attendees at the first Solvay conference in 1911. Madame Curie is sitting next to Henri Poincaré; they’re both examining a paper and it’s more interesting than the group photo. Behind them, a shockingly young Al Einstein is paying more attention to the photographer. Nernst is there, and Rutherford, Lorentz, Planck, de Broglie, Brillouin, Langevin. I could go on.
Do you think Al would’ve stayed home if he didn’t get enough stage time?
Patrick Wensink had a best-selling novel on Amazon last summer. It got a nice boost when Jack Daniels sent the world’s nicest cease-and-desist letter and the letter went viral.
My book was the No. 6 bestselling title in America for a while, right behind all the different “50 Shades of Grey” and “Gone Girl.” It was selling more copies than “Hunger Games” and “Bossypants.”
In the end, he made $12,000. It’s not a story of fraud or theft or a lousy contract. He was selling more copies than Hunger Games, but he was selling all of 4000 copies.
Ouch.
From the University of Southampton, a Web Science poster session. Worth a look — not least for a variety of approaches to designing academic posters. Some great topics — including linking clay tablets.
I spent the morning at the Malden Democratic City Committee’s big annual shindig, the St. Patrick’s Day Breakfast. Malden For Markey had a great, if chilly, turnout, complete with Markey signage in green. And Lynch was nowhere to be seen.
Hint to organizers, though: it’s great to have a comedian, but it would be nice of the comedian weren’t a Republican. The poor fellow wasn’t getting any love for his jokes about taxes and “illegal aliens” and the letting the post office run health care; I don’t think he knows who the Democrats are.
Someone should tell him.
Being Dan, a new book by Richard A. Chase.
Chase’s Frankie just won a nice award from the Cambridge Art Association.
I’ve been reading a bunch of papers and magazine articles about controlling cyber-bullying. It’s a very real problem.
New media makes bullying worse. It’s fast. It’s graphic. It transcends geography and it can reach across time. The internet is big. Surely we should control this sort of cruelty?
This is the test of whether we believe in rights. If rights are just a social construct — if they’re merely a contract we arrange for our convenience — then there’s no problem.
But do high-school kids have any right to freedom of speech and freedom of conscience?
It’s absurd to hold that Billy has every right to say that he support Rick Santorum, or that Obama’s a Muslim Fascist, but that he doesn’t have a right to say that a classmate is a bad person.
It’s absurd to hold that Amy has a right to choose to worship Christ but has no right to say that Billy is a lying, cheating slut.
Kids will have opinions about kids. It’s what they know best. Kids will attempt to enforce peer sexual norms. It’s what adolescents do. Kids will push limits and push buttons.
I do think kids have certain inalienable rights. That’s inconvenient. I don’t think we can regulate their language, and I suspect that language isn’t the problem anyway. I don’t think we can detect bullying without understanding context, and sometimes it takes the wisdom of Solomon to get the context right.
Here’s what we can do.
Anonymous posting is a bad idea. Sure, it’s got a theoretical place in the Democratic Nature Of The Web. And we could give up everything that’s good about the Web in defense of anonymity, in which case we’re going to have AOL and HBO and no Web. Lack of anonymity won’t stop bullying, but it will let observers get the context and help them find the kids in the ditch.
Discount childhood achievements and errors. Since a bully will punish missteps, we have to find a way to blunt the bully’s impact. Mistakes are embarrassing, but we can defuse their consequences. As a society, we’re going to have to agree to simply ignore the achievements and blunders of kids. Did you publish a book of poetry at 17? The day after you’re grown up, we don’t care anymore. Did you get naked and dance on the table of The Four Seasons at your coming out party? Old news. We won’t want to hear about your football triumphs or your high school grades any more than we want to see your refrigerator drawings. (This means the end of high school sports beyond recreation and exercise, which would also be a very good thing.)
A right of passage makes a lot of sense here. The fundies have that spooky silver ring thing, but we really need some dramatic way to say, “All the things you did before, that was growing up. Yesterday you were a kid. Tomorrow, you are no longer a kid: life is not a rehearsal, and it’s time to put childish things on the shelf. Tomorrow, it counts.”
I see no technical solution to bullying that, if applied to Chinese dissenters or American war resisters, doesn’t lead to political consequences incompatible with the rights of man. Ending anonymity will help, and forgiving childish mistakes
Nate Thayer, a reporter, took grave offense when The Atlantic asked him to adapt a basketball story for one of The Atlantic’s weblogs but didn’t want to pay him. He lost his temper colorfully, and also published the editor’s email address, which wasn’t terribly nice.
Alex Madrigal replies at length in A Day in the Life of a Digital Editor, 2013. It’s a shaggy post and gets off to a slow start, but it’s also one of the all-time best pieces of new media on the Web.
I'll be damned if The Atlantic dies with my generation, if all that is left of it when I leave is some moldering books and cold servers. Quite possibly, I would get to the gates of heaven and Ida Tarbell would be sitting there like, “Wait, wait, you’re one of those guys who let The Atlantic die?” And poof: trapdoor in the clouds, burning in hell for all eternity. Actually, strike that, I'd probably get stuck in purgatory rewriting press releases about corporate sustainability, forced to eat tuna sandwiches every day for lunch.
We threw a brunch last Sunday to get past the winter doldrums. I used it as an opportunity to try to put together a good fresh-backed bread basket.
The ambitious morning also featured a quiche implosion, wherein my lovely-looking quiche crust slumped irretrievably while it was being blind-baked in my springform pan. I hated to waste the ingredients for the quiche filling, and there was no time for a new crust, so this turned into a tasty bread pudding with caramelized onions, sautéed mushrooms, and lots of gruyere.
For those who wanted something besides carbs, I made:
The pastrami is a hit: once again, we went through more than 4lb of brisket in a couple of hours.
I’ve been absolutely flattened by planning for the Web Science conference this week. We have a ton of papers – more than 130 – which means nearly 400 reviews from about 80 prominent scholars, journalists, and writers.
I ought to have foreseen one difficulty that I did not: in a wildly interdisciplinary conference, reviewers will disagree wildly. Every conference seems to have some paper with reviews like this:
but for Web Science this year, we’ve got these coming out of our ears.
People sometimes want to take an average, or to vote, but that’s a poor solution. Back in the old days, we’d get those two experts at the program committee table, hear them argue, and decide who was convincing. Now, travel is too expensive and we try to make do with EasyChair.
I’m organizing the program in Tinderbox Six. This has its advantages, both for debugging and testing and for checking that performance is adequate. And today was a new first: Tinderbox Six has stayed up through an entire day of challenging work.
This is not to say there are no problems. For example, I’ve got a macro ^do(tbx) that lets me write “Tinderbox” quickly with a proper link. Tinderbox Six autocorrects “tbx” to “tax.” Thanks a lot!
We’ve just sent out notifications for Web Science 2013 papers. (There’s still a few days before the March 16 deadline for extended abstracts of late-breaking research and for social sciences and digital humanities.)
I don’t think it’s generally understood how much work goes into this program.
First, you’ve got about 140 different research papers — each describing new work, each based on extensive scholarship, each reporting new experiments, original engineering, and new analysis.
Then each paper is read independently by a bunch of experts. We aim for three reviews of each paper, but some papers require as many as six opinions. The reviews are frequently long and detailed and often quite technical.
These reviews then need to be weighed and discussed. Some experts place more weight on scholarship. Some prize rigor, others are inclined to accept methodological blemishes that may be required to investigate interesting phenomena. Some may see a methodological or theoretical disaster where another reader, equally expert, sees no problem at all. The debate can sometimes be vigorous: my inbox today included email from one reviewer who thanked us for accepting paper X because now that reviewer will have an example for students of how not to design research.
Then, for Web Science we need to match papers to presentation modes. Lots of conferences just give more time to better work. We try instead to find the perfect fit. A top-ranked paper might be a poster if we think it will make a spectacular poster. A bunch of our best presenters this year will find themselves in the pecha kucha session; it’s a new format for Web Science and experienced presenters may help get it properly launched.
I admit that during the review process I sometimes despaired. Academic writing is not often everything that one could wish.
One great concern for me today is how difficult it’s becoming to get a paper accepted. I felt that some papers this year were timid, aiming to placate readers and aspiring to dim acceptability rather than brilliance. The economics of research are moderately grim, so the times make people even more cautious in their work and more anxious not to offend.
