If you're a small team with no sysops guy, PaaS will save your SaaS

We've recognized it time and time again.

Just this past week, the GHOST issue (glibc gethostbyname buffer overflow) popped up. Many people all over the world were scrambling to patch their servers. Large companies and small companies alike, they all had to deal with it one way or another.

As usual with anything like this, we looked to Engine Yard for an update. Our app servers and database servers are hosted on Amazon EC2 and Engine Yard is a PaaS that sits on top of it. Engine Yard provided their customers with a timely update about the issue and how they planned to solve it.

They've gained our trust over time, so we simply stopped worrying about it and waited until they released their patch. Once they released their patch, we followed their detailed instructions and applied the patch on our own schedule. As with something as far reaching as GHOST, it wasn't super easy, but we made it through and we're now the proud owners of patched servers and relaxed minds.

With our servers hosted on vanilla EC2 and without a talented, dedicated sysops guy, this situation would have been a nightmare for us. Instead of shipping new improvements to our product, we would've been at a full stop investigating, experimenting, testing, etc. etc. We don't consider ourselves experts when it comes to managing servers. While most of our engineers have plenty of experience with Linux, we don't want to mess around with sysops.

We want to focus on what we do best - releasing software.

Do we always want to be afraid of Chef recipes, server updates, automated provisioning and the like? Certainly not. However, at this point, we don't want to rely on it as a core competency.

By not hosting your product on a PaaS, you're designating sysops as a core competency of your engineering team. If you don't, you'll pay the price.

One day, you might pay the price in security. You won't have anyone watching out for security issues and your servers will go unpatched, open to abuse.

Next time, you might lose a week or two on scaling. You won't have a proper, load-balanced cluster. Your servers will be on fire. Your engineering team will be firefighting for days. They'll have to learn Chef, haproxy, and countless other things they haven't been spending time with.

You'll most definitely be paying the price during your day-to-day operations. Your deploys will cause downtime. Deploys will be frowned upon. Your engineering won't be happy. They'll have to stay late to deploy something that should've been deployed as soon as it was ready.

Companies that manage everything from deployments to automated scaling are saying, "Hey, sysops is important to us. It's a core competency of our business. We get huge value from it." If you're trying to imitate them and you don't have anyone focused on sysops, you're not ready. Companies like Facebook get huge value from their data centers. They need them. If you're not ready to hire someone with a specific focus on the subject, you don't.

The argument for small businesses and PaaS is a numbers game - in a good way. You might think it's more expensive at first, but it's not. Here's an easy list of things we receive from Engine Yard:

• Someone to talk to when a weird problem pops up
• Someone to be on the lookout for security patches
• Someone to ask about scaling
• Someone to alert us about server maintenance on EC2
• Someone to improve our server configuration

That's just the short list. When you start to think about the amount of value you get from a PaaS, it's enormous. It's far cheaper than what you would be paying someone in annual salary to be your sysops guy.

Spring cleaning your code base

Code rots over time. While you're busy adding new features to your app, you might be forgetting to throw out the old. This is a friendly reminder to sweep out the garage and get rid of the things you don't need.

You don't have to scour through every line of code to get results. Here are some areas you may be able to score a quick win.

Move any third-party assets in `app/assets` to `vendor/assets`. Putting third-party assets in your `app/assets` directory is generally a mistake, and that's ok. Clean up and put them where they belong and you'll be fine.

Remove any CSS files and/or rules no longer being used. The level of detail you achieve here depends on how much time you want to spend. Removing unused CSS may be as simple as removing some files you're no longer using. If you want to dive into removing rules, there's a great tool for that called deadweight.

Remove old JavaScript files. This is usually easy and difficult. You'll probably find at least one library or plugin no longer in use. Just remove it - that's the easy part. If you have a bunch of your own custom JavaScript i.e. a Backbone application, you may need to comb through it a bit more to find out which parts are not in use.

Get rid of legacy models/database tables. A few legacy models may have leaked into your code base early on in the life of your app (when you're under rapid development). That's ok. Figure out what they are and get rid of them. Write a migration to remove the table, too.

Find any unused partials. If you're refactoring quite a bit, you might forget to remove some unused partials. Check out this gem to remove unused partials.

Three ways you can bend the ransack gem to your liking

In the world's best yoga studio software for independent yoga studios, we have a page which lists all people in your studio. It's super basic: it only shows their name and role at the studio along with some actions you can take i.e. edit, delete. We haven't improved it much along the way.

I wanted to change that. TULA, in its essence, is a yoga centric CRM + billing system. Armed with inspiration from Intercom and their brilliant list of people, I set out to improve our people page.

We've had requests from our customers like "show me all the students who haven't been to class since X date" and "show me all the students who have joined the studio since Y date". These are great questions to ask and TULA should give you the answers. It's as simple as that.

To give them this, I did some investigation and found a great gem called ransack (if you haven't already, check out the ransack GitHub page). I quickly became satisfied with ransack as the basis of this new page. However, there were a few things I was constantly fighting with.

Ransackers derived from column aliases

This frustrated me for some time. I had a query like this:

I wanted to use their role, last attendance date, last purchase date, and join date as sortable columns in the table. However, it wasn't working out of the box until I realized I could simply pass an Arel node (thanks to this GitHub issue) of the column alias to a ransacker.

Default sort order

You can also use ransack to set a default sort order for when your users first visit the page.

Nulls last with ransackers

When you start sorting by column, you'll quickly notice null values getting in your way of the important data. For example, if you're sorting by the last time a user has made a purchase, you'll most likely want to see an order like this: about an hour ago, three hours ago, one week ago, etc. You wouldn't want to see an order like this: never, never, never, never, ... , about an hour ago, etc. The important data is getting buried by the nulls.

Ransack doesn't support this by default. However, there's a workaround (read more about how to add nulls last to ransack).

The workaround is great; however, it doesn't immediately work when you're using ransackers which return an instance of `Arel::Nodes::InfixOperation` or similar. You'll see a generated query similar to the following:

Obviously, this isn't valid SQL. This is actually due to the `full_name` ransacker defined above and in this case, the default sort order set to `full_name`. However, `Arel::Nodes::InfixOperation` responds to `to_sql`, so you can test for this case and transform it into valid SQL for the query. The code below will show you how:

Ransack is powerful, and we're just scratching the surface of its power. If you think I missed anything important, just mention me on Twitter or add a comment below.

Poker, business, and the optimal decision

When you reach a certain level of any topic, you realize how deep the rabbit hole goes. That's why the term professional, when used the right way, is so prestigious. When it comes to poker, the same is true. It's a deep game and most variants of pokers haven't achieved GTO (game theory optimal).

Sure, there's a generally agreed upon way to play most games of poker. Most often, aggression is the key to victory. But, most people think it's all about the numbers or the cards you're dealt; however, it couldn't be further from the truth.

Variables you must consider:

• The number of chips you have (money in the bank)
• The number of people still in the hand (people still in the game)
• The person on your left
• Your opponent's aggression
• Your opponent's lack of aggression (most incumbents)
• The number of chips in the pot
• The number of chips on the table (the size of the market)
• The person on your right
• Your opponent's range of cards (their people)
• Your cards (your people)
• The list goes on and on...

You use all of these variables to make a decision. You should always ask yourself: What's the optimal decision? If you don't make the optimal decision, you might get lucky and still win. However, you're definitely more likely to lose.

If you do make the optimal decision, you're slightly more likely to win - but you could still lose. That's the catch.

Just like poker, business follows along. You can make all the right decisions, and you can still get unlucky. On the other hand, you can make a bad decision with luck on your side.

The best we can do is make optimal decisions. The optimal decision is the one which gives us the greatest chance to win.

And like business, poker is a long-term game. Over the short-term, any victory or loss is almost certainly due to a high amount of luck (variance). However, when you stretch your decisions over many years, the person making the most optimal decisions reduces the amount of luck effecting his results.

An example of this in business is the moat. Over many years, a company makes optimal decisions, creating many different mechanisms by which they keep their competitive advantage. Compare this to the company just starting out with one product. They need some luck to stay alive.

Even though we can try, it's impossible to always find the optimal decision. Your opponent may be great at altering his play to trick you into a less than optimal decision.

Sometimes the optimal decision is to just go with it. The same is true for business. Sometimes you just don't know what to do. That's ok. Make the decision and be ok with it. The important part is to reflect and study that decision. Knowing what you know after the fact, was it the optimal decision? If yes, you were lucky. If no, figure out why. Armed with that knowledge, you should be able to move toward more optimal decisions in the future.

Product Market Dance

I've never really liked the phrase 'product-market-fit'. It's never felt right to me, in the same way the phrase 'passive income' doesn't feel right. They both imply that that you get to a point of stillness at which everything stops and you're 'done'.

But that's not how the economy works, and it's certainly not how technology companies and software work. 

Today's product/market fit might be tomorrow's myspace. The market is constantly shifting and evolving, and so too are the products that serve them. It's wise to remain focused, but not at the expense of missing an entire market shift that kills your company. 

Markets are alive, we have new devices and new pieces of hardware at our disposal and with more coming. Not only this, people's expectations change. Like the changing beat of a song as it reaches a climax and comes back down again, so too does the market, and your customers fluctuate.

Today's Minimum Viable Product is tomorrow's starting point. Interestingly, today's failure can be tomorrow's success too, because there is such a thing as being too early.

Here's another secret: within markets there are different songs playing. Our biggest competitor to Tula is a half-a-billion dollar company in what they call the 'health, beauty and wellness' category.

That's one song I suppose. Another? Independent Yoga Studios.

There are many songs playing in every market. 

There's no such thing as product/market fit unless you're talking about a short time horizon.

For anything longer, it's a dance.