Simple post this afternoon. We’re on Twitter.
You should follow us on twitter here.
Simple post this afternoon. We’re on Twitter.
You should follow us on twitter here.
Last week, I posted a new Twitter integration for AnthillPro. Integrating with Twitter wasn’t really a critical piece of Urbancode’s strategy for Anthill. We did have a new, exciting way to create integrations in the Plugin system and I wanted to try it out. Working with Twitter was just a straight forward way of testing out the new system.
Plugins in AnthillPro allow people with minimal programming skills, in any language, the ability to augment AnthillPro with new and cool integrations. It’s also allowing us at Urbancode more flexibility to create integrations. It’s easier and faster for us to write, and we can release plugins outside of the product’s release cycle.
All great in theory, but would it actually work? I knew it was already helping our developers. With the new static analysis integrations, they seem to spend as much time setting up the various static analysis tools than actually writing the integrations. I think one developer put together four of these plugins in a week. So, what about a guy like me who used to sling some code but has been retired from active development for a couple years in order to consult and do important blogging work?
It was pretty easy for me too. There were some bits of missing documentation, but discovering where those were (and letting the doc team know) was part of my mission in evaluating a prerelease feature. All told, I probably spent a day learning the system, writing the plugin and debugging. Continue reading
Using the plugin system that’s new to version 3.7, I wrote a little plugin that lets you send Twitter status updates automatically from AnthillPro.
AnthillPro can manage one or more Twitter accounts centrally. Any job can then include the “Tweet” step, which logs into Twitter as one of those accounts and updates the account’s status. Configuration just requires loading the plugin, creating an account, and telling the step what message to send up to which account.
This could be used as part of continuous integration builds, but probably makes more sense for larger events like a production release.