<?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="https://bethmathews.substack.com/p/why-so-many-control-rooms-were-seafoam"/>
	<rdf:li rdf:resource="https://nvartolomei.com/oswald/"/>
	<rdf:li rdf:resource="https://github.com/slatedb/slatedb/issues/454"/>
	<rdf:li rdf:resource="https://spin.atomicobject.com/capability-feature-flags/"/>
	<rdf:li rdf:resource="https://dev.to/stripe/designing-apis-for-humans-object-ids-3o5a"/>
	<rdf:li rdf:resource="https://rehanvdm.com/blog/should-you-use-a-lambda-monolith-lambdalith-for-the-api"/>
	<rdf:li rdf:resource="http://thenonist.com/index.php/thenonist/permalink/stick_charts/"/>
	<rdf:li rdf:resource="https://blogs.scientificamerican.com/sa-visual/pop-culture-pulsar-origin-story-of-joy-division-s-unknown-pleasures-album-cover-video/"/>
	<rdf:li rdf:resource="https://www.mukama.com/en/"/>
	<rdf:li rdf:resource="https://irelandcoins.ie/percy-metcalfe/"/>
	<rdf:li rdf:resource="https://www.designedbycave.co.uk/2020/LEGO-Interface-UX/"/>
	<rdf:li rdf:resource="http://blog.presentandcorrect.com/27986-2"/>
	<rdf:li rdf:resource="https://www.projectopenair.org/"/>
	<rdf:li rdf:resource="https://pair.withgoogle.com/"/>
	<rdf:li rdf:resource="https://blog.acolyer.org/2020/01/08/ironies-of-automation/"/>
	<rdf:li rdf:resource="https://twitter.com/davidcrawshaw/status/1178478240970600450"/>
	<rdf:li rdf:resource="https://shape19.imascientist.ie/"/>
	<rdf:li rdf:resource="https://www.fastcompany.com/90395110/how-googly-eyes-solved-one-of-todays-trickiest-ux-problems"/>
	<rdf:li rdf:resource="https://www.quora.com/Why-do-some-developers-at-strong-companies-like-Google-consider-Agile-development-to-be-nonsense/answer/David-Jeske?share=1"/>
	<rdf:li rdf:resource="https://twitter.com/ItsTheShadsy/status/1151868012707962881"/>
	<rdf:li rdf:resource="https://nyc.streetsblog.org/2019/06/03/op-ed-breaking-down-barriers-to-disabled-cyclists/"/>
	<rdf:li rdf:resource="https://www.buzzfeednews.com/article/mikemonteiro/we-built-a-broken-internet-now-we-need-to-burn-it"/>
	<rdf:li rdf:resource="https://www.usenix.org/sites/default/files/conference/protected-files/srecon18americas_slides_virji.pdf"/>
	<rdf:li rdf:resource="https://techcrunch.com/2018/04/17/facebook-gdpr-changes/"/>
	<rdf:li rdf:resource="https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/best-practices.html"/>
	<rdf:li rdf:resource="https://www.reddit.com/r/aws/comments/7phlq2/best_way_designing_a_gdpr_compliant_datalake/"/>
	<rdf:li rdf:resource="http://singletrackworld.com/2018/01/collision-course-why-this-type-of-road-junction-will-keep-killing-cyclists/"/>
	<rdf:li rdf:resource="http://londonist.com/london/transport/london-cutaways"/>
	<rdf:li rdf:resource="https://aadrake.com/posts/2017-05-20-enough-with-the-microservices.html"/>
	<rdf:li rdf:resource="https://blog.bolt.io/heres-why-juicero-s-press-is-so-expensive-6add74594e50"/>
	<rdf:li rdf:resource="http://www.blindltd.com/rogue-one"/>
	<rdf:li rdf:resource="http://www.itsnicethat.com/news/google-monotype-noto-type-family-061016"/>
	<rdf:li rdf:resource="https://blog.acolyer.org/2016/10/06/simple-testing-can-prevent-most-critical-failures/"/>
	<rdf:li rdf:resource="http://martinfowler.com/bliki/TechnicalDebtQuadrant.html"/>
	<rdf:li rdf:resource="http://www.citylab.com/design/2011/09/street-grids/124/"/>
	<rdf:li rdf:resource="http://basho.com/posts/technical/microservices-please-dont/"/>
	<rdf:li rdf:resource="http://fuckyournoguchicoffeetable.tumblr.com/?og=1"/>
	<rdf:li rdf:resource="https://blog.vellumatlanta.com/2016/05/04/apple-stole-my-music-no-seriously/"/>
	<rdf:li rdf:resource="http://www.bbc.com/future/story/20160325-the-names-that-break-computer-systems"/>
	<rdf:li rdf:resource="http://blog.cleancoder.com/uncle-bob/2016/03/19/GivingUpOnTDD.html"/>
	<rdf:li rdf:resource="https://www.lonelyplanet.com/ireland/dublin/travel-tips-and-articles/hip-cafes-and-hot-design-exploring-the-new-dublin"/>
	<rdf:li rdf:resource="http://www.pixelmator.com/mac/"/>
	<rdf:li rdf:resource="http://isdublinbusy.com/"/>
	<rdf:li rdf:resource="https://twitter.com/cabel/status/648680009381511168"/>
	<rdf:li rdf:resource="https://msol.io/blog/tech/2015/09/05/youre-probably-wrong-about-caching/"/>
	<rdf:li rdf:resource="https://deardesignstudent.com/in-praise-of-the-ak-47-a24cc8a46c13"/>
	<rdf:li rdf:resource="http://radleymarx.com/blog/simple-guide-to-9-patch/"/>
	<rdf:li rdf:resource="http://colossalshop.com/"/>
	<rdf:li rdf:resource="http://www.ustream.tv/recorded/61486500"/>
	<rdf:li rdf:resource="http://www.squarespace.com/"/>
	<rdf:li rdf:resource="http://asciiflow.com/"/>
	<rdf:li rdf:resource="http://www.zeldman.com/2014/12/28/unexamined-privilege-is-the-real-source-of-cruelty-in-facebooks-your-year-in-review/"/>
	<rdf:li rdf:resource="http://www.beerlabelizer.com/"/>
	<rdf:li rdf:resource="http://bldgblog.blogspot.ie/2014/09/procedural-brutalism.html"/>
	<rdf:li rdf:resource="http://www.90percentofeverything.com/2014/08/26/some-dark-patterns-now-illegal-in-uk-interview-with-heather-burns/"/>
	<rdf:li rdf:resource="http://www.infoworld.com/d/data-center/systemd-harbinger-of-the-linux-apocalypse-248436?source=rss_data_center"/>
	<rdf:li rdf:resource="http://www.thisiscolossal.com/2014/07/layered-glass-table-concept-duffy-london/"/>
	<rdf:li rdf:resource="http://www.coolhunting.com/design/makers-brothers-marmoreal-board-pepper-mill.php"/>
	<rdf:li rdf:resource="http://www.aviewfromthecyclepath.com/2014/04/where-crashes-are-shared-space-and.html"/>
	<rdf:li rdf:resource="http://arnon.me/2014/03/services-microservices-nanoservices/"/>
	<rdf:li rdf:resource="http://designtaxi.com/news/364536/A-Look-At-Airbnb-s-Irish-Pub-Inspired-Office-In-Dublin/#.Uyvx5Zh4cTN.twitter"/>
	<rdf:li rdf:resource="http://blog.johnryding.com/post/78544969349/how-to-reconnect-web-sockets-in-a-realtime-web-app"/>
	<rdf:li rdf:resource="http://jpkoning.blogspot.ie/2012/10/data-visualization-breaking-down.html"/>
	<rdf:li rdf:resource="http://tla2012.loria.fr/contributed/newcombe-slides.pdf"/>
	<rdf:li rdf:resource="http://sockpuppet.org/blog/2013/07/22/applied-practical-cryptography/"/>
	<rdf:li rdf:resource="http://engineering.pinterest.com/post/55272557617/building-a-follower-model-from-scratch"/>
	<rdf:li rdf:resource="http://www.oracle.com/technetwork/products/berkeleydb/learnmore/bdb-je-architecture-whitepaper-366830.pdf"/>
	<rdf:li rdf:resource="http://sweng.the-davies.net/Home/rustys-api-design-manifesto"/>
	<rdf:li rdf:resource="http://nerds.airbnb.com/introducing-chronos"/>
	<rdf:li rdf:resource="http://www.slideshare.net/Wolfr/design-for-developersonlineversionlong"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="https://bethmathews.substack.com/p/why-so-many-control-rooms-were-seafoam">
    <title>Why So Many Control Rooms Were Seafoam Green</title>
    <dc:date>2026-03-27T12:34:11+00:00</dc:date>
    <link>https://bethmathews.substack.com/p/why-so-many-control-rooms-were-seafoam</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Turns out it's US standard Industrial Color Coding, thanks to "color theorist" Faber Birren:

<blockquote>
With the increase in wartime production in the US during WWII, Birren and DuPont created a master color safety code for the industrial plant industry, with the aim of reducing accidents and increasing efficiency within plants. These color codes were approved by the National Safety Council in 1944 and are now internationally recognized, having been mandatory practice since 1948. The color coding went as such:

- Fire Red: All fire protection, emergency stop buttons, and flammable liquids should be red

- Solar Yellow: Signifies caution and physical hazards such as falling

- Alert Orange: Hazardous parts of machinery

- Safety Green: Indicates safety features such as first-aid equipment, emergency exits, and eyewash stations.

- Caution Blue: Non-safety information, notices, or out-of-order signage

- Light Green: Used on walls to reduce visual fatigue</blockquote>

]]></description>
<dc:subject>green design history color-theory faber-birren control-rooms industrial-design color-coding</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:4817a29dbe1d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:green"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:history"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:color-theory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:faber-birren"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:control-rooms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:industrial-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:color-coding"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://nvartolomei.com/oswald/">
    <title>OSWALD</title>
    <dc:date>2025-10-06T10:08:19+00:00</dc:date>
    <link>https://nvartolomei.com/oswald/</link>
    <dc:creator>jm</dc:creator><description><![CDATA["OSWALD is a Write-Ahead Log (WAL) design built exclusively on object storage primitives. It works with any object storage service that provides read-after-write consistency and compare-and-swap operations, including AWS S3, Google Cloud Storage, and Azure Blob Storage. The design supports checkpointing and garbage collection, making it suitable for State Machine Replication (SMR) [and] has been formally specified and verified using the P programming language." - by Nicolae Vartolomei]]></description>
<dc:subject>oswald wal object-storage s3 gcs azure smr storage formal-methods design architecture cloud-computing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f7539b20cbc1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:oswald"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:object-storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:s3"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gcs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:azure"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:smr"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:formal-methods"/>
	<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:cloud-computing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/slatedb/slatedb/issues/454">
    <title>API Error Design</title>
    <dc:date>2025-01-23T16:33:53+00:00</dc:date>
    <link>https://github.com/slatedb/slatedb/issues/454</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Some good thoughts from a SlateDB dev, regarding initial principles for errors in SlateDB, derived from experience with Kafka:

- Keep public errors separate from internal errors. The set of public errors should be kept minimal and new errors should be highly scrutinized. For internal errors, we can go to town since they can be refactored and consolidated over time without affecting the user.
- Public errors should be prescriptive. Can an operation be retried? Is the database left in an inconsistent state? Can a transaction be aborted? What should the user actually do when the error is encountered? The error should have clear guidance.
- Prefer coarse error types with rich error messages. There are probably hundreds of cases where the database can enter an invalid state. We don't need a separate type for each of them. We can use a single FatalError and pack as much information into the error message as is necessary to diagnose the root cause.

(via Chris Riccomini)]]></description>
<dc:subject>errors api design slatedb api-design error-handling exceptions architecture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:96f66b5f9f7e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:errors"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:slatedb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:api-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:error-handling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:exceptions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://spin.atomicobject.com/capability-feature-flags/">
    <title>Capability Feature Flags for Backward Compatibility</title>
    <dc:date>2024-10-30T15:54:40+00:00</dc:date>
    <link>https://spin.atomicobject.com/capability-feature-flags/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Good reference blog post for a design approach I like for APIs; instead of using numeric version attributes and mapping "version=4" means "supports feature foo", use a capability flag of "supports_foo=1".]]></description>
<dc:subject>apis design coding capabilities feature-flags flags</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a2496c3513d1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:capabilities"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:feature-flags"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:flags"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://dev.to/stripe/designing-apis-for-humans-object-ids-3o5a">
    <title>Type-prefixed object IDs</title>
    <dc:date>2024-07-15T09:33:20+00:00</dc:date>
    <link>https://dev.to/stripe/designing-apis-for-humans-object-ids-3o5a</link>
    <dc:creator>jm</dc:creator><description><![CDATA[The Stripe approach to object IDs: random alphanums, with a type prefix.  Type prefixing allows polymorphic lookups, and most importantly prevents errors -- it's strong typing for IDs.]]></description>
<dc:subject>api design development programming stripe apis ids object-ids coding</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0173ac820a13/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:development"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:stripe"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ids"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:object-ids"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://rehanvdm.com/blog/should-you-use-a-lambda-monolith-lambdalith-for-the-api">
    <title>Should you use a Lambda Monolith, aka Lambdalith, for your API?</title>
    <dc:date>2023-11-14T12:39:20+00:00</dc:date>
    <link>https://rehanvdm.com/blog/should-you-use-a-lambda-monolith-lambdalith-for-the-api</link>
    <dc:creator>jm</dc:creator><description><![CDATA[I don't use Lambda, personally, as I find it too expensive and it doesn't fit well with our current infrastructure (and I still fear the availability risks that might come with it, viz. this year's outage).  But this seems like a good guideline for those who might be using it:

<blockquote>
The argument to limit the blast radius on a per route level by default is too fine-grained, adds bloat and optimizes too early. The boundary of the blast radius should be on the whole API/service level, just as it is and always has been for traditional software.

Use a Lambdalith if you are not using any advance features of AWS REST API Gateway and you want the highest level of portability to other AWS gateways or compute layer. There are also many escape hatches to fill some of the promises that single-purpose functions offer.</blockquote>

]]></description>
<dc:subject>lambda monolith api design architecture aws serverless</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ccf4ade953bc/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lambda"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monolith"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:api"/>
	<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:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:serverless"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://thenonist.com/index.php/thenonist/permalink/stick_charts/">
    <title>Polynesian Stick Charts</title>
    <dc:date>2023-08-29T08:53:32+00:00</dc:date>
    <link>http://thenonist.com/index.php/thenonist/permalink/stick_charts/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Fascinating:

<blockquote>The Polynesians, scattered as they were over 1,000 islands across the central and southern Pacific Ocean, were master navigators who tracked their way over a huge expanses of ocean without any of the complex mechanical aids we associate with sea fairing. They didn’t have the astrolabe or the sextant, the compass or the chronometer. They did however have aids of a sort, which though seemingly humble, were in fact the repositories of an extremely complex kind of knowledge. Called Rebbelibs, Medos. and Mattangs, today we call them simply “Stick Charts.”</blockquote>

]]></description>
<dc:subject>cartography design history maps polynesia stick-charts navigation seafaring</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:fff857421ec1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cartography"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:history"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:maps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:polynesia"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:stick-charts"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:navigation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:seafaring"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blogs.scientificamerican.com/sa-visual/pop-culture-pulsar-origin-story-of-joy-division-s-unknown-pleasures-album-cover-video/">
    <title>Pop Culture Pulsar: Origin Story of Joy Division's Unknown Pleasures Album Cover</title>
    <dc:date>2023-03-20T11:04:51+00:00</dc:date>
    <link>https://blogs.scientificamerican.com/sa-visual/pop-culture-pulsar-origin-story-of-joy-division-s-unknown-pleasures-album-cover-video/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Great dig into the CP1919 pulsar signal plot that was used for "Unknown Pleasures":

<blockquote>This plotting of sequences like this, it started just a little bit earlier when we were looking at potentially drifting subpulses within the major pulse itself. So, the thought was, well, is there something like this peak here, which on the next pulse moves over here, and then moves over here, and over there. Actually, would be moving this way in that case – either way. I think Frank Drake and I published a paper in Science Magazine on exactly that issue – suggesting there might be drifting subpulses within the major pulse, which would then get back to the physics of what was causing the emission in the first place. So, then the thought was, well let’s plot out a whole array of pulses, and see if we can see particular patterns in there. So that’s why, this one was the first I did – CP1919 – and you can pick out patterns in there if you really work at it. But I think the answer is, there weren’t any that were real obvious anyway. I don’t really recall, but my bet is that the first one of these that I did, I didn’t bother to block out the stuff, and I found that it was just too confusing. So then, I wrote the program so that I would block out when a hill here was high enough, then the stuff behind it would stay hidden. And it was pretty easy to do from a computer perspective.</blockquote>

]]></description>
<dc:subject>design joy-division music science physics pulsars astronomy cp1919 dataviz</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5857d82604fc/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:joy-division"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:music"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:science"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:physics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pulsars"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:astronomy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cp1919"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dataviz"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.mukama.com/en/">
    <title>Mukama</title>
    <dc:date>2021-05-19T11:29:32+00:00</dc:date>
    <link>https://www.mukama.com/en/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['Essentials for your daily round' -- a really lovely set of EDC products, and not _too_ crazy expensive....]]></description>
<dc:subject>edc keys wallets tools gadgets design</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f03246060569/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:edc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:keys"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wallets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gadgets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://irelandcoins.ie/percy-metcalfe/">
    <title>Irish coins designed by Percy Metcalfe</title>
    <dc:date>2020-08-20T10:26:30+00:00</dc:date>
    <link>https://irelandcoins.ie/percy-metcalfe/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[the coins used in Ireland between 1928 and 2000 (when the Euro became standard here). Beautiful, classic designs ]]></description>
<dc:subject>coins history ireland numismatism design art money</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b4185452585f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coins"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:history"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ireland"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:numismatism"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:art"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:money"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.designedbycave.co.uk/2020/LEGO-Interface-UX/">
    <title>The UX of LEGO Interface Panels – George Cave</title>
    <dc:date>2020-08-04T12:26:49+00:00</dc:date>
    <link>https://www.designedbycave.co.uk/2020/LEGO-Interface-UX/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[love it]]></description>
<dc:subject>lego ux ui design funny</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:73ce2c81c8cc/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lego"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ui"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:funny"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.presentandcorrect.com/27986-2">
    <title>Button it. | Present&amp;Correct</title>
    <dc:date>2020-05-27T13:47:21+00:00</dc:date>
    <link>http://blog.presentandcorrect.com/27986-2</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Whole load of photos of Soviet nuclear power station control panels here. What an aesthetic
]]></description>
<dc:subject>soviet control nuclear design history power dashboards control-panels buttons lights beeping</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e3da3b082e18/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:soviet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:control"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nuclear"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:history"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:power"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dashboards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:control-panels"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:buttons"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lights"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:beeping"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.projectopenair.org/">
    <title>Project Open Air</title>
    <dc:date>2020-03-15T13:08:39+00:00</dc:date>
    <link>https://www.projectopenair.org/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>We are working on medical devices, such as open source ventilators, to have a fast and easy solution that can be reproduced and assembled locally worldwide.  If you have any skills that you consider might help, join the Helpful Engineering group.</blockquote>

]]></description>
<dc:subject>health medicine ventilators devices hardware design engineering covid-19</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ea8039705a68/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:health"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:medicine"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ventilators"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:devices"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hardware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:engineering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:covid-19"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://pair.withgoogle.com/">
    <title>People + AI Guidebook</title>
    <dc:date>2020-01-21T11:07:01+00:00</dc:date>
    <link>https://pair.withgoogle.com/</link>
    <dc:creator>jm</dc:creator><description><![CDATA["Designing human-centered AI products".  Some good UX recommendations when working with AI smarts behind the scenes]]></description>
<dc:subject>ux ai design google graphics tips machine-learning</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:717d33fb1d13/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tips"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:machine-learning"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.acolyer.org/2020/01/08/ironies-of-automation/">
    <title>Ironies of automation</title>
    <dc:date>2020-01-09T17:32:47+00:00</dc:date>
    <link>https://blog.acolyer.org/2020/01/08/ironies-of-automation/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Wow, this is a great paper recommendation from Adrian Colyer - 'Ironies of automation', Bainbridge, Automatica, Vol. 19, No. 6, 1983.

<blockquote>In an automated system, two roles are left to humans: monitoring that the automated system is operating correctly, and taking over control if it isn’t. An operator that doesn’t routinely operate the system will have atrophied skills if ever called on to take over.

Unfortunately, physical skills deteriorate when they are not used, particularly the refinements of gain and timing. This means that a formerly experienced operator who has been monitoring an automated process may now be an inexeperienced one.

Not only are the operator’s skills declining, but the situations when the operator will be called upon are by their very nature the most demanding ones where something is deemed to be going wrong. Thus what we really need in such a situation is a more, not a lesser skilled operator! To generate successful strategies for unusual situtations, an operator also needs good understanding of the process under control, and the current state of the system. The former understanding develops most effectively through use and feedback (which the operator may no longer be getting the regular opportunity for), the latter takes some time to assimilate.</blockquote>

(via John Allspaw)]]></description>
<dc:subject>via:allspaw automation software reliability debugging ops design failsafe failure human-interfaces ui ux outages</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:8dde64ad2f41/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:allspaw"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:automation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reliability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:debugging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:failsafe"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:failure"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:human-interfaces"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ui"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:outages"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://twitter.com/davidcrawshaw/status/1178478240970600450">
    <title>JSON originally had comments. They were removed</title>
    <dc:date>2019-10-01T10:52:04+00:00</dc:date>
    <link>https://twitter.com/davidcrawshaw/status/1178478240970600450</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Oh christ.  This is some terrible logic from Douglas Crockford:

<blockquote>
Comments in JSON (Apr 30, 2012)

I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability.  I know that the lack of comments makes some people sad, but it shouldn't.

Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.
</blockquote>

I've never even _heard_ of JSMin.  Meanwhile various tools which chose to use JSON as a configuration file format work around this crappy decision with messy hacks.]]></description>
<dc:subject>hacks json bad-decisions design apis configuration file-formats javascript douglas-crockford fail jsmin parsing comments</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:feb4d4589a64/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:json"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bad-decisions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:configuration"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:file-formats"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:javascript"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:douglas-crockford"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fail"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jsmin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:parsing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:comments"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://shape19.imascientist.ie/">
    <title>Shape the future: 3D Printing a Sustainable World</title>
    <dc:date>2019-09-03T11:53:33+00:00</dc:date>
    <link>https://shape19.imascientist.ie/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>our planet needs bright ideas and new ways of thinking, consuming and living.  Pitch your idea and I-Form, the SFI Research Centre for Advanced Manufacturing, will turn the winning idea for sustainability into 3D printed reality.</blockquote>

]]></description>
<dc:subject>3d-printing future sustainability design ireland sfi</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:acfc015d6b29/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:3d-printing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:future"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sustainability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ireland"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sfi"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.fastcompany.com/90395110/how-googly-eyes-solved-one-of-todays-trickiest-ux-problems">
    <title>How googly eyes solved one of today’s trickiest UX problems</title>
    <dc:date>2019-08-29T13:11:36+00:00</dc:date>
    <link>https://www.fastcompany.com/90395110/how-googly-eyes-solved-one-of-todays-trickiest-ux-problems</link>
    <dc:creator>jm</dc:creator><description><![CDATA['A little robot at a library in Helsinki went from reviled to beloved, all because it got a new pair of plastic eyes.' AWWWW

]]></description>
<dc:subject>googly-eyes robots ux design cute funny</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0cb2c1bb6cf1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:googly-eyes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:robots"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cute"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:funny"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.quora.com/Why-do-some-developers-at-strong-companies-like-Google-consider-Agile-development-to-be-nonsense/answer/David-Jeske?share=1">
    <title>David Jeske's answer to Why do some developers at strong companies like Google consider Agile development to be nonsense? - Quora</title>
    <dc:date>2019-08-06T11:57:13+00:00</dc:date>
    <link>https://www.quora.com/Why-do-some-developers-at-strong-companies-like-Google-consider-Agile-development-to-be-nonsense/answer/David-Jeske?share=1</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Wow, this is a great answer.  As he notes, the Scrum-style process is flawed for big backend projects:

"This style of short-term planning, direct customer contact, and continuous iteration is well suited to software with a simple core and lots of customer visible features that are incrementally useful. It is not so well suited to software which has a very simple interface and tons of hidden internal complexity, software which isn’t useful until it’s fairly complete, or leapfrog solutions the customer can’t imagine."

And he goes on to come up with something which works better for Google-style projects:

<blockquote>
Our highest priority is to increase customer (and programmer) productivity and access to information. Work on the biggest, most frequently used problems you can find, and create the largest net impact. Don’t give the customer what they ask for; understand them, and revolutionize their world.

Developers should create a Google Design Document (a fairly minimal, but structured design doc), explaining the project, what goals it hopes to achieve, and explains why it can’t be done in other ways. This document should be circulated with stakeholders, to get early feedback before the project gets underway. The written record is essential, as it assures there is a clear and agreed understanding of when the project is a success and how it aims to get there.
At all phases of the project, critical design elements for larger components should be concisely explained and captured in a design document.

Innovate in leapfrogs. It’s more important to finish and deploy a leapfrog than to attempt perfection. There is no perfection. Instead be flexible, and plan to constantly reinvent at every level of the stack.

Deliver working software as soon as is reasonably possible, and no sooner. “Dogfood” projects internally before they are shipped externally. Make sure products meet high quality standards before shipping. The quality of the product is more important than the time it takes to achieve it.</blockquote>

]]></description>
<dc:subject>agile architecture google scrum development coding projects project-management design</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a6046dfadf0d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:agile"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scrum"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:development"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:projects"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:project-management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://twitter.com/ItsTheShadsy/status/1151868012707962881">
    <title>twitter thread on how same-sex romance was added to The Sims back in 1998</title>
    <dc:date>2019-07-25T09:28:24+00:00</dc:date>
    <link>https://twitter.com/ItsTheShadsy/status/1151868012707962881</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Phil Salvador on Twitter: "Sims developer Don Hopkins released a bunch of design documents from The Sims, including this one from August 1998 with his notes about romance: [...] It's incredible to see the internal discussion about romance in The Sims written out so strongly like this."]]></description>
<dc:subject>don-hopkins games history the-sims design romance 1990s</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b0a787e27996/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:don-hopkins"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:games"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:history"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:the-sims"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:romance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:1990s"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://nyc.streetsblog.org/2019/06/03/op-ed-breaking-down-barriers-to-disabled-cyclists/">
    <title>two-thirds of cyclists with disabilities find cycling easier than walking</title>
    <dc:date>2019-06-06T09:33:02+00:00</dc:date>
    <link>https://nyc.streetsblog.org/2019/06/03/op-ed-breaking-down-barriers-to-disabled-cyclists/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[and other facts about disabled cyclists.  This is very thought-provoking stuff.

<blockquote>According to a recent study by Wheels for Well-being, a British organization of disabled cyclists, 15 percent of people with disabilities cycle, compared with 18 percent of the general population. Moreover, two-thirds of cyclists with disabilities find cycling easier than walking, the group says.

Clearly, bikes are not just a mode of transit, but function as mobility devices for many disabled people. I find it ableist, or prejudiced against the disabled, when we consider e-bikes and other adaptive-cycling methods as “inferior.” Many of us can ride a traditional two-wheeled bicycle, but others simply can’t.</blockquote>

]]></description>
<dc:subject>cycling disability accessibility cities design cycles disabled</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c98cd333f1ee/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cycling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:disability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:accessibility"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cities"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cycles"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:disabled"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.buzzfeednews.com/article/mikemonteiro/we-built-a-broken-internet-now-we-need-to-burn-it">
    <title>We Built A Broken Internet. Now We Need To Burn It To The Ground.</title>
    <dc:date>2019-04-01T21:12:47+00:00</dc:date>
    <link>https://www.buzzfeednews.com/article/mikemonteiro/we-built-a-broken-internet-now-we-need-to-burn-it</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>The promise of the internet was that it was going to give voice to the voiceless, visibility to the invisible, and power to the powerless. That’s what originally excited me about it. That’s what originally excited a ton of people about it. It was supposed to be an engine of equality. Suddenly, everyone could tell their story. Suddenly, everyone could sing their song. Suddenly, that one weird kid in Helena, Montana, could find another weird kid just like them in Bakersfield, California, and they could talk and know they weren’t alone. Suddenly, we didn’t need anybody’s permission to publish. We put our stories and songs and messages and artwork where the world could find them. For a while it was beautiful, it was messy, and it was punk as fuck. We all rolled up our sleeves and helped to build it.

We were the ones who were supposed to guide it there, and we failed. We failed because we were naive enough to believe everyone had the same goals we did. We failed because we underestimated greed. We failed because we didn’t pay attention to history. We failed because our definition of we wasn’t big enough.

We designed and built platforms that undermined democracy across the world. We designed and built technology that is used to round up immigrants and refugees and put them in cages. We designed and built platforms that young, stupid, hateful men use to demean and shame women. We designed and built an entire industry that exploits the poor in order to make old rich men even richer.</blockquote>

]]></description>
<dc:subject>design ethics internet web twitter social-media</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:4b0be05e86cf/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ethics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:twitter"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:social-media"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.usenix.org/sites/default/files/conference/protected-files/srecon18americas_slides_virji.pdf">
    <title>slides from &quot;Distributed Log-Processing Design Workshop&quot;, SRECon Americas 2018</title>
    <dc:date>2018-12-20T11:07:07+00:00</dc:date>
    <link>https://www.usenix.org/sites/default/files/conference/protected-files/srecon18americas_slides_virji.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Fantastic presentation discussing the kinds of design criteria used when architecting a large-scale data processing and storage service.  Interesting to see some Google terminology, e.g. "dimensioning" -- ballparking the expected scalability numbers, bandwidth, qps, and limits.]]></description>
<dc:subject>distributed-systems coding design architecture google photon logs log-storage slides srecon</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c50bc41c6207/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distributed-systems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<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:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:photon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:logs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:log-storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:slides"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:srecon"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://techcrunch.com/2018/04/17/facebook-gdpr-changes/">
    <title>A flaw-by-flaw guide to Facebook’s new GDPR privacy changes | TechCrunch</title>
    <dc:date>2018-04-18T15:07:01+00:00</dc:date>
    <link>https://techcrunch.com/2018/04/17/facebook-gdpr-changes/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Overall, it seems like Facebook is complying with the letter of GDPR law, but with questionable spirit. Sure, privacy is boring to a lot of people. Too little info and they feel confused and scared. Too many choices and screens and they feel overwhelmed and annoyed. Facebook struck the right balance in some places here. But the subtly pushy designs seem intended to steer people away from changing their defaults in ways that could hamper Facebook’s mission and business.</blockquote>

]]></description>
<dc:subject>gdpr design facebook privacy data-protection data-privacy social-networking eu law</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b2f326655ebb/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gdpr"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:facebook"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:privacy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-protection"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-privacy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:social-networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:eu"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:law"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/best-practices.html">
    <title>Best Practices for DynamoDB</title>
    <dc:date>2018-04-17T09:51:56+00:00</dc:date>
    <link>https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/best-practices.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Amazon have updated this architectural tips doc for DynamoDB users -- good reference]]></description>
<dc:subject>dynamodb nosql aws storage databases design coding</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:cb830b6ff7c4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dynamodb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nosql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.reddit.com/r/aws/comments/7phlq2/best_way_designing_a_gdpr_compliant_datalake/">
    <title>Best way designing a GDPR compliant datalake using AWS services : aws</title>
    <dc:date>2018-01-11T17:23:49+00:00</dc:date>
    <link>https://www.reddit.com/r/aws/comments/7phlq2/best_way_designing_a_gdpr_compliant_datalake/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[interesting thread at Reddit]]></description>
<dc:subject>gdpr reddit aws tips design services ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:740cf65fe3c8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gdpr"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reddit"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tips"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://singletrackworld.com/2018/01/collision-course-why-this-type-of-road-junction-will-keep-killing-cyclists/">
    <title>Collision Course: Why This Type Of Road Junction Will Keep Killing Cyclists</title>
    <dc:date>2018-01-10T13:41:24+00:00</dc:date>
    <link>http://singletrackworld.com/2018/01/collision-course-why-this-type-of-road-junction-will-keep-killing-cyclists/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This aspect of road design had never occurred to me, but once explained it makes sense.  Great article on the design of an oblique crossroads junction and how it's unexpectedly dangerous due to human factors and car design.

<blockquote>“Human error” may be real, but so are techniques to mitigate or eliminate its effects — and driver training is poor when it comes to equipping people with those techniques, let alone habituating them. (And let alone reviewing knowledge of those techniques every few years.)
</blockquote>

]]></description>
<dc:subject>cars cycling road-safety safety accidents traffic junctions road-design design human-error human-factors</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:31334714bb0e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cars"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cycling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:road-safety"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:safety"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:accidents"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:traffic"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:junctions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:road-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:human-error"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:human-factors"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://londonist.com/london/transport/london-cutaways">
    <title>London's Hidden Tunnels Revealed In Amazing Cutaways | Londonist</title>
    <dc:date>2017-10-09T09:59:40+00:00</dc:date>
    <link>http://londonist.com/london/transport/london-cutaways</link>
    <dc:creator>jm</dc:creator><description><![CDATA[these really are remarkable.  I love the Renzo Picassos in particular]]></description>
<dc:subject>design history london 3d cutaways diagrams comics mid-century</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:7a16b7d52c31/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:history"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:london"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:3d"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cutaways"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:diagrams"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:comics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mid-century"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aadrake.com/posts/2017-05-20-enough-with-the-microservices.html">
    <title>Enough with the microservices</title>
    <dc:date>2017-05-25T11:22:46+00:00</dc:date>
    <link>https://aadrake.com/posts/2017-05-20-enough-with-the-microservices.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Good post!

<blockquote>Much has been written on the pros and cons of microservices, but unfortunately I’m still seeing them as something being pursued in a cargo cult fashion in the growth-stage startup world. At the risk of rewriting Martin Fowler’s Microservice Premium article, I thought it would be good to write up some thoughts so that I can send them to clients when the topic arises, and hopefully help people avoid some of the mistakes I’ve seen. The mistake of choosing a path towards a given architecture or technology on the basis of so-called best practices articles found online is a costly one, and if I can help a single company avoid it then writing this will have been worth it.
</blockquote>

]]></description>
<dc:subject>architecture design microservices coding devops ops monolith</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:933b1a0bc792/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:microservices"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:devops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monolith"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.bolt.io/heres-why-juicero-s-press-is-so-expensive-6add74594e50">
    <title>Here’s Why Juicero’s Press is So Expensive – Bolt Blog</title>
    <dc:date>2017-04-25T10:13:11+00:00</dc:date>
    <link>https://blog.bolt.io/heres-why-juicero-s-press-is-so-expensive-6add74594e50</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Our usual advice to hardware founders is to focus on getting a product to market to test the core assumptions on actual target customers, and then iterate. Instead, Juicero spent $120M over two years to build a complex supply chain and perfectly engineered product that is too expensive for their target demographic.

Imagine a world where Juicero raised only $10M and built a product subject to significant constraints. Maybe the Press wouldn’t be so perfectly engineered but it might have a fewer features and cost a fraction of the original $699. Or maybe with a more iterative approach, they would have quickly found that customers vary greatly in their juice consumption patterns, and would have chosen a per-pack pricing model rather than one-size-fits-all $35/week subscription. Suddenly Juicero is incredibly compelling as a product offering, at least to this consumer.</blockquote>

]]></description>
<dc:subject>juicero design electronics hardware products startups engineering teardowns</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d783778cc083/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:juicero"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:electronics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hardware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:products"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:startups"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:engineering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:teardowns"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.blindltd.com/rogue-one">
    <title>BLIND's work on UIs for Rogue One</title>
    <dc:date>2016-12-23T21:37:23+00:00</dc:date>
    <link>http://www.blindltd.com/rogue-one</link>
    <dc:creator>jm</dc:creator><description><![CDATA[beautifully retro to match Episode 4]]></description>
<dc:subject>star-wars rogue-one ui design graphics via:jk</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0116e18b337e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:star-wars"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rogue-one"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ui"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:jk"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.itsnicethat.com/news/google-monotype-noto-type-family-061016">
    <title>Google and Monotype launch Noto, an open-source typeface family for all the world’s languages</title>
    <dc:date>2016-10-07T12:51:15+00:00</dc:date>
    <link>http://www.itsnicethat.com/news/google-monotype-noto-type-family-061016</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Great font factoid: 'The name “Noto” comes from the little squares that show when a font is not supported by a computer. This are often referred to as “tofu”, because of their shape, therefore the font is short for No Tofu.']]></description>
<dc:subject>tofu fonts i18n google design typography unicode</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b8bb772a76c9/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tofu"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fonts"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:i18n"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:typography"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unicode"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.acolyer.org/2016/10/06/simple-testing-can-prevent-most-critical-failures/">
    <title>Simple testing can prevent most critical failures</title>
    <dc:date>2016-10-06T09:25:42+00:00</dc:date>
    <link>https://blog.acolyer.org/2016/10/06/simple-testing-can-prevent-most-critical-failures/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Specifically, the following 3 classes of errors were implicated in 92% of the major production outages in this study and could have been caught with simple code review:

<blockquote>Error handlers that ignore errors (or just contain a log statement);  error handlers with “TODO” or “FIXME” in the comment; and error handlers that catch an abstract exception type (e.g. Exception or Throwable in Java) and then take drastic action such as aborting the system. </blockquote>

(Interestingly, the latter was a particular favourite approach of some misplaced "fail fast"/"crash-only software design" dogma in Amazon. I wasn't a fan)]]></description>
<dc:subject>fail-fast crash-only-software coding design bugs code-review review outages papers logging errors exceptions</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2e3db77ebdbb/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fail-fast"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:crash-only-software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bugs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:code-review"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:review"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:outages"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:papers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:logging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:errors"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:exceptions"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://martinfowler.com/bliki/TechnicalDebtQuadrant.html">
    <title>The Technical Debt Quadrant</title>
    <dc:date>2016-10-05T13:29:28+00:00</dc:date>
    <link>http://martinfowler.com/bliki/TechnicalDebtQuadrant.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Martin Fowler's take on the 4 kinds of tech debt]]></description>
<dc:subject>programming design tech-debt technical-debt deadlines product ship</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ed1c826ba271/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tech-debt"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:technical-debt"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:deadlines"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:product"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ship"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.citylab.com/design/2011/09/street-grids/124/">
    <title>The Problem With Cul-de-Sac Design - CityLab</title>
    <dc:date>2016-09-21T11:09:51+00:00</dc:date>
    <link>http://www.citylab.com/design/2011/09/street-grids/124/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>“A lot of people feel that they want to live in a cul-de-sac, they feel like it’s a safer place to be,” Marshall says. “The reality is yes, you’re safer – if you never leave your cul-de-sac. But if you actually move around town like a normal person, your town as a whole is much more dangerous.”

This is the opposite of what traffic engineers (and home buyers) have thought for decades. And it’s just the beginning of what we’re now starting to understand about the relative advantages of going back to the way we designed communities a century ago.

Marshall and Garrick took the same group of California cities and also examined all their minutely classified street networks for the amount of driving associated with them. On average, they found, people who live in more sparse, tree-like communities drive about 18 percent more than people who live in dense grids. And that’s a conservative calculation.</blockquote>

(via Tony Finch)]]></description>
<dc:subject>cul-de-sacs cities city design layout simcity grids safety</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:43d4aba86831/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cul-de-sacs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cities"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:city"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:layout"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:simcity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:grids"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:safety"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://basho.com/posts/technical/microservices-please-dont/">
    <title>Microservices – Please, don’t</title>
    <dc:date>2016-09-19T16:03:04+00:00</dc:date>
    <link>http://basho.com/posts/technical/microservices-please-dont/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[great list of Microservices gotchas from Sean Kelly.  see also https://news.ycombinator.com/item?id=12508655]]></description>
<dc:subject>architecture design distributed-systems microservices soa devops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:80695d510a92/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distributed-systems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:microservices"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:soa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:devops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://fuckyournoguchicoffeetable.tumblr.com/?og=1">
    <title>Fuck Your Noguchi Coffee Table</title>
    <dc:date>2016-09-09T13:39:02+00:00</dc:date>
    <link>http://fuckyournoguchicoffeetable.tumblr.com/?og=1</link>
    <dc:creator>jm</dc:creator><description><![CDATA["fuck your bookshelf with all of the spines facing in"]]></description>
<dc:subject>funny fuck-this noguchi coffee-tables furniture design</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:9d0c2f597350/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:funny"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fuck-this"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:noguchi"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coffee-tables"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:furniture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.vellumatlanta.com/2016/05/04/apple-stole-my-music-no-seriously/">
    <title>Apple Stole My Music. No, Seriously.</title>
    <dc:date>2016-05-05T13:11:24+00:00</dc:date>
    <link>https://blog.vellumatlanta.com/2016/05/04/apple-stole-my-music-no-seriously/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[some amazingly terrible product decisions here.  Deleting local copies of unreleased WAV files -- on the assumption that the user will simply listen to them streamed down from Apple Music -- that is astonishingly bad, and it's amazing they didn't consider the "freelance composer" use case at all.  (via Tony Finch)]]></description>
<dc:subject>apple music terrible wav sound copyright streaming apple-music design product fail</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:4472dfb3552c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apple"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:music"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:terrible"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wav"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sound"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:copyright"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:streaming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apple-music"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:product"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fail"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.bbc.com/future/story/20160325-the-names-that-break-computer-systems">
    <title>These unlucky people have names that break computers</title>
    <dc:date>2016-03-29T11:55:39+00:00</dc:date>
    <link>http://www.bbc.com/future/story/20160325-the-names-that-break-computer-systems</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Pat McKenzie's name is too long to fit in Japanese database schemas; Janice Keihanaikukauakahihulihe'ekahaunaele's name was too long for US schemas; and Jennifer Null suffers from the obvious problem]]></description>
<dc:subject>databases design programming names coding japan schemas</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:005f384de103/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:names"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:japan"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:schemas"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.cleancoder.com/uncle-bob/2016/03/19/GivingUpOnTDD.html">
    <title>Uncle Bob on &quot;giving up TDD&quot;</title>
    <dc:date>2016-03-22T10:58:33+00:00</dc:date>
    <link>http://blog.cleancoder.com/uncle-bob/2016/03/19/GivingUpOnTDD.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is a great point, and one I'll be quoting:

<blockquote>Any design that is hard to test is crap. Pure crap. Why? Because if it's hard to test, you aren't going to test it well enough. And if you don't test it well enough, it's not going to work when you need it to work. And if it doesn't work when you need it to work the design is crap.</blockquote>

Amen!]]></description>
<dc:subject>testing tdd uncle-bob coding design testability unit-tests</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:42b575986da3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tdd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:uncle-bob"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unit-tests"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.lonelyplanet.com/ireland/dublin/travel-tips-and-articles/hip-cafes-and-hot-design-exploring-the-new-dublin">
    <title>Hip cafes and hot design: exploring the new Dublin - Lonely Planet</title>
    <dc:date>2016-01-11T12:10:49+00:00</dc:date>
    <link>https://www.lonelyplanet.com/ireland/dublin/travel-tips-and-articles/hip-cafes-and-hot-design-exploring-the-new-dublin</link>
    <dc:creator>jm</dc:creator><description><![CDATA[I haven't been to half of these places!  Good tips]]></description>
<dc:subject>dublin cafes design shops tovisit</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0830717e0e28/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dublin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cafes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:shops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tovisit"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.pixelmator.com/mac/">
    <title>Pixelmator</title>
    <dc:date>2015-12-04T12:01:39+00:00</dc:date>
    <link>http://www.pixelmator.com/mac/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Image editing tool for the Mac, recommended by Oisin]]></description>
<dc:subject>images design graphics mac osx tools apps</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0957fc41f228/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:images"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mac"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:osx"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apps"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://isdublinbusy.com/">
    <title>Is Dublin Busy?</title>
    <dc:date>2015-11-28T16:05:48+00:00</dc:date>
    <link>http://isdublinbusy.com/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[a bunch of metrics for Dublin xmas-shopping capacity]]></description>
<dc:subject>xmas dublin metrics design stats</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:61760fdc6169/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:xmas"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dublin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:stats"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://twitter.com/cabel/status/648680009381511168">
    <title>Cabel Sasser on Twitter: &quot;From a &quot;cash for phones&quot; ATM in the mall (in maintenance mode): @daveaddey finds the most amazing UI ever created. http://t.co/0qKg68wHjQ 😧&quot;</title>
    <dc:date>2015-09-29T16:26:53+00:00</dc:date>
    <link>https://twitter.com/cabel/status/648680009381511168</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Amazing. This is what happens when embedded software engineers make a UI, in my experience]]></description>
<dc:subject>embedded-software ui ux design graphics windows the-horror omgwtf atms</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:9b45bc91bb39/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:embedded-software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ui"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:windows"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:the-horror"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:omgwtf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:atms"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://msol.io/blog/tech/2015/09/05/youre-probably-wrong-about-caching/">
    <title>You're probably wrong about caching</title>
    <dc:date>2015-09-07T10:49:36+00:00</dc:date>
    <link>https://msol.io/blog/tech/2015/09/05/youre-probably-wrong-about-caching/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Excellent cut-out-and-keep guide to why you should add a caching layer.  I've been following this practice for the past few years, after I realised that #6 (recovering from a failed cache is hard) is a killer -- I've seen a few large-scale outages where a production system had gained enough scale that it required a cache to operate, and once that cache was damaged, bringing the system back online required a painful rewarming protocol.  Better to design for the non-cached case if possible.]]></description>
<dc:subject>architecture caching coding design caches ops production scalability</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:580ce012d9e2/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:caching"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:caches"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:production"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://deardesignstudent.com/in-praise-of-the-ak-47-a24cc8a46c13">
    <title>In Praise of the AK-47 — Dear Design Student — Medium</title>
    <dc:date>2015-07-27T22:22:51+00:00</dc:date>
    <link>https://deardesignstudent.com/in-praise-of-the-ak-47-a24cc8a46c13</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>While someone can certainly make the case that an AK-47, or any other kind of gun or rifle is designed, nothing whose primary purpose is to take away life can be said to be designed well. And that attempting to separate an object from its function in order to appreciate it for purely aesthetic reasons, or to be impressed by its minimal elegance, is a coward’s way of justifying the death they’ve designed into the word, and the money with which they’re lining their pockets.</blockquote>

]]></description>
<dc:subject>design ux ak-47 kalashnikov guns function work</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2714d3a1ff81/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ak-47"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kalashnikov"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:guns"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:function"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:work"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://radleymarx.com/blog/simple-guide-to-9-patch/">
    <title>A simple guide to 9-patch for Android UI</title>
    <dc:date>2015-07-16T13:41:34+00:00</dc:date>
    <link>http://radleymarx.com/blog/simple-guide-to-9-patch/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is a nifty hack.  TIL!

'9-patch uses png transparency to do an advanced form of 9-slice or scale9. The guides are straight, 1-pixel black lines drawn on the edge of your image that define the scaling and fill of your image. By naming your image file name.9.png, Android will recognize the 9.png format and use the black guides to scale and fill your bitmaps.']]></description>
<dc:subject>android design 9-patch scaling images bitmaps scale9 9-slice ui graphics</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b41718f48439/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:android"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:9-patch"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:images"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bitmaps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scale9"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:9-slice"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ui"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://colossalshop.com/">
    <title>The Colossal Shop</title>
    <dc:date>2015-04-29T20:56:22+00:00</dc:date>
    <link>http://colossalshop.com/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[ThisIsColossal now have a shop! bookmarking for some lovely gifts]]></description>
<dc:subject>art design shop colossal shopping christmas gifts</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e3aa9e6c0e67/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:art"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:shop"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:colossal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:shopping"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:christmas"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gifts"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.ustream.tv/recorded/61486500">
    <title>'Microservice AntiPatterns'</title>
    <dc:date>2015-04-28T13:22:41+00:00</dc:date>
    <link>http://www.ustream.tv/recorded/61486500</link>
    <dc:creator>jm</dc:creator><description><![CDATA[presentation from last week's Craft Conference in Budapest; Tammer Saleh of Pivotal with a few antipatterns observed in dealing with microservices.]]></description>
<dc:subject>microservices soa architecture design coding software presentations slides tammer-saleh pivotal craft</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2c706e32b817/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:microservices"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:soa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<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:presentations"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:slides"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tammer-saleh"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pivotal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:craft"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.squarespace.com/">
    <title>Squarespace</title>
    <dc:date>2015-04-17T22:00:25+00:00</dc:date>
    <link>http://www.squarespace.com/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Nice, simple "build a website" platform.  Keeping this one bookmarked for the next time someone non-techie asks me for the simplest way to do just that (thanks for the tip, Oisin)]]></description>
<dc:subject>via:oisin blog cms design hosting web-design web websites</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f9e94f3d504e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:oisin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:blog"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hosting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:web-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:websites"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://asciiflow.com/">
    <title>ASCIIFlow</title>
    <dc:date>2015-03-04T23:05:53+00:00</dc:date>
    <link>http://asciiflow.com/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Excellent web-based ASCII-art editor (via Craig)]]></description>
<dc:subject>via:craig design ascii diagrams editor ascii-art art asciiflow drawing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b1e4fb83a031/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:craig"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ascii"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:diagrams"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:editor"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ascii-art"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:art"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:asciiflow"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:drawing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.zeldman.com/2014/12/28/unexamined-privilege-is-the-real-source-of-cruelty-in-facebooks-your-year-in-review/">
    <title>Zeldman on Facebook's &quot;Year In Review&quot; feature</title>
    <dc:date>2014-12-29T11:47:42+00:00</dc:date>
    <link>http://www.zeldman.com/2014/12/28/unexamined-privilege-is-the-real-source-of-cruelty-in-facebooks-your-year-in-review/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is a great point.

<blockquote>When you put together teams of largely homogenous people of the same class and background, and pay them a lot of money, and when most of those people are under 30, it stands to reason that when someone in the room says, “Let’s do ‘your year in review, and front-load it with visuals,’” most folks in the room will imagine photos of skiing trips, parties, and awards shows— not photos of dead spouses, parents, and children.

So it comes back to this. When we talk about the need for diversity in tech, we’re not doing it because we like quota systems. Diverse backgrounds produce differing points of view. And those differences are needed if we are to put the flowering of internet genius to use actually helping humanity with its many terrifying and seemingly intractable problems.</blockquote>

]]></description>
<dc:subject>best-practices sensitivity culture design silicon-valley youth privilege facebook</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:4d86836aae34/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:best-practices"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sensitivity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:culture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:silicon-valley"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:youth"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:privilege"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:facebook"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.beerlabelizer.com/">
    <title>Beer Labelizer</title>
    <dc:date>2014-11-23T23:28:29+00:00</dc:date>
    <link>http://www.beerlabelizer.com/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['Design your own beer labels']]></description>
<dc:subject>beer labels generator flash design bottling</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c4caa7b941ca/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:beer"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:labels"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:generator"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:flash"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bottling"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://bldgblog.blogspot.ie/2014/09/procedural-brutalism.html">
    <title>BLDGBLOG: Procedural Brutalism</title>
    <dc:date>2014-09-09T08:54:25+00:00</dc:date>
    <link>http://bldgblog.blogspot.ie/2014/09/procedural-brutalism.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>a few GIFs of procedurally generated architecture by a game developer named Cedric, built using Unity. Cedric describes himself as an "indie game dev focused on social AI, emergent narrative and procedural worlds." Imagine whole game worlds powered by real-time computation at the building level, constantly and parametrically fizzing with architectural forms, barely predictable new Woolworth Buildings and Barbicans sprouting on-demand from the ground whenever needed.</blockquote>

]]></description>
<dc:subject>brutalism architecture games graphics design procedural generation gifs animation</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1ebdb7ff1019/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:brutalism"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:games"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:procedural"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:generation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gifs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:animation"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.90percentofeverything.com/2014/08/26/some-dark-patterns-now-illegal-in-uk-interview-with-heather-burns/">
    <title>Some UX Dark Patterns now illegal in the EU</title>
    <dc:date>2014-09-01T15:18:11+00:00</dc:date>
    <link>http://www.90percentofeverything.com/2014/08/26/some-dark-patterns-now-illegal-in-uk-interview-with-heather-burns/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>The EU’s new consumer rights law bans certain dark patterns related to e-commerce across Europe. The “sneak into basket” pattern is now illegal. Full stop, end of story. You cannot create a situation where additional items and services are added by default. [...]

Hidden costs are now illegal, whether that’s an undeclared subscription, extra shipping charges, or extra items. [....]

Forced continuity, when imposed on the user as a form of bait-and-switch, has been banned. Just the other day a web designer mentioned to me that he had only just discovered he had been charged for four years of annual membership dues in a “theme club”, having bought what he thought was a one-off theme. Since he lives in Europe, he may be able to claim all of this money back. All he needs to do is prove that the website did not inform him that the purchase included a membership with recurring payments.</blockquote>

]]></description>
<dc:subject>design europe law ecommerce ux dark-patterns scams ryanair selling online consumer consumer-rights bait-and-switch</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:eb827a186477/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:europe"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:law"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ecommerce"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dark-patterns"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scams"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ryanair"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:selling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:online"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:consumer"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:consumer-rights"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bait-and-switch"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.infoworld.com/d/data-center/systemd-harbinger-of-the-linux-apocalypse-248436?source=rss_data_center">
    <title>Systemd: Harbinger of the Linux apocalypse</title>
    <dc:date>2014-08-18T13:40:05+00:00</dc:date>
    <link>http://www.infoworld.com/d/data-center/systemd-harbinger-of-the-linux-apocalypse-248436?source=rss_data_center</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>While there are many defensible aspects of Systemd, other aspects boggle the mind. Not the least of these was that, as of a few months ago, trying to debug the kernel from the boot line would cause the system to crash. This was because of Systemd's voracious logging and the fact that Systemd responds to the "debug" flag on the kernel boot line -- a flag meant for the kernel, not anything else. That, straight up, is a bug.

However, the Systemd developers didn't see it that way and actively fought with those experiencing the problem. Add the fact that one of the Systemd developers was banned by Linus Torvalds for poor attitude and bad design and another was responsible for causing significant issues with Linux audio support, but blamed the problem on everything else but his software, and you have a bad situation on your hands.

There's no shortage of egos in the open source development world. There's no shortage of new ideas and veteran developers and administrators pooh-poohing something new simply because it's new. But there are also 45 years of history behind Unix and extremely good reasons it's still flourishing. Tools designed like Systemd do not fit the Linux mold, to their own detriment. Systemd's design has more in common with Windows than with Unix -- down to the binary logging.</blockquote>

The link re systemd consuming the "debug" kernel boot arg is a canonical example of inflexible coders refusing to fix their own bugs.  (via Jason Dixon)
]]></description>
<dc:subject>systemd linux red-hat egos linus-torvalds unix init booting debugging logging design software via:obfuscurity</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1a3ccdd34802/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:systemd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:red-hat"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:egos"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linus-torvalds"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:init"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:booting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:debugging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:logging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:obfuscurity"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.thisiscolossal.com/2014/07/layered-glass-table-concept-duffy-london/">
    <title>Layered Glass Table Concept Creates a Cross-Section of the Ocean</title>
    <dc:date>2014-07-06T21:24:09+00:00</dc:date>
    <link>http://www.thisiscolossal.com/2014/07/layered-glass-table-concept-duffy-london/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[beautiful stuff -- and a snip at only UKP 5,800 ex VAT.  it'd make a good DIY project though ;)]]></description>
<dc:subject>art tables glass layering 3d cross-sections water ocean sea mapping cartography layers this-is-colossal design furniture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:16f8d5d8bbde/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:art"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tables"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:glass"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:layering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:3d"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cross-sections"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:water"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ocean"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sea"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mapping"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cartography"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:layers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:this-is-colossal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:furniture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.coolhunting.com/design/makers-brothers-marmoreal-board-pepper-mill.php">
    <title>Handmade Kitchen Goods from Makers &amp; Brothers - Cool Hunting</title>
    <dc:date>2014-05-23T17:23:24+00:00</dc:date>
    <link>http://www.coolhunting.com/design/makers-brothers-marmoreal-board-pepper-mill.php</link>
    <dc:creator>jm</dc:creator><description><![CDATA[lovely kitchen-gear design from local-boys-made-good Makers & Brothers]]></description>
<dc:subject>makers-and-brothers design crafts kitchen nyc terrazo chopping-boards</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:90b39decbcfa/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:makers-and-brothers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:crafts"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kitchen"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nyc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:terrazo"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:chopping-boards"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.aviewfromthecyclepath.com/2014/04/where-crashes-are-shared-space-and.html">
    <title>Shared Space and other bad junction designs lead to crashes and injuries</title>
    <dc:date>2014-04-16T13:32:48+00:00</dc:date>
    <link>http://www.aviewfromthecyclepath.com/2014/04/where-crashes-are-shared-space-and.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Just because something is "Dutch", that doesn't mean it's good. The Netherlands has many excellent examples, but you have to be very selective about what serves as a model.  Cyclists fare best where their interactions with motor vehicles are limited and controlled. They fare best where infrastructure ensures that minor mistakes do not result in injuries.

Anywhere that we rely upon everyone behaving perfectly but where we do not protect the most vulnerable, there will be injuries. Good design takes human nature into account and removes the causes of danger from those who are most vulnerable.</blockquote>

via Tony Finch]]></description>
<dc:subject>cycling design junctions shared-space dutch holland roads safety crashes</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:810ac264dd38/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cycling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:junctions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:shared-space"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dutch"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:holland"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:roads"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:safety"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:crashes"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arnon.me/2014/03/services-microservices-nanoservices/">
    <title>Microservices and nanoservices</title>
    <dc:date>2014-03-25T10:26:55+00:00</dc:date>
    <link>http://arnon.me/2014/03/services-microservices-nanoservices/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A great reaction to Martin Fowler's "microservices" coinage, from Arnon Rotem-Gal-Oz:

'I guess it is easier to use a new name (Microservices) rather than say that this is what SOA actually meant'; 'these are the very principles of SOA before vendors pushed the [ESB] in the middle.'

Others have also chosen to define microservices slightly differently, as a service written in 10-100 LOC.   Arnon's reaction:

“Nanoservice is an antipattern where a service is too fine-grained. A nanoservice is a service whose overhead (communications, maintenance, and so on) outweighs its utility.”

Having dealt with maintaining an over-fine-grained SOA stack in Amazon, I can only agree with this definition; it's easy to make things too fine-grained and create a raft of distributed-computing bugs and deployment/management complexity where there is no need to do so.]]></description>
<dc:subject>architecture antipatterns nanoservices microservices soa services design esb</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a19528e98dbf/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:antipatterns"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nanoservices"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:microservices"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:soa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:esb"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://designtaxi.com/news/364536/A-Look-At-Airbnb-s-Irish-Pub-Inspired-Office-In-Dublin/#.Uyvx5Zh4cTN.twitter">
    <title>A Look At Airbnb’s Irish Pub-Inspired Office In Dublin - DesignTAXI.com</title>
    <dc:date>2014-03-21T10:48:36+00:00</dc:date>
    <link>http://designtaxi.com/news/364536/A-Look-At-Airbnb-s-Irish-Pub-Inspired-Office-In-Dublin/#.Uyvx5Zh4cTN.twitter</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Very nice, Airbnb!]]></description>
<dc:subject>airbnb design offices work pubs ireland dublin</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5353b0377a51/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:airbnb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:offices"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:work"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pubs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ireland"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dublin"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.johnryding.com/post/78544969349/how-to-reconnect-web-sockets-in-a-realtime-web-app">
    <title>Good explanation of exponential backoff</title>
    <dc:date>2014-03-13T16:41:51+00:00</dc:date>
    <link>http://blog.johnryding.com/post/78544969349/how-to-reconnect-web-sockets-in-a-realtime-web-app</link>
    <dc:creator>jm</dc:creator><description><![CDATA[I've often had to explain this key feature verbosely, and it's hard to do without handwaving. Great to have a solid, well-explained URL to point to]]></description>
<dc:subject>exponential-backoff backoff retries reliability web-services http networking internet coding design</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f3677453107a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:exponential-backoff"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:backoff"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:retries"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reliability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:web-services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://jpkoning.blogspot.ie/2012/10/data-visualization-breaking-down.html">
    <title>Data visualization: breaking down The Economist's classic chart style</title>
    <dc:date>2014-02-23T22:14:44+00:00</dc:date>
    <link>http://jpkoning.blogspot.ie/2012/10/data-visualization-breaking-down.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[nice piece of classic graph design]]></description>
<dc:subject>economist graphs dataviz charts design ui</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:3e3d6a192060/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:economist"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dataviz"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:charts"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ui"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://tla2012.loria.fr/contributed/newcombe-slides.pdf">
    <title>'Experience of software engineers using TLA+, PlusCal and TLC' [slides] [pdf]</title>
    <dc:date>2013-10-10T14:07:50+00:00</dc:date>
    <link>http://tla2012.loria.fr/contributed/newcombe-slides.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA[by Chris Newcombe, an AWS principal engineer.  Several Amazonians sharing their results in simulating tricky distributed-systems problems using formal methods]]></description>
<dc:subject>tla+ pluscal tlc formal-methods simulation proving aws amazon architecture design</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:897973b787e0/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tla+"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pluscal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tlc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:formal-methods"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:simulation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:proving"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amazon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://sockpuppet.org/blog/2013/07/22/applied-practical-cryptography/">
    <title>Applied Cryptography, Cryptography Engineering, and how they need to be updated</title>
    <dc:date>2013-07-27T17:33:29+00:00</dc:date>
    <link>http://sockpuppet.org/blog/2013/07/22/applied-practical-cryptography/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Whoa, I had no idea my knowledge of crypto was so out of date!  For example:

<blockquote>ECC is going to replace RSA within the next 10 years. New systems probably shouldn’t use RSA at all. </blockquote>

This blogpost is full of similar useful guidelines and rules of thumb.   Here's hoping I don't need to work on a low-level cryptosystem any time soon, as the risk of screwing it up is always high, but if I do this is a good reference for how it needs to be done nowadays.]]></description>
<dc:subject>thomas-ptacek crypto cryptography coding design security aes cbc ctr ecb hmac side-channels rsa ecc</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:40c846206102/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:thomas-ptacek"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:crypto"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cryptography"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cbc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ctr"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ecb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hmac"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:side-channels"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rsa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ecc"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://engineering.pinterest.com/post/55272557617/building-a-follower-model-from-scratch">
    <title>Pinterest's follower graph store, built on Redis</title>
    <dc:date>2013-07-17T10:24:54+00:00</dc:date>
    <link>http://engineering.pinterest.com/post/55272557617/building-a-follower-model-from-scratch</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is a good, high-availability Redis configuration; sharded by userid across 8192 shards, with a Redis master/slave pair of instances for each set of N shards. I like their use of two redundancy systems -- hot slave and backup snapshots:

<blockquote>We run our cluster in a Redis master-slave configuration, and the slaves act as hot backups. Upon a master failure, we failover the slave as the new master and either bring up a new slave or reuse the old master as the new slave. We rely on ZooKeeper to make this as quick as possible.

Each master Redis instance (and slave instance) is configured to write to AOF on Amazon EBS. This ensures that if the Redis instances terminate unexpectedly then the loss of data is limited to 1 second of updates. The slave Redis instances also perform BGsave hourly which is then loaded to a more permanent store (Amazon S3). This copy is also used by Map Reduce jobs for analytics.

As a production system, we need many failure modes to guard ourselves. As mentioned, if the master host is down, we will manually failover to slave. If a single master Redis instance reboots, monit restart restores from AOF, implying a 1 second window of data loss on the shards on that instance. If the slave host goes down, we bring up a replacement. If a single slave Redis instance goes down, we rely on monit to restart using the AOF data. Because we may encounter AOF or BGsave file corruption, we BGSave and copy hourly backups to S3. Note that large file sizes can cause BGsave induced delays but in our cluster this is mitigated by smaller Redis data due to the sharding scheme.</blockquote>
]]></description>
<dc:subject>graph redis architecture ha high-availability design redundancy sharding</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:78c92555c7b0/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graph"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:redis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ha"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:high-availability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:redundancy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sharding"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.oracle.com/technetwork/products/berkeleydb/learnmore/bdb-je-architecture-whitepaper-366830.pdf">
    <title>Berkeley DB Java Edition Architecture [PDF]</title>
    <dc:date>2013-05-16T15:43:40+00:00</dc:date>
    <link>http://www.oracle.com/technetwork/products/berkeleydb/learnmore/bdb-je-architecture-whitepaper-366830.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA[background white paper on the BDB-JE innards and design, from 2006. Still pretty accurate and good info]]></description>
<dc:subject>bdb-je java berkeley-db bdb design databases pdf white-papers trees</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:92793f758cdc/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bdb-je"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:berkeley-db"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bdb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pdf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:white-papers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:trees"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://sweng.the-davies.net/Home/rustys-api-design-manifesto">
    <title>Rusty's API Design Manifesto</title>
    <dc:date>2013-05-15T09:06:28+00:00</dc:date>
    <link>http://sweng.the-davies.net/Home/rustys-api-design-manifesto</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This classic came up in discussions yesterday...
<blockquote>
In the Linux Kernel community Rusty Russell came up with a API rating scheme to help us determine if our API is sensible, or not.  It's a rating from -10 to 10, where 10 is perfect is -10 is hell. Unfortunately there are too many examples at the wrong end of the scale.
</blockquote>

]]></description>
<dc:subject>rusty-russell quality coding kernel linux apis design code-reviews code</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:af2d8a163fb9/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rusty-russell"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:quality"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kernel"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:code-reviews"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:code"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://nerds.airbnb.com/introducing-chronos">
    <title>Introducing Chronos: A Replacement for Cron</title>
    <dc:date>2013-03-29T11:31:40+00:00</dc:date>
    <link>http://nerds.airbnb.com/introducing-chronos</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A distributed, fault-tolerant "cron" is something which comes up frequently -- it makes for a great fault-tolerance building block.  This one sounds like it's too closely tied into Mesos, though (IMO).

<blockquote>Chronos is our replacement for cron. It is a distributed and fault-tolerant scheduler which runs on top of Mesos. It's a framework and supports custom mesos executors as well as the default command executor. Thus by default, Chronos executes SH (on most systems BASH) scripts. Chronos can be used to interact with systems such as Hadoop (incl. EMR), even if the mesos slaves on which execution happens do not have Hadoop installed. Included wrapper scripts allow transfering files and executing them on a remote machine in the background and using asynchroneous callbacks to notify Chronos of job completion or failures.</blockquote>

]]></description>
<dc:subject>cron scheduling mesos stacks design airbnb chronos fault-tolerance distcomp distributed-computing scripts jobs</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ed1cc2afd7bc/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cron"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scheduling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mesos"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:stacks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:airbnb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:chronos"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fault-tolerance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distcomp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distributed-computing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scripts"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jobs"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.slideshare.net/Wolfr/design-for-developersonlineversionlong">
    <title>Design for developers [presentation]</title>
    <dc:date>2013-03-27T13:18:35+00:00</dc:date>
    <link>http://www.slideshare.net/Wolfr/design-for-developersonlineversionlong</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A nice set of practical web/UI/typography design guidelines, naming specific sources (via Rob C)]]></description>
<dc:subject>ui interface typography css design web slides</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6b75d4b1efcd/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ui"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:interface"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:typography"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:css"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:slides"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>