Elliot Jay Stocks on Apple vs Google

Last Saturday, Elliot Jay Stocks wrote a Medium piece on his disenfranchisement of the Apple ecosystem.

The result is two-fold: firstly, from a software perspective, Google-authored apps have all but replaced Apple’s defaults on my iPhone; secondly, for the first time ever, I find myself potentially choosing a Google phone over an Apple phone — a choice that represents not just a one-off hardware purchasing decision, but a first tentative step outside of Apple’s ecosystem and, as a result, a break in unashamed Apple fanboy-ism.

Apple’s high ground has always been their superior hardware. Here are a couple of anecdotal metrics:

  1. Year over year, more and more software developers are switching to Macs to do their work. Not just more developers, but a higher percentage of developers.
  2. The iPhone 6S, nearly a year old, is still faster than the brand new Galaxy Note 7.

Apple isn’t worried about having a monopoly on the software that runs on your devices. Its goal is to be the best at hardware and the best at operating system software. On the side, it writes enough of its own apps that the average user could use only its apps, but that’s not its goal. Apple makes its money selling hardware. Once that point of sale is over, it tries to up-sell SaaS packages like premium iCloud Storage and Apple Music, but those are side gigs compared to the hardware.

If Elliot wants to run a bunch of Google apps on his iPhone’s home screen, Apple has achieved its primary goal.

Elliot goes on:

It’s not that Apple no longer creates great products, but there’s just not that spark there anymore, is there?

If you read this article carefully, Elliot isn’t comparing Apple to Google, he’s comparing present Apple with past Apple. Where’s Google’s great spark? Where’s its magnificent product launches equal to those of Apple’s past? They don’t exist. The landscape has matured. The kinds of ground-breaking work that Apple did in the 2000s aren’t sustainable. Steve Jobs knew this back in 2007:

Every once in a while a revolutionary product comes along that changes everything. It’s very fortunate if you can work on just one of these in your career. … Apple’s been very fortunate in that it’s introduced a few of these.

We’re in a new era now, and Elliot is rejecting Apple without an equal alternative. He’s allowing the past to flavor his perception of the present, instead of looking at the present objectively.1

His conclusion:

All this is to say: if Google can be this good on a competitor’s operating system, how much better can it be in its own environment?

A rarely remembered fact is that iOS is more profitable for Google than Android is by a large margin. If anything, Google spends more talent and energy on iOS than on Android. I’m afraid that Elliot is setting himself up for disappointment, but he should give Android a try so he can see for himself. He’ll find that the experience within Google’s apps is pretty much the same, while the overall operating system runs slower and some of the frames are janky.

  1. As an aside, this is one of the reasons it’s so hard to play against a computer chess engine. The engine analyzes each stage of the game as if there were no history. The engine has no desire to continue surging forward with a previous idea that, as good as it was at the time, is now detrimental. It’s incredibly difficult for humans to have this detachment. ↩︎

Harvest 2.0

Earlier this week, Harvest announced version 2.0 of their Mac App. It’s now much more visually similar to the company’s iPhone app:

One of the biggest changes you’ll notice on a daily basis is in the forms you use to track and edit time entries. New Entry Previous versions of Harvest for Mac used two different forms for entering and editing time. In Harvest for Mac 2.0, you’ll notice we’ve used the same design for both forms. The end result makes the app much more intuitive.

Harvest is my favorite time tracking software.1 With the robust key shortcuts, I can create a brand new time entry without ever touching a mouse. I can resume a previous one with a single click to the top right corner of the screen. This is much faster than pulling a phone out of my pocket and messing with it. For professionals, Mac Apps are where it’s at, and it’s great to see Harvest give its desktop app the time and attention it deserves.

Also delicious is the fact that if you’re on a Windows, you get a Chrome extension, not an app. Harvest knows its customer base.

  1. Even though I’m an employee and not a contractor primarily, I keep track of every second I spend at my desk. It’s important to know how many hours per day are spent at a computer, and what was accomplished in those hours. ↩︎

Separation of Concerns in ReactJS

Michael Chan, in an excellent gist:

A component like this would be rejected in code review for having both a presentation and data concern.

If you’re new to ReactJs I highly recommend going through this gist. Bottom line: if you’re making an API call to a server within a component, you’re best off not having that component output JSX.

Are Native Fonts Here to Stay on the Web?

Earlier this week, WordPress announced 4.6 “Pepper”. One of the interesting things in this release was the transition to native fonts for the dashboard:

The WordPress dashboard now takes advantage of the fonts you already have, making it load faster and letting you feel more at home on whatever device you use.

WordPress is 25% of the Internet, so a lot of site owners are going to get used to this. Last month Github switched as well.

It’s too early to tell if it’s a fad or the beginning of a longterm trend.

Strava's Redesigned iOS App

From Strava’s blog:

There is a reason that text is often black on white. We want to eliminate the amount of squinting needed to use Strava. […]

Now the whole Strava ecosystem has a light theme, from iOS to our website and Android app.

I’m delighted to see Strava’s iPhone app have the same dark-on-light scheme as its desktop website. This makes the platforms feel much more consistent with each other, and dark-on-light feels superior. There’s this assumption sometimes that “dark is sophisticated” and that that’s somehow a good enough reason to go with light-on-dark. Good to see Strava escaping this mindset.

If you read the comments on that blog post, people are begging Strava to reinstate the dark color scheme as an optional theme. This is unsurprising — one thing that will never change about humans is their pathological dislike of change, be it good or bad change — but I’m hopeful Strava stands its ground and doesn’t give users this option.

Github's Longest Streak Statistic

Erik Romijn wrote a really fascinating piece April 1 of this year1 about Github’s longest streak data point that appeared on members’ profiles:

Stepping away from our work regularly is not only important to uphold high quality work, but also to maintain our well-being. For example, I personally do not generally work in the weekends. That’s completely healthy. […]

When I see someone with a 416 day streak, it means they haven’t taken a break for a single day in over a year. […]

Any mechanism in our community that motivates people to avoid taking breaks and avoid stepping back, can be harmful to the well-being of contributors and is thereby harmful to open source as a whole.

Completely oblivious to Erik’s article, I wrote this 4 days later, in which I gloried in my weekend work:

I am making a more conscious effort to make weekend contributions, which is usually the period of the week that causes streaks to end.

This was unsustainable, of course, and just days later I broke my streak. In the back of my mind I felt like I’d let myself down, even though it was the right thing to do. In hindsight, it’s a good thing that Github removed this feature. Just because you can show a data point doesn’t mean you should. That’s a counterintuitive concept to a lot of developers and site owners but it’s really true. Showing the longest streak was causing me and others to engage in a behavior that wasn’t a good idea. Individually we all already knew this, but Github was creating a groupthink nudge in the opposite direction so strongly that it was altering our reality.

That said, I disagree with Erik’s overall claim in his headline that “Contribution graph can be harmful to contributors.” The longest streak can be harmful, but it’s not clear to me how the overall graph is harmful. It’s never created anxiety for me. Monday through Friday you should be getting a lot of work done as a developer! Maybe your pull requests tend to be large and therefore infrequent, but still, overall there should be a pattern of progress on your graph.

I especially like the new feature that Github introduced in May that allows you to set your contributions to show both your public and private activity:

Visitors to your profile will see your public and anonymized private contributions.

Here’s what my profile looks like. I don’t contribute to public repositories that much, but thanks to this feature you can see that I do have a lot of private stuff going on.

  1. In case you’re wondering why I’m thinking about this 4 months later, that’s because I’m only just now noticing that the longest streak feature has been removed. I guess that proves that while its removal is interesting, it’s also not that big of a deal. ↩︎

3D Touch and Javascript Assumptions

Try this:

Install 1Blocker on your iPhone.1 Then go to Forbes.com and view this annoying overlay:

Looks like you might have an Adblock on. Please whitelist Forbes.com OR log in to enjoy an Ad-Light experience.

The “Continue to Site” link still exists though. Using 3D Touch, go ahead and Peek it. You’ll see the same page as you’re already on, reloaded. Release the Peek. Then Peek again. This time, you’ll see the actual site appear. Pop it, and you’re on the page you’re after.

The interesting thing about Pop is that it’s the equivalent of right clicking and selecting “Open Link in New Tab” in Chrome on a Mac. In other words, any Javascript on-click events are overridden.

A lot of people haven’t figured this out yet, obviously. 3D Touch complicates bullet proofing on the mobile web.

  1. I recently started using 1Blocker again, thanks to an old episode of The Talk Show that I finally got around to. ↩︎

The Genius of Github's Squash and Merge Feature

On April 1, 2016, Github released a feature that allows you to squash your commits before merging a pull request. Prior to this feature, you had to do this manually by locally squashing and force pushing to the pull request’s branch. The ability to handle the squashing directly on Github’s interface saves time, but it does more than just save time: it preserves the individual commits of that pull request.

If you were to locally squash and force push, you’d be disconnecting those squashed commits from their formerly associated branch. They still exist locally, technically, until you run git prune, but unless you happen to know their SHAs then you’ll never be able to find them.1 2

In contrast, when you squash using Github’s squash and merge feature, you aren’t changing the pull request’s commits. They remain as they were. Usually this doesn’t have much bearing — you squash and merge, delete the branch, and move on. But what if in that pull request you started to solve a problem one way, committed, and then proceeded to solve the problem another way? Those two commits representing those two different solutions will continue to be accessible in perpetuity if you squash and merge directly on Github. This would not be the case if you locally squashed (or performed a fixup) as the final step before force pushing and merging the pull request.

What Github has really done, besides make our lives more convenient, is make all of our code changes accessible in a way that it previously was not.

  1. Well, technically you can, but it’s like looking for a needle in a haystack if your working head has any amount of subsequent history on it. I’ve done Nick’s approach but only in a pinch and as a last resort. In anticipation of disconnecting a commit that I might later need, I’ve written down the SHAs in a sticky note before. ↩︎

  2. It’s also worth noting here that Github never runs git prune. That means that unless you go far, far out of your way to delete a commit, it’s on Github’s servers forever. You might detach it from anything, making it for all practical purposes as secure as a private Gist, but if someone knows the hash, they can still access it (assuming they have repo read access). ↩︎

Auto-deploying to gh-pages with Codeship

As a side project, I’m working on a ReactJS app that I’m hosting on Github Pages in a private repo. My build process is in Gulp and while I could have just pushed a dist folder containing my combined and compressed assets to the gh-pages branch on Github, this seemed like a bad idea. It would be much nicer if I didn’t ever have to think about the gh-pages branch. I’d prefer just making a change to the master branch and have this trigger an auto-deploy that builds everything and pushes that build to the gh-pages branch. With my custom domain pointing to this repo, a change to master is the same as a deploy to my website. Voilà.

It turns out that this is relatively easy to do, thanks to CI and CD services out there. In 2011 three big ones hit the market: Travis, Circle, and Codeship. Here’s a great breakdown of their pros and cons from StrongLoop. I started out with the first one, Travis. There’s an excellent gist that explains how to do it. It took me an hour or two to get all the kinks worked out but it’s a solid way of doing a deploy to gh-pages. If it weren’t for the fact that I want this to be a private repo project, I would have stayed with Travis due to how incredible the experience was. The problem is that Travis is pretty limiting on their private repos plan. You have 100 builds for free and the after that you’re paying $129/mo at the base plan. For a little side project that I’d still prefer to keep as a private repository, that’s really steep. I might consider doing $10/mo but certainly not $129. That’s startup territory.

Next, I skipped Circle altogether and turned my attention to Codeship. Circle only lets you have one concurrent container (or build) on the free tier, which isn’t as generous as Codeship’s 5. It’s nice having the legroom for creating a couple of more impulse side projects should I ever wish to, without having to break out the wallet.

Getting set up with Codeship was actually simpler than with Travis and that aforementioned gist. Here’s the general documentation for how to do it. I followed the first two steps exactly, but third step is a bit open-ended.

1
2
3
4
5
6
7
8
9
10
11
12
13
git  clone <the ssh link to your repo> dist
cd dist
git checkout gh-pages || git checkout --orphan gh-pages
cd ..
rm -rf out/**/* || exit 0
npm install
gulp deploy
cd dist
git config user.email "<the email address you used for your machine user Github account>"
git config user.name "<the username you used for your machine user Github account>"
git add .
git commit -m "Deploy to Github Pages: ${CI_COMMIT_ID} --skip-ci"
git push origin gh-pages

This is a clever little set of commands, really. It’s creating a git repo inside of another git repo in order to handle the build correctly. I wish I could say I was the one who came up with this idea but the hat tip belongs to Domenic who gave me the idea with his Travis gist. A few things to note about this:

  1. This assumes that npm install; gulp deploy is the series of commands you use to combine and minify your assets. That’s true of my project but yours may be different (particularly the second one). Be sure to replace lines 6 and 7 with your actual ones (as well as the <placeholder> values, of course).
  2. This also assumes your output dir is dist. Hopefully it is, because that’s the convention, but if you’ve got something else, you’ll need to update lines 1, 2, and 8.
  3. There’s more hardcoding here than abstraction. These things could be lifted out of here into environmental variables but I tend to be a literalist with this stuff.
  4. I’m completely bypassing Codeship’s recommendation of handling the final git push via their own provided code (“include the commands from eployments/git-push.sh”). Not a big deal either way, I just don’t see the need for an extra HTTP request.

When you combine a smartly built front-end-only app on Github Pages with a Ruby on Rails app on Heroku, very cool things are possible on a shoestring budget. On weekends when I’m not doing freelance work, it makes for a very good way to keep my skills sharp while staying in love with what I do. This ties in with one of my favorite Steve Jobs quotes:

I have looked in the mirror every morning and asked myself: “If today were the last day of my life, would I want to do what I am about to do today?” And whenever the answer has been “No” for too many days in a row, I know I need to change something.

Fun side projects, ones you’re in complete control of, are a great way to stay fresh and excited with the tech we use Monday through Friday.

Working for Someone Besides Yourself

Jon Westenberg, writing at Medium:

I want to tell you something crazy. There’s nothing wrong with being an employee. There’s nothing wrong with building someone else’s dream. There’s nothing wrong with having a job that you fucking love. I don’t want to imagine a world where nobody is willing to work on someone’s idea just because they didn’t have it themselves.

The article is a few weeks old and I’m still mentally going back to it often. Just because you can run your own business doesn’t mean you have to or should. There are a lot of successful companies already out there and they all require talented employees to keep them innovative and relevant. It’s incredibly difficult being a one man guru shop in competition with a well staffed company. Most tech related business ideas concievable have already been hatched into profitable companies, and in many cases it makes a whole lot more sense being a part of a preexisting one than trying to create your own.