some updates

Author: i8ramin

Diff for: _data/authors.yml

@@ -1,5 +1,6 @@
 ramin_bozorgzadeh:
   name: Ramin Bozorgzadeh
   gravatar_email: [email protected]
-  github: i8ramin
+  github: https://github.com/i8ramin
+  twitter: https://twitter.com/i8ramin
   summary: Engineering Director at WeWork and loving all things performance, front-end and design related.

Diff for: _drafts/wework-com-is-going-static.markdown

@@ -49,33 +49,33 @@ each countries, index in records.marketsByCountry
         != countries[0]
 ```
 
-If you are interested to learn more about how it all works and a real-world example, [check out their tutorial here](http://roots.cx/articles/hybrid-static).
-
 
 ### The static host with the most
 
-One of the biggest challenges of this whole process has been to figure out a way to slowly migrate our site over from a dynamic app, over to a static one. One way to do this would be to stop all development for a few months and rebuild all of our pages one by one over to this new process. But as the saying goes, "aint nobody got time for that!"
+One of the biggest challenges of this whole process has been to figure out a way to slowly migrate our site over from a dynamic app, over to a static one. One way to do this would be to stop all development for a few months and rebuild all of our pages one by one over to this new infrastructure. But as the saying goes, "aint nobody got time for that!"
 
-We needed a way to move things over piecemeal. One page at a time. This meant that we couldn't move wework.com to a new static host all at once, but at the same time, we need some URL's to serve up the old content, and some URL's to serve up the new static pages. One way to do this is via a [reverse proxy](https://en.wikipedia.org/wiki/Reverse_proxy).
+We needed a way to move things over piecemeal. One page at a time. This meant that we couldn't move wework.com to a new static host all at once, but at the same time, we needed some URL's to serve up the old content, and some URL's to serve up the new static pages. One way to do this is via a [reverse proxy](https://en.wikipedia.org/wiki/Reverse_proxy).
 
-Again, there are many different ways to skin this cat. You can install and configure your own Apache or Ngnix server. You can use something like [`rack-reverse-proxy`](https://github.com/jaswope/rack-reverse-proxy) or a slew of other similar solutions in different languages. There are pros and cons to each approach. For us, being a team of web developers, we wanted to spend our time focusing on our KPI's and optimizing our pages for best performance, and not on setting up and managing servers. We had a few requirements:
+There are many different ways to skin this cat. You can install and configure your own Apache or Ngnix server. You can use something like [`rack-reverse-proxy`](https://github.com/jaswope/rack-reverse-proxy) or a slew of other similar solutions. There are pros and cons to each approach. For us, being a team of web developers, we wanted to spend our time focusing on our KPI's and optimizing our pages for performance, and not on setting up and managing servers. We had a few requirements. Specifically, we were looking for a host that could:
 
-- Host our new static site and scale with our fast growing company
-- Have an API so we can trigger builds when data changes
-- Ability to proxy requests to other URL's
+- House our new static site and scale with our fast growing company
+- Have an API so we can trigger builds when content changes
+- Ability to proxy requests to other URL's (internal and external)
 - Global CDN to improve our international traffic and SEO
 - Easy to use and configure
 - Great and responsive customer support
 
-We found one host that met all of those requirements and more, and they are called [Netlify](https://www.netlify.com/). Never heard of them? Neither had we, but as one engineer I recently spoke with who was familiar with their services put it, "Netlify is like the web developer whisperer". This team has put together an amazing service that handles SO much for you from a dev-ops persective of hosting static sites. And if there is a feature that is missing, they will bend over backwards to either implement it for you, or help you figure out a solution. I can sit here and sing their praises all day long, but its probably best if I explained a bit about how they were able to help us with our migration to a static site and make the static verions of our site *4-5x faster*.
+We found one host that met all of those requirements and more, and they are called [Netlify](https://www.netlify.com/). Never heard of them? Neither had we, but as one engineer I recently spoke with who was familiar with their services put it, "Netlify is like the developer whisperer". This team has put together an amazing service that handles SO much for you from a dev-ops persective of hosting static sites. And if there is a feature that is missing, they will bend over backwards to either implement it for you, or help you figure out a solution. I can sit here and sing their praises all day long, but its probably best if I explained a bit about how they were able to help us with our migration to a static site and make the static verions of our site *2-3x faster*.
 
-To get started, one of the first pages we decided to migrate over to static was our [`/locations`](https://www.wework.com/locations/) page. This page doesn't get a ton of traffic, but has dynamic content coming from our backend, so it seemed like a good place to start. We no longer have the old version up now, so I can't do a side by side comparison, but just looking at the graph below you can see that our server response time is **1ms** (this number is around 150-200ms on other pages), and the page is visually complete in about 2.8 seconds, which is 2-3x faster than it used to be. Of course, we've done other optimizations as well (reducing unused assets, optimizing images, etc) and there are still other things we can do to make it even more performant, but we are very pleased with the results so far.
+To get started, one of the first pages we decided to migrate over to static was our [`/locations`](https://www.wework.com/locations/) page. This page doesn't get a ton of traffic, but has dynamic content coming from our backend, so it seemed like a good place to start. We no longer have the old version up now, so I can't do a side by side comparison, but just looking at the graph below you can see the downward trend from the day we rolled it out. Our server response time is **1ms** (this number is around 150-200ms on other pages) and the page is visually complete in about 2.8 seconds, which is 2-3x faster than it used to be. Of course, we've done other optimizations as well (reducing unused assets, optimizing images, etc) and there are still other things we can do to make it even more performant, but we are very pleased with the results so far.
 
 ![Performance graph of locations page](http://res.cloudinary.com/wework/image/upload/c_scale,f_auto,w_1000/v1448740493/engineering/locations-graph.png)
 
 So how are we serving up traffic to `wework.com/locations/` from the static host and the other pages from our current host? It was as simple has modiftying some DNS settings to route all traffic through Netlify, [creating a `_redirects` file](https://www.netlify.com/docs/redirects) at the root of our very basic static site and configuring Netlify to compile and deploy our static site anytime it detects changes in our `master` branch.
 
-The reality is that we are currently maintaining two versions of our site as we move things over, but this allows us to continue doing business as usual, make updates to existing pages and not have to stop our normal workflow as we migrate things over little by little. By doing this, we hope to see an improvement in direct and SEO traffic and hopefully a small uptick in our KPI numbers, as it has been proven that conversion numbers generally improve when your pages load faster and people are able to get to the information they are looking for quicker. This also allows us to expand globally without having to worry as much about traffic load and performance. One thing to keep in mind with all of this is that it is not necessarily *easier*, but it is a lot *simpler*.
+The reality is that we are currently maintaining two versions of our site as we move things over, but this allows us to continue doing business as usual, make updates to existing pages and not have to stop our normal workflow as we migrate things over little by little. What's great about all of this is that we are sharing the same data across both sites.
+
+By doing this, we hope to see an improvement in direct and SEO traffic and hopefully a small uptick in our KPI numbers, as it has been proven that conversion numbers generally improve when your pages load faster and people are able to get to the information they are looking for quicker. This also allows us to expand globally without having to worry as much about traffic load and performance. One thing to keep in mind with all of this is that it is not necessarily *easier*, but it is a lot *simpler*. And as a side effect of serving up static pages, your site becomes a lot more secure. There is a [great article on Smashing Magazine](http://www.smashingmagazine.com/2015/11/modern-static-website-generators-next-big-thing/) written by the co-founder of Netlify (Mathias Biilmann Christensen) about why static site generators are the next big thing. If you are interested in this approach, I highly recommend reading it.
 
 In a future post we will discuss how we've started to also generate our React components as part of this static build process and how by doing so, we've seen a huge improvement in overall load times on pages that rely heavily on React.
 

Diff for: _layouts/post.html

@@ -37,7 +37,17 @@ <h1>{{ page.title }}</h1>
     </div>
     {% endif %}
     <div class="author-info">
-      <div class="author-name">Written by <strong>{{ author.name }}</strong></div>
+      <div class="author-name">
+        Written by <strong>{{ author.name }}</strong>
+        {% if author.github %}
+        <span class="author-social">
+          <a class="si fa fa-github" href="{{author.github}}" rel="nofollow" target="_blank"></a>
+          {% endif %}
+          {% if author.twitter %}
+          <a class="si fa fa-twitter" href="{{author.twitter}}" rel="nofollow" target="_blank"></a>
+          {% endif %}
+        </span>
+      </div>
       {% if author.summary %}
       <div class="author-summary">
         {{author.summary}}
@@ -73,12 +83,11 @@ <h1>{{ page.title }}</h1>
 {% endif %}
 
 {% if site.show_related_posts and site.related_posts.size > 0 %}
-  <h3 class="related-post-title">Related Posts {{site.related_posts.size}}</h3>
+  <h4 class="related-post-title mt2">Related Posts {{site.related_posts.size}}</h4>
   {% for post in site.related_posts %}
-    <div class="post ml2">
+    <div class="post">
       <a href="{{ post.url | prepend: site.baseurl }}" class="post-link">
-        <h4 class="post-title">{{ post.title }}</h4>
-        <p class="post-summary">{{ post.summary }}</p>
+        <h5 class="post-title">{{ post.title }}</h5>
       </a>
     </div>
   {% endfor %}

Diff for: css/styles.scss

@@ -38,6 +38,15 @@
     }
   }
 
+  .author-social {
+    padding-left: 10px;
+
+    .fa {
+      padding: 0 2px;
+      color: #666;
+    }
+  }
+
   .author-summary {
     margin-top: 10px;
     font-size: 90%;