Slides: What Everyone Should Know About REST

Thanks UX Mastery for the sketchnotes, they are awesome! (Seriously, I would be much more swayed to speak at any conference with sketchnotes because it’s a straightforward permanent memento, a better snapshot than slides or video.)

Overall, it was great to be associated with another fine Web Directions conference and the Melbourne Town Hall venue was amazing. I only regret that we were so busy scrambling on the Android app, after launching just a few days earlier, to be around the whole time. But this being my hometown — I’ll be back!

Talk Structure

I spoke at Web Directions Code on Friday, a talk on REST. I’ve been putting a lot of this into practice lately, and the talk was really an attempt to convey the main practical things every developer should know. The structure was:

• Everyone should know about REST because it’s not just about websites anymore. Devices, whether computers, fridges, or wearable glasses – are connected, and device-to-device communication happens with web standards, i.e. HTTP. The talk covered three things about REST: Simplicity+Consistency; Security; Caching.
• Simplicity+Consistency: Emphasising Developer Experience (#devexp) was a way to frame the general concepts, ie URLs, HTTP methods, response types.
• Security: How the web is becoming SSL-only, and various authentication schemes. I referenced the latest Traffic and Weather, which has a good discussion on this.
• Performance+Scalability: Mostly about caching. I’ve been musing on REST caching quite a bit for Player FM’s API (most recently thinking about a kind of reverse patch protocol, where the server can send out diffs that get cached), and explained some of the standards and tricks for squeezing efficiency out of the network.

What Wasn’t Covered

• I didn’t go into the REST acronym or the general theory of REST as an architectural pattern arising from specific forces.
• SSL and caching. Good Twitter conversation afterwards about this point, that you can’t cache in the middle of an SSL connection. The answer is to split the connection in the middle and run SSL on either side, with a trusted cache seeing plain-text in the middle. This is how Cloudflare works, and the CEO Matthew Prince chimed in to say it will be free soon. (At least, SSL from client to Cloudflare.) So that means the SSL-protected web could triple overnight.

The post What Everyone Should Know About REST: Talk at Web Directions Code appeared first on Software As She's Developed.

Extract below with obligatory PSD artwork. Emphasis mine.

[Background: Speaking about REST at Web Directions Code soon and finding myself on a long day of interstate flights, I bit the bullet and finally read Roy Fieldings' original REST thesis cover-to-cover. And if anyone has a good way to export highlights from a personal document in Kindle, please let me know as it's apparently unsupported.]

6.5.4.3 Java versus JavaScript

REST can also be used to gain insight into why some media types have had greater adoption within the Web architecture than others, even when the balance of developer opinion is not in their favor. The case of Java applets versus JavaScript is one example.

…

The question is: why is JavaScript more successful on the Web than Java? It certainly isn’t because of its technical quality as a language, since both its syntax and execution environment are considered poor when compared to Java. It also isn’t because of marketing: Sun far outspent Netscape in that regard, and continues to do so. It isn’t because of any intrinsic characteristics of the languages either, since Java has been more successful than JavaScript within all other programming areas (stand-alone applications, servlets, etc.). In order to better understand the reasons for this discrepancy, we need to evaluate Java in terms of its characteristics as a representation media type within REST.

JavaScript better fits the deployment model of Web technology. It has a much lower entry-barrier, both in terms of its overall complexity as a language and the amount of initial effort required by a novice programmer to put together their first piece of working code. JavaScript also has less impact on the visibility of interactions. Independent organizations can read, verify, and copy the JavaScript source code in the same way that they could copy HTML. Java, in contrast, is downloaded as binary packaged archives — the user is therefore left to trust the security restrictions within the Java execution environment. Likewise, Java has many more features that are considered questionable to allow within a secure environment, including the ability to send RMI requests back to the origin server. RMI does not support visibility for intermediaries.

Perhaps the most important distinction between the two, however, is that JavaScript causes less user-perceived latency. JavaScript is usually downloaded as part of the primary representation, whereas Java applets require a separate request. Java code, once converted to the byte code format, is much larger than typical JavaScript. Finally, whereas JavaScript can be executed while the rest of the HTML page is downloading, Java requires that the complete package of class files be downloaded and installed before the application can begin. Java, therefore, does not support incremental rendering.

The post JavaScript swims downstream with the web appeared first on Software As She's Developed.

And the harsh but fair warning, upon inspection: “However, this page includes other resources which are not secure. These resources can be viewed by others while in transit, and can be modified by an attacker to change the look of the page.”

So to fix this locally, a nice setup for Ruby/Rails devs is Pow + Tunnels. Both are super-simple to setup.

Pow is a local server, so if you usually run Rails on http://localhost:3000, you can one-click install Pow and all you need is to symlink your Rails folder to ~/.pow. Then you have a local server, sans port, like http://player.dev. Then, just install Tunnels and it will simply pipe https://player.dev into http://player.dev.

Now you can open Chrome devtools’ resource tab and fish out any connections which are still https. Ideally host them locally, or at least change the links to https ones at possible loss of cache performance. Still, did you see various posts recently about ISPs injecting crapware script tags into people’s pages? OMG I know right! Seriously, https-everywhere is where the web is heading. Even public sites aren’t immune.

The post Testing HTTPS Locally appeared first on Software As She's Developed.

It’s archival because these days, my glorified pastebins you shouldn’t subscribe to are:

• My Gist Stream.
• My Notes Community. You see, I’ve stumbled onto a nice Posterous replacement, which is a Google Plus community. Google Plus pages can work that way too, but they are more cumbersome to deal with, requiring a new window each time. G+ is not a Posterous replacement in the sense that you can’t mail things to it, or tweet them etc, but it’s quick to share stuff and works nicely from mobile. Plus one thing Posterous never sorted out was commenting – it required a Posterous login. Whereas anyone on Plus can leave a comment. So it’s turned into a nice way to create a public thread, but one that won’t spam followers when published.

The post Post hoc ergo propter hoc: Posterous Moved appeared first on Software As She's Developed.

1. http://infrequently.org/2013/04/probably-wrong/

The post Blinking WebKit appeared first on Software As She's Developed.

Backstory is I started writing it on Thursday night after seeing all the Reader tweetstorm and figured it’s probably of more general interest, so I submitted it there. The original draft was ~1400 words and I wasn’t sure how seriously they take their guideline fo ~800, so just left it at 1400, but turns out they are, in fact, serious. So we edited it down.

For the record (since some people asked), I used Bloglines for as long as I could cope with its downtime, as I always found Google Reader too magic (unpredictable) with its use of Ajax. Eventually Bloglines was outaging for hours and IIRC whole days, so I made the switch to Reader, but could never get into the web app – too much Ajax magic – and instead used Reeder, sync’d to Reader when it came along. When I switched to Android for my primary device, I couldn’t find a satisfactory app, so just used Reeder on the iPad occasionally.

Meanwhile, with podcasts, I preferred the cloud approach of Odeo and Podnova, but both sadly died. I tried podcasts with Reader, but it just wasn’t the right experience so I mostly used iTunes, and then on Android, mixed it up between several apps (DoggCatcher, BeyondPod, PocketCasts, etc…the usual suspects) until eventually creating my own (still in beta). I really had problems with Listen though, so again, no didn’t do the Reader sync.

So bottom line is I did use Reader “somewhat”, but mostly as an API; and it’s no great loss to me like I appreciate it is to others. The responses to this article certainly demonstrate how passionate people are about a product they get to know and love, and use on a daily basis. It’s never easy giving up on muscle memory. The bright side of the equation is exactly what people like about it: RSS and OPML are open, so at least people can move on to Feedly, Newsblur, and so on. And I truly believe this decision ultimately liberates the standard and allows it to thrive among smaller players.

The post Why Google killed off Google Reader: It was self-defense (GigaOM guest post) appeared first on Software As She's Developed.

WebWait User asks:

I have been using webwait for a while and have a quick question for you. When running multiple calls on the same website, is each call downloading the entire page again, or is the information being loaded from the browser cache?

My answer:

It will do whatever the browser would do if the page was loaded normally, so that would usually mean the 2nd-Nth time it will download from the cache. To counter-act that, you can simply disable your browser cache while performing your tests. Or if you do want to test cache performance, just open your site once (either in the browser or WebWait) and then start the WebWait tests, obviously keeping the cache enabled throughout.

The post About WebWait and Caching appeared first on Software As She's Developed.

[ruby] def area(r=radius) { Math::pi * r * r } [/ruby]

Simple example, but you get the point. It lets you tell the external world what a parameter is all about, but keeps the implementation shorthand. Obviously it’s just a simple example here; parameter names can be much more verbose than just this example and functions can be longer, so you don’t want to keep repeating a long name. For example:

[ruby] def damage_level(force_exterted_by_car=force) { force = 0 if force < 0 acceleration = mass/force … } [/ruby]

Now you might say “just declare it in the first line”, but I prefer small code and there could be several such lines.

You might say “mention it in a comment”, but I prefer self-documenting code. Comments go out of date and clutter up code. (Strictly speaking, the long name here is a comment, but it’s more likely to be maintained.)

[Update: I don't often mention Pi, but when I do, it's on March 14: Pi Day. Thanks to the reader who pointed it out!]

The post Shorthand Parameters appeared first on Software As She's Developed.

• Google App Permissions
• Twitter App Permissions
• LinkedIn App Permissions
• Dropbox App Permissions

Mainly writing this because I keep searching for these things and don’t have much luck (as I forgot about MyPermissions). Being personalised URLs, they don’t show up in searches (which is a wasted opporunity, since they are all static and could have just been public placeholders). Hopefully this post will show up in the future when I search for “revoke OAuth Tokens”. You can find links to more of these services on MyPermissions.

The post Revoking OAuth Tokens From Google, Twitter, etc appeared first on Software As She's Developed.

Most scripts simply run `date` to show the boring long date format: Fri Mar 29 21:07:39 MST 2002. Info overload! You don’t want to know what month it is, whether you’re in the middle of a weekend, or what timezone you’re in! More to the point, you want to know how much time has elapsed, not what time it is now; you want to know the script’s age.

So here’s a little utility to make it easy. Just call “age” and it will output time since the script began in 00:00:00 format.

I also made another function “announce” which you can use to announce the current function is running. With larger bash scripts, I tend to break them into functions with a list of calls at the bottom; so I can quickly bypass unnecessary crunching by commenting out the call. “announce” makes it easy to see which is running. And if you wanted, you could easily automate announcing for each function…making aspect-oriented Bash the place to be.

The post A Bash Logging Utility appeared first on Software As She's Developed.