Red flags. Red flags everywhere.



  • @blakeyrat said:

    However I skimmed one of ObiWayne's blogs when I was on the bus (the devlicio.us one, which he didn't bother to link because he's a jerk) and it had an article on, supposedly, IoC containers. Which started by quoting a programmer saying that implementing a IoC container was a huge disaster for his product. Then it spent roughly 3 Moby Dicks talking about pretty much everything except what the holy shit an IoC container actually does. I gave up before he got to the actual explanation of what the shit it was, naively assuming he ever got there. I firmly believe that, as a general rule, if you can't explain something in 500 words or less, you don't understand it yourself.

    I noticed he used "UI" and didn't explain what that was, either. The nerve.

    @blakeyrat said:

    If you need things like dependency injection (which I assume is what you mean by DI) and inversion of control containers (which apparently can't even be explained in less than 50,000 words) then your code is Too. Fucking. Complicated. Back away, take a deep breath, and spend some time actually breaking down the problem into smaller, simpler, manageable chunks.

    And obviously you can't appreciate the irony of your statement saying to break things into little chunks while ranting about a concept designed to help you do exactly that.

    Ignorance is OK. Except when you work so hard to cultivate it.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    @PedanticCurmudgeon said:
    To the person who's convinced that he can't use Ruby because it doesn't have a GUI debugger that works the same way as Visual Studio?

    Who's that? It doesn't resemble anything I've ever said.

    This must have been your twin brother then:<br/ >


    http://forums.thedailywtf.com/forums/p/26781/306339.aspx#306339
    @blakeyrat said:

    I just don't like them (and where does this "not bothering to learn anything" shit come from anyway?) Did it ever occur to you that the reason I don't like those technologies is because they're all stuff that was obsolete 25 years ago? I'm not a Tech Luddite, I'm a "Tech Modernist". Which is pretty much the exact opposite.



    Look. Microsoft Basic 1.0 on my Mac in 1986 had a GUI debugger with breakpoints, conditional breakpoints, setting breakpoints while executing, an inspector, etc. In 1986. Ruby, in 2012, does not have a [GUI] debugger that good. This is fucking ridiculous. Fucking. Ridiculous.



  • @PJH said:

    This must have been your twin brother then:


    http://forums.thedailywtf.com/forums/p/26781/306339.aspx#306339
    @blakeyrat said:
    I just don't like them (and where does this "not bothering to learn anything" shit come from anyway?) Did it ever occur to you that the reason I don't like those technologies is because they're all stuff that was obsolete 25 years ago? I'm not a Tech Luddite, I'm a "Tech Modernist". Which is pretty much the exact opposite.



    Look. Microsoft Basic 1.0 on my Mac in 1986 had a GUI debugger with breakpoints, conditional breakpoints, setting breakpoints while executing, an inspector, etc. In 1986. Ruby, in 2012, does not have a [GUI] debugger that good. This is fucking ridiculous. Fucking. Ridiculous.

    Did you read your own post? Did you read the text you quoted?

    I specifically say I don't like it not that I can't use it. Do you understand that those are two different things? Do you understand that I've posted here multiple times that not only can I used Ruby, but I did use Ruby to de-WTF their code?

    Fuck man.


  • Discourse touched me in a no-no place

    @Cassidy said:

    I'm simply questioning if the situation is the other way around: are they not using an IDE - or their choice of IDE - because they don't know something other people do?

    Most people who use Haskell and Lisp (this may also be true of Ruby and Python) also have experience with either C# or Java, so probably not.



  • @blakeyrat said:

    Stuff about DI and IOC

    Quite the opposite.  DI is supposed to make your code simpler because you don't have to worry about how everything interacts.  You can create modules that implement interfaces, and you don't have to worry about how everything else works.  It also makes it easily testable.  You don't need an IOC container to manage dependencies, either... it's just one way to put all the pieces together so that you can completely decouple objects.  It's essentially your InstanceFactory (probably what similar classes would be named in Java).

    Example:
    class MyClass{

    DatabaseLogger logger = new DatabaseLogger();

    }

    =====================

    The DatabaseLogger is a dependency, and makes it hard to test that.  Let's pull that functionality out into an interface, then the dependency can be injected into the constructor.

    =====================

    class MyClass{

    ILogger _logger;

    public MyClass(ILogger logger) {_logger = logger;}

    }

    =====================

    Now, when we are testing it, we can pass in a Mock Logger, that ignores what is logged, or verifies it... but now our tests aren't dependant on a network connection, or (really) any other class. If there's a bug in that class, it won't affect this class working.

    =====================

    Now, to manage your dependencies, you can do something like creating a basic constructor that retrieves them:

    =====================

    class MyClass {

    ILogger _logger;

    public MyClass() : this(new DatabaseLogger()); //or

    public MyClass() : this(LoggerFactory.GetLogger());

    public MyClass(ILogger logger) {_logger = logger;}

    }

    =====================

    This allows you to easily test things, or to pass in specific instances if you want them, but it still couples your code (either with the DatabaseLogger or the LoggerFactory).  With an IOC Container, it manages injecting all the dependencies for you.  You set them up at the beginning, and then do:

    =====================

    MyClass instance = Unity.Resolve<MyClass>();

    =====================

    and it will create the class for you, and pass in whatever ILogger you have set up.

    =====================

    There you go, less than 300 words. 


  • Impossible Mission - B

    @blakeyrat said:

    Fuck man.



  • @Sutherlands said:

    DI is supposed to make your code simpler because you don't have to worry about how everything interacts.

    I already don't worry about how everything interacts.

    @Sutherlands said:

    You don't need an IOC container to manage dependencies, either...

    For the record you still haven't defined "dependency" in this context, because you're using it in a way I've never come across before.


  • Impossible Mission - B

    Dependency: an instance of a class required by another class. It was shown in the example, MyClass needed a logger. It depended upon having a logger instance. In the old bad world, it would grab a singleton or instantiate it itself. This made the two components tightly coupled and difficult to test in isolation. In the new world, the class constructor takes the instance it depends upon as a parameter, allowing you to inject the dependency. This allows you to inject the database logger in your production code and the dummy logger in your unit test code. The classes are no longer tightly coupled.

    Removed this paragraph because I'm not sure I understand Inversion of Control fully yet.



  • If you read between the lines, I was just calling him a shitty teacher because he didn't define the term "dependency" after his student specifically said he didn't understand how the term was being used. But I was trying to be polite.

    Yes, from the examples I got a sense of what he meant by "dependency", but I had to guess and assume and I hate that.

    Anyway as far as passing around a Logger instead of having every class create it's own, duh? Of course I do that. I just don't use your fancy-nancy terms for it.


  • Impossible Mission - B

    I think at least some of these frameworks are trying to make life easier by keeping you from needing to juggle around a dozen different instances of your various dependencies, instead giving you a neatly categorized catalog of shared dependencies relevant for the current environment configuration. I'm still researching them, but that's why I lurk here. I pick up stuff.

    IoC remains a bit nebulously defined (that's your cue, guys).



  • @blakeyrat said:

    For the record you still haven't defined "dependency" in this context, because you're using it in a way I've never come across before.

    A dependency as in "A depends on B", where class/interface A requires knowledge of class/interface B to facilitate either its (interface) specification or implementation. E.g.

    public interface ISupplier {
    }
    
    public class Client {
      private readonly ISupplier _Supplier;
    
      public Client( ISupplier supplier )
      {
        _Supplier = supplier;
      }
    }
    

    Here creating an instance of Client will require an instance of type ISupplier. In other words: ISupplier is a dependency of Client.

    Your typical IoC Container will allow you to configure a set of mapping rules that can satisfy these dependencies automatically for you. It would allow you to specify a rule of the form: "When I ask for an instance of type Client, I expect you to supply the constructor with an instance of whatever type I have configured that implements ISupplier."

    For instance with Unity:

    // Create a container to hold mapping rules.
    IUnityContainer container = new UnityContainer();
    

    // Configure FooSupplier as the type to inject for ISupplier.
    container.RegisterType<ISupplier,FooSupplier>();

    // Resolve an instance of Client through the container; Unity analyzes the constructor and
    // finds that the first argument is of type ISupplier. It builds and injects an instance of
    // the configured FooSupplier class when constructing the instance of Client you asked for.
    Client client = container.Resolve<Client>():

    Ofcourse this is a trivial example. When you upscale and get more complex relations / dependencies to handle, then the IoC pattern becomes an easy way to manage dependencies and swap them out, e.g. for unit testing.



  • @blakeyrat said:

    @Sutherlands said:
    You don't need an IOC container to manage dependencies, either...

    For the record you still haven't defined "dependency" in this context, because you're using it in a way I've never come across before.

    You're right, I didn't say what a dependency was, but I did say what was a dependency.  Most people can use logical thinking.  Apparently, so can you, you just choose to be difficult.



  • What's the point of an interface if you have a 1:1 relationship between interfaces and classes?



  • @joe.edwards said:

    IoC remains a bit nebulously defined (that's your cue, guys).

    Inversion of control is basically where you don't know what you're calling until runtime.  This is because you're using event callbacks or calling into an interface.  This can be achieved by using constructor or setter injection (DI), factories, or some other way to get the instance at runtime.  From Wikipedia: "Inversion of control is sometimes facetiously referred to as the "Hollywood Principle: Don't call us, we'll call you", because program logic runs against abstractions such as callbacks."



  • @blakeyrat said:

    What's the point of an interface if you have a 1:1 relationship between interfaces and classes?

    Well, just off the top of my head, testing.



  • @Sutherlands said:

    You're right, I didn't say what a dependency was, but I did say what was a dependency. Most people can use logical thinking.  Apparently, so can you, you just choose to be difficult.

    Pretty sure I never asked for the lecture in the first place, buddy. But if you're going to write a lecture, write it well.



  • @Sutherlands said:

    @blakeyrat said:
    What's the point of an interface if you have a 1:1 relationship between interfaces and classes?
    Well, just off the top of my head, testing.

    How?



  • @blakeyrat said:

    @Sutherlands said:
    @blakeyrat said:
    What's the point of an interface if you have a 1:1 relationship between interfaces and classes?
    Well, just off the top of my head, testing.

    How?

    @Sutherlands said:

    Now, when we are testing it, we can pass in a Mock Logger, that ignores what is logged, or verifies it... but now our tests aren't dependant on a network connection, or (really) any other class. If there's a bug in that class, it won't affect this class working.



  • @blakeyrat said:

    @Sutherlands said:
    You're right, I didn't say what a dependency was, but I did say what was a dependency. Most people can use logical thinking.  Apparently, so can you, you just choose to be difficult.

    Pretty sure I never asked for the lecture in the first place, buddy. But if you're going to write a lecture, write it well.

    You're right, what you said was akin to: "That's not what I think a dependency is.  I don't understand what IOC containers are.  ObiWayne doesn't explain what IOC containers are.  IOC containers aren't useful."

    Silly me for explaining the concepts to someone who was complaining about not understanding them.



  • @Sutherlands said:

    Silly me for explaining the concepts to someone who was complaining about not understanding them.

    I don't understand a lot of things. I don't give a shit about the vast majority of them. If I put in a quick reference to not understanding the rules of Cricket, do you take that to mean I care? Because I don't care.

    Oh and when I asked what the point of having a 1:1 interfaces-to-class relationship your replied with an example that requires having a 1:many interface-to-class relationship. So... good reading there.

    All of this shit sounds way too complex. Maybe there's some goddamned benefit, but how the fuck do you keep all this bullshit straight in your heads? Christ. I just write classes, methods, and sometimes inherit stuff from other stuff.



  • @blakeyrat said:

    I don't understand a lot of things. I don't give a shit about the vast majority of them. If I put in a quick reference to not understanding the rules of Cricket, do you take that to mean I care? Because I don't care.

    If you started talking about how the rules don't make sense and how Cricket was a pointless sport, probably.  If you just said "I don't understand cricket" then probably not.@blakeyrat said:

    Oh and when I asked what the point of having a 1:1 interfaces-to-class relationship your replied with an example that requires having a 1:many interface-to-class relationship. So... good reading there.

    I mean... I GUESS you could consider "new Mock<ILogger>()" to be an implementation of an interface... but most people wouldn't.  So... good comprehension there.

    @blakeyrat said:

    All of this shit sounds way too complex. Maybe there's some goddamned benefit, but how the fuck do you keep all this bullshit straight in your heads? Christ. I just write classes, methods, and sometimes inherit stuff from other stuff.

    Do your functions span 1000 lines and your classes 5k?



  • @Sutherlands said:

    Do your functions span 1000 lines and your classes 5k?

    No.



  • I dunno about blakey but I used DI and IoC before I knew what the names for them were - just like I use a lot of patterns without knowing what they're called. IMO, if you're a good dev you'll unconsciously end up using the appropriate pattern(s) because your thinking will eventually take you there.

    On the topic of DI/IoC - they're great for code modularity, but terrible for code readability. I hate reviewing projects that make heavy use of these patterns because it's fucking impossible to figure out what the code is doing (i.e. which concrete implementation is being used). I also have an issue with devs who see DI/IoC as a hammer for every project, even when said project doesn't and will never need them.



  • And my whole argument wasn't "DI/IoC is a golden hammer" it was that .NET guys IN MY EXPERIENCE are more likely to have no fucking idea what DI/IoC even is, or when it would be useful, or have any desire at all to broaden their horizons by learning them so they can apply them IF they have the need. Most .NET guys in my experience are happy just relying on pure WebForms (i.e. no MVVM/MVP, just code-behind), DataSets and DataReaders (the key point made here is using them directly on the page, not that they're the root of all evil. You can use a DataSet or Reader for data retrieval, just put it into a DTO or business object for the consuming code), and really have no idea about craftsmanship or quality. That's been my personal experience over around 4 years or so; I got sick and tired of getting a "deer in headlights" look whenever I'd be talking to a fellow .NET dev (either at the job or on an interview) and just casually mention what their thoughts were on such-and-such (just for conversation) and got a look like "I've never heard of that before. We won't ever use that here." because it really made me think like none of them cared enough about their career to actually stay up to date.



  • @blakeyrat said:

    (Actually he got into that whole, "well I consider IDEs a crutch" attitude which is the most ridiculous thing I've ever heard.)

    Next time, say “Yes, yes it’s a crutch, and unless you can remember every parameter for every method for every class in the entire API, then you’re handicapped, so use the crutch instead of dragging yourself around by your fingernails.”

     @blakeyrat said:

    They're significantly worse for me, since
    none integrate with VS. SVN at least has TortoiseSVN, which is a decent
    interface, but it doesn't do what TFS does (there's no linkage between
    your bug database and TortoiseSVN), and it still doesn't integrate with
    VS. (Yes, yes, I know there are VS extensions, yadda yadda.) Why should I
    have to leave my IDE to get a quick diff? Why should I have to open up
    my web browser to see what bug entry was associated with a code
    check-in?

    There are
    [url=http://ankhsvn.open.collab.net/]AnkhSVN[/url] (free, and a full SCC
    provider) and [url=http://www.visualsvn.com/visualsvn/]VisualSVN[/url]
    ($$, and is just a VS-integrated interface to TSVN).

    Look in the
    TSVN help file under the “bug tracking” index entry. You can set some
    properties and have the log window automatically turn things like
    “addresses issue #1234” into a link to the bug tracker. It’s still your
    web browser, but you don't have to manually look the issue up.

    @ObiWayneKenobi said:

    And my whole argument wasn't "DI/IoC is a
    golden hammer" it was that .NET guys IN MY EXPERIENCE are more likely
    to have no fucking idea what DI/IoC even is, or when it would be useful,
    or have any desire at all to broaden their horizons by learning them so
    they can apply them IF they have the need.

    It sounds like you only ever run into VB6 guys who have learned only enough .NET to make their crufty old shit build again.

     

     



  • @Sir Twist said:

    It sounds like you only ever run into VB6 guys who have learned only enough .NET to make their crufty old shit build again.
     

    It sure feels that way sometimes.  A lot of the .NET shops around here just don't seem to have a clue; either they've built a lot of legacy systems back in the 1.1 and 2.0 days and have no desire to ever refactor or address them, but keep adding to them nonstop and forcing the same old standards, or they're just seemingly staffed with old VB6ers that are lazy.  I don't rightly know.  What I do know is constantly dealing with "senior" developers, tech leads, and managers/directors/CIOs that had zero clue about any new trends in .NET started to get to me - I mean I didn't expect them to be jumping on the bandwagon, but I DO expect good developers to at least do what I do and keep a little up to date on trends and tools and best practices.The last straw for me was being fired because I was the only person on the team wanting us to refactor our code, make it not unmaintainable garbage, and actually try to make it scalable so it didn't crash every day.

     



  • @Sir Twist said:

    @blakeyrat said:
    (Actually he got into that whole, "well I consider IDEs a crutch" attitude which is the most ridiculous thing I've ever heard.)
    Next time, say “Yes, yes it’s a crutch, and unless you can remember every parameter for every method for every class in the entire API, then you’re handicapped, so use the crutch instead of dragging yourself around by your fingernails.”

    IIRC, I said, "there's nothing wrong with using a crutch if you need one."



  • @ObiWayneKenobi said:

    @Sir Twist said:
    It sounds like you only ever run into VB6 guys who have learned only enough .NET to make their crufty old shit build again.
    It sure feels that way sometimes. A lot of the .NET shops around here just don't seem to have a clue; either they've built a lot of legacy systems back in the 1.1 and 2.0 days and have no desire to ever refactor or address them, but keep adding to them nonstop and forcing the same old standards, or they're just seemingly staffed with old VB6ers that are lazy. I don't rightly know. What I do know is constantly dealing with "senior" developers, tech leads, and managers/directors/CIOs that had zero clue about any new trends in .NET started to get to me - I mean I didn't expect them to be jumping on the bandwagon, but I DO expect good developers to at least do what I do and keep a little up to date on trends and tools and best practices.The last straw for me was being fired because I was the only person on the team wanting us to refactor our code, make it not unmaintainable garbage, and actually try to make it scalable so it didn't crash every day.

    Ok ok ok ok ok we fucking get it. You had some bad experiences with .net devs. You got fired once. We get it. Shut up already. Get the fuck over it. Christ.

    For the record, I might be a terrible developer who's never heard of inversion of control containers, but I've never been fired. So there.



  • @blakeyrat said:

    For the record, I might be a terrible developer who's never heard of inversion of control containers, but I've never been fired. So there.

    You are terrible. I've heard of inversion of control.

    Of course, when I asked for clarification as to what that meant, the person advocating it took 20 minutes to stammer, mumble and explain something about configuration files before I nodded and backed away slowly.


  • Discourse touched me in a no-no place

    @Sutherlands said:

    @blakeyrat said:
    @Sutherlands said:
    @blakeyrat said:
    What's the point of an interface if you have a 1:1 relationship between interfaces and classes?
    Well, just off the top of my head, testing.

    How?

    @Sutherlands said:
    Now, when we are testing it, we can pass in a Mock Logger, that ignores what is logged, or verifies it... but now our tests aren't dependant on a network connection, or (really) any other class. If there's a bug in that class, it won't affect this class working.
     

     In other words, it allows you to test your class independently of anything else in the system, by setting up do-nothing mockups (or even ones that partially or even fully implement whatever they're mocking).  It's actually a pretty neat idea, but if you're working with legacy stuff--like my current job, we have one monolithic app that's probably 15+ years old, and regularly updated, but you could never really add all this cool stuff into it without a huge rewrite, and nobody's ever going to spend 6 months rewriting hundreds of thousands of LOC because that's not revenue-generating.

     


Log in to reply

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.