Work you didn’t sell is no better than the work you didn’t do.

A talk on the React.js library, covering the two key principles of react: reusable components and statelessness in your UI. Also covers some internals of the virtual DOM.

Be opinionated about what makes a tool great, but be pragmatic about how to achieve greatness.

There isn’t one. But here are a few options.

Fall in love with the problem, not the solution. Try to find a market and a problem that you are passionate about solving.

A new semester appears! New classes, new side projects. I’m taking some really interesting modules this semester and embarking on a new project.

Read a number of interesting books this month. People have been recommending me such good books and courses.

So this is a habitual thing I'm starting this month. At the start of each month I'll publish a retrospective of things I read/wrote/built/thought/played over the past month. This one is for the past June. I'm hopeful that this monthly retrospective will help chart my growth and act as a garbage collector for my thoughts.

It’s been a slow month for my main side project. Mostly spent on reading and experimentation.

Most of us have a pet project graveyard. It could be software where we spent considerable time coming up with the perfect name, created a Github repo, purchased a domain name, and saw partway through but never quite finished. The project may have began strong, but came to a halt because more pressing work came up; or because we simply lost interest. In the end, nothing gets launched. Have you experienced this?

Having unused domain names is a clear symptom of consistently failing to ship.

In this post, I’d like to outline the reasons why so many of us struggle with shipping and propose a practical approach to sustainably cultivate your pet projects.

Take my thoughts with a pinch of salt. I’m still figuring this out. This post aims to document my own learning process.

If you’re working with a framework (like Rails, Django, Sinatra, or Flask), learning to use it is just scratching the surface. Be rigorous. Go deeper. Learn how it works.

Let’s take a close look at real-world uses of metaprogramming.

Metaprogramming is the writing of computer programs with the ability to treat programs as their data. It means that a program could be designed to read, generate, analyse and/or transform other programs, and even modify itself while running.

We’ll deconstruct how Rails’ ActiveRecord creates methods on the fly in has_secure_token and enum class annotations. By the end of this post, you’ll better understand the underlying mechanisms used by Rails and your favorite gems to create their class annotations.

Metaprogramming is one of my all-time favorite topics, so let’s get started!

I seem to be building APIs left and right, so in this post, we’ll build a RESTful API with Ruby.

There are many approaches you can take when it comes to building an API with Ruby, such as the choice of using the grape DSL, Sinatra, or Rails. There's also design considerations to be made with regards to the language you write in. Node.js and Go is preferable when performance is a core requirement. As always, consider your requirements carefully when deciding on what to use to build your API.

Let’s start with some theory on REST and RESTful APIs. Then, we’ll work through building an API which supports the following:

• API Namespacing
• API Versioning
• API Request Authentication and API Keys
• Object serialization + caching
• HATEOAS

In Part 2, we will go into more detail on documentation, security, optimization, and testing.