Unboxing the Sony MDR-7506 Headphones

I recorded an unboxing video for the Sony MDR-7506 headphones. I had used these headphones before when I worked at my college radio station. Interestingly, although less expensive, they’re an upgrade from the Beats Pro. The sound is more accurate, and they’re so light, you can use them for hours.

‘On The Verge’

Jeremy Keith:

If the message coming down from above is that performance concerns and business concerns are fundamentally at odds, then I just don’t know how the developers are ever going to create a culture of performance (which is a real shame, because they sound like a great bunch). It’s a particularly bizarre false dichotomy to be foisting when you consider that all the evidence points to performance as being a key differentiator when it comes to making moolah.

Jeremy continues:

For such a young, supposedly-innovative industry, I’m often amazed at what people choose to treat as immovable, unchangeable, carved-in-stone issues. Bloated, invasive ad tracking isn’t a law of nature. It’s a choice. We can choose to change.

The Verge’s Nilay Patel is so full of crap. The argument presented makes it sound like this is the only way, and if you’re against it, then you’re against people feeding themselves and their families.

It’s a choice. I don’t want The Verge to go away, or to fail. I just fundamentally disagree with the way they’re choosing to do business.

Ad-supported businesses need to reevaluate, and ask themselves how far they’re willing to go to please their advertisers. Unfortunately, these companies seem to be under the false notion that they’re the ones in charge, and content makers are only reinforcing that notion.

There is a fork in the road: change or lose your audience. People are tired of it.

Working Remotely Can Be the Dream

Mark Nichols:

During the hardest times, working remotely can feel like a punishment. For what, though? Your defection from the norm? Your overconfidence, maybe — your inability to do something that seems so easy? You suddenly have all these questions and insecurities keeping you up at night. What’s happening?

Mark’s experience has not been mine in the slightest. I’ve had the fortune of working with companies that really understand remote working. Without that, you’re left with the insecurities Mark has experienced: feeling out of the loop and alone.

I used to think that a company had to be completely remote for it to work. However, I currently work somewhere where only some of us are remote, and it’s been great. But it’s because online communication and collaboration has been engrained in the company culture even when you’re working at the office.

My recommendation is this: if you’re feeling out of the loop and alone, you should address those concerns with your supervisor. If things don’t get better, you might need to find a company who wants to put the effort into remote working.

Matt Gemmell on Working from Home

Matt Gemmell writes an excellent piece on working from home. You can tell he’s been doing it for a while, and I love his emphasis on creating a routine. If you don’t have a routine when you work from home, you’ll never get anything done.

Personally, the thing I would’ve dedicated a little more time to is the work-life balance. Working from home, and in Matt’s case, owning your own business should afford you the luxury of working less, not slaving away more. But, to each their own.

‘20 for 20’

Paul Armstrong:

My wife and I celebrated 20 years of marriage on July 1st 2015. I’m far from having any of what makes marriage work, let alone work for two decades, but here are some simple things I’ve learned and working on.

Chris Bowler on Blogging Tools

Chris Bowler:

I realize many folks consider talking about your blogging toolset is akin to talking about your relationship issues in public. Loudly. But I appreciate hearing how the writers I respect get content on their site and hopefully someone can benefit from hearing about my own.

I’m so glad Chris decided to ignore the haters of process. I love hearing how people work towards being more efficient, and Chris has a setup, that although simple, is powerful in making it easier for him to write. I plan to implement parts of it in my own process. Thanks, Chris.

The Sad State of iOS Development

Brent Simmons:

Yes, there are strategies for making a living, and nobody’s entitled to anything. But it’s also true that the economics of a thing may be generally favorable or generally unfavorable — and the iOS App Store is, to understate the case, generally unfavorable. Indies don’t have a fighting chance.

The platform is awesome. We love writing iOS apps. It’s fun and massively rewarding in every way except monetarily. As a craft — as a budding art form, perhaps — it’s juicy.

How sad is it that people who’ve put immense amounts of work into making their iOS apps great, can’t make a living from it? Could it be true that developers actually discard ideas before even trying them due to this?

One thing is for sure, indie devs making apps “for love” can’t go on forever.

Hosting a Jekyll Site on Heroku

Avoid pulling your hair out like I did.

This post is part of a series on hosting Jekyll with Heroku.

I love using Jekyll. I use it for this blog, my personal site, and it’s the first thing I suggest when people want something with content that needs to be updated. However, deploying gets complicated when you’re using a variety of plugins and you don’t want to host with GitHub Pages.

I had setup Deploy to do this automatically when new commits were pushed to the master branch. But I wanted something better; something that didn’t feel like so much of a hack. I was having to compile the whole site locally, and sometimes I’d forget to use the right config file, so things would break and I’d have to scramble to fix quickly.

One day, the lightbulb when off, and I started to wonder if I could use Heroku to host my Jekyll sites. After doing some calculations, I felt like I could improve the deploy workflow, and save a little money.

So how the heck do you do it?

Well, it was a bigger pain in the butt to figure out than I thought, but once you understand the pieces, it actually is pretty simple. Unfortunately, most of the articles that walk you through this process were published a while ago, so they were using out-of-date gems, and deprecated commands.1 But by combining the process of this article and this article, you find yourself with a great solution. Hopefully you’ll find this useful.

Ignore the Site Folder

First things first, you’ll want to ignore your _site folder. You’ll be building the site on the server now, so there’s no need for these files to be cluttering up your repo. In your .gitignore add the following line:

# .gitignore

Exclude Vendor in _config.yml

You’ll also want to exclude vendor in your _config.yml file. This folder is generated by Heroku I believe. I didn’t actually test why this needs to be done, but I did it.

# _config.yml
excluded: ['vendor']

Add Gemfile

If you don’t have one already, you’ll want to create a Gemfile.2 I recommend you visit RubyGems.org for the latest versions of these gems.

# Gemfile
source "https://rubygems.org"
gem 'foreman'
gem 'jekyll'
gem 'rack-contrib'
gem 'rake'
gem 'thin'

Once you’ve got these gems in your Gemfile, run bundle install and make sure your Gemfile.lock is checked into your repo. The build process will fail without the Gemfile.lock.

Add Procfile

Next, add a Procfile. We’ll be using thin to serve up our site. You do that with the following lines:

# Procfile
web: bundle exec thin start -p $PORT -V
console: echo console
rake: echo rake

Add Rakefile

We need to tell Heroku to build our site, and we’ll do that by attaching a command to the rake assets:precompile task that Heroku runs. Create a Rakefile, and add these lines:

# Rakefile
namespace :assets do
  task :precompile do
    puts `bundle exec jekyll build`

Add config.ru

Now, we need to tell Rack how to serve up our files. We want it to do this statically so we’ll add a config.ru file and add the following lines:

# config.ru
require 'rack/contrib/try_static'

use Rack::TryStatic,
  :root => "_site",
  :urls => %w[/],
  :try => ['.html', 'index.html', '/index.html']

run lambda { |env|
  return [404, {'Content-Type' => 'text/html'}, ['Not Found']]

Lastly, make sure you’re using relative URLs for assets. I ran into a javascript error for calling jQuery over an insecure connection. Which meant changing the line.3

<!-- You'll change a line like this -->
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>

<!-- To this -->
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>

That’s it! Now just push your repo to Heroku, and it’ll build the site and serve it. If you’d like to dig through the repo for this site, it’s on GitHub.

  1. Not to mention, it was difficult to find a pattern of how people do this. You’ll usually do research on something like this and all the blog posts will point you to the same steps. Not here. There were like four different ways, some that seemed simple, and others that were quite complex and required knowledge of routes in Sinatra. Craziness. 

  2. You can do this by going into your terminal, cd into the directory of your Jekyll site, and type bundle init. You’ll need to have the bundler gem to do this, so if you don’t have that, type gem install bundler into your terminal to install. 

  3. I add this information because my JS wasn’t working and I spent like 20 minutes just scratching my head as to why. Opened the console, and found the issue immediately. Should’ve done that in the first place.