Not all of them do. It's also nice to have one closer to you, so you don't have to walk to the bus stop to find out when it's time to leave house for the bus...
You could check on the phone, but I could certainly see the appeal of a fixed display in a convenient location.
I don't really understand, don't you just go out of your house, go to a bus-stop and wait for the next one? Isn't the bus arrival display more of a convenience to know how long to wait? For the bus stop in my neighborhood I see busses every couple of minutes.
You're very lucky to have high frequency transit. I've lived in several places (in cities) where the bus routes ran every 20-30 minutes. So if you don't feel like waiting at a bus stop for 20 minutes, often these days one without any seats, it's nice to be able to check the ETA.
Got it. I typically use my legs or bicycle to get from A to B. Don't like being stuffed in a metal box with strangers. 20-30 minutes would definitely warrant a nice display on your fridge!
Water gets split into oxygen and hydrogen using energy. The hydrogen then gets burned to release usable energy, which creates water. At least as far as I remember from chemistry class ages ago.
There's some truth to what the gp said. Some hydrogen will escape, enter the upper atmosphere, and be blown away by the solar wind and thus be permanently lost.
I assume that this has been happening to all gases in the atmosphere for aeons, and thus, while technically correct, it is completely negligible for the relevant time scale.
Point taken. I forgot that brackets are not shifted on my keyboard.
They do require worse acrobatics than a shift key on a German keyboard, though - one of the Alt keys is special and needed to trigger them, if memory serves.
Well, that's another argument for everyone to use an English layout for coding, I suppose.
Of course you can now set up your own trade agreements, but so can Fiji, I suppose. The point is that you have a lot less negotiating power going it alone, instead of as part of an economic superbloc that you can influence as one of its biggest members.
The time of individual European "great powers" has long gone, but somehow, large fractions of the respective populations do not realize it. Band together, or be swept aside. That nationalistic reflex is not helping.
As I understand it, trunk based development does not call for committing directly to main. It says to avoid long-lived branches for releases, whole features, etc.
There's nothing wrong with small, short-lived branches that can be quickly reviewed and merged into main.
That being said, I've been in a small team where the blessed style was to commit directly to main and do reviews "on demand". It quickly gets features deployed in a way that builds a lot of rot and debt into your project that people quickly lose a good understanding of. Then you just keep piling.
There's probably a way to get this done properly with a tiny team of very experienced and well-aligned developers; but that's usually not what you have in an environment that pushes this kind of extreme no-review-interpretation of trunk-based development.
Slow down, do reviews, avoid keeping branches open for more than a day.
What counts as "long-lived"? Our shortest lived branches are quick fixes because something got merged into main that doesn't work properly.
I'd like main to always be ready for production, but that seems an elusive goal no matter what git workflow you use.
The best way to prevent complex merges does not depend on your git strategy, but on how modular you make your code. If a change requires changes to only a single file, and your files aren't too big, there's little chance of conflict. The more files need to be changed (often because the same thing needs to be declared in 4 different places), the bigger the chance of conflict. Same with larger files. Each file should have a single concern.
For the purposes of this discussion, I'd say a "long-lived" branch is one that keeps running into merge conflicts with other code that's been developed in ignorance of the branch's contents, or a branch that acquires enough changes to not be easily reviewable in its entirety. But generally, I'd say if it lives longer than a day, that's getting too old. (Exceptions apply.)
Code should live in main/master and be in a production environment as soon as possible, but it does not have to run for all, most or even any customers/clients from the start. You can gate it behind feature switches, preprocessor directives, global constants, whatever. As long as it has an active purpose and is being developed further, it is not dead. Ideally, it will have tests.
The result of merging back to main often is that other changes will be made in awareness of your new code, and all merging will happen organically and in small increments. You also get to develop complex features bit by bit, in a way that can be verified in a real environment in a controlled way. And everything can be deployed anytime, which should happen often.
Being able to verify incrementally and get quick feedback lowers the risk of otherwise releasing a hitherto completely untested large feature into the wild in one go.
This does not absolve you from making sure that your changes actually work as intended. That will be easier if you portion the work into smaller chunks that are easier to understand than a whole, complex, all-or-nothing feature.
Of course you will still have to make sure that your small chunks fit together and make up a good "whole". However, the idea is that you're doing this exact work anyway when developing a larger feature on the side, but you might as well cut it up to deliver in much smaller increments.
This approach has its own costs and drawbacks, but in my experience it often produces a substantial net-reduction in friction and accumulated complexity and risk, and it keeps things moving, which is a benefit on its own. This is from my perspective in backend development, and it will not apply universally, but widely. Essentially, whenever you can get away with it, you should strive to deliver like this.
I think this is very key, if the development style and the direction of the project is clear, much less review and alignment is necessary.
And also
> avoid keeping branches open for more than a day
Big +1 on that, fast reviews are extremely key. Most teams I have seen often took days or even weeks to merge branches though, often because you end up waiting too long for reviews in the first place. Or because of good old bike-shedding. But also because these code reviews often uncovered uncertainties that needed longer discussions.
However usually code is easy to change, so defaulting to "just merge it" and creating followup tasks is often the cheaper approach than infinite review cycles.
I think it's still worth-while to do reviews. A second pair of eyes does wonders, and it spreads knowledge of what things exist and how they work. If changes are small, reviews can be quick. It's possible to keep building on top of code being reviewed, and even easy when using modern VCS tooling like jujutsu.
Once the code is merged, chances are it will not get changed
Those follow-up tasks will be displaced by more pressing work that will keep piling onto a slightly unstable foundation, increasing the tilt over time.
There is an excluded middle between "no reviews" and "infinite review cycles": proper, timely and efficient reviews. They are worth investing the time to get right. They will start paying dividends months down the line, and boy will they keep paying.
This is not about trying to get things perfect from the get go, but to get them done right while you're there. "We'll fix it later" is not gonna happen, and is much more expensive than it initially seems.
> However usually code is easy to change, so defaulting to "just merge it" and creating followup tasks is often the cheaper approach than infinite review cycles.
I wish this was the "default" mindset everywhere, especially in those cases where you have that one colleague that loves to nitpick everything and doesn't see an issue with holding up both releases and wasting your time over menial pedantic stuff. It would be so much easier to merge working code and let it work, and keep those TODOs in the backlog (e.g. trash).
In a sane world, code review would be like:
1. Will this work and not break anything? We checked it, it's okay. There are no apparent critical or serious issues here.
2. Here's a list of stuff that you can change if you wish, here's why it might be an improvement.
3. Okay, we have some left-over nice to haves, let's keep track of those for later (or not) and merge.
It gets infinitely worse if you're working on 3 projects in parallel and the person wants long winded calls or starts nitpicking about naming, or wants things done exactly their way as if it's the only way (doubly worse if their way is actually worse by most metrics and tastes).
My dog does this thing where she picks a stick and gets you to pull on it, and she will pull on her end, too. She gets very focused on it. Pulling on the stick is the most important thing to her in that moment, when in fact it's just a stick she chose to turn into this tug of war.
That's not entirely unlike what you're doing here. You latched onto a misunderstanding of OP's intent, and by making a thing out of it got people to pull back, and now you also keep tugging on your end.
Except she does it on purpose and enjoys it, while I think you did it inadvertently and you do not seem that happy. But then, you're not a dog, of course.
You could stop pulling on the stick. I do enjoy these doggy similes, though. :)
This is a perfect description. I've probably been the dog at some point.
p_ing, see my nearby comment about what we mean by "multiple". Does that comment make any false "assumptions"? Or, is it you who are mistaken, persistently failing to understand what your interlocutors are saying?
There is no such thing as "making an assumption" on what a process "should be". I am asserting what it should be. A multi-trillion dollar company should absolutely have a robust review process in place. If one single person can submit plagiarised and defective material onto an official platform that implicates the company as a whole in copyright infringement, management has failed, ergo multiple people have failed, ergo the failure is systemic.
It is extremely well-known that individual humans make mistakes. Therefore, any well-functioning system has guards in place to catch mistakes, such that it takes multiple people making mistakes for an individual mistake to cascade to system failure. A system that does not have these guards in place at all, and allows one individual's failure to immediately become a system failure, is a bad system, and management staff who implement bad systems are as responsible for their failure as the individual who made the mistake. Let us be grateful that you do not work in an engineering or aviation capacity, given the great lengths you are going to defend the "correctness" of a bad system.
Wouldn't that be nice. I've been party and witness to enough misunderstandings to know that this is far from universally true, even for people like me who are more primed than average to spot missing context.
What you describe sounds like the late nineties to me, not what we had with the technology of (at most) 1990. There are orders of magnitude between available performance and memory on both ends of this decade.
That comment you're complaining about is a useful signal for me who only watches zig from the far periphery. I feel like I'm getting good mileage out of it, just like I do from other, different ones. I'm glad it's in the mix.
You could check on the phone, but I could certainly see the appeal of a fixed display in a convenient location.
reply