2018 in Review

Published 3 weeks ago

2018 was a pretty big year for BLP. (Sorry, just had a Rob Van Dam moment there.)


I moved into my new apartment last December, but this was the first full here and this is the first time I've lived with anyone. It took quite a long time to adjust to not being alone all the time. Luckily, I've found a decent balance and things are going well at home.


On the career front, I finally was able to stop teaching English. For those who've never lived in Japan, the stigma of being an English teacher is quite strong. It's even worse when you're not running your own business. If you're at least satisfied being an English teacher, it can be good, but I had been wanting to get out of being a teacher for quite some time.

Unfortunately, I took a job that I wasn't crazy about just to stop being an English teacher. I can't say 100% is if was a mistake though. It was doing development at a large Japanese corporation and the environment was depressing. It wasn't what I had in mind when I dreamed of getting into programming. I stayed for six months, and while the first couple were okay, the last couple—where I had no freedom with what or how I worked—were pretty brutal.

I was all set to quit—going back to teaching English if need be—but I was lucky enough to find a spot at a company that fit me and my skillset much better. I've been there for three months so far and things are going well.


I learned two major frameworks this year: Laravel and Vue. You could also throw Tailwind in there as well, but that's a pretty easy one to pick up. This site is built on all three of them. Tangentially, I also learned Nuxt and Gridsome, which are built on top of Vue and a little bit of Adonis, which is a Laravel clone in Node. I never programmed anything in PHP before this year. It was an interesting experience joining the community. The overlap between Laravel, Vue and Tailwind users led me to each one. I can't even remember if it was Laravel that led me to Vue or Vue which led me to Laravel, but the fantastic members in each community made learning both technologies much easier than learning Rails or Ember ever was for me in the past.

I also realized that JavaScript is actually my favorite language now. I used to swear up and down that Ruby was my favorite and that JS was awful, but after learning all the ways that JS has improved in recent years, I really came around on it. Once Adonis and its community come along a bit more (here's hoping), I could see moving away from Laravel to Adonis—to be able to do everything in JavaScript. I love Laravel. I just don't love PHP. PHP isn't as bad as all the Rubyists and Rails people would lead you to believe, but without Laravel, I wouldn't touch PHP.

Favorite Things from this Year

  • Red Dead Redemption 2 (not quite finished yet though)
  • Reliving 90's pro-wrestling through YouTube, podcasts and the WWE archives
  • Buying a proper Christmas tree for the first time in Japan
  • Biking to work
  • Coming home for lunch on workdays

Adding Laravel Nova

Published 1 month ago

Added Laravel Nova to the site—mostly for editing blog posts. Pretty hot stuff. I built my own crappy editing interface earlier, but this is definitely better. I suppose I need to add a published column to the database so I can control that kind of stuff—like a real CMS. Statamic it ain't, but it ain't bad either.

Most of my setup issues were things of my own doing. I couldn't get it working on the production server because I missed a message during deployment that said the git pull didn't succeed. Wasted a lot of time trying to figure out why my config didn't work—it would have, I just wasn't successfully deploying the changed config file.

I had been wanting to use Nova since its release, and the Black Friday sale was a good kick in the pants to buy a license. Glad I picked it up, and I'm looking forward to trying out some plug-ins and seeing what else I can do with this now.

Update: 2018-11-25

Had a little time to think about Nova since last night when I got it mostly set up. I'm really excited about the possibilities. I don't have anything other than this blog to take advantage of Nova right now, but I could see building lots of little personal things that are just for myself that I could use Nova to manage.

When I started working on this site, I was a little worried about how to break up the Blade and Vue templates. I love Vue and feel most comfortable building views with Vue, but the pages on this site don’t need AJAX calls and SPA-like functionality. I could totally go down that route, but it seemed simple and more user-friendly to just generate the views server-side with Blade templates and pass along props to any Vue components I might have as per Caleb Porzio’s suggestion.

I still wanted to try my hand at making AJAXy forms so I could use Sweet Alert to do fancy message pop-ups. Probably unnecessary, but I wanted to try it. I then worried about people needing JavaScript just to do a simple form. So, in the event that JavaScript isn’t available, I want the form to just be a regular form, but if JavaScript is available (as it usually will be), it used the Vue component. Luckily, whatever you stick in a Vue component’s slot will render when no JavaScript can be used. My solution was to wrap my forms with a renderless Vue component that spits up needed functions and data through a scoped slot. Here’s that component.

Definitely not perfect, but it’s an interesting use case for scoped slots and renderless components.

Dump that JavaScript

Published 2 months ago

By dumping, I’m referring to dumper.js. It’s a dd() clone from Laravel-land. The output is colorful and the data comes out looking like PHP var_dumps.

It’s a great alternative to console.log and PHP devs will feel like they never left Psysh.

Last month, I gave a talk at Vue.js Night in Nagoya about async components in Vue.js. I really got into the idea of code-splitting everything and loading as much as possible asynchronously. If you're interested in the slides (which were built as an async Vue app) check them out here.

Introducing laravel-mix-rails

Published 3 months ago

Continuing on from my previous post, I whipped up a little npm package to facilitate using Laravel Mix with Rails

You can see the package here.

Use it by running npx laravel-mix-rails.

Mixing Laravel and Rails

Published 3 months ago

This information is pretty much just a regurgitation of a Japanese post I found here. I didn't find anything on the topic of using Laravel Mix with Rails in English, so I thought I'd write this technique up myself. I love Laravel and its asset system Mix. The combo of Rails and Webpacker kind of sucks. I used to think Rails was amazing, but then I found Laravel and I saw how forward thinking the Laravel community is in regards to the frontend. They embrace the frontend and its trends, while the Rails community seems to fight against it whenever it can. So let's find a way to use the frontend and all its wonderful abilities while still having access to Ruby on the backend.

Inside laravel_mix_helper.rb, drop this inside:

module LaravelMixHelper
  class LaravelMixError < StandardError; end
  MANIFEST_FILE = 'public/mix-manifest.json'
  def mix(path)
    unless File.exists?(MANIFEST_FILE)
      raise LaravelMixError.new('The Mix manifest does not exist. Run `npm run dev`.')
    manifest = JSON.parse(File.read(MANIFEST_FILE))

Inside webpack.mix.js, include this:

let mix = require('laravel-mix');
  .js('resources/js/app.js', 'public/js')
  .postCss('resources/css/app.css', 'public/css')
// Cache-busting
if (mix.inProduction()) {

Then, in your app/views/application.html.erb, reference your new asset files like this.

<link rel="stylesheet" href="<%= mix('/css/app.css') %>">
<script src="<%= mix('/js/app.js') %>"></script>

Now you can run npm run watch to get your dev server going, and run npm run production when you're ready to push. Relatively easy to set up, and way better than Webpacker.

Hunger and Guides

Published 3 months ago

There's a lot to be said for turning the tasks in your productivity system into guides. Instead of checking OmniFocus to see if you need to wash the dishes or do the laundry, you're better served by taking notice of the dishes or clothes that are piling up and then acting on that guide. After considering the role of guides vs. tasks, I've found there's been a great weight lifted off of me in regards to task management. I used to have silly tasks popping up in my OmniFocus Dashboard every day. Things like "wash dishes", "do laundry", "brush teeth" and "take out the trash". I then made them Considered Tasks for a while, with names like "Consider taking out the trash". This was just as bad. Some things are best left to guides. Go through your task manager and see what mundane tasks can be left to guides. In OmniFocus, you can assign these tasks to a "Retired Habits" context that's placed "On Hold". Try living without these tasks for a few weeks and see if you're functioning just as well without seeing them pop up flagged and screaming for your attention. If the guides are working, delete the tasks. If they aren't maybe you need to work on building the habit a little more.

The best way I've found to improve the effectiveness of guides is to make the guides more visibile. An inbox or laundry basket with a lid is harder to see than an inbox or laundry basket without a lid. Lidded baskets allow us to shove things in, close the lid and not see what's really there. It's why we buy cabinets for books, videos and games that we don't want to see---because we know that deep down we don't really need all these things. Also, make the baskets smaller. A small laundry basket with no lid on it is going to fill up much faster than a bigger one, and with no lid to keep keep the mountain of dirty clothes at bay, the erupting volcano of laundry will get your attention in a much less nagging way than a due or flagged task in a task manager.

So, let's bring this idea of guides to health. Our ancestors didn't worry about eating breakfast, lunch and dinner. They found food when they could and they ate when they wanted. It's our manmade workday that's forced us into meals. Meals are like tasks. They are scheduled events that we think we have to get done. We should be thinking about hunger and meals the same way we think about guides and tasks. If we relied on our hunger to be our guide, we'd eat when we are hungry---instead of when we think we should eat. This idea is central to the Primal Blueprint. So while you're trying to use your guides for handling household chores, try listening to your body about when it's time to eat.