
Hubot, “the hardest working GitHubber” - jfernandez
http://www.wired.com/2015/10/the-most-important-startups-hardest-worker-isnt-a-person/
======
forgottenpass
If 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?

~~~
anon4
Where I work at, Sir Jenkins receives more praise, scorn, veneration and
sacrilegious remarks than any traditional religious figure.

~~~
alexives
Same here. We love to hate jenkins.

------
KaiserPro
Aha, chatbots!

Brings back my days on IRC.

~~~
jarek
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."

~~~
t4nkd
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...

~~~
jarek
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.

~~~
Joof
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.

------
Domenic_S
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.

~~~
listenrightmeow
[https://github.com/listenrightmeow/dbot](https://github.com/listenrightmeow/dbot)

[http://pgarbe.github.io/blog/2015/03/24/how-to-run-hubot-
in-...](http://pgarbe.github.io/blog/2015/03/24/how-to-run-hubot-in-docker-on-
aws-ec2-container-services-part-1/)

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.

~~~
Domenic_S
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?

~~~
davewongillies
Then you just follow the installation instructions on your iron behind your
corporate firewall:
[https://hubot.github.com/docs/](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](https://github.com/spajus/hubot-control)

~~~
Domenic_S
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...](https://github.com/atmos/heaven/blob/master/doc/installation.md)

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.

------
javajosh
/askforraise 10%

