Carrierwave-AWS and fixing Excon::Errors::SocketError Broken Pipe Errors

custom software ruby on rails software development

So we've been using Carrierwave for a while. It's an amazing solution for Ruby on Rails apps that need to store files.

We use it mainly with Amazon AWS S3 as our storage. However, recently when trying to use it for a new app, we kept running into these errors anytime we tried to upload anything to S3. The errors were Excon::Errors::SocketError Broken Pipe errors. Most posts on the internet suggest issues with permissions or with not setting the region properly, but after trying all those, we still couldn't get it to work.

We then came across a Stack Overflow answer that talked about using an alternative gem called Carrierwave-AWS.

I was skeptical at first, because I wasn't sure who was maintaining it and why I hadn't heard of it before. As it turns out, this is maintained by the same people who maintain the original CarrierWave!

This new library uses the official AWS-SDK library and actually solved my Broken Pipe issues! What's more, I was happy to see that I could still revert to using file storage for dev environments with this library. All pretty sweet!

So if you're using Carrierwave with AWS S3 and you haven't heard of Carrierwave-AWS, it's probably a good time to check it out!

Here's the link:


Casey Li
CEO & Founder, BiteSite

Ruby on Rails Templates

ruby on rails software development

As a junior Ruby on Rails developer, GoRails has been a great help with all their free video tutorials Chris Oliver creates. When I started to venture into rails templates, I found he hosts a repository of community created rails templates for others to upload or use for free.

Check it out here if you're a Rails developer and are interested in automating some of your workflow.

Chris Francis
Software Developer, BiteSite

Ruby on Rails CSS File Structure

css ruby on rails software development

Ruby on Rails is an amazing framework. At BiteSite, we started using it back in 2011 and haven’t stopped since. It’s combination of technical ability and software philosophy has kept it our framework of choice when it comes to web development and it only gets better with time.

One of the things we appreciate most about Ruby on Rails is its convention over configuration philosophy. In short, it basically says, “If you follow our conventions, you don’t have to configure your code”. This allows for less boilerplate code and is, in my opinion, the best way to enforce coding conventions.

With convention over configuration, one of the best benefits you get is a well designed architecture for your code. Every Rails app puts all of its controllers in the same folder, all of its models in the same folder and so on. It makes developing Rails so easy to jump into.

That being said - it’s not perfect. While convention over configuration is in so many places in Ruby on Rails - there are areas it doesn’t exist and you’re left to come up with your own design or structure.

One of these places is CSS.

While Rails does suggest how to structure your CSS when you use scaffolding, it doesn’t really have a strict convention over configuration policy about how to split up your CSS into multiple files and where to put them (aside from the ‘stylesheets’ folder).

When apps get big, this can become a problem.

Over the years, we have come up with a system that has served us pretty well that we thought we’d share. It’s not perfect, but it does work.


To be clear, this system only dictates how to split up your files and where to put them. It does not cover how to actually structure your CSS selectors and CSS code within those files.

Driving Forces

When we set out our to improve our CSS File structure, there were really two driving forces. One, as with most coding, we wanted our code to be DRY (Don’t Repeat Yourself) where possible. Now, notice I said “where possible” vs. “as much as possible”. We found that overtime, it was hard to keep track of CSS code and so many times you would change some CSS code to fix one problem, but not realize it was being used in 5 other places. We were consistently breaking pages without realizing it and so we implemented our second driving principle: make our file structure easy to follow and easy to figure out what pages it was affecting.

We realized this was breaking DRY code, but it kept our codebase sane and predictable.

(Incidentally, we found out later on, that this true separation of concerns vs separation of technologies was being embraced in future frameworks like React and Vue where you can scope CSS to individual components).


Note, at BiteSite, we use SCSS to help with a lot of this, but a lot of the learnings can be applied to vanilla CSS.

CSS File Structure

With those two driving forces in places, we came up with the following CSS file structure:

↳ assets
  ↳ stylesheets
    ↳ base
    ↳ common
    ↳ components
    ↳ views

The 4 folders we’ve introduced are base, common, components, views. Let’s explore each of these.


The base folder is where we put our UI Kit CSS. So all your standard buttons, links, typography, tables and other CSS that would apply to most or all web apps we put in here. To complement this, we also include things like globals and colorswatches which we can import into the rest of the files. We’ll usually split each of these into its own file. Examples include:

↳ assets
  ↳ stylesheets
    ↳ base
      ↳ globals.scss
      ↳ colorswatches.scss
      ↳ buttons.scss
      ↳ links.scss
      ↳ typography.scss
      ↳ forms.scss
      ↳ tables.scss


The common folder is how we achieve ‘DRY’ code outside of UI Kit elements. While we generally try to scope our CSS to specific pages (or components if using React), there are definitely some cases where it’s better to re-use CSS within HTML/JS code. We have a dedicated folder for these to help remind developers. It tells the developer, “Hey, if you’re editing something in the common folder, be careful, because it most likely affects more than just the part of the web app that you’re working on.” Additional to some reusable CSS that’s specific to your app, we also include things like layout CSS here. Examples include:

↳ assets
  ↳ stylesheets
    ↳ common
      ↳ layout.scss
      ↳ shopping_cart_line_item.scss
      ↳ pricing_badge.scss


This is specific to web applications that use Webpacker + React. If you don’t use React, you can skip this part. When we create components and want to scope some CSS specifically to the component. Now I’m sure there are better JS ways to do this, but to be honest we haven’t quite figured them out yet, so we do this instead.

To make this work, we add a CSS ID/class selector to the outer most element of the component that starts with “component-”. Here is an example:

/* product_card.jsx */
function ProductCard() {
  return (
    <div className=’component-product-card’>

Then we place it’s corresponding CSS in this folder:

/* app/assets/stylesheets/components/product_card.scss */
.component-product-card {


This is the last folder and we use this for page specific CSS. To do this scoping, we surround every view template in a <div> or <span> that has an ID in the form of “controller-view”. Here is an example:

<!-- app/views/products/show.html.erb -->
<div id=”products-show”>

With the page scoped, we then place the CSS files in a file structure that’s similar to the regular app/views/ folders. We create a folder for each controller and a file for each view.

/* app/assets/stylesheets/views/products/show.scss */
#products-show {


We’ve been using this file structure for over 5 years now and while we know of some shortfalls (e.g. React components named the same but within different folders), it has worked out very well for us. Hopefully this will help others as well!

Casey Li
CEO & Founder, BiteSite

Why choose Off-the-shelf Software over Custom Software?

custom software business

For those who don’t know, my name is Casey Li, and I run a business that provides Custom Software services. So it might be a bit strange to see an article from us that talks about why you should NOT choose Custom Software.

However, the reality is that a lot of times when we talk to new customers, we recommend that they go with a solution that we cannot provide. We believe that if we try to sell everyone on Custom Software - even to the ones that it doesn’t make sense for - then not only will they suffer, but we will too. They will end up spending too much money and time and end up with something that they are not happy with. Meanwhile, our team will consistently fail to meet expectations and sour the relationship.

With that, I’m writing an article on why it’s best to consider one of the alternatives: Off-the-shelf Software.

What is Off-the-shelf Software?

There are other names for the type of software that we are calling “Off-the-shelf Software”. Some people call this “Commercial Off the shelf software” and we’ve referred to it as “Mass Market software” in previous articles. What it boils down to is software that is already made and available to use for the public.

Nowadays, most of the time, this takes place in the form of something you can easily buy online and either download to use, or simply use through a browser like a website.

Examples of Off-the-shelf Software cover a wide range of uses. They include Microsoft Office, GMail, Quickbooks, Spotify, Adobe Creative Suite, and more.

Generally speaking, if you can go online and purchase it (or use it for free), you’re most likely dealing with Off-the-shelf or Off the shelf software.

What is Custom Software?

Custom Software, on the other hand, is software that doesn’t exist yet. It’s software that you pay someone or some organization to build specifically for you to solve your problem.

What can Off-the-shelf Software do for your business?

Why are we even talking about this in the first place? Usually when you’re considering your options like Off-the-shelf Software or Custom Software, you’re usually looking to solve a problem. Very commonly, you run a business and you’re looking for some tools to help your business.

You might be looking for some software to manage your accounting - something that can keep track of your expenses, invoices, and time tracking. You might be looking for something to manage your staff’s schedules. Or maybe you’re looking for software to run email marketing campaigns.

Either way, most of the time you’re looking for something to augment your business and the reality is, if you have a problem to solve, there is a very high likelihood that someone has built software to solve it.

Why choose Off-the-shelf Software over Custom Software?

Ok, so now that you know what Off-the-shelf Software is and what it can do for your business, what are some of the reasons you would choose it over Custom Software?


One of the best things about Off-the-shelf software is that it’s available right away. If you need to solve your problem today, or just want to try out the solution, you can start implementing your solution today. In fact, most web applications today can be set up within minutes.

For example, you need an invoicing system, you could easily sign up for an account on Waves ( or Freshbooks ( Within minutes you’ll have access to a very powerful invoicing tool.

If your problem is urgent, or time sensitive, or you realize the importance of moving fast on a solution - then off-the-shelf software is probably right for you.


Companies that build off-the-shelf software typically rely on economies of scale and not relying on a one-to-one relationship between the hours spent building it and the money they are charging for it. As a result, most of these companies are able to charge a very reasonable price for a very powerful piece of software.

For example, let’s take Figma ( as an example. Figma is a very powerful tool that lets designers create wireframes and user interfaces. Figma starts at $0.00/month and only goes as high as $45.00/month. For what you get and for what you can produce, this is quite cheap.

What’s more, is that a lot of these services and platforms price their software per user or per usage. What that boils down to is, the more successful you are, the more we’ll charge you, but that also means, if you’re small today, we’ll charge you less.

So not only is paying to use off-the-shelf software generally cheaper than building your own custom solution, it’s also generally cheaper to try out.

In some cases, the costs savings can be quite substantial.

Feature Set

This kind of goes hand in hand with Timing and Price. While Custom Software can get you all the features you could ever want, Custom Software is built from the ground up which means it can take a lot of time and money to get those features built, up and running, and ultimately to a state where they are operating well.

On top of those exciting new features that you want built that Off-the-shelf software doesn’t offer, even basic functionality that you’ve come to expect can take some time to get in there. For example, a sign up and sign in screen, a forgot password screen - all the things you take for granted in software you use has to be built up.

Off-the-shelf software has typically been around way longer than a custom solution and is built by a bigger team. With that, they are usually much richer in functionality at the start. As soon as you sign-up, you’ll probably have access to hundreds of features whereas with Custom software, these features are slowly built over time.


This argument can be made for either Custom Software or for Off-the-shelf Software. However, all things being equal, Off-the-shelf Software being typically built by bigger teams and tested by more people can lead to higher quality software. Some off-the-shelf software is built by the best software teams in the world and as such you might get access to some of the best software in the world.

Some other things to consider So we’re really starting to make the case for Off-the-shelf software. However, if you’re still not convinced, here are two more things to consider.

One, as we have written about before, if you’re trying to decide between the two, it’s usually a good idea to try out Off-the-shelf software first. It’s usually quite cheap and a lot of the offerings have a free trial.

Two, you should consider that it’s not necessarily all or nothing. There are a LOT of Off-the-shelf software solutions that offer integrations, APIs, and more to allow for a large amount of customization. For example, Wordpress can be considered Off-the-shelf software, but it offers a lot of customization options that allow the best of both worlds.

The right solution for the right problem So, yes, Off-the-shelf software has a lot going for it and like I said, we recommend it a lot. In fact, we use a lot of off-the-shelf software to run our business. However, it’s not always clear cut. What it comes down to is there is a place and time for each and it’s about determining whether or not your problem merits one or the other.

Even though I think most people would have considered the Off-the-shelf software option already, we thought we’d shed some light on the reasons you should choose it.

Photo Credit: Andrea Piacquadio from Pexels

Casey Li
CEO & Founder, BiteSite

Developer Productivity Tools

tools software software development

Every developer has their own environment. Take a peek into the environment I use to create software. Most of these are independent of the software I create and can be used by anyone.

1. GitLens Visual Studio Code Extension

Visual Studio Code - commonly referred to as vscode - is a free to use code editor created by Microsoft available on all operating systems. With its large popularity, if you are a developer you probably already use this everyday.

On the surface vscode is a code editor that allows you to edit files. Its power lies in the extensions it offers and the customizability of your programming environment. If there is a way to optimize your coding experience an extension for it probably exists.

How does it increase productivity?

My most used (and all time favourite) extension that improves productivity is the GitLens extension. With 59.43 million downloads and an overall rating of 4.8/5 stars, I am confident this will be one of your most used extensions. Overall this extension allows you to use Git inside your code editor.

If you open your project in its root folder, Vscode is smart enough to recognize the branch you are currently on as well as all previous repository information. The days of needing to be a command line wizard are long gone with the ability to do all source control commands straight from your code editor’s GUI. As seen in the image below, the source control menu contains multiple submenus such as commits, repositories, file history, branches, etc. The use of these sub-menus could be a full article itself but I will focus on the source control section since I use it the most.

The source control section is a list of all files changed since your last commit. Each file can be selected to show a side by side ‘Working Tree’ highlighting the removals and additions you did to each file. Picture either git diff or the Files Changed section of a PR on GitHub.

Before I commit and push my code for a PR review I use this file changes section to go through all the changes I made on the current branch to make sure when I create my PR it is clean and only contains changes I made to complete the feature.


2. GitHub Actions

GitHub Actions is a relatively new feature GitHub provides. This feature automates workflows through the use of action scripts. Action scripts are used to run some code when different things happen in your repository. This could be anything from welcoming a new user, to a full CI/CD pipeline.

How does it increase productivity?

Actions increase productivity by allowing developers to automate workflows in their projects. This is not a new concept as seen in well known tools such as Travis, Jenkins, CircleCI, and many others but if you already have your repository in GitHub it does further centralize your development process.

A nice feature Actions provides that helps with developer productivity is the ability to see whether all tests have passed before merging a pull request. If set up to run on pull request creation, GitHub will run the tests when a pull request is created. This then will stop the reviewers from merging the pull request until all tests have been completed. If there are failing tests it will display this information above the ‘Merge pull request’. This can restrict failing tests from getting into the main branch.

A repository’s workflows are stored in .yml files that contain the instructions for Actions to follow. GitHub provides many great examples here if you would like a base file to start with.


3. OhMyZsh Z Shell Framework

With the release of MacOS Catalina, Apple switched from bash to Z shell(zsh) as their default login shell. This was due to the licensing around using bash. The licensing for zsh is much easier for Apple to keep their shell environment updated to the latest version for their new releases.

OhMyZsh is a Z shell framework used to easily install plugins and themes. With its massive popularity there is a large community of developers that have created content to help you understand its features as well as help you through any problems you might encounter.

I would suggest this framework to anyone who doesn’t want to worry about small details and would rather have a quick and easy way to customize their shell. You can have all these features with the default Z shell but it will take more time to set up.

How does it increase productivity?

As every developer knows, getting the right theme for a text editor is almost as important as writing good code. OhMyZsh brings the same ability to your terminal through the use of themes.

Here are some features the simple theme in the image below contains:

  • The current branch is displayed beside the directory path. No more needing to type $ git branch to see if you're pushing to master.
  • The X beside the current branch shows that you have uncommitted changes.
  • Double clicking tab will allow you to tab through the options available. Depending on how long you name your branch names this could save seconds of your day.

Okay, none of these are life changing but it's a nice visual upgrade from the default black and white terminal.

Depending on your developer needs, the plugins are where you can actually save time without having to configure shell scripts yourself. There are around 300 different plugins you can choose from to add aliases to your terminal without you having to write the shell scripts yourself. It’s as simple as adding the plugin name to your ~/.zshrc file in the form plugins=(... <NAME>).

Out of all tools mentioned in this article I believe this one is the most variable in its helpfulness. I am glad it's available as I use it myself but I can see how a developer would view it as being overkill for what is essentially a few shell scripts.


4. React DevTools Extension

Although all the other tools in this list could be used by any developer, this tool is specifically for React developers. React DevTools is a Chrome and Firefox extension that provides a component tree hierarchy in the dev tools. Picture the ‘elements’ tab but with your component names rather than html tags. Each component can be selected to show it’s props, state, and hooks.

How does it increase productivity?

This extension is really helpful when trying to debug what components have been rendered as well as what their current variables are assigned to. I like using this extension to manually edit props or state variables in my components to see the result.

This is also helpful when starting a new feature that I am not sure where in the codebase I will be working from. I can use this extension in the app's feature location to find what the affected component names are, then start developing in the code base from there.


5. Microsoft Azure Virtual Machines

While at work I use MacOS but I have helped develop a Windows service. To test this I needed access to a Windows environment. Microsoft offers a cloud platform service that provides access to a windows virtual machine.

How does it increase productivity?

Microsoft Azure provides users with all the benefits of virtual machines. This helps with productivity by providing access to tools without buying another physical machine. To develop the Windows service I could have used another PC with windows installed but it was much easier (and cheaper) to open the Azure virtual machine and do everything remotely.


Chris Francis
Software Developer, BiteSite