Monday was a public holiday in the US. That gives us a day to catch-up on internal tasks and personal projects.

We’ve been deep in C++ for the ESP32 microprocessor to control the LED lights. After constantly hitting walls, back tracking and trying another approach, we’re finally in a good spot. Every light combination we need is programmed into the system and the firmware is firing on all cylinders!

Wednesday we had both a Nintendo event. Which we are keeping closer eyes on and the bug annual Apple event. This year we got the expected barage of new iPhones and Watches. This year we got the new iPhone DUO. Time will tell how that all shakes our and how it impacts developers. For years people designed for a specific height and width and argued about “above the fold” and with every new device we get a new size ratio.

To us, there were a few items in the presentation that felt strange or awkward. A while ago we wrote about the Blind Men and the Elephant. I fully believe we say some things in their presentation which are meant not for today, but for some future hardware.

On Thursday, we published a bit more about our backup scheme, specifically how we’re handling some backups of database backups. We identified a potential issue and plugged the hole to prevent accidents.

With the publication of the iOS/macOS/Xcode 27 Release Candidates, we updated everything and got a chance to experiment with some Gaussian Splats. These are now first-class file types and we have libraries to natively load and view the output.

There is the concept of Quiet or Ghost Quitting, where someone no longer responds or shows-up. We’re a bit on the opposite end and have a Ghost Firing. We’re on a project, but can’t get any meetings booked and the weekly sync has been cancelled. We’re here and ready, but the customer seems to have second thoughts, but doesn’t want to pull the plug (yet). We’ll see what the next weeks hold.

Week #814

This week we started off with a remote visit for the LED project. We uploaded our new software to the microcontroller and it worked flawlessly! Of course the model makers had changed the LED count, so we had to change the software. Somewhere along the way the ESP32 died. We had a backup and flashed that one and did a quick test and it worked, but now we need to unsolder a bunch of connects on the old board to the new one and split the LED strip into two universes. On Thursday, we went back and confirmed all the updates with the architect.

We continue with updates to an old survey. We’re trying our best to extract ourselves from this project. We’re no longer dealing with any other projects around health data and our school surveys are getting more focused. We told the customer this a few years ago, but the transition is a slow one. We are JUST ABOUT at the finish line. We’ve updated the code libraries and login method, now we’re making the last of the question and text tweaks. Then we really want to hand this over to their new tech team.

On Tuesday, we had a meeting for another project. We met with the architects and design teams to go over the software, workflow and other image rendering requirements. Off the back of that we had to make a few tweaks to our software to fix some bugs and new ideas that came up in the meeting.

We also managed to have an online meeting with an old friend in Lisbon to hear what he’s up to.

Overall, these last two weeks we touched eight or nine different projects over ten (realistically nine) work days.

• Backups
• Backups 2.0 DAS Edition
• Backups 3.0 Remote

Most recently we did some database maintenance on Heroku. This is pretty straightforward as Heroku handles a lot of the heavy work for you. Periodically, we need to upgrade the database version or migrate to a larger database as needed.

As part of their database package, you can set up both manual and automatic backups. These are saved to an S3 bucket associated with your database instance. Every time we need to make a change, we make a manual backing-up. There is also an automatic, nightly back-up when the server is quiet.

During one maintenance phase, we were working to upgrade the database, but accidentally pressed the delete button. Luckily Heroku has a nice double confirmation so you can’t delete something that you’re not supposed to by accident. This got us worried, because had we actually deleted that database, all of the corresponding backups would have also disappeared. This is a very bad single point of failure. Having both the database and the backups so easily destroyable was something we needed to guard against.

This also doesn’t need to be malicious. Accidentally deleting a database is possible, so is forgetting to pay the credit card bill or update it when it expires. Heroku might quietly terminate all of our services and along with that we would lose all of our backups!

We set out to at least get a copy of those databases somewhere not inside Heroku’s control. Luckily the Heroku command line gives us a few tools to do this. We can get the most recent Postgres S3 backup URL and we can get the Postgres URL directly.

Our goal was to build a script which could save the database offsite in case something catastrophic happens. Rather than use the existing S3 backup URL we decided to fetch the Postgres database dump directly. (To make use of the Heroku CLI tools, you need to be logged in and that wasn’t going to be possible, so we saved the direct Postgres URL instead. This does periodically change, so we need to be aware of the fragility.)

For now, we setup a few different CSV files with the service names and the Postgres URLs. A bash script was created to run pg_dump looping through the corresponding csv file. Each row creates a database dump with the service name. We can direct that output to our DAS system. Once it is put onto a drive, that flows into our existing system of an additional nightly local copy and remote copy.

Using the same script, we can pass-in different target folders so we can separate the dumps by company, project or service. This also allows us to create a series of cron tasks that run at different intervals. For instance, some surveys only run for 1 month, so there is no need to be backing these up nightly the other 11 months of the year! The same is true of our reports server, we publish reports usually at the start of the month for the previous month’s results. Having that pull a remote backup once a month in the middle of the month is probably the most sensible. Especially since the DB size is pushing 3 GB.

Also, since these commands are all listed in the crontab, we can manually run the same command if we can’t wait for the next backup cycle to occur.

For some customers and internal projects we use our own 3-2-1 backups system. For others who are concerned about GDPR and sensitive data, we can save the database dumps to their network drives and let them handle the data.

It is a flexible system, which does require us to save the login strings, which periodically change. We’ll see how much of an issue this becomes as we implement the system.

We are constantly finding loop-holes, like these Heroku backups, but close them each time. We continue to iterate and improve on our backup setup and with each step, improve our piece of mind.

This week summer seemed to have abruptly ended and fall/winter has arrived. We’ve moved back into work mode and started to run.

This week we continued to debug some of the WebRTC issue reported. The client was complaining things were moving slowly, so we offered to have more frequent, shorter check-in meetings. Everyone agreed, and then it hasn’t happened for 2-3 weeks. When we get bug reports, we try to fix them quickly and ask for a meeting so we can iterate, but no reply.

On the LED front, we’re continuing to debug, iterate and fix minor issues with both the microcontroller software, but also the iPad app that sends the commands for which LEDs to light-up. We’re very close and the deadline is looming. Some of the team in NYC goes over to the model maker’s office and we have marathon video calls to work through and debug any issues in real time. As they continue to wire and re-wire, we seem to take a few steps backwards. Hopefully by next week, we wrap-up everything.

On Thursday, we published our article about UK Public House names. This was a side-quest that was spurred on by a throw-a-way comment on a podcast we were listening too.

(You can tell we’re avoiding real work) We also sat down and re-created a test stereogram (those magic eye posters from the 90s). The images in those posters were always dolphins, cubes, landscapes, etc. We wondered how to construct our own and if it was easier 30 years later? It turns out, it is pretty easy, but the subject matter and composition are key.

There are plenty of websites to help you make stereograms. Usually you just need a depth map of the image. It then uses a noise pattern and that depth map to make some offsets in the final output. Previously, to make those depth maps you needed to make some 3D objects in software and then position a camera. It wasn’t trivial and you needed to recreate everything you wanted in your picture. Fast-forward to the 2020s and you have smart phones with LIDAR that produce depth maps with your portrait photos! It is pretty easy to extract those black and white depth maps, so we did.

Friday we continued to do some digital house-cleaning. We also had a meeting about the WebRTC project and we continue to find small bugs, but have shifted gears a bit back to using Apple Continuity Camera rather than our own home grown WebRTC version (for now).

On the PETALS project, we added Lemon Squeezy as our checkout/payment system to take subscriptions. There is a free trial when you sign-up so your credit card only gets billed after 7 days. Low-and-behold, that’s a boon to credit card fraudsters. We’ve got endless fake sign-ups over the weekend. They obviously have a list of stolen card numbers and need to test to see if they are still active or not. If they do that on a large retailer like Amazon and the card is already blocked or marked as fraud that’s problematic. So they first find a service that has a free trial – like PETALS and run the card to see if it is valid. If it is, it hasn’t been charged and thrown-up any flags (yet), so they know they can use that valid, working card at other retailers immediately. We’ve been playing whack-a-mole with them all weekend, but the way lemon squeezy was originally setup by us, that makes it very difficult along with invalidating all these fake purchases to now ruin our charge-back reputation. Good times.

Week #812

This week we properly started a bunch of new surveys and are gearing up for more in October and November. As part of that process we continue to improve our backups. We found some weak spots and fixed it with redundancy L-O-C-K-S-S (Lot of Copies Keeps Stuff Safe). We have a draft article outline all this in more detail.

We continue debugging some of the WebRTC code and also the LED code. Things are in a good place, but (as always) it is hard for us to debug in real-world situations. The WebRTC echo is partly due to geography and network latency, VPNs can help, but real testing is always best. On Tuesday, we were told by the client to stop working on it. They are getting cold feet, so we feel this project has run its course. Our normal Friday meeting was even canceled.

The LEDs are a similar story, we have a roll of 300 LEDs to help us test, but the final product has 15x so we test in parts where we can and then try to integrate everything and work with the New York team to test.

For the old Spellstruck project, we were originally call upon to help with the analytics, but idle hands are the devils work. While we waited for everything to get instrumented, we helped with the push notifications. That meant dealing with certificates, AWS lambda functions and simple queues. Which now is partly our responsibility to update the certs annually and keep the code versions up-to-date. This week we had to migrate the Heroku Postgres database from version 15 to 18. We ran the tests, add the follower, let it all sync for a day, then put things into maintenance mode and did the swap. It’s not difficult, but can be stressful if something goes wrong.

Using cloud services is great, but they periodically end support for software versions you are using, so you need to go back to things that work just fine, upgrade them and potentially introduce errors.

For yet another project, we are getting into the HubSpot API. We have various forms to collect information at the top of a sales funnel. To start with, we just want to capture that data and organize it into various models in HubSpot. Once the data is correctly flowing in, we can start to do some smart stuff with it.

We’ve heard the trope that all the pubs in the UK have either an animal, plant or body part in their name: The Red Lion, The Pear Tree, The Athletic Arms. The Three Horseshoes fit the template. But how true was it?

Step 1: Find the Data

We needed to find a decent list of UK pubs and it turns out that you can download a CSV of 50,000 registered public houses. This is a list from 02024, so your favorite place may or may not have made the cut. Also, what a company trades as and what’s on the door are not guaranteed to be the same either.

Using: https://www.getthedata.com/open-pubs we downloaded the list of pub names. The CSV contains a list of names, addresses, post codes, cities, and additional columns. All we were concerned with was a list of distinct names and their frequency.

That was pretty easy to do, but we quickly spotted some problems. Was The Fox and Hound the same as The Fox & Hound or even Fox and Hound?

Step 2: Data Cleansing

Now that we had the list, we needed to normalize it and collapse similar names. Ignoring the capitalization Fox and Hound versus Fox and hound we quickly did some find and replacing on punctuation, spelling and removed (at the …) and (Bar Only), Ltd. and a few other common strings. Since we knew this was going to be an alphabetically sorted list, we also moved any “The XYZ…” to “XYZ…, The”. The final output is much easier to search and browse manually.

This collapsed the list from around 50,000 pubs to around 27,500 distinct names and their corresponding frequency.

But that’s all the pub names in the UK, we are only interested in those with animal, plant or body parts. We made a big list of words and went through each of the 27,500 and tested to see if they contained anything in our list. That got us down to about 10,000 rows or 1 in 5 pubs in the UK contain the trope. When we counted those names by frequency we had 3,000 rows of distinct pub names and their frequency count.

Step 3: Curation

Now that we had only 3,000 rows to review, it made things easier to go over manually and curate. Our goal wasn’t a comprehensive list or any exact numbers. At this point we just wanted a list of real pub names you might find when you needed to make-up a quick name for a pub in the UK. The Quill and Porcupine, The Dragon’s Arms, The Bear and Boar.

Sorting the list alphabetically and browsing through we found some false positives: John Bull Inn, that’s a surname not directly an animal reference. So we remove those. We also found lots of White Stag at the XYZ usually the city name. We further collapsed those into just White Stag, similar for some chains: Slug and Lettuce / X / Y / Z was very common where they seemed to be paired with other restaurants, again we just collapsed those down to Slug and Lettuce.

After reviewing that list a few times, we were happy with what we managed to curate. The next step was to put it into some chapters and columns with some nice headers and engraving images to make a nice book from this work and research.

Step 4: Stats

When we sorted by frequency we got the top 50 common UK pub names with an animal, plant or body part in the name.

1. Red Lion, The
2. Royal Oak, The
3. White Hart, The
4. Swan, The
5. White Horse, The
6. Rose and Crown
7. Wheatsheaf, The
8. Black Horse, The
9. Greyhound, The
10. White Lion, The
11. Coach & Horses
12. Three Horseshoes, The
13. Fox and Hounds
14. George & Dragon
15. Black Bull, The
16. Bull, The
17. Bulls Head, The
18. White Swan, The
19. Fox Inn, The
20. Golden Lion, The
21. Nags Head
22. Lamb Inn, The
23. Horseshoe, The
24. Black Swan, The
25. Cock Inn, The
26. Bay Horse, The
27. Beehive, The
28. Eagle, The
29. Horse & Jockey
30. Barley Mow, The
31. Grapes, The
32. Griffin, The
33. Horse and Groom
34. Dolphin, The
35. Green Dragon, The
36. Vine, The
37. Black Lion, The
38. Woolpack, The
39. Shoulder of Mutton
40. Slug & Lettuce
41. Stag, The
42. Lion, The
43. Talbot, The
44. Bear, The
45. Bird in Hand
46. Pheasant Inn, The
47. Cherry Tree, The
48. Peacock, The
49. Falcon, The
50. Phoenix, The

First place was The Red Lion with ~450 pubs using that name. In second was The Royal Oak with ~350. Third was The White Hart with ~230 and continuing to drop to a long tale of names.

In 12th place The Three Horseshoes! It turns out to be a pretty common name for a UK pub.

If we break it down by what terms the pubs fell into (and they could be in multiple) we can see that Animals are by far the most popular in names.

Since public houses in the UK date back centuries, their names are often hold-overs from another era. Many of their early patrons were illiterate, so using commonly recognizable symbols were more important than how the pub name was spelt.

Step 5: Publication

Now that we have the curated short list of names, some interesting stats we decided to do something more than just this article. We created several printable publications for anyone to use as an interesting reference.

First we copy and pasted the full comma separated text from the most frequent name to the least into a document. It was noisy, cluttered and un-organized. It made no sense to look-up words or find anything. We sorted the words alphabetically, broke them into logical chapters based on their first letter (where we also moved “The” to the end of the names), and put one name per line and made each page two columns.

This was much easier to read, but it still felt very utilitarian – like an ancient pub phone directory. To solve this, we added some illustrations to try and match some of the animals and plants references. This broke-up the text and filled in some blank space. Luckily, there is no shortage of public domain engravings! After an afternoon of figuring out some layout we found plenty of images to fill the gaps.

We made a few different A5 PDFs that you can download and print at home.

• pub_names_A5_booklet.pdf A5 (9.5 MB)
• pub_names_A5_booklet_spread.pdf A4 (10.6 MB)

You can also purchase a 42 page book on Amazon’s using their print on demand service.

• Dictionary of Pub Names Amazon US ($8)
• Dictionary of Pub Names Amazon UK (£6)
• Dictionary of Pub Names Amazon IE (€7)

Conclusion

It’s funny how some small, one off-comment in a podcast can lead down a path of data scraping to publishing a small book.

We hope you enjoy a look into our process, inspiration, thought process and publication.

Cheers, Iechyd da, Slàinte Mhath!

Let’s VR like it’s 01995! We picked-up the Nintendo Virtual Boy faux-headset. This is really a box with some lenses that takes a Switch running the Virtual Boy emulation software to make a left and right channel for each eye to create a stereoscopic, 3D view.

The results are exactly what you’d expect, it feels like 30 year old VR technology. There are only 16 games out of the 22 ever released and they certainly feel their age. It is a great, fun experience and some interesting early experiments.

For some Australian projects their CFO reached out and asked for a data dump. They are reviewing the last 3 years worth of jobs, costs and invoices to see where they made money and were they lost as a general review of the company. Most of this data was easy to export from both our database and Xero. The slightly trickier part was merging the two. Sometimes an invoice was connected to a few small projects in our system, or a different enough name that we couldn’t with confidence match it. Now it’s up to them to do the harder business logic and find the good, the bad and the ugly.

Our WebRTC project is coming back.

Wednesday was the Solar Eclipse here in Reykjavik. Not much got done that whole afternoon. It was quite overcast and raining, but it did get dark for a few minutes as we passed through the moon’s shadow.

On Friday we published an article about our Newsletter Badges. We are experimenting with custom, dynamically generating SVG/PNG images for our newsletter subscribers. If you already subscribe, expect a little something extra next quarter.

Week #810

Surveys are now back in full-swing! We started a “one-off” survey project as part of some research at the University of Iceland. We did something similar a few years ago which resulted in an academic paper (You can read it online in Icelandic) It focused on the deteriorating reading levels in young Icelandic students and how home-reading was the proposed solution. The paper looks at the efficacy of the intervention. Now, we’re back looking to Peer-Assisted Learning Strategies (PALS). We have a long survey which teachers take before, during and at the end of the intervention. Then a much shorter survey which is answered weekly about the type and amount of PALS that week.

Our WebRTC project gave us a kick in the gut this week. It always worked when we tested in the office, but when trying to connect to a remote participant it failed. At first we thought it was our code, but it turned out to be an issue with the STUN/TURN servers. Once we switched the info and made it dynamic and not hard-coded in the app, we could move forward again. The regularly scheduled Friday meeting was cancelled – which is annoying. The client feels things are taking too long and behind schedule. They do take a long time for several reasons; we only work on this 1 day a week, it’s been summer, we got stuck on an echo issue, and meetings always get cancelled so it’s then 2-3 weeks between reviews. We offered to have them more frequently, but it doesn’t fit their schedule.

We met with the our contact to test our LEDs and it was a bit of a disaster, but we learnt a lot and quickly adapted. As it turns out, we’ve very rusty when it comes to soldering! On Thursday we did a bunch of software and hardware tests and on Friday it’s back to our contact to try it all again.

Our todo list is long and grows longer by the day. What tends to accumulate are ideas for things, big and small, that we’d like to try and prototype. Those get pushed down the list when deadlines are looming. We’re really hoping to get through a few tasks in August and in September, free-up some time to explore.

During the week we were listening to a podcast and a throw-away comment about the name of a British pub sent us down a rabbit hole. Pretty quickly we found the data we wanted, created a prototype of our idea and made a physical printout. Time to review and refine.

Bric-à-brac

This week we learnt about Hafrún (Ming Clam) a clam that was dredged-up around Iceland that turned out to be 507 years old, oldest individual (non-clonal) animal ever discovered whose age could be precisely determined.

Did we mention we have a newsletter? You can subscribe here: https://optional.is/newsletter/subscribe

If you want your own personalized badge you need to be a subscriber!

The badge needed to grow over time to include more and more items the longer you were a subscriber. We wanted it to both be Icelandic but also heraldic.

As part of the mock-ups and design, we had the banner which in heraldry holds some sort of motto. We repurposed it as the year you subscribed. Later we changed that to be a sort of mini-inventory of special achievements.

Currently, we have two achievements: Material Conference supporter and Alumni/Co-Worker.

Back in 02016 we planned to have our first Material Conference. We tried to kickstart it, but the campaign didn’t get enough backers. We subsequently had an event in 02017, 02018 and we planned for 02020 but it was cancelled. If you attended, backed, or spoke at any of these four events you get an M on your badge. We have everyone’s email, but matching them to subscribers in the database is hit-or-miss, so if you think you should have this achievement, but don’t, let us know.

The other is a small star for alumni/co-worker. We’re taking a very broad definition of alumni/co-worker. Obviously, we worked at the same company or you paid us or we paid you, it’s pretty clean-cut. Other situations include volunteer projects, open source projects or one-off special events. We considered those (as we remember them) in this definition too. If you think you should have a star, remind us why and we’ll add it.

Over time we’ll add more achievements as we can think of them or justify their existence. They shouldn’t be impossible, but also shouldn’t be simple either. The achievement designs are unlikely to evolve over time or be affected by your subscription date.

To keep the badges changing everything without re-inventing the entire design, we settled on a five-year cycle. Every fifth year, you get some upgrade. In year one, you start with a basalt column. For the next four years, one start is added. On your 6th year, you get the banner and the stars reset. The four following years are stars again, then on the 11th year you get the supporters. We reset the stars every 5 years and then count-up again. On the 16th year the supporters change color, on the 21st year the basalt column changes colors. Luckily, no one has been subscribed for more than 16 years. So we have 10 more years to figure-out what happens next and if this is worth continuing.

You can visit the newsletter badge website now to check what each year looks like as well as paste-in your email address to see your current badge, or sign-up to start. The link to your custom badge is pretty simple. It is a dynamic SVG that take your email address as a query parameter. We’ll use this in the footer of future email newsletter templates. Even if you revisit older saved newsletters, the image will be reloaded and show you the most current design.

Our WebRTC project has somewhat stalled. We meet normally on Fridays, and the consensus is that it’s moving too slowly between bug reports and fixes. We proposed to meet on Wednesdays for a short time, then Fridays to organize priorities. This week, they cancelled the Wednesday meeting (not sure why), then last minute cancelled the Friday meeting. Which is annoying because we spent some time over the previous weekend and Tuesday night to fix the immediate issues for review. Now we’re another week to two weeks behind.

This week we’ve flashed the firmware on more devices, more times than we’ve done in the last few years combined. Two projects needed to update hardware. One being some security cameras, the other is an ESP32 to control some LEDs.

The LED project continues, we’re trying to get any sort of feedback from the model builder about how they have installed the LEDs and what we can expect. We need some sort of ballpark on how many LEDs are installed, which impacts the power consumption and how many lines/universes were created, which affects the software an the pin connections to the ESP32.

As part of the survey research company our current CEO is taking a leave of absences for health reasons. The rest of the team will setup and we’ll shuffle some responsibilities around, but it does mean both some extra work for us and also no new developments for the next school year.

On Thursday we published an article about another internal app Rest Music. We’ve made it public, it is our music app for the rest of our collection.

As another late-night side project, we attempted to make a new camera app. We have a really good framework for experimenting with camera apps for the iPhone. In photography there is a concept of “Color Splash” where only 1 part of the image is in color and the rest is in black and white. It is completely possible todo this in post-production, but we really like the idea of producing these effects in camera so you can better frame your shot.

Color Splash Camera was born. You can select a color hue range and in real-time, remove the saturation from all the pixels not in that range. It isn’t perfect, but as a first pass it works incredibly well.

Week #808

Monday was a public holiday in Iceland.

On Tuesday, we had a few meetings and started more planning. One project is now “un-officially” wrapped-up. The fixed we’re doing on the front-end are very minor.

We also got an update on our LED project. We’ve spec’ed out some hardware and software with our 300 LED test. Today we got an updated on roughly the number of LEDs to expect and it is 1.4-1.5 orders of magnitude more. It’s not unconceivable we can handle that on the software side, but we need to go back to the drawing board on how we’re going to power and connect all these lines/universes. On Friday morning, the LED count was back down to only 1 order of magnitude more. Still no idea how many lines, but we’ll get those answers soon.

It is August now and we’re oiling the machine and starting to turn the cranks to get the school survey system back up and running. Over the summer we added a few new features, updated the libraries and conducted general maintenance. Now it is time to deploy these changes and start to lockdown the releases before customers start using it.

Along with our regular bank of surveys, we have an extra one we’re adding for a customer. This is very basic, but unique in that instead of test months, they need test weeks. It will be highly compressed schedule for the whole school year.

On Friday we had a meeting about another project we’re trying to wrap-up. The client is hung-up on one tiny aspect, it is an important part of the product, but it is solvable in the long term. We convinced them to table that issue so we can work through all the rest in the meantime. That seemed to work and we’ll continue testing.

Bric-à-brac

We were outside the office in downtown Reykjavik this week. We’re right under the flight path for the downtown airport. We got buzzed by the Red Bull Flying Bulls P-38!

The P-38 is a very rare WWII plane worth millions of dollars. There are exhibitions to Greenland to try to dig out the ones that crash landed. No matter what the cost of the salvage it’s worth it.

The major downsides of ‘renting’ your music is that the current payout for artists is pretty bad and if you like something you need to pay for it. The current situation isn’t sustainable. The second issue is censorship/curation. Maybe your favorite track doesn’t exist on any streaming service, or it is a crazy DJ mashup or live recording? Thirdly, you are relying on streaming gatekeepers for your access – if for some EULA reason they decide to cut you off, you loose access to everything and then ownership becomes more important.

We used to have loads of CDs and MP3s that we listened too that aren’t on any streaming service. (We have BBC radio episodes converted from RealAudio Streams!) To enjoy our old music library we needed a new music player that could play songs locally not streamed. If you search for “Offline music player” on the App Store you get plenty of results. Some are free, some are ad driven, some have in app purchases, others cost to download. Some look good, some less so.

As a programmer, we decided to make our own Offline music player that suited our needs and looked and worked as we wanted. (Sure it probably would have been cheaper to pay for several apps than spend a single hour of our billable time on it, but then you’d never learn anything). Besides, the world already has enough love songs, but musicians keep writing them!

To build the offline music player, we first made all the dummy screens we wanted with placeholder content. Next, we started to wire-up the connections to import, save and extract mp3 metadata. That replaced our placeholder text with real text. Then we actually got the music to play. Rinse, wash, repeat.

We’re happy with the app and how it is performing. Occasionally we find edge-cases and fix those bugs.

We called the app “Rest” since it is both the opposite of “Play” and a pun on “the rest of your music collection”. The songs that aren’t on streaming.

Rest Music App is a free download for iOS, so if you find it useful or find any bugs, drop us a line.

Offline Mode

When you talk about having all your music downloaded outside of the streaming service you think about offline mode scenarios like long flights where Internet isn’t available.

While that’s true, we find that Rest isn’t our offline music app, since you can take streaming songs offline too, it really is the “rest” of our music library that’s not available on streaming. That is more valuable than just being available offline.

Next Steps

To get better feeling for what a Music app should have, we aped the built-in Music app from Apple as our template. Much like Hunter S. Thompson typing out a few pages of The Great Gatsby to get the feel and rhythm, we needed to know the workings of a Music app before we start to go all free-form Jazz. Now that we have the ‘table-stakes’ in our working we can make it unique.

The playback queue could use some love. When you toggle shuffle it does a good job of randomizing, but when you toggle it again it doesn’t really know how to go back to the original order.

The Album artwork is only used as a display in playback. We can be more creative with what we have. Also our Playlist names and defaults when no artwork is available is simple some random gradient meshes. We should allow you to edit them if needed.

These are all points we’ll address over time with more feedback, but we’re happy with the app and are using it on a frequent basis. Now that more people are aware of it, download it and use it, we’ll incorporate their feedback as well.

We wrote about the Old Icelandic Month (kinda) of Aukanætur. This is a short 4 to 10 day week (depending if it is a leap week year) to keep the 12 months of 30 days each starting on the same weekday.

It was a busy week, we touched on 9 different projects, sometimes all on the same day. It can be very exhausting, especially when we assumed a few of these were finishing. We’re really hoping that it is a transition period where some will be ending, others ramping-up, because we can’t have them overlap for too long!

On the PETALS project, we found a bug that’s been plaguing us for a while. It was not code related, but DNS. To setup the CNAMEs on Heroku we use Cloudflare, but somewhere deep in their settings we also had something checked that would drop our x-headers when referring http to https causing some infinite redirects. For the longest time we had that auto-forwarding turned off. It works on the dev server and we were chasing ghosts for a long time on production. This week we finally pushed some Single Sign-On code for Google and Microsoft. Those required https and it worked on dev. When we pushed to production, it failed over and over. For days we reset API keys for the services, but it was never a code problem. Once we finally stumbled on the x-headers being striped, that lead us to Cloudflare. One checkbox later it was all working again as intended!

For other projects this week we had to create a Hubspot syncing script, flash some custom camera firmware to get GPS working, looked into Gaussian splats, had another secret meeting to discuss JSON and rendering that output in XR, fixing bugs in a WebRTC client – which will probably come down to noise cancelling, and cleaned-up some SPSS and CSV exports to better match real survey data instead of database columns.

In between all that, we managed to watch some of the World Cup games.

Week #806

This week we managed to only spread ourselves over 7 projects, down two from last week.

We’re really trying to wrap-up two projects. With one, we need to debug some WebRTC echos. The issue is that we use the phone as your camera and mic and the TV as the playback speakers. Of course we always tested with headphones, but now without we’re getting some echoing feedback. That needs to get fixed before the customer will test it all. Then we can get the last round of bugs, fix them, then re-evaluate our roll in the project.

The other we’re just trying to get some basic API stuff working with some hardware cameras. Somehow we got in the middle between the manufacturer and the team building the backend portal. We’re trying to get ourselves out, but first we need this API working to add one last small GPS map position to the app. Then we need to re-evaluate our roll in that project.

Internally, we managed to get a few things done. We continue to work on our Newsletter badges (more on that later), we created a script to create a random forest of trees based on the Isny designs by Oti Aicher and continued to update our suite of camera apps in preparation for iOS27. We added the ability to make them shortcuts on the Lock Screen. We’re still tweaking some icons, but expect an update soon.

We also continued with our LED experiments for a client project (more on that later). Our end is going well, but we’re coördinating with another company and it is hard to get a straight answer out of them! The only responses we get are things like “When it’s all wired-up, we’ll know how many LEDs and lines we used”. Which makes it hard to plan for the power supply or software!

The calendar was designed to have exactly 12 months of 30 days. That’s 5.25 days short of a solar year.

The other unique aspect of the Old Icelandic calendar is that the months always start on the same day of the week. Sólmanuður always starts on a Monday, Heyannir always starts on Sunday. To keep the months starting on the same day of the week, a 4 day month called Aukanætur (Extra Nights) is added in the middle of the 6 months of summer.

That gets us to 364 days, which is divisible by 7 without a remainder. Now the drift each year is only 1.25 days from the Gregorian calendar. To make-up for this, every few years and additional seven days called Sumarauki are added to Aukanætur. This keeps the months consistently starting on the same day and rectifies the drift from the Gregorian calendar.

Next week is the start of Aukanætur. It is only 4 days long and there is no Sumarauki this year. This month also means we’re half-way through the six-month summer season. The days are still long, but they are getting shorter as we head towards the autumn equinox.

While the Old Icelandic calendar is no longer used directly, there is still shadow of that old calendar in use in Iceland. For instance, Sumardagurinn fyrsti (The First Day of Summer) is a bank holiday and is always on a Thursday because it is connected to the Old Calendar format. The first day of Gormánuður, the start of the winter season, is becoming an event in Reykjavik, but rather than remind people of winter, it’s rebranded as Kjötsúpudagurinn (Meat-Soup Day). That is always on a Saturday. Bóndadagur (Men’s Day) and Konudagur (Women’s Day) holidays are both the first days of the Old Icelandic winter months of Þorri and Góa. Icelanders still celebrate Þorri with Þorramatur, a smorgasbord of pickled animal parts you’d never normally eat!

Even though Iceland doesn’t use the Old Calendar on a daily basis, it is still used in many other ways.

You can read more about Misseristal and Download an ics calendar file to add the Old Icelandic Calendar to your digital calendar.

Each year we publish an annual A0 wall calendar and include the Old Icelandic Months along side the Gregorian ones. You can download the PDF and take it to any print shop to get your own A0 or A1 calendar poster.