M2Crypto woes

Guido Van Rossum says in 'M2Crypto woes': "I've yet to see an extension module using SWIG that doesn't make me think it was a mistake to use SWIG instead of manually written wrappers. The extra time paid upfront to create hand-crafted wrappers is gained back hundredfold by time saved debugging the SWIG-generated code later."

Myers Carpenter in the comments says that he has great luck using ctypes. I must check it out.

It's beautiful outside

I thought "It would be nice to take a picture of this." But then I remembered that cameras don't capture what you see, they only capture what they see. That's why I don't carry a camera anywhere. I'd rather forget than remember it poorly.

Ajax

JJG over at Adaptive Path has a nice article on rich clients in their current incarnation of asynchronous JavaScript and XML. He calls this Ajax. It's good and worth reading if you're not already familiar. I have one small problem with it:

By defining an architectural style as it's building materials and not with it's underlying philosophy, it will quickly become obsolete. In fact, it's already obsolete: Google Suggest doesn't use XML for data interchange; just JavaScript arrays. Gmail also doesn't use XML and it doesn't use standards-based markup for presentation. Are they no longer Ajax applications? Of course they are.

What's amazing here isn't that there are rich clients on the web that use an asynchronous tier. What's amazing is that they aren't built using proprietary technology; they're not Flash, Java, or ActiveX.

Because they're not proprietary, we can, as JJG says, use the techniques we already know and are well deployed. This is also true for scaling Ajax applications; we can use the stuff we already know; Etags, Range, If-None-Match, etc.

Superman is a Dick.

Superman is a Dick. Great old Superman Comic covers with moderately funny subtitles.

anti-anti-nofollow

Evan Martin on (the tiny) anti-nofollow crowd: "What's really going on is someone whispered 'you may lose your 'influence'' and a bunch of people with inflated self-importance panicked."

Mnesia

This weekend I read a short paper on Mnesia; a relational database designed for telecom applications with soft realtime requirements. It features election-free replication (!!) and is linked into the application's address space for efficiency.

Mnesia is written entirely in Erlang and is only 20,000 lines of code. It's query and operational language are also Erlang meaning that there's no potentially absurd impedance mismatch like you see with various ORM tools such as Torque or Ruby on Rails. You won't be mysteriously executing 500 queries to route a single phone call.

You can reconfigure it dynamically. Since it's meant for a highly available telecom environment, the idea is that you never turn it off. Erlang's Actors model helps it acheive fault tolerance.

Queries are built using list comprehensions and a more powerful form of Views are built out of logic variables.

You are able to bypass the transaction manager and access any data using only a lightweight dirty lock interface to make sure your reads aren't garbled. The authors recognize that sometimes it just doesn't matter if a little of your data is wrong and that you should be able to control when that might happen.

In practice, data in Mnesia is not usually normalized as many of the current applications that use it want to be able to get as much data as needed in a single query. Even with it's query optimizer and ability to sidestep the lock manager, many telecom apps still need to be able to get all of their data in a single query. How long do you usually wait for a telephone call to start ringing? 100 milliseconds? That's as long as some RDBMS take to optimize a single query let alone execute it and return the results.

Apparently quite a few applications within Ericsson and Nortel use Mnesia. It's open source along with the rest of Erlang.

If I have time to play with it, I'll post some example code. I'd like to see how well this election-free replication works.

Ball and Chain

Stacy brought home some books on wedding planning today. I suppose that has to do with the fact that I asked her to marry me. In all the confusion, I can't remember exactly her answer but between this, the blog, and the fact that she wears the ring, "all signs point to yes."

Topix.net Architecture: KISS

"The lesson I took away from watching the horror of Netscape's UREG database being down for two weeks after a RAID enclosure failure was that even fancy databases, expensive hardware and knowledgeable staff weren't a substitute for fail-safe KISS architecture.

Co-Worker: The Little Idiot That Could

"The irony of the situation is that you think you are brilliant."

Distributed Systems for a Living

So, you're interested in distributed systems? Where to start? Actually, the job description that Werner Vogels just posted is a great way to see what'll be expected. Learn what every sentence in that job description means. Meditate on it, they are your koans.

But Steve, that stuff is complicated. Throw a brother a bone.

• Read Elements of Distributed Computing
• Read Milner's Communicating and Mobile Systems: the pi-calculus
• Learn Hewitt's Actors Model
• Compare and Contrast Actors and the Join Calculus
• Stop being scared by the term 'calculus'
• Learn an Actors Language. E, IO, Erlang, will all do.
• Read about how other good engineers have built distributed systems
• Build some distributed systems

One day, when I grow up, my systems will stop relying on caching layers and liveness guarantees. It's tough, friends, but there's a brave new world out there and I don't think SQL is anywhere to be seen.

Update: I just noticed that my name is in the history of the E project. Wow, that's very generous of them.