When you, as a consumer, buy an item out of state, receive a gift, or win money from gambling - or a slew of other sources - you're expected to report your winnings to the state so they can tax it. The problem is that people don't. They either don't know, don't care, or don't worry about residental-level tax evasion being enforced. So technically the mechanisms for taxes already covers this, but it would take each state a lot of effort to track down each evader and retrieve their monies due (though one could argue that, along with fines and the jobs this would create, it could be a good thing for the state). So, basically it's really tough for them, since they wrote laws which are hard to enforce.
That's the issue. It's not convenient for the state to collect tax money.
So now they're attempting to change the laws so it's easy - they make the online retailers responsible for collecting money on their behalf and it's fine. Then they have one place to go to collect, instead of hundreds of thousands that have to be litigated. They're attempting to make online retailers - like Amazon - bear the burden that they themselves do not wish to shoulder (granted, it's easier for Amazon, but by no mean effortless). They're stretching the interpretation of existing laws to claim that in-state third parties Amazon has a business relationship represent a direct presence by Amazon, and thus they must follow the state laws for brick and mortar vendors.
If you ~had~ to bring up ethics, you should probably look at the state lawmakers. They're acting like the stereotypical royal taxmen: they see you have money, and they will make up any excuse they can to liberate it from you. Moreso now, due to budget/economy constraints they have to work under.
I've almost lunged across a transatlantic gap and strangled someone through a phone line because they indicated I needed to rewrite my entire program to encode the names of the design patterns I was using into my object names and methods, or they would block my submission. This from a fellow who bulk submitted about 30 changes resulting in the build being broken for a week and a half.... That said, there IS a place for it. Code architecture is somewhat subjective, and two people may come up with a more effective solution to a problem than either working solo. The problem is scope and zealots.
Code reviews are good for finding bugs and - if you happen to have one - confirming to a coding style guide. This means that we'll be more likely to find bugs, and the code will be potentially easier to maintain. Seems like it's an easy win, at the cost of some small amount of dev time.
However, there's a big list of detriments.
Let's take the average developer, who stereotypically has a social coping mechanism that is... shall we say off-by-one. Take the thing he does well, and subject it to criticism every time he does it. Keep in mind that many aspects of software development are subjective; how to 'best' write a function, or how to architect a component. That means the criticism isn't constrained to bug fixes (valid) or coding style (valid, even if you dislike them) - it's about personal choices.
Also, there's an issue with ownership. We, as developers, often grow attached to a piece of code and no matter how poorly written or convoluted it is, there's still a certain amount of hurt associated with someone else wanting to change it. This is the case even if we just get assigned to maintain some piece of garbage code we don't even want to deal with.
Then add deadlines. We all know that developing bulletproof code is largely a matter of time. Time to analyze, time to review, time spent peer programming instead of solo, time writing documentation, time writing and running tests, etc. There's good reason that functionality comes first and docs come last in most environments, and it's out of the developer's hands. That's another source of stress since you're tripling the load for each submission: first you have to write it, then you have to go over it with another person in fine detail comparable to writing it. That's assuming you believe you write perfect code to begin with, and don't spend longer than normal reformatting and rewriting your code to make the reviewer happy.
Take those added stresses and add them over and over, and tell me that won't change the coder's behavior in some way. In most places I've worked, this usually results in developers picking 'safe' reviewers - people who don't review in depth, people who don't have the time to do a good job, or people who will defer to the original developer due to perceived differences in experience or rank. In some cases, it means that large rewrites are avoided, and hacks put in place instead, because it's easier to get a 30 line hacked-in function successfully reviewed than a 30 file change. It also appears to limit the creation of new functionality to some extent - if you're breaking ground, everyone has a chance to critique your methods. Most seem to find a way to route around 'damage' in the process, especially if you have any zealots on your team.
Personally, I prefer the more objective code analysis and coverage tools, test driven development, and most important, consensus among developers on questions of architecture prior to implementation. Code can be accessed by those wishing to review it after the fact (which, like refactoring, almost never happens), and it can be handled on an informal level if necessary.
As far as ROI is concerned, this seems to be the most effective and efficient mechanism. Perhaps if the user communities did not so easily accept computer/software failures, this would not be the case.
Even with one end loosely tethered, isn't a cord stretched across any walkway an inherently dangerous thing? If not to the product, then to the person doing the tripping?
Now, my viewpoint may be biased, because I tend to use a desk when I do my work, not a coffee bar, but I've had lots of problems with these magsafe connectors; they don't stay plugged in, or they appear plugged in, but are not actually 'all' the way in. Pulling the mouse cord when it gets stuck dislodges it, rotating the monitor a little bit dislodges them, throwing a wayward glance in their direction freakin' dislodges them.
Besides that, shouldn't we already be using USB for this purpose? It handles up to 240v, and while the connectors are various shapes, it's ubiquitous and would require only standardization on the hardware end, and nothing on the software side.
Every business - when it reaches a certain size - realizes that they need to have a fixed process for handling X, where X can be contract approval, printer supply purchase, production system access, hiring new employees and so on. They need it because it provides accountability, oversight, size estimation, consistency, and the higher you are in the org chart, the more important those attributes become versus one individual task's result. At some level, being able to say someone is 60% complete with 32 man hours remaining is more important than having someone who code ninjas a fix in a single night because it needs to be done. With accurate info, you can plan for resources and identify where there are problems and effect systemic change if necessary - you can't plan for "Bob did it last week without telling anyone and we didn't know he did it until today."
This is because the goal for the person (and their direct manager) is 'complete task', and 'process' can be perceived as an impediment that provides no immediate value. The more motivated that person is, the more likely they are to route around what they perceive as damage and circumvent the process in spirit, if not completely. Thus what may appear to be duplication of effort or reliance on external resources is really a myopic focus on short term goals.
In my experience, the good companies allow this, because they all realize that sometimes a time delay is unacceptable, even if it 'breaks process'. They'll say "It's better to ask forgiveness, than to ask permission." It is, of course, subjective when an employee should or should not exercise this quote.
This is just what it's like to work in a company. Nothing unusual.
Sometimes you need to state the obvious over and over again because it doesn't take much for a person to internalize a viewpoint that makes the obvious non-obvious. Like Lewis Caroll pointed out, 3 times seems to be enough.
You're not getting a snow day - you're following the infrastructure interruption business continuity plan!
other fun entries are: You're no longer sick - you're working remotely! You're no longer on vacation - you're off site with limited access! You're no longer driving in your car/using the bathroom/eating a meal* - you're responsive to electronic communications! You're no longer sleeping - you're managing cross-time-zone issues!
On the other hand, as soon as email goes down, you may as well skip out for the rest of the day.
* - not all at once, please.
Attn Introverts: being an extrovert is a job skill
on
The Importance of Lunch
·
· Score: 3, Insightful
In today's job market you should be more aware than ever that even in technical positions, it's often who you know, not what you know that gets you the job, that lets you keep the job, that keeps you over the cut-off line when there's layoffs, that has you in line for raises, that has you spearheading the neat new technologies, that has non-technical folks deferring to you.
I know the idea of a code ninja who silently fixes problems with nary a word might seem romantic. I get it when people say they need personal time for introspection and analysis. There are many people out there who simply work better by themselves.
Just keep in mind that your skills need to be exponentially better than those of your peers if you're going to stand out by product/efficiency/quality alone. The guy who keeps asking you for help and self-promotes his achievements is going to end up with a raise while your name is going to pop up at the budget meetings as a potential cut after several years of 'meets expectations' evaluations.
So, do yourself a favor, find some quiet time and think about it.
From the article: "This is the talent that our country has invested so much resource in producing."
Really? So, the country pays for college, makes sure that people who take graduate degree programs and such, not only do not have to pay for their education, but actually gives them a stipend to live on that exceeds the poverty line? They also go so far as to provide free, high quality medical care, insurance, and ensures that everyone involved in education are provided with a higher standard of living and guaranteed employment.
Isn't the investment on the part of the 'talent' ? Don't they take the risk, expend the effort, pay the price? How many people do you expect to attend college with the goal of complete altruism? Baring altruism, why is there a belief that a purchased education leaves the graduate with a debt to the country/society? That's a bit presumptuous, don't you think?
The author is displaying his bias pretty heavily. He's a professional academic. He's got honorary positions at prestigious universities, he's got tenure, and as far as he's concerned - free access to a great deal of resources. He can't even make the connection anymore with students and the athletic clubs being responsible for his salary. He seems to imply it comes from thin air, or a magic coddling government to which we all owe a social debt that can only be repaid by devoting your life to.
There's no other way to say it; his statements mark him as delusional.
I have worked with the NFB on projects before, and prior to that when I was contracting at IBM, I was the section 508 guy for my group. I have a decent bit of insight into accessible software development, and push for it's inclusion at my current workplace.
However, realize that the NFB is an advocacy group. They do not care about business needs, or the cost of adding support for screen readers to your application. They could care less that you need to spend 40% of the project costs retooling, or increase the work effort by 20%, in order to support approximately.3% of the population. They simply want it to work for them - as it should be, and the rest is your problem.
So, what's is that problem?
Well, businesses have roadblocks in realizing that providing accessibility standards for your software is a losing proposition - the NBT actively attempts to cloud this viewpoint or strike it down as morally objectionable. However, it is unlikely that the level of effort that goes into producing an accessible application or website will ever show any reasonable return. Additionally, as with all software, the later in the game is is added, the more expensive it is - so retooling an app is worse than the cost of folding it in from the beginning. So we're looking at a big expense with no return - low ROI.
Beyond all this, non-sighted or otherwise impaired individuals are already coping with non-accessible interfaces on a daily basis. They have specialty software that helps them cope with this, and in other cases, there are learned workarounds. Just like a Microsoft product user, they are conditioned to accept the failures, and while aggravating, they can usually accomplish their goals regardless.
So, what are my points?
1) Never agree to retool an existing app (though you can accept submissions) 2) While in the planning stages decide what level of accessibility support you're going to aim for. It's increasingly expensive, especially the QA side where there's a severe demand for accessibility testers. Make a rational cost-based analysis. Some things you get for free just by adhering to strict HTML standards (like providing alt text for your images AND LINKS, or properly labeling your tables with a summary attribute, and column descriptions) for webapps. 3) Don't ever sweat the compliance if it's hard to do at any one point - it's simply not financially worth it. Go for as much as you can. All the rich "web 2.0" features which make the difference between a sale or a miss don't translate well in the accessibility world. It won't help your product if it's accessible if no one is going to use it. Remember - unless the laws change, compliance is usually a 'good to have feature' - not a 'must have'. Prioritize it well. 4) Harsh though it may seem, you can rely on your disabled users to provide their own solutions. Your software is unlikely to be a required resource - worse comes to worse, they can always use something else willing to lose money by supporting specialty groups.
When I was a kid, I had a mental map of all the arcade games in town - and in the next few towns too. We had 2-3 arcades, for a while at least. Star Worlds, Aladdin's Castle, The Machine... Sure, sometimes it was a sit-down conversion of karnov in a bowling alley that was never open except for league play, or a double dragon console with the first player punch button broken in a 7-11, or even a robotron in the back of a newspaper/magazine & soda jerk place.
The thing about it was, in all these various locations, there was nothing as dangerous or decrepit looking at that chinatown arcade looked. I lived outside of chicago, and the seedy bars we went to because they had zaxxon and vanguard (with the sound turned off) were more reputable looking than that place.
So no wonder this one is closing. It looks like it's falling down. Or waiting in an alley to shiv you.
I've been at various times, a syadmin, a dba, sec/op, developer, manager and even took my turns at answering the phones at one point in time. Often, several of these roles at once. I've been on every side of this issue, and if you wanted to take a stab at a generic fix, it could be summed up simply: work on your communication skills.
I hate to plug agile, but the focus on round table discussion among all stakeholders really seems to be the way to go. Aside from the criminal examples, the problems in the article all stem from lack of understanding or an inability to explain. Making the people who dream it (sales & marketing) sit with the people who make it (developers, dbas), the people that make it go (admins, security), and the people who say go or no-go (managers), is required if you're going to churn out products with as little strife as possible. Devs need requirements and tools, DBAs and Admins need hardware budgets and usage estimates, Security needs the policy followed or amended, Management needs to keep costs down and cycle time high, and so on. You need to communicate this to all members, not just via project managers.
The article ends with a choice quote: "The top sources of conflict are the tech person's ego, poor management, a lack of proper leadership, and allowing technical people to make business decisions. The solution there is to know your role and let your talents shine where they should."
No. This is just a quote to sell services to non-technical management. Paraphrased: "Those silly technical people have no social skills, or business acumen. It's their all their fault, pay us to tell you why" with a subtext of, 'use this to ensure your year-end bonus to the board, and why only the grunts should be fired'. Everything in there perpetuates the myth of the antisocial nerd, incapable of everything but a magic control over computers.
As an aside, I think the devs get it the worst. Requirements always suck, always move, and often conflict, management always moves up dates, removes people, adds features, and rearranges priorities in the 11'th hour. Some companies don't allow devs to install local software, slowing development. Most hardware allocation requests have to come from them, instead of the product managers, so it's often one dev vs. dba/sec/admin- department. Operations crews don't want to learn new systems or introduce esoteric requirements only after software is gold, and so on.
For some reason, no one has problems when security or admins say it will take 3 weeks for a badge or new hard drive, but expect developers to rewrite software in a day. I often wonder if it's just that the dev department never does a good job training their manager compared to the other groups.
- If you're going to cheat, you should attempt to not get caught. - The more people that know, the more likely you're going to get caught. Therefore, cheating only works when it's a small number of people who can keep a secret. Preferably one.
"What you're suggesting is that just because corporations now have the affordable tools necessary to spy on us constantly that we should deal with it and they should be allowed to do it."
Except this is the exact opposite of spying. Spying is where one party goes through the trouble of finding out what another has kept hidden. In this case, it's one party simply compiling what another person has made public (even if doing so unknowingly). The problem is the people, and what they're making public, not the company - or individual - who is compiling it.
This might be an important point, to show you how unreasonable your idea is: You're claiming that it's a breach of privacy by a company, but a single individual could perform the same searches. If you were worried about that public privacy, you would necessarily need to apply these sorts of restrictions to individuals as well. Is it any different if a company takes a picture of the front of your house, than if someone stalking you does it? Or even just a random tourist walking by?
When you make statements like this: "The real answer is requiring companies to ask permission and bar them from trying to compel people to give them the permission," change your phrasing to 'individuals or companies'.
I know it's not what you said - that I'm changing your argument based on it's logical outcome and scope, but please consider what this would turn to.
It wouldn't stop at suing companies for making a hiring decision based on facebook photos of you in a drunken state. An individual could start suing individuals for breach of privacy because they decided not to date you based on something they found you wrote in your blog. Or for not voting for you because of what they read in the newspaper about your affair. Ever tried to get every person in a photo you took at the beach while on vacation to 'opt-in' to allow you to take it?
Eventually, you could sue someone for remembering what you said in a conversation loud enough to overhear.
It comes down to the fact that regardless of the legislation that's out there, it's impossible to put the cat back in the bag once it's out. Some folks rely on that fact when releasing information on the internet. If you want to have an expectation of what you consider private to STAY private, you must actually make sure to keep it private - and not release it to the public.
I can't see how this isn't just a commonsense view.
If it's posted in a public space - it's not private If it's accessible via public records - it's not private If it occurs in a public forum - it's not private If, for legal reasons, it must be disclosed in public - it's not private... and so on.
If someone were to compile that set of information in an easy-to-read for, complete with a table of contents and nice index, that is also not invasion of privacy. Using a computer to do the heavy lifting and reducing the time required to match everything together is also not invasion of privacy.
Listen, if you're talking about the privacy of your public information, and you're threatened by search engines, you are relying on security through obscurity. At least the people here on slashdot should recognize the follow of that.
It may be different in Canada, but in the US, the professors in the field of education tend to be some of the greatest contributors to the various scientific fields. They generally don't work for the government or the industry.
Let me see if I've got this right: If robot 1: make 2 paths to fixed positions, stay at the second. if robot 2: follow the path to the first fixed position.
Result: 75% of the time, robot 2 ended at the wrong (first) position. 25% of the time, robot 1 failed to mark the first path because it didn't physically bump the markers properly.
Did you even need robots? Couldn't you have just written this on a whiteboard? There's no thought or analysis that appears to occur. I don't see anywhere that indicates there was learning going on. What is this even proving?
I'm really honestly baffled what they're trying to prove.
Perhaps there was some sort of neural net or some other sort of optimizing heuristic on the first robot's part so that this was emergent deceptive behavior, this might be even a little interesting (though, not really...). However, all I can see is a waste of time to prove that if you present two choices, and you pick the wrong one, then you will be wrong. With robot for visual demonstration.
If someone is putting up classified information in a publicly accessible location (even if it's restricted by the user giving explicit permission), isn't that the source of the information leak? Hasn't it already escaped the secure environment? Jeremiah Grossman even points this out. (I do like how they indicate he was duped, when he indicates that it's an automatic facebook bot that runs on his behalf that accepts all requests automatically - that isn't 'his' account.)
Of course, this assumes that the information was considered secure in the first place. I'm not sure you'd call it a security leak if the policy is to allow that information to be accessible to the public.
That aside, isn't this just an online-only update of the standard telephony scam that the military actually sponsored and publicized back in the late 60's/early 70's? To show how social engineering worked, they sat a woman down in a room with a phonebook and a phone, and asked her to get some general's schedule or something, and it took about 40 minutes?
We are already aware of the fact that organizations have social structures which allow for manipulation. Was there anything constructive about this, like a 'policies to avoid this' list? Or was this just another fluff piece, reiterating what was already well established?
I wish I could find the references I'm looking for, but 10 minutes of google seems to be failing me.
There was an environmental scientist who had his own show in the 70's and 80's, one of the first pro-environmental shows, big into opposing deforestation, one of the first to advocate recycling, and so on. When global warming started becoming a hot topic, he said;
1) I don't see conclusive evidence it's caused by man
and 2) If it is happening, the best way to fight it isn't emission controls, it's protecting the rainforests.
He lost his show, was removed from the public eye, any further work was mostly ignored; he was blacklisted.
There's a few people that agree with him, of course, (Here and here for example), but by and large he's been ostracized because he didn't toe the line. In the parlance of grant work, emission studies were sexy, and pushing protection of rain forests was not.
There are many environmental scientists that have been blacklisted for having dissenting views. This is what I really have a problem with.
I find that the debate about whether global warming is due to man or not is being handled with politics, not with reason. Perhaps this is why even in the small group of posters here, I see obvious evidence of closed minds. When I see an individual state a hypothesis (even one with good evidence) as a fact, it's bad enough, but when it is followed up with a statement indicating that anyone doubting them is an idiot - that is not science or rationality. I see individuals making a claim, and then stating that because no argument they accept disproves it, that it must be true - a negative proof, and a fallacy.
In fact, the game industry thrives on just-out-of-college developers, or technically-interns-but-not-going-back.
You've all seen the articles, they burn through developers like mad. They need the young and inexperienced because they don't complain when they make 1/3 of industry average for 2x the hours and no job security. There are only a few senior members that stay on. The 'complex' parts of the program are bought from middlewear or game engine companies or developed by their seniors. The tailoring - that's left to the newbies. I got to see the team for one of the cookie-cutter Madden-20xx games, and 80% of them appeared within a year of 20.
You hire young, keep the price and expectations low, train em how you want, and ditch them as soon as they become too expensive, or you can find another kid who costs less.
The point isn't one specific number, it's being marked at all.
According to that mythology, you get a choice to receive a mark or not, either on your hand or forehead. If you don't have the mark, people are not allowed to do business with you - you cannot buy food, etc.
The big problem though, is this; before this all happens, 144k jews will be saved (the 'rapture'), and everyone else is pretty much doomed to hell. The choice of having the mark or not doesn't come until later. So, basically if you ever reach the point where you are offered a mark or not, it is already too late for you.
Would be the RAT 9; http://www.cyborggaming.com/prod/rat9.htm. Frankly, the only problem I have with modern mice is that they seem to be made for people with shrunken, perhaps t-rex-like, children's hands. The idea of a mouse with somewhat adjustable areas sounds like a good start.
Of course, the price is insane, so I'd have to check it out in a store before I'd ever buy one. Still, I'm on board with the general concept.
Slashdot Mirror
... it's one of convenience.
When you, as a consumer, buy an item out of state, receive a gift, or win money from gambling - or a slew of other sources - you're expected to report your winnings to the state so they can tax it. The problem is that people don't. They either don't know, don't care, or don't worry about residental-level tax evasion being enforced. So technically the mechanisms for taxes already covers this, but it would take each state a lot of effort to track down each evader and retrieve their monies due (though one could argue that, along with fines and the jobs this would create, it could be a good thing for the state). So, basically it's really tough for them, since they wrote laws which are hard to enforce.
That's the issue. It's not convenient for the state to collect tax money.
So now they're attempting to change the laws so it's easy - they make the online retailers responsible for collecting money on their behalf and it's fine. Then they have one place to go to collect, instead of hundreds of thousands that have to be litigated. They're attempting to make online retailers - like Amazon - bear the burden that they themselves do not wish to shoulder (granted, it's easier for Amazon, but by no mean effortless). They're stretching the interpretation of existing laws to claim that in-state third parties Amazon has a business relationship represent a direct presence by Amazon, and thus they must follow the state laws for brick and mortar vendors.
If you ~had~ to bring up ethics, you should probably look at the state lawmakers. They're acting like the stereotypical royal taxmen: they see you have money, and they will make up any excuse they can to liberate it from you. Moreso now, due to budget/economy constraints they have to work under.
I've almost lunged across a transatlantic gap and strangled someone through a phone line because they indicated I needed to rewrite my entire program to encode the names of the design patterns I was using into my object names and methods, or they would block my submission. This from a fellow who bulk submitted about 30 changes resulting in the build being broken for a week and a half. ...
That said, there IS a place for it. Code architecture is somewhat subjective, and two people may come up with a more effective solution to a problem than either working solo. The problem is scope and zealots.
Code reviews are good for finding bugs and - if you happen to have one - confirming to a coding style guide. This means that we'll be more likely to find bugs, and the code will be potentially easier to maintain. Seems like it's an easy win, at the cost of some small amount of dev time.
However, there's a big list of detriments.
Let's take the average developer, who stereotypically has a social coping mechanism that is ... shall we say off-by-one. Take the thing he does well, and subject it to criticism every time he does it. Keep in mind that many aspects of software development are subjective; how to 'best' write a function, or how to architect a component. That means the criticism isn't constrained to bug fixes (valid) or coding style (valid, even if you dislike them) - it's about personal choices.
Also, there's an issue with ownership. We, as developers, often grow attached to a piece of code and no matter how poorly written or convoluted it is, there's still a certain amount of hurt associated with someone else wanting to change it. This is the case even if we just get assigned to maintain some piece of garbage code we don't even want to deal with.
Then add deadlines. We all know that developing bulletproof code is largely a matter of time. Time to analyze, time to review, time spent peer programming instead of solo, time writing documentation, time writing and running tests, etc. There's good reason that functionality comes first and docs come last in most environments, and it's out of the developer's hands. That's another source of stress since you're tripling the load for each submission: first you have to write it, then you have to go over it with another person in fine detail comparable to writing it. That's assuming you believe you write perfect code to begin with, and don't spend longer than normal reformatting and rewriting your code to make the reviewer happy.
Take those added stresses and add them over and over, and tell me that won't change the coder's behavior in some way. In most places I've worked, this usually results in developers picking 'safe' reviewers - people who don't review in depth, people who don't have the time to do a good job, or people who will defer to the original developer due to perceived differences in experience or rank. In some cases, it means that large rewrites are avoided, and hacks put in place instead, because it's easier to get a 30 line hacked-in function successfully reviewed than a 30 file change. It also appears to limit the creation of new functionality to some extent - if you're breaking ground, everyone has a chance to critique your methods. Most seem to find a way to route around 'damage' in the process, especially if you have any zealots on your team.
Personally, I prefer the more objective code analysis and coverage tools, test driven development, and most important, consensus among developers on questions of architecture prior to implementation. Code can be accessed by those wishing to review it after the fact (which, like refactoring, almost never happens), and it can be handled on an informal level if necessary.
As far as ROI is concerned, this seems to be the most effective and efficient mechanism. Perhaps if the user communities did not so easily accept computer/software failures, this would not be the case.
Even with one end loosely tethered, isn't a cord stretched across any walkway an inherently dangerous thing? If not to the product, then to the person doing the tripping?
Now, my viewpoint may be biased, because I tend to use a desk when I do my work, not a coffee bar, but I've had lots of problems with these magsafe connectors; they don't stay plugged in, or they appear plugged in, but are not actually 'all' the way in. Pulling the mouse cord when it gets stuck dislodges it, rotating the monitor a little bit dislodges them, throwing a wayward glance in their direction freakin' dislodges them.
Besides that, shouldn't we already be using USB for this purpose? It handles up to 240v, and while the connectors are various shapes, it's ubiquitous and would require only standardization on the hardware end, and nothing on the software side.
Every business - when it reaches a certain size - realizes that they need to have a fixed process for handling X, where X can be contract approval, printer supply purchase, production system access, hiring new employees and so on. They need it because it provides accountability, oversight, size estimation, consistency, and the higher you are in the org chart, the more important those attributes become versus one individual task's result. At some level, being able to say someone is 60% complete with 32 man hours remaining is more important than having someone who code ninjas a fix in a single night because it needs to be done. With accurate info, you can plan for resources and identify where there are problems and effect systemic change if necessary - you can't plan for "Bob did it last week without telling anyone and we didn't know he did it until today."
This is because the goal for the person (and their direct manager) is 'complete task', and 'process' can be perceived as an impediment that provides no immediate value. The more motivated that person is, the more likely they are to route around what they perceive as damage and circumvent the process in spirit, if not completely. Thus what may appear to be duplication of effort or reliance on external resources is really a myopic focus on short term goals.
In my experience, the good companies allow this, because they all realize that sometimes a time delay is unacceptable, even if it 'breaks process'. They'll say "It's better to ask forgiveness, than to ask permission." It is, of course, subjective when an employee should or should not exercise this quote.
This is just what it's like to work in a company. Nothing unusual.
Sometimes you need to state the obvious over and over again because it doesn't take much for a person to internalize a viewpoint that makes the obvious non-obvious. Like Lewis Caroll pointed out, 3 times seems to be enough.
As simple examples, Snopes take on aspartame causing cancer & tumors and as an ant poison The FDA still ends up being inundated with this claim so many times a year that they end up retesting, just to humor the population.
As a more loaded example, check out the belief systems of anyone who claims they are strongly religious. Or Truthers. Or Birthers.
Sadly, it appears that the majority of the population needs to be told what is obvious over and over.
One in a long line of recent changes:
You're not getting a snow day - you're following the infrastructure interruption business continuity plan!
other fun entries are:
You're no longer sick - you're working remotely!
You're no longer on vacation - you're off site with limited access!
You're no longer driving in your car/using the bathroom/eating a meal* - you're responsive to electronic communications!
You're no longer sleeping - you're managing cross-time-zone issues!
On the other hand, as soon as email goes down, you may as well skip out for the rest of the day.
* - not all at once, please.
In today's job market you should be more aware than ever that even in technical positions, it's often who you know, not what you know that gets you the job, that lets you keep the job, that keeps you over the cut-off line when there's layoffs, that has you in line for raises, that has you spearheading the neat new technologies, that has non-technical folks deferring to you.
I know the idea of a code ninja who silently fixes problems with nary a word might seem romantic. I get it when people say they need personal time for introspection and analysis. There are many people out there who simply work better by themselves.
Just keep in mind that your skills need to be exponentially better than those of your peers if you're going to stand out by product/efficiency/quality alone. The guy who keeps asking you for help and self-promotes his achievements is going to end up with a raise while your name is going to pop up at the budget meetings as a potential cut after several years of 'meets expectations' evaluations.
So, do yourself a favor, find some quiet time and think about it.
I remember abandoning it for Might and Magic (I & II), and then returning to the series when I got a hold of Ultima V. Ultima V kicked serious butt!
How come no one ever wants to remake/re-release/re-whatever that one?
*goes in a corner and plays the stones song*
From the article: "This is the talent that our country has invested so much resource in producing."
Really? So, the country pays for college, makes sure that people who take graduate degree programs and such, not only do not have to pay for their education, but actually gives them a stipend to live on that exceeds the poverty line? They also go so far as to provide free, high quality medical care, insurance, and ensures that everyone involved in education are provided with a higher standard of living and guaranteed employment.
Isn't the investment on the part of the 'talent' ? Don't they take the risk, expend the effort, pay the price? How many people do you expect to attend college with the goal of complete altruism? Baring altruism, why is there a belief that a purchased education leaves the graduate with a debt to the country/society? That's a bit presumptuous, don't you think?
The author is displaying his bias pretty heavily. He's a professional academic. He's got honorary positions at prestigious universities, he's got tenure, and as far as he's concerned - free access to a great deal of resources. He can't even make the connection anymore with students and the athletic clubs being responsible for his salary. He seems to imply it comes from thin air, or a magic coddling government to which we all owe a social debt that can only be repaid by devoting your life to.
There's no other way to say it; his statements mark him as delusional.
I have worked with the NFB on projects before, and prior to that when I was contracting at IBM, I was the section 508 guy for my group. I have a decent bit of insight into accessible software development, and push for it's inclusion at my current workplace.
However, realize that the NFB is an advocacy group. They do not care about business needs, or the cost of adding support for screen readers to your application. They could care less that you need to spend 40% of the project costs retooling, or increase the work effort by 20%, in order to support approximately .3% of the population. They simply want it to work for them - as it should be, and the rest is your problem.
So, what's is that problem?
Well, businesses have roadblocks in realizing that providing accessibility standards for your software is a losing proposition - the NBT actively attempts to cloud this viewpoint or strike it down as morally objectionable. However, it is unlikely that the level of effort that goes into producing an accessible application or website will ever show any reasonable return. Additionally, as with all software, the later in the game is is added, the more expensive it is - so retooling an app is worse than the cost of folding it in from the beginning. So we're looking at a big expense with no return - low ROI.
Beyond all this, non-sighted or otherwise impaired individuals are already coping with non-accessible interfaces on a daily basis. They have specialty software that helps them cope with this, and in other cases, there are learned workarounds. Just like a Microsoft product user, they are conditioned to accept the failures, and while aggravating, they can usually accomplish their goals regardless.
So, what are my points?
1) Never agree to retool an existing app (though you can accept submissions)
2) While in the planning stages decide what level of accessibility support you're going to aim for. It's increasingly expensive, especially the QA side where there's a severe demand for accessibility testers. Make a rational cost-based analysis. Some things you get for free just by adhering to strict HTML standards (like providing alt text for your images AND LINKS, or properly labeling your tables with a summary attribute, and column descriptions) for webapps.
3) Don't ever sweat the compliance if it's hard to do at any one point - it's simply not financially worth it. Go for as much as you can. All the rich "web 2.0" features which make the difference between a sale or a miss don't translate well in the accessibility world. It won't help your product if it's accessible if no one is going to use it. Remember - unless the laws change, compliance is usually a 'good to have feature' - not a 'must have'. Prioritize it well.
4) Harsh though it may seem, you can rely on your disabled users to provide their own solutions. Your software is unlikely to be a required resource - worse comes to worse, they can always use something else willing to lose money by supporting specialty groups.
When I was a kid, I had a mental map of all the arcade games in town - and in the next few towns too. We had 2-3 arcades, for a while at least. Star Worlds, Aladdin's Castle, The Machine... Sure, sometimes it was a sit-down conversion of karnov in a bowling alley that was never open except for league play, or a double dragon console with the first player punch button broken in a 7-11, or even a robotron in the back of a newspaper/magazine & soda jerk place.
The thing about it was, in all these various locations, there was nothing as dangerous or decrepit looking at that chinatown arcade looked. I lived outside of chicago, and the seedy bars we went to because they had zaxxon and vanguard (with the sound turned off) were more reputable looking than that place.
So no wonder this one is closing. It looks like it's falling down. Or waiting in an alley to shiv you.
I've been at various times, a syadmin, a dba, sec/op, developer, manager and even took my turns at answering the phones at one point in time. Often, several of these roles at once. I've been on every side of this issue, and if you wanted to take a stab at a generic fix, it could be summed up simply: work on your communication skills.
I hate to plug agile, but the focus on round table discussion among all stakeholders really seems to be the way to go. Aside from the criminal examples, the problems in the article all stem from lack of understanding or an inability to explain. Making the people who dream it (sales & marketing) sit with the people who make it (developers, dbas), the people that make it go (admins, security), and the people who say go or no-go (managers), is required if you're going to churn out products with as little strife as possible. Devs need requirements and tools, DBAs and Admins need hardware budgets and usage estimates, Security needs the policy followed or amended, Management needs to keep costs down and cycle time high, and so on. You need to communicate this to all members, not just via project managers.
The article ends with a choice quote:
"The top sources of conflict are the tech person's ego, poor management, a lack of proper leadership, and allowing technical people to make business decisions. The solution there is to know your role and let your talents shine where they should."
No. This is just a quote to sell services to non-technical management. Paraphrased: "Those silly technical people have no social skills, or business acumen. It's their all their fault, pay us to tell you why" with a subtext of, 'use this to ensure your year-end bonus to the board, and why only the grunts should be fired'. Everything in there perpetuates the myth of the antisocial nerd, incapable of everything but a magic control over computers.
As an aside, I think the devs get it the worst. Requirements always suck, always move, and often conflict, management always moves up dates, removes people, adds features, and rearranges priorities in the 11'th hour. Some companies don't allow devs to install local software, slowing development. Most hardware allocation requests have to come from them, instead of the product managers, so it's often one dev vs. dba/sec/admin- department. Operations crews don't want to learn new systems or introduce esoteric requirements only after software is gold, and so on.
For some reason, no one has problems when security or admins say it will take 3 weeks for a badge or new hard drive, but expect developers to rewrite software in a day. I often wonder if it's just that the dev department never does a good job training their manager compared to the other groups.
- If you're going to cheat, you should attempt to not get caught.
- The more people that know, the more likely you're going to get caught.
Therefore, cheating only works when it's a small number of people who can keep a secret. Preferably one.
"What you're suggesting is that just because corporations now have the affordable tools necessary to spy on us constantly that we should deal with it and they should be allowed to do it."
Except this is the exact opposite of spying. Spying is where one party goes through the trouble of finding out what another has kept hidden. In this case, it's one party simply compiling what another person has made public (even if doing so unknowingly). The problem is the people, and what they're making public, not the company - or individual - who is compiling it.
This might be an important point, to show you how unreasonable your idea is: You're claiming that it's a breach of privacy by a company, but a single individual could perform the same searches. If you were worried about that public privacy, you would necessarily need to apply these sorts of restrictions to individuals as well. Is it any different if a company takes a picture of the front of your house, than if someone stalking you does it? Or even just a random tourist walking by?
When you make statements like this: "The real answer is requiring companies to ask permission and bar them from trying to compel people to give them the permission," change your phrasing to 'individuals or companies'.
I know it's not what you said - that I'm changing your argument based on it's logical outcome and scope, but please consider what this would turn to.
It wouldn't stop at suing companies for making a hiring decision based on facebook photos of you in a drunken state. An individual could start suing individuals for breach of privacy because they decided not to date you based on something they found you wrote in your blog. Or for not voting for you because of what they read in the newspaper about your affair. Ever tried to get every person in a photo you took at the beach while on vacation to 'opt-in' to allow you to take it?
Eventually, you could sue someone for remembering what you said in a conversation loud enough to overhear.
It comes down to the fact that regardless of the legislation that's out there, it's impossible to put the cat back in the bag once it's out. Some folks rely on that fact when releasing information on the internet. If you want to have an expectation of what you consider private to STAY private, you must actually make sure to keep it private - and not release it to the public.
I can't see how this isn't just a commonsense view.
If it's posted in a public space - it's not private ... and so on.
If it's accessible via public records - it's not private
If it occurs in a public forum - it's not private
If, for legal reasons, it must be disclosed in public - it's not private
If someone were to compile that set of information in an easy-to-read for, complete with a table of contents and nice index, that is also not invasion of privacy.
Using a computer to do the heavy lifting and reducing the time required to match everything together is also not invasion of privacy.
Listen, if you're talking about the privacy of your public information, and you're threatened by search engines, you are relying on security through obscurity. At least the people here on slashdot should recognize the follow of that.
It may be different in Canada, but in the US, the professors in the field of education tend to be some of the greatest contributors to the various scientific fields. They generally don't work for the government or the industry.
Let me see if I've got this right:
If robot 1: make 2 paths to fixed positions, stay at the second.
if robot 2: follow the path to the first fixed position.
Result: 75% of the time, robot 2 ended at the wrong (first) position. 25% of the time, robot 1 failed to mark the first path because it didn't physically bump the markers properly.
Did you even need robots? Couldn't you have just written this on a whiteboard?
There's no thought or analysis that appears to occur. I don't see anywhere that indicates there was learning going on. What is this even proving?
I'm really honestly baffled what they're trying to prove.
Perhaps there was some sort of neural net or some other sort of optimizing heuristic on the first robot's part so that this was emergent deceptive behavior, this might be even a little interesting (though, not really ...). However, all I can see is a waste of time to prove that if you present two choices, and you pick the wrong one, then you will be wrong. With robot for visual demonstration.
So the only thing I have to add is a Nelson-like "Haw-Haw!"
If someone is putting up classified information in a publicly accessible location (even if it's restricted by the user giving explicit permission), isn't that the source of the information leak? Hasn't it already escaped the secure environment? Jeremiah Grossman even points this out. (I do like how they indicate he was duped, when he indicates that it's an automatic facebook bot that runs on his behalf that accepts all requests automatically - that isn't 'his' account.)
Of course, this assumes that the information was considered secure in the first place. I'm not sure you'd call it a security leak if the policy is to allow that information to be accessible to the public.
That aside, isn't this just an online-only update of the standard telephony scam that the military actually sponsored and publicized back in the late 60's/early 70's? To show how social engineering worked, they sat a woman down in a room with a phonebook and a phone, and asked her to get some general's schedule or something, and it took about 40 minutes?
We are already aware of the fact that organizations have social structures which allow for manipulation. Was there anything constructive about this, like a 'policies to avoid this' list? Or was this just another fluff piece, reiterating what was already well established?
I wish I could find the references I'm looking for, but 10 minutes of google seems to be failing me.
There was an environmental scientist who had his own show in the 70's and 80's, one of the first pro-environmental shows, big into opposing deforestation, one of the first to advocate recycling, and so on. When global warming started becoming a hot topic, he said;
1) I don't see conclusive evidence it's caused by man
and
2) If it is happening, the best way to fight it isn't emission controls, it's protecting the rainforests.
He lost his show, was removed from the public eye, any further work was mostly ignored; he was blacklisted.
There's a few people that agree with him, of course, (Here and here for example), but by and large he's been ostracized because he didn't toe the line. In the parlance of grant work, emission studies were sexy, and pushing protection of rain forests was not.
There are many environmental scientists that have been blacklisted for having dissenting views. This is what I really have a problem with.
I find that the debate about whether global warming is due to man or not is being handled with politics, not with reason. Perhaps this is why even in the small group of posters here, I see obvious evidence of closed minds. When I see an individual state a hypothesis (even one with good evidence) as a fact, it's bad enough, but when it is followed up with a statement indicating that anyone doubting them is an idiot - that is not science or rationality. I see individuals making a claim, and then stating that because no argument they accept disproves it, that it must be true - a negative proof, and a fallacy.
That's not science. That's a religion.
In fact, the game industry thrives on just-out-of-college developers, or technically-interns-but-not-going-back.
You've all seen the articles, they burn through developers like mad. They need the young and inexperienced because they don't complain when they make 1/3 of industry average for 2x the hours and no job security. There are only a few senior members that stay on. The 'complex' parts of the program are bought from middlewear or game engine companies or developed by their seniors. The tailoring - that's left to the newbies. I got to see the team for one of the cookie-cutter Madden-20xx games, and 80% of them appeared within a year of 20.
You hire young, keep the price and expectations low, train em how you want, and ditch them as soon as they become too expensive, or you can find another kid who costs less.
The point isn't one specific number, it's being marked at all.
According to that mythology, you get a choice to receive a mark or not, either on your hand or forehead. If you don't have the mark, people are not allowed to do business with you - you cannot buy food, etc.
The big problem though, is this; before this all happens, 144k jews will be saved (the 'rapture'), and everyone else is pretty much doomed to hell. The choice of having the mark or not doesn't come until later. So, basically if you ever reach the point where you are offered a mark or not, it is already too late for you.
It's all laid out in a most reasonable fashion here; http://www.thebricktestament.com/revelation/
Wait, it's india. Wouldn't they relish the chance to be treated like cattle?
Would be the RAT 9; http://www.cyborggaming.com/prod/rat9.htm. Frankly, the only problem I have with modern mice is that they seem to be made for people with shrunken, perhaps t-rex-like, children's hands. The idea of a mouse with somewhat adjustable areas sounds like a good start.
Of course, the price is insane, so I'd have to check it out in a store before I'd ever buy one. Still, I'm on board with the general concept.