restore posts, basic config

Author: solvingj

_config.yml

@@ -5,9 +5,7 @@ paginate_path: "page:num"
 exclude: ["README.md"] # files to exclude
 highlighter: rouge
 markdown: kramdown
-disqus: dbyll
-google_analytics: dbyll
-title: dbyll
+title: solvingj's blog
 
 defaults:
   -
@@ -16,17 +14,14 @@ defaults:
     values:
       title: dbyll
 
-description: Stylish Jekyll Theme
+description: SolvingJ's Blog
 author:
-  name: dbyll
-  email: dbyll@ismaildemirbilek.com
-  github: dbtek
-  twitter: dbtek
-  pinterest: asd123
-  linkedin: asd123
-  bio: Your stylish, minimalist theme!
-  email_md5: 726351295ec82e145928582f595aa3aa
-
+  name: solvingj
+  email: jerrywiltse@gmail.com
+  github: solvingj
+  twitter: solvingj
+  bio: Technologist Developer, Problem Solver
+  
 rss_path: feed.xml
 categories_path: categories.html
 tags_path: tags.html

_posts/2013-11-14-sample-2.md

@@ -0,0 +1,19 @@
+---
+layout: post
+title: Why Develop Software?
+published: true
+---
+A few years ago, I started the challenging transition from a career as an experienced IT professional to a more junior software developer.  Many people have asked why, so I thought I'd start a blog post with some thoughts about Software Development as a career and hobby in general. 
+
+### Fulfilling a Need
+
+I believe it's important for the human mind to "create". Even those who don't think they're "creative" can't resist this urge.  This is clearly evidenced by the proliferation of paper airplanes and footballs in schools, gardens in backyards, and entire worlds in Minecraft. On a personal level, when I started working with computers, I quickly became addicted to helping people by solving their technical problems. When designing and building complex network and server environments, there was a fair amount of creation and problem solving.  However, after a project where I was forced wade a little deeper into the waters of software development, I could see that the opportunities to create and solve problems were vast in comparison to IT. Also, there were problems in IT for which there were no good solutions, and which I felt I could solve some day with software. 
+
+### My Advice for Would-Be Developers
+If you enjoy working with technology, then I encourage you to ignore the apparent overwhelming complexity that exists on the face of software development, and try your hand. For those who know they want to become developers, but aren't confident in their abilities, do not be discouraged. Despite being a natural technologist, I was NOT a natural developer.  Perhaps it was because I started later in life, but I continue to have to wrestle with new concepts for months before actually being able to read or write an example (even simple ones). I think I would have been discouraged, if not so stubborn... so be stubborn. 
+
+### Realistic Expectations
+It's also important to realize that even if you get into the field as a professional, you may decide that you do not enjoy or accept the lifestyle of a software developer.  However, this is true for almost any professional field.  Unfortunately, the fields of higher learning such as science, engineering, medicine, law, and others do not lend themselves to young people trying to choose a career path or major in college.  However, among these fields, software development is a bit of an exception because people can try it out while they are still young (although it does typically requires significant guidance and mentoring). 
+
+### Summary
+The transition to a career in software development has been a rewarding one for me, and I do recommend it. "Right now" seems like the most exciting and inspiring time one could possibly hope to be creating software. However, perhaps what excites me most is the knowledge that today's possibilities are almost certain to be dwarfed by those of tomorrow. 

_posts/2013-11-14-sample.md

@@ -0,0 +1,41 @@
+---
+layout: post
+title: DevOpsDays Detroit 2016 - Takeaways
+published: true
+---
+This year I attended DevOpsDays detroit.  Like last year, the organization of the event and the general feel of the experience were both outstanding. Two days seems like a lot at first, but it flies by.  Special thanks to the RightBrainNetworks team. 
+
+### The Personal Element
+
+It was interesting to see a lot of returning teams from local enterprises, and hearing how far they've come in the past year. Different companies have tried different paths, and hearing the realities of their experience can absolutely be valuable to those on the verge of similar paths. Some were downright inspiring.   The speakers were also fascinating. Talked to some after the fact and they were all keen on elaborating about their stories further. 
+
+### Ignite Talks
+
+I think I enjoyed the ignite talks more than most people. Maybe I'm in the minority, but I would like to see more of these.  I'm a person who enjoys as much diverse exposure as I can get at gatherings.  It's a real challenge for the speakers to distill big ideas and a big message to such a small window. From my perspective, I think thats what makes them so attractive (somewhat like a TedTalk).  
+
+### Breakout Rooms
+
+The participation in the breakout rooms was also great. There were some new topics for ideas I had not heard before, and some of the conversations really made me think about new things. The process where people walk up to stage and gave their idea works, but I think a suggestion + voting app could be better in some ways.  I'm sure there are apps out there for this. 
+
+### Braindump
+
+For those wondering what actually was discussed, here's a braindump of things I personally heard about and found interesting. These are from organizers, break-out rooms, vendors and 1-on-1's. 
+
+* Embedding security information in the DevOps pipeline is a challenge. There are clever solutions for treating "security as code" some involve PGP. 
+
+* People are making Kubernetes work on numerous scales and platforms.  Still evolving, and the new federation feature might be a necessity at large scale. 
+
+* There are still many IOT devices and use-cases with very limited memory, where having a network stack with TCP is still not possible. 
+
+* GE trying to encourage use of IOT platform, all built on Cloud Foundry.
+
+* Positive review of ProGet for .NET shop doing CI/CD for SAAS. Some people trying chocolatey for enterprise use. 
+
+* Immutable infrastructure is still an awkward solution for IAAS use cases. It might never be a good fit. Active Directory join is part of the issue, but even without this, problems still exist. 
+
+* There are software companies trying to bring DevOps to IBM systems, Mainframe specifically, not sure about AIX or ISeries. 
+
+* When votes were taken for breakout rooms, there were almost no hands for "Monitoring" discussions.
+
+* A lot of people were interested in the discussions about challenges when working from home. 
+

_posts/2013-11-15-configuration.md

@@ -0,0 +1,19 @@
+---
+layout: post
+title: "IT Professionals != Developers, and so what"
+date: 2016-11-07
+---
+### Non-Developers and DevOps
+The DevOps communities have a LOT of non-developers, and this post is about them.  I'm talking mostly about enterprise IT engineers and architects.  These people often have a specialty such as networking, security, servers, enterprise applications, virtualization, storage, automation, monitoring, etc.  If you are one such specialist, you've probably used some DevOps tools by now, and maybe have been to a conference or two. You also might have found yourself feeling a little out-of-place at times, not really understanding or relating to a large number of the topics and tools being discussed. If so, you are not alone. 
+
+### The Gap
+Many of the speakers we hear from at DevOps conferences come from software companies (or occasionally large enterprise software teams) which are focused almost entirely on developer problems. They often begin their talks with "ops-related" battlefield stories which include being on call when outages occur. This is great because virtually everyone can connect with this experience to some degree. However, the connection often begins to dissolve when the speakers start talking about software-specific problems and tools which are foreign to our non-developers attendees. The problem continues in conferences which have "breakout rooms", where it's clear that some of the attendeeds are quietly wondering why they can't relate to the conversation at all, even though they use the tool the group is talking about. This isn't really groundbreaking news, but what is surprising to me is how little people talk about it. 
+
+### The Reason
+There's certainly a psychological component where people don't like to speak up about what they don't know.  However, beyond this I think the situation surrounding tools is another big part of this phenomena.  There seems to be a bit of a use case see-saw among tools that are used by both developers and enterprise engineers.  Most of the DevOps tools are rooted in development first.  Some really smart developers tackle a very specific problem really well with a bold new technology or concept (eg. "Immutable Infrastucture" or "Containers" or a new cloud orchestration methodology). All the weight on the see-saw begins on the side of the developer use case, and eventually it gains a following in one or more developer communities.  Inevitably, any obvious benefits and overlap with enterprise use cases draws enterprise attention, and the potential for enterprise revenue draws the vendor's attention. Enterprise engineers start trying to jam the new product or concept into their environment, and the vendors do their best to expand their features and accomodate (while also clarifying and hardening their scope boundries). During this period, more weight goes over to solving enterprise problems and a product or process can become pretty flexible and robust this way.  Over time, then the see-saw starts to balance out and it starts to meet the "Definition" of a DevOps tool, truly applicable to a fair number of uses cases in both realms. 
+
+### Sharing Tools: Abstract Problems vs Specific Problems
+I think one thing that might be helpful for companies developing DevOps tools is to think more deeply about the problems they're "willing" to solve as early as possible.  I think this is one case where it's very important to divide your potential target market into two separate groups:  1) Enterprise Infrastructure Teams, 2) Development Teams (whether at a startup, major software company, or enterprise).  While a large part of the unifying message of the DevOps movement is that these two groups share problems, it's critical to look at the situation more closely.  Indeed these two groups often share a large number of common "abstract problems" (eg: configuration management), but it turns out that they have very different "specific problems" (eg: enterprise solaris configuration management with RBAC that also integrates into service-now). The size of the differences between specific problems is another rarely-discussed challenge in DevOps.  
+
+### The Confusion
+In a way, the tools of developers and enterprises have essentially been dumped into one big DevOps "toolbox". This has benefits, but makes the use cases of the individual tools less discernable for the non-developer.  The maturing of these tools takes time, and the sheer number can be very hard to navigate for the average "enterprise shopper".  Most teams are forging ahead and eventually figuring out which tools they need and making them work with varying success. However, I think this situation is a near-silent, but potentially defining characteristic of the DevOps movement.