Source control + Wait, what language?


  • Garbage Person

    I finally received a rejection from this place, so I'm comfortable sharing this pile-o-wtf. My interview panel was made up of 3 individuals - the head of IT, the lead developer, and one random goon developer. They were all very proud of their credentials and for some reason thought it would be helpful to tell me all about them. They all had years and years of .net experience and degrees from prestigious universities.

     

    The interview was going great, all the way up until we got to the "do you have any questions for us" part. I like to get an idea of their process and culture (generally speaking, that's what I'll make my decision based upon - am I going to be driven positively insane or not), so I ask about that stuff.

    Me:  "Tell me a bit about your processes"
    Random developer: "Well, various people throughout the organization will find a need for a piece of software, and we write it for them."
    Me: (uh, that's not a process. I'd better break this up into short, easily digestible questions.)  "... How many developers will work on any given project?"
    Head of IT: "One."
    <some questions about office environment and development technologies here. Biggest WTF: Shared cubicles>
    Me: Do you use any source control?
    Lead developer: "... Source control? <looks at other developers, equally blank-faced>...."
    Me: "CVS, Subversion, SVN, Mercurial, Visual SourceSafe"
    Random developer: "Like SourceForge?"
    Me: ".... Uh, yeah. Sure."
    Random developer: "No, we don't use SourceForge."

     After that, I was prettymuch satisfied that I wasn't going to be coming back unless they offered me loads of money (which was a possibility, so I wasn't going to be TOO overt about it) and had them get on to the pencil-and-paper "skills test".I was assured that the test counted very little for 

     

    They're a .net shop with some random PHP and Perl applications floating around for support. Or at least that's what the description on the listing said, and they backed it up in the interview. They stuck me in a cubicle with some poor developer (who seemed to be serving as frontline helldesk, because during the 30 minutes I was sitting there, he reset at least four activedirectory passwords) and gave me a pile of paper. First question: "Write a VBScript to connect to a SQL Server and fill an array from a query, and then print the results."

    I've written maybe ten lines of VBScript in my ENTIRE LIFE. After googling for a few minutes, I still can't tell you conclusively whether or not you can even do what was asked of me in a non-shit manner.

    The entire test was in VBScript except one question on SQL - which asked me to do a certain task "using a subquery". For the life of me, I couldn't figure out what the hell they wanted me to subquery - so I just did it with a join.

    After my time had expired (with little over 1/2 of the test having my best guess at VBScript syntax and libraries penciled into the blank space), I asked the other guy in the cubicle whether the test was supposed to be in VBScript. "Yeah, we do everything in VBScript, but we're thinking about converting to .net. You probably just interviewed for that position."



  • @Worker bee said:

    Yeah, we do everything in VBScript, but we're thinking about converting to .net.
     

    So, they lied to you on the interview?

    But then again, if the words "source control" produce blank stares, maybe it wasn't lying per se.



  •  Source control? Is that something like pest control but for source code?



  • @Weng said:

    "Write a VBScript to connect to a SQL Server and fill an array from a query, and then print the results."

    I've written maybe ten lines of VBScript in my ENTIRE LIFE. After googling for a few minutes, I still can't tell you conclusively whether or not you can even do what was asked of me in a non-shit manner.

    From the first result of Google for VBScript+SQL+server the answer is Re: VBScript / SQL Server

    sub RecordLogon(sUsername,sComputername,sIP)

    dim sServer, sConn, oConn,oRS

    sServer="sqlservername"

    sConn="provider=sqloledb;data source=" & sServer & ";initial catalog=logoninfo"

    Set oConn = CreateObject("ADODB.Connection")

    oConn.Open sConn, "username", "secretpassword"

    Set oRS =CreateObject("ADODB.Recordset")

    sSQL="insert into logonoff(username,compname,ip,ontime) values('" & sUserName & "','" & sComputerName & "','" & sIP & "',getdate())"

    ors.open sSQL, oconn

    end sub

    You're welcome! But then again even though I have done heaps of VBScript I still had to google it. On the other hand it doesn't sound like a place you would want to work anyway


  • Garbage Person

    I really could have gotten through life without knowing that. And that still doesn't put results into an 2d array, but instead a recordset object. Which means there's more arcane magic to be done (and hand-written into a hypothetical 2-inch block of page space)


  • Garbage Person

    @dhromed said:

    So, they lied to you on the interview?
    Yup. I guess they were otherwise having problems finding someone qualified to start a .net initiative without having written that in the listing.

     

    ... And I guess they found the one guy in the entire world both capable of such and able to write passable VBScript.

     



  • @Weng said:

    I really could have gotten through life without knowing that.

    I could write a book on all the computer related stuff that I wish I didn't know. But VBScript isn't that bad, although I do prefer JScript (which is NOT Javascript), and basically I am a computer whore so if you want to pay me to do it I will.



  • @OzPeter said:

    JScript (which is NOT Javascript)
     

    Nitpick time!

    The differences, as I see it, are not remotely great enough to warrant such an partial-CAPS caveat. The are variations on implementations details that might produce minor problems that most practical usage never encounters.

    One such aspect is that, while the ECMA spec says that the keys  in objects/hashmaps have no inherent sequence, JScript will always output the keys in the same order they were added. In other engines, output sequence is based on luck*.

    If you're talking about ASP-JScript versus client-side javascript, then of course they use different standard objects and functions, and have different usages, but that still doesn't mean it's a wholly different language.

    Now, if you'd said "Java (which is NOT Javascript)", then you'd have a case.

     

    *) fairly dated intel. Not verified for all recent engines in all browsers. So, pinch of salt etc.



  • @Weng said:

    Lead developer: "... Source control? <looks at other developers, equally blank-faced>...."
    This is where the hair on the back of my neck would start to stand up. Realising that a company doesn't use something as basic as source control is like walking into a restaraunt and as a waiter exits the kitchen catching a glimpse of a chef with a stray dog in one hand and a butcher's knife on the other.



  • @DOA said:

    catching a glimpse of a chef with a stray dog in one hand and a butcher's knife on the other.
     

    What's wrong with dog steak?



  •  @DOA said:

    @Weng said:

    Lead developer: "... Source control? <looks at other developers, equally blank-faced>...."
    This is where the hair on the back of my neck would start to stand up. Realising that a company doesn't use something as basic as source control is like walking into a restaraunt and as a waiter exits the kitchen catching a glimpse of a chef with a stray dog in one hand and a butcher's knife on the other.

    They don't use SC : red flag. Interview over.

    They don't know what is SC : infrared flag. Drop a plasma grenade in the room and run for your life.



  • "We did say we needed people knowledeable in X, but we do everything in Y, we are just planning on maybe moving to X in some random future", is another common WTF that's as bad as not using SC.

    And since Y (in this case vbscript) is their cash cow, they'll either never move, or produce such disfunctional code when moving on that they'll break the company. I've been there.



  • @dhromed said:

    @OzPeter said:

    JScript (which is NOT Javascript)
     

    Nitpick time!

    The differences, as I see it, are not remotely great enough to warrant such an partial-CAPS caveat. The are variations on implementations details that might produce minor problems that most practical usage never encounters.

    One such aspect is that, while the ECMA spec says that the keys  in objects/hashmaps have no inherent sequence, JScript will always output the keys in the same order they were added. In other engines, output sequence is based on luck*.

    If you're talking about ASP-JScript versus client-side javascript, then of course they use different standard objects and functions, and have different usages, but that still doesn't mean it's a wholly different language.

    Now, if you'd said "Java (which is NOT Javascript)", then you'd have a case.

     

    *) fairly dated intel. Not verified for all recent engines in all browsers. So, pinch of salt etc.

    I meant JScript is NOT Javascript in the same manner that VBScript is NOT VB, and my experiences with JScript have nothing to do with ASP, but with the Windows scripting host and have nothing to do with browser based client side scripting either.



  • @OzPeter said:

    I meant JScript is NOT Javascript in the same manner that VBScript is NOT VB
     

    Google it.

    As explained by JavaScript guru Douglas Crockford in his talk entitled The JavaScript Programming Language on YUI Theater, "[Microsoft] did not want to deal with Sun about the trademark issue, and so they called their implementation JScript. A lot of people think that JScript and JavaScript are different but similar languages. That's not the case. They are just different names for the same language, and the reason the names are different was to get around trademark issues."

    And while I know wiki can be (very) wrong, all other hits seem to confirm this.



  • @b_redeker said:

    @OzPeter said:

    I meant JScript is NOT Javascript in the same manner that VBScript is NOT VB
     

    Google it.

    I don't have to, but for you I will: Differences


  • Garbage Person

    [quote user="Renan "C#" Sousa"]And since Y (in this case vbscript) is their cash cow, they'll either never move, or produce such disfunctional code when moving on that they'll break the company. I've been there.[/quote] Company?

    Government agency. Which is worse, because those CAN'T break - just consume infinite amounts of money.



  • @OzPeter said:

    @Weng said:

    I really could have gotten through life without knowing that.

    I could write a book on all the computer related stuff that I wish I didn't know. But VBScript isn't that bad, although I do prefer JScript (which is NOT Javascript), and basically I am a computer whore so if you want to pay me to do it I will.

    +1 for hey-didn't-I-do-this-already?



  • [quote user="Renan "C#" Sousa"] I've been there.[/quote] ...and you've... done *that* ? What a shame.



  • @OzPeter said:

    @b_redeker said:

    @OzPeter said:

    I meant JScript is NOT Javascript in the same manner that VBScript is NOT VB
     

    Google it.

    I don't have to, but for you I will: Differences
    Hm:
    The JavaScript and JScript syntax for square is the same. JScript is largely compatible with JavaScript. However, JScript includes some objects not currently supported by JavaScript, such as ActiveXObject, Enumerator, Error, Global, and VBArray. For more information about these objects, see the JScript Language Reference.

    On the surface, JavaScript and JScript syntax resembles Java syntax. This similarity is only superficial. The Java language was developed independently from both JavaScript and JScript and is not related to either.

    VBScript, on the other hand, is a subset of the Visual Basic programming language. Because of this, VBScript syntax is a subset of Visual Basic syntax and is often interchangeable with Visual Basic syntax.

    Not the most compelling of arguments.

     



  • @Weng said:

    Government agency. Which is worse, because those CAN'T break - just consume infinite amounts of money.

    Would that explain what I saw in one government department yesterday. IE 5 serving as a front end to screen-scraped AS400 CRUD screens, and Netscape 6 for web access. Oh, and the obligatory three or four bespoke applications that looked different enough from each other that they were surely from different vendors and a workflow mainly consisting of reading something displayed in one window and typing it into another (while remembering the appropriate two-digit or four-letter codes to switch forms).

    Sometimes I really really regret taking that sabbatical from development to be a professional end user for a while.





  • @OzPeter said:

    @Weng said:

    "Write a VBScript to connect to a SQL Server and fill an array from a query, and then print the results."

    I've written maybe ten lines of VBScript in my ENTIRE LIFE. After googling for a few minutes, I still can't tell you conclusively whether or not you can even do what was asked of me in a non-shit manner.

    From the first result of Google for VBScript+SQL+server the answer is Re: VBScript / SQL Server

    sub RecordLogon(sUsername,sComputername,sIP)
    dim sServer, sConn, oConn,oRS
    sServer="sqlservername"
    sConn="provider=sqloledb;data source=" & sServer & ";initial catalog=logoninfo"
    Set oConn = CreateObject("ADODB.Connection")
    oConn.Open sConn, "username", "secretpassword"
    Set oRS =CreateObject("ADODB.Recordset")
    sSQL="insert into logonoff(username,compname,ip,ontime) values('" & sUserName & "','" & sComputerName & "','" & sIP & "',getdate())"
    ors.open sSQL, oconn
    end sub

    You're welcome! But then again even though I have done heaps of VBScript I still had to google it. On the other hand it doesn't sound like a place you would want to work anyway

    Yay for SQL Injection!!!

    He asked for a non-shit manner.  VBScript is missing so many features that everything you write feels dirty and you pretty much have to invent a standard library from scratch to prevent the stench from permeating all of the code.  VBScript make VB6 seem modern.



  • @Watson said:

    Not the most compelling of arguments.
    Well given that the original argument was more over me using "NOT" vs "not" I think its a perfectly suitable argument.



  • @OzPeter said:

    @Watson said:
    Not the most compelling of arguments.
    Well given that the original argument was more over me using "NOT" vs "not" I think its a perfectly suitable argument.
    You could have also used the word "practically" or "essentially" instead of "NOT", but whatever.



  • @dhromed said:

    @OzPeter said:

    JScript (which is NOT Javascript)
     

    Nitpick time!

    The differences, as I see it, are not remotely great enough to warrant such an partial-CAPS caveat. The are variations on implementations details that might produce minor problems that most practical usage never encounters.

    One such aspect is that, while the ECMA spec says that the keys  in objects/hashmaps have no inherent sequence, JScript will always output the keys in the same order they were added. In other engines, output sequence is based on luck*.

    If you're talking about ASP-JScript versus client-side javascript, then of course they use different standard objects and functions, and have different usages, but that still doesn't mean it's a wholly different language.

    Now, if you'd said "Java (which is NOT Javascript)", then you'd have a case.

     

    *) fairly dated intel. Not verified for all recent engines in all browsers. So, pinch of salt etc.

    Try this little construct in IE and Firefox (gets me every time):

    var gebi = document.getElementById;
    gebi( "test_element" ); // Fails in everything but IE

    What FF does is somehow "detaches" the getElementById function from its parent object, so when it runs it gives you a nice little internal error I don't remember the details of at the moment. But it's not a normal JS exception, it's a script engine exception.

    I've never dug into the standards deep enough to figure out whether IE or FF is "correct" on this little construct (or even if the standards address it). I just got used to that gebi() construct back when we were an IE-only shop, and it drives me batty every time I write script for any other browser. Obviously the workaround is just to make gebi a normal function.



  • @blakeyrat said:

    @dhromed said:
    ...
    Try this little construct in IE and Firefox (gets me every time):

    var gebi = document.getElementById;
    gebi( "test_element" ); // Fails in everything but IE

    What FF does is somehow "detaches" the getElementById function from its parent object, so when it runs it gives you a nice little internal error I don't remember the details of at the moment. But it's not a normal JS exception, it's a script engine exception.

    I've never dug into the standards deep enough to figure out whether IE or FF is "correct" on this little construct (or even if the standards address it). I just got used to that gebi() construct back when we were an IE-only shop, and it drives me batty every time I write script for any other browser. Obviously the workaround is just to make gebi a normal function.

    Or, hmm, I dunno. Use a framework like everyone else and stop spending your time on fixing cross-browser JS problems because someone else has already solved them.



  • @stratos said:

    Or, hmm, I dunno. Use a framework like everyone else and stop spending your time on fixing cross-browser JS problems because someone else has already solved them.

    We don't have that option, since we don't (except in extremely rare cases) control the website. Our JS code is an add-on to existing websites that already have God knows what framework installed, meaning we'd either:

    1) Be stacking a framework on top of another framework, which is usually a BAD idea and reduces website performance to crap. Also, it would bloat our code by a significant amount
    2) Maintain a separate version of our code for each framework out there, which is a support and development nightmare

    The best solution in our case is just to learn how to write cross-browser JS. Keeps our code small, keeps it modular (so it'll plug in to almost any website with little/no redevelopment), keeps the namespace small (only one global object), keeps our clients happy.



  • @blakeyrat said:

    @stratos said:
    Or, hmm, I dunno. Use a framework like everyone else and stop spending your time on fixing cross-browser JS problems because someone else has already solved them.

    We don't have that option, since we don't (except in extremely rare cases) control the website. Our JS code is an add-on to existing websites that already have God knows what framework installed, meaning we'd either:

    1) Be stacking a framework on top of another framework, which is usually a BAD idea and reduces website performance to crap. Also, it would bloat our code by a significant amount
    2) Maintain a separate version of our code for each framework out there, which is a support and development nightmare

    The best solution in our case is just to learn how to write cross-browser JS. Keeps our code small, keeps it modular (so it'll plug in to almost any website with little/no redevelopment), keeps the namespace small (only one global object), keeps our clients happy.

     

    Fair enough, I'm fortunate enough that that's not a use-case i've had to experience, so it didn't pop into my mind. 



  • @stratos said:

    Fair enough, I'm fortunate enough that that's not a use-case i've had to experience, so it didn't pop into my mind.

    If only it would pop into the W3C's mind, we might get super-useful IE-only properties like readyState on all browsers. But... that's not going to happen. Even if the W3C cared about our company's use-case, it'd be overridden by their irrational hatred of IE.



  • @blakeyrat said:

    @stratos said:
    Fair enough, I'm fortunate enough that that's not a use-case i've had to experience, so it didn't pop into my mind.

    If only it would pop into the W3C's mind, we might get super-useful IE-only properties like readyState on all browsers. But... that's not going to happen. Even if the W3C cared about our company's use-case, it'd be overridden by their irrational hatred of IE.

    "irrational"?



  • @toth said:

    @blakeyrat said:
    @stratos said:
    Fair enough, I'm fortunate enough that that's not a use-case i've had to experience, so it didn't pop into my mind.

    If only it would pop into the W3C's mind, we might get super-useful IE-only properties like readyState on all browsers. But... that's not going to happen. Even if the W3C cared about our company's use-case, it'd be overridden by their irrational hatred of IE.

    "irrational"?

    Why else would they rename the innerText property which fit their own naming scheme perfectly and was already-implemented in the largest marketshare browser to "textContent"? No sane entity would do that.



  • @blakeyrat said:

    @toth said:
    @blakeyrat said:
    @stratos said:
    Fair enough, I'm fortunate enough that that's not a use-case i've had to experience, so it didn't pop into my mind.
    If only it would pop into the W3C's mind, we might get super-useful IE-only properties like readyState on all browsers. But... that's not going to happen. Even if the W3C cared about our company's use-case, it'd be overridden by their irrational hatred of IE.
    "irrational"?
    Why else would they rename the innerText property which fit their own naming scheme perfectly *and* was already-implemented in the largest marketshare browser to "textContent"? No sane entity would do that.
    I think he was suggesting that any hatred of IE was rational and warranted, not that they didn't hate IE.  I think your example is a rather clever way to make a browser retro-actively more non-standards-compliant, no irrationality necessary.



  • @Jaime said:

    I think he was suggesting that any hatred of IE was rational and warranted, not that they didn't hate IE.  I think your example is a rather clever way to make a browser retro-actively more non-standards-compliant, no irrationality necessary.

    Well, assuming the W3C's mission was specifically to fuck over Microsoft, then yes it was a rational move. On the other hand, if their mission statement was to standardize web development, then it's insane. That's my point-- or am I missing a sarcasm tag?



  • Yes, your sarcasm detector seems to be on the fritz today.



  • @blakeyrat said:

    No sane entity would do that.

    But we're not talking about a sane entity here; we're talking about the W3C.



  • @Jaime said:

    Yes, your sarcasm detector seems to be on the fritz today.

    Sorry. I had the fuzzy vague, "hm, is this sarcasm?" feeling, but that wasn't enough to prevent my stupid post.



  • @blakeyrat said:

    @toth said:
    @blakeyrat said:
    @stratos said:
    Fair enough, I'm fortunate enough that that's not a use-case i've had to experience, so it didn't pop into my mind.

    If only it would pop into the W3C's mind, we might get super-useful IE-only properties like readyState on all browsers. But... that's not going to happen. Even if the W3C cared about our company's use-case, it'd be overridden by their irrational hatred of IE.

    "irrational"?

    Why else would they rename the innerText property which fit their own naming scheme perfectly and was already-implemented in the largest marketshare browser to "textContent"? No sane entity would do that.

    Yes, I'll give you that one. But surely you're not going to claim that every IE fuckup, every annoying IE6 quirk is the result of the W3C trying to pull a fast one on MS, are you?



  • Having talked to a guy from the W3C xhtml workgroup (not ECMA, but still)
    Of course the guy I talked to doesn't reprisent them all, but I did get quite a good feeling of the underlying principles.

    They mostly look at a bigger picture, they don't care what browsers do or don't do.  Of course this is the whole reason we have HTML5 now, because the people who make browsers do rather care about browsers. But XHTML was supposed to be, and in a sense is, more then just a language that browsers can talk in. This is also the reason why the w3c has always had the rather vague "object" tag, instead of a video tag or canvas tag like html5.  They more or less create contextless black boxes in the xhtml, and as such defy the proposed purpose of xhtml. The point of which is to define content and context.

    Now the guy admitted that there was also some difference on opinion on that within the w3c, but the more academically inclined didn't like the idea one bit.

    Of course while the html5 crowd was louding the canvas and video element xhtml has had support for SVG since before 2000 probably. Just none of the browsers implemented it. (fast and correctly)

    Ok, somehwere I lost my point really quickly, so i'm just going to stop here



  • @stratos said:

    but the more academically inclined didn't like the idea one bit.

    That's exactly the problem. Letting academics design the web is like letting a physicist design a car's transmission.

    It's not some freakin' research project, it's a vital communication channel that is responsible for billions of dollars in economic transactions a day.

    Back when they started going on about "separate your content from your presentation!!!" I used to say to my more web standards-inclined friends: "we already do that, it's called a CMS."



  •  @blakeyrat said:

    Try this little construct in IE and Firefox (gets me every time):

    var gebi = document.getElementById;
    gebi( "test_element" ); // Fails in everything but IE


    Huh, I've never tried that. Just did now, and got smacked for trying to link my script to the native chrome, for what Firefox claims are for security reasons.

    I don't even know which standards apply in this case: it's not a DOM issue, because that's language-independent, and this is specifically JavaScript. But then, it's not JavaScript, because DOM isn't formally part of the language.



  • @Weng said:

    Me: "CVS, Subversion, SVN, Mercurial, Visual SourceSafe"

     

    I always thought that Subversion and SVN are the same thing?



  • @mol1111 said:

    @Weng said:

    Me: "CVS, Subversion, SVN, Mercurial, Visual SourceSafe"

     

    I always thought that Subversion and SVN are the same thing?


    He was trying to find a name the dumbasses recognize, so giving both the abbreviation and the full name of SVN was a good idea, as there's roughly 50/50 split between people who use the short and the full name.

    I doubt anyone ever use CVS's full name in speech.



  • In university there was this annoying guy who, whenever a web programming question caught is attention, would utter something similar to "Look it up on W3C schools..." or after doing a task "I found the answer on W3C schools..." :(@mol1111 said:

    @Weng said:

    Me: "CVS, Subversion, SVN, Mercurial, Visual SourceSafe"

     

    I always thought that Subversion and SVN are the same thing?

    Near enough for government work. (Which conveniently enough is what I do)



  • @blakeyrat said:

    @stratos said:
    but the more academically inclined didn't like the idea one bit.

    That's exactly the problem. Letting academics design the web is like letting a physicist design a car's transmission.

    It's not some freakin' research project, it's a vital communication channel that is responsible for billions of dollars in economic transactions a day.

    Back when they started going on about "separate your content from your presentation!!!" I used to say to my more web standards-inclined friends: "we already do that, it's called a CMS."

    So you are still using the font tag then?



  • @stratos said:

    So you are still using the font tag then?

    I haven't done web design since CSS got trendy.

    In any case, you're missing the point. I'm not arguing that CSS is bad or unnecessary, I'm arguing that we *already* separated content and presentation before CSS was even supported by browsers. What the eggheads who came up with CSS didn't realize is that *all* of the markup (regardless of how it's separated out) is presentation; content is in the database.

    So the reason for adding CSS, a completely new language with a completely new syntax and completely different commenting rules, all of which you now need to learn... was really a non-reason. It really helps that the CSS namespace collides with Javascript's, too, that was some excellent planning.



  • @blakeyrat said:

    @stratos said:
    So you are still using the font tag then?

    In any case, you're missing the point. I'm not arguing that CSS is bad or unnecessary, I'm arguing that we *already* separated content and presentation before CSS was even supported by browsers. What the eggheads who came up with CSS didn't realize is that *all* of the markup (regardless of how it's separated out) is presentation; content is in the database.

     

    HTML doesn't care if the content came from a database from a XSLT transformation or someone who typed it out. You have to look at it in and on itself. 

    Secondly, not all markup is presentation. A xhtml file is a web-friendly container of data with context attached. Add a CSS file and a browser can display a website. Add a few XSLT rules and it can generate a RSS file. Other applications can read the file and understand the structure, if you add rdf you can even define deeper relationships.

    The idea that the web is just websites and that xhtml should be meant for just presentation is simply too shallow put nicely.  



  • Or you could have your web server spit out the RSS, like 99.9% of them already do and ignore all that crap. If all you have is a hammer, everything looks like a nail. Similarly, if you live and breathe XML, suddenly XML becomes the solution to every problem.

    I don't believe in that gradiose vision.



  • @Watson said:

     @blakeyrat said:

    Try this little construct in IE and Firefox (gets me every time):

    var gebi = document.getElementById;
    gebi( "test_element" ); // Fails in everything but IE


    Huh, I've never tried that. Just did now, and got smacked for trying to link my script to the native chrome, for what Firefox claims are for security reasons.

    I don't even know which standards apply in this case: it's not a DOM issue, because that's language-independent, and this is specifically JavaScript. But then, it's not JavaScript, because DOM isn't formally part of the language.

     

    The reason is probably the way JavaScript determines the value of "this". In the call to gebi, "this" is window, not document. I guess Firefox complains because gebi would access the chrome-DOM, but there is no such thing in IE, so it does not matter.

    Try this little test script. Every invocation of tst should print something different.

    function tst(){ alert(this); }

    tst();

    var arr = [1, 2, 3];
    arr.asdf = tst;
    arr.asdf();

    document.asdf = tst;
    document.asdf();

    document.asdf.call(arr);

    String.prototype.asdf = tst;
    "foo".asdf();


  • @OzPeter said:

    @Weng said:

    "Write a VBScript to connect to a SQL Server and fill an array from a query, and then print the results."

    I've written maybe ten lines of VBScript in my ENTIRE LIFE. After googling for a few minutes, I still can't tell you conclusively whether or not you can even do what was asked of me in a non-shit manner.

    From the first result of Google for VBScript+SQL+server the answer is Re: VBScript / SQL Server

     

    sub RecordLogon(sUsername,sComputername,sIP)
    dim sServer, sConn, oConn,oRS
    sServer="sqlservername"
    sConn="provider=sqloledb;data source=" & sServer & ";initial catalog=logoninfo"
    Set oConn = CreateObject("ADODB.Connection")
    oConn.Open sConn, "username", "secretpassword"
    Set oRS =CreateObject("ADODB.Recordset")
    sSQL="insert into logonoff(username,compname,ip,ontime) values('" & sUserName & "','" & sComputerName & "','" & sIP & "',getdate())"
    ors.open sSQL, oconn
    end sub

    You're welcome! But then again even though I have done heaps of VBScript I still had to google it. On the other hand it doesn't sound like a place you would want to work anyway

    I'm finding it hard to believe that nobody even noticed that this is doing an INSERT and not a SELECT.  This code is a WTF of its own.  There is no reason to create a recordset object when the query doesn't even return data.

    The correct way to execute that query (is there really a correct way though with it being vulnerable to injection?) would be to remove oRS from the dim line, remove the Set oRS line, and change the ors.open line to oConn.Execute sSQL



  • @smbarbour said:

    @OzPeter said:

    @Weng said:

    "Write a VBScript to connect to a SQL Server and fill an array from a query, and then print the results."

    I've written maybe ten lines of VBScript in my ENTIRE LIFE. After googling for a few minutes, I still can't tell you conclusively whether or not you can even do what was asked of me in a non-shit manner.

    From the first result of Google for VBScript+SQL+server the answer is Re: VBScript / SQL Server

     

    sub RecordLogon(sUsername,sComputername,sIP)
    dim sServer, sConn, oConn,oRS
    sServer="sqlservername"
    sConn="provider=sqloledb;data source=" & sServer & ";initial catalog=logoninfo"
    Set oConn = CreateObject("ADODB.Connection")
    oConn.Open sConn, "username", "secretpassword"
    Set oRS =CreateObject("ADODB.Recordset")
    sSQL="insert into logonoff(username,compname,ip,ontime) values('" & sUserName & "','" & sComputerName & "','" & sIP & "',getdate())"
    ors.open sSQL, oconn
    end sub

    You're welcome! But then again even though I have done heaps of VBScript I still had to google it. On the other hand it doesn't sound like a place you would want to work anyway

    I'm finding it hard to believe that nobody even noticed that this is doing an INSERT and not a SELECT.  This code is a WTF of its own.  There is no reason to create a recordset object when the query doesn't even return data.

    The correct way to execute that query (is there really a correct way though with it being vulnerable to injection?) would be to remove oRS from the dim line, remove the Set oRS line, and change the ors.open line to oConn.Execute sSQL

    You have only polished a small part of that turd.  If you can't see more than 1 WTF per line, then you aren't trying.  As for the injection vulnerability, just parameterize the statement.


  • @Jaime said:

    @smbarbour said:

     I'm finding it hard to believe that nobody even noticed that this is doing an INSERT and not a SELECT.  This code is a WTF of its own.  There is no reason to create a recordset object when the query doesn't even return data.

    The correct way to execute that query (is there really a correct way though with it being vulnerable to injection?) would be to remove oRS from the dim line, remove the Set oRS line, and change the ors.open line to oConn.Execute sSQL

    You have only polished a small part of that turd.  If you can't see more than 1 WTF per line, then you aren't trying.  As for the injection vulnerability, just parameterize the statement.
    Well, there's only so much polish you can do to VBScript (hence why there is no native way to use VBScript within .NET apps other than to do ActiveX Interop).

    I'm just surprised that no one else pointed out that it wasn't selecting data (and therefore doesn't meet the criteria for task it was posted for).  There is a relatively flawless line (given the language anyway) that contains no bastardized Hungarian notation or poor coding practices:  "end sub" (even if it should be capitalized)


Log in to reply