Today’s puzzle would make a great job interview question. It’s a question that I would’ve failed before today. Are you ready? Here it goes.
Consider the git branch
feature-1, which is based on
master. Is there a situation where merging the latest
feature-1 before then merging
master would result in a different software state than if you simply merged
feature-1 directly into
master? If so, describe how this could occur.
The answer is yes, surprisingly. There are probably more elegant ways to arrive at a proof, but here’s how this is possible. I’ll mostly just let you read through the logs, with an explanation at the two critical sections.
Here’s where things go wonky. The developer working on
feature-1 hasn’t fetched the latest origin, and attempts to apply the latest changes that are in his latest local
At this point, if we were to merge
master, we would not have the
feature-2.md file. However, what if we had not merged the
master branch into the
feature-1 branch before merging the
feature-1 branch into
master? In that case, we would have the
feature-2.md file. I’ll prove it:
The takeaway, of course, is to never fetch changes from external branches in a way that causes git to think that those changes occurred in the current branch as new code.
I’m typing this on a Bluetooth keyboard in Editorial for iPhone. More later on my setup. The question is whether or not this will eventually become the future: whether we can get iOS apps deep enough to replace macOS. It’s too early to tell, but the past 24 hours are the first time that I’ve realized that it might be possible. What you can do with Editorial is truly remarkable.
Meanwhile, here’s the list of keyboard shortcuts that are accessible to a Bluetooth keyboard. It’s a decent list, although we’re going to need many, many more until it feels like you can fly on an iOS device like you can on a Mac. Basically we’re going to need keyboard shortcuts to mimic what you can do with a mouse on macOS.
Every episode of The Talk Show is gold but I’m especially enjoying this one. This line cracked me up.
Yesterday, Scott Adams announced a hackathon for 3 different contests surrounding his WhenHub app.
A goal-oriented startup would have a specific customer and a specific product in mind. If that doesn’t work out, the startup might have enough cash left over for a pivot, or maybe two, to try again. But in each case, there is a specific goal. And the way startups work, the odds of any particular startup hitting its goal is dismal. That’s why WhenHub was designed from the ground-up to be a systems business model instead of a goal-focused model. The idea is to get something like a portfolio effect to increase the odds of at least one of the things we’re doing becoming a profitable line of business.
Now we’re taking it up a notch by running an online hackathon for our WhenHub platform.
Being systems-oriented sounds good in theory and it works in certain situations - evidently it worked for Donald Trump - but when it comes to a product, it doesn’t work. What Adams needs is a very clear product and value proposition while simultaneously being willing to pivot by listening to what the market tells him. Instead, he has an ambiguous product that he’s attempting to crowdsource into existence. What does WhenHub do, and why do I need it? That question needs to be asked and answered succinctly and satisfactorily. The fact that it can’t be is worrisome.
This morning I cloned the WhenHub/mycomposer repo and played around with it some. Going through that process was buggy. I had to re-clone the repo several times before the system dynamically populated my instance’s manifest.json variables to my own data. And even then, because it wasn’t bulletproofed to handle repo deletion and re-cloning (despite it prompting for this), the css and js folders didn’t exist, so I had to manually copy them from a zip version of the original.
Once I was finally working - it took me over an hour, and I consider myself decently well versed in how to set up front-end environments - I got to looking at the actual JS code. It’s all in ES5, not ES6. This tells me right away that the developers aren’t living on the edge. They aren’t hustling. Scott’s not surrounding himself with a Class A team. Now admittedly, doing that is tricky when you’re not a developer yourself and don’t know what to look for. But man. I went from thinking, It’d be fun to take a stab at one of those $4,000 prizes, to thinking, I could spend the same amount of time elsewhere on a guaranteed gig, make the same amount of money, and actually get to work with a code base that I’m not cringing over.
So we’ve got:
- A product that’s a non-product, one that glories in the fact that it doesn’t know what it is yet.
- An interface that’s as bloated as Microsoft Word.1
- A code base that’s full of holes and lives in the past.
I’m going to leave this hackathon to others. It’s fundamentally flawed in ways that I can’t help it. I’m reminded of a comment that a Dilbert Blog reader left about it.
There is an idea behind it, it’s the execution and presentation that sucks, something that [Steve] Jobs would eat the developers alive for.
The idea might suck too, but we’ll never be able to tell.
Yeah, pretty much.
Not actually that bloated. But definitely too busy and way too many borders and box shadows. ↩︎
With Micro.blog coming out soon - the invite-only beta is already available - having the ability to publish to a Jekyll powered site from an iOS device is a must. Kirby Turner has put together a good resource here on how to publish to a Jekyll site directly from an iPhone. I’ve sort of wanted the ability to do this in the past, but with the imminent launching of Micro.blog, this is soon going to become a must. The idea is that you need to be able to publish something to your site - which gets syndicated to Micro.blog - as easily, or almost as easily, as opening Tweetbot and posting a tweet. Until we get to that point, this isn’t going to take off.
I’m not going to rest until I’ve got a similar setup going on over here.
I’m reading Web Performance in Action by Jeremy Wagner and one of the things he introduces is NPM’s html-minify module. The performance benefits are undeniable plus it just looks better having the source all consolidated. Here’s how to do that in Jekyll, which you’ll notice I’m now doing on this site.
It used to be the case that if you
⌘click Finder arrows in macOS, it would be the equivalent of
⌘click Safari arrows. In other words, it would perform the same action as a regular click - going forwards or backwards in history - but it would load the new view in a new tab.1 That’s no longer the case, and I think macOS 10.12.4 is the first version in which this is true. It’s possible the change was introduced earlier, but I didn’t notice until 10.12.4. For a while I thought this was a bug but today I realized that it’s intended to be a feature. Going forward, when you
⌘click the Finder arrows, you trigger an ability to rearrange / remove the customizable items in the Finder bar.
I’m not happy about this change for two reasons:
- It creates ambiguity about what
⌘clickdoes on arrow buttons. It’s no longer consistent across the apps. Finder and Safari (and all other browsers) are now disjointed.
- It’s much more common to need to open a Finder history in an enclosing window than it is to rearrange or remove the items in the Finder bar. Once you’ve got your Finder bar items set the way you want them, you’re done. That’s a once-every-six-months sort of thing. Navigating through history on the other hand is a daily task for some people.
⌘click functionality in Finder is not limited to the arrow keys. It’s available on any customizable item in the Finder bar. In asking for Apple to restore
⌘click on arrows to their former functionality - that of opening in an enclosing window - I’m aware that I’m asking for
⌘click to do different things in the Finder bar depending on what you click on. I’m ok with that.
⌘click on the title in the Finder bar already does something different anyway: it shows a dropdown menu of items, each of which is a shortcut to the previous item’s parent directory, starting with the current directory and traversing past Macintosh HD all the way to the very root (i.e. “Devices”).
If performing the same action (
⌘click) on different looking things (e.g. Finder arrow buttons and Finder search) in the same area (Finder bar) results in different outcomes, that’s not inconsistency. If performing the same action on similar looking things in different areas results in different outcomes, that is inconsistency.
For quite some time, it’s been rumored that this year’s iPhone is going to have two tiers with noticeably different industrial designs. From Mac Rumors:
Japanese site Mac Otakara believes the iPhone 8 might actually be called the “iPhone Edition,” after the higher-end Apple Watch Edition models. Such a name would reportedly reinforce its position as a high end iPhone that’s meant to be sold alongside two standard iPhone models.
And then this morning from The Verge:
2017 marks the iPhone’s 10th anniversary, and the rumors are that Apple will be releasing three new models to celebrate: two handsets with incremental improvements, and a third, radically redesigned “premium” iPhone.
Here’s what bothers me about this. If Apple does this, then it’s essentially saying that a full screen iPhone isn’t for everyone. It’s only for the people who really want it, who are willing to splurge. That might be ok, except that the Galaxy S8 has this premium screen, and the Galaxy S8 isn’t a “premium” or “luxury” SKU. It’s the de facto in the Galaxy lineup.
In other words, Apple is saying this: what our competition views as essential, we view as a splurge only for those who want to pay us even more exorbitant amounts than they’re already used to paying. That really rubs me the wrong way.
If Apple’s baseline 2017 iPhone had everything the Galaxy S8 had to offer and then its premium iPhone had even more, that’d be one thing. But that’s not what I’m hearing through the grapevine. Instead it sounds like if you want an industrial design that’s visually similar to the Android competition, you’re going to need to go all the way to the top of Apple’s pricing tier. You shouldn’t have to do that. The subliminal message that Apple is emitting in its rumored decision here is unsavory.
Earlier this week, Twitter CEO Jack Dorsey contacted me to discuss my ongoing public observations that Twitter appears to be “shadowbanning” me because of my writings about Trump. Jack introduced me via Direct Message to Del Harvey, Twitter’s Head of Trust & Safety, for the official answer.
The official answer is that no one, including me, is shadowbanned on Twitter. It has never happened.
There are about four possible explanations at this point.
- Twitter is outright lying. I find this extremely unlikely. I’m leaning towards taking Twitter’s statement at face value.
- Or employees lower down the food chain are monkeying with tweet visibility and their superiors are blissfully unaware. This sort of thing is farfetched, practically unheard of, and can cost a developer his job, so I think we can rule this one out.
- Or there’s a conveniently partisan bug in Twitter’s software.
- Or this is a clear example of confirmation bias, and Scott is living in a delusional world.
Something strange is afoot. The last option seems the most likely, but there’ve been an awful lot of incidents that are hard to explain away to pure chance.
When you sign up for Dropbox, you get 2GB of space. If you want more than that, you can earn it by referring other at 500MB per referral. That’s not much space, however, so more than likely you’re going to need to upgrade to Dropbox Premium which starts at 1T.
This is a sensible business model because it Dropbox’s only source of revenue. Selling storage is what Dropbox does.
But why does Apple think it needs to charge for its premium storage in iCloud? You cannot have more than 5GB with a free plan. From Apple Support:
When you sign up for iCloud, you automatically get 5GB of storage. You can use that storage for backups, iCloud Photo Library, iCloud Drive, Mail, and more.
It’s possible to sign up for iCloud without owning any Apple devices, but how many people do that? I’m going to say that number is small - very small. The overwhelming majority of people who own an iCloud account have spent many hundreds if not thousands of dollars on Apple products. They should have more storage than 5GB in iCloud.
When you buy an Apple Device, you should get as much iCloud storage as that device can contain. The pain and annoyance of not having this is much more tarnishing to Apple’s brand than the revenue that Apple would lose from having it. This is the exact argument I made for the Mac Pro. Not selling a Mac Pro is more of a financial problem in the long run for Apple than losing money1 by developing and selling a Mac Pro.
I was reminded of this frustration today because my iPhone cannot back up to iCloud unless I upgrade to premium. It wouldn’t hurt me to pay the $11.88/year, but it’s the principle of the thing. You spend $2,000 on a MacBook Pro and then Apple tells you to spend 99¢ per month with them so you can store 50GB of that data in the cloud. That’s disgraceful and insulting. It’s the equivalent of being at a high end steakhouse and the waiter telling you that bringing a wet towel at the end is going to be an extra 99¢, please confirm. The price of that towel should not be something you’re aware of. It should be bundled in the overall price of the meal. The overall experience. Of course hosting data in the cloud costs money. Apple’s users should still have to pay for it. But that method of payment should be bundled in the cost of the devices, which are arguably marked up enough to not need a price bump just to include this.
And then for the iCloud users who don’t have activated Apple devices, well, let them pay. Or make it mandatory that you own an activated Apple device to use iCloud storage.
That’s relatively speaking, from an opportunity cost standpoint, compared to investing that money in the iPhone. If Apple actually runs at an operational loss on the Mac Pro then something’s badly wrong. ↩︎
From the Slack blog:
Let’s say you’re stepping away from Slack for a bit — maybe you’re grabbing some lunch, taking a week off, or even just focusing on a task for a few hours. Now you can set a custom status in Slack to share what you’re up to, when you’ll be back, whom to contact in your place, or anything else that helps your team know when they can expect to hear from you.
I actually fully expect Slack to dial this back at some point. The concept is great but the implementation is too busy. When you set a status update, it appears in the following places:
- In the sidebar.
- In the text box that people see when they message you.
- In your profile header.
- At the end of your name, everywhere you write messages.
The idea of a status is a great idea in one or two places, but having it in these four places is just too much. Even if only 1/3 of the people in your Slack channel implement this feature, it has the result of getting way too busy. The overall UI looks more like a child’s toy than a serious application for professional communicating.
Every maturing company fights against bloat. Some more than others. Some companies fight tooth and nail at the expense of not looking like they’re innovating. Others fight so little that you get the feeling that the place is turning into a cluttered junk yard. Finding that balance is hard.
I just finished listening to Thermal Corner, the first ATP episode that came out after the new Mac Pro was announced. Everyone at Apple should listen to this episode, particularly the word of caution at the end. For Apple to continue to update this new Mac Pro, people are going to need to buy it. But in order for them to buy it, they’re going to need confidence that it’s a product that Apple is truly invested in and won’t abandon. And Apple must prove that by issuing new updates to it every year. That’s the only way Apple’s going to restore the confidence and trust that was broken with the 2013 model.
It makes sense that Google shut this down, but man oh man.
Vlad Savov, writing for The Verge:
I’ve been reading about Gcam, the Google X project that was first sparked by the need for a tiny camera to fit inside Google Glass, before evolving to power the world-beating camera of the Google Pixel.
Well, ok. So you think Google’s camera is better than Apple’s. It’s a free country, so we’ll move on.
What if your phone knew when, where, and what you’re pointing it at; what if it had a library of trillions of images; and what if it could intelligently account for things like weather and time of day? Would it need to have eyes to see the scene you’re trying to capture? […]
Tell your phone how tall you are and, with the help of the same orientation sensors it uses to know its place on a map, the device will be able to calculate both your subject and your point of view when you want to shoot a photo. And if it’s something as ubiquitously photographed as, say, the Roman Forum, all a future Googlephone would need to know are the cloud formations and Sun position at the particular time of the shot, and it’d have enough data to synthesize a photo.
I don’t know where to begin with this, other than to say that it’s never ever going to happen. Ever. Phones aren’t going to lose their cameras because of artificial intelligence. You can already do what Vlad is suggesting by going to Google Images and pasting in people’s faces with Adobe Photoshop. All he’s talking about is an automated way to do this. Using this exclusively in lieu of a camera is madness. How is it anything other than a huge step back from where we currently are? The whole point of a camera is to say, “I was here, and this happened.” Neither one of those things happens with Vlad’s idea. You don’t have to be anywhere, and you won’t be able to capture anything special. This Verge piece doesn’t seem to comprehend the basic reason for mobile photography.
For the longest, I’d thought that a JS file being in the
<head> tag versus immediately after the opening
<body> tag would make a difference perf-wise and render-wise. Turns out that’s not the case. Putting a script immediately before the closing
</head> tag or immediately after the opening
<body> tag makes zero difference. They’re both render blocking, unless you use the
async property. This is one of those I can’t believe I didn’t know that years ago things.
Nilay Patel, writing for The Verge:
At the end of all this, it really just seems like Apple thought people were fine with the iMac and MacBook Pro, didn’t want to throw resources at the Mac Pro, and got blindsided by the reaction of their most loyal fans who depend on high-end Macs when the Pro lingered and the MacBook Pro was a little weirder and slightly more underpowered than expected. So the course was corrected, and here we are.
I would say that certain people at Apple thought everyone was fine with the iMac and MacBook Pro, but I would not say that it was everyone. If it’d been everyone, the Mac Pro would not have remained in its outdated form for so long on the store. What we have here is a tale of two different factions within Apple. The Cook faction wanted to kill the Mac Pro altogether, while the other faction wanted to remake it. Neither side prevailed until 2017, and then the right side won. And the right side won because the Cook faction finally saw “the reaction of their most loyal fans who depend on high-end Macs.”
- It’s a relief that all the speculation drama is over.
- This is the most important piece on Daring Fireball for a long, long time. Parts of it read like a lengthy article from a professional journalist at the New York Times or The Atlantic. That’s unusual, unexpected, but delightful.
- Tim Cook’s efficiency mindset was the primary road block to this. There’s zero doubt of that in my mind. There has been an internal conflict in Apple for years now. The conflict in the abstract is this: do you focus exclusively on making the company more profitable or are you the people’s hero, the company that does the right thing simply because it’s the right thing? The paradox is that when you do the latter, that’s what makes people love you in a fanatical way, which in turn makes your company financially profitable in a way that could never happen if you focused exclusively on profit.
- When did Apple start working on this new Mac Pro? I’d bet my bottom dollar that this decision was made in 2017. Not a day earlier. It took that long for people to convince Cook and those that shared his mindset to green light it. Building this Mac Pro to accommodate 1-3% of the Mac market is an unprofitable venture compared to spending that money on the iPhone. If I were at Apple trying to persuade Cook, my persuasion would have been focused on brand perception: that in the long run, Apple would lose more money not making the new Mac Pro than making it.
- Regarding the question of why Apple didn’t update the Mac Pro sooner, that one’s easy. It’s the same reason Apple didn’t start building the new Mac Pro sooner. It’s because a portion of Apple really did plan on abandoning the Mac Pro. Don’t tell me with a straight face that everyone at Apple for the past 3+ years has been planning on continuing the Mac Pro. The gatekeepers couldn’t have cared less. And this goes all the way to the very top of the company. No, it took the outcry of the community through articles and podcasts and voting with their wallets to finally tilt the scales. And then once the company was committed to the Mac Pro once more, it made sense to give speed bumps to the preexisting one. Also notice how seemingly effortlessly Apple updated it, too. What did it take, a few hundred man hours total? That’s undeniable proof that if the company had been committed to the Mac Pro all this time, it would have done this years ago.
- The fact that some people at Apple were against continuing the Mac Pro and others were for it explains why so many bright pundits fell to each side of the debate. We were getting mixed signals and we interpreted them differently. This is The Prestige writ corporate.
- That Apple had unilaterally completely turned its back on the Mac Pro and standalone displays was something I never could convince myself. My gut was less based on evidence (other than the current Mac Pro not being discontinued) and more on a feeling of, there’s no way Apple would actually leave the Pro market.
I’m sure there are people in the Gnu PGL community who are nice, but this sums up the community’s general attitude towards licensing better than anything I’ve ever seen. Specifically WordPress’.
When the late 2016 MacBook Pro with Touch Bar came out, I wanted it so badly. But after listening to this podcast, I don’t feel the need for it. About half the Internet feels the same way, apparently.
If you’re on GitHub every day as much as I am, these shortcuts are valuable. My favorite one is
On Wednesday of this week, Stack Overflow released the survey results from the 2017 survey. There are a lot of little nuggets that are fascinating to dig into. Here are a couple of big takeaways.
- The wording on the question for operating system was very ambiguous. It wasn’t clear if it was asking what platform you were writing for or on. Amazon Web Services was an option along side Windows Desktop and Raspberry Pi. That’s very strange. The result is that the number of people who specified Mac OS (a compromise term that combines both Mac OS X and macOS) was just 18.4%, down from 26.2% from last year. This is misleading. If the survey had asked the question as clearly as it did previously, Mac OS would be in the 30% range.
- Working remote is becoming more and more of a thing. 53.3% of developers looking for a new job say that remote options are a top priority? That’s huge.
I hadn’t known before today that Find My Friends was available on macOS. I wish it were a standalone app like it is on iOS, but this will do for now.
On the flipside, I, for one, view Uber’s regulatory maneuvering in a much more positive light.
One of the great things about Ben is that you can depend on him to be against overt regulation and oppression of business. I’m glad to finally see someone say this.
Then this nugget:
Moreover, one of Uber’s other “scandals” — the fact that Kalanick asked Amit Singhal to step down as Senior Vice President of Engineering after not disclosing a sexual harassment claim at Google — reflected far worse on Google than Uber: if Singhal committed a fireable offense the search giant should have fired the man who rewrote their search engine; instead someone in the know dribbled out allegations that happened to damage a company they view as a threat.
Everyone’s talking about how horrible Uber is, but Uber isn’t alone in this.
The sad truth is that for too many this is the first case of sexual harassment they’ve cared about, not because of the victim, but because of the potential for taking Uber down.
Uber isn’t a perfect company. But the app is still on my iPhone and I continue to look forward to using it. Ben’s done a service to the community. He’s done the delicate job of analyzing the positive aspects of Uber without looking like an uncaring misogynist.
Today I upgraded to Beta 5 of macOS 10.12.4 and discovered that it breaks commit signing in tmux. If you’re using pinetry-mac and if you have
commit.gpgsign set to
true in your git config, then every time you make a commit, pinentry-mac is supposed to auto-supply the GPG passphrase from your keychain.1 What happens however with Beta 5 is that pinetry-mac doesn’t work specifically in tmux. It works in Terminal and iTerm just fine, but if you try to use tmux in either of those programs, it doesn’t work.
What are your options? You have a few.
First, you could revert using Beta 5 and go back to the latest stable version of macOS. I’m not going to do this because Night Shift on macOS beta has become indispensable for me. I use it 24x7.
The second option is that you could quit using tmux, but tmux is a must for me. This is a non-option.
The third option is that you could quit using pinetry-mac and just supply the password everytime. To do this, just modify the
~/.gnupg/gpg.conf file by removing this line:
This would get laborious though, having to manually paste in the GPG passphrase every time.
The fourth option, the one I’m going with for now, is just disabling commit signing for now. Commit signing is very cool and I like the green “Verified” badge that comes with it, but it’s not a huge loss to no longer have this. Disabling commit signing is as easy as running this:
Update: here’s the fix.
Of course, you have to supply your GPG passphrase to pinentry’s dialog window the first time you’re setting this up. ↩︎
Casey Newton, writing at The Verge:
On Tuesday morning, members of the S3 team were debugging the billing system. As part of that, the team needed to take a small number of servers offline. “Unfortunately, one of the inputs to the command was entered incorrectly and a larger set of servers was removed than intended,” Amazon said. “The servers that were inadvertently removed supported two other S3 subsystems.”
Someone enters the wrong command in Terminal, and next thing you know, entire websites are down and people can’t turn on their IoT lights in their house. That’s one powerful Terminal window.