Remember not to register the same ZeroMQ socket with a poller twice or it will seem it’s hanging or processing every other message only – that’s a piece of advice I have for you after several hours of bug squashing 
Hm.. when I hear that ‘the research says the [Duqu] Trojan exploited a previously unknown vulnerability embedded in Word files, allowing Duqu to modify computers’ security protection‘, I just can’t help but imagine my opening a car, tossing a book on the back seat and then later on, being unable to use the brakes anymore because the publisher had used a wrong type of ink, one that makes the disc brakes vaporise immediately upon the book’s opening on page 51 when it lands on the seat.
That’s simply insane.
vNote cThat pThis vIs prpTo vDo prpWith nProgramming adjOnly advNot daThe nCountry pm! sml:-)
nTwo naThings vPrompted prnMe prpInto nWriting pThis pm.
prnI’ve adjRecently vSeen iaA adjPromising nJavaScript nLibrary cnjAnd prnI vWas intrjOh advSo advClose prpTo vStart vUsing cnjExcept prnThat cnjWhen prnI vHad iaA vLook prpAt adjIts nAPI adjMy nJaw vFell prpTo daThe nFloor pm- daThe nThing vWas vUsing daThe adjHungarian nNotation, vIncluding vPrefixing naFunctions prpWith iaAn nFn pm- advSo prnI vConsulted iaA nCalendar cnjAnd advYes pm, prnIt vWas advStill daThe nNear n2011 pm.
prnI vAm vWriting prnThis nPost advSo prnThat adjPotential adjHungarian nNotation naUsers vCan vUnderstand advHow adjSuch iaAn nAPI vLooks prpLike prpIn daThe nEye prpOf daThe nBeholder pm, prnI vAm advPerfectly adjSure penThey advJust vDo advNot vRealise adjWhat nSort prpOf nCommotion prnThey vCause pm. prnThere vIs adjNo nBeauty prpIn prnIt pm, vDon’t prnYou vAgree pm? intrjSo vPlease pm, vCan pwnWe vStop prnIt advNow pm?
prnI vRemember vSeeing adjSuch naThings prpLike n15 naYears advAgo cnjAnd advReally pm, adThe nWorld vHas advSince vChanged pm, prnWe vDon’t advLonger vUse nVi cnjOr nEd pm- intrjWell, advNot prpTo daThe advSame nExtent prpAt advLeast pm- prnWe vHave nAuto-completion pm, nSyntax vHighlighting pm, nCode vRefactoring pm, nUnit vTesting pm, adjContinuous nIntegration cnjAnd nWhatnot pm.
vLet’s vLeave daThe adjMundane nJob prpOf nType nInference prpTo naCompilers cnjAnd prpUnless daThe adjParticular nLanguage vDoesn’t vEnforce daThe nUsage prpOf prnThese naPrefixes pm, intrjWell pm, vLet’s advNot vDo prnIt advThen pm, advAright pm? naThanks pm!
prnAnother nThing vWas iaAn nSQLite nDatabase prnI vHad iaA nMisfortune prpOf vHaving vHad iaA vLook prpAt prnWhich vHad adjEach nTable conjAnd nColumn vPrefixed prpWith nTbl cnjAnd nCol advRespectively pm. prnI vMean pm, prnI’ve vSeen prpAt advLeast naDozens prpOf naDatabases pm, prpFrom nFirebird prpOn nWindows prpTo nDB2 prpOn nMainframe cnjAnd prnI’m advYet prpTo vConfuse iaA nTable prpWith iaA nColumn pm- prnIt vIs advOK prpTo vUse nUq or nIdx prpIn daThe naNames cnjBut prpBy nApollo’s adjHoly naTrousers, vLet’s advNot vDo daThe prnSame prpWith naTables cnjAnd naAolumns prnThemselves pm!
András Veres-Szentkirályi has started a series on securing web services with Python; the first part deals with UserNameTokens and mentions sec-wall, the security proxy, yay!
I’ve gotten a little bit tired of long constant names, like imagine there’s constants.py module which has the following:
MESSAGE_CREATE_FOO = '1000' MESSAGE_DELETE_FOO = '1001' # And so on..
Now the trouble is with importing it all. I can do either:
from constants import *
Which may be considered a bad style on one hand and on the other hand it becomes a mess if your IDE, like Wing IDE, autocompletes the names for you, so you type ME and then have to scroll through several dozens of them. Not to mention that it’s hardly ever the case that all of the constants are needed in any single module.
I can also carefully pick the names I need, like so:
from constants import MESSAGE_CREATE_FOO, MESSAGE_DELETE_FOO # And so on..
But that’s yet another place that needs to be kept in sync with the rest of the code.
So I’ve finally settled on using the Bunch class, which basically is a regular dictionary with an extra attribute-style access, meaning I can now write it all like so:
from bunch import Bunch MESSAGE = Bunch() MESSAGE.CREATE_FOO = '1000' MESSAGE.DELETE_FOO = '1001' # And so on..
# Yay, we're importing one thing only, the only one needed # in this module, and if the code below ever starts deleting # FOO, we won't have to update the import statement! from constants import MESSAGE print(MESSAGE.CREATE_FOO)
Isn’t that nicer?
Here’s another one in the hoping-it-saves-someone-at-least-half-an-hour-worth-of-searching-around category which shows nothing but how to define an ON DELETE CASCADE constraint and then how to issue a LEFT JOIN in SQLAlchemy.
# -*- coding: utf-8 -*- # SQLAlchemy from sqlalchemy import create_engine from sqlalchemy import Column, Integer, String, ForeignKey from sqlalchemy.ext.declarative import declarative_base from sqlalchemy.orm import backref, relationship, sessionmaker Base = declarative_base() # The definitions, note the use of both 'ondelete' and 'cascade'. class Mom(Base): __tablename__ = 'mom' id = Column(Integer, primary_key=True) name = Column(String(60)) class Daughter(Base): __tablename__ = 'daughter' id = Column(Integer, primary_key=True) name = Column(String(60)) mom_id = Column(Integer, ForeignKey('mom.id', ondelete='CASCADE'), nullable=False) mom = relationship(Mom, backref=backref('daughters', cascade='all, delete, delete-orphan')) class Son(Base): __tablename__ = 'son' id = Column(Integer, primary_key=True) name = Column(String(60)) mom_id = Column(Integer, ForeignKey('mom.id', ondelete='CASCADE'), nullable=False) mom = relationship(Mom, backref=backref('sons', cascade='all, delete, delete-orphan')) # Create an in-memory database. engine = create_engine('sqlite:///:memory:', echo=True) Base.metadata.create_all(engine) Session = sessionmaker(bind=engine) session = Session() # Let's find out how LEFT JOIN works, note the usage of .outerjoin mom1 = Mom() mom1.name = 'Molly' mom2 = Mom() mom2.name = 'Sarah' mom3 = Mom() mom3.name = 'Martha' daughter = Daughter() daughter.name = 'Matilda' daughter.mom = mom1 son1 = Son() son1.name = 'Robert' son1.mom = mom1 son2 = Son() son2.name = 'Tom' son2.mom = mom2 session.add_all([mom1, mom2, mom3]) session.commit() session.delete(mom2) session.commit() # All moms and their children. rows1 = session.query(Mom.id, Mom.name, Daughter.name.label('daughter_name'), Son.name.label('son_name')).\ outerjoin(Daughter, Mom.id==Daughter.mom_id).\ outerjoin(Son, Mom.id==Son.mom_id).\ order_by('mom.name').\ all() # Sarah doesn't like us anymore so Tom should be gone as well. rows2 = session.query(Son.id, Son.name).all() for row in rows1: print(row) print('') for row in rows2: print(row)
As expected, the result is
(3, u'Martha', None, None) (1, u'Molly', u'Matilda', u'Robert') (1, u'Robert')
We can also confirm the SQL code that’s being generated – notice the ON DELETE CASCADE clause ..
CREATE TABLE mom ( id INTEGER NOT NULL, name VARCHAR(60), PRIMARY KEY (id) ) CREATE TABLE daughter ( id INTEGER NOT NULL, name VARCHAR(60), mom_id INTEGER NOT NULL, PRIMARY KEY (id), FOREIGN KEY(mom_id) REFERENCES mom (id) ON DELETE CASCADE ) CREATE TABLE son ( id INTEGER NOT NULL, name VARCHAR(60), mom_id INTEGER NOT NULL, PRIMARY KEY (id), FOREIGN KEY(mom_id) REFERENCES mom (id) ON DELETE CASCADE )
.. and the LEFT JOIN is here indeed.
SELECT mom.id AS mom_id, mom.name AS mom_name, daughter.name AS daughter_name, son.name AS son_name FROM mom LEFT OUTER JOIN daughter ON mom.id = daughter.mom_id LEFT OUTER JOIN son ON mom.id = son.mom_id ORDER BY mom.name
Here’s a short visualisation of how I perceive various revision control systems, given in the order of my being exposed to each of them throughout all those years.
Many winters ago, it was the first RCS I used and I remember it was pretty powerful yet somewhat clumsy to steer and handle not to mention the thick armour that wouldn’t let me peek inside and have a look at its source code. I hear it’s still being sold to customers around the world who don’t mind to trade a little bit of the manoeuvrability in exchange for its main gun’s fire-power.
A funny-looking though not really forgiving system that would bring a lot of projects home. The crucial point was its low price (opensource) yet the lack of features (like no real ‘reverse gear’, one couldn’t easily delete empty directories) meant I was looking for something else pretty soon.
Now, I spent a couple of years working with svn for various corporate clients and it’s clear that’s what the prevailing majority of them can easily understand. It’s a centrally-managed system with no push and pull steps like in those fancy modern distributed ones and usually does its job sufficiently well. The feature most important for all the selfish ‘enterprise’ clients is that it has a built-in lock command with the power to break the locks if need be.
A very versatile modern system whose only issue was the maker’s marketing department who in the system’s early days wasn’t able to stop warning people that features were first and the speed advancements would come later so in the end pretty much everyone still thinks the system’s slow. Well, it isn’t. It’s called being ‘fast enough’ my friend. Oh, and the maker’s move to hire a couple of experienced user interface designers means the system’s a pure pleasure to use with no surprising commands required for everyday usage.
Another system that’s good all-around, fast, fuel efficient and very comfortable to drive. Doesn’t have as many fans as it deserves to because it’s not called Volkswagen Golf even though 99% of the features are precisely the same.
So now it’s git. A prime example of why space rocket engineers shouldn’t really design end user-facing technologies. It’s fast and that’s all one can say. There’s no hood so all of the gory details are left exposed and you’re supposed to deal with it (like it’s natural that one needs to check out two consecutive dashes when there’s a need to revert something). Just notice the number of times the words ‘unusual’, ’surprising’, ‘unexpected’ get mentioned in books on git. Really, the only thing that makes git usable is GitHub, which indeed is a very good service, like git done correctly only in the browser.
I guess you can easily tell where my heart is, eh? 
Apparently one can’t insert two and more ‘<tr>’ elements into a ‘<tbody>’ using PrototypeJS 1.7.0.0 and 1.6.0.3 if there’s also a ‘<br/>’ element involved in the conspiracy so that code simply won’t work at all:
var new_content = '<tr><td>foo</td></tr><br/><tr><td>bar</td></tr>'; $('my-tbody').insert(new_content);
One needs to leave out the poor ‘<br/>’ and I guess that applies to inserting ‘<br/>’ in general, not only in this situation but thankfully right now I only need to dynamically add new table rows not line breaks..
So if you have a piece of YUI Javascript code similar to the one shown below
function foo() { var on_success = function(o) { alert('Yay!'); }; var on_failure = function(o) { alert('Oh ones!') } var callback = { success: on_success, failure: on_failure, }; var url = '/url/to/invoke'; var transaction = YAHOO.util.Connect.asyncRequest('POST', url, callback); }
and the URL the AJAX call invokes returns the “CSRF verification failed. Request aborted. CSRF token missing or incorrect.” error, the easiest way to properly handle is to set the custom X-CSRFToken HTTP header to the same value the csrftoken cookie has been set by Django to, just like the Django documentation says it can be done.
In code terms, that will do the trick
function foo() { var on_success = function(o) { alert('Yay!'); }; var on_failure = function(o) { alert('Oh ones!') } var callback = { success: on_success, failure: on_failure, }; var url = '/url/to/invoke'; YAHOO.util.Connect.initHeader('X-CSRFToken', YAHOO.util.Cookie.get('csrftoken')); var transaction = YAHOO.util.Connect.asyncRequest('POST', url, callback); }
Hoping this helps someone some day!
Here’s a minimal lighttpd SSL/TLS reverse proxy configuration that allows for securing the traffic to plain HTTP servers using client certificates.
For easier management, the config has been broken into two modules, the main part and a list of variables. A caveat one needs to be aware of is that even though we’re interested in lighttd’s proxying capabilities only, we still need to configure everything as though lighttpd was going to serve plain HTTP traffic using static files – hence the need for configuring server.port and server.document-root.
The config files as well as the crypto material (courtesy of the Spring Python project) being used below can be also fetched from bitbucket. Of course, being uploaded to a public site, the private key is useless outside of a development environment and should never be used for anything close to production.
Enjoy
# Include necessary modules.
server.modules = ("mod_proxy", "mod_setenv")
# Include config variables.
include "./config-variables.conf"
server.document-root = my-dummy-document-root
server.username = my-username
server.groupname = my-groupname
# IP address or hostname to listen on.
server.bind = my-host
server.port = my-plain-http-port
$SERVER["socket"] == my-host + ":" + my-ssl-client-validation-port {
ssl.engine = "enable"
ssl.use-sslv2 = "disable"
ssl.verifyclient.exportcert = "enable"
ssl.verifyclient.username = "enable"
proxy.server = ("" => (("host"=>my-backend-host,
"port"=>my-backend-plain-http-port)))
# Server certificate.
ssl.pemfile = my-ssl-server-certificate-key
# Verify client's certificate.
ssl.verifyclient.activate = "enable"
ssl.verifyclient.enforce = "enable"
ssl.verifyclient.depth = my-verifyclient-depth
ssl.ca-file = my-ca-certificate
}
var.my-host = "localhost" var.my-ssl-client-validation-port = "17443" var.my-plain-http-port = "18080" var.my-backend-host = "localhost" var.my-backend-plain-http-port = "28080" var.my-dummy-document-root="./" var.my-username="dsuch" var.my-groupname="dsuch" var.my-ssl-server-certificate-key = "server-pair.pem" var.my-ca-certificate = "./ca-chain.pem" var.my-verifyclient-depth = "3"
