Non-blocking transactional atomicity

“Performing multi-object updates is a common but difficult problem in real-world distributed systems. When updating two or more items at once, it’s useful for other readers of those items to observe atomicity: either all of your updates are visible or none of them are.1 This crops up in a bunch of contexts, from social network graphs (e.g., Facebook’s Tao system, where bi-directional “friend” relationships are stored in two uni-directional pointers) to distributed data structures like counters (e.g., Twitter’s Rainbird hierarchical aggregator) and secondary indexes (a topic for a future post). In conversations I’ve had regarding our work on Highly Available Transactions, atomic multi-item update, or transactional atomicity, is often the most-requested feature…”

http://www.bailis.org/blog/non-blocking-transactional-atomicity/

Where did all the HTTP referrers go?

“Good (and bad news): the general consensus in the web developer community is that any and every website should be HTTPS by default. Why? HTTP by itself isn’t encrypted, leaving it open to eavesdropping, message tampering, and man-in-the-middle attacks. HTTPS, if you use it consistently, prevents these issues.

So how can that possibly be bad news? HTTPS is confusing one of the core metadata tools of the Internet: HTTP Referrers. HTTP Referrers disappear when going from HTTPS to HTTP, but, more worryingly, sensitive HTTPS Referrers still get carried when going from HTTPS to HTTPS. Most secure applications aren’t aware of where their HTTP Referrers do or don’t go. Don’t worry though: there’s hope. Or at lest meta hope…”

http://smerity.com/articles/2013/where_did_all_the_http_referrers_go.html

SICP distilled

“If you’re still thinking about reading SICP, here’s an article, written by Abelson and Sussman shortly after publishing the first edition of the book, that may dispel your doubts: Lisp: A language for stratified design. It’s a quick distillation of some of the central themes discussed at length in SICP, with accompanying code. Some of them may seem old hat these days (the article was published in 1987), but they’re as relevant as they were back in the day, and it’s difficult to find them exposed in as good (let alone a better) a way. Its dozen pages are full of quotable pearls of wisdom. For instance, right from the start:…”

http://programming-musings.org/2009/12/29/sicp-distilled/

Building LISP

“The best way to understand how something works is to try to build it for yourself. Reading somebody else’s explanation might satisfy your curiosity, but without the experience of falling into all the little traps it is difficult to get a feel for why something is designed a certain way.

It’s been said that every would-be programmer should write a compiler. While I think this is good advice (although I haven’t followed it myself), there is so much effort involved just in parsing a language such as C that any potential insights risk getting lost in a mire of details. Perhaps creating an interpreter for some simple language would be a good first step.

I first started playing around with LISP a good few years ago, yet much later than I should have. This led me to the classic lecture series Structure and Interpretation of Computer Programs. If you have the next 24 hours free and haven’t seen the videos already, go watch them now.

The course covers many topics, but the second half shows in detail how to evaluate LISP, first by implementing a simple version of eval in LISP itself. I figured that this would translate well into C, and so decided to try creating my own implementation of LISP…”

http://www.lwh.jp/lisp/intro.html

Google’s Go and implicit interface declaration

“Last week I decided to start going through some of the popular Go tutorials, specifically “Tour of Go”. It wasn’t long before I was introduced to the idea of “Implicit Interface Declaration” in Go. This means that to implement an interface you simply have to implement the method signatures that the interface defines; you do not need to explicitly say “I want to implement Interface X”, you simply go ahead and implement it. Let’s say that there’s some interface “Shape” and it’s defined as so:…”

http://www.swageroo.com/wordpress/googles-go-and-implicit-interface-declaration/?h

Advanced Go Concurrency Patterns

“At Google I/O a year ago Rob Pike presented Go Concurrency Patterns, an introduction to Go’s concurrency model. Last week, at I/O 2013, Go team member Sameer Ajmani continued the story with Advanced Go Concurrency Patterns, an in-depth look at a real concurrent programming problem. The talk shows how to detect and avoid deadlocks and race conditions, and demonstrates the implementation of deadlines, cancellation, and more. For those who want to take their Go programming to the next level, this is a must-see…”

http://blog.golang.org/2013/05/advanced-go-concurrency-patterns.html