-
This is great! I visited IDII and briefly met Barragán ca. 2004 when Processing was new and Wiring was just approaching usability. The institute closed a short time after, but they assembled a magical group of students and professors in an old Olivetti factory. It feels slightly ironic in retrospect that this shell of a former typewriter factory was graduating students for whom then-powerful Nokia was a top employment goal.
-
OSM is more widely used than ever before, but I agree that it’s got a number of systemic risks. Zverik hints at a few key ones: a long-time exclusively volunteer approach, a fear of executive action, and a resistance to professional input. Fortunately the US Foundation (there are many international chapters) is working on some of these issues by hiring its first-ever executive director. This may benefit just the US community initially. I expect it will help OSM cross over from a hobbyist (“craft”) mentality to a product or utility mindset long-term.
-
Some of these are great! Unfortunately many of the GIFs have a thin black line across the bottom.
-
The gifs are not the final product and are meant as an example. The real code for all the spinners can be found at https://github.com/zmcartor/ThinkingFaces
-
-
-
Writing to Mastodon’s API isn’t too hard! Here’s my Tumblr-to-Mastodon bot, written in Python to run on AWS Lambda. It posts to @migurski@mastodon.social. Darius Kazemi’s Mastodon OAuth page was helpful.
-
-
migurski
5 months ago
|
link
| on:
A Japanese Photographer Traces How Cities Are Built and Destroyed
Beautiful photos, thanks for posting this. Reminds me somewhat of Andreas Gursky’s work.
-
migurski
6 months ago
|
link
| on:
Extending CircleCI's API with a Custom Microservice on AWS Lambda
Neat. Whenever I’ve made static sites over the past few years, I’ve used Circle’s artifacts feature to store the results and make them browseable by branch. Code here.
-
It’s hard to reason about this sort of thing in the dark. I like Alex Russell’s explanation of performance budgets for shining a bit of light on front-end behavior. Webpagetest has a “first interactive” measurement that seems to be a decent stand-in for Alex’s time-to-interactive metric, and it lets you specify network performance and location to boot.
Overall, it’s much simpler to talk about tradeoffs when you have some initial objective numbers to kick around. I have at various points in my career been for and against doing everything client side: I delivered Flash applications for a few years, and more recently I commissioned a mostly-front-end project where we determined the performance budget upfront. The sad logjam of a silver bullet duel between opinionated developers can only be broken by agreeing on a goal and a way to measure it.
-
Such an influential classic. I have always loved the calculus-like conclusion that an expensive operation must be done continuously instead of intermittently.
-
The recommendation to separately test each combination of feature flags/toggles sounds sensible, but the number of parallel tests per commit would grow at O(2^n). That’s unworkable. I’m unsure of a solution to this. I’ve only been exposed to a few feature flag setups, and they all seemed to be periodically surprised by weird flag interactions as a fact of life.
-
O(n^2) isn’t a problem when n is small; you can choose practices that keep n manageable (eg prioritise work that finishes a feature over work that starts one, even if that increases communication overheads).
Team practices are mutually supportive, so it’s often difficult to see how a given one could work (since in your environment it would lack its supporting practices) even if others are getting good results with it.
-
Most feature flag setups I’ve seen have a dozen or more flags, though. Thousands of potential test combinations. I imagine you’d get some backpressure when your tests start to take forever or cost a fortune, but you’ll get that pressure really fast at O(2^n). Tests flipping each one individually with some developer-specified combinations seem to be more tenable, closer to O(n).
-
-
-
As a programmer, I read this and think, yes, that’s an unsurpassable moat. How will Apple–much less OpenStreetMaps–ever catch up?
As someone who worked with Sanborn fire insurance maps in a previous career, I’m not so sure. Sanborn maps had even more detail than today’s Google Maps–they showed not only building footprints but building function, number of floors, construction materials, and other features of interest to fire insurers (sometimes interior structural walls were indicated). They existed for big cities but also for places like Circle City, Alaska and Adrian, Michigan. I have a hard time imagining the level of effort that went into creating and maintaining these maps (they were literally updated by mailing out sheets with bits of paper you would cut out and paste over your existing map, usually at the level of individual buildings). But people managed to do it without aerial or satellite imagery, or ML image recognition, or any of the other tools available to us today. It’s hard to imagine that Apple couldn’t–if it wanted to–replicate something a much smaller company (the Sanborn Map Company employed 700 people at its peak) was doing a hundred years ago.
-
The Sanborn example is a really good one. As a fire insurance company, they invested in good maps because they were potentially liable for a lot of unexpected costs from inaccurately-estimated risks. The maps were literally Sanborn’s business. Apple sells phones and computers so they just need a good-enough map to keep people from jumping ship to Android or allowing GMaps an enclave in iOS territory. What does Google need this level of detail for? Ultimately they sell ads, and they’ve been very creative in figuring out ways to expand the potential surface area for ad sales and improve consumer data flowing back to them.
-
I agree with you, it’s all about who the detail is for. It’s not unsurpassable. It really depends what you’re trying to do.
Mapping is one of the most subjective pieces of data you can offer: a map’s value is only what the reader gets from it. That’s why we have so many… hiking maps, road maps, the fire maps you point out. Is the information that the article notes others don’t have really that valuable? Not to me. I’m sure it’s valuable to some. I’ve tried Apple Maps again because it worked nicely with the iPhone X out the box (note to app developers: you don’t get second chances, you gotta be there at the beginning) and it seems fine for road maps, which is what I need it for. I also like the Yelp reviews that are embedded. I remain skeptical about the traffic information, though.
Waze is a really good example of a map that’s hyperfocused on a single use case: driving. You got roads. You got traffic. You got where you can get a donut. You don’t need to know the shape of a building.
I guess I just don’t find the idea of moats all that compelling. I think we’ve seen time and again in tech and elsewhere that when people see a moat, what you usually have is a very broad offering which leaves opportunities for very focused offerings to do better (even Google was this at the beginning, Yahoo had all the content out the wazoo, and everyone thought you couldn’t compete with that, and Larry and Sergey just built a very good search engine that rocked the one Yahoo had).
-
-
I sat next to a Apple maps engineer on a flight recently. Was told it’s a 1500 person org. Kind of shocked me.
-
-
-
What a strange article. Author lists every common benefit of REST and just disagrees with each one while providing no new information. “No it isn’t… no it doesn’t… that’s not true… nope, not that either.”
If you want to design an RPC API and stick all your semantics into POST bodies talking to a single “/do” endpoint, fine. Personally, I much prefer to interact with a well-designed REST API like Github’s with its RFC-compliant URL templates, header-driven paging, cache semantics, and more.
-
Have you used Github’s GraphQL API yet? Personally, I’ve found using it to be a breath of fresh air in comparison to their REST API, which was easily one of the best REST APIs I’ve used and leagues ahead of most implementations. Give it a go, the RPC-like mutations are particularly wonderful.
-
-
-
-
These few HTTP verbs
You can have as many HTTP verbs as you want.
HTTP actually is an RPC system with verbs as the method names. REST, though, is about switching API design away from verbs and towards nouns. The problem outlined in this article is that the author is still designing verb-first RPC APIs but then trying to shoehorn those into “REST” – which is of course painful.
-
Execution in the Kingdom of Nouns
Slightly related.
-
-
REST is not designed for CRUD operations specifically. It is based around the idea of performing some ACTION against some kind of ENTITY, and if you are running into issues like these you probably don’t have very well defined entities or you are trying to wedge everything into one bucket instead of knowing where to draw the lines.
-
Okay but what do you do when you need to perform some ACTION against three kinds of ENTITIES? It just doesn’t work.
And that isn’t even true. REST is about Transfering REpresentation State, i.e. CRUD. Where do you see “perform arbitrary actions on entities” in “transfer representation state”?
-
I can think of a few options:
- Chain the three actions so they have to be performed in order, such as with a multi-page form. Mastadon’s API requires that photos be uploaded before they’re used in a message.
- Create a unified entity that wraps all three. Old-style multipart file uploads do this in a single request.
- Model a collection that provides space for three sub-resources. This SO answer explains it succinctly.
This is not challenging at all. REST can handle all kinds of applications just fine, and the decisions required to make it work are exactly the same ones you’ll be making in your own server code. You might have to do some up-front modeling work to adapt your application model to REST to save your end-users a headache if they’re already confident with other APIs, if it’s a worthwhile trade-off for you. It’s hardly an example of REST falling apart!
-
Cherry picking a few obvious examples is not particularly convincing.
But if it’s “not challenging at all” then maybe you can solve this for me. I have a REST API that handles task scheduling for multiple teams. Tasks have different interactions, A blocks B, B can only be done Tuesday-Thursday, C can only be done on weekends but not concurrently with A or B, but doesn’t depend on either of them being done.
Now we need to reschedule A. PUT /task/A {“start_time”: “new time”}. This will reflow the entire schedule and require user approval of changes. So how do I make this RESTful? In practice, possibly hundreds of entities are affected, and that’s not an infrequent edge case.
Hint, things that will not work:
- action chain, this would potentially involve hundreds of RPCs and would need substantial business logic on the client side, and we must support 4 client platforms
- unified entity, this is just the entire project
- a virtual reschedule operation “resource”, this is just an RPC, if you suggest this you have failed
-
Interesting problem! If I’m understanding correctly, you want to make it possible for Task A to be updated, but you need the result to be provisional in some form so that the implications can be approved? Does the application do the reflow on its own and then ask for a thumbs-up?
Sounds like a branching operation, since you have that user approval in the middle. So, the client might POST a proposed new Task A and get a 303 response with changes for approval: “Had to move B to Wednesday to fit A, is this okay?”. Nothing would actually change in the master schedule until the user had followed the chain to approve the various constraint resolutions. The model (and associated resources) could look a lot like Git trees, with alternative branching histories of different options that later get merged depending on conflicts.
If you’d rather require the user to resolve conflicts themselves ahead of time, the client might PUT a change to Task A and get a 409 response with a list of conflicting tasks. Then it’d be up to the user to figure out that moving Task B to Wednesday will make room for Task A, which would be a bummer for the user but would save the effort of attempting to represent alternative possibilities.
In both cases, the client app is following prompts and links as it moves between requests and responses. The resources change along the way depending on whether it’s the user or the application that’s tracking alternative states, but the client need only walk the API piece by piece the same way you can make complex branching histories on Github by typing into boxes and pressing buttons on web pages.
-
Good effort. We considered of all of those ideas in some form but ultimately just gave up on REST.
you want to make it possible for Task A to be updated, but you need the result to be provisional in some form so that the implications can be approved? Does the application do the reflow on its own and then ask for a thumbs-up?
Yes and yes. Except potentially the client will send a batch of edits to update, create, and delete multiple tasks. That initially looked like a POST to our /tasks endpoint with a list of operations. I don’t think that’s particularly RESTful. We ended up with an RPC API that allowed you to submit multiple RPCs as a transaction. That made the change endpoints less special case-y, since the batched RPCs and regular RPCs were the same code.
In both cases, the client app is following prompts and links as it moves between requests and responses.
This would generate far too many requests. We really wanted to keep it to 1 request, 1 response per save attempt.
Unfortunately, in order for the conflicts to be meaningfully displayed, the entire result of the change had to be returned, which means returning every changed entity. We ended up returning property-level diffs of every entity, allowing the user to reflow manually, update, and get a new list of diffs from their previous attempt. Every request ended up being really stateful, for this particular UI action and for most other write UI actions.
You’re spot on that the model looked like git trees, the application ended up like a git repo: a user’s entire project cached locally, and most updates done with sync-from-revision-N style RPCs. We didn’t think it would be valuable to have git-like resources representing change sets, since the change sets were never actually stored in our data model. It makes more sense for e.g. GitHub when those change sets are the data model. And I definitely don’t think this makes any sense as a general purpose way to handle complex changes in REST applications. IMO it’s pretending you’re RESTful but really just placing a RESTful transaction layer under your application, rather than actually writing your application in a RESTful way.
It’s not like I hate REST or anything. It works great for applications where you really are transferring representation state around. But for us, the client effectively had no say in what the data would look like, it could only perform actions and get the new state. Modeling that as proposed changes to state just did not work, especially when faced with concurrent modification. Many of our actions potentially affected multiple entities based on complex business logic, and it would just be too much work for the client to perform even some of that logic and submit a new state that made any sense.
So I guess my real problem isn’t with multiple entities, it’s that REST pushes business logic into client side code, and that logic can become exponentially more complicated as more and more entities get involved. For APIs meant to be used by third parties to create new functionality, the logic is supposed to be in the client side code, and REST provides a lot of flexibility. But for your own application code you have the option of building the exact operations you want directly into the server. If your application is all about navigating through different resources, and extremely reusable resources like photos, REST would work just fine even for working on multiple entities as you described. Not all applications work like that.
-
-
-
-
-
-
Write code. Not too much. Mostly procedural. (Apologies to Michael Pollan)
-
Is this a Michael Pollan quote?
-
-
-
migurski
8 months ago
|
link
| on:
Smart contracts, Heise Technology Review, Oktober 2017: original interview in English
Excellent article. I particularly liked his warning to look for evidence of IBM PR whenever blockchain is mentioned in the press, because they’re the gorilla testing this out in a bunch of places where it might or might not make sense.
-
it’s terrible, even in sources that should know better like the FT.
There’s a press-release news article for every Blockchain(tm) pilot launch, but very few for reports on how the pilot went. I found the report for one, ECB and Bank of Japan testing Hyperledger, where they called it “immature” and “not a solution”.
-
I see that we have discovered what is clearly the ultimate use for smart contracts, i.e. cat pictures on the Blockchain. That are popular enough to clog Ethereum. https://www.reddit.com/r/ethtrader/comments/7haqky/i_think_cryptokitties_is_clogging_the_network/
-
-
Google is a media and advertising company, but so far hasn’t shown willingness to act like one by employing human content overseers. They don’t really understand media, except in the most reductive technical terms. Maybe pressure from Al Franken will help.
-
I didn’t see it mentioned anywhere, so for those who enjoyed the “deep thoughts,” they’re by Jack Handey.
-
Thanks for the info! I did not remember where these were from :-)
I found the quotes in a txt file on an old disk while cleaning my backups.I’ve updated the add-on now.
Deep Thought Tabs v1.1 now has a quote attribution as well (among other updates).
https://github.com/TheCodeArtist/deep-thought-tabs/commits/master7431907 Update AddOn version to 1.1 6ac746e Modify layout 29d80dd Trim unnecessary html d67ca19 Update quote attribution 13a1768 Add quote attribution with link d9bad4b Tweak font sizes a8c5b5f Fix CORS issues with proper permission-
Jack Handey is a comic genius. He wrote many of the weirder SNL skits of the 90s like Unfrozen Caveman Lawyer, and Deep Thoughts was an early feature in Army Man Magazine (“America’s Only Magazine”):
Although Army Man was never widely distributed, it gathered a lot of attention in the comedy world. Two of its writers (John Swartzwelder and Jon Vitti) were picked up alongside Meyer to be part of the original writing staff of The Simpsons by the show’s developer and show-runner Sam Simon, an enormous fan of the magazine. Eventually other Army Man writers would go on to write for The Simpsons in later seasons, namely Jeff Martin, David Sacks, Ian Maxtone-Graham, Tom Gammill, Max Pross, Kevin Curran and Billy Kimball.
All of Army Man is available at armymans.tumblr.com.
-
Thanks for the link. The Army Man Magazine is fantastic!
-
-
-
-
Excellent article. I thought this part about unintentionally excluding women was powerful:
Other self-taught narratives, such as starting with Wordpress-based design backgrounds and moving from more simple themes to more complex themes where PHP knowledge is required, to plugin development is a completely valid narrative, but a path that is predominately for women.
This was a bombshell. I’d been loudly criticising the language and, through that criticism, implying that people using the language weren’t as good me, weren’t good programmers. And suddenly I was thinking about all the myriad ways that someone with that background would feel othered by me, like they didn’t belong and weren’t welcome in the communities I was a part of.
All of the ways in which I was actively participating in the exclusion of women from STEM.
Every common inter-language contempt pattern seems based on a similar dynamic rooted in some kind of us/them stereotype. Node.js people are children. Java people are corporate squares. Situated mostly in the Python world, I don’t know how my own community is stereotyped.
-
Other self-taught narratives, such as starting with Wordpress-based design backgrounds and moving from more simple themes to more complex themes where PHP knowledge is required, to plugin development is a completely valid narrative, but a path that is predominately for women.
I’d really like to see some research or statistics showing this to be the case. I’ve seen it as more of a general “this is how I advanced in web development” among people (notice: people, not women, men, minorities…but people) coming from a non-programming (or even non-web) background. Either way, it’d be good data to have.
-
Out of curiosity, what would having this data change? Would your actions be any different? Your thoughts?
I ask not because the data wouldn’t be interesting (it would be), but because I think this kind of request for proof is often used to subtly undermine a valid point. There seems to be a higher burden of proof for claims that relate to the experiences of oppressed groups in technical fields.
This may have not been your intention, of course, but I think it does warrant a mention.
Also, FWIW, I identify as a man but followed the PHP plugins -> PHP apps -> other languages route myself. Although this was before Wordpress was everywhere.
-
Out of curiosity, what would having this data change? Would your actions be any different? Your thoughts?
I’d reference it in future discussions on policy. For me, personally, it’d probably change how I treat my recruiting and referral pipelines, how I evaluate priors when modeling new acquaintances, and how I understand the demographics in tech.
When faced with new facts I try to make new opinions–what do you do? :)
-
-
You beat me to it. I found the article to be great identifying lots of bad patterns that were basically social shaming for ego or emotional reasons rather than constructive criticism of programming tools for specific uses or objective attributes. Then, it drops the minority card out of nowhere on a subject that I thought was about people doing hardcore stuff mocking what they believed to be amateur work. I usually don’t personally mock people who barely know programming that are using PHP or writing plugins since it’s significant work for them. It’s the people that know good tools that create more ecosystem in crappy ones I call out for increasing amount of crappy or poorly-tooled stuff out there (esp if security risk). That’s all I’ve ever heard from others, too, outside the mantras that get repeated which again were about perceived superiority or ego around language crowd.
I’ve never heard anything about this predominantly being about or affecting minorities. I’d counter it again, though, on grounds that this is typical PC style where people mocking use of a technology over their beliefs about the tech itself are reframed to be in some way attacking/suppressing minorities because the minorities themselves take offense to it (their beliefs not the “attackers”), associate their minority status with something not relevant to it, and then possibly reduce their own engagement on false, defeatist beliefs. The solution is for people to explain the truth to them so they stop thinking it’s because they’re a minority. That’s a really self-reinforcing trap to fall into best avoided where possible. The other solution if minorities are clustering around weak tech is to get more of them into strong tech with mentoring, coding conferences/camps, good intros with practice problems, and so on. Get them coding the good shit to increase the visibility of their talent. Fortunately, there’s a lot of that going on for programmers in general which can help minority members, too.
So, I’m seeing recommendations of do less bashing of people using tech X/Y/Z, informing minorities people (esp industry professionals) are reacting negatively to X/Y/Z instead of them, and get more of them either out of X/Y/Z or doing awesome stuff with such tech. Just the key takeaways anyway.
-
The article specifically mentions women, who (at least in the US) are actually in the majority. Even if we assume that the article was written from a global perspective (where I think there are slightly more men, not totally sure), referring to women as “minorities”, in addition to some of the other phrases you used (“PC”, “minority card”, “minorities taking offense”, general victim blaming) show a certain level of distain for the valid concerns of oppressed people.
This is a bad look and one that is best avoided, not to mention its role in perpetuating the very problems this comment appears to be in denial of.
-
“The article specifically mentions women, who (at least in the US) are actually in the majority. “
In tech, they’re a minority. There’s endless articles about oppression, lower wages, harassment, and so on. There’s people who stay writing about these things to raise awareness and get action happening. They’re activists of sorts. Then, the author is also talking about the contempt culture of programmers mocking other programmers for their choices. I’m responding to both of those.
“show a certain level of distain for the valid concerns of oppressed people.”
Having been a minority in black school where whites were hated, anti-intellectual parts of rural America, and female-dominated environments, I certainly am aware of the concerns of people oppressed due to race, gender, or even technology preferences. I’ve received everything from no right to participate in something (race/gender) to fighting for my job to physical beatdowns by at least 3 people. I’ve tried to avoid being a hater given most were biased but otherwise decent (non-aggressive). That said, what I don’t tolerate is a political belief pushed by a subset of America that one is attacking or suppressing another person/group if the other group takes offense at your otherwise non-offensive words or actions. The sophist technique in question is to arbitrarily decide the words are about a specific thing they weren’t about, call them hate speech or an aggression, and then claim the speaker must change their words or actions since they are “attacking” the other person. I mean, there’s clearly a line to draw where certain words were defined for hateful reasons or are clearly being used for attacking someone. I’m not talking about that subset as “Be Civil/Courteous and Compassionate” covers that.
In this case, there’s a problem of people bullying others who use tech that’s perceived as inferior possibly because the people are inferior per the bullies. The author says that minority members, a subset but not all, are feeling oppressed since they believe it’s instead an attack on minority members about their gender or whatever. It’s an attack on whoever uses the tech. The minority members have a false belief. Author is reinforcing that false belief. They author is also supporting the sophist claim that the existence of that belief in their minds means it’s true, infers those bullies are also anti-minority, and the bullies should change their beliefs to stop being anti-minority. That’s non-sense. The minorities should stop believing false things possibly with the help of those of us who recognize these patterns and fight actual harm to minorities. Plus everyone else for me. Most important, the bullies should stop being bullies since that’s inherently bad and can lead to such false beliefs as people often internalize attacks thinking they’re really responsible for them or something.
That’s my takeaway from the claims of the article involving some people doing provably harmful things, others believing nonsense, and I have two problems to address on top of introspection about my prior posts that fit the contempt problem. There’s also probably nonsense behind what the bullies are doing but that would be a whole other article that could go on and on. Rather just counter the bullying itself than try to eliminate all nonsense from the world. ;)
-
While I don’t discount your personal experiences, and acknowledge that your feelings are valid, this sounds a lot like “reverse racism”, which is not a real thing. It is impossible for someone in a privileged group to know what is it like to be the subject of racism, sexism, etc. Comparing systemic oppression carried out over hundreds of years to some personal experiences minimizes the very real harm that has been done to huge numbers of real people throughout history. It is truly unfortunate that you have had experiences where you were not treated fairly, but it is important to recognize that, sadly, this is not something unique to you. Everyone has had bad things happen to them, and this is not something that we can control. But whether to ascribe such events to the race/gender/class/etc. of the perpetrators is something we choose. People of all types can be assholes.
The sophist technique in question is to arbitrarily decide the words are about a specific thing they weren’t about, call them hate speech or an aggression, and then claim the speaker must change their words or actions since they are “attacking” the other person.
No, that’s not really it. The reason certain things shouldn’t be said is that they perpetuate or refer to real oppression and harm that has been done to people in the past. If you say something that I find offensive, and I ask you to not use a certain word or phrase, all you have to do is not say it (or find another way to say it). Do some people take this too far? Certainly. But writing off all attempts to improve the way people communicate and find ways to talk and think about real world problems is not the way forward. It’s really not that hard to just not say offensive things. And if this is a common problem a person encounters, that may be a sign that what they are saying is not in line with where society is or will be. Some things that used to be OK to say are no longer acceptable. This is how it has always been.
Again, “I don’t like that I can’t say offensive things” is not a good look. It doesn’t matter how dressed up this sentiment is; sounding like an academic argument or not, the underlying intention simply doesn’t persuade.
The best way forward on these issues is to do more listening (not to me, but to the folks the author is discussing) and less explaining to such groups how they need to change. You might not agree with what someone is saying, but calling it “nonsense” and waiving them off demonstrates a lack of willingness to really engage on the issue. And this approach makes it easy to ignore the other interesting things you might have to say.
-
“this sounds a lot like “reverse racism”, which is not a real thing. It is impossible for someone in a privileged group to know what is it like to be the subject of racism, sexism, etc. “
And boom, there it is! I knew you’d believe that article of faith that some groups push to gain power over their outgroups. Here’s the theory with strong evidence: most groups will give favorable treatment to those they iddntify with (in-group) but discriminate against those that are significantly different (outgroup). Discrimination tends to go up with more difference or competitive interests. This is a human problem. There’s evidence that all groups do it when in power.
Then, a segment of leftists will go further, without evidence that no group ever does this to whites or males. We’re always treated priveleged regardless of who is in power. We never receive structural discrimination as those in power favor other members of their own group. This is a lie easily countered by piles of experience reports of whites or males in businesses or schools dominated by other groups.
It’s easy to test. Did you collect data on black or latino schools that had white people in them? Did you survey if whites had negative social or academic experienced due to ill-will or bias from classmates or teachers? And similar for whites in businesses run by non-whites in terms of pay, promotions, or what jobs they were assigned? Or… typical case… you or your sources developed your stated theory without ever looking for data on what whites experience as outgroup. That would be non-scientific, faith-based, and only do damage in reverse direction. Hence the term.
Re more problems happened to blacks or minorities
They got worse treatment. We also put more action into helping them. No excuse to ignore evils done against uncommon group. It takes little extra effort to fight all structural racism and sexism. It takes lots of effort to push reasons to ignore those people. I fight for everyone, was (is cuurently) an oppressed minority, and call such things out. I encourage you to survey whites in minority-dominated schools to see if the actions and reported self-doubts & rage match what minorities say. They did when i did it.
Re words
Break nearly over so I gotta be quick now. Some words and symbols were specifically about oppression. I already said we should fight those. My problem, which author does, is to define words or actions that are intended for one purpose to mean something totally different. Then use that secomd, false meaning to argue for action against the speaker. That’s dishonest activity that usually damages the source of those words/actions usually dor political benefit of those reframing it. It’s a known technique in sophistry. Author did it, it would reinforce false victimhood in minorities that already have real problems to worry about, and so I countered it by showing that bullying wasnt about minorities at all. This empowers minorities that believed it by letting them know their status wasnt cause of the insults: only the bully’s false or slanderous belief about a tech stack. They can then ignore or counter the bully with more self confidence.
Im stepping out of this further. Ill still read any replies but tangent is long enough. Except that mistake pushing politics, author’s article had great points that got me thinking extra on my habits.
-
-
-
-
Then, it drops the minority card out of nowhere on a subject that I thought was about people doing hardcore stuff mocking what they believed to be amateur work.
The idea that there’s a “minority card” is pretty insulting. This post isn’t asking for special privileges and the general dismissal of minority opinions and experiences that’s wrapped up in the phrase is lousy. Going on to suggest that minorities are responsible for discrimination against them because they’re aware they’re minorities is toxic victim blaming. Don’t do it again.
The article makes a clear link to why she thinks contempt is particularly connected to minorities (ctrl-f for “Wordpress” if you missed it).
-
“ Other self-taught narratives, such as starting with Wordpress-based design backgrounds and moving from more simple themes to more complex themes where PHP knowledge is required, to plugin development is a completely valid narrative, but a path that is predominately for women.”
If Im misunderstanding anything, it’s the above quote. I have to guess about it since Ive read trash talk about Wordpress and PHP for years without seening anyonw claim the path was for women. I read countless comments talking about how low skill it was or language was garbage. Maybe it’s recent or in low-quality forums I dont follow.
So how to interpret it? I read it as a narrative or common belief out there that being a minority destined one to weak stuff like Wordpress plugins. I countered that. My counter would be wrong if author is saying she personally was labelling women this way within her group of programmers. It depends on what she meant by it. Like I said, Ive never heard anyone say this even on forums that attract sexist comments. It’s new to me.
Re minorities, card, and victim blaming
You’re saying something completely different than I said. I was talking about incorrect perceptions about whether race/gender was related to people thinking Wordpress development is weak. While you’re warning not to say that people talking about discrimination are responsible for their own discrimination. That’s a horrible strawman of a claim Id never push. Im not sure why you brought it up.
Back to my actual claim and context. People ascribing more responsibility to minority status than what is really caused by minority status is a known type of negative thinking that liberals and cognitive therapists have reported on. Ive seen it plenty, too. People also fake it for personal gain sometimes. Work mass market customer service for a while like I did to experience it regularly. So, I always consider it. I was addressing the first possibility, though, since the latter is uncommon to rare in comparison and I gave benefit of doubt.
Again, though, if the author was referring to herself on that narrative instead of something others were believing about themselves then my card claim wouldnt apply. She’d have been simply discriminating against women in that case and stopped after realizing it. If true, it’s good that she stopped and drew attention to serious problems. Im still unclear on how many programmers out there are pushing a narrative that plugin development is women’s work.
-
You wrote:
[minorities] associate their minority status with something not relevant to it, and then possibly reduce their own engagement on false, defeatist beliefs. The solution is for people to explain the truth to them so they stop thinking it’s because they’re a minority.
This victim-blaming. Please don’t tell me I didn’t read it.
We’re veering off into meta talk on moderation. If you have more to say, please message me directly, but let’s leave this subthread here.
-
I see where the disagreement is at least. Yeah, we’ll talk more about that in the future or another thread just due to this being so far into meta. Im stopping on this one. Especially since you’ll want references I dont have on my phone.
-
-
-
-
-
-
Author is concerned mostly about Java tools (client code generation, specification generation from annotations) and lack of “hypermedia” support. Hypermedia is not a big deal, is there any real-world API that uses this approach?
Lack of forward compatibility, though, might be a problem with OpenAPI itself. API specifications in it describe only current version of protocol and you can’t define forward compatibility rules, such as “if enum has other value, treat it as this value”. At least “object” keys are non-required by default, just like in json schema, this enables forward compatibility. The problem might be not only with enums, but with
anyOf/oneOf, which can be treated as generalization of enums (sum types).For “robustness principle” to work, API specification should enable writer to be conservative (i.e. don’t allow non-listed values in enums) and readers to be liberal (i.e. substitute default values for unknown enum values). This is not supported by OpenAPI.
Note that “new XSD” is json schema and not Swagger/OpenAPI (OpenAPI uses some subsets of json schema in its format). YAML is used only as syntax sugar over json, primary data model of all this is json.
I don’t understand this argument at all. Swagger is a tool for generating API documentation. Client generation is afterthought, it’s documentation tool primarily.
Github’s REST API uses hypermedia extensively, in the various “*_url” properties and RFC 6570 URI template values.