Ted Dziuba's take on Hubot

by johns • 15 years ago

130 65 15 years ago

dhotson• 15 years ago

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• 15 years ago

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

igorgue• 15 years ago

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.

aaronbrethorst2• 15 years ago

Ted is a dick, but he's generally able to back it up by walking the walk.

For some good times, check out his original trolls from Uncov: http://web.archive.org/web/20081017084932/http://uncov.com/

mechanical_fish2• 15 years ago

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.

snprbob862• 15 years ago

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• 15 years ago

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

jsolson• 15 years ago

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

nupark2• 15 years ago

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

StavrosK2• 15 years ago

Haha, I found your slip "the digger I deep" rather funny, thanks for the morning chuckle!

snprbob862• 15 years ago

Heh. And I even proof-read that post.

I'd also like to s/TWENTY/THIRTY -- I keep forgetting what year it is. I'm way too young to be this curmudgeonly!

joshu3• 15 years ago

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?

hboon• 15 years ago

GitHub uses hubot for deploys too.

weavejester3• 15 years ago

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.

joshu3• 15 years ago

Sure. It is convenient.

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

martinp• 15 years ago

We do this at my job too, although we use Jenkins and its IRC plugin. Very neat.

tanoku2• 15 years ago

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.

judofyr2• 15 years ago

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.

tanoku2• 15 years ago

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.

secoif• 15 years ago

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

jarin• 15 years ago

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.

gexla• 15 years ago

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• 15 years ago

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

weavejester3• 15 years ago

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

piotrSikora• 15 years ago

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

Tobu• 15 years ago

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.

phzbOx• 15 years ago

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.

icebraining3• 15 years ago

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

MicahWedemeyer• 15 years ago

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_fish2• 15 years ago

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• 15 years ago

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.

luminousbit• 15 years ago

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• 15 years ago

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.

LeafStorm• 15 years ago

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!

random422• 15 years ago

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

app• 15 years ago

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.

lysol• 15 years ago

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• 15 years ago

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

IgorPartola6• 15 years ago

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.

semanticist• 15 years ago

A simple file-based key-value store would be something like GDBM? It's been around since approximately forever and has been used in a ton of things.

NoSQL doesn't have to mean new and trendy.

IgorPartola6• 15 years ago

Agreed. I was thinking of an object store where you get to index properties of objects and perform arbitrary queries. New, old,etc is not a concern.

tombell5• 15 years ago

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.

IgorPartola6• 15 years ago

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.

cldwalker• 15 years ago

* I've been running this on heroku for free for weeks. Why would anyone be nervous about that?

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

IgorPartola6• 15 years ago

I would not be running it 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.

icebraining3• 15 years ago

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.

[1] https://en.wikipedia.org/wiki/Berkeley_DB

tombell5• 15 years ago

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

tcarney• 15 years ago

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/

collypops• 15 years ago

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

william422• 15 years ago

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.

Ted Dziuba's take on Hubot

Related Stories