diff --git a/contents/articles/fuck-webpack/index.md b/contents/articles/fuck-webpack/index.md
index 9fb9dc7..a793388 100644
--- a/contents/articles/fuck-webpack/index.md
+++ b/contents/articles/fuck-webpack/index.md
@@ -13,7 +13,7 @@ Lets take a jaded closer look...
 
 [Webpack](https://webpack.js.org/) became the defacto go-to solution to get the latest [es6](http://es6-features.org) javascript language functionality into a developers pipeline via transpilers like [Babeljs](https://babeljs.io/) and support the overly bloated non-standard web component soultion as the [ReactJS](https://reactjs.org/) framework (batteries NOT included). Sure [Webpack](https://webpack.js.org/) does more or can do more, but in the end developers just want to develop with [es6](http://es6-features.org) features, **however** this was only supose to be a temporay *polyfill*, until browsers started supporting the next version of Javascript -- ES6.
 
-ES6 is HERE
+**ES6 browser support is [HERE](http://kangax.github.io/compat-table/es6/)**
 
 99% of the browsers support it, even Microsoft Edge, Safari, Chrome, Opera, Firefox...
 
diff --git a/contents/articles/pragmatic-api-design/index.md b/contents/articles/pragmatic-api-design/index.md
index cb91ed1..73c3cdc 100644
--- a/contents/articles/pragmatic-api-design/index.md
+++ b/contents/articles/pragmatic-api-design/index.md
@@ -7,7 +7,7 @@ template: article.jade
 
 The API design *should* be organized around **REST** principles, however to maintain both user and developer sanity it should *also* be pragmatic, thus we call it **RESTful design**, as it may not conform to *all* the REST architecture design tenets.
 
-## Launch like a start-up, scale like an enterprise
+### Launch like a start-up, scale like an enterprise
 
 API's should have predictable, resource-oriented URLs and to use HTTP-based response codes to indicate API errors. Leveraging built-in HTTP features, like HTTP authentication and HTTP verbs, allows off-the-shelf HTTP clients to work out-of-the-box.
 
@@ -90,7 +90,7 @@ Core RESOURCES should map HTTP VERBS to CRUD operations
 |Collection <code>/resources/</code>|<b>List</b> the URIs and perhaps other details of the collection's members.|<b>Replace</b> the entire collection with another collection|<b>Create</b> a new entry in the collection. The new entry's URI is assigned automatically and is usually returned by the operation|<b>Delete</b> the entire collection|
 |Element <code>/resources/item</code>|<b>Retrieve</b> a representation of the addressed member of the collection, expressed in an appropriate Internet media type|<b>Replace</b> the addressed member of the collection, or if it doesn't exist, <b>create</b> it|Not generally used. Treat the addressed member as a collection in its own right and <b>create</b> a new entry in it|<b>Delete</b> the addressed member of the collection|
 
-> NOTE: PATCH could update a resource, however this was once a browser support issue
+> NOTE: PATCH could update a resource, save for browser limitations
 
 
 ### URL Structure
@@ -180,7 +180,7 @@ Not all errors map cleanly onto HTTP response codes, but you should not throw ou
 
 standard js error/exception object
 
-`{name:, message:}`
+	{name: "", message: ""}
 
 
 #### Error Suppression