Over a period of roughly seven business days, traffic had slowed to a crawl at the Tampa, Fla.-based firm, which had outsourced its IT department to The Revere Group. GunnAllen's acting CIO, a Revere Group partner, asked a member of the IT team to investigate.
Well, here we go! The CIO of the company outsourced the IT department to..... his own personal company. No conflict of interest there!
Learn programming fundamentals, data structures, algorithms, encapsulation. Multiple languages and technologies. For god sake, don't pin yourself to Microsoft technologies--you're going to be on a permanent treadmill. Any given MS technology is guaranteed to be obsolete soon, once they decide that they want to sell another latest "enterprise solutions" package with all new technologies.
Someone help me with that one. So it tricks users into sending an expensive SMS. So how in the world does that enrich the hackers? I pay my SMS fees to AT&T. Are we saying that AT&T is behind these attacks?
The thread was about "what counts as risk." I'll leave the determination of whether entrepreneurship SHOULD require personal risk to another discussion.
My point was, many (most?) business owners who claim to be "taking a risk" with their start-up are actually not, comparatively.
This is just anecdotal, but most start-up owners I've worked with were already quite wealthy and/or had a family cushion to fall back on in the event of failure. Sure, they risked some start-up capital, but orders of magnitude less risky than literally putting your life on the line in a dangerous job. I know a guy whose family is quite well-off, who started and failed about 4 or 5 businesses before one finally happened to take off. He could keep spinning the wheel of fortune because he knew that regardless of what happened he wouldn't starve or be homeless. That sure doesn't sound like risk-taking to me.
That said, I have met a few who had their personal savings and home equity loans on the line if their start-ups failed. That's, for sure, respect-earning balls-out risk. Those guys definitely deserve their returns.
- take that for example, should the people who were hired by a successful startup and were promised something in case the company succeeds get more than those, who take more salary upfront?
What about various Google employees who became millionaires, do you think they were not "productive"? They got pretty wealthy as a result of "options".
I wouldn't say they were, on average, necessarily more productive than the average tech start-up employee. Getting rich from stock options is basically like winning the lottery. You luck into being one of the first few employees at a company, and your company lucks into being one of ones that happen to make it. Right place at the right time.
I've met tons of really smart, productive people toiling away for a salary with no equity upside. I've also met tons of really unproductive people who never have to work again simply because they happened to be employee number 19 and their options turned them into millionaires.
1. You have to schedule time off from work. This can be extremely difficult if you work multiple jobs. 2. You have to forgo the pay you would have gotten (unless you're lucky enough to have paid vacation). 3. You have to plan the trip, book airline tickets, book hotels, book transportation, etc. or pay someone to do it. 4. The expense of the above. 5. If we're talking international travel, there's the hassle of getting a passport, visa, currency exchange, language barrier, etc. 6. If you have kids, you have to figure out WTF you're going to do with them, or bring them along.
This is a great point. Before all this technology, you had to find paper photos of some place that other people took, or had to have the financial and physical means to actually go somewhere to see it. Google has opened up experiences to people who otherwise wouldn't have been able to take part.
I guess we're going to have to agree to disagree then. To me, requirements document what the program is and does, not what it isn't or doesn't do. It makes as much sense to write in a spec "Do not put any character constraints on this text field," as it does to write "Do not display a purple elephant in this window."
I'll admit that I left out the beginning of the conversation:
Me: "Users are reporting that we are silently dropping punctuation characters from this text field."... now try this, go back and re-read the conversation in that light, and notice how that one line changes everything. We now have a developer trying to weasel away from his bug (turns out he added un-asked-for logic to filter out non-alpha-numeric characters), pointing to the spec claiming that the full allowed character set should have been specified if that's what I wanted.
Having been recently a developer (I'm only just now starting to grow my pointy hair), I definitely have mixed feelings about the "Must have complete 5000 page requirements document in order to write any code" mentality. It's extremely important to have clear, unambiguous requirements for the major software features, important business logic, etc. But some developers take it too far: They can't take a dump without a detailed spec and written use cases. Other developers take a lack of specification to mean "Insert whatever goofy logic I feel like", like the above (otherwise, very talented) developer did in this case. In my documents, I tend to stick to specifying what is required. If I also have to list what is NOT required, you're going to find yourself with a 5000-page document for an iPhone app.
My intention in the post was not to launch a "1-pager vs. full-specification argument" although it's an interesting discussion. It was merely to point out how ingrained into developers' heads the idea of a "special" character has become, for whatever reason. I've been asked way too often "should we allow 'special' characters here?"
And yes, I understand the distinction between printable and non-printable becomes less clear when unicode comes into play.
It's a good point about length. It's probably fine to specify an upper AND lower length limit. Is there actually some standard or best practice out there regarding allowed characters in passwords?
The question that should be asked is, "What's a 'Special Character' and why shouldn't it be allowed in a password?"
I had this argument with a developer the other day.
Him: "What characters should be allowed in this text field?" Me: "Um, How about all of them, at least the printable ones." Him: "What about special characters?" Me: "Give me an example." Him: "The ! sign" Me: "What's so special about that? I can type it? I use it at the end of some sentences when I'm angry. Why would you not allow it?" Him: "What about non-latin characters?" Me: "What, are they special too?" Him: "You need to specify a list of every character that is allowed in the text field, otherwise I cannot program it." Me: [Facepalm]
etc..
There doesn't seem to be any compelling security reason to exclude certain characters from eligibility for use in a password.
It's not a silver bullet, but lack of a test environment is sure to eventually cause disaster. It's by far the biggest problem mentioned above, even more of a problem than lack of version control.
Yes!!! Create git repos of all those various parts on some central git server. Create backups of those repos periodically, like a sane person...
The great thing about git is that there is no need for "central servers" or other such infrastructure. Just back up the current repositories wherever they are located.
Limited liability allows one to not be personally liable for everything their company does. Before the concept of limited liability was created, everybody was personally liable for everything their company did. If everybody were personally liable for everything their company did, nobody would run companies. Therefore, before the concept of limited liability was created, nobody would run companies.
Slashdot Mirror
Well, here we go! The CIO of the company outsourced the IT department to..... his own personal company. No conflict of interest there!
So basically, you're a coward and a hypocrite. And you're teaching your kids to be that way, too.
You know, maybe people shouldn't feel like they have to "follow up" just because you can't be bothered to read your damn E-mail.
Learn programming fundamentals, data structures, algorithms, encapsulation. Multiple languages and technologies. For god sake, don't pin yourself to Microsoft technologies--you're going to be on a permanent treadmill. Any given MS technology is guaranteed to be obsolete soon, once they decide that they want to sell another latest "enterprise solutions" package with all new technologies.
Someone help me with that one. So it tricks users into sending an expensive SMS. So how in the world does that enrich the hackers? I pay my SMS fees to AT&T. Are we saying that AT&T is behind these attacks?
Who the hell is so stupid that they would just do what a random person calling them tells them to do?
WhyDoTheyAllUseCamelCase?
The thread was about "what counts as risk." I'll leave the determination of whether entrepreneurship SHOULD require personal risk to another discussion.
My point was, many (most?) business owners who claim to be "taking a risk" with their start-up are actually not, comparatively.
This is just anecdotal, but most start-up owners I've worked with were already quite wealthy and/or had a family cushion to fall back on in the event of failure. Sure, they risked some start-up capital, but orders of magnitude less risky than literally putting your life on the line in a dangerous job. I know a guy whose family is quite well-off, who started and failed about 4 or 5 businesses before one finally happened to take off. He could keep spinning the wheel of fortune because he knew that regardless of what happened he wouldn't starve or be homeless. That sure doesn't sound like risk-taking to me.
That said, I have met a few who had their personal savings and home equity loans on the line if their start-ups failed. That's, for sure, respect-earning balls-out risk. Those guys definitely deserve their returns.
- take that for example, should the people who were hired by a successful startup and were promised something in case the company succeeds get more than those, who take more salary upfront?
What about various Google employees who became millionaires, do you think they were not "productive"? They got pretty wealthy as a result of "options".
I wouldn't say they were, on average, necessarily more productive than the average tech start-up employee. Getting rich from stock options is basically like winning the lottery. You luck into being one of the first few employees at a company, and your company lucks into being one of ones that happen to make it. Right place at the right time.
I've met tons of really smart, productive people toiling away for a salary with no equity upside. I've also met tons of really unproductive people who never have to work again simply because they happened to be employee number 19 and their options turned them into millionaires.
To be honest, "real" travel is over-rated.
1. You have to schedule time off from work. This can be extremely difficult if you work multiple jobs.
2. You have to forgo the pay you would have gotten (unless you're lucky enough to have paid vacation).
3. You have to plan the trip, book airline tickets, book hotels, book transportation, etc. or pay someone to do it.
4. The expense of the above.
5. If we're talking international travel, there's the hassle of getting a passport, visa, currency exchange, language barrier, etc.
6. If you have kids, you have to figure out WTF you're going to do with them, or bring them along.
I used to love traveling, back when I had no responsibilities, family or job. Now, it seems like such a waste of time and money.
This is a great point. Before all this technology, you had to find paper photos of some place that other people took, or had to have the financial and physical means to actually go somewhere to see it. Google has opened up experiences to people who otherwise wouldn't have been able to take part.
I guess we're going to have to agree to disagree then. To me, requirements document what the program is and does, not what it isn't or doesn't do. It makes as much sense to write in a spec "Do not put any character constraints on this text field," as it does to write "Do not display a purple elephant in this window."
I'll admit that I left out the beginning of the conversation:
Me: "Users are reporting that we are silently dropping punctuation characters from this text field." ... now try this, go back and re-read the conversation in that light, and notice how that one line changes everything. We now have a developer trying to weasel away from his bug (turns out he added un-asked-for logic to filter out non-alpha-numeric characters), pointing to the spec claiming that the full allowed character set should have been specified if that's what I wanted.
Having been recently a developer (I'm only just now starting to grow my pointy hair), I definitely have mixed feelings about the "Must have complete 5000 page requirements document in order to write any code" mentality. It's extremely important to have clear, unambiguous requirements for the major software features, important business logic, etc. But some developers take it too far: They can't take a dump without a detailed spec and written use cases. Other developers take a lack of specification to mean "Insert whatever goofy logic I feel like", like the above (otherwise, very talented) developer did in this case. In my documents, I tend to stick to specifying what is required. If I also have to list what is NOT required, you're going to find yourself with a 5000-page document for an iPhone app.
My intention in the post was not to launch a "1-pager vs. full-specification argument" although it's an interesting discussion. It was merely to point out how ingrained into developers' heads the idea of a "special" character has become, for whatever reason. I've been asked way too often "should we allow 'special' characters here?"
And yes, I understand the distinction between printable and non-printable becomes less clear when unicode comes into play.
In every transaction, there's a seller, a buyer, and a product.
If you're not getting any money and you're not losing any money, guess what you are...
It's a good point about length. It's probably fine to specify an upper AND lower length limit. Is there actually some standard or best practice out there regarding allowed characters in passwords?
The question that should be asked is, "What's a 'Special Character' and why shouldn't it be allowed in a password?"
I had this argument with a developer the other day.
Him: "What characters should be allowed in this text field?"
Me: "Um, How about all of them, at least the printable ones."
Him: "What about special characters?"
Me: "Give me an example."
Him: "The ! sign"
Me: "What's so special about that? I can type it? I use it at the end of some sentences when I'm angry. Why would you not allow it?"
Him: "What about non-latin characters?"
Me: "What, are they special too?"
Him: "You need to specify a list of every character that is allowed in the text field, otherwise I cannot program it."
Me: [Facepalm]
etc..
There doesn't seem to be any compelling security reason to exclude certain characters from eligibility for use in a password.
LOL I'm sure they'd get right on it!
It's not a silver bullet, but lack of a test environment is sure to eventually cause disaster. It's by far the biggest problem mentioned above, even more of a problem than lack of version control.
Yes!!! Create git repos of all those various parts on some central git server. Create backups of those repos periodically, like a sane person...
The great thing about git is that there is no need for "central servers" or other such infrastructure. Just back up the current repositories wherever they are located.
Rule of thumb: If the software's name or description has the word "Enterprise" in it, it's going to suck.
I heard a perfect echo die
Into an anonymous wall of digital sound
Somewhere deep inside
Of my soul
You post a google cache of a white supremacist group's "science" as your evidence?
Did this silly study control for poverty or other socioeconomic factors? No, didn't think so. Go back to Stormfront, troll.
Sounds like he's talking about "localizers". Probably similar stuff found in other books as well.
Limited liability allows one to not be personally liable for everything their company does.
Before the concept of limited liability was created, everybody was personally liable for everything their company did.
If everybody were personally liable for everything their company did, nobody would run companies.
Therefore, before the concept of limited liability was created, nobody would run companies.