Hubot, “the hardest working GitHubber”
wired.comIf pieces of software count as workers, I guess there are at least a dozen of harder-working more-vital workers at github.
So as long as I personify a piece of software, it too can become the subject of worthless press articles?
Where I work at, Sir Jenkins receives more praise, scorn, veneration and sacrilegious remarks than any traditional religious figure.
Same here. We love to hate jenkins.
Aha, chatbots!
Brings back my days on IRC.
Everything old on IRC is new again.
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."
One time I asked why, since cgroups and the pattern of container based deployment had been popular for a decade before Docker started, that containers are so popular right now. We ultimately decided that someone constructing a really easy to use suite of tools around the concept was the reason it has all this love and growth.
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...
Replacing RSS with walled-gardens solutions from Internet Bigcos is another example.
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.
My friend's mom used irc in the 90's / early 2000's for dating chatrooms. IRC can be plugged into the browser and embedded into applications seamlessly.
In contrast, I've never even heard of all the things mentioned above.
The problem with IRC was the channel wars, the hierarchy of founder, ops, +v, etc, and the crazy medieval hierarchy that ensued from it.
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.
On Slack the channel owner will form a hierarchy too, if it's less problematic it's because Slack is usually used in a professional setting where flaming is generally frowned upon. You see these kind of issues pop up on the easy-to-use Twitter as well.
It's a social question. The most the tech did wrong was not making flooding impossible in the first place.
Having a botnet with all your servers really isn't a bad idea. I mean, easy admin access, live monitoring, the ability to query everything and have all interested ops people examine the output... pretty handy. Seems like it'd beat a lot of these monitoring services and tools people pay for these days.
Do you mean having a bot? I can't see how having a botnet would be relevant or helpful.
No, I'm referring to a botnet. In the OP case we've got just a single bot which controls things, I'm more thinking 1 bot per server sort of thing so you can administer individual servers simply by directing messages at them.
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.
check out https://github.com/andyleap/srvbot. Still needs to do real time handling, but you can run commands on multiple servers and optionally receive output
well, logging is now handled, so that's fun :)
It may not be malicious, but its definitely a botnet, especially given most botnets tend to use IRC for command and control.
I love the tech, but hate how heroku-centric it all is. If you want to spin up your own hubot+heaven instance somewhere not-heroku, glhf.
https://github.com/listenrightmeow/dbot
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.
I guess I'm lazy and want an apt-get/yum/brew recipe. What if I have to install it on iron behind a corporate firewall?
Then you just follow the installation instructions on your iron behind your corporate firewall: https://hubot.github.com/docs/
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
Right, but then you need some kind of deployment adaptor to do something useful (like deploying apps) -- Heaven's the recommended one, but
> 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.
There's always Supybot which runs basically anywhere :)
/askforraise 10%