Andrew B. Collier / @datawookie

No two email clients are equal. Nowhere is this more true than in the way that they treat images in HTML messages.

I’m using the source for GPXSee to figure out some details of the QCT format. The build instructions in the README are somewhat terse. Here are more details.

I’ve got a stash of old (2004 vintage) UK Ordnance Survey maps. They are really works of art and the folk at the Ordnance Survey should be commended on the level of detail embedded in these maps. There’s just one small snag: the maps are in a rather obscure format. The proprietary Quick Chart (.qct extension) format is intended for use with Memory Map navigation software. If you want to use these maps for other purposes then you are stuck.

In a previous post I documented what I had learned while trying to understand the structure of encrypted emails. I then took an informal Twitter poll to gauge how many people are using encrypted email messages.

I’m adding encrypted message support to the {emayili} package for sending emails from R.

At Fathom Data we have a number of workflows that require us to share various bits of data for a short time. The data are not sensitive, so we can freely share them. We have been doing this manually via platforms like Google Drive, Box or Dropbox. However we need to remember to go back and delete the file some time later. This is not ideal. What we needed was a simple “fire and forget” solution which would allow us to share the files and they would disappear automatically after some time. Well, this is precisely what Filebin does.

Peer-to-Peer (P2P) cryptocurrency trades occur directly between two parties without a central authority (like an exchange) being involved.

The shared memory device, /dev/shm, provides a temporary file storage filesystem using RAM for storing files. It’s not mandatory to have /dev/shm, although it’s probably desirable since it facilitates inter-process communication (IPC).

In previous posts we looked at creating market orders and limit orders with {binance}. We saw a couple of successful trades. However, sometimes trades are not successful and the orders are not filled. Let’s try to understand why.

Memory is something I generally don’t worry about when working with Docker. It just works. This is great… but what happens when it doesn’t?

In the previous post we looked at creating market orders on Binance using the {binance} package. Today we’re going to dig into limit orders.

Functionality for working with spot trades is now available in {binance}. In this post we’ll establish some background on spot trading and then explore some related functions.

Dust refers to the fragments of coins which are too small to use for transactions. In the fiat world the equivalent would be those worthless coins with too little value to actually buy anything, that take up space in your wallet and end up scattered across parking areas.

Binance allows you to convert dust into BNB. In this post I discuss the functions in {binance} which support this operation.

I’ve got a bit of dust in my wallet.

I started dabbling in Crypto trading on Binance at the beginning of September 2021. I am really impressed with the interface, which is smooth and full featured (if perhaps a little complicated and confusing!). One of the things that has frustrated me though is not being able to get an idea of whether I’m making progress. There’s no view which shows me the overall status of my account and how this has evolved over time.

Fathom Data has been doing a lot of work with the HCRIS (Healthcare Cost Report Information System) data. The underlying reports are submitted as a spreadsheet with multiple sheets. The data are then extracted and recorded in a simple tabular format, with each field linked to a worksheet code (wksht_cd), column number (clmn_num) and line number (clmn_num). These three keys are then mapped to a single compound key. The resulting data look something like this:

Being able to view related messages as threads is really useful. To make this possible, messages must use either the In-Reply-To or References header field to link to the Message-ID from another message.

This is now possible in {emayili}.

The {emayili} package supports configuring a generic SMTP server via the server() function. In the most recent version, v0.6.5, we add three new functions, gmail(), sendgrid() and mailgun(), which provide specific support for Gmail, SendGrid and Mailgun.

If you pull back the curtain and take a look at what a naked email looks like, then you might be astonished.

Sometimes you need to have a message delivered immediately. Other times it doesn’t matter when it’s delivered. Similarly, you might want the recipient to read a message immediately. Or you may not really care when they read it. The ability to specify message priority and importance in {emayili} has been added to address both scenarios.

library(emayili)

packageVersion("emayili")

[1] '0.6.1'

Importance

The Importance header specifies how important a message is (surprise!). It reflects how important the sender thinks the message is, which might not necessarily agree with the recipient’s opinion. According to RFC 4021 this (optional) field can assume one of three values: low, normal or high.

How can you be sure that the contents of an email haven’t been tampered with? The best approach would probably be to have a digital signature on each component of the message. Perhaps I’ll look at integrating that into {emayili} some time in the future. However, today I’m writing about the first step in that direction: MD5 checksums.