Struggling with the same issues with junior developers. I've been asking for an implementation plan and iterating on it. Typical workflow is to commit the implementation plan and review it as part of a pr. It takes 2-3 iterations to get right. Then the developer asks claude code to implement the based on the markdown. I've seen good results with this.
Another thing I do is ask for the claude session log file. The inputs and thought they provided to claude give me a lot more insight than the output of claude. Quite often I am able to correct the thought process when I know how they are thinking. I've found junior developers treat claude like a sms - small ambiguous messages with very little context, hoping it would perform magic. By reviewing the claude session file, I try to fix this superficial prompting behaviour.
And third, I've realized claude works best of the code itself is structured well and has tests, tools to debug and documentation. So I spend more time on tooling so that claude can use these tools to investigate issues, write tests and iterate faster.
Still a far way to go, but this seems promising right now.
Take a look at JinjaSQL (https://github.com/hashedin/jinjasql). Supports conditional where clauses as well as in statements. It uses Jinja templates, so you get a complete template language to create the queries.
I have been working on an idea to leverage SQL + REST APIs instead of GraphQL to solve the similar problems, and I would love to get some feedback on it.
GraphQL is great during development, but in production you often use "persisted queries" to prevent abuse. Persisted queries are also a way to use HTTP GET instead of POST, and thereby leverage HTTP caching. As such, if you swap out graphql and use sql during the development phase, you perhaps can get similar benefits.
My solution (https://github.com/hashedin/squealy) uses SQL queries to generate the API response. Squealy uses a template language for the sql queries, so you can directly embed where clause from the API parameters. The library internally binds the parameters, and is free from SQL injection.
Handling many-to-many relation, or many one-to-many relations is done in-memory after fetching data from the relational database. This provides the same flexibility as GraphQL, but of course requires you to know SQL.
This looks really cool! Particularly for the embedded analytics use case.
Do you have an example of how this would work on the front end with relationships. For example if I want to fetch posts and their comments how would the front code look like?
In short, with 1 GET API call that uses 3 SQL queries, you are getting a list of questions, related answers and related comments.
You should parse that example as follows -
1. The first SQL query fetches all the questions, filtered by API parameters
2. The second SQL query fetches all comments for the questions selected in the first query. See the `WHERE c.postid in {{ questions.id | inclause }}` part - questions.id is coming from the output of the first query
3. The output of the first and second query is merged together on the basis of the questionid that is present in both the query output.
4. Similar approach is used for all the answers
I have been working JinjaSQL[1] for a while to simplify complex SQL Queries.
JinjaSQL is a templating language, so you can use interpolation, conditionals, macros, includes and so on. It automatically identifies bind parameters, so you don't have you to keep track of them.
Re. Guide comments - I usually try to make a smaller function with an appropriate name and then call the function. So long function become a series of invocations to smaller functions. This eliminates most guide comments IMO.
I came to make a similar observation re guide comments, with the difference that guide comments with inline code is better in most cases than a sequence of small function calls.
I've often wondered why my code style is moderate inline blocks with guide comments when I know about the benefits of good naming and self-documenting code. In the end, I find it more effective. By encoding in function names, you've (technically) eliminated comments but now buried what it actually does somewhere else meaning the reader must navigate to verify it does exacty and only what each reader infers from the name. I much prefer having a function of a small-medium logical size that I can hold in my head all at once and see relevant details without navigating away from where I'm reading/editing.
My experience is that less depth and fewer single-use functions aids overall comprehension similarly to how flattening as in list comprehensions or filter/map pipelines buys more headroom. I can imagine building/using DSL where everything is well-named and free of guide comments but I have never encountered such a thing where there are multiple committers using a procedural language.
Absolutely. First was the Apache commons clause license, and responding to random folks who assumed Redis was going closed source. Then the current issue of changing master slave termibology,and having to hear negative things from both the camps.
The way I look at it, the amount of effort required to change that terminology is less than the amount of community discomfort generated by keeping it.
That's all kind of tossed out the window when people start bullying the maintainer to get their way. Now you have to deal with the fact that some members of the debate are decidedly acting in bad faith, making it much cheaper to simply say "okay, fuck off now, we aren't talking about this".
That is exactly what I have done in the past. I have told social justice warriors patrolling around to random projects that do not even contribute to leave and not come back. My response to those that do contribute to the project is, "Are you will to make, test, and solely support this massive change for the next three years as part of a long term support release?".
That’s.. really interesting. I’m having trouble figuring out how a codebase could offend a person. It has to be more than using masculine pronouns or something - do you have any examples you’d share?
There are a lot of busybodies on Github, sometimes these go viral on Twitter and other locations for the heated discussions. Here's a small collection of various levels of offence. Some are merely polite requests and some are "horribly offended". I think one or two of them may even be concern trolls but that doesn't matter since they still got the changes made.
There are a few hundred other examples to pull from, these are just a few I chose at random while trying to select ones that are more about the code, or terms used in the code, than contributors or maintainers of the code.
Wow, thanks for all the links. I just spent way too long reading all of these.
I found some of the requests to be pretty reasonable. Some were reasonable, but not very pragmatic. Some just kinda elicited an "eh, come on?" sort of response.
Haha, yeah, I just read through that entire list. I'd say that more than half of those seemed very reasonable and civilized to me. But the people complaining about penis.js seemed to have completely missed the point of that whole project.
I then started browsing through my own code to see if anything seemed offensive. One thing that caught my eye: in SPI communications, there is very clearly a "master" and a "slave". I have programmed many SPI-related code... So now I wonder, what was the original complaint in calling Redis servers "master" and "slave"? That terminology is very, very common in computers.
It makes me very angry when "they" (I'm not even sure who "they" are or what their motives are) go around policing random software projects for political correctness compliance, bullying/mobbing the maintainers if they don't comply, etc. These people even go after your project if one of your maintainers is deemed politically incorrect outside of the scope of the project (i.e. on Twitter) and demand they be kicked out.
I miss the days when politics and political correctness didn't directly affect software projects. What do these political police stand to gain from all of this?
> What do these political police stand to gain from all of this?
A warm fuzzy feeling of seemingly contributing to the Forces of Good and fighting the Forces of Evil. Some launch rockets to the Moon, some create beautiful art, some create awesome software. Some instead bully people to not use certain words. The consider it their contribution to the society. Unfortunately, as more and more people fold to their pressure, this serves as confirmation that this contribution is worthwhile and there's more to come. If you write a symphony and it is applauded, you want to write another one. If you speech-police one project and it works, you want to speech-police another one.
> It's creating a culture that is welcoming to more individuals
Somehow I feel less welcome in a culture where there are lots of people vigilantly seeking offense where none ever was and waiting to pounce on the use of every word they can find any reason, real or imaginary, to feel slighted with. In fact, I feel a strong desire to not touch such a culture with a ten foot pole. I am glad to contribute my time and my effort to open source (and I regularly do), but I would not want to be a target of hate mob trying to ruin my life or argue with concern trolls, that's just not how I want to spend my life.
> It's not bullying
You do what they want, or they'll hurt you and your project. How it's not bullying?
> In fact, I'd say active code maintainers who receive these requests and don't _reasonably_ accommodate them are the real bullies.
You may say whatever you want, but you will be wrong. Actual bullies are those who try to force people to behave to their liking with threats and hurt. No amount of redefining terms will change that. If you threaten to hurt someone in any way - virtually or physically - over some words that they say or don't say to your liking - you are a bully. It's not hard to see.
This is extreme and very, very far beyond the scope of what I was attempting to discuss.
That's a lot different than simply submitting a PR to change "man" to "person" -- If there's actual physical threats occurring on a regular basis within our communities I'm severely uninformed. No argument, it's bullying and it's wrong.
I suppose in that case, I advocate the underlying message but not its conveyance.
Creating and maintaining an open source project is an act of generosity. Making demands on open source maintainers and "shaming" them into political actions in no way creates a welcoming culture, quite the contrary.
If you don't like the code, fork it if you must but don't harass the creator of the thing you get to use for free.
I believe I'm misinformed about what's happening lately, I'm not advocating for political action or anything of that nature. Just supporting the underlying message.
Not OP but it's extremely pretentious to assume that.
More generally, assuming that "people against changes (that you personally think are positive towards minorities)" are not part of said minorities tends to be as incorrect as assuming that the people in favor of those changes are part of them.
Furthermore, just because the term "minority" implies that there is a minority of people in that group, there are many minorities which together form far larger groups. So "encountering a minority" isn't uncommon. And I've seen on multiple occasions horribly-arrogant people addressing some of my white male friends, claiming they're oblivious to "the plight of minorities", all because said friends didn't come forward to explain they're gay.
So all that to say, don't assume the person you're replying to hasn't been affected by those things. Even if you're correct, it's not a correct nor even safe thing to assume.
> Making other people feel as welcome in software as you've already been by default.
If you're only superficially aware of the issues involved, it's easy to think that superficial changes will suddenly improve things. It's also all too easy to ignore the fallout of those changes.
Reminds me of PETA's philosophy towards animals: If they can't be free, then they're better off dead. Ignoring that PETA:
1. Isn't objectively correct / morally right
2. Harms the greater cause with their methods (by harming public perception)
In general, not being tactful is a terrible idea. Forcing changes through is a terrible idea. Bullying people is a terrible idea. And if you think these tactics are worth it to "make people feel more welcome", I don't know you.
I responded to a comment pining for the days of politics not affecting software, by pointing out that software development always has been. I'm not commenting on any particular changes here, I'm commenting on the position of "I don't want to think about politics" being a position that biases in favor of the status quo.
Apart from that, I'm not suggesting that people should ignore normal contribution procedures and conventions when making such contributions. Nothing in my comment is endorsing ever single person who has ever made such a contribution, regardless of the approach they took. I am, however, suggesting that maintainers who refuse such contributions (for reasons like "I don't want to do this" rather than "this change has issues, please address them") are part of the problem.
Not the above poster, but, alas, given some of the behaviour I've seen, I'd no longer be particularly inclined to be welcoming. In some sense, a broad, offensive filter is better than doing it manually. Who cares if it reduces user count or whatever - it makes my life easier.
Perhaps it's a "good" thing I haven't created any major OSS projects...
No, they're making themselves feel righteous, at very little gain to the minorities they're ostensibly protecting. I'm Slavic. The name for my ethnicity literally means, and is the root of the word slave. Shouldn't I have more say than anyone how my ethnic identity as a slave gets bandied about? I say the master/slave terminology is effective, evocative, and useful.
I've come to believe its a mix of virtue signalling (public, empty gestures intended to convey socially approved attitude without any associated risk or sacrifice.) and pat-yourself-on-the-back slacktavism (there, I tweeted about what people perceive to be a problem, therefor I've done my part).
In essence, they get to tell themselves (mostly convincingly so) that they have contributed to reduce inequality and discrimination, and are helping right a historical wrong.
In the end, I dont think it changes things one wit - but it makes people feel better, so I guess its a net good over time - albeit an unconscionably silly one.
I didn't think that is true. Have you ever seen legacy code. Some code in Cobol and Fortran still exists and is functional. Redis isn't as old as those ofcourse but everyone who used it will need to change code and docs.
This isn't some isolated word doc that can be fixed with a findall/replaceall command this is backend code connected to many systems.
I am not even a professional developer , I am a researcher/grad student and I have faced such issues with something as new as Tensorflow.
If it is such a big issue, then those who had the problem can fork the repo and change the terminology in their fork. Legacy code that wants to use updated redis won't be affected.
Ensure that you're measuring community discomfort accurately, though: volume of noise about something like this usually correlates less to the number of people who are upset, and more closely to the number of people who think that someone else could possibly, potentially be upset.
If you think it's that easy, you personally should be the one to do the work to change it.
Now that sounds incredibly snarky, for that I apologise. But it does sum up a lot of people's thoughts towards it, and it's no more snarky that the typical twitter driveby of 'it's just a find/replace'
Anyone who has actually read the author's explanation (not saying you haven't), knows that he would choose different terminology in hindsight, but the work involved in updating documentation, and maintaining protocol compatibility that allows redis to keep its backwards compatibility features it aims for is non-trivial.
Not to mention all the documentation, and also the ongoing responsibility to third party code and infrastructure which relies on the ecosystem, that has to update along with this.
That's all work, constant, ongoing work.
Should they still make this change? Maybe, master/slave isn't exactly accurate.
But my point is that talk is cheap, and the loudest voices seem to be the folks with no willingness to put skin in the game to change it.
If you truly believe it's so trivial, why won't you help with the labour, both initial and ongoing?
You didn't use the words, but if saying that community discomfort eclipses all the different types of the work involved (with your point being that they might have been better just doing the work) isn't a trivialisation of said work, then I don't know what is.
EDIT: Actually, I take that back, sorry. If we both have different estimations of what the community discomfort actually is (both the discomfort currently and the discomfort that will be caused technically), then I can't make that call and say you were trivialising it.
My point is that a lot of the more vocal elements were definitely trivialising the work involved, going as far as suggesting that the maintainer is an asshole for not just doing a find/replace.
It's hard to take that in good faith, as if it were just a find/replace, why don't they offer to take care of it along with any ongoing technical consequences?
The answer is that they're both ignorant of the technical implications, and ultimately, more comfortable shouting from the sidelines than rolling up their sleeves, preferring instead to make innate character judgements about the maintainer.
Yes, and I think this is indicative of a broader problem with humanity itself.
It's very easy to assume that things that impact oneself negatively were done out of malice. Most of the time, these are innocent or naive, not malicious. However, as humans, we tend to jump to the worst possible case and _act on that assumption_. That's the real problem here.
I'll add another point: if the reason to not do this is the effort, then why is effort being put into generative art in redis? To be clear, I think this is neat, and appreciate that antirez can and should add some joy into the world in what ever way they see fit. I'm just playing devil's advocate.
With that said, changing terminology is more than just a code change, there's a bunch of documentation, as well as possible downstream effects that would need to be clearly communicated without causing breaking changes. I still think it's worth being conscious of the words we use, and rather than looking at it as a "us vs them" political game, as a way to introspect and reflect on how we use words, and what they communicate. Falling back on "it's how we always did it" is a cop out, but if you're the maintainer of a project, it's up to you if you want to do that or not, and I don't think it's worthwhile for a community to harass someone for their decision, antirez was pretty open about this all.
Given that generating discomfort is a very low-effort endeavor, and no discernable skill besides having lots of free time is required for it, if there are people who want to generate discomfort, they will always be able to generate enough to overcome any boundary.
Since people don't like discomfort, squeaky wheel gets the grease, even if the squeaky wheel represents only a tiny minority of the community, because other people are not interested in wasting time and emotional energy on arguing and being target of the outrage-of-the-day mobs.
That's an excellent heuristic when the people doing the work are also the people experiencing discomfort! Each person so affected can make their own decision from ample firsthand information.
It might become more subtle in scenarios where the two are disjoint groups, raising the question of how to compare them. I don't see an easy way of quantifying each that allows for such, but I'm sure that's just my own failures of imagination. Can you help me?
Probably from engineering in the 30s/40s, I'd bet. Say you had two gun turrets with servos, and used a synchro slaved to another synchro to have one track whatever the other was pointing at.
It's pretty obvious terminology for systems that don't support dynamic hierarchy changes.
The term master does have origins in the latin word "magister" (teacher, leader, chief or someone with a license to each philosophy or liberal arts). The middle english form, maister, was not connected to slavery either, it was more about someone of authority (ie, lord, ruler).
A lot of times it's use similarly like "Master Clock". The term in technology is strongly connected to that root; the master in a protocol is the leading participant.
I think simply not using "slave" for the passive or accepting device would be sufficient to reduce the problem since that is the word that has even in the deeper roots of it's origin the same meaning as today. (Slave comes from Slav, a group of people enslaved in the medieval ages and later expanded to cover all "slavs")
For a current project I'm using master/client as terminology.
I think it's sad this was a debate at all. As a maintainer, there is some responsibility to respond to people who are working with you or using your product.
On the other hand, personally I would have just said: "deal with it".
The fact of the matter is, virtually no one has been or is a slave, no one is being mocked, no one is being belittled, it's a term used to describe a system. Sure, it could be more "politically correct" (I use master and worker, personally) - however, if I inherited or was working on a code base. I would not have been as open to changing terminology as this guy.
As he put it, we are there to program.
If it doesn't enhance readability, speed, etc. it's not changing - stop wasting my time. As a "computer scientist" we should try to be objective about terms, and build forward. That means, potentially changing that terminology for the future, but also not being emotionally attached to the terms which are not intended to be subversive, subjective, etc.
We live in a society, people are going to use the term "slave" to describe things, people are going to say things you don't like, use terms you don't enjoy. I hate acronyms, I find that it is a way to segment a society or group into those who know them and those who don't. Even the term "LOLWUT", means you need to understand the term "LOL" and where "WUT" comes from.
... And that's my point, as a society, I shouldn't be pushing my preferences onto you. I should be learning to deal with my own emotions and understanding. If it's something that impacts my freedom, then maybe I should bring it up. Calling something a "slave" doesn't mean it impacts your freedom.
I disagree. Having terminology that is clear (which master/slave is not) decreases the time needed to spend to get an understanding of whatever it is you're working on.
Also related, if someone is offended by terminology then that will slow down their progress in understanding because they first have to process those feelings in order to continue.
Don't give me that - also as a maintainer, I wouldn't want to work with people who slow me down on terminology issues (when they feel offended, for industry standard terms).
I think the idea of "master" as in a definitive or original copy has enough usage that it's considered a second meaning of the word. I guess it's still possible that people will be upset, but without "slave", it's not unreasonable to assume that people will think of a key or album master instead of a slaver.
Is master/slave even a proper term to begin with? If we approach it from a "human slavery" standpoint, the master directs slaves to perform tasks that the master does not itself perform.
Master/replica makes sense to me in the context of copies that all perform the same function, including the master.
Even that doesn't quite fit, I think. It makes sense for Redis, but in a lot of other master/slave topologies, what's actually happening is that 1. a group is electing a leader; 2. the leader says what is happening; and then 3. everyone (including the leader) all does what the leader said, concurrently.
I feel like there is probably an exact term for this arrangement, from another discipline. Maybe choreography?
• There are principal dancers and back-up dancers. People performing the same action are dancing in unison.
• There are cheerleading captains and their squads, which consist of the roles of base, flyer, and spotter. Interestingly, being captain (giving orders) is disjoint from a member's performative role within the squad; a member of any role could also be the captain.
• There are operatic prima donnas (or primo uomos)—the lead singers—and a chorus, though these are not mirrored.
• Orchestral organization has tons of different roles: the orchestral ensemble composed of players; their conductor; the principal of each section; the concertmaster (the principal of the section leading the melody of the piece, usually the first violin section.) You can also speak of accompaniment.
Interestingly, most of these disciplines lack a term for "everyone of a group being led, besides the leader." I would assume that this is because the leader is taking part in the group, and so there is no explicit action taken by the group-minus-the-lead, only actions taken by the lead or taken by the group as a whole. (On the other hand, for machines, it is useful to talk about the process of following the lead's... lead. Humans generally do this implicitly, and don't really refer to it as an explicit action they're undertaking, separately from the actions that they're mirroring.)
Now this is the kind of argument that could actually persuade any remaining holdouts. It's not bad terminology because it's offensive but because it's inaccurate!
Personally I wasn't-necessarily-a hold out, rather dispassionately observing from the sidelines but I'll admit that approach to the descriptors made me subtly. It makes the most sense, and much more accurately defines the mechanisms involved.
Is this also true for localhost, or does localhost get special treatment? What is a good way to get https certificates for localhost other than self signed certificates?
This isn't true for localhost. But some browsers don't know whether "localhost" is really localhost, so for best compatibility write 127.0.0.1 or ::1 as appropriate
If you need to simulate HTTPS for your local host, but you actually control all the moving parts (e.g. a dev environment) you can use any private key + associated certificate for a DNS FQDN you control, then use /etc/hosts or its moral equivalent to tell your local machine that this name is on the local loop, and the key + certificate will validate.
You must not ship this as a "product" because when you do that all the end users end up with the private key, which both destroys the whole _point_ of public key cryptography AND violates the terms of whichever CA issued you with the certificate.
