It's easier if everything has the same name



  • $PROJECT/.../util/CacheManager.java

    $PROJECT/.../cache/CacheMaanger.java

    $PROJECT/.../gui/CacheManager.java

    $PROJECT/.../gui/util/CacheManager.java

    $PROJECT/.../lib/cache/CacheManager.java

    $PROJECT/.../lib/util/CacheManager.java

    All having completely different implementations, doing completely unrelated things.

    When I asked "Why?", I was told by the team lead that it's easier if everything that pertains to maps has the same name, even if the purpose and implementation is completely different; don't worry, the jvm can tell them apart.

     



  •  So do any of them manage the cache, by chance?  If not that would about triplicate the level of WTF.



  • @Master Chief said:

     So do any of them manage the cache, by chance?  If not that would about triplicate the level of WTF.

    Well, they all had some form of Map in them, but the ones I've looked into thus far are transient, which would seem to rule out anything cache-like, so yeah...


  •  Why do you work there?



  • " don't worry, the jvm can tell them apart."

     Hahaha... stupid SOB!

    So your code must be filled with full package calls, I really love those.

    Make this better by implementing an Interface CacheManager and a CacheManagerFactory:

     CacheManagerFactory.instanceOf(com.xxx.enum.CacheManager.GUI_UTIL); 

     CacheManagerFactory.instanceOf(com.xxx.enum.CacheManager.LIB_UTIL);

     Actually, you just gave me an idea for an antipattern.



  •  Because they pay him to sit there and shake his head every few minutes?



  • @KattMan said:

     Because they pay him to sit there and shake his head every few minutes?

    Actually, I was going to take a different job - doing web service development at another firm. A headhunter-agency had subcontracted some web services development, and I was to work for the agency. I told them during the phone and in-person interviews that I have zero experience doing web development and they said it was no problem because they wanted someone who could think, and that they'd teach me the web service stuff. Ok, sounds like a good opportunity to learn something on someone elses nickel. Except that 2 days before the start date, they called and said that I needed to be an expert on day one because the manager was going to be looking over our shoulders, so I should read a book on web development.

    Erm, and what happens when anything in the stack from SOAP to XML to ... goes wrong and provides one of those "ERROR - bad thing happened - no useful details here" error messages we all love? The on-site manager is surely going to notice me struggling trying to figure out stuff that someone familiar with the technologies would already know.

    It turns out the head hunter had pawned me off as a web services expert, so I called the client-hiring manager, told him the truth, begged off and wished him well. He thanked me for my honesty.

    I wound up here because I can come and go as I please, work from home if I don't feel like coming to the office, get paid a lot of money, and the pace here is comparable to a crippled snail stuck in molasses on a cold winter day. It'll be an easy summer. Then I can look for something better in the fall.

     



  • @snoofle said:

    It turns out the head hunter had pawned me off as a web services expert, so I called the client-hiring manager, told him the truth, begged off and wished him well. He thanked me for my honesty.

    And he didn't irrationally blow his stack?  Sounds like he would have been a great guy to work for.  Pity it didn't pan out.


    I wound up here because I can come and go as I please, work from home if I don't feel like coming to the office, get paid a lot of money, and the pace here is comparable to a crippled snail stuck in molasses on a cold winter day. It'll be an easy summer. Then I can look for something better in the fall.

     

    Not only that, but you get a steady stream of WTFs to post here.  I don't see much room for improvement.



  • @snoofle said:

    Erm, and what happens when anything in the stack from SOAP to XML to ... goes wrong and provides one of those "ERROR - bad thing happened - no useful details here" error messages we all love? The on-site manager is surely going to notice me struggling trying to figure out stuff that someone familiar with the technologies would already know.

    It turns out the head hunter had pawned me off as a web services expert, so I called the client-hiring manager, told him the truth, begged off and wished him well. He thanked me for my honesty.


    Whoa, GOOD MOVE THERE. The less you know about the current state of webservices, the saner you'll be. I'll take a dozen CacheManager classes over the inevitable almost-but-not-quite-compatible webservice hell any day of the week. As long as you are exclusively using one major vendor to provide WS facilities, then it's fine, although then it's just a hugely humongous waste of resources.

    But as soon as you have two vendors, especially competing vendors, especially if one is Microsoft, trying to interoperate through webservices, it will take all your strength plus some tempered steel chains to keep you from going postal and defenestrating your equipment. (Or at least that's how it is with me.) Web services are in theory a simple, straightforward, and fun-loving way for everybody to sing along and have fun together sharing love and data. Instead, it's a tangled and utterly frustrating mess of incompatible implementations, incomplete and laughably ridiculously complicated specs, buggy code generators, a lack of control in your own code, nigh zero support, crappy old versions of .Net webservices that never followed the spec in the first place, bizarre case-sensitive HTTP header bugs, and more things that can go wrong than you'd ever imagine could be encoded into <acronym xmlns="http://this.url.doesnt.exist/so/why/are/we/using/it/as/the/uri/" hurp:xmlns="i:just:love:this:fun:easy:human:readable:format"> <letter>X</letter> <letter>M</letter> <letter>L</letter> </acronym>

    (That reminds me of some [url=http://www.theserverside.com/news/thread.tss?thread_id=40064]light humor[/url] that shocked me with its accuracy.)



  • Aw, c'mon Xyro! Don't hold back! Tell us how you *really* feel.



  • The only problems I've had with webservices is when people used it poorly from Java and built a new object from the WSDL every call, thus expecting it to be exactly the same, so we couldn't add to our implementation (even non-breaking changes).  Webservices are easy.

     edit: And our team uses .Net



  • @snoofle said:

    the jvm can tell them apart.
    This is how inside jokes are born.



  • @Xyro said:

    Whoa, GOOD MOVE THERE. The less you know about the current state of webservices, the saner you'll be. I'll take a dozen CacheManager classes over the inevitable almost-but-not-quite-compatible webservice hell any day of the week. As long as you are exclusively using one major vendor to provide WS facilities, then it's fine, although then it's just a hugely humongous waste of resources.

    But as soon as you have two vendors, especially competing vendors, especially if one is Microsoft, trying to interoperate through webservices, it will take all your strength plus some tempered steel chains to keep you from going postal and defenestrating your equipment. (Or at least that's how it is with me.) Web services are in theory a simple, straightforward, and fun-loving way for everybody to sing along and have fun together sharing love and data. Instead, it's a tangled and utterly frustrating mess of incompatible implementations, incomplete and laughably ridiculously complicated specs, buggy code generators, a lack of control in your own code, nigh zero support, crappy old versions of .Net webservices that never followed the spec in the first place, bizarre case-sensitive HTTP header bugs, and more things that can go wrong than you'd ever imagine could be encoded into <acronym xmlns="http://this.url.doesnt.exist/so/why/are/we/using/it/as/the/uri/" hurp:xmlns="i:just:love:this:fun:easy:human:readable:format"> <letter>X</letter> <letter>M</letter> <letter>L</letter> </acronym>

    (That reminds me of some light humor that shocked me with its accuracy.)

    I do web services every day. My most common use case is my .Net web service is called by a Java client through an IBM DataPower security gateway. I've never had an interoperability problem. @Xyro said:
    <acronym xmlns="http://this.url.doesnt.exist/so/why/are/we/using/it/as/the/uri/" hurp:xmlns="i:just:love:this:fun:easy:human:readable:format"> <letter>X</letter> <letter>M</letter> <letter>L</letter> </acronym>
    This is a classic example of where the problem is; you don't seem to realize that a URI is a superset of a URL. XML namespaces are URNs, and as such, only need to be unique. The safest way to make them unique is to begin them with a prefix that you control; the URL of the company website is a good choice. The suffix is irrelevant, except for its uniqueness and descriptiveness.


  • @Jaime said:

    XML namespaces are URNs

    That's not true, they can be any kind of URI.



  • @Spectre said:

    @Jaime said:
    XML namespaces are URNs

    That's not true, they can be any kind of URI.


    @RFC 3986 said:
    The term "Uniform Resource Name" (URN) has been used historically to refer to both URIs under the "urn" scheme (RFC 2141), which are required to remain globally unique and persistent even when the resource ceases to exist or becomes unavailable, and to any other URI with the properties of a name.

    It is acceptable to call a URI a URN when it is being used as a name. Of course, the RFC also says that we should stop doing it in the future, but I'm a creature of habit and I'd been doing XML for almost ten years when that RFC came out.



  • @Jaime said:

    @Spectre said:
    @Jaime said:
    XML namespaces are URNs

    That's not true, they can be any kind of URI.


    @RFC 3986 said:
    The term "Uniform Resource Name" (URN) has been used historically to refer to both URIs under the "urn" scheme (RFC 2141), which are required to remain globally unique and persistent even when the resource ceases to exist or becomes unavailable, and to any other URI with the properties of a name.

    It is acceptable to call a URI a URN when it is being used as a name. Of course, the RFC also says that we should stop doing it in the future, but I'm a creature of habit and I'd been doing XML for almost ten years when that RFC came out.

    Okay.


Log in to reply