We love open source and we invest in continuous learning. We give back our knowledge to the community.

A Review of Server Side Rendering in Javascript Frameworks

javascript Comments

The Javascript ecosystem is always moving fast, so it’s important to keep track of how everything is progressing, especially when it comes to tools and frameworks. The people at This.Dot produces an amazing series of webinars, called This.Javascript, that discuss the latest on major Javascript frameworks and tools. This post is the first in a series of articles about topics that caught my attention after watching the latest episode.

Let’s now discuss the current state of Server Side Rendering (SSR) in Javascript frameworks. Each of the big contenders in the ecosystem made remarkable progress in their particular SSR solutions in 2017. Moreover, the existing solutions are still improving while more and more people are using them for real stuff.

What the Tag? Episode 1 - the Document Object

html Comments

Twenty three years ago, as I was learning to walk, something more important was going on, something that has been part of the technology we use every day, something that pretty much brought us to where we are today (in terms of web development): HTML’s birth!

In this series we’ll dig into the DNA of modern HTML (or as the people at WHATWG call it, The Living Standard). We will identify and explore things that are unusual or unknown (just because nobody was told about them).

Better Tests Feedback With Ember-qunit-nice-errors

ember Comments

As any Ember developer probably knows by now, the error messages shown by failing asserts are far from ideal. Getting a failed, expected argument to be truthy, was: false followed by a stack trace that points to lines on the generated test file (one file with all your compiled tests), can be pretty disappointing when you want to be able to get quick feedback from your tests.

One of the best practices when using QUnit is to always include an error message that explains what’s the purpose of the assertion. This is a good practice but in reality it falls short: developers tend to be lazy and not include all messages, or sometimes the error message and the assertion are one to one equivalent, e.g.: assert.equal(page.title, 'hello world', "Page title is hello world"); Having better errors by default can help in those cases.

As part of our Technical Thursdays’ last cycle, we set out to improve this, looking to both enhance our tests and learn more about ember-cli and its addons.

The result was ember-qunit-nice-errors, a just add water and mix kinda addon 😉

Behavior Changes in Ruby 2.4

Comments

The first preview version of Ruby 2.4 was released a few days ago. This particular release includes a bunch of new features. Moreover, it introduces some fixes and changes that are not entirely backward compatible. Thus, we need to pay close attention to these differences in this new version of Ruby.

In this post, we’ll focus on some remarkable changes in behavior, so as to better understand how our applications could be affected or improved once we upgrade to Ruby 2.4.

Our Onboarding Process

Comments

We have a saying on one of our office walls that reads, “A company is only as good as the people it keeps”. Not only do we find that to be true, but we consider it to be of the utmost importance, and that’s why we try hard to have only the best.

With this in mind, we don’t limit ourselves to candidates with professional experience in Ruby when hiring. We really don’t care what programming language you have a background in, be it Java, PHP, .NET, and so on. What matters to us is that you’re talented and a good fit within our company culture.

In order to further assist you in becoming one of the best, we have outlined an onboarding process enabling you to learn everything you need to know before becoming a team member on a client project.

Upgrading to Ruby on Rails 5.0

Comments

Edit: In this post we’re upgrading an application to Rails 5.0.0.beta1.1 and Rails 5.0.0.beta2 is now already released. Throughout this post we show some patches we needed to apply to Rails to get our application working. Those patches are now included as part of Rails 5.0.0.beta2. We still consider this post worth reading to get an interesting view of how to upgrade your applications to newer versions of Rails and betas in particular.

In this post, we’re going to upgrade a Rails 4.2.5 application to Rails 5.0.0.beta1.1. If we didn’t already have that version, we would have to first upgrade to Rails 4.2.5 and clean up the possible warnings generated before continuing. A good test suite is recommended - our application has them - but if we didn’t have them, it would be good to have the ability to add a few automated tests that lend us some confidence before jumping into the new Rails 5. Not doing so would confront us with too many risks.