I released v0.2 of Tunnel Boring Machine for managing SSH tunnels. The core of this release is a significant improvement to the configuration file for my needs and the needs of the people I'm currently working with, although you can read through the GitHub issues if you want to know more.
I feel like the configuration file format is also stabilizing, so I've documented it reasonably thoroughly. There isn't that much left on my planned scope for v0.3, so I'll probably get that out sometime in the next month or so, although I do have some other things on my plate that will have to get done first.
Showing posts with label github. Show all posts
Showing posts with label github. Show all posts
Friday, February 22, 2013
Friday, May 4, 2012
Hubot Project Automation
I'd been curious to try Hubot, a GitHub chatbot written in node.js that can interact with users in IRC, Campfire and other chat systems and do any number of tasks which are defined in CoffeeScript. I was interested in the project automation scripts that others had written and contributed to the hubot-scripts repository, such as the teamcity and jira integrations. I was also interested in discovering if having a hubot in our chatroom would encourage the adoption of chat within the project team.
Installation
It took a couple of hours to get set up and working with Campfire. There were a few gotchas and pieces of unclear documentation along the way, but soon enough I had my hubot installed and working, and I tried a few of the contributed scripts. It didn't help that the server on which I wanted to run Hubot didn't have node.js installed, so some of that time was the node setup.
Hubot Scripts
It's easy to find yourself staring at the github folder of contributed scripts, wondering what they all do. I encourage you to go look at the script catalog instead, which is a little more amenable to skim-reading. A lot of them are simple humor things which weren't really my area of interest for hubot -- I was more interested in fuctional integrations.
The scripts that are there tend to be pretty limited; if you wanted to do anything sophisticated, you're probably going to have to do it yourself. I was hoping for a little more, to be honest.
That said, the scripts look fairly easy to write, and if you're already familiar with CoffeeScript or you're interested in picking it up, I don't think it's going to be a big barrier to entry. It would be nice to have more sophisticated well-documented examples showing how to do a few things like respond to externally-triggered events.
In any case, much of the things I might want a hubot to do are going to be specific to the projects and environments of a particular project and company, and those things aren't going to be things that others will write.
Automating with Hubot vs. Other Tools
I haven't personally written any Hubot scripts, so I can only speculate at what Hubot would be good at and where other tools would be a better fit.
Looking at the technology and the kinds of integrations that have already been written, I feel like Hubot's basis in CoffeeScript and Node.js give it a lot of affinity with web technologies. That means that integrating with other systems using REST and JSON is pretty easy in a way that wouldn't be for shell scripts. If you're doing a lot of these kinds of integrations, you'd probably find that Hubot's a good fit. If what you really want to do is interact with the filesystem on a server, I suspect you'd find it easier to do that with shell scripts and build tools.
Encouraging Chat Usage
After trying out Hubot briefly, I'm going to have to say that I don't think it's sufficient to really encourage the use of chat. If you're already using a chat room, then being able to invoke those things from the chat room you're already in and in a way that's visible to the rest of the team is potentially worth the trouble.
If you're not in a chat room already, then everything you might have a hubot do is probably simpler to do with shell scripts, build tools (e.g. maven, ant, rake, make), and custom command-line programs (e.g. awesome-cli-ruby) than loading a chat room and using a chat robot.
Thoughts
Hubot is a neat bit of technology. If you're already using team chat, and particularly if you're distributed I'd definitely suggest checking it out. But if you're not using team chat, then I don't think that Hubot will be the driver that will make that happen.
Installation
It took a couple of hours to get set up and working with Campfire. There were a few gotchas and pieces of unclear documentation along the way, but soon enough I had my hubot installed and working, and I tried a few of the contributed scripts. It didn't help that the server on which I wanted to run Hubot didn't have node.js installed, so some of that time was the node setup.
Hubot Scripts
It's easy to find yourself staring at the github folder of contributed scripts, wondering what they all do. I encourage you to go look at the script catalog instead, which is a little more amenable to skim-reading. A lot of them are simple humor things which weren't really my area of interest for hubot -- I was more interested in fuctional integrations.
The scripts that are there tend to be pretty limited; if you wanted to do anything sophisticated, you're probably going to have to do it yourself. I was hoping for a little more, to be honest.
That said, the scripts look fairly easy to write, and if you're already familiar with CoffeeScript or you're interested in picking it up, I don't think it's going to be a big barrier to entry. It would be nice to have more sophisticated well-documented examples showing how to do a few things like respond to externally-triggered events.
In any case, much of the things I might want a hubot to do are going to be specific to the projects and environments of a particular project and company, and those things aren't going to be things that others will write.
Automating with Hubot vs. Other Tools
I haven't personally written any Hubot scripts, so I can only speculate at what Hubot would be good at and where other tools would be a better fit.
Looking at the technology and the kinds of integrations that have already been written, I feel like Hubot's basis in CoffeeScript and Node.js give it a lot of affinity with web technologies. That means that integrating with other systems using REST and JSON is pretty easy in a way that wouldn't be for shell scripts. If you're doing a lot of these kinds of integrations, you'd probably find that Hubot's a good fit. If what you really want to do is interact with the filesystem on a server, I suspect you'd find it easier to do that with shell scripts and build tools.
Encouraging Chat Usage
After trying out Hubot briefly, I'm going to have to say that I don't think it's sufficient to really encourage the use of chat. If you're already using a chat room, then being able to invoke those things from the chat room you're already in and in a way that's visible to the rest of the team is potentially worth the trouble.
If you're not in a chat room already, then everything you might have a hubot do is probably simpler to do with shell scripts, build tools (e.g. maven, ant, rake, make), and custom command-line programs (e.g. awesome-cli-ruby) than loading a chat room and using a chat robot.
Thoughts
Hubot is a neat bit of technology. If you're already using team chat, and particularly if you're distributed I'd definitely suggest checking it out. But if you're not using team chat, then I don't think that Hubot will be the driver that will make that happen.
Thursday, March 1, 2012
Moo 1.3 Released: Nested Updates and Collection Updates
I've just released Moo v1.3 with extensive new support for updating a graph of nested objects including collections. This allowed me to get rid of a class we were using in a production to manage the nested update, using Moo to update each sub-object, but not the graph as a whole. This has long felt like a weak area of Moo, and that class felt like a piece of code whose existence personified features that Moo should and couldn't do. As a result, I'm glad to see that class go away.
Moo is a project of mine for doing translation and update of objects from objects. While I encourage you to find a way to avoid needing to do this kind of data copying, if you can't avoid it altogether then I believe you'll find that Moo is a relatively unintrusive and yet reasonably powerful way to do these kinds of translations and updates.
I've also had a chance to flesh out the User Guide, add Release History and Community and Support pages to the wiki, and update the Moo website. You can get Moo from the github downloads page or from Maven Central repository.
Moo is a project of mine for doing translation and update of objects from objects. While I encourage you to find a way to avoid needing to do this kind of data copying, if you can't avoid it altogether then I believe you'll find that Moo is a relatively unintrusive and yet reasonably powerful way to do these kinds of translations and updates.
I've also had a chance to flesh out the User Guide, add Release History and Community and Support pages to the wiki, and update the Moo website. You can get Moo from the github downloads page or from Maven Central repository.
Subscribe to:
Posts (Atom)