Posts

Posted on

PocketBible 3 for Windows Progress Update #19

Once again, we’re overdue for an update. I know it seems like this is taking a long time, but we really are getting closer to at least a beta release. You can watch the video if you want to see the program in action. It’s a long one this time.

Almost everything in this update is an Advanced Feature Set feature. As a reminder, if you have an AFS subscription (or if you own the “legacy AFS” before it became a subscription) for the Windows Store version of PocketBible, it will gain you access to the equivalent features in this new version. Since the features we’re going to talk about today are not present in the current Windows Store version, your AFS subscription for that version will not get you access to these features. You’ll need a new subscription to the new version for these features.

User Note Indicators

One thing that is not an AFS feature is the new indicator for user-created notes in the text. You’re used to seeing the word “Note” linked to your notes at the beginning of a verse. PocketBible 3 for Windows will let you select either a duotone solid or outline note icon to use in place of the word “Note”.

Position of Layout Tabs

In previous screenshots and progress report videos, you’ve seen that the row of layout tabs extended all the way across the screen, including the area above the study panel. We’ve modified the layout so that the tabs appear over the text panes only.

Navigator

The Navigator is a featured ported from the macOS version of PocketBible. It allows you to see a list of all the places in your entire library (or a subset of your library that you define) where the current verse is mentioned. The Navigator can be set up to display its results based on which of your books contain the most references to the current verse, or it can be configured to always show your books in an order you choose.

When you select a link from the Navigator pane, you’re taken to the section of the book where the active verse is mentioned. You can configure the Navigator to always be active or you can disable the continuous updates and manually refresh its content when you need it.

Library Search

As you may have guessed, the Library Search study panel is where you perform searches across your entire library — or the portions of your library that you select. Library Search does not perform the full range of searches (such as “sounds like” and “root word”) that the single-book search does. Instead it looks only for exact matches, so that it can search your entire library quickly. To perform a deeper search of any single book, you can select the magnifying glass icon next to that book.

Searching your entire library can take time, so we provide a way for you to select only those books that you are most interested in searching. You can also control the order in which results are displayed — either by putting the books with the most search hits on top, or by following the order that you choose.

Verse Autostudy

If you’ve used PocketBible for Android, iOS, or macOS, you’re familiar with PocketBible’s Autostudy feature. It lets you easily collect material from your library that is related to a given verse (or passage), word (or phrase), or date. Autostudy will be implemented in PocketBible 3 for the first time on the Windows platform.

Verse Autostudy works on a single verse (“John 3:16”) or on a contiguous range of verses (“John 3:16-18”). You select the books that you want included in your results, and the order in which the books should appear.

For the Windows version we’ve improved the method PocketBible uses to determine if a given commentary is a “book of cross-references”. Previously, only the Treasury of Scripture Knowledge qualified. PocketBible 3 for Windows can look at a book at runtime and decide if its cross-reference density is high enough to make it useful for this function.

We’re introducing AI Insights as an experimental feature in this version of PocketBible. PocketBible can perform custom queries of ChatGPT to create Bible commentary for the passage, generate a list of topical cross-references related to the passage, provide theological and doctrinal history as it relates to the passage, give you insight into key Greek or Hebrew words used, and even generate a sermon title and alliterated outline. (We’ve found the alliteration to be hit-and-miss, but it does reasonably well on creating an organized outline.)

Any time that a Bible reference appears in your Autostudy reports, it is “hot” — click on it and PocketBible will go to the selected verse. This applies to your AI Insights as well — that is, the links to Bible verses are added to ChatGPT output so that references in its output can link to PocketBible. In addition to Bible verses, any links in the books that are in your Autostudy output are active as well.

This linking feature is also present in Word and Today Autostudy results.

Here is a link to the Verse Autostudy we did in the video.

Word Autostudy

Similar to Verse Autostudy, you can ask PocketBible to collect information from your library on a given word or (new in the Windows version) phrase. For the Windows version, we’re adding the AI Insights feature. PocketBible will use ChatGPT to generate a Bible dictionary entry for the word or phrase you give it.

Here is a link to the Word Autostudy we did in the video.

Autostudy Today

The purpose of Autostudy Today is to collect all the Bible verses you need to read on a given day. Assuming you’re doing one of our read-through-the-Bible plans, this can be very convenient.

AI Insights is also coming to Autostudy Today. You’ll be able to generate three types of devotional readings: An inspirational reading that focuses on the praise, prayer, and the attributes of God as revealed in the passage you’re reading; a commentary on the passage, providing background and interpretive information on the passage; or an applicational article, encouraging you to apply and practice what you’ve learned. You can also get an article entitled “Today in Christian History” that gives you information about key events that took place on today’s date in the past.

Here is a link to the first Today Autostudy we did in the video, and here is a link to the second one we did, which included the AI insights.

External Windows

A couple of interesting synergies happened as a result of implementing Autostudy. First, the dialog that lets you choose the books you want included in the Autostudy came in very handy for choosing the books you want to include in the Navigator and Library Search features.

Second, we needed a way to display Autostudy output. After some experimentation, we came up with the idea of using an external window with its own controls to allow you to save, copy, and print your Autostudy reports. It wasn’t much of an extension to this feature to make it so that you can re-open a saved report. And if you can re-open a saved report, you can open any HTML document in one of these windows. And if you can open any HTML document, you can open HTML documents that you create yourself, and any links you put in those documents can link to PocketBible.

Once we had this capability, it solved another problem. Many of you have asked for a way to copy search results to the clipboard. We used external windows to not only give you the ability to copy search results to the clipboard, but to allow you to print or save them. And since links in external windows are active, when you output your search results to an external window, it behaves a lot like the Search pane in the Study Panel — select a search result to cause PocketBible to show you the verse in context.

And then, once we had the ability to output search results, it wasn’t much of an extension to also output lists of bookmarks, highlights, and notes, and also to output your Library Search and Navigator results.

Any external windows you have open when you exit PocketBible will be re-opened when you launch it later.

What’s Next

  1. We believe the app is “feature complete”. There’s nothing major that needs to be added before it will be ready to ship. There are a couple small features that are “on the bubble” and either could or couldn’t be added before we release at least a beta version. But for the most part, it’s safe to say that there are no major features left to be added.
  2. There are a number of bugs on our list that need to be found and squashed. None of these are large, but sometimes you can’t tell how hard it’s going to be until you get into the code and figure out what’s going on.
  3. We are very sensitive to maintaining the integrity of your user-created notes, highlights, bookmarks, and devotional reading progress. We’ve been testing this code as we’ve implemented it, but I want to take a step back and re-run the full test suite on this code before we trust it with your data.

We’re not announcing any ship date at this point, of course, but we anticipate that our next update (whenever that might be) will be to announce a beta version. No promises. Just letting you know what we’re thinking at this point.

Posted on

Tech Talk: The Dingus and the Gooberizer

If you want to think of this as a PocketBible 3 for Windows progress update, you wouldn’t be entirely wrong. You will surely be disappointed, but you won’t technically be wrong.

The Dingus

We’re experimenting with giving you access to AI-generated commentary and other tools in the Autostudy feature in PocketBible 3 using the ChatGPT API. You won’t have to have a ChatGPT account to use it; we’ll create the prompts and automatically submit them and get responses for you to include (if you’d like) in your Autostudy output.

ChatGPT uses Markdown in its responses. Markdown is an easy way to create formatted text with a plain text editor. PocketBible use HTML for this purpose, which is a very different and more difficult way to create formatted text. So we have to convert from Markdown to HTML to display ChatGPT results in PocketBible. This is not straightforward, as Markdown wasn’t “designed” so much as it was pieced together as needed.

When the nerds who power our tech economy were asked to come up with a “standard” for Markdown, they discovered that even its most formal definition was ambiguous. If someone asked, “What happens if you overlap bold and italic markers in the text?” the only way to find out was to try it and see what happened. In order to make it easy for users to experiment and deduce the rules, they produced what is known simply as “the CommonMark Dingus” — as in “that whatchamacallit on their website”. The Dingus lets you enter text using CommonMark syntax and it shows you how it will render and what HTML tags are required to get the same result.

AI-generated instructions for use of the dingus. Pretty simple once you get it turned on.

The Laridian Dingus

After laughing about the CommonMark Dingus every time I used it, I realized the only way I was going to be able to interactively test my server-based Markdown to HTML converter was to write my own “dingus”. Turns out it’s actually not a bad idea. I see now why they created it.

The Gooberizer

While writing this, I (Craig) was reminded of some PocketBible code. Back around 2002, my programming partner, Jeff Wheeler, was working on the DailyReader app. At the time, daily devotional books and Bible reading plans were not a part of PocketBible, but rather, you needed a separate app called DailyReader.

Since DailyReader didn’t know how to read PocketBible books, and since Palm OS, the hot mobile operating system at the time, didn’t have a file system (!!!), we had to come up with a way to store the text of reading plans and devotionals in a way that would be compatible with a Palm OS database, would be quick and easy to decode, and wouldn’t be readable by humans.

Of the two of us, I was the guy who had experience with encryption. I had implemented a simple encryption algorithm that we were able to use on our website and in our apps when we needed something “secure enough” — not something you’d trust your credit card number to, but good enough to obscure other sensitive information that we don’t want you messing with. So Jeff came to me to figure out how to obfuscate his DailyReader data.

“I don’t need some kind of unbreakable encryption. I just want to goober up the text enough that it can’t be read by the average user,” he said. I picked up on Jeff’s goofy terminology and created the skeleton of code called “The Gooberizer“. I created a simple encryption algorithm with a symmetric key — as long as the producer of the encrypted file (his little program that created DailyReader books) and the consumer of it (the DailyReader app itself) use the same key, one can encrypt and the other can decrypt the data. In order to make it slightly more secure, the secret key is not something stored in the program, but rather is computed based on the data in the book. This made it harder for a nefarious (or curious) user to break the code and ungooberize the text for himself.

Jeff fleshed out the code from my design and DailyReader soon had fully gooberized text.

AI-generated instructions for use of the Gooberizer. Pretty simple.

PocketBible and the Gooberizer

Three years later I was adding some code to PocketBible and needed a way to authenticate an LBK (Laridian Book) file. We had decided to release our BookBuilder app as a commercial product but didn’t want a rogue competitor to use it to reproduce our entire library and put us out of business. So we put information into the LBK file that tells us that the file was built by the consumer version of BookBuilder. We needed a way to verify that these imaginary rogue competitors (who were growing more vile and contemptible the more we thought about them) weren’t tampering with the info to convince PocketBible that their books came from Laridian.

Then I remembered the Gooberizer. I rejiggered the Gooberizer code so it could produce a one-way hash of any string you gave it. The idea is that BookBuilder would build a string based on critical values in the LBK file, then store the gooberized string in the LBK itself. When PocketBible opens the file, it builds its own copy of the critical-values string and produces its own gooberized representation of it. If the stored goober and the runtime goober match, you get to read the book.

But seriously…

It can be embarrassing when the terminology you use around the office to describe something makes its way into public. You casually refer to your experimental test page on the website as “that dingus” and the next thing you know it becomes the most important part of your project.

Fortunately, we don’t foresee any need to give the public access to the Gooberizer. So for now it’s our little inside joke. Until somebody decides to write a blog article about it.

Posted on

PocketBible for Windows Progress Update #18

This isn’t so much a progress update as it is a quick demo of some of the user interface features of the upcoming PocketBible 3 for Windows.

Recently I got an email from a PocketBible user who didn’t like something about how the current Windows version of PocketBible worked. He was hoping it was not to late to ask for it to be fixed in the new version that we’re working on. I was able to reassure him that the new version won’t work anything like the version he was using. I wanted to send him a link to a video to demonstrate the feature, but while searching past updates it surprised me to find I hadn’t done one of these for a while.

So here’s a very fast tour through the app that touches a lot of different features and is meant mainly to reassure you that you’ll be able to resize the text (a flaw in both the current Windows Desktop and Windows Store versions of PocketBible) and that the toolbar will stay visible all the time (you PocketBible for Windows Store users will know what I’m talking about).

Posted on

PocketBible for Windows Progress Update #17

ChatGPT’s interpretation of a youthful version of Craig (the beneficiary of time dilation, apparently) coding on a laptop in a light-speed spaceship while wearing enormous sneakers.

When traveling near the speed of light, one experiences both the dilation of time and the contraction of distance. An astronaut traveling to a distant star at near light speed experiences less time than his friends back on Earth. He arrives at his destination sooner than expected because he also experiences less distance to that destination — as he accelerates toward light speed, his destination appears to be disproportionately closer to him than it would appear if he were at rest.

Then an interesting thing happens as he gets closer and begins to slow down — his destination gets farther away. This is due to the reduction in the effect of length contraction as he slows towards being stationary with respect to the destination.

We see the same thing happen in the software world. As we approach the end of a software project and find ourselves implementing fewer new features and solving fewer bugs, the release date appears to move farther away. The effect of taking 4 weeks at the beginning of a project to solve a major problem is relatively minor in the grand scheme of things. But taking 4 weeks on a single task at the end of a project makes it feel like it is never going to be completed.

Reactivity

One of the major challenges we’ve faced in the last couple of months is related to Vue — the user interface framework we use. Vue is a “reactive” system. That is, if you want to display some text on the screen, you don’t write code that moves to a particular (x,y) location and outputs the text in a particular font, but rather you define an area of the screen that will display text in a certain font, then attach a particular variable in your code to that area of the screen. Now when you change that variable, the screen is updated with its new value. In other words, the user interface reacts directly to changes in your data.

In order to know when it needs to update the screen, Vue wraps its own code around these reactive variables. It is very good at doing its wrapping. If you’re not careful, it can “infect” certain pieces of data with its reactive wrapper. The result is not only inefficiency (since a bunch of unnecessary code is executed when you change the value of a variable) but potential confusion as Vue believes you’re changing data at a time when you shouldn’t be changing it. In reality, Vue shouldn’t be paying attention to it at all, and everything it reports is nonsense.

One common problem is changing the value of a reactive object or variable while Vue is getting its value in order to render the screen layout. This seems easy to avoid (why would you change something while getting its value?) but in reality, it happens often. For example, the table of contents of a book is a static piece of data. But we don’t keep it all in memory at the same time. So when you want to display the table of contents on the screen, we have to read it from the book. Doing so changes the value of the file pointer that tells us where we are while reading the file. In other words, reading static data (the table of contents) changes a value (file position) in the object in our code that represents the book. If Vue has wrapped this object with its reactivity code, it believes you are changing the data while it’s trying to read it.

The other way this can happen is when accessing some piece of data from a book that needs to be constructed the first time it is accessed but is static after that. Consider the field where you type the name of a book of the Bible that you want to go to. That field needs access to a list of all the book names and the abbreviations of those names that are in this Bible. That information isn’t stored directly in the book file — we have to iterate over the list of all the books of the Bible that are in this particular Bible and generate a supplemental list of all possible names and abbreviations. Consider, for example, 2 John. You might enter “2 John”, “2 Jn”, “2John”, “2J”, “2Jn”, “II John”, “Second John”, etc. We keep a list of all possibilities so we can auto-fill the field. So the act of getting the list of book names for the first time will cause the list of names to be stored in the book object for use if you need it later. Storing the list in the book object that has been infected with reactivity code makes Vue believe you’re changing data while it’s trying to read it.

There are certain significant data structures in PocketBible that are susceptible to this unnecessary infection by Vue’s reactivity code. For example, we keep a list of books that you own. Some are open, some are installed but not open, and some are back on the server. We know a little about the ones on the server; more about the ones that are installed; and a lot about the ones that are open. What we know about each book is stored in an “object” that is the representation of that book in the list.

For the most part, this large list of book objects is not directly displayed anywhere on the screen and Vue doesn’t need to know about it. Our code will reference it when getting Bible text or when showing you the table of contents of a reference book. But you’re rarely looking directly at data directly stored in this list. As a result, this list is immune to being infected by reactivity code, and we’re free to change the data it contains whenever we want.

But because this list is so central to almost everything PocketBible does, it isn’t difficult to accidentally expose it to Vue, then have the result of the reactivity infection show up in a completely different part of the app.

We’ve spent a lot of time in the last 3 months chasing down a major bug related to this reactivity infection phenomena. We’ve been seeing the symptoms for quite a while but hadn’t taken the time to look into it until recently. We think we have it solved but it’s the kind of thing that can pop back up at any time.

New Bible Format Implementation

We continued and perhaps finished work on integrating the new Bible format that we’ve been talking about for the last year or so. In addition to the basic functionality we added some enhancements that allow us to see the version numbers of this Bible data and identify where it came from so that future troubleshooting should be easier.

Link Preview

We began work on the link preview function, where hovering over a link causes the target of that link to be displayed in a pop-up window. For example, hovering over a Bible reference will cause that verse to be shown as long as your mouse is hovering over it. The user interface portion of this task (tracking your mouse and popping up a window) is basically complete; now we need to implement code to get the text that populates the window.

We’ll also be adding code to activate the link preview pop-up on long press for touch-screen devices.

Delete Books

We implemented the ability to delete books installed on your machine. This is trickier than you might think, since you have to make sure the book is not left open in one or more panes after it has been deleted.

Miscellaneous

We fixed a problem with devotional start dates and at the same time, found a problem that might be related to 2024 being a leap year. Should be easy to fix once we take the time to look for it.

We fixed a problem when trying to find an installed book when you only know its publisher ID and book ID. This is rarely used but could have caused a hard-to-find bug had we not caught it when we did.

When looking for a Bible to handle a link (or, in general, any book to handle any link) errors were always being reported to the user even though there are some cases where we want to know there was an error but don’t necessarily want to show it to the user.

Posted on

The Eclipse Effect

On Friday, April 5, my wife and I took off from our home in Iowa and headed toward New England — the only area along the path of the April 8 total solar eclipse forecast to have clear skies. By Saturday, the weather was improving in central Indiana, so we turned back a bit and spent Saturday night in Indianapolis. Sunday morning’s forecast suggested Cape Girardeau, MO might be the place to be. I saw the 2017 eclipse from Makanda, IL, which is about 2 hours from Cape Girardeau, so we headed to that area to spend Sunday night — with the idea we might move quickly on Monday morning, in time to set up for the 12:40 PM “first contact” (C1) between the sun and the moon.

Monday morning things looked no better in southern Missouri than they were in southern Illinois, so we headed to Makanda to reprise my 2017 experience at the place where the two paths of totality (2017 and 2024) met.

With me was a new Seestar S50 Smart Telescope. The Seestar is just a sophisticated digital camera. You set it on its tripod, calibrate its internal compass, level it up, then tap “sun” in its app. It just rotates and looks up and finds the sun, then follows it across the sky until you tell it to stop.

We got some great footage with the telescope. I combined it with my iPhone footage to document our experience.

The big telescope is just there to impress the kids. The workhorse Seestar is the little guy on the ground on the left.

Meanwhile, At Laridian

If you’ve been paying attention, you’ve figured out over the last 5-6 years that we’ve settled in on a marketing schedule where we announce a new product or sale every Monday morning. The email goes out around 9:30 AM Central Time. This tends to make Mondays our best revenue day. On Thursday, the email goes out to anyone who hasn’t opened it yet, as a reminder that they’re not keeping up. 🙂

After getting back in the office, I looked at Monday’s orders and found an interesting pattern. We had an initial bump around 9:30 AM as expected, but then starting in the hour that the partial eclipse started in southwest Texas, sales fell to all but nothing. They didn’t come up until the hour after the total eclipse ended in northeastern Maine. For the rest of the day they were higher than usual as everyone recovered from staring at the sun.

In this graph I’ve normalized the sales numbers so that “peak sales” is at the same level for both a typical Monday and eclipse Monday. The point is not to reveal exact numbers but to show the dramatic effect of the eclipse. Sales are reported hourly, so the slant in the line that starts at 14:00 (2PM) doesn’t mean that we started to see sales as soon as totality started in the midwest, but rather that there were a lot more sales in the 3:00 hour than the 2:00 hour.

I suspect there might be more to see here, but I haven’t taken time to dig into it. For example, I wouldn’t expect to see as much of a difference in sales from western states as from eastern states, since the former were so far away from the path of totality.

I wouldn’t normally share information like this but it was so dramatic that it seemed like it might be interesting. And I don’t blame you for not buying anything during the eclipse — even those of us at Laridian were doing nothing but watching the eclipse along with you.

Thinking about PocketBible users’ group meetings in Iceland in 2026 and Sydney in 2028.

🤔🥳🌞🌚

Posted on

PocketBible 2024 User Survey

I’m just going with these AI-generated images now. No excuses. Pretend like it’s a game — find the anomalies. Which person is a ghost? Which is part of the furniture? Where is the sun? Why is there a big red violator in the upper left corner? What is it hiding?

We just completed our annual survey of our PocketBible users and I thought I’d share a few results with you. This isn’t everything and it’s not even every important thing. But some of this is interesting and might help you understand who your fellow PocketBible users are, and in some cases, why we might make the choices we do when it comes to the products we create for PocketBible.

Demographics

The majority of you are male, and are 55 or older. To some peoples’ surprise, most of you are not preachers — though about half of you have some kind of teaching ministry.

This is consistent with what we’ve come to know about our PocketBible users. I believe that our age (yes, I’m in that “over 55” group, too) puts us in a generation that trusts the authority of the Bible and therefore wants to know more about it. We also believe there are people smarter than us who have things to say about the Bible from whom we can learn. Younger people tend to value the experience of God. They learn about God through their community experiences with their fellow believers. As a result they have less dependence on the kind of commentary and research tools at which PocketBible excels. Not all of them, of course; we continue to add new users of all ages to the PocketBible family.

Beliefs

Half of you chose the label “Bible-believing” to describe your Christian beliefs. One-third use the term “evangelical” and one-third “nondenominational”. About two thirds selected “Catholic”, “Orthodox”, or a specific Protestant denomination. These terms aren’t mutually exclusive so the totals add up to more than 100% with a lot of overlap.

It’s interesting to note how our ranking of denominations is different than the ranking of these denominations in the general population. Note that these are cherry-picked to match what we asked on our survey; there could be a number of smaller denominations missing.

Church/DenominationRank (In the US)Rank (Among PocketBible users)
Catholic18
Baptist21
Methodist34
Lutheran46
Pentecostal52
Presbyterian63
Episcopal/Anglican75
Seventh Day Adventist87
Orthodox99
Only denominations that got at least 10 responses on our survey are listed. 80% of you are in the US, so only members of these churches in the US were considered.

This is consistent with what we know from being in the Christian publishing business for over 30 years. People who purchase Bibles and Bible study materials tend to be on the more theologically “conservative” end of the spectrum and they tend to describe themselves as neither Catholic nor Protestant. That “Bible-believing” term sums up who they are. This has been true the entire time I’ve been in this business.

And it makes sense. These are the kind of people who are encouraged by the churches they attend to study the Bible for themselves and not to depend on a formal member of the clergy to answer their questions. Even the least leadership-oriented person in this group has a small but useful Bible library, which may or may not be entirely digital.

Bible Reading

90% of you spend time reading the Bible every day (or nearly every day). The majority of those are either using PocketBible’s devotional features or following an external plan but using PocketBible to read the Bible. Those who do read every day spend 17 minutes each day reading the Bible. This is consistent with the 16.5 minutes we got last year.

I find that encouraging. I believe it’s important for Christians to read and understand the Bible. It’s our most direct way of getting instruction from God.

Online Habits

Most of you are still using Google for searches even though it puts your privacy at risk. The next most popular choice is arguably the right one: Duck Duck Go.

A few of you, when asked what search engine you use, told us you use Edge, Firefox, or Safari. Please — these are browsers. A browser is how you access the Web. A search engine is a website you use to perform searches. Most browsers allow you to choose a default search engine. This allows you to type some search words into the address line in your browser and it will automatically invoke your chosen search engine to perform the search.

Use of PocketBible

Most of you use PocketBible every day and almost 90% use it more than just in church on Sunday.

Over 80% of you use PocketBible most of the time on either a phone or tablet. This is consistent with how we target our marketing of what we do — we are a mobile app developer and always have been. That less-than-20% who use it primarily on a desktop or laptop will argue with us about that and point out that Windows is the most popular operating system. Until we point out that Windows is the most popular desktop operating system. If you expand your scope to all computing devices, then Android OS is actually installed on more devices than Windows.

Satisfaction

94% of you are somewhat or very satisfied with PocketBible. You are most interested in the same kinds of resources that we are already producing — commentaries, dictionaries, Bibles, and atlases. You have some very specific recommendations in some cases, and we’ve made a note of those.

2% of you are dissatisfied with PocketBible, so we’re pouring over your criticisms and suggestions. We don’t respond to these of course, but we do read them. We don’t enjoy it, but we do it anyway.

This is just a quick overview of the portions of the survey that I thought might be of general interest. The complete report is 49 pages long, including your comments, suggestions, and complaints in 10-point font.

Thanks to those of you who participated! This is an important part of what we do to make PocketBible into a useful tool.

Posted on

Your Power Supply is Smarter than You Think

I recently purchased an Apple Vision Pro. I’ll eventually have some thoughts about this platform and its potential for Bible software, but right now I want to talk about that boring little brick you plug your iOS device into when you charge it.

I’ve owned an iPhone since the day it was introduced, an iPad since its launch date, too, and now a Vision Pro 1.0. Just like many of you, I have drawers and computer bags full of those little USB power supply bricks and a variety of the bigger ones that come with MacBooks. I figured out a long time ago that I can plug any device with a USB charger into any USB power supply even if it’s intended for a different device. So I charge my iPhone and Watch with my MacBook charger and have been known to plug my MacBook into an iPad charger just for grins.

When I got the Vision Pro, I saw someone on YouTube put a meter inline with the charging cable and note that it would draw up to 60 watts when connected to his MacBook power supply, even though it ships with a 30 W power supply.

I have just a little bit of experience with electronics, having learned Ohm’s Law for my ham radio license 50 years ago (!) and having built a number of transceivers and other electronic gizmos. I’ve been assuming that all these devices needed 5V at some number of amps — 1.5 A for iPhones and 2.1 A for iPads and many more amps for my MacBook. They are all interchangeable, so they must all use the same voltage, right? Maybe just limit the current?

Wrong.

Turns out these little power supply bricks are smart. They talk to your device and negotiate a voltage the device can use and the current limit the supply might have at that voltage. Between your device and the power supply, they work out the optimum arrangement for operating your device and charging the battery. Voltage ranges from about 5V to about 20V and current is adjusted so as not to exceed the limits of either the power supply or the device.

I guess they’ve been doing this since about 2012. Who knew? Not me.

Image by ChatGPT/DALL•E, of course.

Posted on

Happy Candlemas! (Groundhog Day)

Recently discovered Byzantine representation of an ancient Candlemas celebration, as recreated by ChatGPT

Groundhog Day, celebrated on February 2nd, has its roots in an ancient Christian tradition known as Candlemas Day, which marks the midpoint between the winter solstice and the spring equinox. On Candlemas Day, clergy would bless and distribute candles needed for winter, and the candles represented how long and cold the winter would be.

The choice of February 2nd is rooted in early Christian tradition and Jewish custom, which mandated a period of purification for a mother after giving birth, followed by the presentation of the child at the Temple. For a male child, this period was 40 days, and since Jesus’s birth is celebrated on December 25th, the 40th day thereafter is February 2nd.

The weather lore associated with Candlemas, however, has pre-Christian roots.

Pre-Christian Traditions

The tradition of observing weather patterns around the beginning of February can be traced back to pre-Christian times and is linked to ancient Celtic festivals, particularly Imbolc. Imbolc is celebrated on February 1st and marks the beginning of spring in the Celtic calendar. It was a time for weather divination, and the weather on Imbolc was thought to predict the weather for the coming spring and the remainder of winter. This period, falling halfway between the winter solstice and the spring equinox, was a significant seasonal marker in many ancient agrarian cultures.

Candlemas and Weather Lore

When Christianity spread throughout Europe, many pagan traditions were Christianized or absorbed into Christian celebrations. Candlemas became one such feast where pre-existing weather lore was integrated into Christian practice. Sunny weather on February 2nd indicated more winter to come, similar to the Groundhog Day belief that if the groundhog sees its shadow, there will be six more weeks of winter.

This lore found expression in various regional aphorisms:

England

If Candlemas be fair and bright,
Winter has another flight.
If Candlemas brings clouds and rain,
Winter will not come again.

Scotland

If Candlemas Day is bright and clear,
There’ll be two winters in the year.

Germany

For as the sun shines on Candlemas Day,
So far will the snow swirl until May.
For as the snow blows on Candlemas Day,
So far will the sunshine before May.

America

If the sun shines on Groundhog Day;
Half the fuel and half the hay.

Germanic Influence and the Emergence of the Groundhog Tradition

The specific tradition of using an animal to predict the weather on this day is more directly traceable to Germany and surrounding regions. Before the tradition was brought to North America, Germans looked to the badger as a weather prognosticator. When German settlers arrived in North America, particularly in Pennsylvania, they adapted the tradition to use the groundhog due to the absence of badgers in their new homeland.

Early German settlers in America mourn their inability to predict the weather in their new homeland due to the scarcity of badgers. Fortunately, groundhogs were plentiful.
Posted on

PocketBible for Windows Progress Update #16

ChatGPT attempts to render my Windows programming workspace based on a general description.

I told myself I’d write a progress update after the first of the year. Suddenly that’s where we’re at.

As you recall from updates 14 and 15, we had a bit of a crisis of our own creation happen toward the end of 2022 which required us to update both BookBuilder and PocketBible on every platform. We had to modify our Bible format and make sure all versions of PocketBible (with the exception of the old/current Windows versions) could read the new format.

We started with our BookBuilder and PocketBible apps for macOS, since these two share a lot of code and doing them at the same time gave us a platform on which to test our new Bible format. We held off on releasing BookBuilder in case we discovered anything we needed to fix as we rolled out the changes. We released the macOS version of PocketBible in May with updates following into June.

This allowed us to turn our attention to the Android version, which was problematic because of Google shenanigans. An initial version was released in September to address new Play Store requirements. We spent the next 6-8 weeks implementing the Bible changes and doing updates to fix various problems discovered after the release of the new version. This was our first update in 5 years for the Android app, so there were some issues.

That brought us to the Thanksgiving/Christmas season, which is our busiest time of year. There are two large tasks that I’m personally involved in because they impact code on the website — creating the 2024 editions of the Bronze, Silver, Gold, Platinum, and Emerald PocketBible Library collections, and implementing the end-of-year “name your price” sale. Because these tasks have to be done every year, some of the process is automated. But it still requires a bunch of my time.

Despite the distractions, progress was made on the Windows app during this time.

The app is very close to being feature-complete, at least for the standard (non-AFS) feature set. One of the next big tasks that, oddly enough, consists of a lot of unknowns is being able to build a Windows EXE suitable for distribution.

As I’ve explained before, we do all of our development and testing on macOS. We’ve done occasional debug builds for Windows, but we’ve never been able to generate a stand-alone EXE like we’ll have to do when we release the product. So even though we’re not quite there yet, I have someone looking into those issues.

This has taken us down two dark alleys. One was compatibility problems with the versions of the Electron and Vue frameworks we’re using in the app. In order to build an executable that works, I think we’re going to need to be running newer versions of those foundational tools. Electron isn’t much of an issue, but Vue has undergone breaking changes in its most recent major update. This requires that we make significant changes just to get our code to build with that version.

The second issue is code signing. Code signing is a process that is supposed to do a couple of things. First, it assures you that the software you download from our website really is from us and not some other company pretending to be us. Second, it assures you that the code hasn’t changed between the time we signed it and the time you downloaded it. This is meant to make you safer (or at least make you feel safer). But if you think about it, code signing is arguably pointless. No malware you’ve ever been a victim of is stopped by a code signing requirement. If this requirement were lifted, all the same malware would continue to work just fine.

Anyway, signing our executable and getting it to work after it is signed has been a challenge. But we’re working on it.

Meanwhile, I’ve been able to get back in my coding chair and have been porting the new Bible format to the Windows code. One unexpected benefit is that I’ve gotten to re-think the way we had ported this code from C++ to JavaScript in the first place and make some changes that will make it easier to maintain. I’ve borrowed some from the C++ (macOS and Windows) implementation and some from the Java (Android) implementation. This gives us good consistency between all platforms and will make maintenance easier in the future.

To sum up, after a detour to do a lot of work on other platforms, we’re back to work; we’re close to feature-complete (at least for the standard feature set); and we’re focusing on tasks that are necessary to move from development to beta to release.