JIRA's JavaScript is full of debug statements



  • There are many things that irritate me about JIRA, but most of them seem to be a result of misconfiguration by certain people with whom I work. There is one thing that is a constant irritation though, and it's entirely Atlassian's fault. I have Firebug open in my other monitor all day every day, and whenever I have to interact with JIRA for any reason there is a steady stream of debugging statements from console.log. It looks like this:

    ui    : GH.PlanController.hide
    tried to get container of DetailsView before selector was set
    ui    : GH.BurndownChartController.hide
    ui    : GH.SprintRetrospectiveController.hide
    ui    : GH.VelocityChartController.hide
    ui    : GH.ControlChartController.hide
    ui    : GH.CFDController.hide
    ui    : GH.WorkController.show
    state : GH.RapidBoard.State.replaceState by setMode
    callback: Executing callbacks for gh.work.pool.loaded
    callback: Finished callbacks for gh.work.pool.loaded
    callback: Executing callbacks for gh.work.pool.rendered
    callback: Finished callbacks for gh.work.pool.rendered
    Setting poll handler: WorkPoller
    ui    : creating stalker header
    ui    : removing stalker header
    ui    : creating stalker header
    ui    : removing stalker header
    state : GH.RapidBoard.State.pushState by toggleActiveQuickFilter
    

    You can tell just from glancing at these messages what they're for. Especially "tried to get container of DetailsView before selector was set", which is clearly somebody's null pointer debugging check from some perhaps unfinished attempt to fix a bug. This is a very rudimentary faux pas which pretty much nobody else does, and a sign of lots of different types of WTFery. My intuition tells me that they're doing this because they have allowed their code quality to drop so incredibly low that they no longer feel they can live without this "feature".



  • oh my God—it's full of stars!



  • At least it doesn't have debugger statements everywhere.

    Also wouldn't this break iE8?



  • So what? You open a tool dedicated to debugging webpages and you complain you are getting debugging statements there?



  • @tchize said:

    So what? You open a tool dedicated to debugging webpages and you complain you are getting debugging statements there?
    What's your company? It's to avoid doing business with you.

    Seriously: debug statements in production, that's just not a great sign.



  • Try using Chrome for your work. I'm not sure about Firebug, but in Chrome (and even IE) the dev tools are tab/window specific. Then you only need to open the dev tools for the tab you want, and keep JIRA open in a different tab or window. No mess in your console.log!

    Or, doesn't Firebug force you to white-list which pages/domains it is active on (assuming you don't have "enable for all pages" turned on? Can't you thus turn off Firebug for JIRA?



  • JIRA is a piece of shit software that I hate with a passion. I found out it was written in Java when it gave me a stacktrace when I was trying to move a task. It's slow, it's bloated, it's ugly, Atlassian changes the fucking interface at least once a week... avoid if at all possible.



  • @The_Assimilator said:

    JIRA is a piece of shit software that I hate with a passion. I found out it was written in Java when it gave me a stacktrace when I was trying to move a task. It's slow, it's bloated, it's ugly, Atlassian changes the fucking interface at least once a week... avoid if at all possible.

    This is pretty much the opposite of my experience with it. I'm not saying that it's perfect, but I've never gotten any sort of a stack trace or had performance problems. We only upgrade about once a year (or so...I think...I'm not really involved, so I couldn't really say) but the interface changes didn't seem overwhelming to me.



  • @The_Assimilator said:

    JIRA is a piece of shit software that I hate with a passion. I found out it was written in Java when it gave me a stacktrace when I was trying to move a task. It's slow, it's bloated, it's ugly, Atlassian changes the fucking interface at least once a week... avoid if at all possible.

    Everything you say is true. I have seen those stack traces with my own eyes. You move a task, there's a flicker, and suddenly BOOM. A gigantic stack trace in 10px font filling the entire screen is overlayed on top of the existing page content.

    You know you're dealing with rotten software when its decaying flesh causes so many externally observable sights and smells.



  • @boomzilla said:

    @The_Assimilator said:
    JIRA is a piece of shit software that I hate with a passion. I found out it was written in Java when it gave me a stacktrace when I was trying to move a task. It's slow, it's bloated, it's ugly, Atlassian changes the fucking interface at least once a week... avoid if at all possible.

    This is pretty much the opposite of my experience with it. I'm not saying that it's perfect, but I've never gotten any sort of a stack trace or had performance problems. We only upgrade about once a year (or so...I think...I'm not really involved, so I couldn't really say) but the interface changes didn't seem overwhelming to me.

    Ditto, we have it here and so far everyone seems to really like it. Of course, our old method was to write things on sticky notes and move them around manually, and we were using Fogbugs for tracking software. JIRA, at least, interfaces properly with Perforce and PeerReview Complete.


    As for performance, yeah it runs like [i]crap[/i] on IE. Chrome runs it fluidly, even on our old conference room PCs.



  • @CodeNinja said:

    As for performance, yeah it runs like crap on IE. Chrome runs it fluidly, even on our old conference room PCs.
    Holy crap, thank you, thank you, thank you!

    I was this >| |< close to kicking the living crap out of my machine when I read your post.  It runs like a dream on chrome compared to IE. I didn't bother trying with chrome because everything other "enterprise" web app here breaks horribly unless you use IE.



  • @TGV said:

    @tchize said:

    So what? You open a tool dedicated to debugging webpages and you complain you are getting debugging statements there?
    What's your company? It's to avoid doing business with you.

    Seriously: debug statements in production, that's just not a great sign.

     

    Come on, Op has explicitly requested debug information, he gets debug information... It's not debug statement in production, it's debug statements in a debug environments. You are confusing between the server side (production) and the client side (where debug tools are installed and used). Jira is juste issuing a logic if (debug level is activated) then issue a debug statement.

     



  • @tchize said:

    Come on, Op has explicitly requested debug information, he gets debug information... It's not debug statement in production, it's debug statements in a debug environments. You are confusing between the server side (production) and the client side (where debug tools are installed and used). Jira is juste issuing a logic if (debug level is activated) then issue a debug statement.

    You don't sound like a web developer to me. The Javascript console doesn't "request" debug information. It just prints any that is sent from the application. Except on Internet Explorer, the open/closed state of the Javascript console isn't even something the application code can have awareness of. console.log in Javascript isn't any kind of fancy debugging tool, it's just the language's principal output method, analogous to "System.out.println", "printf", "echo" or "puts". Committing code that does this and deploying it to production is on a similar level of professionalism as shipping binaries that write debug statements to STDOUT. In fact, unless Atlassian are willingly breaking IE compatibility, they must have some sort of wrapper in place to avoid writing to console.log if there is no console object. That's because IE even turns this feature off when the console isn't open, because the assumption that web developers will not ship code containing console.log calls is that ingrained.



  • Disabling console.log in browsers that don't support it or have it turned off is a piece of cake:

    https://github.com/h5bp/html5-boilerplate/blob/master/js/plugins.js



  • @GNU Pepper said:

    console.log in Javascript isn't any kind of fancy debugging tool, it's just the language's principal output method, analogous to "System.out.println", "printf", "echo" or "puts".

    JS's version of those is more "document.write()" or (horrors) "alert()". I first learnt about console.log when I first installed Firebug; before then I alerted debugging information, or modify innerHTML of a dedicated debugging div.

    @GNU Pepper said:

    In fact, unless Atlassian are willingly breaking IE compatibility, they must have some sort of wrapper in place to avoid writing to console.log if there is no console object.

    Plenty of information in links posted above.

    @GNU Pepper said:

    Committing code that does this and deploying it to production is on a similar level of professionalism as shipping binaries that write debug statements to STDOUT.

    A lot of programs would have that available, even if only turned on with a command line switch. Which is analogous to having the console open.


Log in to reply
 

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