Blog

In my last post, I mentioned the transition to Gridsome and it has been relatively pain free. I owe a lot of this to the existing community and the great list of starter resources. If a concept isn't explained or clear in the docs, chances are you can gain some insight from the various starters.

One particular concept I had a problem with right out of the gate was how to use markdown files from multiple directories. I started with the post type to handle /year/month/day/title routes but I wanted to move to an equivalent of the generic page type from Hexo. In doing research to the search terms I could've used months ago, I stumbled on multiple issues that point out how to do it.

In the file gridsome.config.js, I use the following snippet in the plugins section:

{
  use: '@gridsome/source-filesystem',
  options: {
    path: 'blog/articles/**/*.md',
    typeName: 'Article',
    refs: {
      authors: {
        typeName: 'Author',
        create: true
      },
    }
  }
},
{
  use: '@gridsome/source-filesystem',
  options: {
    path: 'blog/posts/**/*.md',
    typeName: 'Post',
    refs: {
      authors: {
        typeName: 'Author',
        create: true
      },
      categories: {
        typeName: 'Category',
        create: true
      },
      tags: {
        typeName: 'Tag',
        create: true
      },
    }
  }
},

Since Gridsome has a concept of pages already, I chose the word article to represent them instead. As an example, the portfolio page is an article type while this page represents a post type. While hindsight makes this seem intuitive now, I somehow had the impression that you were only allowed one plugin type for safety reasons.

To point out something else, the portfolio page highlights a technique I didn't think was possible at the time. The parent portfolio page is an article type but all the subsequent child pages are markdown files in a separate portfolio directory as a portfolio type. In the plugins section of gridsome.config.js:

{
  use: '@gridsome/source-filesystem',
  options: {
    path: 'blog/portfolio/**/*.md',
    typeName: 'Portfolio',
    refs: {
      authors: {
        typeName: 'Author',
        create: true
      },
    }
  }
},

Coming from Hexo, I opt for placing content in markdown files and having unique layouts defined in the various pages and templates files. As much as Gridsome is a generic website framework, I find that it can be extremely flexible to whatever workflow you wish to create. There are some parts of Hexo I miss like scaffolding new page types or steering me into blog concepts but the transition to Gridsome has been rather smooth. While Gridsome may not be for everyone, I can definitely see how JAMstack has gained traction recently. Barring very few gotchas, working on this site is fun again even in the I-can-see-every-blemish state it's currently in.

It's been over a year since my last post and while unfinished drafts don't count, I thought my blog was due for a change. The move from Octopress to Hexo was relatively uneventful but I found keeping up a little difficult. It wasn't completely on Hexo, I had tweaked things to a point that merging in changes over time became cumbersome and slow. In a previous post, I roughly mentioned the transition and a lot has happened to the web in over 3 years.

Static site generators like Hugo and Gatsby have picked up steam and the feature set of Gatsby, particularly the GraphQL component stood out. I wanted to stick to Vue for as many of my personal projects as possible, so I searched for any static site generator using Vue I could find. Fortunately Gridsome has come along as a nice clone of Gatsby using Vue rather than React and even though it's at v0.7.12 at the time of this post, I've run into very few hurdles.

I don't have the best understanding of JAMstack after working with a sample size of one, but learning GraphQL by only dealing with queries has made this one of the best ways to get my feet wet. I'm by no means an expert but this light interaction compels me to use it more often, as it's mostly been a pleasure to work with. Frameworks like Gridsome and I suspect Gatsby let you focus on almost entirely the frontend. Even though the A in JAMstack stands for APIs, as a backend developer I haven't had to write a single REST, GraphQL or what I'd typically associate with an API like I would with Laravel, Phoenix Framework, or Express.

One thing I miss about Hexo is that it had scaffolding to generate new files. Gridsome is a framework for generic sites, not just blogs, so scaffolding doesn't seem to be included. Coming from Hexo I wanted to keep as much of the existing markdown as possible and I think some of the approaches I've taken may be useful to others. A small example I had a problem understanding is that you can use a @gridsome/source-filesystem plugin multiple times, one for each directory or type. It makes sense in hindsight but none of the starters used the technique nor did the docs seem to suggest it was possible. I'm tempted to create a starter based on my usage patterns but worst case, I plan on writing a post outlining some of these approaches in the near future.

One last thing is a small humblebrag. While the theme for this site draws a few cues from the older version, I wanted to flex my design abilities by focusing on techniques I've learned reading Refactoring UI. By the time this post is published it likely won't be perfect but I think it's a decent first pass that should only get better over time.

I wanted to mark what feels like an oasis in the desert of a long journey. During my last job search over 2 years ago, I tired of what had become a disjointed resume update routine. Accomplish a task, go to the Word-document-as-one-true-source, update, print to PDF, go to LinkedIn, update, go to careers.stackoverflow.com, update, rinse & repeat.

I yearned for one interchangeable format that allowed me to generate HTML, Word and PDF at the very least. JSON Resume combined with resume-linkedin seemed like a great fit. Unfortunately, due to recent LinkedIn API changes resume-linkedin was all but useless. My first contribution was born out of the realization that if you could get the LinkedIn data through the API console, the process still worked, albeit extremely cumbersome.

As I worked on migrating this site to my personal fork of a theme in Hexo, I thought a custom JSON Resume theme would also be a good fit. These changes to my resume can be found here or here.

I said in my previous post that a lot can happen in 2 years.

In that time span I've:

• Moved to using a MacBook and OSX.

  • OSX being very BSD-like makes it an prime target for web development. It isn't the second class citizen Windows is in the Ruby or Node.js communities.

• Transitioned away from .NET and don't really miss it. I do randomly play around with .NET core when possible but I haven't actually built anything with it.

  • This was honestly very huge at the time but I still feel I made the right decision. Though Windows 10 is the platform Windows 8 should have been and likely would've kept me on board.
• Transitioned to PHP and web technologies full bore. I'm no fan of the PHP language but in the era of Visual Studio 2012, a dynamic language that only required refreshing my browser was much faster than waiting on the compile cycle.

• Drank the vagrant koolaid via PuPHPet.

  • Recreating production hardware isn't too difficult with my ancient DevOps experience.
  • Waiting on the painful commit/push/wait for deployment/refresh cycle to see a change was a huge productivity destroyer.
  • Even developing locally when production PHP versions aren't consistent can be a nightmare. Something like rvm in Ruby comes close but it isn't perfect.
• Immediately took to PHPStorm as my IDE of choice. JetBrains have done an amazing job and if you've used ReSharper you've only had a taste. I'm no fan of Java but I'll make a concession for tools this good.
• Wrote a very crude front-end only CMS. When working in only HTML, CSS, and Javascript you really see the separation of client and server very clearly.

• I jumped in the deep end with tools like gulp, bower and yeoman.

  • This has fueled my desire to be a lot more fluent in Node.js.
  • Frontend development becomes insanely fun because a lot of the tedium melts away if you do it right.
  • This gulp template was extended from this blog post and it's subsequent repository to streamline working on the custom CMS.
  • This yeoman gulp generator looks a little more promising as it seems to serve a similar purpose but feels like less work.
• I have a Microsoft Lumia 640 and the Windows 10 Mobile OS is one of the best mobile experiences I've used to date. I know I'm biased but it has shaped up really well.
• My personal laptop is running Windows 10 as well so I haven't abandoned the Windows ecosystem by a long shot, I've just become more of a consumer rather than a developer.

That's really only scratching the surface. It would've been helpful to have blog posts as I moved along but as with most things, life got in the way.

My main goal for the early part of 2016 is to revamp this site and make it the playground I was looking for in 2013. Octopress is really nice but if I upgrade to v3 it's not much more work to migrating away to something like Hexo, Metalsmith, or DocPad.

A lot can happen in a little over 2 years...

In my last post, I had proposed an attempt to tackle the FizzBuzz problem. PowerShell was done, PHP was barely started but I never pointed to it in a subsequent post or finished what I wanted. The project url has completed and checked solutions for PHP and Node.js. I had mentioned b. F#, Objective-C, CoffeeScript, C/C++, Go, Dart, and Haskell are the planned languages I've mostly touched in passing or know about., as well as C#, Pascal, and Ruby but I may never get to them.

Shortly after that last post, I switched jobs from .NET to web development focusing on PHP with HTML, CSS, and Javascript. That one action shifted much of my focus from most of the languages in that list. With ES6 coming and recently finishing a CodeSchool course in CoffeeScript, the Javascript landscape is looking pretty awesome. Elixir and the Phoenix Framework have recently stood out as upcoming contenders for my mindshare as well.

My last post taught me that while I may know of a language, it doesn't mean I'll have a genuine desire to pursue it. It can also easily become difficult to want to pursue development outside of your day job. Staying current, however, is always worth pursuing. Tooling and efficiency around web development seems to have come a very long way.

To keep this post brief, I plan on making more updates as I feel a lot has changed for me in the past 2 years that I'd still love to share.