On Trump

Ten years ago, Harry Frankfurt, a philosophy professor (emeritus) at Princeton, came out with a very slim volume entitled On Bullshit. It was basically just the republication of an essay he’d written about 20 years earlier, but it got a fair amount of attention when put in book form. What struck me about it at the time was the contrast Frankfurt drew between bullshit and lying.

This is the crux of the distinction between him [the bullshitter] and the liar. Both he and the liar represent themselves falsely as endeavoring to communicate the truth. The success of each depends upon deceiving us about that. But the fact about himself that the liar hides is that he is attempting to lead us away from a correct apprehension of reality; we are not to know that he wants us to believe something he supposes to be false. The fact about himself that the bullshitter hides, on the other hand, is that the truth-values of his statements are of no central interest to him; what we are not to understand is that his intention is neither to report the truth nor to conceal it. This does not mean that his speech is anarchically impulsive, but that the motive guiding and controlling it is unconcerned with how the things about which he speaks truly are.

Donald Trump’s recent success in the race for the Republican nomination strikes me as the apotheosis of Frankfurtean bullshit. The truth-values of his statements are of no central interest to him. Not that I haven’t run into people who spout at least as much bullshit as Trump—I’m sure you have, too—but I’ve never seen this level of bullshit when the stakes and the attention are so high.

Trump

Last week, Leon Wolf got some attention by describing Trump’s candidacy this way:

Donald Trump is the political equivalent of chaff, a billion shiny objects all floating through the sky at once, ephemeral, practically without substance, serving almost exclusively to distract from more important things – yet nonetheless completely impossible to ignore.

Chaff is a good word, but chaff is a form of lying, not bullshit. Here’s Frankfurt again (with emphasis by me), in a paragraph that seems to be written specifically for Trump:

It is impossible for someone to lie unless he thinks he knows the truth. Producing bullshit requires no such conviction. A person who lies is thereby responding to the truth, and he is to that extent respectful of it. When an honest man speaks, he says only what he believes to be true; and for the liar, it is correspondingly indispensable that he considers his statements to be false. For the bullshitter, however, all these bets are off: he is neither on the side of the true nor on the side of the false. His eye is not on the facts at all, as the eyes of the honest man and of the liar are, except insofar as they may be pertinent to his interest in getting away with what he says. He does not care whether the things he says describe reality correctly. He just picks them out, or makes them up, to suit his purpose.


New weather page

Last year, I wrote a CGI script in Python that generates a web page with just the weather information I want. It was a response to the plethora of weather apps for the iPhone that don’t quite do what I want. As I said,

This weather app doesn’t have Feature A; that app does, but it doesn’t have Feature B; this other app has both, but they’re inconveniently hidden behind a series of taps and swipes. What I want is a custom-built app that presents just the information I use in a format that’s convenient to me.

I recently updated the script to give a little more detail for the “tomorrow” and “day after tomorrow” forecasts, and I put it up on GitHub for people to download if they want to adjust it to their own needs.

I’ll reproduce the README below. If you need more detail, the original writeup is still largely correct.


Wunder

Weather information via the Weather Underground API. Intended for use on an iPhone, but I’m sure the GPS stuff can be adapted to Android.

CGI script

The CGI script, wunder.py, takes the latitude and longitude as parameters and generates a web page with

Weather page

The script requires a Weather Underground key that’s saved in the wukey variable on Line 187.

HTML file

The HTML file, wunderlocal.html, uses the iOS Geolocation class to access the GPS data via JavaScript and uses the latitude and longitude to construct a URL that calls wunder.py.

Both the wunder.py and wunderlocal.html must be put on a server where they’re accessible via a web browser. Depending on how your web server is configured, you may need to change the extension on wunder.py to make it executable. Whatever its name, you’ll need to edit Line 11 of wunderlocal.html to set the wURL variable to the URL of the CGI script.

Home screen buttons

To create a home screen button for a fixed location, just enter a URL of the form

http://path/to/wunder.py?lat=yy.yyy&lon=-xx.xxx

where yy.yyy and -xx.xxx are the latitude and longitude of the location in decimal degrees. After the page loads, use the Share button and the Add to Home Screen command to create an icon on your home screen that opens Safari immediately to the weather page for that location.

Creating a home screen button that gives you the weather for your current location is a little trickier. First, comment out the <script> in Lines 17–19 of wunderlocal.html. Then uncomment the <h1> on Line 21. Then go to

http://path/to/wunderlocal.html

in Safari. Because of the commenting/uncommenting, it won’t show any weather data, but that’s OK. Go ahead and use Add to Home Screen again to make an icon on your home screen linked to that URL.

Once you’ve made the home screen button, go back into wunderlocal.html and uncomment Lines 17–19 and comment out Line 21, putting the file back into its original state. Now when you tap the home screen button, it’ll redirect you to a weather info page for your current location. You’ll probably be asked for permission for the page to access your location.

Permission request


App Store bitching

The internet is filled with complaints about the iOS App Store. Most of the complaints are about its infrastructure, the behind-the-scenes stuff that controls features like search results and the top charts. Developers—and users who are sympathetic to developers—complain about the review process, glitches in iTunes Connect, and the race to the bottom in pricing that the App Store encourages. These are all valid complaints, but I want to focus on the App Store app itself, which has a couple of longstanding bugs that I find inexplicable.

The first is the updates badge. I don’t have my phone automatically update apps as new versions are released,1 so every few days I see a red badge on the App Store icon.

App Store in Springboard

When the number in the badge gets large enough, or if I know of a particular update I want to install, I launch the App Store app to do the updates. The app usually starts up in the Featured screen, which I don’t like but accept as a sales gimmick. What bothers me is the state of the button for the Updates screen. It should have the same badge as the icon, a red circle with the number of available updates. But the badge doesn’t appear until 5–10 seconds later.

App Store opening screen

I understand what’s going on during those 5–10 seconds. The badge on the app’s icon might have been out of date because it isn’t updated continuously, so now the app is communicating with Apple to get the correct number of updates that are available. What I don’t understand is why they can’t just use the same number that was showing on the icon as a placeholder until the new information has been retrieved. It’s disconcerting to launch the App Store because I see that two updates are waiting, only to see—initially, at least—that there are no updates waiting. Apple’s apps should be more polished than that.

More annoying is what happens when I tap the Search button. I get a lot of whitespace, a list of suggestions I have absolutely no interest in,2 and a search field at the top of the screen that I have to tap on before I can start typing.

App Store search screen

In the seven years since the App Store was established, I have never tapped on the Search button without wanting to immediately type in a search term. And yet for seven years, the App Store has forced me to stare stupidly at my phone for a second as I wonder why there’s no keyboard for me to type on. Then I think, “Oh, right. This is the stupid app,” and reach up to tap in the field that brings up the keyboard.

I get the feeling that the App Store app, like many of Apple’s “small” apps, has no champion, no one who’s spent time thinking about and testing how people use the app and how it should respond to them. It shows.

Update 8/29/15 7:36 AM
Interesting feedback on this one. A few people pointed out that Spotlight used to have the same “no focus on the field” problem (and that it might be returning in iOS 9).

Greg Pierce said, correctly, that losing the last search would be a bad thing. True enough, but if that’s the motivation for the Search behavior, it wasn’t thought through. You put focus on the field without deleting the last search terms.

Via email, Dylan Ryan mentioned that he hits the Search tab by mistake often enough to be thankful that he can back out without first having to dismiss the keyboard. He’d prefer to have the Search button on the top of the screen. Even though I’m a big wrong-button-hitter, I don’t like the idea of having app behavior so strongly influenced by response to mistaken input.

To me, the only real justification for not putting the focus on the search field immediately is if there were other reasonable things to do on that screen. Recent search history would be legitimate, but the silly suggestions I see aren’t.

The most disturbing feedback came from David Barnard,

@drdrang 5 years, 6 months


David Barnard (@drbarnard) Aug 29 2015 7:29 AM

which pretty much destroys my “no champion” speculation in the final paragraph. Oh, well. Being a tech pundit means never having to say you’re sorry.


  1. Why don’t I update automatically? That goes back to the infrastructure problems. Too often, updated versions of apps have been crippled by Apple’s policy changes, and I want to have the option of hanging onto the good versions. 

  2. And which my purchase history would show I have no interest in. 


Factories

Since writing this post about using Pandas and Matplotlib to plot the progression of the National League’s wildcard race, I’ve been periodically updating the input text files and remaking the graph. Here’s what it looked like as of this morning:

Wildcard plot

As I mentioned in that earlier post, I get the data for each game by copying and pasting from the mobile version of the Baseball Reference site. The game results come in looking like this:

CHC 7 v. ATL 1, Aug 20th
CHC 5 v. ATL 3, Aug 21st
CHC 9 v. ATL 7, Aug 22nd
CHC 9 v. ATL 3, Aug 23rd
CHC 2 v. CLE 1, Aug 24th
CHC 8 @ SFG 5, Aug 25th
CHC 2 @ SFG 4, Aug 26th

and I need to transform them into this

7     1     ATL   H     Aug-20
5     3     ATL   H     Aug-21
9     7     ATL   H     Aug-22
9     3     ATL   H     Aug-23
2     1     CLE   H     Aug-24
8     5     SFG   A     Aug-25
2     4     SFG   A     Aug-26

with tabs between each column. When I first did this transformation for that post, I just ran through a few manipulations using BBEdit’s find and replace tools, kind of making it up as I went along. But when I found myself in the habit of updating the graph a couple of times a week, I realized I needed something more automated. The quickest way to get what I wanted was to build a Text Factory.

Text Factories are a BBEdit feature that I don’t use as often as I should. They consist of a simple list of transformations—replacements, deletions, case changes, entabbing/detabbing, etc.—that are applied one after another to either the selected text (if there is any) or the the document as a whole. Their genius lies in their simplicity: there’s nothing a Text Factory can do that a Perl, Python, or Ruby script couldn’t do, but for simple series of transformations, Text Factories take less time to build and debug.

Here’s my Text Factory for transforming the Baseball Reference game data:

BBRef Text Factory

The first step is the trickiest. It’s a Grep (regular expression) that searches for

^[A-Z]{3}\s+(\d+)\s+([^ ]+)\s+([A-Z]{3})\s+(\d+),\s+([A-Za-z]+)\s(\d+)(st|nd|rd|th)$

and replaces it with

\1\t\4\t\3\t\2\t\5-\6

By itself, it turns lines like

CHC 2 v. CLE 1, Aug 24th
CHC 8 @ SFG 5, Aug 25th

into

2     1     CLE   v.    Aug-24
8     5     SFG   @     Aug-25

The regex search pattern is probably longer than it needs to be because I’ve added some defensive features, like using \s+ as field separators even though every example I’ve seen separates the parts with just a single space character. I’ve had enough experience with regexes breaking because of an unexpected extra space to know that sacrificing brevity for robustness is a worthwhile tradeoff.

With the hardest part done, the following two steps change the “v.” into “H” and the “@” into “A.” That completes the transformation and makes the input files ready for the plotting script.

The downside of using a Text Factory is that it locks me to BBEdit. I can’t do the transformation from the command line or use it as part of some longer pipeline, as I could if I’d written it as a Python script. For this transformation, that loss of flexibility is no big deal, as I don’t expect to be making this plot much longer. Rewriting it as a regular script isn’t worth the effort.

What’s kept me interested the past few weeks has been the tremendous run of success the Cubs have had recently, but I know myself and the Cubs too well to expect that to continue.

So I’m enjoying this August but waiting for the inevitable disgust to set in. When it does, the Text Factory will be shuttered and its regular expressions laid off.