I am definitely guilt for that, but I find this approach really productive. We use small bug fixes as an opportunity to improve the code quality. Bigger PRs often introduce new features and take a lot of time, you know the other person is tired and needs to move on, so we focus on the bigger picture, requesting changes only if there is a bug or an important structural issue.

While I agree with most of what you say, I have a personal anecdote that highlights the importance of performance as a feature.

I have a friend that studies economics and uses python for his day to day. Since computer science is not his domain, he finds it difficult to optimize his code, and learning a new language (C in this case) is not really an option.

Some of his experiments take days to run, and this is becoming a major bottleneck in his workflow. Being able to write faster code without relying on C is going to have a significant impact on his research.

Of course, there are other ways to achieve similar results, for example another friend is working on DIAS a framework that optimizes pandas in the runtime. But, the point still stands, there are a tonne of researchers relying on python to get quick and dirty results, and performance plays a significant in that when the load of data is huge.

Here is a list of note-taking apps:

https://github.com/tehtbl/awesome-note-taking

By the way, I am building my own Journaling system, it’s still early stages and I am looking for ideas!

So that’s the legal equivalent of the guy committing 10k changes the day before leaving the company…

Boston is a compact battleship with a complement of 18 programmable keys, in a footprint 2u narrower than a full-size, and only about 1.5u wider than a 96%.

I am sold.

I cannot help, but your post got me wondering can you share your keyboard or a picture?

I cannot understand how some many fkeys could be useful. Why not use regural shortcuts?

Reminds me when dayjs decided to change the duration of a month during a random bugfix. I had to update so many tests…

Now I am going to share a horror story: Multitimezone Operational Calendars

No, they are using an ORM.

A good place to start is the owasp cheat sheet. They provide up-to-date, high value information about software security, I wish there was a resource like this when I started learning about security.

Even though, I have a decent background in software security, it’s hard to decide on an encryption schema that’s both safe and easy to use. My goal is to increase the number of components an attacker has to compromise in order to get access to the data.

twelve factor app

Great resource!

Write database migrations in both directions so people can downgrade on failures.

Good point. Personally, I take backups before upgrades and restore if anything goes wrong. But, I understand how downgrading sometimes is just easier.

I have trouble coming up with a migration procedure that makes sense to me. I have the following in mind:

1. Provide init scripts that produce a schema that matches beginning state of the current major.
2. Provide major to major migration scripts.
3. For every major, provide minor to minor migration scripts.
4. Schema changes require at least a minor release.

Make it possible to configure your system via ENV variables, ENV files and config files.

I am bit worried about this one, environment variables can be a security concern. Specifically, I am not sure if I should allow providing secrets (like db connection strings) through environment variables. I am inclined to let people do what they want to, but issue a warning.

Make it possible to disable authentication to add Authelia or LDAP through the webserver. Make clear that this is only to be used for external authentication.

I am considering adding support for oauth through keycloak. My assumption is that if you are going to host your own LDAP, you can probably configure keycloak too. Do you think that makes sense?

Make it possible to run multiple parallel instances of your software without affecting the database consistency, e.g. for high availability or horizontal scaling.

Ideally, an instance shouldn’t be big enough to need it. I know, famous last words, but in my case I think it’s a bad problem to have. I am going out of scope, but I am wondering where is the line between discouraging large scale deployments and designing something pre-destined to obscurity.

Telemetry

Not even on my radar, thanks for bringing it into my attention 🙏

Great point, I always consider dependencies from a security perspective, but for management/setup sometimes I am like “the devops are going to figure it out”…

To clarify, would an example be supporting sqlite, so people won’t have to deploy postgres unless they need to?

My plan is to offer a docker-compose configuration people can tinker with. I had the mindset that whatever happens in the container stays in the container, but your comment made me realize I should be mindful of other installation methods. Thanks 🙏

WOW! https://github.com/modularml/mojo

Been looking for something like this, thanks a lot!!!

Edit: Had a quick look at the docs. Mojo’s initial build was published Sep2022, it’s fairly young, but seems to be getting a lot of attention (on GitHub they have the same number of stars as mypy 🤯).

For anyone interested, their roadmap is an interested read. They seem to be taking a step-by-step approach, trying first to nail down core features first before moving to stuff like python inter-op and syntactic sugar.

Mojo still doesn’t support classes, the primary thing Python programmers use pervasively! This isn’t because we hate dynamism - quite the opposite. It is because we need to get the core language semantics nailed down before adding them. We expect to provide full support for all the dynamic features in Python classes, and want the right framework to hang that off of.

The “why mojo” section give a lot of background too. They are implementing an ML-IR compiler, which is really promising for optimization (think all the goodies we could use from LLVM).

this is a method, and always was a method, I just wanted it to look like an attribute for aesthetic reasons

I think “aesthetic reasons” is an oversimplification. There are certain assumptions a developer makes when reading some code that uses properties. While these assumptions are not clearly defined and may differ per developer, I think there is a common core.

(1) There are no side-effects. The object is not mutated (or any other object), no IO takes place.

(2) The time and space complexity is O(1).

(3) The result is consistent. Consequent calls to the property should return the same value unless there is a mutation between them.

(tried to delete this comment but somehow didn’t work, I re-read the article and have a different outlook, sorry for the low effort comment)