This is an interesting article about the continued dominance of relatively expensive Texas Instruments graphing calculators in secondary education.

I still have (and periodically use) my TI-89. Even though my phone is vastly more capable, there’s something to be said for dedicated, optimized hardware keys for heavy use.

I relied on this calculator throughout high school, but when I got to college, calculators were simply not allowed for math tests. I thought I would hate this, but in reality it worked fine. I’m not sure why high school math courses don’t ban calculators for tests considering how many problems the TI calculators cause.

The article linked above quotes the founder of Desmos, which provides a free web tool with an accompanying iOS application that provides a lot of the functionality of a TI graphing calculator but with better interactivity. It’s worth playing around with!

I’ve bounced back and forth between OmniFocus and Things several times now. They are very similar applications in many ways, but do have some significant differences.

Here’s what I like and dislike about each:

OmniFocus

Pros:

• End to end encryption.
• Extremely flexible.
• Web interface.

Cons:

• The visual design of the app isn’t to my taste. This seems silly, but I find myself less willing to use an app I don’t like the look of.
• Keyboard shortcuts on the Mac are not intuitive to me.
• Extra complexity of defer + due dates for every task is an annoyance. The Things model of “plan for later” dates, with optional deadlines and additional reminders, works better with the way I work.
• The downside of having an extremely flexible application is that it is necessary more complex. I do find OmniFocus’s flexibility helpful, but I’m left with just a bit more unhelpful (for me) complexity than I’d like.
• Uses the clunky, default iOS date picker with no option for natural language parsing of dates/times.
• The natural language date parsing on the Mac is a bit finicky. For example, sep 1 works but sept 1 does not for “September 1”.
• Adding a new task on the watch with “hey Siri” requires tapping the watch after you finish dictating.

Things

Pros:

• One of the best-looking apps of all time (not hyperbole, it’s really good).
• User interface design and user experience is extremely well-conceived and we’ll-executed.
• iPad keyboard support (arguably the best of any app of any category – again, not hyperbole).
• Excellent natural language parsing for dates on the Mac, and a great custom date picker on iOS.
• Headings inside projects.
• The “today” and “this evening” lists map onto how my brain works.

Cons:

• Can’t check off a repeating task before its due date (they are working on fixing this but it requires a revamp of their underlying data models so I don’t expect this to change anytime soon).
• No ability to attach files to tasks.
• No ability to use rich text in task notes.

Both are good at

• Reliable, fast sync.
• Very few, if any, crashes or bugs.
• Made by reputable indie developers who have been around for a long time.
• Quick task entry pop-up on the Mac, and draggable new task button on iOS (allows you to drop a new task exactly where you want it).
• Integration with the system share sheet on iOS.

Both are missing

• Any notion of shared task lists.

Earlier this month, Microsoft announced native support for Jupyter notebooks in VS Code. I just got the chance to try it out today, and it works great.

Why does this matter? Primarily because the web interface for Jupyter notebooks doesn’t have many of the features Python programmers who use IDEs are used to, such as autocomplete and interactive debugging. These features make programming in Python much faster and less error-prone.

I’ve tried to use PyCharm’s Jupyter notebook support in the past, but it ran quite slow even on my very beefy computer. (This was at least a year ago, so it may no longer be true.)

In my testing, VS Code is lightning fast and the autocomplete support is great. Interactive debugging currently works via exporting the notebook as a Python script, and according to their blog post they are planning to add debugging features directly to Jupyter cells in the future.

For anyone who does serious work in Jupyter notebooks, I highly recommend checking out VS Code.

(PyCharm is also generally great, but is more complex and requires a license for Jupyter notebook support. The license is free for academics/research; paid otherwise.)

There’s an interesting paper in Science by Ziad Obermeyer and colleagues on racial bias in healthcare risk prediction algorithms:

The bias arises because the algorithm predicts health care costs rather than illness, but unequal access to care means that we spend less money caring for Black patients than for White patients. Thus, despite health care cost appearing to be an effective proxy for health by some measures of predictive accuracy, large racial biases arise. We suggest that the choice of convenient, seemingly effective proxies for ground truth can be an important source of algorithmic bias in many contexts.

The effect of this bias is that healthier White patients were referred for extra services in place of less-healthy Black patients (who presumably needed the extra services more).

This is a good reminder for anyone working on healthcare models to always stratify to see if the model behaves differently for traditionally marginalized groups. Not fixing these issues has serious real-world consequences on people’s health!

It’s been a while since I went down an epidemiology rabbit hole, but I just ran across this great discussion on the datamethods forum about chance imbalances in baseline characteristics among study arms in randomized trials, and the typical “Table 1” that reports summary statistics for each baseline characteristic stratified by study arm. This gets at something that has bugged me since I took a clinical trials class in grad school.

First of all, if you haven’t already closed this tab, you should read Frank Harrell post arguing for the elimination of the traditional “Table 1” from reporting clinical trial results. His alternative is really interesting, and he makes a compelling case.

But if you don’t have a traditional Table 1, how does a reader know that a chance imbalance of a critical baseline variable didn’t influence the results of the trial? Randomization of patients into study arms only guarantees balance of baseline characteristics on average if you randomize many times — but most clinical trials are just conducted once. If that one randomization happens to, for example, put all women in Group A and all men in Group B (unlikely but theoretically possible), it’s important to know this and account for it. This is something that’s always bothered me about clinical trials that rely on unadjusted comparisons among arms.

Frank’s suggestion is to:

“Pre-specify the most important prognostic factors” and adjust for them come hell or high water.

This seems like a clean solution, and it forces investigators to identify key baseline characteristics a priori, which is a good idea regardless of the analytical approach.

The CONSORT guidelines for clinical trials recommend reporting both unadjusted and adjusted analyses. But I’ve never understood what value the unadjusted analysis adds over the adjusted one (assuming the adjustment is for pre-specified baseline characteristics). If the baseline characteristics are balanaced among arms, then the adjusted analysis will show no effect for these covariates — in other words it will look essentially the same as the unadjusted analysis. If they are not balanced, then you want to adjust for them — and the unadjusted analysis isn’t meaningful.

I’m not a clinical trials analysis expert by any means, so I’m willing to be convinced that I’m wrong here. If there’s a compelling argument for reporting unadjusted analysis instead of (or along with) a pre-specified adjusted analysis, I’m all ears!

Michael Bernstein, writing about spreadsheets vs. programming:

Spreadsheets are amazing, they solve specific problems in an optimal way, and they are as useful as a currency as we could hope for in information exchange.

I agree spreadsheets are very powerful and accessible. Excel is one of my all-time favorite applications! But there are two fundamental problems with spreadsheets:

1. The way spreadsheets are structured makes it very difficult to find bugs in formulas or peer review them. In fact, a complex spreadsheet may be impossible to understand for anyone but the author.
2. Version control and “diff” capabilities are far less advanced for spreadsheets than for programming languages. This is important for identifying the impact of changes and understanding the history of how a file was constructed.

I’m not saying we should throw out Excel and do everything in FORTRAN. But we need to be aware of these limitations, especially when using spreadsheets to make major decisions or in mission critical applications.

I wish makers of spreadsheet software would add in more advanced capabilities to address these problems, but I’m not holding my breath.

There’s a great article from Geoffrey Fowler at The Washington Post on the massive security problems with browser extensions:

Jadali tested the links between extensions and Nacho by installing a bunch himself and watching to see if his data appeared for sale. We did some of these together, with me as a willing victim. After I installed an extension called PanelMeasurement, Jadali showed me how he could access private iPhone and Facebook photos I’d opened in Chrome, as well as a OneDrive document I had named “Geoff’s Private Document.” (To find the latter, all he had to do was search page titles on Nacho for “Geoff.”)

…

After we disclosed the leaks to browser makers, Google remotely deactivated seven extensions, and Mozilla did the same to two others (in addition to one it disabled in February). Together, they had tallied more than 4 million users.

(Emphasis mine.)

These extensions can literally see anything you look at or type on a web page, and can send this information to a third party’s server without your knowledge.

The only browser extensions I run are from highly trusted developers, namely 1Password and MarsEdit. Everything else that needs a browser extension (mostly reference management services) lives only in a separate user profile in Chrome where I don’t open anything sensitive.

I’m a huge fan of Soulver, a scratchpad for doing calculations and unit conversions of all kinds. It’s great for things that aren’t complex enough to need a spreadsheet, but are too fiddly for a standard calculator. This is what it looks like:

I maintain that anyone who is doing any math on their Mac or iOS device should have Soulver open at all times. I’m not the only one.

But what about people on Windows or who want to use a web browser? I was hoping this thread on Hacker News would surface some good options, but none of the suggestions I tried were as well-designed, well-maintained, or usable.

SpeedCrunch was the one suggestion that looked interesting – it’s open source and available on Linux, Mac, and Windows (not mobile though). The design differs from Soulver but the basic idea is the same. Unfortunately the Mac version is not signed with a developer certificate so I’m not comfortable installing it on my computer. If you are braver than I, let me know how it works.

Update (April 11, 2020): hCaptcha is now a viable replacement for reCAPTCHA.

I use Google’s reCAPTCHA v2 on my website’s contact form to prevent spam from automated systems. It seems to work fine – the only spam I get is manually produced by real humans trying to convince me to post their garbage on my blog.

Long-term it looks like Google is moving to reCAPTCHA v3, which apparently should be run on every single page of my site to be most effective and uses the presence of a Google cookie as a signal to identify humans from robots.

I would prefer to not run extra mystery-meat JavaScript on every page of my site and penalize humans who don’t stay signed into Google services, and I’ve found recent reCAPTCHA v2 challenges increasingly difficult and inconvenient. Because my site is not a magnet for targeted spam attacks, most likely any sort of CAPTCHA would work fine – I don’t strictly need the high sensitivity of reCAPTCHA v2 or v3.

I spent a bit of time looking at alternatives, starting with this “Ask HN” post and then doing some research on my own. I turns out there are pretty much no alternatives to reCAPTCHA. The few that were mentioned on “alternative to reCAPTCHA” lists seem to be shut down, their websites returning 404 errors or (ironically) taken over by spam.

The one possibly viable option I found was TextCaptcha, which according to Pinboard I first found back in 2013 and subsequently forgot about. However, their API is not available over HTTPS so I can’t use it on my HTTPS-enabled site without either a proxy or setting up a server-generated contact page.

Therefore my options are:

1. Write my own CAPTCHA in JavaScript (would be effective but might have usability edge cases)
2. Replace my static contact form with a dynamically generated page (adds complexity and maintenance to my website, will be slower to end users than a static page)
3. Continue using reCAPTCHA v2 for now, while I work on a solution for using TextCaptcha that gets around the HTTPS issue.

The last option seems the best for me. I wish there was a non-creepy state-of-the-art CAPTCHA option, but I suspect these attributes are mutually exclusive for large websites today.

DuckDuckGo seems to be the go-to replacement for Google for those concerned about privacy. DDG is relatively mainstream now, after being added as a search engine option in Safari back in 2014.

I’ve used DDG as my default search engine for a while now, but sometimes the results just aren’t great. I have been falling back to Google with this bookmarklet that takes advantage of DDG’s awesome !g bang feature.

(I should mention that sometimes the DDG results are actually better than Google’s. It depends on the query.)

Yesterday, I ran across Startpage.com for the first time. It’s a DDG-esque search engine that displays results from Google but claims to not track any user data. I’m surprised I haven’t heard of them before – they’ve been around since 1998.

It turns out you can swap !g with !sp with DDG’s bang feature to try searching Startpage.com instead of Google. I’ve switched my search fallback bookmarklet accordingly in the hope that SP really is a drop-in replacement for my use of Google.

I wm curious if anyone knows more about Startpage.com, or has experience using it. Please get in touch if you do.

It’s awesome that Apple Music has a Deutsche Grammophon-curated “Browse” section, but there doesn’t appear to be a way to actually find this in the Apple Music iOS app.

You can search for “Deutsche Grammophon” but that only will bring you to this page.

The “Browse” page, which is at http://www.applemusic.com/dg (I didn’t know applemusic.com was a thing until now), does not appear to actually be discoverable through Apple Music. Maybe it magically appears in “Browse” for some users?

This is annoying because the “Browse” page has way more content than the search result for DG. Why in the world don’t they surface the “Browse” page for DG in search results?

Also when I tried going to applemusic.com on iOS, I was sent to the App Store and shown an error indicating that I need to update to at least iOS 8.4 to use Apple Music (I’m on iOS 12.1.4).

Update:

https://music.apple.com/us/curator/deutsche-grammophon/1099882563 works at least on macOS.

The journal eLife recently published a “computationally reproducible” article:

Today eLife, in collaboration with Substance, Stencila and Tim Errington, Director of Research ar the Center for Open Science, US, published its first reproducible article, based on one of Errington’s papers in the Reproducibility Project: Cancer Biology. This reproducible version of the article showcases some of what’s possible with the new RDS tools, and we invite researchers to explore the newly available opportunities to tell their story.

eLife’s reproducible format essentially gives readers functionality like you would find in a Jupyter notebook or RMarkdown document, but in the standard browser interface on eLife’s website. This lets you modify analysis code and re-generate tables/figures without having to download anything, or set up a local R or Python environment!

If you read their post about this, it’s clear that a lot of effort went into the technology stack making this possible. It’s an impressive effort, and sorely needed by the scientific community.

Hopefully other publishers will follow suit—but even if they don’t, eLife uses an industry-standard format called JATS (of course it’s XML-based), which should allow publishers to handle these sorts of documents even if they don’t support the full suite of in-browser code execution capabilities that eLife does.

eLife is also working on better support for converting from Jupyter and RMarkdown to DAR (their document archive format). Kudos to them for supporting the literate programming technology the community is already using, rather than trying to force authors to use something else.