Skip to main content

Codex Audentia

Codex: An ancient manuscript text in book form.
Audentia: Latin for “audacity”.

This is my codex — a working notebook with my notes, experiments, and rambles in their full glory. It is raw, unpolished and unfiltered.

This is not a blog.

You can subscribe to these posts here.

I’m building a 1,000 year company, and writing about the process.

Technical Fluency Course for Non-Engineers

By Rambles No Comments

This is a new project/business idea about teaching non-technical people about modern computing technologies in a rapid fashion without learning to code, to build systems thinking and technical fluency which is way more valuable than writing your first 5000 lines of code.

Inspiration:
Was talking to Taylor Kennon in the gym at 1040 about him getting ripped off by a developer, and offered to explain to him the overall tech ecosystem etc. Prepared a talk about it and gave it in the gym itself a few days later – my first talk was terrible because there wasn’t enough time, but it showed me that this knowledge is actually not easily available anywhere.

Discussions: Dan Frysinger, Derek Pankaew, Vardhan

User Interviews/Advice: Lee Hansen, John Brandes, Garrett Gibbs, Sampath Mallidi

Notes

Lee:

  • Large teams already have dedicated teams to train employees immersively. But small/mid-sized teams could definitely use something like this.
  • The Challenger Sale was quite popular, and its authors created their own practice, selling seminars and training.
  • Sales people aren’t the only people that need it.
  • For sales training, companies simply ask “will this help my chaps make more sales?” And if the answer is “not really” or “indirectly”, then they won’t spend a single dime on it.
  • A lot of university professors are also trying to get into consulting/executive training.

Sampath:

  • Idea definitely has legs.
  • Needs a lot of content marketing.
  • What you predict will rarely happen. You’ll have to adjust and figure out as you go along.
  • Can add other services like Intandemly etc to build a more complete package.
  • Sell to IT services firms etc.
  • There’s a large market and having a high-ticket micro-volume business will leave a lot of opportunity on the table.

Garrett:

  • Validates the idea, thinks it is terrific.
  • Datadog has an extensive immersion program for exactly this training.
  • Smaller companies (<500 people) will benefit much more from this training.
  • Become the trusted engineer, teacher and resource for non-engineers. À la Seth Godin.
  • Create 3 personas of buyers
    • Super niche content
    • Build a following
    • Freemium
  • Start with a very niche field like ML. Nail the entire AI ecosystem – from ML to data pipelines to labeling and infrastructure.

John Brandes:

  • Validates the idea
  • Again, Amazon AWS has an enablement team with online courses and trainings for all sales people.
  • 90 minute cloud practitioner “generalist” certification exam (CloudGuru.com, and other certifications)
  • How Amazon sells: courses like working backwards 101, cost optimization, how to create business case, walk through POC etc, how to use salesforce.
  • You need to be equipped and proficient enough to answer questions to the TOP leadership (the first meeting is all yours). DO NO HARM. Some of those big customers probably know Amazon’s services better than the non-technical account executives. Second meeting you get a team of solutions architects etc.
  • Not gonna have complete mastery for all 174 services. Tech is evolving just too rapidly and non-technical people are falling behind.
  • “The Fuzzy and the Techie” by Scott Hartley. A potential influencer.
  • The rise of “No Code” – Unqork, Airtable etc. (Addendum: Ryan Hoover)

My Thoughts

  • Crystal clear, visualizable learning outcomes are essential. If they can’t see the result already, they won’t spend time and money.
  • There is a clear divide between fuzzys and techies.
  • People don’t want to learn to code.
  • Build credibility through great content and branding.
  • Companies like Rakuten have launched an initiative so that all employees learn to code. So the trend is there – and I have the best solution to the problem.
  • You attract the type of client that you are. If you want a certain type of customer, then be that kind of person yourself.
  • Your customers won’t buy something that you wouldn’t buy for yourself.

What does failure for DenseLayers look like?

By DenseLayers, Rambles No Comments
  1. Nobody wants to read my essays about papers on Medium.
  2. Nobody wants to discuss papers on DenseLayers.
  3. DenseLayers gets sued and forced to shut down or escape.
  4. Site is never able to scale, and becomes/remains a niche community or fancy blog.
  5. Site gets hacked.
  6. Becomes community of spammers, haters and bots.

Questions

  1. Which ones are realistic? All of them
  2. What can be easily/mostly avoided? 3,5,6
  3. What is the Minimum Successful Product? A site that has a new cool paper from DRL every month or so, with my comments. Essentially a community that only includes myself.
  4. Am I okay with minimum success? Yes.

Audiobook Tool Idea

By Rambles No Comments

So I had an idea about how a tool that would allow people to easily record voice versions of their Medium articles, and automatically did the noise removal and balancing etc for them using machine learning. I imagined that most people don’t really want to spend all their time doing audio editing, which is why a lot of online articles don’t have any audio versions on them.

I also imagined that a lot of people would enjoy turning their blog posts into “podcast”-like episodes, but are deterred by all the technical mayhem involved. I feel like recording and hitting “publish” on an audio recording should not be a pain in the ass.

I also spoke to my friend from Cornell, Teddy Reiss who is my expert on all things radio and audio.

Initial design requirements without consulting any users:

  1. Should make recording very easy
  2. Should allow automatic noise removal
  3. An automatic teleprompter that is visually pleasing

I also found out about Play.ht which allows you to let your articles be read by artificial human voices. And another company that is a marketplace for matching authors with aspiring narrators. It seems like being a narrator is a niche career path, and I never knew! Many actors use narration as a side gig, and some actually become popular narrators in their own right.

I decided to do user interviews.

I looked further into other use cases like audiobook publishing, not just online articles. Turns out, the quality requirements for audiobooks are very stringent, and recording one can be quite expensive because it includes a low-noise space, an audio engineer, and sometimes a director and editor. Often the author has to do all of these by themselves.

I decided to post into a few different subreddits, one of them being r/SelfPublish:

https://www.reddit.com/r/selfpublish/comments/gl4olw/recording_your_own_audiobook/

Several people responded, and it seemed like the noise editing for audiobooks is quite difficult to do automatically and there’s plenty of software that allows them to do it. And for audiobooks, anything less than perfect is frowned upon (because the author wants to produce their best work!)

Notes

Learnings

The audiobook “script” is actually different from the book – it is usually especially written for the narrator’s use. Examples:
1. https://www.voices.com/blog/narration-scripts-fiction-genre/
2. https://cchogan.com/audiobook-tips-a-short-guide/preparing-a-script-for-recording/

A more useful thing is the teleprompter and the ability to string together a large number of audio snippets like lego blocks, doing retakes on the fly, managing the files and the editing process.

If the software highlights each passage/section as marked by the author or through line breaks, and smoothly skips from one to another (cutting the audio in the background as soon as the narrator presses the button), it’s almost like a digital director.

Visual elements clearly show the narrator when the audio is being recorded or not, so that they can toggle on or off and learn the keyboard shortcuts quickly.

It could also labels each audio clip with the actual text it contains, and the page and paragraph number (which can also be used as a bookmark on the script!)

The chain of audio can then be exported to be sound-edited in another software package like Audacity or Adobe Pro Tools. Will have to figure that one out.

More notes on how to do Mastering etc

Next steps

I am still not fully convinced about the ideal market, target customer/use cases and feature list for the software, so I need to get a prototype together ASAP and get feedback on it from at least 25 users who are willing to pay $10/month for it, and a 50% discount if they refer someone else.

Wait, I need to figure out the pricing – I can’t just pull a number out of my ass. Intention is the key – remembering how Zapier initially discovered pricing, I don’t want to undercharge for the product, because that’s bad for both me and the end customer (they don’t value it enough).

So one next step is a high-fidelity prototype that can be used for pre-sales purposes – and I’m going to crowdfund this. That is the best possible way of knowing that there is a market.
Advice: https://medium.com/@EndaRunning/create-a-kickstarter-referral-rewards-program-25b8ed12b0aa

Marketing

The marketing plan should ideally have a referral system, because I’d need a large onus of customers to be able to break even and generate some profit. And I’d like to optimize for volume rather than high-ticket, so that I can impact more people.

But wait, what is my real goal here? And I’ll probably need a cofounder, so should be looking into that as well. Ideally someone with a similar passion for helping authors and creators, and someone I can trust. You don’t have to do everything alone, Aman. There are people out there who’d be willing to help you.

FINAL THOUGHTS (July 12)

I gave up on the idea because even the MSP did not excite me enough. The MSP would be very hard to build and still not be something I can be proud of.

DenseLayers Pre-Launch Refresh

By DenseLayers, Rambles No Comments

Using this post to think through all assumptions, strategy and technical decisions made so far about DenseLayers. Deploy date is tomorrow.

Today is 01May2020, and DenseLayers is ready to release minus a few last-minute changes that I keep making. I am in a state where I keep adding one more feature to make it easy to maintain the website once it is out, so that I can focus exclusively on content creation and marketing for the next several weeks.

It is classic scope creep. But in the midst of all the excitement, I need to recollect my thoughts and ideas and get a snapshot of where I’m at.

Strategy Ramble

1. What is DenseLayers and what problem is it solving?

– DenseLayers is a website where people can discuss research papers.
– Most scientists and scholars have to spend a significant chunk of their time crunching papers. I know for a fact my friend in the lab at Cornell said he had to read 200 papers for his project.
Assumption: reading oscillates between ‘skimming’ and being stuck, given the nature of these papers.
– The vision is that reading papers should be a collaborative exercise, done along with everyone else in the world, in the language of your choice, free of cost.

There are some other tools/platforms out there for doing this, such as Fermat’s Library etc, but they don’t solve the same problem or even solve it effectively.

2. How is it different from just using another tool like a subreddit or Google Docs? Why build a custom website?

– I like to control my destiny.
– I can build custom features and innovate out of the box, iterating quickly.
– I can manage the culture of the community by seeding it from the beginning.

3. What is the content and growth strategy?

– I will first begin with Deep Reinforcement Learning as the field I pick papers from. It is a small niche field but with a lot of exciting potential, and a lot of eyeballs on it. DRL is mainly done by a few key groups like DeepMind and OpenAI etc, and they only publish so many papers per year. Growing the site to become the de facto place for high-quality discussions around DRL research is much easier than doing so for a broader field.

– Papers should ideally be only those which are published on arXiv or other open-source journals. I do not wish to endorse or encourage publication in the major paid journals. Open-access is a good selective criteria that also reduces potential legal hurdles, and it makes the appearance of a paper on DenseLayers to be even more of a symbol of quality/novelty. Moreover, open-access journals used to be often considered to have questionable quality of peer review (the perception due to which Springer and Elsevier exist till today). Having a publicly open, transparent discussion platform improves their perception.

– If/once the site is successful at doing this, I can begin to offer a side service like job posts etc to begin generating just enough revenue to sustain the site.

– After that, I can start to expand into other adjacent fields which are interdisciplinary in nature, such as Deep Learning in Neuroscience etc.

– I’d like to focus on fast growth in terms of the quality and depth of discussions, slower growth in terms of papers added from each particular domain, and even slower growth in the number of research domains on the website. Quality is the goose, growth is just eggs. If you let the goose die, the eggs will stop coming. Wow I just came up with a good adage.

4. Talk more about the revenue model and long term plans

– Not entirely sure yet how the site will make money, but so far a job portal sounds very enticing. It’s very much like the StackOverflow model, which was actually an early inspiration for the project. I’ve also studied the models of Reddit, Wikipedia, Quora, Yahoo Answers, Urban Dictionary, Justin.TV among others.
– Finding niche talent from a research domain is hard and expensive, so companies probably need help. I intend to offer it for as cheap as I can as long as the website can stay in business.
– The job posts thing can only happen if the website grows enough.
– But the long term prize is to build the world’s greatest open-access publication platform. Scientific publishing has been staggeringly profitable for way too long. It is time for the giants to fall.

5. Where will I find users?

– I happen to have a relevant following on Medium, and I will soon begin to publish more essays there. Every time I publish a paper on DenseLayers, I will write its breakdown essay there to generate interest – if anyone would like to join the discussion, they can do so.

6. Thoughts on alternatives/competition

– The basic necessity for the solution to grow in usage, is to inherently be useful from day one. Most platforms have a chicken-egg problem. What I can do that others aren’t, is to seed extremely-high quality content in the beginning.

7. Potential problems, Achilles’ heels, etc

– Deepmind and OpenAI themselves also publish long blog posts that clearly explain what they did in each research paper, in a fairly easy to understand way. So do most researchers. So there may not be a big enough need for DenseLayers to attract readers.
Thoughts:
1.
Well, they don’t really offer a consolidated platform where anyone can add their own thoughts, and read multiple papers across companies without having to search around.
2. People will still read research papers.
3. My writing can rival theirs. I’ll try my best.

Technical Ramble

1. Much more beautiful than I intended at first, due to a friend remarking that the design is “terrible”.
2. Decided to use memcached, and then good friend Patrick said I shouldn’t, to avoid unnecessary complications for an MVP that isn’t meant to scale yet. So not using memcached.
3. Will deploy on Heroku, and use SendGrid for email support.
4. Added user moderation. Admin can delete posts that break rules.
5. Decided to show user names on paper page with Gravatars. I guess the friction of not being able to find your own comment is more of a nuisance than anonymity. Will need to add anonymity controls in next update as well as upvotes and downvotes.

Decision Process for Key Metrics for DenseLayers

By DenseLayers, Rambles No Comments

 

The first version of DenseLayers is very close to completion (it’s past the deadline of Dec 31, which makes me disappointed but at the same time I’m glad I’m making a lot of progress and doing it right.

Need to decide what kind of metrics I should be monitoring as the founder, during the crucial initial stage. Using this post to think out loud from first principles and put my ideas on paper, hoping it will help me make sense.

What I want to accomplish

I want to grow the website into a product that people enjoy using, and can imagine themselves using at least on a weekly basis.

This means a few things:

1. They see DL as a place where discussions are of high quality
2. They find the website easy to use

If the above were true, users would respond with by:

1. Visiting the website often
2. Reading their paper in detail
3. Reading other people’s comments posts
4. Adding more of their own comments posts
5. Signing up with an account! (duh)
6. Being nice to each other

I should stick to using the word “post” as opposed to “comments” from now on, since comments are a different feature that will not be in V1.

Possible metrics derived from each of these items:

  1. Overall traffic to different pages
  2. Traffic to different papers
  3. Number of logins per week?
  4. Recurrent visits (monthly active/weekly active/daily active)
  5. % of all signed up users who log in/visit per week
  6. Change in traffic from week to week
  7. How many posts people are writing
  8. Number of posts per paper
  9. Number of users who have ever written a post on a paper
  10. % of people who have visited each paper, who wrote a post
  11. % of visitors per week, who wrote a post
  12. % of contributors who show spammy behaviour

Now – I want to be really careful in choosing my key metrics here. The metrics I choose will trickle down into every other decision I make. They will define the whole strategy. And focusing on the wrong metric can jeopardize long-term sustainability of the DenseLayers community. I could argue that I should definitely be *looking* at all of these metrics (or build in a way to calculate them), but I should make my decisions based on only 1-3 metrics that reflect long-term health and growth, and trump everything else.

My way of choosing the right metrics here would be to go back to the overarching things I want to accomplish. For each metric, I’ll ask the following questions:

1) Does this directly mean users enjoy using DenseLayers?
2) Does this directly mean DenseLayers is a place for high quality discussions?

For the first version of the site, these two are extremely important questions. So let’s go through the list of metrics again:

Overall traffic to different pages
Traffic to different papers
Number of logins per week?
Recurrent visits (monthly active/weekly active/daily active)
% of all signed up users who log in/visit per week
Change in traffic from week to week
How many posts people are writing
Number of posts per paper
Number of users who have ever written a post on a paper
% of people who have visited each paper, who wrote a post
% of visitors per week, who wrote a post
% of contributors who show spammy behaviour

 

The three metrics marked in bold should be the main metrics. Weekly active users is an obvious number, it shows people who enjoy coming to DenseLayers regularly for whatever reason. Number of posts per paper is important because having a paper on DenseLayers is useless if people aren’t discussing it. And then, I want as many people as possible to write posts and not just read them, so the % of weekly visitors who write a post captures that.

I will be calculating and looking at some of the other metrics though. So I can refer to them if I find anomalies in the data.

 

 

Defining the MVP of DenseLayers

By DenseLayers, Rambles No Comments

DenseLayers is a website where people can discuss research papers online, paragraph by paragraph. It is the project I am working on right now, and aim to launch the site by Dec 31. The story of how it came about etc is quite long, but essentially it started with me explaining the AlphaGo paper on Medium. I’ll skip to a more pressing matter – what features should be in the first version of the website. As always, don’t mind if this turns into a rambling post towards the end.

***

As per my philosophy, my first version should have the following qualities:

  1. It should solve a pressing problem at least 4x better than what people do currently.
  2. Doesn’t matter how much friction there is, as long as it solves that problem better than the alternatives.
  3. It’s a proof of concept – a “test”. As a Systems Engineer, I’ve been taught to believe that a good test tells you not just what’s wrong, but also what to do. This means there should be some way to collect feedback (=data) from the MVP.
  4. It should be as intimate and unscalable as possible without becoming a pain in the ass for me. I want to be as close to the website’s users as possible, but don’t want to be overwhelmed. So I need to decide what should be automated and what shouldn’t.

So here it is: the list of features in V1.

Front Page

This page doesn’t need to be flashy. Understanding DenseLayers’ purpose is not rocket science, so I don’t need to put effort into explaining something that’s obvious. For nostalgia, here’s how the site will look in its first iteration (this is a screenshot of what I’ve actually coded up built).

front page first v1

 

1. The front page should have a list of all papers currently on the website, ranked in some way. These list items should have some info about the paper, as well as a link to the full paper’s place on the website.
2. Navigation links at the top of the page: About and Site Rules are a must. Also Login/Sign up.

User accounts

Users can sign up, login, log out, remember password, forget password etc. I’ll talk about user anonymity and privacy later. Users shall also have a profile page where they can have a little bio and contact etc. Nostalgia:

login

sign up page v1

 

Single paper display

1. Users can read the whole paper, broken into individual paragraphs that I’ll call “fragments”.
2. Users can add and delete their own explanations for a particular fragment. Each fragment will have its own comment thread that opens when you click it.
3. Users can also leave comments on the overall paper (not just individual paragraphs). (I’ve decided it’s not critical)
4. Users CANNOT comment on someone else’s post/explanation. No need. I don’t want good thoughts to be buried inside long nested comments. The only thing you can do is write your own post.
5. Don’t display users’ name on the paper page (!!). Give users a random temporary name or a pixel art thumbnail. Users can only see their own names.
6. Users’ profile pages can be opened however, if someone clicks on their pixel art/random name.
7. Users can vote on paper fragments that are particularly unclear and need more discussion/explanation. This will help direct the community towards parts of the paper that are particularly unclear, thus stimulating more productive discussions (“bang for the buck”).
8. Users CANNOT tag or “@mention” other users in their explanations or comments.

Here’s a wireframe of what it might look like. Interestingly, I made these wireframes more than a year ago and now finally sat down to build the damn thing!

paper 2

Data Collection and Metrics

I think it was Peter Drucker who said that what gets measured, gets improved. But I don’t yet know what overall metrics I want to be looking at – at this stage, the purpose is not “growth”, but rather having a site that I can show to users and get in-person feedback by watching how they use it, so that I can improve the product. So I’ll only spend the bare minimum of my time on setting up vanity metrics, at the acceptable risk of not being data-driven enough. I can always add all those analytics packages etc later.

1. Definitely collect information about how many views a paper has.
2. Also collect some user visit data. Now, what should count as a “visit”? I’m interested in seeing how “active” the site is, and at what times the website is most active. So essentially, every time someone loads a page on the site, I’ll consider it a “visit”. It can always change later. Interestingly, this definition did change later :D. I am now defining a “visit” as a user visiting a paper on the site, and not just any page. The only visits that are important are the ones when people are reading papers!

Spam

Steve Huffman to the rescue! His lectures on spam were a lifesaver, without which I’d be totally lost. The key idea is that just by being familiar with the motivations and behavior of spammers, you can fix a LOT of things without technical wizardry. So here’s what we’re gonna do.

  1. Check a time difference between a person’s consecutive posts. If a person is posting new stuff within less than 2 minutes after the previous one, it’s likely that either they are posting ads, or they didn’t put much thought into what they are saying. I don’t want DenseLayers to be a place where people talk mindlessly. So if you post within 2 minutes of your last post, I’ll stop you there and ask you to slow down.
  2. If someone includes a link within their comment, I’ll add an attribute rel=nofollow so that search engines don’t follow the link.
  3. Every time someone shows spammy behaviour (posting too quickly, or being flagged by the community), increase their account’s spammy count (this score will be invisible of course). Keep a threshold above which a user is certainly spammy. If someone is very spammy, log them out of their account and ask them to contact me personally. In future, I might not even let them know that they’ve been flagged – I’d just restrict their ability to post stuff on the site. It’s called “security through obscurity”.

Internationalization, Localization, Accessibility

The very fundamental premise of DenseLayers is to open up access to scientific discussion for everyone, all around the world. So it goes without saying that people should be able to write comments and explanations in the language they prefer. In the first version of the website, I won’t localize it to different languages. However, people can add comments in whatever language they prefer – I’ll try to make sure the text is in Unicode and doesn’t break on different browsers and the database stores their words without corruption. There will be no other accommodation, I’m sorry but I have limited time.

As for accessibility by people who have disabilities, I cannot really include many features but I will try to build the front-end using best practices that make it less painful for them.

I’d also love people with poor internet connections to use my site. The paper pages will be very heavy on images, but I will try to reduce the resolution to an optimal number, so that the file sizes are as small as possible (that helps with data storage costs as well, so it’s a win-win). I’m also flirting with the idea of not using any front-end frameworks, and instead just creating my own mini framework to use for V1. That should make the site leaner and simpler (although for future versions of the site, it’s a trade-off. I might give in to learning and using a popular framework like React or Vue etc).

Critical Decision: The front-end won’t be super responsive. At this stage I don’t need people to use Denselayers on their phones on the subway. I’d prefer users using it on a big screen and a proper keyboard.

Anonymity and seating at the table

Now comes a sensitive topic that I’m sure people will have differing opinions about when the site launches. Let me document my thought process here. The core premise of the website is openness. DenseLayers will be a judgement-free, hater-free and crap-free space. I’ve also decided that I want ideas to be given weight based on merit, and not the person’s credentials. This means that if a college freshman has an interesting point, it should be taken seriously. And if a professor emeritus says something stupid, it shouldn’t be accepted just because of authority. I believe that since the research community is tight knit, if you’re scrolling down a paper on DenseLayers and see 10 people leave comments here and there, you’ll probably already know 7 of them personally and 3 will likely from your own department. In such a scenario, it’s easy to disregard someone’s comments simply because they haven’t “earned a seat at the table”.

Let me be clear: nothing would piss me off more than that. So I’ve decided that even though users can have their own profile pages, their names won’t show next to the things they write. I’ll give each comment a different random pixel art thumbnail and that’s it. If a user does want to see the person behind a comment, they can click on the thumbnail and see the person’s profile page where they can see the person’s identity. This may sound self-defeating but it is not. I want people to be recognized, but only if their comments are particularly intriguing in some way. My hypothesis is that the friction will create a healthy balance between meritocracy and anarchy.

Alas, this means someone who just wants to troll, is also welcome on the site. So I’ll have to add other mechanisms to the site to keep trolls in check. In the future, every comment will have options that allow people to flag them for spam or douchebaggery. Too many offences, and a user is ostracized from the community. Unfortunately this feature will not be present in V1.

More importantly, culture always starts with the founder. To guide the culture on the website, I need to take the reigns in my own hands and show the example for what kind of comments I want people to leave. For V1, I will strive to be the foremost contributor on the website.

Another note on anonymity

Well, I was going to talk about a different feature that I planned to introduce later, but in this post I’ll keep it to myself. The gist is that a user who has particularly strong reasons to be anonymous (whistleblower situation), should be able to choose ONE paper per month that they will be completely anonymous on, so nobody can see their identity or visit their profile even if they click on the user’s thumbnail image.

Monetization?

Probably nothing, but a separate page where I list my favorite books (with honestly-shown Amazon referral links) might pop up later.

Technical Choices

Using Python/Flask for the backend, and using Flask plugins for almost everything. Mini front-end framework made by myself. Thinking of storing paper fragments on Amazon S3 and deploying website itself on either AWS Lightsail or Heroku.

How do I describe my database schema?

By DenseLayers, Rambles No Comments

This is a post in which I explore what would be the best way to explain my current database schema for DenseLayers (my current project) in a clear and concise manner – which I will do in another post. This means that this is a rambling post about how I should write that future post. Writing great documentation (whether for yourself or others) is a skill and it should be practiced thoughtfully. I want to compare different ways of organizing/structuring the ideas on paper so that they make the most sense.

Update: I realize other readers may not know what DenseLayers is because I haven’t introduced it yet. It’s a website where people can discuss research papers online, paragraph-by-paragraph. I believe that having to read a paper alone by yourself is a terrible waste of time. Reading research should be collaborative.

I guess the best way is to start with the goal in mind – by the end of reading that future post, I want the following from the readers:

  1. I want them to know what high-level decisions I’ve made about the website and its functionality.
  2. I want them to see how I translated those decisions into a database architecture.
  3. I want them to see what decisions I’ve made regarding privacy and anonymity, and how they too translate into the database schema.

Yeah I think that makes sense. Let’s try a few different ways to organize explain these ideas in a cohesive manner.

Okay, firstly readers need to know that what I’m doing right now is just the first version of the website, which is an MVP and not meant to be perfect. So most of the features that I envision in the future will not be there. Cool. Decision: I shall write a couple lines in the beginning about how this is just the first version.

Then, I should describe the features of V1, including the reasons for why. So maybe describe them as…

  1. Front page – what it will contain
  2. Paper page – what the paper page will look like, what features it will have?
  3. User sign up and login, password reset etc
  4. User profile and settings
  5. A form that I can use to quickly add new papers to the website – should only have admin access. How would this form work?
  6. How does user data etc get displayed on the paper page? (It not very simple)
  7. Language flexibility – people should be able to use the site in any language they want
  8. What kind of analytics and user activity I will collect from the site.
  9. Should there be a spam filter already? (Another decision to make!)

Which basically seems like describing the wireframe I drew over a year ago. Maybe I should include screens from the wireframe.

I think if I split the website functionality like this, it makes sense. Not too deep nor too shallow. So, I can now show readers my database schema and teach them about it?

Also it would obviously be worth mentioning that I’m using a SQL database – maybe that should be the first thing? I guess the readers who read that future post will be those who have a technical background and are interested in learning about my database schema.

No wait – I can’t just assume maybe I should create a short list of personas of readers, split by technical ability, and use that to drive the decision?

  1. People who don’t know anything about database schemas. These people likely are just into the website that I’m actually building, and happen to find the blog post codex?
  2. People who know about database schemas, and find that codex entry many months/years later when they’re curious about how it was built. <– I guess for these people, the decisions that govern the schema design are more interesting than the schema itself. But I guess we’ve already taken care of that in the proposed structure above. So we’re good here.
  3. People who are very actively involved in the building of this website and want to have a clear picture of why anything is done. Wait, is that just me? In any case, this section of the readership is actually most important – because the most frequent reader of this codex will be myself. Decision: anything that Present Me writes should be useful to Future Me.

Future Me, you better be grateful to me for making decisions in your best interests.

Anyway – It seems that #1 is not a useful section of the audience to structure my post about. I’d rather focus on #2 and #3, and… wow, that brings us back to ground zero. Looks like I learned nothing from this whole “audience persona” mental exercise. So from this exercise of creating audience personas, the only thing I’ve learned is that everything I write should be useful to my future self if he ever needs to go back in time and look at his my decision making process.

Letting that aside, I don’t know the big advantages of SQL vs noSQL, do I need to talk about that? I pretty much went with SQL because it works perfectly for what I’m trying to do. That reminds me, I should read more blogs and watch some videos about noSQL because I barely know anything about it. Awesome, cheers!

Wait, what would be a good way to sign off at the end? Now this is one place where I should probably use something that is appropriate to a larger audience and not just Future Me. How about a few contenders:

1. Awesome, cheers! <– sounds weird-ish
2. Thanks for reading! <– too formal?
3. Cheerio! <– this one is pleasant, I’ve used it in emails a lot
4. That’s all, folks! <– can’t believe my brain farted this one. Cringe
5. See y’all later! <– same as #4
6. …nothing? Just end at the last logical sentence? <– sounds very flexible actually

So it’s a tie between #3 and #6. Let’s just go with #6 for now. After all I can always suddenly change to whatever I feel like. Wow, I just spent another 10 minutes overthinking something so trivial.

Let’s be terrible together.

By Reflections No Comments

If you’ve seen my front page, you know that I love writing, teaching and sharing ideas.

This blog website shall be my codex; my personal manuscript, inspired by Leonardo da Vinci’s Codex Atlanticus. The Atlanticus is a twelve-volume series of handwritten notebooks in which he documented his ideas and studies on a great variety of subjects, from botany to weaponry. These private scribbles give us a peek into the brain of a prolific man, and have allowed us to recognize his endeavours although half a millenium has passed since.

Crossbow design, sketched by Leonardo da Vinci Leonardo da Vinci's self portrait

Giant crossbow design by Da Vinci; and his self portrait

I too wish to be a documentarian of my own work, but a little differently – the Codex Audentia shall be open to the public from day one. This is where the word “audentia” comes in (Latin for audacity). You get indefinite backstage access. I will share my work in progress, my ideas and my “scribbles” – be it good or bad.

I don’t really intend for this to be a “blog”. Calling it a blog would cause me to be self-critical and judge my writings too harshly, and care too much about my “personal brand”. I don’t want that pressure. This codex is meant to capture what goes on in my brain, and my brain is very chaotic. A lot of my work will be terrible, and that’s fine. Let’s be terrible together.

‘You are remembered for the rules you break.’ – General Douglas MacArthur

 

I challenged myself to get a black belt in Judo in 12 months, training at the Kodokan in Tokyo.

I challenged myself to achieve fluency in Japanese in 12 months. The result blew me away.

Designed by

best down free | web phu nu so | toc dep 2017