I'm a full-stack web developer, and this is my blog. Please connect with me on LinkedIn or visit my Github for more!

Projects

> > >All projects
  • Common Errors When Developing for Fitbit

    Or maybe just common to me?

    Image of the Fitbit developer bridge on a watch

    Problem:

    Install failed: RPC call to 'app.install.stream.begin' could not be completed as the RPC stream is closed

    Cause:

    Jury’s out on what causes this. It seems to happen when I sleep my laptop; the Fitbit simulator doesn’t seem to be able to recover.

    Solution:

    Remove ~/Library/Application\ Support/Fitbit\ OS\ Simulator/, which contains caches, preferences, etc. You’ll have to reset your preferences afterwards of course.

    Read on →

  • Developing for the Fitbit Versa

    In my previous post I said something about learning Android app development so I could make a Fitbit app. However, silly me– just because Google owns Fitbit now does not mean that Fitbits run Android. (:

    Android Wear is what powers Google-owned smartwatches, but if you have a vanilla Fitbit like I do, it’s Fitbit OS. Clear as mud. The upshot, however, is that if you want to write an app for Fitbit OS, you can use plain ol’ Node. So that’s what we’ll do today.

    Fitbit’s dev page has a good tutorial which we’ll follow. First, make sure you have node installed, and have downloaded the Fitbit simulator. (Links on Fitbit’s page.) Then, run npx create-fitbit-app my-app to get started. For this blog post I’m following Fitbit’s instructions so the prompts to answer are clock, any name, no companion.

    cd into your newly created directory.

    I’m developing this app for my personal use (for now) and my Fitbit is a Versa 2, running the “mira” version of Fitbit OS. The default settings for npx create-fitbit-app assume I have at least a Versa 3. To get my new app onto the Versa 2 simulator (and ultimately onto my wrist) I have to edit my package.json:

    "devDependencies": {
    -    "@fitbit/sdk": "~5.0.0",    
    +    "@fitbit/sdk": "~4.2.0",
    ...
     "buildTargets": [
    -      "atlas",
    -      "vulcan",
    +      "mira"
        ],
    

    According to this forum user we also need to change some filenames in the scaffolded project. We must rename index.view to index.gui, widget.defs to widgets.gui (note the plural change), and edit the contents of widgets.gui to point to /mnt/sysassets/widgets_common.gui instead of the file it points to.

    Also, lol, the highest supported version of node is 16, so make sure you’re using node 16 or lower, preferably with something like nvm so you can go back to the present day easily. (Poor Fitbit!)

    Once you’ve done all that, you should be able to start the fitbit CLI with npx fitbit, then build and (assuming the Fitbit simulator is up and running Mira) install.

    Boom.

    Huh. Aren’t clocks supposed to, uh, tell time?

    Follow the Fitbit getting started tutorial to turn this blank screen into a clock. TLDR: Edit resources/index.gui (remember we renamed this from the .view file used in later SDK versions), styles.css, and app/index.js with the provided code, run build and install (or bi which apparently is shorthand for both) and you get a very nice clock:

    picture of a not-actually-very-nice clock face on the fitbit simulator

    Okay, it’s… fine. But hey, it’s up and running. Now let’s do something cooler with it… in a future post.

  • Firebase Crashlytics and Feature Flagging, or What I Learned at WITS Spring 2024

    The following info comes from the Women in Tech Summit which I attended in Philadelphia this weekend. I may type up a more fluffy post about how it felt to attend this conference later, but for now, these are my technical notes from the hands-on session I attended.

    Android app development seems a lot more complex than web-app development. I might be wrong, I’ve built a lot of web apps but no Android apps. (Yet; I just got a Fitbit Versa and feel like that postage-stamp-sized screen is crying out for me to do something with. Apparently it doesn’t run DOOM yet…)

    Anyway, making an app run on the hugely fragmented Android ecosystem, as well as keeping users’ versions up to date (including forcing them to update if there’s a critical security fix) seems like a huge problem. Presumably there are enterprise solutions for this but in my hypothetical DOOM-on-Fitbit scenario where it’s just me, what’s the solution?

    Google Firebase has some great options for solving these problems, which I learned about from two Comcast engineers. Crashlytics can help track and centralize crash data from multiple devices, and Remote Config can manage some app features without having to publish a new version of the app.

    Read on →

  • Local Firebase, or, how I learned to stop trashing my prod db

    Noodle has a lot of the hallmarks of a solo dev side project, which is fair, because it is. Stupid simple deploy pipeline (which is probably a good thing), no tests to speak of (probably not a good thing), no real dev environment. That means when I test Noodle locally I hook up to the prod Firebase db, and usually end up writing a lot of bogus data to it along the lines of:

    • “test event”
    • “test event 2”
    • “asfdkf;;; why wont you work”

    and so on. This isn’t really a problem, as Firebase lets me have a GB of data before I have to start paying them – that is a lot of JSON – but it’s kinda messy. And now that I’m converting Noodle to Typescript, I’m doing a lot of testing.

    Enter the Firebase Emulator Suite. I got it set up so I can run a local copy of my database on my machine and not worry about junk data polluting the real database.

    Here’s how I did it.

    Read on →

  • Typescript-ifying Noodle

    Javascript is great because it lets you do anything

    Over the spring and summer, I built Noodle, a minimalist, privacy-focused event scheduling app. (more) My friends and I use it all the time, but development has kinda slowed.

    This is a problem, because if I ever need to fix anything, I’m going to have to go back and remember how the code works, from scratch.

    Javascript is so permissive. It’s great that I can get up and running without having to worry about whether I’m comparing a string to an int, but future me is going to step on that rake, I know it.

    Separately from the conversation I’m having with myself about how to ensure code maintainability without having to remember why I made all the decisions I did, my mentor at work suggested converting the project to Typescript. So that’s two people telling me to do this, so here we are.

    Read on →

> > >Blog archive