I’ve run into an issue with a little portable music player I have – it doesn’t make reasonable assumptions about the order in which to play the tracks of an audio book. Even when the files are named sequentially with numbers, when the timestamps are in the order they should be played back, when there are valid and correct track numbers in the ID3 tags, and regardless of the order in which they are copied to the device (corresponding to the order of their entries in the filesystem lookup table), they always play in what seems like random order (this doesn’t happen with music, which works as one would expect). I’ve found that the easiest solution to this is to just wrap them up into a single large MP3 that contains the whole book. There are many ways to accomplish this, and here I’ll show a tool called mp3wrap that worked simply and reliably for me.
I recently had a need to set up donation functionality on a Shopify web store. Shopify provides a great method for adding donations to the shopping cart, but I found one aspect of functionality lacking.
Because the donations are implemented as an arbitrary number of a 1 cent donation item added to the shopping cart, if the user gets back to a page where the number of items in the shopping cart is displayed (like in a widget in the header), the number shown will be the number of items in the cart, plus the number of cents being donated. Our desired behavior was to have a donation represented in this total as a single item, regardless of the amount.
When setting up accounts or handing out my email address, I use a catchall on a different domain I have, giving a different mailbox to each sender. So, for instance if I give my address to Bob’s Cream Puffs to get a coupon, it might be email@example.com. You can do this with a normal (non-catch-all) address too, by using the plus sign after the mailbox name. In my case, that would be something like firstname.lastname@example.org. That trick even works with GMail and a number of other web services.
The Arduino EEPROM library provides the read() and write() functions for accessing the EEPROM memory for storing and recalling values that will persist if the device is restarted or its operation interrupted. Unfortunately, these functions only allow accessing one byte at a time. The float, double (the same as float on most Arduinos), and long data types are all four bytes long, and the int data type is two bytes long, the same length as the word data type. Some trickery is needed to easily store and recall these values.