Skip to content

All posts by moore - 31. page

Bare minimum of ops tasks for heroku

Awesome, you are a CTO or founding engineer of a newborn startup.  You have an web app up on Heroku and someone is paying you money for it!  Nice job.

Now, you need to think about supporting it.  Heroku makes things way easier (no racking and stacking, no purchasing hardware, no configuring apache) but you still to set up some operations.

Here is the bare minimum you need to do to make sure you can sleep at night.  (Based on a couple of years of heroku projects, and being really really cheap.)

  • Have a staging environment
    • You don’t want to push code direct to prod, do you?
    • This can be a free dyno, depending on the complexity of your app.
    • Pipelines are nice, as is preboot.
    • Cost: free
  • Have a one line deploy.
    • Or, if you like CD/CI, an automatic deploy or a one click deploy.  But make it really easy to deploy.
    • Have a deploy script that goes straight to production for emergencies.
    • Cost: free
  •  Backups
    • User data.  If you aren’t using a shared object store like S3, make sure you are doing a backup.
    • Database.  Both heroku postgresql and amazon RDS have point and click solutions.  All you have to do is set them up.  (Test them, at least once.)
    • Cost: freeish, depending on the solution.  But, user data is worth spending money on.
  • Alerting
    • Heroku has options if you are running professional dynos.
    • Uptimerobot is a great free third party service that will check ports every 5 minutes and has a variety of alert options.  If you want SMS, you have to pay for it, but it’s not outrageous.
    • Cost: free
  • Logging
    • Use a logging framework (like slf4j or the rails logger, and mark error conditions with a string that will be easy to search for.
    • Yes, you can use heroku logs but having a log management solution like papertrail will make you much happier.  Plus, it’s free for 2 days of logfiles.
    • Set up alerts with papertrail as well.  These can be more granular.
    • Cost: free
  • Create a list of third party dependencies.
    • Sign up for status alerts from these.  If you have pro slack, you can have them push an email to a channel.  If you don’t, create an alias that receives them.  You want to be the person that tells your clients about outages, not the other way around.
    • Cost: free
  • Communication
    • Internal
      • a devops_alert slack channel is my preferred solutions.  All deploys and other alerts go there.
    • External
      • create a mailing list for your clients so you can inform them of issues easily.  Google groups is fine, but use whatever other folks are using.  Don’t use an alias in your email–you’ll forget to add new clients.
      • do not use this mailing list for marketing purposes, unless you want to offload the burden of keeping the list up to date to the marketing department.
      • do make sure when you gain or lose clients you keep this up to date
    • Run through a disaster in your mind and make notes on how you would communicate the issue, both internally and externally.  How often do you update your team?  How often do you update your clients?  What about an internal issue (some of your code screwed up) vs an external issue.  This doesn’t need to be exhaustive, but thinking about it ahead of time and making some notes will help you in the crisis.
    • Cost: free

All of this is probably a four hour project, max.

But once this is done, you’ll rest easier at night, knowing you have what you need to troubleshoot and recover from production issues.

Cloud Computing Technology The Food Corridor Tips | moore | | 1 Comment

Machine sympathy vs human constraint

I had beers with an work acquaintance recently. He’s a developer of a large system that helps contact management. Talk turned, as it so often does in these situations, to the automation of development work. We both were of the opinion that it was far far in the future. This was three whole decades of experience talking, right? And of course, we weren’t talking our book–ha ha. I’m sure that artisan weavers in the 1800s were positive that their bespoke designs and craftmanship would mean full employment no matter what kind of looms were developed.

But seriously, we each had an independent reason for thinking that software development would not be fully automated anytime soon.

My reason:

It’s very hard to fully think through all the edge cases of development. This includes failure states, exceptional conditions, and just plain human idiosyncrasies. Yes, this is what every system must do. That’s right. Anything you want handled by an automated system has two options: plan for every detail or bump exceptional cases up to human beings to make judgements. The former requires a lot of planning and exercising the system, while the latter slows the system down and introduces labor costs into the mix.

This system definition is hard to do and hard to automate. I’ve seen at least five new languages/IDEs/software platforms over the years that claimed to allow a normal human being to build such robust automatic systems, but they all seem to fail in the short term. I believe that is because normal human beings just don’t think through edge cases, but those edge cases are a key part of software.

His reason:

When systems reach a certain size, abstractions fail (I commented about this years and years ago). Different size, different failures. But just as an experienced car mechanic knows what kind of system failures are likely under what conditions, experienced software engineers, especially those who understand first principles, have insight into these failures. This intution (he called it “machine sympathy”) is something that can only be acquired by experience, and, by its very nature, can’t be automated. The systems are so complex and the layers so deep that every failure is likely to be unique in some manner.

So, which one is more likely to remain a relevant issue. It depends on the organization and system size. Moore’s law (and all the corollaries for other pieces of software systems) works both for and against machine sympathy. For, because, as hardware gets better, the chances of system breakdown decrease, and against, because as hardware gets better, larger and larger systems get more affordable. Whereas I believe the human constraint is ever present at all sizes of system (though less present in smaller ones where there is less concern about ‘bumping up’ issues to humans, or even just not handling edge cases at all).

What do you think?

Programming Technology | moore | | Leave a comment

Dan Moore! Turns 13

number-437931_640Thirteen years ago, I wrote and posted my first blog post, about RSS. Since then, this blog has been a great journey for me: over 750 published posts and over 1300 approved comments.  I can’t even bear to count the number of spam comments!  It has been moved around three different blogging software platforms.  The world has obviously changed radically as well.

I’m not going to post any “best of” links, but I will say I’ve enjoyed blogging tremendously.  It’s allowed me to track progress in my career, test out ideas for books and engage with others. And, like all writing, blogging forces me to really think.

I wrote recently about why I blog (for myself), but I’m also very thankful for the emails, the comments and the pageviews.  Thank you, audience!

Who knows what will happen as my blog continues to grow up?

Blog | moore | | Leave a comment

Extending an existing Rails application that wasn’t meant to be extended

I am modifying an existing open source rails 4.2 app and wanted to keep my changes (some of which are to models, some to controllers, some to views) as separate as I can, so that when a new release of the app comes out, I won’t be in (too much) merge hell.

This app was not designed to be extended, which makes things more interesting.

For the views, I’m just doing partials with a prefix (_xxx_user_cta.haml).

For the models and controllers, I started out hacking the code directly, but after some digging around I discovered how to monkey patch (I believe that is what it is called) the classes.

In the config/application.rb file, I added the following code:

config.to_prepare do
Dir.glob(Rails.root + "app/decorators/**/*_decorator*.rb").each do |c|
require_dependency(c)
end
end

And then, if I want to make a change to app/models/person.rb, I add the file app/decorators/models/person_decorator.rb. In that file is something like this:

Person.class_eval do
# ... changes
end

This lets me add additional relations, helper methods, and other classes to extend existing functionality. I try to prefix things with a unique identifier (xxx_set_timezone rather than set_timezone) to lessen the chances of a collision, because if a method is added to the Person class with the same name as a method in the decorator, the decorator will win.

Write tests around this new functionality so that if anything changes, I’m aware and can more easily troubleshoot.

The downsides of this approach is that it is harder to track logic, because instead of everything in one file, it is now in two. (I don’t know if there are memory or performance implications.) However, that is a tradeoff I’m willing to make to make it easier to keep up with the upstream development and to pull said development in as often as possible.

I’m still fairly new to rails and didn’t know if this is the only or best way, but thought I’d share.

Rails Sharetribe The Food Corridor | moore | | Leave a comment

Early Product Lessons

fence-238475_640I wanted to jot down some lessons I’ve learned being an early stage technical founder of an unfunded startup, from no product or revenue -> product and revenue. (Of The Food Corridor, if you’re interested in the startup.) I had the luxury of a co-founder who had spent years immersed in the problem space and months researching the niche. If you can find that, it really really helps in product development.

That said, here are some other lessons. For an idea of our timeline, we did a build or buy or both evaluation in March, started building in April, did beta testing in May and launched June 1.

 

Determine features through demand/pull, rather than push

Once you have a product that you can show users, show it to them!

It will be embarrassing.  Record all their feedback and note patterns (we did a month of beta testing, as noted above). Then, let the user requests pull features from you, rather than push features to them. This serves a couple of purposes:

  • people will know that you are hearing them, and will be more forgiving of inevitable issues
  • you will build features that people want to use
  • you’ll develop a sense of users needs
  • you’ll learn to politely say no to requests that are off base/only useful to one user

Everything is broken

Everything is borked, all the time. At an early stage startup you just don’t have time to do everything right (nor should you, because the wrong thing perfectly engineered is a waste). So there will be features that are half done, or edge cases unhandled, or undocumented build systems. Do the best you can, and realize that it gets better, but make your priority getting something out that users can give feedback from. “Usage is like oxygen for ideas.” – Matt Mullenweg

You have to walk a fine line between building something quickly and building something that you can build on later.  Get used to ambiguity and brokenness and apologizing to the customer.  (But not too used to the apologies!)

UX/UI polish is relative

Our app is a number of open source gems smashed together with some scaffolded ruby code.  The underlying framework had a decent look and feel, but there are definitely some UI and UX holes.  I thought I’d have to spend some time working on those, but our customers thought the product was beautiful and useful.  My standards were different than their standards.

That doesn’t mean that the app can look horrible, but a plain old bootstrap theme or one of the other common CSS themes is ok. You need to know your audience–many people are stuck using a mix of software and are used to navigating clunky user interfaces. If your interface is just decent, but still solves the problem, you’ll be OK.  Of course, you’ll want to solve gross UX issues eventually, but a startup is all about balance.  A friend of mine gave me the advice: “don’t allow your users to make any mistakes”.

Favor manual process for complex edge cases

There have been a couple of situations during the build where a lot of work was needed to handle an edge case. For example, prorating monthly plans. Once you start thinking about prorating in depth, it turns out to be a really interesting problem with a lot of edge cases. But guess what?  For your startup, edge cases can be a wild goose chase.

When an edge case rears its head, you should consider the following options (in preferential order).

  • can you outsource the complexity (Stripe handles proration, for example, and I guarantee you they handle edge cases you don’t).
  • can you make it a manual process? If it doesn’t happen that often and/or a real time response is unneeded, you can often get by with a manual solution. This may be partly automated, for example, an SQL query that generates an email to a human who can handle the exceptional situation.
  • if neither of the above apply, can you defer it? Maybe for a few months, maybe for just a few weeks. But sometimes requirements change and you learn things from users that may make this edge case less important.
  • if all of the above don’t apply, you may need to bite the bullet and write code.

Back end and front end development doesn’t have to be synchronized

Most users equate the front end with the complete product. Most developers know that, just like an iceberg, there’s a lot of back end processing hidden in any project. But guess what? When you are getting feedback from users, some of the backend processes need to work, but many don’t. For example, we had a billing system that handled monthly invoices. We didn’t need to build the billing system while we were getting feedback from users on what type of charges they needed to handle. We did, however, need to know that we could build it. So make sure you can build the backend system to support your front end system, perhaps by building one path through, but defer the full build-out until you have to.

What about you?  Any tips for early stage product engineering?

Programming Rails Stripe | moore | | 2 Comments

The single biggest obstacle to running self hosted Sharetribe

dollar-1362244_640So, you checked out Can I customize Sharetribe? and determined you need a backend programmer? And that you’re going to self host, whether on Heroku or elsewhere? That’s great!

Let me let you in on the single biggest obstacle to running Sharetribe self hosted. (It’s not the biggest obstacle to building a successful marketplace–that is building the community and getting liquidity–but it is a big one.)

There’s no great option for taking payments on self hosted Sharetribe.

Braintree has limitations and can only support companies in the USA (I believe).

Paypal isn’t supported with the open source version.

No other payment processors are supported ‘out of the box’.

So, if you are charging nothing for your marketplace, or if you monetize your site in some other way such as a listing fee or using the marketplace as a captive market, you’re fine with the self hosted version.

Otherwise you are going to have to pay a developer to integrate with a payment processor. Here is what to think about when you are evaluating payment processors:

  • Do they support the currency I need to support? (Sharetribe only supports one currency per marketplace at this time).
  • Do they handle splitting payments?  That is, if someone pays $100, and the marketplace commission is 10%, $10 goes to the marketplace and $90 to the seller.  How is that handled–many payment processors don’t support splitting payments in the manner.
    • If you aren’t splitting payments, how are you going to get your money and make sure the seller gets theirs?
  • If I need payment escrow, do they support that?
  • Are there legal ramifications (taxes, fees, etc) that my marketplace has to handle with regards to taking money?

It’s worth looking at these:

And if you are interested in having Stripe connect in your system, I’m working on such an integration.  Please sign up for the list to be notified when it is ready to go.

Sharetribe Stripe | moore | | 5 Comments

Can I customize Sharetribe?

I’ve been talking to some people about customizing Sharetribe.  It’s a big piece of software and there are a lot of moving parts, but many of the people I’m talking to are business folks.  They chose Sharetribe because they have a marketplace in mind, and the software is just a tool.  However, all tools have their limits.

So, I thought it’d be fun to organize it as a ‘choose your own adventure’. Click the link to learn how to customize Sharetribe’s awesome marketplace software.

Sharetribe Useful Tools | moore | | 4 Comments

Example of customizing a marketplace on sharetribe.com

Here’s an example of some javascript code I wrote to customize a sharetribe.com marketplace.

This code adds a LinkedIn share button to the listing page.

Comments inline.

window.onload = function () {  // make sure you run after the document has been loaded, otherwise you won't have access to jquery.
	$( document ).ready(function() {
    		startcustomization();
	});
}

function startcustomization() {
	console.log("cust started");  // good old debugging log statements.
 	var d = document.createElement("div");  // adding a div to hold our stuff
	d.className = "listing-tweet-button"    // leveraging a existing css class

 	var s = document.createElement("script");  // inject a script tag
    	s.type = "text/javascript";
    	s.src = "//platform.linkedin.com/in.js";  // this code is all from https://developer.linkedin.com/plugins/share 
        var textnode = document.createTextNode("lang: en_US");
	d.appendChild(s);

 	var s = document.createElement("script");  // had to inject both script tags, otherwise they weren't executed.
    	s.type = "IN/Share";
	// commented out: s["data-url"] = "http://www.foo.com";  If you wanted to share a different page than the one that the sharebutton was on, you'd use this.  The share button defaults to sharing the page it is installed on.  
	d.appendChild(s);

	$(".listing-social").append(d);  // find where the other share buttons are, and append our div
}

 

You can, of course, stack as many interesting custom functions as you’d like into this script.  Do make sure you’re hosting the script on an SSL server (an S3 bucket will do fine) otherwise the script won’t be loaded, since sharetribe.com runs SSL only.

Sharetribe | moore |

Running costs for self hosted Sharetribe

I have one instance of Sharetribe’s open source platform self hosted, and I thought I’d share the costs around that.

This is hosted on Heroku. Why? It’s not the cheapest option, but it is the easiest option to get up and running with regard to developer time. It also is what sharetribe.com runs, so there’s less possibility of future incompatibilities. But I understand if you want to do all your own devops stuff (scaling, upgrading the server, backing up the db, etc) to save some bucks.

Anyway, on production, you’ll want to run a 2X dyno for the web dyno, and a 1X dyno for the css_compile and worker dynos. I run 1 2X dyno for the web, and a 1x dyno for the worker tasks. That means about $75/month, plus maybe $5/month for heroku run bash and css compiles. You can obviously scale up the web dynos as you need to.

And here are the addons I’ve found useful:

  • Cleardb for mysql, ‘drift’ level (make sure to be careful about your total db connections–each passenger process uses 5 and ‘drift’ only has 30. $49.99
  • flying sphinx for searches, ‘wooden’, $12. We have few enough listings that I’m not worried about deltas yet. $12
  • memcachier for caching. Been able to stay at the developer level for now, which is free.
  • new relic for monitoring and performance reporting. Been able to stay at the ‘wayne’ level for now, which is free.
  • papertrail for logfile review and alerting. Very valuable! Haven’t needed more than 2 days of logs, so am at the ‘choklad’ level, free.
  • heroku scheduler, which is essentially cron. Free.
  • sendgrid for emails, which lets us send 12k emails for free.
  • SSL addon, which lets us serve up the app under SSL with a custom domain name. $20

So, add these all up and you are looking at a running cost of $75+$5+$50+$12+$20 == $162 for a base level heroku install of Sharetribe (plus the SSL certificate, which is another $20, but is a yearly expense). It’s worth remembering that these will increase as you have more traffic and success.

Note, this is for production only. You probably want a staging server. I’ve been able to get by with free dynos for staging, though if you want to support/test full text searches or have a DB with more than 5MB of data in it, you’ll need to pay *something* for staging.

Sharetribe | moore |

Getting started with sharetribe development–vagrant style

I have recently spent a fair bit of time working with Sharetribe, an open source, MIT licensed marketplace platform that also powers a hosted solution.

First, let me say that the software is the least significant piece of a marketplace (like AirBnB).  The least significant! (Check out the Sharetribe Academy for some great content about the other steps.)  

But it is still a necessary component.  If you can get by with the hosted solution to prove out your idea, I suggest you do so–$100/month is a lot cheaper than hours of software development. There may come a time when you want to customize the sharetribe interface beyond what javascript injection can do.  If this is the case, you need a developer.  And that developer needs an environment.  That’s what this post is really about.

The sharetribe github readme explains the installation process pretty well, but I find it tedious, so I created a quick start vagrant VM. This VM has a sharetribe installation ready to go.  I use vagrant 1.6.3 and Virtualbox 5–google around for instructions on how to get those up and running. The guest VM is Ubuntu 14.04. This VM uses rvm to manage ruby versions, but I couldn’t be bothered with nvm. It will install sharetribe 5.8.0 and all needed components.

Assuming you have vagrant and virtual box installed, download the Vagrant file and put it in the directory where you want to work. Edit it and change any options you’d like. The options I changed were the port forwarding (I set it to 3003), networking options, and the amount of memory used (I allocate 4GB).

Then run vagrant box add http://www.mooreds.com/sharetribe/sharetribe-base-mooreds.box --name sharetribe-base-mooreds to download the file. It’s downloading a large file from my (small) server, so expect it to take a while (hours).

Then run vagrant init.

When you can login (password is vagrant if you use vagrant putty or you can use vagrant ssh) you can go to the sharetribe directory and do the following:

  • fork the sharetribe repo
  • update your git remote so that your origin is your forked repo (and not mine, because you won’t get write access to mine)
  • create a branch in your repo off of the 5.8.0 tag. There’s one startup script I tweaked a bit, but you can just ignore those changes.
  • update your mysql password: SET PASSWORD FOR 'root'@'localhost' = PASSWORD('MyNewPass');
  • start mailcatcher listening to all interfaces: mailcatcher --ip=0.0.0.0
  • start the rails/react server: foreman start -f Procfile.static
  • visit lvh.me:3003 and start your server
  • set up your local super user and first marketplace
  • edit the url you are redirected to to have the correct external port on it (from the vagrant settings): from http://testdev.lvh.me:3000/?auth=baEOj7kFrsw to http://testdev.lvh.me:3003/?auth=baEOj7kFrsw for example

This is running sharetribe 5.8.0, and I’m sure there will be follow on releases. Here’s how to sync the releases coming from the sharetribe team with your current repo. I’ve taken the liberty of creating an upstream branch for you.

This doesn’t cover deploying the code anywhere–I’d recommend this gist. Make sure you read the comments! Or I can install a vanilla version of sharetribe to heroku for a flat fee–contact me for details.

Rails Sharetribe Useful Tools | moore | | 2 Comments