Recently I decided to act on an idea that I’ve had for a long time now. I planned, designed, architected, built and deployed a fully-fledged web application in under a week.
That’s right. One Saturday I sat down to start planning the app, the following Friday it was online and I had my first users - they’re just friends and family, but they’re users!
Let’s back up a bit to the ideation phase - 10 years ago I spent a month travelling around Australia with a friend from university. Let’s call him Jim (because I haven’t asked him whether I can use his real name yet). Jim and I each brought big backpacks with us. Enough to carry a few days’ worth of clothes and other items like cards and a dice game that we liked to play called Perudo. The other thing, I later learned, that Jim brought with him, was a little diary that he would write in every day. Just a quick, short summary of what we’d been up to that day, pretty standard for a diary.
Only it wasn’t just that. In that same diary, he had entries from the previous year as well. In this special diary of his, each page represents one specific date, like July 27th and contains 5 slots, one for each of the 5 years, so for 2012, 2013, 2014, 2015 and 2016 in the case of Jim’s diary. He had started his 5-year diary in 2012 and there he was in 2013, travelling around Australia with the very same diary.
At first, I didn’t really get it. It seemed like a nonsense idea. Why not just have separate diaries for each year? That way, you’d have more space to write your entry and be able to give more details. It wasn’t until a year later that it started to make sense. I’d get messages from Jim every few days telling me what we’d been doing on that exact date the year before, while enjoying our travels on the other side of the world. Even the shortest description of those days would bring back vivid memories of the adventures we went on, the sometimes bizarre accommodation we found ourselves in and the interesting people we met along the way. Just a few words, that’s all it needed.
I really liked the idea, so a few years ago, I took up the challenge of keeping a daily diary. I bought myself a 5-year diary like the one Jim had back in 2013, and started on January 1st. It went fine for the first few weeks. I diligently added my daily entry, even when it wasn’t very spectacular or altogether exciting, but I stuck with it.
Eventually, I got a bit lazy and started keeping notes on my phone, that I would transcribe once every now and again. A little while later I got even lazier and started adding my entries in bulk, at first on my phone, backfilling days at a time, and then over into the diary. Well, I’m sure you see where this is going - less than a year after I started, I’d abandoned it. By December 31st, it had already been a few months since the last note on my phone and entry in the diary itself. I failed miserably.
But, I still liked the idea of a 5-year diary so much and I didn’t want to completely rid myself of the idea. In fact, I began to learn that journaling is a good habit to get into it. It helps you to remember things that you learn, it provides an outlet for your emotions when you don’t have any other, so I thought I would give it another try, but this time as a web application. I would’ve gone as far as saying that a mobile app would be ideal but since mobile development is still outside my domain, I stuck with a web app, just for now.
But instead of a 5-year diary, or even a 10-year diary, which takes the idea even further, why not just a forever diary? After all, on the web, you aren’t constrained by the physical bounds of a book like in the real world. So, that was it, I decided to make Forever Diary, a simple web application that would allow me start a journaling habit and also perhaps provide my friend Jim a way to back up his diary entries. At this point, he’s on the 12th year of keeping a daily diary, he’s already on his 3rd book!
I checked in with Jim, explained my idea and asked if he’d like to help me to develop it. I would do all the actual development, of course, but he would provide valuable user feedback for me. So, I had my idea, I even had my first user/tester, but I still didn’t even have an application! I needed a plan to get going.
I devised a 7-phase approach to get me from 0 to a full-on web application that I could consider to be deployed to production. Here are those phases:
- Sketching - create rough sketches of how user interface should look
- Wireframing - create an actual wireframe based on the sketches to move towards something more concrete
- Designing - filling in smaller details such as layout specifics, theme and colour scheme
- Architecting - design the structure of the application from a software perspective
- Tool selection - select the best tools for the job knowing the architectural requirements
- Development - developing the application from scratch
- Deployment - deploying the application to production and launching it to the world
Phase 1: Sketching
Before writing any code, buying a domain, looking into tools or anything that you can call software development, I needed to know what I was actually building. My first step was to get a blank online canvas and just sketch out what the user interface would look like. Diaries are easy in that every page looks more or less the same, so I really only had one screen to design. That made life easier.
It wasn’t detailed, and I still didn’t care about colour schemes or layout architecture, I just wanted to see what would go where. I created a simple header element with some navigation items (just squiggles at this early stage), a side bar with some day navigation (you need a way to turn pages when you don’t have any actual pages), and a main section with the entry input, the date at the top and a save button at the bottom. I included a couple of links to navigate back and forth 1 entire year at a time, keeping in line with how the layout of a 5-year diary allows you to quickly look back to previous year, and the years before that.
It took me all of 30 minutes to get a sketch ready, surely a lot faster than if I’d chosen to start coding it up from scratch, trying to get it ready for production.
Phase 2: Wireframing
Wireframing is not a new idea - it’s essentially a more structured version of a sketch that’s usually done with an actual design tool, rather than freehand, like during my sketching phase. Although, I’d recently heard about a different way to wireframe, and that’s with actual HTML and CSS. I was skeptical at first, because that sounded to me more like the development phase than the design phase. But I gave it a go and I was more than pleasantly surprised by the results.
Not only was this far quicker and simpler than coding for production, but it also suited my skills much better than trying to find and learn a designer-focussed wireframing tool like Miro or similar. Again, this phase took very little time. I wireframes the entry page from my sketch from the previous phase, as well as login and sign up screens, which were very similar to one another.
The code I wrote in the wireframing phase came in handy later when I was really coding the production application. I opted for a more maintainable class naming convention (BEM, in case you’re interested), but mostly just lifted the style attributes from my wireframes straight into my CSS files for the application. To this day, those wireframes remain part of the checked-in code in the repository. I figured, it’s not doing any harm and it actually might illuminate to future developers, or just Future Me, what was going on and how some of those pages came to be.
Phase 3: Designing
I’ll be the first to admit that I’m a really lousy designer. I mean, I really suck. I don’t have an eye for design and I couldn’t tell you really anything about UX. I can maybe understand a little bit about how users think, just from having been a user myself on so many web and mobile applications, but that’s really it. I therefore decided to just skip phase 3 and not bother with the design at all. I chose some colours that I’ve used in the past, stuck with my pretty basic layout and moved on to the next phase.
Phase 4: Architecting
I’ve worked on several applications from scratch, and for each one I’ve benefitted hugely from designing and architecting the database schema ahead of time. It can only be done up to a point, that point being the initial vision of the application because who really knows where it might go in the future. For this application, I was once again lucky. The initial database schema had just 2 tables - users and entries. Still, I charted it out in DBdiagram (this is my favourite tool for this; it’s free and easy to use) and sat and looked at it, thinking about how it might expand in the future. What other features might I add on that could change the fundamental structure. For example, each entry belongs to a user. Pretty uncontroversial, right? But would that change? In some domains, it might look like a user owns something, but then if you want to enable joint or combined ownership over that thing, you need to change it up. In this case, I was happy that it wouldn’t. We don’t tend to share our diaries, so I find it unlikely that I’ll need to cater to that scenario. I was happy with my schema, so I moved on to phase 5.
Phase 5: Tool selection
OK, so I kind of already knew what tools I wanted to use for this, and in a way, I chose to build this project now so that I could use it - full-stack Ruby on Rails. One of my coaching students recently shared her code for a full-stack Rails app that she’s building and it inspired me to get back into it.
I did briefly consider going with my newer stack, which is a Rails API behind a Next.js frontend, which would have also made the jump to supporting a mobile app much smoother, but my goal here was speed, so I stuck with what I knew best.
Phase 6: Development
I really enjoy TDD and I love writing feature specs with RSpec and Capybara in Ruby on Rails. For me, it’s really the easiest way to beat the Blank Slate Effect, a term I’m semi-inventing right now that describes a sort of paralysis that developers have when starting a new project, “Where do I begin?”. Beyond the framework setup with a new Rails project, it’s easy to be struck with this feeling and feel stranded and overwhelmed about the prospect of building a full application. But with TDD and feature specs, it’s really, really simple. You just create a spec file named something sensible, use Capybara to do a bunch of high-level things like visit a URL, type in a field, and hit a button and then make some RSpec assertions about what will happen.
OK, it helps a lot if you know how Rails applications work. I knew I’d be writing an assertion about a flash message appearing. I knew how to do all the Capybara-y things and so I just got going. My first test was failing for quite a while, but every error message moved me in the right direction.
“What’s that? You don’t know this URL? OK, I’ll create it in my routes.rb file.”
“There’s no controller called EntriesController? I’ll just generate it then!”
“No edit action in the controller, alright, I’ll add it here”
And so on until I saw green.
Doing this sort of outside-in TDD is a nice way to quickly get the core functionality into the application. Without worrying initially about users or logins or signups, I had the entry functionality in no time at all.
I added the Devise gem, which I’ve written about before, as it works really well in a full-stack Rails app and it just works out of the box. It also integrates well with the test suite by providing some nice test controls to sign users in and out.
There were a few more features I wanted to build out, like the Today link in the navigation. I felt that going directly to today’s entry would be a really valuable feature, and at first I made a faux-pas by trying to implement this on the routing level. I realised this wasn’t really a great approach and I moved it into the controller level. This also made testing a lot easier, as I could easily test the today action at the controller level using the travel_to built-in Rails test helper for manipulating time.
When I was mostly happy with the styling, basic as it might have been, and the functionality I’d added, I moved onto phase 7.
Phase 7: Deployment
I’ve used fly.io once or twice before and I liked how quick it was to get started. No need to build your own Dockerfile or other deployment configuration, fly takes care of it all for you with their CLI. It’s configurable, so even though you take their assumptions at first, you can easily customise it.
I started by just using their default URL that comes with the application but quickly thought that my own domain, even a temporary one, would look a lot better. I looked around a bit and finally opted for foreverdiary.online. It’s not a perfect domain, It’s a bit long, for one thing, but it’s easy enough to remember. I also thought that journal might be a better word since it’s used more in the USA and therefore is internationally accepted rather than diary, but being from the UK and catering primarily to my friend, Jim, I stuck with diary.
Jim started using it pretty much straight away, adding his current entries and even backdating it for the last 7 years. He told me it took him about ten minutes to do 7 years of one particular date.
And that’s pretty much it! In 7 pretty straight-forward phases, I took the Forever Diary from ideation to deployment in just one week.
The obvious caveat is that it’s not perfect, I still have some loose ends to tie up, such as finding and integration an email service provider to send emails like reset password and perhaps other emails, like reminders, in the future, but overall it’s in a stable state, and best of all, it’s really well tested, so I have a high level of confidence that it won’t break with my future updates.
If you’ve made it this far, thanks for sticking with me, and feel free to check it out here: foreverdiary.online