Source control + Wait, what language?



  • @stratos said:

    @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. 

     

     

    Lucky you. Once you start working with systems of a certain age, you begin to see some weird shit that doesn't quite fit (or can be covered) with a nice framework, with no options but to tickle the guts of it. For what's worth, it's not specific to JavaScript/JScript. You see that in all programming languages or environments in one shape/form/manner or another :/



  • @blakeyrat said:

    [b]Or you could have your web server spit out the RSS, like 99.9% of them already do and ignore all that crap.[/b] If all you have is a hammer, everything looks like a nail.

    You are insane. You are proposing a simple and effective solution when the standard approach is to propose a complex one (with layers upon layers of XML) to pad one's resume. Who do you think you are, trying to break the status quo?

    @blakeyrat said:

    Similarly, if you live and breathe XML, suddenly XML becomes the solution to every problem.

    I don't believe in that gradiose vision.

     

    I share the sentiment. I worked on on someone's grandiose vision once. It worked well as a prototype, but apparently whoever crapped the grandiouse turd never thought about scalability. I got hard-to-refute profiling data showing that over 20% of memory and CPU resources were going to XML transformations... and that was just during off hours. Them numbers must have been too incomprehensible for the XML astronauts who preferred to blame the databases, code... even God, despite scientifically-collected evidence to the contrary. 

    XML astronauts, the scourge of the Earth.


  • Garbage Person

    @blakeyrat said:

    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.
    Aww, that's CUTE!

    I still see an alarming number of .html pages.



  • @Weng said:

    @blakeyrat said:

    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.
    Aww, that's CUTE!

    I still see an alarming number of .html pages.

    And?

    If your content is in HTML, then it's useless for other purposes. That applies whether or not you're using CSS. There might be some pie-in-the-sky idea out there that you can get the existing HTML pages, convert them to XHTML, then use XML transforms to "query" that data for the stuff you need, but have you ever seen that work in a real-world scenario? No, it would be quicker and easier to start the site from scratch and do it properly in the first place.

    BTW, another thing that's forgotten when "simplifying" HTML is backwards-compatibility. Sure, a browser can probably parse a XHTML file faster than a HTML file. But there are still millions of HTML pages out there, some of them with awful markup, that are not going away... ever. So what have you gained by XHTML-izing your browser? Well, more code paths to fail, I guess...



  • @luis.espinal said:

    @stratos said:

    @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. 

     

     

    Lucky you. Once you start working with systems of a certain age, you begin to see some weird shit that doesn't quite fit (or can be covered) with a nice framework, with no options but to tickle the guts of it. For what's worth, it's not specific to JavaScript/JScript. You see that in all programming languages or environments in one shape/form/manner or another :/

     

    What I did not have to experience was having to write javascript that needs to work in other peoples sites. Meaning that indeed frameworks are out of the question.  What you seem to be describing is being an asshole. You know the type, a shop has some old code which is still getting built on, but everyone just keeps repeating that it can't be saved and hack upon hack gets added increasing the complexity of the code, and no one ever does any refactoring/functional decompisition so the code never gets any better.

    The age of code doesn't make that any harder, just unwillingness or managers/clients who forbid doing it.



  • Well, you're lucky you didn't have to [url=http://forums.thedailywtf.com/forums/p/11221/220964.aspx]convert PHP to HTML[/url], the ultimate Columbus's Egg in web development ;-)



  • @stratos said:

    @luis.espinal said:

    @stratos said:

    @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. 

     

     

    Lucky you. Once you start working with systems of a certain age, you begin to see some weird shit that doesn't quite fit (or can be covered) with a nice framework, with no options but to tickle the guts of it. For what's worth, it's not specific to JavaScript/JScript. You see that in all programming languages or environments in one shape/form/manner or another :/

     

    What I did not have to experience was having to write javascript that needs to work in other peoples sites. Meaning that indeed frameworks are out of the question.  What you seem to be describing is being an asshole. You know the type, a shop has some old code which is still getting built on, but everyone just keeps repeating that it can't be saved and hack upon hack gets added increasing the complexity of the code, and no one ever does any refactoring/functional decompisition so the code never gets any better.

    Yep, you hit it in the head. It is pretty much that's what I'm describing. It is the state of affairs in the software industry because, as of yet (and unlike the physical engineering disciplines), 1) the software industry does not know how to build software methodically and 2) most software developers are only thought at school and work to create code but are never taugh a modicum of process management and engineering principles. Couple that with the typical ZOMG! I NEED THIS IMPLEMENTED YESTERDAY! LOLCATZ! pressure developers get, that's how it gets to deteriorate.

    Yep, it is an asshole. Moreover, work in this field long enough, and you will be bound to face/deal/survive it. I actually lost my job once for trying to reign in it. Until we develop a proper engineering discipline, this is how it's going to be... and we are not close to develop one unfortunately.

    The age of code doesn't make that any harder, just unwillingness or managers/clients who forbid doing it.

     

    Age of code does make it harder because, just as in the physical world, the 2nd law of thermodynamics also applies to software. Code doesn't exist in a vacuum because the problems it tries to address does not exist in a vacuum either. The business context in which it runs changes wrt to time. And with  it, code, ergo ages and deteriorates. As you clearly stated, there is to be a concerted effort to manage this change, this entropy. 

    Where I do disagree is in that it happens by management unwilligness. Sometimes you have operational constrains - you have no money to fund a full revamping, just enough to pay man-hours to put some lipstick on the pig. There is also management incompetence. There is no clear cost on software and cost of building hacks over hacks over old code is not clearly captured. 

    But most important, there is software developer incompetence. This one is the greatest contributing factor of them all. Not businesses, not customers. Software developers.



  • Our product (the JS that runs on other people's sites) was developed back when supporting browsers other than IE5.5 & IE6 simply didn't matter. Getting it to work on Safari for Mac was a real, real bear-- Firefox wasn't as bad. But yes, a year ago, I finally took the time to re-write the whole shebang from scratch, and now it runs in everything except IE5.5 and IE6. Hah!

    (To be fair, it might run in IE6. I just didn't ever QA that.)



  • Jesus, you faggots need to stop bitching and and arguing about this shit...all you need is a hierarchtical stack of objects.

     

    Duh.



  •  @sys said:

    Jesus, you faggots need to stop bitching and and arguing about this shit...all you need is a hierarchtical stack of objects.

     

    Duh.

    Hmm, a hierarchical stack of objects, what a revolutionary, fool-proof idea expressed in such a professional manner. Here, have a cookie.



  • @luis.espinal said:

     @sys said:

    Jesus, you faggots need to stop bitching and and arguing about this shit...all you need is a hierarchtical stack of objects.

     

    Duh.

    Hmm, a hierarchical stack of objects, what a revolutionary, fool-proof idea expressed in such a professional manner. Here, have a cookie.

     

    This has been mentioned a couple times like in this thread and at least one other.  Do I need <sarcasm></sarcasm> tags or something?  What the fuck.



  •  @sys said:

    @luis.espinal said:

     @sys said:

    Jesus, you faggots need to stop bitching and and arguing about this shit...all you need is a hierarchtical stack of objects.

     

    Duh.

    Hmm, a hierarchical stack of objects, what a revolutionary, fool-proof idea expressed in such a professional manner. Here, have a cookie.

     

    This has been mentioned a couple times like in this thread and at least one other.  Do I need <sarcasm></sarcasm> tags or something?  What the fuck.

    Newsflash, sarcasm goes both ways; wanna dish but can't take? Besides, since sarcasm is usually subjective and doesn't require the usage of teenage-wannabe-thug expletives, I'd say you actually do need them. Here is something that'll help you through the night.


     



  • @sys said:

    Jesus, you faggots need to stop bitching and and arguing about this shit...all you need is a hierarchtical stack of objects.

    Funny you should mention this. I was suffering through having to hear a pointless argument between an idiot dev and a PMP who thinks he can write code. After 30 minutes of back-and-forth retardation, the graphic designer stood up and reminded them that they could indeed solve their problem with a hierarchtical stack of objects. Please shoot me. Nobody deserves this on a Monday morning.


Log in to reply