I'm sitting in the airport with my lovely wife (who's watching me type this) waiting to board my flight to Montreal. I'm quite excited to attend my first PyCon, indeed my first large conference ever. If you're going to be there, let me know! Hit me up on Twitter (@jeffknupp), email me at firstname.lastname@example.org or text me at (419) 455-6877. I'll be in town until Sunday afternoon, so please get in touch! Looking forward to meeting a few readers...
When someone asks why the
if __name__ == '__main__' idiom should be used, I
say it's because it makes turning your "script" into a "library" a seamless
act. Novices often write a series of one-off Python scripts that exist only as
long as it takes to finish and run them. More seasoned developers have accumulated a set of libraries they've written over
Last night I needed to properly parse a fully-qualified domain into its constituent parts (top-level domain, second-level domain, sub-domains). I found one library that looked promising, but it used a hard-coded list to represent all of the possible TLDs. The problem is this list changes with some frequency, and I needed to get it right.
So, fine, there's no third-party package that exactly fits my needs. Rather than just bolt on the domain parsing functionality to the application that required it, however, I turned it into a first-class citizen: a library (more accurately, a Python package). Heck, I even released it with unit tests and hooked it up to TravisCI.
Why would I take the extra time required to make this a reusable library? Two main reasons: first, this is a straightforward problem that should be solved once and never thought of again. Any time you encounter situations like that, do the right thing and write a small library. Second, because it's a general enough task, I wanted to make it available to others so that they didn't need to keep solving a problem that's already been solved.
As developers, we waste a ton of time on solved problems. Whether it's due to "Not Invented Here"-itis or general ignorance, I've seen entire systems duplicated by different teams in the same organization. I would argue that being able to sense when a problem likely has an open source solution is an integral part of being a "good" developer.
So in the interest of saving everyone a bunch of time, I wrote the package, released it, and am happy to accept bug reports (and will fix them). What's more, the library becomes another tool in my tool belt rather than a few random functions in a script I'll never use again.
As developers, we should be working together on the mundane stuff so that we can all go off and work on the cool stuff. Please, don't make other people solve your problem over and over again. Do it once, make a library, and release it to the world. You'll save all of us a lot of time.
Recently, I've seen a number of nice-looking blogging platforms pop up. Each basically let's you write your content in Markdown, shows you a live preview, and can keep posts unpublished until you're ready to bestow them upon the world. They all look nifty, but I'll never use them.
Why? I've been using blug, my Python-based static blog generator, to generate
this site for years. blug was designed with a certain workflow in mind (mine)
and has grown since then. I have a private fork of the public
blug repo where I
have all my settings and special templates. That repo is the one that sees the
most love (and I'm long overdue for a sync between the private code and the
public). But more importantly than
blug being tuned for how I work,
me something other blogging platforms don't: control.
kazu graciously offered to translate my article, What is a Web Framework into Japanese.
Here's the link to the Japanese version: http://rdepf.hatenablog.jp/entry/2014/03/31/150142.
A big thanks to
kazu for making the article more accessible to Japanese