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.
If you ride your genetic lottery winning privilege into success and then have a continuing history of pissing on people less fortunate than you, you must be a narcissistic ass.
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.
The commands right now attempt to map directly to unix equivalents where it makes sense. set, unset, & env are the traditional unix commands for modifying the environment.
The main problem I have with the flat, non-namespaced commands is that there will be far too many of them once we've implemented the full command set.
Anyway, as I wrote in my other comment, this is very early software and it has a long way to go before I'll recommend that regular Heroku users rely on it.
If you are willing to accept some excuses (one can hope?), our dev blog is running the yet-to-be-released version of HubSpot's new blogging tool and is very much a work in progress. Also, the pages served by that blog (and our CMS) are not related to the tool this post is talking about.
But nonetheless, we need to make it faster. Thanks for the feedback.
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.