Archive for July 21, 2023

Friday, July 21, 2023

A Fast Timestamp Parser in Swift

Juri Pakaste (Mastodon):

It’s well known that DateFormatter, the main timestamp formatter and parser Apple ships in Foundation, is not particularly fast. It’s flexible and it’s correct, but it takes its time. The newer ISO8601DateFormatter has similar performance.

[…]

Swift’s C bridging is first-class; struct tm and timegm(3) are right there. After changing the code to use those, the whole String to Date conversion runs completely without heap allocations and it’s around 6–7 times faster than when doing the detour via DateComponents.

The final result, according to Benchmark, is maybe around 15x the speed of the Foundation parsers. I’m pretty happy with it. It’s available as a Swift package, there’s documentation, and if you need something different or don’t feel like using a package, all the parsing code is in just one file you can copy over to your project.

You can set set it as a JSONDecoder.DateDecodingStrategy.

Previously:

Better Medication Tracking

Dr. Drang:

Slight differences in color, which could be very helpful in distinguishing pills that are otherwise similar in size and shape, just aren’t available in the app. I don’t get why Apple doesn’t let you just take a photo of a pill and use that as the ID.

Another deficiency is that size isn’t included as part of the visual ID. While I understand Apple’s reluctance to ask its users to measure their pills (something I’d do readily, but I’m weird that way), there’s no question that people use their pills’ sizes to help distinguish them.

[…]

There are several advantages to using the organizer, but the main one for me is that it’s self-documenting. Because I leave the lid open, the organizer itself provides a record of whether I’ve taken today’s pills or not. This is true automation, something I doubt the Health app will ever equal.

Previously:

Update (2023-07-25): A. Lee Bennett Jr.:

I just wish Apple Health had a means of tracking remaining pill quantity the way Mango Health did, which I still use, but it’s been abandoned and is showing early signs of breaking.

Kᑐᑌᑐᕮ:

I noticed another bug:

  1. Use 2 Apple Watches: 1 during the day, 1 for sleeping.
  2. Turn the Watch you’re NOT wearing off
  3. So, when you switch watches, and turn one off and the other one ON, after a while you get (duplicate) notifications with all that days Medication reminders (which you had already taken) AGAIN a second time 🤦🏼‍♂️

Advice for Operating a Public-Facing API

Joshua Stein:

Serve your API at api.example.com, never at example.com/api. As your API’s usage grows, it will expand beyond your website/dashboard server and need to move to a separate server or many separate servers. […] Your API may also have more relaxed security restrictions in terms of TLS versions and ciphers accepted that you don’t want to relax on your dashboard website that handles sensitive information.

[…]

Rather than bending over backwards trying to support poorly written code, don’t let their bad code function properly in the first place so it doesn’t get deployed.

[…]

With OAuth your API can’t be used from a simple curl request but has to be a custom multi-step process pulling in a whole OAuth library. Use static API tokens if you can, but make it easy to rotate them.

[…]

[Generate] a unique ID or UUID with every request, return it to the user in the message body somewhere, log it, and ask for it on your support form.

[…]

[Use] a short prefix for each type of random ID you create.

ABC C Compiler

Tom Murphy (PDF, via Nicolas Seriot):

Since only 37% of bytes are printable, if you inspect (i.e., “cat”) an executable program, it will almost always contain unprintable characters, and may beep at you, etc. However, since the printable bytes do stand for some subset of X86 opcodes, it is technically possible to make X86 sequences that are printable. One famous example is the EICAR Test File[…]

[…]

Most damningly, like many viruses it uses “self-modifying code” to first rewrite itself into different opcodes. This means that the processor ends up executing several non-printable opcodes. This is like telling the waiter that you don’t eat poultry but eggs are okay, and then they bring you an egg, but that egg hatches into a chicken right after they bring it to you. Come on.

[…]

In this paper I present a compiler for the C89 programming language called ABC. It produces completely printable executables from C code. While self-modifying code is a powerful technique, it makes this problem “too easy;” I want to explore what programs can be written natively in the printable subset of X86. Programs compiled with ABC do not modify themselves, or cause themselves to be modified; every instruction program executes (outside of the operating system) contains only the bytes 0x20-0x7E. Moreover, every byte in the file is printable, so programs can viewed as text.

Source code for this project is available at: http://tom7.org/abc

Tom Murphy:

But I also created the following video that explains the ideas involved, for interested non-experts or patient experts.