update

Author: kdkavanagh

_config.yml

@@ -13,7 +13,7 @@ name                     : "Kyle D. Kavanagh"
 description              : ""
 url                      : "https://kdkavanagh.github.io"
 baseurl                  : # the subpath of your site, e.g. "/blog"
-repository               : # GitHub username/repo-name e.g. "mmistakes/minimal-mistakes"
+repository               : "kdkavanagh/kdkavanagh.github.io"
 teaser                   : # path of fallback teaser image, e.g. "/assets/images/500x300.png"
 # breadcrumbs            : false # true, false (default)
 words_per_minute         : 200
@@ -78,7 +78,7 @@ analytics:
 # Site Author
 author:
   name             : "Kyle D. Kavanagh"
-  avatar           : "/assets/images/bio-photo.jpg"
+  avatar           : #"/assets/images/bio-photo.jpg"
   bio              : "Performance-focused software engineer and aspiring market microstructure expert"
   location         : "Chicago, IL"
   email            : "kdkavanagh@gmail.com"

_posts/2016-01-02-how-to-talk-about-performance-part-one.md

@@ -1,10 +1,8 @@
 ---
-layout: post
 title: How To Talk About Performance - Part 1
 excerpt: "The numbers and graphs used to report the performance of the fastest computer software and hardware."
 modified: 2016-01-09
 tags: [performance, metrics, latency, R]
-comments: true
 ---
 In 90% of the software engineering world, performance is often something that is "fine until it isn't", where only the most concerned developers mull over latency metrics until there is a some kind of capacity issue or noticeable performance degradation to the end user.  This post is intended to be a crash course on how to answer the call your infrastructure & ops team sounds the alarm because your application can't keep up with demand and you must confront a performance problem.
 

_posts/2016-02-07-how-to-talk-about-performance-part-two.md

@@ -1,10 +1,8 @@
 ---
-layout: post
 title: How To Talk About Performance - Part 2
 excerpt: "The right things to measure and report to paint an accurate performance picture"
 modified: 2016-02-20
 tags: [performance, response time, service time, latency]
-comments: true
 ---
 In part 1 of this post, we talked about how to report on performance - The important numbers and how to visualize them.  Now we must know what we should actually be measuring in our system.
 

_posts/2016-02-21-measuring-jitter.md

@@ -1,10 +1,8 @@
 ---
-layout: post
 title: Measuring Jitter - Work In Progress
 excerpt: "Using R to separate high latency caused by queuing from that caused randomly by the operating system, garbage collections, power savings, etc in massive datasets"
 modified: 2016-02-21
 tags: [performance, R, jitter, visualization]
-comments: true
 ---
 # Generating the Dummy Data
 First we generate a dummy set of messages.  Common queuing theory states that messages typically arrive to a system at rates following a Poisson distribution, and as such, we use a Poisson process to model the interarrival times of our fake messages.  We then perform a cumulative sum on these arrival rates to calculate the arrival time of each message in our data set.

_posts/2016-11-05-waterfall-plots-with-ggplot2.md

@@ -1,10 +1,8 @@
 ---
-layout: post
 title: Waterfall Plots with ggplot2
 excerpt: "Using R and ggplot2 to build 2D visualizations with 3D perspectives"
 modified: 2016-11-05
 tags: [R, visualization, ggplot2, plots]
-comments: true
 image:
   feature: waterfallWide.png