UML is a design system. It can be used to document the application; however, the point was that code is difficult to understand without documentation. Since UML would be the missing documentation, its use would invalidate the myth.
What tools does Linux have for creating regression tests?
I use dejagnu when I'm coding C, or junit when coding Java. I understand that Perl has a similar framework.
Debian and Gentoo does this well. I'm not certain how the others compare.
But these are distributions. In order to get your software into the distributions, you need to have a following. You won't have a following unless you have some way for your users to get your software; this requires some sort of packaging.
But it seems to imply a next-try improvement. In reality, this will generaly be a slow improvement; it is very rare to go from complete, undisciplined slob to perfectly clean and maintainable style without a few steps in between.
How many times have you seen a project that says "Here's our ultra-cool project. Just grab the files from CVS and build". No mention of the dependencies (the mailing list will tell you that you need libfoo-1.2; we depend on a specific bug in 1.2, so 1.2.1, which fixes the bug, will break our app).
Or "Here's our ultra-cool project. It's only a small app right now, but when we get people working on it, it'll do your dishes, write your thesis, and mow the lawn, with 3-D graphics and 6.1 surround sound."
What most developers don't think is "Hey, I didn't contribute anything. Nobody I know has contributed anything. Why will my project be any different?"
Myth 3: Reading code
I've tried to read large bodies of code before. It's damn hard, even if it is documented. And when it isn't documented, your beginning developers don't have a chance.
Myth 4: Packaging
Um...duh? Of course it needs to be properly packaged. And dependency lists? If someone can't get it to compile, they definitely won't use it.
Myth 5: Start from scratch
Don't start from scratch if the code isn't clean. Make new code clean, and go back to clean up existing code. Make sure you have those regression tests ready.
Myth 7: Perfection
Developers are humans. Humans are fallible. I'll make a perfect program - when Bullwinkle pulls a rabbit out of his hat.
Myth 8: Ignore warnings
If the warnings were ignorable, they wouldn't be there. My profs would take marks off if you got warnings in compilation, unless your documentation explained exactly why you let the warning stand (and it had better be a good reason).
Why are they allowed to combine dissimmilar items on the same bill? Each law (and thus bill) should have a single focus, and any clause that is not related to this focus should be stricken. Whether it is stricken by the House and Senate before passing, or by the courts when someone gets charged, these submarine laws should be destroyed.
The process happens at 5-minute intervals. It's possible that this could interfere with what the tech was doing. It could, therefore, be standard policy to disable the update before reconfiguring the settings.
I don't know which cave it was, only what my wife has told me about it (she's one of those blue-spacesuit people that works with ebola). IIRC, there were multiple caves, just as there are multiple strains of ebola.
They don't know yet. It's generally suspected to be some kind of bat, but it's not known for sure.
There was a cave in the Congo that seemed to be the centre of several outbreaks. However, it was being flooded, so they had to take samples immediately. Unfortunately, a civil war prevented scientists from being able to go to the cave. I think it's too late now for that cave, so they need to find the source of the next outbreak, and hope it's in a "safe" area.
It's more like if everybody who bought Linux from RedHat were suddenly told that they have to pay SCO an additional $699 or be sued. Because we can see this trend already starting, it makes sense to try to get indemnity.
I've never seen a game distributed as a 100 meg shell script before!
A little off topic:
Software is (was?) often distributed in this fashion. It is known as a shar file (SHell ARchive). I believe that Sun's version of Java is delivered in this way; it allows them to feed you a license agreement before creating the tarball that contains the file. The tarball itself is Base64 encoded (just as if it went through an email system) and tacked onto the end of the script.
Talk to the higher-ups in the compsci department. They'll probably understand the benefits of having source available, and may be able to implement the software as departmental policy (if the school policy allows it). They may also be able to point you in the right direction for a campus-wide policy.
That only works within a limited scope. What if you're trying to send to everybody in several offices? What if only certain people are supposed to know? That's good if everybody in your office needs to know, though. And if you have paging access (some sites lock down so only the receptionist, for example, is able to page).
The reason that they know it's Google is because of the user-agent string. What if they randomly visit sites using a different string? If the site doesn't know it's Google, it can't treat the engine specially. And according to Google's FAQ, that's grounds for de-indexing.
Maybe they should follow redirects and index only the final page. This avoids indexing the intermediate pages that are there only for redirects, and also allows you to move your site somewhat more easily by adding a redirect to your current page.
As for the text/background idea, what about running the page through something similar to SpamAssassin. Not all tests are applicable for websites, but a new ruleset shouldn't be too hard for them to write.
Also, do they keep all pages for their cache, or just ones with a high enough PageRank? How difficult would it be for them to compare two pages for similarity, and lowering the rank for identical pages? Or for pages that have the exact same set of links (to reduce the effectiveness of link farms).
Due to the nature of the PageRank algorithm, lowering the score on the referring pages will have a result on the target page, while ensuring that it's difficult to get someone dropped completely (since other, high-ranking sites may also be pointing there).
Wasn't COBOL orignally written in order to allow the user to bypass the programmer? One of the lessons they learned from that experiment was that, even given a simplified language, most people don't understand computers well enough to write a program.
I'm not saying things like API obfuscation or similar. I mean people don't generally think logically. Computers don't think emotionally. The average person has no idea about algorithms, or why you may want an O(lg(n)) algorithm in preference to an O(n^2) algorithm.
For these things, professional programmers will still be required.
Some locations (including a former employer of mine) do exactly that. Have, for example, a Cisco firewall connected to the 'net feed. Plug that into an OpenBSD firewall, connect that to the house 'net. Possibly include more firewalls around the DMZ.
But it seems to imply a next-try improvement. In reality, this will generaly be a slow improvement; it is very rare to go from complete, undisciplined slob to perfectly clean and maintainable style without a few steps in between.
How many times have you seen a project that says "Here's our ultra-cool project. Just grab the files from CVS and build". No mention of the dependencies (the mailing list will tell you that you need libfoo-1.2; we depend on a specific bug in 1.2, so 1.2.1, which fixes the bug, will break our app).
Or "Here's our ultra-cool project. It's only a small app right now, but when we get people working on it, it'll do your dishes, write your thesis, and mow the lawn, with 3-D graphics and 6.1 surround sound."
What most developers don't think is "Hey, I didn't contribute anything. Nobody I know has contributed anything. Why will my project be any different?"
Myth 3: Reading code
I've tried to read large bodies of code before. It's damn hard, even if it is documented. And when it isn't documented, your beginning developers don't have a chance.
Myth 4: Packaging
Um...duh? Of course it needs to be properly packaged. And dependency lists? If someone can't get it to compile, they definitely won't use it.
Myth 5: Start from scratch
Don't start from scratch if the code isn't clean. Make new code clean, and go back to clean up existing code. Make sure you have those regression tests ready.
Myth 7: Perfection
Developers are humans. Humans are fallible. I'll make a perfect program - when Bullwinkle pulls a rabbit out of his hat.
Myth 8: Ignore warnings
If the warnings were ignorable, they wouldn't be there. My profs would take marks off if you got warnings in compilation, unless your documentation explained exactly why you let the warning stand (and it had better be a good reason).
Myth 9: Tracking CVS
Users don't track CVS. Developers track CVS. Users want quick-and-easy, working code.
Either I miscounted, or there's more than 8 entries on the site (they aren't numbered)
Maybe, but Earth is a bigger target.
According to the CCFDA, there's a fee on both - 21 cents on a regular CDR or 77 cents on an audio CDR.
Why are they allowed to combine dissimmilar items on the same bill? Each law (and thus bill) should have a single focus, and any clause that is not related to this focus should be stricken. Whether it is stricken by the House and Senate before passing, or by the courts when someone gets charged, these submarine laws should be destroyed.
Translation - "If we think you stole something from us, we can contact you." I don't think that's unreasonable.
The process happens at 5-minute intervals. It's possible that this could interfere with what the tech was doing. It could, therefore, be standard policy to disable the update before reconfiguring the settings.
Only if you remember to pay for parking.
I don't know which cave it was, only what my wife has told me about it (she's one of those blue-spacesuit people that works with ebola). IIRC, there were multiple caves, just as there are multiple strains of ebola.
There was a cave in the Congo that seemed to be the centre of several outbreaks. However, it was being flooded, so they had to take samples immediately. Unfortunately, a civil war prevented scientists from being able to go to the cave. I think it's too late now for that cave, so they need to find the source of the next outbreak, and hope it's in a "safe" area.
It's more like if everybody who bought Linux from RedHat were suddenly told that they have to pay SCO an additional $699 or be sued. Because we can see this trend already starting, it makes sense to try to get indemnity.
There's a setting (preferences -> comments -> signature dash) that lets you know where the sig starts. Trust me; it's not his sig.
My college uses software developed by one of the professors. They know exactly who to call when it breaks. And where to find him.
Software is (was?) often distributed in this fashion. It is known as a shar file (SHell ARchive). I believe that Sun's version of Java is delivered in this way; it allows them to feed you a license agreement before creating the tarball that contains the file. The tarball itself is Base64 encoded (just as if it went through an email system) and tacked onto the end of the script.
Talk to the higher-ups in the compsci department. They'll probably understand the benefits of having source available, and may be able to implement the software as departmental policy (if the school policy allows it). They may also be able to point you in the right direction for a campus-wide policy.
And I just got one from Mr. Chekov. All we need now is Kirk and Spock ;)
That only works within a limited scope. What if you're trying to send to everybody in several offices? What if only certain people are supposed to know? That's good if everybody in your office needs to know, though. And if you have paging access (some sites lock down so only the receptionist, for example, is able to page).
The reason that they know it's Google is because of the user-agent string. What if they randomly visit sites using a different string? If the site doesn't know it's Google, it can't treat the engine specially. And according to Google's FAQ, that's grounds for de-indexing.
As for the text/background idea, what about running the page through something similar to SpamAssassin. Not all tests are applicable for websites, but a new ruleset shouldn't be too hard for them to write.
Also, do they keep all pages for their cache, or just ones with a high enough PageRank? How difficult would it be for them to compare two pages for similarity, and lowering the rank for identical pages? Or for pages that have the exact same set of links (to reduce the effectiveness of link farms).
Due to the nature of the PageRank algorithm, lowering the score on the referring pages will have a result on the target page, while ensuring that it's difficult to get someone dropped completely (since other, high-ranking sites may also be pointing there).
I'm not saying things like API obfuscation or similar. I mean people don't generally think logically. Computers don't think emotionally. The average person has no idea about algorithms, or why you may want an O(lg(n)) algorithm in preference to an O(n^2) algorithm.
For these things, professional programmers will still be required.
Some locations (including a former employer of mine) do exactly that. Have, for example, a Cisco firewall connected to the 'net feed. Plug that into an OpenBSD firewall, connect that to the house 'net. Possibly include more firewalls around the DMZ.