Comment Re:Gambling online is completely fucking stupid (Score 1) 296
I must be pretty damn lucky to be consistently winning money at internet dice year after year, huh?
You too? And here I thought I was the one in a million lottery winner!
I must be pretty damn lucky to be consistently winning money at internet dice year after year, huh?
You too? And here I thought I was the one in a million lottery winner!
Wow, just wow.
I will put it simply - you are not as good at poker as you think you are.
How do I know this? I play seriously both live AND online. I win at both, and not cheesburger stakes either (I am a winner at mid stakes at both and use it to comfortably support myself between contracts). If you can beat live but can't beat online it is not because OMGZ online is rigged! it is generally because at least at up to mid stakes online players are far better than live players.
I am happy to expand (whether you want me to or not). Online games tend to be both tighter and more aggressive. What this generally means is that an online only player coming to a live game will at first struggle with the looser more passive play. If they are tilt prone they may struggle with the greater number of suckouts in live play due to more players to the flop who will go all the way with their weak draw or underpair and don't know what went wrong. The better players quickly adjust and after a relatively small crossover period will happily destroy most live games as they generally have a far better understanding of the theory behind the game. And no, wearing your sunglasses and hoodie looking for the twitch in the corner of your opponents eye does not give you a massive advantage, if you think it does, then that may explain why you struggle online.
Live players moving to online on the other hand get crushed when they call 3-bets out of position with their any 2 suited cards and attribute it to online being rigged rather than piss poor pre-flop strategy. In general (this is generalising but does apply in the majority of cases) they have no grasp of positional play, have no clue why playing out of position is bad and will call down the whole way with a weak draw and don't get paid off when they do hit. Then they wonder what went wrong as this play works fine in live games where most flops see 5 to 7 to a flop rather than most being heads up or 3-way. In a large multi-way pot pre-flop mistakes are negligible. In a short handed game where heads up post flop play is the norm rather than exception pre-flop mistakes add up very quickly and if they are large enough can't be compensated for by post-flop skill.
Poker is poker, whether it be live or online. They play differently however it is still the same game with the same rules and it is just a matter of adjusting. If you can beat one and not the other then the flaw lies in your game rather than in the medium of delivery.
Who needs proof here on
If by any chance the poster does have proof there are many people who would be very interested in seeing it. Trouble is - proof has to be a bit more definitive than "I don't trust their RNG" or "they cheat cause I am the worlds best poker player but can't win online". In re the random number generator - proof or STFU. In re being a good player but can't beat online, the reason for that is because online players tend to be, at least at the small to mid stakes, orders of magnitude better than live players.
If your requirements keep changing, the project manager/program analyst should be fired.
I could not agree more - however there would be a lot of out of work PMs if that really happened. A big part of that is the PM has no authority to say no to the board - if the order comes from above to move go-live forward generally the only authority they have is downwards to re-arrange resources to best make it happen. To be honest however I am yet to come across a single larger scale project where no requirements changed as the project progressed (I have never worked on medical / defence / real-time systems which I am *hoping* do not have the same issues!). After all - was that not why as an industry we moved away from the waterfall and towards a spiral / agile / whatever buzzword type methodology? The whole problem with waterfall was that it fell apart if the requirements changed after they had been signed off and these newer methodologies were brought in to deal with those issues. I personally feel waterfall has a lot to offer and as an industry we need to start moving back in that direction if we want to compare ourselves to the true engineering disciplines. How can we possibly consider ourselves professionals when we are willing to change fundamental design decisions only a short time before go-live and consider that a positive (ie. it is supposed to show how flexible we are)?
Yeah, but you can keep them from doing it again.
The reason people don't use these well-known techniques is very simple: it takes time and effort, and people are lazy. So until the customer tells them to, they won't bother.
Which brings me to my biggest objection to this proposed contract. There's lots of documentation requirements, and no assignment of liability. Documentation is expensive to produce, and much of this I really don't care about. (Exception: the document on how to secure the delivered software, and security implications of config options, is an excellent idea.) For most of the documentation requirements, I don't really need to hear how you plan to do it: I just need to know that, if you screw up, you're going to be (at least partially) financially liable. And yet, the contract fails to specify that. What happens when there *is* a security breach, despite all the documentation saying the software is secure? If the procedures weren't followed, then that's obviously a breach of contract — but what if there was a problem anyway?
I actually like designating a single person in charge of security. Finding someone to blame after the fact is a horrible idea. However, having someone who's job it is to pay attention early, with the authority to do something about it is an excellent way to make sure it doesn't just fall through the cracks. By requiring their personal signoff on deliverables, you give them the power they need to be effective. (Of course, if management inside your vendor is so bad that they get forced into just rubber-stamping everything, that's a different problem. But if you wanted to micromanage every detail of how your vendor does things internally, why are you contracting to a vendor?)
I don't agree there re the lazy comment. The reason poor coders release insecure code is because they are lazy. For the rest of us, it is generally because we are told we MUST release X features by go-live date. Go-live date will not slip under any circumstances. X features are non-negotiable for go-live date. The project manager (not the development PM, the project owner) has assigned a certain period for testing, however this testing is never SIT or the such, it is usually UAT of a very non-technical nature and the devs time is spent on feedback from UAT. Development itself has virtually no proper regression / SIT / design time factored in. The development team are never asked how long realistically something will take, instead some non-technical person will tell them how long they have and then tells them to figure out how to make it happen. Specs will change continuously throughout the project so a design approach at the beginning will be all but useless at the end after numerous fundamental changes (got this one on a project I'm working on now - had my part finished, fully tested and ready to deploy about 3 months ago, then change after change after change and I'm still doing dev and if I mention that I need time to conduct SIT / regression testing I'm told "but I thought you fully tested it already a few months ago?"). This leads a dev with a fast approaching deadline, who doesn't have the authority to say "no, this won't give us enough time to test properly" and the emphasis on being feature complete rather than a few features down but fully tested and secure.
This of course does not even touch on the subject of what happens if a third party library or other software sourced externally has vulnerabilities. Can you in good faith sign off that you guarantee a piece of software is totally secure without knowing how third party libraries, runtime environments or whatever were developed? This is not just isolated to open source, try holding MS liable for a security vulnerability that was uncovered after you deployed and see how far you get. This then starts taking us out of the realm of absolutes and into the realm of "best practices" etc. So how good is a contract that expects the signatory to follow "best practices" in regards to security. Who determines these best practices? So the contract has two possibilities, it is either too strict to make it practically meaningful (people will still sign if that is the only way to get employment but it will not make the software any more secure) or it is to vague to have any meaning.
The bridge analogy works very well as the work software developers do would be unheard of while building a bridge. Imagine a civil engineer having to sign off on a contract that went something like "We reserve the right to change the completion date, including move it forward, any time we see fit. A panel of marketers will determine how long the bridge will take to complete with no consultation of any technical people, any timeline set is non-negotiable. We can add new features that you are currently not aware of at any stage of the build process, right up to a week before completion date. If we so choose we can tell you mid project to change the bridge from an arch to a suspension bridge and the deadline shall not move. Up until completion date the marketing team will hold internal discussions whether or not the bridge needs to open for ships, if they decide it does then you must ensure that this conforms to marketing requirements without missing go-live. And you need to sign off that you will be personally responsible if there are any structural defects."
Same here, and same with everyone I know. Since when is "barbie" not the Aussie slang for bbq?? On that note - if its not "barbie" then what is it?
And loosely coupled code is fundamentally better *why*?
"Because it can be easily unit tested" is the only argument I can swallow
On the past few systems I have worked on I have had the "fun" job of adding new features to existing legacy code. Adding features to the existing tightly coupled code was a nightmare, finding what did exactly what took ages, some functionality was partially performed in several different locations - each relying on the previous part - and the slightest spec change would need the whole thing to be re-done yet again. The exact same spec changes (eg a new element in a message) were trivial to do in the applications I had written from scratch as each change only needed to be done in a single location and was easy to test. I may have seen some extreme cases but I have certainly become a "loosely coupled" evangelist since.
Provide a solid spec and I would be happy to do a fixed cost project - however I will hold you to the spec just as much as you will hold me to the cost. Provide me a vague wishlist and I will not do a job for you fixed cost. Keep in mind any fixed cost quote will come with the risk priced in at some point. Some people are unhappy with that, wanting a fixed cost to be based upon best case estimates - I simply won't do business with them. Just because someone contracts does not mean they will do any job under any conditions presented to them.
I hate this. And when you say you can't estimate something like that, they say: "oh just give us your best guess, we won't hold you to it." Then six months down the line you get called into someone's office and interrogated for an hour because you can't deliver "on time"...and by this time you forgot that they said they wouldn't hold you to the estimate so you end up trying to defend it...trying desperately to think of all the little things that went wrong and blow them up into bigger issues.
One of the first things I learnt - always always ALWAYS ask for any stupid request / comment / statement in an email. "We won't hold you to it" rates very highly on the list of things I want in writing before I will commit to something. If they will not provide you with an email saying as much, make sure that you email them (preferably cc'ing someone) confirming their request and any problems you might see in it so they can't plead ignorance at that future date. That way when you do get called into that meeting you have something to back yourself up with. It has saved me on multiple occassions.
Sounds similar to the method I used to use
I would make an estimate, add a 50% buffer and double it and send it to the sales rep
The sales rep came from a technical background so knew how IT projects went, so he would take my estimate, double it and add a buffer to that.
This method actually produced estimates quite close to what turned into reality.
I think the problem with estimates are that:
a) developers are never as fast as they think they are,
b) the customer always has something hidden in there that actually means something far more complex than what it appears,
c) there are always unforseen things that go wrong eg a bug in some framework you use that you have to then spend time hacking around and
d) the human factor - some people leave the project, some people would be more useful to the project if they had nothing to do with it, etc.
The trouble is one of the biggest impact items - ie. the customers or vendors - will almost never be the same project to project. Other peoples experiences may differ but I always find that the people involved usually are the biggest factor determining if a project meets deadlines or not and you have no idea what they will be like until the project begins. Even the same person may perform differently project to project, on the first they may be a dedicated resource, on the next the project is one of a dozen they are working on simultaneously so can only devote a fraction of the time and effort of the original. I have had projects that in reality should have taken a few hours take a couple of weeks while other highly complex projects lasting several months go off without a hitch and come in early, all due to the different people.
Revising or 'dropping' a promise you made is called reneging on obligations you made.
No, dropping a promise is not reneging on obligations. Sun promised to work on accessibility, however they were in absolutely no way obliged to work on accessibility. There is a big difference between the two.
After reading TFA, as far as my medically ignorant mind makes out, the study was withdrawn due to ethical issues obtaining the samples for the study, not due to issues with the conclusions drawn. I can see how this would lead Wakefield to be deregistered due to ethical considerations however how does this disprove his conclusions? The logic seems to go "your study shows there may be a link between autism and vaccines, you obtained samples unethically, therefore this proves once and for all and hereby ends the discussion that there is conclusively no link between autism and vaccines". I always pay extra close attention when a scientific discussion starts descending into claims of absolutes, a statement like "the possibility is laughably remote that there is a link between x and y" makes sense, "there is no link between x and y and nobody is to suggest there is" smacks of dark ages medicine rather than science.
I would love someone more medically inclined to provide more background as I sense a lot of info was missing from the story / article.
This is a common misconception.
The truth is, every scientist in industry (ie: making products to sell) wants all of the animals in their experiments to come out completely safe and healthy.
Why? Because the company has already spent a LOT of money in development by the time it gets to animal testing. Animal testing is expensive (but required by law) and it only comes after everything else has been tried. At this point, the company believes the product to be safe. It then becomes the toxicologist's job to make sure it's absolutely safe on actual living beings.
There is a difference between your first and second paragraph. Let me expand. Many scientists (I have known a couple involved in animal testing) in the actual testing want as many animals to come out safely as they can. They are human after all and unless they have a mental problem get no joy out of inflicting suffering on other beings. The company however has no such issues. The bean counters at the top both never have contact with the experiments and are only interested in the money and have no human interest in suffering minimisation. If anything they do not want to have personal contact with the experiments because then they can go on TV and say their company inflicts no suffering on animals etc and claim plausible deniability. Anybody representing a testing lab who makes a statement that their test animals go through little to no suffering is either ignorant of what happens or lying.
The truth of the matter is that a lot of these experiments are truly shocking in the pain they inflict. The one I know who worked in a commercial lab ended up leaving the industry and turning vegetarian it had that much of an impact on him. Some pet store owners who couldn't sell their animals would sell them to the lab for testing to make a few $. These animals were subjected to things ranging from having deadly diseases injected into them to having commercial products tested on their skin and eyes. There is no happy ending - if the animal survives they are killed anyway. In some instances an animal with a lot of "character" would come along and one of the scientists would take them home rather than test on them. In many cases the medical experiments are justified and the only way to do something. That doesn't explain why thousands of animals need their eyes burnt out so a slightly differently scented shampoo can go on the shelves.
Just because someone loves working with technology does not mean they are good at it. Just because someone works just to pay their bills (and hopefully a bit extra) doesn't mean they are bad at what they do. This is true in some instances, however I have also come across some people who love technology who I would hate working with and quite a number of others who wouldn't spend any extra time in front of a computer than they had to but who are fantastic at their job.
To do nothing is to be nothing.
