drone-hipchat released. A HipChat plugin for Drone CI.

/

Since the Drone CI Plugin Marketplace didn't have one yet, I put together a quick plugin. It's written in Python instead of Go, so it won't ever be in the official plugin namespace, but it also requires substantially less boilerplate than the Go plugins. So we'll run with it because it's simple!

If this interests you, check out the Github repo and the documentation. You should be able to copy/paste that sample YAML and substitute your values. Since all Drone CI plugins are Docker containers, you'll get the benefit of automatic updates if/when I make improvements or fixes in the future.

I'm all ears for feedback, which you are encouraged to send to the issue tracker.

Progress update on python-gotalk

/

As covered in a previous post, I’ve been tinkering with a Pythonimplementation of the fledgling Gotalk. Since this has been fun to play with, I figured it’d be worth sharing where python-gotalk is, and what has happened with it in the last two weeks.

Upstream gotalk progress

Rasmus has created a new protocol v1 branch in the Gotalk repo, where all of the new hotness is landing. A few hilights:

  • Request IDs have grown from three bytes to four in response to requests for more potential permutations.
  • A new ProtocolError message type was added. This is sent when a peer doesn’t understand the protocol version specified by the sender. While I haven’t seen any specifics on how potential downgrades may work, this could conceivably be used to handle that in the future (maybe?). It is not clear if gotalk is striving for any kinds of backwards compatibility between protocol versions, so that’ll be something to watch.
  • The Go and JS example client/servers have progressed quite a bit.

python-gotalk updates

At this point in time, we should be current with the gotalk v1 branch wire format (as of the night of Feb 6). I haven’t started on any socket/state tracking stuff, and probably won’t until v1 is mostly solidified.

However, I’ve thought about keeping python-gotalk focused on just the message marshalling/unmarshalling. The socket/state tracking code will differ quite a bit depending on whether you are using Twisted, asyncio, Tornado, etc. It’d also mean that python-gotalk could avoid all external dependencies.

We’ll continue tracking the Gotalk v1 branch and see how it goes!

Progress update on python-gotalk

/

As covered in a previous post, I’ve been tinkering with a Pythonimplementation of the fledgling Gotalk. Since this has been fun to play with, I figured it’d be worth sharing where python-gotalk is, and what has happened with it in the last two weeks.

Upstream gotalk progress

Rasmus has created a new protocol v1 branch in the Gotalk repo, where all of the new hotness is landing. A few hilights:

  • Request IDs have grown from three bytes to four in response to requests for more potential permutations.
  • A new ProtocolError message type was added. This is sent when a peer doesn’t understand the protocol version specified by the sender. While I haven’t seen any specifics on how potential downgrades may work, this could conceivably be used to handle that in the future (maybe?). It is not clear if gotalk is striving for any kinds of backwards compatibility between protocol versions, so that’ll be something to watch.
  • The Go and JS example client/servers have progressed quite a bit.

python-gotalk updates

At this point in time, we should be current with the gotalk v1 branch wire format (as of the night of Feb 6). I haven’t started on any socket/state tracking stuff, and probably won’t until v1 is mostly solidified.

However, I’ve thought about keeping python-gotalk focused on just the message marshalling/unmarshalling. The socket/state tracking code will differ quite a bit depending on whether you are using Twisted, asyncio, Tornado, etc. It’d also mean that python-gotalk could avoid all external dependencies.

We’ll continue tracking the Gotalk v1 branch and see how it goes!

python-fedex 1.1.0 released

/

I am pleased (and somewhat embarrassed) to release python-fedex 1.1.0!Pleased in that these changes have been patiently waiting for PyPi for a few years now, embarrassed in that I’ve let the project sit since I stopped using it more than five years ago. Let’s re-visit that after we talk about the changes:

  • A quick PEP8 pass on most of the codebase. Yucky. (gtaylor)
  • Changing recommended install method to use pip + PyPi. (radlws)
  • Updated rate_request and freight_rate_request examples for WSDL v16 compatibility. (foxxyz)
  • Updated rate service WSDL from v8 to v16. (foxxyz)
  • Added a freight rate request example (mwcbrent)
  • Bump ShipService WSDL to v13. (mwcbrent)
  • Update rate example to show multiple ServiceTypes. (danielatdattrixdotcom)

If anyone who actively uses python-fedex would like to take over maintainership of the project, please get in touch. I have a super hard time getting psyched up about playing with these FedEx SOAP services for funzies.

A few of the things that need doing, which my younger self skimped on:

  • The module is in bad need of unit and integration tests. The FedEx WSDLs change periodically, and it’s not always in a backwards-compatible manner. The examples we already have would be a good starting point.
  • The label certification stuff should be cleaned up and checked over. The process still exists, but it may be different now.

If any of this sounds riveting (or you have other ideas of your own), please let me know and we can figure something out.

For the rest of you, enjoy python-fedex 1.1.0, in “development” for two and a half years!