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.
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.
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.
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.
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.
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.
In my life I have never been able to underestimate the power of luck. I am lucky that I was born at this time in history. Computers created the world in which I trive. Any other time in history, I just don’t know.
I am lucky that I love to write code. I don’t have the same ability as others to understand some of the harder concepts in programming, but I have made up for that in time spent on the hard problems. If I didn’t love programming I wouldn’t have spent the time it took me to get over the hurdle.
For the past couple years I have been really interested in feeds. This interest usually manifests its self in talking about Google Reader or RSS, but really it’s just the feed that I am talking about.
Well something amazing happened to me, I go lucky again. My boss, Dalton Caldwell, CEO of App.net has been writing some barn burner posts about twitter, and his last one touched a nerve.
So, today we are announcing a fix for the common twitter: An Audacious Proposal
We think that if we can get enough backers that we can create a better social network. If you want to back us, go here
I am incredibly stoked to be working on a problem that is so close to my own personal interests, and something that I have been thinking about for a long time.
Sorry for the biblical reference, I just got back from Italy, and have seen a lot of renditions of this story. It does feel somehow apt for the recent news from Twitter. I agree with most people that Twitter has made a number of misteps, but its not on it’s last legs. It’s vulnerable like Goliath is vunerable, meaning the luckiest of shots will have to be made if people want to take Twitter down.
Doesn’t it all just look like people are talking about RSS. What about something like Status.net. It doesn’t feel like we need to stretch to far to find a replacement for twitter.
For some background, you should take a look at some of the recent blog posts from Brent Simmons (here, here, and here). Also I thought this was a great post by Dalton Caldwell (to be transparent he is my boss).
The new aesthetic sat in my overflow folder for a while. I probably subscribed to it while working though a best new blog list. It was always curios. The pictures were nice, but like many blogs you figure it out by reading it. When I read the Atlantic piece It finally clicked.
If you don’t know, The new aesthetic is an art movement. It’s tag line would be an exploration of how our digital products effect us. An idea popped into my head while reading the article; I was reading the new aesthetic like people play video games. Reading the New Aesthetic manual never occurred to me. Like a video game, i just started playing, and learned by falling off the cliffs. Clearly something like the new aesthetic was never designed to be used this way, but I did, and I do. I read many blogs from this perspective.
I may not be the only one either. This might be how many people come to blogs. It might also be why many people don’t like blogs, or don’t find blogs worth there time. They might be uncomfortable with the idea of not knowing what’s going on. Or, it could be as simple as not knowing the mechanics. That’s the reason I don’t play video games. I never caught on to the mechanics of games, both physical, and in game. Which prevented me from really enjoying games like my peers.
If any of these things are true about reading blogs it would have big implications about how you write a blog. It all goes back to context I guess.
Bookmarks are a weird invention. Even more weird is that people actually use them. Sites like Pinterest, and Instapaper practically wouldn’t have been as big without bookmarklets. Of course to go mainstream there had to be buy in. Other sites needed to include them in there ecosystem. That core group of people that made the service grew up those are an amazing group of people.
I don’t know if there is any thing definitive about these people, but I am going to make some assumptions. They are informed, ahead of the curve, market makers. That last one is important, they create new markets, new spaces where there weren’t any before. I think we can all be sure that if we created a website, we want those people to use it.
I am talking about these sites, and these people not just because they are interesting, but they all seem to have something in common. Google Reader. The early growth of these websites could easily be driven by their bookmarklets, and both bookmarklets handle Google Reader especially. Instapaper even handles Newsblur. This is serious business. With all the talk of the death of RSS, these two companies still support Google Reader specially.
If you, or your company is building a new product, and you aren’t thinking about RSS, are you missing out on an opportunity to reach the same people that build Instapaper, and Pinterest?
In the all honesty category I did look at more then just Instapaper, and Pinterest bookmarklet. Turns out many other popular bookmarklets don’t handle google reader specially.
All the bookmarklets
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.