Introducing Trello Views!

custom software trello software development

So we use Trello - a lot.

We use it to manage our Scrum Express process and it's become an integral part of our software development. However, one thing we noticed is that our Trello boards are getting BIG. Like super wide with lots of columns.

The thing is though, at any given time, we only need to see a subset of those columns. For example, when doing Product Management meetings, we're concerned with a very different set of columns than when we're doing development.

So - we built a Chrome extension to solve this. We call it Trello Views.

Super MVP at this point, but would love some feedback.

Check it out:

Casey Li
CEO & Founder, BiteSite

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

custom software software development ruby on rails

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

software development ruby on rails

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 software development ruby on rails

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

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