|
Carthag Tuek posted:open a new question on stack overflow & upload the image there, then copy the imgur url without posting the question this is for all intents and purposes the approved way to do this on github. open an issue, upload an image, grab the URL and use it on a github page or whatever.
|
#
?
Sep 9, 2020 16:29
|
|
|
|
| # ? Apr 16, 2024 05:54 |
|
|
simply embed images in posts as base64
|
|
#
?
Sep 10, 2020 02:05
|
|
|
just render every page to minified JavaScript that constructs the required DOM
|
|
#
?
Sep 10, 2020 02:24
|
|
|
If only the forum software would allow us to upload webassembly modules that would render content to a canvas.
|
|
#
?
Sep 10, 2020 02:35
|
|
|
I think I may have found an actual good post on reddit:/r/pcj posted:
This but it's normal capitalism insanity instead of computy boi go fast
|
|
#
?
Sep 10, 2020 05:17
|
|
|
ctps: trying very gently to convey to a very junior colleague that it is often possible to solve problems by reading the documentation or searching stack overflow before asking me how to concatenate two lists or w/e
|
|
#
?
Sep 10, 2020 13:18
|
|
|
Soricidus posted:ctps: trying very gently to convey to a very junior colleague that it is often possible to solve problems by reading the documentation or searching stack overflow before asking me how to concatenate two lists or w/e
|
|
#
?
Sep 10, 2020 13:48
|
|
|
mystes posted:Teach a person to fish, only with copy and pasting from stack overflow. give a jr a SO link, they work for a day teach a jr to ask SO questions, they get Flagged: Duplicate for the rest of their life
|
|
#
?
Sep 10, 2020 16:12
|
|
|
ChickenWing posted:give a jr a SO link, they work for a day ask SO questions, get SO answers
|
|
#
?
Sep 10, 2020 17:01
|
|
|
Why do js devs hate DI and do weird mocking stuff which breaks constantly
|
|
#
?
Sep 10, 2020 20:21
|
|
|
pointsofdata posted:Why do js devs hate DI and do weird mocking stuff which breaks constantly They've got a little bit of the Go disease: afraid of doing anything the same as common Java solutions, even if it was a good thing
|
|
#
?
Sep 10, 2020 20:37
|
|
|
js devs are used to being mocked, so they turn around and mock others. maybe if people were nicer to js devs?
|
|
#
?
Sep 10, 2020 21:10
|
|
|
pointsofdata posted:Why do js devs hate DI and do weird mocking stuff which breaks constantly because its very easy to do it in javascript, and seems like a fun thing to write on your own disclaimer: no I don’t do it and I think all forms of mocks that aren’t just an object passed in to a constructor that has the same interface are bad and a different code smell
|
|
#
?
Sep 10, 2020 21:54
|
|
|
dependency injection as a concept is cool and good dependency injection frameworks are frequently terrible
|
|
#
?
Sep 11, 2020 01:17
|
|
|
.net core providing one ootb so that you don't have to put up with nonsense was a real smart move
|
|
#
?
Sep 11, 2020 01:23
|
|
|
Beamed posted:.net core providing one ootb so that you don't have to put up with nonsense was a real smart move yeah but ooth every java di framework is ridiculous nonsense
|
|
#
?
Sep 11, 2020 01:27
|
|
|
i have still yet to really understand the usefulness of it, because the code still breaks and people still push updates that even with mocks and loose coupling just loving crash all over the place, and despite complaining in this thread multiple times about it already i generally can't understand oop and probably won't start now
|
|
#
?
Sep 11, 2020 01:37
|
|
|
the only js framework i know of that has embraced DI as a concept was angular and, well, that didn't go super well on a number of fronts with react/redux a lot of the time the patterns actually lend themselves pretty well to not needing mocking since there's usually some layer of indirection you can test instead (testing that an action is dispatched instead of mocking out a method on an object). a lot of times stuff that would be provided by a DI container can live in some top level component and get accessed through context, for things like api clients and whatnot, which... i dunno that's basically DI, if you're coming from the perspective of "DI is basically just passing dependencies as arguments to things"
|
|
#
?
Sep 11, 2020 01:51
|
|
|
didnt the last oop discussion in this thread land on oop being so successful you just happened to no longer conflate oop concepts and ideas with oop anymore? sorry if that was another poster
|
|
#
?
Sep 11, 2020 01:51
|
|
|
pointsofdata posted:Why do js devs hate DI and do weird mocking stuff which breaks constantly cause everything in js is global so why do you need to inject it?
|
|
#
?
Sep 11, 2020 01:53
|
|
|
Shaggar posted:cause everything in js is global so why do you need to inject it? and/or everything is already injected so why mention it
|
|
#
?
Sep 11, 2020 02:00
|
|
|
Beamed posted:didnt the last oop discussion in this thread land on oop being so successful you just happened to no longer conflate oop concepts and ideas with oop anymore? sorry if that was another poster yes this is correct, and what i only recall of it
|
|
#
?
Sep 11, 2020 02:06
|
|
|
abraham linksys posted:the only js framework i know of that has embraced DI as a concept was angular and, well, that didn't go super well on a number of fronts yeah, that's more or less my perspective. you don't need a framework to follow the pattern, and sometimes a framework introduces complexities that just make poo poo worse
|
|
#
?
Sep 11, 2020 02:31
|
|
|
DaTroof posted:yeah but ooth every java di framework is ridiculous nonsense and drat near impossible to get rid of if you fall into the trap of relying on them too hard the codebase at work has been trying to rip out guice for literal years after realizing how bad it is. 90% of our use has been replaced by explicitly constructing things, which works a lot better.
|
|
#
?
Sep 11, 2020 03:01
|
|
|
Guice literally just calls constructors for you, how is it difficult to just ... call them yourself somewhere instead.abraham linksys posted:the only js framework i know of that has embraced DI as a concept was angular and, well, that didn't go super well on a number of fronts Redux makes your components into a function of the state of the entire universe so when I think of a system that lends itself well to unit testing Redux is not the first thing that comes to mind.
|
|
#
?
Sep 11, 2020 03:24
|
|
|
i've only used two di frameworks before and in both cases, 90% of the time, they were cool and good. lifetime management (a complicated thing) was handled in discrete, well-defined spots in the application, rather than being strung out all over the application, and my dependencies just appeared out of the aether when i needed them. the other 10% of the time the dependencies from the aether were wrong and i had no idea how to fix them because the code to actually instantiate things was buried four layers deep in a third-party library
|
|
#
?
Sep 11, 2020 03:34
|
|
|
Arcsech posted:and drat near impossible to get rid of if you fall into the trap of relying on them too hard guice is one of the specific examples i was thinking of. also whatever eclipse rcp calls its di framework. jesus. just jesus side note: angular still loving sucks
|
|
#
?
Sep 11, 2020 04:19
|
|
|
the di frameworks i've used were only useful for creating runtime failures for things that otherwise would have been build errors
|
|
#
?
Sep 11, 2020 06:11
|
|
|
that is the best description of a dependency injection framework i have ever seen
|
|
#
?
Sep 11, 2020 06:33
|
|
|
Depends on the di framework. Dagger makes a point of moving those failures back to compile time, for instance.
|
|
#
?
Sep 11, 2020 06:40
|
|
|
Beamed posted:.net core providing one ootb so that you don't have to put up with nonsense was a real smart move yeah it's great. does just the things it should do with minimal amount of magic, all in normal code.
|
|
#
?
Sep 11, 2020 14:32
|
|
|
java DI is ok if you don't do classpath scanning. everything should be explicitly created.
|
|
#
?
Sep 11, 2020 14:44
|
|
|
Sapozhnik posted:Guice literally just calls constructors for you, how is it difficult to just ... call them yourself somewhere instead. at work for testing react components that are connected to the redux store, I've just been exporting the unconnected component to be tested with, and exporting the connected components as the default export to be used in the app. limit the scope of the props you're passing down from the global store, and add them to proptypes, and testing redux-connected components hasn't been bad for us, we just pass in the props that would be passed down from the `mapStateToProps` function and don't worry about simulating the global state. DaTroof posted:
I haven't used angular since the initial version (before they changed the name from AngularJS to Angular, and rewrote the whole codebase) but christ what a shitshow of complexity and unnecessary new terms that was. then react came out and it was so much simpler and straightforward  (but also powerful enough to run one of the most trafficked front-page heavy websites in the world)
piratepilates fucked around with this message at 16:12 on Sep 11, 2020 |
|
#
?
Sep 11, 2020 16:08
|
|
|
piratepilates posted:at work for testing react components that are connected to the redux store, I've just been exporting the unconnected component to be tested with, and exporting the connected components as the default export to be used in the app. yeah, i've had much more success (and a much more pleasant experience) using react. i've worked less with redux, but only because most of my react apps are relatively small, and passing a data interface to the top-level component is frequently good enough
|
|
#
?
Sep 11, 2020 17:00
|
|
|
any advice for breaking out of the classic loop of: doing tech debt informally, so tickets take longer, and management won't dedicate time to tech debt due to tickets always already being behind
|
|
#
?
Sep 11, 2020 17:16
|
|
|
gonadic io posted:any advice for breaking out of the classic loop of: doing tech debt informally, so tickets take longer, and management won't dedicate time to tech debt due to tickets always already being behind  ?
|
|
#
?
Sep 11, 2020 17:16
|
|
|
I mean that's the successful strategy I have used for previous companies I'm trying to avoid it this time I like this company but it's got the classic startup-no-more growing pains
|
|
#
?
Sep 11, 2020 17:21
|
|
|
gonadic io posted:I mean that's the successful strategy I have used for previous companies I'm trying to avoid it this time I like this company but it's got the classic startup-no-more growing pains Either paying-down tech debt is a priority for management or it's not. If it's a priority then they need to devote time to solving the problem (and if they won't then it's not actually a priority). If they do consider it a priority then they need to be made to see that it has to have resources devoted to it (which, perforce, cannot be used to plink tickets while so devoted) and if they can't be made to understand this we could be looking at a more fundamental problem (management not understanding the fish/cut-bait nature of either solving new business or solving old business) which suggests they don't value their worker's time sufficiently?
|
|
#
?
Sep 11, 2020 17:27
|
|
|
gonadic io posted:any advice for breaking out of the classic loop of: doing tech debt informally, so tickets take longer, and management won't dedicate time to tech debt due to tickets always already being behind is there any downside to continuing as you are? feel free to tell management you're gonna keep paying down tech debt as you go, regardless of whether that's formally accounted for, because you know what you're doing. but feel free not to
|
|
#
?
Sep 11, 2020 17:29
|
|
|
|
| # ? Apr 16, 2024 05:54 |
|
|
DaTroof posted:yeah, i've had much more success (and a much more pleasant experience) using react. i've worked less with redux, but only because most of my react apps are relatively small, and passing a data interface to the top-level component is frequently good enough redux is one of the react cases where it got super hyped up for some reason, and everyone thought it should be used everywhere always at all times for everything. as a result you see people race to use it for everything for no good reason, like storing every piece of their application's component-local state in it, and never using `setState` or `useState`. it's meant for one thing: global shared state across a react application. it does it pretty decently (but with admittedly really lovely boilerplate/syntax). if you don't need to share global state between two components that otherwise have nothing to do with each other (i.e. no close common parent), then it's not needed. even if you have a need for some global state, if you can satisfy that requirement with making separate api calls, that's probably a much better approach for as long as you can reasonably do it.
|
|
#
?
Sep 11, 2020 17:33
|
|