Programming Leftovers

posted by Roy Schestowitz on Sep 12, 2023

• First Publicly Available R-Based Submission Package Submitted to FDA (Pilot 3)

  The pilot 3 test submission is an example of an all R submission package following eCTD specifications. These include the installation and loading of the proprietary {pilot3} R package and other open-source R packages, R scripts for the analysis data model (ADaM) datasets from pilot 3 and tables, listings, figures (TLFs) from pilot 1, analysis data reviewer’s guide (adrg), and other required eCTD components. To our knowledge, this is the first publicly available R-based FDA submission package, which includes R scripts to generate ADaM datasets and TLFs. We hope this submission package and our learnings can serve as a good reference for future R-based regulatory submissions from different sponsors. Additional agency feedback will be shared in future communications. [...]

• Porting my Mac ROM SIMM programmer from AVR to ARM

  Long story short, I was able to get the firmware working with the AT90USB1286, but it was more difficult than I thought it would be. For some strange reason, the 646 and 1286 have a subtle difference other than the flash size: the USB PLL bits have different meanings. Debugging this remotely without hardware of my own was “fun” to say the least, but I got it working! (Will offered to send me one, which was very kind, but I declined and later built my own.) I was able to automatically detect the chip type at runtime so that the same firmware binary could be used on both variants.

• The Low-Hanging Fruit

  Finding the “low-hanging fruit” is not only the most straightforward plan, but it’s often one of the most effective. Continuously executing against the obvious plan gets you much further than you’d think.

• A systematic approach to debugging

  I've got a reputation at work as being a skilled debugger. It's a frequent occurrence that the weird stuff lands on my desk1 after it goes through another skilled engineer or two. To say my job is substantially "debug the weird shit" would not be an understatement and I'm here for it.

  This extends throughout our codebase, and into code I haven't seen before at all. I'm the longest tenured engineer at my company, so I'm familiar with most of our systems. But I've lost track of most of the features that get deployed, and we have way more code changes than I can personally review. And my debugging spans the stack: backend to frontend to database to weird Ubuntu behavior on our dev laptops. (Yes, our principal engineer also does tech support, and again, I'm so here for it.)

  So... How do I do it? If I'm presented routinely with bugs I'm expected to solve in systems I'm unfamiliar with, what's the process? And does it extend to things outside of code?

• How to add pledge to a program in OpenBSD

  This article is meant to be a simple guide explaining how to make use of the OpenBSD specific feature pledge in order to restrict a software capabilities for more security.

  While pledge falls in the sandboxing features, it's different than the traditional sandboxing we are used to see because it happens within the source code itself, and can be really tightened. Actually, many programs requires lot of privileges like reading files, doing DNS etc... when initializing, then those privileges could be removed, this is possible with pledge but not for traditional sandboxing wrappers.

• Please don't write application launchers in `sh`!

  Thus, just like I've done a few years ago with Erlang, I'll try to write my own erl and iex launchers in Rust...