We take a look at the main flows through a web application I've been running for over ten years, OxbridgeNotes. You'll see each side of this marketplace, along with its admin area. You'll visit Google Analytics to see the traffic figures, and afterwards we'll return to the command line and analyze the codebase size, showing off some handy tools in the process.
March 22, 2020
Transcribed by Rugo Obi
Welcome to Semicolon&Sons.
Semicolon & Sons produce programming screencasts, depicting actual workflows in real-life code bases instead of toy examples.
On top of this, the emphasis is on the perennial concepts that will remain relevant in ten years, instead of the latest fad framework that will become irrelevant in ten minutes.
This set of videos is called Inside the Muse.
About ten years ago, I launched a web app called Oxbridge Notes.
My goal was to create a highly automated online business, that will enable me to work remotely from wherever I happen to be at the time.
Because of my position as the owner/programmer, I'm at liberty to share the code and also the analytics and marketing statistics...whatever.
That means it provides a rich and interesting case study for a real-life coding project.
I also hope that this would be of particular use to indie hackers, to anyone who hopes to set up something similar for themselves.
Obviously, there's a ton of luck involved, but at the same time I made a lot of mistakes and I think others could learn from them.
With that, let's leave the comfort of dark mode and hit the browser to check out the website.
Oxbridge Notes is a two-sided marketplace for buying and selling study notes. What's unique about the website is that the focus is on sellers who achieved very high grades in their final exams, especially those that won some sort of prize.
The idea being that a buyer knows they're getting something excellent. So I'm gonna show you the buying process here.
Now I'm using the Vimium plugin. I press 'f
and now the various links have letters beside them.
If I type ss
, we go to Law which is in the bottom corner of the left-hand column. I'm going to do the same thing again to go to administrative law and here we can see a typical product page.
This is a PDF rendering of the notes that somebody can buy and then someone can add them to cart in a very typical sort of flow. Oops... I jumped a bit there.
Let's show the seller side.
So a seller can apply on a page like this. Yes, it's not pretty and it doesn't seem to matter an awful lot because that's where most of the suppliers ….It's the easy side of the marketplace.
They fill in this form, and then our admin gets an email and gets to decide what to do about it.
This is the author's dashboard where they can manage what they have uploaded.
And finally here is the admin dashboard, that I or any virtual assistants I work with can use to manage the website.
You see I've redacted the IP addresses and emails of any customers, so as to protect their identities. On top of that, you'll also notice that it doesn't look very pretty here. But it doesn't matter.
This is just in-house, so what's the point in spending time and budget and maintenance on something that's for your eyes only.
In fact, if I had my way, I would control everything just through a REPL console. However, that doesn't scale out when you get freelancers involved in doing customer service.
Next, I'd like to show you a couple of pages from Google Analytics.
This first one shows the number of users actively browsing the web site right now. This figure is hovering between 6 and 7. I like the idea that at any time of the day there are people on the website, that it's not a ghost town.
Next, let's look at a cumulative score for how many monthly page views there are. As you can see from the graph it's highly cyclical, and tends to move between about 50,000 on the low end and maybe 230,000 at the high end.
This third view shows the distribution of where my traffic comes from. The pie chart shows a huge big blue area which corresponds to organic search .i.e to SEO. The green segment, the next biggest one, 6.9%, is people who directly type in the website. Referral is in red with 1.76% and paid search is in the yellow next to it with 1.65%.
When I launched the website, paid search was 100%. This being a necessity because SEO takes a long time to build. But after a while, nothing can beat SEO for cost-competitiveness.
Anyway, with that, let's return to the console and have a look at the code.
That is a much prettier sight to behold.
Next, I'm going to navigate to the Oxbridge Notes code folder. I like to use a tool called Z, which takes a search Key as an argument; here "ox", and then cds to the most recently accessed directory matching that search string, no matter where it is on your computer.
And there we are, in the Oxbridge notes folder.
I should mention now that I will leave installation instructions for all the tools I show within the screencasts, including Z. They'll appear on Semicolon&Sons
So, this is a Ruby on Rails application. However, the screencasts will in no way be a Ruby on Rails screencasts.
I'm going to avoid the idiosyncrasies of the Ruby language and also the Rails framework. I've toyed around with Laravel and the PHP world, with Python, with React Native, with node, even with C, and I hope I have the perspective to tell the difference between problems that affect every website, web app; you name it, and specific issues and hacks for a given framework. The kind of knowledge that is going to go out of date.
But, that said, I'll cheat a little bit right now and use a built-in Rails tool to see a count of how many lines of code are in this project.
Have a guess.
There the results are, at the bottom of the page, in the very last row, you'll see code LOC: 9223. Just a little under 10,000 lines of code.
To put that into perspective, that's about 350 pages in book form. Basically, a novel's worth, which I find to be a reasonable amount of code for one person to manage.
Next, you see, "test lines of code; 4805". I like my testing, although I don't test everything.
Also of interest, if you look at the headers at the top of the screen, you'll see classes and methods in the middle.
Then if you trail your eyes down to the bottom, you'll see there are 330 classes and 1306 methods.
I'm going to use the word count command (wc) to count the number of lines of JavaScript in the project. You'll notice that my shell is filling out the argument in grey. This is due to a plugin called "zsh auto-suggest". It looks at the arguments I parse to a given command in the past and guesses that I want them again.
In order to make use of that, I'm going to press the right arrow key…. and there you go. It's filled out.
This autofill is present because I rehearsed this screencast a little bit earlier. When I run this command, at the bottom of the screen, you can see that I have 1870 lines of JavaScript. That is both test and regular code mixed together.
So, how many commits have I done over the years?
If we do a git log, we'll get all the commits. But that's sort of difficult to work with because it's not one commit per line.
We add a modifier to git log...one line, and then we have one commit per line. This can then be parsed to STDIN or word count, our old friend.
Let me see, there are 6748 commits. But that's not the full story. These commits were heavily front-loaded.
Let's look for example at how many commits occurred in the year 2017, once this was well and truly up and running.
To start off, we are going to use a slightly different format for git log; with a date in short format. This puts dashes between the years and months and makes it easier to parse with other tools.
Next, I'm going to search for the year 2017. As you can see, there is a bit of junk at the bottom. We can disambiguate by adding a hyphen after 2017. That will only match the days on which I committed.
There are some duplicate entries there, so we can take only the unique entries by parsing the output into unique.
Okay, now we're getting there. Those are the individual days I committed to this codebase in 2017.
How many of them were there? 14.
I'm showing you this to emphasize how automated a website or web-business can be and still be up and running.
That's all I have to show you for today.
Next week, I'm going to share my origin story...How 10 years ago when I was 23 and straight out of college, I launched a website and got my first sale within about 3 or 4 weeks.
If this is something that will interest you, please sign up for episode alerts on Semicolon&Sons.com
I may or may not be releasing future episodes on YouTube. I haven't decided what platform I prefer yet, so the safest thing to keep abreast of episode releases is to be on that mailing list.
Thank you for watching.