May 8, 2015

My experience with analytics & measurement:

The Analytics Cycle

May 6, 2015

I've been getting into Ruby & other software engineering talks lately, as they complement my usual diet of quantum physics, neuroscience, and social psychology lectures. I'm not actually that smart, a lot of it goes over my head, but sometimes I get concepts and other times they prompt me to poke through Wolfram Alpha, Wikipedia, etc.

Anyway, Technical Talks:

Starts off with some fun ranting about some bad code, then gets real. Fantastic.

How people on dev teams interact, and how to maintain sanity.

How to design your Ruby gem so people will actually want to use it.

How to make sure your open source project doesn't die, and actually get other people to contribute.

Why estimation is important and how it goes wrong.

Gets into some of the low-level capabilities the Ruby engine gives you. I thought I knew a lot about Kernel and Object methods, but this taught me otherwise.


I guess most of these are "soft talks" in that they aren't about some new library or specific functions of programming. But these topics are critical to working on a team. Even if you know some or all the material, it's worth a refresher course now and again.

May 3, 2015

I had the pleasure of attending RailsConf 2015 this year with my company Hired.

It was exhausting.

That's the biggest thing I learned - I haven't been to many tech conferences, and I've only once been paid to fly somewhere else on business. The factors added up, and I spent nearly every minute tired, exhausted, and not so functional.

  • 5-hour flight on Monday
  • Jet lag
  • Being out of my familiar places
  • Going to talks all day, and trying to learn something at each of them
  • Socializing during any breaks or downtime
  • Syncing up with the team
  • Trying to bang out some code here and there
  • The Hired semi-official after party on Weds

For an introvert like me, that kind of chaos took everything I had.

The upshot was, there were some great talks, and I met a lot of cool fellow Rubyists. We bounced ideas and war stories off each other during lunch & breaks, talked about our respective companies, and made the place more of a community than a business conference.

Favorite Talks

The videos are up on ConFreaks, who are by far the best conference-talk recording people I've ever seen. Some of my favorites:

A few of my notes

  • DHH's motivation on Rails is making a framework for small teams the does 90% of what you need. Twitter took this as him crapping on microservices and front-end frameworks, which he did a little bit. I respect that motivation, as that's what let me pick up Rails and do cool stuff with it in the first place. And for small teams (<100ish) it allows everyone to be self-sufficient.

  • He mentioned Writeboard as a terrible experience developing a microservice. Couldn't agree more - it was a PITA to use. I've gone down a similar path with at least one team, and the added overhead becomes awful.

  • If you're running an open source project, respond to ALL pull requests within 48hrs. If you wait more than a week, they'll never contribute to you again.

  • Don't hoard the keys to your open source project - make sure someone else has access to the domain, can publish the gem, etc.

  • Kubernetes is pronounced kübêrnêtēs - thanks to Aja "Thagomizer" for the clarification. And the quick intro to Rails on Docker.

  • Model callbacks in Rails 5 will not halt the callback chain unless you explicitly throw(:abort) . For a ridiculously long discussion why, check out this ginormous PR.

  • From Koichi - keyword params are still 2x slower than normal params (30x slower on Ruby 2.0)

  • I left the "Crossing the Bridge" talk on Rails with client-side js frameworks. The architecture he outlined (ActiveRecord, ActiveModel::Serializers, ng-rails-resource) is terrible. 20x the overhead of server-side rendering, and your client-side app ends up a disastrous mess.

  • I did get to talk to Mike Perham, the creator of Sidekiq. We had an interesting chat about memory usage and ruby GC. I was hoping that the OS would clean up memory used by a separate thread -- ie, ending a sidekiq job cleans out memory much faster than letting ruby's GC run. Unfortunately, that's not the case, and there's still no real way to predict when ruby GC will run, short of calling it manually.

Mar 20, 2015

On the second day of Elastic{ON}, I woke up to an email from my VPS provider saying that my server was participating in a DDoS attack. Network access had been suspended, and I needed to back up any data and kill the server. I had console access via their portal, so I logged in.

Turned out ElasticSearch was the culprit. I found a bash console running under the elasticsearch user, so I killed all their processes (and Elasticsearch). If you are not on on the latest version, you need to be. And if you have dynamic scripting on (the default in previous versions), you need to make sure it's off.

I didn't have much of import on there anyway, so I just blew away the server. Then it was time to figure out a new, more secure setup. I use this server to try out quick apps I do on the side. They don't take very much in terms of resources. Usually they just need a basic app run, and a service like Postgres, Redis, or Mongo at very low scale. There's no reason to have one or more servers per app.

Heroku has the auto-sleep thing, which sucks, and not all addons are free at the intro tier. For example, Found.

My first thought was Docker, because it's the new hotness.

  • Dooku is the simplest solution, but it seems to be very oriented towards having one app.
  • Deis seems production-ready, but it's very focused on having multiple servers
  • Flynn has single-server examples, but no way to add "appliances" (stateful applications) besides Postgres

While I could run just base Docker, I just can't justify having to do these things manually. For now, I'm sticking with the "just a linux box" architecture.

Enter chef-solo. I'd been itching to write a setup & config script for a while, especially since my apps have so many components in common. Upstart, monit, logrotate, cron jobs - it's way better to have this stuff in a repo than just sitting on a server somewhere.

Plus, the recipes for the most part come with secure defaults and recommended best practices right in the REAME. My final repo stack ended up using:

This made it super easy to write some chef scripts, run a test build on a Vagrant box, and then deploy it to my shiny new dev server. My blahg here is running on nginx on it, since it's built with Jekyll, Grunt, and rsync, modified from the super-nice yeoman generator.

My new setup is hopefully more secure, and won't be going down again for a while.

Dec 2, 2014

Why? Because job security. See also: Coding in Emoji with Swift

Nov 21, 2014

Mattel® released "Barbie: I Can Be A Computer Engineer" back in 2013. It was apparently the most sexist Barbie book ever. Barbie is totally incompetent - she infects her and a friend's computer with viruses, only makes the "designs" for a game and relies on male friends to code it, and then takes all the credit for the eventual game.

It made waves this week; somehow people only noticed it now. Mashable did a great writeup, and the book got hundreds of one-star reviews on Amazon before being de-listed. The internet continues to rag on it via the #FeministHackerBarbie hashtag, taking pages out of the book and re-captioning them.

I am seriously cracking up. Here's one of my favorites via Livelyivy:

#FeministHackerBarbie

There's also a tool for making your own version, and it's great. Here's mine:

#VertexShaderBarbie

Nov 20, 2014

I've been trying to find a good WYSIWYG editor for simple CMS I'm building. My project just needs to make static pages - you know, /about, /faq, etc. The idea was that even if a developer had to write the HTML, anyone could go in and fix a typo or add a paragraph. My requirements for the html editor were pretty simple, I thought:

  • Produces mostly clean HTML (no <font>, <span style="ugly: yes;">, etc )
  • Forces Word, RTF, and HTML paste into plaintext, or at least something not horrible
  • Assigns classes for p, h1, hr, etc (or has hooks so I can add it in)
  • In-place editing mode
  • Minimal dependencies

Of course, you can't just use contentEditable directly. The Guardian has a great run-down of inconsistencies they found while building their back-end.

As has ever been the case, there are dozens of js libraries to do this sort of thing, and figuring out which ones are even worth investigating is a huge and draining process. Unfortunately my go-to for this sort of thing was out. Readactor is excellent, with a good API, good documentation, and readable code. But it's not free, and I want to release this as open-source.

  • TinyMCE - I got burned badly enough by this back in the PHP era
  • CKEditor - if anyone can show me a list of configuration options and their variations for this beast, I'll be impressed. A list of events I can hook into, and I'll be stunned. Some of the worst documentation I've ever dealt with. And look at the freakin' Rails plugin - better hope you use CanCan, Pundit, Mongoid, and want to slap in an extra controller.
  • WYMeditor - sounds interesting, but the mid-90's design isn't inspiring
  • Etch - backbone
  • Summernote - bootstrap
  • jQuery Text Editor - bare bones, and kinda crap docs
  • Hallo - links plugin isn't working. wut?
  • SmallEditor - angular
  • jQuery Notebook - can't even guess what requirements this will / won't need from reading the page and the docs - also needs font-awesome
  • Trumbowyg - wtf is with that name? "semantic" option is still in alpha
  • Morrigan - their demo page has scantly clad women! This must be a great editor! Yes, I played Dragon Age as well, but come on. Also v0.1-beta
  • Azexo Composer - drag and drop Bootstrap components, not quite what I wanted
  • Aloha Editor - beautiful page, but it really doesn't tell me a damn thing about how to use it, and their API docs are nil
  • Medium.js - no support for messing with classes or styles in the content
  • Scribe - not an editor, but a toolkit for building one. Built as AMD js modules, distributed via Bower, and everything is a plugin. Try building on this in a Rails engine, and you're gonna have a bad time.

The bottom line is that WYSIWYG editors for HTML are awful, and have been ever since Dreamweaver. I never thought about why it was an impossible concept until I read Nick Santos' article about Medium's editor.

Now I'm trying to figure out if I should accept an ugly, duct-taped-together interface for my CMS or just screw it and use Markdown.

Update

Got an email from the folks at Froala, which frankly looks pretty awesome. Good docs, html cleaning and class assignment. There is a distributable open-source version, so theoretically you could package it in to a project like this. But like Redactor, the "real thing" and un-minified source code are paid products.

WYSIWYG editors are hugely complicated, and this is one place I can totally justify paying for development tools and software. Compared to the time-sink black hole that is trying to roll your own, it's a steal.

Oct 16, 2014

Other post-checkout hooks try to auto-run migrations or bundling for you, but I feel like those are pretty error-prone. On the other hand, just getting notified is pretty helpful.

Copy + paste into project/.git/hooks/post-checkout

Sep 14, 2014

Very helpful. Difficulty not addressed: load testing in production.

Aug 28, 2014

Javascript is an interesting language. While Ruby has a style guide, and Python has a few (including Google's, they are not critical to how your code functions. They just help avoid those "strip whitespace" commits that touch every line in your repo and permanently ruin git blame.

With Javascript, the style is the substance. Take these two for example:

var object = {
    method: function(data){ ... },
    _variable: 3
};

object2 = {
    method: function(datae){ ... },
    _variable: 2
}

var Klass = function(){
    this.method = function(data){ ... };
    this.variable = 4;
    return this;
}

These seemingly small differences might not affect how a short script works, but they are critical to how your app works as a whole. The first declares a single object. The second declares a global variable. The third declares effectively a factory function.

Newlines can result in syntax errors for strings. Missing semicolons can ruin your JS after compression. Using reserved words as object keys can break your code in some browsers. Failing to use === can result in unexpected behavior.

It is essential to use a Javascript style guide. Frameworks like Express and Angular can help standardize things like object and module declarations, and CoffeeScript can provide syntax sugar to cover simple issues.

Otherwise, AirBnB's style guide is comprehensive and helps show best practices. Pick something, and stick with it, especially if you are working on a team.