Since this is a breaking change
for Rails application upgrading
to ruby 2.4, Rails 4.2.8 built
a compatibility layer by
adding a config option.
ActiveSupport.to_time_preserves_timezone was added to control how to_time handles timezone offsets.
Here is an example of how application behaves when
to_time_preserves_timezone is set to false.
Recompose
is a toolkit for writing React components using
higher-order components. Recompose allows us
to write
many smaller higher-order components
and
then we compose all those components
together to get the desired component.
It improves both readability and the maintainability
of the code.
HigherOrderComponents
are also written as HOC.
Going forward we will use
HOC to refer to
higher-order components.
Using Recompose in an e-commerce application
We are working on an e-commerce application
and
we need to build payment page.
Here are the modes of payment.
Online
Cash on delivery
Swipe on delivery
We need to render our
React components depending upon
the payment mode selected by the user.
Typically we render components
based on some state.
We will try to refactor the code using the tools
provided by Recompose.
In general, the guiding principle of functional programming
is composition. So here we will assume that the
default payment mechanism is online.
If the payment mode happens to be something else
then we will take care of it by enhancing the existing component.
Recompose has
branch
function which acts like a ternary operator.
The branch function accepts three arguments
and
returns a HOC.
The first argument is a
predicate
which
accepts props as the argument
and
returns a Boolean value.
The second and third arguments are higher-order components.
If the predicate evaluates to true then the left HOC is rendered otherwise the right HOC is rendered.
Here is how branch is implemented.
Notice the question mark in ?HigherOrderComponent.
It means that
the third argument is optional.
If you are familiar with Ramdajs
then
this is similar to
ifElse
in Ramdajs.
renderComponent
takes a component and returns an HOC version of it.
renderNothing
is an HOC which will always render null.
Since the third argument to branch is optional, we do not need to supply it. If we don’t supply the third argument then
that means the original component will be rendered.
So now we can make our code shorter by removing usage of renderNothing.
At this time we are building a condition (like cashOnDeliveryCondition)
for each payment type and then using that condition in compose.
We can put all such conditions in an array and then we can use that array in
compose. Let’s see it in action.
Functional code is all about composing smaller functions together
like lego pieces. It results in better code because functions
are usually smaller in size and do only one thing.
In coming weeks we will see more applications of recompose in the
real world.
In a typical
single-page application (SPA)
server sends JSON data.
Browser receives that JSON data
and builds HTML.
In an isomorphic app,
the server sends a fully-formed HTML
to the browser.
This is typically done for SEO,
performance
and code maintainability.
In an isomorphic app the browser
does not directly deal with the API server.
This is because the API server will render
JSON data and browser needs to have fully formed
HTML. To solve this problem a “proxy server”
is introduced in between the browser and the API server.
In this case the proxy server is powered by Node.js.
Uploading a file in an isomorphic app
Recently,
while working on an isomorphic app,
we needed to upload a file
to the API server.
We couldn’t directly upload from the browser
because we ran into
CORS
issue.
One way to solve CORS issue is to add CORS support
to the API sever. Since we did not have access
to the API server this was not an option.
It means now the file must go through the proxy server.
The problem can be seen as two separate issues.
Uploading the file from the browser to the proxy server.
Uploading the file from the proxy server to the API server.
Implementation
Before we start writing any code,
we need to accept file on proxy server
and
it can be done by using
Multer.
Multer
is a node.js middleware
for handling multipart/form-data.
We need to initialize multer
with
a path where it
will store the uploaded files.
We can do that by adding
the following code
before initializing the node.js server app.
app.set('config',config)// ...other middleware.use(multer({dest:'uploads/'}).any());// add this line
Now
any file uploaded to proxy server
would be stored
in the /uploads directory.
Next we need a function
which uploads a file
from browser
to the node.js server.
// code on clientfunctionuploadImagesToNodeServer(files){constformData=newFormData();map(files,(file,fileName)=>{if(file&&fileinstanceofFile){formData.append(fileName,file);}});superagent.post('/node_server/upload_path').type('form').set(headers).send(data,formData).then(response=>{// handle response});}
Next,
let’s upload
the same file
from the node.js server
to the API server.
To do that,
we need to add
a callback function
to our node.js server
where we are accepting
the POST request for step 1.
// code on node.js serverapp.post('/node_server/upload_path',function(req,res){uploadImagesToApiServer(req);// handle response});functionuploadImagesToApiServer(req){superagent.post('/api_server/upload_path').type('form').set(headers).attach('image',req.files[0].path).then(response=>{// handle response});}
When we deploy Rails applications on kubernetes
it stops existing pods and spins up new ones.
When old pod is terminated by Replicaset,
then active Sidekiq processes are also terminated.
We run our batch jobs using sidekiq and it is possible that
sidekiq jobs might be running when deployment is being performed.
Terminating old pod during deployment can kill the already running jobs.
Solution #1
As per default
pod termination
policy of kubernetes, kubernetes sends command to delete pod with a default grace period of 30 seconds.
At this time kubernetes sends TERM signal.
When the grace period expires, any processes still running in the Pod are killed with SIGKILL.
We can adjust the terminationGracePeriodSeconds timeout as per our need and can change it from
30 seconds to 2 minutes.
However there might be cases where we are not
sure how much time a process takes to gracefully shutdown.
In such cases we should consider using
PreStop hook which is our next solution.
PreStop hook is called immediately before a container is terminated.
It is a blocking call. It means it is synchronous.
It also means that this hook must be completed before
the container is terminated.
Note that unlike solution1 this solution is not time bound.
Kubernetes will wait as long as it takes for PreStop process
to finish. It is never a good idea to have a process which takes more
than a minute to shutdown but in real world there are cases
where more time is needed. Use PreStop for such cases.
We decided to use preStop hook to stop Sidekiq because we had some really long running processes.
Using PreStop hooks in Sidekiq deployment
This is a simple deployment template which terminates
Sidekiq process
when pod is terminated during deployment.
We can confirm that existing Sidekiq jobs are completed
before termination of old pod during the deployment process.
In this way we handle a graceful shutdown of
Sidekiq process. We can apply this technique to other processes
as well.
Now that same HTML div tag can be generated as follows.
tag.div class: 'home'
<div class="home">
</div>
Earlier, the tag type was decided by
the positional argument to the content_tag and tag methods
but now we can just call the required tag type on the tag method
itself.
We can pass the tag body and attributes in the block format as well.
<%= tag.div class: 'home' do %>
Welcome to Home!
<% end %>
<div class="home">
Welcome to Home!
</div>
HTML5 compliant by default
The new tag helper is also HTML 5 compliant by default, such
that it respects HTML5 features such as void elements.
Backward compatibility
The old syntax of content_tag and tag methods
is still supported but might be deprecated and removed
in future versions of Rails.
Prior to Ruby 2.4,
if we were to dup
an Integer,
it would fail
with a TypeError.
>1.dupTypeError:can't dup Fixnum
from (irb):1:in `dup'from(irb):1
This was confusing
because
Integer#dup
is actually implemented.
>Integer.respond_to?:dup=>true
However,
if we were to freeze
an Integer
it would fail silently.
>1.freeze=>1
Ruby 2.4 has now included dup-ability for Integer as well.
>1.dup=>1
In Ruby,
some object types
are immediate variables
and
therefore cannot be duped/cloned.
Yet,
there was no graceful way
of averting the error thrown
by the sanity check
when we attempt to dup/clone them.
So now Integer#dup
functions exactly the way
freeze does –
fail silently
and
return the object itself.
It makes sense
because
nothing about these objects
can be changed in the first place.
We deploy Rails applications on Kubernetes frequently
and
we need to ensure that
deployments do not cause any downtime.
When we used Capistrano to manage deployments
it was much easier since
it has provision to restart services in the rolling fashion.
Kubernetes restarts pods directly
and
any process already running on the pod is terminated.
So on rolling deployments we face downtime
until the new pod is up and running.
Solution
In Kubernetes we have
readiness probes and liveness probes.
Liveness probes take care of keeping pod live
while readiness probe is responsible for keeping pods ready.
This is what Kubernetes documentation has to say about
when to use readiness probes.
Sometimes, applications are temporarily unable to serve traffic. For example, an application might need to load large data or configuration files during startup. In such cases, you don’t want to kill the application, but you don’t want to send it requests either. Kubernetes provides readiness probes to detect and mitigate these situations. A pod with containers reporting that they are not ready does not receive traffic through Kubernetes Services.
It means
new traffic should not be routed to
those pods which are currently running but
are not ready yet.
Using readiness probes in deployment flow
Here is what we are going to do.
We will use readiness probes to deploy our Rails app.
Readiness probes definition has to be specified in pod spec of deployment.
Readiness probe uses health check to detect the pod readiness.
We will create a simple file on our pod with name health_check returning status 200.
This health check runs on arbitrary port 81.
We will expose this port in nginx config running on a pod.
When our application is up on nginx this health_check returns 200.
We will use above fields to configure health check in pod’s spec of deployment.
This is a simple deployment template which will terminate pod on the rolling deployment.
Application may suffer a downtime until the pod is in running state.
Next we will use readiness probe to define that pod is ready to accept the application traffic.
We will add the following block in deployment manifest.
In above rediness probe definition httpGet checks the health check.
Health-check queries application on the file health_check printing 200 when accessed over port 81.
We will poll it for each 5 seconds with the field periodSeconds.
We will mark pod as ready only if we get a successful health_check count for 3 times.
Similarly, we will mark it as a failure if we get failureThreshold twice.
This can be adjusted as per application need.
This helps deployment to determine if the pod is in ready status or not.
With readiness probes for rolling updates, we will use maxUnavailable and maxSurge in deployment strategy.
As per Kubernetes documentation.
maxUnavailable is a field that specifies the maximum number of Pods
that can be unavailable during the update process.
The value can be an absolute number (e.g. 5) or a percentage of desired Pods (e.g. 10%).
The absolute number is calculated from percentage by rounding down.
This can not be 0.
and
maxSurge is field that specifies
The maximum number of Pods
that can be created above the desired number of Pods.
Value can be an absolute number (e.g. 5) or
a percentage of desired Pods (e.g. 10%).
This cannot be 0 if MaxUnavailable is 0.
The absolute number is calculated from percentage by rounding up.
By default, a value of 25% is used.
Now we will update our deployment manifests with
two replicas and the rolling update strategy by specifying the following parameters.
After the deployment is configured we can check the pods and how they are restarted.
We can also access the application to check if we face any down time.
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
test-staging-web-372228001-t85d4 1/1 Running 0 1d
test-staging-web-372424609-1fpqg 0/1 Running 0 50s
We can see above that only one pod is re-created at the time
and
one of the old pod is serving the application traffic.
Also, new pod is running but not ready as it has not yet passed the readiness probe condition.
After sometime when the new pod is in ready state,
old pod is re-created and traffic is served by the new pod.
In this way, our application does not suffer any down-time and
we can confidently do deployments even at peak hours.
The
ActiveSupport::TimeZone
class serves as wrapper around
TZInfo::TimeZone
class.
It limits the set of zones provided by TZInfo
to smaller meaningful subset
and
returns zones with friendly names.
For example, TZInfo gem returns “America/New_York” whereas Active Support returns “Eastern Time (US & Canada)”.
In Rails 5.0,
the country_zones method returns empty
for some countries.
This is because
ActiveSupport::TimeZone::MAPPING
supports only a
limited number of timezone names.
>>ActiveSupport::TimeZone.country_zones('SV')// El Salvador
=> []
Rails 5.1
fixed this
issue.
So now if the country is not found in the MAPPING hash
then a new ActiveSupport::TimeZone instance
for the country is returned.
>>ActiveSupport::TimeZone.country_zones('SV')// El Salvador
=> [#<ActiveSupport::TimeZone:0x007ff0dab83080 @name="America/El_Salvador", @utc_offset=nil, @tzinfo=#<TZInfo::DataTimezone: America/El_Salvador>>]
What is the differnece between type and type alias.
Elm FAQ has
an answer
to this question. However I could not fully understand the answer.
This is my attempt in explaining it.
What is type
In Elm everything has a type.
Fire up elm-repl
and
you will see
4 is a
number
and
“hello” is a String.
>44:number>"hello""hello":String
Let’s assume that we are working with users records and we have
following attributes of those users.
Name
Age
Status (Active or Inactive)
It’s pretty clear
that “Name” should be of type “String”
and
“Age” should be of type “number”.
Let’s think about a moment what is the type of “Status”.
What is “Active” and “Inactive” in terms of type.
Active and Inactive are two valid values of Status.
In other programming languages
we might represent Status as an enum.
In Elm we need to create a new type.
And that can be done as shown here.
typeStatus=Active|Inactive
Second thing we are doing is that we are stating that
the valid values for this new type are
Active and Inactive.
When I discussed this code with my team members
they asked me to show where is
Active and Inactive defined.
Good question.
The simple answer is that
they are not defined anywhere.
They do not
need to be defined. What needs definition is the new type that is being
created.
What makes understanding it a bit hard
for people coming from
Ruby, Java
and such background is that
these people (including me) are looking at
Active and
Inactive
as a class or a constant
which is not the right way to look at.
Active and Inactive are the valid values for type Status.
We can solve this by pasting following code in repl.
typeStatus=Active|Inactive
Now we can run the same code again. This time no error.
>ActiveActive:Repl.Status
What is type alias
Let’s see a simple application
which just prints name and age
of a single user.
Here
is the code. I’m posting screenshot of the same below with certain
part highlighted.
As you can see { name : String, age : Int }
is repeated at four different places.
In a bigger application
it might get repeated more often.
This is what type alias does.
It removes repetition.
It removes verbosity.
As the name suggests this is just an alias.
Note that type creates
a new type whereas type alias is literally saving keystrokes.
type alias
does not create a new type.
Now if you read the FAQ answer
again then hopefully
it will make morse sense now.
Now let’s think about what the
type annotation
(rubyist think of it as method signature )
of function getUserStatus
might look like.
It takes username as input and
returns user record.
So the type annotation
might look like
getUserStatus:String->Status
This works.
However the issue is that
String is not expressive enough.
It can be made more expressive if the
signature were
getUserStatus:Username->Status
Now that we know about type alias
all we need to do is
typealiasUsername=String
This makes code more expressive.
No recursion with type alias
An example of where we might need recursion is
while designing commenting system.
A comment can have sub-comments.
However
since type alias is just a substituation
and
recursion does not work with
it.
The main point here is that since we used
type alias, function getUserAge works for both
UserInfo as well as Coach.
It would be a stretch to say
that this sounds like
“duck typing in Elm” but it comes pretty close.
Yes Elm is staticly typed language and it enforces type.
However the point here is the type alias is not exactly
a type.
So why did this code work.
It worked because of Elm’s support for
pattern matching
for records.
As mentioned earlier type alias is just a shortcut for typing
the verbose version.
So let’s expand the type annotation of
getUserAge.
If we were not using type alias UserInfo then
it might have looked like as shown below.
getUserAge:{name:String,age:Int}->Int
Here the argument is a record.
Here is
official guide on Records.
While dealing with records
Elm looks at the argument
and if that argument is a record
and
has all the matching attributes
then Elm will not complain because of its support
for
pattern matching.
Since Coach has both name and age attribute
getUserAge charlie works.
You can test it by removing the attribute age from
Coach and then you will see that Compiler will complain.
In summary if we want strict type enforcement then we
should go for type.
If we need something so that we do not need to type
all the attributes all the time and we want pattern
matching then we should go for type alias.
In Ruby,
IPAddr#== method
is used to check whether two IP addresses are equal or not.
Ruby also has IPAddr#<=> method
which is used to compare two IP addresses.
In Ruby 2.3, behavior of these methods was inconsistent.
Let’s see an example.
# Ruby 2.3>>IPAddr.new("1.2.1.3")=="Some ip address"=>IPAddr::InvalidAddressError:invalidaddress
But if the first argument is invalid IP address
and second is valid IP address,
then it would return false.
# Ruby 2.3>>"Some ip address"==IPAddr.new("1.2.1.3")=>false
The <=> method would raise exception in both the cases.
# Ruby 2.3>>"Some ip address"<=>IPAddr.new("1.2.1.3")=>IPAddr::InvalidAddressError:invalidaddress>>IPAddr.new("1.2.1.3")<=>"Some ip address"=>IPAddr::InvalidAddressError:invalidaddress
In Ruby 2.4,
this issue
is fixed
for both the methods
to return the result without raising exception,
if the objects being compared can’t be converted to an IPAddr object.
# Ruby 2.4>>IPAddr.new("1.2.1.3")=="Some ip address"=>false>>"Some ip address"==IPAddr.new("1.2.1.3")=>false>>IPAddr.new("1.2.1.3")<=>"Some ip address"=>nil>>"Some ip address"<=>IPAddr.new("1.2.1.3")=>nil
This might cause some backward compatibility
if our code is expecting the exception
which is no longer raised in Ruby 2.4.
Rails has been dependent on jQuery
for providing the unobtrusive JavaScript helpers
such as
data-remote, data-url
and the Ajax
interactions.
Every Rails application before Rails 5.1
would have the jquery-rails gem included by default.
The jquery-rails gem contains the jquery-ujs
driver which provides all the nice unobtrusive features.
But now JavaScript has progressed well such that we can
write the unobtrusive driver which Rails needs using
just plain vanilla JavaScript.
That’s what has happened for the 5.1 release. The jquery-ujs
driver has been rewritten using just plain JavaScript
as part of a GSoC project by Dangyui Liu.
Now that the unobtrusive JavaScript driver does not depend
on jQuery, new Rails applications also need not depend on jQuery.
The current
jquery-based
approach would still be
available. It’s just that it’s not
part of the default stack.
You will need to manually add the jquery-rails gem
to newly created 5.1 application
and update the application.js to include the jquery-ujs driver.
It’s worth noting that rails-ujs only supports IE 11+.
Visit the Desktop Browser Support
section of Basecamp to see the full list of all the supported browsers.
Browsers support without jQuery
We saw some discussion about which all
browsers are supported without jQuery.
We decided to test it outselves on a plain vanilla CRUD
Rails app.
We tested “adding”, “editing” and “deleting”
of a resource.
We found that all three operations (adding, editing and deleting) to be working in
following cases.
Win 7 - IE 9
Win 7 - IE 10
Win 7 - IE 11
Win 8 - IE 10
Win 8.1 - IE 11
Win 10 - IE 14 Edge
Win 10 - IE 15 Edge
Win 10 - Firefox 53
Win 10 - Chrome 58
Win 10 - Safari 5.1
Mac Siera - Safari 10.1
Mac Sierra - Firefox 53
Mac Sierra - Chrome 58
API change for the event handlers
rails-ujs driver has changed the signature of the event handler functions
to just pass one event object instead of event, data, status and xhr
as in the case of jquery-ujs driver.
Let’s save this template file as myapp-deployment.yml.
We can change the options and environment variables
in above template as per our need.
The environment variables specified here
will be available
to our Rails application.
To apply above template for the first time on Kubernetes,
we will use the following command.
$ kubectl create -f myapp-deployment.yml
Later on, to apply the same template
after modifications such as
change in the Docker image name
or
change in the environment variables,
we will use the following command.
$ kubectl apply -f myapp-deployment.yml
After applying the deployment template,
it will create a pod for our application on Kuberentes.
To see the pods, we use the following command.
$ kubectl get pods
Let’s say that our app is now running
in the pod named myapp-4007005961-1st7s.
To execute a rake task, for e.g. db:migrate on this pod,
we can run the following command.
Similarly, we can execute db:seed rake task as well.
If we already have an automated flow for deployments on Kubernetes,
we can make use of this approach
to programmatically or conditionally
run
any rake task as per the needs.
We faced some issues while using Kubernetes Jobs
to run migration and seed rake tasks.
If the rake task returns a non-zero exit code,
the Kubernetes job keeps spawning pods until the
task command returns a zero exit code.
To get around the issue mentioned above
we needed to unnecessarily implement additional
custom logic
of checking job status
and the status of
all the spawned pods.
Capturing the command’s STDOUT or STDERR was
difficult using Kubernetes job.
Some housekeeping was needed such as manually
terminating the job if it wasn’t successful.
If not done, it will fail to create a Kubernetes job
with the same name, which is bound to occur when we
perform later deployments.
Because of these issues, we choose not to rely on
Kubernetes jobs to solve this problem.
We can transform the values of a hash destructively
(i.e. modify the original hash with new values)
or non-destructively
(i.e. return a new hash instead of modifying the original hash).
Prior to Ruby 2.4,
we need to use
following code
to transform the values of a hash.
Recently
we started
using
prettier
and
rubocop
to automatically
format our code
on git commit.
Here is how
we
got started with
setting up both prettier and rubocop
in our Ruby on Rails applications.
Generate package.json
If you don’t already have a package.json file
then
execute the
following command
to create
a package.json file
with value {}.
echo "{}" > package.json
Install prettier
Now execute following command
to install prettier.
Note that if you send pull request with your changes
and circleCI or such tools run npm install then
downgrade husky to ^0.13.4 and that will solve
the problem.
In Ruby on Rails applications
third party vendor files
are stored in vendor folder
and
we do not
want to format
JavaScript code in those files.
Hence we have applied
the rule to run prettier
only on files residing in app directory.
Here at BigBinary
we store
all JavaScript files using ES6 features
with extension .es6.
Hence we are running such files through
prettier.
Customize this to match with
your application requirements.
Note that “precommit” hook is powered
by
husky.
Read up “husky” documentation to learn about
“prepush” hook and other features.
Commit the change
git add .
git commit -m "Added support for prettier for JavaScript files"
We were thrilled
to see
prettier format our JavaScript code.
We wanted more of it at more places.
We found that
prettier can also format
CSS files.
We changed our code to also
format CSS code. It was an easy change.
All we had to do was change
one line.
Before : "app/**/*.{js,es6,jsx}"
After : "app/**/*.{js,es6,jsx,scss,css}"
Inspired by prettier we welcomed rubocop
Now that
JavaScript
and
CSS
files are covered
we started looking at
other places where we can
get this
productivity gain.
Since we write
a lot of Ruby code we
turned our attention to
rubocop.
It turned out that
“rubocop” already had a feature to automatically
format the code.
Open package.json
and
change lint-staged section to following
The behavior of rubocop
can be controlled by
.rubocop.yml
file.
If you want to get started
with the rubocop file that
Rails uses then just
execute following command
at the root of your
Rails application.
Open the downloaded file and change the TargetRubyVersion value
to match with the ruby version the project is using.
` value
to match with the ruby version the project is using.
Execute rubcop in all ruby files.
bundle install
bundle exec rubocop -a "{app}/**/*.rb"
Code is changed on git commit and not on git add
We notice that
some people were
a bit confused when
git add did not format the code.
Code is formatted when git commit is done.
npm install is important
It’s important to note that
users need to do
npm install
for all this to work.
Otherwise prettier or
rubocop won’t be activated
and they will silently fail.
Full package.json file
After all the changes are done
then
package.json should be like as shown
below.
When we use method_missing then we should also use
respond_to_missing?.
Because of this code becomes verbose since both method_missing and
respond_to_missing? need to move in tandem.
DHH in
the issue
itself provided a good example of this verbosity.
We at BigBinary have used
SimpleDelegator.
However one issue with this is that statically we do not know to what
object the calls are getting delegated to since at run time the
delegator could be anything.
I prefer not having to hijack the inheritance tree for such a simple feature.
Why not delegate method
Delegate
method works.
However here we need to white list all the
methods and in some cases the list can get really long. Following is a
real example from a real project.
Sometimes we just want to delegate all missing methods.
In such cases method delegate_missing_to does the job neatly.
Note that the delegation happens to only public methods of the object being delegated to.
Check out the
pull request
for more details on this.
We deploy our Rails applications on Kubernetes and frequently do rolling deployments.
While performing application deployments on kubernetes cluster, sometimes we need to change the application configuration file.
Changing this application configuration file means we
need to change source code, commit the change and then go through the complete deployment process.
This gets cumbersome for simple changes.
Let’s take the case of wanting to add queue in sidekiq configuration.
We should be able to change configuration and restart the pod instead of modifying the source-code, creating a new image and then performing a new deployment.
This is where Kubernetes’s ConfigMap comes handy.
It allows us to handle configuration files much more efficiently.
Now we will walk you through the process of managing sidekiq configuration file using configmap.
Starting with configmap
First we need to create a configmap.
We can either create it using kubectl create configmap command
or
we can use a yaml template.
We will be using yaml template test-configmap.yml which already has sidekiq configuration.
Rails 5.0 provides
mattr_accessor
to define class level variables
on a per thread basis.
However, the variable
was getting shared with child classes as well.
That meant when a child class changed
value of the variable,
then its effect was seen in the parent class.
