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.