After becoming increasingly frustrated with the multi-column-search plugin, I’ve taken the script from my calibre “read next” query and turned it into a tiny plugin of its own. It adds a button to the toolbar which will mark all books with the “readnext” label when clicked, bypassing the need to open up MCS, load an existing query from the difficult-to-read menu, execute the query, and finally close the window again.

The plugin package can be downloaded here.

This post is deprecated in favor of a plugin I wrote which does the exact same thing but in a much less annoying way.

---

I read a lot, and a common problem I have is keeping track of the series I’m currently reading. For a while I’ve toyed with the idea of writing a Calibre plugin that would allow me to see books that belong to a series which I’ve started but haven’t caught up with (I rate books as I finish them, but parsing my library at a glance to see what comes next is difficult). Today I found the Multi-Column Search plugin and it turns out to have exactly what I need to solve this problem: a freeform SQLite field.

select id from (
  select *,
    row_number() over(
      partition by series order by series_index asc
    ) row_num
  from (
    select
      b.id, bsl.series, b.series_index, r.rating
    from books b
    inner join books_series_link bsl on b.id = bsl.book
    left join books_ratings_link brl on b.id = brl.book
    left join ratings r on brl.rating = r.id
  ) where rating is null
)
where row_num = 1 and series_index > 1

This script will filter the library to include the next unread (unrated) book in your library from each series that has at least one book that has been rated. It’s a little uglier than I would have liked, since I had to use one long query instead of CTEs, and I would have liked to be able to return them in order (maybe by overall average score), but due to limitations in the plugin this is as good as it’s going to get. Even so, I can tell it’s going to be super useful.

In Year, Month, Day, I explained an annoying problem with Javascript dates, and outlined the solution I took to avoid it in Moyase (which only needs to deal with dates in local time, and shouldn’t care if you move your device across timezones). Well, as it turns out, even this solution was not foolproof, and I totally should have seen it coming.

See, Date.toISOString() does indeed return a pretty nicely-formatted string that I can carve up and use for date components…the (obvious, in retrospect) problem is that it gives it to you in UTC time with a timezone offset, which can very well be a totally different calendar day than in local time. I probably would have never noticed this until I found myself on the other side of the world at some point in the future, or happened to be working in the app very early in the morning, so I’m very lucky to have a friend in Australia as an early adopter; she noticed that at certain times in the day, her work would be counted towards the previous day and her calendar wouldn’t display the right dates.

The fix ended up being pretty simple; instead of this:

return date.toISOString().substr(10);

I went with this instead:

return [
    String(date.getFullYear()).padStart(4, '0'),
    String(date.getMonth() + 1).padStart(2, '0'),
    String(date.getDate()).padStart(2, '0'),
].join('-');

With this, the app works correctly no matter the timezone or time of day. Hopefully this is the last time I have to think about this problem.

5…4…3…2…1…Happy New Year!

It’s midnight, January 1st, 2021. The ceremonial ball has dropped in Times Square and 2020 has just come to a close. As the festivities begin to wind down, your phone buzzes. It’s a text from your friend in Los Angeles.

“My wife just delivered our baby! It’s a boy!”

What is the baby’s birthday?

Continue reading →

When writing code, I try to structure my project in such a way that it’s impossible to misuse. I often run into cases where I need some class to be responsible for instantiating and managing its own resources, such as a message hub (which needs to maintain a list of subscribers) or a tweening engine (which would need to update and dispose of tween control objects according to a timer). In these cases, I like to ensure that these objects can never be created outside the class which manages them.

A simple solution, of course, is to use internal constructors, but I personally prefer to avoid using the internal access modifier whenever possible, as I find it does a poor job of signalling the intent of the code, and in many cases is just a band-aid fix for a poorly planned access scheme. Furthermore, in cases where the class in question will only be consumed within the same project, internal is essentially no different than public.

My solution to this problem is as follows:

Continue reading →

Following up from my post about using Haxe/OpenFL to save some of my old Flash games, I do feel like I have to talk about some frustrating points that came up during the progress.

I will preface this by saying that the problems Haxe has now are different than the problems it had when I was using it previously. Throughout this process, I only came across a bare few instances where switching targets led to suddenly broken code. The OpenFL runtime never totally crashed on me like it used to do. I didn’t have to fiddle with DCE flags to prevent my code from being erroneously stripped from the build. It’s obvious that Haxe has improved a lot over the past few years, and that’s great. I do plan on continuing to use it to port my other game projects, and I would recommend it to anyone else for the same purpose. I do believe in criticizing the things we love though, so let’s get into it.

Continue reading →