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!

Why you should donate to the Django fellowship program

Disclaimer: I do not represent the Django Software Foundation in any way,nor has anything below been endorsed by the DSF. The following opinions are my own, unsolicited rambling.

If you hadn’t been looking for it specifically, you may have missed it. The Django Softare Foundation is running a fundraising effort for the new Django Fellowship program. It sounds like they’re still trying to figure out how to get the word out, so I wanted to do what I could to tell you why you should chip in.

This particular blog post is going to focus on encouraging (peer-pressuring) commercial Django users in particular, though enthusiasts are welcome to read along!

Humble beginnings

Django is free and open source. Just provide the expertise and the infrastructure and you can build just about whatever web powered contraption you’d like. So you end up doing just that.

Your first stop is the Django tutorial, written and maintained by a community of volunteers (just like the rest framework itself). You stumble along, slowly at first. Perhaps you find yourself frustrated at times, or maybe things move along at a faster pace. In no time, you’ve got “Hello World!” rendering, and here comes a business idea!

One hundred lines of code turns into a thousand, then five thousand, and beyond. You start seeing signups, and revenue begins to trickle in. You toil away at your codebase, making improvements and dealing with the “accidental features” that crept in during one of your late night dev sessions.

You could have built your business on one of any number of frameworks, but you chose Django. You like how it’s a very productive way to build a web app. You appreciate how it’s not impossible to find Django developers to work with you. There are probably some things you don’t like, but you might not have the time to work on fixing them yourself. You’re just busy shipping and growing.

But it could be better still!

You’re happily using Django, it serves you well. There are a few things you’d love to see fixed or improved, but you don’t really have the time or expertise to contribute directly. As luck would have it, all of the Django core developers have day jobs themselves. Things would progress much more quickly if we had someone working full-time on Django…

Enter: Django Fellowship Program. The idea is to fund at least one Django developer to work for the DSF part or full-time for a while. During this fellowship, said developer sets aside some or all of their other responsibilities to focus on improving Django. The DSF, in turn, pays the developer a fair (but low rate) for their work.

As per the Tim Graham’s recent retrospective blog post, we’ve see some huge leaps forward for the project during these fellowships. These are periods of focus and rapid improvement that everyone (including your business) benefit from.

The only problem is that we’re not going to see the benefits of this program unless it gets (and stays) funded. A well-funded fellowship program could mean one (or more) developers working on Django full-time at any given point in time. That would be huge for the project (and you and I).

Why you should donate

As a business, we are donating to the fellowship program to see one of our critical components improved. Due to the fellowship application process, you can be assured that your money will be paying a capable, trusted developer to get things done.

Consequently, you can view a donation to the Django Fellowship program as an investment with an almost assuredly positive return. If you are making money with Django, consider making a (potentially tax-deductible) investment in what may be the foundation of your business.

At the end of the first full day of fund-raising, there are precious few commercial donors listed in the “Django Heroes” leaderboard. Let’s help change that!

If you don’t hold the purse strings at your business, get in touch with someone who does and tell them about this investment with near-guaranteed returns.

Let’s play: python-gotalk

A recent HackerNews post announced Gotalk, a simple bidirectional protocol.I can imagine your collective eyeballs rolling. “Oh great, yet another half-baked way for… things to talk to one other”. But keep following along, maybe you’ll see something you like. Here are some highlights:

  • By Rasmus Andersson - You may know him from his work at Facebook, Spotify, and Dropbox.
  • Bidirectional — There’s no discrimination on capabilities depending on who connected or who accepted. Both “servers” and “clients” can expose operations as well as send requests to the other side.
  • Concurrent - Not too earthshattering, but this is a non-blocking, multiplexed protocol.
  • Debuggable - ASCII-based wire format. You can, of course, encode your payloads any number of way, but you’ll have an easy time with your packet sniffers and debug tools.
  • Pretty damned simple - There’s not a whole lot to Gotalk. A handful of message types. A pretty simple, easy-to-parse wire format. Nothing crazy for terminology or concepts. If you were curious about network protocols and wanted a gentle intro, this would be a great one to look at.

The official Gotalk repo has a bunch of examples and even some helper libraries in Go and JS. The official implementation is in Go, with the JS libraries being built on top of WebSockets.

But what about Python?!?

“But Greg, I too want to play with this fledging version 0.0 protocol! And I want to do it in Python!”

You, my friend, are in luck! I have a rough, version 0.0 Python module to go with this new, version 0.0 protocol.

For now, most of the effort is on message serialization and deserialization. We’ll be keeping that separate from any of the naughty bits (sockets, IO, and other things). The goal is to provide some reusable components that people can tinker with.

And more importantly, I haven’t ever bothered to mess around at the protocol level very often. This has been a great excuse to play around with a spec that is just getting started.

Pull requests, issues, suggestions, and the whole lot are welcome. Tell me how bad I screwed up!

Closing notes

If it wasn’t already evident, do not use this for anything but tinkering right now!.

Also, to stem the tide of “Well, why didn’t you just use X instead?”, this is a fun little experiment for me. Yes, I wrote a protocol serialization/deserialization for funzies. No, I’m not mentally ill.