

Ted Dziuba's take on Hubot - johns
https://github.com/teddziuba/hubot

======
IgorPartola
There seem to be lots of people here that are offended by the "Node.js cancer"
line. I am not defending his choice of words, but in TFA he wrote "Unix can do
that all by itself with out all the stupid Node.js cancer.". I take it as,
"there is no reason to have node.js involved since simpler tools can
accomplish the same task". This says nothing about Node.js itself. In fact,
try re-reading that same sentence but substituting a different technology from
the following list: [MySQL, MS SQL, PHP, Perl, Visual Basic]. Does it sound
slightly more reasonable now?

From what I gather his gripe was with the fact that the original Hubot was
over-engineered. I agree that it was. Not only that, but the original Hubot
came with almost no useful documentation, and a pretty horrible bootstraping
mechanism (scripts that download other scripts onto a server over HTTP should
never be run in prod environments). Getting it to run one step away from how
it was intended (specifically on IRC) required digging deep into the code
since the command line options/environment variables that were supposed to be
passed in to make it tick were not exposed in any docs. This _daemon process_
did not background itself properly, writing a PID file, etc. The whole thing
was a cool proof of concept, but running it in production would make me very
nervous. On top of that, it did require Redis, for some ungodly reason. SQLite
would have been a much nicer choice since it's much more easily obtained (at
least on CentOS) and does not require a separate process or having to
configure. (Offtopic: has anyone had good experiences with SQLite style no-sql
data stores? Something like MongoDB, but storing stuff on disk and accessing
it in-process?).

Don't get me wrong. Hubot is awesome. It's just that it's only awesome at
GitHub, where it integrates into all sorts of ecosystem _and_ the culture. I
tried it for an afternoon, and by default it comes with no useful plugins
(mustache generators notwithstanding) because the plugins are the trivial part
when you have a great infrastructure already. Imagine if I handed you the
source to bash, but you and everyone you know uses MS DOS. Yes, you can see
that bash has potential to be powerful, but until you have utilities like
find, ls, grep, awk, sed, ed, cat, and so on.

~~~
tombell
News just in: cool and fun side project doesn't do things the 'serious' way.

Hubot doesn't "require" Redis, don't load the `redis-brain.coffee` script.
Problem solved.

Hubot is a framework for building your own useful things on top of it. Sure it
doesn't provide a billion and one ways to do useful thing, you add those
yourself. If it doesn't work for you, don't use it simple as.

Given it is a fun side project a company can use, I don't think the concept of
"production" or "development" comes into it. You just run it. Plenty of people
have run it without issues, and anyone that have had issues has been helped to
have them resolved. Feel free to send a pull request to improve documentation
rather than just slate it :).

Hubot is what YOU make it, not what you can just download and hope it brings
useful things to your team.

~~~
IgorPartola
I understand that Hubot is more framework than finished product. My point is
that when I am evaluating whether to implement it fir the company I work for
vs spending time and resources on some other side project, I am having a hard
time making a case for this particular framework.

As for production vs dev: Hubit is either your tool for deploying code or it
is not. If there are many ways to deploy the same piece of code you are doing
it wrong. Now consider being the Ops guy who has to deploy a critical security
fix and Hubot took a cigarette break because it never started properly or some
other bug in the code caused it to fail.

~~~
tombell
Understandable. But surely you would have a fall back way to deploy given your
main way doesn't work? I can deploy my apps via Hubot, but I can also deploy
them without Hubot because I have an abstraction that Hubot uses to deploy my
apps. And as far as I know GitHub have also something similar in place.

A bug in any piece of software is going to cause issues, Hubot isn't an
exception.

~~~
IgorPartola
Yes. And I agree that any piece of software in you stack can ahve bugs that
make life difficult. My issue is that (1) Hubot is supposed to be central to
your ecosystem and (2) when I looked at the code at first I saw a style of
deployment and docs that made me think that running it would be more trouble
than it's worth.

~~~
tombell
I am continually trying to help improve the deployment and documentation of
Hubot, and I even created <https://hubot-factory.herokuapp.com> that makes it
really easy to get up and running on Heroku.

~~~
IgorPartola
Cool. That's good to know. FWIW, this is the kind of project I would
contribute to, was my plant not so full currently.

------
snprbob86
Awesome. Love it.

Lately, I've been on a rampage of technological regression. The digger I deep
into many tools, the more I wonder "How is this better than
${RELEVANT_TWENTY_YEAR_OLD_TOOL}?"

I'm discovering that "worse is better" so many times, I've stopped searching
for what's new or popular in any problem space. Instead, I go looking for the
"history of" the problem space. Turns out, that tends to yield better
solutions.

~~~
Fluxx
I think a lot of it has to do with the fact that software engineering as a
discipline is so _huge_ that often times there are giant swaths of communities
struggling with concepts and how to solve problems that really smart people
already figured out the solutions to 25 years ago. Like how on the Unicorn!
blog post Github wrote a while ago, someone was amazed[1] that they hadn't
heard of known decades-old things like the pre-forking socket server.

It would be an interesting experiment to get a bunch of luminaries from
different computing disciplines in a room together and to have them all talk
about problems they have and see if anyone has any solutions.

[1] <https://github.com/blog/517-unicorn#comment-3124>

~~~
nupark2
I think what you're seeing here is endemic of teams of almost entirely junior
engineers with insufficient experience (especially in startups), rather than
the software engineering space being inordinately large.

Regarding GitHub's seeming rediscovery of the pre-fork model, I too was pretty
surprised -- largely because the model was long-since dated by the time they
opted for it, as it doesn't scale well on modern multi-core/multi-cpu
hardware. This original HN thread on Unicorn had a vibrant discussion on the
subject -- the differences of opinion seemed to boil down to experience and
subjective biases: <http://news.ycombinator.com/item?id=872361>

------
tanoku
What a brilliant project! It's enlightening to see more people follow the UNIX
way of doing things.

I was trying to migrate to this awesome new bot, but I found this little
issue: with the bot idling in ~10 rooms and ~30 plugins installed, this
version of Hubot spawns and kills and average of 200 processes per second
(most of them shells, Node, Python and Ruby interpreters), even when nobody is
addressing Hubot directly. This peaks at up to 1000 processes/second. It's
killing my computer!

I wanted to open an issue on Tedd's fork, but unfortunately he disabled the
issues section. Oh well. I'm going to keep pondering a workaround for this,
because there has to be one. Writing real time network applications in Bash
can be hard, but so is the UNIX way.

~~~
judofyr
You can use "the UNIX way" and have one process per plugin. Simply create two
FIFOs per plugin and have a long-running process connected to those two FIFOs.

~~~
tanoku
Great suggestion! I've started implementing that, and now I only have 30
running processes and 60 pipes for my chat bot. That's much more reasonable,
but I still have a small issue: each plug-in FIFO blocks after each request!
The plug-ins that perform web requests block everybody else from marking a
request to the same plug-in while the previous request is being processed...
And some of those requests can take several seconds, or even timeout!

This is turning out to be much more complicated than I had originally
expected. With the UNIX way saying of "using the right tool for each job", I
kind of wish there was a tool to build scalable network programs... Oh well,
until that comes along, I'm going to stick to Bash.

~~~
judofyr
Can't you read the output (from the plugin) in the background?

~~~
pak
In bash? Good luck. Your main problem is that by creating two FIFO's per
plugin daemon in your design, any long-running request in a plugin will hold
up other requests to that plugin. Unless you go ahead and implement an async
I/O stack or threaded architecture inside each plugin. (Starting to sound more
like Node.js...)

He's using chipper sarcasm to illustrate the point that rewriting things "the
Unix way" may produce a great troll fork on Github, but more up-front
engineering is absolutely justified if you anticipate the need to scale.

To get more to the point, Unix pipelines in shell scripts are nifty but
absolutely not designed to scale in the ways that a typical networked server
process does.

I happen to agree with him; if the only point of hubot was to be a campfire
bot with a plugin architecture, you could probably accomplish that in 5 lines
of Ruby that would never see the light of day in a production environment.

------
dhotson
Wow.. is it really necessary to slag off someone else's project like this? Is
it even fair to name your project after the original if it's completely re-
written?

I don't know Ted—and he may make some valid points—but after reading the
README the lasting impression I have is that he's a complete asshole.

Keep it classy folks.

~~~
natesm
This the guy that wrote "Node.js is cancer", he basically admits to being a
troll in reddit comments[1] as well. I don't care if Node.js is good or not
(well maybe I will if I end up using it some day) but calling it cancer is
unproductive linkbait that degrades discourse in the programming community.
This isn't much better.

1:
[http://www.reddit.com/r/programming/comments/l0ml6/nodejs_ha...](http://www.reddit.com/r/programming/comments/l0ml6/nodejs_has_jumped_the_shark/c2oterg?context=3)

~~~
igorgue
You sir take it too seriously... just "lol" your way out, if you after reading
the README think the author meant "Node.js is "cancer"" for reals, then you
lost.

~~~
random42
The guy wrote this: <http://teddziuba.com/2011/10/node-js-is-cancer.html>

------
MicahWedemeyer
Must be tough to find time to get your work done if you're constantly a slave
to fixing other people's "shitty" code without being asked.

I've got a few half-baked ruby gems sitting on github, so maybe Ted can
rewrite those and then call me an idiot. After that, come reinstall the sink I
put in the kitchen and call me retarded.

~~~
mechanical_fish
And I'd like to personally thank whichever HN readers submitted and upvoted
this hate-filled piece of trollwork. Now I feel miserable and sad to be here,
and my Sunday has just started. Troll mission accomplished!

~~~
moe
Can we get out of sissy-mode for a moment?

He states his opinion on a piece of software. I don't see him insulting
anyone. No rivers need to be cried.

Better yet, he backs it up with an impl that he thinks is better, so you're
free to tear that apart and call it even more shitty.

~~~
Confusion
Can we cut out the ad hominems for a moment? This is not about being a sissy;
not about getting your feelings hurt.

These kinds of diatribes get tiresome real fast. The information density is
inversely proportional to the amount of foul-mouthing going on. It makes me
not want to read it, just like I don't like sieving through toxic mud to find
some specks of gold. It's unnecessary and doesn't add anything. It merely
detracts from what was achieved and makes it less awesome.

First you had some gold, now you've covered it in toxic mud before giving it
to me. And don't give me "be grateful anyway, otherwise you would have had
nothing". You don't cover what you give to beggars or your favorite charity in
toxic mud either. It's extremely uncivilized and everything will say you're an
asshole if you do. This is no different.

Thanks Ted, love the code. Too bad about the toxic waste you've covered it in.

------
LeafStorm
For the love of Notch, why on Earth do people continue to write full-fledged
applications in shell?! Shell may be Turing-complete, but it has crappy
syntax, just about NO data structures, and you have to fork and exec a process
just to check whether a string contains a substring or something simple like
that that a _proper_ programming language could do without even any system
calls!

~~~
random42
Ted's perspective on this: <http://teddziuba.com/2010/10/taco-bell-
programming.html>

------
gexla
Interesting project, I will give it a run. Thanks!

His comments against Hubot were probably just for getting a laugh, but I'm
pretty sure that Hubot was a side project which started as an idea mostly for
screwing around with NodeJS (maybe just as a learning experience.) That the
project actually turned into something useful (and actually used) was probably
unexpected. The same developer who created Hubot may have done this different
in other circumstances. I don't know the history though.

~~~
davidw
Getting a laugh at the expense of other people's hard work is poor form where
I'm from.

------
phzbOx
HuBot is part of the github culture and they have fun hacking with it. They
even open-sourced it so that other people can hack on it too. I hate how this
guy demolishes this project..: "This is a fork of GitHub's Hubot that's
substantially _less shitty_." I find it kinda ironic how he forked _github_
repository, hacked on the bot and then called it shitty.

~~~
icebraining
I think it's the philosophy of "all software is shitty, some are less shitty
than others"; it's basically the same mentality of suckless.org

------
joshu
Wait, he wants to type commands into a chat system to have it do a deploy and
thinks that somebody else's architecture is odd?

~~~
weavejester
GitHub's Hubot does this too, and I don't think it's a bad idea. It's very
similar to typing commands at a terminal, and has the advantages of being
innately asynchronous, and telling everyone else in the team what you're
doing.

~~~
joshu
Sure. It is convenient.

Consider the security implications of arbitrary commands like he suggests,
instead of using, I dunno, SSH or whatever.

~~~
weavejester
Well, (a) he's not suggesting that, and (b) even if he were, it doesn't seem
like a huge deal.

If an attacker has access to Hubot, then they already have access to
everything the Hubot server can do.

~~~
joshu
If they can TALK to hubot. So whatever the security is on campfire, or
whatever it is.

~~~
william42
Campfire's a webapp, so presumably https.

------
tcarney
This project seems much more accessible since shell scripting is a more
fundamental glue language. But if you read Zach Holman's post[1] on glue
languages he makes the point that JavaScript is becoming a glue language, so
you can start to see why github used Node.js for their implementation. Github
built a tool that fits their culture, Ted took the idea and went back to the
basics. To each his own.

[1] <http://zachholman.com/posts/glue-languages/>

------
secoif
"... to add a plugin, you just need to put the executable in the plugins
directory. You do not need to restart Hubot."

We noted this was a problem as well and put together a script loader. This
won't modify your hubot configuration permanently, but does allow you to try
out different plugins before committing them to your installation. Just add
the 'script' plugin to your project, then use "script load x" to load any
script on the fly.

------
luminousbit
I'm certainly not keen on Ted's anger at Hubot. But I think he's generally
correct that it is far over-engineered for what it does (as is most up-and-
coming web software today). These problems HAVE been solved before!

~~~
mnutt
I see this as a classic case of "look, I took your billion lines of awful code
and turned it into 4 lines of beautiful code!" but the new code does a tiny
subset of the original, and isn't extendable in any of the original ways.

Edit: which isn't to say that his hack isn't cool, but he's still a jerk.

------
lysol
I usually like Ted's posts but this is past the valid criticisms of Node.JS
and into pure troll. The real troll is that he wrote an overly complicated
command line interface to campfire. Watch me wave my arms around, I'm so
impressed.

Hubot is cool because it takes advantage of the surrounding ecology. Ditching
that is a bad design decision, pure and simple.

~~~
gcr
Ted's whole point is that Node.js ditches the environment of the UNIX system
surrounding it, instead doing everything from scratch.

------
jarin
Probably the main reason I'd still pick Hubot over Hubot′ is that it's quick
and easy to deploy to a free Heroku account.

Plus there are a good number of modules available nowadays for node.js if I
don't feel like reinventing the wheel.

------
weavejester
I really like this approach, but he should probably give it a different name!
There's nothing left of the original Hubot.

------
piotrSikora
...and why exactly does it depend on bash instead of sh?

~~~
Tobu
I was going to say that bash has a lot of features making it easier to write
safe scripts without the kind of workarounds you see in autoconf scripts, but
this bot doesn't appear to use them, even obvious things like [[. bash is
still a pretty good default.

------
app
If you're looking for a less functional Hubot that's been around for years,
why not use Last.fm's irccat? <http://www.metabrew.com/article/how-we-use-irc-
at-lastfm>

It already does the whole "kick of a script with these params from irc" thing
and can easily be piped to from any langage that can open a port.

------
collypops
I was hoping he'd add a Fibonacci command. Ah well, one can dream...

------
tombell
Wait, no tests? Think some should be added to be brutally honest.

------
william42
You know what I dislike about this the most? That it's a _fork_. It's not a
fork. It's a completely different project.

