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.
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.
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.
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.
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.
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.
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.
For a in-process key-value store, I'd use BerkeleyDB [1], I think it's pretty much the default solution and it's used by plenty of projects. The free license is copyleft, though, and the commercial license is pricey.
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.
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.
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.
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.
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.
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.
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
> 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.
Ah, proofreading never catches those because you know what you meant to write. You pretty much just have to wait for someone to point it out. It was funny, though!
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.
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.
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.
Since when is there an ability, let alone a need, to "back up" gratuitous rudeness? Is there a certification that qualifies one for that?
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.
You make a good point. What I meant was that, yes, Ted's a dick. He says enough interesting things in the midst of his dickishness for me to justify continuing to read what he writes.
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.
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!
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.
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!
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.
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.
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.
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.
"... 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.
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!
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.
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.
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.
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.