DEV Community: Peyton Casper

7 Days of Bootstraps: Days 5 and 6

Peyton Casper — Sun, 15 Aug 2021 14:18:38 +0000

On Monday, August 9th I started a challenge for myself to bootstrap a business from the group up during my 7 day vacation. This post documents what I learned and the challenges that I faced on day 5 and 6. The start of my journey with the Remarkable Sidekick is here.

My Lesson

There is a lot of hidden work in the error handling and the non-happy paths.

The adage of focusing on the smallest set of features as possible starts to make a clearer picture. The feature is the relatively easy part, but providing a solid experience around it means handling all the scenarios in which it doesn’t work correctly.

Auth0

While the GCP API Gateway supports authentication, it hooks into an external identity provider like Okta or Auth0. This sent me down the path of exploring Auth0 which I’ve been wanting to use for a while. The experience has been great, so far as they provide a ton of out of the box examples and code.

However, given that I’m planning to use it the basis for account management, I spent a bit more time understanding exactly how it integrates into the broader platform. As a result, I move back to focusing on wrapping up the free features and ensuring that I can package up the application.

Thumbnails

I utilize the NodeJS Sharp library to create thumbnails for each image based on the aspect ratio (4:3) of the Remarkable 2. This allowed me to fix the sizing issue with the image tags. There were some issues leveraging this library as they don’t currently provide an Arm64 version of the library so I had to ensure the proper dependencies where in place for NPM to compile it during the install.

Edge Cases

The last major update was around the Home Screen. As you can see, I spent some time building out a better looking disconnected screen along with providing guidance on how to connect a Remarkable. The good part, is that this will also form a basis for the new user onboarding process.

To make this work properly, I had to handle errors from the NodeSSH library and configure connection timeouts. This allowed me to make the connection process more responsive and detect that status of the connection in the background.

Conclusion

Overall, I’ve made good progress on the offline features, and slightly stalled out around the account management. Hopefully, I can finalize the bundling process today and finish reviewing the Mac and Windows App Store submission process.

Remarkable Sidekick | Twitter

7 Days of Bootstraps: Day 4

Peyton Casper — Fri, 13 Aug 2021 12:11:31 +0000

On Monday, August 9th I started a challenge for myself to bootstrap a business from the group up during my 7 day vacation. This post documents what I learned and the challenges that I faced on day 4. The start of my journey with the Remarkable Sidekick is here.

Lesson of The Day

Move on quickly, when you hit a roadblock.

I ran into an issue when trying to pass images from the front-end to the back-end components of the Remarkable Sidekick. Unfortunately, the IPC interaction works great in an asynchronous mode, but gets a little bit clunky when expecting a response back in a synchronous fashion.

I ended up spending a few hours trying a few different approaches, but ultimately moved on. After returning later, I ended up with a satisfactory approach by centralizing the error handling. Such that no individual request will handle their own errors, rather error notifications will be emitted by the IPCConsumer process.

Moving onto other problems, and returning later a bit sooner likely would have saved me some time in the long run.

Early Morning

I spent most of the morning working on implementing the ability to add images locally. This involved base64 encoding the images, passing them to the Electron back-end via IPC and then persisting them to a local directory. In addition to that, I implemented a simple scan of that images directory so that the Remarkable Sidekick is able to populate a 4x4 image grid showcasing the available images that can be set as the lockscreen image.

I still have an open item to define the image height and widths based on the 4:3 aspect ratio of the Remarkable. I played around with this a little, but I think I'm going to have to resize the images to a fixed size, as setting the width and height dynamically isn't providing to best UX.

Afternoon

The afternoon was focused on implementing the first serverless function to handle uploading images to a centralized GCS bucket. In addition to that, I started exploring GCP's API gateway as it offers a few amazing capabilities out of the box. Specifically, it provides authentication, rate limiting, routing and the ability to natively integrate with GCP Cloud functions.

As someone who has worked built out at least two reverse-proxy API gateways, these features can not only be tedious to build, but also challenging to get right. I've been wanting to try out one of the managed API Gateways, so this has turned out to be a perfect chance.

I have not seen this Open API format before, but its a pretty interesting way to define the relative API paths and metadata. Standards can be nice, especially for providing cross platform compatibility, and it does look like AWS and Azure support the same configuration approach based on Open API.

swagger: '2.0'
info:
  title: API_ID optional-string
  description: Remarkable API with Cloud Functions backend
  version: 0.0.1
schemes:
  - https
produces:
  - application/json
paths:
  /image/upload:
    post:
      summary: Allows a user to upload a lockscreen image
      operationId: hello
      x-google-backend:
        address: https://us-east1-remarkable-sidekick.cloudfunctions.net/upload-image
      responses:
        '200':
          description: A successful response
          schema:
            type: string

Progress

Conclusion

We're starting to get into the home stretch and I'll admit that I still have a decent amount of work to do. That being said, I'm almost finish with the initial set of offline features. This should allow me to start identifying the process for submitting this application to both the Mac App Store and the Windows App Store.

I also still have a decent amount of work to do on the API side of things, namely around creating accounts and handling payment information via Stripe.

Remarkable Sidekick | Twitter

7 Days of Bootstraps: Day 3

Peyton Casper — Thu, 12 Aug 2021 11:54:01 +0000

On Monday, August 9th I started a challenge for myself to bootstrap a business from the group up during my 7 day vacation. This post documents what I learned and the challenges that I faced on day 3. The start of my journey with the Remarkable Sidekick is here.

Lesson of the Day

I learned about an interesting quirk with Electron where the backend has to communicate to the front-end via the 1BrowserWindow1. This is in contrast to how the front-end is able to utilize an importable ipcRenderer object which can be pre-loaded.

This leads to an interesting issue in which the window has to either be injected into the objects that need to communicate or it has to be persisted as a global object. I'm not a terribly large fan of this design choice as the ipcRenderer method clearly provides the most flexibility. I'm not sure if this is due to an early design decision, but I'm hoping to do some research into this in the coming days, and understand why this choice was made.

Early Morning

I got off to a quick start by adding support for establishing the SSH connection between the Remarkable and the Remarkable Sidekick. This was a building block for the next major milestone which was dynamically pulling the current lockscreen PNG at startup. In the screenshot above, the Remarkable Model on screen is actually fully dynamic. This work also laid the groundwork for uploading new lockscreen images which will be the primary focus for tomorrow.

Mid Day

Towards the middle of the day, I began working on pulling storage stats from the Remarkable. This was a rather interesting task, as I essentially needed to run df using the SSH connection and then parse the stdout output that is returned.

This resulted in a pretty fun block of code that I am decently proud of. Essentially, we break each line out by newlines, split those lines by spaces and then filter out pure spaces from our result. Once we had our array of arrays that represents the content on each line, I was able to iterate through the each line and pull the used and available space for each path on the device.

After that was done, all that was left was to hook this data up via IPC and send it to the frontend.

const output = result.split('\n').map((line) => {
    return line.split(" ").filter((word) => {
        if(word != ' ')
            return word
    })
})

let paths: Path[] = []

let usedSpace = 0
let availableSpace = 0

for (let i = 1; i < output.length; i++) {
    const o = output[i]
    const pathUsed = parseFloat(o[2])
    const pathAvailable = parseFloat(o[3])

    usedSpace += pathUsed
    availableSpace += pathAvailable

    paths.push({
        used:       pathUsed,
        available:  pathAvailable,
        path:       o[5],

    })
}

Afternoon

Once I had all of the storage data available in the frontend, I was able to quickly wire this up to a progress bar and show the available amount of space left on the device.

To wrap up the day, I was able to get the navigation in place for the Local and Gallery lockscreen management screen. This was an exciting milestone as tomorrow I should be finished with all of the offline capabilities of the MVP. Ideally, I'll be able to get a head start on designing account management and the Gallery feature which will allow users to shared black and white lockscreen images as paying customers.

Progress

Wrap Up

Overall, the day went by rather quick, but the pace at which I was able to add new features was much faster than Monday and Tuesday. This was a good sign that signals the framework that was put into place is starting to payoff. Here is to getting the first paying feature working tomorrow!

Remarkable Sidekick | Twitter

7 Days of Bootstraps: Day 2

Peyton Casper — Wed, 11 Aug 2021 11:41:47 +0000

On Monday, August 9th I started a challenge for myself to bootstrap a business from the group up during my 7 day vacation. I'll be documenting what I learned and the challenges that I faced on day 2. The start of my journey with the Remarkable Sidekick is here.

Lesson of the Day

Today was filled with a ton of technical work. The largest learning I made today was around how Electron works compared to a typical React application. I was running into a really odd issue on Monday where Event Listeners and components were not unmounting correctly. If bump into this post at a later date with the error message below.

Warning: Can't perform a React state update on an unmounted component.

You're likely adding your loading your React application twice. Typically, a React app requires the bundled JS file to be loaded via a script tag inside of your index.html file. Electron handles this for you automatically and by also including it manually, it causes multiple instances of components to exist and affects how event listeners and mount/unmount actions work.

Early Morning

I spent most of the morning working on understanding how IPC communication works between the NodeJS backend and Javascript based frontend. This is a rather interesting aspect of Electron, in that it contains both a server backend and client-side front-end compiled into a single binary. Where as traditionally, you would leverage a library like axios to communicate with a backend that hosts your client-side JS, Electron actually has a messaging library built in.

However, there are some additional factors around security to keep in mind. When you're just getting started, you're likely to run across examples in which ipcRenderer is imported directly into your front-end application. The problem is that this requires nodeIntegration to be set to true which opens up a security vulnerability, because any NodeJS library can be called via any front-end code.

To resolve this security hole, Electron utilizes a preload.js file which essentially compiles down these NodeJS functions and attaches them to the window context in the browser.

Mid Day

After building out a skeleton for communication back and forth, I moved onto loading and saving settings for the application. Each OS obviously has a different preferred location for storing local files, and Electron provides a nice helper function for grabbing this directory that is generic to the underlying OS.

const userDataPath = electron.app.getPath('userData');

Once I created simple functions for loading and saving a JSON file from disk, I was then able to wrap up this interaction into a settings module.

Typescript Side Note

Typescript's ability to not only create a union of types but also create new types on the fly is incredibly powerful. In the example below, I get extremely granular type checking on the what type of value a string will support.

Afternoon

Towards the end of the day, I shifted my focus towards combining the previous concepts together. This involved adding two new message types get_settings and save_settings which allow me to pass settings objects back and forth between the front-end and back-end components.

I now have access to persistent connection settings and allowed me to build out the UI screenshot that is shown below. This also sets me up nicely to get a running start on the NodeSSH integration which will allow me to start pulling information about the device such as the current lock screen, used disk space and more.

Progress

It was a heads down day, with some additional skeleton building that I had to do around page navigation and IPC communication. That being said, I'm in a great position to get lockscreen management in place by the end of the day.

RemarkableSidekick | Twitter

7 Days of Bootstraps: Day 1

Peyton Casper — Tue, 10 Aug 2021 12:31:21 +0000

On Monday, August 9th I started a challenge for myself to bootstrap a business during my 7 day vacation. The reasons why and more details on the Remarkable Sidekick can be found here.

Lesson of the Day

I refactored too early… The developer says with a grimace on their face.

While helpful for development, I lost a decent amount of time towards the end of the day.

Early Morning

Skeletons

I accomplished my goal for the morning which was to get a barebones skeleton in place leveraging Tailwind assets. This proved to be pretty straightforward and using Tailwind CSS brought me back to the days of Bootstrap components.
There is something rather powerful in having a massive library of CSS classes to quickly iterate on style ideas. That is without even getting into the catalog of UI examples to pull from. Overall, my experience with Tailwind UI has been good. Does it beat having a team of designers building out a custom UI library? Not at all, but for rapid prototyping its worked great.

MailChimp

Alright, so technically this came up on Sunday when I was putting together the Marketing site, but I thought this was rather interesting. The CAN-SPAM Act in the US is what requires all email subscriptions to come with an unsubscribe link and forces a company to provide a reachable physical address.
As a consumer, this is pretty awesome. As a solo-dev, the last part kind of sucks.

The Logo

I got the logo towards the end of the morning, overall not bad for $30 and a rush job on Fiverr. Linking to the seller as they did a pretty good job on short notice.

Mid Day

FontAwesome + Styled Components + Tailwind

I started out my afternoon by integrating FontAwesome into the project so that I would have access to a library of Glyphicons. I initially started out by inlining the icon tags with the appropriate classNames but I settled on a pretty nice abstraction that I picked up from the Tailwind library.
The snippet below wraps a simple Icon styled-component in a React FunctionComponent and uses a simple utility function that merges passed in classNames with the appropriate FontAwesome className. This provides a composable Icon component and isolates the integration with FontAwesome to one place.

function fontAwesomeLookup(name: string): string {
    switch(name) {
        case "home":
            return "fa-home"
        case "search":
            return "fa-search"
        case "exchange":
            return "fa-exchange"
        case "random":
            return "fa-random"
        default:
            return "fa-home"
    }
}
export const SolidIcon : React.FunctionComponent<IconComponentProps> = (props) => {
    let className = mergeClassNames("fas", fontAwesomeLookup(props.name))

    if (props.className) {
        className = mergeClassNames(props.className, className)
    }

    return (
        <Icon className={className} fontSize={props.fontSize}/>
    )
}

Interact-able Remarkable Model

Towards the later part of the day, I started on the interaction model for uploading a local lock screen image. This took a little longer than expected due to some issues with the way that Electron handles onMouseOver events and my initial attempt at just leveraging CSS.

I'm still running into a memory leak error, despite removing the event listeners during the unmount. So if you have any ideas, I would love to hear them. The error is below, and you can find the relevant code here.

The Dreaded Refactor

At some point in the afternoon, I stumbled upon electron-webpack and thought it would be the answer to all my ailments around the lack of hot reloading. At the time, I was testing everything in a Chrome browser and then bundling it up before I started the Electron app.

Electron Webpack introduced me to the proper project structure for Electron apps, namely the renderer and main folders. After I made those initial changes, I got sent down a rabbit hole trying to get React, Electron, Typescript and Webpack to play nicely with each other.
After a couple of hours wasted, I finally stumbled upon a decent boilerplate setup that I finished migrating to towards the end of the day.

Progress

Overall, it was a rather productive day, with the bulk of the gruntwork taken care of today. I'm hoping to crank out my first offline features tomorrow and ideally have a downloadable copy of the Remarkable Sidekick to start playing around with outside of the IDE.
Heres to hoping I don't get sidetracked by another refactor. 😄

RemarkableSidekick | Twitter

peytoncasper / remarkable-sidekick

7 Days of Bootstraps

Peyton Casper — Mon, 09 Aug 2021 12:02:01 +0000

On Monday, August 9th, I start a weeklong vacation! But, this is not going to be a typical vacation. I will spend the next seven days building an application called the Remarkable Sidekick, bootstrapping a small business around it, and chronicling the journey.

Why

It is odd to me, having grown up utilizing incredible devices that allow us to create infinite possibilities, which require of us the confidence to explore every possibility. That I struggle to have confidence in things that I create.

Brené Brown's incredible talks introduced me to the "Man in the Arena" speech from Theodore Roosevelt. If you haven't seen her talks or read this quote before, I urge you to take a moment.

I admire people who create in public, whether it's 100 days of code, 12 products in 12 months, open-source maintainers, writers, speakers, researchers, or anyone else who takes the time to showcase what they do and open themselves up to the critic. It is certainly not an easy path, and it's a trait/skill/belief that I want to improve in myself.

I've recently been reading Zero to Sold by Arvid Kahl, Doing Content Right by Steph Smith, and learning how to write better from David Perell. I want to put these ideas to practice by bootstrapping a small business over seven days and consistently writing about the process every day.

The What

I purchased the Remarkable 2 around 7 months ago, and it was largely driven by a wish to be able to read longer-form writing like academic papers and technical PDFs on a larger E-ink screen. I've since started using it to take notes, draw small diagrams and perform the bulk of my reading.

Overall, the experience has been great, but I wish it had a few additional capabilities, which form the basis for this project. So I figured, let's build something, do it in public, see what happens and learn a lot along the way.

The Audience

It's probably obvious, that this is a small audience. Not only are we talking about E-readers, but 10.3" E-Ink tablets at that. But honestly, it might be just the right size for a 7 day challenge.

Let's take a look.

The two images above show the drastic difference in market size between e-readers like the Kindle and e-ink tablets such as the Remarkable. The Kindle is a generalized device that excels at allowing users to consume traditional books that aren't image-heavy and don't have rich content like code blocks, charts, graphics, and more.
When doing my research before buying the Remarkable 2, I noticed that its users seemed to break down into two main categories.

Handwritten Notetakers - This is the Remarkables primary audience and who Remarkable the company seems to advertise to directly. They accomplish this by providing a distraction-free UI and an incredible writing experience for notes, diagrams, and sketches.
E-Reader for Research and Technical Papers - I did not fit into the first segment. I've certainly used it more for freehanding diagrams over time, but generally, I like the ability to view a paper-sized PDF on a 10.3" screen with all the benefits that E-Ink screens provide related to eye strain. Additionally, Remarkable seems to be branching more into this space. They have recently added smart highlighting that auto-detects text and adapts your highlights to the words rather than just being a drawing on top.

Now that we have narrowed our search down to just E-Ink tablets, I ran a search for the Remarkable, Remarkable 2, Boox, and Supernote, which are the major competitors in this space.

I was initially shocked to see how large of a gap the original Remarkable seemed to have even over its successor. However, after looking at the related queries, I think that is primarily driven by Remarkable 2 owners searching for content and shortening their search to "The Remarkable." We can see that generally, the Remarkable seems to be a leader in this market within the US.

Going Global!

If we zoom out, we can see some hotspots where Boox seems to have an advantage, such as Russia. Baidu has a similar tool to Google Trend Analytics, but I couldn't seem to use it without a Baidu account. I imagine, like Russia, it is dominated by Boox which Onyx, a China based company, manufactures.

SubredditStats

Lastly, I wanted to look at the SubredditStats for each of these devices and get an idea of how strong the community is. Overall, I think it's probably fair to estimate the Remarkable Audience around 20k to 30k strong. Not all Remarkable users are on Reddit and aren't represented by these stats, but similarly, there is likely overlap from users that look for similar content but own a Boox or Supernote device.

Problems

I am a user, which gives me an advantage and biases me towards issues that I personally want to solve. As a result, I'm breaking this section down into features that I personally wanted and insights I gained from looking at our audience data.

Personal Problems

Ecosystem Integration is my largest problem with the Remarkable 2. As I mentioned above, they have recently introduced a new feature that adds smart highlighting, which wraps the digital highlighter marks to the text. However, I want these highlights to be extracted automatically sent to my Notion so that I can track these highlights centrally rather than having to dig through old PDFs or manually save these off.
Sending Articles and Newsletters to my Remarkable is possible via a Chrome browser extension. However, this depends on me manually visiting each web page, converting the page, and then sending it to my device. I wish I could automate this process so that it would convert articles based on links in Asana, which represent articles I want to read that day.

Audience Problems

Custom Lockscreens, as with most devices, seems to be an area of interest for owners. However, there isn't a native way to do this and instead requires a user to SSH into their device and place the image into a specific directory
Custom Templates are similar to Lockscreens in that there isn't a native way to upload them, and they also require the user to bundle them correctly.

Solutions

Now that we have outlined a few problems that we can solve, let's define the solutions.

Barebones

The user should be able to upload a custom lock screen image or template with a single click
The application should be multi-platform
The application should be able to work offline over a USB C connection

Core

A gallery that allows users to share and find awesome lock screen images and templates easily
The user should be able to upload a lock screen image or template from the gallery with a single click
Marketing website
Ability to handle payments

Killer Feature

Leverage the Remarkable Cloud API to scan for document changes, extract highlighted text sections
Emit those highlights to a Zapier integration which can then be used to forward them onto Notion

Stretch Goal

A customizable newsletter capability that allows a user to send their newsletters to a designated email address that compiles them into a daily PDF that is sent to their device

Technology

This is a bit fluid, as I will likely encounter more challenges once we get started, but these are roughly the tools I am looking to use.

Electron - Provides us with native multi-platform support and allows me to leverage my existing Javascript/React skill set.
Tailwind UI - I've wanted to experiment with this for a while, and this provides me an excellent opportunity to learn more about it and leverage off-the-shelf components.
Go - There will be some back-end components I will be writing in Go, but with an eye towards Serverless functions and Google App Run to limit operations.
Zapier Integration - I've never built a Zapier integration before, but the tradeoff is that I can write one integration and gain access to a larger universe of integrations.
Stripe Integration - Similarly to Zapier, I've never built or integrated a payment management system before, but this should do most of the heavy lifting for me.

Some Initial Mockups

Let's Build!

I'll admit, this isn't a typical vacation, but hopefully, I've done a good job of explaining why I'm doing this. I'm equal parts excited and terrified for this week; if you're interested in following along, drop by my Twitter or subscribe for email updates.

Lastly, the goal of this is to make it as open as possible, so the public GitHub repo is below. You can find the initial landing page that I put together last night here.

Failure and success share one thing in common, they both require you to step into the Arena.