Web Intents/Activities are dead, but they could bring more life to the web

If you are creating an awesome e-mail app, you have a big problem. When meeting e-mails show up in your users' inboxes from their bosses and colleagues' calendars, they will expect some kind of integration with a calendar. You'd better integrate with a calendar, or create your own!

And integrating with only one calendar app is not enough. Oh no. You will alienate most of your users by doing that. Do you know how many calendar apps are out there? I sure don't, but OMG there must be a shitload of them!

Any.do Cal? You cannot simply afford to waste even half a week's time to improve the experience of 20 users instead of working on the loading animation. So you don't even consider supporting it.

In the end you'll only support the big guys.

This effect ends unbalancing the popularity of apps in the internet (by making the most popular apps be integrated with more stuff, which in turn makes them more popular). It also increases vendor lock-in and software duplication because it's just easier, more secure, and less trouble-prone to just develop an entire suite of related apps so they integrate well together than to integrate with dozens of third-party apps.

And you'd better pray that nobody new comes along and makes an app that becomes really popular.

This is the problem which Web Intents / Web Activities attempt to fix.

This is something which needs to have a universal browser support so web app developers can start registering their intents/activities. Unfortunately, the standardization effort seems to have been dropped by both Mozilla and Google, experimental support was removed from Chrome, and isn't even available on Firefox other than for the Firefox OS platform and Firefox for Android powered apps. A sad outcome for such wonderful tech.

Intents or Activities?

Did you notice I keep referring to this as "Intents/Activities"? The reason for that is that there are two competing defunct specs.

Google was working on standardizing Web Intents through the Web Intents Task Force, and even had (it's been removed) an experimental, prefixed WebKitIntent in their Chrome browser.

Mozilla needed something like Android's Intent on their Firefox OS platform, so they started standardizing Web Activities. They now provide a prefixed MozActivity in that same platform, and it's the standard way of doing Intents there. However, no support is present on the Firefox browser on the desktop.

A look at the dead APIs: Google's Web Intents

The Web Intents spec defines the relationship between a "Client" and a "Service". The client is the page which "Invokes" other webapps' Services, and the Service is a page which is "Registered" as capable to do some actions to some MIME types.

When the Client Invokes the service, the browser allows the user to Select what app they want to use to perform the action (which is something like "edit", "view" or "crop" but in URL form) on their data. There are a bunch of action URLs you can use, based on "http://webintents.org". It smells weird to me to use URLs as names for things, but it could be a good idea.

When The Service is Invoked, its page will be loaded up just like any other page, but have a window.intent Intent object available so they can look at what action, type and data the Client has passed him in this Invocation, and provide an adequate Response to send the Client when the user is done.

These examples are taken from the spec.

Below is an example which shows you how to register a Web Intents service for other apps to use:

[...]
<intent action="http://webintents.org/edit" type="text/uri-list image/*"></intent>
<script>
  window.addEventListener("load", function() {
    if (window.intent) {
      setImageContentURI(window.intent.data);
    }
  }, false);

  document.getElementById('save-button').addEventListener("click", function() {
    window.intent.postResult(getImageDataURI(...));
  }, false);
</script>

It's simple really, you only need to add one or more <intent> tags to your HTML describing the services you provide, and some Java Scripts to handle the case where the page is loaded as a service, and talk back to the intent user.

Here is how you use a Web Intent on some other page to allow the user to edit a photo you have somewhere.

document.getElementById('edit-photo').addEventListener("click", function() {
  var intent = new Intent({"action":"http://webintents.org/edit",
                           "type":"image/jpeg",
                           "data":getImageDataBlob(...)});
  navigator.startActivity(intent, imageEdited);
}, false);

function imageEdited(data) {
  document.getElementById('image').src = data;
}

As you can see, the intent type is a URL referring to the kind of action the intent is supposed to achieve. I can see this being unhelpful in many ways (by encouraging companies to create their own taxonomies of actions, for example).

All in all, it seems like a good proposal API, and I see no good reason it stopped being specified. I literally could not find it why it stopped, nor whether it stopped permanently.

A look at the dead APIs: Mozilla's Web Activities

Mozilla has developed Web Activities for their Firefox OS platform, and it shows.

An Activity is handled by a Handler, which is an App (mostly a Firefox OS concept) which Registers in its manifest which kinds of Activities it can handle, and what pages handle them.

When registering a handler, you can specify filters (an example of this is the type filter, which filters by mime type), and also a disposition (which defines how the application is displayed) and a returnValue boolean, which indicates if this activity handler will return a value or not.

They used a field in Firefox OS's app manifest file to announce what kind of activities your application can handle and where are the HTML files where these activities are handled.

The examples below were taken from MDN.

Here is how you can register your app as an activity handler in your app manifest:

{
  // Other App Manifest related stuff

  // Activity registration
  "activities": {

    // The name of the activity to handle (here "pick")
    "pick": {
      "href": "./pick.html",
      "disposition": "inline",
      "filters": {
        "type": ["image/*","image/jpeg","image/png"]
      },
      "returnValue": true
    }
  }
}

Here is how you handle an activity. You listen to a message (which is like an event, but is buffered for you so you can't miss it by adding a handler only after it was sent).

navigator.mozSetMessageHandler('activity', function(activityRequest) {
  var option = activityRequest.source;

  if (option.name === "pick") {
    // Do something to handle the activity
  }
});

And here is how you ask the Browser to somehow give you a JPEG. Pretty clean, no?

var activity = new MozActivity({
  // Ask for the "pick" activity
  name: "pick",

  // Provide the data required by the filters of the activity
  data: {
    type: "image/jpeg"
  }
});

activity.onsuccess = function() {
  var picture = this.result;
  console.log("A picture has been retrieved");
};

activity.onerror = function() {
  console.log(this.error);
};

A look at the dead APIs: comparison

I like how the Mozilla spec limits the activity types to a manageable count and how it lets you define if you wish to open a new window or open an overlay.

I also prefer Mozilla's client API. It seems much more familiar to just create an Activity and listen to events on that instance, like we do with XmlHTTPRequest and Web Workers.

On the other hand, I like how the Google spec allows a much, much simpler implementation of the Service.

Both have their pros and cons, and I hope they merge the two specs together somehow, and create an amazing shiny unicorn of love and butterflies!

Closing thoughts

Intents/Activities are already present in the mobile app world, and connect our mobile apps seamlessly and beautifully. In the desktop, it seems like fans of putting files somewhere and use them later have taken over everything and barf at gorgeous and intuitive workflows.

These APIs are seriously cool and extremely beneficial for both developers and users. Unfortunately it's not good businesses which want users to only use their stuff. It's definitely not good for Google, Apple nor Microsoft who have a lot of apps and want them integrated together in a closed ecosystem to increase vendor lock-in. And this means that 3 out of the 4 significant browser vendors are simply not interested in pushing this forward. They'd best snuff this out.

We already have closed walled-garden versions of Intents in Microsoft Office/Outlook, Adobe Creative Suite, and on Google apps (like the cool integration between Gmail and Google Drive). These weren't created to benefit the users, but instead to increase vendor lock-in.

This would make the web a significantly better place by giving a chance to smaller independent developers. They will do their integration more easily and concentrate on what their app does best, while easily connecting their app to a web-sized ecosystem of shite they could never dream of supporting otherwise.

If one of these specs was released, implemented and used by webdevs worldwide it would make the web a lot better, but it's pretty much dead. I would very much like them to be alive. I would very much like browser vendors to bridge Web Intents / Web Activities with similar APIs like Elementary OS's Contractor or Android's Intents so everyone can finally work seamlessly with web apps and native apps. I want to upload my e-mail attachments on Dropbox or to Google Keep all the time, and it's a bother. It doesn't have to be.

Learn to encode, please!

As a software developer, you should be aware of character encodings and avoiding several problems with encoded strings.

Thanks to many software developers' issues in understanding that (and Windows) (and paths with spaces), I have four home folders in my system.

Thank you for your understanding. Or should I say, please start understanding?

Undercutting - a personal rambling

My underpaid self has been thinking about his own life and actions. It turns out I am doing the wrong thing by sitting in the same place.

I have spoken to a friend about my salary and what I do at work, and she scolded me for helping undercut other people's well deserved salaries. She is quite right. She told me of how she and her group had lost a web and graphic design project to some company who promised to do the same for much less. They obviously ended up doing a terrible job, and screwed up someone else's opportunity in the process.

My current employer does do the same thing, but this post is not about companies undercutting each other. It is about workers undercutting other workers in the same sector. By allowing myself to be underpaid for my work, I am not just being a fool. I am undercutting other IT professionals who live around my area and have skill sets similar to mine.

When I started working at my current job, I was told that my pay would increase as soon as I had proven myself a valuable addition to my company.

I should have known it wasn't true as soon as I had learned that a colleague and old friend, who is a skilled programmer and most defenitely a valuable addition to the company, has worked for nearly three years in the company and earns little more (less than 1%) than I. It should have been blatantly obvious when I knew that another colleague, an IT tech and nerdy nice guy on whose shoulders the company runs a lot of its profit and stability (he runs the actual maintenance operations for the company's maintenance clients), is in a worse situation, since he actually deserves more than both of us, but earns the same amount we do.

And as time passed and I created websites, applications and whatnot, it was obvious that that "valuable addition to the company" line was just crap.

I feel like a sucker. Now my country is in a crisis. Prices going up, a higher tax on my salary. My boss is saying that if we ever get a raise we will only waste the extra money in luxuries. I guess that's how he sleeps at night. This shit revolts me deeply.

But I never stopped to think that I was actually harming someone else.

Sometimes people are not too picky about their jobs. People at the start of their carreer or people who have just lost a job are often happy to take whatever they get. Some companies (like my own) are opportunists and will use this instead of hiring qualified personel for a proper value. Some companies use excuses like "gathering experience", "prove oneself as valuable to the company", or "finantial issues" to postpone expectations of better pay for another day. Empty promises that I am sure have made many boost their dedication and productivity for nothing. Actually they ended up undercutting a lot of people and yet deserved better pay themselves. It happened to me. I have seen it happen to a dear colleague who was hired after me.

This snowball of bullshit has to stop, and not just for me and my company. If you are in a similar situation, you should at least consider trying to end it if you can afford losing your job for a few months. If everyone accepts crappy jobs and bullshit, someday we all will only have crappy jobs and bullshit, and nobody will be able to do anything about it.

Python's new Enum class

I used to wish to have an enumeration in Python, like you have in other languages.

On May 10th, GvR accepted PEP 435, which proposes the addition of an Enum type to the standard library.

Before this, us python coders would need to use plain classes for enums, which doesn't work so well. We can't get enum names by value, for example.

It follows that it's not possible to create a list of 2-tuples for use with Django models. We'd need to have a class mapping our choice names to their values, but you can't create the good old "choices" structure, so that's pretty useless. However, since our new enums are iterable we can:

    class ChoiceClass(IntEnum):
        foo = 1
        bar = 2
        baz = 3

    CHOICES = [(e.value, e.name) for e in ChoiceClass]

Creating your enumerations

By inheriting from Enum, you can create your own enumerations. If all your enumeration values are supposed to be of the same type, you should inherit Enum as well as that type.

    class Numbers(int, Enum):  # you can also use IntEnum
        one = 1
        two = 2
        three = 3

    class Text(str, Enum):
        one = 'one'
        two = 'two'
        three = 'three'

Using your enumerations

By iterating over your enum class, you get the enumeration members, which can be queried for their name or value.

    print(' '.join(['{}: {}'.format(number.name, number.value) for number in Numbers]))

Internally, there is some metaclass magic going on, to allow us to succintly declare these enums. The class comes with a few facilities, like __iter__ as I showed above, __call__ which gets enumeration items by value, and __getitem__ which gets them by name.

You should understand that enumeration items are actually instances of your enumeration class. Which allows us to say isinstance(Text.one, Text).

You can get your enumeration items in several ways.

• As an attribute: Numbers.one, the Java way
• By name: Numbers['one'], a tad prettier than using getattr
• By value: Numbers(1), as a constructor

In a way, the third syntax reminds me of how we convert values using their constructors in python, for instance, using str or int to convert existing objects to string or integer values.

You can start using these enums right away. There was talk of porting this back to python 2 on the python-dev mailing list, but right now the code is for python 3 only. I'm going to convert some Django code to use these enums later, because I have three declarations for each Choice I need (SOMETHING_CHOICES, SOMETHING_DICT, SOMETHING_REVERSE), which is just backwards.

You can grab a copy of this module at bitbucket. Beware, because this was only put up for PEP evaluation. You'll want to wear a helmet and keep in mind that this is not stable or supposed to be used in production code. Although Guido has accepted it at the time of writing, it may still be subject to change, since the PEP is not in the "final" status.

That said, grab the "ref435" module from that package and try it out.

    >>> from ref435 import Enum
    >>> class Enumeration(int, Enum):
    ...     potatoes = 1
    ...     apples = oranges = 2
    ... 
    >>> Enumeration.apples is Enumeration.oranges
    True

You can look for reference in the PEP.

See you next time!

PHP

Yesterday I have had the joy of writing some php code. It was marvelous. minutes later a syntax error popped from a regular function taking a string. I called my colleague, who had experience with php. We were both stumped. It used eval. I guess we are both dumb.

Php is so simplistic and easy to understand, it's painful. If I pass an undeclared constant off to a function, php goes all the way to interpret it as its own name for me. I guess that would make some code more readable. Why mix foo with "bar"? This syntax allows us to just go all the way and use constant name syntax everywhere. Then we just don't declare the constants supposed to be those strings. Such advanced magic.

They say that the best technology is indistinguishable from magic. I say the best technology goes ahead and makes my code run more easily, even if it has bugs which will pop up later. It's so smart right? Who cares about tomorrow? Everybody knows code is written just once and doesn't need to be maintained or anything like that.

Code for today. Write no abstractions. Php allows the ultimate freedom. If you want to shoot yourself in the foot, just do it. It's not like there is anything stopping you at all. It's your job, not mine. You know what you are doing. We all know that php is a language for experts, everyone will know better than to carelessly use unsanitized user input to form SQL queries (and HTML too!) It all comes from $_GET clean and safe with your magic slashes right?

</sarcasm>

It's not a language problem as much as it is a cultural problem. Although the former appears to have caused the latter.

Django-webtest

When testing my views in a Django application, I always use django-webtest. This is a Django binding for a library from paste, which simply talks to a web application using wsgi, and acts like a browser in a very basic manner.

For example: submitting forms works as expected and sends the data contained in the inputs inside such form, in the method defined in <form method=""> and to the url defined in <form action="">, click()ing links takes you to the url in their href attribute, etc.

These are tests which will actually tell you if your templates are broken. So you are not simply testing your views. You are testing the template html as well. If you forget to add that {÷ csrf_token ÷} to your form, the test will fail. If one of the designers accidentally removes your "edit profile" link, you will know that.

An obviously missing feature is JavaScript support. So, if your app doesn't work without it, you won't be able to use this to the fullest.

Your view testing code with WebTest will look like this:

    def test_delete_object(self):
        object = construct_model_instance_somehow()
        owner = object.owner

        # go to the object's page, logged in as the owner
        details_page = self.app.get(object.get_absolute_url(), user=owner)

        # click delete link
        delete_page = details_page.click('delete')

        form = delete_page.form

        form.submit().follow()

        self.assertFalse(Object.objects.filter(
            some_data='you know').exists())

Every .click() call is an assertion that the page loads with no errors, and returns the response. You can actually chain click calls, even though I don't find it so useful myself. If you want a BeautifulSoup to check that your HTML response contains the correct links, just install BeautifulSoup (3.x for now) in your environment and access response.html to get a soup. Not to mention .showbrowser(), which fires up your browser to show you the HTML directly. A huge time saver for debugging.

In conclusion, very useful stuff. You should use it.

Pip requirements.txt tip

Everybody loves requirements.txt files, right? You can list your dependencies, and then together with pip and virtualenv reproduce your application's environment complete with all dependencies in several machines.

This file is also known as pipscript.txt. in case you don't know, requirements.txt is a file containing a list of packages in this format:

    Django==1.4.4
    Fabric>=1.0
    OtherPackage==6.0
    -e git://some.git/repo/containing/package

It's very simple to use. You just have to use the command pip install -r <requirements file>. For this reason, it makes it very easy to automate a deployment step.

Splitting your requirements

In case your application needs to split requirement files for some reason, you can do that! Just add this line in a pip file:

    -r some/requirements.txt

To include another requirements file.

The requirements listed in the included file will get installed too.

I found out about this trick in this heroku doc page . It makes a lot of sense, seeing that requirements.txt represents a pip install command for each line. We get -e, why not -r?

This is very useful for Django, where you need a different package set in production and development.