Monthly Archives: March 2018

My slide into audiophile territory, Part 2

This is the second in a series of posts about my realization that I have become an audiophile. The prior post examined why I think of myself as an audiophile now.

What does it mean, to me, to be an audiophile?

So, I’m an audiophile now. What does that even mean? Am I just an overexcited consumer with enough disposable income to blow a lot of money on headphones? Hopefully there is more to it than that.

A lot of people, when talking about speakers or headphones, preface their comments with “I’m not an audiophile, but…” They do so out of humility, to admit their own limitations of hearing, and their own lack of experience discerning good sounding speakers from mediocre ones. What it is really about, however, is saying that you are not a snob. I used to do that, too. But I’ve given myself leeway to put myself in the audiophile camp, despite my lack of ear training and my lack of sophisticated acoustical measuring equipment. I want to take the term “audiophile” back from the snobs.

I call myself an audiophile now because I love sound. I love sound so much that I listen to music hours and hours each day. I love sound so much that I will listen to types of music I didn’t like before—EDM, hip-hop, country, standards, soundtracks—just because they sound good. I love sound so much I will spend large—but not obscene or unlimited—amounts of money on decent equipment.

My love of sound itself is a relatively new development. While I have loved music as long as I can remember, what drove that love was always the melody, the song structure, the lyrics, and the performance—all the normal things people enjoy about music. The production, on the other hand, was not important to me. In fact, over-produced recordings turned me off, because studio slickness betrayed, in my opinion, the authenticity of the music.

Now, I think differently. I admire the craft of studio engineers in a way I never appreciate before. Some recordings just sound great, and that is part of the pleasure of listening to them. Similarly, some singers have have beautiful voices, and it doesn’t matter if they are singing the same old songs (ahem, standards): the sound of their voices brings life to the music and helps make it worthwhile to listen to.

To me, being an audiophile is about appreciating the distinction between the sound and the music, and deriving pleasure from it, far more than it is about spending vast amounts of money on expensive equipment, or believing the hokum perpetrated by high-end audio equipment manufacturers and sellers.

SwiftoDo Development Notes, March 2018

Today I released the ninth update to SwiftoDo in about ten weeks. What is driving all these small (but good!) releases? Two main things:

  1. I want the app to get better
  2. I want to have fun

I want it to get better

SwiftoDo is a good app, but it is by no means perfect. There are a lot of things that can be improved. My development task list for the app is a mile long. For a long time, the most important items on that list were also the most difficult for me to implement. To be honest, some of those “most important” improvements feel like they are beyond my current capabilities as a developer—but that doesn’t mean that I can’t make improvements somewhere. The app can still get better.

Sometimes, small things can make the app a lot better. Based on many emails with customers, I have learned that, a lot of times, a simple-to-implement feature, rather than a broad reimagining of a portion of the app, will make a big difference to their enjoyment of the app and the productivity they gain from it. That’s why I have been working on “small” features, such as the full file editor, that merely build on what was already there, but end up making the app more powerful and flexible for users. That is also my rationale behind improving application performance, which has become a much higher priority for me this year. Better performance benefits everybody.

I also decided to release features and fixes regularly and frequently. Every week I ask myself, “How can you make the app better for your customers?” And, on another day each week, I ask myself, “Is my latest commit better than what my customers have?” Once I’m sure the new version is better than the last version, I release it.

I figure that adding small features and fixing small bugs eventually accumulates, and my good app can eventually become a great app.

I want to have fun

I’m working on SwiftoDo because it the app is useful to me and because it is fun.

Coding is fun for me, but certainly not every minute of it. Sometimes I have to fight with UIKit’s quirks or work around its bugs, which can take hours of frustrating work. Sometimes I fail to get a feature working without introducing a crash or breaking something else in the app. Sometimes things just don’t work, and it’s really hard to figure out why. Sometimes I’m stuck, and that’s no fun.

I have decided not to remain stuck for more than a day or two anymore. If something isn’t working, I table the work and move onto smaller, solvable problems for a while. This philosophy has led me to work on features that seem simple, useful, and fun to code, but maybe not as important as the larger, more difficult things that have been blocking my progress. That explains why I’ve been pushing forward on improvements to the task text editor, for example, rather than adding new data providers. As a side benefit, working on those smaller things sometimes clears a way, either in the codebase or in my mind, to tackle those larger, more important items.

So, what’s fun? Racking up win after win, week after week, by pushing a better version of my app out to my users. And knowing, every day, that no matter what is not in the app yet, what is in the app keeps getting better.

Version numbers

SwiftoDo’s version number, currently at 2.9.2, is heading into the weird-looking, double-digit-minor-version-number terrority. The next version I release will be 2.10.0.

As Apple suggests, I’m using a 3-number semantic version numbering system, with my own rules for what increments each component. Architectural changes to the app (such as a total rewrite) will bump the first number. Adding new user facing features will bump the second number. Fixing bugs or enhancing existing features, in minor ways, will bump the third number.

Because I am releasing so often now, and batching fewer new user-facing features together, the minor version number has been increasing rapidly. No one should care what the version number is, as long as it goes up. I don’t really care if it is, eventually, version 2.50.0. I does look a little funny to me, though.

What about the Mac version?

I have not been releasing updates to SwiftoDo Desktop recently. The main reason for that is that SwiftoDo Desktop is, basically, feature complete. Unfortunately, because it is coded in Objective C and relies on cell-based table views (mainly for the inline editing to work), it sits at a technological dead end. A total rewrite is in order.

I have prepared for this scenario. My todo.txt-related code is in a framework that can be ported over to the Mac easily. In fact, I have started and stopped a total rewrite of the Mac version a couple times now, but have never gotten that far into it. The things holding me back are:

  1. I have to update my knowledge of AppKit, which is the Mac’s UI framework.
  2. The desktop app uses a different filtering system, which is a little harder to use than the iOS version’s filtering system, but it is much more powerful. I don’t really want to kill it off.
  3. SwiftoDo on iOS could always use more work, and it represents 70% of my user base.

In June, Apple may announce a new framework that would allow me to port my iOS code to the Mac much more easily. If that happens, my ability to provide an updated Mac version would be greatly improved.