Ted Dziuba's take on Hubot
github.com
github.com
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.
NoSQL doesn't have to mean new and trendy.
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.
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.
A bug in any piece of software is going to cause issues, Hubot isn't an exception.
* As tombell pointed out, you don't need Redis
* The docs are ok but compared to just ranting docs for this fork they're awesome.
* The docs for IRC usage have moved - https://github.com/nandub/hubot-irc/
* Who cares if Hubot is over-engineered? It has tests. This ranting fork has none. Moving on ...
Redis requirement seemed to be strickt based on the docs when Hubot first hit HN
Agreed on ranting, but docs are not OK. Docs talk about how awesome it is, but not about how to get it running
Those docs were not there AFAIK when it first hit HN.
Just because something has unit tests does not mean its paradigm is sound or that it scales or is reliable.
This "fork" is not great either by the criteria I use. On top of that both are simply for fun projects not billed as bullet proof battle hardened pieces of software. However, I can see the OP's point of view: Hubot is over-engineered, with a convoluted deploy process outside of Heroku and other design shortcomings. The OP attempted to improve on the idea with a different design, and arguably failed.
1. Download the latest version from the downloads section
2. Install dependencies with `npm install`
3. Export any environment variables for your adapters and/or scripts
4. `bin/hubot -a <adapter>`
That's as simple as it is to run in a terminal. You can use many things to manage the actual process e.g. Foreman/Upstart/Forever.
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.
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.
I think it would get considerably more interesting if you brought in a bunch of people from other disciplines as well. Exposure to alternate disciplines and the models they create for the world is, I think, one of the most valuable things one can do to enhance their understanding of their preferred field of study.
I sort of assume the entire field of Bioinformatics developed out of a couple of colleagues from Biology and CS having a beer and a similar situation unfolding.
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
I'd also like to s/TWENTY/THIRTY -- I keep forgetting what year it is. I'm way too young to be this curmudgeonly!
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.
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.
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.
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.
1: http://www.reddit.com/r/programming/comments/l0ml6/nodejs_ha...
For some good times, check out his original trolls from Uncov: http://web.archive.org/web/20081017084932/http://uncov.com/
Maybe if the guy invents the transistor we'll listen to him long enough to get the formula, and if he amasses Ty Cobb's batting average we'll probably elect him to the Hall of Fame (but, perhaps, neglect to remember where we put our tickets to that year's ceremony), but even these things don't excuse being a jerk. They just coexist with the jerkishness, uncomfortably.
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.
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.
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.
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.
Consider the security implications of arbitrary commands like he suggests, instead of using, I dunno, SSH or whatever.
If an attacker has access to Hubot, then they already have access to everything the Hubot server can do.
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.
Edit: which isn't to say that his hack isn't cool, but he's still a jerk.
Hubot is cool because it takes advantage of the surrounding ecology. Ditching that is a bad design decision, pure and simple.
Plus there are a good number of modules available nowadays for node.js if I don't feel like reinventing the wheel.
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.