Thursday, December 17, 2009
PyCon Talks
Hotels, venues, transportation, food, rooms, electric, schedules, invitations, visas, slogans, marketing, and talks. Lots of talks. So many talks in fact that it's difficult to choose a favorite. But I'm going to do it. Here I go.
I build big web systems for a living. I don't write web applications, I build the systems that host them. This involves a lot of systems engineering work and a lot of automation code. Generally everything from Unix account management and LDAP up through integration with external APIs.
All of this generates statistics, errors, warnings, and alerts. Furthermore, each component has it's own special way of presenting that information. Some write to nice log files, some display HTML pages, the list goes on and on. Since we also integrate with external providers, there's a small collection of SOAP, XML, REST, and proprietary integration points I care about.
So, you've probably figured out by now that I work for a service provider. As such, it's important that we know the state of our systems at all times. There are many subtle levels between "up" and "down." The problem though is that it's difficult to frame all of the data points we care about in a single and presentable page.
I currently use all kinds of random tools to extract status information. Awk, Python, a random screen scrape. It works, but my gut tells me there's probably a much better way to do it. This is why (drum roll, please) I'm looking forward to "Dealing with unsightly data in the real world." You know, if you'd like, you can probably learn how to queue up that drumroll programmatically via the "Remixing Music Pythonically" talk.
Now, while my personal favorite here seems to be more geared towards web servers and API integration, it's all the same in my book once it fits into a Python data structure. It will also be nice to hear folks speak about some of the same problems I have to deal with. Being the only Python developer here, it's nice to hear others chat about this stuff.
Oh, one more thing. I mentioned food earlier. The food is good. Being a block away, I was able to take part in some of the food tasting the hotel setup a few weeks back. Here's what we have to look forward to:
Not bad, eh? Not bad at all.
FizzBuzz, really?
Admittedly, I have trouble conjuring some of the "Comp Sci Basics" out of the depths of my brain when asked. How often as techies do we do things like write quick sort implementations or doubly linked-lists from scratch these days? But modulus math? Really?
This really beats the "why are manholes round?" style question, though.
I haven't interviewed in well over a year and a half. I don't remember the last time we hired new programmers or engineers, so it's been even longer since I've done an interview. I've always been impressed by organizations that put you in front of a workstation and step through small projects. Not only does that quiz your technical aptitude, it runs you through an abbreviated development process.
Friday, November 13, 2009
PyAtl: First Impressions & Helping with PyCon 2010
I've been a resident of the Atlanta metropolitan area for almost 14 years now. I've been a Python developer for about five years. Last evening was the first time I've allowed the two to blend when I attended my first PyAtl meeting. I chose to make this my first as Van Lindberg, the Chairman of PyCon 2010, was our distinguished guest.
First off, If you've never attended a Python user's group, I highly recommend that you do. I work in a group of between 6 - 8 developers (depending on your definition of the word "developer"). Unfortunately, I'm the only Python developer among us. I churn out Python & Linux platforms while the remainder of my team is working on .Net on Windows.
You can imagine how much I get to discuss my language of choice.
Being in that position, this was really one of the first times I've been able to actually take part in pure Python discussion. Most of my day job talks revolve around comparing it to certain proprietary components that I don't fully understand (ASP.Net, for example).
I wasn't new to the material, though I do believe Mr. Brandon Rhodes did a great job presenting during his talk on Data Structures in Python. I counted no less than three "Wow, I've never thought of using it for that" moments. Really. I was keeping track as to place a value on the evening. We'll make this a standing appointment. What a great group of guys (err... guys and one girl)!
Van did a wonderful job in highlighting how important the user group community is and how helpful we can be. He's right. I'm really looking forward to helping out this year and watching it all come together this February. It doesn't hurt that the conference halls are a five minute walk from my office!
Finally, this morning we got a chance to check out the conference facilities - and most importantly - sample the food prepared by the hotel chefs. The conference is worth attending for the high quality chow alone.
Tuesday, August 4, 2009
Regular Expressions
Tuesday, May 26, 2009
One of those rare posts...
A Brief, Incomplete, and Mostly Wrong History of Programming Languages.
Thursday, May 14, 2009
Odd Python Errors
Here are a couple of my favourites.
Metaclass Conflicts
There are a few reasons these might pop up, but one error message in particular seems to stand out. Each time I see it I've got to read through it a few times and mentally break it down into components.
Traceback (most recent call last):
File "t.py", line 44, in
class C3(C1, C2): pass
TypeError: Error when calling the metaclass bases
metaclass conflict: the metaclass of a derived \
class must be a (non-strict) subclass of the metaclasses \
of all its bases
Pfft? Wha? Ouch. The offending code is as follows.
class M1(type): pass
class M2(type): pass
class C1(object):
__metaclass__ = M1
class C2(object):
__metaclass__ = M2
class C3(C1, C2): pass #<--- Boom!
In other words, C1 and C2 each define a __metaclass__ attribute, but issubclass(M1, M2) and issubclass(M2, M1) both return false. Python raises a TypeError as the metaclasses are not in the same inheritance chain.
The following, however, does work:
class M1(type): pass
class M2(M1): pass
class C1(object):
__metaclass__ = M1
class C2(object):
__metaclass__ = M2
class C3(C2, C1): pass #<--- No Boom!
In this situation, issubclass(M2, M1) is true so Python is able to build C3 using M2. What happens if we add another base class to C3?
class M1(type): pass
class M2(M1): pass
class M3(M1): pass
class C1(object):
__metaclass__ = M1
class C2(object):
__metaclass__ = M2
class G(object):
__metaclass__ = M3
class C3(G, C2, C1): pass #<--- Boom!
Inserting 'G' into the mix causes the same error to occur.
Traceback (most recent call last):
File "t7.py", line 16, in
class C3(G, C2, C1): pass #<--- Boom!
TypeError: Error when calling the metaclass bases
metaclass conflict: the metaclass of a derived \
class must be a (non-strict) subclass of the metaclasses \
of all its bases
The same error, but why? M3 is a child of M1, so according to the above example, this should work, correct? Well, not really. Consider the wording of the above error message. The metaclass of C3 is not a subclass of all of it's bases. The fix?
class M1(type): pass
class M2(M1): pass
class M3(M2): pass
class C1(object):
__metaclass__ = M1
class C2(object):
__metaclass__ = M2
class G(object):
__metaclass__ = M3
class C3(G, C2, C1): pass #<--- No Boom!
Now the metaclass of C3 (M3) is a subclass of all of the metaclasses of all of C3's bases.
Layout Conflicts
This is another one of my favourites. I spent quite a while tracking this one down the first time it showed up.
Traceback (most recent call last):
File "t88.py", line 7, in
class C3(C2, C1): pass
TypeError: Error when calling the metaclass bases
multiple bases have instance lay-out conflict
The offending code is as follows:
class C1(object):
__slots__ = ('attr1', 'attr2')
class C2(object):
__slots__ = ('attr3', 'attr4')
class C3(C2, C1): pass #<--- Boom!
This one isn't quite so bad. The '__slots__' attribute is used when allocating heap memory for the new type. In general terms, pointers to the attributes defined in '__slots__' are inserted into the new type's structure. Since C1 and C2 both define '__slots__' and they're not from the same inheritance chain, the type structures differ. Thus, we have an instance lay-out conflict.
The fix?
class C1(object):
__slots__ = ('attr1', 'attr2')
class C2(C1):
__slots__ = ('attr3', 'attr4')
class C3(C2, C1): pass #<-- No Boom!
Note that it is entirely possible to add another class to C3's bases so long as it doesn't define any additional '__slots__' attributes.
Are there any other odd errors out there that trip people up? If you've got any, I'd love to add them to my little text file.
Monday, February 23, 2009
I keep killing my X server...
That said, I have a terrible habit of smacking CTRL+ALT+BACKSPACE while attempting to hit CTRL+BACKSPACE. Yeah, I know. One kills the previous word and one kills the X server...
I've never really bothered to plug that up. This morning, I did it again. I did some digging:
Section "ServerFlags"
Option "DontZap" "yes"
EndSection
There. Now I can hit the wrong combination all day long and I won't bounce my X session. What a helpful little config option.

