A new product: The easiest way to tweet a storm!
How the NYT covered D-Day on this day in 1944.
I'm really happy with the response to Little Pork Chop so far. The number one FAQ is, as I expected it would be, "I like 140, why are you screwing with that?" Well we know that Twitter was made with this limit, and it may be the best of all possible ways to do it, but it's not the only possible way. How else will we learn what's possible unless we try? There's too much "should" in software thinking these days, imho. I like it when we try new ideas out, and see what happens. This is a tool. We have no idea how people will use it. Maybe there's a great art to this and we just don't know about it. Or maybe we'll discover a very good reason why tweets should be different than they are today. Maybe the new thing won't happen on Twitter. Who knows what will happen. But we'll learn, I hope!
What do you think would happen if a bunch of people posted to Twitter in "tweetstorms" as @pmarca does? Do you think Twitter would fall apart as a social medium? Or perhaps Twitter would change the way the system works, and permit users to post messages that are longer than 140 characters? Is this a case where users design a new feature, as used to happen in the early days? Many of the features we've come to love and depend on were designed by users and developers. I do recognize the irony that I am asking the question in a tweetstream, rather than a blog post!
If it had been properly designed, one programmer would deal with the mess of concurrent threading, and everyone else (including the original programmer) would get to ride on a cushy higher layer. It's bad design that you have to worry about concurrency all the time in Node.js apps. But it is what it is. Once you learn to deal with it, it's actually kind of fun.
I learned something important doing River4, that what people say about Node.js being single-threaded, isn't true. Because of all the hype about it's single-thread architecture, I expected to hit a brick wall doing River4, when it came time to do N feed reads, I was sure I'd only be able to do 1. Not so! You can do as many as you like. You can even change the maximum number of open sockets. It's a great environment for doing something like River4.
Now, it took ten times as long to write River4 as it did River3, that's because Frontier is a much more supportive environment for these kinds of apps. It handles all the messy threading issues in the kernel, exactly as you want to. You want to fork a thread, just do it. We copied the programming interface from C, circa 1974. This is not new stuff.
But Node.js was done as a bootstrap by a few brave programmers, and it works. The magic of Node isn't the environment, or the language, it's the consensus. It's not NPM, it's all the shit you can get in NPM. It's a structure for solved problems that you need when writing server software.
It's also a culture that appears to place high value on stability. I can't say for sure, I'll let you know in a couple of years, Murphy-willing, when I'll know how many times the various apps I've been developing have broken due to gratuitous changes in the platform. The kinds of things Apple does on a regular basis to see if you're paying attention. It's why Mac software breaks, and Unix software tends not to break. (I may be naive about this.)
So Eric Jiang is right, it is an emperor without clothes, but it is an emperor, and that's something. All software is shitty, it's all the worst possible solution to the problem it solves, but that's the point, it's a solution. It works. So you shut up and eat your vegetables, and get on with it. And hope it's good for 10 or 20 years.
A reader pointed out on Twitter that the short codes for Emojis are included, unreduced, in my RSS feed. So when you're looking at an item from my blog in a feed reader, you see the code, not the image.
But why not go a step further, and integrate this language into feed readers as well? That's why I left the codes unreduced in the feed. I think the icons should travel over the wire in an encoded fashion, as semantic entities instead of visual entities. It's up to the software that's displaying it to decide what it should look like. This seems to be the philosophy of the web. Wait until the last minute possible to turn semantic into visual.
It also might help bootstrap a conversation in the RSS community. Does an idea have to have an installed base before we'll try it out? That's why I did River4. It's my statement that if you want to move forward, someone has to go first. That means inevitably supporting features that don't have an installed base. (Seems kind of obvious?) River4 is where I'll implement ideas I want to try out in Fargo, but need support on the consuming side to make them work.
So here's the Emoji Cheat Sheet, offering the perfect way to raise the question. It has an installed base, just not in RSS-generating software. I went first with Fargo's feeds. Not much of an installed base. Eventually I'll put the feature in my river displayer. That's how bootstraps work.
If you want to be a leader, imho, you have to take leadership from others. That's the way it works, in my experience. It's the person who goes second that has all the power. I didn't invent the Emoji Cheat Sheet, but am showing a small amount of leadership by accepting it as-is, without change, in furtherance of a standard.