Comment Re:...opaque language is the norm. (Score 1) 374
9 employers in 12 years is excessive for a programmer? I guess you don't know many contractors then. Regular 3 to 12 month gigs are the norm and nobody bats an eyelid at it.
9 employers in 12 years is excessive for a programmer? I guess you don't know many contractors then. Regular 3 to 12 month gigs are the norm and nobody bats an eyelid at it.
Not in the browser market, no. They have enough market share that they're able to influence the market and keep the innovations and advancements flowing, and that's all that matters to them.
So their main goal is not to make money but to produce innovations and advancements? I'm sure their shareholders would be interested in that one.
Oh come now, we all know you just enjoy the ability to play with no clothes on! Must admit I have done that more than once.
A big problem online poker players face is the nonsense that the GP was sprouting. The trouble is that they know nothing about the topic at hand yet feel they are qualified to talk about it (well, I guess the same goes for any topic really). You summed it up nicely - in a game of poker it is player v player, the house does not care one bit who wins and loses as they get a "rake" out of every pot. Their sole interest - the one that makes them the most money - is to make as many people play as possible. The better players tend to play more tables therefore provide more income to the sites, which is why sites reward high volume players regardless of whether they are winners or losers (and there are quite a number of high volume winners). The site gets paid regardless of who wins and loses a game, there is no way for them to end up behind on a hand played.
If I were playing a cash game I would fist pump if I saw my AK get called by 43. Yes, the flop comes out 443 this time however in the long run (and poker is about the long run, as in tens if not hundreds of thousands of hands if you play seriously online) you will destroy that clown. Yes he wins this game, however over the next 10 times this happens he will lose around 2/3 of the hands, providing a nice profit.
You clearly don't know what you are talking about or you wouldn't make such blatantly false statement.
I'm glad someone beat me to it. That statement was just absurd and shows a total ignorance of the subject being discussed, made worse with the condescending "you are all so sadly mistaken and I am now going to tell you how it is" tone.
The ONLY game where computers are a match with the top human players is heads up limit holdem. There is no other poker game where computers would be favoured against a top pro so the statement "pitted against a computer, their results suddenly fall well within a bell curve of chance" is just false.
When I look in my database there is a very strong trend where winrates reduce as the stakes increase. This would indicate that as opponents get tougher, it is harder to beat the game in the long run. This flies in the face of the notion that poker is only a game of chance which would lead to no correlation between opponent skill level and winrates.
It would have been interesting to a C, C++ and Fortran shootout on some heavy number crunching. Throw in some OpenGL, OpenCL and assembly for good measure. We always get to see how high level languages compare, when in reality for most apps that are written in higher level languages raw speed is one of the lesser factors when choosing a language. Yet we never see shootouts between the lower level languages which would be used if speed truly was a concern.
TFA here though isn't referring to someone "sneaking a few minutes break at work to check a website while they wait for an email", it is talking about a police officer accessing personal and by its nature I would imagine very sensitive information on a police database, not a random website, that they had no legal reason to be accessing. This is a far cry from using company time to surf the web.
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.
Anyone can make an omelet with eggs. The trick is to make one with none.
