|
http://www.phpsadness.com/sad/52quote:Let's examine the rules for comparison in PHP. Here is a digraph of a variety of values and how they compare; a green line means ==, and an arrow from A to B means A < B: (can't embed cause HTTP)
|
# ? Sep 23, 2019 17:29 |
|
|
# ? May 23, 2024 13:10 |
|
PHP apologists are always like "yeah, PHP was bad but modern PHP is pretty good". I haven't used PHP in a very long time, so I never know how much credence to give that argument.
|
# ? Sep 23, 2019 18:18 |
|
the name stands for “polished horse poop”
|
# ? Sep 23, 2019 18:28 |
|
Soricidus posted:the name stands for “polished horse poop” no it's actually "Pretty Horrible PHP"
|
# ? Sep 23, 2019 20:17 |
|
Thermopyle posted:PHP apologists are always like "yeah, PHP was bad but modern PHP is pretty good". PHP in particular has had slow adoption because the new modern version isn't backwards-compatible, and there's a world of legacy to support. Any new web stuff just moved on to Node/Ruby/.NET/etc.
|
# ? Sep 23, 2019 20:26 |
|
DaTroof posted:Maybe he snuck in a back door that depends on a collision. Hanlons razor, it was actually a run once data import script lol, just slowed it down slightly!
|
# ? Sep 23, 2019 20:52 |
|
SupSuper posted:It's a tough sell for any language because if you take too long, the damage is already done (see: PHP, Javascript, OpenGL, etc). The new doesn't instantly supplant the old, 90% of people and resources will be working with existing old bad code, not new modern code. whoa, don't lump OpenGL in with there... it still doesn't have a modern form that's actually good
|
# ? Sep 23, 2019 21:37 |
|
git log wip merge from develop wip wip general fixes wip wip merge from develop wip
|
# ? Sep 23, 2019 21:51 |
|
Suspicious Dish posted:whoa, don't lump OpenGL in with there... Curious, does that include Vulkan? Though old GL is kinda similar to PHP in that the easy way is the bad way.
|
# ? Sep 23, 2019 22:19 |
|
Xik posted:git log I started putting my foot down a few months ago in regards to poo poo like this. git rebase -i HEAD~ is a thing, and I made our developers learn it.
|
# ? Sep 23, 2019 22:43 |
|
Xik posted:git The real horror is the steaming pile of rubbish that is git. Unfortunately the alternatives are also garbage fires. None are particularly easy to use, and git experts seem particularly proud of it as if that’s a good thing.
|
# ? Sep 23, 2019 23:04 |
|
Goreld posted:The real horror is the steaming pile of rubbish that is git. Unfortunately the alternatives are also garbage fires. None are particularly easy to use, and git experts seem particularly proud of it as if that’s a good thing. Git is actually a Very Good Thing
|
# ? Sep 23, 2019 23:11 |
|
git is hard to learn, but it's good.
|
# ? Sep 23, 2019 23:12 |
|
Xik posted:git log Hold up Do your developers actually get to push commits called "wip" to your main branch? What the actual dick?
|
# ? Sep 24, 2019 00:38 |
|
Well there is a PR process for merging from feature branches into the primary dev branch but it seems these sort of commit messages are being approved. I used to be full time here and this would have been something I'd make a bunch of noise about but I took a break and now I'm a contractor here too so can't really stick my neck out. While I was gone many of the old permanent employees left so the place has been running on mostly sub-par contractors. I mean, they're not all bad, some are top quality (a couple better then me for sure) but it's like a handful of diamonds in a swimming pool of feces.
|
# ? Sep 24, 2019 01:14 |
|
OddObserver posted:Curious, does that include Vulkan? Normal disclaimer that I use graphics API for compute not actual graphics, but we did investigate Vulkan a bit. It's better than OpenGL in the sense that you can also remove the bullshit from C by just using assembly instead. Everything seems pretty sane and predictable, but you have to do everything yourself. I can't imagine anyone using Vulkan for anything but building a higher-level abstraction on top, whereas people use OpenGL directly to write (relatively) simple graphical demos and such.
|
# ? Sep 24, 2019 07:59 |
|
ratbert90 posted:I started putting my foot down a few months ago in regards to poo poo like this. Oh man, I didn’t know about tilde thing, thanks.
|
# ? Sep 24, 2019 09:05 |
|
I don't think I've ever used tilde without number. What has been working nicely for me is git rebase -i master.
|
# ? Sep 24, 2019 12:50 |
|
OddObserver posted:Curious, does that include Vulkan? Vulkan is low-level, unfriendly, and prone to break in weird ways, and the tooling around it sucks but is slowly getting better (hopefully LunarG stops existing soon, at least) The expectation was that serious engine developers would use it and then everybody would use those serious engines, but they misunderestimated how many people consider themselves to be "hardcore pro low-level programmers" and are basically playing with knives
|
# ? Sep 24, 2019 15:21 |
|
Jewel posted:PHP is garbage and "0wordshere" == 0 is true because "The string has a number in it! It failed the exact equality check so lets try and parse it as a number instead" No, the correct answer is to use hash_equals, which eliminates a hypothetical timing attack based on the lengths of the hashes.
|
# ? Sep 24, 2019 18:04 |
|
Suspicious Dish posted:(hopefully LunarG stops existing soon, at least) What's the problem with LunarG?
|
# ? Sep 24, 2019 18:07 |
|
code:
Edit: I've also found at least 5 methods for parsing dates in this crap.
|
# ? Sep 24, 2019 18:20 |
Xik posted:git log People who do this make me irrationally angry because that sort of poo poo leads to "thou shalt squash-merge" and gently caress all of you my commit history is useful swear to god companies that use git need to have mandatory lunch and learns about proper git use because all I ever see is one of: [ticket] ALL THE WORK AT ONCE WHAT'S INCREMENTAL PRECIOUS or: wip wip wip merge wip wip [ticket] did a thing merge fix pr comments or, almost even worse: [ticket] ticket description [ticket] ticket description [ticket] ticket description [ticket] ticket description [ticket] ticket description [ticket] ticket description [ticket] ticket description merge
|
|
# ? Sep 27, 2019 14:32 |
|
I'm fine with squash commits because they should include the PR number where you can see all of the iterative progress if it's actually important. It's invariably better than a mix of good commits and wip bullshit.
|
# ? Sep 27, 2019 14:46 |
necrotic posted:I'm fine with squash commits because they should include the PR number where you can see all of the iterative progress if it's actually important. I prefer being able to pop through blame annotation history in my IDE, makes things a whole hell of a lot simpler
|
|
# ? Sep 27, 2019 14:48 |
|
Best is to rebase and massage the sausage into something nice. If that can't be done, squish it all together rather than having a bunch of useless garbage commits that don't mean anything.
|
# ? Sep 27, 2019 14:54 |
|
ChickenWing posted:I prefer being able to pop through blame annotation history in my IDE, makes things a whole hell of a lot simpler Yeah, if everyone writes good commits this is better but I've never found that to work out.
|
# ? Sep 27, 2019 15:06 |
necrotic posted:Yeah, if everyone writes good commits this is better but I've never found that to work out. So long as people are even writing mediocre commits it's still handy.
|
|
# ? Sep 27, 2019 16:17 |
|
Yeah, it takes very little for commit messages to be useful. Even half-assed descriptions of what the commit changed with no attempt at saying why sometimes accidentally tell me what I wanted to know.
|
# ? Sep 27, 2019 18:15 |
|
ChickenWing posted:People who do this make me irrationally angry because that sort of poo poo leads to "thou shalt squash-merge" and gently caress all of you my commit history is useful proper git usage is the first one, the problem with 18 commits having ‘wip’ isn’t solved by typing out ‘fixing white spaces based on review feedback’ and needlessly bloating bisect
|
# ? Sep 27, 2019 19:27 |
|
when i'm working on a branch, commits exist to help me make progress when i'm merging the branch, commits exist to explain the changes the ideal commits for each phase are completely different
|
# ? Sep 27, 2019 19:35 |
|
"Progress saved to cloud because I'm wary about losing all my work"
|
# ? Sep 27, 2019 19:46 |
|
Doc Hawkins posted:when i'm working on a branch, commits exist to help me make progress Which is why you work in different branches. One for the work in progress and one for the entire feature. merge --squash and you're golden. In the WIP branch, "wip" comments are fine if you really really like them, since you're the only one ever seeing them. In the feature branch ... nah.
|
# ? Sep 27, 2019 22:19 |
|
git commit -am 'asdf' && git push -f
|
# ? Sep 27, 2019 22:24 |
|
Volguus posted:Which is why you work in different branches. One for the work in progress and one for the entire feature. merge --squash and you're golden. In the WIP branch, "wip" comments are fine if you really really like them, since you're the only one ever seeing them. In the feature branch ... nah. uh or just rebase the one branch to group and order the changes logically with useful messages
|
# ? Sep 27, 2019 22:39 |
|
tak posted:Git is actually a Very Good Thing Provably false.
|
# ? Sep 27, 2019 23:11 |
|
Soricidus posted:git commit -am 'asdf' && git push -f git commit --allow-empty -m''
|
# ? Sep 27, 2019 23:56 |
|
Presto posted:Provably false. Sounds like someone needs to... Git Gud™ I think I may actually have grabbed it from this thread, but I've aliased man git as git gud
|
# ? Sep 28, 2019 01:25 |
|
Doc Hawkins posted:uh Uh or just merge squash and have one commit with one message for the entire thing. Easy, peasy, lemon squeezy. Of course, this does crumble when the "feature" was a 6 months project with 100 contributors from 20 countries. Yes, a merge --squash in that case may not be easy to review. Volguus fucked around with this message at 02:02 on Sep 28, 2019 |
# ? Sep 28, 2019 01:58 |
|
|
# ? May 23, 2024 13:10 |
|
just don't use long-lived branches if you can at all help it. if your feature is going to take several months to develop, it's better to have it in master, with integration tests making sure it still works, but with a compiler flag or similar turning it off in the final build. Avoiding the hell merge at the end has many advantages. For example, other developers are allowed to actually do refactorings and pay down tech debt without worrying about making your merge even more hellish.
|
# ? Sep 28, 2019 06:47 |