In my last post, I created a web application in one month as part of a series of Ruby on Rails projects designed to increase my speed of output for software prototypes. I halved the available time to two weeks with this most recent project, Phasmid. As of Monday, July 14th, Phasmid is complete and now I can say I’m officially halfway done with my goal of making four Rails projects.
Progress on the 1212 train
✅ Complete a project within 1 month (Bloggington) (~60 hours of focused work)
✅ Complete another project within 2 weeks (Phasmid) (~50 hours of focused work)
🚧Complete another within 1 week (Start day TBD)
🚧Complete a final project within 2 days (Start day TBD)
The grand goal at the end of this four-project process is to be more comfortable publicly shipping Rails web apps without the worry of burning myself out from lack of technical skill.
So what is Phasmid?
Phasmid is a simple bug tracking application. To be clear, it is a blatant reinvention of the wheel and is not meant to help anyone but myself. The features are as follows:
- Users can create projects which have sets of bugs
- Each project has a pool of tags that can be attached to bugs
- Tags have a weight value, and bugs can have any number of tags
- The multiplied weight of all tags attached to a bug determines the bug’s score
- A higher bug score indicates a more concerning bug with (ideally) a higher priority
Having completed the one-month project, I went into Phasmid with valuable knowledge. I found that I was writing out code snippets before having to reference online sources for clarification on syntax and function parameters. Sure, it still took me some time to figure things out. However, the burden of learning the fundamentals was considerably lighter this time around; this gave me more bandwidth to learn new things.
As a side note, I shared this project with my public discord server. It was great to have others test it in a call and get real feedback!
Here is a simple demo video where I click around a bit. Note, there is no sound.
How it all went
Making the database
Starting out, I had issues wiring together relationships using join tables. I suspect that database wrangling will be easier next time, especially since I can use Phasmid as reference when I work on my next project. Part of my issue was generating scaffolds for models without considering that some models would be nested under each other. This led to a bunch of backtracking before I got things right where they needed to be.
The teeny smidge of testing
All good software should be released out the gate with testing. While I had a feeling I would not have time for a full test suite, I did want to get system tests running. After some messing around with my WSL instance, I was able to get it working. I made a simple system test where a project is created and then it asserts that the project was indeed created. It’s not much, but at least now I have a starting point when I test more in the future.
Freedom to format
I spent a decent amount of time writing the HTML and CSS of the web app. It was surprisingly fun and I felt far more in control of how things fell into place than how I did with Bloggington. I got my hands dirty with designing the web page using a simple grid system and a custom color palette.
When I was in the weeds of the last stretch, being able to work on something a tad more straightforward like HTML/CSS had huge returns on morale. It felt great to have a web app that had its own style and did not look like a complete disaster.
The wonderfully dense hour
On July 4th I saw the greatest evidence of my improvement. In the course of an hour, I implemented two features which took me multiple days to figure out the first time around with Bloggington. This was a huge win, and represented a speed boost by an order of magnitude. For the curious, it was these two commits (1, 2). They both involve real time updates on form submissions using Turbo and Action Cable.
The last stretch
It’s crazy how wide the gap gets between the size of a to-do list and your true velocity. This became readily apparent towards the end. There were also times where I was not sure what the priority should be.
I tried to deal with the difficulty through this lens: if there were an audience of just me, what would that audience want that would help the most with bug tracking? Even as myself, it was hard to know what I wanted. It turned out I had no idea what I wanted other than “thing that tracks bugs.” This does give me a little bit of a peek into what building for a customer would be like.
My takeaway was this: get a solid core out there and don’t worry about the rest. Remember, people don’t know and don’t care about what features were cut in your first iteration.
Cut features
Memberships
My original goal was to have users be members of projects with specific sets of permissions. The database had the pieces in place for it, but I never got around to it.
Instead, people can see all projects/bugs but can only edit things they own. If this was being monetized, people may not even want that if it became a platform that was more focused on transparency. In that case, not having done it may have been better. You can always adjust later if the opposite is true.
Fancy flash messages using Stimulus
When things were created, deleted, or something failed, I wanted a fancy bubble to show up describing said things. Sadly, that also did not make it. It was more of a nice-to-have, and I settled for the default Rails way of logging flash messages on the screen, a good ol’ paragraph tag.
Improved UI
The UI is vastly improved compared to Bloggington. For example:
Bloggington
Phasmid
Room for improvement
Next time, I want to build with a mobile-first approach. Phasmid is a bit awkward on mobile, though it is still reasonably usable. I also want to make sure that the web app works just as well without any of the fancy Hotwire SPA-like features.
Findings
So what did I learn? In 2 weeks, I can construct a project that at least resembles something useful. I picked up these topics while making Phasmid:
- Action Cable and redis
- Getting system tests to run with WSL
- Grid layout basics
- Adding a new font
- Simple time zones
- CSS
That’s 6 things I didn’t know much about in my first project.
Expectations for the one-week project
While I improved my input by roughly 10 hours during the 2-week project, my available time is going to be cut in half. To give some perspective:
| Project | Time Window | Hours Worked | % of Total Time |
| Bloggington | 1 month (~730 hrs) | ~60 hrs | 8.2% |
| Phasmid | 2 weeks (~336 hrs) | ~50 hrs | 14.8% |
| Project 3 | 1 week (~168 hrs) | TBD, but ideally 25 hrs | TBD, but ideally 14.8% |
Even if my efficiency improves where it takes 10 fewer hours to get the same output as I did with Phasmid, I would still need 40 hours in theory. And I’m not going to have those hours. 25 hours is 3.5 hours every day of the week if I want to at least maintain same the ratio from Phasmid.
Whatever my next project is, it will need to be incredibly laser focused if I want to make something of value. I have some ideas.
Project 3 is where real challenge begins.