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.
String literals immutability is one of the new features you can find in Ruby 2.3. But, what does this imply?
- Same value literals points to the same object
- Better performance
- Thread safety
Currently string immutability is included as opt-in, being the first step of a multi stage rollout and if it works well it will be enabled by default on Ruby 3.0. So it still can end up being just an experiment. Time will tell.
You can follow frozen string literals feature status in Ruby issue tracker Feature #11473: Immutable String literal in Ruby 3
The Ember object model provides support for dynamically resolving properties in an object. In other words, if we request the value of a property from an Ember object, this object has the chance to respond to the request even if the property doesn’t exist.
This can easily be implemented using the handler
As you already may know by now, Ember controllers are singleton, this can be handy under some circumstances for example for keeping global state, but by now, most of the Ember community is moving forward to other solutions (like
Ember.Service) to avoid certain problems that arise due to their singleton condition.
When I began studying Ruby, one of the things that most caught my attention was the length of time between having an idea and being able to validate the first step; if this were an article about TDD, I would refer to this as the speed with which we receive feedback. The feedback loop is very short.
What’s the authentication agent forwarding for?
Let’s start showing what
man ssh says about it:
-AEnables forwarding of the authentication agent connection. This can also be specified on a per-host basis in a configuration file. Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent’s UNIX-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent.
It tries to solve the following problem:
Laptop -> Server A -> Server B
User wants to connect to Server A and from Server A to Server B forwarding all authentication requests to Laptop.