Fix blog post links after move

Author: w01fe

_posts/2014-03-31-schema-0-2-0-back-with-clojurescript-data-coercion.markdown

@@ -3,11 +3,11 @@ layout: post
 title: 'Schema 0.2.0: back with Clojure(Script) data coercion'
 date: 2014-03-31 14:56:52.000000000 -07:00
 ---
-*tl;dr: [Schema](https://github.com/prismatic/schema) 0.2.0 is here, adding support for data coercion and 5x faster validation.  We've also added Schema support in [Plumbing and Graph 0.2.0](https://github.com/prismatic/plumbing). Join the discussion on Hacker News and let us know what you think.*
+*tl;dr: [Schema](https://github.com/plumatic/schema) 0.2.0 is here, adding support for data coercion and 5x faster validation.  We've also added Schema support in [Plumbing and Graph 0.2.0](https://github.com/plumatic/plumbing). Join the discussion on Hacker News and let us know what you think.*
 
-Back in September, Prismatic [released](http://blog.getprismatic.com/blog/2013/9/4/schema-for-clojurescript-data-shape-declaration-and-validation) the first version of [Schema](https://github.com/prismatic/schema), and we've been blown away by the interest and contributions from the community since.  Schemas are declarative descriptions of data shapes that make it easy to document and validate Clojure(Script) data. We use Schemas all over our codebase, and others seem to share our finding that Schemas can make Clojure development clearer, faster, and more fun.
+Back in September, we [released](http://plumatic.github.io/schema-for-clojurescript-data-shape-declaration-and-validation/) the first version of [Schema](https://github.com/plumatic/schema), and we've been blown away by the interest and contributions from the community since.  Schemas are declarative descriptions of data shapes that make it easy to document and validate Clojure(Script) data. We use Schemas all over our codebase, and others seem to share our finding that Schemas can make Clojure development clearer, faster, and more fun.
 
-In addition to a variety of small bugfixes, improvements, and a huge performance boost (see the [Changelog](https://github.com/Prismatic/schema/blob/master/CHANGELOG.md)), version 0.2.0 brings something new to the party: **transformations**, which provide a way to perform structured manipulation of data using rules cued by Schemas.
+In addition to a variety of small bugfixes, improvements, and a huge performance boost (see the [Changelog](https://github.com/plumatic/schema/blob/master/CHANGELOG.md)), version 0.2.0 brings something new to the party: **transformations**, which provide a way to perform structured manipulation of data using rules cued by Schemas.
 
 ## Why Transformations?
 
@@ -25,17 +25,17 @@ Spending time writing the boilerplate conversions became exceedingly inefficient
 
 And the fun doesn't stop at coercion.  Schema is now based on a general `walker` protocol that allows for structured Schema-driven data transformations, of which validation and input coercion are just two simple examples.  This abstraction is inspired by the excellent data transformation facilities of `clojure.walk`; the difference is that whereas `clojure.walk` operates on free-form data, `schema/walker` allows you to define transformations that depend on *both* the Schema and data at a particular place in a data structure via a parallel walk.  To `clojure.walk` a String is just a String; but `schema/walker` knows whether this string is *supposed to be* a String, Keyword, Number, or FooBar, and can act accordingly.
 
-It's easy to write your own [custom transformations](https://github.com/Prismatic/schema/wiki/Writing-Custom-Transformations). We're excited to see what other applications for transformation the community dreams up!
+It's easy to write your own [custom transformations](https://github.com/plumatic/schema/wiki/Writing-Custom-Transformations). We're excited to see what other applications for transformation the community dreams up!
 
 ## Show Me The Code
 
 The rest of this post describes this new functionality in more detail, with examples.  We start with a brief recap of Schema definition and validation, using an example that we'll build on throughout the post:
 
 <script src="https://gist.github.com/w01fe/8246933.js"></script>
 
-`CommentRequest` is a schema for data a client might send to the [Prismatic](http://preview.getprismatic.com/news/home) API to post a comment and share it to the provided external networks.  The `parent-comment-id` field is optional, and is only present if the comment is a reply.
+`CommentRequest` is a schema for data a client might send to the API to post a comment and share it to the provided external networks.  The `parent-comment-id` field is optional, and is only present if the comment is a reply.
 
-`+good-request+` matches the schema and passes validation, but `+bad-request+` has several issues that are clearly explained in the validation exception.  (For more Schema examples, check out the [readme](https://github.com/prismatic/schema).)  
+`+good-request+` matches the schema and passes validation, but `+bad-request+` has several issues that are clearly explained in the validation exception.  (For more Schema examples, check out the [readme](https://github.com/plumatic/schema).)  
 
 ### Coercion
 
@@ -99,11 +99,11 @@ The first change enables applications like transformation, which require the abi
 
 ## Conclusion 
 
-We've released the latest version of [Schema](https://github.com/prismatic/schema), which is both 5x faster and adds a generic facility for parallel schema-data walks.  Schema ships with an application of this facility for *coercion*, which Prismatic is using in production to automatically massage input data into a suitable form, and transparently clientize output data.  
+We've released the latest version of [Schema](https://github.com/plumatic/schema), which is both 5x faster and adds a generic facility for parallel schema-data walks.  Schema ships with an application of this facility for *coercion*, which we are using in production to automatically massage input data into a suitable form, and transparently clientize output data.  
 
 This application is another step towards meeting Schema's design goal: enabling a single declarative definition of your data's shape that drives everything you want to do with your data, without writing a single line of traversal code.  Validation and coercion are just the first two applications, with others like test data generation just around the corner.  
 
-In other open-source news, we're also excited to announce the `0.2.0` release of [Plumbing](https://github.com/prismatic/plumbing), which makes Graph, `fnk`, and friends Schema-friendly. Be on the lookout for more releases on the horizon, including our API definition library with validation and pluggable coercion included.  
+In other open-source news, we're also excited to announce the `0.2.0` release of [Plumbing](https://github.com/plumatic/plumbing), which makes Graph, `fnk`, and friends Schema-friendly. Be on the lookout for more releases on the horizon, including our API definition library with validation and pluggable coercion included.  
 
 Join the discussion on Hacker News and let us know what you think.
 

_posts/2014-04-08-bringing-functional-to-the-frontend-clojure-clojurescript-for-the-web.markdown

@@ -3,11 +3,11 @@ layout: post
 title: 'Bringing functional to the frontend: Clojure + ClojureScript for the web'
 date: 2014-04-08 12:13:03.000000000 -07:00
 ---
-Earlier last year, we gave a [talk](http://www.infoq.com/presentations/Why-Prismatic-Goes-Faster-With-Clojure) about how Prismatic uses [Clojure](http://clojure.org) to craft fine grained software abstractions for maximal productivity and reuse. On the back-end, Clojure is a great fit for our functional programming approach to [software engineering](http://blog.getprismatic.com/blog/2012/4/5/software-engineering-at-prismatic.html). On the front-end however, none of the popular languages (Objective-C, JavaScript, Java) or frameworks are really functional, making it harder to design and test good engineering abstractions. Part of our new year's resolution was to bring the same level of engineering and abstraction to our front-end applications as we do our back-end services. We've started by migrating ouar web application away from [Node.js](http://nodejs.org) and JavaScript to Clojure and [ClojureScript](https://github.com/clojure/clojurescript). The resulting code is smaller, more expressive, and has allowed us to introduce many optimizations. 
+Earlier last year, we gave a [talk](http://www.infoq.com/presentations/Why-Prismatic-Goes-Faster-With-Clojure) about how we use [Clojure](http://clojure.org) to craft fine grained software abstractions for maximal productivity and reuse. On the back-end, Clojure is a great fit for our functional programming approach to software engineering. On the front-end however, none of the popular languages (Objective-C, JavaScript, Java) or frameworks are really functional, making it harder to design and test good engineering abstractions. Part of our new year's resolution was to bring the same level of engineering and abstraction to our front-end applications as we do our back-end services. We've started by migrating ouar web application away from [Node.js](http://nodejs.org) and JavaScript to Clojure and [ClojureScript](https://github.com/clojure/clojurescript). The resulting code is smaller, more expressive, and has allowed us to introduce many optimizations. 
 
 ## Migrating from Node to Clojure
 
-The first version of the Prismatic web application used a pretty standard web stack: [ExpressJS](http://expressjs.com/) as a server running on [Node.js](http://nodejs.org/), [Jade](http://jade-lang.com/) as a server-side templating language and [Jadevu](https://github.com/LearnBoost/jadevu) for client-side templating (and [Stylus](http://learnboost.github.com/stylus/) for CSS, which will be the subject of a future post). 
+The first version of our web application used a pretty standard web stack: [ExpressJS](http://expressjs.com/) as a server running on [Node.js](http://nodejs.org/), [Jade](http://jade-lang.com/) as a server-side templating language and [Jadevu](https://github.com/LearnBoost/jadevu) for client-side templating (and [Stylus](http://learnboost.github.com/stylus/) for CSS, which will be the subject of a future post). 
 
 Here's an example of what functional programming and abstractions can buy you in a web server. Much of the code in a web server is concerned with templating data to HTML. In Node.js land, there are many templating options, but most are derived from [Haml](http://haml.info/) and define their own language which compiles to JavaScript (or directly to HTML). Here's what templating looked like in our old template engine Jade:
 
@@ -41,14 +41,14 @@ When [ClojureScript](https://github.com/clojure/clojurescript) was announced abo
 
 Our migration to Clojure for our web server afforded us the chance to re-examine ClojureScript. We're happy to say that ClojureScript has matured substantially since we first looked at it and we are now running it in our production web app. The first thing we moved to ClojureScript was our client-side templating to do things like render articles and search results on the client from back-end JSON data.
 
-### Introducing [dommy](http://github.com/prismatic/dommy): Fast Clojurescript Templating
+### Introducing [dommy](http://github.com/plumatic/dommy): Fast Clojurescript Templating
 
 We made a similar transition in client-side templating as on the server: we replaced
-[jadevu](https://github.com/LearnBoost/jadevu) with a ClojureScript-native approach very similar to Hiccup. We tried some popular ClojureScript templating libraries (e.g., [crate](https://github.com/ibdknox/crate)), but couldn't find one with acceptable performance, so we wrote one -- and we're happy to announce that this library, [dommy](http://github.com/prismatic/dommy), is open-source. The entire templating library is [one small file](https://github.com/Prismatic/dommy/blob/master/src/dommy/template.cljs).
+[jadevu](https://github.com/LearnBoost/jadevu) with a ClojureScript-native approach very similar to Hiccup. We tried some popular ClojureScript templating libraries (e.g., [crate](https://github.com/ibdknox/crate)), but couldn't find one with acceptable performance, so we wrote one -- and we're happy to announce that this library, [dommy](http://github.com/plumatic/dommy), is open-source. The entire templating library is [one small file](https://github.com/plumatic/dommy/blob/master/src/dommy/template.cljs).
 
 ### But what about performance?
 
-One potential concern with using ClojureScript is that you're taking a large performance hit relative to something more standard like jQuery. To address this concern, we compared performance of three client-side templating approaches: jQuery, [crate](https://github.com/ibdknox/crate), and our library [dommy](https://github.com/prismatic/dommy); see our [pert test](https://github.com/Prismatic/dommy/blob/master/test/dommy/template_perf_test.cljs) for the code. The task was to generate 10,000 nested structure elements and add them to a DOM parent. Here's the ClojureScript representation of the DOM element in dommy (the crate representation is almost identical):
+One potential concern with using ClojureScript is that you're taking a large performance hit relative to something more standard like jQuery. To address this concern, we compared performance of three client-side templating approaches: jQuery, [crate](https://github.com/ibdknox/crate), and our library [dommy](https://github.com/plumatic/dommy); see our [pert test](https://github.com/plumatic/dommy/blob/master/test/dommy/template_perf_test.cljs) for the code. The task was to generate 10,000 nested structure elements and add them to a DOM parent. Here's the ClojureScript representation of the DOM element in dommy (the crate representation is almost identical):
 
 <script src="https://gist.github.com/4527612.js"></script>