Code Chronicles (mostly)

Though I am primarily a backend/system developer, I have worked with frontend for a long time. Coffeescript, react when it was just in beta, rails, react when it matured a bit more, etc.

Many a time, my work there had been shooting in the dark, because one (or I) couldn’t easily find the rhyme/reason in those things.

I have always gotten things done, and to the client’s satisfaction¹. But not always to my satisfaction.

For the uninitiated in accounting, and tax reporting: though it must be absolutely standardised, everyone uses their own accounting “standards” (at the very least, they use their own accounting descriptions, and numbers)

And when I say account numbers, it is not bank account numbers I mean. Every/any thing that happens in accouting goes to and comes from one or another account. That’s something we’ll address another day.

Coming to the issue at hand: When clients report their accounting to tax consultants (who then must calculate the tax adjusted P&L¹ and Balance Sheet), the account numbering is based on the clients internal system.

Every now and then I have to create a new server. Sometimes in Python, sometimes in Javascript (lately more Typescript), sometimes it is Go. Rarely Rails (at least lately). Over time, the following are my self-inflicted requirements for a nice server. Just putting it out here for future reference. Also, I might just create a series about creating such a server (perhaps in Golang?)

1. Database connection/s
   • of course at least one type should be configured.
   • but possibly with choice of environments - develop on psql, testing on sqlite (for example)
     • I’ve found it quite nice to have local tests that can be run on against an in-memory sqlite DB
2. Migration (either automatic on start, or with a simple trigger)
   • CRUD for entities, and similar things
   • NOTE that this might get tricky with ability to run against different DBs.
     • In conflict, I think we stick with the DB of our choice and migrations win
3. /health endpoint
   • Should return something like { status: "Ok", db_ping: "43ns", version: "x.yy.zzz" }
   • The DB ping is quite useful at times (if you ping takes longer, you can directly see there’s a bit of load there)
4. NO global variables (must I explain?)
5. NOTHING hardcoded
   • Env variables are to be read only in the main (entry method)
   • And proper dependency injection
6. Swagger generated with annotations, not with a large yaml/json file
   • Would love if it is a smart/er system which generates from code itself ;)
7. One method createServer(params) should return
   • a server we can run, and
   • a shutDownServer which will gracefully shut things down
     • (optional) proper disconnection from DB as well
     • And to be called when we receive signals to die/kill
8. Middle/After-ware which logs
   • Request arrival
     • possibility to turn on body/header logging
   • Request completion with time taken
     • possibility to turn on output logging
   • The possibility to add an arbitrary middleware
     • For example, something to add a dummy-header to the request.
9. Unit tests
   • Anything which is NOT an api call should be testable with unit tests
     • (optional) If possible the migration method should be tested too
10. Integration/API tests
    • All apis should be testable (/health included)
      • Test the response code, and verify with another call, but not by looking into DB.
    • Create database at start
    • Connect to database (in memory is fine too)
    • NO tests shall call endpoints directly with path.
      • They shall be called as methods of server, or server like object.
    • On test completion, shutdown the server, disconnect the database
      • a nice teardown (though our db might be in memory or temporary file)
11. Internationalisation / Localisation
    • The request shall be able to send `Accepted-Language` header, and the response must respect it.
    • Should have some kind of localised strings file.
12. Project shall be
    • structured to
      • entry-point.<java|ts|go|js|py>, (say main)
      • and folders like routes/, models/, controllers/, repository/ (business logic), and /services
    • with rather limited package dependency
    • compile/runnable and testable with simple commands, small script, etc.
13. Basic auth endpoints, sessions, tokens, etc. without JWT (I personally dislike JWT)

– sillyfellow on 2023-08-06 (Sun 22:47)

I have been thinking a bit about git and the tools that help us with it.

Git is a super powerful tool, but with quite complicated ways of working.

And to most of the developers, the interface in the command line is hard.

That usually leads them to using some UI which claims to make things easier by abstracting details away (that is, the UI claims to do the magic).

I blog directly from Emacs (Org mode), using hugo-markdown export, and easy hugo.

Org mode capture allows me to directly write to my entries.org file, which I then export the usual way (C-c C-e), but into the markdown file in the posts folder in my hugo website.

And with easy-hugo, I just publish it. That’s it :)

What I shall not forget is giving a proper name in the entries.org so that all is kept in order.

I TODO

– sillyfellow @ [2022-02-10 Thu 00:17]

#include <stdio.h>
int main() {
  printf("Hello World!\n");
  return 0;
}

– sillyfellow @ [2022-01-03 Mon 09:14]