Archive for May 15, 2017

Monday, May 15, 2017 [Tweets] [Favorites]

A Tale of Three Git Filter Branches

Greg Hurrell (via tweet):

I used git-filter-branch to rewrite the history of the repo containing this website’s files, processing 4,980 commits and transforming 3,702 wikitext files to Markdown along the way. I wrote three separate versions: the first would have taken as long as 42 days to complete, the second perhaps 3 to 4 days, and the third and final version completed in about an hour.

[…]

That last one sure sounds the most elegant, doesn’t it? But it also obliges us to accept a reality about Git’s object database: it’s made to be blazingly fast for certain common operations (git status, git commit etc) but not others. For example, answering that question of “detecting when an item first entered the repository” could require you to traverse back from the current HEAD all the way back to the root commit of the repository, which could mean examining a thousands-long commit chain. And note, even if you know how Git works and seek to minimize the number of git processes that you need fork and the number of commits that you actually need to examine (eg. by limiting git log with a pathspec), Git’s internals will still need to traverse that thousands-long chain in the worst case.

Searching for Swift Objects by Type

Tim Ekl:

This rubbed me the wrong way, specifically because of the is SpecialView/as! SpecialView combination. It seemed like I should be able to do the type check once and get the object back as that type, maybe using as?.

[…]

However, there’s a cost here: where previously we’d stop enumerating subviews once we found the first SpecialView, with flatMap we run all the way through the array before getting the first result. If subviews is an especially large array, this could become a performance hotspot very quickly.

In Objective-C, the obvious for loop or array-searching closure would do the right thing, without the need for concepts like flatMap and lazy. Then again, so would a Swift for loop with if let, but people would tend not to write it that way.

If you wanted to generalize this sort of view search in Objective-C, you could pass a class as a parameter. That doesn’t really work in Swift because you would end up with an awkward Any? return value. So you get into generics. You can pass a parameter of type Any.Type, but that doesn't really help because Swift can’t use this to determine the return type. Instead, you could make the function take no parameters, passing the type as a template parameter that’s inferred based on the calling context. However, I think that makes the call sites look weird, and you still end up with an optional to unwrap.

Everything Is Broken

Dan Luu:

If I had to guess, I’d say I probably work around hundreds of bugs in an average week, and thousands in a bad week. It’s not unusual for me to run into a hundred new bugs in a single week. But I often get skepticism when I mention that I run into multiple new (to me) bugs per day, and that this is inevitable if we don’t change how we write tests. Well, here’s a log of one week of bugs, limited to bugs that were new to me that week. After a brief description of the bugs, I’ll talk about what we can do to improve the situation.

See also: Will Thompson (tweet).

This is how I feel using Apple’s software lately, but I guess the grass isn’t greener.

Instagram Now Supports Photo Uploads From Mobile Site

Juli Clover:

Prior to the update, Instagram only allowed photo uploads from its mobile apps, and the iOS app is limited to the iPhone, so iPad users were forced to download an iPhone-only app with an unoptimized layout to upload photos to the social network.

The Instagram website on mobile devices was previously only available for browsing photos, liking content, searching, and viewing notifications, but now it's possible to upload photos.

But it sounds like there still isn’t a first-class iPad experience, and you can’t upload from a Mac unless you set your browser to use the mobile version of the site.