generalist/Genera - the outline

5-minute read
genera • list • todo • software

Introduction

This outline was written by me, Brandon Nolet. This outline will be on the topic of my software project with the working title ‘genera’.

What is it?

As briefly mentioned in the previous post generalist will be a simple yet powerful todo list platform. With generalist you’ll be able to manage all your todo lists from a central location and with ease. generalist will be GTD-compliant

The feature set is meant to mirror the likes of Wunderlist and Todoist. generalist will have a server component a webapp component that interacts with the server.

Language

I’ll be using NodeJS for this project. I’m not saying it’s the best suited language/platform for this project, I’m saying this is the one I’m currently most comfortable with and so I feel comfortable making my software project in it.

I’ll be trying to be as minimalist as possible, not requiring too many dependencies. My intention is to make the software maintainable by a single person but also accessible to a lot of people. I think my style of coding is slightly opinionated?

I don’t know, I’m still in a relatively early point in the development of the project.

Structure

The structure of the project will slowly but surely evolve over the process of realization of it. I have an idea in my mind about what direction I’m going but the nitty gritty has yet to be defined or discovered.

Eventually I will get to a point where I have to start making flowcharts and hopefully that will be before I realize a fatal flaw in some of the decisions I’ve made over the course of the project.

Here’s what I have so far:

Be Modular

I know this is already a tenet of NodeJS and this is something that NodeJS was built for, but I’m also a fan of making my own modules. I feel like I can better understand a module that I’ve built myself than something that I opt to use that belongs to someone else.

I usually reserve using other people’s modules for things that I don’t fully understand yet or something that I fully understand but would otherwise take a long time to implement. Why reinvent the wheel?

In following with that modular nature, the front and back ends will be separable but the front end will also easily integrate with the backend.

Document, A Lot

I want the whole project documented from A to Z. I want someone to be able to look at my code as a learning opportunity rather than a jumbled mess of poorly named variables and functions. Up until now I’ve been pretty good about that but there are certainly some variables and functions that could be better named.

I’ve found that looking through other people’s code, they rely on the code-hosting platform too often for documentation and that can lock them into that platform. I like to document right inside the code. Code comment maintenance is something that I’m trying to practice regularly in my project.

All this will improve the accessibility of the project.

Easily Set-Up Test Environment

Not only do I want it to be easy to know what the code does but I also want it to be easy for people to test the code. Eventually that’ll mean setting up automated testing but for now, providing some test-data to work with and a precise bit of documentation should suffice.

The test data and testing environment instructions should be detailed enough for even newbies to follow.

API

I want a standardized API. For the backend I’ve mostly worked out a RESTful API that loosely corresponds to the CRUD operations. The backend will essentially be an abstraction of the database that it connects to.

The standardization of the API is to ensure that people can build their own front-ends whether it be a webapp or an iOS application, a desktop program or an Android app. As long as it can communicate with the web, it should be able to communicate with genera the back-end.

Guidelines

I’ll also be proposing some sort of guidelines for how the front-end could be built depending on the purpose of the front-end. If you want a kanban style task management front-end, then that’s what you should be able to get and “this” is how you do it. Etc. Stuff like that.

Feedback

To anyone wishing to ask questions, provide feedback, contribute ideas, etc, there will be a few ways to do so:

  • The Fediverse (Mastodon) - This is probably the quickest way to get a response from me.
  • Email - For lengthy messages this would be the best way to get a lengthy response.
  • Issues - Pay no attention to the current issues, I’ve been using them for my own “todo” items. This might be the best place to put suggestions/ideas for the app.

Conclusion

I’m slowly but surely working on the project. Once I finally get all my priorities in order and I work on trimming down the fat (unproductive uses of time) I should have more time to do that. Maybe one day I’ll not only write a post but also do some coding!