Table of Contents
This is a summary of TinyDevCRM development for the week of February 8th, 2020 to February 15th, 2020.
Goals for last week
- [❓] Published two technical reviews on this blog
- [❓] Re-do the landing page to reflect updated value proposition
- [❓] Purchase Balsamiq Cloud license and wireframe UI/UX workflows
- [❓] Create IEEE-830.1998 technical specification
- [❓] Work out process evolution roadmap (CI/CD pipelines, technical documentation, etc.)
What I got done this week
- [✔] Published one technical review on this blog
- [✔] Re-did landing page to reflect updated value proposition
- [✔] Started new space on Balsamiq Cloud for TinyDevCRM
- [❌] Published second technical review on this blog
- [❌] Wireframe UI/UX workflows for complete application workflow
- [❌] Create IEEE-830.1998 technical specification
- [❌] Work out process evolution roadmap (CI/CD pipelines, technical documentation, etc.)
Goals for next week (February 22nd, 2020)
- [❓] Work through React.js tutorial
- [❓] Work through TypeScript tutorial
- [❓] Understand how pieces of
- [❓] Build out working, full-stack, email-based, token-based
authentication workflow with a blank dashboard for
- [❓] “Sign Up” page
- [❓] “Log In” page
- [❓] “Forgot Password” page
- [❓] “Confirm Email” page
- [❓] Blank dashboard
Things I've learned
Processes are highly onerous. I was going to create all the structure up front, but man is it exhausting and not worth the effort. I think it's the perfectionist streak in me that tries to lock everything down before I've even started, and part of the reason why I don't have too much to show for this week (as opposed to last week).
Instead of the full specification, I'm going to make living Markdown documents instead, and instead of full Balsamiq wireframes, I'll apply Post-It Notes and User Story Mapping on my apartment wall and draw out workflows on my notepad, to increase my personal resource utilization and get something off the ground. I'll see if I can lock down things and formalize processes after I reach feature parity, but right now if I don't ship, it won't matter.
Admin dashboard templates are expensive, and onerously licensed. You can go on Envato, or Themeforest, and the price of $29 or $49 might be tempting. It's certainly tempting to me, since I don't care for clients too much and my full-stack skills have atrophied a good deal. Then you look at the licensing, and you see “this is for free projects only”. Okay, so how much for a project that could be commercialized? I want this option, if only because I'm a bit terrified of operational expenses.
$700, easy. And that's for one project, if you want to use the template for a different project that could be commercialized and want to avoid all notion of liability, you have to pay for the template again. Yeah no. No wonder the “we're used by” field doesn't have any noticeable companies in the byline. Scrappy open-source projects just can't spend that kind of money on a template. They (or I) might spend it on a full-fledged solution, like Bullet Train, where you could conceivably replace a developer with yourself and some customer support and achieve double-digit cost savings, if the darn thing itself was monetizable. That's not the case (or intention) at the moment, so I need to find something that's much more passively licensed and less headache-inducing.
I kept searching, and remembered tabler.io, an MIT-licensed dashboard. One thing I really like about Tabler is how it handles tables, especially complex workflows involving data and how it appears on mobile. In particular, there's a dev preview that has a lot of the features I desperately missed from the original preview. I decided to donate $5 / mo. to @codecalm via GitHub Sponsors.
Then I remembered that at my last company, the full-stack engineers used this thing called Ant Design. I checked it out and woah. Much pretty, such wow. It has more stars on GitHub than Material UI, and has better fit and finish than Material UI (the UI framework I used for Traveltile). Better yet, it natively supports data visualizations, and also supports a dashboard view with clear Unicode support (Mandarin characters throughout). It's all MIT licensed. So I'm going to use that, instead. Seriously, I don't think I'm going to switch again, or I'll just have analysis paralysis.
Names are hard. I was trying to create the “optimal” “Sign Up” screen, when I remembered a blog post by @patio11 on falsehoods programmers believe about names. I want to avoid this because I know of its existence already, so took a look at what Stripe does for its signup screen. It just has “Full Name”. I'm guessing it's because a straight-up Unicode bytestring is the only commonality between names all over. I think it's fine if the user's name is only for display purposes. There are better ways to uniquely identify users within a database anyways.
Time is hard. From @patio11's blog post, I also remembered another blog post about falsehoods people believe about time. I'll have to keep in mind that all time in the database should be normalized to UTC+0, and offsets recorded on some granular (maybe per-second if overflow isn't an issue) basis.
Keep SaaS best practices in mind. Mostly 12-factor app, maybe other stuff. I think this fits in with a lot of best practices I keep in mind and execute on already.
I think this wasted time should be tamped down with the discovery of Ant Design Landing. I should be able to put together some components later that fits in well with the theming of the UI components.
(For Bytes by Ying and TinyDevCRM subscribers, despite what I had mentioned in my newsletters, I decided not to push notifications via MailChimp. Most of these updates are pretty boring, and I don't want to bore people with this or that. I've decided to just post these on Hacker News instead and inform people of release notes after the product has launched and is usable.)