IOS devices (iPods, iPads, iPhones) have no JavaScript debugger


  • :belt_onion:

    DON'T MAKE ME TURN THIS CAR AROUND.



  • @blakeyrat said:

    criticize me based on things I've actually said

    Challenge accepted.

    @blakeyrat said:

    @e4tmyl33t said:
    Aardwolf
    They "pause execution" by sending an asynch XmlHttpRequest, I don't see how that could possibly work in a BeforeUnload handler

    You acknowledge that foo is not likely to work...

    @blakeyrat said:

    @Kittemon said:
    @blakeyrat said:
    @dhromed said:
    @blakeyrat said:
    You still can't debug a BeforeUnload handler that way
    Shoot off a quick httprequest to some server-side code that gives you the error?
    99% of the time, the exact thing I'm debugging is why the browser won't let me send a http request during BeforeUnload.
    Intuition suggests that, for reasons which should be obvious, You Shouldn't Do That, and that as a consequence, You Can't Do That.
    And yet I Must Do That, so.

    ...yet you attempt foo anyway, then complain that you have no way to debug why foo doesn't work. RTFM perhaps?

    (Yes, I realize that the complaint is valid and that it preceded the quoted example, but that makes neither the complaint nor the example any less WTFs.)



  • @boomzilla said:

    @dhromed said:
    Also, what the hell happened to the tag entry field? Or is it just me?

    I noticed it, too. It looks like you have to post, then edit tags.

    The tag entry field seems to be working normally for me. The tag box doesn't contain any tags, but it seems to be working normally.



  • @Kittemon said:

    @boomzilla said:
    @dhromed said:
    Also, what the hell happened to the tag entry field? Or is it just me?
    I noticed it, too. It looks like you have to post, then edit tags.

    The tag entry field seems to be working normally for me. The tag box doesn't contain any tags, but it seems to be working normally.

    If it's not suggesting all sorts of random words with accents it's not working normally.


  • @Kittemon said:

    ...yet you attempt foo anyway, then complain that you have no way to debug why foo doesn't work. RTFM perhaps?

    No; foo is sending an async request. I've never tried that, that's stupid, that's going to break websites and make angry clients. Or much more likely, the browser will just say, "you're trying to do whaaa!?" and feed you an exception back. (EDIT: although the makers of that fake-o JS debugger seem to show it works at least on WebKit browsers.)

    What I'm trying to do is send a single synchronous request, a pixel load. The problem is that when the page unloads, the browser automatically cancels all pending data requests (as it should). The only "solution" I've come up with so far is to delay the browser unload so there's a good chance the pixel request completes before it's cancelled. Since there's no standard, or non-standard, command to say, "hey please load this pixel but go ahead and unload everything else, then throw the pixel away when you get it, thanks!" I have no other choice in the matter.



  • @blakeyrat said:

    What I'm trying to do is send a single synchronous request, a pixel load. The problem is that when the page unloads, the browser automatically cancels all pending data requests (as it should). The only "solution" I've come up with so far is to delay the browser unload so there's a good chance the pixel request completes before it's cancelled. Since there's no standard, or non-standard, command to say, "hey please load this pixel but go ahead and unload everything else, then throw the pixel away when you get it, thanks!" I have no other choice in the matter.


    You said something about analytics - are you basically trying to get timestamps to measure how long someone was on the page? If so, ugly though it is, spamming "I'm still on the page" messages to the server might be the only reliable solution.



  • @pjt33 said:

    You said something about analytics - are you basically trying to get timestamps to measure how long someone was on the page? If so, ugly though it is, spamming "I'm still on the page" messages to the server might be the only reliable solution.

    The solution I'm using now is about 90% reliable for desktop browsers (even normal Safari), but only 18.8% reliable for Mobile Safari. But yes, the intent is to:

    1) Get time-on-page

    2) Flush out any other pending analytics on-page events (I cache them, of course)

    The alternative is to make my analytics code spammy as shit (like your suggestion), constantly sending out pixels for basically no reason at all. I refuse to do that; I am trying to write a quality product here. Even if I have to fight the W3C tooth and nail every step of the way.

    The other alternative, and this is what a lot of shitty analytics tools do (like, say, that turd Adobe bought) is to "estimate" time-on-page by looking at the delta between a load of page 1, and a load of page 2. Then report that number to the client as if it actually meant something and wasn't a pure fiction. I'm trying to write a quality product here. I'm not going to feed rabbit shit to my clients and call it raisins.

    The Real WTF, of course, is the W3C having absolutely ZERO interest in analytics, and thus providing absolutely no support for extremely common analytics tasks like this. I fully understand the potential for abuse in what I'm doing, but it would be trivial to add a DOM command to provide a "one way HTTP request" that just sends the requests to our back-end and ignores the results. Believe me, everybody would be better off.



  • @blakeyrat said:

    The Real WTF, of course, is the W3C having absolutely ZERO interest in analytics, and thus providing absolutely no support for extremely common analytics tasks like this.

    The W3C exists solely to hold up the development of coherent web standards. I have two hypotheses for why this is:

    1. The W3C is comprised entirely of pointy-headed, academic shitheads.

    2. The W3C is a front for a hostile alien race sent to Earth to retard technical advancement long enough for their Harvester-class ships to make the 500 light year voyage after which all humans will be rounded up and processed into our base nutrients which will supply our cruel alien masters with sustenance.

    For obvious reasons, I believe all evidence points to conclusion #2.



  • @morbiuswilters said:

    I have two hypotheses for why this is:

    1. The W3C is comprised entirely of pointy-headed, academic shitheads.

    2. The W3C is a front for a hostile alien race sent to Earth to retard technical advancement long enough for their Harvester-class ships to make the 500 light year voyage after which all humans will be rounded up and processed into our base nutrients which will supply our cruel alien masters with sustenance.

    For obvious reasons, I believe all evidence points to conclusion #2.

    Those hypothesesare not mutually exclusive: the hostile alien race could still be pointy-headed academic shitheads, just studying off-world. Hell, some of their decisions are really unearthly.

    @morbiuswilters said:

    What if he wrote on the wrong leg to begin with?

    Simply copy his name to the other leg also. That way, both options are covered, and he can confidently state he's operated upon the correct one.



  • @blakeyrat said:

    How is any "professional" developer not using a debugger constantly?

    because most of the time those professional developers KNOW what their code does.


  • ♿ (Parody)

    @Weps said:

    @blakeyrat said:

    How is any "professional" developer not using a debugger constantly?

    because most of the time those professional developers KNOW what their code does.

    Of course! It crashes.



  • @Weps said:

    @blakeyrat said:

    How is any "professional" developer not using a debugger constantly?

    because most of the time those professional developers KNOW what their code does.

    Hahahaha, oh wait, you were serious? Let me laugh even harder: HAHAHA



  • @blakeyrat said:

    @Weps said:
    @blakeyrat said:

    How is any "professional" developer not using a debugger constantly?

    because most of the time those professional developers KNOW what their code does.

    Hahahaha, oh wait, you were serious? Let me laugh even harder: HAHAHA

    Have fun at it, tomorrow another day watching the debugger. O wait...you're lacking one. lol.



  • @Weps said:

    @blakeyrat said:

    How is any "professional" developer not using a debugger constantly?

    because most of the time those professional developers KNOW what their code is intended to do.

    FTFY. If code worked and behaved in exactly the way the developer intended, we wouldn't need testers. And it's precisely this "I know what my code does" attitude that costs the S/W industry dear.



  • @Weps said:

    @blakeyrat said:

    How is any "professional" developer not using a debugger constantly?

    because most of the time those professional developers KNOW what their code does.

    What I love about TDWTF is that you learn something new every day. Take today's lesson for example:

    Debuggers: They tell you what your code does. Useless if you are a Master Programmer and already KNOW what your code does. Mostly used by n00bs.



  • @Weps said:

    because most of the time those professional developers KNOW what their code does.
     

    I don't know if it would be sadder if this was a troll attempt or if you were serious...


  • @blakeyrat said:

    The other alternative, and this is what a lot of shitty analytics tools do (like, say, that turd Adobe bought) is to "estimate" time-on-page by looking at the delta between a load of page 1, and a load of page 2. Then report that number to the client as if it actually meant something and wasn't a pure fiction. I'm trying to write a quality product here. I'm not going to feed rabbit shit to my clients and call it raisins.

    Surely time on page is a fiction anyway in the sense that what the clients care about is time looking at page, and all you can really say is that you have an upper bound? A single callback after 30 seconds to tell you they're still on the page captures the most important information: at least they waited for the page to load and didn't immediately discard it.

    It seems to me that there's a fourth option, which is to ping on an exponentially increasing delay. It's not very spammy, and given that on-page times almost certainly follow a power law a logarithmic time scale would be the natural choice to present the data anyway.



  • @Cassidy said:

    @Weps said:
    @blakeyrat said:

    How is any "professional" developer not using a debugger constantly?

    because most of the time those professional developers KNOW what their code is intended to do.

    FTFY. If code worked and behaved in exactly the way the developer intended, we wouldn't need testers. And it's precisely this "I know what my code does" attitude that costs the S/W industry dear.

    No, it's the 'don't know what this code does' attitude that costs the industry much, but apparently it's so normal to be a fuck up and spend time [b]constantly[/b] in the debugger that it is even seen as being professional. Hilarious.



  • @pjt33 said:

    It seems to me that there's a fourth option, which is to ping on an exponentially increasing delay. It's not very spammy, and given that on-page times almost certainly follow a power law a logarithmic time scale would be the natural choice to present the data anyway.

    Except we still need data on what link the user pressed to leave the site (if any). So... that doesn't help.

    Don't think that because I'm talking about time-on-page that time-on-page is the only thing I care about. It's just the easiest to explain to people not familiar with web analytics. (Or people whose only exposure to web analytics is through shitty tools.)



  •  You could do what Google does, and not actually link to the external sites at all. Look at their search pages, the results display the URL, but the link behind them is actually to another Google page which does whatever clearing up or final checking they need. Quite easy to add in your last visit entry and the link you've requested before sending the users browser to another site.

    This is probably least fraught with problems and most likely to work in all cases.



  • @ASheridan said:

    This is probably least fraught with problems and most likely to work in all cases.

    Look we've already been over all this in another thread. notthisshitagain.jpg

    EVERYBODY READ THIS THREAD BEFORE PROVIDING ME STUPID-ASS SUGGESTIONS THAT DON'T FUCKING WORK k thanx bye



  •  Look, if you're going to be a complete twat and ignore good advice, that's no skin off my back, you're just going further to prove your stupidity. What I gave was a valid suggestion, and I think that if it's good enough for Google, it's good enough for whatever shitty script you're putting together.

    Other have already pointed out on this thread that you just don't want to listen to good advice, or take suggestions of any kind. As you've not actually said anything that specifically rules out my suggestion, I'll take it to mean that either it was so far above your head (simple idea that it was) or you just don't really want ideas. We're mainly only suggesting them to get you to stfu, because you're an insufferable cock.

    Oh, and I didn't bother reading that other thread. If you can't be bothered to read and at least reply intelligently to my post, why the fuck should I read an entire thread where you couldn't be fucking bothered to point out the one or two posts that were pertinent to your point?

    k thx bye



  • @blakeyrat said:

    @ASheridan said:
    This is probably least fraught with problems and most likely to work in all cases.
    Look we've already been over all this in another thread. notthisshitagain.jpg

    EVERYBODY READ THIS THREAD BEFORE PROVIDING ME STUPID-ASS SUGGESTIONS THAT DON'T FUCKING WORK k thanx bye

    Hmmm... have you tried using a debugger?


  • @ASheridan said:

    If you can't be bothered to read and at least reply intelligently to my post, why the fuck should I read an entire thread where you couldn't be fucking bothered to point out the one or two posts that were pertinent to your point?

    Except I wasn't asking for your advice in the first place. You're not doing me a service by giving me the same useless suggestions I've gotten 20 times in the past because you think you're somehow qualified to give me advice when you don't even know what the requirements of the project are and, from that response you just typed, don't seem to have any interest in finding them out. You're not helping me, you're wasting both our time.

    And yes I recognize the irony. Here's where you call me a hypocrite, etc etc.



  • @Weps said:

    @Cassidy said:
    @Weps said:
    @blakeyrat said:

    How is any "professional" developer not using a debugger constantly?

    because most of the time those professional developers KNOW what their code is intended to do.

    FTFY. If code worked and behaved in exactly the way the developer intended, we wouldn't need testers. And it's precisely this "I know what my code does" attitude that costs the S/W industry dear.

    No, it's the 'don't know what this code does' attitude that costs the industry much, but apparently it's so normal to be a fuck up and spend time constantly in the debugger that it is even seen as being professional. Hilarious.

    You should know what your code is supposed to do.

    And you should also verify that it does.

    Testing can take care of 99% of that automatically for you, but it's always good to take a look under the bonnet and watch your code actually running.  I often do it the first couple of times through when I've added a big or tricky new chunk of code that's running for the first time.




  • @ASheridan said:

    You could do what Google does every other site in the world has been doing since the end of the last millennium, and not actually link to the external sites at all. Look at their search pages, the results display the URL, but the link behind them is actually to another Google page which does whatever clearing up or final checking they need. Quite easy to add in your last visit entry and the link you've requested before sending the users browser to another site.

    This is probably least fraught with problems and most likely to work in all cases.

    FTFY. To be fair, this can't catch the case where the site is so obviously sucky that the user immediately hits the back button when they realize where they've ended up at.



  • @Kittemon said:

    @ASheridan said:

    You could do what Google does every other site in the world has been doing since the end of the last millennium, and not actually link to the external sites at all. Look at their search pages, the results display the URL, but the link behind them is actually to another Google page which does whatever clearing up or final checking they need. Quite easy to add in your last visit entry and the link you've requested before sending the users browser to another site.

    This is probably least fraught with problems and most likely to work in all cases.

    FTFY. To be fair, this can't catch the case where the site is so obviously sucky that the user immediately hits the back button when they realize where they've ended up at.

    Seriously, do you people read before posting? This is for a Javascript web analytics program. He does not control the page. He has no server-side code.



  • @morbiuswilters said:

    @Kittemon said:
    @ASheridan said:

    You could do what Google does every other site in the world has been doing since the end of the last millennium, and not actually link to the external sites at all. Look at their search pages, the results display the URL, but the link behind them is actually to another Google page which does whatever clearing up or final checking they need. Quite easy to add in your last visit entry and the link you've requested before sending the users browser to another site.

    This is probably least fraught with problems and most likely to work in all cases.

    FTFY. To be fair, this can't catch the case where the site is so obviously sucky that the user immediately hits the back button when they realize where they've ended up at.

    Seriously, do you people read before posting? This is for a Javascript web analytics program. He does not control the page. He has no server-side code.

    Yes, I read before posting, yet I don't recall blakeyrat ever actually explaining why he needed to do this. It's possible that it got lost in the midst of a blakeyrant. It's also possible that he only explained that part in a different thread altogether.



  • @morbiuswilters said:

    Seriously, do you people read before posting? This is for a Javascript web analytics program. He does not control the page. He has no server-side code.

    I have given up, my friend. You, also, should give up. That is the wisest and best thing to do.

    Leave this forum for the Weps and the Bridget99's of the world. Nothing of value remains here.



  • @blakeyrat said:

    @morbiuswilters said:
    Seriously, do you people read before posting? This is for a Javascript web analytics program. He does not control the page. He has no server-side code.
    I have given up, my friend. You, also, should give up. That is the wisest and best thing to do.

    Sorry if I missed it but I only remember you stating that you use javascript to do analytics (but not that it's analytics on other people's pages) so that may be where some people's confusion came from.  I mean I knew you had no control on the page due to old topics, but I don't remember it being mentioned here (though that may just me being dumb).



  • @morbiuswilters said:

    @Kittemon said:
    @ASheridan said:

    You could do what Google does every other site in the world has been doing since the end of the last millennium, and not actually link to the external sites at all. Look at their search pages, the results display the URL, but the link behind them is actually to another Google page which does whatever clearing up or final checking they need. Quite easy to add in your last visit entry and the link you've requested before sending the users browser to another site.

    This is probably least fraught with problems and most likely to work in all cases.

    FTFY. To be fair, this can't catch the case where the site is so obviously sucky that the user immediately hits the back button when they realize where they've ended up at.

    Seriously, do you people read before posting? This is for a Javascript web analytics program. He does not control the page. He has no server-side code.

    Yes, I read before posting, yet I don't recall blakeyrat ever actually explaining why he needed to do this. It's possible that it got lost in the midst of a blakeyrant. It's also possible that he only explained that part in a different thread altogether (edit: yup).

    Edit: I stand corrected! He did indeed say that it was for web analytics, from which I am to have inferred that it was for sites other than his own.

    @blakeyrat said:

    I'm trying to write a quality product here. I'm not going to feed rabbit shit to my clients and call it raisins.



  • @DaveK said:

    @Weps said:

    No, it's the 'don't know what this code does' attitude that costs the industry much, but apparently it's so normal to be a fuck up and spend time constantly in the debugger that it is even seen as being professional. Hilarious.

    You should know what your code is supposed to do.

    And you should also verify that it does.

    Testing can take care of 99% of that automatically for you, but it's always good to take a look under the bonnet and watch your code actually running.  I often do it the first couple of times through when I've added a big or tricky new chunk of code that's running for the first time.

    Mmm.. I missed the "constantly" bit - and I won't disagree with the concept that 20% kicking out low-quality code then 80% on the debugger to identify and iron out quirks is unprofessional (if that's Weps' original point).

    I've met several coders that are arrogant and blinkered to even entertain the notion that their code could be flawed, a kinda "debuggers are for pussies" and "it doesn't need testing - it WORKS!" culture... I probably tarnished Weps' professionals with the same brush. My bad on that front.

    On a side note, I've come across a coder that worked by the mantra "It's important for you to understand what it does; it's important for other coders to understand how it does it"and had a good attitude to documentation and design plans. He was the one that impressed upon me the importance of code legibility and maintainability, in the form of the "next developer is a raving psychotic" quip.



  • @Kittemon said:

    @morbiuswilters said:
    @Kittemon said:
    @ASheridan said:

    You could do what Google does every other site in the world has been doing since the end of the last millennium, and not actually link to the external sites at all. Look at their search pages, the results display the URL, but the link behind them is actually to another Google page which does whatever clearing up or final checking they need. Quite easy to add in your last visit entry and the link you've requested before sending the users browser to another site.

    This is probably least fraught with problems and most likely to work in all cases.

    FTFY. To be fair, this can't catch the case where the site is so obviously sucky that the user immediately hits the back button when they realize where they've ended up at.

    Seriously, do you people read before posting? This is for a Javascript web analytics program. He does not control the page. He has no server-side code.

    Yes, I read before posting, yet I don't recall blakeyrat ever actually explaining why he needed to do this. It's possible that it got lost in the midst of a blakeyrant. It's also possible that he only explained that part in a different thread altogether (edit: yup).

    Edit: I stand corrected! He did indeed say that it was for web analytics, from which I am to have inferred that it was for sites other than his own.

    @blakeyrat said:

    I'm trying to write a quality product here. I'm not going to feed rabbit shit to my clients and call it raisins.

    tl;dr: "No, I don't read before I post."



  • @Kittemon said:

    Edit: I stand corrected! He did indeed say that it was for web analytics, from which I am to have inferred that it was for sites other than his own.
    WTF?  Right in his original post he says that the problem is an app, written in Javascript, that needs to run on an iPad.  But it doesn't work properly on the iPad and he can't debug it because IOS devices have no Javascript debugger.  It has nothing to do with "web analytics" or "sites other than his own".



  • @Cassidy said:

    @DaveK said:

    @Weps said:

    No, it's the 'don't know what this code does' attitude that costs the industry much, but apparently it's so normal to be a fuck up and spend time constantly in the debugger that it is even seen as being professional. Hilarious.

    You should know what your code is supposed to do.

    And you should also verify that it does.

    Testing can take care of 99% of that automatically for you, but it's always good to take a look under the bonnet and watch your code actually running.  I often do it the first couple of times through when I've added a big or tricky new chunk of code that's running for the first time.

    Mmm.. I missed the "constantly" bit - and I won't disagree with the concept that 20% kicking out low-quality code then 80% on the debugger to identify and iron out quirks is unprofessional (if that's Weps' original point).

    It was. Is.

    @Cassidy said:

    I've met several coders that are arrogant and blinkered to even entertain the notion that their code could be flawed, a kinda "debuggers are for pussies" and "it doesn't need testing - it WORKS!" culture... I probably tarnished Weps' professionals with the same brush. My bad on that front.

    No harm done. Tho, I have to admit that I do have a tendency to say that my code works, but that should be understood quite differently.



  • @dargor17 said:

    @Weps said:

    because most of the time those professional developers KNOW what their code does.
     

    I don't know if it would be sadder if this was a troll attempt or if you were serious...

     

    Why? Its true. You wouldn't be much of a developer if you cannot even understand what a piece of code does, I mean that is the minimum requirement for being even somewhat of a programmer or scripter.

    Its failing to understand that there is a big bad world beyond the code and that decisions can have collossal consequences in that outside world that is a big source of WTF. But all of that is moot compared to the fact that decisions are usually made by people who care more about status or return on investment than about doing the right thing. You can never win.

    Code and tooling are such trivial things anyway, a real developer takes what he has and performes the wonders that everyone expects of him/her with it and ultimately will win someone else (consultant/architect) the pat on the back. After all - isn't that simply our job? To perform miracles?

     



  • I guess I should have kept also blakey's quote to keep the context... I'm not saying that developers aren't supposed to know what their code does, that would be ridicuolus. But it looked like Weps was saying that debuggers are useless because a developer should already know what happens at runtime and, well, that's a bit optimistic for non-trivial programs.

    I kind of agree with your post, but calling miracles something that is done every single day by hundreds of thousands of persons looks a bit... exagerated to me. Unless you're one of these guys  http://www.youtube.com/watch?v=_-agl0pOQfs



  • @dargor17 said:

    But it looked like Weps was saying that debuggers are useless because a developer should already know what happens at runtime and, well, that's a bit optimistic for non-trivial programs.

    I agree, people who say that simply don't know how to use them properly. Debuggers save immense amounts of time, if you know your way around them.


    but calling miracles something that is done every single day by hundreds of thousands of persons looks a bit... exagerated to me.

     

    It is exagerated :) But in a sense it is still true, because as a developer you tend to have to work under far from optimal conditions and have to work under people who think programming is the act of pushing buttons in stead of applying intelligence, reasoning and lots of effort. With all THAT, we still get the job done. Most of the time. To me its a miracle I manage to escape the disaster imposed by others so often.

     



  • @morbiuswilters said:

    tl;dr: "No, I don't read other threads that may not be remotely related to the one I'm posting in before I post."

    FTFY



  • @El_Heffe said:

    @Kittemon said:

    Edit: I stand corrected! He did indeed say that it was for web analytics, from which I am to have inferred that it was for sites other than his own.
    WTF? Right in his original post he says that the problem is an app, written in Javascript, that needs to run on an iPad. But it doesn't work properly on the iPad and he can't debug it because IOS devices have no Javascript debugger. It has nothing to do with "web analytics" or "sites other than his own".

    Apparently it has everything to do with that, but he didn't bother mentioning it until the fourth page of comments. Oh, and also in that other thread, which we all should have known to read for additional context prior to reading this one.



  • @dargor17 said:

    I'm not saying that developers aren't supposed to know what their code does, that would be ridicuolus.

    Nobody's saying that. It's a straw man made up by these idiots.

    @dargor17 said:

    But it looked like Weps was saying that debuggers are useless because a developer should already know what happens at runtime and, well, that's a bit optimistic for non-trivial programs.

    Which is basically exactly what Weps said, even if it wasn't what was intended.



  • @Kittemon said:

    Apparently it has everything to do with that, but he didn't bother mentioning it until the fourth page of comments.

    Who gives a shit? It's irrelevant to the WTF. He only had to offer the context because people wouldn't stop suggesting naive, unworkable solutions. The lack of that context does nothing to detract from the WTF. This isn't a help forum where Blakeyrat was asking for assistance but left out valuable context.



  • @Kittemon said:

    @morbiuswilters said:
    tl;dr: "No, I don't read other threads that may not be remotely related to the one I'm posting in before I post."

    FTFY

    Blakey said "Hey, that sever-side redirect thing won't work and here's a link to a previous thread where I explain why." Seven hours later you quote the same incorrect suggestion and then add condescending text that implies this is exactly what Blakey should have been doing all along. So, yes, your reply was idiotic flamebait.

    Edit: BTW, I'm not saying it made sense for Blakey to flame the guy who provided the initial suggestion. The point is, by the time you chimed in it had been well-established that server-side redirects will not work. So my conclusion is either: 1) you did not read the thread; or 2) you are an idiot. I went for #1 because I'm a nice guy.



  • Thank you.



  • @morbiuswilters said:

    @dargor17 said:
    I'm not saying that developers aren't supposed to know what their code does, that would be ridicuolus.

    Nobody's saying that. It's a straw man made up by these idiots.

    You two have clearly never worked in a national-security related field. Or sometimes with seriously commercially sensitive stuff as well. It's not uncommon to be given such small pieces to code that you genuinely have no idea what they do. Well, you know what actions are performed, but not why, and sometimes not even what their effect will be since that's handled by other code you don't get to see. Obviously it's not the easiest or most efficient way to do things, but sometimes people are most concerned with minimising the number of people working on building a system who will be able to say what was built at the end.



  • @fterfi secure said:

    You two have clearly never worked in a national-security related field.

    Actually, I'm the guy who wrote the code to generate Obama's fake birth certificate. It doesn't get more national security than that.

    Oh, and, uh, I probably wasn't supposed to tell anyone that.



  • @morbiuswilters said:

    Actually, I'm the guy who wrote the code to generate Obama's fake birth certificate.
    No, we just made you think you were. In fact that was the auto-calibration software for a baby-grater powered by burning puppies.



  • @morbiuswilters said:

    @dargor17 said:
    I'm not saying that developers aren't supposed to know what their code does, that would be ridicuolus.

    Nobody's saying that. It's a straw man made up by these idiots.

    @fterfi secure said:

    It's not uncommon to be given such small pieces to code that you genuinely have no idea what they do. Well, you know what actions are performed, but not why, and sometimes not even what their effect will be since that's handled by other code you don't get to see.

    But then it's not your code, is it? It's some routine/fragment that's (presumably) documented and you treat it as you would any API - as a black-box module. Provided your code supplies input in the correct fashion and you receive the expected results, it's not really a concern for the programmer what occurs within that supplied code.

    Perhaps I'm being a pedantic dickwad here, but although you have a valid point I don't see the relevance to the discussion[1] of a programmer knowing their own code well enough to explain its workings and behaviour.

    [1] one discussion of many, it seems.



  • @morbiuswilters said:

    @Kittemon said:
    Apparently it has everything to do with that, but he didn't bother mentioning it until the fourth page of comments.

    Who gives a shit? It's irrelevant to the WTF.

    It's relevant because blakey himself said that the very thing he was attempting to do probably would not work (because it's a stupid thing to do, and any sensible person would expect a browser to disallow it). Yet he attempted to do it anyway, then posted a blakeyrant because he had no way to debug what he was doing when it did, as expected, fail to work. I pointed out his apparent cognitive disconnect earlier on in the thread, on the assumption that he wouldn't have posted this particular blakeyrant if he hadn't been so driven to try something that he figured would not work even before he tried it. Did you read that part of the thread?

    @morbiuswilters said:

    @Kittemon said:
    @morbiuswilters said:
    tl;dr: "No, I don't read other threads that may not be remotely related to the one I'm posting in before I post."

    FTFY

    Blakey said "Hey, that sever-side redirect thing won't work and here's a link to a previous thread where I explain why."

    Actually, what he said was more along the lines of "ZOMG YOU ARE ALL IDIOTS WHY DIDN'T YOU THINK TO READ THIS THREAD FRIST". We're talking about blakeyrat after all.

    @morbiuswilters said:

    Seven hours later you quote the same incorrect suggestion and then add condescending text that implies this is exactly what Blakey should have been doing all along. So, yes, your reply was idiotic flamebait.

    Edit: BTW, I'm not saying it made sense for Blakey to flame the guy who provided the initial suggestion. The point is, by the time you chimed in it had been well-established that server-side redirects will not work.

    By the time I chimed in, I had already established in a previous comment that blakeyrat was well aware that what he was trying to accomplish was stupid. Did you read that part of the thread? I was merely adding a bit of humor to something that was no longer relevant to anyone. Blakeyrat doesn't come here for answers anyway, he comes here for humor; so, I don't see the problem.

    @morbiuswilters said:

    So my conclusion is either: 1) you did not read the thread; or 2) you are an idiot. I went for #1 because I'm a nice guy.

    False dilemma. Also, you are a liar.



  • @Kittemon said:

    It's relevant because blakey himself said that the very thing he was attempting to do probably would not work (because it's a stupid thing to do, and any sensible person would expect a browser to disallow it).

    No, I said an async HTTP request would be stupid and disallowed. That's not what I'm trying to do.

    @Kittemon said:

    Yet he attempted to do it anyway, then posted a blakeyrant because he had no way to debug what he was doing when it did, as expected, fail to work.

    I am trying to send a synchronous HTTP request (actually an image request), not an async XmlHttpRequest. Do you not understand the difference?

    There's no reason for those to be cancelled by the browser, because they do not (normally) slow the browsing experience for the user. The reason the request is cancelled is because of the way the browsers have implemented their unload... basically they dispose all the connections related to the last page before beginning the next, instead of letting the connections complete on their own. And as I pointed out in this thread, that is a reasonable and right design decision in most use-cases except mine-- in which case it would be nice to have another command or a XmlHttpRequest flag to be able to hint to the browser that I need the connection to remain open, despite page unload.

    @Kittemon said:

    By the time I chimed in, I had already established in a previous comment that blakeyrat was well aware that what he was trying to accomplish was stupid.

    You're either too stupid to know the difference between an async HTTP request and a synchronous HTTP request (even after I pointed it out in this very thread), or you're the one lying here.

    EDIT: Not only did I point it out in this thread, I addressed it specifically to you, Kittemon! Still going to try and claim you read the thread completely?


Log in to reply