|
he thinks blazor is great because itll transition c# developers to the frontend e: ef is awful because you should just query Mongo directly Flat Daddy fucked around with this message at 16:05 on May 3, 2019 |
#
?
May 3, 2019 16:03
|
|
|
|
| # ? Jan 19, 2025 00:21 |
|
|
I just learned of the Bazel build system and I am truly and utterly horrified by it. It requires Java, uses protobufs for configuration, and cross-compiling is a giant lol bag of nope. Basically, I don't think I will ever get envoyproxy into Buildroot because of it.
|
|
#
?
May 3, 2019 16:08
|
|
|
that node-ecstatic guy hosed up. the only reason to remove a published package from the registry is if it contains bona-fide malware. you deprecate instead. npm even added a whole "audit" system for dealing with these situations. course, the whole problem with node is that people will take a dependency on something as soon as glance at it regardless of whether it's some guy's library or there's some org behind it that actually dedicates resources to its maintenance.
|
|
#
?
May 3, 2019 16:14
|
|
|
ratbert90 posted:I just learned of the Bazel build system and I am truly and utterly horrified by it. it works great inside Google where there are whole teams for managing different toolchains. also I like it for my personal garbage because it's what I'm used to and I never need to cross compile anything anyway. What do you mean by the protobuf part though? i've never had to use a protobuf to configure anything
|
|
#
?
May 3, 2019 16:23
|
|
|
ratbert90 posted:I just learned of the Bazel build system and I am truly and utterly horrified by it. Still beats groovy
|
|
#
?
May 3, 2019 16:38
|
|
|
Finster Dexter posted:webdev? allow me to introduce you to Go's `go get` command... i didn't say they were the only clowns
|
|
#
?
May 3, 2019 16:44
|
|
|
ratbert90 posted:I just learned of the Bazel build system and I am truly and utterly horrified by it. yeah its really good
|
|
#
?
May 3, 2019 17:03
|
|
|
Illusive gently caress Man posted:it works great inside Google where there are whole teams for managing different toolchains. I thought the config files were derived from protobufs? Also, the documentation sucks and is outdated/often wrong. gonadic io posted:Still beats groovy Everything beats groovy. Autotools beats groovy ffs. DONT THREAD ON ME posted:yeah its really good Compared to meson? Nah
|
|
#
?
May 3, 2019 17:41
|
|
|
is blazor still somehow ~powered by the blockchain~?
|
|
#
?
May 3, 2019 17:58
|
|
|
I very nearly ended up a pants developer
|
|
#
?
May 3, 2019 18:01
|
|
|
gonadic io posted:I very nearly ended up a pants developer usually called "tailors" and they don't post here
|
|
#
?
May 3, 2019 19:44
|
|
|
HoboMan posted:is blazor still somehow ~powered by the blockchain~? never was. that was just a joke.
|
|
#
?
May 3, 2019 20:33
|
|
|
the more i read about dependency injection frameworks the more it feels completely unnecessary and complexifying
|
|
#
?
May 3, 2019 20:52
|
|
|
like im halfway through https://martinfowler.com/articles/injection.html and so far the toy problem is 100% solvable by a function that takes a type that satisfies the correct interface. but for some reason instead its a method in a class and that class is going to own an instance of some random thing thats going to get deus ex machinaed into place by some random rear end framework
|
|
#
?
May 3, 2019 20:53
|
|
|
dependency injection frameworks solve one problem but cause dozens of new ones the one problem they solve is the ability to write unit tests that don't really test much of anything
|
|
#
?
May 3, 2019 20:53
|
|
|
Bloody posted:the more i read about dependency injection frameworks the more it feels completely unnecessary and complexifying it's enterprise programming, there's no real work to do so let's make up some bullshit to justify our salaries
|
|
#
?
May 3, 2019 20:55
|
|
|
Bloody posted:like im halfway through https://martinfowler.com/articles/injection.html and so far the toy problem is 100% solvable by a function that takes a type that satisfies the correct interface. but for some reason instead its a method in a class and that class is going to own an instance of some random thing thats going to get deus ex machinaed into place by some random rear end framework Most legacy java patterns are obseleted by decent typeclass or first class function support
|
|
#
?
May 3, 2019 20:58
|
|
|
this is in a c# code base and the di thing its using references that article in its documentation lol
|
|
#
?
May 3, 2019 21:01
|
|
|
Symbolic Butt posted:it's enterprise programming, there's no real work to do so let's make up some bullshit to justify our salaries yah theres no reason di frameworks have to work via magic annotations or xml or w/e its just enterprise smoothbrains
|
|
#
?
May 3, 2019 21:05
|
|
|
di: ok i guess di frameworks: bad
|
|
#
?
May 3, 2019 21:10
|
|
|
di is the one design choice that has never failed me im never sitting around regretting using di
|
|
#
?
May 3, 2019 21:11
|
|
|
it seems like a phenomenal pile of complexity just to avoid thinking about how your data gets around
|
|
#
?
May 3, 2019 21:17
|
|
|
i am probably 100% conflating DI with DI Frameworks
|
|
#
?
May 3, 2019 21:17
|
|
|
DONT THREAD ON ME posted:di is the one design choice that has never failed me
|
|
#
?
May 3, 2019 21:18
|
|
|
every single example i am looking at on the internet is just bafflingly stupid wait no this one looks fine. ok DI is fine, it is literally just constructors with arguments. thats fine. DI frameworks are bafflingly stupid still
|
|
#
?
May 3, 2019 21:19
|
|
|
DONT THREAD ON ME posted:yah theres no reason di frameworks have to work via magic annotations or xml or w/e its just enterprise smoothbrains
|
|
#
?
May 3, 2019 21:24
|
|
|
dependency injection means giving an object values for its instance variables those values are usually themselves complex objects that have instance variables, etc this is nice when you are writing a unit test for one object, and you don't want to have to figure out how to instantiate its whole chain of dependencies in fact you may prefer mock implementations for those dependencies that don't really do anything, so you can focus on the one particular thing you're testing the di framework will do this for you, it knows you are in test mode so it just uses the mock impl classes for your interfaces instead of the real ones but this means you are giving up control of object construction and lifetimes to your di framework it turns out that when and how things are constructed is a really important part of the data and control flow in an object oriented program and now you don't get to write it directly in java/c# anymore, you're stuck trying to coax the framework into doing what you would have, but with annotations or xml so now who the gently caress knows what the flow of your program looks like it works ok when you're using really awful enterprise patterns with poo poo like service classes all over that will only ever be singletons and you don't care and you just want to throw them into the pile of singletons and have the framework populate your instance variables however it wants to pools of objects also work ok anything beyond that, good loving luck, hope you know spring real well and like reading documentation
|
|
#
?
May 3, 2019 21:27
|
|
|
Bloody posted:wait no this one looks fine. ok DI is fine, it is literally just constructors with arguments. thats fine. DI frameworks are bafflingly stupid still
|
|
#
?
May 3, 2019 21:29
|
|
|
you can literally read about why dependency injection frameworks are useful on the wikipedia page: https://en.wikipedia.org/wiki/Dependency_injection#Dependency_injection_frameworks it's about scales of code. if you have a small self-contained program that doesn't have independent components to test, you don't need dependency injection. likewise, if the things you need to configure in your application are easily representable as, say, scalar values instead of code, you don't need dependency injection frameworks
|
|
#
?
May 3, 2019 21:29
|
|
|
DELETE CASCADE posted:this is nice when you are writing a unit test for one object just lol
|
|
#
?
May 3, 2019 21:46
|
|
|
also yea like the previous poaster said, its a design choice, so its not NECESSARY for anything, but it does make things easier
|
|
#
?
May 3, 2019 21:48
|
|
|
Bloody posted:
ya lol you could have a di framework that requires you to write a bit of boilerplate but is actually simple to read and reason about but nope gotta be a lovely dsl DONT THREAD ON ME fucked around with this message at 22:04 on May 3, 2019 |
|
#
?
May 3, 2019 22:00
|
|
|
@Autowired ftw
|
|
#
?
May 3, 2019 22:10
|
|
|
but for real di frameworks own because i don't want to worry about what type is fulfilling the interface
|
|
#
?
May 3, 2019 22:11
|
|
|
All I know about it is from this thread but isn't di hard to illustrate with toy problems because it only is actually helpful once your codebase exceeds the size of "toy"
|
|
#
?
May 3, 2019 22:17
|
|
|
Captain Foo posted:All I know about it is from this thread but isn't di hard to illustrate with toy problems because it only is actually helpful once your codebase exceeds the size of "toy" not really its very simple to understand, is almost immediately useful and scales well. its literally just passing dependencies to constructors, eg passing a database connection into a view controller rather than storing the connection in a global. thats it. the frameworks do lots of different things to make this easier depending upon language but thats all orthogonal to the concept of di. there are times where i dont use di, but in these cases im also not writing tests or using version control DONT THREAD ON ME fucked around with this message at 22:36 on May 3, 2019 |
|
#
?
May 3, 2019 22:33
|
|
|
Jabor posted:oh no, my continuous integration is broken because for some reason it downloads half the code from arbitrary places on the internet for every single build. there is no way this problem could have been avoided. Zlodo posted:build processes should never ever involve internet accesses so what's the alternative? janitor your own local package repo? check a bunch of binary dependencies into source control? you're obviously gonna have to hit the internet at least once, somehow
|
|
#
?
May 3, 2019 22:53
|
|
|
i worked on a big guice project once and they were really into turning random bs into providers, frequently with providers chaining off of each other and it just ended up creating problems. for example I was frequently finding bugs that were caused by a class getting provided the wrong thing in a way that was very hard to diagnose, or tracking down performance issues that were the result of expensive code getting instantiated when the developer didn't expect. all of which couldn't be replicated in the unit tests that were claimed to be made so much easier under the di system since then I've just worked on projects that used constructor arguments and/or function passing without any of the di glue bs and I haven't missed it one bit at this point I think di frameworks are only useful for setting up bumper rails that force your coworkers to declare dependencies in their constructors, but at the cost of total opacity when those dependencies don't behave the way you expect, and at the risk that the code will be turned into an interdependent mess of providers when functions would be better
|
|
#
?
May 3, 2019 22:53
|
|
|
also I picture di frameworks as plastering over code that's poorly structured to begin with. like if you've got some code 20 layers down that's making queries into an external database then maybe you should rethink that structure. if you're using regular constructors in that situation then the pain of passing a database client through 20 layers is obvious while with a di framework the pain is obscured until it bites you in the rear end
|
|
#
?
May 3, 2019 23:01
|
|
|
|
| # ? Jan 19, 2025 00:21 |
|
|
the built-in asp.net di framework seems alright. no magic annotations or xml; you declare your dependencies (ISomething -> SomethingImpl) and their lifetime in your app startup method. sure, you have to write a single line of boilerplate whenever you need something to be injected, but eh.
|
|
#
?
May 3, 2019 23:01
|
|