Swank Bookie Jibes

TCWTF

Chime.Tv’s video player has got the kind of flash and style Ruby developers would envy, especially since it’s programmed in PHP and AJAX.

It uses some Windows2000 specific stuff and has been succesfully tested under Beta versions of this operating system.

One of these quotations is from a spam, one is a techcrunch lede.  Care to guess which is which?

Hopefully some of that money they are raising will go to delivering editorial with semantic meaning.  They tell me "Semantic Writing" is the hot new shit in blogging these days.

Running in the Special Olympics

If you are going to get in an argument with someone on the internet, choose a good avatar that makes you look like a cool easy going guy:

No matter what, do NOT choose one that makes you look like the bad guy from James Bond:

Seriously, I don't know/care about 8020 Publishing or whatever but don't you think this argument was kind of lost when when one guy showed up to the battle with an eyepatch and a tuxedo?  He looks like he's about to plan an elaborate death sequence for Powazek that he'll only narrowly escape by using using a 'web communities' version of Hulk Hogan's 'Hulkamania' move.

Finally

I can access my horoscope via a RESTful API.  Now I can get on with building my astrology<->palmistry mashups.

Whoah! Screw palmistry, rumpology is where its at. Thanks wikipedia.

Question

Can you sit on IRC with a nick like NickSrv or NickServer and catch people accidently msging the wrong thing to claim their nick, and then have their nick/pw and take over their identity?  Do ops go with this?  I don't actually know how IRC works, I just typed that by mistake and it made me wonder.

BDD?

This is the basis of Behaviour Driven Development, the methodology that I will use in this tutorial to iteratively develop a Rails model, test-first spec-first.[emphasis mine] ...and the circle is complete. via.

Again With The Search Engines

DAMN YOU SEMANTIC MARKUP

Why does HTML not have a footnote tag? Footnotes are the OG hypertext, that people have been linking with since monastic times. W3C: First, do no harm. HTML has two separate tags for "strikethrough text" and none for footnote? As far as I can tell, those tags are only useful for inflicting porting the ^H^H^H^H eyeball abuse joke onto the web. Shouldn't footnotes really be a real tag so UAs can handle them differently? Screen readers, etc. Maybe I should just try to write less discursively. This whole post was almost a footnote. I'm actually curious. I'm sure there was some lengthy fight about this at some point on some W3C list, but I don't read those and nothing is turning up in my searching.

How embarrassing is it going to be when someone's like "how did you miss the <notefoot> tag? Tim B-L slaved over that tag personally, and harder than any of the other tags you insensitive clod! Of course he loved footnotes why do you think he invented the www?" And yes, I know <strike< and <s> are deprecated. But answer me this: why are <big> and <small> not deprecated semantic fanboys? And how perfect would this whole spiel have been in a footnote?

Email Is The New...I Don't know...Twitter?

For a long time, I've been wishing I had a blog posting tool that would let you use email to post to your blog. Let's say the service is called blogmastergeneral. I'm at work, I see an image or screen I want to post, I use SnagIt to grab it to my clipboard, I paste it into an email with some Markdown-like syntax for the post, send it, and its done. In practice, I have no idea how this would work (how does the blogmastergeneral know my email came from me?), but I've always thought it would be cool.

I never thought, though, that someone would think about building it, because here in the blogosphere, rich clients are uncool, right (ummm..with a few blogger-approved exceptions? So why would we want to build stuff to interact with them (blogmastergeneral isn't really that compelling with webmail, IMHO, mainly cause of the lack of image pasting)?

It seems that rich client or no, email is making a big comeback since the dark days of October 2006.

I've seen a lot of new stuff lately thats based on the idea of email-as-version-manager, email-as-collaboration-tool, etc. One of the most memorable email-related demos I've seen lately was Rael Dornfest's Sandy demo at UTR. part if which is recapitulated on the Values of N blog:

And it dawned on us that the core product had been there all along.

We noticed that active Stikkiteers — ourselves included — tended to interact with Stikkit from the comfort of an already-familiar interface: email. We already know how to use email to collaborate and share; and with the addition of Stikkit's "thinking," our email had become more useful.

As much as email sucks, we've got a real lot of tooling built around it that's pretty thoroughly debugged and pretty powerful. Arguably more important, we've got social norms around it. It seems like there's a general pattern that you can tell if a social tool like email is successful if people abuse it. If it's unsuccessful, there's no payoff, cause there's no audience (so stay tuned for some serious Twitter spam). People know how to use it and even the normal people are willing to use it, so it doesn't run as much of a risk of sitting there with one "Welcome (content goes here)" page set up like the wiki you set up for your bar league softball team to schedule stuff. So a lot of this is a "pave the cowpaths" mentality. I'm a big buyer of cowpath-paving. I can't let this paragraph go by without pointing out again that this another reason why RESTful web services built on top of HTTP are the Right Thing.

APP Interop

This rules. This is the bane of my existence. At Proto, we are always trying to build (or help people build) cool apps that consume WSDLs and generate handy Proto interfaces to web services. When it works, it's awesome. It's very easy to use. In Proto, you paste in your WSDL URI and Proto uses .NET's WS stack to generate some proxy classes you never have to see, which it handily exposes Proto-style (input and output menus) and it more-or-less magically deals with type conversions, data structures, etc. When we first added this feature to test builds of Proto, we tried it with the Google Search WSDL, which used XML-RPC IIRC (RIP). It was one of those times where you're like, "let's see if this works". We pasted in a URI, clicked a button, and all of the sudden, we had a Proto module with inputs like "Set Search Query" and outputs like "Get Results" that we could connect anything to: Proto input modules like textboxes, Excel cells, all sorts of stuff. It took a few seconds to set up. Very cool.

However, the WS-* stack is so complicated that (1) .NET is not even close to perfectly interoperable with all endpoints. Not even close. For example, the last time I checked the .NET 1.1 libs could not parse the Amazon S3 WSDL. It's not like the joker implementations aren't interoperable, it's the people who ostensibly know what they are doing. (2) We don't implement/expose every option. In fact, we don't even understand every option. The specs seem to be internally contradictory, overlapping, or vague, so we chose what we considered to be a reasonable subset to implement by inspecting a wide array of services, and went with it. This means every so often we hit a service we can't use because it relies on a feature we didn't implement. For the record, as far as I can tell, everyone does this. I'm not sure if a complete implementation of those specs is even logically possible. The last time I checked, .NET didn't implement certain features of WSDL or SOAP, but I can't remember exactly what. In fact, the practice is so prevalent, there is an industry group dedicated to picking which parts are safe to use. Even with this magical tooling stack (I have to assume the .NET implementation is one that every vendor would test against), we still end up in situations where it's faster and easier to write a little VBA code in a module to hit a reasonably RESTy 'web service' (in the traditional sense of 'all web endpoints represent web services').

I have two distinct suspicions about this type of engineering. The first is that I'm struck by how much this feels like C++ in the 90s (can't keep the design in your head, no complete implementations, industry WGs working on an 'ok to use' subset, etc.) . I'm not saying C++ isn't powerful and useful and used successfully in all sorts of mission critical applications (and Bjarne Stroustrup lived down the block from my friend when we were in middle school. You gotta support the home team) , but haven't we learned some important lessons about that sort of thing? Things that can save us some agita nowadays? Again, I fully admit my second is a not a provable hypothesis, but it is a strong suspicion: I suspect the document-oriented design of REST-style web services makes a lot more sense as a distributed computing architecture for the bulk of distributed computing applications, not all, but the bulk, as opposed to "hey lets have distributed objects with methods we can call just like normal, and pretend the network doesn't exist! The tools will take care of it! W00t!1!"

April 1

"April Fools' Day" should be called "The Internet is Sucky and Useless Day".