Barcamp Viejo San Juan

image

Last Barcamp we organized was back in 2012 in Mayagüez. The one before that was in 2011, and the first one was back in 2010.

We already have a date for the next Barcamp Viejo San Juan, Tuesday, June 3 at 7PM. This time we’ll be meeting at Piloto151 in Old San Juan.

For those that don’t know what a Barcamp is, Barcamp is a conference in which the guests become the event speakers. We expect everybody to make a 10 minute presentation to the rest of the audience. The idea is to encourage the exchange of ideas in an open and interactive environment.

Even though the ideal situation would be that everybody gets a chance to present, we know it’s not possible. We’ll have 20 reserved spaces and they will be available on a first come-first served basis.  If there’s not enough time or you are not ready to present, the least we expect is for everybody to interact with questions, suggestions, and help create an environment of interaction with the presenters.

The format for presentations will be 10 minutes and focused around the topics like:

  • Web development & design
  • iPhone / iPad application design & development
  • Software development in general
  • Mobile application design & development
  • Interaction Design, information architecture, user experience
  • Tech startups & venture capital

Spots for presenting are limited so if you’d like to present you should arrive early. Like always, we’ll do everything possible to make this event another #win.

We’ll have beers, some hors d’oeuvres, and t-shirts. Please let us know you plan to attend by RSVP’ing on the Eventbrite event page. This helps us plan for space and food accordingly. 

Internet Speed Tests on a Raspberry Pi

image

A couple of weeks ago soynerdito soynerdito shared a bot he made to tweet internet connection speed results every now and then.

I then remembered I had a Raspberry Pi I wasn’t using at all. So I built a small app that runs speed tests every 3 hours. It’s based on speedtest-cli which is a Command line interface for testing internet bandwidth using speedtest.net.

The only difference with the one I built is that instead of tweeting the results, it posted all available data to an endpoint. I built a Flask app that can be used to store those results for different users as well as share them via a JSON API.

If you’re interested in running your own, check this Gist out. It contains a README file that will help you setup your box(doesn’t have to be a Raspberry Pi). It also includes a sample Flask app to store your own results. If you’re interested in using the one I’m hosting you could do so, just let me know and I’ll send you a URL to store results and one to share or consume. It’d be interesting to see different kinds of results at a larger scale, not just my own.

Here are the results graphed since I started running it. Interesting to see how so many spikes in my download speeds. Those are probably related to download in other computers or probably streaming Netflix. Upload speed as expected doesn’t really fluctuate that much.

Photo credit: John Talbot

The easiest way to add WebSockets to Django

image

TL;DR – I came up with a very simple solution to handle WebSockets in Django apps. You just install django-websocket-request, run a script and you have WebSockets for your Django app. The cool thing is that this solution makes Django believe its getting a (somewhat) normal HTTP request so you can reuse almost all of you application’s code. Plays nicely with Django REST Framework and with plain function-based views and class-based views. Check out the demo and it’s source code on GitHub.

The Details

We’re building Blimp 2 which means a lot of changes in our current application, infrastructure, and how we’d tackle old and new problems. One of the decisions we made regarding our application was how our frontend and backend would be organized and how they would interact.

Blimp’s backend is currently built on Django. It serves our frontend’s HTML, handles our private and public API, and all our business logic. That’s how most web apps are usually built, but Blimp is already a client-side JavaScript heavy application. Right now a normal request goes something like: You request a URL, there’s some backend work, queries to the database, caching, some more logic, render an HTML response, load third party CSS and JavaScript libraries, load our JavaScript application, some more logic, and finally render it.

After months of usage and growth, we’ve noticed a few key improvements we can build on. The new version will have a backend app that will only serve JSON, no HTML. Our frontend app, served from another location, will then consume data from that API. We want the frontend app to use WebSockets when possible, falling back to XHR.

Web frameworks like Django are built for the HTTP request/response life cycle, so everything from middleware, authentication, and views takes in an HTTP request, and at the end is an HTTP response. On the other hand, a WebSockets server implementation knows nothing about that kind of lifecycle and what it means.

Our main objectives were:

  1. Reuse the same serialization and deserialization logic between the HTTP and WebSockets API.
  2. Reuse all business logic for all available resources.

First ideas that came to mind were to abstract all of what we wanted to reuse by writing them as methods for our models. That way we would write what we needed once, sharing it between the two implementations. This seemed like the right answer at the moment, but after a couple of hours, it proved not to be. Since we are building on top of the awesome Django REST framework, we were going to have to subclass tons of their Generic Views and Mixins, which didn’t sound as bad at the moment, but still being very skeptical we decided to look for other possible solutions.

By then we knew that we wanted a single REST API available via two different transports, HTTP and WebSockets. The best case scenario for me was to avoid rewriting anything of what we have already working for the new HTTP API, just to have it work via WebSockets. Then it clicked. I remembered that Sails.js does something similar to what we wanted to achieve.

Sails supports transport agnostic routing, which allows your controllers/policies to automatically handle Socket.io / WebSocket messages. In the past, you’d have to maintain a separate code base to make that happen.

So in more formal terms, we wanted to support transport agnostic routing, allowing us to use everything in Django’s request/response lifecycle to automatically handle WebSocket messages.

Solution

image

WebSocketRequest is the surprisingly simple solution I came up with to solve this.

WebSocketRequest is a simple class that requires a JSON string containing the following keys: method, url, data, and token. The method key can be any HTTP method: GET, POST, PUT, DELETE, PATCH, HEAD, or OPTIONS. The url key is an absolute URL without the domain name. The data key is an optional dictionary in which the key-value pairs in used to create the method’s data payload. The token key is also optional, and used to recreate an HTTP Authorization header, Authorization: JWT YOUR_TOKEN_HERE. You might want to check out my last blog post to learn more about authentication with JSON Web Tokens and if you’re using Django REST framework, you might like to check out django-rest-framework-jwt.

WebSocketRequest works as following:

  1. Validates JSON string payload.
  2. Creates an instance of Django’s RequestFactory.
  3. Dynamically calls one of RequestFactory’s methods, which returns a WSGIRequest object
  4. Resolves the given URL
  5. Instantiates the resolved view passing along the request, any positional and keyword arguments from the resolved URL.

Yeah, RequestFactory, you read that right. You might be familiar with it if you’ve written tests in Django, but if you haven’t, the RequestFactory provides a way to generate a request instance that can be used as the first argument for any view. The only down side to this is that it does not support middleware, which might be a problem for some.

You can install WebSocketRequest via pip.

pip install django-websocket-request

As always source is available on GitHub.

Demo time!

I’ve setup a demo application running on Heroku. Source code is also available on GitHub.

http://dwr-example.herokuapp.com/

Note that Django is not running at all. Tornado is serving a static HTML file and is routing the websocket requests. django-websocket-request then does the magic.

Throttling is enabled and snippets are erased periodically. If you run into any errors feel free to bother me on Twitter about it.

I definitely would like to hear about possible problems of this solution. Where do you think that this fails? How about for a production environment? Where can it be improved?

Photo Credit: Alice Bartlett / Martin Börjesson

Auth with JSON Web Tokens

image

When it comes to implementing authentication on web apps, one solution you’ll definitely hear about first are cookies. Cookie-based authentication uses a server side cookies to authenticate the user on every request. This means that you’ll need to keep a session store, whether it’s on a database or on something like Redis. A solution you’ll probably not hear as often is token-based authentication which relies on a signed token that is sent to the server on each request.

Alberto Pose over at Auth0 wrote a great blog post about Cookie vs Tokens, diagrams how both of these method works, and goes over the benefits of using a token-based approach for authentication.

There’s a relatively new standard called JSON Web Token that happens to be backed by companies like Firebase, Google, Microsoft, and Zendesk. There are already many libraries to handle encoding and decoding of this tokens in the backend.

After a couple of days of research I was convinced that this was something we could definitely use for Blimp 2. This new version will be an ambitious web application written on JavaScript. This means that there will be no HTML rendering from the server. The backend application will only serve a RESTful API that will be used by our own application as well as by developers working on third party applications.

The only difference when accessing the API will be the authentication method used. We’ll use JWT but third party application will use OAuth2.

The JWT Spec

JWT(pronounced “jot”) or JSON Web Token is a compact URL-safe representation format intented for space constrained environments such as HTTP Authorization headers and URL query paramaters. JWTs represent a set of claims as a JSON object that is encoded in a JSON Web Signature or JSON Web Encryption structure.

A JWT is represented as a sequence of base64url encoded values(with all trailing ‘=’ characters omitted.) that are separated by period characters.

The following is an example of a JWT Header

Base64url encoding of the JWT Header yields this encoded JWT Header value:

The following is an example of a JWT Claims Set:

Base64url encoding of the JWS Payload yields this encoded JWS Payload:

Computing the MAC of the encoded JWS Header and encoded JWS Payload with the HMAC SHA-256 algorithm(using the key ‘my_secret_key’) and base64url encoding the HMAC value, yields this encoded JWS Signature:

Concatenating these encoded parts in this order with period characters between the parts, yields this complete JWT.

You can read more about JWT in the submitted Internet-Draft.

An Example Scenario

First enters djangorestframework-jwt, a package I just released that provides JWT Authentication support for Django REST framework. It also provides an endpoint that can be used to obtain a JWT for a given username and password.

Once you’ve obtained a JWT, you can access resources that required authentication by passing the HTTP Authorization header.

A simple example of how this would be handled with jQuery and a Django REST Framework API endpoint with JWT Authentication.

And that’s a wrap!

And that’s basically it! I’d love to know what you think about JWT. Would you consider using token-based authentication? Any questions or feedback? Feel free to leave a comment.

Photo Credit: http://www.flickr.com/photos/number657/5179518226/

The Hacker and Designer News Newsletter

image

After recently building a scraper and web API for The News, I thought  it’d be a cool idea to use that data somehow. First thing that came to mind was to build a newsletter. And so The Hacker and Designer News Newsletter was built.

Newsletter

Every week I’ll send a newsletter with a curated recap of the week’s best articles from Hacker News and Designer News on startups, entrepreneurship, hacks, programming, design, and more. Something I may consider for the new future is allowing people to subscribe to a simple and shorter daily recap.


image

Sponsors

I’ll add your logo, copy, and a link in the top of the newsletter. If you’re interested in sponsoring this newsletter, feel free to send me an email to: [email protected].

Technical stuff

This time I didn’t take advantage of The News and decided to build a new system to collect and aggregate posts from Hacker News using HNSearch and from Designer News using a scraper. HNSearch has a niftee RSS feed that works beautifully and has all the available data. Designer News, on the other hand, has some inconsistency with the data available in the RSS and JSON feeds, so the only way to fetch all the data I wanted was by scraping their site.

Example response data format:

The project/hack is available in GitHub. Star, Watch, Fork at https://github.com/jpadilla/HackerDesignerNews