• Debrief of Brussels Ember.js Meetup #3

    I’m back in Belgium for a couple of days and I used the opportunity to set up another Brussels Ember.js meetup. Since I moved to Boston with Hstry three months ago, I haven’t had the occasion to organize one and the last one was in December. Since the plan for Hstry is to stay in Boston for a longer period, I expressed the need to find someone who is willing to take care of the organization of the meetup. I think that it would be a great thing because I could feel the level of engagement of the members during the meetup has risen since we did the first one back in October last year. Also, the participants have been getting more and more familiar with the framework so the level of the talks and discussions has gone up too.

    Logo of the Brussels Ember.js meetup

    Ember.js Belgium

    Below are the slides that I presented at the meetup. I did one talk about integration testing in Ember.js based on my experiences from working on the Hstry application (the code for the demo can be found on GitHub). Then I did a lightning talk called “How to call A from B in Ember.js”. It was basically a copy of a talk I had seen during a Boston Ember.js meetup by Ben Donaldson.

  • Why Hstry is going HTML5 and not native

    Go native? or go HTML5? One of the most important decisions to make for a lot of tech startups. A lot has been written and a lot of different opinions are available about this choice. In the end, however, there’s no single answer that works for everyone. Each startup has to look at its own case, and make a decision based on what requirements it finds most important. At Hstry we chose to go for a HTML5 web application, the main motivation being the openness and accessibility of the web.

    Read more

  • A sorted_by custom matcher for RSpec

    I recently had to test that the result of an Active Record query was sorted by a particular attribute of the model. In this case, the model implemented the acts_as_list mixin and the result set had to be sorted by the position attribute. I came up with the following RSpec custom matcher.:

    RSpec::Matchers.define :be_sorted_by do |attr|
      match do |records|
        a = records.map{ |record| record.send(attr) }
        a.sort == a
      end
    end

    One limitation of this solution is that it only works for ascending order but it can be extended by supplying an extra argument for the direction.

    It can then be used in an RSpec example as follows:

    subject { ... }
    it "should be sorted" do
      should be_sorted_by(:position)
    end
  • I became a member of the Pioneer Club of Bitcoin Vikings

    Last week, as a new payment method offered by Mobile Vikings, I topped up my mobile credit with Bitcoin. This morning I got a letter (in Dutch) saying that I was one of the first people who used this new payment method and became an official member of the Pioneer Club of Bitcoin Vikings. To complete the playful action by the mobile operator, the letter was accompanied by a fitting badge. I say kudos to Mobile Vikings and I doubt this is something you can expect from a traditional mobile operator.

    Pioneer Club of Bitcoin Vikings by Mobile Vikings

    I’m now a member of the Pioneer Club of Bitcoin Vikings.

  • Loading animations with asynchronous models in Ember.js

    People don’t like waiting. Unfortunately, latency is an inherent part of our world so waiting is something that you have to consider when you’re designing an interface for a web application. However, people tend to be more tolerant of waiting if they know that something is going on. Therefore, it is very important to show loading animations to indicate that the application is still responsive and is doing some computations or communication behind the curtains.

    In Ember.js, there’s a solution to do this that works for models that are loaded in the model hook of a Route. However, a different solution is required if your application contains asynchronously loaded models. I presented this at December’s Brussels Ember.js meetup.

    Read more

  • Elegantly preload background images with SASS

    To display icons, I mainly use SVG’s as background images. This works fine because vector images look crisp on all screens, the SVG format is easily compressible using gzip (it’s XML after all) and using Modernizr I can provide PNGs as fallback if SVG background images are not supported. However, sometimes we need to preload an image to prevent a lag when it is used later than at page load. This post describes a way to do this elegantly using SASS.

    The problem

    In some cases there is the need for preloading background images. For instance, on our Hstry platform we have multiple choice quiz questions. As long as the question is not correct, the tick is blue. When the answer is correct, the tick becomes green. So in SASS the code is something like this:

    .quiz-question {
      .tick-box { background-image: url('icon-tick-blue.svg'); }
      &.correct .tick-box { background-image: url('icon-tick-green.svg'); }
    }

    The problem is that when the page is loaded, only the icon-tick-blue.svg image is loaded because the CSS rule corresponding to the green tick is not matched. This is a browser optimisation and it makes total sense. However, what happens is that there is a lag before the green tick is shown when the user answers the question correctly because it needs to load the image from the server.

    Preload images with CSS

    A trick to preload images is by setting the images as content of a pseudo-element on the body element:

    body:before {
      display: none;
      // both images are now loaded when the page loads
      content: url('icon-tick-blue.svg') url('icon-tick-green.svg');
    }

    We don’t want to add each image that we want to preload manually. Instead, every time we use a background image, we want it to be automatically added to this list. This is possible using SASS lists.

    The solution in SASS

    First we define a mixin background-image-svg that will:

    • set an SVG background image
    • provide a PNG fallback
    • add the SVG image to the list of preloaded images
    @mixin background-image-svg($img-name, $png-directory: "png-fallback/") {
      background-image: image-url($img-name + ".svg");
      // This function will add the image to the list of images to preload.
      // The function is defined below.
      $tmp: preload-image($img-name + ".svg");
      // no-svg is defined by Modernizr
      .no-svg & { background-image: image-url($png-directory + $img-name + ".png"); }
    }

    We replace the code above as follows:

    .quiz-question {
      .tick-box { @include background-image-svg('icon-tick-blue'); }
      &.correct .tick-box { @include background-image-svg('icon-tick-green'); }
    }

    Then we have to define the SASS function preload-image.

    $preloaded-images: null;
    @function preload-image($image-url) {
      $preloaded-images: $preloaded-images url($image-url);
      @return $preloaded-images;
    }

    We define a list $preloaded-images which is null initially. Every time the function is called, it appends the string url($image-url) to this list. The return call is not necessary for our purpose but is required by the SASS language.

    As the SASS processor goes through the stylesheets, it builds up this $preloaded-images list every time the background-image-svg mixin is included. At the end, it will have generated this long string url(...) url(...) ... url(...). All we have to do now is output the string as the content of the pseudo-element on body!

    body:before {                                                                                           
      display: none;                                                                                        
      content: $preloaded-images;                                                                           
    }

    And we’re done! Using SASS mixins, functions and lists, we can automatically preload an image every time it is included as a background image.

  • Topped up my mobile credit with Bitcoin

    Mobile Vikings is a mobile provider on the Belgian market and it made news today by accepting Bitcoin as a way of topping up your pre-paid card. I happen to be on Mobile Vikings (their price for mobile data is advantageous) and I happened to run out of credit this morning. Also, I’m an owner of and believer in Bitcoin so after the Bitcoin pizza of two weeks ago, I decided to try it out.

    Read more

  • Ordering pizza with Bitcoin

    I’m sure everyone has heard about Bitcoins. It’s been in the mainstream news back in May, when its value reached records heights (at that time). Now it’s all over the news again after it has reached $1000 and the bubble doesn’t seem to burst. Everyone has an opinion about it but I truly believe that it has a future in the world economy. As a first step towards proving that, I ordered my first Bitcoin pizza yesterday.

    The website pizza.be offers the possibility to pay with Bitcoin. When you pay, you have to transfer the amount to a given address, either by scanning a QR-code or by using your Bitcoin client. They generate a new address for each order so you don’t even need to give a payment reference. You can track the confirmation of your payment via blockchain.info. After a few minutes, the payment was confirmed and a little while later the pizza’s arrived! It’s great in the sense that no intermediary payment system, like PayPal, Visa or a bank, was necessary to process the payment. It’s directly between you and pizza.be. Promising!

  • ISO8601 for negative years in Ruby and Javascript

    Today, when working on the product we are making at Hstry, I was integrating a timeline about the history of medicine during the Roman times. This part of history takes place before Christ so I was dealing with negative times (years AD or BC). I came across a difference between the way the ISO8601 standard is implemented in Ruby and Javascript.

    Both Ruby and Javascript understand ISO8601, right?

    Yes, but not in the same way. My case is as follows. On the server-side, a Ruby DateTime is serialized as a string with the date in ISO8601 format.

    # Gives "2013-11-01T17:00:00+00:00"
    DateTime::parse("5th of November 2013 at 5pm").iso8601

    This string is transported across the wire and is parsed client-side into a Javascript Date object.

    // Gives a Date {Fri Nov 01 2013 18:00:00 GMT+0100 (CET)} object
    new Date("2013-11-01T17:00:00+00:00")

    So this works fine. What if we try to do it with a date from the Roman time?

    # Gives "-0166-11-01T17:00:00+00:00"
    DateTime::parse("5th of November 167 BC at 5pm").iso8601

    Cool! So Ruby correctly serialized the negative year. Now we parse this date on the client.

    // Gives a Date {Invalid Date} object
    new Date("-0166-11-01T17:00:00+00:00")

    So our date is not correctly parsed. It turns out that for Javascript to understand an ISO8601 with a negative year, you need to add two leading zeros before the year. This is documented in the ECMAScript specification.

    // Gives a Date {Sat Nov 01 -0166 18:00:00 GMT+0100 (LMT)} object
    new Date("-000166-11-01T17:00:00+00:00")

    The specification further says

    To represent years before 0 or after 9999, ISO 8601 permits the expansion of the year representation, but only by prior agreement between the sender and the receiver.

    In this case, I made the sender agree with the receiver by adding the leading zeros on the server. And it works now!

    # Use ISO8601 expanded notation for negative years, i.e. use 2 leading zeros
    # '-0167-01-01T00:01:06.000Z' becomes '-000167-01-01T00:01:06.000Z'
    def serialize_date(date)
      if date.year < 0
        a = date.iso8601.split('-')
        a[1] = "00#{a[1]}"
        a.join('-')
      else
        date.iso8601
      end
    end
  • Debrief for Meetup #1 Ember.js Brussels

    Yesterday I organised the very first Ember.js Brussels Meetup. Thanks to the Betagroup, we got a room at the ICAB to host the meetup. For a first meetup, I can say that it was a success. Fuelled by some beer, the participants were very engaged and happy to show what they’d been working on. I think everyone had a good time and it was a step towards building a local community of Ember.js users in Belgium. The next meetup will be in about a month, around the end of November.

    Below are the slides for my presentation. Also, you can find the presentation as well as the source code for the examples on GitHub: YoranBrondsema/emberjs-meetup-brussels.