<?xml version="1.0" encoding="UTF-8"?>
 <rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://pinboard.in">
    <title>Pinboard (jm)</title>
    <link>https://pinboard.in/u:jm/public/</link>
    <description>recent bookmarks from jm</description>
    <items>
      <rdf:Seq>	<rdf:li rdf:resource="http://ferd.ca/lessons-learned-while-working-on-large-scale-server-software.html"/>
	<rdf:li rdf:resource="https://medium.com/@jlouis666/mnesia-and-cap-d2673a92850"/>
	<rdf:li rdf:resource="http://www.erlang-factory.com/upload/presentations/558/efsf2012-whatsapp-scaling.pdf"/>
	<rdf:li rdf:resource="http://webcache.googleusercontent.com/search?q=cache%3Awww.snookles.com%2Fslf-blog%2F2012%2F01%2F05%2Ftcp-incast-what-is-it%2F&amp;oq=cache%3Awww.snookles.com%2Fslf-blog%2F2012%2F01%2F05%2Ftcp-incast-what-is-it%2F&amp;aqs=chrome..69i57j69i58.795j0j4&amp;sourceid=chrome&amp;espv=210&amp;es_sm=91&amp;ie=UTF-8"/>
	<rdf:li rdf:resource="http://highscalability.com/blog/2014/2/5/littles-law-scalability-and-fault-tolerance-the-os-is-your-b.html"/>
	<rdf:li rdf:resource="http://www.infoq.com/interviews/ennis-events"/>
	<rdf:li rdf:resource="http://en.wikipedia.org/wiki/Crash-only_software"/>
	<rdf:li rdf:resource="https://www.erlang-factory.com/upload/presentations/462/euc2011-draft2.pdf"/>
	<rdf:li rdf:resource="http://akka.io/"/>
	<rdf:li rdf:resource="http://www.eflorenzano.com/blog/post/how-do-we-kick-our-synchronous-addiction/"/>
	<rdf:li rdf:resource="http://www.25hoursaday.com/weblog/2009/10/29/FacebookSeattleEngineeringRoadShowMikeShroepferOnEngineeringAtScaleAtFacebook.aspx"/>
	<rdf:li rdf:resource="http://github.com/blog/531-introducing-bert-and-bert-rpc"/>
	<rdf:li rdf:resource="http://codemonkeyism.com/generation-java-programming-style/"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="http://ferd.ca/lessons-learned-while-working-on-large-scale-server-software.html">
    <title>ferd.ca -&gt; Lessons Learned while Working on Large-Scale Server Software</title>
    <dc:date>2015-04-22T15:26:07+00:00</dc:date>
    <link>http://ferd.ca/lessons-learned-while-working-on-large-scale-server-software.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Good advice]]></description>
<dc:subject>distributed scalability systems coding server-side erlang devops networking reliability</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:4b4817db08ed/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distributed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:systems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:server-side"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:erlang"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:devops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reliability"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://medium.com/@jlouis666/mnesia-and-cap-d2673a92850">
    <title>Mnesia and CAP</title>
    <dc:date>2014-10-06T15:19:54+00:00</dc:date>
    <link>https://medium.com/@jlouis666/mnesia-and-cap-d2673a92850</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>A common “trick” is to claim:

'We assume network partitions can’t happen. Therefore, our system is CA according to the CAP theorem.'

This is a nice little twist. By asserting network partitions cannot happen, you just made your system into one which is not distributed. Hence the CAP theorem doesn’t even apply to your case and anything can happen. Your system may be linearizable. Your system might have good availability. But the CAP theorem doesn’t apply. [...] 
In fact, any well-behaved system will be “CA” as long as there are no partitions. This makes the statement of a system being “CA” very weak, because it doesn’t put honesty first. I tries to avoid the hard question, which is how the system operates under failure. By assuming no network partitions, you assume perfect information knowledge in a distributed system. This isn’t the physical reality.
</blockquote>

]]></description>
<dc:subject>cap erlang mnesia databases storage distcomp reliability ca postgres partitions</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:cb712d5066e6/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:erlang"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mnesia"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distcomp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reliability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ca"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:postgres"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:partitions"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.erlang-factory.com/upload/presentations/558/efsf2012-whatsapp-scaling.pdf">
    <title>'Scaling to Millions of Simultaneous Connections' [pdf]</title>
    <dc:date>2014-02-20T14:24:00+00:00</dc:date>
    <link>http://www.erlang-factory.com/upload/presentations/558/efsf2012-whatsapp-scaling.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Presentation by Rick Reed of WhatsApp on the large-scale Erlang cluster backing the WhatsApp API, delivered at Erlang Factory SF, March 30 2012. lots of juicy innards here]]></description>
<dc:subject>erlang scaling scalability performance whatsapp freebsd presentations</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:67245dcffadb/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:erlang"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:whatsapp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:freebsd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:presentations"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://webcache.googleusercontent.com/search?q=cache%3Awww.snookles.com%2Fslf-blog%2F2012%2F01%2F05%2Ftcp-incast-what-is-it%2F&amp;oq=cache%3Awww.snookles.com%2Fslf-blog%2F2012%2F01%2F05%2Ftcp-incast-what-is-it%2F&amp;aqs=chrome..69i57j69i58.795j0j4&amp;sourceid=chrome&amp;espv=210&amp;es_sm=91&amp;ie=UTF-8">
    <title>TCP incast vs Riak</title>
    <dc:date>2014-02-14T15:36:17+00:00</dc:date>
    <link>http://webcache.googleusercontent.com/search?q=cache%3Awww.snookles.com%2Fslf-blog%2F2012%2F01%2F05%2Ftcp-incast-what-is-it%2F&amp;oq=cache%3Awww.snookles.com%2Fslf-blog%2F2012%2F01%2F05%2Ftcp-incast-what-is-it%2F&amp;aqs=chrome..69i57j69i58.795j0j4&amp;sourceid=chrome&amp;espv=210&amp;es_sm=91&amp;ie=UTF-8</link>
    <dc:creator>jm</dc:creator><description><![CDATA[An extremely congested local network segment causes the "TCP incast" throughput collapse problem -- packet loss occurs, and TCP throughput collapses as a side effect.  So far, this is pretty unsurprising, and anyone designing a service needs to keep bandwidth requirements in mind.

However it gets worse with Riak.  Due to a bug, this becomes a serious issue for all clients: the Erlang network distribution port buffers fill up in turn, and the Riak KV vnode process (in its entirety) will be descheduled and 'cannot answer any more queries until the A-to-B network link becomes uncongested.'

This is where EC2's fully-uncontended-1:1-network compute cluster instances come in handy, btw. ;)]]></description>
<dc:subject>incast tcp networking bandwidth riak architecture erlang buffering queueing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:895ea7fbed24/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:incast"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bandwidth"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:riak"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:erlang"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:buffering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://highscalability.com/blog/2014/2/5/littles-law-scalability-and-fault-tolerance-the-os-is-your-b.html">
    <title>Little’s Law, Scalability and Fault Tolerance: The OS is your bottleneck. What you can do?</title>
    <dc:date>2014-02-05T17:35:26+00:00</dc:date>
    <link>http://highscalability.com/blog/2014/2/5/littles-law-scalability-and-fault-tolerance-the-os-is-your-b.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[good blog post on Little's Law, plugging quasar, pulsar, and comsat, 3 new open-source libs offering Erlang-like lightweight threads on the JVM]]></description>
<dc:subject>jvm java quasar pulsar comsat littles-law scalability async erlang</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:bb3e77510a90/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:quasar"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pulsar"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:comsat"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:littles-law"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:async"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:erlang"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.infoq.com/interviews/ennis-events">
    <title>Darach Ennis on CEP, Stream Processing, Messaging, OOP vs Functional Architecture</title>
    <dc:date>2013-05-14T21:03:27+00:00</dc:date>
    <link>http://www.infoq.com/interviews/ennis-events</link>
    <dc:creator>jm</dc:creator><description><![CDATA[good interview -- lots of food for thought!]]></description>
<dc:subject>darach-ennis stream-processing messaging architecture qcon interviews erlang cep realtime rx comet events</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:262333000223/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:darach-ennis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:stream-processing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:qcon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:interviews"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:erlang"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cep"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:realtime"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rx"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:comet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:events"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://en.wikipedia.org/wiki/Crash-only_software">
    <title>Crash-only software</title>
    <dc:date>2013-02-19T13:26:35+00:00</dc:date>
    <link>http://en.wikipedia.org/wiki/Crash-only_software</link>
    <dc:creator>jm</dc:creator><description><![CDATA[I couldn't remember the name for this design principle, so it's worth a bookmark to remind me in future...

'This refers to computer programs that handle failures by simply restarting, without attempting any sophisticated recovery.  Correctly written components of crash-only software can microreboot to a known-good state without the help of a user. Since failure-handling and normal startup use the same methods, this can increase the chance that bugs in failure-handling code will be noticed.']]></description>
<dc:subject>crashing crash-only-software design architecture coding software fault-tolerance erlang let-it-fail microreboot recovery autosave</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1ee8d59c6ee5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:crashing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:crash-only-software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fault-tolerance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:erlang"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:let-it-fail"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:microreboot"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:recovery"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:autosave"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.erlang-factory.com/upload/presentations/462/euc2011-draft2.pdf">
    <title>DTrace and Erlang</title>
    <dc:date>2011-11-09T13:54:17+00:00</dc:date>
    <link>https://www.erlang-factory.com/upload/presentations/462/euc2011-draft2.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA[from Basho, via istvan.  DTrace is becoming more compelling as a deep instrumentation/monitoring API -- I didn't realise disabled DTrace probes were virtually 0-overhead (a "2 NOOP instruction placeholder", apparently), that's nifty.  Wonder if they've fixed the licensing mess, though]]></description>
<dc:subject>dtrace monitoring instrumentation debugging tracing unix erlang via:istvan</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:76d5b3fb1bbf/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dtrace"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:instrumentation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:debugging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tracing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:erlang"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:istvan"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://akka.io/">
    <title>Akka</title>
    <dc:date>2011-03-27T22:20:47+00:00</dc:date>
    <link>http://akka.io/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['platform for event-driven, scalable, and fault-tolerant architectures on the JVM' .. Actor-based, 'let-it-crash', Apache-licensed, Java and Scala APIs, remote Actors, transactional memory -- looks quite nice]]></description>
<dc:subject>scala java concurrency scalability apache akka actors erlang fault-tolerance events</dc:subject>
<dc:identifier>https://pinboard.in/u:jm/b:d8d97dabbd34/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scala"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:concurrency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apache"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:akka"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:actors"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:erlang"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fault-tolerance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:events"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.eflorenzano.com/blog/post/how-do-we-kick-our-synchronous-addiction/">
    <title>How do we kick our synchronous addiction?</title>
    <dc:date>2010-02-10T14:45:36+00:00</dc:date>
    <link>http://www.eflorenzano.com/blog/post/how-do-we-kick-our-synchronous-addiction/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[great post on the hazards of programming in an async framework, and how damn hard it is.  good comments thread too (via jzawodny)]]></description>
<dc:subject>via:jzawodny coding python javascript scalability ruby concurrency erlang async node.js twisted</dc:subject>
<dc:identifier>https://pinboard.in/u:jm/b:c44bdbe63e1d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:jzawodny"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:python"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:javascript"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:concurrency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:erlang"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:async"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:node.js"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:twisted"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.25hoursaday.com/weblog/2009/10/29/FacebookSeattleEngineeringRoadShowMikeShroepferOnEngineeringAtScaleAtFacebook.aspx">
    <title>Mike Shroepfer on Engineering at Scale at Facebook</title>
    <dc:date>2009-10-30T15:46:46+00:00</dc:date>
    <link>http://www.25hoursaday.com/weblog/2009/10/29/FacebookSeattleEngineeringRoadShowMikeShroepferOnEngineeringAtScaleAtFacebook.aspx</link>
    <dc:creator>jm</dc:creator><description><![CDATA[lots of gory details on FB's innards via Dare Obasanjo]]></description>
<dc:subject>facebook scaling scalability erlang caching architecture multifeed</dc:subject>
<dc:identifier>https://pinboard.in/u:jm/b:8f5a7a849f17/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:facebook"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:erlang"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:caching"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:multifeed"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://github.com/blog/531-introducing-bert-and-bert-rpc">
    <title>Introducing BERT and BERT-RPC</title>
    <dc:date>2009-10-22T11:04:20+00:00</dc:date>
    <link>http://github.com/blog/531-introducing-bert-and-bert-rpc</link>
    <dc:creator>jm</dc:creator><description><![CDATA[another serialization format, binary, no IDL, no code generation, from GitHub]]></description>
<dc:subject>github bert erlang ruby rpc protocol thrift serialization networking</dc:subject>
<dc:identifier>https://pinboard.in/u:jm/b:f2f0b799bc30/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:github"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bert"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:erlang"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rpc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:protocol"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:thrift"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:serialization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://codemonkeyism.com/generation-java-programming-style/">
    <title>Next Generation Java Programming Style</title>
    <dc:date>2009-08-10T13:29:30+00:00</dc:date>
    <link>http://codemonkeyism.com/generation-java-programming-style/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[a Reddit-friendly 8-point list of new idioms for Java code in a more functional style.  not sure about a couple of these, but another couple get my +1]]></description>
<dc:subject>erlang via:janl coding java oop style fluent-interfaces final encapsulation</dc:subject>
<dc:identifier>https://pinboard.in/u:jm/b:4937bf10f81d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:erlang"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:janl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:oop"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:style"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fluent-interfaces"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:final"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:encapsulation"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>