Requirements for a Text Editor

These are my minimum requirements for a competent text editor. The list is meant to serve as a quick litmus test for true understanding of tooling in the craft of writing software.

  1. Navigate with ease; jumping to line number, move to top/bottom of file, selection/deletion helpers (inside of quotes, block, function, etc)
  2. Fuzzy file finder + jump to mentioned files / methods
    • I use ctrl-p to fuzzy find in vim (one of my must have plugins)

    • For part of my day rails.vim provides handy helpers to jump from model to controller using custom commands like :Emodel, and :Econtroller. When not working with Rails I can typically rely on ctags to do the trick and allow me to gf around projects at will (hard to beat Command+Click inspection in RubyMine)
  3. Run spec(s) without having to Alt+Tab
    • I use vim-dispatch to run tasks in the background and have the results returned in the vim quickfix window
    • When running a single test or named context I can use a custom hotkey to select the test name under the cursor and create the dispatch command to run
  4. Find Regex pattern within file (replace, count, etc)
    • I’m lucky enough that my editor has %s. Allows for a ton of options with the same simple DSL
  5. Search entire project (git grep or Ag inside the editor)
    • Results should be returned in easy to parse format with jump-to-file capabilities
  6. Organize code into tabs / windows / panes
    • This should come with all editors now but please know how to vsplit if you claim to be a vi user..
  7. View git changes within file (+/- on line numbers) and basic git workflow integration (git blame, commit/push without leaving editor)
    • I use vim-gitgutter to track changes to the file. This has become a staple of my vim config and I couldn’t imagine working without it.

    • For the rest of my git functionatlity I use Tim Pope’s `vim-fugitive’, serves as a wonderful git wrapper for the majority of git commands.
  8. Customizability
    • This is the whole reason I am a vim user. I love the ability to change almost all facets of the editor; from basic config options in .vimrc to adding autocmds to change functionality for events within the editor (file open, file save, etc). In my mind an editor should allow the user to tailor the tool exactly how they want it.

It’s important for anyone writing software to respect the craft and maximize the effectiveness of the tools we use to create. Since the editor is such an important tool in our toolbelt we should always strive to optimize and improve our daily usage.

Replacing Heroku

For anyone still on Heroku and throwing addons at your application please stop and seriously reconsider what you are doing. Across the board things are getting a bit ridiculous for the average hobbyist / fincially conscious company. I used to be quite the Heroku fanboy but after my recent experience with Hosted Graphite I have changed my tone completely.

I was recently looking to add some Graphite metrics to a Heroku application that I’m working on and stumbled across a solution called Hosted Graphite. There was of course a starter package which shows off the beauty of Grafana and a few metrics to give you an idea of the potential. The current pricing can be found here (this prices do fluctuate quite regularly depending on the service); I’ve also gone ahead and added the current prices as of writing this below:

Each price point adds a few key features to the mix + increases your metric limit (this is a bullshit number stored by whatever service you are using so feel free to push it without too much fear. I’ll do a follow-up post on my experience with a MongoDB solution that had a document “limit”). The paid features for Hosted Graphite are as follows:

  • Daily Backups (>Tiny)
  • Data Retention (>Tiny)
  • Hosted StatsD (>Small)
  • Account Sharing (>Medium)

For most folks that are looking to use Graphite in their application they are probably looking to use some StatsD wrapper to report metrics. If you only have a few data points that you care about and can deal with the low retention rate / backup policy then maybe you could add an aditional worker to handle the task and not have to deal with a “hosted StatsD” solution. Even with that stretch of the imagination you are looking at a $19 monthly solution but most likely going to be suckered into a higher cost if you seriously start to add metrics.

Rather than paying for a plugable addon I’d highly recommend spinning up your own Digitalocean server for $10 bucks and get as much value as the Small package (this is being very generous..) being offered on Heroku. If you don’t know how to spin up a Graphite+StatsD server there is no excuse with the resources provided by DO alone:

Assuming that you can get through a basic set of steps then you should have a working Graphite+StatsD service at your disposal with 1/2 the monthly cost. The interface will be exactly the same (API key/namespace + service endpoint) and you will have the freedom to manage the server as you please. And when you are measuring things you sure as hell don’t want things to stop reporting because a reporting mechanism fails and you have no way to tell..

This is another major gripe that I have with Hosted Graphite; why would I pay for a service like “hosted statsD” when it will fall over and I have no debug info into why that might have happened. When testing with a Small instance of Hosted Graphite the StatsD endpoint would become unresponsive for minutes at a time while UDP/TCP were working as expected. On the other hand with a droplet you have the freedom of config (and Graphite, Carbon, and StatsD have a lot of configuration).

Configuration brings me to the final point I want to make. “Features” like Data retention length are nothing more than configuration that can be managed when setting up your Graphite instance. By configuring carbon you can set custom retention policies on different data points (regex matching FTW) and ensure that you have the policy in place that makes sense for the data being stored. This gives you the freedom of full flexibility inside of a problem-set that you are actively engaged in when adding measurements (naming new metrics). As a best practice you should set a reasonable default and add new metrics into the appropriate policies as needed.