terrible programmers: my god, it's full of chars

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > terrible programmers: my god, it's full of chars

«‹›1446 »

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

rotor posted:

you forgot the picture of the trash can

oh, with the right injectionconfig.xml that's what you see. check your build environment.

# ? Jan 21, 2015 06:00

Adbot: ADBOT LOVES YOU

# ? May 10, 2024 00:21

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

I have to say I don't really get the value of DI annotations as they're usually presented in JavaScript frameworks. Typically the prototype to receive injection has string annotations, I guess I just don't see the benefit of declaring dependencies like that if you want to be able to control it from the outside. Sure it'll save you time while you're wiring it up, at least a little bit, but there's no easy place to go and see what gets injected where.

Maybe I'm the horror, but I set up something like this in a recent project, where you register classes under a string name with a class. newWith is how its gets instantiated and by default they're singletons, which was overridden in the last call to be instances instead.

JavaScript code:

 


world.register("comms", Comms).newWith();

world.register("planes:location", LocationPlane).newWith();
world.register("planes:form", FormPlane).newWith();
world.register("planes:user", UserPlane).newWith("comms", "actors:location", "actors:tickets");
world.register("planes:tickets", TicketsPlane).newWith("comms");

world.register("lookouts:app", AppLookout).newWith("planes:location", "planes:user").instances();

And tbh I didn't mind the little workflow of having to inject my new component into this wiring file. The things being injected are just ES6 classes with no dependence on the DI, so if I wanted to change strategy I can do it all here and be done with it. As I said, maybe there's something I don't get about DI but this feels like its reliable enough for my purposes.

Edit: only just realised how bad the cp of code was, but hopefully you get the idea

Maluco Marinero fucked around with this message at 09:10 on Jan 21, 2015

# ? Jan 21, 2015 08:11

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

Maluco Marinero posted:

I have to say I don't really get the value of DI annotations as they're usually presented in JavaScript frameworks. Typically the prototype to receive injection has string annotations, I guess I just don't see the benefit of declaring dependencies like that if you want to be able to control it from the outside. Sure it'll save you time while you're wiring it up, at least a little bit, but there's no easy place to go and see what gets injected where.

Maybe I'm the horror, but I set up something like this in a recent project, where you register classes under a string name with a class. newWith is how its gets instantiated and by default they're singletons, which was overridden in the last call to be instances instead.
JavaScript code:
world.register("comms", Comms).newWith();

world.register("planes:location", LocationPlane).newWith();
world.register("planes:form", FormPlane).newWith(); 
world.register("planes:user", UserPlane) .newWith("comms", "actors:location", "actors:tickets"); 
world.register("planes:tickets", TicketsPlane).newWith("comms"); 

world.register("lookouts:app", AppLookout) .newWith("planes:location", "planes:user").instances();
And tbh I didn't mind the little workflow of having to inject my new component into this wiring file. The things being injected are just ES6 classes with no dependence on the DI, so if I wanted to change strategy I can do it all here and be done with it. As I said, maybe there's something I don't get about DI but this feels like its reliable enough for my purposes.

JFC FIXED THAT FOR YOU

# ? Jan 21, 2015 08:16

Carthag Tuek: Oct 15, 2005; Tider skal komme,
tider skal henrulle,
sl�gt skal f�lge sl�gters gang

ughg i keep designing software in my head that i cant bring myself to actually code

# ? Jan 21, 2015 09:01

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

Snapchat A Titty posted:

ughg i keep designing software in my head that i cant bring myself to actually code

the only good software is software that you never write

# ? Jan 21, 2015 09:03

karms: Jan 22, 2006; by Nyc_Tattoo; Yam Slacker

rotor posted:

you forgot the picture of the trash can

# ? Jan 21, 2015 09:19

Carthag Tuek: Oct 15, 2005; Tider skal komme,
tider skal henrulle,
sl�gt skal f�lge sl�gters gang

MALE SHOEGAZE posted:

the only good software is software that you never write

yeah thats a plus i suppose :unsmith:

# ? Jan 21, 2015 09:43

comedyblissoption: Mar 15, 2006

Maluco Marinero posted:

I have to say I don't really get the value of DI annotations as they're usually presented in JavaScript frameworks. Typically the prototype to receive injection has string annotations, I guess I just don't see the benefit of declaring dependencies like that if you want to be able to control it from the outside. Sure it'll save you time while you're wiring it up, at least a little bit, but there's no easy place to go and see what gets injected where.

Maybe I'm the horror, but I set up something like this in a recent project, where you register classes under a string name with a class. newWith is how its gets instantiated and by default they're singletons, which was overridden in the last call to be instances instead.
JavaScript code:
 


world.register("comms", Comms).newWith();

world.register("planes:location", LocationPlane).newWith();
world.register("planes:form", FormPlane).newWith();
world.register("planes:user", UserPlane).newWith("comms", "actors:location", "actors:tickets");
world.register("planes:tickets", TicketsPlane).newWith("comms");

world.register("lookouts:app", AppLookout).newWith("planes:location", "planes:user").instances(); 

One big benefit in a javascript project w/ string annotations and a DI framework is that it dramatically reduces the possibility of error in creating your object graph. Javascript is dynamically typed and doesn't check the number of arguments in function calls, so this can bite you in the rear end and not be caught until you actually run the application. Javascript kind of sucks.

Even in a statically typed language, I think it can be tedious to have to remember to update a registration file whenever modifying the dependencies or adding a new module. A DI framework does automatically whatever you would do by hand. The only magic-ness should really be how you override the default convention.

Edit: I edited this post b/c I thought this was intended to be used as a service locator but it isn't. Don't use service locators instead of DI.

comedyblissoption fucked around with this message at 12:22 on Jan 21, 2015

# ? Jan 21, 2015 11:26

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

I guess I don't understand. Each of the 'classes' provided work just fine without this world context. They're just ordinary constructor functions that return objects. They can be passed mocks of the dependency they expect, the real deal, etc.

My confusion is this, ostensibly a number of claiming to be DI patterns, including Angulars and di-lite, ask you to declare whether its a service, factory, controller, etc, and declare all dependencies as strings. How is that not coupling your implementation to your dependency injection.

By specifying all that, you're requiring all pieces of code to identify themselves by a string and then trusting the big DI container in the sky to sort it out, aren't you?

If you mock out elements here, you still need to know the interfaces you're mocking, you still need to know the string identifiers if you use the DI context rather than calling it directly.

So at this point, I'm wondering where is the time saved. If you need to use modular components they still have to declare their dependencies if that's the approach used.

To be honest, I think I'd understand better if there was something people could point to as a reference library, ie, this is what a good dependency injection library looks like.

# ? Jan 21, 2015 11:53

comedyblissoption: Mar 15, 2006

I'm dumb and misinterpreted your stuff as a service locator pattern. It isn't.

A non-lovely DI framework looks like what you might expect:

Instead of rolling by hand:

code:

void main(...) {
  var herp = new Herp();
  var derp = new Derp();
  var baz = new Baz(herp, derp);
  var qux = new Qux();
  var foo = new Foo(baz, qux);
  var bar = new Bar();

  //more poo poo
  ...

  var application = new Application(foo, bar, ...);
  application.Run();
}

A non-lovely DI framework should use convention and save you typing and look roughly like:

code:

//a non-lovely framework allows customization in code and doesn't force XML
IDiConfiguration GetDiConfiguration() {
  var diConfiguration = new DiConfiguration();
  diConfiguration.MakeEverythingSingletonsByDefault();
  return diConfiguration;
}

void main(...) {
  var diConfiguration = GetDiConfiguration();
  var diContainer = new diContainer(diConfiguration);

  var application = diContainer.Instantiate(typeof(Application));

  application.Run();
}

Angular's string annotations for dependencies is fine. It's essentially the same as feeding static type information so the DI framework can understand how it's supposed to wire up the dependencies. Wiring it by hand or string annotations are equivalent in coupling. The only caveat is that angular may want you to do annotations in a certain way while another framework wants you to do it in another way. This is really a manifestation of javascript (and maybe dynamically typed langs in general) sucking for stuff like this.

The way they make you declare the role of the dependency (service, factory, controller, etc.) is tight coupling specifically to the Angular framework, though. Other than that Angular is what you should mostly expect out of a DI framework.

Castle Windsor is okay for simple stuff in C# and hopefully you don't need all the crazy customization, although it's there if you need it. The main thing you need to configure is which objects are singletons and not.

Depending on how easy it is to mock stuff for unit tests, you will probably make all your dependencies that you inject interfaces.

EDIT: modified pseudocode since it broke tables

comedyblissoption fucked around with this message at 12:42 on Jan 21, 2015

# ? Jan 21, 2015 12:17

tef: May 30, 2004; -> some l-system crap ->

Shaggar posted:

heh, all my DI dependencies are runtime

ugh why would you do things like a p-lang

# ? Jan 21, 2015 12:22

Destroyenator: Dec 27, 2004; Don't ask me lady, I live in beer

angular using strings for dependencies is because js is a terrible untyped language and once it gets minified you lose the variable names and then you're hosed so you have to put the strings in as well but then yeah you've got these bullshit magic strings that may or may not work at runtime and they you have to maintain this poo poo and keep both sets of lists in the same order etc. etc.

at least with jasmine you can skip the strings because nobody minifies tests and it looks vaguely more sane but it's still fragile untyped nonsense

DI with asp mvc is the business though

edit: whoops not the pl thread, i am a terrible programmer though

# ? Jan 21, 2015 15:09

hobbesmaster: Jan 28, 2008

Ludwig van Halen posted:

i don't "get" object oriented programming either

the c programming language was handed down to us mortals by god and u make an abomination of it by altering god's vision

so do it in c

# ? Jan 21, 2015 15:47

Shaggar: Apr 26, 2006

tef posted:

ugh why would you do things like a p-lang

rude

# ? Jan 21, 2015 16:03

prefect: Sep 11, 2001; No one, Woodhouse.
No one.; Dead Man’s Band

Shaggar posted:

rude

i think i've asked this before, but how do you do your maven deployments? i'm reading up on this "cargo" plugin -- is that what you use?

# ? Jan 21, 2015 16:08

SYSV Fanfic: Sep 9, 2003; by Pragmatica

Using C is a premature optimization.

# ? Jan 21, 2015 16:47

Arcsech: Aug 5, 2008

SYSV Fanfic posted:

Using C is a premature optimization.

Unless you are on a microcontroller this is probably true

# ? Jan 21, 2015 16:51

SYSV Fanfic: Sep 9, 2003; by Pragmatica

How bad is it to pass a pickled data structue between python 2 and 3 by using subprocess and stdout of one program?

# ? Jan 21, 2015 16:51

Notorious b.s.d.: Jan 25, 2003; by Reene

prefect posted:

i think i've asked this before, but how do you do your maven deployments? i'm reading up on this "cargo" plugin -- is that what you use?

maven is a build tool

i would not recommend its use for deployment

# ? Jan 21, 2015 16:52

Shaggar: Apr 26, 2006

prefect posted:

i think i've asked this before, but how do you do your maven deployments? i'm reading up on this "cargo" plugin -- is that what you use?

for tomcat deployments I use the tomcat-deploy plugin, but cargo would work too I guess.

you can deploy from your build server or you could deploy manually with maven or you could just let maven build the war and then manually deploy that. it's up to you and ur environment.

# ? Jan 21, 2015 16:52

Shaggar: Apr 26, 2006

the tomcat deploy plugin does the litterral exact same thing as if you deployed the packaged war yourself. theres no reason not to trust it unless you don't trust your servers.

# ? Jan 21, 2015 16:53

Notorious b.s.d.: Jan 25, 2003; by Reene

Shaggar posted:

the tomcat deploy plugin does the litterral exact same thing as if you deployed the packaged war yourself. theres no reason not to trust it unless you don't trust your servers.

no, it doesn't. it relies on the tomcat manager. no, i do not trust tomcat manager. and it doesn't work for modern apps anyway (why would you use tomcat for a new application in 2015?)

i prefer to have jenkins orchestrate deployment --

have a human being manually mark the build for release
let jenkins upload the rpm (maven can do this part)
have jenkins talk to salt/m-collective/whatever to update servers one at a time.
bonus points: get jenkins to coordinate rolling servers in/out of the LB

double extra bonus points: don't ever update a server, just create new ones. then your rollback procedure can be "roll the old servers into the LB"

# ? Jan 21, 2015 17:03

hobbesmaster: Jan 28, 2008

Arcsech posted:

Unless you are on a microcontroller this is probably true

hacking object oriented programming techniques and exceptions into micro controller code leads to some crazy stuff

it all looks fine if you don't expand any macros though!

# ? Jan 21, 2015 17:04

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

some of the first major C code (Unix) was done in an OO style (inode and filesystem jonx). read your Lions, scrubs.

# ? Jan 21, 2015 17:05

prefect: Sep 11, 2001; No one, Woodhouse.
No one.; Dead Man’s Band

Subjunctive posted:

some of the first major C code (Unix) was done in an OO style (inode and filesystem jonx). read your Lions, scrubs.

no kidding? could you give us a nutshell version?

# ? Jan 21, 2015 17:06

crazypenguin: Mar 9, 2005; nothing witty here, move along

DI (in general, idk anything about angular) can be confusing to figure out because it's really only useful "in the large" and so small examples often feel pointless. It's also troublesome in that there's about 4 or more real use cases rolled together which may not exactly be related all the time.

First, as someone mentioned, it helps deal with (hide) a large number of parameters that might need to be threaded around as the number of injected things increases.

Second, if you have cycles in the object dependency graph, constructor parameters no longer work. Now the objects all need to be created and mutated to be given their dependencies. Hiding that is even nicer.

Third, it's substituting for missing language features, like mixins (though I've never seen mixins done right.) That is, what we might really want to do is compose together pieces of behavior into a class, but we can't do that so we're trying to approximate it with an object graph.

Fourth, when it's used solely as a way to inject mock objects or whatever for testing, it's making up for lack of a better way to do that. Yes, this is basically abusing it and bad design, but it very well may be better than all the current alternatives, sometimes.

# ? Jan 21, 2015 17:35

Notorious b.s.d.: Jan 25, 2003; by Reene

usually angular defenders argue that it doesn't matter that it's a clusterfuck for large apps, because it lets you get a small app out the door

interesting to see someone try to make an argument from the other direction

# ? Jan 21, 2015 17:37

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

crazypenguin posted:

DI (in general, idk anything about angular) can be confusing to figure out because it's really only useful "in the large" and so small examples often feel pointless. It's also troublesome in that there's about 4 or more real use cases rolled together which may not exactly be related all the time.

First, as someone mentioned, it helps deal with (hide) a large number of parameters that might need to be threaded around as the number of injected things increases.

Second, if you have cycles in the object dependency graph, constructor parameters no longer work. Now the objects all need to be created and mutated to be given their dependencies. Hiding that is even nicer.

Third, it's substituting for missing language features, like mixins (though I've never seen mixins done right.) That is, what we might really want to do is compose together pieces of behavior into a class, but we can't do that so we're trying to approximate it with an object graph.

Fourth, when it's used solely as a way to inject mock objects or whatever for testing, it's making up for lack of a better way to do that. Yes, this is basically abusing it and bad design, but it very well may be better than all the current alternatives, sometimes.

di is useful in the small, but the frameworks are not particularly so

if u not coding to interface, u r doing it wrong

# ? Jan 21, 2015 17:39

The Leck: Feb 27, 2001

Malcolm XML posted:

lmao di is trivial

1. write to an interface not an implementation
2. let the constructor take the implementation for that interface

=> DI frameworks just poo poo that up by having implict filling in of dependencies and poo poo

cool this is basically what i was thinking. i haven't really used a di framework, and i don't foresee it anytime soon, so i'm good with this.

# ? Jan 21, 2015 17:49

Necc0: Jun 30, 2005; by exmarx; Broken Cake

lol nice thread title

# ? Jan 21, 2015 18:22

crazypenguin: Mar 9, 2005; nothing witty here, move along

Malcolm XML posted:

di is useful in the small, but the frameworks are not particularly so

if u not coding to interface, u r doing it wrong

oh yeah.

I guess I think of DI as actually being the frameworks.

edit: saw some people in the horrors thread saying "di" is dependency inversion principle. just thought I should also say i'm talking about dependency injection frameworks.

crazypenguin fucked around with this message at 20:19 on Jan 21, 2015

# ? Jan 21, 2015 20:08

Zaxxon: Feb 14, 2004; Wir Tanzen Mekanik

Malcolm XML posted:

if u not coding to interface, u r doing it wrong

# ? Jan 21, 2015 20:13

FamDav: Mar 29, 2008

crazypenguin posted:

oh yeah.

I guess I think of DI as actually being the frameworks.

edit: saw some people in the horrors thread saying "di" is dependency inversion principle. just thought I should also say i'm talking about dependency injection frameworks.

the d they are talking about is the D in SOLID. DI is understood to be dependency injection by anybody that is a person

on SOLID, follow all the consonants and never follow the vowels.

# ? Jan 21, 2015 20:30

Space Whale: Nov 6, 2014

FamDav posted:

the d they are talking about is the D in SOLID. DI is understood to be dependency injection by anybody that is a person

on SOLID, follow all the consonants and never follow the vowels.

What's wrong with the I?

# ? Jan 21, 2015 21:54

Shaggar: Apr 26, 2006

Notorious b.s.d. posted:

let jenkins upload the rpm

# ? Jan 21, 2015 22:04

Shaggar: Apr 26, 2006

Notorious b.s.d. posted:

usually angular defenders argue that it doesn't matter that it's a clusterfuck for large apps, because it lets you get a small app out the door

interesting to see someone try to make an argument from the other direction

that's a common argument for bad languages and bad frameworks that's always a lie. knockout.js is better for large apps and for getting small apps out the door. likewise mvc/webapi are better and faster for both small and large apps than flavoroftheweek frameworks like node or ruby.

# ? Jan 21, 2015 22:05

hobbesmaster: Jan 28, 2008

Shaggar posted:

theres a plugin for nupkg's

# ? Jan 21, 2015 22:10

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

prefect posted:

no kidding? could you give us a nutshell version?

you'll have to wait for my talk at yoscon

# ? Jan 21, 2015 22:20

FamDav: Mar 29, 2008

Space Whale posted:

What's wrong with the I?

if your interface is too heavy then that probably means your implementations are too heavy and you should sheer things apart full stop. the i says that god classes are fine so long as they dont implement god interfaces, which is bad and or wrong. its also either at direct odds or redundant in the face of single responsibility, imo

# ? Jan 22, 2015 00:59

Adbot: ADBOT LOVES YOU

# ? May 10, 2024 00:21

FamDav: Mar 29, 2008

fy i trust no man or woman who uses the acronym SOLID unironically because every person i know who has also insists on way more inheritance than is ever necessary.

# ? Jan 22, 2015 01:13

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > terrible programmers: my god, it's full of chars

«‹›1446 »