Hubot, “the hardest working GitHubber”(wired.com) |
Hubot, “the hardest working GitHubber”(wired.com) |
So as long as I personify a piece of software, it too can become the subject of worthless press articles?
Brings back my days on IRC.
I read an article about Slack that praised their speed of integrating feedback and iterating with the following example: "the Slack team quickly identified small changes that had a big impact: Within the list of channels, they added fields for a description and the number of people using that channel."
Not that I totally disagree, but, signing up for Slack is easier than using NickServ for the average person. There's a bunch of features that make HipChat, Slack, Hall et al easier to use than IRC, especially for someone who doesn't want to learn anything new.
Just worth thinking about...
http://pgarbe.github.io/blog/2015/03/24/how-to-run-hubot-in-...
There are a couple articles/repos out there with detailed steps on running Hubot on AWS. While the ease and simplicity of deploying Hubot outside of Heroku is not a tenth as easy, there are a couple of options out there.
My team controls our hubots on iron behind a firewall with hubot-control, which can also create hubots for you too: https://github.com/spajus/hubot-control
> Heaven is a rails app that was designed to be hosted on heroku. https://github.com/atmos/heaven/blob/master/doc/installation...
Now we've got dependencies on node, npm, ruby, rails, heroku, some datastore, a queue for hubot, whatever your actual builder is (capistrano/chef/whatever) etc etc.
Right now I do all this with Jenkins+bash scripts. Inelegant and not as robust as I'd prefer, but so simple. I could just use a Jenkins adaptor for hubot, but then what's the point? I want locking environments, advanced permissions, and so forth.
I'm mostly complaining because I'm dying to implement chatops (mostly for slack-based deployments) but the information is really light, or the tools are too environment-specific, and I don't have people to bounce ideas/questions off of.
In general I agree that ease-of-use is a big factor. Having said that, I was witness to decidedly non-technical teens in a mid-size town quite happily using mIRC in 2004, so maybe we're not giving people quite enough credit. If you tell people something is hard to use they'll believe you.
The real lesson is to look into what has been done and worked before and see how it can be improved if you're looking for "new" ideas and businesses.
In contrast, I've never even heard of all the things mentioned above.
The easy of use of bots and flooding scripts was a downside, not an advantage.
Any web page that embedded IRC had to deal with that nonsense.
It's a social question. The most the tech did wrong was not making flooding impossible in the first place.
Server goes down? You see it quit on IRC or send an alert message nickalerting relevant admins when a service halts. Need live information on just about anything, just direct a message to a given server. Could even direct logs to a separate IRC channel for each type of service, relevant admins can join and set alerts up just based on message content and keep track of small logs via IRC logging too.
You can make a lot of low visibility processes very visible using such a setup. Of course, it wouldn't be appropriate for a giant company, but for a small to medium sized one I think it could work quite well. For devops types who are already comfortable with IRC at least.