A bit over a year ago, I wrote this article about continuous learning and discussed our Technical Thursdays. If you haven’t read it yet, I encourage you to do so! There, I talked about the importance of having a great team that is passionate and curious about learning.
A very common problem people have while testing an ember application that uses the wonderful ember-wormhole addon is making the page objects to play nicely with it. In this blog post I’ll try to cover some of the problems and solutions regarding this.
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 😉
In this post I want to share with you a set of addons that I regularly use to aid me when testing an Ember application or addon which I think should be in every Ember developer toolbox.
The idea is to give you a hint of what problems they solve and how they work.
This is the list of addons we’ll go through
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.
TC39 has a proposal for adding async functions to ECMAScript. This new language feature is very useful for working with the promise pattern that is heavily used in Ember’s acceptance tests.
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.
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.
In previous posts, we demonstrated how to build an API application with Rails 5. Specifically, we covered integration with Backbone and Ember. At the time of writing of those posts, the only way to try out the all-new Rails API mode was by taking the code from the master branch, since Rails 5 had not yet been released. However, Rails-5-0-beta1 is available now, so you can easily start to build applications using Rails in its new API-flavored mode.
This Rails release also includes some changes related to the API mode that materialized in Rails a few weeks ago. The purpose of those changes is to improve error responses to JSON requests in Rails. We initiated a discussion about how Rails should handle and return responses in the proper format in the case of an error in processing a request, and then we finally came up with the necessary code changes in Rails.
Life doesn’t stand still.
Neither can the code that we write. In order to keep up with today’s near-frantic pace of change, we need to make every effort to write code that’s as loose–as flexible–as possible. Otherwise we may find our code quickly becoming outdated, or too brittle to fix, and may ultimately be left behind in the mad dash toward the future.
This quote, taken from the highly regarded “The Pragmatic Programmer” book, depicts beautifully an ongoing, everyday challenge software developers face: writing flexible enough code which smoothly adapts to change.
What Andy Hunt and Dave Thomas are telling us is that software we develop, just as much as the world we live in, resides in a constant state of evolution. Despite our best efforts, requirements will change, and we’ll be better off if our solution is prepared for it.