Ricardo Lopes

The most amazing animal in the world

Thu, 23 Jul 2015 00:00:00 +0100

Is it the cat? The dog? The velociraptor? Or something completely different? This is the blog post format of the lightning talk “The most amazing animal in the world” I recently gave at FutureLearn and Thundercloud LND.

There is an animal out there that is far more amazing than anything else we might have known before. An animal that has been found in the heights of the Himalayas, the warmth of Japanese hot springs, the high pressures of the bottom of the ocean, the freezing cold of Antarctica, among other places. An animal that you’ve probably never seen before, as it’s no longer than 1.5 mm. An animal that has been on this planet far longer than we have, and that will probably remain after we’re all long gone. That animal is the water bear, also known as tardigrade, and this post will explain why it is, by far, the most amazing animal in the world.

Tardigrades have been on this planet for the last 500 million years. In comparison, humanity started 2 million years ago. Even the earliest dinosaurs (227 million years ago) are closer in time to us than to the first tardigrades. This means that the tardigrades have survived the natural disaster that pushed dinosaurs to extinction. In fact, they’ve survived all 5 mass extinctions of this planet. But how did they manage to do that?

Heat

Tardigrades are incredibly resistant to extreme heat. How extreme is that, exactly?

Most heat-tolerant organisms support up to 122 ºC. These organisms are typically simple bacteria, as more complex ones would more easily have a weak spot. Tardigrades, however, can do even better: in one experiment, they were able to support some impressive 151 ºC!

Cold

The coldest temperature ever recorded on Earth was some freezing -89.2 ºC. So animals don’t really need to worry about anything colder than that. Except for the tardigrade, which supports temperatures as low as -272 ºC! That’s about just one degree above absolute zero, the lowest temperature that can ever exist in the universe, when molecules stop moving and even gases turn into solids.

Near absolute zero, crystals start forming inside animals’ bodies. These crystals can tear apart crucial molecules like the DNA. However, tardigrades seem to be able to prevent that, thanks to their superpower:

Tun

Tardigrades have a superpower called the tun state. They can get into a state where they get rid of all the water in their bodies and their metabolism slows down to near 0%. This is like hibernation, improved. Because they replaced the water in their bodies, they can survive near absolute zero temperatures without great risk of crystals forming inside them. They can also survive in this state for many years, without the need to eat or drink.

After getting into this protective state, tardigrades only need to get in contact with water to return to their normal state and get back to business.

Pressure

Pressure, apparently, is measured with megapascals (MPa). I don’t know what 1 MPa means, and probably neither do most of you, so let’s put things in perspective:

Most systems stop metabolising and start failing at around 30 MPa. The deepest part of the sea, the Challenger Deep in the Mariana Trench (around 11 km deep), can get pressure up to 100 MPa. So that’s the strongest any living organism on Earth would need to support. The strongest bacteria, however, can manage up to 300 MPa before dying. And tardigrades? Those can support up to 600 MPa. That’s twice as much as the strongest bacteria, and 6x more than the strongest pressure on this planet!

Radiation

At this point there seems to be little left that could surprise us. These tiny animals just seem to be consistently breaking records. So how do they fare when handling radiation?

Tardigrades are able to sustain 1,000x more radiation than other animals. A thousand times more. They support up to between 5,000 and 6,200 Gy (grays, the unit for absorbed radiation), while humans, for instance, can’t take more than between 5 and 10 Gy.

This incredible resistance to radiation helps explain the next and last fact, which might well be the most impressive of them all.

Space

If the previous facts weren’t enough to convince you that we’re talking about the most amazing animal in the world, how about this one: the tardigrade was the first (and only) known animal to survive in space. And by surviving in space, I mean being left in the vacuum for days, completely exposed to solar radiation. And then returning home and successfully hatching healthy offspring. Humans, in comparison, would die in seconds, either by suffocation or due to the radiation.

So let’s recap

Tardigrades:

survived 5 mass extinctions (and counting)
manage up to 151 ºC
and down to ~1 ºC above absolute zero
which is 3x colder than the coldest place on Earth
have an amazing superpower: the tun state
can live years without food and water
can handle 6x more pressure than the highest pressure on Earth
sustain 1,000x more radiation than other animals
are the only known animal to survive in space

And that’s why tardigrades are definitely the most amazing animal in the ~~world~~ universe!

Cool links if you want to know more about them:

The Wikipedia page on tardigrades
A recent BBC article
This one includes tardigrades and Neil deGrasse Tyson gifs

Setting up a hacker's blog with Jekyll, part 3

Fri, 19 Jun 2015 00:00:00 +0100

This is the last part of my small series of tutorials about building your own blog with Jekyll, no autogenerated code included. You can read the previous posts, part 1 and part 2. In this last tutorial we’ll be working with the same blog example code as in the previous ones. However, if you’re just looking for a particular solution to a problem you might be facing, these examples should be self-contained enough to help.

Just to recap from the previous tutorials: we’re using the gem Jekyll to generate our blog’s static pages. We do that by running jekyll serve, which also allows us to test it in our browser locally. Our blog code structure is currently looking like this:

_config.yml
_layouts
    default.html
    post.html
_includes
    disqus.html
    paginator.html
_posts
    2015-02-01-hello-world.md
    2015-03-01-my-second-post.md
    2015-04-01-aprils-fools-post.md
_site
index.html

And now let’s improve it.

RSS feed

What’s a blog without an RSS feed to let readers subscribe to it? To get one, you need an XML file complying with the RSS spec, and then a link to that file from your default layout, so that it’s available for every page of your blog. Let’s start with the XML file. You can simply create a feed.xml in your project root, like you have for index.html. Let’s fill it with the blog’s latest posts:

---
---

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>{{ site.name | xml_escape }}</title>
    <description>{{ site.description | xml_escape }}</description>
    <link>{{ site.url }}</link>
    <atom:link href="{{ site.url }}/feed.xml" rel="self" type="application/rss+xml" />
    {% for post in site.posts limit:10 %}
      <item>
        <title>{{ post.title | xml_escape }}</title>
        <description>{{ post.content | xml_escape }}</description>
        <pubDate>{{ post.date | date_to_rfc822 }}</pubDate>
        <link>{{ site.url }}{{ post.url }}</link>
        <guid isPermaLink="true">{{ site.url }}{{ post.url }}</guid>
      </item>
    {% endfor %}
  </channel>
</rss>

This code fetches relevant information from site.name, site.description, site.url and site.posts. That last one we already used in the first tutorial for building the initial index page, so should be no surprise. The other ones are values we can define in _config.yml. We’ve previously set the value of name. Now we can add description and url as well:

name: My blog
description: This is my new blog
url: http://www.example.com

author: Ricardo Lopes
twitter: ricardoplopes

permalink: "/:title"

paginate: 2
paginate_path: "/:num"

Now, Jekyll should have generated a _site/feed.xml file that includes the blog’s posts. The last thing we need to do is including the feed in the blog pages. We can do that in _layouts/default.html, so that all pages include it, by placing the relevant line inside the <head> element:

---
---

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>{{ site.name }}</title>
    <link rel="alternate" type="application/rss+xml" title="{{ site.title }}" href="{{ site.url }}/feed.xml">
  </head>
  <body>
    <div style="max-width: 800px; margin: 20px auto">
      <h1><a href="/">{{ site.name }}</a></h1>

      {{ content }}

      <hr>
      © {{ site.time | date: '%Y' }} {{ site.author }}.
      <a href="https://twitter.com/{{ site.twitter }}">Follow me on Twitter</a>
    </div>
  </body>
</html>

And that’s all you need to do to set up a feed so that your readers can start subscribing to your blog.

And now for something completely different: styling.

Styling with SASS

Given the choice between something terrible and an improvement, you’d probably go for the improvement. So our blog’s style will be in SASS instead of plain CSS. Those files will live in the new _sass directory of our project (didn’t see that one coming). For every jekyll serve, the SASS files will be compiled and the necessary CSS will be generated in the _site directory, like the rest of the generated static pages.

Let’s start this exercise with a simple refactor. Just by looking at the last code example, we can see some ugly inline CSS in an HTML file. That’s not what any serious codebase should look like. Let’s separate those styles into their own styling file (like _sass/style.scss) and leave the HTML alone:

#body {
  max-width: 800px;
  margin: 20px auto;
}

We’re applying those rules to a DOM element with id body. So now, in _layouts/default.html, we can replace:

<div style="max-width: 800px; margin: 20px auto">

with:

<div id="body">

Great, so now if you check the newly generated pages… you’ll see that we’ve just broken the previous style. That’s because we still need to include the generated CSS file, css/main.css, in the layout. The final code should now look like this:

---
---

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>{{ site.name }}</title>
    <link rel="stylesheet" href="/css/main.css" type="text/css">
    <link rel="alternate" type="application/rss+xml" title="{{ site.title }}" href="{{ site.url }}/feed.xml">
  </head>
  <body>
    <div id="body">
      <h1><a href="/">{{ site.name }}</a></h1>

      {{ content }}

      <hr>
      © {{ site.time | date: '%Y' }} {{ site.author }}.
      <a href="https://twitter.com/{{ site.twitter }}">Follow me on Twitter</a>
    </div>
  </body>
</html>

Now we should get our old style back.

Because SASS augments CSS in some interesting ways, we can explore new things in our new styles file:

$body-width: 800px;
$phone-max-width: 570px;

$desktop-vertical-margins: 20px;
$phone-vertical-margins: 10px;

$main-color: #F91111;
$text-color: #564A4A;

@mixin on-phone {
  @media screen and (max-width: $phone-max-width) {
    @content;
  }
}

#body {
  max-width: $body-width;
  color: $text-color;
  margin: $desktop-vertical-margins auto;
  @include on-phone {
    margin: $phone-vertical-margins auto;
  }
}

a {
  color: $main-color;
  text-decoration: none;

  &:hover {
    color: lighten($color-main, 15%);
    text-decoration: underline;
  }
}

Some things this code does, if you’re not too familiar with SASS:

Nesting: if we’re styling links and want to ad additional styles to its hover status, we only need to define &:hover inside a, instead of having a separate a:hover. Great for avoiding scattering things all over the place;
Saving commonly used values like colours into variables that can be used in CSS properties. Great for DRY;
Using mixins to define different styles for different situations, like setting a smaller margin for smartphones. Also great for DRY.

Studying the things we can do with SASS is out of scope of this tutorial, so if you want to know more, I encourage you to explore the great tutorials that can be found online.

Summary

After having improved our blog in this last tutorial, we should now have a structure like this:

_config.yml
_layouts
    category_index.html
    default.html
    post.html
    tag_index.html
_includes
    disqus.html
    paginator.html
_plugins
    categories.rb
    tags.rb
_posts
    2015-02-01-hello-world.md
    2015-03-01-my-second-post.md
    2015-04-01-aprils-fools-post.md
_saas
    style.scss
_site
index.html
feed.html

We now have a fully functional blog with categories, tags, proper styling, a feed to subscribe to and all the other features shown in the previous parts of this tutorial, like comments and pagination. There is, of course, a lot more that we can do. If you’ve followed through, I’d recommend you to take a look at the official documentation, where you can find more detailed information about each thing. You can also take a look at my own blog’s source code, which is open source and available on Github.

A layman's guide to good passwords online

Fri, 01 May 2015 00:00:00 +0100

We have a problem with passwords: they suck. They’re hard to memorise, easy to steal and sometimes have to fit to very specific and silly rules. Online security, nowadays, is just too complicated. So most people tend to end up ignoring security practises, making them vulnerable to cyberattacks. You know you should be doing better, but you don’t know exactly how or why, and your patience and energy are better focused somewhere else, right? If so, then this guide is for you.

Let’s start debunking some myths and exploring easy and secure practises you can start implementing today. By the end of this guide, dealing with your passwords should actually be simpler and need less of your energy than before.

Use long, not cryptic passwords

You’ve probably heard that the strongest passwords are the ones that have letters (lowercase and uppercase), numbers, special symbols like # or ! and that aren’t common words. So something like b@2Y&s would be great. But that’s too hard to remember, so you go for something simpler, or decide to note that down somewhere.

I have some good news for you: that example password I just showed you is actually terrible, and you shouldn’t torture yourself trying to memorise something like that. Why is it terrible?

A typical attack tries to guess your password by trying every single possible combination of characters until it finds the right one. So it could start trying for a, then b, then c, at some point going through Y, Z, aa, ab, and so on. For 1-character long passwords with letters and numbers, that means that such an attack tries 62 different possibilities (26 lowercase letters, 26 uppercase letters and 10 numbers, from 0 to 9). For 2-characters long passwords, the number of different possibilities rises to 3,906. And so on. For a 6-characters long password that’s around 57 billion different combinations.

But b@2Y&s includes special symbols like @ and +. Let’s say that means that there are now 38 more symbols to consider, making it a total of 100 (26 lowercase letters, 26 uppercase letters, 10 numbers and 38 special symbols). Now, the number of different possibilities to consider to break your 6-characters long password increases to 1 trillion. That’s why adding those symbols is good: it’s more combinations that attackers have to try.

However, if, instead of adding those symbols, we just increase the password size from 6 to 8 characters, the number of different combinations rises to 222 trillion. So a password like 2Bananas is 222 times harder to break than a password like b@2Y&s! If you add numbers and special symbols it gets even better, of course. But that doesn’t mean having to come up with impossible to remember passwords. Something like 2Bananas!! would need 101,010,101 trillion combinations (also because it increases in size).

Why is this important? Those numbers of different combinations might all seem too big to be a problem. However, computers are getting increasingly fast. If a computer can try a billion combinations per second, for instance, then breaking b@2Y&s takes less than 17 minutes. Breaking 2Bananas would take around 2.5 hours. Breaking 2Bananas!! would take 3,200 years.

So if there’s one thing you should be remembering from this post is this: longer passwords are way better than shorter passwords, even if you don’t use special characters. They’re also way easier to remember. So go ahead and change them now. The biggest example I showed was still small (just 10-characters long), so that the numbers wouldn’t be too high to understand. But in practise it’s better to use even longer passwords.

Here’s a great comic on this topic.

Don’t use common passwords

Just because you were just freed from using cryptic passwords like Rs*F2Q9kn%[L, it doesn’t mean that you can use any word for a password. You’ve just learned how to protect against a brute-force attack, but there are other kinds of attacks.

Attackers know that brute-force attacks can be extremely inefficient against long passwords. Wait 3,200 years to break a password? Good luck with that. So they like shortcuts. If a lot of people use password, qwerty, 1234567890 or others, then there’s no need to wait for all possible combinations: they can just try those ones first. Here’s a list of the 10 most common passwords, as of 2014:

123456
password
12345
12345678
qwerty
1234567890
1234
baseball
dragon
football

A lot of accounts are currently using one of those passwords. This means that if an attacker doesn’t want to wait to get access to logged in accounts, they just need to try these. So if you use any of these passwords for any of your online accounts, change it right now, because it takes any serious attacker a fraction of a second to break it, even if you’re not specifically the only target! In fact, take a look at the original, longer list and make sure it’s not in there also.

Using your email address, full name, name of the website you’re visiting or anything like that isn’t also going to be a lot safer. Those are all things that an attacker will know. So it’s important that you choose uncommon or illogical words or phrases, because those will be nearly impossible to guess (once again, refer to the comic in the previous section).

So, one last time, please remember: never use any of those most popular passwords as a password to any kind of account you might have. Having one of those is almost as safe as having nothing at all.

Don’t repeat passwords

You’ve probably heard this one before. You should have different passwords for every account. But it’s so hard to remember any password, how could anyone possibly remember that many? And why should you even do it, exactly?

If a website you’re using doesn’t properly protect login details and gets hacked, a list with your email and password gets leaked for every attacker to use. So if you’re using the same combination in different websites, no matter how secure they might be, your account there will still be compromised. Sometimes you don’t even need to have a website get hacked: you just need someone to get physical access to your PC, or to glance at your post-it with a complicated password written down, among other possibilities. Getting passwords is easy. So you don’t want people entering your bank account because somebody watched you type your Facebook password.

So how can anyone remember so many different passwords? I hope that if you read the previous sections, this one gets easier. We’ve discussed how cryptic, impossible to memorise passwords aren’t that good, and how memorable phrases are actually much more secure. If that still sounds too difficult to do for every single account you have online, then make sure that you do it at least for the most important ones (like your bank account, or your email account where you keep important confidential notes).

Since you should now be using phrases as passwords, you might want to make some rules that let you have different passwords for different accounts without having too much to memorise. For instance, you could include the main colour of the website. So for Facebook you could use 2BlueBananas, and for GMail 2RedBananas. This isn’t perfect, and you shouldn’t be too obvious (like just adding the website name), but it’s better than nothing.

A better approach to have great passwords that never repeat for different websites is to use a password manager. A password manager is an application that you can have in your devices that will generate strong passwords for your and store them securely. This way, passwords can be long and cryptic, because you don’t need to remember them, and you can have one of those per account. Comparing different password managers and explaining how to use them goes out of scope of this guide, but it might be a good topic for a future one. If you’re curious, I invite you to investigate more and start using one. It will be the best you’ll do for your security online.

I’m lost, summary please

Use long passwords. For every character that you add, breaking your password gets incredibly more difficult. It’s ok if it’s 20, 30 characters long.
Don’t use cryptic passwords. There’s no point in trying to memorise b@2Y&s (or noting it down somewhere insecure) if longer, more memorable passwords like 2Bananas!! are way more secure.
Don’t use common passwords. Those are the absolute worst. Really. Never use anything from this list.
Use different passwords for different accounts. At least for important accounts, like your bank.
Coming up with some rules (like adding the colour of the website) is not perfect, but better than doing nothing.
Better yet, you could start using a password manager that will pick great passwords for you and store them securely, so that you can have one per account and will never need to memorise them again.
Watch this short interview with Edward Snowden, who knows a lot more about this than I do.
Share this post with your friends. Seriously, they’re probably vulnerable to cyberattacks right now, and you can help them improve their security online.

Setting up a hacker's blog with Jekyll, part 2

Fri, 13 Mar 2015 00:00:00 +0000

Feeling like building your new bog from scratch with tools that empower you to develop it the way you want? You’ve come to the right place. If you’re just starting, make sure you read part 1 of this tutorial, where you can learn the advantages of using Jekyll over other options and how to use it to create a basic blog from scratch. In this second part we’ll be working with the same blog example code to extend it and make it more interesting. However, if you’re just looking for a particular solution to a problem you might have with your existing blog, these examples should be self-contained enough.

Just to recap from the previous tutorial: we’re using the gem Jekyll to generate our blog’s static pages. We do that by running jekyll serve, which also allows us to test it in our browser locally. Our blog code structure is currently looking like this:

_config.yml
_layouts
    default.html
    post.html
_posts
    2015-02-01-hello-world.md
_site
index.html

Now without further ado let’s get hacking.

Better URLs

Jekyll defaults URLs to the format /:year/:month/:day/:title.html. So our Hello World post has the URL /2015/02/01/hello-world.html. However, this isn’t the best structure: it’s long and exposes a file extension and the full date. We can change this by setting a value to permalink in _config.yml.

If you’re ok with showing the full date on the URL (some blogs do this to give a temporal context and to make it easier to have multiple posts with the same slug), then you can set the value of permalink to pretty, which hides the HTML extension:

name: My blog
author: Ricardo Lopes
twitter: ricardoplopes

permalink: pretty

I typically prefer to remove the date from the URL, because I want my posts to be generally timeless, and because if they got an update, that URL would suddenly be misleading. You can do that setting permalink to none.

However, that still exposes the HMTL file extension, which I also don’t want. Jekyll doesn’t provide a direct value for these requirements, but fortunately it lets you build your own custom URLs. So if you want URLs that simply display the post slug you need to change your _config.yml to:

name: My blog
author: Ricardo Lopes
twitter: ricardoplopes

permalink: "/:title"

You can adapt that to your needs: prefer having the categories and the publication year included? Change it to /:categories/:year/:title. And so on.

Paginating our list of posts

Right now we’re displaying every single blog post in our index page, which is far from ideal. Since we have just one blog post so far we still don’t see a problem with it, but if we get to hundreds, we really shouldn’t be showing them all in one page.

For the sake of experimentation, let’s create two new blog posts. Our posts directory should now look like this:

_posts
    2015-02-01-hello-world.md
    2015-03-01-my-second-post.md
    2015-04-01-aprils-fools-post.md

Now that we have 3 different posts, we can paginate our blog to show only 2 posts per page. Ideally you might want more posts per page, but for now this should be good enough to test what we want.

Pagination is done by setting the number of posts per page in the config attribute paginate and, if you want a particular URL for those pages, setting its format like the one described for permalinks in the config attribute paginate_path. So to test for 2 posts per page, our _config.yml would change to something like:

name: My blog
author: Ricardo Lopes
twitter: ricardoplopes

permalink: "/:title"

paginate: 2
paginate_path: "/:num"

However, if you visit your blog now you’ll notice that it’s still not paginating. That’s because we’ve configured pagination, but we’re still not using it. Let’s look back at index.html:

---
layout: default
---

{% for post in site.posts %}
  <h2><a href="{{ post.url }}">{{ post.title }}</a></h2>
  {{ post.excerpt }}
{% endfor %}

We’re iterating over the full list of the website’s posts. We want to iterate over the posts that belong to a particular page of our pagination. To do that, we have to fetch posts not from site, but from paginator:

---
layout: default
---

{% for post in paginator.posts %}
  <h2><a href="{{ post.url }}">{{ post.title }}</a></h2>
  {{ post.excerpt }}
{% endfor %}

Great, now we should just see the latest two posts. And if we browse /2 we should see the second page, with the oldest post there. Still, there’s no paginator to browse different pages easily.

We can add that to the end of index.html, so that it shows after the list of posts. we only want to show it if there’s any need for it, i.e. only if there’s a previous page or a next page:

...

{% if paginator.next_page or paginator.previous_page %}
  <!-- paginator code here -->
{% endif %}

With this interface you can do the fanciest paginator you can think of. Here’s a suggestion for how index.html might look like with one of the simplest paginators that can be done:

---
layout: default
---

{% for post in paginator.posts %}
  <h2><a href="{{ post.url }}">{{ post.title }}</a></h2>
  {{ post.excerpt }}
{% endfor %}

{% if paginator.next_page or paginator.previous_page %}
  {% if paginator.previous_page %}
    <a href="{{ paginator.previous_page_path }}">Previous page</a>
  {% else %}
    Previous page
  {% endif %}
  |
  {% if paginator.next_page %}
    <a href="{{ paginator.next_page_path }}">Next page</a>
  {% else %}
    Next page
  {% endif %}
{% endif %}

Great, we now have pagination working with proper navigation. Our index.html is starting to look crowded, though, and if we ever want to reuse the paginator code, there’s a lot there to copy and to maintain. It’s time to look at includes.

Includes

Jekyll has this nice thing called includes, which are basically partials that you can reuse on multiple pages. So if you’ve just built your perfect paginator and you want to use it in different lists of posts, you can just put it in its own include and then just call it from those pages. Includes, unlike regular layouts, go inside their own directory: _includes. If you want to isolate the paginator code into one, then you’ll need to create a _includes/paginator.html. Using the same code as above, that file would be something like:

{% if paginator.next_page or paginator.previous_page %}
  {% if paginator.previous_page %}
    <a href="{{ paginator.previous_page_path }}">Previous page</a>
  {% else %}
    Previous page
  {% endif %}
  |
  {% if paginator.next_page %}
    <a href="{{ paginator.next_page_path }}">Next page</a>
  {% else %}
    Next page
  {% endif %}
{% endif %}

As you can see, there’s no need to add a front matter for includes. Having this new file, we could then change our index.html to be simply:

---
layout: default
---

{% for post in paginator.posts %}
  <h2><a href="{{ post.url }}">{{ post.title }}</a></h2>
  {{ post.excerpt }}
{% endfor %}

{% include paginator.html %}

In the beginning, it might seem that using includes is an overkill that just scatters the code all over your code. However, as the code gets more complex, some parts start to repeat, or files start to get too big. Right now this paginator is only used for one page (the blog index), but is ready to be reused by other future pages, like tags or categories pages. Another good use for includes is using them to isolate external blocks, like share links or comments. Speaking of comments…

Comments with Disqus

Because these blogs are nothing but a group of static pages, it’s impossible to serve comments as you would with Wordpress or something similar: when a reader wants to post a comment, there’s no database for it to go to. So the solution is to use a third-party tool to serve comments.

There are plenty of solutions out there that can be used. The most popular one, which is also the one I’m using for my blog, must probably be Disqus. It’s usually a good option because it allows users to post using their favourite social network accounts, lets the same account post on multiple blogs, instead of having to create a new one per blog, and gives blog authors a good set of tools to moderate and manage inbound comments.

There are other platforms for blog comments, like Facebook’s, Google’s and more. You should really pick the one that you think makes more sense for the type of blog you’re creating. So if you’re building an awesome new hacker’s blog, there probably won’t be a big audience that prefers to use their personal Facebook accounts to engage in the discussions.

Because Disqus is usually seen as a good generic option and because that’s what I experimented with when I built my blog, that’s the one I’m showing how to use. If you want to use another, you might still benefit from some of the tips below.

To get started with Disqus go to their website, register and follow their instructions. You should be given a code snippet to paste into your blog. That code snippet should be asking for important information like your username, the post’s identifier and the post’s URL. This is a great example of code that we can put in its own include. So let’s create a _includes/disqus.html and drop the code there, using the right tags to fill the requested information:

<div id="disqus_thread"></div>
<script type="text/javascript">
    /* * * CONFIGURATION VARIABLES: EDIT BEFORE PASTING INTO YOUR WEBPAGE * * */
    var disqus_shortname = 'your_disqus_shortname';
    var disqus_identifier = '{{ page.url }}';
    var disqus_url = '{{ site.url }}{{ page.url }}';

    /* * * DON'T EDIT BELOW THIS LINE * * */
    (function() {
        var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true;
        dsq.src = '//' + disqus_shortname + '.disqus.com/embed.js';
        (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq);
    })();
</script>

Please remember that, because this is a third-party tool, it might have changed since this post was written. Make sure that you get the most up-to-date code instead of just copying this example.

Now that we have a new include, we just need to add it wherever we prefer. Because it’s comments, it makes sense to add it to the blog post layout. So _layouts/post.html should be updated to:

---
layout: default
---

<h2>{{ page.title }}</h2>
<p>{{ page.date | date_to_string }}</p>
{{ content }}

{% include disqus.html %}

That should be enough to have comments on your blog. Disqus will also give you moderator options through their website. Other providers should probably give you similar tools. If at some point you want to switch commenting providers, you can work on the new one’s code on its own include while still keeping the old one, and when you’re happy to do the switch you just need to change in the post layout the include to be used.

What’s next

After having improved our blog in this second tutorial, we should now have a structure like this:

_config.yml
_layouts
    default.html
    post.html
_includes
    disqus.html
    paginator.html
_posts
    2015-02-01-hello-world.md
    2015-03-01-my-second-post.md
    2015-04-01-aprils-fools-post.md
_site
index.html

In this second tutorial we covered some more material to get to an awesome hacker’s blog. However, there’s still a lot more that we can add, and it wouldn’t fit in a single blog post. So there will be a third post where I’ll try to cover RSS, categories, tags and some theming. If you think that there’s something else worth mentioning, do shout.

Don’t forget to subscribe to get the latest updates as soon as they’re published. Alternatively, you can follow me on Twitter, where I plan to post the links to those updates. And, like I mentioned the last time, my blog’s source code is open, so you can learn from it and get some ideas through its Github project.

Update: Part 3 now available.

What if we found life on Mars?

Sat, 28 Feb 2015 00:00:00 +0000

A week ago I gave a lightning talk at FutureLearn called “What if we found life on Mars?”. It’s a highly speculative theme, outside of my usual discussions around tech and software development, but one that I find particularly fascinating. So I thought that it would be a good idea to bring that talk’s ideas into a blog post format.

Recently we’ve been greeted with exciting news: Curiosity rover, which roams our neighbour planet Mars, has found active organic chemistry. This is big news because organic matter is one of the necessary conditions for life to emerge. Here’s what the team said about the discovery (emphasis mine):

We think life began on Earth around 3.8 billion years ago, and our result shows that places on Mars had the same conditions at that time – liquid water, a warm environment, and organic matter.

So if life emerged on Earth in these conditions, why not on Mars as well?

Curiosity confirms organics on Mars; Opportunity’s 10 year anniversary

This exciting piece of news makes us all wonder: what if, indeed, we found evidence that there is or there was at some point life on Mars? And what does that mean for us?

The Fermi Paradox

To better understand what that would mean for us, we’ll look at the Fermi Paradox. Let’s start with some maths:

There are around 10²² to 10²⁴ stars in the observable universe. That’s 10,000 stars for every grain of sand on Earth. Our galaxy alone has between 100 to 400 billion stars. Knowing that around 5 to 20% of those stars are similar to our sun, then the lowest estimate points to at least 5 billion sun-like stars in our galaxy. Also, we know that those stars have a probability of around 22% of having en Earth-like planet orbiting it. Adding everything up, there’s at least 1 billion Earth-like planets orbiting sun-like stars in our galaxy alone.

Now we need to start getting speculative. How likely is it that a planet like that develops life? We know that Earth did, but we don’t know if this was a rare occurrence or not. So if we go for a conservative route and say there’s just a 1% probability of an Earth-like planet orbiting a sun-like star to develop life, then that means that there should be at least 10 million different planets with life.

Now, how many of those planets get life to evolve into an intelligent species? Once again, we know that life on Earth evolved to that point, but we have no way of knowing how rare we are. If we keep speculating with the same probability, then out of 1% of all those planets that developed life would emerge intelligent life. Adding all these conservative estimates up, that’s at least 100 thousand different intelligent species across the galaxy!

And that’s not all. The Earth is a young planet orbiting a young star. Our galaxy is old, and there are much older planets than ours out there. Can we imagine what would it be like for a species that evolved at the same rate as ours, but in a planet that’s just 1 billion years older? How would we be in a billion years from now? Colonising our galaxy? That’s estimated to take around 5 million years, so if we’re talking about a 1 billion year period, then that’s something relatively quick to do for such a civilisation. Sending communications to other places in the universe? Also pretty likely. So if there are younger intelligent species, they should be already at that stage. The universe should be full of interplanetary communications from many different civilisations, and our galaxy should have been colonised by now.

Where is everybody?

So if the universe should be so full of life and communications, how come haven’t we seen anything yet? Our observations never registered any kind of artificial device that wasn’t launched from Earth. And although we keep listening for signals in many different wavelengths from space, we still didn’t get a single message. This doesn’t make any sense, when we think of our previous estimations. So there must be something else going on.

Theory 1: They’re there, we just haven’t heard from them

One theory is that those civilisations exist, but for some reason we just never heard from them. And there are many possible explanations.

Maybe some colonising species did indeed visit Earth at some point, but since our civilisation and recorded history are so young, they could have visited well before that, and so we would have no way to know about it now.

Or maybe our galaxy is colonised, but we just live in some desolate rural area. Similarly, we could still be considered too primitive by more developed species, and so we could be living in some protected environment (think of something like a zoo).

One scary possibility is that there might be a highly developed predator species. This would explain not only a lower number of existing intelligent civilisations than what we estimated, but also why they could be hiding their presence instead of broadcasting it. Let’s not think too much about this one, OK?

Maybe our technology is just too primitive and our understanding of space too incomplete. We’re listening for radio signals, but maybe they use radio as much as we use smoke signals. Maybe there’s a lot of communication going on using different channels, like by manipulating sub-atomic particles, and we’re just too primitive to be able to listen to that.

Many other possibilities exist to try to justify this. Maybe colonisation doesn’t make sense for higher civilisations after all, or maybe we’re just a product of a simulation of some other species, or maybe it’s something else no one thought of yet.

However, there’s a scarier theory to explain this paradox.

Theory 2: There are no higher civilisations in existence

Maybe we’re really alone and there’s no one else in the entire universe. This should be highly unlikely, because of all the numbers we’ve seen before. So the best explanation for this is that we’re taking too much stuff for granted, and one of the steps between having a habitable planet and actually developing a galaxy-colonising civilisation must be nearly impossible to achieve.

This hypothetical nearly impossible step is commonly referred as the Great Filter: there are probably many planets creating the simplest forms of life out there, but at some point in the evolution process there’s this filter that eliminates almost all of them. These are some of the steps that might qualify as the Great Filter:

Habitable star system
Reproductive molecules
Simple (prokaryotic) single-cell life
Complex (archaeatic and eukaryotic) single-cell life
Sexual reproduction
Multi-cell life
Tool-using animals with big brains
Intelligent life
Colonisation explosion

In this list, we’re currently on step 8, which means that we’ve successfully transitioned from all the previous steps. Unfortunately, because we don’t about any species from other planets, we don’t know how easy any of these steps are. Did we already pass the Great Filter and we’re now on our way to colonise the galaxy? Or is the Great Filter ahead of us?

There are many reasons to why the Great Filter could lie ahead of us: maybe a civilisation is unable to start harvesting its galaxy’s resources before running out of its own planet’s. Or maybe the development of advanced artificial intelligence can result in extinction due to unexpected consequences. Or getting to galaxy exploration may take too much time to avoid some life-ending asteroid collision. Among many other depressing possibilities.

Back to Mars, what can we learn?

Looking back at the list of possible steps for the Great Filter, what would it mean for us to find life on Mars?

Imagine that we find life on Mars at step 5: “sexual reproduction”. This means that that step and all the previous ones were easy steps, since 2 out of 2 studied planets (Earth and Mars) managed to get there. So the probability that the nearly impossible step lies ahead suddenly increases. In addition, still considering that example, we can assume that the next step, “multi-cell life”, would also be easy, since we’ve got records of that happening 46 times already. So the only possible difficult steps would be 7 (“tool-using animals with big brains”), 8 (“intelligent life”) or 9 (“colonisation explosion”). That would mean that the probability of having the Great Filter ahead of us would suddenly jump to 1 out of 3.

So, in conclusion, if we found life on Mars, we’d probably be doomed, because that would mean that the chances of having the Great Filter ahead of us would increase dramatically. And having the Great Filter ahead of us means that our chances of reaching the next evolutionary step are as good as none.

Some interesting reading material if you found this topic interesting:

Wikipedia entries on the Fermi Paradox and the Great Filter
The Fermi Paradox from What But Why
The Fermi Paradox: Back with a vengeance from Sentient Developments

Avoiding the “think outside the box” trap

Sun, 22 Feb 2015 00:00:00 +0000

Disclaimer: This blog post was first published on the 25th of October of 2012. This means that most of its content might no longer be up-to-date. This was published in my previous blog, which has met an unfortunate end, and is being reposted now as an attempt to resurface some of the most popular posts that have been lost.

These days I’m getting sick and tired of all the “think outside the box” talk. In my area (technology and computers stuff) we have three kinds of young people: those who have yet to wake up for reality (mostly gamers that chose this area because it’s about those machines that can run videogames); those who want to play safe and spend their years being treated as slaves in a low-wage and unfulfilling job; and those that love to “think outside the box”. So what is that thoughtful activity anyway?

“Thinking outside the box” means trying unconventional ideas and questioning the status quo to get to new conclusions and possibilities. Imagine all you take for granted in this world and all your beliefs being put in a box. That means that whenever you’re solving a problem or looking for an answer, you’re thinking inside that box of yours. You’re in your comfort zone. You’re safe. But there is a full world of possibilities outside of that box to be explored, and sometimes the answer to a problem might just be hidden outside of those boundaries. So you have to step out of your comfort zone and explore new ideas and beliefs you you want to get your answers.

That is the theory. Now for reality.

At least among rather young people (18 to 30?) in the technology area, that expression is very popular. People use it to try to stand out from the crowd, although much of the crowd is using it already by now. Even though they might not notice it, they’re not really using it in its original meaning anymore: for the tech guys, “thinking outside the box” is avoiding the low-wage unfulfilling job and challenging the standard, usually by trying to live an entrepreneur’s adventure or simply by chatting about the latest innovations and what cool technological projects could be made out of them. In every meetup, in every talk, in every event, there it is: the dreaded “think outside the box” telling you to create the next Google or Facebook and live the startup entrepreneur’s dream (this is actually an oversimplification, but I hope you can still see my point here).

So, have you noticed something terribly wrong so far? If not, please read the description of the original meaning of that expression again. It seems that almost all the tech guys are pointing to the same direction when they talk about “thinking outside the box”. Not just to the same direction, but many times also to the very same spot! Now how’s that for challenging your beliefs, getting out of the comfort zone and exploring new ideas and possibilities? How come can you talk about shifting the way you question the world and then fall to the same exact spot as everybody else who tries to do the same?

Eager to stand out from the crowd and expand their ideas, people move their thoughts out of their box, just to let them fall in another one. This “second box”, as it might be called, is just a trap state where you can easily fall if you don’t see it. But hey, nobody said it’d be easy to truly get out of that hated box! The whole purpose was to do the near-impossible and change the status quo, so it shouldn’t be too much of a surprise if there are some traps and pitfalls on the way.

So how can that trap be avoided so that we can truly achieve great paradigm shifts and new discoveries? Unfortunately, there is no right answer for it, at least that I’m aware of. If I new it, I’m sure I’d be a much better and happier person by now. However, I’m sure it wouldn’t hurt to stop thinking so much about creating new startups and launching new technological products, and start trying to push creativity and imagination to come up with amazing new ideas. Not million-dollar business ideas (although those might also be welcome), but simply crazy ideas that at the end of the day will have an impact on you and on the world around you.

How many tech folks would consider travelling to a country not knowing a single word of their language just to help children with family problems? How many with the right skills would work with a young NGO to develop their website without asking anything in return? And how many would spend hours every week watching recorded lectures online from the world’s best universities and doing their exercises?

As every other guy will tell you, it’s still nice to look for entrepreneurship adventures, though (as I’ve also done and intend to keep doing). Just keep in mind that it’s just one pattern you can follow when you’re trying to think different and broaden your scope of the world, and that there is an endless list of other patterns, some of them better, others worse. Just don’t fall in the trap of immediately going for that “second box” if that wasn’t your initial goal.

If you dodge that trap, there is a whole world of new adventures waiting for you. A scary world, way different from your usual assumptions and mostly unknown And still, powerful enough to amaze you and to give you new insights and tools for critical thinking, problem solving and self-fulfilment.

More Semantic Web for Ruby: mastering your data

Sun, 15 Feb 2015 00:00:00 +0000

Disclaimer: This blog post was first published on the 14th of October of 2013. This means that most of its content might no longer be up-to-date. This was published in my previous blog, which has met an unfortunate end, and is being reposted now as an attempt to resurface some of the most popular posts that have been lost.

In a previous post I shared some important tips and resources for anyone who plans on developing for the Semantic Web in Ruby (like in a Ruby on Rails webapp). If you haven’t checked it yet, I strongly recommend you to do so. This new post goes a step further and shows you how to convert data from the Semantic Web to your app’s data model and also the other way around.

To get our mappings between the Semantic Web data and our app’s data model we need some Ruby gems. The gem rdf lets us parse and work with RDF data in Ruby. The gem linkeddata gives us additional resources for working with the semantic web and the Linked Data. Finally, I will also use the gem rdf-turtle because I find the Turtle notation to be clearer than the RDF/XML notation, so this gem helps us parse this alternative notation (if you won’t use Turtle, you’ll be just fine without this gem).

Importing RDF data to Ruby

As we’ve seen in the previous tutorial, creating a semantic graph in Ruby for describing RDF data is as easy as doing:

graph = RDF::Graph.new

Now we want to create a semantic graph based on the data of an existing RDF file. To do that, we need to change it to:

graph = RDF::Graph.load(path_of_rdf_file)

We can now query that graph to import its data to our Ruby application. The rdf gem is powerful enough to allow querying that graph using pure Ruby code (no SPARQL needed).

Let’s imagine we’re developing a blog and we’re importing RDF data about posts and their authors. We have the models Post and Author in our application. The RDF ontology that the data on that file is using is called MyBlog and has the class Post (for the authors, it reuses the class Person from the well-known ontology FOAF). That ontology has also the properties hasTitle (that links a MyBlog:Post to a string of its title) and hasAuthor (that links a MyBlog:Post to a FOAF:Person).

Here is an example of how we could query the graph to find all posts:

include RDF
MyBlog = RDF::Vocabulary.new("http://ricardolopes.net/myblog.owl#")

# Load the RDF file to a semantic graph
graph = RDF::Graph.load(path_of_rdf_file)

# To get all the posts, we need a SPARQL-like query, but using hashes
query_posts = RDF::Query.new({
  :post => {
    RDF.type => MyBlog.Post,
    MyBlog.hasTitle => :title,
    MyBlog.hasAuthor => :author
  }
})

# Build an array of results of that query
results = query_posts.execute(graph)

Now we have an array called results that holds all instances of objects with RDF:type MyBlog:Post. To import the relevant data, we should now iterate through these results and create a new Post for each. Here is an example of how to do that and fetch each post’s title:

results.each do |result_post|
  post = Post.new
  post.title = result_post.title
  post.save
end

We can fetch the title of the post using result_post.title because in the query that originated those results we asked to store the value of the property MyBlog:hasTitle in a variable called title. Remember that the value of MyBlog:hasTitle is a string with the title of the post, so we can save its value directly in our Ruby class.

To fetch each post’s author we need to do an extra step. Unlike MyBlog:hasTitle, the MyBlog:hasAuthor property doesn’t hold a string: it holds a reference to an individual of the class FOAF:Person. For our application we want to store the author’s name and URI. To get the string with the name of a FOAF:Person we need to query its property FOAF:name. To get the string with their URI we use the reference of the individual. Here is an example of how we could modify the last piece of code to add the author’s name and URI to the post:

results.each do |result_post|
  post = Post.new
  post.title = result_post.title

  # New query, this time to get the post's author
  query_author = RDF::Query.new({
    :author => {
      RDF.type => FOAF.Person,
      FOAF.name => :name
    }
  })

  # Get the authors and fetch the one from this post
  query_author.execute(graph).each do |result_author|
    # If it's the same reference, we found it!
    if result_author.author == result_post.author
      post.author_name = result_author.name
      post.author_uri = result_author.author
    end
  end

  post.save
end

As we can see, this second query looks like it’s cluttering the code. This could be avoided if the original query (query_posts) was already expecting it. So one way to greatly simplify this code would be to change query_posts to the following:

query_posts = RDF::Query.new({
  :post => {
    RDF.type => MyBlog.Post,
    MyBlog.hasTitle => :title,
    MyBlog.hasAuthor => :author
  },
  :author => {
    FOAF:name => :name
  }
})

This would fetch not only the full list of posts, but also the author (and their name) of that post, because its identifier is the same as the identifier of the value of MyBlog:hasAuthor (:author). However, if an author didn’t have a FOAF:name, we wouldn’t get any information of that post, because that query expects results in all the variables we’re querying. In addition, if we wanted to fetch more information about the post (its creation date, its category, etc.), we should only include it in the initial query if it’s always present, because otherwise, since there’s a variable in the query with no value, the posts that don’t have that value won’t be fetched. So the solution to fetch that additional information only if it’s available is to do a second query (so even if that second query fails for posts without that value, the first query still succeeds and at least we got the essential information of the post).

So unfortunately there might be situations where we do need to do further queries that make the overall code look uglier. However, there are always ways of trying to mitigate that problem as much as possible. One way is to create a separate method for these second queries, so to get the author’s name you only had to do:

results.each do |result_post|
  post = Post.new
  post.title = result_post.title
  post.author_name = query(graph, result_post.author, FOAF.name)
  post.save
end

# And the method would look like:
def query(graph, element, property)
  new_query = RDF::Query.new({
    :element => {
      property => :property
    }
  })
  new_query.execute(graph).each do |result|
    return s.property.to_s if element == result.element
  end
end

That method expects to return a string. It might need some adjustments for other tasks, like returning the URI of the element.

With this information, it is now possible to fetch all the information we need from an RDF file to the Ruby application’s data model. Now we look at the exact opposite: exporting our application’s data into an RDF file.

Exporting relational data from Ruby to semantic data in RDF

In the previous tutorial, in section “Putting the Semantic Web in Ruby on Rails”, we already saw how to create a semantic graph in Ruby, populate it with RDF classes and properties, and export it to a file. Now, we’re using the application’s data model to automatically export the application data.

Lets use the same blog example for the export process. The first thing we need to do is get everything ready:

graph = RDF::Graph.new
FOAF = RDF::FOAF # This vocabulary is known by the gem
MyBlog = RDF::Vocabulary.new("http://ricardolopes.net/myblog.owl#")
data = RDF::Vocabulary.new("http://example.com/myblogdata#")

MyBlog represents the ontology we’ve been using. data represents the namespace of this blog application (one of the many that would be using the MyBlog ontology). We can now iterate through all the blog’s posts and save them to the semantic graph:

Post.each do |post|
  uri = generate_unique_uri(post)
  graph << [data[uri], RDF.type, MyBlog.Post]
end

In the code snippet above we first fetch a unique URI for the blog post, because every object in RDF must have an identifying URI. We could implement a method to generate such URI based on some rules (an auto-incremented integer, truncating its title, etc.), or we could avoid that step if we saved its URI when we were importing the RDF data. However, if your application is intended to make it easier for users to manage semantic data, chances are not all the exported objects were previously imported.

After generating the identifying URI, we use it to add the post to the semantic graph. data[uri] joins the application’s namespace (defined in the snippet of code before this last one) with the generated URI (so if a post got an URI my-first-post, it would result in http://example.com/myblogdata#my-first-post). RDF.type and MyOnt.Post return the property type of the ontology RDF and the class Post of the ontology MyBlog, respectively. These three elements together are the equivalent of the following triple:

<http://example.com/myblogdata#my-first-post>
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
<http://ricardolopes.net/myblog.owl#Post> .

This means that we are adding to the semantic graph a triple that states that the blog post identified by my-first-post is of type MyBlog:Post. We could extend the previous code to include the remaining information of the post:

Post.each do |post|
  uri = generate_unique_uri(post)
  graph << [data[uri], RDF.type, MyBlog.Post]
  graph << [data[uri], MyBlog.hasTitle, post.title]
end

Finally, we also want to add the author information. Since the author is another RDF object, we need to create it and link it to the post:

created_authors = []
Post.each do |post|
  uri = generate_unique_uri(post)
  graph << [data[uri], RDF.type, MyBlog.Post]
  graph << [data[uri], MyBlog.hasTitle, post.title]

  # Only add new author element if it hasn't been added before
  if not created_authors.index(post.author_uri)
    graph << [data[post.author_uri], RDF.type, FOAF.Person]
    graph << [data[post.author_uri], FOAF.name, post.author_name]
    created_authors << post.author_uri
  end

  # Link the post to its author
  graph << [data[uri], MyBlog.hasAuthor, data[post.author_uri]]
end

Now we should have all the information we want in our semantic graph. The last step is to export it into an external file. This is something that we also dealt with in the previous tutorial, so now let’s try to do it using the Turtle notation, to generate files that are easier to read by humans:

PREFIXES = {
  rdf: 'http://www.w3.org/1999/02/22-rdf-syntax-ns#',
  owl: 'http://www.w3.org/2002/07/owl#',
  xsd: 'http://www.w3.org/2001/XMLSchema#',
  rdfs: 'http://www.w3.org/2000/01/rdf-schema#',
  foaf: 'http://xmlns.com/foaf/0.1/',
  myblog: 'http://ricardolopes.net/myblog.owl#',
  data: 'http://example.com/myblogdata#'
}
RDF::Writer.for(:ttl).buffer do |writer|
  writer.prefixes = PREFIXES
  graph.each_statement do |statement|
    writer << statement
  end
end

The PREFIXES array is optional, but it’s a nice to have addition to make the resulting file easier to read. If you are using other ontologies, it’s better to add them to that array, as well. Then, we use an RDF::Writer to write all statements of our semantic graph into a file using Turtle (:ttl) notation. This is where the gem rdf-turtle comes in handy, so if you’re exporting to a different RDF notation, you probably won’t need it.

To sum up

As with my previous tutorial, this one is also not intended to be a step-by-step manual that gives you a working demo by the end of it. Instead, this tutorial is meant to be a helper for everybody that is struggling with the integration of the Semantic Web and Ruby, and a complement to the previous tutorial. More specifically, it is intended to demonstrate how to import and export semantic data into/from a Ruby application that relies on a relational data model.

As I’ve concluded in early 2012, Ruby tools for development with the Semantic Web are still not as good as tools that we can find for other languages, such as Java. Still, it’s good to see that it is in fact possible to import and export data seamlessly using pure Ruby, so if this is the main Semantic Web related feature your application is supposed to have, the good news is that it shouldn’t be too hard to develop it in Ruby on Rails, Sinatra or any other Ruby framework.

Developing for the Semantic Web with Ruby on Rails, the 2012 guide

Sun, 08 Feb 2015 00:00:00 +0000

Disclaimer: This blog post was first published on the 30th of January of 2012. This means that most of its content might no longer be up-to-date. This was published in my previous blog, which has met an unfortunate end, and is being reposted now as an attempt to resurface some of the most popular posts that have been lost.

The Semantic Web, an Internet of of connected knowledge, meaningful data and machine-readable information, is seen as many as the future of the Internet. Envisioned by Tim Berners-Lee, its purpose is to transition from a web of unstructured documents into a “web of data”, in which we could browse and search for data not only based on syntactic keywords, but also based on semantic meaning. However, it’s awkward to realise that most of the work around the Semantic Web is done in Java, and many technologies with great future potential, such as Ruby on Rails, are seemingly forgotten.

Having developed a Semantic Web project using that Ruby framework, I found very scattered information and tiny bits of contributions, many already obsolete. It’s almost shocking to see so few and old information around such a modern framework with such a vibrant and participating community developing for it. As such, having collected many of those bits of information, I believe it’s time to put them together and finally create an updated guide to the development for the Semantic Web with Ruby on Rails.

Disclaimer: This is not a step-by-step tutorial, so don’t expect to know how to develop a Semantic Web application in Ruby on Rails as soon as you finish reading this. The main goal of this article is to save hours of research and show the best and updated tools available. Also, the code examples aren’t necessarily complete or 100% correct, as their goal is to explain something, and not simply being copy+pasted to a tutorial application.

Building the ontology and fetching relevant data

If you’re going to develop a website using the concept of the Semantic Web, one of the first things you’ll need is an ontology. You may find many useful ontologies capable of describing the data your web application is going to use (the Swoogle project might be a good place to start your search), but you might as well have to develop your own. If you’re building your own ontology, I recommend using Protégé for it.

The development of the ontology is out of the scope of this article, as it has no relation to the platform used to develop the web application itself, so if you don’t know how to start I’d recommend reading some simpler guides first (here’s a short collection of links that might help you with that).

After you have the right ontology to power your web application, it’s time to to fetch the data. Unless you’re aiming for a very limited and controled set of elements, you’ll probably want to develop a screen scraper or use an external API. Using the Ruby gem Nokogiri, you can easily browse and fetch the information you want from any useful website. Here is a simple example of a screen scraper for your application:

items = []
doc = Nokogiri::HTML(open(website_url))

doc.css(".item").each do |item|
  link = item.at_css(".info h4 a")[:href]
  item_doc = Nokogiri::HTML(open(link))

  name = item_doc.at_css("h2#title a").content.to_s
  description = item_doc.at_css("p.description").content.to_s

  items << ["name" => name, "description" => description]
end

return items

As you see, this little example simply iterates through all the elements of the website of the class item, browses to their specific page and then extracts the name and description. This technique may have its flaws, like being vulnerable to major website redesigns, but it’s also a very simple and rapid way of extracting large quantities of information.

Ideally, you’ll want to save your new information in XML files or in a database, so you can use them later without having to run the fetcher again. This, of course, is just a temporary location, ready to change as soon as the Semantic Web enters the game.

Putting the Semantic Web in Ruby on Rails

It’s easy enough to develop for the Semantic Web in Java, as you can easily find a large set of tools to help you in every stage of the development. In Ruby it’s not that easy at all. After some research you’ll probably come across two Ruby gems that handle the semantic graph: ActiveRDF and RDF.rb. However, ActiveRDF is now outdated and it doesn’t seem to work as it should in Rails 3. So RDF.rb it is, then.

Now that we have the tool to manage the semantic data, we should save our raw data in a semantic graph. We’ll use the N-Triples format for that. First you’ll need to define all the semantic relations of your data:

include RDF

MyOnt = RDF::Vocabulary.new("http://ricardolopes.net/myont.owl#")
graph = RDF::Graph.new

items.each do |item|
  graph << [item["uri"], RDF.type, MyOnt.Item]
  graph << [item["uri"], MyOnt.hasName, item["name"]]
end

return graph

This example assumes that you have an ontology with the URI http://ricardolopes.net/myont.owl, which has at least a class Item and a property hasName. This example, as all others in this guide, is far from complete, as it is just used for quick demonstrations. One thing it doesn’t show is how to create the unique URI for each item. That is up to you to decide, as every project is different. However, when you have a unique identifier for every item, you probably should do something like item["uri"] = MyOnt[unique_identifier]. Beware, though, that if you use MyOnt to store individuals, you’ll no longer have an empty ontology serving only as a schema. You’ll probably find it more useful to use an URI for the ontology schema and another for the individuals (MyOnt and Data, for instance).

After that step, you’ll then need to store the information of the semantic graph you created in an N-Triples file:

RDF::Writer.open("data/graph.nt") do |writer|
  graph.each_statement do |stmt|
    writer << stmt
  end
end

This is it. you should now have a complete N-Triples file with all your semantic information. Now that you have the semantic data, you may start using its full potential.

Querying the graph

If you’re not new to the Semantic Web development you’re probably used to SPARQL when it comes to querying for information. In Ruby on Rails you’ll find it possible to do such queries using pure Ruby, thanks to the RDF.rb gem. Imagine you have the following information:

<http://ricardolopes.net/data/2011/01/10/ricardolopes>
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
<http://ricardolopes.net/myont.owl#Developer> .

<http://ricardolopes.net/data/2011/01/10/ricardolopes>
<http://ricardolopes.net/myont.owl#hasName>
"Ricardo Lopes" .

<http://ricardolopes.net/data/2012/01/30/semanticwebarticle>
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
<http://ricardolopes.net/myont.owl#Article> .

<http://ricardolopes.net/data/2012/01/30/semanticwebarticle>
<http://ricardolopes.net/myont.owl#hasName>
"Semantic Web article" .

<http://ricardolopes.net/data/2011/01/10/ricardolopes>
<http://ricardolopes.net/myont.owl#isAuthorOf>
<http://ricardolopes.net/data/2011/01/30/semanticwebarticle> .

This means that we have an individual of the class Developer that has the name “Ricardo Lopes”, and an individual of the class Article that has the name “Semantic Web article”. We also have a relation that states that the Developer “Ricardo Lopes” is the author of the Article “Semantic Web article”.

Imagine now that you’re showing the article “Semantic Web article” and want to show the name of its author. Using the RDF.rb gem, you could do it simply using Ruby:

article_name = "Semantic Web article"

graph.query([nil, MyOnt.hasName, article_name]) do |stmt1|
  # stmt1.subject now holds the URI of the article
  graph.query([nil, MyOnt.isAuthorOf, stmt1.subject]) do |stmt2|
    # stmt2.subject now holds the URI of the author
    graph.query([stmt2.subject, MyOnt.hasName, nil]) do |stmt3|
      # stmt3.object now holds the name of the author
      author_name = stmt3.object.inspect
    end
  end
end

If you still prefer to use SPARQL instead of pure Ruby, there’s a gem for that: SPARQL-Grammar. Beware, though, that, as I’ve said before, the Semantic Web in Ruby has still a long road to run to catch up with languages such as Java. The work to bring SPARQL to Ruby is still very incomplete and there are many things you can’t do (sometimes I couldn’t even define prefixes, which resulted in some very ugly queries).

You now have the tools you need to make full use of the semantic information of your application. With many Semantic Web applications, this is all you need to know. However, there’s more we can do. If you’re developing in Ruby on Rails, chances are you’re intending to put your web application on the cloud. And there’s also a good possibility that you may want to change some of your data in the future. That’s when a simple file is no longer an option to store your data and you must upgrade it to a Triple Store.

Leveling up to a Triple Store

A Triple Store stands for an N-Triples file as a database stands for an XML file (sort of). So if you’ll ever need to update the semantic information of your web application, that’s what you should use.

There are plenty of Triple Stores in Java for you to run locally or in your server, like Jena, AllegroGraph, Sesame and many more. There are interfaces that let your Ruby application interact with those Java Triple Stores, so if your server supports Java or localhost is as far as you’ll get, them one of those might be the right solution for you.

However, if you’re developing the webapp in Ruby on Rails, chances are you want it online, and your infrastructure might not make it simple to support many languages and configurations. If that’s the case, then you need to develop an interface that creates an abstraction in your server’s database so it acts as a Triple Store. Such an abstraction would probably use a single 3-column table (for subject, predicate and object) and would return a set of triples for every query received. The hardest step should be converting from SPARQL or pure-Ruby RDF.rb queries into the proper SQL query.

Fortunately, if you use PostgreSQL and/or SQLite, there’s an amazing work done that integrates those databases with RDF.rb data. It’s the Ruby gem RDF-do, and it may save you days of work and many frustrations.

To sum up

Once one grasps the power of the Semantic Web, it’s not easy to ignore its advantages and future potential. However, as you can now see, the work around it in Ruby feels scattered and incomplete. Because it was so difficult to come across these scattered pieces of great work and because of what can be achieved when they are all connected, there was a great need of putting all this knowledge together. Yes, there are other similar guides online, but many are so outdated that may put you on the wrong track.

As I’ve pointed out before, this wasn’t intended to be a step-by-step tutorial for you to copy+paste all the code you needed to develop a basic application. If this article is so long as it is, imagine how it would be with all that information. It’s more like an updated guide you can use to save hours of research and frustration.

A follow-up tutorial is now available, describing how to import and export semantic data into/from Ruby: More Semantic Web for Ruby: mastering your data.

Setting up a hacker's blog with Jekyll

Sun, 01 Feb 2015 00:00:00 +0000

If you’re looking for a blogging platform or framework to start sharing your thoughts with the rest of the world, there’s no shortage of options to consider. My previous blog was a self-hosted Wordpress install, a pretty popular option, which turned out to be a disaster for me. Other popular options include regular Wordpress, Medium or even Tumblr. However, if you want your blog to exercise your hacking skills, then Jekyll is the way to go.

Jekyll is a static websites and blogs generator that is run from the command line. What this means is that instead of setting up a database of posts, comments, etc. and a webapp that connects to that database to generate dynamic webpages, it simply generates all the necessary pages upfront. This means that you don’t have to worry about databases, caching, running live server code, and so on: it’s as simple and practical as it can get.

I wouldn’t recommend it to anyone with no programming background, however. You’re expected to deal with YAML files to change the website settings, HTML with Liquid tags to build the structure of every page, Ruby to develop or tweak any plugins and Markdown (or an alternative, like Textile or raw HTML) to write any post. Also, generating the website after every change (in design, structure, or simply after every new post) is done through the command line, and after that you still have to upload the generated files to your server.

However, for the enthusiastic developer, this means that you have full control over the entire process. It also means that dealing with your blog feels closer than ever to hacking one of your projects. You can, in fact, never leave your favourite text editor: even for regular blog posts, I get to do everything with vim.

Enough talk already. If I got your interest, let’s get hacking. This is a Ruby tutorial, so I’m assuming that you have Ruby installed and are comfortable enough using it.

Setting up Jekyll

Jekyll is a Ruby gem, so its installation is what you’d expect:

gem install jekyll

Now you have two options: you either ask Jekyll to build you a complete new site from its default template, or you just go ahead and build your own from scratch. For the former, you’d just need to type:

jekyll new yourwebsitename

After that, you’d have your brand new website in the newly created yourwebsitename directory. From that directory, you’d only need to type jekyll serve to generate the static files and be able to browse it.

However, that doesn’t feel like hacking at all. So fire up your favourite text editor and get yourself a cup of coffee, because we’re building it the fun way.

Index

A typical Jekyll blog is structured into specific directories inside of the root project directory. So start by creating a directory for your new blog, where all the code will live.

All the generated static files will go to the directory _site. So if you create a new index.html in your project root and run jekyll serve, a _site/index.html will be created. While that Jekyll server is running, you can view that generated page at localhost:4000.

For our new blog’s index, we’ll want to iterate through our list of blog posts and show their title and excerpt:

---
---

{% for post in site.posts %}
  <h2><a href="{{ post.url }}">{{ post.title }}</a></h2>
  {{ post.excerpt }}
{% endfor %}

The templating tags you can see are Liquid tags. You use {% text %} for logic like iterating a list (like ERB’s <% text %>, and {{ text }} for text output (like ERB’s <%= text %>). Another relevant remark about the code above is that you don’t need to surround the excerpt with <p> tags: its output already includes them.

In this code we can see another important part of Jekyll: the front matter. It’s the block defined by the triple dashes, and it holds any configuration, in YAML, that you might need in a page. Right now we’re not needing anything, so we’ll just leave it empty. We can’t just remove it, because otherwise the Liquid tags won’t get parsed by Jekyll (it would just be treated as a regular, static HTML file).

Trying to check the generated site with this code won’t show anything interesting. That’s because our blog still has no posts to display. Let’s fix that.

Posts

The blog posts must be stored in the _posts directory. Their filename should be their publication date followed by their intended URL identifier (slug). This ensures that you get your posts organised by date and you can immediatelly identify any of their files, while it also gives two important bits of information to Jekyll to use. So if you want to create your Hello World post, you would name it something like _posts/2015-02-01-hello-world.md (in this tutorial I’m assuming we’re formatting our posts with Markdown). Here’s how that file would look like:

---
title: Hello World!
---

Welcome to my new **blog**!

This time we have a use for the front matter: for a blog post we need to define a title. It’s not necessary to include the post publication date and slug, because Jekyll already gets them from the filename.

Browsing the generated site should now start to get more interesting. You should now be able to see your new post listed in the blog index and be able to navigate to its page.

However, everything still seems too simple and ugly. It’s time to give our blog a proper look.

Layouts

In Jekyll you theme your blog by providing a list of layouts. Those are stored in the _layouts directory. Let’s start with a default layout _layouts/default.html to apply to all our existing pages:

---
---

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>My blog</title>
  </head>
  <body>
    <div style="max-width: 800px; margin: 20px auto">
      <h1><a href="/">My blog</a></h1>

      {{ content }}

    </div>
  </body>
</html>

We now have a slightly better design and the blog title in every page, linking to the blog index. The contents of every page will be replacing that {{ content }}. And if you try to browse the generated site… you’ll see that nothing changed and the layout isn’t being used.

To make every page use this new layout, we have to specify it in their front matters. So your index will have to change into:

---
layout: default
---

{% for post in site.posts %}
  <h2><a href="{{ post.url }}">{{ post.title }}</a></h2>
  {{ post.excerpt }}
{% endfor %}

And, likewise, the front matter of your post will also need to be updated:

---
layout: default
title: Hello World!
---

Welcome to my new **blog**!

You should now be able to see the changes in the generated site. The design is still not great, but styling webpages is out of scope of this tutorial. Our blog post, however, still looks incomplete, without its title and publication date. We can fix that by introducing a new layout, just for blog posts. Fortunately, specific layouts can reuse more generic ones, to avoid duplicating a lot of code. Here’s how a _layouts/post.html could look like:

---
layout: default
---

<h2>{{ page.title }}</h2>
<p>{{ page.date | date_to_string }}</p>
{{ content }}

Notice that by setting a layout to a layout we avoid a lot of code repetition. Now if you change the layout in the post file from default into post, you should be able to see the post title and publication date in its page.

Also, you might have noticed the new | date_to_string. The | is used in Liquid to apply the filter specified on the right to the element on the left. So in this example we’re applying the date_to_string filter to post.date, which converts the post publication date into a nicer to read string.

So now we have a blog index, posts and a theme. Things are starting to look better, and you’re now in a position to start adding elements like a sidebar, Google Analytics, Disqus comments and anything else you want. So now let’s finish with some cleanup, to help with future improvements.

Configurations

In our defaut layout we’re hardcoding the name of our blog twice. If we want to add elements like an RSS feed, semantic annotations or others, chances are we’re going to have to hardcode it again. The same applies for other information like blog author, description and social media links.

Fortunately, there is a place to store all this information: the configurations file, which acts like the ultimate front matter of the whole site. So create the _config.yml file in the project root:

name: My blog
author: Ricardo Lopes
twitter: ricardoplopes

Now we can access any of these variables through the site object. We can now change the default layout to something more interesting (and maintainable):

---
---

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>{{ site.name }}</title>
  </head>
  <body>
    <div style="max-width: 800px; margin: 20px auto">
      <h1><a href="/">{{ site.name }}</a></h1>

      {{ content }}

      <hr>
      © {{ site.time | date: '%Y' }} {{ site.author }}.
      <a href="https://twitter.com/{{ site.twitter }}">Follow me on Twitter</a>
    </div>
  </body>
</html>

What’s next

So far we’ve only really scratched the surface on what Jekyll can do for our blog. The current structure should be something like:

_config.yml
_layouts
    default.html
    post.html
_posts
    2015-02-01-hello-world.md
_site
index.html

However, there’s a lot more hacking that can be done. Some examples are building an RSS feed, paginating the index page, getting better URLs, better theming and adding categories and tags. Also, although you can go ahead and upload the generated files to your personal server to get your blog online, it’s still worth to discuss some alternatives to ease that process.

Unfortunately, it all starts to be too much for a single blog post. So expect to see all those examples explained in future tutorials, and don’t forget to subscribe to get them as soon as they’re published. In the meantime, my blog’s source code is open, so you can learn from it and get some ideas through its Github project.

Update: Part 2 and Part 3 now available.

What Windows 8 could have been

Fri, 23 Jan 2015 00:00:00 +0000

Disclaimer: This blog post was first published on the 25th of November of 2012. This means that most of its content might no longer be up-to-date. This was published in my previous blog, which has met an unfortunate end, and is being reposted now as an attempt to resurface some of the most popular posts that have been lost. After the very recent announcement by Microsoft about the new Windows 10, this seems to be an interesting time to bring back this particular post.

This post was supposed to be yet another Windows 8 review but, as I’ve gained experience with the latest Microsoft OS, I saw the potential for something a little more interesting. I’ve been using Windows 8 as the only OS in my main computer since it was officially released by Microsoft, so I might say I have some experience, now, to tell you a thing or two about it that you probably missed in other reviews. I’ve already used Windows, Mac and Linux as my primary OS (and I tend to change it quite frequently), and I find advantages and disadvantages in all of them. I’m pretty “agnostic” in most technology debates, and OSs aren’t an exception, so these thoughts aren’t distorted by fanboy opinions. I didn’t do a simple review not only because the Internet is full of it (really, I’m not even posting any links), but because my continuous usage of this new OS kept bugging me more and more about very specific details. So I’ll skip the typical suspense and just tell you my quick opinion about it, so I can discuss what I see as the most pressing issue: what Windows 8 could have been.

Firstly, I know many people don’t agree with me, but I actually think Microsoft changed the game with Windows 8 and the Surface. The notion of converging the laptop and tablet experience seems almost intuitive to me. As you might already know, tablets are the latest revolution in computing and are slowly throwing laptops to oblivion as once laptops did to desktop PCs (OK, I know it’s not that simple, but when we look at market shares there’s no doubt the landscape is changing). Tablets are also more portable than the thinnest ultrabooks, have a more intuitive and friendly input, don’t have the dreaded noisy fans, have better communication options and so on (I could go on listing the advantages of tablets over any laptop, but I guess I made my point already). So isn’t it silly that we’re still using them just as consumption devices (read: overpriced toys)? Is the great revolution in computing really only worth it for browsing Facebook and throwing some birds at evil pigs?

The answer, of course, is no. If these devices are so much better than their ancestors, then we must be able to switch and leave the old laptops behind. Some power users might not be able to do it, but that’s exactly what happened in the transition from desktop PCs to laptops anyway. Apple has been very careful in this matter: they have slowly improved iOS to meet more demands and updated Mac OS to be more iOS-like. They’re basically doing baby steps for converging the two OSs, cautious not to make a very risky move. I’m still very curious about what the conclusion of that convergence might look like. Microsoft, on the other hand, went all-in about the matter and evolved from a pure PC OS to a completely hybrid, both tablet-friendly and “traditional”.

In my opinion, and this might be controversial, Microsoft decided, for a change, to be the innovator and to push to the market a concept that is probably ahead of its time. They were so proud of their concept, they even build their own tablet/laptop hybrid just so they could show the full picture of their envisioned game changer product. This move is as refreshing as it is unexpected. So, as you can see by now, Windows 8 and the tablet/laptop hybrids approach have really caught my eye and promise to be a welcome revolution brought by an unexpected player.

So… what could possibly go wrong? Here are some of the details I’ve been struggling with lately.

Affordances

In interaction design, affordance is the quality of an element to display to a user how it is supposed to be used. Imagine a door with no signs and with equal handles on both sides. That’s an example of poor affordance, since you don’t know if you’re supposed to push it or pull it. A door with better affordance would have the handle only in the side where you needed to pull and probably a sign in each side displaying the correct action.

The Modern UI design aka Windows Store design aka Metro style design is, in my opinion, a nice UI that makes Windows Phone 7 and 8 look much more fresh and lively than the big guys iOS and Android. However, I’m not so sure about it in tablets and specially on regular PCs. One of its major advantages, the flat UI that strips down the unnecessary and focuses on content, is also one of its major flaws, because you’re also losing some important elements that weren’t just there for decoration. Don’t agree?

This image is showing two different elements from the same screen (not in their actual position, just next to each other in this picture for comparison). The one on the top is just a title with no action on click, and the one in the bottom is a button to a settings page (although we’re already in a settings panel, and another button in the same panel already points us to the Control Panel, another settings tool).

I could add more examples, but I hope you got the idea. Cleaning the UI is a very good idea, but you must do it with caution. “Make it as simple as possible, but not simpler”.

The best of two worlds?

One of Windows 8′s most ambitious promises is the convergence of desktop and tablet experiences. As I said, I’m a big fan of that concept and I believe that’s a trend to follow. But a concept is one thing, execution is another. My ideal use case would be something like:

I pick my tablet for working on the go. Since I don’t have paperwork nor a cumbersome laptop to carry, travelling with everything I need for work (just a tablet) is easier than ever. In those free times I can just turn on my tablet and browse my favourite websites, check my email and so on. When I get to my office I just link the Bluetooth keyboard and mouse and the HDMI display, start the traditional environment and fire up the MS Office suite, the IDE, etc.

Next day I decide to do some work at a coffee shop, so I just bring the tablet and a keyboard (a Surface keyboard would add no bulk to the pack, and a keyboard dock like what we see in Asus’s offerings would, in a worst case scenario, make me feel like I’m carrying a thin netbook).

When going to meetings, presentations or others I simply carry the tablet and use it with the onscreen keyboard, since I won’t be typing long sequences of text. In between, I think about my laptop and wonder when was the last time I used that heavy, noisy and awkward machine.

This use case is what I think when I see new hybrids in the market running full-blown OSs in a tablet form and when I hear Microsoft state how Windows 8 promises to deliver the best of both worlds. Unfortunately, that’s not what’s happening.

Firstly, Windows RT, a dumbed-down version of Windows 8 developed to run on ARM processors, miserably fails to live up to that promise, as you won’t be able to run legacy apps in it (read: you can’t install typical desktop applications, like the ones you absolutely must have for your job).

Also, when using a tablet with no mouse or keyboard, this ideal vision means not interacting with the traditional desktop and its windows, as they’re not the most touch friendly interfaces you’ll see. So it’s too bad that actions such as file management and configuring some settings have to be done in the desktop environment. I can’t help but think that Microsoft’s tight schedule for Windows 8 left many holes in the OS, and this lack of support for the continuous use of the tablet environment shows many of them.

These holes in the OS aren’t an exclusive of the tablet interface. As an example, in the desktop mode hitting the Networks taskbar icon brings a panel in line with the new design, but hitting the Sound or Power taskbar icons still brings the old style popup. Also, when using the desktop environment, the Charms bar has close to no functionality (but it still shows up when hitting non-configurable hot corners). There are many more rough corners that still need to be polished if this is to look like a finished product.

Finally, the integration of these two poorly-implemented worlds is nothing but disappointment. If you like a Metro application, you can’t run it as a window in the desktop environment (nor can you go full-screen in most desktop applications). If you open a file in one of the environments, the only way to move it to the other environment is to open it again manually using another application. The only way to see two Metro apps at once (or any Metro app while using the desktop interface) is by snapping one of them to the left or right of the screen. However, you have no control of the size of each app, and you can’t have two documents side by side, since the distributed space isn’t 50%-50%, but more like 75%-25%.

Apps, apps, apps

At the end of the day, what really matters is the applications. That’s why most users prefer Mac OS or Linux over Windows, but when you look at market shares that’s not what it looks like. However, with this new OS Microsoft seems to be trying to get rid of its huge market advantage.

As I’ve stated before, there’s not much integration between the two different environments of Windows 8. So, while you have a huge collection of legacy apps in the traditional one, you’ll feel the emptiness of options in the newest one. If desktop apps could integrate with the tablet mode this wouldn’t be such a big issue, because we’d have something to cover that emptiness while the new apps ecosystem was being developed. But we don’t, so if you’re like me you’ll probably want to make use of that awesome new environment, but will find no reason for it and eventually give up.

Things get pretty ugly if you consider Windows RT instead of 8, because it also has a desktop mode but lacks the support for legacy apps. So yes, the market leader that has built its success on top of its huge apps ecosystem has just started a new one from scratch and one of the versions of its newest OS doesn’t even support the old one.

Also, if this new desktop/tablet mix in the same OS serves as a “bridge” from the old ecosystem to the new, I can’t figure a simple reason for Microsoft to launch the Surface with RT before launching the Surface with 8. They basically launched a device with virtually no ecosystem and waited to later launch a similar device with support for all Windows applications. That’s like trying to build a whole village in a desert island and only later building a bridge to it. I wonder how much has Microsoft lost with this new, unpopulated village already.

Finally, if we look to the Metro apps that come with the OS, there’s also some aspects that make me think this could have gone a totally different way. The built-in calendar app couldn’t import all calendars from my Google account (in fact, it could only import the personal one), so it’s useless for me. The messaging app can’t send new messages if I’m set as invisible, and can’t get them from contacts that show up as offline, so this one’s also useless for me. Thanks to the poor integration between the two environments, I can’t get a mini player of the XBox Music app (only a snapped panel from top to bottom that shrinks my horizontal desktop area). These are just some examples of the poor job that leave us early adopters with little incentive to keep trying the new environment.

To sum up

Please don’t get me wrong: I love Windows 8′s concept and I share (more or less) Microsoft’s vision for the future of computers. If this was the typical review, I’d spend more time highlighting some good implementations and how I believe it’s the right direction. I might even have recommended the upgrade. However, my goal is to highlight what I find poorly implemented in such a great concept.

Thanks to this whole notebook/tablet hybrid concept, I’ve started to look at the latest ultrabooks as kind of obsolete devices. They don’t have touch screens, it’s impossible to use them while walking without looking awkward, and so forth. The same goes for all Apple’s notebook options (that’s probably the reason why most Apple fans don’t agree with this vision). However, after quite some time with Windows 8, I fear we don’t have a strong alternative yet. Yes, this is definitely an important step in that direction, but it’s still looking too immature, for now. Windows 8 seems to have suffered a lot from its tight schedule and, thanks to this incomplete effort, we now have a vision of what’s to come, but are left with a poor demo of it.

All in all, this could have been a new revolution in the way we use our computers. As it stands, it’s nothing but a glimpse of what that revolution might look like. Maybe they’ll get it right in an hypothetical Windows 9. After all, Microsoft is known for releasing great versions of Windows after disappointing ones, and disappointing versions after great ones (and so far, this pattern seems unchanged). Or maybe Apple will get it right first.

Ricardo Lopes

The most amazing animal in the world

Heat

Cold

Tun

Pressure

Radiation

Space

So let’s recap

Setting up a hacker's blog with Jekyll, part 3

RSS feed

Styling with SASS

Categories

Tags

Summary

A layman's guide to good passwords online

Use long, not cryptic passwords

Don’t use common passwords

Don’t repeat passwords

I’m lost, summary please

Setting up a hacker's blog with Jekyll, part 2

Better URLs

Paginating our list of posts

Includes

Comments with Disqus

What’s next

What if we found life on Mars?

The Fermi Paradox

Where is everybody?

Theory 1: They’re there, we just haven’t heard from them

Theory 2: There are no higher civilisations in existence

Back to Mars, what can we learn?

Avoiding the “think outside the box” trap

More Semantic Web for Ruby: mastering your data

Importing RDF data to Ruby

Exporting relational data from Ruby to semantic data in RDF

To sum up

Developing for the Semantic Web with Ruby on Rails, the 2012 guide

Building the ontology and fetching relevant data

Putting the Semantic Web in Ruby on Rails

Querying the graph

Leveling up to a Triple Store

To sum up

Setting up a hacker's blog with Jekyll

Setting up Jekyll

Index

Posts

Layouts

Configurations

What’s next

What Windows 8 could have been

Affordances

The best of two worlds?

Apps, apps, apps

To sum up