August 30, 2015 at 11:01 PM by Dr. Drang
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.
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.
August 29, 2015 at 4:23 PM by Dr. Drang
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.
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.
The CGI script,
wunder.py, takes the latitude and longitude as parameters and generates a web page with
- A local radar image centered 1° west of the location. I’m used to weather coming from the west.
- The current conditions and today’s sunrise and sunset.
- The forecast for the next twelve hours, given at three-hour intervals.
- Forecasts for the next two days, given at four-hour intervals.
The script requires a Weather Underground key that’s saved in the
wukey variable on Line 187.
The HTML file,
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
-xx.xxx are the latitude and longitude of the location in decimal degrees. After the page loads, use the Share button and the 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
in Safari. Because of the commenting/uncommenting, it won’t show any weather data, but that’s OK. Go ahead and useagain 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.
August 28, 2015 at 10:10 PM by Dr. Drang
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.
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.
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.
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,
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.
August 27, 2015 at 11:39 PM by Dr. Drang
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:
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:
The first step is the trickiest. It’s a Grep (regular expression) that searches for
and replaces it with
By itself, it turns lines like
CHC 2 v. CLE 1, Aug 24th CHC 8 @ SFG 5, Aug 25th
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.
- I was driving across Ohio on October 14, 2003, screaming at the radio in my rental car when the Steve Bartman incident occurred and the Cubs self-destructed, losing a game they had well in hand and fumbling away their chance to go to the World Series.
- I was in graduate school, watching every game on TV in 1984 when the Cubs blew a 2–0 series lead in a best-of-five playoff to the Padres, capping it off with Leon Durham’s error in Game 5.
- I was a young and impressionable fan in 1969, when the Cubs underwent the most celebrated collapse in baseball history, going from an 9½ game lead on the Mets in mid-August to 8 games behind them by the end of the season.
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.