Rack Sailing

In this article we will discuss how we can sail with Rack in a real-world problem.

What Is Rack

Rack is a minimalistic Ruby Web server Interface. As a matter of fact, we can use Rack to build web applications if we follow its protocol. Notably, the protocol is straightforward. We need a Ruby object that responds to the call method which returns a three-element Array:

# rack_hello_world.rb

require 'rack'
 
class HelloWorldApp
  def self.call(env)
    # 200 is the HTTP status code
    # the second element is the response HTTP header hash
    # finally the last element is the response body
    ['200', {'Content-Type' => 'text/html'}, ['A hello world rack app.']]
  end
end

Rack::Handler::WEBrick.run HelloWorldApp

To try the above rack application:

$ gem install rack
$ mkdir rack_hello_world
$ cd rack_hello_world

Write the rack_hello_world.rb file and execute:

$ ruby rack_hello_world.rb
$ curl -I http://localhost:8080

The Middleware

We can compose Rack applications together using middlewares. A middleware basically lets us wrap different inputs and outputs in order to integrate them into our problem-solving.

One common usage is in Rails. For example, Rails uses middlewares to wrap HTTP requests in a simple way.

Continuing from the previous example lets implement a middleware which will add some headers to our response:

# rack_hello_world.rb

# ...

class AddSomeHeaders
  def initialize(app)
    @app = app
  end

  def call(env)
    @app.call(env).tap { |status, headers, body| headers['X-awesome'] = true }
  end
end

app = Rack::Builder.new do
  use AddSomeHeaders
  run HelloWorldApp
end

Rack::Server.start app: app

The response headers:

$ curl -I http://localhost:8080
# => HTTP/1.1 200 OK
# => Content-Type: text/html
# => X-Awesome: true
# => Server: WEBrick/1.3.1 (Ruby/2.3.3/2016-11-21)
# => Date: Thu, 01 Jan 2018 21:29:53 GMT
# => Content-Length: 23
# => Connection: Keep-Alive

The Real World

For a real-world usage of a Rack middleware, we can open the Rails project.

# /actionpack/lib/action_dispatch/middleware/ssl.rb

# I simplified the call for the article's purpose
def call(env)
  request = Request.new env

  if request.ssl?
    @app.call(env).tap do |status, headers, body|
      set_hsts_header! headers
    end
  end
end

As a matter of fact, we can observe that the tap is being used. This basically enables us to manipulate the app object(here the response) in a clean way at a later time. To put it differently, the logic is that @app.call(env) will have to return before the tap block gets executed.

The above is equivalent to:

def call(env)
  request = Request.new env

  if request.ssl?
    res = @app.call(env)
    res[1] = set_hsts_header! res[1]
    res
  end
end

It’s important to realize that if we want to place a middleware before the ActionDispatch::SSL one we would have to tap(sic) into the object after the ActionDispatch::SSL middleware is done.

Indeed, we can observe this functionality if we extend our previous example:

# rack_hello_world.rb

# ...

class EditSomeHeaders
  def initialize(app)
    @app = app
  end

  def call(env)
    @app.call(env).tap do |status, headers, body|
      headers.delete('X-awesome')
      headers['X-double-awesome'] = 'true'
    end
  end
end

app = Rack::Builder.new do
  use EditSomeHeaders
  use AddSomeHeaders
  run HelloWorldApp
end

Rack::Handler::WEBrick.run app

Notice how EditSomeHeaders is being placed before AddSomeHeaders in the middleware stack.

To clarify, execute:

$ curl -I http://localhost:8080
# => HTTP/1.1 200 OK
# => Content-Type: text/html
# => X-Double-Awesome: true # => This has changed
# => Server: WEBrick/1.3.1 (Ruby/2.3.3/2016-11-21)
# => Date: Thu, 01 Jan 2018 22:24:29 GMT
# => Content-Length: 23
# => Connection: Keep-Alive

Meanwhile, the full code example is available on github.

Takeaway

In this article, we’ve explored the basic concepts of Rack, built a Rack middleware and investigated how Rails utilizes
Rack to enforce the SSL policy.

All things considered, reading the code under the hood of a famous or well-engineered library or framework can teach us new methodologies and ways of solving problems. In essence, going through the Rails source code taught us how to use the tap method to manipulate a Rack object that is being manipulated later in the stack.

Pragmatic Teams

In this article, we will discuss my notes regarding the pragmatic teams, what are they and why you should strive to build a pragmatic team or become a member of one.

Why build a pragmatic team?

First of all, this article’s title is influenced from the excellent book about software engineering best practices from Andrew Hunt and David Thomas, The Pragmatic Programmer: From Journeyman to Master, which I read recently.

In addition, I strongly suggest not only to read, but also take notes and think about the ideas and the engineering culture this book suggests. As an illustration, it covers topics ranging from personal development and career decisions to architectural patterns and software development methodologies, so most readers will find something interesting that applies to their current situation.

What are pragmatic teams

The first thing to remember is that a pragmatic team is not a team which is formed under some vague principles. In contrast, it is a team that consists of pragmatic developers working in an enabling environment.

Most noteworthy, the authors of the aforementioned book promise that once a group of pragmatic developers is formed, the group will define their own team dynamics that best suit them.

Pragmatic team dynamics

We should build our pragmatic team on some distinct unconditional values. In general, all members of the team internalize these values and are always seeking to improve, evolve and adapt.

Quality

Teams should not tolerate small bugs that no one fixes. All team members should take responsibility for the quality of the products the team is shipping.

Monitoring

Make sure everyone is able to monitor and actually monitors the project for changes. Monitor things such as:

  • Project scope
  • Time issues
  • Feature requests
  • Any requirement changes

Communication

Developers must talk to each other. Pragmatic teams communicate clearly:

  • They hold structured meetings
  • They produce consistent documentation
  • The team speaks with one voice and understands humor

DRY(sic)

The well-known development rules should be respected and followed in the context of a team too. The point of this strategy is that all team members know to whom to talk about their project issues and to eliminate duplicated work.

Assimilation

Team activities can’t happen today in isolation. In detail, people from different backgrounds can offer valuable insights into a problem domain they are not experts.

Call to action

To summarize, the pragmatic team notion really helped me grow as an engineer and as a valuable team member.

From my experience, before we can start discussing building our culture, refining our methodologies and expand our teams we should fulfill our own personal duties.

All things considered, we should strive to build an enabling environment. Furthermore, learn to celebrate the power that comes from individuality. Rather than fear anything not technical, focus on how to ascend beyond the engineering tasks.

Most of all, adopt a growth mindset and grow as communicators, problem solvers, and social beings.

Why WordPress

In this article, we will discuss why I chose to invest in WordPress.

Intro

I decided to use WordPress on my personal website and blog. Since I am fluent in Ruby the alternatives were Jekyll and Rails.

The requirements

When I started researching how should I build this blog I had some clear requirements in mind.

These requirements were the bare minimum and the list that follows is not the complete feature set I had in mind. Some things would be nice to have whether I chose Rails or WordPress or something else entirely.

So, the must-have were:

  • I should be able to focus on content creation(that means minimum plumping and maintenance)
  • My budget is small. I should be able to spend my budget on books and lessons to get better so that I can serve a higher quality content.
  • Minimum troubleshooting. Again content is the focus here. I love troubleshooting and I will write about many issues I face daily in my job and in my personal projects or open source. But the blog should act as a means to transfer this information.

With these clear requirements in mind, I began my quest to explore many platforms. Eventually, I only considered seriously Rails, Jekyll and WordPress.

The evaluation

I chose WordPress. Rails would need either managed hosting(too expensive for my budget) or maintenance from me(less time for content creation). Jekyll was a good alternative but was missing many plugins

WordPress has over 30,000 plugins. I could host my content relatively cheaply. The maintenance would be minimum.

Outro

The above worked fine for me, but another technology stack may have been a better solution or it may have been a better fit for somewhat different requirements.

Choose whatever technology stack you feel comfortable with and have a clear plan to start researching the alternatives.