This post is good, and it's a great example of taking a problem and solving it with the appropriate tech with the right amount of depth. It really helps to have full domain knowledge of your customers as well.
However, I do not like how it is framed as "simple html is better than react" - because you could just as well have told the same story as a react developer.
(Nb. I could go on forever about the complexities and intricacies of storing things session based on a server vs browser based and etc - and lots of other things that were skimmed over in this article, but that would be too long)
All of those things that are simple in html are also simple in react.
It's literally the same code - there's nothing preventing you from using browser based html validation in react - all the same code that gets complicated in react (overly complicated validation logic) also ends up being complicated in astro - they have their own thing around schema validation etc and integrating it within an astro site means you have to integrate their client router etc etc.. so it's very easy to go overly-complicated there as well.
The comparison is also with an off-shore team doing development for you with probably incomplete knowledge and the way projects are structured they have an incentive to create the solution as fast as possible, in as little time as possible, with the biggest amount of complexity as possible.
The last point is devious - it's not necessarily that the contractor does this by design, but the incentive structure makes it so something that's overly complicated actually benefits them, so they don't have a direct incentive to go with something simple.
Anyways, a simple solution, directly addressing the problem at hand is always better - no matter what stack you pick.
(I'd like to say that I don't have anything against Astro's form validation, I was just trying to highlight how there's more to it than "native html browser validation")
Originally Indians didn't drink tea. British East India company got Indians addicted to tea/chai when they sold it for free. Then the real prices came in.
it could probably work as well to close your eyes instead of staring at a wall.
i've always found meditation types revolving around focusing on one thing (candle, wall etc), or nothing (empty mind) to be really hard. my mind just wanders and i end up super anxious, frustrated, and exhausted - resulting in me giving up pretty quickly
What I've found is that focusing on "everything" - ie sitting still and trying to observe your surroundings, your body, all sounds simultaneously seems to work much better. It's easier to get to a calm state this way.
Also, doing this while walking can also work - but perhaps easier to accidentally start thinking about something else
The idea as far as I understand it is that it’s the point exactly to sit with and process whatever comes up in your mind when you don’t distract yourself. The more often you do it, the more present you become, and the more ability you develop to discriminate between what really is there and what is your imagination/unprocessed memories of the past. The object you focus on merely serves as a still reference point from which you look at what else is showing up (feelings, thoughts, memories).
There will always be anxiety, otherwise you would have processed it already and not hurried away into other activities. It sure feels life-threatening, but as long as you don’t give in to the illusion and remind yourself that it is not, there is no rational reason to jump away. Breathing is a typical way to remind yourself that you are safe in the present environment. And the gift you receive is more and more clarity and a relaxed base state from which to face what’s next.
i wonder if you could use a bayesian classifier, like the first anti-spam measures used, to automatically classify these submissions.
Kind of off-topic - but why is there always so much focus amongst AI-bros on how good or whether or not LLMs are good at building UI? My shallow assumptions were that the reason is because that's what LLMs are particularly bad at.
But lately I've kind of gotten the sense that a lot of people seem to mostly be building UI stuff with LLMs. Weird.
I think they just forgot to link their train of thought. I have also used Levenshtein distance for deduplication comparisons so I can guess where the story came from.
Thank you for your question. At least there is one person who shares opinion, when down-voting. This is good, because I know what I did wrong, and I highly respect any respectable feedback ;)
I really hate, when people down-vote, without giving any feedback what they don't like.
Levenshtein, in combination with Machine Learning and big data engines, like Apache Sparks, can do a good job comparing content as well ;)
Wanted to share another approach, and ideas to people who are interested in comparing strings, doing fuzzy searches, and searching for duplicated content.
The author is talking about the case where you have coherent commits, probably from multiple PRs/merges, that get merged into a main branch as a single commit.
Yeah, I can imagine it being annoying that sqashing in that case wipes the author attribution, when not everybody is doing PRs against the main branch.
However, calling all squash-merge workflows "stupid" without any nuance.. well that's "stupid" :)
I don't think there's much nuance in the "I don't know --first-parent exists" workflow. Yes, you may sometimes squash-merge a contribution coming from someone who can't use git well when you realize that it will just be simpler for everyone to do that than to demand them to clean their stuff up, but that's pretty much the only time you actually have a good reason to do that.
* git merge ALWAYS does a merge and git pull ALWAYS does a fast forward.
* git log --first-parent is the default. Have a git log --deep if you want to go down into branches.
If you use a workflow that always merges a PR with a merge commit, then git log --first-parent gives you a very nice linear history. I feel like if this was the default, so many arguments about squashing or rebasing workflows wouldn't be necessary to get our "linear history", everyone would just be doing merges and be happy with it. You get a clean top level history and you can dig down into the individual commits in a merge if you are bisecting for a bug.
I set merge.ff = false and alias ff to merge --ff-only. I don't use pull but I do have pull.ff = only set, just in case someday I do.
The graph log and the first-parent log serve different purposes and possibly shouldn't be the same command conceptually; this varies by user preference but the first-parent log is more of a "good default", generally. Merges do say "Merge" at the start, after all.
This is what I advise people to do in consulting engagements, too, it's not one of my personal quirks.
Do people actually share PR as in different people contributing to the same branch?
Also I can understand not squashing if the contribution comes from outside the organization. But in that case, I would expect a cleaned up history. But if every contribution is from members of the team, who can merge their own PR, squash merge is an easy way to get a clean history. Especially when most PR should be a single commit.
We do. If we are building out a feature, none of its code is merged into main until it is complete (if this is a big feature, we milestone into mergeable and releasable units).
The feature is represented by a Story in Jira and a feature branch for that story. Subtasks in jira are created and multiple developers can pick up the different subtasks. There is a personal branch per subtasks, and PRs are put up against the feature branch. Those subtasks are code reviewed, tested, and merged into the feature branch.
In the end, it is the feature branch that is merged (as a single merge commit and complete unit) into main, and may well have had contributions from multiple people.
I get your POV, but I’ve always considered that long-lived branches in the canonical repo (the one in the forge) other than the main one should be directly related to deployable artifacts. Anything else should be short-lived.
There can be experiment on the side that warrants your approach, but the amounts of merge going back and forth would make this hard to investigate (especially when blaming) I would prefer to have one single commit with a message that describe every contribution.
Unlike merge strategies, where squash-to-merge is almost always motivated by someone not knowing how to use the tools well, branching strategies can be very diverse and project-dependent for very good reasons. Some projects have to maintain multiple versions of the thing they produce simultaneously, others don't. Some projects effectively maintain a patchset on top of some external upstream project, some are the upstream that's being forked by others - and some are somewhere in-between. Sometimes you break half the world to slowly fix it afterwards in a long running refactor, often you don't. Often there's a single canonical repo where all work happens, sometimes there's not. There's no genuine one-size-fits-it-all, but fortunately, git is very flexible there.
Blame, bisect etc. work well with histories with lots of back-and-forth merging, as can be easily seen in Linux, so blaming is definitely not a reason not to do it this way if your project calls for it otherwise. Perhaps one issue with such workflow is that some popular review tools aren't exactly great at letting you review merge conflict resolutions.
Somewhat Linux-like. You could probably improve it purely from a git perspective by letting subtask dependencies be many-to-many (the commit graph is a dependency graph), but what you have is probably best for your whole Jira workflow.
I think the point is that if you have to squash, the PR-maker was already gitting wrong. They should have "squashed" on their end to one or more smaller, logically coherent commits, and then submitted that result.
It’s not “having to squash”. The intent was already for a PR to be a single commit. I could squash it on my end and merge by rebasing, but any alteration would then need to be force-pushed. So I don’t bother. I squash-merge when it’s ready and delete the branch.
Does orange peel not produce any CO2 / methane when left like this? I'm assuming there is some negative carbon footprint before this becomes a positive?
The ecological win definitely looks nice on paper, but whenever people talk about compost the carbon footprint / gas emissions is always at the front of people's minds, and I don't really see that discussed in the article.
The article does say
> Especially since, in addition to the double-win of dealing with waste and revitalising barren landscapes, richer woodlands also sequester greater amounts of carbon from the atmosphere – meaning little plots of regenerated land like this could ultimately help save the planet.
How long will it take for it to cross the CO2-neutral mark? Maybe a silly question, definitely not my area of expertese.
CO2 is going to be neutral for the peels. You're just transporting it from where the oranges grew to where they were dumped. The CO2 benefit is purely from the trees and other biomass that grow where they wouldn't be growing before.
As for methane, that's a good question. Orange peels are better than most things because the limonene inhibits methane producing bacteria. But you'd still get quite a bit in the deeper piles (that produce the anaerobic conditions needed for methane production).
Spreading them out more would help, but might interfere with the beneficial effects.
China could definitely do this, to offset the minuscule of the destruction they do with the dark fishing fleets around (and possibly in) protected marine areas.
The orange peel is going to decompose and produce CO2 either way. Methane is produced when there is not enough oxygen available while decomposing, which certainly seems a possibility if it's dumped in big piles.
Remember the orange trees took the CO2 out of the atmosphere to make the peels. Some of it, probably most of it, is going back into the atmosphere but some of it is going to become soil carbon which could be retained for decades
You're getting downvoted but it's a reasonable question if posed in good faith. The tl;dr is that there are really a few options for what could happen to those orange peels:
(1) Landfill burial
(1a) Without methane capture and use: Produces methane, relatively high short term warming potential.
(1b) With methane capture and use: Ends up as CO2 after burning the methane.
(2) Composting (this approach)
(2a) Mostly aerobic: Produces CO2
(2b) Mostly anaerobic: Produces methane
A deep pile that is never turned will decompose anaerobically, resulting in fairly undesirable methane. A shallower pile or one that is mixed well will result in mostly aerobic decomposition. The aerobic decomposition will produce CO2 but not huge amounts of it. Each hectare of land could absorb something like ~8 tons of CO2 per year; with 7 hectares, the CO2 emitted by composting 12t of oranges is going to be dwarfed by the new vegetation. After a few years when you're growing big trees, the rate of CO2 absorption might rise as high as 20-30t/year/hectare in costa rica's environment. And this is probably an underestimate, as the soil amendment of the orange peels seems to have stimulated faster regrowth than would have happened otherwise.
And perhaps more to the point: There isn't really a purely "no co2" way of disposing of organic matter other than perhaps burying it at the bottom of a deep mineshaft (but the co2 or methane will be produced anyway). Landfilling it is strictly worse - you still get the decomposition products, _or worse_ because you'll mostly get methane, but without producing useful soil byproducts.
Overall this project is a huge win on a carbon perspective and a waste reduction perspective.
It's not a reasonable question. What's the alternative for the orange peels? They were going to rot and release that CO2 whether they did it in a big pile here or somewhere else.
But seriously GP could have had a mental model that landfilled orange peels might sit there for a long time -- which depending on conditions and food could be true on human scales (like 10-40 years) but not on the scale of 100 years. Especially if the conditions were dry -- a dry orange peel is pretty robust. That's not likely to be the case in Costa Rica, but I'll forgive some naivety here absent demonstrated malice.
However, I do not like how it is framed as "simple html is better than react" - because you could just as well have told the same story as a react developer.
(Nb. I could go on forever about the complexities and intricacies of storing things session based on a server vs browser based and etc - and lots of other things that were skimmed over in this article, but that would be too long)
All of those things that are simple in html are also simple in react.
It's literally the same code - there's nothing preventing you from using browser based html validation in react - all the same code that gets complicated in react (overly complicated validation logic) also ends up being complicated in astro - they have their own thing around schema validation etc and integrating it within an astro site means you have to integrate their client router etc etc.. so it's very easy to go overly-complicated there as well.
The comparison is also with an off-shore team doing development for you with probably incomplete knowledge and the way projects are structured they have an incentive to create the solution as fast as possible, in as little time as possible, with the biggest amount of complexity as possible.
The last point is devious - it's not necessarily that the contractor does this by design, but the incentive structure makes it so something that's overly complicated actually benefits them, so they don't have a direct incentive to go with something simple.
Anyways, a simple solution, directly addressing the problem at hand is always better - no matter what stack you pick.
(I'd like to say that I don't have anything against Astro's form validation, I was just trying to highlight how there's more to it than "native html browser validation")
reply