Recently, we released version 1.0 of myPrayerJournal, a minimalistic prayer journaling application. This series aims to provide a tour of the code, with several stops along the way:

• Part 0: Introduction (this post)
• Part 1: The Front End - Vue components and routing
• Part 2: State in the Browser - Vuex and getting information from an API
• Part 3: The API - Giraffe and JSON web endpoints
• Part 4: Authentication - Auth0, using information in both app and API
• Part 5: The Data Store - EF Core backed by PostgreSQL, with the DbContext defined in F#
• Part 6: Documentation - GitHub Pages generated on each commit
• Part 7: Conclusion - Lessons learned and opinions based on the development experience

From a technical perspective, this application was going to be a learning experience. We knew we wanted to use a Single Page Application (SPA) framework with an API; we'd built APIs before, but had yet to build a SPA. For front-end frameworks, we started with Angular, went through Aurelia and Elm, then decided on Vue. For the back-end API, we started with Suave, then went live on Node.js with Koa; later, we moved it to Go, and after .NET Core 2.1 was released, landed on Giraffe. The “learning experience” part was a success; through all these attempts, we utilized 5 different languages and 3 different database access techniques.

To understand the requirements, a short explanation of the process will help. “Prayer journaling” is a discipline where a person will write down the things for which they are praying; this provides a defined list to help guide their prayer, and helps them not forget things. Then, as the situation changes, they can record updates, through to the resolution of the situation (also called the request being “answered”). This discipline not only helps to focus efforts, it also provides a record of requests and answers. Although people have successfully used a notebook, or something similar, for a long time, that approach does have some downsides:

• For long term requests, you can run out of room for updates.
• A physical journal can only be in one place at one time.
• Answered requests coexist with unanswered requests, so you have to flip pages past them.
• Books can end up under stacks of other things, falling victim to “out of sight, out of mind.”

Looking to address some of those, the initial requirements started as the first three bullets below. The remaining requirements emerged through using the application as it was being developed.

• List unanswered requests, in a way that they can be marked as prayed or answered, and be updated
• List answered requests, and allow full requests (and their history) to be viewed
• Do the above in a way that will not be distracting
• Allow notes to be recorded for a request; not every update on a situation requires a change in the verbiage of the request
• Allow requests to be “snoozed” (removed from the journal, with a specified date when they will reappear), and list snoozed requests so that the snooze can be expired (returning the request to the journal immediately)
• Allow requests to be prioritized (this became the request recurrence feature)

Armed with these requirements, we will pick up next time with a look at the Vue front end.

When I ran Windows as my desktop, I had a program called WebShots that I used to set my desktop wallpaper, and cycle it. They have Windows and Mac versions, but no Linux version yet. They still send me e-mails each week, showing the daily picture selections for each day in the past week. I decided to download the Windows version, and install in under wine to see if it would work. I moved websamp.exe to /home/summersd/.wine/fake_windows, then ran wine C:\\websamp.exe to install the program. wine "C:\\Program Files\\Webshots\\Launcher.exe" then started the desktop control. I used that to disable the tray icon (wine has one, but you can't see it), and I disabled almost every other “auto update” feature.

I had downloaded a “.wbz” file (which is what is imported into WebShots), and I finally figured out how to import it. Running the launcher program, and following it with the name of the .wbz file, imports it. I may figure out a way to automate that, but for now, I know how to do it.

(Note: This is the end of the “My Linux Adventure” series of posts. After this, I ended up going back to Windows XP, just because it worked and I didn't have hobbyist time. As of May 2007, I'm running Ubuntu 7.04 on one computer, and Windows Vista on my laptop, which is currently out of commission.)

I was finally able to resolve my problems with Apache and MySQL. When I decided to mount my FAT32 drive under /home/summersd, I inadvertently caused myself some problems. From talking to a Linux guy at work, I found that no processes that weren't running under my user ID could access those files. The reason is that Linux looks up the entire directory tree, back to /, to determine if you can access the file. So, although I had -rwxrwxrwx summersd summersd on every file, /home/summersd was drwx------ summersd summersd, and /home was drwxr-xr-x. The permissions on /home/summersd were keeping Apache from seeing /home/summersd/drive_d/wwwroot, and MySQL from seeing or writing to /home/summersd/drive_d/mysql/data. I moved the drive to /mnt/drive_d, with the mount point being owned by “root”, still mounting the drive with my user name, and everything worked.

In the process of reconfiguring Thunderbird, I believe I may have found out how to share the address book across operating systems. The file ~/.thunderbird/default.[something]/prefs.js has a listing of all the preferences and settings. I modified this file to change the location of my mail files, and there is a setting there for an address book (which isn't shown in the configuration dialog - after all, it is 0.7.3…) I'll play with that later - right now I'm just elated to have Apache and MySQL working again.

foobar2000 is about the best, most organized audio player I've found. However, it is a Windows application, and according to what I've read, very reliant on Microsoft C++ extensions. I decided to give it a shot under wine, and it works great! There is a repaint problem - sometimes the playlist doesn't refresh as it should. But, it's pretty much a start-and-minimize sort of application, so that's acceptable.

We're speedily working towards a Friday deadline at work, so tonight I had some analysis work to do on some COBOL code. Great, I thought, I can use my VSlick setup under wine. I moved my computer from the living room back to our now-empty bedroom (soon to be nursery), and booted it up. Kernel panics galore - never got past the network stuff. When I booted to Windows, I found that the wireless network didn't reach that far, and I'm guessing that the ndiswrapper folks haven't tried their driver a lot with a wireless card, but no wireless network. Once I get past that, I may grab the dumps from these kernel panics and see if the developers need them to see what went wrong. So, for tonight, I had to use WXP (in which I actually had to disable the wireless connection - seems Windows doesn't handle a barely-there wireless connection much better than Linux).

The diagnostics I ran last night never found anything - they ran for about 10 hours. I suppose I'll just have to wait until I have problems again, then run it right then. Another person from the WBEL users list suggested I check the way I have my hard drives set up; he thinks that a 2GB drive slaved to a 20GB drive may be causing conflicts, which would cause freezes or panics.

At work, we use an editor called Visual SlickEdit (VSlick). It's got a lot of features, and supports color-coding for many different languages. I decided that I'd give wine another shot, as we only have the Windows version of this program. I installed wine and winesetuptk, used winesetuptk to configure the installation, then ran the installation program. Everything installed, and the program ran up to a point, when it started complaining about a missing DLL. I booted to WXP, found the DLL, copied it to the FAT32 drive, rebooted to Linux, and copied the DLL into the “fake windows” system directory. Soon, it was working great! I can't believe it - success with wine!

I also have made little headway towards getting Apache and MySQL to working. I changed the process that Apache uses to run as “summersd”, and I was able to see pages (although any pages that relied on a database didn't work). I still haven't figured this one out yet…

I'm still getting kernel panics from time to time, and it seems to be whenever I access networking. A suggestion from one of the folks on the WBEL users list was to download the Ultimate Boot CD, filled with diagnostic programs. I downloaded it, burned it, and ran some memory checks. Those checked out, so I'm going to run a “CPU Burn-In” program to see if it can detect errors from the CPU. It runs for up to 7 days, but I think I'll just run it overnight - folding@home didn't take nearly that long to crash it before.