fderp

I can't imagine a situation where you need to know analytics are being consumed in order to give users the data they want (unless the site in question is itself an analytics site).

To allow / cause your site to break when analytics aren't served is, in essence, attempting to enforce an unspoken contract between gathering user info and serving them data.

As far as I'm concerned, a site that doesn't work when analytics aren't served is a site I will literally never use.

Yes, it's completely impossible that this company has its own corporate culture, they're probably exactly like every other startup (to a laughable stereotype). Working 500 hour weeks, literally paid in peanuts, and if you go on a date instead of pushing a bugfix they crucify you.

Oh, you mean 'most days'. Now I get it.

Not responsive.... why even bother redesigning today with a separate mobile subdomain?

Yes because if you went to a 35,000/year high school and a $60,000/year college and now work in the tech sector, you must:

* be a "bro"

* have wasted your college years (doing keg stands, I suppose)

* be a narcissist.

Using the heroku client every day, I noticed this new client does not namespace any of the commands. Subcommands of hk are:

    hk create # create app
    hk destroy # destroy app
    hk apps  # list apps
    hk set    # set config var
    hk unset  #unset config var

Compare to heroku's (preferable, imho) commands:

    heroku apps:create    # create app
    heroku apps:destroy   # destroy app
    heroku apps           # list apps
    heroku config:set     # set config var
    heroku config:unset   # unset config var

The command 'hk set' doesn't tell you any semantic information at all about what it's doing - I prefer the original syntax for its convention of being explicit.

Other than that minor complaint, seems like a really cool project, going to look through the source later.

I would have a lot more interest in what this blog post said if the page actually had good performance.