Makes me think of how many Minecraft server plugins use YAML files as a database
Json-Base – Database built as JSON files
91–100 of 189 posts
Re: Json-Base – Database built as JSON files
#92Made in India..
Re: Json-Base – Database built as JSON files
#93This is both more effort and a worse outcome than just using Postgres with JSONB data types.
Re: Json-Base – Database built as JSON files
#94Earlier quoted context omitted.
I left my last company because one of my co-devs would always do crazy hack-job things, and when I complained to them or higher-ups, the excuse was: "When?" I asked, considering she had just put up the (big) PR's and PR's ARE the time to review... My jaw dropped. Especially since I was hired on as "Lead" and had all the accountability but no actual power.
Yeah, I'm in a similar situation at the moment. It's incredibly frustrating because during code reviews I will request changes so it's not such a broken hack job, and the response will basically be "No, it's not worth changing". At which point I'm the one "holding up development". We wasted hundreds of development hours during the last project because of this persons "inventive" code, and nobody seems to understand w…
It's hard to get more strength to push back with out of thin air. I'd encourage you to try pushing for more detailed post-mortems (if you don't already have them) and just keep an eye out on how much curtailed reviews cost the company. You also really want an advocate for code maintenance and if you don't have one of these with a loud voice there isn't a really feasible way to solve it except becoming it yourself and earning the trust of those above you.
Two pieces of actual useful advice I can offer are:
1. A review style I picked up based off of RFC 2119[1] basically the reviewing software we use allows us to mark particular comments as blocking of non-blocking and I pair that with the usage of MAY/SHOULD/MUST within the comment language i.e. "We're using the old `array()` syntax here instead of `[]` we MAY wish to use the more modern syntax" this allows me some room to elevate necessary change while keeping in the nitpicks I really want to throw in (and I do try and minimize them) without lowering the power of the strong comments. I've used MUST maybe three times always for something incredibly terrible like pages not loading or migrations to the DB that are unsafe and cause data loss.
2. Agree on syntax and style rules and enforce them. It's easier to get people to agree to rules once than try and argue for them on each PR - anything like brace placement or line limit shouldn't come up repeatedly since it wastes everyone time and makes folks feel belittled.
Re: Json-Base – Database built as JSON files
#95Earlier quoted context omitted.
Funny read, why did nobody stop him?
I tried. I held a meeting to talk about the code. I found the problems hard to predict and hard to describe. It was decided that after the meeting he would work more on making his code less hacky and more production ready. But the real answer is that our team was very siloed. No one knew what anyone else was doing. The other problem was that he was actually solving real world problems, and he was a very high performe…
It's not very agile friendly, but emphasizing design early in the process and having some "gate-keeping" protocol such as design review or code review can greatly reduce the chance of something going off the rails like this as it forces everyone to acknowledge what done looks like, as well as what the "missing" pieces will be.
The GateKeeper process isn't something you want to index on too heavily - but you also need a mechanism to counter-balance the possibility of a dev saying "I built a prototype last week that does 95% of the things we want" and 3 months of iteration later identifying that it only did 5%, and that getting the remaining use cases will require a re-write.
Re: Json-Base – Database built as JSON files
#96This is useful for a lot of projects. I've used a similar db library in a rust project I was working on for an example application. This way there are no heavy dependencies or even the need to say "you need sqlite".
Re: Json-Base – Database built as JSON files
#97Earlier quoted context omitted.
Many many years ago In college, SQL sounded hard. So I built my own database in PHP. Enough said
When I was in university, one of our major projects was to implement a rdbms. Super fun project that taught us a lot of respect.
How did you implement the file block sectors? Did you build your own sub FAT protocol?
Like, initially allocating a large file block, and then you subdivided that yourself to get individual sector access?
Re: Json-Base – Database built as JSON files
#98Earlier quoted context omitted.
I can sympathize but it seems hard to argue with this developer's approach then. If it met the needs of the company, particularly to the desired level at the times these features were requested, I don't think there's a valid critique of the developer's architecture beyond iT's NoT DoNe CoRrEcTlY. And still, there's a lot to be said for keeping your developer's entertained so they stick around.
I can certainly say that that's exactly the way I felt complaining about it. I felt like I was an asshole attacking him, and I don't think he liked me very much because of it. The whole thing was very uncomfortable. I didn't throw a fit. I tried to be very understanding and make suggestions. If it's any consolation, it fell on to me to maintain this code after he moved on to something else, which is why I know so muc…
> it fell on to me to maintain this code after he moved on to something else
This has happened to be before. I disagreed with a technical direction, it was implemented anyways, and then I'm left to maintain it. Very frustrating.
Re: Json-Base – Database built as JSON files
#99Earlier quoted context omitted.
I can sympathize but it seems hard to argue with this developer's approach then. If it met the needs of the company, particularly to the desired level at the times these features were requested, I don't think there's a valid critique of the developer's architecture beyond iT's NoT DoNe CoRrEcTlY. And still, there's a lot to be said for keeping your developer's entertained so they stick around.
> If it met the needs of the company, particularly to the desired level at the times these features were requested, I don't think there's a valid critique of the developer's architecture beyond iT's NoT DoNe CoRrEcTlY. I'm pretty sure the cascading series of "his next problem" sentences implies that there were plenty of problems with the architecture that weren't identified ahead of time, and they had to encounter an…
I would say operator friendliness is actually the best reason to roll your own (was clearly not the case here). If you have a system that is less complex, because it meets your use case only and not the competing use cases of every damn engineering outfit that can pay overpaid and underqualified devs to commit to an open sourced codebase, and as a result requires less labor to manage (for example, not using kubernetes for a 3 person startup), you should roll your own.
Re: Json-Base – Database built as JSON files
#100Earlier quoted context omitted.
I can sympathize but it seems hard to argue with this developer's approach then. If it met the needs of the company, particularly to the desired level at the times these features were requested, I don't think there's a valid critique of the developer's architecture beyond iT's NoT DoNe CoRrEcTlY. And still, there's a lot to be said for keeping your developer's entertained so they stick around.
I can certainly say that that's exactly the way I felt complaining about it. I felt like I was an asshole attacking him, and I don't think he liked me very much because of it. The whole thing was very uncomfortable. I didn't throw a fit. I tried to be very understanding and make suggestions. If it's any consolation, it fell on to me to maintain this code after he moved on to something else, which is why I know so muc…
If you're maintaining it, then I think you get a fair vote in it's architecture going forward. Things that are plainly problematic now didn't seem that way to a different group of people in a different context before it was even created. Perhaps it was a cascade of poor choices, but regardless, identifying problems with the architecture in the context of today gives a huge advantage over those who were putting it together under who knows what conditions (at work or elsewhere).
Just like the never ending "turn this Excel workbook into an app" stream of work, refactoring older apps will be a constant. Focusing today's conversations on yesterday's mistakes only detracts from the work left to do (which is to say if your architecture change arguments are valid, there should be ways to justify implementing them today outside of "it should've been done this way in the first place because then we wouldn't have had those problems that are now solved anyway")