Well there's your problem - or at least a good part of it.
You should code your applications to work with a compliant rendering model first of all. They you use CSS workarounds to cater for IE6's (or whoever's) broken rendering model. It's actually much easier and saves loads of grief in the long run.
Coding for IE6 and having your app break in a compliant browser (IE7 is 'almost' compliant) is just unforgivable.
IE6's rendering is borked for sure, but it's not so bad that you need to write app code specifically for it. Simple design, clean markup and a few conditional CSS hacks can make an app work with just about any browser.
ASP.Net is a way of implementing rich web apps WITHOUT having ActiveX enabled. That is one of the major plus points!
Sounds like 'where you work' doesn't have a clue, or has developed/bought apps that need ActiveX components to work at all. It has nothing to do with.NET.
In what way does IE7 break moodle - my wife is using Moodle all day long, using IE7 ???
I used to work for IBM on the MVS (now z/os) operating system. At the time it was all written in s/370 assembler, but got rewritten in PL/S (a cousin of PL/I but with lower-level functions like direct register/memory access).
I spent 3 years of my life (mid to late 80's) refactoring the MVS operating system. It was a mammoth exercise, and exacting too. There were 28 of us on the team, all top IBM sysprogs, based in the US (Armonk NY) and UK (Portsmouth). We had 5 IBM 3090-4 mainframes in various states of disaster while we carefully recreated decades of s/370 OS code.
It was a bit like archeology. You analyzed and pealed away layer after layer of BXLE and MVCL instructions (mostly uncommented) and tried to grasp what the original programmer's intention was. There was self-modifying code in some modules (changing a BR branch destination!) and some of the code was actually lost, and only available on microfiche!
A lot of folks here just don't understand what 'REFACTORING' means.
Wikki says:
"A code refactoring is any change to a computer program's code which improves its readability or simplifies its structure without changing its results."
It has nothing to do with the size source code or the functionality of the program.
A properly refactored program will have the exact same characteristics and bugs as the original.
It seems to me like doing a quick makeover as opposed to getting it right the first time around.
In my experience, and I don't thing I'm a coding God or anything, most code is generated by idiots (or to be kind, people who just don't understand the task at hand).
If the design of an application is fubared from the start, you can't refine the mistakes out of the result.
You need to understand the application requirement and code correctly through the entire process. There's no going back.
The code that runs most of the world as we know it is pig-ugly. But it doesn't matter because it works, day-in, day-out. Now I'm not advocating ugly code (I try to make mine as pretty as I can) but the fact is, ugly code can be workable and efficient.
There seems to be a mindset here that only beautiful, elegant code can do the job. Not so!
By all means refactor the code you're working on but please leave working production code alone!
Why refactor?
1) Too much time on your hands 2) Big Ego - you can do what the original programmer did better 3) Someone has a ton of money to waste and some of it is on programming
I've seen refactoring in action - Boy! have I seen it!!
The blatant obnoxiousness of most (yes, MOST) people today means that we'll have to watch their mindless crap as well as listen to it.
If we don't like it we'll be labeled 'old farts'. Welcome to the brave new world!
Re:We need this type of thing done in the classroo
on
Hand-Made Vacuum Tubes
·
· Score: 1
errm, sorry - was that a rebuff of some kind?
Completely went over my head if it was?
I wasn't commenting on what the OP said, but what you said.
Re:We need this type of thing done in the classroo
on
Hand-Made Vacuum Tubes
·
· Score: 1
God what a fucking stupid comment.
Ok, I know this is Slashdot and stupid comments abound, but there's a limit, really!
Vacuum tubes are a perfect illustration of electronic amplification. Far simpler to grasp and observe in action than semiconductor devices. They have unique and subtle characteristics which can't be replicated by transistors.
This is equivalent to slopping out pigs a hundred years ago and useless to "99% of students" ?
That little movie is really one of the best things I've ever seen on the net.
The dedication, the craft. The art of it all.
I'd hate to think how much one of these would cost. Probably their not for sale anyway, which is cool. They look fairly low-power devices so unsuitable for audio power amps where valves (tubes) are king. The application shown is as a detector/demodulator in a very retro TRF radio (I think) radio. Brilliant!
These valves/tubes stand alone as sublime little works of art.
I think that every teenage case-modder who thinks they are "leet" should watch this and cry into their Cheetos.
As if it isn't bad enough that brain-dead shit-heads can force their choice 'music' upon us via 1000 Watt car audio system, now we can look forward to them projecting Goatse.cx and Tubgirl on any available surface.
I think we should stop technology now. I've had enough.
Before corporate America invades, and it's Wendys, Burger King, McDonalds and Starbucks on every street in Habana.
For those of you that have never been to Cuba, it really is a unique place.
Not for much longer, I fear.
In the UK, the government certainly CAN snoop on your data if they want to.
q.v. The Regulation of Invistigatory Powers Bill of 2000
(http://www.parliament.the-stationery-office.co.uk/pa/ld199900/ldbills/061/2000061.htm)
OMG!
"a wave of FireFox user coming!"
Ugh! Pass the Kleenex.
>>Screw HTML and CSS standards compliance; the only thing I'm holding out for is sweet, sweet 24-bit PNG support.
I think we can safely say that you're in the minority buddy.
Well there's your problem - or at least a good part of it.
You should code your applications to work with a compliant rendering model first of all. They you use CSS workarounds to cater for IE6's (or whoever's) broken rendering model. It's actually much easier and saves loads of grief in the long run.
Coding for IE6 and having your app break in a compliant browser (IE7 is 'almost' compliant) is just unforgivable.
IE6's rendering is borked for sure, but it's not so bad that you need to write app code specifically for it. Simple design, clean markup and a few conditional CSS hacks can make an app work with just about any browser.
>>If you have paid no heed to standards or alternative browsers, it's trivially simple to make a site that breaks on IE7.
Yes, that's exactly what I meant: a pretty damn bad application.
Pardon me, but... Bullshit!
.NET.
ASP.Net is a way of implementing rich web apps WITHOUT having ActiveX enabled. That is one of the major plus points!
Sounds like 'where you work' doesn't have a clue, or has developed/bought apps that need ActiveX components to work at all. It has nothing to do with
In what way does IE7 break moodle - my wife is using Moodle all day long, using IE7 ???
>>My company has a few dozen internal applications which fail when using them on IE7.
They must be pretty damn bad applications in the first place if moving from IE6 to IE7 'breaks' them!
How does IE7 break them?
Yes I know that replicating bugs is not a virtue, but strictly speaking, refactoring should neither introduce bugs nor eliminate them.
Beautifying code is a subjective business.
I used to work for IBM on the MVS (now z/os) operating system. At the time it was all written in s/370 assembler, but got rewritten in PL/S (a cousin of PL/I but with lower-level functions like direct register/memory access).
I spent 3 years of my life (mid to late 80's) refactoring the MVS operating system. It was a mammoth exercise, and exacting too. There were 28 of us on the team, all top IBM sysprogs, based in the US (Armonk NY) and UK (Portsmouth). We had 5 IBM 3090-4 mainframes in various states of disaster while we carefully recreated decades of s/370 OS code.
It was a bit like archeology. You analyzed and pealed away layer after layer of BXLE and MVCL instructions (mostly uncommented) and tried to grasp what the original programmer's intention was. There was self-modifying code in some modules (changing a BR branch destination!) and some of the code was actually lost, and only available on microfiche!
Now that's refactoring!
I've fixed plenty of ugly code in my time - and learned from it too.
Rather that turning my nose up at it, I tried to understand the intention of the original programmer. Sometimes I learned a trick or two.
A lot of folks here just don't understand what 'REFACTORING' means.
Wikki says:
"A code refactoring is any change to a computer program's code which improves its readability or simplifies its structure without changing its results."
It has nothing to do with the size source code or the functionality of the program.
A properly refactored program will have the exact same characteristics and bugs as the original.
Kids nowadays!
Do you mean by that that your refactoring reduced reportable errors? I so, I salute you Sir!
Thing is, REFACTORING should exactly replicate the original, bugs and all.
You were most fortunate, and no doubt you were the guy doing the refactoring in question.
Stick around a while and see what happens when some asshat 'refactors' your code and you are called in to clean up the mess.
How is it better?
It seems to me like doing a quick makeover as opposed to getting it right the first time around.
In my experience, and I don't thing I'm a coding God or anything, most code is generated by idiots (or to be kind, people who just don't understand the task at hand).
If the design of an application is fubared from the start, you can't refine the mistakes out of the result.
You need to understand the application requirement and code correctly through the entire process. There's no going back.
Dan,
Yes, but that's more like encapsulation than refactoring.
I totally agree that complex functions should be contained in a 'black box' with well-defined interfaces (like your big 202k block of code).
Absolutely Hal
The code that runs most of the world as we know it is pig-ugly. But it doesn't matter because it works, day-in, day-out. Now I'm not advocating ugly code (I try to make mine as pretty as I can) but the fact is, ugly code can be workable and efficient.
There seems to be a mindset here that only beautiful, elegant code can do the job. Not so!
...breaking working code!
By all means refactor the code you're working on but please leave working production code alone!
Why refactor?
1) Too much time on your hands
2) Big Ego - you can do what the original programmer did better
3) Someone has a ton of money to waste and some of it is on programming
I've seen refactoring in action - Boy! have I seen it!!
And bury them deep.
How this can be compared to McConnell's epic(s) I don't know.
I thoroughly agree.
The blatant obnoxiousness of most (yes, MOST) people today means that we'll have to watch their mindless crap as well as listen to it.
If we don't like it we'll be labeled 'old farts'. Welcome to the brave new world!
errm, sorry - was that a rebuff of some kind?
Completely went over my head if it was?
I wasn't commenting on what the OP said, but what you said.
God what a fucking stupid comment.
Ok, I know this is Slashdot and stupid comments abound, but there's a limit, really!
Vacuum tubes are a perfect illustration of electronic amplification. Far simpler to grasp and observe in action than semiconductor devices. They have unique and subtle characteristics which can't be replicated by transistors.
This is equivalent to slopping out pigs a hundred years ago and useless to "99% of students" ?
The guy is a genius and nut-case!
That little movie is really one of the best things I've ever seen on the net.
The dedication, the craft. The art of it all.
I'd hate to think how much one of these would cost. Probably their not for sale anyway, which is cool. They look fairly low-power devices so unsuitable for audio power amps where valves (tubes) are king. The application shown is as a detector/demodulator in a very retro TRF radio (I think) radio. Brilliant!
These valves/tubes stand alone as sublime little works of art.
I think that every teenage case-modder who thinks they are "leet" should watch this and cry into their Cheetos.
As if it isn't bad enough that brain-dead shit-heads can force their choice 'music' upon us via 1000 Watt car audio system, now we can look forward to them projecting Goatse.cx and Tubgirl on any available surface.
I think we should stop technology now. I've had enough.