Pythonista has been popping up recently in my stream, cough Federico Viticci on App.net cough. So much so, I had to take a look. I also had a petty annoyance that I figured Pythonista could help me fix. There are probably better introductions, but this how I got up to speed.

My goal was the take feedburner links, you know the kind you would find in an RSS reader, and unwrap them into their real URLs. Feedburner also adds some query string cruft, so that had to go as well. In the end you would have a URL worthy of posting on your social network of choice. All of this could happen with out going over to your big boy computer.

After downloading Pythonista I stalled. Getting random bits of text to your phone is still a little tricky. This is the hardest part of Pythonista, at least in the first 5 minutes, getting code onto the phone in a sane way. Luckily, someone has gone down this path before me and I can just follow in their steps.

After installing, the first step is to use this gist. Copy, and paste this into a script called gistcheck. Then run the code. It will set up more scripts for you to use. ¹

Now you’ll have a couple of new scripts from which you can create actions. Goto settings find the “Actions Menu”, scroll to the bottom and you will see your new scripts. Add them.

The next thing you need to do is setup the bookmarklet mentioned in the gistcheck ². This will allow you to open a gist in mobile safari and save it to your scripts in pythonista.

From here you can create a gist with the code for any script you want. Then you can use the bookmarklet to get it into pythonista. From that point forward you can use Gist Pull action to update your script. On your dev box you can clone the gist, and push updates to github.

To solve my specific problem I developed this gist.

Webscript.io is like a programmable Yahoo Pipes. It allows you to run simple Lua scripts in a sandbox. They can make HTTP requests, store data in a simple key/value store, and they can load in lua modules from github. By giving you access to a real language and not a simulacrum of programing they open up a bunch of possibilities.

It’s still early though. I keep running into pain points, but the guys running it have been very responsive to support request, and have already addressed some of my earlier problems. I signed up to be a paying member because I think this affords a lot of hackability, its kinda like drinkability.

One pain point I keep running into is that to import modules from Github you need to add a webhook to your Github project. Which makes sense from the perspective of Webscript.io. It allows them to only update there local copy only when its updated on Github. At least I imagine that is how it works on there side. On the user side you must fork any module that looks cool, then add the webhook. After a few times of something like this:

1. Fork the project
2. Add the webhook
3. Click test webhook

I created a repo and now add modules as I find them to that one repo. You can use it too: webscript-lua-modules

Anyway, other then trying to import a Markdown module(haven’t got that to work yet) the first thing I have tried was to hookup App.net, and Webscript.io. Here is a simple authorization flow.

https://gist.github.com/voidfiles/4014269#file-adn_webscript-lua

The next step would be to setup sessions of some kind. Another interesting bit of information is that Webscript.io is supporting CORS so you could build a very interesting client side only app using Webscript.io.

I wrote a bit about this over at daily.js.

At PicPlz we built a hybrid mobile app. We had a native container written for iOS and Android that hosted a web version of our code. PicPlz was the first time I had worked on a fully mobile website. My operating paradigm was that I was building a website for a small screen.

One day, our iOS developer asked me why our follow button didn’t just react when a user touched it. He pointed out that most iOS apps work that way. It was a glaring reminder that our app was something other than native. I genuinely had never thought about doing it any other way. I was building a web app, and when building web apps there is network IO. For things to be consistent, you need to wait until the network IO has finished. The other engineer persisted though, claiming that it doesn’t have to work that way.

“Optimistic Server Interactions” via DailyJS

I really want to see how far we can take these.

My grandfather once got mad at me for using the word awesome needlessly. I don’t even remember what I was talking about, which further iterates his point, but he was right to get mad. I didn’t really understand what awesome meant. Today though, I think I do know. The last 30 days working on App.net have been awesome. We haven’t reached our goal over at join.app.net, but I wanted to take a moment to reflect before we get to the end of this larval stage.

I have felt every feeling under the sun; I have felt fear, hurt, excitement, delusion (is that a feeling?), and I felt them all with gusto. I have caught my wife, on more then on occasion, trying slyly to make sure I was okay. Once I embraced something a co-worker said, “Don’t think too much about the wall or you’ll hit it,” things got a lot easier and I relaxed. I started to use all of those feelings to help me get my work done. I am not the only one who’s been exasperated by this journey, the tone of the office has been jovial but tense; which is exactly how a good team should respond to pressure.

I have kept a diary as well, really just because I want to make sure I take note of what this feels like. I knew from day one that I would want to remember how this went down. I had keep some record. Now I know I wasn’t wrong to do that. I might be sitting in my own little echo chamber and people have publicly announced there audacious proposals before, but nothing I have ever worked on has had so much coverage. At least in my neck of the woods.

Tuesday I am going to wake up and go to work, but it will be awesome, err, it will be awesomer. One way or another my life will be better on that day, because I lived through this. We might not make it, but my life is irrevocably changed. My coffee is going to taste better. My glazed donut will probably be the sweetest it has ever been. And, then I am going to put in some hours. I hope it’s on App.net, but whatever it is I am going to do it really fucking well.

I finished my weekend hack project, and join.app.net just passed 450k. This has been a great weekend, so far. I hope that it can only get better.

If you want to take a look at what I built http://alexkessinger.net/projects/appdotnet-notifier/html/notifier.html

source code is here https://github.com/voidfiles/appdotnet-notifier

So, I just finished setting up the Authentication flow for a client side app. You can see the code up on github.

The next step here is that I need to contact that API on behalf of the user. I want to just use JavaScript to contact the API, but the API clearly lives on another host then my project. In the past at this point I would need to write some kind of server component to proxy my requests to the API, but the future is here. I am going to use CORS.

CORS stands for cross origin resource sharing. Basically you can $.post across domains boom did I just blow your mind.

But what about the Same Origin Policy?

That is a good point, if sites could just $.post willy nilly it would be a problem, but the magic of CORS is that it allows for your browser to negotiate the nature of the connection to the remote origin.

So, the first step is that it when you try and use CORS to go cross domain your browser sends an OPTIONS request. The receiving server, if its set up correctly, can then respond with a magic header. That header tells to browser whether the requesting origin can have access to the remote origin, or not.

There are a couple other things that happen at this points as well. The remote origin can let the browser know what headers it will allow and what HTTP methods are acceptable.

So, at the end of the negotiation if the remote origin allows if the browser will then allow your site to make cross origin requests.

CORS, and App.net

At App.net we also support the client side OAuth 2 flow. This means that you can setup a whole application that lives only on the client, and using CORS you can also make authenticated requests to our API on behalf of a user.

I am using CORS, and the client side auth flow on App.net you can see how I set it all up here.

It’s not supported everywhere though

CORS is pretty awesome. And if you put your future-forward hat on it makes a lot of sense to start investing in the idea of CORS. Even right now there is really good browser support for CORS and it will only get better in the years to come. So, if you are starting now and you don’t have to support legacy browsers, check it out.

Yes, I work at App.net, but I am also a hacker. I wanted to bring these two things together this weekend to build my first ever App.net API project.

In the spirit of the project its self. I am going to release early and often. I want make this thing as public as possible and I am going to try get it done by Sunday night.

Now I am going to the zoo, and park over the weekend to play with my kids, but all my spare time I think will be spent working on this first project.

What am I going to build

The simplest possible useful thing. Something that is missing right now, but is coming soon - seriously soon - is the realtime portion of App.net. Part of that will include a realtime mentions feed. Right now I have a growl style system that notifies me when I get an email. Thanks to the Chrome Notifications API I am prompted every time I get an important email. I want to replicated this for App.net, and mentions.

Basically whenever anyone mentions me on App.net I want to know about it.

How am I going to do it

To me one of the most exciting parts of the API is that we support CORS. We do this right now. Among the many benefits of CORS, this means that I can write an entirely client side app and it can be a first class client of the API. So, CORS FTW. I am not sure exactly where I am going to host this yet, first I need to create the github repo.

UPDATE: its here https://github.com/voidfiles/appdotnet-notifier

I have been standards spelunking recently. ATOM, OStatus, JSON XMPP (hint: that one is a joke), and Activity Steams. All this exploration led me to a conclusion - standards are not the panacea I once thought. There is a lot to like about standards; hard work, thourough thought, and sometimes a success, but we can’t blindly follow the standards off a cliff.

I have been presented with an amazing opportunity to spend some time looking through all this prior art. Within minutes of learning what I would be working on for the next month my mind leapt to standards. I thought to my self we can do this the responsible way. Activity Streams was the clear frontrunner, being implemented and shipped in Google+. I have even been following its development out of an academic interest in such things. Mostly lurking on the public email list. I am sad to say though, here is where it all starts to fall apart.

I can remember when activity streams was an XML only initiative. If you look at what kind of Activity Steams Google+ shipped it’s the JSON implementation. So, why isn’t ActivtyStreams only XML? From the outside looking in it seems as if the problem they had was that the process took so long that the public eye shifted from XML to JSON. They needed to created a JSON version of the schema. It’s laudable that they responded to market conditions, but JSON is not XML. To true XML nerds JSON is an abomination.

If you look back you can see that ActivityStreams has its start in the ATOM community. ATOM it’s self originated out of the webs 2.0 holy war between RSS and civility. As far as I can tell the whole idea behind ATOM seems to be an attempt to civilize RSS. All they achieved was another mess, but that’s not where we stop. One of ATOM’s progeny is OStatus. Which you can think of as the container for ActivityStreams. ATOM its self is a container for OStatus…

Look, I can keep going here, but my point is that we already have one major problem with the current JSON version of ActivityStreams - it’s steeped in XML history - and its a deal breaker. They literally fork lifted some XML ideas out of ATOM, and then ported them to JSON. What I don’t understand is why no one thought to challenge the premise of building a realtime feed on top of ATOM, especially after the writing was on the wall. I don’t even dislike ATOM either. I am a feed reading wonk to the nTH degree, but it just clearly isn’t what realtime social feeds are. Twitter isn’t, Facebook isn’t. You can’t just build the thing you wish existed, and not base it any reality.

If the WHATWG got anything right about standards, it got that you can’t just keep piling bad ideas on top of one another. You can’t create standards in an Ivory Tower. You need to look at what the ecosystem is already doing. In this case they had two models they could have looked at - Twitter and Facebook - but chose not too. When web standards were confronted with creating what came after HTML4 they started with XHTML, which like ActivityStreams was an Ivory Tower method. It took the WHATWG breaking away from the W3C and creating HTML5 to wake everyone up. They had amazing buy in from the ecosystem because they paved the cow paths(section, header, name). They solved users real needs (localStorage).

Where I ended up was partially in a state of awe. After digging through this corpus of documents that had been created by some web giants, I realized that they weren’t solving anyone’s problems. There was no there, there.

So, here is the part that I hope lives on after this mad dash of a project. We chose to go in with clear eyes, and full hearts we read the specs, we talked with some really smart people, we paved some cow paths, and in the end we created something that I am really happy with.

Please, come and help us.

PS: Github has created, bar none, one of the best collaborative code tools ever known to man. There is no reason it can’t also do that for creating a useful convention for a whole community.

Bootstrap was at the center of the recent semicolon debate. If you haven’t seen Bootstrap yet checkout our their docs. Clearly work went into this project and it’s had great adoption. Many sites use Bootstrap as a framework. They had a problem though; strong opinions on semicolons. The debate raged, and still rages to this day. To me the debate brought up two interesting ideas should we be able to code however we see fit, and who are we coding for?

Automatic semicolon insertion(ASI) as a topic of debate isn’t new to Javascript, it probably has a long history of people contributing to the topic. I say probably because as Ben Ward points out we aren’t the best at documenting it’s history:

We’ve taken our knowledge for granted, passed it on with examples and well-meaning advice, but failed to establish our references. … here we’ve failed as librarians. We knew the knowledge was out there, we trusted the knowledge, but when it was challenged no-one had a robust answer. In its place, dogmatic presumption undermines a lot of the effort around education and best practice, and the cooperative attitudes of our community.

While I agree that documentation is important, I don’t think the biggest prolem with this debate is one of history or the documentating of that history, it’s all about perspective. In an effort to help document I tried to reacll the first time I saw this debate. I came to this article written by Isaac Schlueter. Here’s something he had to say:

If you don’t understand how statements in JavaScript are terminated, then you just don’t know JavaScript very well, and shouldn’t write JavaScript programs professionally without supervision, and you definitely should not tell anyone else how to write their JavaScript programs.

I was reminded of this post because of it’s similarity in tone to @fat’s remarks regarding semicolons, near the beginning of the bootstrap semicolon debate.

i have learned to use them, that’s why there isn’t one present.

You can see these two developers echoing roughly the same idea. I code how I want, its valid, so get off my ass. If this was just two developers writing code for themselves, the debate could stop there but that just isn’t the case. These two developers are leading voices in the JS community, stewards of the language, if you will. But if you create a project like Bootstrap for general use you have to ask the question, who are we coding for?

When you take a project that is built for a large audience, including a fair number of new developers, you can’t just write code however you want. You have to ask the question. Are we writing code for ourselves, or for other people?

Ben Alman made this point, in the very thread that caused all this ruckus:

The solution to a problem like this is very simple. Project maintainers need to consider who the target audience for their project is, and maintain their project in such a way as to properly set and meet the expectations of that target audience.

and

Also, regarding the setting of expectations, one of the most prominent headers on the Twitter Bootstrap homepage is Designed for everyone, everywhere.

His voice was a rare change of topic in the long, winding thread, and hasn’t gotten it’s due. In the case of Bootstrap it’s clear that the creators don’t understand the audience they are writing for. They may not even want to think of themselves as stewards of Javascript, but I don’t think they have a choice anymore. The bottom line, if you are a steward of Javascript, you need to start thinking about your audience.

A great counterpoint to Bootstrap would be something like Backbone.js, or Underscore.js. When you frequent the bug lists of those project or read the source, you get a sense that someone is thinking about who is going to be reading this code. Granted not as many new developers, but still a great example of how you can create something beautiful that also helps the community.