Perhaps I'm embittered after too much DailyWTF reading - there are a lot of idiots in our trade.
I wish it were true that every programmer, laid off in the recession, would seek to use his free time in a way that contributes to society - or at least to his own career growth. Sadly, this won't be the case; many will spend the next year watching TV and raiding dungeons, and not learn a thing.
A laid-off person needs to consider his future. Open Source participation is one of the best ways to ensure that, when the depression finally ends, such a person can still be considered a programmer.
Likely, some of those who have lost their jobs will moan that they don't have time to work on open-source projects; they'll move into their parents' basements, read job postings on Craigslist and send off a few dozen resumes each day, then spend the rest of their time playing World of Warcraft.
These people are losers. They weren't going to work on open-source projects anyway, so a recession and layoff doesn't make a bit of difference to their usefulness to the world. It just gives them more time for World of Warcraft.
For the rest of us, though, a layoff would be an opportunity to learn and to create. Job-hunting does not take eight hours a day - especially in a weakened job market, when few interviews are being granted. Does anyone really expect to go to four interviews a day? If things really tank, you'll be lucky to get one or two interviews a week. Mailing out resumes and reading advertisements doesn't take more than a few hours a day. What is a laid-off programmer going to do with the rest of the day?
The good ones will still be programming. Learn a new language or framework; study for certifications; work on an open-source project. All of these things will make the person more marketable.
(There are exceptions, of course. People with no savings and no family or friends who they can move in with might have to work twelve hours a day slinging hamburgers.)
When the job market improves, what will you say to a hiring manager at an interview about the missing year on your resume? "I learned Ruby and Haskell, and contributed Feature X to Project Y" or "I sent out lots of resumes and no one was hiring. But I got my Arch-Druid to level 80!"?
I'll be at Grant Park next Tuesday night, so I expect to learn the election results direct from Senator Obama's mouth to my ears (albeit through a series of loudspeakers mounted above the stage, most likely).
The mood of the crowd will be an indicator of how things are going early in the process, with cheers for each state where Democrats are victorious, and sadness whenever a state goes red.
We were specifically hiring Java programmers for web applications - so an answer of "I don't know Java or HTML" would have been an immediate no-hire.
There weren't questions about other languages on the exam, as $BigCompany had decreed that all development was to take place in Java henceforth.
During the interview, though, I asked about other languages - if the candidate had worked with multiple languages, then it was a mark in their favour - they weren't a "one-trick pony".
While I do believe a written test is a valid method of sorting out the undesirables, giving you one the minute you walked in the door was just plain rude.
At $BigCompany, where I worked for several years and had a title with the word "Senior" in it, I wrote a test with about thirty questions about HTML, Java, Unix, and general computing. We had to do this after hiring several horribly underqualified candidates, whose resumes were filled with bullshit and outright lies. (Such as the guy who "ran his own ISP", and was hired - we later discovered he merely had a web site to which the real ISP had given him a "Control Panel").
Eventually, our method was to receive about 10-15 resumes from HR, call in the best six or so, and have an interview with both a manager and one or two technical people (me, usually). Only after the interview was finished, we'd give the candidate the written test, and suggest to them that it should take about a half hour to complete.
We'd do this even if the candidate had revealed himself to be completely unsuitable in the oral interview - this was done mainly so that we'd have something to show to our HR person, who was annoyed that we rejected so many of the "good" candidates she sent.
I'd go back in the conference room after twenty minutes - sometimes the candidate was visibly shaken, having failed to answer anything correctly. These were invariably people who had been sent by one of several big contracting companies who our company had a "preferred vendor" relationship with.
On several occasions, my manager told me had really been impressed with the candidate during the interview, and would have hired them had it not been for their wretched performance on the test - and realized now that we had "dodged a bullet" there.
The test wasn't difficult. The questions were like:
"which of the following is a valid HTML link: (multiple choice: A HREF=foo, A SRC=foo, LINK ADDRESS=foo, PAGE LINK=foo)
"write the HTML for a table with two cells, one cell having a yellow background"; [As it wasn't machine graded, any of several ways to do this were acceptable... I'd accept just about anything that had TR's and TD's in it.]
"here is a database table EMPLOYEE [layout and rows of data shown], write the SQL to get the name and salary of employee #6";
"spot two errors in this snippet of Java" [one was obvious, one less obvious but not particularly subtle].
"what does the Unix command 'ls' do?"
Scores in the 25% range weren't uncommon. Those who we did hire generally had 75% or more correct, and some scored above 90%.
Some people in this thread might be offended by such a test. But in the corporate IT world, we just don't run into many like that... the vast majority of candidates we received for our openings were simpletons whose competence had been exaggerated by their contracting companies (one with a three-letter acronym in particular). We weren't looking for superstars; our goal was to separate the liars and time-wasters from the competent craftsmen, and for this the test worked very well.
What they found is Illudium Q-36, a key component of the "Explosive Space Modulator". The president needed to be briefed so he could begin an invasion - it's an election year, after all, and Republican chances depend on a quest for fictional weapons of mass destruction.
I worked for a company that was destroyed by a bad coding standard.
This was a small company, that, back in '96, was awarded the contract for a POS application for a regional store chain, with back-office servers that would be updated nightly by modem.
The guys who ran the company weren't programmers (though one of them knew enough to be dangerous); they were technical salesmen. They were also big fans of Microsoft, with "MVP" plaques on the walls, and every employee except me having Microsoft certs.
I worked for them part-time while also working for another company. I advocated Unix (mostly BSDI and SunOS at the time), and always argued with them about why Unix was better (technical superiority vs. potential for big profits).
When their big project was well underway, they brought me in to do the communications part of it, where the POS terminals would contact one of several servers by modem each night ("why not just ethernet them together, get a dialup PPP connection, and use IP? the interface is so much more reliable..." Request denied).
The app was Visual Basic, with third-party "custom controls" for things like talking to modems. My part went fairly smoothly, and I was eventually asked to help out with the main application, which was suffering from unexplained crashes. When I looked at the code, I found something... strange.
For error handling, they had elected to use a program called "VB Rig" (the name came from the rigging used on sailing ships, which prevents a sailor from falling to his death. Sometimes.) What this program did was to examine the source code, and then add error handling boilerplate at the start and end of each and every function. It inserted the exact same error handling code into every function.
Because the error handler had to be all purpose, it was about 20 lines of code per function - sometimes much larger than the regular part of the function. And, worse, because it was the same for every function, and it made use of the same variable names, that meant either every variable had to be global, or you'd have to declare the ten or so standard variable names at the start of every function (they opted for the "everything is global" approach).
Which led to things like this (forgive the syntax errors, it's been years since I've touched VB):
On Error goto my_data_file_read_function_VBRIG_TRAP
open MyDataFile for writing... goto my_data_file_read_function_VBRIG_CLEANUP
my_data_file_read_function_VBRIG_TRAP: on error 101 'Permission Denied
delete MyDataFile
resume on error 102 'File Not Found
MessageBox 'Cannot read ' + MyConfigFile
resume my_data_file_read_function_VBRIG_CLEANUP:
blah blah
my_data_file_read_function = SUCCESS ' return
As you see, the error handling code - which had to be exactly the same for every function - made use of global variables (names like DataFile1, MyFile1, UserName, etc.) to figure out what to do for each error. That meant, that if there was any possibility you might have a "File Not Found", you had to expect the filename where that might happen to be in a particular global variable - say, MyFile1 - and hope that the calling function wasn't using that name too, for the same reasons.
Naturally, files were being created and deleted at random, and the programmers often spent hours on the phone with the customer trying to figure out why the Access database had disappeared *again*.
I asked if we could just write the error handling by hand, and use appropriate local variables; or take the standard VBRig error handling and trim out the lines that weren't relevant for a particular function (as subsequent VBRig runs wouldn't touch its code region if it saw that it had been customized).
Request Denied. "This is our coding standard. We carefully reviewed the options before making the decision to use t
I didn't have anything on those disks that was *really* sensitive - at most, a few credit card numbers that were probably expired already. Smashing the circuit board is just to deter casual scavengers.
A while back, I disposed of some drives - mostly unreadable - that might have once contained confidential information (they came from an employer who did a lot of credit card transactions).
step 1: slam against concrete floor repeatedly, until hearing bits shake about inside. step 2: with the claw-end of a hammer, smash the exposed circuit boards. step 3: submerge drives in a bucket of salt water for a month. step 4: put drives in Hefty bag and cover with cat litter and cat shit (a psychological barrier to deter exploration of the bag's contents). step 5: city dumpster.
Let's illustrate with a thought experiment centered around the fictional article "GraxFink". If anyone were to come along and nominate GraxFink for deletion, only those users who care about deletions will vote! The 99% of the visitors to that particular page, That seems to be exactly what happens. Worse, if someone goes to a place where people actually interested in GraxFink congregate, and says "please help me stop this article from being deleted", he'll be accused of sock-puppetry or ballot-box stuffing, and all of the "Keep"'s from people truly interested in the subject will be discounted.
But deletionist votes seem to always be counted, even if they're from people whose only interest seems to be deletion. Someone could go through the entire AfD list on a particular day, vote "delete" on every article (on subjects they might not have ever heard of before), and their statements will be given more weight than those of persons who truly have an interest in the subjects in question.
The process is rigged, and rigged in such a way that destruction is easier than creation.
I love Wikipedia. I use Wikipedia every day. I've written articles, and uploaded numerous photos. I've installed the software on two of my own sites. I donated to WikiMedia last year.
But this year, I will not be making a donation, as a protest against deletionism, against false claims of "consensus", and against an ivory-tower elite who try to impose the will of a small fraction of the community onto articles that they had nothing to do with. The administrators need to be sent a message: "consensus" doesn't just happen on policy discussion pages, it comes from the bottom up.
There's a sample of five thousand articles that still have your little anti-trivia boxes nagging the editors to "fix" trivia sections. Press "Next 5000" to see the other half of the list.
The facts show that plenty of editors are ignoring the trivia nag-box.
Let's take one of these articles as an example - I chose the first one on that page that was about a subject I'm interested in:
According to the history page for that article, the article was tagged with the {{trivia}} template on 10 May 2007. That was nearly six months ago. It was a "drive-by" edit; the user who put in the {{trivia}} box has made no edits to [[Arthur C. Clarke]] before or since.
Since the article was thus tagged, there have been over 130 edits to the page. At least five of those edits were in the trivia section - plus one edit to remove the nag-box, followed immediately by another edit to put it back in.
So, over nearly six months none of the people who have an actual interest in the Arthur C. Clarke article have been motivated to remove, merge, or rewrite the trivia section in a form acceptable to the policy police.
That's a fact. It shows that the "consensus" is a myth.
Rubbish. This edit put the lie to the fire - notice the revision is 8th October 2006. Thanks - that's even better. The policy has existed for over a year, then, not just a few months. Yet no one wants to see it enforced except a handful of people in the policy discussion areas.
In case you missed it, the point of my message was that someone or something who is not a regular editor of the articles in question has gone around and inserted annoying little nag-boxes into tens of thousands of articles - nag-boxes which are generally ignored by the real editors of those articles, who don't agree with the false consensus that trivia has to go.
The trivia sections continue to exist, in spite of the pissy little boxes, because people like trivia sections, and there was never a 'consensus' against them.
One thing I would like to point out is that list of information is frowned upon by many, many Wikipedians. Trivia sections are generally disliked... Are they?
Trivia sections have the support of many, many Wikipedians, as is evidenced by the large number of them that exist and continue to exist.
Some months ago, it was decided by a tiny percentage of Wikipedia editors - those who take part in the policy discussions - that trivia sections were to be marked as discouraged. In thousands (tens of thousands?) of articles, someone inserted a little box in the trivia section saying that trivia sections were discouraged.
For most of the editors who actually work on the articles in question, this was the first time we were aware that there was a crusade to eliminate trivia.
And months later, those boxes are still there, and so are the trivia sections. It seems that the people who actually edit articles don't take kindly to random persons coming in and barking orders about how to edit an article. We scroll right past those annoying little boxes and continue to edit and add to the trivia sections.
So much for "consensus". Consensus on wikipedia is a sham - it means consensus among people who spend their time reading and editing WP:* pages, not among the community as a whole.
It's far easier to write a list of points than it is to carefully incorporate the information into prose. We don't want to encourage that sort of thing. The "In popular culture" and "trivia" sections are loose collections of facts about the subject, or references to it in other media. Converting a list into a paragraph would make it almost unreadable. If I want to find out what television shows were filmed in a particular location, for example, a list is by far the best way to present this information.
Speaking as a graveyard connoisseur...
on
Video Tombstones
·
· Score: 1
...I think it's an incredibly bad idea.
Putting playback devices on the stones will detract from the historic appearance of graveyards by making them look "too high-tech".
The screens will be prone to vandalism, accidents, and damage by weather. Why pay hundreds (if not thousands) of dollars for something that will almost certainly be smashed, faded or waterlogged within ten years?
Putting screens on individual monuments is a colossal waste of resources.
A far better approach would be to put a kiosk in each cemetery, protected from weather and vandals. Visitors would key in the name of the person whose video clip they want to view; it would then be fetched across the network (from on-site or off-site servers that are backed up regularly) and displayed. Large cemeteries could have multiple kiosks, perhaps scattered throughout the grounds.
The interiors of community mausolea would be ideal places for such playback devices.
This would be far cheaper, and eliminate the danger of the only copy of your video being lost when the screen on your monument gives up the ghost.
the scientists and engineers working on the problem are being impeded by almost hourly calls from President George W. Bush.
Although they have patiently explained to him dozens of times why his idea won't work, the president cannot understand why they won't follow his suggestion: to simply have the astronauts "get out and push".
I photograph graveyards using a Nikon D100 camera body, which on the medium quality setting produces 1.5-2MB JPG's. On a good day I'll shoot six to seven hundred images - 2 CD's worth. As I want these photos to survive my own death and someday be on file in the local historical society, I'm very concerned about their longevity.
Each night after I return from a photo expedition, I'll immediately copy the contents of the compact flash cards onto my Windows machine. They are stored there with a minimum of organization - just a directory named for the date. I then FTP them to the Linux machine, leaving a copy behind (plenty of disk space on the Windows machine).
On the Linux machine, on a 160GB disk that's used for almost nothing else, I'll sort the day's photos by location, putting them in subdirectories and adding a prefix to each filename based on the location (but leaving the image's original sequence number intact); this ensures that every file has a unique name even if the directories are munged together - something like "calvary/calvary7932.jpg"). I'll then group these directories together into lots of slightly under 650MB - depending on productivity, one day's work will fill either one or two CD's - write a text file as an index for each, and burn them.
My shell script wrapper for cdrecord will mount and list the contents of the disk after the burn is complete, allowing me to visually verify that it was successful. This has been useful, as on at least two occasions cdrecord recorded success but the disk would not mount.
At least five copies will be made of each, on different manufacturer's media, and stored in different locations. Currently, the media I'm using are Sony, Memorex, K-Hypermedia, Maxell Black, and Maxell Pro. These last are much more expensive but promise superior quality - time will tell if this is true.
The disks are stored in several locations - one copy of each into a sleeve in a binder, other copies storied upright in slim cases in various lightproof CD drawers in different rooms; a complete set is also at my parents' house in another city, and a friend in a nearby town will also be hosting a copy as soon as I drive out there with it.
I have a strict rule - no matter how tired I am, the Flash cards do not get erased until after I have written and verified at least one CD.
The images also remain on the 160GB drive in their original forms, and also in a parallel directory structure where everything has been resized (via shell scripts invoking gimp) to 600x400.
By next year I'll likely acquire a DVD-writer and make additional copies on DVD, again with the quintuple redundancy on different manufacturer's media. Five dollars isn't too much to spend to ensure the survival of a full day's work!
And a few years later, the process will be repeated with whatever replaces DVD's...
This isn't directed at you, but I'm still stumped over why people get their undies in a bunch over the smaller sensors.
The loss of the wide angles can be a problem. In some locations - such as across the street from a historic building - there just isn't any more room to back away from the subject and still get it all in. I've had to buy an 18mm lens (at $450) just to try to get back some of what I've been missing.
The other effect of the smaller image sensor is that the viewfinder image has been cropped to match. The image in the viewfinder is about half the area that it should be - making small details much harder to spot.
I use a D100 and an N90. The vast majority of my shots are done with the D100 and a 28-105 lens. I've found myself taking many more pictures than ever before, now that the incremental cost of each is essentially zero. I'll switch to the N90 when I need the width (it usually has a 18-35mm lens attached), or on those rare occasions where I need to use a shift lens.
Whenever I pick up the N90, I find myself wishing I could use it all the time. The viewfinder image is twice the size of the D100; bright, sharp, and clear. I can easily spot ugly background details that might ruin the picture, and would have been unnoticeable in the tiny D100 viewfinder.
The N90 is a delight to use; the D100 is a convenience. Still, it was a worthwhile investment - I've taken nearly 5,000 photos with it in the past three months, and it has more than paid for itself in saved film processing costs.
I explore and photograph graveyards. I've been to about 120 in Cook County, Illinois, and perhaps 40 or so elsewhere.
With the exception of the modern "memorial park" cemeteries, something interesting can be found in nearly any cemetery. Even the smallest is likely to have something - I particularly like discovering hollow monuments made of zinc hidden away in small urban graveyards.
Of course, there is a geek side to this as well - cameras and lenses are as much a high-tech device as any computer, more in the field of optics than electronics. Primarily, I use Nikon D100 and N90 bodies with a Nikon 28-105mm lens; I have 18-35mm and 70-210mm lenses, and a 35mm shift lens as well.
Still, the technology is not my primary focus; it is merely a tool to be used in collecting and preserving the images of graveyards before they are gone.
My book, "Graveyards of Chicago", can be found on Amazon; and my website is graveyards.com
Does a person registering within.name get full control of an actual domain - with the ability to create usernames at will, change the nameservers, etc.?
Someone buying "john@smith.name" owns only an email address within a domain he doesn't control. "john.smith.name" is a bit better - if this is actually a domain name that they'll have full control over. If it's just an "A" record in your server, it's not a good deal.
These names have less value than any other domain. I initially registered "hucke.org", years ago, so I could have "matt @ hucke.org"; since then, I've given email addresses within that domain to my mother and brother, at no additional cost. I still pay only $13.50 a year for that domain, regardless of how many addresses or subdomains I create within it. Can john@smith.name do that?
"John Smith" may have a slightly better chance of getting john@smith.name than he would johnsmith.org - but that remains true only as long as.name remains unpopular. If.name domains ever did become popular, you'd suffer from the same unavailability of names as anywhere else.
And john@smith.name still can't add an address for his wife or mother without having to pay an additional fee.
For $19.95 a year, you're delivering a product with *less* value than registrars in other TLDs.
Slashdot Mirror
Perhaps I'm embittered after too much DailyWTF reading - there are a lot of idiots in our trade.
I wish it were true that every programmer, laid off in the recession, would seek to use his free time in a way that contributes to society - or at least to his own career growth. Sadly, this won't be the case; many will spend the next year watching TV and raiding dungeons, and not learn a thing.
A laid-off person needs to consider his future. Open Source participation is one of the best ways to ensure that, when the depression finally ends, such a person can still be considered a programmer.
Likely, some of those who have lost their jobs will moan that they don't have time to work on open-source projects; they'll move into their parents' basements, read job postings on Craigslist and send off a few dozen resumes each day, then spend the rest of their time playing World of Warcraft.
These people are losers. They weren't going to work on open-source projects anyway, so a recession and layoff doesn't make a bit of difference to their usefulness to the world. It just gives them more time for World of Warcraft.
For the rest of us, though, a layoff would be an opportunity to learn and to create. Job-hunting does not take eight hours a day - especially in a weakened job market, when few interviews are being granted. Does anyone really expect to go to four interviews a day? If things really tank, you'll be lucky to get one or two interviews a week. Mailing out resumes and reading advertisements doesn't take more than a few hours a day. What is a laid-off programmer going to do with the rest of the day?
The good ones will still be programming. Learn a new language or framework; study for certifications; work on an open-source project. All of these things will make the person more marketable.
(There are exceptions, of course. People with no savings and no family or friends who they can move in with might have to work twelve hours a day slinging hamburgers.)
When the job market improves, what will you say to a hiring manager at an interview about the missing year on your resume? "I learned Ruby and Haskell, and contributed Feature X to Project Y" or "I sent out lots of resumes and no one was hiring. But I got my Arch-Druid to level 80!"?
I'll be at Grant Park next Tuesday night, so I expect to learn the election results direct from Senator Obama's mouth to my ears (albeit through a series of loudspeakers mounted above the stage, most likely).
The mood of the crowd will be an indicator of how things are going early in the process, with cheers for each state where Democrats are victorious, and sadness whenever a state goes red.
We were specifically hiring Java programmers for web applications - so an answer of "I don't know Java or HTML" would have been an immediate no-hire.
There weren't questions about other languages on the exam, as $BigCompany had decreed that all development was to take place in Java henceforth.
During the interview, though, I asked about other languages - if the candidate had worked with multiple languages, then it was a mark in their favour - they weren't a "one-trick pony".
While I do believe a written test is a valid method of sorting out the undesirables, giving you one the minute you walked in the door was just plain rude.
At $BigCompany, where I worked for several years and had a title with the word "Senior" in it, I wrote a test with about thirty questions about HTML, Java, Unix, and general computing. We had to do this after hiring several horribly underqualified candidates, whose resumes were filled with bullshit and outright lies. (Such as the guy who "ran his own ISP", and was hired - we later discovered he merely had a web site to which the real ISP had given him a "Control Panel").
Eventually, our method was to receive about 10-15 resumes from HR, call in the best six or so, and have an interview with both a manager and one or two technical people (me, usually). Only after the interview was finished, we'd give the candidate the written test, and suggest to them that it should take about a half hour to complete.
We'd do this even if the candidate had revealed himself to be completely unsuitable in the oral interview - this was done mainly so that we'd have something to show to our HR person, who was annoyed that we rejected so many of the "good" candidates she sent.
I'd go back in the conference room after twenty minutes - sometimes the candidate was visibly shaken, having failed to answer anything correctly. These were invariably people who had been sent by one of several big contracting companies who our company had a "preferred vendor" relationship with.
On several occasions, my manager told me had really been impressed with the candidate during the interview, and would have hired them had it not been for their wretched performance on the test - and realized now that we had "dodged a bullet" there.
The test wasn't difficult. The questions were like:
"which of the following is a valid HTML link: (multiple choice: A HREF=foo, A SRC=foo, LINK ADDRESS=foo, PAGE LINK=foo)
"write the HTML for a table with two cells, one cell having a yellow background"; [As it wasn't machine graded, any of several ways to do this were acceptable... I'd accept just about anything that had TR's and TD's in it.]
"here is a database table EMPLOYEE [layout and rows of data shown], write the SQL to get the name and salary of employee #6";
"spot two errors in this snippet of Java" [one was obvious, one less obvious but not particularly subtle].
"what does the Unix command 'ls' do?"
Scores in the 25% range weren't uncommon. Those who we did hire generally had 75% or more correct, and some scored above 90%.
Some people in this thread might be offended by such a test. But in the corporate IT world, we just don't run into many like that... the vast majority of candidates we received for our openings were simpletons whose competence had been exaggerated by their contracting companies (one with a three-letter acronym in particular). We weren't looking for superstars; our goal was to separate the liars and time-wasters from the competent craftsmen, and for this the test worked very well.
wonderful - that leaves more job openings available for those of us who are willing to prove ourselves. Thanks for weeding yourself out!
What they found is Illudium Q-36, a key component of the "Explosive Space Modulator". The president needed to be briefed so he could begin an invasion - it's an election year, after all, and Republican chances depend on a quest for fictional weapons of mass destruction.
I worked for a company that was destroyed by a bad coding standard.
This was a small company, that, back in '96, was awarded the contract for a POS application for a regional store chain, with back-office servers that would be updated nightly by modem.
The guys who ran the company weren't programmers (though one of them knew enough to be dangerous); they were technical salesmen. They were also big fans of Microsoft, with "MVP" plaques on the walls, and every employee except me having Microsoft certs.
I worked for them part-time while also working for another company. I advocated Unix (mostly BSDI and SunOS at the time), and always argued with them about why Unix was better (technical superiority vs. potential for big profits).
When their big project was well underway, they brought me in to do the communications part of it, where the POS terminals would contact one of several servers by modem each night ("why not just ethernet them together, get a dialup PPP connection, and use IP? the interface is so much more reliable..." Request denied).
The app was Visual Basic, with third-party "custom controls" for things like talking to modems. My part went fairly smoothly, and I was eventually asked to help out with the main application, which was suffering from unexplained crashes. When I looked at the code, I found something... strange.
For error handling, they had elected to use a program called "VB Rig" (the name came from the rigging used on sailing ships, which prevents a sailor from falling to his death. Sometimes.) What this program did was to examine the source code, and then add error handling boilerplate at the start and end of each and every function. It inserted the exact same error handling code into every function.
Because the error handler had to be all purpose, it was about 20 lines of code per function - sometimes much larger than the regular part of the function. And, worse, because it was the same for every function, and it made use of the same variable names, that meant either every variable had to be global, or you'd have to declare the ten or so standard variable names at the start of every function (they opted for the "everything is global" approach).
Which led to things like this (forgive the syntax errors, it's been years since I've touched VB):
On Error goto my_data_file_read_function_VBRIG_TRAP
open MyDataFile for writing ...
goto my_data_file_read_function_VBRIG_CLEANUP
my_data_file_read_function_VBRIG_TRAP:
on error 101 'Permission Denied
delete MyDataFile
resume
on error 102 'File Not Found
MessageBox 'Cannot read ' + MyConfigFile
resume
my_data_file_read_function_VBRIG_CLEANUP:
blah blah
my_data_file_read_function = SUCCESS ' return
As you see, the error handling code - which had to be exactly the same for every function - made use of global variables (names like DataFile1, MyFile1, UserName, etc.) to figure out what to do for each error. That meant, that if there was any possibility you might have a "File Not Found", you had to expect the filename where that might happen to be in a particular global variable - say, MyFile1 - and hope that the calling function wasn't using that name too, for the same reasons.
Naturally, files were being created and deleted at random, and the programmers often spent hours on the phone with the customer trying to figure out why the Access database had disappeared *again*.
I asked if we could just write the error handling by hand, and use appropriate local variables; or take the standard VBRig error handling and trim out the lines that weren't relevant for a particular function (as subsequent VBRig runs wouldn't touch its code region if it saw that it had been customized).
Request Denied. "This is our coding standard. We carefully reviewed the options before making the decision to use t
I didn't have anything on those disks that was *really* sensitive - at most, a few credit card numbers that were probably expired already. Smashing the circuit board is just to deter casual scavengers.
A while back, I disposed of some drives - mostly unreadable - that might have once contained confidential information (they came from an employer who did a lot of credit card transactions).
step 1: slam against concrete floor repeatedly, until hearing bits shake about inside.
step 2: with the claw-end of a hammer, smash the exposed circuit boards.
step 3: submerge drives in a bucket of salt water for a month.
step 4: put drives in Hefty bag and cover with cat litter and cat shit (a psychological barrier to deter exploration of the bag's contents).
step 5: city dumpster.
Probably overkill - but it was fun.
But deletionist votes seem to always be counted, even if they're from people whose only interest seems to be deletion. Someone could go through the entire AfD list on a particular day, vote "delete" on every article (on subjects they might not have ever heard of before), and their statements will be given more weight than those of persons who truly have an interest in the subjects in question.
The process is rigged, and rigged in such a way that destruction is easier than creation.
I love Wikipedia. I use Wikipedia every day. I've written articles, and uploaded numerous photos. I've installed the software on two of my own sites. I donated to WikiMedia last year.
But this year, I will not be making a donation, as a protest against deletionism, against false claims of "consensus", and against an ivory-tower elite who try to impose the will of a small fraction of the community onto articles that they had nothing to do with. The administrators need to be sent a message: "consensus" doesn't just happen on policy discussion pages, it comes from the bottom up.
"Caught out"? Are you trying to call me a liar? (I guess you're not a believer in WP:AGF)
Here, I'll "check the facts":
http://en.wikipedia.org/w/index.php?title=Special:Whatlinkshere/Template:Trivia&limit=5000
There's a sample of five thousand articles that still have your little anti-trivia boxes nagging the editors to "fix" trivia sections. Press "Next 5000" to see the other half of the list.
The facts show that plenty of editors are ignoring the trivia nag-box.
Let's take one of these articles as an example - I chose the first one on that page that was about a subject I'm interested in:
http://en.wikipedia.org/wiki/Arthur_C._Clarke
According to the history page for that article, the article was tagged with the {{trivia}} template on 10 May 2007. That was nearly six months ago. It was a "drive-by" edit; the user who put in the {{trivia}} box has made no edits to [[Arthur C. Clarke]] before or since.
Since the article was thus tagged, there have been over 130 edits to the page. At least five of those edits were in the trivia section - plus one edit to remove the nag-box, followed immediately by another edit to put it back in.
So, over nearly six months none of the people who have an actual interest in the Arthur C. Clarke article have been motivated to remove, merge, or rewrite the trivia section in a form acceptable to the policy police.
That's a fact. It shows that the "consensus" is a myth.
In case you missed it, the point of my message was that someone or something who is not a regular editor of the articles in question has gone around and inserted annoying little nag-boxes into tens of thousands of articles - nag-boxes which are generally ignored by the real editors of those articles, who don't agree with the false consensus that trivia has to go.
The trivia sections continue to exist, in spite of the pissy little boxes, because people like trivia sections, and there was never a 'consensus' against them.
Trivia sections have the support of many, many Wikipedians, as is evidenced by the large number of them that exist and continue to exist.
Some months ago, it was decided by a tiny percentage of Wikipedia editors - those who take part in the policy discussions - that trivia sections were to be marked as discouraged. In thousands (tens of thousands?) of articles, someone inserted a little box in the trivia section saying that trivia sections were discouraged.
For most of the editors who actually work on the articles in question, this was the first time we were aware that there was a crusade to eliminate trivia.
And months later, those boxes are still there, and so are the trivia sections. It seems that the people who actually edit articles don't take kindly to random persons coming in and barking orders about how to edit an article. We scroll right past those annoying little boxes and continue to edit and add to the trivia sections.
So much for "consensus". Consensus on wikipedia is a sham - it means consensus among people who spend their time reading and editing WP:* pages, not among the community as a whole. It's far easier to write a list of points than it is to carefully incorporate the information into prose. We don't want to encourage that sort of thing. The "In popular culture" and "trivia" sections are loose collections of facts about the subject, or references to it in other media. Converting a list into a paragraph would make it almost unreadable. If I want to find out what television shows were filmed in a particular location, for example, a list is by far the best way to present this information.
...I think it's an incredibly bad idea.
Putting playback devices on the stones will detract from the historic
appearance of graveyards by making them look "too high-tech".
The screens will be prone to vandalism, accidents, and damage by
weather. Why pay hundreds (if not thousands) of dollars for something
that will almost certainly be smashed, faded or waterlogged within
ten years?
Putting screens on individual monuments is a colossal waste of resources.
A far better approach would be to put a kiosk in each cemetery,
protected from weather and vandals. Visitors would key in the
name of the person whose video clip they want to view; it would then
be fetched across the network (from on-site or off-site servers
that are backed up regularly) and displayed. Large cemeteries
could have multiple kiosks, perhaps scattered throughout the
grounds.
The interiors of community mausolea would be ideal places for such playback devices.
This would be far cheaper, and eliminate the danger of the only
copy of your video being lost when the screen on your monument gives
up the ghost.
the scientists and engineers working on the problem are being impeded by almost hourly calls from President George W. Bush.
Although they have patiently explained to him dozens of times why his idea won't work, the president cannot understand why they won't follow his suggestion: to simply have the astronauts "get out and push".
The tours are full - no more registrations are being accepted.
The answering machine on the phone number given in the Sun-Times article indicates that there is no more space available.
I photograph graveyards using a Nikon D100 camera body, which on the medium quality setting produces 1.5-2MB JPG's. On a good day I'll shoot six to seven hundred images - 2 CD's worth. As I want these photos to survive my own death and someday be on file in the local historical society, I'm very concerned about their longevity.
Each night after I return from a photo expedition, I'll immediately copy the contents of the compact flash cards onto my Windows machine. They are stored there with a minimum of organization - just a directory named for the date. I then FTP them to the Linux machine, leaving a copy behind (plenty of disk space on the Windows machine).
On the Linux machine, on a 160GB disk that's used for almost nothing else, I'll sort the day's photos by location, putting them in subdirectories and adding a prefix to each filename based on the location (but leaving the image's original sequence number intact); this ensures that every file has a unique name even if the directories are munged together - something like "calvary/calvary7932.jpg"). I'll then group these directories together into lots of slightly under 650MB - depending on productivity, one day's work will fill either one or two CD's - write a text file as an index for each, and burn them.
My shell script wrapper for cdrecord will mount and list the contents of the disk after the burn is complete, allowing me to visually verify that it was successful. This has been useful, as on at least two occasions cdrecord recorded success but the disk would not mount.
At least five copies will be made of each, on different manufacturer's media, and stored in different locations. Currently, the media I'm using are Sony, Memorex, K-Hypermedia, Maxell Black, and Maxell Pro. These last are much more expensive but promise superior quality - time will tell if this is true.
The disks are stored in several locations - one copy of each into a sleeve in a binder, other copies storied upright in slim cases in various lightproof CD drawers in different rooms; a complete set is also at my parents' house in another city, and a friend in a nearby town will also be hosting a copy as soon as I drive out there with it.
I have a strict rule - no matter how tired I am, the Flash cards do not get erased until after I have written and verified at least one CD.
The images also remain on the 160GB drive in their original forms, and also in a parallel directory structure where everything has been resized (via shell scripts invoking gimp) to 600x400.
By next year I'll likely acquire a DVD-writer and make additional copies on DVD, again with the quintuple redundancy on different manufacturer's media. Five dollars isn't too much to spend to ensure the survival of a full day's work!
And a few years later, the process will be repeated with whatever replaces DVD's...
Codpiece.
I had a jar for backup and ended up just tossing it into the trash.
That's because "jar" isn't for backup. "tar" is for backup; "jar" is for packaging java applications.
UIC = Univ. of Illinois, Chicago? If so, I can give you some older stuff - contact me as hucke@cynico.net.
The loss of the wide angles can be a problem. In some locations - such as across the street from a historic building - there just isn't any more room to back away from the subject and still get it all in. I've had to buy an 18mm lens (at $450) just to try to get back some of what I've been missing.
The other effect of the smaller image sensor is that the viewfinder image has been cropped to match. The image in the viewfinder is about half the area that it should be - making small details much harder to spot.
I use a D100 and an N90. The vast majority of my shots are done with the D100 and a 28-105 lens. I've found myself taking many more pictures than ever before, now that the incremental cost of each is essentially zero. I'll switch to the N90 when I need the width (it usually has a 18-35mm lens attached), or on those rare occasions where I need to use a shift lens.
Whenever I pick up the N90, I find myself wishing I could use it all the time. The viewfinder image is twice the size of the D100; bright, sharp, and clear. I can easily spot ugly background details that might ruin the picture, and would have been unnoticeable in the tiny D100 viewfinder.
The N90 is a delight to use; the D100 is a convenience. Still, it was a worthwhile investment - I've taken nearly 5,000 photos with it in the past three months, and it has more than paid for itself in saved film processing costs.
I explore and photograph graveyards. I've been to about 120 in Cook County, Illinois, and perhaps 40 or so elsewhere.
With the exception of the modern "memorial park" cemeteries, something interesting can be found in nearly any cemetery. Even the smallest is likely to have something - I particularly like discovering hollow monuments made of zinc hidden away in small urban graveyards.
Of course, there is a geek side to this as well - cameras and lenses are as much a high-tech device as any computer, more in the field of optics than electronics. Primarily, I use Nikon D100 and N90 bodies with a Nikon 28-105mm lens; I have 18-35mm and 70-210mm lenses, and a 35mm shift lens as well.
Still, the technology is not my primary focus; it is merely a tool to be used in collecting and preserving the images of graveyards before they are gone.
My book, "Graveyards of Chicago", can be found on Amazon; and my website is graveyards.com
Does a person registering within .name get full control of an actual domain - with the ability to create usernames at will, change the nameservers, etc.?
.name remains unpopular. If .name domains ever did become popular, you'd suffer from the same unavailability of names as anywhere else.
Someone buying "john@smith.name" owns only an email address within a domain he doesn't control. "john.smith.name" is a bit better - if this is actually a domain name that they'll have full control over. If it's just an "A" record in your server, it's not a good deal.
These names have less value than any other domain. I initially registered "hucke.org", years ago, so I could have "matt @ hucke.org"; since then, I've given email addresses within that domain to my mother and brother, at no additional cost. I still pay only $13.50 a year for that domain, regardless of how many addresses or subdomains I create within it. Can john@smith.name do that?
"John Smith" may have a slightly better chance of getting john@smith.name than he would johnsmith.org - but that remains true only as long as
And john@smith.name still can't add an address for his wife or mother without having to pay an additional fee.
For $19.95 a year, you're delivering a product with *less* value than registrars in other TLDs.
No, the best beer in the world is Chimay Grande Riserve ("Chimay blue label").