... (somehow including a database of checksums of widely-deployed, known-safe scripts like Google Analytics' urchin, jquery, Amazon affiliate stuff, and... that's all that comes to mind)
Why is everyone in love with checksums?
Disk is cheap. The amount of scripting I should trust is small.
So cache the *actual* scripts... and then use those as keys into what scripts are actually run.
That is, when you first hit a website that tries to run a script, capture all of the script functions and fragments, and indicate to the user how many un-approved scripts are on this page. The user than has the option to say "Trust this set of scripts" (like noscript now), or "Let me look at these scripts."
And this is where the fun can begin.
The browser can present to me a list of script functions and fragments, each with a "allow", "deny", or "remap" option. Allow is just that -- allow that script function or fragment to be run as-is, temporarily or for that page, machine, or domain. Deny is just that -- deny that script function or fragment, again, for that page, machine, or domain.
For remap, however, I should get a little two-window/textarea display (top/bottom, left/right, don't care, should probably be the user's choice), one read-only (the key) and the other editable. I can then edit the second chunk of code as I please -- stupid client-side verification, gone, replaced with "return true;". Code that disables a feature, deletes information from the display, and so on and so forth... gone. The test for browser/os versions... gone. Bugs become fixable. (Sure, I might introduce bugs, but that's my own fault, and it's my browser anyway.)
Most folks wouldn't ever use "remap" in this way, but that's okay. The ability is there, just like most folks don't compile open-source programs from scratch. That's not the point... if they wanted to, they could.
The next step is to share remapping libraries, like people are sharing greasemonkey scripts now. I could get a call from my mother about how some website is broken to how she'd want to use it, and I can go look at the web-page, fix it, export my changes to some convenient archive, drop it on to my webpage, and then send the url to my mother, who can click on the archive, and have the browser ask "Do you want to install this?", click "Yes", and all is well in the world.
Sure, some websites will take steps to make every bit of client-side scripting unique for every connection. They'll obfuscate their code, randomize the variable names on a per-session basis, mess with the structure... and now you KNOW those websites are hostile and malicious and should be treated as such.
Don't bother with checksums, that doesn't put any power into the hands of the users. Track code, and allow for client-side replacement of code. Allow end-users to share their code-replacement libraries. We can kinda-sorta do that now with plugins and greasemonkey, but that's tricky and error-prone and tedious. Let the computer solve the problems that are tricky, or error-prone, and especially the problems that are tedious!
Comment the why in preference to the how. You end up with fewer comments, but they're far more useful.
Also, document assumptions -- in a procedure/function/method comment that does significant work, describe the preconditions you assume to be true, and what the caller can assume to be true once the procedure/function/method has finished. In a long (procedural) section, it's useful to insert "By here we know X, Y, and Z" type comments.
I recently gave Eclipse an "honest go", and tried to use it on the current project at work. It was a very frustrating experience, even with a die-hard Eclipse user on hand to offer advice and tips. After a month, I gave NetBeans a chance, and by the end of the first day I was managing to get as much done as I was in Eclipse.
Eclipse is a fine product, I'm sure, but it's pretty much set up to be the whole and only development environment. When a solution to a problem is "wipe your workspace and start over, and get it right this time", there's a serious usability issue (from my point of view, at least).
The above-mentioned "Eclipse guy" ended up doing some work for us. We gave him a skeleton project (directory structure, third-party libraries, ant buildfile, etc.) to start with, as we'd eventually be the ones maintaining the code when he was done. It proved to be rather difficult for him to adapt Eclipse to our bog-standard project structure -- he eventually discarded all of it and went with what Eclipse wanted to do.
Now we have some code that is designed to be compiled and run from Eclipse, and nowhere else.
Netbeans, on the other hand, fell over itself accomodating our project structure. "Fixing up" the NetBeans configuration was a snap (once the correct magic dialog box was found, that that's ever the case for GUI tools).
In short, Eclipse is a fine tool, for those that like it and can mandate that everyone else in the project use Eclipse. If you're working in a heterogeneous environment, however, and desire a GUI IDE, then you should also check out NetBeans.
(Of course, to be fair, on my Mac, I tend to use Terminal.app and GVim for preference, and neither Eclipse nor Netbeans.)
Diablo II LoD was amazing. I loved playing that game with friends. And then one of the 'patches' came out and corrupted my favorite character, and then resulted in ever-more-frequent crashes. Now, I can't even start up the game without it crashing right away. Nothing in the logs, no useful errors, nothing.
Blizzard no longer cares -- I've paid for the software, and I'm not playing WoW -- so tough noogies to me.
I can't get at any of my characters with the base version, straight out of the box, and installing the patch results in an unstable and unplayable game. I'm not much interested in starting over from scratch.
No way am I going to subject myself to this sort of treatment with WoW.
So.... I play NWN (NWN1) now. The online community is friendlier than that on Battle.NET, and consequently a lot more fun. I'm afraid that Blizzard's concentration on the New and Shiny has lost them a customer, and I'm now busy trying to get all of my friends from Diablo II days to install NWN.
If you don't support your old customers, you won't get repeat business. They'll go somewhere else.
Oh, it requires X11 to be installed, but I do that as a matter of course anyway. It's just that it doesn't come with a package installer.
Come to think of it, I don't think any of the Macs in the house lack X11. Which means there's a good reason for them not to lack OpenOffice 2.1 as well.
I never got that far with NeoOffice. OpenOffice 2.1 installs by dragging an application folder, giving me a choice of where to install it (~/Apps in my case), while NeoOffice has the stupid-ass package-installer, which doesn't give me a choice, so far as I could tell. When developers start treating my machine as their machine, I'll go find some other product. It's still my computer for a little while longer.
The failure to provide an option for copy/paste preservation of hyperlinks is just a second strike against 'em.
Oh, Firefox already did that. ^U no longer deletes the text in the address bar like it should.
Or how about Tools -> Options -> Content -> JavaScript -> Advanced -> Disable or replace context menus? That's even a more direct way to stop it!
Or better yet, Edit->Preferences->Disable Javascript!
If browsers would ship with Javascript disabled by default, and require a menu-option to enable javascript for each and every page they visited, then the average user would give up on websites that require Javascript. Businesses, such as the radio station engaged in this idiocy, would see less revenue from their javascript-mandatory website than from their competitor's javascript-optional or javascript-free websites...
I remember when shipping a system with "all services enabled" was standard operating procedure. We've gotten away from that now -- but we're back to that same mindset with browsers. You'd think we'd learn to ship products in a locked-down state, and only enable "features" when and if the user explicitly requests it.
I don't even like debit cards. I like using a credit card as a buffer between (unknown) vendors and my bank account -- plus I get float (you don't HAVE to carry a balance on a credit card). My bank keeps pushing me to get a debit card, and I keep telling them that if they force it on me, I'm taking my money somewhere else.
Oh, well. I suppose a little sandpaper to the magnetic strip will do a good job of dedebitcardifying my REAL ID compliant license....
Why don't they just diagram the sentence for us? That makes the structure explicit, which would do the same thing, but offer additional (useful) information in the presentation.
Wait, they couldn't patent that. Too much "prior art".
Your friends probably dont[sic] need military grade public key cryptography along with a confusing install.
"Military grade cryptography" is one of those security snake-oil warning phrases. There ain't no such thing, and the use of that phrase is an indicator that you're probably being fed a line of BS.
So what do you do when the presented ideas are completely useless? Take for example the suggestion I've seen for every project I've ever been involved with where someone will just stop in and demand the whole project be rewritten in their favorite language. What then?
Why, set up a sourceforge page for $foo-$language-port, and put that person in charge of it, of course.
Seriously, I think this is a common problem, and unfortunately, sometimes those people actually get
something released. There's a large number of people who want everything to be written in Python,
and get upset if your project is in Java, TCL, or Perl. And should you be crazy enough to admit you
wrote a five-line csh script, you'll suffer the kneejerk reaction of a bunch of idiots who shout
"CSH considered harmful".
On the other hand, the "let's rewrite everything in my favorite language" is a wonderful driving force
in a community. It fosters the us-vs-them attitude, and really motivates people to "show up" the
despised opponents. So while the behavior may seem silly, counterproductive, and juvenile, it might
well have real-world benefits.
I find it amusing that it's the SVN developers talking about 'poisonous people', as they seem to be one of the most
poisonous groups around, as they routinely interrupt conversations about how to do something with CVS
with "you shouldn't use that cvs crap, use svn instead".
What do you do with the person who thinks your text editor needs a video playback system and demands it's immediate inclusion?
Point 'em at emacs and aalib, and tell 'em there's an obvious alt-meta-mod4-control-mumble key sequence that will do
just what they ask, but you can't right now remember.
What do you do when you just get vague complaints of bugs with absolutely no information about what actually went wrong?
Ask for steps on how to replicate it. Folks who know enough to tell you exactly what went wrong don't need your help.
Often, the initial bug report is just to see if someone is there, paying attention. The appropriate response is to
ask for information -- you may want a template for this -- and initiate a conversation. "Well, Joe, I don't know
enough to answer your question right now, could you tell me some things, like the version of the software, your OS,
hardware, and the command-line that failed, along with its output."
All users lie. They omit steps. They forget critical changes they've made to a system, but remember all the
trivial changes. They get sequences of events out of order. They fail to follow instructions properly. They
are quick to assign blame. They fail to read error messages. They don't know what's important.
Remember, they're frustrated far more than you are; YOU have a modicum of control over the system, because you nominally understand it.
.. does it, by default, save to a format that the older versions can't read?
If not, we'll see the same thing we've seen the past few times with an MS Office "upgrade": companies will have to upgrade because some employee installed the latest version "to check it out", and touched some important files. Eventually, the company will find it easier to just pay for the upgrade than to keep reverting those files.
...it's mean for the people who today voluntarily tell you that a link they're posting is NSFW out of common courtesy.
Indeed. It's intended to fix something that isn't broken; to replace something that works now with something more complicated and clever. The real problem it's addressing seems to be that the current approach assumes that the recipient is literate (or at least willing to read a little bit before clicking on a link).
That being said, and while I think it's a supremely stupid idea, I'd use it like mad -- label everything I have control over as NSFW. That way I don't have to worry about ever offending some coporate behemoth; I'd just smile sweetly and say "it's not safe for work, so how did your easily-offended employee even SEE it?"
Rinse, lather, and repeat for RIAA goons. Again for MPAA thugs....
Except that I don't consider McDonald's to be "very clean, good ingredients". McDonald's is full of hard, brightly-colored, plastic surfaces that are easily wiped down, giving the appearance of cleanliness; the food is crap, the service worse; it's all about marketing and appearances and not at all about substance and quality.
Having formatting requirements is one thing; punishing students equally or worse for (for example) indenting incorrectly and writing broken code is another.
That's why you go through and apply weights to the various things you're scoring. "Consistent indentation" might be worth, oh, 3 points ( 3 = consistent indentation, 2 = minor lapses, 1 = made an effort, 0 = randomness ), while "accomplishes the task" might be worth 30 points.
In my opinion, errors that can be fixed by a well-known script or program (e.g. indent) with no harmful effect on the functioning of a program should under no circumstances be conflated with anything that leads to incorrect behaviour of the program.
In school, you're trying to teach the students several things at once. The only way you have to teach a student to write clear code is to penalize them when they fail to do so; and it's best that this is done early, before they acquire too many bad habits.
Consider -- any reasonable coding project will have a Coding Style Guide. (If you come across a project with more than three programmers and there isn't at least an informal Coding Style Guide, run like hell. You'll save yourself a lot of grief, unless, that is, you enjoy tracking down stupid little bugs.) Getting a student used to this early is important.
Further, imposing formatting constraints is good for the novice programmer -- the easier code is to read, the easier it will be for someone to help them with their program. Students who plop down some ugly code and say "It doesn't work, can you help me?" do not get the same quality of help as students who have taken the time to format their code consistently. (And it's not uncommon when you tell a student to go away and come back after they have cleaned up their code (by hand) that they return to say that they found the error.)
Finally, it's in the grader's best interest to look at readable -- read, well-formatted -- code. More time can be spent on figuring out where the student almost got it right. A grader's time is limited, wasting it on trying to parse ugly code isn't what the grader is being paid for. A student who tries to make a grader's life more difficult than it needs to be should reap what they sow.
The last thing we need in the software business is an influx of programmers with obsessive attention to formatting detail who don't really care whether their code works!
The last thing we need in the software business is this continuing influx of programmers who so despise writing that they format their code randomly, choose terrible variable, function, and class names, and eschew comments. The mantra of "so long as it works, ship it!" results in buggy and hard-to-maintain code.
So while we may not want programmers who obsess on formatting to the exclusion of all else, we most certianly do not want any more programmers who disdain all formatting. It is possible train a programmer with an obsessive attention to formatting detail to produce code that works; it's far harder to train a programmer with a pathological disdain for formatting to produce maintainable code.
If a programmer can't follow instructions, their code may compile and run, but it ain't gonna do the job.
Use CVS or other version-control system. Set it up so that each student gets their own module, and each student has access _only_ to their module [if individual assignments -- group assignments should naturally be set up for group access]. Then you can obtain and compile the code by performing a checkout rather than the student running a turnin program.
Teach 'em how to use Make or Ant. Specify the directory structure and the name of the build-control file. This lets you automate the "checkout, compile, run" process. Give them the script that does this, so that they can test this part of their process.
Then go through the assignment, and make a list of everything you told 'em to do and not to do. This includes stuff like "every file will have your name, the class, the assignment name, and the date in a comment at the top of the file' -- the finer-grained the list, the easier it is for you to grade. Go through this list and assign weights to the items on this list. Adjust the weights so that you come up with something reasonable -- you don't want to have an assignment that is worth 191.125 points.
As you're teaching a Java class, take advantage of the Java sandbox. Take a couple of days to learn how to use the policytool to create a policy file. If it's pure computation, stdin/stdout are good enough; otherwise, it's easy enough to set up filesystem access.
The start of your script should cat the documentation -- GRADER.NOTES file, README, whatever. Then it should cat all of the source files. Then it should compile the program. Then run the program w/ the appropriate policy file, with the inputs as desired. (Don't give the students _all_ of the possible inputs, but just a couple.) Capture all of this (script is a good tool), and print it out.
Inspect and markup the printout. Do NOT get hung up on correcting their crappy code. Do not let their crappy code slide by, or the next assignment will be just as hard to inspect. (And they'll get in the habit of writing really ugly code, which is a habit that's really, really, really hard to break, and they'll say, with all seriousness, "if it's hard to write it should be hard to read", and I'll just have to stake them through the heart when I encounter them.) Use the checklist.
At least 1/3 but no more than 2/3 of the grade should come from passing the tests. You're teaching 'em HOW to program, which involves following instructions, abiding by constraints and specifications, and writing readable code.
My problem was always that I spent too much time showing 'em how to do something right, rather than marking it as a problem and letting 'em come to me in office hours.
Finally, speaking of office hours, determine your appeals policy. Do not, ever, discuss the assignment with an individual student in class. They should come to your office during office hours to discuss, and _there_ you can point out why "if ( expression ) return TRUE; else return FALSE;" got them dinged, or why "i++;// incr i" does not count as commenting in your book. (The caveat being... if a sizable fraction of the class did the same sort of stupid error, that's a sign you need to cover that topic.)
P.S. The version-control history is a useful tool for tracking down cheaters. When three people with very nearly the exact same code commit the entire project the day it's due, that's supporting evidence.
I want to rent it for an hour or three to take my WRX out to play where there's nothing to hit. Parking lots often have light poles, or security guards who get irate. Taking my car to an SCCA event voids my warranty. An empty stretch of highway might not be so empty, and tickets obtained while "seeing how fast my car can go" tend to be REALLY expensive.
Nearly three miles of empty pavement sounds like a lot of (pretty safe) fun.
Why aren't I interested in eBooks? Let me count the ways....
Resolution. The resolution of the printed page is far better than just about any electronic display device, and far better than a PDA-sized eBook reader. This makes books easier to read, and more important, more pleasant to read.
Glare. It's generally rather difficult to get into a situation with a paper book where the light source causes enough glare on the page to make a difference; anything with a glassy display surface has just the opposite problem -- glare is the normal condition. As a result, you either get a matte surface (which does lousy things to the resolution, see above) or you contort yourself to eliminate the glare. (Or you put up with it, I suppose, but that's just stupid.)
Reliability. I have books that are literally falling apart. They've taken a lot of abuse over the years -- they've been dropped, sat upon, stacked, knocked over, bumped, banged, handled, pried from the fingers of little kids... and they're still readable. Even the books in poor shape can be read, with care -- that's graceful degregation. An eBook reader doesn't have that. Given DRM, I can't have that. Oh, I can download the book again if I lose it? Sure... for as long as the publisher lets me. When it's no longer profitable, they'll discontinue that service, or change the terms, and what can I do then? (Pensions used to be safe....)
You Can't Sign An EBook. A small fraction of the books in my library are signed, and often by the author _to_ me. I get a kick out of this. Can't do that with an eBook. Digital signatures just aren't the same.
Display area. Generally, a "reader" doesn't display a full page. This is probably a combination of "Resolution" and "Form Factor", but the effect is that of reading the work through a tiny window. That's okay for short stories, but for longer works, it gets tiring.
Carbon Sequestering. We're dumping too much carbon into the atmosphere. Trees take up that carbon, and we then turn it into paper. I'm doing my bit to sequester carbon from the atmosphere. . .:)
Awhile back, some kid was playing with a laser pointer during the trailers; a bunch of strangers coordinated, some watching the screen, some watching various areas of the theater -- and someone spotted the kid, and a manager was quietly notified.
He turned up the house lights, and asked for the laser pointer. The kid's father got all huffy and said "You can't do that." -- so the manager told him it was a choice: hand over the laser pointer, or be ejected from the theater complex.
The kid eventually handed over the laser pointer, and we have the manager a standing ovation as he walked out.
And while $10/ticket is expensive enough to really reduce how often I go to a movie theater, when I do see a movie, I tend to go there.
If this will result in someone's lawyers contacting all the people running insecure home PCs and giving 'em a short scare, I'm all for it. The first time, hopefully, should be a quick excuse to the judge: "My PC was compromised without my knowledge. I'm not at fault." -- but the _second_ time, well, the sharks get to have fun.
There's a potential for this to improve the 'Net. Having the copyright holders identify compromised machines? It's pratically a public service.
Yeah, but if you brought a lead weight into the classroom you'd be crucified for endangering the children with lead, and if you brought a small feather it you're dead either for exposing them to avian viruses or torturing animals. And let's not even think about the witchcraft trial over your sleight of hand wizardry...
Heh.
Well, there would be no crucifixion, as that's now associated with a religous event. You'd instead get a memo and sensitivity training. Er, *more* sensitivity training.
The lead weight would be perfectly okay, so long as the demonstration was given by trained professionals (after they'd signed the appropriate waivers) with a hazmat team standing by. Perhaps in the interests of concerned parents, the children who wish to view the demonstration could bring in signed forms (triplicate!) granting permission.
The feather could easily be synthetic. In fact, that leads to an interesting variation on the experiment... Why does the ball fall faster than the feather? Perhaps it's because the feather comes from a bird and "wants" to fly? So... make a ball and a feather out of steel, and repeat the experiment. Eventually, you conclude that the *shape* is important... which leads into the experiment-in-a-vacuum.
There's a strong desire not to "waste time" by investigating dead ends and debunked theories, but I wonder if perhaps that isn't counter-productive in the long run.
Slashdot Mirror
Why is everyone in love with checksums?
Disk is cheap. The amount of scripting I should trust is small.
So cache the *actual* scripts... and then use those as keys into what scripts are actually run.
That is, when you first hit a website that tries to run a script, capture all of the script functions and fragments, and indicate to the user how many un-approved scripts are on this page. The user than has the option to say "Trust this set of scripts" (like noscript now), or "Let me look at these scripts."
And this is where the fun can begin.
The browser can present to me a list of script functions and fragments, each with a "allow", "deny", or "remap" option. Allow is just that -- allow that script function or fragment to be run as-is, temporarily or for that page, machine, or domain. Deny is just that -- deny that script function or fragment, again, for that page, machine, or domain.
For remap, however, I should get a little two-window/textarea display (top/bottom, left/right, don't care, should probably be the user's choice), one read-only (the key) and the other editable. I can then edit the second chunk of code as I please -- stupid client-side verification, gone, replaced with "return true;". Code that disables a feature, deletes information from the display, and so on and so forth... gone. The test for browser/os versions... gone. Bugs become fixable. (Sure, I might introduce bugs, but that's my own fault, and it's my browser anyway.)
Most folks wouldn't ever use "remap" in this way, but that's okay. The ability is there, just like most folks don't compile open-source programs from scratch. That's not the point... if they wanted to, they could.
The next step is to share remapping libraries, like people are sharing greasemonkey scripts now. I could get a call from my mother about how some website is broken to how she'd want to use it, and I can go look at the web-page, fix it, export my changes to some convenient archive, drop it on to my webpage, and then send the url to my mother, who can click on the archive, and have the browser ask "Do you want to install this?", click "Yes", and all is well in the world.
Sure, some websites will take steps to make every bit of client-side scripting unique for every connection. They'll obfuscate their code, randomize the variable names on a per-session basis, mess with the structure... and now you KNOW those websites are hostile and malicious and should be treated as such.
Don't bother with checksums, that doesn't put any power into the hands of the users. Track code, and allow for client-side replacement of code. Allow end-users to share their code-replacement libraries. We can kinda-sorta do that now with plugins and greasemonkey, but that's tricky and error-prone and tedious. Let the computer solve the problems that are tricky, or error-prone, and especially the problems that are tedious!
Comment the why in preference to the how. You end up with fewer comments, but they're far more useful. Also, document assumptions -- in a procedure/function/method comment that does significant work, describe the preconditions you assume to be true, and what the caller can assume to be true once the procedure/function/method has finished. In a long (procedural) section, it's useful to insert "By here we know X, Y, and Z" type comments.
The classic poor example is
Avoid this.I recently gave Eclipse an "honest go", and tried to use it on the current project at work. It was a very frustrating experience, even with a die-hard Eclipse user on hand to offer advice and tips. After a month, I gave NetBeans a chance, and by the end of the first day I was managing to get as much done as I was in Eclipse.
Eclipse is a fine product, I'm sure, but it's pretty much set up to be the whole and only development environment. When a solution to a problem is "wipe your workspace and start over, and get it right this time", there's a serious usability issue (from my point of view, at least).
The above-mentioned "Eclipse guy" ended up doing some work for us. We gave him a skeleton project (directory structure, third-party libraries, ant buildfile, etc.) to start with, as we'd eventually be the ones maintaining the code when he was done. It proved to be rather difficult for him to adapt Eclipse to our bog-standard project structure -- he eventually discarded all of it and went with what Eclipse wanted to do.
Now we have some code that is designed to be compiled and run from Eclipse, and nowhere else.
Netbeans, on the other hand, fell over itself accomodating our project structure. "Fixing up" the NetBeans configuration was a snap (once the correct magic dialog box was found, that that's ever the case for GUI tools).
In short, Eclipse is a fine tool, for those that like it and can mandate that everyone else in the project use Eclipse. If you're working in a heterogeneous environment, however, and desire a GUI IDE, then you should also check out NetBeans.
(Of course, to be fair, on my Mac, I tend to use Terminal.app and GVim for preference, and neither Eclipse nor Netbeans.)
Diablo II LoD was amazing. I loved playing that game with friends. And then one of the 'patches' came out and corrupted my favorite character, and then resulted in ever-more-frequent crashes. Now, I can't even start up the game without it crashing right away. Nothing in the logs, no useful errors, nothing.
Blizzard no longer cares -- I've paid for the software, and I'm not playing WoW -- so tough noogies to me.
I can't get at any of my characters with the base version, straight out of the box, and installing the patch results in an unstable and unplayable game. I'm not much interested in starting over from scratch.
No way am I going to subject myself to this sort of treatment with WoW.
So.... I play NWN (NWN1) now. The online community is friendlier than that on Battle.NET, and consequently a lot more fun. I'm afraid that Blizzard's concentration on the New and Shiny has lost them a customer, and I'm now busy trying to get all of my friends from Diablo II days to install NWN.
If you don't support your old customers, you won't get repeat business. They'll go somewhere else.
I suppose it's "Good Riddance" on both sides.
Oh, it requires X11 to be installed, but I do that as a matter of course anyway. It's just that it doesn't come with a package installer.
Come to think of it, I don't think any of the Macs in the house lack X11. Which means there's a good reason for them not to lack OpenOffice 2.1 as well.
I never got that far with NeoOffice. OpenOffice 2.1 installs by dragging an application folder, giving me a choice of where to install it (~/Apps in my case), while NeoOffice has the stupid-ass package-installer, which doesn't give me a choice, so far as I could tell. When developers start treating my machine as their machine, I'll go find some other product. It's still my computer for a little while longer.
The failure to provide an option for copy/paste preservation of hyperlinks is just a second strike against 'em.
Oh, well. Such promise.
Oh, Firefox already did that. ^U no longer deletes the text in the address bar like it should.
Or better yet, Edit->Preferences->Disable Javascript!
If browsers would ship with Javascript disabled by default, and require a menu-option to enable javascript for each and every page they visited, then the average user would give up on websites that require Javascript. Businesses, such as the radio station engaged in this idiocy, would see less revenue from their javascript-mandatory website than from their competitor's javascript-optional or javascript-free websites...
I remember when shipping a system with "all services enabled" was standard operating procedure. We've gotten away from that now -- but we're back to that same mindset with browsers. You'd think we'd learn to ship products in a locked-down state, and only enable "features" when and if the user explicitly requests it.
I don't even like debit cards. I like using a credit card as a buffer between (unknown) vendors and my bank account -- plus I get float (you don't HAVE to carry a balance on a credit card). My bank keeps pushing me to get a debit card, and I keep telling them that if they force it on me, I'm taking my money somewhere else.
Oh, well. I suppose a little sandpaper to the magnetic strip will do a good job of dedebitcardifying my REAL ID compliant license....
Why don't they just diagram the sentence for us? That makes the structure explicit, which would do the same thing, but offer additional (useful) information in the presentation.
Wait, they couldn't patent that. Too much "prior art".
My bad.
Why, set up a sourceforge page for $foo-$language-port, and put that person in charge of it, of course.
Seriously, I think this is a common problem, and unfortunately, sometimes those people actually get something released. There's a large number of people who want everything to be written in Python, and get upset if your project is in Java, TCL, or Perl. And should you be crazy enough to admit you wrote a five-line csh script, you'll suffer the kneejerk reaction of a bunch of idiots who shout "CSH considered harmful".
On the other hand, the "let's rewrite everything in my favorite language" is a wonderful driving force in a community. It fosters the us-vs-them attitude, and really motivates people to "show up" the despised opponents. So while the behavior may seem silly, counterproductive, and juvenile, it might well have real-world benefits.
I find it amusing that it's the SVN developers talking about 'poisonous people', as they seem to be one of the most poisonous groups around, as they routinely interrupt conversations about how to do something with CVS with "you shouldn't use that cvs crap, use svn instead".
Point 'em at emacs and aalib, and tell 'em there's an obvious alt-meta-mod4-control-mumble key sequence that will do just what they ask, but you can't right now remember.
Ask for steps on how to replicate it. Folks who know enough to tell you exactly what went wrong don't need your help.
Often, the initial bug report is just to see if someone is there, paying attention. The appropriate response is to ask for information -- you may want a template for this -- and initiate a conversation. "Well, Joe, I don't know enough to answer your question right now, could you tell me some things, like the version of the software, your OS, hardware, and the command-line that failed, along with its output."
All users lie. They omit steps. They forget critical changes they've made to a system, but remember all the trivial changes. They get sequences of events out of order. They fail to follow instructions properly. They are quick to assign blame. They fail to read error messages. They don't know what's important.
Remember, they're frustrated far more than you are; YOU have a modicum of control over the system, because you nominally understand it.
If they're going to say "White" is a race, then surely the other races are "Black", "Brown", "Red", and "Yellow".
In games, I typically try to choose a blue or a green race.
If not, we'll see the same thing we've seen the past few times with an MS Office "upgrade": companies will have to upgrade because some employee installed the latest version "to check it out", and touched some important files. Eventually, the company will find it easier to just pay for the upgrade than to keep reverting those files.
Been there, done that. Twice.
Indeed. It's intended to fix something that isn't broken; to replace something that works now with something more complicated and clever. The real problem it's addressing seems to be that the current approach assumes that the recipient is literate (or at least willing to read a little bit before clicking on a link).
That being said, and while I think it's a supremely stupid idea, I'd use it like mad -- label everything I have control over as NSFW. That way I don't have to worry about ever offending some coporate behemoth; I'd just smile sweetly and say "it's not safe for work, so how did your easily-offended employee even SEE it?"
Rinse, lather, and repeat for RIAA goons. Again for MPAA thugs....
I like the McDonald's analogy.
Except that I don't consider McDonald's to be "very clean, good ingredients". McDonald's is full of hard, brightly-colored, plastic surfaces that are easily wiped down, giving the appearance of cleanliness; the food is crap, the service worse; it's all about marketing and appearances and not at all about substance and quality.
Fits perfectly with Microsoft.
In school, you're trying to teach the students several things at once. The only way you have to teach a student to write clear code is to penalize them when they fail to do so; and it's best that this is done early, before they acquire too many bad habits.
Consider -- any reasonable coding project will have a Coding Style Guide. (If you come across a project with more than three programmers and there isn't at least an informal Coding Style Guide, run like hell. You'll save yourself a lot of grief, unless, that is, you enjoy tracking down stupid little bugs.) Getting a student used to this early is important.
Further, imposing formatting constraints is good for the novice programmer -- the easier code is to read, the easier it will be for someone to help them with their program. Students who plop down some ugly code and say "It doesn't work, can you help me?" do not get the same quality of help as students who have taken the time to format their code consistently. (And it's not uncommon when you tell a student to go away and come back after they have cleaned up their code (by hand) that they return to say that they found the error.)
Finally, it's in the grader's best interest to look at readable -- read, well-formatted -- code. More time can be spent on figuring out where the student almost got it right. A grader's time is limited, wasting it on trying to parse ugly code isn't what the grader is being paid for. A student who tries to make a grader's life more difficult than it needs to be should reap what they sow.
The last thing we need in the software business is this continuing influx of programmers who so despise writing that they format their code randomly, choose terrible variable, function, and class names, and eschew comments. The mantra of "so long as it works, ship it!" results in buggy and hard-to-maintain code.
So while we may not want programmers who obsess on formatting to the exclusion of all else, we most certianly do not want any more programmers who disdain all formatting. It is possible train a programmer with an obsessive attention to formatting detail to produce code that works; it's far harder to train a programmer with a pathological disdain for formatting to produce maintainable code.
If a programmer can't follow instructions, their code may compile and run, but it ain't gonna do the job.
Use CVS or other version-control system. Set it up so that each student gets their own module, and each student has access _only_ to their module [if individual assignments -- group assignments should naturally be set up for group access]. Then you can obtain and compile the code by performing a checkout rather than the student running a turnin program.
Teach 'em how to use Make or Ant. Specify the directory structure and the name of the build-control file. This lets you automate the "checkout, compile, run" process. Give them the script that does this, so that they can test this part of their process.
Then go through the assignment, and make a list of everything you told 'em to do and not to do. This includes stuff like "every file will have your name, the class, the assignment name, and the date in a comment at the top of the file' -- the finer-grained the list, the easier it is for you to grade. Go through this list and assign weights to the items on this list. Adjust the weights so that you come up with something reasonable -- you don't want to have an assignment that is worth 191.125 points.
As you're teaching a Java class, take advantage of the Java sandbox. Take a couple of days to learn how to use the policytool to create a policy file. If it's pure computation, stdin/stdout are good enough; otherwise, it's easy enough to set up filesystem access.
The start of your script should cat the documentation -- GRADER.NOTES file, README, whatever. Then it should cat all of the source files. Then it should compile the program. Then run the program w/ the appropriate policy file, with the inputs as desired. (Don't give the students _all_ of the possible inputs, but just a couple.) Capture all of this (script is a good tool), and print it out.
Inspect and markup the printout. Do NOT get hung up on correcting their crappy code. Do not let their crappy code slide by, or the next assignment will be just as hard to inspect. (And they'll get in the habit of writing really ugly code, which is a habit that's really, really, really hard to break, and they'll say, with all seriousness, "if it's hard to write it should be hard to read", and I'll just have to stake them through the heart when I encounter them.) Use the checklist.
At least 1/3 but no more than 2/3 of the grade should come from passing the tests. You're teaching 'em HOW to program, which involves following instructions, abiding by constraints and specifications, and writing readable code.
My problem was always that I spent too much time showing 'em how to do something right, rather than marking it as a problem and letting 'em come to me in office hours.
Finally, speaking of office hours, determine your appeals policy. Do not, ever, discuss the assignment with an individual student in class. They should come to your office during office hours to discuss, and _there_ you can point out why "if ( expression ) return TRUE; else return FALSE;" got them dinged, or why "i++; // incr i" does not count as commenting in your book. (The caveat being... if a sizable fraction of the class did the same sort of stupid error, that's a sign you need to cover that topic.)
P.S. The version-control history is a useful tool for tracking down cheaters. When three people with very nearly the exact same code commit the entire project the day it's due, that's supporting evidence.
Nearly three miles of empty pavement sounds like a lot of (pretty safe) fun.
He turned up the house lights, and asked for the laser pointer. The kid's father got all huffy and said "You can't do that." -- so the manager told him it was a choice: hand over the laser pointer, or be ejected from the theater complex.
The kid eventually handed over the laser pointer, and we have the manager a standing ovation as he walked out.
And while $10/ticket is expensive enough to really reduce how often I go to a movie theater, when I do see a movie, I tend to go there.
Mod parent down as troll.
If this will result in someone's lawyers contacting all the people running insecure home PCs and giving 'em a short scare, I'm all for it. The first time, hopefully, should be a quick excuse to the judge: "My PC was compromised without my knowledge. I'm not at fault." -- but the _second_ time, well, the sharks get to have fun.
There's a potential for this to improve the 'Net. Having the copyright holders identify compromised machines? It's pratically a public service.
I think he's speaking with the voice of experience. "Do as I say and not as I just did." kind of thing.
What is it about Tokyo and 610,000 anyway? http://catless.ncl.ac.uk/Risks/21.81.html#subj1
Well, there would be no crucifixion, as that's now associated with a religous event. You'd instead get a memo and sensitivity training. Er, *more* sensitivity training.
The lead weight would be perfectly okay, so long as the demonstration was given by trained professionals (after they'd signed the appropriate waivers) with a hazmat team standing by. Perhaps in the interests of concerned parents, the children who wish to view the demonstration could bring in signed forms (triplicate!) granting permission.
The feather could easily be synthetic. In fact, that leads to an interesting variation on the experiment... Why does the ball fall faster than the feather? Perhaps it's because the feather comes from a bird and "wants" to fly? So... make a ball and a feather out of steel, and repeat the experiment. Eventually, you conclude that the *shape* is important... which leads into the experiment-in-a-vacuum.
There's a strong desire not to "waste time" by investigating dead ends and debunked theories, but I wonder if perhaps that isn't counter-productive in the long run.