This is the easiest-to-follow of the various Python logging guides/posts/docs that I’ve seen:
-
Archives
A few great things to read on REST (technical)
Jun 28, ’11
5:21 PM
I’m not sure how I missed this post by Jacob Kaplan-Moss, where he’s throwing the kind of REST question out there that has, in the past kept me thinking for hours:
It seems like URIs like /people/{my-uid}/photos and /people/{my-uid}/photos/{photo-id} are more “pure.” But now that’s weird because only one single user ever has access to a given URI (e.g only user #7 gets to access the entire space under /people/7). And the information in the URI is redundant with the information in the Authorization header.
Then things get really interesting in the comments, with links to two great posts (which I also missed):
The last constraint is incredibly simple, but nobody actually does it. It’s named Hypertext As The Engine Of Application State. I still haven’t decided how to pronounce the acronym, I always try to say “Hate ee ohs,” which sounds like a breakfast cereal. Anyway, let’s break this down. We’re using Hypertext, fine, that makes sense. But what’s it mean to be an engine? And application state?
…
Now, when I said ‘nobody’ does this, what I meant was ‘for APIs.’ This is exactly how the Web works. Think about it. You start off on the homepage. That’s the only URL you have to know. From there, a bunch of links point you towards each state that you can reach from there. People would consider it ludicrous if they had to remember a dozen URLs to navigate a website, so why do we expect the consumers of our APIs to do so as well?
Haters gonna HATEOAS
Finally, comes an elegant, much more RESTful solution to the API version dilemma:
You can simply define a new media type – say
application/vnd.mycompany.myapp-v2+xml– and associate new multi-email format with it. Clients can then request whichever format they want. Older clients don’t know the new media type so they get served the older single email format.…
Newer clients do know the new media type so they can have access to the new functionality.
VERSIONING REST WEB SERVICES
All three of these posts/discussions are worth reading, but if you only read one, read Steve Klabnik’s HATEOAS post.
Python 2.5 distutils, snow leopard and xcode making gcc happy
May 14, ’10
1:45 PM
As many Python folks have discovered, upgrading to Snow Leopard can cause some pain for development. For the most part, this involves reinstalling a bunch of things (macports, python itself and whatever python packages you use). This has been a hassle for me, but up until today it was just time consuming, rather than actually difficult. Apparently if you upgrade xcode (like I did for the new iphone stuff), unless you explicitly choose the old SDK, xcode blows it away.
So today, while trying to compile multiprocessor on Python 2.5, I got this:
Compiling with an SDK that doesn’t seem to exist: /Developer/SDKs/MacOSX10.4u.sdk
Please check your Xcode installation
Which left me staring at the screen thinking “how the f**k do I fix THAT?” After poking through every file in multiprocessor and then googling quite a bit I finally found this message on the epd-users mailing list, which got me to the promised land.
From what I can gather there are two ways to fix this. One is to reinstall xcode and choose to include the older SDK. The other (and possibly scarier, depending on your taste for mucking around inside installed stuff) is to point distutils at the newer SDK. I did the latter: in a text editor, open up:
/Library/Frameworks/Python.framework/Versions/Current/lib/python2.5/config/Makefile
Then find all the instances of MacOSX10.4u.sdk and change that to something you do have installed. To see them just do
$ ls -la /Developer/SDKs/
If there’s nothing there, well, then you need to install xcode or you’re SOL. There should be four places to make the change in the Makefile. Finally, the newer compiler doesn’t seem to like the “-Wno-long-double” flag, so I had to the delete that as well. And voila, multiprocessor compiled (and I hope any other Python package that I try to install that needed the gcc).
3 steps for the “cool” web frameworks to get a toe in the door at “enterprise-only” organizations
Mar 15, ’10
5:38 PM
There was a brief mention at the web framework battle royale at sxsw (twitter: #frameworkbattleroyale ) about Java and Enterprise environments and I was reminded of an old peeve of mine: the old enterprise vs. “cool” webby frameworks battle. I don’t want to jump into either the battle or the definition of “enterprise.” For the purposes of this post I’m simply going to define “enterprise” as “acceptable to institutions that only use software described as enterprise.” Realistically, we’re really just talking about Java and .net based platforms and frameworks vs. everything else 
Which brings us to what has always my been my pet peeve about this debate – Rails, Django, Plone, CodeIgniter, etc. – can implement a just a few features and become much more acceptable to these institutions. What are these organizations concerned with? Mostly, it’s compliance, oversight, accountability and, where applicable, adherence to things like PII and PCI.
I will also acknowledge that my thinking probably applies most to Django, since it’s what I know best and I think Python has the least steep hill to climb as a language (vs. PHP or Ruby).
So, what are these steps? To my mind there three things I see as going a long way towards acceptance:
- Content version control These organizations need document history. How many changes has a piece of content (text,html,image, whatever) gone through? Who made the changes, and when? I now include django-reversion in all our Django projects. It’s not my ideal solution, but it goes a long way and continues to get better.
- Object-level permissions out of the box I’m obviously picking on DJango in particular here and there has been a ton of discussion on this topic on the Django mailing lists. Usually the discussion goes something like “write on your own specific to your domain” or “write it and submit it for inclusion”. Fair enough, but that doesn’t change the fact that organizations, especially publicly held companies, really need read/write level object control over their content. Happily, the Washington Times has taken this on this task. Hopefully this project grows and continues to be supported and maybe even eventually can be included in core Django.
- Integration with existing authentication systems. Django has a great authentication framework. It would be even greater if there were some included batteries for things like Kerberos, which you can roll on your own, but it’s not the easiest thing to integrate with if you are unfamiliar.
Implementing these, or similar features in these frameworks would go a long way to getting a foot in the door at bigger organizations. These features would give internal employee stealth advocates (and trust me, they DO exist) some ammo.
Thoughts?
Okay, I’m fiddling with Scala next
Jul 7, ’09
12:41 AM
I’m sold on trying out Scala, after seeing James Strachan state:
I’m very impressed with it! I can honestly say if someone had shown me the Programming Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I’d probably have never created Groovy.
Strachan created the very cool Groovy and is one of the few big Java guys (along with Jerome Louvel) who has some good perspective on the language and has been doing cool stuff.
I even have a couple of small projects I’m fiddling with where I can try it out. For client work I will still be using Python and straight up Java for the time being.