Stack trace or backtrace
is a sequential representation
of the stack of method calls
in a program which gets printed
when an exception is raised.
It is often used
to find out the exact location
in a program
from where the exception was raised.
Before Ruby 2.5
Before Ruby 2.5,
the printed backtrace contained
the exception class and the error message
at the top.
Next line contained where in the program
the exception was raised.
Next we got more lines
which contained cascaded method calls.
$RBENV_VERSION=2.4.0rubydivision_service.rb50division_service.rb:9:in`/': divided by 0 (ZeroDivisionError)
from division_service.rb:9:in `divide'
from division_service.rb:13:in `<main>'
In the printed backtrace above,
the first line shows the location,
error message and the exception class name;
whereas the subsequent lines shows
the caller method names and their locations.
Each line in the backtrace above
is often considered as a stack frame
placed on the call stack.
Most of the times,
a backtrace has so many lines that
it makes it very difficult
to fit the whole backtrace in the visible viewport
of the terminal.
Since the backtrace is printed in top to bottom order
the meaningful information
like error message,
exception class
and the exact location where the exception was raised
is displayed at top of the backtrace.
It means developers
often need to scroll to the top
in the terminal window
to find out what went wrong.
After Ruby 2.5
Over 4 years ago an
issue
was created to make printing of backtrace
in reverse order configurable.
After much discussion
Nobuyoshi Nakada
made the commit to
print backtrace and error message
in reverse order
only when the error output device (STDERR)
is a TTY (i.e. a terminal).
Message will not be printed in reverse order
if the original STDERR
is attached to something like a File object.
This feature makes
the debugging convenient
when the backtrace size is a quite big
and cannot fit in the terminal window.
We can easily see the error message
without scrolling up now.
Note that,
the Exception#backtrace attribute
still holds an array of stack frames
like before
in the top to bottom order.
So if we rescue the caught exception
and print the backtrace manually
Also,
note that if we assign
STDERR with a File object,
thus making it a non-TTY
puts"STDERR is a TTY? [before]: #{$stderr.tty?}"$stderr=File.new("stderr.log","w")$stderr.sync=trueputs"STDERR is a TTY? [after]: #{$stderr.tty?}"classDivisionServiceattr_reader:a,:bdefinitialize(a,b)@a,@b=a.to_i,b.to_ienddefdivideputsa/bendendDivisionService.new(ARGV[0],ARGV[1]).divide
we can get the old behavior
but the backtrace would be written
to the specified file
and not to STDERR.
$RBENV_VERSION=2.5.0rubydivision_service.rb50STDERRisaTTY?[before]:trueSTDERRisaTTY?[after]:false$catstderr.logdivision_service.rb:14:in`/': divided by 0 (ZeroDivisionError)
from division_service.rb:14:in `divide'
from division_service.rb:18:in `<main>'$
Typically our Rails app has services like unicorn/puma,
sidekiq/delayed-job/resque, Websockets and some dedicated API services.
We had one web service exposed to the world
using load balancer and it was working well.
But as the traffic increased it became necessary
to route traffic based on URLs/path.
However Kubernetes does not supports
this type of load balancing out of the box.
There is work in progress for alb-ingress-controller
to support this
but we could not rely on it for
production usage as it is still in alpha.
The best way to achieve path based routing was to use
ingress controller.
We researched and found that there are different types of ingress
available in k8s world.
We experimented with nginx-ingress and HAProxy and decided to go with HAProxy.
HAProxy has better support for Rails websockets which we needed in the project.
We will walk you through step by step on how to use haproxy ingress in a Rails app.
Configuring Rails app with HAProxy ingress controller
Here is what we are going to do.
Create a Rails app with different services and deployments.
Create tls secret for SSL.
Create HAProxy ingress configmap.
Create HAProxy ingress controller.
Expose ingress with service type LoadBalancer
Setup app DNS with ingress service.
Create different ingress rules specifying path based routing.
Test the path based routing.
Now let’s build Rails application deployment manifest
for services like web(unicorn),background(sidekiq),
Websocket(ruby thin),API(dedicated unicorn).
Here is our web app deployment and service template.
$ kubectl apply -f test-web.yml -f test-background.yml -f test-websocket.yml -f test-api.yml
deployment "test-production-web" created
service "test-production-web" created
deployment "test-production-background" created
service "test-production-background" created
deployment "test-production-websocket" created
service "test-production-websocket" created
deployment "test-production-api" created
service "test-production-api" created
Once our app is deployed and running we should create HAProxy ingress.
Before that let’s create a tls secret with our SSL key and certificate.
This is also used to enable HTTPS for app URL and to terminate it on L7.
$ kubectl apply -f haproxy-configmap.yml -f haproxy-deployment.yml -f haproxy-service.yml
configmap "haproxy-configmap" created
deployment "haproxy-ingress" created
service "haproxy-ingress" created
Once all the resources are running get the LoadBalancer endpoint using.
$ kubectl -ntest get svc haproxy-ingress -o wide
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
haproxy-ingress LoadBalancer 100.67.194.186 a694abcdefghi11e8bc3b0af2eb5c5d8-806901662.us-east-1.elb.amazonaws.com 80:31788/TCP,443:32274/TCP,1936:32157/TCP 2m run=ingress
DNS mapping with application URL
Once we have ELB endpoint of ingress service,
map the DNS with URL like test-rails-app.com.
Ingress Implementation
Now after doing all the hard work it is time to configure
ingress and path based rules.
In our case we want to have following rules.
https://test-rails-app.com requests to be served by test-production-web.
https://test-rails-app.com/websocket requests to be served by test-production-websocket.
https://test-rails-app.com/api requests to be served by test-production-api.
Let’s create a ingress manifest defining all the rules.
To have consistent and symmetrical behaviour
across all the attribute extensions,
it was decided to support specifying
a default value
using default option
for all the module and class attribute macros
as well.
mattr_accessor, mattr_reader and mattr_writer
macros
generate getter and setter methods
at the module level.
Similarly,
cattr_accessor, cattr_reader, and cattr_writer
macros generate getter and setter methods
at the class level.
Before Rails 5.2
Before Rails 5.2,
this is how we would set the default values
for the module
and class attribute accessor macros.
We can still set
a default value
of a module or class attribute accessor
by providing a block.
In this pull request,
support for specifying a default value
using a new default option
has been introduced.
So instead of
cattr_writer:logger{Logger.new(STDOUT)}
or
cattr_writer:loggerself.logger=Logger.new(STDOUT)
or
cattr_writer:logger@@logger=Logger.new(STDOUT)
we can now easily write
cattr_writer:logger,default: Logger.new(STDOUT)
Same applies
to the other attribute accessor macros
like mattr_accessor, mattr_reader,
mattr_writer, cattr_accessor,
and cattr_reader.
Note that,
the old way
of specifying a default value
using the block syntax will work
but will not
be documented anywhere.
Also, note that if we try to set
the default value by both ways
i.e. by providing a block
as well as by specifying a
default option; the value
provided by default option
will always take the precedence.
Let’s say that we have a hash
{ id: 1, name: 'Ruby 2.5', description: 'BigBinary Blog' }
and we
want to select key value pairs having keys name and description.
An index
is used to speed up
the performance of queries
on a database.
Rails
allows us to create
index on a database column
by means of a migration.
By default,
the sort order
for the index
is ascending.
But consider the case
where we are fetching
reports from the database.
And while querying the database,
we always want to get
the latest report.
In this case,
it is efficient
to specify the sort order
for the index
to be descending.
We can
specify the sort order
by adding an index
to the required column
by adding a migration
.
This will work as expected. But our email template
is displayed differently based on user’s role. To test this,
we need to update the notify method
and then check the updated preview.
What if we could just pass the email in the preview URL.
Ruby 2.5 allows using a shorthand for this by
passing a pattern argument.
Internally
case equality operator(===) is used
against every element of the sequence
and the pattern argument.
This allows us to write concise and shorthand expressions where block
is only used for comparisons.
This feature is applicable to all?, none?, one? and any? methods.
Similarities with Enumerable#grep
This feature is based on how Enumerable#grep works.
grep returns an array
of every element in the sequence
for which the case equality operator(===)
returns true
by applying the pattern.
In this case,
the all? and friends return true or false.
There is a proposal to add it for select and reject as well.
If we generate a new Rails app using Rails 5.2, we will see bootsnap gem
in the Gemfile. bootsnap helps in
reducing the boot time of the app by caching expensive computations.
In a new Rails 5.2 app, boot.rb will contain following content:
ENV['BUNDLE_GEMFILE']||=File.expand_path('../Gemfile',__dir__)require'bundler/setup'# Set up gems listed in the Gemfile.require'bootsnap/setup'# Speed up boot time by caching expensive operations.if%w[s server c console].any?{|a|ARGV.include?(a)}puts"=> Booting Rails"end
This sets up bootsnap to start in all environments. We can toggle it per environment
as required.
This works out of the box and we don’t have do to anything for the new app.
If we are upgrading an older app which already has bootsnap, then we need to make sure that
we are using bootsnap >= 1.1.0 because new Rails apps ship with that version constraint.
If the app doesn’t contain the bootsnap gem already then we will need to add it manually
since rails app:update task adds the bootsnap/setup line to boot.rb regardless of its presence
in the Gemfile.
Ruby allows pretty printing
of objects using
pp method.
Before Ruby 2.5, we had to require PP explicitly before using it.
Even the official documentation states that “All examples assume you have loaded the PP class with require ‘pp’”.
>>months=%w(January February March)=>["January","February","March"]>>ppmonthsNoMethodError:undefinedmethod`pp' for main:Object
Did you mean? p
from (irb):5
from /Users/prathamesh/.rbenv/versions/2.4.1/bin/irb:11:
>> require 'pp'
=> true
>> pp months
["January",
"February",
"March"]
=> ["January", "February", "March"]
Ruby has Array#unshift to
prepend an element to the start of an array
and
Array#push to append an element to the end of an array.
The names of these methods are not very intuitive.
Active Support from Rails already has aliases for the unshift and push methods , namely prepend and append.
Without a method argument
try
behaves similar to yield_self.
It would yield to the given block
unless the receiver is nil
and returns the output of the last statement in the block.
irb>"Hello".try{|str|str+" World"}=>"Hello World"
Couple of differences to note are,
try is not part of Ruby but Rails.
Also try’s main purpose is protection against nil
hence it doesn’t execute the block if receiver is nil.
tap also is similar to yield_self.
It’s part of Ruby itself.
The only difference is the value that is returned.
tap returns the receiver itself
while yield_self returns the
output of the block.
Overall, yield_self
improves readability of the code
by promoting chaining
over nested function calls.
Here is an example of both the styles.
irb>add_greeting=->(str){"HELLO "+str}irb>to_upper=->(str){str.upcase}# with new `yield_self`irb>"world".yield_self(&to_upper).yield_self(&add_greeting)=>"HELLO WORLD"# nested function callsirb>add_greeting.call(to_upper.call("world"))=>"HELLO WORLD"
yield_self is part of Kernel
and
hence it’s available to all the objects.
By using fetch_values we are able to
get values for multiple keys in a hash.
capitals={usa: "Washington DC",china: "Beijing",india: "New Delhi",australia: "Canberra"}capitals.fetch_values(:usa,:india)#=> ["Washington DC", "New Delhi"]capitals.fetch_values(:usa,:spain){|country|"N/A"}#=> ["Washington DC", "N/A"]
Rails 5.2 introduces method fetch_valueson HashWithIndifferentAccess.
We’ll hence be able to fetch values of multiple keys
on any instance of HashWithIndifferentAccess class.
Now in order to delete prefix we can use delete_prefix and to delete
suffix we could use chomp. This did not feel right. So for symmetry
delete_suffix was added.
We can see that
the output includes the directives for
current directory and parent directory
which are "." and "..".
When we want to have access
only to the children files and directories,
we do not need the
[".", ".."] subarray.
This is a very common use case and
we’ll probably have to do something like
Dir.entries(path) - [".", ".."]
to achieve the desired output.
To overcome such issues,
Ruby 2.5 introduced Dir.children.
It returns the output of ls -a command without
the directives for current and parent directories.
In one of our
previous blogs,
we mentioned how
recompose
improves both
the readability
and the
maintainability
of the code.
We also saw
how branch
and
renderComponent
functions
from recompose
help us
in deciding
which component to render
based on a condition.
We can use the code from
renderComponent documentation
to render a
spinner component when
the data is being fetched
in a ReactJS application.
Initial Code
// PatientsList.jsimportReact,{Component}from'react';importLoadingIndicatorfrom'./LoadingIndicator';exportdefaultclassPatientsListextendsComponent{state={isLoading:true,patientsList:[],}componentDidMount(){api.getPatientsList().then(responseData=>{this.setState({patientsList:responseData,isLoading:false,})})}render(){const{isLoading}=this.state;if(isLoading){return<LoadingIndicatorisLoading={isLoading}/>
}else{return(<ScrollView>// Some header component// View rendering the patients</ScrollView>
)}}
In the above code,
when the PatientsList component mounts,
it fetches
the list of patients from the API.
During this time,
the isLoading state is true,
so we render
the LoadingIndicator component.
Once the API call
returns with the response,
we set
the isLoading state to false.
This renders
ScrollView component,
with our list of patients.
The above code works fine,
but
if our app has multiple screens,
which show
the loading indicator
and fetch data,
the above way
of handling it
becomes repetitive
and hard to maintain.
Building a higher order component
Here’s where
Higher Order Components(HOC)
are very useful.
We can extract the logic
for the ability
to show the loading indicator
in a HOC.
Here,
we created a HOC component
which accepts a component
and the isLoading prop.
If isLoading is true,
we show the LoadingIndicator.
If isLoading is false,
we show the supplied component
with its children,
and pass in the props.
Now,
we can use the above HOC
in our PatientsList.js file.
The supplied component
can be any React Native component
based on the use case.
Here in our case,
its a ScrollView.
// PatientsList.jsimport{ScrollView}from'react-native';importwithSpinnerfrom'./withSpinner';constScrollViewWithSpinner=withSpinner(ScrollView);exportdefaultclassPatientsListextendsComponent{state={isLoading:true,patientsList:[],}componentDidMount(){api.getPatientsList().then(responseData=>{this.setState({patientsList:responseData,isLoading:false,})})}render(){const{isLoading}=this.state;return(<ScrollViewWithSpinnerisLoading={isLoading}// other props>// Some header component// View rendering the patients</ScrollViewWithSpinner>
)}
Conclusion
Because of the above
extraction of logic to a HOC,
we can now use the same HOC
in all our components
which render a loading indicator
while the data is being fetched.
The logic
to show a loading indicator
now resides in a HOC.
This makes the code easier
to maintain and less repetitive.
Let’s take a project with hundreds of users.
When we call inspect on User.all,
we see an array of 10 users followed by ....
That means the output of #inspect method
shows data only for
10 records.
