|
You poor fucker, i guess
|
#
?
Mar 26, 2024 23:12
|
|
|
|
| # ? Apr 27, 2024 09:54 |
|
|
Just approve it op what’s the worse that can happen
|
|
#
?
Mar 27, 2024 00:07
|
|
|
i work at a place right now that approves all PRs instantly but dudes will go on later and change names of fields and deployed names and poo poo, passive aggressively breaking things to align with their own unwritten naming convention that is best summarized by "as many redundant prefixes as possible"
|
|
#
?
Mar 27, 2024 00:26
|
|
|
Subjunctive posted:this is what stacked diffs are for, sigh git won, everything else lost. get used to it
|
|
#
?
Mar 27, 2024 00:37
|
|
|
"wouldn't it be nice if our source control could do xyz?" probably, but github for sure aren't interested maybe you can build an xyz workflow using git's lego pieces, but you'll be fighting everything all the time
|
|
#
?
Mar 27, 2024 00:39
|
|
|
you can do stacked diffs with git, even now that phabricator/arcanist are dead! even on GitHub! see the link in my previous post
|
|
#
?
Mar 27, 2024 00:39
|
|
|
There's more, btw. The branch for this mr was not made from the current mainline branch, but from a working branch the previous tech lead (who's retiring at the end of the week) made 2 or 3 weeks ago. Also, hello from page 15.
|
|
#
?
Mar 27, 2024 01:08
|
|
|
ef core is great because every time you add a migration it adds a second .Designer.cs file, containing a snapshot of the entire EF DB model at that point for us, every PR with a migration adds a 7.5k line file. our migrations folder has 75mb of these designer files - 1.8m lines of code in total the official ef response to this is "go gently caress yourself" Subjunctive posted:you can do stacked diffs with git, even now that phabricator/arcanist are dead! even on GitHub! see the link in my previous post oh, i just saw the url and assumed it was some random new vcs instead of, yes, someone willing to fight git on your behalf. i'll check it out
|
|
#
?
Mar 27, 2024 01:29
|
|
|
Presto posted:There's more, btw. The branch for this mr was not made from the current mainline branch, but from a working branch the previous tech lead (who's retiring at the end of the week) made 2 or 3 weeks ago. remember to schedule self-care, it's important redleader posted:oh, i just saw the url and assumed it was some random new vcs instead of, yes, someone willing to fight git on your behalf. i'll check it out oh yeah, sorry -- various ex-FB people have built tools that replicate the stacked diff capability on top of GitHub's swirl of pain, and this is the one that won. I like it a lot
|
|
#
?
Mar 27, 2024 01:32
|
|
|
redleader posted:ef core is great because every time you add a migration it adds a second .Designer.cs file, containing a snapshot of the entire EF DB model at that point EF sucks and migrations suck
|
|
#
?
Mar 27, 2024 01:40
|
|
|
Subjunctive posted:remember to schedule self-care, it's important Good news, I'm taking some time off next week. Bad news, I'm flying on a 737 Max 9.
|
|
#
?
Mar 27, 2024 02:12
|
|
|
Subjunctive posted:(stacked diffs remain the best way out of this situation, IMO) thanks for this. I've been rebasing my whole stack by hand like a chump
|
|
#
?
Mar 27, 2024 02:34
|
|
|
what’s a stacked diff
|
|
#
?
Mar 27, 2024 03:04
|
|
|
oh nifty, didn't know that had a name or tooling but yeah it's a pain to do it manually
|
|
#
?
Mar 27, 2024 03:17
|
|
|
Presto posted:Oh and the person who posted the MR is the new tech lead for this component. fake your death and move to belize
|
|
#
?
Mar 27, 2024 07:09
|
|
|
oh this is just branching off your branch if you need to. this does not seem revolutionary
|
|
#
?
Mar 27, 2024 07:27
|
|
|
subjunctive, googling for other stacked diff tools led me to a Facebook vcs tool called sapling that interoperates with git, iirc you’re a facebooker, is it any good?
|
|
#
?
Mar 27, 2024 08:50
|
|
|
Bloody posted:oh this is just branching off your branch if you need to. this does not seem revolutionary
|
|
#
?
Mar 27, 2024 11:38
|
|
|
Bloody posted:oh this is just branching off your branch if you need to. this does not seem revolutionary the reason specifically graphite is cool is that most git interaction tooling does an absolutely dogshit job of driving this interaction, especially if you are squash-merging PRs into the target branch. for instance, if you have main <- featurebranch1/pr1 <- featurebranch2/pr2 < featurebranch3/pr3 and each feature branch has 2 or 3 commits, on the github web ui when you merge 1 into main the web ui will retarget 2 onto main, but if you squash merged it won't take out the commits that were in 1 from 2 and you have to manually rebase 2 and therefore 3. this is doubly a problem because many git uis have absolutely dogshit affordances for doing selective rebasing (onto + limit selection). so the benefit of treating this flow as first class in some kind of add on software like graphite is it does that part for you and manages all the rebasing automatically, and it's intended for one dev to say "i want to use this" without having everybody need to - if you're not using graphite, all you're seeing is just nicer than usual diffs in your pr or mr or whatever your vcs forge calls it. but also if you have a workflow that you're fine with anyway it works fine. like i do stacked diffs when i can without graphite or whatever and yeah i do my own rebasing and it's fine because i use magit and it makes doing those kinds of rebases take about 5 seconds so whatever
|
|
#
?
Mar 27, 2024 12:53
|
|
|
Surprise T Rex posted:subjunctive, googling for other stacked diff tools led me to a Facebook vcs tool called sapling that interoperates with git, iirc you’re a facebooker, is it any good? sapling is from after my time, sorry. I’ve heard good things though!
|
|
#
?
Mar 27, 2024 13:36
|
|
|
Bloody posted:oh this is just branching off your branch if you need to. this does not seem revolutionary it’s everything you have to do if you land or alter the earlier branches that it makes easy. it’s not revolutionary, phabricator/arcanist were doing it almost 20 years ago, but it’s a nice way to work and it’s very annoying to do atop git(hub) without tooling support
|
|
#
?
Mar 27, 2024 13:38
|
|
|
just take a leisurely month to comb over the two commits. e: I should read all the pages before shitposting.
|
|
#
?
Mar 27, 2024 13:53
|
|
|
gbut posted:just take a leisurely month to comb over the two commits. i would instead give it a quick once-over, put a couple of naming nitpick conments, and hit that green tick. spending more than 10min is a waste of time
|
|
#
?
Mar 28, 2024 06:51
|
|
|
gbut posted:I read all the pages before shitposting. *amend, commit, force push*
|
|
#
?
Mar 28, 2024 13:51
|
|
|
i've been owned by apple, and need to vent we want to use a web view in a mobile app for a flow that we want to do a lot of iteration on for a/b test reasons. much easier to do that on web than mobile given release cycles and stuff, plus our mobile codebase is a loving disaster no one has confidence in and every time we try to ship some big swing it falls apart in production. our web code isn't that much better but at least we can ship bugfixes and rollbacks as quickly as we can write them. we also want to start doing more automated testing, because, well, see complaints about our codebase being a disaster. on iOS we use XCUITest, which is like the Apple-created-and-blessed tool for this. it's like "black box" app testing; you cannot run arbitrary code in your app. you can select elements in the app using stuff that's visible to accessibility tooling - so labels and stuff - or using the hilariously-named Accessibility Identifiers (https://developer.apple.com/documentation/uikit/uiaccessibilityidentification/1623132-accessibilityidentifier), which are... not actually used by accessibility tooling at all, and are purely meant for visibility to automated testing tooling. so you can render say, a ProfileViewController, and give it the Accessibility Identifier of "Profile Screen," and then your tests can look for an element called "Profile Screen" and look for subelements within that, etc. pretty standard UI testing stuff, from my perspective as a frontend dev - the equivalent of sticking some arbitrary `data-` attribute on an HTML element so that you can target it easily in tests. these two things have collided in a bad way, because you know what XCUITest doesn't support? Accessibility Identifiers for DOM elements in a web view! you can interact with web views in XCUITest by: * targeting copy on interactive elements - click a link labeled "Continue" * targeting interactive inputs by aria-label (which are basically copy for screen readers - not an internal testing identifier) * iterating through every piece of static text on the page that's it! you don't get access to the DOM, you don't get any selectors that aren't tied directly to copy. this has lead to one of our ios developers freaking out and saying we have to stop using web views, because we can't truly test them. and, hey, i don't disagree that this limitation sucks, but business needs mean we absolutely need to use web views here for iteration and experimentation purposes. this has lead to like a 50+ post slack thread of paragraphs of text being thrown back and forth about testing strategies and angry posts about shipping quality software and this all would have been avoided if apple just, loving, supported some arbitrary data tag as an accessibility identifier or something we can move forward with "low-quality" web view tests - we have tests in the web codebases that should cover granular assertions in these web views, so the ios app really just needs to be able to step through the web views and get back to the native app, and that can be done in a brittle manner by targeting copy (this test suite isn't going to fail builds anyways, since it's an expensive end-to-end suite that depends on our backend and stuff anyways). the only option i've found to truly test web views in ios ui tests is appium, which uses the truly loving galaxy brain option of letting you switch "contexts" from targeting XCUITest to targeting web views using Selenium WebDriver targeting the Safari DevTools protocol - which is exposed by the iOS simulator so that you can use Safari DevTools with web views. i kind of wish someone could build that functionality as a standalone library you could integrate into regular XCUITests, since i don't think we are going to switch to appium every time i look into iOS development i always walk away thinking "how the gently caress does anyone live like this." i will take all the web framework churn in the world over the hellish tooling that exists in that space
|
|
#
?
Mar 28, 2024 16:00
|
|
|
also i enjoyed learning that XCUITest has no built-in way to completely reset app state, so the way people do this is by scripting the loving home screen: https://stackoverflow.com/a/36168101
|
|
#
?
Mar 28, 2024 16:37
|
|
|
I just get the code right first time, so I don’t need tests
|
|
#
?
Mar 28, 2024 16:40
|
|
|
same. tests are for amateurs
|
|
#
?
Mar 28, 2024 16:46
|
|
|
why write tests if they're just gonna pass anyway
|
|
#
?
Mar 28, 2024 23:31
|
|
|
Increase prize, hire actual tester.
|
|
#
?
Apr 1, 2024 08:58
|
|
|
is testing the web stuff using some normal mobile browser web stuff testing tools not viable for some reason? do you expect the webview rendering to behave differently?
|
|
#
?
Apr 1, 2024 21:53
|
|
|
cool av posted:is testing the web stuff using some normal mobile browser web stuff testing tools not viable for some reason? do you expect the webview rendering to behave differently? it’s quite common for internal webviews to have things registered such as URL handlers that communicate with the hosting app, and that tends (IME) to be a fragile surface
|
|
#
?
Apr 2, 2024 00:39
|
|
|
yeah for this case it's not just an "open the web view and let the user do stuff," there's communication back to the app via https://developer.apple.com/documentation/webkit/wkscriptmessagehandler and whatever the android equivalent is
|
|
#
?
Apr 2, 2024 01:24
|
|
|
Just to keep you all up to date, that MR is now 314 files +10669 -5873
|
|
#
?
Apr 2, 2024 17:07
|
|
|
Presto posted:Just to keep you all up to date, that MR is now 314 files +10669 -5873 reject without comment imo
|
|
#
?
Apr 2, 2024 17:10
|
|
|
or say "no im not going to tell you whats wrong, you need to find it for yourself in your pr"
|
|
#
?
Apr 2, 2024 17:11
|
|
|
Took a bunch of pseudoephedrine and banged a -4455/+652 across 106 files with a description of “cleanup” into my teams queue; it’s good to be the boss.
|
|
#
?
Apr 2, 2024 17:29
|
|
|
bob dobbs is dead posted:or say "no im not going to tell you whats wrong, you need to find it for yourself in your pr" “I have fundamental architectural concerns with this approach; could you prototype up something that will scale a bit better?”
|
|
#
?
Apr 2, 2024 19:49
|
|
|
i think ive already changed my mind and an easy stacked diff tool would be nice. i do a lot of minor cleanup changes locally but typically wind up discarding them because its too much effort to land them as their own thing and i dont want to include them in an unrelated pr but... if that effort was lower...
|
|
#
?
Apr 3, 2024 16:45
|
|
|
|
| # ? Apr 27, 2024 09:54 |
|
|
Presto posted:Just to keep you all up to date, that MR is now 314 files +10669 -5873 Presto posted:Good news, I'm taking some time off next week. Bad news, I'm flying on a 737 Max 9. Soricidus posted:fake your death and move to belize push that review back; if boeing doesn't get you then do what soricidus said. it's the only way
|
|
#
?
Apr 3, 2024 17:10
|
|
