Max Masnick

Last summer I wrote about the lack of real alternatives to Google’s reCAPTCHA service for preventing bots from interacting with websites. I personally use a captcha on my contact form to reduce spam.

Recently I heard about hCaptcha from Cloudflare’s post on switching from reCAPTCHA to hCAPTCHA. It appears hCaptcha is a more or less drop-in replacement for reCAPTCHA. I have personally been trying to move away from Google’s services as they adopt more creepy data collection and sharing practices, but was stuck with reCAPTCHA until now.

I’ve moved my contact form to hCaptcha, which is powered by this simple Ruby application that can run for free on Heroku.

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.