wrote on ITNEXT publication on medium. Just re-sharing it here on my own blog

Simply said, it’s a plain ruby object that serves only a single purpose. Just like a chair. It only serves to let people sit on it. Period. There are many reasons for this. It makes it easier for anyone to understand what it does while also making it easier to write tests.

 One thing I have learned over the years writing maintainable code is that objects in the software development world can be better understood and written by relating it to real world objects. Just like how you wouldn’t want your electric stove top to also serve as your work desk (fire hazard!), it only makes sense to create objects that serves only a single purpose.

Below is a simple example of a plain ruby service object class that only creates posts. We’ll elaborate on this further to demonstrate how we can make use of this simple class to refactor your rails controllers using success or failure blocks.

Tip: Try to always name your service objects as a verb (i.e. create, build, update, etc.) It forces you to focus on the action and purpose of the object. Also makes it mentally hard for anyone to add business logic that doesn’t belong there.

Encapsulating the business logic while keeping it isolated from the rest of the Rails framework makes it a component that you can reuse elsewhere within your app. Let’s say you need to apply the same business logic in your controller and API endpoint, you can re-use the same service object with the freedom to decide how you want to respond back to requests (i.e. in your controller, you can redirect the user while in your API endpoint, you can send back a JSON response)

Furthermore, it makes it so much easier to test your business logic since you don’t have to set up any additional overhead for the controller or API just to test the business logic.

Without further ado, let’s jump right into success or failure blocks.

Here is a simple example of a typical controller action containing business logic that we can later refactor into a service object:

I first encountered this technique while peeking into the “

” gem. It was the section on how we can overwrite the default inherited resources actions using success or failure blocks that piqued my interest. Here’s a snippet from the 

Here’s a high-level overview of what the code is doing. When an update is being made to a project resource, if the update fails, it will invoke the failure response by redirecting to the project resource’s show page. However, if the update succeeds, it will default to the normal flow of redirecting to the projects index page (that’s just how inherited resources does it by default). Allowing us to have control over what to do for each success and failure scenario while encapsulating the business logic helps simplifies our controller logic.

Let’s use our earlier service object example with a few tweaks to achieve the same outcome using a more simplified implementation logic (as compared to the one used in 

Here’s the refactored version of our controller action along with the service object and other classes necessary to pull this off.

 instance method (line 25) essentially accepts a block of code with 

 will be yielded which redirects the user request to the posts index page along with a success notice. However, if the 

 class, the block given to it will not be called since 

 class method does nothing. This entire logic applies to the 

Blocks, procs and lambdas can be somewhat confusing, but when you finally grasp the concept, they can be a very powerful and flexible tool to help you write simpler and better code. Here are a few useful resources if you want to learn more:

https://blog.appsignal.com/2018/09/04/ruby-magic-closures-in-ruby-blocks-procs-and-lambdas.html

https://www.rubyguides.com/2016/02/ruby-procs-and-lambdas/

https://pragprog.com/book/btrubyclo/mastering-ruby-closures

Hope you enjoyed reading my article. I love refactoring code and hope to share more refactoring techniques in the future. As always, feel free to leave a comment if you have any feedback or suggestions that can help improve my posts.

Using service objects and success or failure blocks to help you write maintainable ruby on rails controllers

How to refactor Ruby on Rails controllers using blocks and service objects

It didn't took long for me to decide on using Airtable as my data source given I've used it many times in the past to create quick MVPs and hacks. To those unfamiliar, Airtable is like Google Spreadsheets on Nitro. It basically lets you create and manage databases with the ability to add scripts and extensions to do pretty much anything you need. It's highly customizable and offers a variety of options for integrating with different services (i.e. Google Calendar, Salesforce, Asana, etc). 

Next.js is a popular JavaScript React-based framework for building fast-loading static and server-rendered sites. Since my website and blog will consist mainly of static content, Next JS was the obvious choice. It was easy to start and the deployment is a breeze with platforms like Vercel.

In this article, I'll be guiding you on how to re-create my Books page that shows you a gallery of all the noteworthy books I've read in the past. 

Now, let's talk about how to create your database of images using Airtable. Here are the steps:

Update the default table/spreadsheet with the relevant columns. I've updated mine with a `Title` (Single Line Text), `Image` (Attachment) and `URL` (URL) columns.

Create an Airtable personal access token. This can be done by going to the "Developer Hub" page in Airtable and then generating a new personal access token. Here's a link for your convenience https://airtable.com/create/tokens

Give your token a name, and provide the token with the right access scope and workspace by selecting the 

I'm going to be using Tailwind CSS for this guide, so lets install it along with its dependencies. Running the init command will generate both 

Depending on your setup, add the paths to all of your template files by updating the newly generated 

 file. In my example below, I'm adding the path to my 

 file and add the tailwind directives as follow. You can choose to remove any existing default styles generated:

Now that tailwind is setup, lets create a 

 file in our root directory to manage our Airtable token, base and table id that we will need later on as environment variables. We can then conveniently access them via 

The following is a guide from Airtable on locating your base and table ID. To do so, simply navigate to your Airtable workspace and utilize the URL in your browser's address bar.

With the environment variables out of the way, lets start up our NextJS app and visit 

 to make sure everything is loading fine:

 page and start fetching the records from Airtable. 

 to load the images with links to the respective URLs from the Airtable workspace

 function, fetch the records from your Airtable workspace using the environment variables you set up earlier with the 

Using the records, render your page accordingly. Below is a complete example of my 

This article is one of many that I plan to share regarding my experiences and learnings gained from building my personal website using NextJS. I hope you found this article useful!

A step-by-step guide on setting up an image gallery using Airtable with NextJS and TailwindCSS for styling

How to create an image gallery using Airtable with NextJS

Took me long enough but I finally did it. It has been a crazy decade with the hurdles and opportunities life threw at me in business, work and life. Since I've had quite a lot of time this past few months, I've decided to properly re-introduce myself with my own website and blog.

I've picked up a few things over the years as a father, a founder and engineer and i've often wondered the best way to share my learnings. A personal website with a blog came to mind and voila!

Startups (Tears and joys of startup life)

Software Engineering (How-tos, architecture, etc.)

Product Building (How to build and manage product)

Special projects (Hacks, side projects, etc.)

Ideally every 2 weeks. Gonna hold myself to this 😅

Welcome to my website. Thanks for visiting. I'll be sharing my journey and learnings in business, work and life. Hope you enjoy!

Welcome to my blog!

In short, test drive development or more commonly known as TDD is a development methodology by which test code with certain output expectations is written to fail and developers would work towards getting them to pass by writing the necessary code to produce the expected output.

That’s what I thought when I first learned to write tests. I was a freelance developer when I started. I was time-strapped and the last thing I needed was more work to get things done. Writing tests to me wasn’t only a concept that was hard to grasp, it was taking twice as much effort for me to get anything done. So, why do developers even write tests?

It wasn’t until I started building large applications with a team of engineers that I finally grasped the essence and importance of writing tests.

Simon Sinek in his book “Start with Why” explains it best with “The Golden Circle”. There needs to be a pull factor that gives us enough reason to adopt a new habit or process. Here are 3 key reasons why:

Let’s forget about programming for a second and pretend you’re a contractor tasked to make changes to an existing building. You removed a pillar and the next thing you know, the building completely collapses before your eyes. Had you known the pillar was one of the core supporting structures that others 

Code has dependencies just like the supporting pillars in the building. Structures rely on one another to keep your application working. As developers, we constantly need to refactor our code. Having tests around the core parts of our application serves as a guard against breaking changes that can be fatal.

It’s easy to get lost in the weeds once you’re knee-deep into building out a feature. Without a clear plan of execution, often times we miss out on scenarios or contexts that need to be fulfilled when building a feature.

Writing tests first offers us the opportunity to take a step back and “think” through all the possible scenarios with expected input and outcomes before writing any code. It serves as a “blueprint” of sorts that helps guide the development of a feature one step at a time, making sure all business objectives/cases are met, even new ones that you will uncover during the writing process.

I don’t know about you but I don’t like to keep things in my head for long periods of time. I forget things and others can’t read my mind. Tests serve as a reference to help your future self and your teammates understand, to a certain extent why a feature is written the way they are. Comments can only go so far unless you enjoy writing a novel next to your method definitions.

Enough with the reasons why you should write tests. Let’s jump right into some core concepts on how you should think about tests.

I’m sure you’ve heard about the term 

 when it comes to tests. In Wikipedia as it relates to software development, the assertion is defined as:

 a predicate (a Boolean-valued function over the state space, usually expressed as a logical proposition using the variables of a program) connected to a point in the program, that always should evaluate to true at that point in code execution.

I don’t know about you but that confuses the hell out of me when I first read it. Here’s a better take at it:

We expect a lot of things in life. I expect that my cake would come out perfect IF I follow the baking instructions. I expect to lose weight IF I exercise. I expect my kids to stop screaming IF I give them ice-cream. It’s a natural thought process that we expect certain outcomes from our application when certain criteria are met. However, unlike real life expectations, you have absolute control over the expected outcome in your application. If it is meant to output something, you can make it happen.

Writing tests is about writing expectations. RSpec makes it abundantly clear with their own DSL:

 somewhere on the page to contain the text “Hello World”. All I need to do now is to write some code that will print the text “Hello World” on the page when it gets rendered. It's a simple concept.

RSpec is a well known testing framework written in Ruby that I typically use to test my rails application. To use it, you will need to include the 

 gem in your Gemfile. Below is a short gist on how to get your Rails app setup:

 gem defines 10 different types of specs for testing different parts of a Ruby on Rails application. Here’s an illustration of the main types:

Let’s get this straight. Feature tests, system tests, integration tests, acceptance tests, and end-to-end tests, they’re all the same. Its purpose is to help you test your application from the perspective of a real-life user (i.e. going to a page, filling in a text field, clicking on a button, etc.). By simulating the interaction of a real-life user, all your routes, views, controllers and models get tested.

As of Rails 5.1+, with the introduction of 

, it is now recommended to write System specs in replacement of Feature specs.

The Rails RSpec README explains it best: Request specs are for testing your application from the perspective of a 

 They begin with an HTTP request and end with the HTTP response, so they’re faster than feature specs, but do not examine your app’s UI or JavaScript.

It’s perfect for testing API requests and responses which is what I use request specs for most of the time.

A controller spec is nothing more than just unit tests for controllers. It allows you to simulate HTTP requests and specify expected outcomes such as:

some instance variable gets assigned to be used in the view

cookies get set and sent back in response

One of the most common mistakes I find in controller specs is over-expecting outcomes. Expecting that a record gets created in a controller spec can be acceptable if your code does just that. What is not acceptable is when you start writing expectations for mailers, notifications and even view components (including 

 in your controller spec). This is usually an indicator of a bloated controller that needs refactoring.

A model spec is simply a unit test for models. In a typical Rails application, it allows you to write expectations around:

Associations with other models (i.e. has_many, belongs_to)

Validations like uniqueness, presence, etc.

Input and outcomes of methods that defines the behaviour of your model

A routing spec basically allows you to expect/assert your HTTP requests get routed to the right controller and action. This can prove to be useful when you have custom routes that can get pretty gnarly if not managed/tested.

I almost never write view specs but for completeness' sake, I’ve decided to include it here. As its name suggests, view specs allow you to expect your view/page to render certain content when rendered without actually invoking your controllers.

Now that you’ve understood what TDD is, and hopefully given yourself enough reason to adopt testing first in your next project, the next logical step is to figure out how to actually test your Rails application. I’m not talking about how to write tests, I’m talking about knowing how to test. There’s a big difference. It’s like knowing how to write a bunch of English words vs actually knowing how to compose a sentence with perfect grammar.

As illustrated in the diagram above, outside-in is a common approach where high-level feature tests that describe how a feature should work are written first. Working towards getting these high-level expectations to pass will in turn drive us down to lower-level tests such as routing, controller and model tests. Writing implementation code to get the tests passing on each level will help us ultimately build the feature we wanted.

Let’s get into some real-life examples:

Imagine we’re working on the next cool blog application and you’re asked to build a feature to post articles:

As a user, I can post a blog article so that I can share my thoughts with my friends

Before jumping straight into writing out the routes, controller, model and view code, we write a high-level system or feature spec to flesh out how a user would interact with our feature to create a blog post

 will throw you a missing routes error. Awesome! Now, let’s add the appropriate route to our routes file

Running the spec again will throw a new error indicating that we’re missing the controller class. Fixing this error would simply require you to create the missing controller.

As you can already tell, repeating this cycle will throw you new failures and as you work towards fixing these test failures, you will eventually end up writing the necessary routes, controller, model and view code to complete your feature.

As a society, we see failure as a negative thing. Ever since we were young, we were taught to avoid failure. Test-driven development on the other hand flips this mindset to instead embrace failure, to constantly write tests that fail and use it as a guiding light towards building our feature. I think that’s a beautiful mindset and process to adopt in both our development work and life.

As Jeff Bezos once wrote in a letter to shareholders:

Failure comes part and parcel with invention. It’s not optional. We understand that and believe in failing early and iterating until we get it right.

Writing on software design, product building, startup learnings, investments and everything in between.

Categories

Monthly Newsletter