Tech and Tips Thursday - First Edition
Login
Technology

Tech and Tips Thursday - First Edition

We would like to introduce to you our first edition of Tech and Tips Thursday, a bi-weekly tech and tips article on various software development, technology and productivity topics.
Welcome to the inaugural edition of the Tech and Tips Thursday series. The idea behind these articles is simple. We would like to share with you what we've learned over the years of building software tools, developing products, and other interesting tidbits from the world of technology and beyond. 

We hope to turn this into a weekly feature, but for the first few months, we will be posting on a bi-weekly schedule. 

About T&T Thursday


Tech and Tips Thursday (or T&T Thursday for short) is a biweekly technology and tips article on various software development, technology, and productivity topics. Topics that we are interested in, have some experience with, and topics that we find interesting outside of technology.

T&T Thursday article follows a standard format. It consists of three sections:

  • One Coding Example
  • One Useful App or Tool 
  • One Interesting Idea or Thought

One Coding Example


Our first coding example will come from the world of Ruby.  We are developing TeamHQ using Rails and that's what we know best.  Rails is an amazing piece of technology and many of us have used and appreciated tools built with it (Github, Shopify, SoundCloud, etc).  In the future, we hope to bring you more examples from other programming languages.

Easy Rescue From Exception

Sometimes you need to print something out and make sure it doesn't throw an error if its parent object is nil. 

For example, let's say you want to print out the name of the author of this article. 

<%= article.author.name %>

This could throw an error on the author of the article has been deleted or wasn't loaded and was nil.  To protect yourself from something like this you can try one of these three techniques:

Technique One
<%= article.author.name rescue "Anonymous Badger" %>

Technique Two
<%= article.author&.name %>

Technique Three
<%= article.author.try(:name) %>

The first technique rescues from any exception that the code could throw your way and prints out "Anonymous Badger" if there is an error. 

Technique Two ensures that the error won't happen by using what is know as a Safe Navigation Operator. If the author happens to be nil, it will not print anything and not throw an error. 

Safe Navigation Operator was introduced in Ruby 2.3.0 and is a useful tool to ensure that your users don't see strange errors if a piece of information is missing on a page. 

Technique Three is similar to Technique Two and it is only available in Rails. It is designed to safeguard against calling a method on a nil object. It will fail gracefully and not print out anything, like the Safe Navigation Operator.

One Useful App or Tool


Our inaugural interesting Tool is Dokku.  Dokku is "The smallest PaaS implementation you've ever seen" and we use it here at TeamHQ to deploy several of our applications.  We've been big fans for over a year now and have been using it in production for 7 months now.  Dokku has matured to become a stable and production-worthy tool.

How Does it Work

If you've heard of Heroku or used it, Dokku is like having Heroku on your own server. 

At its heart, Dokku is a Docker container manager.  It provides simple, but powerful command-line tools to create Docker-based applications, configure networking, setup SSL, and deploy databases, key/value stores, and caching services.

One of the main benefits of using Dokku is the time it saves when you want to deploy and run a docker-based application.  Dokku uses a Git repository internally to manage and deploy your apps to containers.

To deploy your app, simply push your git report to a Dokku server.   Dokku uses Herokuish buildpacks to figure out what type of application you are trying to deploy. Once it's got the right buildpack, it will seamlessly deploy the app and set up the proper environment for it.

If you need more granular control, create your own Dockerfile, add it to your repo and Dokku will be happy to build a special container that fits your needs. 

It also has a rich plugin system that supports the most popular tools. You can deploy your MySQL or Postgres databases. Setup Redis or Memcached. And automatically register and renew SSL certificates with the Letsencrypt plugin.

And the best part about it, if you just have a small web footprint and trying to save money, you can run it on a $5 a month Linode or Digital Ocean server

One Interesting Idea or Thought


Complexity is everywhere, especially in the software world. One thing many people talk about is the need to keep things simple, simplifying processes, breaking down work into smaller chunks.  All of this is great advice but often as useful as "To make money, buy low and sell high" investment insight.

How to Keep Things Simple

In a story, recently on Reddit, a project manager asked how to reduce unnecessary delays and friction between his quality assurance and dev teams.  The author was looking for ideas on how to implement agile better. 

It seems that three teams this project manager had to coordinate were created to simplify things. Each team is focused on a specific area of the project and does specialized work.  While this makes sense for highly repetitive and repeatable work, in software development this could lead to more friction and delays. It could and often does increase second-order complexity. For example, breaking teams by specialty make it more tedious, time-consuming, and inefficient to create an effective interface between those teams. 

What was the alternative? One of the answers shined a light on the heart of the issue. 

Separating test and development into different teams increases handover time and disrupts the flow of a feature. 

When building software it is often better to have a team that is capable of shipping the whole feature together. The team should be able to design, develop, test, and ship the feature together. This is the essence of the agile/scrum process.

Having many specialties might look like it creates unnecessary complexity.  But it actually simplifies things. It reduces the number of outside interactions, makes responding to problems quicker, and increased the amount of value a team can deliver.  And most importantly, it makes it easier to learn from mistakes and change directions if necessary.

Note: This approach is not necessarily applicable to all processes, systems, or teams. Each circumstance is unique and must be evaluated under its own conditions. 

Keeping things simple is not just about breaking things down into smaller chunks. It is often about mixing these smaller chunks in a proper order to increase effectiveness. This, in turn, decreases complexity. 

Until next time...


We hope you have enjoyed our first edition of Tech and Tips Thursday and we look forward to sharing more tips in the next edition of T & T Thursday. 


Get Tech and Tips Thursday articles in your email.