Dependency injection

A large part of my early maintenance of Podcast Chapters was removing various dependencies. From package managers and external scripts to permissions and, of course, third-party libraries. I was eventually very successful in this, ending up with an app where I depended only on the Mac platform, and where I had learned a lot about all the inner workings of everything the app did.

With the latest version, uploaded and released yesterday, I began to make use of some third-party code again. It amuses me a bit just how strong my initial aversion was, and I am happy I got over it for good reasons.

My library aversion mainly comes from a feeling that I, as the creator of an app, should know the inner workings of my creation really well. If I know well how things work, I should be able to code appropriate solutions for problems. If I do not, I should learn to understand better, then code myself. If I do not understand a problem well enough to solve it myself, I also can not expect a third-party library to solve it for me. I just do not know the risks and trade-offs well enough. And if the library ever breaks or otherwise stops solving the problem for me, I have not moved an inch forward.

I am also hesitant about the sheer mass of code I take on. I would not want to take in a huge library to solve what should be a small problem.

So, in the latest version, I added support for import of data using CSV files. A user might enter all their podcast information in, say, Excel or Numbers, save the spreadsheet as CSV and simply drag and drop the file onto Podcast Chapters to fill in all the information at once. Very nice.

It gradually dawned on me that CSV handling was a good candidate for using a library:

• The problem is clearly defined and constrained
• I understood the problem space pretty well, having written code to handle CSV before
• The hardly-even-edge cases did not feel particularly fun to handle myself
• Good solutions could be quite small in terms of number of lines of code

I ended up using Swiftcsv for my CSV parsing needs. Because it is small and light, I added it in the most old-school of ways: by copying the source files into my project. The problem is solved, and the code base is small enough that I could maintain or update it for my needs if I ever needed to.

(I also learned about adding Credits.rtf to my project to get acknowledgement of my usage into Podcast Chapters' about box. Just the way I wanted it.)

The whole exercise also made me curious as to how exactly the solution we built back in the Dark Ages worked. I think we did everything in our own code that time, and I do recall reading up on various edge cases to make sure they worked properly, but I have no recollection of what our actual solutions were. If I saw them today, would I recoil in horror, or be amazed at just how clear-eyed we were? Smart money would be on the first option, but who knows?

I think I could still find that code if I really wanted to …

Small-screen entertainment

After thinking about it many times, I went ahead and resurrected the Iphone SE we have had hanging around in a box for a long time. Poor little thing. The size and weight are truly amazing, and even after a few days I find myself frequently using two hands to hold and handle it even though I can comfortably reach every part of it while maintaining a good grip.

And everything works, too. While I restore phones from backups somewhat regularly, I have never done so over quite this distance in phone generation and device size. Sure, I knew the OS versions were the same, but I still half expected to hit at least some kind of snag somewhere. But no, everything came across just like it should.

I know it was released in 2016, but the SE still feels fast. More than fast enough for the needs of someone who uses his phone little enough that smaller size feels like a natural win. I would of course love if it had a more modern camera, but otherwise I lack nothing here. The battery does burn through noticeably quicker, but I would guess that is a simple factor of the battery being several years older than the Iphone XS I was using just before.

Remember the cool feeling of a phone you could stand up because the edges were straight? Yep, still feels good. Also, it lies flat on a flat surface! There is no camera bump, the lens is flush with the back.How cool is that?

Broken rings

I did manage to break my ring streak after Sunday. On Monday I went about my day, took of the watch and went to bed and did not worry at all (pretty much) about the rings.

You could almost hear the credits roll on my ring era.

It feels good.

(I might still get a new watch in the future though. Some time after sleep tracking is released this autumn. Got to get more use out of all these bands … Perhaps there will be an Apple watch SE?)

Ringwraith

1000 days of Apple watching.

1000 days of filling up rings.

I am not sure it has been a net positive.

I still remember clearly the first evening where I almost did not fill my rings. The annoyance at not wanting to break a streak, added to the annoyance of the system gaming me to make me fill it anyway, combined, still, with a slight satisfaction once I made my goal after all.

That set me off right from the start feeling the whole system was rigged incorrectly, and it has not been changed at all in the years since.

The core issue

My fundamental annoyance is still that I feel that the reward structure - if it really works for you - can only put you in either of two groups:

• Either, it motivates you to do better and better until you fail to reach a goal and lose your streak. Pushing you until you back or break down seems like a bad recepie for long-term success
• Or, it motivates you to set up a routine where you reach the goals without changing them and without risking over-exertion. Playing it safe. The circles are steady, predictable, planned, and much more of a chore than anything else. They need to be done every day, so there is never any true rest day. Which also means less motivation to do something truly exhausting one day, because you will not be able to rest completely the day after

My problem is that I am really good at keeping routines, so I was in the second group ever since the beginning. I imagine that is the only one if you end up trying to fill circles over time. I wonder if the first group has a large portion of new watch users, then rapidly drops off in number of people. Are there any year-three circle fillers still in the first group? I have used my initial red ring goal ever since I started. It is a very easy goal to hit on any reasonably active day, but I have never raised it since I need to be able to hit it every single day, no exceptions, if I want to maintain my streak.

People have wanted Apple to add rest days, and I think that would be a good idea. But I feel there should be a lot more that could be done if your goal really is to motivate people to get healthier. Chasing ever-increasing goals and maintaining streaks feels more like an easy way to motivate those already moving regularly. Surely Apple can think of something more fun, creative, and motivational?

I do appreciate that the watch makes me want to move more, but I resent it for being on my mind so much. I would probably feel more relaxed if I did not care, or did not wear. But would I also be healthier? It is impossible to tell. I always wanted everything to be tracked before I wore it.

Any year now?

Other points

Even with these frustrations, I do enjoy my Apple watch both for its health and activity tracking, and for it as a plain nice accessory.

I never thought I would end up with anywhere near this many bands.

Looking back at what I wrote after 100 and 365 days, things seem to be very much the same. Still somewhat gaming the system, still picking up watch bands, still feeling more likely than not to pick up a new watch should this one break tomorrow.

Time to move on?

It might be time - or long overdue - for the training wheels to come off. This was something discussed ages ago on M vs M: that a streak and the routine to maintain it in a way is like training wheels: something to keep you going in the right direction while learning. Taking off the training wheels means letting go of the routine and see how things work out without the artificial supports. I think this is where I should go.

Light up your world

Sometimes, you get a lamp you like so much it makes you look forward to the darker half of the year. Just a little bit.

Apart from that, I love the actual part of the year we are in right now. Very much including the amazing thunderstorm and intense rain we had yesterday, overflowing our rainwater barrel, washing away layers of pollen and renewing the lushness of everything green. I was disappointed at the level in the rain meter after the downpour, only to realize it had been emptied just before it all broke out. I then switched back to feeling impressed by the weather again.

Other totally summer-like thoughts include finally getting a grip on the wired networking situation of the home. More switches have been bought, cable placements have been planned, yet I still hesitate about how exactly to best cross a few doorways situated in unfortunately solid concrete walls.

There is only one way forward, and it will include making permanent marks on something. Everyone wants to make a dent in the universe, right?

Browsing the archive

As the evening progressed and what passes for darkness in late May set in, I found myself browsing my old entries on this site again.

I think it started with wondering something about Gothenburg startup hack, but I quickly passed Middle earth: shadow of Mordor and then, inevitably, fell into dreams and memories of Webos phones.

If there was a really small phone with a good enough camera, I think I could really enjoy a small-screen lifestyle.

I also learned that - according to the best records I have - the next time i run Göteborgsvarvet will be the tenth. At least that will make the number easier to remember, for a while.

I discovered when I started using my little personal weekly planning and productivity system. I started thinking of Berlin, and the age when Björeman // Melin had less than 50 episodes.

The point here is that it is nice to write things down, and to do it in a place you can actually go have a look at every now and then.

Writing on spec

Another update to Podcast Chapters is currently waiting for Apple to review it.

It is really a single patch, but an important one because it causes some podcast players to only display a single chapter. It also causes garbage characters to show up at the end of chapter titles in some places, but given the problem I am a bit surprised it did not surface earlier and much more frequently.

My error was a classic case of not reading the specification closely enough. Some textual information should, basically, be ended with trailing zeroes, while others should not. This is marked quite clearly in the ID3 tag specification, yet not clear enough for my distracted mind. What happened was that I added trailing zeroes in my string writing function, because all those zeroes-requiring places were breaking. Then, I clearly did not think far enough to realize that the other strings had no indication of wanting zeroes and thus probably should not have them. Plus it all worked in the players I had access to testing in, so I went on my merry way releasing versions.

Now that I finally got a clear and major problem report, I realized I had seen a few indications before, but not dug into them because they were not causing issues.

My way to locating the problem was also rather long. The problem report was of chapters failing to appear in Antennapod, an open-source (and very nice-looking) podcast player app for Android. Suddenly, I found myself setting up all of Android studio, building, running in simulators, debugging Java code, and having a surprisingly good time of it all. I was expecting the whole process to be much more of a slow mess, especially on a Mac, but clearly things have progressed a lot since I last attempted to run an Android simulator.

And it was all worth it for the ability to set break points and inspect local state. Then I just needed some breakpoints in Xcode of the writing side of the process and a little bit of staring at the specification before the pieces fell into place and the handful of changes were ready for upload.

Might come out tomorrow if we are really lucky. Soon, in any case.

I wonder if WWDC will bring anything fun for Podcast Chapters?

Otherwise, I think I still have a few things left on the to-do list …