• Andy (unregistered)

    [yet another snarky comment about imaginary spaceships that are shot full of holes by aliens on a regular basis]


  • coder1 (unregistered) in reply to CMG
    Anonymous:
    Anonymoose:
    Anonymous:
    Alex Papadimoulis:

    //Loading an ApprovalRequest object
    HashMap objectQuery = new HashMap();
    objectQuery.put("ApprovalRequest","*");
    objectQuery.put("ApprovalRequest.RequestId","11799");

    String[] unused = new String[1];
    unused[0] = ""; //note this is only used for updates

    GenericObject myRequest = ApprovalRequestInterface.Query(objectQuery, unused);



    Call me nit-picky if you must, but one thing that bugs the shit out of me is when people don't code to interfaces that already exist. For the love of Pete, use Map as your variable type.


    Are you saying that HashMap doesn't exist?


    Absolutely not. I'm saying that the objectQuery object should be typed to Map rather than HashMap:
    Map objectQuery = new HashMap();

    Similarly, the ApprovalRequestInterface.Query method should expect a Map as it's first argument, rather than a HashMap (and it very well may: we can't tell what kind of argument it expects from the post).

     

    I see your point, but if ApprovalRequestInterface.Query does indeed accept a Map as the first parameter then your argument about changing code is pretty weak.  He'd only have to change one line regardless, ie: HashMap objectQuery = new HashMap(); becomes TreeMap objectQuery = new TreeMap();

  • (cs) in reply to CMG
    Anonymous:

    Absolutely not. I'm saying that the objectQuery object should be typed to Map rather than HashMap:
    Map objectQuery = new HashMap();

    Similarly, the ApprovalRequestInterface.Query method should expect a Map as it's first argument, rather than a HashMap (and it very well may: we can't tell what kind of argument it expects from the post).


    I wonder if there is a (arguably very small) performance penalty for the casting between interface an actual class or not.
    Anyway, I aggree that method parameters should be rather Map than HashMap. In the case of local variables, IMO it doesn't matter.
  • coder1 (unregistered) in reply to CMG
    Anonymous:
    Anonymoose:
    Anonymous:
    Alex Papadimoulis:

    //Loading an ApprovalRequest object
    HashMap objectQuery = new HashMap();
    objectQuery.put("ApprovalRequest","*");
    objectQuery.put("ApprovalRequest.RequestId","11799");

    String[] unused = new String[1];
    unused[0] = ""; //note this is only used for updates

    GenericObject myRequest = ApprovalRequestInterface.Query(objectQuery, unused);



    Call me nit-picky if you must, but one thing that bugs the shit out of me is when people don't code to interfaces that already exist. For the love of Pete, use Map as your variable type.


    Are you saying that HashMap doesn't exist?


    Absolutely not. I'm saying that the objectQuery object should be typed to Map rather than HashMap:
    Map objectQuery = new HashMap();

    Similarly, the ApprovalRequestInterface.Query method should expect a Map as it's first argument, rather than a HashMap (and it very well may: we can't tell what kind of argument it expects from the post).

    I see your point, but if ApprovalRequestInterface.Query does indeed accept a Map as the first parameter then your argument about changing code is pretty weak.  He'd only have to change one line regardless, ie: HashMap objectQuery = new HashMap(); becomes TreeMap

  • (cs) in reply to sporty
    Anonymous:
    Cue the idiots who are going to slam java because some developers can't develop. 


    While I have significant hatred of Java, I can admit that it is a decent language that has a purpose.  One of the reasons I hate it so is that for whatever reason, Java seems to attract these kinds of idiots and encourage sloppy programming (as well as bizarre programming as seen in the WTF).
  • (cs) in reply to Paula Bean
    Anonymous:
    Enterprise! The guys at the places where I worked used to call me Paula "Enterprise" Bean....

    Thank God those Paula Bean jokes haven't gotten old yet.  The people who post as Paula sure are witty and original.
  • (cs) in reply to ammoQ
    ammoQ:
    I wonder if there is a (arguably very small) performance penalty for the casting between interface an actual class or not.

    Probably not.  Unless the class is declared as final, calling a function requires going throgh the vtable, and that cost should be the same whether accessing via the interface or the class itself.
  • An apprentice (unregistered) in reply to GoatCheez
    GoatCheez:
    Someone tells me this whole ordeal spawned from two company owners bragging to each other.

    a) my company has an enterprise web solution!
    b) we have a web solution also
    a) is an an enterprise solution?
    b) um, no....
    a) then it's not as good! ours has the word enterprise in it!
    b) bah! we'll have an enterprise solution soon! just watch!

    hundreds of thousands of dollars later....

    b) We now have an enterprise solution!
    a) That's nice, does it also have (insert buzzword here)
    b) no, what is (insert buzzword here)
    a) oh, it's a great new technology that lets us do more for less!
    b) oh, of course! i've heard of (insert buzzword here)! We just started implementing it yesterday!

    and so the process continues....

    No solution will be enterprise enough until it uses XML extensively. Aaron, brace yourself...

  • (cs) in reply to marvin_rabbit

    >Couldn't you guys just trade consultants?

    But then the consultants wouldn't make as much money. Don't you have any sympathy for them at all?

  • Paula Bean (unregistered) in reply to Jörg

    Bah! Jörg Bean would be even less funny - almost Scanned-in-avian-sounding!

  • (cs) in reply to blackfrancis
    Anonymous:

    I don't get the 3-letter table name thing.  Why would anyone do that?

    because that's all Java can handle?[:P]

  • htsfghsdfghswerqartshbdetghaerhgdsghaerdhgdfh (unregistered) in reply to An apprentice

    I suppose there's a reason why the word "intelligent" is mispelled in the forum software's logo?

  • Fred the bunny (unregistered) in reply to sporty
    Anonymous:
    Cue the idiots who are going to slam java because some developers can't develop. 


    Don't be silly.  Java sucks, but that has nothing to do with this particular episode.  This episode is the result, in part, of some idiots insisting that Java is the answer to every problem.
  • (cs) in reply to An apprentice

    It must be something in the air - there was a somewhat amusing dustup today between egotastic wunderkind David Heinemeier Hansson  and "Enterprise Architecture Thought Leader" (go ahead, explain that one) James McGovern about Ruby (and I suppose Rails, although McGovern doesn't specifically identify it).

    The subject for DHH's entry: "Boy, is James McGovern enterprise or what!" And then, later: "How do we fork the word enterprise? The capitalized version has obviously been hijacked by McGovern and his like-minded to mean something that is synonymous with hurt and pain and torment."

    Anyhoo, that's what this post reminded me of.

  • (cs) in reply to htsfghsdfghswerqartshbdetghaerhgdsghaerdhgdfh

    Yes, because everyone knows that incorrect spelling  is brillant!

  • (cs) in reply to Taevin

    Taevin:
    Anonymous:
    Cue the idiots who are going to slam java because some developers can't develop. 


    While I have significant hatred of Java, I can admit that it is a decent language that has a purpose.  One of the reasons I hate it so is that for whatever reason, Java seems to attract these kinds of idiots and encourage sloppy programming (as well as bizarre programming as seen in the WTF).

    Yes. Precisely the (major) reason I abhor Visual Basic.

  • Anita Tinkle (unregistered) in reply to R.Flowers
    R.Flowers:
    He probably likes also cryptic three-letter variable names like 'num', 'str' and 'sex'

    I'm not too sure about num and str, but I like sex.



    C:\>osql -U sa
    Password:
    1> SELECT PNS INTO ASS FROM COK INNER JOIN BOX ON COK.IFC = BOX.ORA
    2> GO

    (69 records affected)
    1>
  • Jeff (unregistered) in reply to CMG

    The given code fragment doesn't suggest they didn't.

    There's nothing wrong with the
    HashMap map = new HashMap();

    Now, if their Query() method requires a HashMap and not a Map, then yes that is an issue.

  • (cs) in reply to Aaron Griffin

    You can't be serious. Where do you work?  How did you let your moronic bosses get away with that? Don't you know that the job market is great for .net programmers. Quit your job dude, go work somewhere else. Why would a shop of .net programmers be asked to support a Java app? And 3 letter table names, how the hell does the work. Seriously you need to find another job asap.
    That's most ridiculous load of crap I've ever seen.

  • Perri Nelson (unregistered) in reply to sporty

    Anonymous:
    Cue the idiots who are going to slam java because some developers can't develop. 

    So tell me, why slam Java? Why slam VB? Why slam ANY language. Everyone knows you can write FORTRAN code in any language.

  • (cs) in reply to Taevin
    Taevin:
    Anonymous:
    Cue the idiots who are going to slam java because some developers can't develop. 


    While I have significant hatred of Java, I can admit that it is a decent language that has a purpose.  One of the reasons I hate it so is that for whatever reason, Java seems to attract these kinds of idiots and encourage sloppy programming (as well as bizarre programming as seen in the WTF).


    For a reason I cannot understand "Enterprise" to some means spending excessive amounts of time defining and marshalling data.  Here's how it goes, I think ... if an immature and non-scalable project tends to be marred by ad-hoc patches, non-generalizable code, and a absense of structure, and then an enterprise application must have excessive structure.  It should have a protective armor of extra class definitions, wrappers around framework libraries, and a custom query design to not just wrap, but to fully obfuscate sql.

    IMO, Code like this is the reason that Rails exists.  It's supposed to reduce the amount of work to do complicated things.  It's a framework that's easy to use yet still very generalized.  There's a reason it's not written in Java. 

    I don't hate Java, really, but it does attact way too many programmers who accept that working in a enterprise environment means it's more work to do simple things.  I wonder if it's because Java as a language is a bit long-winded?

  • (cs) in reply to Dave Nicolette

    Dave Nicolette:
    I can relate to this WTF. So, they had a perfectly good .NET solution in place and the staff understood the technology. They brought in consultants who ripped it all apart and replaced it with a crappy solution in J2EE. Guess what's happening where I work. Yep, you guessed it: We had a perfectly good J2EE solution in place and the staff understood the technology. They brought in consultants who ripped it all apart and replaced it with a crappy solution in .NET. Why? To make it "enterprise."

    It's all a secret conspiracy between Microsoft, Sun, and major consulting firms. The next step for these guys is a compliance and functionality review, which will recommend that the site be re-architected in .Net. That will last a few years, then management will pick up on the next buzz-word strategy and a new shift to Java# will start.... and on and on and on....

    <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p>-Me</o:p>

  • (cs) in reply to Anita Tinkle

    R.Flowers:
    He probably likes also cryptic three-letter variable names like 'num', 'str' and 'sex'

    I'm not too sure about num and str, but I like sex.

    If your str is num, sex is probably the last thing on your mind...

  • Anita Tinkle (unregistered) in reply to ParkinT
    ParkinT:

    Taevin:
    Anonymous:
    Cue the idiots who are going to slam java because some developers can't develop. 


    While I have significant hatred of Java, I can admit that it is a decent language that has a purpose.  One of the reasons I hate it so is that for whatever reason, Java seems to attract these kinds of idiots and encourage sloppy programming (as well as bizarre programming as seen in the WTF).

    Yes. Precisely the (major) reason I abhor Visual Basic.



    Java attracts the Analysis-Paralysis™ "architects" who spend 99% of their mental efforts writing up designs or building wedding cakes (too many layers) for their apps--only to have them flail on performance and scalability tests when they are released out in the wild to production.  These same architects become flustered quickly if/when users reject early releases of the deliverables since requirements change at a rate that is so faster than the designs can keep up.  If you come in late to a Java project you often see an early elegant shell framework with immense amounts of hastily architected manure hiding in shell classes around the system.

    This pattern is easy to recognize and is one of the few that can be readily fixed with modest effort.  Sometimes the fix involves dropping several layers out of the design and areas in the system that are subject to frequent change can be externalized to a business workflow engine (slap in TIBCO or Microsoft BizTalk) while the remaining parts of the system are streamlined.  Been there done that.

  • Runtime Error (unregistered) in reply to Dave Nicolette
    Dave Nicolette:
    >Couldn't you guys just trade consultants?

    But then the consultants wouldn't make as much money. Don't you have any sympathy for them at all?


    The naivete on this forum astounds me sometimes.  The same consultants work at both companies.  They sell overly complex and brittle java based enterprise systems to .net shops and they sell overly complex and brittle .net based enterprise systems to java shops.  Both are going to require extensive support after going into productions and it seems that the current staff just isn't going to be up to the tasks.  Funny how it works out that way.

    You do all work in this industry, right?
  • (cs) in reply to sammybaby
    sammybaby:

    It must be something in the air - there was a somewhat amusing dustup today between egotastic wunderkind David Heinemeier Hansson  and "Enterprise Architecture Thought Leader" (go ahead, explain that one) James McGovern about Ruby (and I suppose Rails, although McGovern doesn't specifically identify it).

    The subject for DHH's entry: "Boy, is James McGovern enterprise or what!" And then, later: "How do we fork the word enterprise? The capitalized version has obviously been hijacked by McGovern and his like-minded to mean something that is synonymous with hurt and pain and torment."

    Anyhoo, that's what this post reminded me of.



    *LOL*
    Ironically, the only magazine I know that has a regular column about Ruby is called "Linux Enterprise". (It's a German magazine, I'm not sure if it is still alive)
  • (cs) in reply to ammoQ

    ammoQ:
    I wonder if there is a (arguably very small) performance penalty for the casting between interface an actual class or not.

    um..No.

    What do you think could possibly be happening is such a cast?

    The most that could be happening is that a pointer is copied from one variable to another.  Otherwise, the only difference between using a class object and an interface object is that the compiler would see a different set of methods & properties.  The generated code would be the same.

  • (cs) in reply to squirrel
    squirrel:


    For a reason I cannot understand "Enterprise" to some means spending excessive amounts of time defining and marshalling data.  Here's how it goes, I think ... if an immature and non-scalable project tends to be marred by ad-hoc patches, non-generalizable code, and a absense of structure, and then an enterprise application must have excessive structure.  It should have a protective armor of extra class definitions, wrappers around framework libraries, and a custom query design to not just wrap, but to fully obfuscate sql.


    I can easily proof that an Enterprise Architecture(tm) reduces ad-hoc patches (measured in % of the overall system) by as much as 80-90%!

    Proof: In a system with a real Enterprise Architecture(tm), the original system is inflated with meaningless parts by a factor of 5-10. Since these meaningless parts provide no value, no function at all, they are not subject to ad-hoc patches. So, since the size of the patches roughly stays the same, the amount for a smaller part of the overall system.

    Impressive, isn't it?
  • (cs) in reply to JamesCurran
    JamesCurran:

    ammoQ:
    I wonder if there is a (arguably very small) performance penalty for the casting between interface an actual class or not.

    um..No.

    What do you think could possibly be happening is such a cast?

    The most that could be happening is that a pointer is copied from one variable to another.  Otherwise, the only difference between using a class object and an interface object is that the compiler would see a different set of methods & properties.  The generated code would be the same.



    Naively speaking: If there is only single inheritance between classes (like in java), the compiler can assume a certain layout of the class fields and methods since derived classes can only add new fields and methods (to the end of the imaginary "list"), but not change the layout of the inherited fields and methods. With interfaces, no such assumption is possible.
  • B'rick (unregistered)

    This doesn't seem all that bad compared to the CRM system my employer uses.

    Even when approached from the user's perspective, it's useless. The thing comprises 1400 badly-named tables stored in an SQL Server database, with a horrendous front-end written in Uniface. The licenses we purchase to theoretically keep things going for months typically expire after two weeks. The developers are called out on a weekly basis in order to either fix something, or coerce it into doing something it wasn't designed to do. And then that needs fixing.

    I hate it. Hate hate hate.

  • (cs) in reply to B'rick
    Anonymous:
    This doesn't seem all that bad compared to the CRM system my employer uses.

    Even when approached from the user's perspective, it's useless. The thing comprises 1400 badly-named tables stored in an SQL Server database, with a horrendous front-end written in Uniface. The licenses we purchase to theoretically keep things going for months typically expire after two weeks. The developers are called out on a weekly basis in order to either fix something, or coerce it into doing something it wasn't designed to do. And then that needs fixing.

    I hate it. Hate hate hate.


    Uniface still exists?
  • (cs) in reply to Anita Tinkle
    Anonymous:

    Java attracts the Analysis-Paralysis™ "architects" who spend 99% of their mental efforts writing up designs or building wedding cakes (too many layers) for their apps-- ...  These same architects become flustered quickly if/when users reject early releases of the deliverables since requirements change at a rate that is so faster than the designs can keep up. 

    Exactly!  And ironically, the purpose of good design is to add flexibility, not remove it.  It's supposed to separate functionality, and reduce -- or at least identify and isolate -- code dependencies.  It's supposed to reduce code momentum.

    I interviewed one of these people recently.  He was insistant that each business logic object should ideally correspond to only one (not more!) database tables so that the database schema matches the code design.  Also foreign keys should not used sparingly because hibernate has trouble dealing with multiple layers of relationships.  To top it off, he easily handled multiple inheiritance in java by creating multiple interfaces, however, he couldn't figure out a way to inheirit code without copy paste.  He would not compose objects.

    Everything pointed to Javaesque code bloat.  Limit relationships between objects.  Reimplement everywhere.  Implement as many interfaces as you need.  Go Enterprise!

  • (cs) in reply to Aaron Griffin
    Anonymous:
    R.Flowers:

    Umm, I just noticed the graphic... 242 items. Is that 242 tables? (Well, that seems to be a screenshot of - heh -'Enterprise Manager'. So is it 242 minus the handful of 'overhead' tables?)

    If so - wow. Two-hundred-plus tables with TLNs*.

     

    *Three Letter Names



    Absolutely.  And it keeps growing.  Every month or so I see an additional 20-ish tables.

    So i guess that

    1. you're still working there
    2. the management hasn't been fired for utter incompetence
    3. the "enterprise" system is still in use

    ... Why?

  • (cs) in reply to Whiskey Tango Foxtrot? Over.

    Yay, the best thing about this .netrox is the list of items labeled "item has no description" on the left.

  • (cs) in reply to Anita Tinkle
    Anonymous:

    Java attracts the Analysis-Paralysis™ "architects" who spend 99% of their mental efforts writing up designs or building wedding cakes (too many layers) for their apps--only to have them flail on performance and scalability tests when they are released out in the wild to production...


    It's high time that people stop bringing these straw man arguments to language flamewars.  The fact that a given language has several, or many stupid users says nothing about the quality of the language itself.  Their are morons using every language.  The argument that this somehow proves the inferiority of the language is entirely fallacious.
  • Robert (unregistered) in reply to merreborn
    merreborn:
    Anonymous:

    Java attracts the Analysis-Paralysis™ "architects" who spend 99% of their mental efforts writing up designs or building wedding cakes (too many layers) for their apps--only to have them flail on performance and scalability tests when they are released out in the wild to production...


    It's high time that people stop bringing these straw man arguments to language flamewars.  The fact that a given language has several, or many stupid users says nothing about the quality of the language itself.  Their are morons using every language.  The argument that this somehow proves the inferiority of the language is entirely fallacious.


    In my experience it seems to be quite accurate when talking about VB (pre .NET, but most of them seem to have reluctantly moved to VB.NET now). I'm sure there were some good developers using VB, but I have to wonder why.
  • (cs) in reply to merreborn
    merreborn:
    Anonymous:

    Java attracts the Analysis-Paralysis™ "architects" who spend 99% of their mental efforts writing up designs or building wedding cakes (too many layers) for their apps--only to have them flail on performance and scalability tests when they are released out in the wild to production...


    It's high time that people stop bringing these straw man arguments to language flamewars.  The fact that a given language has several, or many stupid users says nothing about the quality of the language itself.  Their are morons using every language.  The argument that this somehow proves the inferiority of the language is entirely fallacious.


    naw man... it's high time people stop language flamewars. anyone worth their weight knows that all languages have their place somewhere, otherwise the language wouldn't exist. get over it yall.
  • (cs) in reply to GoatCheez
    GoatCheez:
    merreborn:
    Anonymous:

    Java attracts the Analysis-Paralysis™ "architects" who spend 99% of their mental efforts writing up designs or building wedding cakes (too many layers) for their apps--only to have them flail on performance and scalability tests when they are released out in the wild to production...


    It's high time that people stop bringing these straw man arguments to language flamewars.  The fact that a given language has several, or many stupid users says nothing about the quality of the language itself.  Their are morons using every language.  The argument that this somehow proves the inferiority of the language is entirely fallacious.


    naw man... it's high time people stop language flamewars. anyone worth their weight knows that all languages have their place somewhere, otherwise the language wouldn't exist. get over it yall.


    Except vb ;-P
  • (cs)

    I think you ought to say who these clowns are, so the rest of us can STAY THE FUCK AWAY.

     

  • Anonymous (unregistered) in reply to CMG

    (my CAPTCHA word is "enterprise", how appropriate :))

    Anonymous:
    Absolutely not. I'm saying that the objectQuery object should be typed to Map rather than HashMap:
    Map objectQuery = new HashMap();


    That's pointless, since you can use a HashMap any time you need a Map anyway. All that does it make things slower, since calling a method through an interface-type reference has around 10 times as much overhead as calling through a class-type reference.


    Similarly, the ApprovalRequestInterface.Query method should expect a Map as it's first argument, rather than a HashMap


    If it needs to be used on other types of Maps as well as HashMap, then yes. Otherwise, again you're just making things pointlessly slower.
  • Jon (unregistered) in reply to merreborn
    merreborn:
    Anonymous:
    Java attracts the Analysis-Paralysis™ "architects"...
    It's high time that people stop bringing these straw man arguments to language flamewars. ... The argument that this somehow proves the inferiority of the language is entirely fallacious.
    He didn't make that argument -- you just brought it up to discredit his point. Who's building straw men now?
  • Robert (unregistered) in reply to Anonymous
    Anonymous:
    (my CAPTCHA word is "enterprise", how appropriate :))

    Anonymous:
    Absolutely not. I'm saying that the objectQuery object should be typed to Map rather than HashMap:
    Map objectQuery = new HashMap();


    That's pointless, since you can use a HashMap any time you need a Map anyway. All that does it make things slower, since calling a method through an interface-type reference has around 10 times as much overhead as calling through a class-type reference.


    Similarly, the ApprovalRequestInterface.Query method should expect a Map as it's first argument, rather than a HashMap


    If it needs to be used on other types of Maps as well as HashMap, then yes. Otherwise, again you're just making things pointlessly slower.


    Even if this was the case with Java, which I've been led to believe it isn't, I would consider good programming practice more important than avoiding the most likely inconsequential performance hit.
  • (cs) in reply to Anonymous
    Anonymous:
    All that does it make things slower, since calling a method through an interface-type reference has around 10 times as much overhead as calling through a class-type reference.

    I really want to see evidence of this.  I see no reason that this should be true.  Both require a vtable lookup.  Why would the interface have 10 times the overhead for a lookup?
  • (cs) in reply to CMG

    Anonymous:
    Call me nit-picky if you must, but one thing that bugs the shit out of me is when people don't code to interfaces that already exist. For the love of Pete, use Map as your variable type.

    I'm not a java programmer so enlighten me. (I've read all the arguments, and they either don't make sense, or are contradictory)

    I assume that HashMap is a derivative of Map? If Query expects a HashMap, or calls a HashMap only function, how can you give it anything but a HashMap?

     

  • Robert (unregistered) in reply to chrismcb
    chrismcb:

    Anonymous:
    Call me nit-picky if you must, but one thing that bugs the shit out of me is when people don't code to interfaces that already exist. For the love of Pete, use Map as your variable type.

    I'm not a java programmer so enlighten me. (I've read all the arguments, and they either don't make sense, or are contradictory)

    I assume that HashMap is a derivative of Map? If Query expects a HashMap, or calls a HashMap only function, how can you give it anything but a HashMap?

     



    It's not so much a Java thing, as a general design principle to reduce class dependencies. The Query shouldn't unless absolutely necessary be programmed against the HashMap implementation in the first place.
  • Anonymous (unregistered) in reply to Robert
    Anonymous:
    Even if this was the case with Java, which I've been led to believe it isn't, I would consider good programming practice more important than avoiding the most likely inconsequential performance hit.


    I have tested it, and it is the case. You have been misled. And how is using misleading variable types "good programming practice"?

    Jörg:
    I really want to see evidence of this.  I see no reason that this should be true.  Both require a vtable lookup.


    Finding the method pointer for interface methods in the vtable takes much longer, since it's not in the same place in all classes.
  • (cs) in reply to Anonymous
    Anonymous:
    Anonymous:
    Even if this was the case with Java, which I've been led to believe it isn't, I would consider good programming practice more important than avoiding the most likely inconsequential performance hit.


    I have tested it, and it is the case. You have been misled. And how is using misleading variable types "good programming practice"?



    I wouldn't consider an interface to be misleading. I couldn't find any information regarding performance differences in my quick search; however, one post I found regarding calling by interface in .NET indicated that it was an additional two instructions for that platform.
  • (cs)

    From reading these replies, I see that no one else has noticed that the database tables are all owned by "sysadmin." This makes me uneasy, and is potentially a WTF. I assume that by its nature, an enterprise system has many users, with different roles requiring different privileges. One of the things this implies is that there are parts of the database some users should not be able to touch or see. Where is the separation of privileges in the new system?

  • (cs)

    No Enterprise solution/application is complete without Enterprise-level flaws and defects. Management knew that well, and have done a great job.

  • (cs) in reply to chrismcb
    chrismcb:

    Anonymous:
    Call me nit-picky if you must, but one thing that bugs the shit out of me is when people don't code to interfaces that already exist. For the love of Pete, use Map as your variable type.

    I'm not a java programmer so enlighten me. (I've read all the arguments, and they either don't make sense, or are contradictory)

    I assume that HashMap is a derivative of Map? If Query expects a HashMap, or calls a HashMap only function, how can you give it anything but a HashMap?

    HashMap implements the Map interface.

Leave a comment on “Bitten by the Enterprise Bug”

Log In or post as a guest

Replying to comment #:

« Return to Article