Benoit Tremblay

Setting up a Rails 6.1 app on Beanstalk/Linux AL2: Paper Cuts Edition

Beanstalk is a great platform, but has gradually become more complex over the years. I remember setting up my first environment about 4 years ago and being quite impressed by how easy it was to have a working environment in a relatively short amount of time.

I’ve been working on a new app lately and had to set up a brand new environment, so I had to start from scratch once again. And boy oh boy, it’s not so much that the fundamentals have changed, but I found myself constantly hitting walls for things that I didn’t anticipate, things that I just assumed would work out of the box or be easy to configure.

What I thought would be a day of work ended up being a week. A week of paper cuts. Again, the initial deployment didn’t take long, but having a functional and usable app is a different story.

Here are some of the papercuts I encountered and how I ended up fixing them. There are plenty of guides on how to get started with Beanstalk, so I’m assuming some basic knowledge, that you’ve deployed a basic version of your app and that you’re starting to hit the same walls as I did.

How we built table support for Trix Editor

Trix is a great text editor, but for the sake of keeping it simple and enjoyable to use, has some limitations.

One of those limitations is the lack of support for HTML tables. Paste a table in Trix, and gone is the table.

For most use cases, it isn’t too much of an issue since I feel that most of the time, it’s possible to find an alternative to a table. Sometimes in the name of simplicity it’s even good to get rid of a table.

I must be using bad user interfaces every day

I’m sure you’ve seen this quote before. It seems particularly popular on LinkedIn, where sharing it unlocks the I know what makes a great user interface, constantly name things right and perfectly position every button status symbol.

Binding Multiple SSL Certificates to a Single AWS ELB or Autoscaling Beanstalk Setup

I ran into an unexpected issue when configuring multi domain SSL support for Timelapse. The servers are running behind a load balancer (ELB) and it appears you can only bind a single SSL certificate to an ELB.

Spending the right amount of energy on the right problems

By recognizing the now, future and hypothetical problems

There are the problems you have now, the problems you’ll have and the problems you might have.

You can’t work simultaneously on all of them.

The Great Deception

It’s inevitable. It happened in your last project and it will happen in the next one. It’s that moment when excitement and romance get replaced by questions, doubts, frustration and deception.

It turns out that as human beings, we’re the only species with a brain capable of running simulations and feel emotions for things that haven’t happened yet. The problem is, we’re really bad at it.

Getting back to engineering

I stopped actively coding a few years ago, right after I graduated in Computer Engineering. I had to do something else. It’s not so much that I didn’t enjoy coding, but I wasn’t in love with writing code for the sake of writing code. I loved the craft, but not as a job or as a service provider.

Probably much like an author loves his craft. It’s great as long as you get to pick what to write. You get to actually create. When somebody else tells you what you should write, the whole magic goes away. You’re just trading time for money and somebody else ends up putting his name on your work.

Making things right

Product or service, sometimes things don’t go as expected.

Maybe you’ve taken too long to deliver, delivered over budget or made a mistake that cost your client a significant sum of money.

Maybe your product didn’t meet expectations or was lost or damaged during shipping.

Maybe a weird bug prevented some of your customers to use your software for a few hours or worst, a few days.

No matter how wrong things go, you always get a chance to make things right and it’s that moment that will define how customers perceive you as an individual, company or product.

Judging past decisions based on today’s facts

While it’s good to regularly reconsider and rethink the way things are done, judging decisions from the past based on the knowledge we have today is far too easy, far too common and quite useless.

The voices killing simplicity

Bill can’t find the document he’s looking for on the Intranet. Clearly it isn’t visible enough, so let’s add it to the home page for everyone to find it.

Someone told us he couldn’t find the contact button on the site. Let’s make the button bigger, change its color and add an additional link to the sidebar.

We don’t generate enough sales of that product. Let’s add a banner everywhere on the site promoting it.

Can you believe that feature was left out from the app? It has to be squeezed in the next release.

It’s OK to listen to these voices, but the danger is to think that because one of them is louder, it necessarily deserves more attention. Or that it’s even a statistically significant representation of the silent majority.

While some projects fail at simplicity right from the start, most really fail at keeping it simple. Keeping as in remaining simple over time, way after the project has launched.