My thoughts exactly. But, then again, I'd have to think that the people law enforcement is seeking aren't all that bright to begin with. Even if they used the software, they'd likely ignore its warnings in favour of satisfying their sick cravings.
Indeed, because it's pattern based - it does not automatically assume that the adult is "smarter", but that any person whose communications are too far off the normal curve will, presumably, get flagged. Kids, be like everyone else, or we'll send the SWAT after you! (j/k - I do think this is a good thing)
There are lots of things you can do - many of them depend on exactly who you are (ie. what jobs you're applying for as well as the experience you have), and some on the specific posting / submission engine you're facing.
Terms like "proficient" and "excellent" are usually not needed: you list your skills in order of your abilities - the most proficient are at the top / front of the list, so you can leave out those extraneous words.
Also, a lot of what you write will sound like standard tripe, but that's a good thing ... to an extent. You want to stand out from the crowd, but you also want to demonstrate that you understand the game being played here. In short, your resume should make it as easy as possible for the person reviewing it to match you to the job posting.
An example of where you should follow the same style as others is in using "action words". Don't say you are familiar with / proficient in project management, for example; say you have managed projects [of X size and scope]. Don't say you know Python; say you have contributed to an open source python project (and provide a link!).
Keywords are good. You can adapt / evolve your resume and cover letters based on the words and phrases you're seeing in postings. This is especially important when the target is not an employer, but a recruiter who might not even understand what a "J2EE Deployment Engineer" is, precisely. And how Weblogic is different than JBoss. So use their terminology - it shows you care. In times when I've been looking for work (or even just polishing off my resume for good measure), I start by gathering together a number (say, 20) of postings that sound like jobs I'd like - regardless of whether I'm actually qualified for them. I then look at the phrases and skills they're asking for; which ones are most common, etc.; and start creating a list. I will then review that list, refining it as I contemplate my own skills and experience, and then building up the terminology I'm going to use to describe myself.
Master these things, and then you can start working on how to stand out. I'm going to cut my comment off here for the moment, but here's one more thought: when listing past experience and when writing cover letters, an example can say a thousand things that will expand out your bullet points. As an example, say you're applying for an intermediate programmer job - they're asking for someone who knows php, and is a "front end rockstar" and works well under pressure, blah blah. You start off by saying "I've been building php websites for 5 years." (or whatever) And then you give an example "At my last employer, we were under extreme pressure to deliver a custom solution for a fortune 500 company. After helping our team derive a scalable architecture based on my DAL model, I was given sole responsibility for implementing the UI by building on the originally approved comps." With two sentences like that, you can show that you know your php, that you can handle the deadlines; that you know your way around the back end as well as the front, etc. And, again, provide a link!
HTH ... if you have any other specific points, I'd be happy to give you my $0.02.
I find this a very interesting topic. Character sets and their encodings are usually completely invisible to the end user, and often even to the engineers working on the system. But, when a problem rears its head, it can be nasty.
A great example is certain api calls in legacy Windows code that modify registry keys. Using the legacy api call can lead to a single-byte encoding of the key, making it un-editable by multibyte methods (i.e. the newer methods that are supposed to depricate the old ones). As much as people love to hate on MSFT, I've often felt honest pity for the programmers who have to build on top of 20+ years of code without breaking backward compatibility.
Also, there was an interesting discussion on slashdot recently:
TRWTF is that it took Jobs and Apple's thousands of employees how many years to notice this? Either that, or his answer is pure BS and has nothing to do with why Apple made this decision now.
Either that, or this is all a really highly orchestrated plan of Apple's to phase out official Java support completely after building up a Cocoa developer base. Are there any good numbers on Java desktop applications (aside from Java plugins) vs Java server applications these days? How big of an effect will dropping official "Apple" support complete with UI fancy-ness and some sorta Cocoa bridge? If we have to move to OpenJDK, will server apps really be burned all that much? What exactly is the big deal with having to switch to OpenJDK, anyway? I hear people complain about Apple being behind all the time with Java...isn't this ultimately what people wanted..an up to date Java distribution on OS X?
I wouldn't argue with the notion of Jobs being "delicate", that's for sure. And, apparently same goes with the feelings of the HN crowd toward all things Apple.
I agree. I think HN is becoming a victim of it's own success, and it's UI wasn't built to scale. (aside - that's a challenge to all you folks interested in ux ;) ).
I would say that we definitely need a way of detecting duplicate submissions. And I would also add another suggestion: categories (or tags) for filtering.
