F1.zone

I don't want to get bogged down with a bunch of proactive technical learning. In general it's awesome, and I'm a big fan of it. It's really the biggest reason I pursue side projects like this one. But my natural instinct is to spend more time learning than building.

In this case I think the better thing to do is go against my usual instincts and do all my learning in a reactive way by learning just what I need to build the very next thing and nothing more.

In that vein, I've settled on the goal of building a minimal end-to-end proof-of-concept. I'll have a DB schema. A Lambda end point to manually push a new item to it, and a live site that pulls items from the DB and displays them. So it's the minimum set of things that will exercise all the major elements of the stack, DB, Lambda, Netlify host, and Elm Client. I have plenty still to learn about a few of these, but I'll only learn what I need to do to get this end-to-end PoC going rather than going through countless (and fascinating) tutorials and docs.

It's been fairly slow going with mostly learning and research and experimentation on the new tech stack. I've bitten off quite a lot with so many net new pieces to me (Go, Elm, FaunaDB, Netlify/JAM).

I've not made a ton of progress validating the one pairing that seems the most tenuous to me, an Elm client to FaunaDB. I did chat with the FaunaDB CEO in their Slack about it. I have spent a lot of time working with and learning about FaunaDB, and it feels a bit early. I still like the project, but maybe better for a 2020 project.

So I have my first stack adjustment. Here's the stack I'm targeting now:

• Client: Elm
• Client Bundler: Parcel
• Client (Elm) Testing: Cypress
• DB: DynamoDB
• PaaS: Netlify + Lambda + AppSync + Cognito
• Lambda Language: Go
• Server (Go) testing: ??

Go seems to have a metric ton of testing options. So I haven't nailed anything down there, but I'm not worried about it. Too few options is a problem. Too many isn't really an issue.

Collected lots of resources and did some research and learning on my chosen technology building blocks (Elm, Go, Lambda, FaunaDB, Netlify). Identified many of the OSS libraries I'll be using. Designed the initial back-end architecture at the highest level. I have a good work break down now.

Still need some due diligence on Elm and FaunaDB together. Not seeing much online about these two. Will conduct a quick PoC on the pairing.

The piece I'm probably least convinced about at this point is Netlify. It provides a buffer to AWS that I'm not sure I need. I'm AWS savvy and can presumably use Lambda directly and static hosting from AWS. Need to do more digging into Netlify.

Spent the last couple of days checking over my notes where I capture things I want to learn, and doing research on them.

I'm torn between using a tech stack I'm intimately familiar with to speed things along, and using this project as a chance to learn things I've been wanting to learn. When it comes to new tech, the absolute best way to learn is to attempt to apply the tech in anger on something real.

You don't have a ton of chances to learn new things in that deep way, since most projects you work on are long term and the tech gets locked in fairly early. So I decided I can't pass up this opportunity, and that I'm going to use a tech stack built entirely off stuff from my "want to learn/try" list.

• Web Client: Elm
• DB: FaunaDB
• PaaS: Netlify + Lambda
• Lambda Language: Go

I've yet to decide on a CSS framework. Contenders are Bulma and Tailwinds.

F1.zone is to be an instance of an open source personalized news aggregator. F1.zone is a source of requirements to the open source project, but any number of personalized content aggregation sites can be stood up from the open source project.

Today the open source project got a name and a GitHub home. It's called Personal Gator (Personal aggreGator) and it's at: https://github.com/Personal-Gator

I have my own set of product development stages that go before and beyond the MVP. They are:

• MUP - minimum usable product
• MVP - minimum viable product
• MLP - minimum lovable product
• MSP - minimum scalable product

Before worrying about building your MVP, you need to build your MUP.

There's nothing "viable" about an MUP. But there is the first possible increment of something useful in it. It's "usable" to solve a problem your product is meant to solve.

It might be manual. It might be horrible. It might be buggy. It might be 10x worse than solving the problem in any another way, but it's at least usable. No one else might ever use it, but you use it.

By using your MUP, you experience its shortcomings and understand how it needs to be improved. You know why it's not yet viable. With an MUP you get to point where you are reacting to a real thing, not vague ideas, documents, sketches and diagrams. It's a critical step.

Today I defined what my MUP will do (but not yet how it will do it).

The 2020 Australian GP is the start of the 2020 F1 season. It's Thursday March 12th, 2020. I'll be launching F1.zone at least 1 week before that, which gives me a launch date of March 7th, 2020. That's 154 days from now. I've budgeted 1 hour per day for this project. So that's 154 hours.

Prioritize Fiercely