With some Facebook bots starting at $30 to $50 to build, of course people are doing that. Facebook has biggerproblems than giving a crap about this company's complaints or requests. If our SEC wasn't a toothless corporate captive, the company would already have been halted for securities abuse.
The gap Perl left Python to successfully fill mainly involves shipping a good enough standard module library. Keeping small scoped library enhancement work moving with the Python Enhancement Process minor version after version is the true reason for the language's success.
CPAN has always been a nightmare of bad version control for non-professional Perl programmers, where it's trivially easy to break things if you try and follow what seems the easiest path for installing things. What Perl should have been doing the last 15 years to reduce that problem, to lower the learning curve, is pruning the need for it. Pull more of the best of them into the library of things guaranteed to ship with the language, the less successful ones should die. Let's consider XML as an example. The Perl-XML FAQ starts with "Where can I find reference documentation for the various XML Modules?"; you already lost a chunk of potential Perl developers right there. A quick count on my Debian laptop shows I have 3 packages for that job that aren't in base Perl: libxml-parser-perl, libxml-twig-perl, and libxml-xpathengine-perl. Why? There seems epic "not invented here" going on whenever I get near CPAN, everybody has their own thing.
Given the same job, Python development shook out one XML implementation to ship as part of its standard library, and for everyone to work on, in version 2.0. Then another one was merged into the standard library for 2.5. The other option on my system is a wrapper around libxml2 and libxslt. That's it. The best of the libraries have made their way into the standard library over time, programs can rely on those, and that's good enough for most jobs. This is why Python has kept advancing year after year, while Perl becomes less relevant. You need to know *less* every year to do things in Python, and that's what people look for--a flattening learning curve.
It didn't help that the transition to Perl 6 has taken 12 years so far, making the core language feel dead too. The similarly disruptive Python 3.0 work took 8 years. I think Python managed the backwards compatibility hurdles better too. That's a very subjective thing though, whereas the scope creep leading to nothing useful shipping for Perl 6 yet is a simple fact.
Turn on a dime? Zynga will be crushed by Facebook if they every become part of a viable threat, by having their games demoted to where they are stripped of operating cash. The change in games ranking was Facebook throwing their weight around just because they could here.
Texas Hold'Em is a game of statistics. In any short-term run, luck might triumph over skill. But if you play long enough, there are a variety of strategies that consistently prove to be better than naive play. The simplest one to model is deciding whether to go all-in pre-flop. That's straightforward enough that papers like Universal statistical properties of poker tournaments have worked on distilling it down to a simple function.
My favorite example of odds-based play involves completing a flush. If the 3-card flop comes out, and you have 4 cards to a flush, the chance you will complete that flush is 35%. Many new players think "I have a 1/4 chance of getting a card of any one suit each time, so the odds I'll finish this flush are 50/50". That's wrong; it doesn't take into account that you already have 4 of the 13 cards in the suit. You have to play a fairly large number of hands to distinguish that the odds are really closer to 1/3 than 1/2 though. That's why someone who is betting based on an incorrect assessment of odds will bleed money over time to someone who bets appropriately, the edge of skills over luck here. It is a long-term edge though, and luck dominates the short-term game.
David Sklansky's writing is a good starting place filled with statistics based poker observations. The Theory of Poker is the standard text on odds-based play. Sklanky's career training was as an actuary, which is one reason his numberic analysis of the game is so strong.
Conversative no-limit is only profitable given the existence of players who lose money against that strategy. I do agree that many on-line players play no-limit in a way that does well again.
The fact that you're profitable is based on the same thing: being more skilled in some way than the other players who you happen to be playing against. After a few thousand hours of play myself, I concluded that by far the most valuable skill for online play is being able to read whether there are players I can make money against at the table. There isn't necessarily even an outcome where some people are winners and some are losers for playing. Given an equal enough match of skills, in the long run a series of poker games leads to money flowing solely toward the house. Everybody else leaves with slightly less money than they started with.
To be pedantic for a minute, regularly enough presenting a false tell is functionally the same as hiding your tells. A tell only works against you if it gives your opponent a consistent edge. Each time you can throw out a fake one, that's diluting how much information you're leaking with the real ones. I don't think there's really a line between "can't tell if it's real" and "hidden" here.
Given that Apple is actively adding Secure Boot Chain to their own devices, I wouldn't place a bet on them as the safe hardware platform here. Normally I buy used Lenovo laptops to put Linux on them. If Microsoft's Secure Boot starts to be more of an issue, I'd probabaly switch to a Linux hardware rebranding company like Emperor Linux to make sure I didn't end up with a problem system.
At the end of the article there's a link to the AURIA EQ276W 27" LED Monitor, which is in stock at my local MicroCenter. It's 27" and 2560 x 1440 like the model reviewed and a bit more expensive, but it also has more inputs (VGA and HDMI).
Look at the coward, pulling out the living with your parents joke. Man, you are a witty character. The "utopia" I live in is one where people are still willing to pay for support and consulting on their open-source databases, because it's still a cost savings over options like Oracle or SQL Server. Maybe they don't have real companies wherever you and the other trolls live at?
I am a software developer, working on an open-source database. That everyone will download the software I work on without paying for it is my business model.
What input differences exist between iOS implementations?
That was my point; there aren't many. I think Apple has even wrapped the difference between the ones that handle multitouch gestures to where apps don't have to care. That's what a good platform should do, where the context for "good" is "makes apps easier to write".
Linux in general isn't doing very well on the "let's have one consistent UI that all applications use" front either. It's a hard problem to solve in an open-source way, where everybody wants their own thing and no one person is the voice for "it's more important to be easy to develop for than for any of you to get your way" in platform context. That's the one thing I'll give Jobs any credit for; the main knew how to shout down dissenters and stay focused on one good way to do things. His definition of good wasn't always sensible (see: one button mouse), but it was more consistent than most.
Most development platforms suffer from some degree of fragmentation. Even Apple's desktop platform, which is happier than most to just leave behind older versions of the software, took a while to shake off cruft leftover from the PowerPC days (which was itself shaking off cruft from the 68K days).
That doesn't mean you can't rate platforms on the degree of fragmention though. And here Android loses, badly, to just about everything else. There are 4 major versions of the Android software still in heavy use, with Jelly Bean adding a fifth one. Each of those major releases has multiple vendor customizations and some disparity in major application design issues like screen sizes and input methods. It's a QA nightmare.
The situation is no better for Windows, but variation in desktop capabilities doesn't seem to hamstring application developers too badly anymore. How long has it been since you found a desktop app that couldn't deal with the screen being resized or with the type of mouse changing? Those things used to be serious fragmentation issues too; nowadays that's faded into something application designers can safely ignore most of the time when developing on Windows. It looks like Windows 8 might alter things badly enough to bring the display issues back into the limelight again, at which point I expect class of "Windows fragmentation" to increase.
The iPhone has kept the variations along these two major axes (screen/inputs) low enough to keep fragmentation from being a drag on the platform. Apple has also done a decent job of keeping the software platform moving forward for older devices. Android has done neither of those things, which is why it deservedly gets beat with the "fragmentation" hammer so often. 80% of the Android market is running 2.2 or 2.3 stil by Google's own figures, so software from 2010. Any iPhone user will tell you the idea of still running the software version from 1.5 years ago would be crazy. Platform statistics easily show how fast iPhone users update; the update times on that platform is weeks for most users, not months or years.
Yes, the fact that iPhone developers have to worry about whether their app is running on an older or a "retina display" iPhone is fragmentation.
Windows developers needing to test applications in Windows XP, Vista, and 7 is fragmentation. Ditto for worrying about 32 vs 64. bit variations.
Thanks for the examples of other fragmentation issues in computing. Wait, were those supposed to disprove this is the right word to use here? That's a pretty terrible fail then. Fragmentation is a word we're using now for when application developers have extensive QA issues around multiple, not quite compatible software platforms on a single hardware platform. It's appropriate here, and for the other examples you give too.
I don't think the report is even addressing whether Agile *can* be used effectively nor not. Its scope seems to be whether it *is* being effective or not for companies, and the answer they present is that it isn't. Whether or not there is a One True Agile that really does work isn't the point; that doesn't matter if people can't figure out how to adopt the approach for their own work (or with consulting help in implementing process, which is also being commented on). You can't prove a software development approach works by presenting examples of it working; the amount of variation among development teams means you could have just been working with a good one. The reason companies try to adopt methologies is to try and get useful work out of *any* development team. A really good software process should work as a filter, only letting things of good quality through as output.
Now, I would turn that conversation not toward Agile--it's no better or worse than the alternatives--and instead ask "is there any process that gets good software even from bad developers?" That's what managers want, and every new softtware development approach that comes along includes some people who claim such magic exists in the process that this will happen. The alternative--accepting there is no silver bullet and focusing on how to get good developers working productively instead--that idea is just fundamentally repugnant to many businesses.
So you think you're the one guy in the world who writes useful, accurate, and complete software specifications without writing the code itself first? It's cool that you're so awesome. I'm actually Batman, I just write comments under this account name. We should hang out.
Like most software methdology, iterative development dates back to the 50's. All of these "new" software approaches are just different mash-ups of existing development techniques; it's inappropriate to credit any of them with real innovation.
Safety improvements like Brake assist and precrash systems are considerably more mature technologies than autonomous driving. It's not very difficult to do better than a human possibly can in most braking situations. Driving on ice is a bit different because an experienced driver might use a controlled dodge rather than braking to avoid objects. That presumes good reflexes, relevant driving skills, and paying attention at the time of accident though. The track record of things like ABS suggests that the slim margin good drivers might have doesn't outweight the statistics, where most people would do better to yield control to a system with far better reaction times. The number of *people* who will do the right thing during a blow-out or patch of ice isn't very high.
Open source offers a variety of options for taking a dump. To satisfy free software purists as well, just make sure you call it GNU/Linux dump. And watch out for the ones made with tar--those can hurt coming out.
I happily work some days on a 2006 ThinkPad T60. The 2GB memory limit is the only part that really limits its ability to function as a basic business laptop. MacBook Pro models from 2006 with 2GB of memory are equally fine for routine work, just can't have too many applications running at once.
Slashdot Mirror
With some Facebook bots starting at $30 to $50 to build, of course people are doing that. Facebook has bigger problems than giving a crap about this company's complaints or requests. If our SEC wasn't a toothless corporate captive, the company would already have been halted for securities abuse.
The gap Perl left Python to successfully fill mainly involves shipping a good enough standard module library. Keeping small scoped library enhancement work moving with the Python Enhancement Process minor version after version is the true reason for the language's success.
CPAN has always been a nightmare of bad version control for non-professional Perl programmers, where it's trivially easy to break things if you try and follow what seems the easiest path for installing things. What Perl should have been doing the last 15 years to reduce that problem, to lower the learning curve, is pruning the need for it. Pull more of the best of them into the library of things guaranteed to ship with the language, the less successful ones should die. Let's consider XML as an example. The Perl-XML FAQ starts with "Where can I find reference documentation for the various XML Modules?"; you already lost a chunk of potential Perl developers right there. A quick count on my Debian laptop shows I have 3 packages for that job that aren't in base Perl: libxml-parser-perl, libxml-twig-perl, and libxml-xpathengine-perl. Why? There seems epic "not invented here" going on whenever I get near CPAN, everybody has their own thing.
Given the same job, Python development shook out one XML implementation to ship as part of its standard library, and for everyone to work on, in version 2.0. Then another one was merged into the standard library for 2.5. The other option on my system is a wrapper around libxml2 and libxslt. That's it. The best of the libraries have made their way into the standard library over time, programs can rely on those, and that's good enough for most jobs. This is why Python has kept advancing year after year, while Perl becomes less relevant. You need to know *less* every year to do things in Python, and that's what people look for--a flattening learning curve.
It didn't help that the transition to Perl 6 has taken 12 years so far, making the core language feel dead too. The similarly disruptive Python 3.0 work took 8 years. I think Python managed the backwards compatibility hurdles better too. That's a very subjective thing though, whereas the scope creep leading to nothing useful shipping for Perl 6 yet is a simple fact.
Yeah, the comment is doubly ridiculous when you note that Morgan Stanley propped up the price to keep the IPO from falling even earlier.
Turn on a dime? Zynga will be crushed by Facebook if they every become part of a viable threat, by having their games demoted to where they are stripped of operating cash. The change in games ranking was Facebook throwing their weight around just because they could here.
Texas Hold'Em is a game of statistics. In any short-term run, luck might triumph over skill. But if you play long enough, there are a variety of strategies that consistently prove to be better than naive play. The simplest one to model is deciding whether to go all-in pre-flop. That's straightforward enough that papers like Universal statistical properties of poker tournaments have worked on distilling it down to a simple function.
My favorite example of odds-based play involves completing a flush. If the 3-card flop comes out, and you have 4 cards to a flush, the chance you will complete that flush is 35%. Many new players think "I have a 1/4 chance of getting a card of any one suit each time, so the odds I'll finish this flush are 50/50". That's wrong; it doesn't take into account that you already have 4 of the 13 cards in the suit. You have to play a fairly large number of hands to distinguish that the odds are really closer to 1/3 than 1/2 though. That's why someone who is betting based on an incorrect assessment of odds will bleed money over time to someone who bets appropriately, the edge of skills over luck here. It is a long-term edge though, and luck dominates the short-term game.
David Sklansky's writing is a good starting place filled with statistics based poker observations. The Theory of Poker is the standard text on odds-based play. Sklanky's career training was as an actuary, which is one reason his numberic analysis of the game is so strong.
Conversative no-limit is only profitable given the existence of players who lose money against that strategy. I do agree that many on-line players play no-limit in a way that does well again.
The fact that you're profitable is based on the same thing: being more skilled in some way than the other players who you happen to be playing against. After a few thousand hours of play myself, I concluded that by far the most valuable skill for online play is being able to read whether there are players I can make money against at the table. There isn't necessarily even an outcome where some people are winners and some are losers for playing. Given an equal enough match of skills, in the long run a series of poker games leads to money flowing solely toward the house. Everybody else leaves with slightly less money than they started with.
We already have Core Wars if that's the sort of game you want to play.
To be pedantic for a minute, regularly enough presenting a false tell is functionally the same as hiding your tells. A tell only works against you if it gives your opponent a consistent edge. Each time you can throw out a fake one, that's diluting how much information you're leaking with the real ones. I don't think there's really a line between "can't tell if it's real" and "hidden" here.
Given that Apple is actively adding Secure Boot Chain to their own devices, I wouldn't place a bet on them as the safe hardware platform here. Normally I buy used Lenovo laptops to put Linux on them. If Microsoft's Secure Boot starts to be more of an issue, I'd probabaly switch to a Linux hardware rebranding company like Emperor Linux to make sure I didn't end up with a problem system.
At the end of the article there's a link to the AURIA EQ276W 27" LED Monitor, which is in stock at my local MicroCenter. It's 27" and 2560 x 1440 like the model reviewed and a bit more expensive, but it also has more inputs (VGA and HDMI).
Look at the coward, pulling out the living with your parents joke. Man, you are a witty character. The "utopia" I live in is one where people are still willing to pay for support and consulting on their open-source databases, because it's still a cost savings over options like Oracle or SQL Server. Maybe they don't have real companies wherever you and the other trolls live at?
I am a software developer, working on an open-source database. That everyone will download the software I work on without paying for it is my business model.
What input differences exist between iOS implementations?
That was my point; there aren't many. I think Apple has even wrapped the difference between the ones that handle multitouch gestures to where apps don't have to care. That's what a good platform should do, where the context for "good" is "makes apps easier to write".
Linux in general isn't doing very well on the "let's have one consistent UI that all applications use" front either. It's a hard problem to solve in an open-source way, where everybody wants their own thing and no one person is the voice for "it's more important to be easy to develop for than for any of you to get your way" in platform context. That's the one thing I'll give Jobs any credit for; the main knew how to shout down dissenters and stay focused on one good way to do things. His definition of good wasn't always sensible (see: one button mouse), but it was more consistent than most.
Most development platforms suffer from some degree of fragmentation. Even Apple's desktop platform, which is happier than most to just leave behind older versions of the software, took a while to shake off cruft leftover from the PowerPC days (which was itself shaking off cruft from the 68K days).
That doesn't mean you can't rate platforms on the degree of fragmention though. And here Android loses, badly, to just about everything else. There are 4 major versions of the Android software still in heavy use, with Jelly Bean adding a fifth one. Each of those major releases has multiple vendor customizations and some disparity in major application design issues like screen sizes and input methods. It's a QA nightmare.
The situation is no better for Windows, but variation in desktop capabilities doesn't seem to hamstring application developers too badly anymore. How long has it been since you found a desktop app that couldn't deal with the screen being resized or with the type of mouse changing? Those things used to be serious fragmentation issues too; nowadays that's faded into something application designers can safely ignore most of the time when developing on Windows. It looks like Windows 8 might alter things badly enough to bring the display issues back into the limelight again, at which point I expect class of "Windows fragmentation" to increase.
The iPhone has kept the variations along these two major axes (screen/inputs) low enough to keep fragmentation from being a drag on the platform. Apple has also done a decent job of keeping the software platform moving forward for older devices. Android has done neither of those things, which is why it deservedly gets beat with the "fragmentation" hammer so often. 80% of the Android market is running 2.2 or 2.3 stil by Google's own figures, so software from 2010. Any iPhone user will tell you the idea of still running the software version from 1.5 years ago would be crazy. Platform statistics easily show how fast iPhone users update; the update times on that platform is weeks for most users, not months or years.
Yes, the fact that iPhone developers have to worry about whether their app is running on an older or a "retina display" iPhone is fragmentation.
Windows developers needing to test applications in Windows XP, Vista, and 7 is fragmentation. Ditto for worrying about 32 vs 64. bit variations.
Thanks for the examples of other fragmentation issues in computing. Wait, were those supposed to disprove this is the right word to use here? That's a pretty terrible fail then. Fragmentation is a word we're using now for when application developers have extensive QA issues around multiple, not quite compatible software platforms on a single hardware platform. It's appropriate here, and for the other examples you give too.
Apparently what they still don't got are good grammar.
Betteridge's Law of Headlines is the rule you're looking for.
This is very close to providing the car anology I was looking for, but it just misses the bus on that.
I don't think the report is even addressing whether Agile *can* be used effectively nor not. Its scope seems to be whether it *is* being effective or not for companies, and the answer they present is that it isn't. Whether or not there is a One True Agile that really does work isn't the point; that doesn't matter if people can't figure out how to adopt the approach for their own work (or with consulting help in implementing process, which is also being commented on). You can't prove a software development approach works by presenting examples of it working; the amount of variation among development teams means you could have just been working with a good one. The reason companies try to adopt methologies is to try and get useful work out of *any* development team. A really good software process should work as a filter, only letting things of good quality through as output.
Now, I would turn that conversation not toward Agile--it's no better or worse than the alternatives--and instead ask "is there any process that gets good software even from bad developers?" That's what managers want, and every new softtware development approach that comes along includes some people who claim such magic exists in the process that this will happen. The alternative--accepting there is no silver bullet and focusing on how to get good developers working productively instead--that idea is just fundamentally repugnant to many businesses.
So you think you're the one guy in the world who writes useful, accurate, and complete software specifications without writing the code itself first? It's cool that you're so awesome. I'm actually Batman, I just write comments under this account name. We should hang out.
I don't know why this is modded Funny when it's the most Insightful description of the report yet.
Like most software methdology, iterative development dates back to the 50's. All of these "new" software approaches are just different mash-ups of existing development techniques; it's inappropriate to credit any of them with real innovation.
Safety improvements like Brake assist and precrash systems are considerably more mature technologies than autonomous driving. It's not very difficult to do better than a human possibly can in most braking situations. Driving on ice is a bit different because an experienced driver might use a controlled dodge rather than braking to avoid objects. That presumes good reflexes, relevant driving skills, and paying attention at the time of accident though. The track record of things like ABS suggests that the slim margin good drivers might have doesn't outweight the statistics, where most people would do better to yield control to a system with far better reaction times. The number of *people* who will do the right thing during a blow-out or patch of ice isn't very high.
Open source offers a variety of options for taking a dump. To satisfy free software purists as well, just make sure you call it GNU/Linux dump. And watch out for the ones made with tar--those can hurt coming out.
I happily work some days on a 2006 ThinkPad T60. The 2GB memory limit is the only part that really limits its ability to function as a basic business laptop. MacBook Pro models from 2006 with 2GB of memory are equally fine for routine work, just can't have too many applications running at once.