The article writer started out well, and then immediately ignored his own line of thought.
"John Graham-Cumming wrote an article today complaining about how a computer system he was working with described his last name as having invalid characters. It of course does not, because anything someone tells you is their name is--by definition--an appropriate identifier for them."
Yes, in your scope, your name is going to be accurate by whatever cultural, political, legal, optional, character-set or other restrictions or freedoms apply.
However, in the scope of any given app, your name may very well be an 8 character, [a-zA-Z] string. That's what the app means by the name field - by definition.
Naturally, no programmer would use any user-provided input for any sort of unique key ( err... right?)... so really what this is about is that someone did not properly set user expectations, that they may not be allowed to arbitrarily spool data in any format or fashion into any given input field - 'name' in this case.
Or someone already knows that fact, and is ranting because they chose today to ignore it.
Disclaimer: I write financial software for a living.
First, I don't see why OFX can't be used for that purpose. You could manage several hundred accounts, payroll, billpay, collections, wire transfers, funds management, etc. Not only that, it's two-way. It's not just displaying account data, it allows you to perform the actual transactions. I know of some payroll processing centers that use OFX for exactly this - either it goes to printer or it goes electronic.
Second, because there is no salable demand for individuals requesting the raw file formats for the backend transfers, those features don't exist. This is common sense - what motivation exists for a company to spend the time and effort providing a feature if there is no money attached to it.
Third, certification. There is quite a bit of hullabaloo in the banking industry about certification, and they're serious. See, there's not a lot of security in the banking world. They rely on hard connections, network separation, and effectively, trust. What they DO have though, is auditing trails. They might not be able to stop a fraudulent ATM transaction, but they can tell you every node, clearing house, third party processor or financial institution it went through. Certification is the thing that allows them to reasonably trust members in their transactional world - you can't just show up with homegrown software and hook right in.
Last, as you said, "The banking world is awash in data protocols". Lemme tell you something - the raw protocols are only about 1/20'th of what goes on. No protocol is perfect, and many systems have what you or I might consider 'undocumented features' that are handled by clever manipulation of the protocol (aka, hacks). The paper description, for example, of the ACH file format can be compressed into about 6 pages. There is a two volume set of books, each about 300 pages, of small print, so thin as to be nearly transparent pages that actually describes how those 8 pages work.
That's one protocol. There are dozens of major ones, and additional complexities when you add in feature specific cores or sinks (back end systems that banks use to store the actual data on, like those provided by MISER or Fiserv )- do you support overdraft protection, provide memo services (a hold against an account for an amount prior to it's actual processing), and if so, which of the dozen ways do you provide that information?
So in the end; * no real financial benefit to providing that access (especially when you say you don't want to pay XD ) * no certification to provide that access * actual software knowledge requires domain knowledge many magnitudes greater than just file formats, including per-FI non-public knowledge
last and not the least important items not discussed above; * financial institutions are slow movers when it comes to adopting technology. * early adopters are NEVER the small banks, and they always require a hefty ($$$$) reason to include it.
So it could be done - and probably will in the next 20 years or so - but not today....
as an aside,
The reason you'd be getting billed 5 figures for access is because they'd end up assigning someone to manually pull your ACH records out of each daily batch and save them to one side. Manually. They may even need to have someone actually type the new entries in (separation of networks, removable media would be disallowed - of course.)
I've been around for a while, dealt with a lot of code that had a missing developer, and one thing I noted was this simple truth:
Every significantly complex piece of code you didn't write, every system you didn't design is "bad".
It doesn't matter if it's well formed, makes sense, works well together, you'll always find a way to complain about the coding style used, the design choices made, the libraries used or ignored, and until you've sat in it for a while, none of it will make sense to you. Not sure what I mean? Try spending some time in a few of the programming centric IRC channels, and watch everyone rip into someone else's code. The #python channels are especially funny since the loudest individuals there appear to be some sort of religious adherents in the church of python. In general, these folks won't even answer simple questions until the code is reorganized in the manner they're accustomed to.
The thing is, we're all like that. It's the same each time you pick up a new language, or you're tackling a new library. This isn't a web-based phenomenon - this is every piece of code ever, regardless of it's actual quality of lack thereof.
This is the sort of thing that you can't fix with single-vendor lock-in, or strict adherence to protocols, and it's not exacerbated by mixing and matching OSS projects. Inside a given company, it can be regulated to a point by having architectural guidelines, strict coding conventions, and well spread code reviews that ensure conventions are used - but the code will still be 'bad' to people outside the company.
I do have a fix for it, but I don't think the author will like it. You should make sure that YOU as a developer experience as many of the frameworks and languages and systems and such that are out there, continue to expand your awareness of program design from data structures to lifecycle management, and that way, when you experience one of these 'bad' systems, you'll be able to absorb what the previous developer was thinking a little quicker than otherwise.
of course, it could just be terribly written code, and not just subjectively bad, in which case I always end up voting 'slash 'n' burn'.
Is that still true? A decade or so ago it would have been, but we have some bright young programmers who have only seen Pascal (from early training), Java, Python, and C#. Many examples now are in one of these languages or pseudocode.
You're correct - there are programmers who've only seen Java, and it's obvious from looking at their coding style and program structure. I'm not saying that in a complimentary way. Java is the new Basic - If it is your first language, it appears to make you a 'bad' programmer.
I'm still finding people who have no concept of memory usage or code complexity (though less lately).
I'm finding people who use exceptions to pass information, instead of return values (especially after they put the class behind 6 layers of unnecessary abstraction)
I'm finding people who were never taught to check their arguments or perform sanity checking of any type, including checking return values from other methods ('Oh, then it should throw an exception!').
I'm still finding people who don't understand that a design pattern is just a shorthand used to communicate ideas about program design. Sitting through a peer review where you're told "I can't approve this unless you make it clear which design pattern you're using here, and name the class after the pattern" is somewhat infuriating.
I'm not saying these people are not bright. It's just that they don't know any better. Sun did a great job packaging Java as a product with end-to-end ownership from training and certs to support and evangelical positions. They made it much easier to write working code.
Unfortunately, it's that much easier to write bad code that nonetheless, is working code.
... the defining method to determine if a game is an RPG or not is if game engine itself penalize someone by denying access to some game content. No joke:
"Where then does that leave the modern RPG? The game where making choices actually results in missing out on things? The game where you don't get to use the best axe because you're focussing on guns instead? While RPG becomes a modern marketing phrase to slap on titles in the hopes of selling additional units and some companies are making real efforts, the truth is, the core mechanics of the most successful RPGs released by the main-stream developers are becoming less and less RPG like."
Two more gems:
- Games that use the same game engine are not new games, with the implication that they are therefore not worth playing 'again'.
- the claim that any company that produces a game labeled as an RPG will go out of business in short order because of that decision.
I could do a point-by-point, but there's no...erhm... point. I'd just ignore this posting if I were Jeff.
This same sort of process is already used in many different forms for things like job screening - especially for bulk blue collar hires. There are certain statistical trends that just come to the forefront, like "95% of people convicted of drug crimes smoke (tobacco) cigarettes". That doesn't mean that anyone who smokes is a drug user, but statistically, if you don't smoke, it's much less likely that you'll eventually be convicted of a drug crime - so you're a better hire if all else is equal.
From what I've seen, most of these systems are not even real datamining systems - and I worked for 2 years doing real cutting edge datamining with self organizing neural nets and overlaid expert systems to guide 'questions'. Instead, they're summaries. "100 kids were arrested for spraying graffiti. What percentage went on to commit felonies? If % is greater than 50%, flag 'arrested for spraying grafiti' as dangerous". That's as much datamining as using the index in the back of a book.
Instead, most of these systems are just a nice way - as the parent indicates - of letting non-technically-competent ask questions that are converted to an sql query or display a nice graph.
To understand how to get hired, you have to understand how hiring works. Here's a simple 2-step generalization:
Part 1) A great number of companies out there rely on their HR staff to do the hiring and applicant-seeking. The project lead or ~maybe~ even manager writes up a job description, and the HR staff formalizes it; breaks down each skill individually, adds 'years of' or 'proficiency level x-out-of-5' etc. This means that either a computer program that scans for buzzwords, or a person with no computer experience is going to be the first one to decide if your resume fits the bill.
They are not going to know that someone with 10 years experience with c++ can probably write pretty good c, or that J2EE is the same thing as Enterprise Java. They won't understand why no applicant has "MVC programming" on their resume. This is your first gauntlet.
Conclusion 1) You need to conform to their specifications.
Rewrite your resume to tailor it for each position you're applying to. Make sure you include every single keyword listed in the job description, exactly as it's listed. Include easy-to-find "years of experience" for skills. When in doubt (say you're submitting without a job listing) investigate the company, make a best guess, and liberally sprinkle buzzwords.
(... and if you're submitting 100% blind, like on dice or monster, rewrite your resume every week or so to change up the buzzwords. It seems that the company searches are re-run upon resubmittal, generating new 'matching candidate found' indicators)
Step 2) Now you've made it to a person. Hopefully a technical person, but sometimes it's an HR person with a 20 question programming quiz - really just an extension of the resume step (JMP step 1). They're going to do the technical and social evaluation.
Conclusion 2) You need to be unique.
Everyone else who's made it to this stage is identical. They all have the same buzzwords, years of experience, etc. Assuming all of them have the actual technical capabilities, there's nothing to differentiate you from anyone else, which means that selection of a candidate is still pretty much random choice. So, you need to find a way to stand out.
One good way available to everyone - in life as well as interviews - is to ask a lot of questions. Get the interviewer talking about their most recent projects, engage their emotions by getting them to talk about customers (no one has a customer-neutral stance). If you can get them talking about themselves, they'll leave with the perception that you were really interested in what they do, and pretty impressed with them in general. It doesn't hurt in most cases to sideline the 'real' interview to talk about their hobbies. Then, the next time they see your name on the page, they remember your face, the discussion, and you're head and shoulders above everyone else.
One person I know had his girlfriend call three times during the interview. He did the check-the-number-frown-send-the-call-to-voicemail thing for the first two times, and then asked for a quick reprieve for the third. Embarassed, he explained it was his girlfriend, and they were meeting her parents for the first time tonight, etc, etc, don't forget this, can you pick up that. That sort of thing totally humanizes a person, turns them from a name on a paper to something more.
Of course, if you have some interesting resume fodder, like the google participation listed in a previous comment, that's good to bring up too. Still, people like to talk about themselves or their code, so usually asking THEM the questions instead of just responding or talking about yourself seems to be a better shot.
Back in college, one of our CE exams required us to build a small system to process incoming data at a certain rate. Most sat down and banged out a simplified assembly language, snapped all the hardware together required to implement it, wrote a little asm program to feed the data and away they went, counting clock cycles and optimizing to ensure they met the requirements.
One of my friends realized there was no need for all that, and created a language with a single instruction; "go".
Semantically then, this would have been a one-bit program. Though he might have used a half-byte for instructions. Room to expand, you know.
I'm just posting this out of idle curiosity, so please indulge me.
As a 33 year old, I currently sleep between 3-5 hours in a day on average. Today I went to sleep around 5:10 AM, and woke up around 7:59 AM (one minute before the alarm, happens frequently). Though I am somewhat grumpy for the first 10-15 minutes, I quickly 'wake up' and feel refreshed and alert. This is normal for me. Back during college, I would often go 2 or 3 days without sleep, though it's more likely I'd take a nap somewhere between 9-11 am (depending on my schedule). I even work out and take martial arts classes to get regular exercise since my job is pretty sedentary.
Is there anyone else out there like this? Where sleep is this annoying intrusion into your schedule that you only allow when you're physically exhausted? Maybe you can help me figure out why people hear me describe my sleep cycle and say they're sorry, like this gift of another 1/6'th or more of my life to live is terrible compared to those people who voluntarily give up 1/3 of theirs.
Other random items; - According to doctors way back when I was 6 or so, I'm 'Hyperactive' - though I guess today it'd be called ADD or ADHD or something... - Only time I feel sleepy/awkward/wrongish is sometime around sunrise and the next 2-3 hours, but it goes away. On cloudy or foggy days, I may not experience this at all. It appears I have to actually see the early morning sunlight to really be negatively affected by it.... just curious to hear if there's anyone else out there like this.
This is a common-sense view that is unfortunately, pretty much wrong.
Indulgence in a form of problem behavior in either a real or simulated fashion does not remove the compulsion to perform that behavior again. In fact, if there's a reward of some sort, it makes sense that it would strengthen it.
A good example would be Mike Tyson. Here is a man who literally used a punching bag for hours a day, fought others constantly in a purely physical realm. According to the theory that you can 'get it out of your system,' he ought to have spent is entire free time performing volunteer work at old person's homes, holding their hands while listening to their stories and making them feel important.
Instead, he beats up Robin Givens, rapes an 18 year old, beats up the paparazzi, and when he gets out of jail and goes back to his intense training schedule, he bites an opponent's ear.
Violence is only a symptom. The cause doesn't change. The best you can hope for is physical exhaustion and a short term inability to carry out those desires.
So, 'getting it out of your system' is a terrible reason to advocate video game violence.
A better one would be, "Any reasonable person should be aware of the difference between real and simulated violence, and adults should take the time to explain this difference to children. The alternative would be to treat every man, woman, and child as being incapable of making this decision."
I write software for banks for a living. Web, mobile, voice, atm, teller, whatever. As far as my industry has indicated, these developing nations rely on cell phones for the majority of their banking, and anyone with enough money to care about banking will likely use a cell phone for that purpose - at least for common daily usage. There are people out there who have to rely on a hand-crank generator or pay a vendor to charge their phone - they have no access to electricity, but you'll note, they STILL have a cell phone.
Even in developing nations, cell phones are incredibly pervasive.
Rather than typing, "Really?" with ever increasing levels of bold and italics, I'll try to address this in a more structured, rational way. Forgive me if this is too long for some, but there were many points made by the article author which need discussion or refutation.
First, and somewhat most importantly, anti-female sexism in FOSS. The entirety of this claim rests on pure statistics: a small percent of FOSS contributors are female, in an unreferenced study, with purported validity due to opinion polls that mirror it's results somewhat. Let's just assume that the statistics are correct, and low. The author references this in a separate article he wrote.
This statistic does not indicate that there are either active or passive pressures on females to avoid this self-declared membership. This statistic does not provide insight to the reason why it is so, or suggest rationale to explain it. By itself, it is a fact and further study would be required to determine the cause. Oddly, I cannot actually find any studies that would suggest that, merely the leap from statistic to unsupported assumption. It seems that this is a perfectly valid, unquestioned mechanism, though I can't see how any individual would rationally support it. Any hypothesizing on my part about what people used to determine sexism from what appears to be a single statistic is therefore pointless - I'd could spend all my time tilting at windmills trying to refute the unvoiced assumption.
Second, much ado has been made about Richard Stallman's recent speech, indicating two separate items; - First, that Stallman is a representative who embodies as a whole - beliefs, motivation, goals - the entirety of those who declare themselves part of the FOSS community. - Second, that Stallman is sexist.
Therefore, the claim goes, all of FOSS is sexist.
I'll ignore dealing with the first. Obviously it's a fallacy not worth further consideration. Beyond that the text of his 'sexist' speech was; "And we also have the cult of the virgin of Emacs. The virgin of Emacs is any female who has not yet learned how to use Emacs. And in the church of Emacs we believe that taking her Emacs virginity away is a blessed act."
I'm not going to simply leave you, the reader, to interpret that as you wish. This is one of Stallman's reoccurring phrases, making a parody comparison of the 'Cult of the Virgin Mary,' to operating Emacs in an intended humorous way. Apparently the gender specific is random, alternating between male, female, and on occasion being left out entirely. His meaning was simply parody. To interpret any other way is to ignore the meaning and the intent and requires a listener to deliberately inject their own personal views and interpretations upon that of the speaker.
As a comparison, consider the phrase, "These are black days indeed." We know the speaker is discussing troubling times: he is not intending to say that people who's skins have a dark pigment are associated with trouble, and therefore it is a racist construct. It takes just such a leap to consider that text sexist.
Next we have a common circular argument construct I see used far too often, by individuals who do not even realize the absurdity of their suggestions. The author indicates that questioning if the problem exists indicates that you are a contributor of the problem. In this, the implicit assumption is made: There is a problem, and to even question it places you in the opposing camp. He even cites correspondence with just such an individual as 'proof' that proves the assumption. We see this quite often with other arguments, but it is exceptionally popular with minority political issues; [you] are guilty of brand-x discrimination. Your denial of your guilt/suggestion that brand-x discrimination does not exist proves that brand-x discrimination exists and that you, being blind to it, are guilty of it.
It is clear this is not a rational argument.
I'll wrap this up with one a few statements regarding the
Working in the banking software industry myself, I can tell you that anything associated with ATMs is incredibly slow to change. Unlike, say, computerized voting, ATM software generally has to go through scads of certification and changes. Usually 2-3 companies must actively collude to provide the entire system, if not more, and all of them have to have their systems certified in turn.
To make matters less urgent, everything is traceable. For a bank, culpability (accountability if you pardon the pun) is more important than theft prevention. I don't mean that the actual thief is found, but rather, that there's a log of every transaction and operation.
No urgency and a huge barrier to change, coupled with a very low rate of occurence - not really a 'real' problem.
As someone who works in the FI-tech industry, I can say that HSM's are effectively sealed, low power, dedicated chipsets. Physically, they resemble a small metal box with spots for inputs. They're supposed to be physically difficult to open and muck around with.
They add about 10-12k USD to the price of an ATM, despite that being nowhere near the unit production cost.
From someone involved on the technical level, it appears that this is the real scam job, but I'm not the one agreeing to follow certain inter-bank standards, so perhaps I'm a bit out of the loop here.
My workplace recently mandated that all laptops/portable media be encrypted. The impact to the system cpu usage isn't that significant to be honest, except when attempting to access, say, USB drives.
What's more important is the reliability of the disk itself.
As everyone knows, drivers shipped with laptops tend to be the first casualties of boot-sector-loading programs, like disk encryption and certain virus scanners.
Guess what happens when your encrypted disk can't be booted? You can't boot under a windows/emergency restore disk, because your partition is not readable. You can't boot off anything other than the hard drive. Guess what happens if the corruption doesn't allow you to run the encryption app's boot loader? Only solution is to format the disk.
Some of us who have been hit by this already have gone through the trouble of ensuring that any data we want to keep is stored on a shared drive, and that all work is done in a VM, which is occasionally uploaded to the shared drive as well. Since any given windows or driver-affecting update could kill our machine at any minute and make it entirely unrestorable, that's what's required.
So in essence, we're switching back to storing the media on a non-encrypted device because the loss of the data is more important than the security of the data.
This reminds me of the policies surrounding passwords I've seen at many companies; limiting the set of choices by making password creation requirements, and forcing them to change so often that people end up writing them down and leaving them on their desk. Defeats much of the purpose of having them in the first place.
Re:The Story of the Semantic Web--Slashdot Style!
on
Untangling Web Information
·
· Score: 5, Interesting
This about sums up my experience with it as well.
First we started off with categories, and tags in our searches. Then we switched to no-searching, but a filter-based tree mechanism for reducing the number of hits - instead of a table of contents. Then we switched to a table of contents using "task", "product" +4 other tree 'heads'. Then they started mulling over per-sentence tagging. It kept ballooning because it was obvious that though we had all these tags and a hierarchy and divisions, it didn't help - our customers used google to search for our help doc rather than our internal systems/help application.
In the end, they decided that they needed to automatically categorize everything. I tried to point out the futility of it, and what that would get them, but no one really wanted to listen. They were very surprised in the end when they got a search engine that looked for keywords.
Exactly what the help system they started with already did.
The two biggest problems with semantic-anything is
1) it doesn't provide any additional value without an exponentially increasing order level of (human) effort,
and 2) Unless someone comes up with a single, agreed upon, final, categorization (an ontology) - your markup will always disagree with someone elses, except for the most simple things that would be noted by search engines looking for keywords.
When I left, the project had been ongoing for 3 years, and they still didn't know what they wanted it to do - they were still searching for purpose and changing the target every day.... we didn't share an office, did we?
It seems some people are confused about the nature of the Automated Clearing House, and making very odd assumptions. Since some of this is due to a conflict in terminology, hopefully I can clear this up.
ACH is a big network. You might say it's really a collection of protocols and legal policies that allow banks and credit card companies to talk to each other. Every time you use your debit card in a non-branch office (like a Wells Fargo card in a Bank of America ATM), you're using ACH.
Now, I'm going to skip the in-depth network topology and give you the highlights. In short, the entire setup consists of Vendors attached to a Payment Processor , which are attached to ACH, which is responsible for routing a transaction from one ACH member to a Financial Institution (like a bank or credit card company).
Vendor->Payment processor->ACH->Financial Institution.
Now, why not have the Vendor connect to the FI directly? Well, each vendor would need a connection for every card. As in physical lines. That makes it expensive for everyone, and hit-or-miss for the consumer - what if they don't support YOUR card?
Okay, so, why not have the vendor connect to the ACH directly? Well, when you make a transaction on the ACH, there's no additional security. Basically, it's assumed that you have the authority to make the transaction, or you wouldn't be doing it. Imagine getting a credit card scanner and service for like 300$, quickly making several hundred thousand in fraudulent charges, and skipping the country. Generally speaking, you need to be an established business with accountability to be allowed to connect to the ACH - and that's where payment processors come in.
Oh, and quick terminology lesson. In ACH parlance:
A debit means "take money from an account"
A credit means "put money into an account"
They have nothing to do with credit cards, or debit cards, or anything of the sort.
Payment Processors, usually make money per transaction, or per connection time. Either way though, they profit from vendor transactions whether valid or not, so there's a good incentive to 'look the other way' with problem vendors.
So, this payment processor was following all the rules, but they're charging it as sort of an accessory to criminal acts by their customers. The states are saying that they knew these were invalid debits, but they processed them anyway, just to make money.
Technically it would be the vendors that have to suffer here, but the states are trying to hit every target they can, especially when busting a little work-out-of-your-house-2000$-laptop-scammer is not worth the money spent sending them to trial.
Without going into details (or doing any relevant fact checking) someone discovered that you could prepare files on a standard CD so that the dreamcast would play them. Aside from any magic checksums or signing required, one important piece was actually an image. Upon disc load, a section of data was read off the disc, and if it was not equal to the expected value, the disc would not play. The data? It was a start up image saying that the following game (and current image) was provided by/copyrighted by sega.
Homebrew Dreamcast developers didn't care, but Sega sued - and lost. Since they made their hardware require that this screen exist in that exact format, and be displayed regardless of the actual content, it was not legally enforcable.
Just imagine this step was a little more complicated though, and question whether a judge would have the technical savvy to understand it.
Let's say Stephen King sat down, and plunked out a book in 2 months. The cheap paperback version sells for 7.95$. When the publisher looks to print it, there's an initial cost to set up the run, and then a per unit cost - which goes down when you print in bulk. Let's say they print a million copies at 1$ per copy. Now they have to distribute it, but they already have pre-existing, active, channels. The distribution price is primarily based on weight, and runs about 8 cents per book. Let's ignore for now the difference between distributor & store prices, and see that right now we've got a profit of around 6.87$, to be divided up among store, distributor/publisher, and author, times 1,000,000 books. Say he only gets 85 cents per book, the author is still looking at 850,000$, or about 425k/per month of work.
Now, lets take our college textbooks. Due to the technical nature, they can't just fire out one every 2 months - it takes at least a year and often more if it's extremely technical in nature (Knuth books, for example were started ~1960, and came out in '68,'69, '73 - vol 4 is now going on 30 years). The printing for these is not as cheap - these books are meant to last, and are invariably hard cover, with better paper. Plus, since we're only submitting a job of, let's say, 30,000 for a popular textbook, over a multiyear period, per-unit costs are going to be higher: perhaps as high as 30-50$/book. Distribution costs are up there too - these text books rarely rely on active and established distribution channels, and focus on 1- or 2x- a year shippings, and due to the weight and size, are fairly expensive to ship in the first place: figure 8-10$ per book being not unreasonable. Assuming that we're selling for 80$, and it runs 60$ to make, we've got a sweet profit of 20$ to divide up. The payout ratio for an in-demand author like Stephen King was about 1/8'th of the profit (sure, that's pretty high, i'm just guessing). Let's make it higher for this book, closer to 1/6'th: author gets 3$. Let's also say that all 30,000 books sell out. That's 90,000k.. but the per-month payout comes close to 3750$/per month of work, or about 113 times LESS than another story about evil clowns.
So, it's simply not as profitable to make these textbooks as it is to make the next 'scary haunted lamp' book. Thus, to even make it worth printing, the price is high.... and all that's just simple economics.
I think that several people posting simply don't have the right concept about what's going on. This isn't a behavior or social ability test, to see how you can cope with a situation. Rather, as a select few individuals have indicated, this is a measure of your personality type.
For example;
Are you extroverted or introverted
Are you more likely to focus on detail and move slowly or focus on results and willing to take a risk.
Are you motivated by a challenge, or by money.
Additionally, certain tests include a quality indicator. Answering questions like, "Have you ever lied?" with a "no" sets off an alarm that the person may be falsifiying information.
I've worked with an industrial psychologist who generates these exact tests, and helped them provide web-enabled interfaces for it. I've implemented the scoring and ran through the tests as they've changed many times. I'm not going to comment on whether they're accurate or not - it's irrelevant to the people here.
Instead, lets look at how they are used - something that I've also been exposed to, both from the usage of the tools I wrote, to being subjected to similiar tests by potential employers.
HR requirement as a filter.
These tools are meant to check you into usually four to eight personality types. If you do not fit the type, you do not get the job, for any company who uses them.
Real world examples I've seen include:
Programmer: Attention to detail, motivated by sense of accomplishment, lack of ambition.
Manager : focus on completion/results over detail, motivated by power/control, high career ambition
Salesman: focus on people, motivated by money & recoginition, optimistic
'Smart' usage
Instead of randomly specifying a category, your existing employees are profiled, and you take the results of your star employees and make those the expected attributes for the position.
Contract jobs
Many contracting firms expect a contractor to take a behavioral assessment, which is used as a tool by the contract manager to; provide a good match for a candidate, ensure the candidate and company needs match, and to provide humanistic value for an individual they have to represent. You can't easily say "Such-and-Such is trustworthy," having only met them once, but you can point to a psych evaluation and say "Our analysis shows that s/he places a high emphasis on trust."
So, what do you do with this info if you're a tech-savvy guy applying for an IT-related position?
These tests work as filters for, well, non-skilled positions. They are applied to every new hire, usually per company HR policy. Honestly, they don't appear to work very well for skilled labour. Look at the programmer example up above. The profile given is for a programmer who is sedate. No new languages, no new technologies, happy to be doing the same job for the next 20 years. This was just the result of a random decision; you had to pick one of the 8 categories, and the one with 'attention to detail' was the top pick. What happens when technologies change, or the software needs to be updated, or new software designed? Too bad you hired someone who won't tend to learn new things.
What they say they want, and what they need are often disparate things. You can be perfectly suited for the job, but dinged on the somewhat arbitrairy match from the personality test.
To answer my question above, the smart IT person will attempt to determine before hand what the employer is looking for and cheat the test.
These tests are transparent. If something asks if you'd rather have a trophy with your name on it, or a cash prize, you can tell one is focused on recognition, and the other on money. Figure out beforehand what the profile is they're looking for and try to match it. Be consistent, since the same question will be asked 3-4 times using different wording. Most scoring systems ar
Slashdot Mirror
The article writer started out well, and then immediately ignored his own line of thought.
"John Graham-Cumming wrote an article today complaining about how a computer system he was working with described his last name as having invalid characters. It of course does not, because anything someone tells you is their name is--by definition--an appropriate identifier for them."
Yes, in your scope, your name is going to be accurate by whatever cultural, political, legal, optional, character-set or other restrictions or freedoms apply.
However, in the scope of any given app, your name may very well be an 8 character, [a-zA-Z] string. That's what the app means by the name field - by definition.
Naturally, no programmer would use any user-provided input for any sort of unique key ( err... right?) ... so really what this is about is that someone did not properly set user expectations, that they may not be allowed to arbitrarily spool data in any format or fashion into any given input field - 'name' in this case.
Or someone already knows that fact, and is ranting because they chose today to ignore it.
Disclaimer: I write financial software for a living.
First, I don't see why OFX can't be used for that purpose. You could manage several hundred accounts, payroll, billpay, collections, wire transfers, funds management, etc. Not only that, it's two-way. It's not just displaying account data, it allows you to perform the actual transactions. I know of some payroll processing centers that use OFX for exactly this - either it goes to printer or it goes electronic.
Second, because there is no salable demand for individuals requesting the raw file formats for the backend transfers, those features don't exist. This is common sense - what motivation exists for a company to spend the time and effort providing a feature if there is no money attached to it.
Third, certification. There is quite a bit of hullabaloo in the banking industry about certification, and they're serious. See, there's not a lot of security in the banking world. They rely on hard connections, network separation, and effectively, trust. What they DO have though, is auditing trails. They might not be able to stop a fraudulent ATM transaction, but they can tell you every node, clearing house, third party processor or financial institution it went through. Certification is the thing that allows them to reasonably trust members in their transactional world - you can't just show up with homegrown software and hook right in.
Last, as you said, "The banking world is awash in data protocols". Lemme tell you something - the raw protocols are only about 1/20'th of what goes on. No protocol is perfect, and many systems have what you or I might consider 'undocumented features' that are handled by clever manipulation of the protocol (aka, hacks). The paper description, for example, of the ACH file format can be compressed into about 6 pages. There is a two volume set of books, each about 300 pages, of small print, so thin as to be nearly transparent pages that actually describes how those 8 pages work.
That's one protocol. There are dozens of major ones, and additional complexities when you add in feature specific cores or sinks (back end systems that banks use to store the actual data on, like those provided by MISER or Fiserv )- do you support overdraft protection, provide memo services (a hold against an account for an amount prior to it's actual processing), and if so, which of the dozen ways do you provide that information?
So in the end;
* no real financial benefit to providing that access (especially when you say you don't want to pay XD )
* no certification to provide that access
* actual software knowledge requires domain knowledge many magnitudes greater than just file formats, including per-FI non-public knowledge
last and not the least important items not discussed above;
* financial institutions are slow movers when it comes to adopting technology.
* early adopters are NEVER the small banks, and they always require a hefty ($$$$) reason to include it.
So it could be done - and probably will in the next 20 years or so - but not today. ...
as an aside,
The reason you'd be getting billed 5 figures for access is because they'd end up assigning someone to manually pull your ACH records out of each daily batch and save them to one side. Manually. They may even need to have someone actually type the new entries in (separation of networks, removable media would be disallowed - of course.)
I've been around for a while, dealt with a lot of code that had a missing developer, and one thing I noted was this simple truth:
Every significantly complex piece of code you didn't write, every system you didn't design is "bad".
It doesn't matter if it's well formed, makes sense, works well together, you'll always find a way to complain about the coding style used, the design choices made, the libraries used or ignored, and until you've sat in it for a while, none of it will make sense to you. Not sure what I mean? Try spending some time in a few of the programming centric IRC channels, and watch everyone rip into someone else's code. The #python channels are especially funny since the loudest individuals there appear to be some sort of religious adherents in the church of python. In general, these folks won't even answer simple questions until the code is reorganized in the manner they're accustomed to.
The thing is, we're all like that. It's the same each time you pick up a new language, or you're tackling a new library. This isn't a web-based phenomenon - this is every piece of code ever, regardless of it's actual quality of lack thereof.
This is the sort of thing that you can't fix with single-vendor lock-in, or strict adherence to protocols, and it's not exacerbated by mixing and matching OSS projects. Inside a given company, it can be regulated to a point by having architectural guidelines, strict coding conventions, and well spread code reviews that ensure conventions are used - but the code will still be 'bad' to people outside the company.
I do have a fix for it, but I don't think the author will like it. You should make sure that YOU as a developer experience as many of the frameworks and languages and systems and such that are out there, continue to expand your awareness of program design from data structures to lifecycle management, and that way, when you experience one of these 'bad' systems, you'll be able to absorb what the previous developer was thinking a little quicker than otherwise.
of course, it could just be terribly written code, and not just subjectively bad, in which case I always end up voting 'slash 'n' burn'.
Is that still true? A decade or so ago it would have been, but we have some bright young programmers who have only seen Pascal (from early training), Java, Python, and C#. Many examples now are in one of these languages or pseudocode.
You're correct - there are programmers who've only seen Java, and it's obvious from looking at their coding style and program structure. I'm not saying that in a complimentary way. Java is the new Basic - If it is your first language, it appears to make you a 'bad' programmer.
I'm still finding people who have no concept of memory usage or code complexity (though less lately).
I'm finding people who use exceptions to pass information, instead of return values (especially after they put the class behind 6 layers of unnecessary abstraction)
I'm finding people who were never taught to check their arguments or perform sanity checking of any type, including checking return values from other methods ('Oh, then it should throw an exception!').
I'm still finding people who don't understand that a design pattern is just a shorthand used to communicate ideas about program design. Sitting through a peer review where you're told "I can't approve this unless you make it clear which design pattern you're using here, and name the class after the pattern" is somewhat infuriating.
I'm not saying these people are not bright. It's just that they don't know any better. Sun did a great job packaging Java as a product with end-to-end ownership from training and certs to support and evangelical positions. They made it much easier to write working code.
Unfortunately, it's that much easier to write bad code that nonetheless, is working code.
... the defining method to determine if a game is an RPG or not is if game engine itself penalize someone by denying access to some game content. No joke:
"Where then does that leave the modern RPG? The game where making choices actually results in missing out on things? The game where you don't get to use the best axe because you're focussing on guns instead? While RPG becomes a modern marketing phrase to slap on titles in the hopes of selling additional units and some companies are making real efforts, the truth is, the core mechanics of the most successful RPGs released by the main-stream developers are becoming less and less RPG like."
Two more gems:
- Games that use the same game engine are not new games, with the implication that they are therefore not worth playing 'again'.
- the claim that any company that produces a game labeled as an RPG will go out of business in short order because of that decision.
I could do a point-by-point, but there's no ...erhm... point. I'd just ignore this posting if I were Jeff.
I was going to point this out myself.
This same sort of process is already used in many different forms for things like job screening - especially for bulk blue collar hires. There are certain statistical trends that just come to the forefront, like "95% of people convicted of drug crimes smoke (tobacco) cigarettes". That doesn't mean that anyone who smokes is a drug user, but statistically, if you don't smoke, it's much less likely that you'll eventually be convicted of a drug crime - so you're a better hire if all else is equal.
From what I've seen, most of these systems are not even real datamining systems - and I worked for 2 years doing real cutting edge datamining with self organizing neural nets and overlaid expert systems to guide 'questions'. Instead, they're summaries. "100 kids were arrested for spraying graffiti. What percentage went on to commit felonies? If % is greater than 50%, flag 'arrested for spraying grafiti' as dangerous". That's as much datamining as using the index in the back of a book.
Instead, most of these systems are just a nice way - as the parent indicates - of letting non-technically-competent ask questions that are converted to an sql query or display a nice graph.
To understand how to get hired, you have to understand how hiring works. Here's a simple 2-step generalization:
Part 1)
A great number of companies out there rely on their HR staff to do the hiring and applicant-seeking. The project lead or ~maybe~ even manager writes up a job description, and the HR staff formalizes it; breaks down each skill individually, adds 'years of' or 'proficiency level x-out-of-5' etc. This means that either a computer program that scans for buzzwords, or a person with no computer experience is going to be the first one to decide if your resume fits the bill.
They are not going to know that someone with 10 years experience with c++ can probably write pretty good c, or that J2EE is the same thing as Enterprise Java. They won't understand why no applicant has "MVC programming" on their resume. This is your first gauntlet.
Conclusion 1)
You need to conform to their specifications.
Rewrite your resume to tailor it for each position you're applying to. Make sure you include every single keyword listed in the job description, exactly as it's listed. Include easy-to-find "years of experience" for skills. When in doubt (say you're submitting without a job listing) investigate the company, make a best guess, and liberally sprinkle buzzwords.
(... and if you're submitting 100% blind, like on dice or monster, rewrite your resume every week or so to change up the buzzwords. It seems that the company searches are re-run upon resubmittal, generating new 'matching candidate found' indicators)
Step 2)
Now you've made it to a person. Hopefully a technical person, but sometimes it's an HR person with a 20 question programming quiz - really just an extension of the resume step (JMP step 1). They're going to do the technical and social evaluation.
Conclusion 2)
You need to be unique.
Everyone else who's made it to this stage is identical. They all have the same buzzwords, years of experience, etc. Assuming all of them have the actual technical capabilities, there's nothing to differentiate you from anyone else, which means that selection of a candidate is still pretty much random choice. So, you need to find a way to stand out.
One good way available to everyone - in life as well as interviews - is to ask a lot of questions. Get the interviewer talking about their most recent projects, engage their emotions by getting them to talk about customers (no one has a customer-neutral stance). If you can get them talking about themselves, they'll leave with the perception that you were really interested in what they do, and pretty impressed with them in general. It doesn't hurt in most cases to sideline the 'real' interview to talk about their hobbies. Then, the next time they see your name on the page, they remember your face, the discussion, and you're head and shoulders above everyone else.
One person I know had his girlfriend call three times during the interview. He did the check-the-number-frown-send-the-call-to-voicemail thing for the first two times, and then asked for a quick reprieve for the third. Embarassed, he explained it was his girlfriend, and they were meeting her parents for the first time tonight, etc, etc, don't forget this, can you pick up that. That sort of thing totally humanizes a person, turns them from a name on a paper to something more.
Of course, if you have some interesting resume fodder, like the google participation listed in a previous comment, that's good to bring up too. Still, people like to talk about themselves or their code, so usually asking THEM the questions instead of just responding or talking about yourself seems to be a better shot.
Back in college, one of our CE exams required us to build a small system to process incoming data at a certain rate. Most sat down and banged out a simplified assembly language, snapped all the hardware together required to implement it, wrote a little asm program to feed the data and away they went, counting clock cycles and optimizing to ensure they met the requirements.
One of my friends realized there was no need for all that, and created a language with a single instruction; "go".
Semantically then, this would have been a one-bit program. Though he might have used a half-byte for instructions. Room to expand, you know.
I'm just posting this out of idle curiosity, so please indulge me.
As a 33 year old, I currently sleep between 3-5 hours in a day on average. Today I went to sleep around 5:10 AM, and woke up around 7:59 AM (one minute before the alarm, happens frequently). Though I am somewhat grumpy for the first 10-15 minutes, I quickly 'wake up' and feel refreshed and alert. This is normal for me. Back during college, I would often go 2 or 3 days without sleep, though it's more likely I'd take a nap somewhere between 9-11 am (depending on my schedule). I even work out and take martial arts classes to get regular exercise since my job is pretty sedentary.
Is there anyone else out there like this? Where sleep is this annoying intrusion into your schedule that you only allow when you're physically exhausted? Maybe you can help me figure out why people hear me describe my sleep cycle and say they're sorry, like this gift of another 1/6'th or more of my life to live is terrible compared to those people who voluntarily give up 1/3 of theirs.
Other random items; ... ... just curious to hear if there's anyone else out there like this.
- According to doctors way back when I was 6 or so, I'm 'Hyperactive' - though I guess today it'd be called ADD or ADHD or something
- Only time I feel sleepy/awkward/wrongish is sometime around sunrise and the next 2-3 hours, but it goes away. On cloudy or foggy days, I may not experience this at all. It appears I have to actually see the early morning sunlight to really be negatively affected by it.
This is a common-sense view that is unfortunately, pretty much wrong.
Indulgence in a form of problem behavior in either a real or simulated fashion does not remove the compulsion to perform that behavior again. In fact, if there's a reward of some sort, it makes sense that it would strengthen it.
A good example would be Mike Tyson. Here is a man who literally used a punching bag for hours a day, fought others constantly in a purely physical realm. According to the theory that you can 'get it out of your system,' he ought to have spent is entire free time performing volunteer work at old person's homes, holding their hands while listening to their stories and making them feel important.
Instead, he beats up Robin Givens, rapes an 18 year old, beats up the paparazzi, and when he gets out of jail and goes back to his intense training schedule, he bites an opponent's ear.
Violence is only a symptom. The cause doesn't change. The best you can hope for is physical exhaustion and a short term inability to carry out those desires.
So, 'getting it out of your system' is a terrible reason to advocate video game violence.
A better one would be, "Any reasonable person should be aware of the difference between real and simulated violence, and adults should take the time to explain this difference to children. The alternative would be to treat every man, woman, and child as being incapable of making this decision."
I write software for banks for a living. Web, mobile, voice, atm, teller, whatever. As far as my industry has indicated, these developing nations rely on cell phones for the majority of their banking, and anyone with enough money to care about banking will likely use a cell phone for that purpose - at least for common daily usage. There are people out there who have to rely on a hand-crank generator or pay a vendor to charge their phone - they have no access to electricity, but you'll note, they STILL have a cell phone.
Even in developing nations, cell phones are incredibly pervasive.
Rather than typing, "Really?" with ever increasing levels of bold and italics, I'll try to address this in a more structured, rational way. Forgive me if this is too long for some, but there were many points made by the article author which need discussion or refutation.
First, and somewhat most importantly, anti-female sexism in FOSS. The entirety of this claim rests on pure statistics: a small percent of FOSS contributors are female, in an unreferenced study, with purported validity due to opinion polls that mirror it's results somewhat. Let's just assume that the statistics are correct, and low. The author references this in a separate article he wrote.
This statistic does not indicate that there are either active or passive pressures on females to avoid this self-declared membership. This statistic does not provide insight to the reason why it is so, or suggest rationale to explain it. By itself, it is a fact and further study would be required to determine the cause. Oddly, I cannot actually find any studies that would suggest that, merely the leap from statistic to unsupported assumption. It seems that this is a perfectly valid, unquestioned mechanism, though I can't see how any individual would rationally support it. Any hypothesizing on my part about what people used to determine sexism from what appears to be a single statistic is therefore pointless - I'd could spend all my time tilting at windmills trying to refute the unvoiced assumption.
Second, much ado has been made about Richard Stallman's recent speech, indicating two separate items;
- First, that Stallman is a representative who embodies as a whole - beliefs, motivation, goals - the entirety of those who declare themselves part of the FOSS community.
- Second, that Stallman is sexist.
Therefore, the claim goes, all of FOSS is sexist.
I'll ignore dealing with the first. Obviously it's a fallacy not worth further consideration. Beyond that the text of his 'sexist' speech was;
"And we also have the cult of the virgin of Emacs. The virgin of Emacs is any female who has not yet learned how to use Emacs. And in the church of Emacs we believe that taking her Emacs virginity away is a blessed act."
I'm not going to simply leave you, the reader, to interpret that as you wish. This is one of Stallman's reoccurring phrases, making a parody comparison of the 'Cult of the Virgin Mary,' to operating Emacs in an intended humorous way. Apparently the gender specific is random, alternating between male, female, and on occasion being left out entirely. His meaning was simply parody. To interpret any other way is to ignore the meaning and the intent and requires a listener to deliberately inject their own personal views and interpretations upon that of the speaker.
As a comparison, consider the phrase, "These are black days indeed." We know the speaker is discussing troubling times: he is not intending to say that people who's skins have a dark pigment are associated with trouble, and therefore it is a racist construct. It takes just such a leap to consider that text sexist.
Next we have a common circular argument construct I see used far too often, by individuals who do not even realize the absurdity of their suggestions. The author indicates that questioning if the problem exists indicates that you are a contributor of the problem. In this, the implicit assumption is made: There is a problem, and to even question it places you in the opposing camp. He even cites correspondence with just such an individual as 'proof' that proves the assumption. We see this quite often with other arguments, but it is exceptionally popular with minority political issues; [you] are guilty of brand-x discrimination. Your denial of your guilt/suggestion that brand-x discrimination does not exist proves that brand-x discrimination exists and that you, being blind to it, are guilty of it.
It is clear this is not a rational argument.
I'll wrap this up with one a few statements regarding the
Working in the banking software industry myself, I can tell you that anything associated with ATMs is incredibly slow to change. Unlike, say, computerized voting, ATM software generally has to go through scads of certification and changes. Usually 2-3 companies must actively collude to provide the entire system, if not more, and all of them have to have their systems certified in turn.
To make matters less urgent, everything is traceable. For a bank, culpability (accountability if you pardon the pun) is more important than theft prevention. I don't mean that the actual thief is found, but rather, that there's a log of every transaction and operation.
No urgency and a huge barrier to change, coupled with a very low rate of occurence - not really a 'real' problem.
As someone who works in the FI-tech industry, I can say that HSM's are effectively sealed, low power, dedicated chipsets. Physically, they resemble a small metal box with spots for inputs. They're supposed to be physically difficult to open and muck around with.
They add about 10-12k USD to the price of an ATM, despite that being nowhere near the unit production cost.
From someone involved on the technical level, it appears that this is the real scam job, but I'm not the one agreeing to follow certain inter-bank standards, so perhaps I'm a bit out of the loop here.
My workplace recently mandated that all laptops/portable media be encrypted. The impact to the system cpu usage isn't that significant to be honest, except when attempting to access, say, USB drives.
What's more important is the reliability of the disk itself.
As everyone knows, drivers shipped with laptops tend to be the first casualties of boot-sector-loading programs, like disk encryption and certain virus scanners.
Guess what happens when your encrypted disk can't be booted? You can't boot under a windows/emergency restore disk, because your partition is not readable. You can't boot off anything other than the hard drive. Guess what happens if the corruption doesn't allow you to run the encryption app's boot loader? Only solution is to format the disk.
Some of us who have been hit by this already have gone through the trouble of ensuring that any data we want to keep is stored on a shared drive, and that all work is done in a VM, which is occasionally uploaded to the shared drive as well. Since any given windows or driver-affecting update could kill our machine at any minute and make it entirely unrestorable, that's what's required.
So in essence, we're switching back to storing the media on a non-encrypted device because the loss of the data is more important than the security of the data.
This reminds me of the policies surrounding passwords I've seen at many companies; limiting the set of choices by making password creation requirements, and forcing them to change so often that people end up writing them down and leaving them on their desk. Defeats much of the purpose of having them in the first place.
This about sums up my experience with it as well.
First we started off with categories, and tags in our searches. Then we switched to no-searching, but a filter-based tree mechanism for reducing the number of hits - instead of a table of contents. Then we switched to a table of contents using "task", "product" +4 other tree 'heads'. Then they started mulling over per-sentence tagging. It kept ballooning because it was obvious that though we had all these tags and a hierarchy and divisions, it didn't help - our customers used google to search for our help doc rather than our internal systems/help application.
In the end, they decided that they needed to automatically categorize everything. I tried to point out the futility of it, and what that would get them, but no one really wanted to listen. They were very surprised in the end when they got a search engine that looked for keywords.
Exactly what the help system they started with already did.
The two biggest problems with semantic-anything is
1) it doesn't provide any additional value without an exponentially increasing order level of (human) effort,
and
2) Unless someone comes up with a single, agreed upon, final, categorization (an ontology) - your markup will always disagree with someone elses, except for the most simple things that would be noted by search engines looking for keywords.
When I left, the project had been ongoing for 3 years, and they still didn't know what they wanted it to do - they were still searching for purpose and changing the target every day. ... we didn't share an office, did we?
It seems some people are confused about the nature of the Automated Clearing House, and making very odd assumptions. Since some of this is due to a conflict in terminology, hopefully I can clear this up. ACH is a big network. You might say it's really a collection of protocols and legal policies that allow banks and credit card companies to talk to each other. Every time you use your debit card in a non-branch office (like a Wells Fargo card in a Bank of America ATM), you're using ACH. Now, I'm going to skip the in-depth network topology and give you the highlights. In short, the entire setup consists of Vendors attached to a Payment Processor , which are attached to ACH, which is responsible for routing a transaction from one ACH member to a Financial Institution (like a bank or credit card company). Vendor->Payment processor->ACH->Financial Institution. Now, why not have the Vendor connect to the FI directly? Well, each vendor would need a connection for every card. As in physical lines. That makes it expensive for everyone, and hit-or-miss for the consumer - what if they don't support YOUR card? Okay, so, why not have the vendor connect to the ACH directly? Well, when you make a transaction on the ACH, there's no additional security. Basically, it's assumed that you have the authority to make the transaction, or you wouldn't be doing it. Imagine getting a credit card scanner and service for like 300$, quickly making several hundred thousand in fraudulent charges, and skipping the country. Generally speaking, you need to be an established business with accountability to be allowed to connect to the ACH - and that's where payment processors come in. Oh, and quick terminology lesson. In ACH parlance: A debit means "take money from an account" A credit means "put money into an account" They have nothing to do with credit cards, or debit cards, or anything of the sort. Payment Processors, usually make money per transaction, or per connection time. Either way though, they profit from vendor transactions whether valid or not, so there's a good incentive to 'look the other way' with problem vendors. So, this payment processor was following all the rules, but they're charging it as sort of an accessory to criminal acts by their customers. The states are saying that they knew these were invalid debits, but they processed them anyway, just to make money. Technically it would be the vendors that have to suffer here, but the states are trying to hit every target they can, especially when busting a little work-out-of-your-house-2000$-laptop-scammer is not worth the money spent sending them to trial.
Anyone remember the issue with the dreamcast?
Without going into details (or doing any relevant fact checking) someone discovered that you could prepare files on a standard CD so that the dreamcast would play them. Aside from any magic checksums or signing required, one important piece was actually an image. Upon disc load, a section of data was read off the disc, and if it was not equal to the expected value, the disc would not play. The data? It was a start up image saying that the following game (and current image) was provided by/copyrighted by sega.
Homebrew Dreamcast developers didn't care, but Sega sued - and lost. Since they made their hardware require that this screen exist in that exact format, and be displayed regardless of the actual content, it was not legally enforcable.
Just imagine this step was a little more complicated though, and question whether a judge would have the technical savvy to understand it.
It's not a scam. It's simple economics.
.. but the per-month payout comes close to 3750$/per month of work, or about 113 times LESS than another story about evil clowns.
... and all that's just simple economics.
Let's say Stephen King sat down, and plunked out a book in 2 months. The cheap paperback version sells for 7.95$. When the publisher looks to print it, there's an initial cost to set up the run, and then a per unit cost - which goes down when you print in bulk. Let's say they print a million copies at 1$ per copy. Now they have to distribute it, but they already have pre-existing, active, channels. The distribution price is primarily based on weight, and runs about 8 cents per book. Let's ignore for now the difference between distributor & store prices, and see that right now we've got a profit of around 6.87$, to be divided up among store, distributor/publisher, and author, times 1,000,000 books. Say he only gets 85 cents per book, the author is still looking at 850,000$, or about 425k/per month of work.
Now, lets take our college textbooks. Due to the technical nature, they can't just fire out one every 2 months - it takes at least a year and often more if it's extremely technical in nature (Knuth books, for example were started ~1960, and came out in '68,'69, '73 - vol 4 is now going on 30 years). The printing for these is not as cheap - these books are meant to last, and are invariably hard cover, with better paper. Plus, since we're only submitting a job of, let's say, 30,000 for a popular textbook, over a multiyear period, per-unit costs are going to be higher: perhaps as high as 30-50$/book. Distribution costs are up there too - these text books rarely rely on active and established distribution channels, and focus on 1- or 2x- a year shippings, and due to the weight and size, are fairly expensive to ship in the first place: figure 8-10$ per book being not unreasonable. Assuming that we're selling for 80$, and it runs 60$ to make, we've got a sweet profit of 20$ to divide up. The payout ratio for an in-demand author like Stephen King was about 1/8'th of the profit (sure, that's pretty high, i'm just guessing). Let's make it higher for this book, closer to 1/6'th: author gets 3$. Let's also say that all 30,000 books sell out. That's 90,000k
So, it's simply not as profitable to make these textbooks as it is to make the next 'scary haunted lamp' book. Thus, to even make it worth printing, the price is high.
For example;
Additionally, certain tests include a quality indicator. Answering questions like, "Have you ever lied?" with a "no" sets off an alarm that the person may be falsifiying information.
I've worked with an industrial psychologist who generates these exact tests, and helped them provide web-enabled interfaces for it. I've implemented the scoring and ran through the tests as they've changed many times. I'm not going to comment on whether they're accurate or not - it's irrelevant to the people here.
Instead, lets look at how they are used - something that I've also been exposed to, both from the usage of the tools I wrote, to being subjected to similiar tests by potential employers.
These tools are meant to check you into usually four to eight personality types. If you do not fit the type, you do not get the job, for any company who uses them.
Real world examples I've seen include:
Instead of randomly specifying a category, your existing employees are profiled, and you take the results of your star employees and make those the expected attributes for the position.
Many contracting firms expect a contractor to take a behavioral assessment, which is used as a tool by the contract manager to; provide a good match for a candidate, ensure the candidate and company needs match, and to provide humanistic value for an individual they have to represent. You can't easily say "Such-and-Such is trustworthy," having only met them once, but you can point to a psych evaluation and say "Our analysis shows that s/he places a high emphasis on trust."
So, what do you do with this info if you're a tech-savvy guy applying for an IT-related position?
These tests work as filters for, well, non-skilled positions. They are applied to every new hire, usually per company HR policy. Honestly, they don't appear to work very well for skilled labour. Look at the programmer example up above. The profile given is for a programmer who is sedate. No new languages, no new technologies, happy to be doing the same job for the next 20 years. This was just the result of a random decision; you had to pick one of the 8 categories, and the one with 'attention to detail' was the top pick. What happens when technologies change, or the software needs to be updated, or new software designed? Too bad you hired someone who won't tend to learn new things.
What they say they want, and what they need are often disparate things. You can be perfectly suited for the job, but dinged on the somewhat arbitrairy match from the personality test.
To answer my question above, the smart IT person will attempt to determine before hand what the employer is looking for and cheat the test.
These tests are transparent. If something asks if you'd rather have a trophy with your name on it, or a cash prize, you can tell one is focused on recognition, and the other on money. Figure out beforehand what the profile is they're looking for and try to match it. Be consistent, since the same question will be asked 3-4 times using different wording. Most scoring systems ar