You should try to write code using SOLID principles. You should then write one using CUPID, try following OOP patterns, functional patterns and good old procedural ones. You should develope one huge code base and then try to maintain it for years. You should build a binary in Ubuntu, in alpine, in nixos, in Mac, in Windows and try to ship them to each other. You should run your code on a bare metal server and you should try writing lambdas. You should start a green field project and a try to maintain a legacy system that none of the original authors are there yet. You should write code in a company that hires 500 people per day and lays off in thousands. You should write code for a company that has 2 engineers that have been there for years. You should write a backend, a frontend , and one that does not do all these. And you should ship them. And use them. You should write codes idiomatically and you should write them idiotically.

The idea is not that a good programmer had done all these, the idea is that no simple tip or priciple can apply to every situation. Anyone claiming that, is no more than a snake’s oil salesman. You should learn to code and design and engineer your software critically based on each situation. You should constantly learn. And you should not be afraid to go against the grain or break from the beaten path or go with the most popular mediocre choice.

Sure thing! Awesome!

OK so, for example if you have to change the structure of the configuration file, in a statically typed language. You have to have two representation of the data, the old one, and the new one.You have to first deserialize the data, in the old format, then convert it back to the new format, then replace the old files. The FAMF alternative, allows you just to easily use copy and paste and delete to achieve the same goal. Please keep in mind that you can just make configuration data structure that you can keep in-memory. It is just that the representation of the persisted information is spread between different files and not just one file.

OK so, you are very much right. You should definitely benchmark it using a simulation of what your data might look like. It should not be that hard. Just make script, that creates bunch of files similar to your data. About the trailing white space, when I am in terminal I just use sed to remove the latest ‘\n’ and in rust I just use .trim(), in go I think there is strings.trim(). It is honestly not that hard. The data structure and parser is not formed the same way as the json, where you have to parse the whole thing. So you don’t have to. You just open the files you need read their content. It is a bit more difficult at first since you can’t just translate a whole struct directly, but it pays for itself when you want to migrate the data to a new format. So if your structure never changes, probably those formats are easier.

You are right. Fat32 is not recommended for implementing FAMF.

Oh goody! F2 is great, but the developers are craaazy! They packages commandline Go application with npm!

I also like vimv and vidir for simpler stuff.

Sure. You should use whatever you are comfortable with. That’s the point. When you don’t need special parsers or tools, you can more easily adopt your tooling for the job, because almost every language has tools to deal with files. ( I assume there is some language that doesn’t, who knows?)

Definitely. But you would need need something other than those for the working with 100 json files as well. The question is, which kinds of things you would like to have as extra. You can go with jq and prettier syntax highlighting or you can go with tree and cat (and dog). It is the matter of taste. But also, I am always right, because my mom told me I am special .

I know! right?

Some say thay since you can use ‘tree’ and things like ranger to navigate the files, it should work alright. But I guess if you have one giant metadatafile for all the posts on your blog, it should be much easier to see the whole picture.

As for upd_at, it does not contain information about when the files have been edited, but when the content of the post was meaningfully edited.

So if for example I change the formatting of my times form ISO3339 to another standard, it changes the file metadata, but it does not update the post content, as far as the readers of the blog are concerned with. But I get why you chuckled.

That’s a pretty cool idea!

Read the content. I address that issue.

Well I’d you have so many data entry, yaml and toml are not that helpful either. They would present different sets of problems. You should use a database (perhaps sqlite) for that purpose.

Well, I mostly target the places where you don’t programmatically generate millions of values. Configurations, entry metadata, etc. Indeed SQLite is much better for when you have a massive amount of data, and you need a better base that a file system. But when that is not the case, a file system is more advanced than whatever tooling are behind toml and yaml.

Yes. That is indeed a more interesting name. But think of the acronym.

• FDS is not as easy to say FAMF.
• FAMF already has an Urban Dictionary entry.

/key/=/value

I have one that has 69 (noice) files changed.

Famf is definitely is. Just put yaml there.

Sure. Why not :))

What would you do with billions of inodes?

So, I had the same sort of struggle a while back. And I have managed to fix it, recognizing what I had been doing wrong.

1. I did not know how to test different parts of my system. Going through other people’ s testing example actually helped me a lot in this respect.
2. I did not separate the complex internal logic of my program, from its side-effects. For example put the mapping of the data in the same function as I was doing external requests. You learn how to manage problems like this by practice. But of course, be mindful of the side-effects of your functions. Avoid it when you can.
3. One other problem I had was that I wrote every test in the same manner. Tests that are not idempotent, and depend on external services, are useful, but you should use the facilities of your language to run them separately from your unit tests. In rust for example we use feature flags.

Testing and writing functions that can be tested are skills that need practice. For me, many of the patterns of the functional programming helped a lot. Since they insist on pure functions and pure functions are massively easier to test. Learning how people manage to write programs with pure functions may help you a lot, too.