October 22, 2016 at 12:21 AM by Dr. Drang
A few weeks ago, a new Mac app called TableFlip was released. It’s a spreadsheet-like editor that works with Markdown tables, and it got favorable reviews from folks like Brett Terpstra, Katie Floyd, Eddie Smith, and John Voorhees. Longtime readers of this blog will know that my interest in making it easy to edit and cleanly display Markdown tables goes way back, so I was eager to give TableFlip a try. I was a little busy earlier in the month, but I’ve had a chance to give TableFlip a workout over the past week. Bottom line: in its present state, it’s not ready for me, but I can see where other people would find it quite useful.
Let’s start at the beginning. Strictly speaking, there is no such thing as a “Markdown table,” because John Gruber never implemented a table syntax. What I, and most people, call the “Markdown table” syntax is a common extension to the basic Gruber syntax. It was popularized by Fletcher Penney in his MultiMarkdown processor, although I believe it was Michel Fortin’s PHP Markdown Extra that was the first to include it.
The syntax uses a set of pipe (|) characters to separate the columns and a row of dashes with optional colons to separate the header from body of the table and to set the alignment of the columns. Here’s an example:
| Column 1 | Column 2 | Column 3 | |--|:--:|--:| | first | second | third | | column | column | column | | left | center | right |
The leading and trailing pipe characters are optional, but I prefer to include them. When processed, the code above turns into a nice HTML table, like this:
|Column 1||Column 2||Column 3|
As you can see, the Markdown code for a table can be messy. It’s easy to lose track of which column you’re working on because the contents of the table cells have different lengths and the pipe characters don’t line up with each other.
Veteran Markdown table users like me have written scripts that allow us to create our tables in a spreadsheet, where the columns line up automatically, copy them them into a text editor, and convert the tab-separated text that comes from the spreadsheet into Markdown format. What TableFlip does is turn that two- to three-step process into a single step without any need to invoke a script.
As you can see, it looks just like a spreadsheet. You can set the column alignment by clicking one of the buttons on the right side of the toolbar. Other buttons let you insert and delete rows and columns, just like a regular spreadsheet application. Documents created in TableFlip are plain text files with the tables in nicely formatted Markdown. The table shown in the screenshot above is saved in this format:
| Element | Grade B | Grade C | | :--------- | ------: | ------: | | Carbon | 0.260 | 0.230 | | Manganese | -- | 1.350 | | Phosphorus | 0.035 | 0.035 | | Sulphur | 0.200 | 0.200 |
As you can see, TableFlip adds spaces to the columns to get the pipe characters to line up and make the text form of the table easy to read.
What’s even better, though, is that TableFlip isn’t limited to files that contain only Markdown tables. Any Markdown file can be opened in TableFlip, and it will find and display for editing the tables within that file. Changes made to the source document in a text editor are reflected in TableFlip; changes made to the tables in TableFlip are reflected in the text editor.
What if you’ve been writing a Markdown file and want to insert a table without typing any of those nasty pipe characters? Can TableFlip help you do that? Yes. If you open an existing Markdown file that has no tables in TableFlip, you’ll see this screen, which gives you an empty stub table to copy and paste into your document.
After you’ve done this a few times, I suspect you’ll learn to just type a pair of pipes wherever you want to put a table.
So after all this praise of TableFlip, why don’t I want to use it? Several reasons, some of which are related to its user interface, some to its functionality, and some to my peculiar tastes in formatting.
On the user interface side, the font size is just a bit too small, and TableFlip has no way to increase it. This is a known problem, and Christian Tietze, TableFlip’s developer, plans to fix it, but until it’s fixed, my 56-year-old eyes find it difficult to use.
Another user interface annoyance is the inability to select more than one cell at a time. TableFlip columns are left-aligned by default, and it’s very common for me to want to change the alignment of several of them after I’ve typed in the data. The natural thing to do would be to drag across the columns I want to change (or to shift-click or command-click to extend a selection) and then click the desired alignment button in the toolbar. But because only one cell can be selected, I’m forced to change the change the alignment one column at a time. This is very unnatural, as no real spreadsheet—and I’ve been using spreadsheets for 30 years—works this way.
On the functionality side, TableFlip doesn’t support two Markdown table features that I use often: multiple header rows, and headers that span multiple columns. Here’s an example with both: as source code,
| | Tensile strength || | Grade | ksi | MPa | |:-----:|:-----------:|:---:| | B | 58 | 400 | | C | 62 | 427 |
and as a rendered table.1
I don’t think PHP Markdown Extra supports either of these extensions (in fact, I cheated and wrote HTML directly to get the rendered table above), but MultiMarkdown has both and I use them a lot in the reports I write for work. The TableFlip roadmap shows that these are planned, but because they aren’t available now, I’m forced to do a lot of hand-editing to get what I want.
TableFlip can get confused when reading complicated Markdown documents. In the source file for this page, for example, the single pipe character in the third paragraph caused TableFlip to think that paragraph was a table.
The “tables” that are actually rendered as source code are a further source of confusion.
This is probably not a problem that would arise with most people, but it does if you write examples and explanations of Markdown.
On matters of taste, look again at how TableFlip saves that table of chemistry limits for A500 steels:
| Element | Grade B | Grade C | | :--------- | ------: | ------: | | Carbon | 0.260 | 0.230 | | Manganese | -- | 1.350 | | Phosphorus | 0.035 | 0.035 | | Sulphur | 0.200 | 0.200 |
Although the second and third columns are to be right-aligned, TableFlip displays them as left-aligned. I know this only source code and it doesn’t affect the rendered output, but if you’re going to format the source code, format it according to the indicated alignment. Even my script can do that.
| Element | Grade B | Grade C | |:-----------|--------:|--------:| | Carbon | 0.260 | 0.230 | | Manganese | -- | 1.350 | | Phosphorus | 0.035 | 0.035 | | Sulphur | 0.200 | 0.200 |
Tietze has big plans for TableFlip, and I hope he follows through with them. I’d like to have a professionally written app that can handle the kinds of tables I need to make. But right now, I’m sticking with Numbers, my formatting scripts, and the workflows I’ve used for years.
And I see now that my CSS stylesheet never anticipated multiple header lines. That thick horizontal line between them looks stupid. ↩︎
October 3, 2016 at 10:09 PM by Dr. Drang
When PCalc 3.6.1 came out a little over a week ago, I saw something disturbing in the release notes:
Round function now always rounds half upwards to the nearest integer.
Perhaps the release notes were wrong. I opened PCalc and began testing.
- 1.5 rounded to 2, which is consistent with PCalc’s previous behavior and correct.
- 2.5 rounded to 3, which is new and wrong.
I got on the Twitter and shot off a direct message to PCalc’s developer, James Thomson, asking, in effect, WTF? His reply was pretty much what I expected. He’d been getting complaints from people who expected (for positive numbers, anyway) that halves would always be rounded up.
This is an all-too-common belief, instilled in children by parents and elementary school teachers who were taught it by previous generations of misguided souls. You may believe it yourself; I certainly did until I became enlightened sometime in grad school.
The problem with always rounding halves up is that in doing so, you introduce a persistent bias in whatever calculations you do with the rounded number. If you’re adding a list of rounded numbers, for example, the sum will be biased high.2
If you round halves to the nearest even number, though, the bias from upward roundings tends to be negated by an equal number of downward roundings.3 Overall, you get better results.
James expected the rounding change to raise hackles, and he was thinking about how to provide rounding options before I DM’d him. PCalc 3.6.2, released today, is the result. There’s a new Rounding item in the Advanced Settings. Tapping it gives you these six choices:
The top option is what the great unwashed expect. The second is the One True Rounding. The others are specialized options that are often needed when doing integer calculations. The floor and ceiling roundings, for example, get used in things like the Doomsday Algorithm.
PCalc’s “round” function rounds to integers, but rounding also applies when you have the display set to show a limited number of decimal places.
With Nearest or Even rounding and two decimal places chosen, the numbers ⅛, –⅛, ⅞, and –⅞ will display like this:
Note that although this display rounding follows the same rule as the round function, the numbers in the display still retain, behind the scenes, all their digits. Therefore, if we enter ⅛, we’ll see 0.12 in the display, but the number is really 0.125. Multiplying by 2 will give us 0.25, not 0.24. This differs from the round function, which really does change whatever number it’s applied to into an integer.
I was perfectly happy with PCalc’s old behavior, which always rounded halves to even, but, shockingly, James has to consider the needs and wants of customers other than me. Now there’s rounding for everyone.
Yes, IEEE 754 does define other rounding rules, but round to nearest, ties to even is the default. ↩︎
I’m assuming positive numbers in this example. When numbers come from measurements, that’s the most common case. ↩︎
If you’re thinking Benford’s Law screws up the notion that there will be an equal number of upward and downward roundings, think again. Benford’s Law applies to the most significant digit; rounding is done to the least significant digit. Only if you’re rounding to one digit will Benford’s Law lead to significant bias. And even then, rounding halves to even is still less biased than rounding them up. ↩︎
October 2, 2016 at 8:40 PM by Dr. Drang
I mentioned Supertop’s Castro podcast player a couple of days ago and decided I should devote a full post to it. It got a lot of coverage when Version 2.0 was released in mid-August, so it’s very unlikely you haven’t heard about its unique approach to organizing your playback queue via “triage” of your inbox of episodes. But since I’m still using it several weeks later, after it’s no longer a novelty, I thought it worth a second look.
Every review of Castro spent most of its time talking about the inbox, and rightly so. If you’re the kind of person who subscribes to many podcasts, but doesn’t have the time to listen to every episode, the inbox is a great way to swiftly look through your available episodes, queue up those that look the most interesting, and get rid of those that you’ll never get around to.
Here’s my inbox as of a few minutes ago:
Tapping on an episode brings up the dispatch buttons.
You can either
- Play the episode right from the inbox. I never do this.
- Send it to the top of the playback queue. If the episode currently at the top of the queue is in progress, the one in the inbox will go just under it.
- Send it to the bottom of the playback queue.
- Archive it. “Archive” is Supertop’s word, and I think it’s a poor choice. The episode, if downloaded, isn’t stored on your device, it’s deleted and only its metadata is kept. Basically, Archive = Delete.
One of the nice usability touches of Castro is that after you’ve dispatched an episode and it disappears from the inbox, the dispatch buttons appear automatically on the next episode in the list. Castro assumes—correctly in almost every case—that once you start triaging you want to continue, and it doesn’t force you to tap on the next episode to make the dispatch buttons reappear. This makes processing your inbox go very quickly.
Don’t be concerned, by the way, that the dispatch buttons limit you to the top and bottom of the playback queue. When you switch to the queue, you can rearrange the episodes by grabbing the dotted handles at the right and dragging them up or down.
One thing that bothered me about the initial reviews of Castro 2 was that they left the impression that you have to go through the triage procedure, even for those podcasts where you listen to every episode. That’s not the case. Although starting in the inbox is the default, you can change the settings for certain podcasts to go straight to the top (or bottom) of the queue.
In my set of subscriptions, new episodes of In Our Time, 99% Invisible, and Slate’s Political Gabfest go straight to the top of the playback queue. I never skip an episode. The Talk Show, on the other hand, too often has guests that offer no insight,1 so it gets the triage treatment. So does The Incomparable, although I’m beginning to think that’s a mistake. I set it up so new episodes would go to the inbox because I thought I wouldn’t want to listen to episodes about books and movies I haven’t read or seen. But I’ve found that I so rarely skip an episode, it isn’t worth the triage step.
The downsides to Castro that most reviewers mentioned back in August still hold true:
- Speeded-up playback in Castro is nowhere near the quality of speeded-up playback in Overcast or Pocket Casts. And it has nothing like Overcast’s Voice Boost feature. These deficiencies don’t affect me because I always listen at normal speed and the shows I subscribe to tend to be recorded with fairly uniform levels among the guests.
- Podcast discovery in Castro pales in comparison to discovery in other apps. Again, this doesn’t bother me, because I learn about new shows from Twitter and blogs. And I’m really subscribed to too many shows as it is.
I’ve been pretty promiscuous in my use of podcast players. Only Downcast and Overcast have stuck for more than a year (and I used Downcast back when there were few decent alternatives). Supertop could make a UI change to Castro tomorrow that sours me on it. But right now, Castro fits my way of listening better than the others.
These are almost always the tech reporters for “real” news outlets. ↩︎
September 30, 2016 at 9:41 PM by Dr. Drang
Yesterday morning, a new podcast episode popped up in my Castro inbox: a Relay B-Side called The Mac Draft.1 In it, Stephen Hackett, Christina Warren, Brian Sutorius and Ed Cormany did a four-round draft of significant or favorite Macintosh models. It’s a fun show, and you should give it a listen. (If you’re used to the draft shows on The Incomparable, fear not. This one’s only 48 minutes long.)
If you’ve been a Mac user for any length of time, you’ll probably think of which machines you would have drafted had you been on the show. I sure did, and that’s what this post is about. One restriction I’m going to impose on myself that the youngsters didn’t is that I will only draft Macs that I owned or was the primary user of at work. I like the personal touch.
Round One: SE/30
Yes, I know Ed drafted the SE/30 with his first round pick. I’m just going to assume that I went before him and sniped this pick. It’s my blog, and I’ll do what I want.
The SE/30 is the favorite of a lot of Mac users of a certain age. During the Mac’s 25th anniversary year, it was hailed as the greatest Mac ever by no less than Adam Engst, John Gruber, and John Siracusa. Introduced to the world at the beginning of 1989 and retired almost three years later, it was the apotheosis of the original Mac form factor.
I was teaching in 1989, and that fall one of my departmental colleagues got an SE/30. I was immediately filled with jealousy. When I changed jobs at the beginning of 1990, I persuaded my new employer to provide me with an SE/30, and the sour feeling of inadequacy washed away as I set it up at the corner of my desk.
That was the great thing about the SE/30. It was a serious workstation—the 68030 processor was a beast for its time—in a package that could fit almost anywhere. And when I was 30 years old, my eyes could handle the 9″, 512×342 pixel, black-and-white screen.
Round Two: 2010 13″ MacBook Air
No need for a stock image of this one; it’s sitting on my lap right now. This is not the much-maligned original Air. It’s the second-generation model, the one they got right. Real ports, no flip-down door, and Flash storage instead of a 4200 rpm, iPod-class hard disk.
This machine was a revelation when I first got it. It booted up so fast. In fact, everything seemed extra quick, an indication that most of what I was doing was constrained more by I/O than by processing. And of course, it was so thin and light. Even after six years, I don’t really feel it’s a museum piece—it still gets the job done.
Although I drafted the SE/30 first, that was a tactical decision. This is my favorite Mac.
Round Three: 512K
This was my first Mac. I bought it in grad school and wrote my Ph.D. thesis on it, using MacWrite, MacDraw, an ImageWriter, and Andy Hertzfeld’s amazing Switcher.
Although the formal name was 512K, based on its RAM, everyone called it the Fat Mac. Mine was configured with an external single-sided diskette drive to compliment the internal drive. That gave me a whopping 800 kB of storage for the system, the applications, and my files.
But the best thing about the Fat Mac was its RAM, something that didn’t become apparent until Switcher was released. Because applications had to be written to fit in the 128 kB of the original Mac, Switcher allowed you to fit the Finder plus two or three other applications into RAM and quickly flip back and forth between them. It wasn’t multitasking, but it was sure better than the usual launch/use/quit, launch/use/quit cycle. Given that I typeset by hand the equations for my thesis in MacDraw and then pasted them into MacWrite, Switcher was a godsend.
Round Four: Cheating
I have three Macs that I’d like to put into the fourth slot, and I don’t know which one to choose. So I’m just going to cheat by squeezing them all into one round. Again, it’s my blog.
- The Macintosh II. I won this computer in an Apple software contest run shortly after the Mac II was introduced. It wasn’t the grand prize, but it was good enough for me. The 68020 processor was a big step up from the 68000 of the Fat Mac and the Mac Plus, and of course it was the first Mac with color. It was a gigantic thing, though, and took up almost all of the desk I had it on.
- The PowerBook 170. This replaced my SE/30 as I started traveling more for my job in the early 90s. It was the high end model of Apple’s first three real notebook Macs (I don’t count the Macintosh Portable, which weighed about 16 pounds and used—you can look it up—a lead-acid battery) and was quite peppy. I remember it took a while for me to get used to the trackball after 5–6 years of mousing.
- The 12″ iBook G4. Lots of people love the 12″ PowerBook G4 (Brian picked it in Round Two). The iBook was about half the price and had close-enough specs. I got a lot of work done on this guy, but when OS X became Intel-only, its days were numbered. I got it at the end of 2004—my return to the Mac after years of using Linux—and held onto it until I got the Air in the fall of 2010. A sturdy performer for many years.
Surprisingly, the SE/30 is the only overlap between my choices and the ones made by Stephen, Christina, Brian, and Ed. A good part of this is because my choices are biased toward the early days of the Mac—a lot of beige, as Stephen would say. But it’s also because 30+ years of design includes something for everyone.