I shop in a mall that has the Waterless urinals and regular stalls. The urinals work fine. The stalls do also, of course. The rest rooms are very heavily used.
This place is well-maintained, better than most, so that may be a factor.
Many toilets outside the US flush better than my low-flush in the US. It's about 6 years old. It works but I don't like it much.
Read my other replies to this article. Study CS and/or SE AND SOMETHING ELSE. OR GET A PHD. Read everything written by Paul Graham and by Norman Matloff. They're online.
The Career Journal article somebody found has it all in a nutshell:
"A guy who's been working on a 15-year-old application is a dinosaur."
While the article is about engineering they're including software in the bundle and the point, if you read between the lines, is that engineering and IT are no longer careers. They're a series of jobs for 10 or 15 years at most.
At some point the IT industry is going to move beyond Java and it will be the COBOL of the IT industry. Your current boss will hire a new grad to replace you when he wants to use it (or when he is replaced) instead of giving you a 3-month course in whatever the new system is.
However, there will be a warning: When they start to teach the new system in CS courses and it begins to edge out Java then the handwriting is on the wall. A year later there will be an avalanche as the CS and IT courses all race to the new system. Java jobs will start getting scarcer.
The new system might be any of:
Verificationist math or correctness tech
Ruby
.NET 2, 3, or 4
Something else
Listen for the buzz. It might be the buzzer signaling the end of your career.
Most IT shops and software development shops won't know if your code is "Genius level" -- only if it works.
If you do an ordinary-seeming thing in a new and better way only a few geeks who read your code will know, if anyone. If you invent a new thing to do and execute it adequately then you might get recognition.
And some coders are geniuses at thinking up the dumbest (simplest) way to do things so that they look so simple they get no recognition. I've seen guys quit over this.
Half the time somebody writes patentable code they don't even know it.
Nevertheless, there are people who turn in working systems on time and under budget consistently. Unless you read their code you don't always know what class of coder they are. And quite often nobody reads working code. Especially not IT managers.
If you want to encourage people to study IT:
Quit firing the ones you've got! And stop with the crap about only hiring young people. People don't go to college to get a 10-year career and burn out.
To any young person entering college I'd say: Major in CS or IT only if you also plan to get another degree -- get an MBA or go get a PH.d and be a researcher. A BS in CS/IT/SE isn't worth a warm bucket of spit. Okay, I'm being a little extreme. A degree in CS/IT/SE is worth a high school diploma.
And to the guy who was complaining about not being able to fill internships: That's because these are unpayed jobs, you dolt! Internships are appropriate for jobs that have a good future; you get paid in your future position as a judge or manager or senator. Internships in software development make only a little more sense than internships in street sweeping. That's because most techies are treated like street sweepers.
I actually worked for a company that had lost the entire source code for one of its main applications. They kept the binary and ran it as needed -- and just kept on working around it's problems. I was impressed with their creativity and shocked at their stupidity.
I have personally created several extremely reliable apps in embedded hard real time systems. It is not easy.
You don't do it by coding the way they tell you to in CS school (by and large). And you don't do it by coding the way many self-taught programmers hack it up. It's a combination of a good CS education and experience.
C has a lot of problems but the alternatives all have problems of their own. C++ is not straightforward and can lead to over-reliance on the heap. There are ways to work around this and people do it. C++ compilers are often not built to support machine-level coding. Take a look, for example, at Microsofts discussion of Windows Device Driver coding on their web site. The list of rules to use when trying to use C++ for device drivers is daunting.
Java is making inroads in some parts of the embedded world but just doesn't have what it takes to own it. We don't have a magic bullet yet.
The realistic approach is to partition the problem into a hard-real-time portion and a more normal portion, which usually contains the user interface. One good way of partitioning is to use separate CPU's for the real-time and the user interface. Perhaps another to manage storage, perhaps not.
Sensible real-time programming tries to do as little as possible in the real-time environment and as much as possible in the more normal environment, because coding is easier there. One result is that real-time coding can be repetitive and unimaginative. This is why I got out.
Yes, a simple free list can be called dynamic memory. And in either case, when you run out of memory you can lose data. With pre-allocation, you can experimentally determine how much memory you need and absolutely prevent running out of memory at a critical time. Instead, if you don't have enough memory, you get a nasty message at system boot. This is something you can fix in the lab before you inflict it on the customers. With more dynamic malloc/free, you might not discover the trouble until a problem happens in the field.
Furthermore, when using malloc/free, you use up time non-deterministically. Simple free lists are practically instantaneous and easily used in a multi-threaded environment. Indeed, one important use of "Dynamic" buffers is to send data from one thread to another. Multi-threaded malloc/free is a real bear. It has been done, but mainly on PC's and such. See this company for a good multi-threaded malloc/free library that is really good for PC applications. Hard real-time systems are a different matter. When you absolutely positively must take action in the next few microseconds you just have to do things differently.
Also, with malloc/free, your application is more likely to go belly up as you try to malloc more memory in the process of recovery. Or as you fail to free everything you need to in the process of recovery and leak memory.
With roll-your-own simple free lists it is much simpler to reclaim stuff and start the failed operation over. What I failed to mention is that I would always take a buffer/block from the free list and immediately insert it on some other linked list whose head I control. That way I have a very simple way to reorganize all of memory in constant time, by appending one list to the end of another -- in the worst case.
And, of course, it all depends. There are some embedded apps that can live with GC and some that can live with well-used malloc/free. But there are some that simply can't afford either one. Of these I wrote.
And if you read my post carefully, I wasn't banishing malloc/free to the woodpile, just to the beginning of operations: at system boot up or possibly at the opening of a port or other major connection. The core requirement is avoid having to malloc/free in alternation with handling interrupts -- one can simply run out of time. Think of coding a device driver, you don't malloc/free in between reading disk blocks, you pre-allocate a series of disk buffers and use them in turn.
No you fools -- HAARP caused the earthquake...
on
HAARP Amping It Up
·
· Score: 1
No you fools -- HAARP caused the earthquake in Pakistan that killed Osama bin Laden. Or didn't you notice the earthquake was in the exact same region where Osama was hiding?
And all that help from the US to Pakistan? That's just a team looking for Osama's body.
Publishing coding standards about comments, variable names, subscripts vs pointers and indentation tends to generate a document that dies after 3 months. A waste.
Have an opinion on all the above but some of your best coders might disagree. And might not agree with each other.
Code reviews for bugs, design, format, readability et cetera are a good way to improve code quality and application quality. Code reviews are very difficult to perform and very difficult to manage.
The idea of code reviews is so old that the older recommendations say you should review before your first compile! Find a newer guideline. The most important guidelines are about the emotions involved in code review. People can get very accusatory and very defensive.
One way of doing reviews is pair programming.
You will find as you go along that many managers and customers simply do not want higher quality if it delays first release. Chew on that.
Think in advance what you will do if you find you have a good coder that nevertheless produces code that is too hard for others to understand. Rather than canning somebody, perhaps you can help the coder to express him or herself more clearly, and help teach the other one to read code more effectively.
Code reading is a specific skill and may be a specific natural talent. That is, different from the skill and the natural talent of code writing.
Code reviewers, testers, managers, and others often have a legitimate need to add comments and/or links to production code ("bug #1234 crashed here", and "I don't understand this", and "90% of the cpu is used here"). It would be good if there were a version-control and text-editing system that allowed non-coders to add "yellow sticky notes" to code -- without breaking the build!
One big problem is handling the case when malloc returns 0 for no-more-memory. In hard real time there simply is no way to allow this to ever, ever happen.
One workaround is to only use malloc when the system boots or maybe when a port opens (free when the port closes). The benefit is you can guarantee you cover the case during testing. For buffers and messages malloc at system boot a fixed number of buffers of a fixed size. Put them on a simple free list. Use them by pulling one off the free list and free them by putting them back on the free list. Never un-malloc them with free() (typically).
The nature of hard real time is that you absolutely have to handle the worst case without terminating the application. You need to know you have enough memory before you let the box out of the factory, you cannot just discover during use you need more memory, and force the user to close the email program or the web browser.
The experience from which I speak is development of telecom and user productivity boxes (like printers) that had to operate completely unattended. If your box has a user always present to take corrective action then your constraints are probably relaxed. However, if you want appliance-level reliability your constraints are not relaxed. Malloc/free is for mere personal-computer-level reliability.
The original need for malloc/free was to save memory space. That becomes less important as memory gets cheaper.
...and within a few months I'd kick any MS user's ass with my $100 laptop
MS Windows and GUI's in general have allowed people who are experts in fields other than computer software to use computers and gain productivity.
While you are kicking the other guys butt he is making money by serving his customers or employers.
A lot of techies have worked very hard for very long to enable non-techies to benefit from computer automation and communications. Just as auto mechanics, designers, geologists and chemical engineers have worked long and hard to enable us to drive around in cars without knowing how to fix cars, refine oil, negotiate with Arabs or engineer mass production lines.
A good auto mechanic and expert driver may be able to drive around better, cheaper and faster than you can but you don't really care, you've got other things to do. That's how most of the world feels about us and they're right.
A good GUI can have an event in one window show up instantly in another window (or, in html, in another frame). For example, ordering a second or third item in one frame of a store would erase the "Total" field in the final-price frame while the server computes the new total with the new shipping costs. This is hard in Ajax because cross-frame scripting is, um, awkward.
Since the other final-price frame isn't in another thread it can't poll for the data, and the catalog buy-this frame can't reliably write to the other frame. That is, frame.document isn't generally available.
So you still have to post the change and draw a new screen or you risk having the displayed total be wrong for a while.
There might be an Ajax hack to do this but I haven't seen it.
Of course, you can write to a "div" in the same frame right away, but it doesn't have the UI features of a separate frame.
2 ** 128 ~= 3.40282366920938e+38, so there are about
10 to the 38th iPv6 addresses in the whole universe, at most. That's assuming the address space is used a maximum efficiency by the hairless apes who run it.
Googling around, we find there are about 10 to the 77th hydrogen atoms in the universe. Same universe. That's a lot larger. So there are (roughly) 10 39 atoms per address in the ipv6 system.
And we know the 10**77 number is right because it's on the web;-)
A quiet office without lots of jangling phones. Also -- don't have an office-wide loudspeaker in the ceiling! Truly nuts.
Extended periods of quiet concentration are the stuff of productivity. Minimize interruptions.
Good assignments are as good as promotions in motivating tech workers. Being offered a job maintaining or testing somebody else work is often perceived as an insult.
Too much flexibility in the choice of tools can create chaos, but too much restriction slows down the work.
Throwing away the code I wrote was the single biggest de-motivator I have ever experienced. Coders, especially, want their code out in the world, and used. This is really why the OSS movement exists.
Top flight equipment is actually inexpensive and a good motivator.
Techies respond well to human-oriented projects. There are a lot more applicants to projects that save human lives (medical equipment, bioinformatics) than to making yet another spreadsheet, internet router, or accounting package.
Since software is providing bits, not atoms, the costs of reproduction are nil. This means that it's all labor, no cost of materials. This is why MS is so profitable and why OSS can afford to be created. In the case of a software company, they decide to build what they think is profitable. In the case of OSS they build what is neat and cool or maybe useful. The government rarely does either one well.
Unlike the Darpanet => Internet thing, law and publically funded development today would be subject to meddling lobbyists like those from MS and Oracle. Would bankers insist on free banking software? Would Chicanos insist on bilingual software nationwide? If it's governmental, do we need a quota on the race and gender of the coders? Are the coders civil servants? If it had been this way in the past, would we have ever gone beyond COBOL? Or would we be using ADA?
On the other hand, it could have turned out more like NIH than the Post Office. And both government and private industry sequenced the genome.
If software were governmental, would the coders be able to get Congress to quit screwing around with Daylight Savings Time? Leave it be for a few years!
So what texts do you recommend we study to learn this stuff?
And how will using full Relational Algebra change our existing ORM systems? And will it impact the object model required of the programming languages? And are there examples of existing commercial software packages that offer a Relational Algebra interface? How much money could we make if we decided to build one?
And who could do it faster, MS, Oracle or Open Source?
Protecting people from getting killed isn't jingoism.
Wearing a flag is jingoistic. Or maybe this storeis. Unless it's a hippy wearing a flag. Then people assume it's anti-jingo, whatever that is. Okay, he might not be a hippy, just a slob. Whatever.
It's clear from experience, and from all the comments to this post, that the phrase "Premature Optimization" is an oxymoron when applied to the development of large database applications.
If we had been smart in the beginning we would have saved ourselves a lot of trouble by using the same language on the client-side as the server side. An improved Javascript could do anything that PHP could do and probably that Ruby could do.
The extra confusion and administrative overhead of using two or three languages (plus html, xml and css) on the same project slows it all down.
What's stunning is that the Netscape server products took exactly this approach but never caught on.
Javascript is the most popular programming language and also one of the slowest. No reason it can't be speeded up. I like ruby better but despair that the browser-makers will ever include it on the client side.
If the compilers were able to process Unicode, and would accept ≠ where we now type !=
Dang slashdot won't display the ≠ properly!
Then the text editors could then gradually migrate to converting != on input to ≠ in the text and displaying it. For instance, notepad on windows will display unicode properly. Most other editors will too,
like eclipse...
Slashdot Mirror
This place is well-maintained, better than most, so that may be a factor.
Many toilets outside the US flush better than my low-flush in the US. It's about 6 years old. It works but I don't like it much.
Read my other replies to this article. Study CS and/or SE AND SOMETHING ELSE. OR GET A PHD. Read everything written by Paul Graham and by Norman Matloff. They're online.
At some point the IT industry is going to move beyond Java and it will be the COBOL of the IT industry. Your current boss will hire a new grad to replace you when he wants to use it (or when he is replaced) instead of giving you a 3-month course in whatever the new system is.
However, there will be a warning: When they start to teach the new system in CS courses and it begins to edge out Java then the handwriting is on the wall. A year later there will be an avalanche as the CS and IT courses all race to the new system. Java jobs will start getting scarcer.
The new system might be any of:
- Verificationist math or correctness tech
- Ruby
- .NET 2, 3, or 4
- Something else
Listen for the buzz. It might be the buzzer signaling the end of your career.Exactly, Amen, you've hit the nail right on the head. An IT/CS degree by itself doesn't cut it. Experience may do it, depending.
If you do an ordinary-seeming thing in a new and better way only a few geeks who read your code will know, if anyone. If you invent a new thing to do and execute it adequately then you might get recognition.
And some coders are geniuses at thinking up the dumbest (simplest) way to do things so that they look so simple they get no recognition. I've seen guys quit over this.
Half the time somebody writes patentable code they don't even know it.
Nevertheless, there are people who turn in working systems on time and under budget consistently. Unless you read their code you don't always know what class of coder they are. And quite often nobody reads working code. Especially not IT managers.
If you want to encourage people to study IT: Quit firing the ones you've got! And stop with the crap about only hiring young people. People don't go to college to get a 10-year career and burn out.
To any young person entering college I'd say: Major in CS or IT only if you also plan to get another degree -- get an MBA or go get a PH.d and be a researcher. A BS in CS/IT/SE isn't worth a warm bucket of spit. Okay, I'm being a little extreme. A degree in CS/IT/SE is worth a high school diploma.
And to the guy who was complaining about not being able to fill internships: That's because these are unpayed jobs, you dolt! Internships are appropriate for jobs that have a good future; you get paid in your future position as a judge or manager or senator. Internships in software development make only a little more sense than internships in street sweeping. That's because most techies are treated like street sweepers.
I actually worked for a company that had lost the entire source code for one of its main applications. They kept the binary and ran it as needed -- and just kept on working around it's problems. I was impressed with their creativity and shocked at their stupidity.
Javascript on the server? I actually thought that went out with Netscape. What servers support javascript well?
You don't do it by coding the way they tell you to in CS school (by and large). And you don't do it by coding the way many self-taught programmers hack it up. It's a combination of a good CS education and experience.
C has a lot of problems but the alternatives all have problems of their own. C++ is not straightforward and can lead to over-reliance on the heap. There are ways to work around this and people do it. C++ compilers are often not built to support machine-level coding. Take a look, for example, at Microsofts discussion of Windows Device Driver coding on their web site. The list of rules to use when trying to use C++ for device drivers is daunting.
Java is making inroads in some parts of the embedded world but just doesn't have what it takes to own it. We don't have a magic bullet yet.
The realistic approach is to partition the problem into a hard-real-time portion and a more normal portion, which usually contains the user interface. One good way of partitioning is to use separate CPU's for the real-time and the user interface. Perhaps another to manage storage, perhaps not.
Sensible real-time programming tries to do as little as possible in the real-time environment and as much as possible in the more normal environment, because coding is easier there. One result is that real-time coding can be repetitive and unimaginative. This is why I got out.
Furthermore, when using malloc/free, you use up time non-deterministically. Simple free lists are practically instantaneous and easily used in a multi-threaded environment. Indeed, one important use of "Dynamic" buffers is to send data from one thread to another. Multi-threaded malloc/free is a real bear. It has been done, but mainly on PC's and such. See this company for a good multi-threaded malloc/free library that is really good for PC applications. Hard real-time systems are a different matter. When you absolutely positively must take action in the next few microseconds you just have to do things differently.
Also, with malloc/free, your application is more likely to go belly up as you try to malloc more memory in the process of recovery. Or as you fail to free everything you need to in the process of recovery and leak memory.
With roll-your-own simple free lists it is much simpler to reclaim stuff and start the failed operation over. What I failed to mention is that I would always take a buffer/block from the free list and immediately insert it on some other linked list whose head I control. That way I have a very simple way to reorganize all of memory in constant time, by appending one list to the end of another -- in the worst case.
And, of course, it all depends. There are some embedded apps that can live with GC and some that can live with well-used malloc/free. But there are some that simply can't afford either one. Of these I wrote.
And if you read my post carefully, I wasn't banishing malloc/free to the woodpile, just to the beginning of operations: at system boot up or possibly at the opening of a port or other major connection. The core requirement is avoid having to malloc/free in alternation with handling interrupts -- one can simply run out of time. Think of coding a device driver, you don't malloc/free in between reading disk blocks, you pre-allocate a series of disk buffers and use them in turn.
And all that help from the US to Pakistan? That's just a team looking for Osama's body.
Have an opinion on all the above but some of your best coders might disagree. And might not agree with each other.
Code reviews for bugs, design, format, readability et cetera are a good way to improve code quality and application quality. Code reviews are very difficult to perform and very difficult to manage.
The idea of code reviews is so old that the older recommendations say you should review before your first compile! Find a newer guideline. The most important guidelines are about the emotions involved in code review. People can get very accusatory and very defensive.
One way of doing reviews is pair programming.
You will find as you go along that many managers and customers simply do not want higher quality if it delays first release. Chew on that.
Think in advance what you will do if you find you have a good coder that nevertheless produces code that is too hard for others to understand. Rather than canning somebody, perhaps you can help the coder to express him or herself more clearly, and help teach the other one to read code more effectively.
Code reading is a specific skill and may be a specific natural talent. That is, different from the skill and the natural talent of code writing.
Code reviewers, testers, managers, and others often have a legitimate need to add comments and/or links to production code ("bug #1234 crashed here", and "I don't understand this", and "90% of the cpu is used here"). It would be good if there were a version-control and text-editing system that allowed non-coders to add "yellow sticky notes" to code -- without breaking the build!
One workaround is to only use malloc when the system boots or maybe when a port opens (free when the port closes). The benefit is you can guarantee you cover the case during testing. For buffers and messages malloc at system boot a fixed number of buffers of a fixed size. Put them on a simple free list. Use them by pulling one off the free list and free them by putting them back on the free list. Never un-malloc them with free() (typically).
The nature of hard real time is that you absolutely have to handle the worst case without terminating the application. You need to know you have enough memory before you let the box out of the factory, you cannot just discover during use you need more memory, and force the user to close the email program or the web browser.
The experience from which I speak is development of telecom and user productivity boxes (like printers) that had to operate completely unattended. If your box has a user always present to take corrective action then your constraints are probably relaxed. However, if you want appliance-level reliability your constraints are not relaxed. Malloc/free is for mere personal-computer-level reliability.
The original need for malloc/free was to save memory space. That becomes less important as memory gets cheaper.
MS Windows and GUI's in general have allowed people who are experts in fields other than computer software to use computers and gain productivity.
While you are kicking the other guys butt he is making money by serving his customers or employers.
A lot of techies have worked very hard for very long to enable non-techies to benefit from computer automation and communications. Just as auto mechanics, designers, geologists and chemical engineers have worked long and hard to enable us to drive around in cars without knowing how to fix cars, refine oil, negotiate with Arabs or engineer mass production lines.
A good auto mechanic and expert driver may be able to drive around better, cheaper and faster than you can but you don't really care, you've got other things to do. That's how most of the world feels about us and they're right.
Since the other final-price frame isn't in another thread it can't poll for the data, and the catalog buy-this frame can't reliably write to the other frame. That is, frame.document isn't generally available.
So you still have to post the change and draw a new screen or you risk having the displayed total be wrong for a while.
There might be an Ajax hack to do this but I haven't seen it.
Of course, you can write to a "div" in the same frame right away, but it doesn't have the UI features of a separate frame.
Googling around, we find there are about 10 to the 77th hydrogen atoms in the universe. Same universe. That's a lot larger. So there are (roughly) 10 39 atoms per address in the ipv6 system.
And we know the 10**77 number is right because it's on the web ;-)
Extended periods of quiet concentration are the stuff of productivity. Minimize interruptions.
Good assignments are as good as promotions in motivating tech workers. Being offered a job maintaining or testing somebody else work is often perceived as an insult.
Too much flexibility in the choice of tools can create chaos, but too much restriction slows down the work.
Throwing away the code I wrote was the single biggest de-motivator I have ever experienced. Coders, especially, want their code out in the world, and used. This is really why the OSS movement exists.
Top flight equipment is actually inexpensive and a good motivator.
Techies respond well to human-oriented projects. There are a lot more applicants to projects that save human lives (medical equipment, bioinformatics) than to making yet another spreadsheet, internet router, or accounting package.
Unlike the Darpanet => Internet thing, law and publically funded development today would be subject to meddling lobbyists like those from MS and Oracle. Would bankers insist on free banking software? Would Chicanos insist on bilingual software nationwide? If it's governmental, do we need a quota on the race and gender of the coders? Are the coders civil servants? If it had been this way in the past, would we have ever gone beyond COBOL? Or would we be using ADA?
On the other hand, it could have turned out more like NIH than the Post Office. And both government and private industry sequenced the genome.
If software were governmental, would the coders be able to get Congress to quit screwing around with Daylight Savings Time? Leave it be for a few years!
They ought to know.
You'll be working for Indian wages as a software tester in either case.
And how will using full Relational Algebra change our existing ORM systems? And will it impact the object model required of the programming languages? And are there examples of existing commercial software packages that offer a Relational Algebra interface? How much money could we make if we decided to build one?
And who could do it faster, MS, Oracle or Open Source?
And how do we justify buying it to management?
Wearing a flag is jingoistic. Or maybe this storeis. Unless it's a hippy wearing a flag. Then people assume it's anti-jingo, whatever that is. Okay, he might not be a hippy, just a slob. Whatever.
Planning for performance can be essential.
The extra confusion and administrative overhead of using two or three languages (plus html, xml and css) on the same project slows it all down.
What's stunning is that the Netscape server products took exactly this approach but never caught on.
Javascript is the most popular programming language and also one of the slowest. No reason it can't be speeded up. I like ruby better but despair that the browser-makers will ever include it on the client side.
By which I mean not only that the compilers would be able to compile UTF-8 files and so forth but recognize the unicode symbols as valid operators.
Dang slashdot won't display the ≠ properly!
Then the text editors could then gradually migrate to converting != on input to ≠ in the text and displaying it. For instance, notepad on windows will display unicode properly. Most other editors will too, like eclipse...