Reading rollup, 2014-09-16.

| categories: reading

On holiday in France. It's nice here!

  • Postel's Principle is a Bad Idea. - programming is terrible

    Lots of interesting references here, and memorable quotes (as is often the way with tef's posts).

    "If some data means two different things to different parts of your program or network, it can be exploited - Interoperability is achieved at the expense of security."

    Examples from the Perl/C interface, TCP/IP, confused deputy, XSS.

    "Notably, HTML5 gained a standardized parser, not for security reasons, but to ensure that bad HTML looks the same on every browser."

    "Interoperability doesn't just mean working in the same way, but failing in the same way too."

  • How To Design A Good API and Why it Matters - Joshua Bloch

    Sensible notes on API design from someone who has very much been in the trenches.

    • Public APIs are forever: one chance to get it right.
    • Make it easy to do the right thing, difficult to the wrong thing, easy to evolve.
    • Just powerful enough to satisfy requirements.
    • Gather requirements, and make a 1-page spec. Share. Pretend to code against it. Take example programs very seriously.
    • Aim to displease everyone equally.
    • Do one thing and do it well. Good names drive development.
    • When in doubt, leave it out.
    • Don't let implementation details "leak" into API. Design serialized forms carefully.
    • Minimize accessibility of everything.
    • Documentation matters. Document everything in your public API.
    • Bad decisions can limit performance; but don't warp the API to gain performance. Good design usually coincides with good performance.
    • API must coexist peacefully with the platform: transliterated APIs are almost always broken.
    • Minimize mutability. Prefer immutable; if mutable, keep state space small & well-defined.
    • Don't make the client do anything the module could - reduce boilerplate.
    • Don't violate the principle of least astonishment.
    • Provide programmatic access to all data available in string form!
    • Use consistent parameter ordering across methods.
    • Avoid return values that demand exceptional processing (e.g. return an empty collection instead of not_found).

  • Actually using ed - Arabesque

    Cute tutorial on using ed. Fun to work through. There's a lot of other interesting stuff at this site, e.g. the "Unix as IDE" series.

  • Nine Nines Article: Erlang Scalability

    A set of notes on things that may limit an Erlang system's scalability:

    • Avoid NIFs if possible; e.g. use MessagePack rather than JSON;
    • Be careful what BIFs you use (example of erlang:decode_packet/3 in Cowboy);
    • Use binaries rather than lists, including for buffering/streaming;
    • Don't hesitate to create a custom pool of processes to do what a single gen_server might; similarly, a custom supervisor might sometimes be the right thing.
    • Use ets public or protected tables for LOLSPEED(tm).

  • How Stacks are Handled in Go - Daniel Morsing

    Clearly-written details of how goroutine stacks work (and how they soon will).

    Now: "segmented" stacks grow by allocating new segments with accounting information to find the previous outgrown. This can cause a "hot split" issue where the stack keeps growing and shrinking at the segment boundary, and releasing the new stack segment each time is expensive.

    Soon: "stack copying" creates a new segment double the size, and copies the old data to it. There's some accounting work that needs to be done here for pointers to stack data, and the Go devs are currently rewriting a pile of the runtime in Go to make this doable.

    This will also enable concurrent garbage collection in future - something which really helps in Erlang - though there are open issues with how this will work for shared heap objects in Go. I tend to prefer the Erlang shared-nothing approach ...

Generated from pinboard by pinroll.

Reading rollup, 2014-09-06.

| categories: reading

  • Debuggers: Russ Cox

    Debuggers post about a lock concurrency problem in code on Plan9. As always, Cox writes brilliantly and clearly about deep technical topics. Note the links to debugging history notes at the end.

  • The Discovery of Debugging - Brian Hayes

    Linked from rsc's article above. Great history piece on EDSAC and its first programmers.

    Software was very much the "stunted sibling" of hardware in the earliest years. "It appeared that programming might be tedious but not fundamentally difficult. A crucial discovery was yet to be made: the discovery of debugging."

    "The human reader passes over such errors without even seeing them, unconsciously filling in the intended meaning, but the machine is resolutely literal. It does only what it is told to do."

    Nice description of the hellish misery of encoding programs for the EDSAC. :o) By September 1949 (6 months in), then-student David J. Wheeler had already written a basic relocatable-code loading facility, basically a linker, amazing.

    Some really nice insight into the early days here. I wonder if there's something that comes *after* software - scalable architectures, maybe? - that we just haven't thought much about yet because we're so obsessed with the software itself.

  • Pitfalls of Object Oriented Programming - Tony Albrecht

    Deck about memory layout in high-performance games and how OO paradigms screw with optimal (columnar, for caching) layout of data in memory. Well worth a read, though these are problems I don't really want to have. :o)

Generated from pinboard by pinroll.

Reading rollup, 2014-08-26.

| categories: reading

I signed up for Pinboard a little over a month ago, finally cleared my "must read this" email labels to it, and haven't looked back. I find myself spending a lot of time in it now, reading documents and taking notes. Recommended.

Following jmason's example, I thought I'd start rolling some of the links I'm reading into blog posts, starting with older stuff.

My pins are private, so I haven't bothered including tags, and I'm doing this on a pull basis rather than daily. :o)

Generated from pinboard by pinroll.

Designing for Brobdingnag

| categories: sysadmin, design

On the topic of talks, while at Google I was involved in an interesting SRE Classroom event in late 2013. These events were run by many of the SRE offices as a way of sharing design approaches with software and systems engineers who might lack exposure to large-scale systems.

I later gave my talk from the Dublin event to in February 2014. PDF with speaker notes from that event:

Designing for Brobdingnag: considerations in scaling large web systems.

Today, we're focusing on technical designs in large-scale software environments, and patterns which we've found work well.

These can be relatively difficult to get exposure to.

This won't be an exhaustive treatment, but we hope to give you:

  • an appreciation of the kinds of constraints and opportunities we have at scale;
  • some tools for approaching design;
  • and a better idea of the kinds of systems SREs engage with.

Note the "Resources" slide towards the end: lots of good links on design and distributed systems there.

Based on presentations at the London and Mountain View SRE Classroom events by Matt Brown, John Neil and Robert Spier. I also include ideas from Jeff Dean's talk Building Software Systems At Google and Lessons Learned. Many thanks to Niall Richard Murphy, Alex Perry, Laura Nolan and Pete Nuttall for assistance, ideas and review.

monendi te salutant

| categories: sysadmin, fun

Talking with Niall on IRC today, I had a brainwave: with just one letter changed, the famous Latin quote morituri te salutant - "those who are about to die salute you" - could become monituri te salutant - "those who are about to be paged salute you".

A noble and fitting handover note for oncall engineers?

Sadly, as is often the case when I take enthusiastic flights into classical translation, I'm off here: moriturus is a somewhat irregular thing from the verb morior. moniturus is active, not passive: it means "about to warn/advise/notify".

To get this right, we need a future passive participle, which it turns out is supplied by the gerundive. So that gives us monendus.

monendi te salutant

Not as sweet a solution as the one-letter change complete with "monitoring" embedded, but not bad. Vale!

« Previous Page -- Next Page »