ec changed the topic of #elliottcable to: a π―ππ ππ π―πππππππππ π―ππππππ slash sΝΜuΝΝpΝΝeΜΜΊrΜΌΜ¦iΜΌΜoΜΜ¬rΜΜ cΜΝα»₯Μ§ΝαΈ·Μ‘ΝΕ£ΝΜ || #ELLIOTTCABLE is not about ELLIOTTCABLE
<pikajude>
yeah i mean
<pikajude>
the amount of work put into the dev environments here is crazy
<jfhbrook>
well like facebook is one of those monorepo places yeah?
<jfhbrook>
like the core repo or repos are all gigantic and have thousands of code reviews going on at any given time
<joepie91>
apparently "let's use the haskell thing and compile it to JS and then use Node as a dep" is one of the serious options
<ljharb>
pikajude: oh you're at fb?
<ljharb>
pikajude: yeah everyone has to rearchitect git/hg to work with big repos. somehow nobody gets the hint that big repos *aren't good*
<ljharb>
twitter forked git itself too
<pikajude>
ljharb: big repos are fine
<ljharb>
oh they so aren't :-)
<ljharb>
monorepos are crap
<jfhbrook>
it does seem to introduce a lot of weird problems
<jfhbrook>
like how to manage so many merged forks at one time, and partial checkouts
<ljharb>
there's a few major classes of problems with monorepos
<ljharb>
1) they don't work well with tools, such that every large company with a monorepo ends up rewriting their VCS itself to make it work
<ljharb>
(this includes that checkouts are massive, so they have to figure out how to enable partial checkouts, or pre-seeded checkouts)
<ljharb>
2) they encourage poor API design, and frequent breaking changes, because "oh, i can just update the consumers while i update the API". which also encourages people to be making changes in parts of the codebase they have no knowledge of or business in.
<ljharb>
3) they don't interface well with the open source community, which includes consuming OSS deps, publishing internal projects as OSS, and continued maintenance while it's open sourced
<ljharb>
4) because they require custom tooling, the workflow, as well as the tools used, will a) be foreign to devs when they enter the company, and b) will leave them utterly unprepared for working anywhere else, because all their cognition about dev workflow and tools will be useless outside that company
<ljharb>
there's probably more, but i just got the baby to sleep and i'm a couple drinks in, so i think those *huge, major, widespread, core* categories will have to do for now
<jfhbrook>
baby? congrats
<ljharb>
lol thanks
<pikajude>
yeah everyone's workflow is unique
<pikajude>
also github PRs suck
<ljharb>
how so
<ljharb>
i love github PRs
<ljharb>
there's def lots of things to improve, but i've not seen anything consistently better
<pikajude>
yeah fair
<pikajude>
i make a lot of useless statements without any intention of backing them up
<pikajude>
only thing i can think of offhand i like better about phab is the ability to plan changes
<pikajude>
and set other dependent PRss
<pikajude>
fuck this keyboard
<pikajude>
one thing i do like that's independent of phabricator is the fact that we have actual continuous push here
<ljharb>
pikajude: the thing is, phabricator might have some nice features, i dunno
<ljharb>
but facebook's usage of it isn't likely open sourced in a way that's friendly to use
<ljharb>
and, because it's an internal instance and nobody else uses it, nobody's likely to use it. whereas if they built it entirely on top of github and ghe, it'd be really useful for everyone (but expensive for them)(
eligrey has joined #elliottcable
<eligrey>
ec what's good
mylesborins has quit [Quit: farewell for now]
mylesborins has joined #elliottcable
eligrey has quit [Quit: Leaving]
<Cheery>
Given a context free grammar, and a mapping from the grammar into structure.
<Cheery>
I'd need to come up with a nice syntax for it.
<joepie91>
my experience with GitHub stuff is that most of it is "not very good, but all the other options are worse"
<jfhbrook>
gh PRs are ok, they've gotten better in the last year or so
<jfhbrook>
gh issues kinda suck for large projects though
<jfhbrook>
I'm personally a fan of moving all that shit to asana or similar, though things like asana are bad for external use
<joepie91>
jfhbrook: so, there's two important qualities of an issue tracking system
<joepie91>
1) it must be low-friction and non-technical for the reporter
<joepie91>
2) it must have sufficient administrative tools for those handling the issues
<joepie91>
almost every issue tracker in existence gets 2 right but 1 wrong
<joepie91>
GitHub is the opposite - it gets 1 mostly right, but 2 wrong
<jfhbrook>
yeah I'd agree with that
<jfhbrook>
"make an issue in our jira" is kind of a fuck you
<joepie91>
I have the same complaint about PRs, although that is slowly increasing - there's just not enough administrative tools
<joepie91>
er
<joepie91>
improving *
<jfhbrook>
but gh's tags are crappy, no swim lanes, etc
<joepie91>
honestly, the solution here is to add a crapload of organizational features that are totally invisible to the user
<joepie91>
and that are opt-in
<jfhbrook>
you ever hear of waffle?
<jfhbrook>
waffle also sucks
<joepie91>
not in this context
<joepie91>
:p
<jfhbrook>
but it's swim lanes on top of gh issues
<joepie91>
jfhbrook: I've worked a bit with zenhub
<joepie91>
jfhbrook: which works similarly but integrated into GitHub
<joepie91>
I was not very impressed :P
<joepie91>
I feel like this is something that has to be implemented on the issue tracker level
<joepie91>
not as an add-on tool
<joepie91>
jfhbrook: aside, there's an idea I've been playing with for a while, to make issue trackers more accessible to non-technical folks
<joepie91>
(for open-source projects in particular)
<joepie91>
jfhbrook: said idea being to maintain a two-tier system - an issue tracker and a support (ticket) system - where the average user only directly interacts with the support system, but every support ticket can be instantly either 1) turned into an issue tracker ticket or 2) associated with an existing issue tracker ticket
<jfhbrook>
yeah, I'd love integration with zendork
<joepie91>
jfhbrook: providing integrations between the two, such as automatically marking every support ticket as "needs response from support" whenever the associated issue ticket's status changes
<joepie91>
so that the user is kept up to date, but doesn't directly see the issue tracker tickets
<jfhbrook>
yeah
<joepie91>
things like that
<joepie91>
jfhbrook: this is something I'm very slowly working on btw
<jfhbrook>
oh neat
<joepie91>
there's currently a big issue in open-source where 'triaging issues' and 'resolving issues' are sort of kind of seen as the same thing
<joepie91>
and that doesn't scale well
<joepie91>
and leads to meltdowns like today's uglifyjs issuie
<joepie91>
and while finding good maintainers can be difficult, it's much less difficult to find people who are willing to triage issues.... *if* you give them the tools and have realistic expectations
<joepie91>
those tools do not currently really exist :P
<joepie91>
so part of the idea I described above is to separate triaging that way - by having support people assess whether something is a bug or not
<joepie91>
they'll likely be the volunteers who are more about the soft skills, and less about the technical issues
<joepie91>
of course remains to be seen whether this works in practice, but on paper it works, and there's only one way to find out
<joepie91>
"Zip entry timestamps are recorded only to two 2 second precision. This reflects the accuracy of DOS timestamps in use when PKZIP was created. That number recorded in the Zip will be the timestamp truncated, not the nearest 2 seconds."
<joepie91>
~legacy~
<joepie91>
"Inside zip files, dates and times are stored in local time in 16 bits, not UTC as is conventional, using an ancient MS DOS format."
<joepie91>
jfhbrook: anyway, that thread is an example of the meltdowns caused by improper triaging because the maintainers are too busy/stressed to triage and there's nobody dedicated to doing so
<jfhbrook>
> In reality, there are no such things. What you have are floating point numbers and pious hope. There are several problems with Excel dates:
<joepie91>
(it's not the first such example either)
<joepie91>
oh man
<joepie91>
jfhbrook: MS Office stuff is a whole bucket of fun
<joepie91>
jfhbrook: the new formats don't fix the fuckedness of MS Office stuff either
<jfhbrook>
OO.o "fixed" one of the bugs
<joepie91>
those "open XML-based formats"? yeah well, that's part of the story, then there's the Microsoft-specific extensions (which are proprietary but documented) and then there are the implementation bugs that have become a sort of unintentional extension (which are proprietary and NOT documented)
<jfhbrook>
but it means that the TS will change if you open and save in OO.o for certain dates
_whitelogger has joined #elliottcable
<pikajude>
lmao we have a file called Monad.php
<jfhbrook>
nice
<pikajude>
ok, here's something that bothers me
<pikajude>
i wrote an abstract final class that uses FooTrait
<pikajude>
the only thing inside FooTrait is "use FooImplTrait"
<pikajude>
what's the point of that
<pikajude>
why isn't it just inside FooTrait
<jfhbrook>
I'm guessing Traits in this case are supposed to be similar-ish to interfaces
<jfhbrook>
insofar as an interface never has implementation, and that's supplied by an Impl
<pikajude>
ok
<pikajude>
so why is there a trait called FooImplTrait then
<pikajude>
and why does it have the implementation in it
<jfhbrook>
FooImplTrait is a trait and not an implementation?
<pikajude>
it's a trait
<jfhbrook>
ok I take back everything I said prior
<pikajude>
yeah that's why it's called FooImplTrait
<jfhbrook>
like knowing the issues with your code reviewers it's probably worth digging up the blame and asking, but I bet that's cruft that could be fixed