Table of Contents
This is a summary of TinyDevCRM development for the week of March 7th, 2020 to March 14th, 2020.
Goals from last week
- [❓] Ship some form of backend to AWS Elastic Beanstalk to get a full-stack workflow going in production
- [❓] Figure out how to use PostgreSQL instead of SQLite for Django while self-deploying instance (i.e. don't use RDS)
- [❓] Talk to at least 1 person on my early adopters list in order to build accountability
What I got done this week
- [❌] Ship some form of backend to AWS Elastic Beanstalk to get a full-stack workflow going in production
- [✔] Figure out how to use PostgreSQL instead of SQLite for Django while self-deploying instance (i.e. don't use RDS)
- [❌] Talk to at least 1 person on my early adopters list in order to build accountability
- Weeks to launch (primary KPI): 2 (has been at 2 for the past 4 weeks or so + 1 week after declared KPI)
- Users talked to: 0
Hour by hour journal
56h 11m (64% productive); 18h 17m “software development”, 8h 24m “communications and scheduling”
Goals for next week
- Finish a tutorial on shipping a webapp backend to AWS Fargate + AWS Elastic Container Service (ECS)
- Apply learnings from that tutorial to original Docker Compose tutorial completed last week
- Apply learnings from both tutorials to TinyDevCRM API and launch something to AWS ECS
- Finalize basic authentication workflows and configuration work between backend / frontend and dev / production
- Update front-end dashboard and auth pages with necessary pages + mobile responsiveness for MVP
- Soft launch MVP by talking to one person from my early adopters list
- Update landing page using https://landing.ant.design
Things I've learned this week
I really like just-in-time learning. Here's one definition of just-in-time learning:
Just-in-time learning systems deliver training to workers when and where they need it. Rather than sitting through hours of traditional classroom training, users can tap into Web-based tutorials, interactive CD-ROMs and other tools to zero in on just the information they need to solve problems, perform specific tasks or quickly update their skills.
I think when I'm looking back to my learnings with Haskell, or all the other books I've reviewed in the past, a big, big problem is how I don't really remember the information because I haven't applied it. With “The Haskell Book” or any book with exercises it's a bit better, but without having a long-term, core application it's difficult if not impossible to remember things. I think this means I burn a lot of hours learning things that I may quickly forget, such as how to execute on a user story map, where I have to dig the book back out of my archives. I can afford to do this now since I'm not too time-constrained (though I should artificially constrain myself to make my perception of time more valuable), but it severely reduces my productivity and resource utilization numbers, which impacts my personal efficacy. It's also not sustainable, not only for when this sabbatical period ends, but also when my free time is taken up by a wife and kids (which is my ideal usage of free time).
Don't use AWS Elastic Beanstalk. I thought it'd be friendlier to beginners and newbies like me, but after using it, I soured on the concept of having others manage your application backend toolchains. You don't control your dependencies, which means if you have a different version of Django than the one AWS EB ships with, you might encounter conflicts that prevent your app from shipping. The infrastructure isn't idempotent, so every
eb deploybuilds on the existing state of the application without having a clear rollback strategy. There's also the issue of integrating AWS EB with databases other than AWS RDS. Unless you're building something for a hackathon or a proof of concept, or you are AWS-native and want to integrate AWS EB with your own AMIs (maybe using something like EC2 image builder), Elastic Beanstalk introduces a high level of vendor lock-in and an even higher level of ops overhead.
Docker Compose is pretty nice. It's containerized, but still targeted towards applications that are single-host, as opposed to multi-host orchestration frameworks like Docker Swarm or the very popular Kubernetes. You can do the same thing as Docker Compose as the Docker CLI, it's just YAML files and syntactic sugar. I messed up initially at certain points (chronicled in my hourly journal), but mistakes took hours to fix vs. days, and there ultimately was a fix, and that fix worked reliably and as expected. It's a world of difference. You can use
ecs-cli composewith AWS-specific keys in your YAML configuration, and template that using a script, as a waypoint towards infrastruture-as-code using AWS CloudFormation.
Configuration management is such a PITA. Every framework, literally every framework, has a set of configurations that need to be managed. Django has a
ecs-cli composehas a modified
docker-compose.yml, and dependent AWS services also have their own configurations. I could have a backend without all this configuration overhead (say use Heroku or Render), but I'd pay a premium for such services and there's the issue of possible vendor lock-in, I'd burn time trying to understand what's going on for vendor-specific config options instead of say
nginx.conf, and I wouldn't really know what's out there per-se.
If I'm building a product and looking to monetize immediately off the bat, then hell no this isn't worth it. It's a lot of pain for very little gain. But if I'm going to build a tool for myself to last the next 50 years, and I want to trust my stack and what it does, I think this could count as time well spent. I think for me, this is the hard thing about hard things; it costs time and energy where little of either is to be found or spared, and ultimately it is the belief this project will succeed and should succeed that will be the deciding factor in whether I prevail.
Here's to the week ahead 🍷