Budget Notify – Part 2

Well, I expected I was going to end up with a series of blog posts on Budget Notify when I originally wrote the Part 1 post. I planning on building out a whole frontend and backend system. At the end of the day though, I found an even better solution to my specific problem, so I went with that.

In short, I scrapped the whole server concept and make the entire process run from my iPhone via Shortcuts. My iPhone automatically runs a set of commands daily that load our budget, see if notifications need to be sent, and if so, send them out via Twilio exactly like the server was doing. I could technically remove Twilio and have my iPhone send the notifications from my own phone number via Messages, but I want to keep Twilio for now.

Debugging the shortcut was the most painful part. Now that I have it setup, it’s trouble free and works great, but I spent several days trying to figure out why certain things weren’t working. The main issue I hit is if you make multiple web requests in the same shortcut, the second web request may never finish. I don’t know if that’s a bug in the Shortcut app or if that is as-designed. The first request works fine, but the second looks like it’s firing, but best I can tell, it never actually makes the request at all and just sits there until it times out.

Given that this solution is working fine, I don’t expect I’ll write the blog post series I originally planned. I may post about how I setup the shortcut in case someone else wants to replicate it (and/or I might share the actual shortcut if I refactor it a bit), but that’s likely as far as this series will go at this point.

Budget Notify – Part 1

This is the start of a series of posts as I build out a new project called "Budget Notify". I don’t know how many posts this will take, when it will be finished, or even how often I’ll post an update. I’m going to be learning some new tech during this project, so it seems like a good project to write about – both for my benefit as well as anyone getting started with this same tech.

For today, I thought I’d share a little background on what the project is and why I’m working on it. I plan to get more into the technical side in future posts.

What is Budget Notify?

Budget Notify is a service that monitors your budget and triggers notifications based on various conditions.

Why would I need something like this?

If you’re the main budgeter in your household (or you are the household), then you don’t need a service like this – at least not for yourself. If you have a budget shared by the family, but the rest of the family isn’t as interested in checking the budget like you are, then this can help. If you set a budget for dining out that applies to the whole family, but no one else looks at that budget category before they place an order, the budget isn’t exactly helping.

With Budget Notify, you can set up notifications so if someone picks up Taco Bell on the way home from work, everyone else is notified that the available dining out funds are a bit lower. A notification like this helps people visualize how much is being spent and how much can still be spent on key budget categories. Budget Notify makes it as frictionless as possible to keep everyone aware of your budget.

How does the service know what the "budget" is?

For now, the focus is specifically on YNAB budgets. If you use YouNeedABudget.com, then your budget will work with Budget Notify. In the future, other budgeting systems may be supported, but for two, it’s YNAB only. Why? Well, two good reasons. First, I personally use YNAB so that’s what I need. Second, YNAB has a nice API that makes querying budget data simple.

What’s the new tech stack?

AWS Amplify w/ GraphQL & React. This may be old hat to you, but it’s brand new for me. I’ve written web apps for years, but not with React. I’ve seen GraphQL many times at conferences, but never tried to implement it in a real project. I’ve worked on Azure, but barely touched AWS outside of a few Alexa lamdas and general EC2/S3 usage, so Amplify is going to be all new.

Why use a new (to you) tech stack?

I’ve started this project a couple of times using the tech stack I know – .NET/C# for the code, SQL Server or Postgres for the DB, and a regular Linux VM for the manually maintained server. The reason for Amplify this time is I’m going to need some Amplify experience for my day job in the next 3-6 months. I learn a new tech stack better when I have a specific usage in mind, and this has such a narrow scope (and no specific timeline) that it’ll be a great learning project.

WordPress/PHP Nonsense

fault code -32700 parse error. not well formed

That’s what I’ve been getting when I tried to use any client to connect to my WordPress instance. The WP web UI worked fine and I wasn’t seeing any errors in the dashboard.

I’ve been trying to get back into the habit of using my micro.blog account for a while now, but kept having trouble with the micro.blog apps. I could read just fine, but I couldn’t post to micro.blog via the app (which in turn posts to my self-hosted WP blog).

This process used to work a few months ago and I thought it was a problem with micro.blog itself. After more investigating and some pointers from Manton Reese via Micro.blog support, I finally figured out the issue…

The server was missing the package php-xml. Turns out, WordPress will happily run without it and the xmlrpc endpoint will even respond with XML without it, but it won’t actually work. After doing a quick:

yum install php-xml

I was back in business. I’m surprised WordPress didn’t detect this and point out that a required package was missing. Maybe it did and it just didn’t make it obvious? I’m not really sure, but I see lots of people with the same issue when I search for the solution. I had to dig through several Google results to finally find the answer which was also surprising.

So if you get an error saying “fault code -32700” and “parse error. not well formed”, make sure your php-xml package is installed.