How specific are the requirements (skills and experience) that you're looking for?
Are you inadvertently/unconsciously subtracting folks from consideration early in the resume evaluation process that might be able to do the job effectively?
Is this a long-term position (where some training is viable), or a short-term one where a drop-in employee is vital?
Many employers cause their own "talent shortages" due to overprecision or simple overoptimism when drafting job requirements.
If your stated requirements are unrealistically high, you'll cut down the number of responders overall and probably increase the number of responders who are willing to pad their resumes just to get in the door. Fewer hits, and even fewer genuine candidates.
By "need people who are really good" I think you mean "want people who have a precise match with their organization in terms of both technical and Line-Of-Business experience".
If you've been in the job market at all in the past five years, you would realize that it isn't about generalized ability or skills anymore. It's about being lucky/resourceful enough to match the keyword lists being generated by HR, or lucky/resourceful enough to be able to cut through the HR maze and deal directly with the technical manager.
If the economy is so great, why are so many former programmers and sysadmin types working at my wife's place of employment (a call center) for $12-15/hour?
Cross-sector numbers across an entire country are one thing, accurate numbers pertaining to a specific industry and location are quite another...
The mainframe (Unisys TIP) transaction environment I worked in at NWA had only two ways for F66 programs to generate trace output -- you could stick a CALL DUMPER statement in to dump 1-to-n words of a buffer in octal, or you could stick a CALL DMPFLD statement in to dump 1-to-n words of a buffer in FIELDATA text. There was no CALL PRTADP equivalent (for those familiar with the Unisys USAS environment).
The end result was single 132-column print file containing a bunch of blocks of octal or FIELDATA information (each with at most a 6-character label) sitting in a print file.
Both dumping methods had serious disadvantages. Reading raw octal isn't fun, and neither format would give you relative word offsets (just raw memory addresses) so on long dumps it was hard to figure out where you were in a given buffer without doing a certain amount of math and counting on a 132-column printout, and in general it could be a lot better. It was also hard to read on an 80-column terminal (some viewers would wrap it, others would simply truncate the stuff beyond column 80). So I decided to write a dumper decoder to make things a lot more readable.
One of the nice things about the TIP online transaction environment is the fact that you can write batch programs which aren't really online transactions, but which can connect to TIP anyway and use TIP services.
We had a fairly large library of utility subroutines out there that could decode a word of data in various ways. We had specialized formats for storing a binary date+time (ACCMIN), storing a binary flight+date, and various other special formats, and these routines would decode a word of otherwise obfuscated information and make it nice and easy to read.
I wanted to be able to display those suckers in human-readable decoded format underneath the original octal words if I could detect the presence of a specialized data field, and I also wanted to frame the FIELDATA output from PRTADP statements in such a way that it would be obvious which words you were looking at in the trace.
I also wanted to write a nice front-end for the thing which detected various options on the command line and presented the information in a nice fullscreen viewer on the mainframe.
For this project, I created two parts:
(1) a FIELDATA FORTRAN V batch TIP program which could read the raw trace file containing the trace information to be decoded, which could connect to TIP, which could tap into the nice utility library, and which could generate a nice formatted report to a file.
(2) a CALL macro front-end which could be called from a command prompt, solicit input from the user, interpret options, and effectively drive the above F66 program, then read the resulting output and present it to the user in a nice fullscreen viewer so they could page and/or search through it however they wanted.
The problems:
(1) FORTRAN V programs could only read/write 6-bit FIELDATA. I also didn't know how to create a FORTRAN program that I could call directly from the command line. Oops!
(2) CALL macros were easy to write and were made to be run from the command line, but they could only write 9-bit ASCII files (though they could *read* both ASCII and FIELDATA).
(3) There was no way to directly link the two together (CALL macros are self-contained interpreted macros, and they don't have any way to directly call a program which is written in another language, or even residing in another CALL macro source file!).
The ugly solution: I had the CALL macro write an ASCII COMMAND file, then kick off a breakpointed runstream (whose execution was hidden from the user) which called the ED line editor to convert the command file to FIELDATA so the FORTRAN program could read it. That's roughly the same as piping it to the line editor, I guess, but a lot uglier.:-) Then, it kicked off a second runstream to run the FORTRAN decoding program and sat around waiting for the FORTRAN program to terminate. Again, the execution of t
The main point it that I'm using a standards-compliant browser which is a bit non-mainstream but which is also still viable with almost all of the modern news-related web sites I've seen.
Unfortunately, Slashdot has been leading the way in moving away from usability with such browsers, and their newest direction doesn't do anything to improve that standing.
I use Links "because I can", and that should be enough reason. With a well-designed web site, even one that uses CSS, it would be a nonissue. With Slashdot, it's becoming a problem.
Tables suck in most Lynx variants, but they rock in Links (really), as do frames.
The presence of proper support for those two items in Links is the biggest reason I abandoned Lynx in the first place. It's a very different browsing experience, and since you can also use a mouse with it in fullscreen Linux or OS/2 consoles it's even point-and-clicky if you want it to be.:-)
Links is getting more and more limited by the day, and, effectively dying.
My comments were really about the pre-CSS site versus the newer incarnations, and also about the fact that these newer CSS variants to little or nothing to improve the situation for non-CSS browsers. Thus, while your comments about CSS changes are correct, they have little to do with the main thrust of my complaint.
Sadly, however, I have to agree with almost everything else that you say. Links is effectively dying even though it's effectively a best-of-breed browser.
The sad part of it, though, is the fact that web site designers *could* choose to continue to support it while also using things like CSS. All it takes is a little focus while testing to see how a page looks in a non-CSS browser. And a site like Slashdot could easily be a shining example of how to do that. It's a technology-conscious site.
Unfortunately, like the KDE developers, the folks at Slashdot seem more interested in flash than functionality.
The main Slashdot page certainly works with text browsers, but it isn't convenient.
You have to compare the current version to the pre-CSS version (which looked and felt almost exactly the same on text-mode as it did on GUI-mode) in order to understand the main thrust of my disappointment in Slashdot's direction.
The current (and apparently future) versions of the site are a huge downgrade by comparison, and for very little relevant functional gain that I can see. YMMV, etc.
Indeed? I'm not sure why you care about my reading here. Now, my *WRITING* here might be an issue at times.:-)
(The Slashdot image server apparently had some issues for a while, meaning that the required titlebar arrow images and certain elements of totlebar functionality were not being served to browsers. That made it a whole lot harder for us to accurately evaluate the new UI entries.)
The arrows were not visible (and those areas of the headers were not clickable) for quite some time. It makes a big difference when they're actually visible (and usable).
It makes the pages portable to that subset of browsers which understands CSS.
The old site (pre-CSS) was far more readable (and hence usable) on a much larger selection of web browsers. CSS dependency is a downgrade. Intelligent design can offset much of that, but it doesn't seem to be a priority here. I have to page down 5-6 pages on the main page to get to any context, and that's a royal pain in the ass.
Nope. I dropped lynx years ago. Links is a completely different text-based browser that shows things like tables and frames in a proper way, which makes some attempt to match text colors, and which (in some variants) also has a GUI display so images and other things are present just like they are in the Big Boys.
Here's an example of www.osnews.com being viewed by Links via PuTTY on a SunOS server:
I've personally used Links under OS/2, Linux, and Solaris with some regularity, and also on BeOS from time to time. It's a really nice browser for what it does. Except on Slashdot.
It's true. I also use a text command-line in 2006 to do both development and administrative functions, and I write these funky things called "shell scripts" on occasion. I even use a vanilla (non-VIM) version of vi on occasion.
Not everyone is interested in loading up multi-MB flashy megabrowsers all the time. If I'm already doing something in a fullscreen console and want to quickly check things out on the web, I can do it with VERY little difficulty on sites such as Google or Yahoo News, OSNews, Groklaw, the various newspaper sites that I read, etc.
Only Slashdot has become unwieldy in such a browser over the past couple of years, and that was mainly due to its switch to the first CSS-based UI (sometime I saw as a complete waste of time which resulted in more browser incompatibilities and usage barriers than it gained).
Slashdot is a text site. TEXT. The main content here is textual news items and a series of forums with a very simple tree structure. It doesn't need all this fancy crap to work, and yet it foists that type of thing upon its users without giving us the option to use a much simpler UI. And yes, I know about the "light" interface. Try using it to bounce between stories and you'll know how worthless it is!
A technie site that doesn't cater to techie users. That's what slashdot has become. It used to be that webnmasters and site designers took pride in creating sites that were usable by even non-mainstream users, but no longer...
One could make the argument that the average airline pilot "deserves" the money they make a lot more than many professional sports players and/or CEOs do.
I don't (Firefox 1.5.0.3 under XP Pro), and I don't see anything resembling collapsable sections in the winner's design either. Something else must be amiss.
My main concern, though, is that these "advanced" interfaces are making Slashdot harder and harder to read in browsers like Links. It used to be totally text-browser friendly, but that is no longer the case. Sad for a so-called techie site...
That's why we thought "Why work our asses off in high school when we could ace the SAT or ACT and get into college that way (with an okay-but-not-stellar high school GPA)?"
Folks we knew who had already been to college told us (and it was true) that your high school GPA typically isn't relevant after you've been accepted into a college or university of some sort.
Of course, I realize NOW that it's the actual education in high school which is important, and I was lucky enough to have absorbed there to be of lage benefit regardless of my questionable attitude at the time (taking some AP classes helped in that regard as well), but back then it was mostly a joke for me. I wanted to go to college!
The only thing I regret is not taking a second language in high school. I did in college for a while, but I had a lot of time and brain power that I could have pointed in a more useful direction during my high school years. Earlier, even. But I had no idea that such a thing would have any meaning. The probability of meeting someone in a Minneapolis suburb in the late 70's who spoke another language was fairly low, especially in the areas of the working world I had been exposed to. Because of the internet and other factors, though, that has changed quite a bit!:-)
Slashdot Mirror
How specific are the requirements (skills and experience) that you're looking for?
Are you inadvertently/unconsciously subtracting folks from consideration early in the resume evaluation process that might be able to do the job effectively?
Is this a long-term position (where some training is viable), or a short-term one where a drop-in employee is vital?
Many employers cause their own "talent shortages" due to overprecision or simple overoptimism when drafting job requirements.
If your stated requirements are unrealistically high, you'll cut down the number of responders overall and probably increase the number of responders who are willing to pad their resumes just to get in the door. Fewer hits, and even fewer genuine candidates.
By "need people who are really good" I think you mean "want people who have a precise match with their organization in terms of both technical and Line-Of-Business experience".
If you've been in the job market at all in the past five years, you would realize that it isn't about generalized ability or skills anymore. It's about being lucky/resourceful enough to match the keyword lists being generated by HR, or lucky/resourceful enough to be able to cut through the HR maze and deal directly with the technical manager.
If the economy is so great, why are so many former programmers and sysadmin types working at my wife's place of employment (a call center) for $12-15/hour?
Cross-sector numbers across an entire country are one thing, accurate numbers pertaining to a specific industry and location are quite another...
"Fedora" is a hat. "Ubuntu" is not a hat. ;-)
The mainframe (Unisys TIP) transaction environment I worked in at NWA had only two ways for F66 programs to generate trace output -- you could stick a CALL DUMPER statement in to dump 1-to-n words of a buffer in octal, or you could stick a CALL DMPFLD statement in to dump 1-to-n words of a buffer in FIELDATA text. There was no CALL PRTADP equivalent (for those familiar with the Unisys USAS environment).
:-) Then, it kicked off a second runstream to run the FORTRAN decoding program and sat around waiting for the FORTRAN program to terminate. Again, the execution of t
The end result was single 132-column print file containing a bunch of blocks of octal or FIELDATA information (each with at most a 6-character label) sitting in a print file.
Both dumping methods had serious disadvantages. Reading raw octal isn't fun, and neither format would give you relative word offsets (just raw memory addresses) so on long dumps it was hard to figure out where you were in a given buffer without doing a certain amount of math and counting on a 132-column printout, and in general it could be a lot better. It was also hard to read on an 80-column terminal (some viewers would wrap it, others would simply truncate the stuff beyond column 80). So I decided to write a dumper decoder to make things a lot more readable.
One of the nice things about the TIP online transaction environment is the fact that you can write batch programs which aren't really online transactions, but which can connect to TIP anyway and use TIP services.
We had a fairly large library of utility subroutines out there that could decode a word of data in various ways. We had specialized formats for storing a binary date+time (ACCMIN), storing a binary flight+date, and various other special formats, and these routines would decode a word of otherwise obfuscated information and make it nice and easy to read.
I wanted to be able to display those suckers in human-readable decoded format underneath the original octal words if I could detect the presence of a specialized data field, and I also wanted to frame the FIELDATA output from PRTADP statements in such a way that it would be obvious which words you were looking at in the trace.
I also wanted to write a nice front-end for the thing which detected various options on the command line and presented the information in a nice fullscreen viewer on the mainframe.
For this project, I created two parts:
(1) a FIELDATA FORTRAN V batch TIP program which could read the raw trace file containing the trace information to be decoded, which could connect to TIP, which could tap into the nice utility library, and which could generate a nice formatted report to a file.
(2) a CALL macro front-end which could be called from a command prompt, solicit input from the user, interpret options, and effectively drive the above F66 program, then read the resulting output and present it to the user in a nice fullscreen viewer so they could page and/or search through it however they wanted.
The problems:
(1) FORTRAN V programs could only read/write 6-bit FIELDATA. I also didn't know how to create a FORTRAN program that I could call directly from the command line. Oops!
(2) CALL macros were easy to write and were made to be run from the command line, but they could only write 9-bit ASCII files (though they could *read* both ASCII and FIELDATA).
(3) There was no way to directly link the two together (CALL macros are self-contained interpreted macros, and they don't have any way to directly call a program which is written in another language, or even residing in another CALL macro source file!).
The ugly solution: I had the CALL macro write an ASCII COMMAND file, then kick off a breakpointed runstream (whose execution was hidden from the user) which called the ED line editor to convert the command file to FIELDATA so the FORTRAN program could read it. That's roughly the same as piping it to the line editor, I guess, but a lot uglier.
I'm not blind, but that's not the point.
The main point it that I'm using a standards-compliant browser which is a bit non-mainstream but which is also still viable with almost all of the modern news-related web sites I've seen.
Unfortunately, Slashdot has been leading the way in moving away from usability with such browsers, and their newest direction doesn't do anything to improve that standing.
I use Links "because I can", and that should be enough reason. With a well-designed web site, even one that uses CSS, it would be a nonissue. With Slashdot, it's becoming a problem.
Tables suck in most Lynx variants, but they rock in Links (really), as do frames.
:-)
The presence of proper support for those two items in Links is the biggest reason I abandoned Lynx in the first place. It's a very different browsing experience, and since you can also use a mouse with it in fullscreen Linux or OS/2 consoles it's even point-and-clicky if you want it to be.
My comments were really about the pre-CSS site versus the newer incarnations, and also about the fact that these newer CSS variants to little or nothing to improve the situation for non-CSS browsers. Thus, while your comments about CSS changes are correct, they have little to do with the main thrust of my complaint.
Sadly, however, I have to agree with almost everything else that you say. Links is effectively dying even though it's effectively a best-of-breed browser.
The sad part of it, though, is the fact that web site designers *could* choose to continue to support it while also using things like CSS. All it takes is a little focus while testing to see how a page looks in a non-CSS browser. And a site like Slashdot could easily be a shining example of how to do that. It's a technology-conscious site.
Unfortunately, like the KDE developers, the folks at Slashdot seem more interested in flash than functionality.
Sorry. Your statement pretty much hit it dead on. My mistake.
Thanks. That looks like it might be useful.
The main Slashdot page certainly works with text browsers, but it isn't convenient.
You have to compare the current version to the pre-CSS version (which looked and felt almost exactly the same on text-mode as it did on GUI-mode) in order to understand the main thrust of my disappointment in Slashdot's direction.
The current (and apparently future) versions of the site are a huge downgrade by comparison, and for very little relevant functional gain that I can see. YMMV, etc.
URL? I wasn't aware such a thing existed, to be honest. There are no links to it from either the FAQ or the front page.
Indeed? I'm not sure why you care about my reading here. Now, my *WRITING* here might be an issue at times. :-)
(The Slashdot image server apparently had some issues for a while, meaning that the required titlebar arrow images and certain elements of totlebar functionality were not being served to browsers. That made it a whole lot harder for us to accurately evaluate the new UI entries.)
Let me guess. You work in Best Buy tech support?
The arrows were not visible (and those areas of the headers were not clickable) for quite some time. It makes a big difference when they're actually visible (and usable).
A simple solution. I've suggested it, as I'm sure many other have, and the suggestion seems to have been ignored. So far. :-(
It makes the pages portable to that subset of browsers which understands CSS.
The old site (pre-CSS) was far more readable (and hence usable) on a much larger selection of web browsers. CSS dependency is a downgrade. Intelligent design can offset much of that, but it doesn't seem to be a priority here. I have to page down 5-6 pages on the main page to get to any context, and that's a royal pain in the ass.
On some of the boxes that I admin at home, running X takes up more resources than it's worth.
Nope. I dropped lynx years ago. Links is a completely different text-based browser that shows things like tables and frames in a proper way, which makes some attempt to match text colors, and which (in some variants) also has a GUI display so images and other things are present just like they are in the Big Boys.
Here's an example of www.osnews.com being viewed by Links via PuTTY on a SunOS server:
http://www.visi.com/~rsteiner/links.gif
and the main project site is here:
http://links.sourceforge.net/
I've personally used Links under OS/2, Linux, and Solaris with some regularity, and also on BeOS from time to time. It's a really nice browser for what it does. Except on Slashdot.
It's true. I also use a text command-line in 2006 to do both development and administrative functions, and I write these funky things called "shell scripts" on occasion. I even use a vanilla (non-VIM) version of vi on occasion.
Not everyone is interested in loading up multi-MB flashy megabrowsers all the time. If I'm already doing something in a fullscreen console and want to quickly check things out on the web, I can do it with VERY little difficulty on sites such as Google or Yahoo News, OSNews, Groklaw, the various newspaper sites that I read, etc.
Only Slashdot has become unwieldy in such a browser over the past couple of years, and that was mainly due to its switch to the first CSS-based UI (sometime I saw as a complete waste of time which resulted in more browser incompatibilities and usage barriers than it gained).
Slashdot is a text site. TEXT. The main content here is textual news items and a series of forums with a very simple tree structure. It doesn't need all this fancy crap to work, and yet it foists that type of thing upon its users without giving us the option to use a much simpler UI. And yes, I know about the "light" interface. Try using it to bounce between stories and you'll know how worthless it is!
A technie site that doesn't cater to techie users. That's what slashdot has become. It used to be that webnmasters and site designers took pride in creating sites that were usable by even non-mainstream users, but no longer...
One could make the argument that the average airline pilot "deserves" the money they make a lot more than many professional sports players and/or CEOs do.
I don't (Firefox 1.5.0.3 under XP Pro), and I don't see anything resembling collapsable sections in the winner's design either. Something else must be amiss.
My main concern, though, is that these "advanced" interfaces are making Slashdot harder and harder to read in browsers like Links. It used to be totally text-browser friendly, but that is no longer the case. Sad for a so-called techie site...
That's why we thought "Why work our asses off in high school when we could ace the SAT or ACT and get into college that way (with an okay-but-not-stellar high school GPA)?"
:-)
Folks we knew who had already been to college told us (and it was true) that your high school GPA typically isn't relevant after you've been accepted into a college or university of some sort.
Of course, I realize NOW that it's the actual education in high school which is important, and I was lucky enough to have absorbed there to be of lage benefit regardless of my questionable attitude at the time (taking some AP classes helped in that regard as well), but back then it was mostly a joke for me. I wanted to go to college!
The only thing I regret is not taking a second language in high school. I did in college for a while, but I had a lot of time and brain power that I could have pointed in a more useful direction during my high school years. Earlier, even. But I had no idea that such a thing would have any meaning. The probability of meeting someone in a Minneapolis suburb in the late 70's who spoke another language was fairly low, especially in the areas of the working world I had been exposed to. Because of the internet and other factors, though, that has changed quite a bit!
BSD is designed. Linux is grown. Windows is squeezed through ones rectal canal.
God is REAL unless declared INTEGER. Simple. :-)