Wednesday, November 18, 2009

Knot Pop Quiz

THE QUESTION
what knot is this? any idea?

THE ANSWER
Bowline.  In this form it's sometimes called a 'double bowline'.

In the old days this knot was used to tie the rope around your waist- no harness.  If the leader fell, and the rope didn't   break, the result was not pretty- broken ribs were common.   When  harnesses first came around the bowline, and later the  double  bowline, was the standard tie in knot. Some people still  use it  to tie in, it's supposed to be easier to untie after  being loaded  than a figure eight, but it has sharper bends in  it which means  it's a slight bit weaker than the figure eight.   Any bend in a  rope lowers its breaking strength, and the sharper the bend the  more the rope is weakened. The figure  eight has the least sharp  bends of any known knot, making it  the 'strongest'.  It is also  easy to tie and easy to  glance at  it and verify it is tied  correctly- which are the main reasons  it is preferred by most climbers today.

Note: This post was ghost written by me for "could have been my first guest blogger but refused" Neal Harder in response to http://twitter.com/sudarkoff/status/5836400206. aka I just copied his email response into this form since he's "allergic" to blogging. 

Wednesday, October 28, 2009

Twisted Reactor w/XML-RPC, POST, GET

Rewriting our Berkeley XMLDB services on Twisted, I decided to implement some couch db type interfaces like responding to post and get requests for DB actions. Oh, and don't forget the already in use xmlrpc interfaces to stay backwards compatible! It was surprisingly simple after staring at the docs for a day or two, so I'm posting a piece of the code in hopes that the example makes it easier for people new to twisted. Below you'll find an example which not only covers the post/get/xmlrpc thing, but also has threadpools, deferreds, xmlrpc kwargs, and a reactor example. There are some pieces missing since the server is actually much more complicated but hopefully you get the idea. Bon appetite!

Thursday, January 8, 2009

Plone LDAP and 450% speed increase rendering page load time

"Where I be workin' now we's goin through trubles, perfomance troubles solved by ma jigga... me?"...

ok - so I can't rap. big deal, neither can you. point is that we have been investigating the curmudgeouness in our plone 2.5.3 custom archetypes based product and came across this gem of a performance fart. our setup is weird I confess and I would be suprised if this actually applies to anyone but nontheless, thar she is.

we have many different users base dns in active directory that share the same group dns (scalability reasons) that map to zope roles. so we make plenty o' calls to see groups members to list them. turns out that this setup had something weird: our manager dn had permission to list other portals dns members but not to retrieve them. so if our user dn from one portal instance was "OU=AWESOME,DC=WE_ARE" and another was "OU=OK,DC=WE_ARE", they could share a groups DN of "OU=EDITORS_GROUP,DC=WE_ARE". The query to ldap for members of editors group would then return all user it can list, not edit, from both portals since they share this gruoping. Seems harmless enough right?

WRONG

(that could not be dramatic enough).

so for each user that comes back from the groups listing, there is a call to get that user. if that user call fails (i.e. the permission fails) the user is just ommitted from the list. so if those two portals each have 50 users in them, then there are 100 calls to get users from either portal, even though only 50% are accurate. oh, and each call is 1/10th of a second each.