I am a big proponent of agile methods (see the agile thread today), but here I disagree. A UI is part of the system architecture, and architecture fundamentals do need to be defined early in development (but then refined and evolved as development proceeds). Agile is definitely not "making stuff up as you go along".
Or: because anything that enables vote-count corruption favors Republicans.
There is no evidence of significant voter fraud anywhere, that's why voter ID proponents never cite any real cases. The only problems with corruption of the voting system occurs when the votes are counted, or measures to deny people the ability to vote.
But when a 101% of the population (not registered to vote, or of voters) of a black precinct votes in favor of the black guy, that's not racist.
Just makin' stuff up, I see.
... really I have no issue with mandatory voter ID -- you just need to severely over-engineer the solution to ensure it's not a burden on those in society with the least time/money/options/eduction.
And the fact that these voted ID laws never include proactive provisions to get IDs into the hands of all voters for free reveals their true intent quite clearly. Heck, Ohio is trying to enact a poll tax (banned explicitly by the Constitution, 24th Amendment) by requiring a voter ID card that you must pay for.
I actually agree with this. The documentation does need to evolve with the implementation, and if you don't, it is as you say. But having a clear concept about how it is to be used, and working out a coherent description of using it is a very strong design tool to make a usable, understandable system.
Inapplicable (or should be). There is no "standard" here. It is a collection of related, mutually supporting practices and tools. People who try to make it into "name brand" all-or-nothing methodologies can create that impression though.
Iterative, incremental development - the core of agile - has been around at least since Barry Boehm described the "spiral model" of development in 1986, and has been successfully used for nigh upon 30 years since under various monickers (and I'll bet there were practitioners before Boehm's paper).
"Agile" has matured and developed a lot of inter-related supporting practices and tools that have made it increasingly powerful and easy to implement. Continuous integration, test-driven development, use of "stories" as a tool for requirements definition, you cannot tell me these techniques and tools are not successful.
I have personally seen the development practices of a company dramatically transformed for the better by having an agile trainer brought in and training the entire staff, including managers, and instituting formal agile practices. It is great when a junior developer can tell the VP of marketing to take a hike because his request has not been submitted through the grooming and priority assignment process.
This one experience gives me complete confidence that people mocking agile simply do not know what they are talking about.
One problem agile does have is with zealots who don't understand that this is, and has to be, a collection of related practices that must be tailored to the needs of the environment, not a one-size-fits-all, all-or-nothing thing. Another problem is thinking that "form" is what is important, not "what is happening".
For example: holding stand-ups is not agile. It is a common, useful tool to use in an agile environment. If your team is coordinating with informal sessions as needed, Skype, chat tools, and an updated Wiki in real time, and the managers are keeping in the loop using these tools, then maybe a stand-up is a waste of time for you. I think most teams benefit, but design and planning is not part of a stand-up, other meetings are needed for these.
There can be long-term planning that does not follow the agile model, and can be described as water-fall, and this has its place too. But I think the only really successful development practices are variants of an "agile" type process.
And not because it has to be that way. The software is just poorly designed.
In an ideal world, user documentation would be written before the software so that an understandable, consistent, UI would exist. This sometimes happens, but even then, the implementation may not match the documentation (yes, I have seen this more than once).
Design principles like: simple things (and common tasks, even if not exactly simple) should be simple to do; the same technique should work in all contexts; etc. are often ignored in OS projects.
I have come to despair in trying to find a nice open source (Linux) object-drawing program that is intuitive (and thus easy to learn), has consistent behavior, and allows the quick creation of clean basic diagrams, and maybe has an additional level of finer controls for more precise work. The original Macintosh had this back in the 1980s with MacDraw, and the even more awesome MacDraw II. Complete novices could take the program and discover how to make good looking "boxologies" in minutes just by playing with the tools. Maybe such programs are still available on the Mac platform (I haven't had one in years), but no OS object drawing or 2D CAD program on Linux seems able to grasp what one of the first such pieces of software on the market was able to accomplish.
(Another really annoying thing to find in user documentation is self-praise about the product and accompanying documentation: making promises about how great the product is, and how wonderful the documentation you are looking at is, that are rarely kept.)
Videos have their place, I grant. Especially when it comes to manipulating some object (could be a graphical object on a screen), where a verbal description just cannot compete.
But I hate "video documentation" with an undying passion. They have an extremely so rate of information transfer, typically very low information density (see how little text is in a 5 minute video script), cannot be scanned at all, require you to have an audible audio hook-up, cannot be copied for notes,... I'm just getting started here, but you get the picture. I can literally take in information 10 times faster in printed form, and locate relevant content even faster than that.
If video documentation is available as optional back-up, great! But if that is the only documentation, I will not use whatever-the-heck-it-is, I'll find something else.
They need to refer the the pieces of hadoop. HDFS is the storage piece and many things can interface to it, it isn't great but is often good enough especially if you just have a couple local disks per node. YARN is the scheduler piece, it is mostly awful performance-wise but is fairly easy to use...long run it'll lose to something like mesos I think.
That's a good call. With Cloudera and HortonWorks both adding new components to the Hadoop stack it has exploded in the number of components in the last a year or two, and that can be a bad thing. The complexity of the whole ecosystem is getting horrendous, with a typical configuration file doubling from 250 or so to 500 configuration items, which are almost all undocumented (unless you read the code - which scarcely qualifies as "documented") in the last year. For a practical deployment you are pretty much forced to use a commercial stack to get something up and running in a manageable fashion. And then there is the fact that the HDFS foundation is showing its age.
MR is the map reduce piece that everyone thinks of when you say hadoop. Almost everything will run quicker in spark(still using a map/reduce methodology) than hadoop MR.
Spark on Mesos is looking mighty awesome.
As a side note, I don't know anyone who still writes MR jobs directly, they are all doing pig or hiveql.
MapReduce is still viable for stable production jobs, but not in a dynamic requirements environment.
Although HiveQL is alive and kicking, the complete replacement of Hive Server with Hive Server 2, while possibly an improvement in usability overall (I am not convinced), it trashes your skill investment in the (now) obsolete Hive stack component. Maybe I am just grousing, but I start having reservations about technology planning in the data center when a key stack component changes so much it a relatively short period of time
Brookings analyses have increasingly been up for sale. Not surprisingly it is taking up this pro-Microsoft, pro-Gates agenda after the Bill's foundation became their biggest contributor.
Durable generational trade agreements like GATT 1947 are formed from open discussions of mutual interest, and finding points where both/all sides can agree, or can at least agree to compromise.
Indeed, we are seeing the U.S. Crony Corporatist Capitalism reaching its highest level of development. Corporations now write out laws in secret - even from our elected representatives (despite the fact that they strictly vote the corporate lobbyist line anyway). And the clear intent here is that this will be presented as a fast track "deal" - no modification permitted, the corporation writ is final.
It should be remembered that "fast track" - secret trade deals with no modification allowed - only came into existence in 1974. It is one of the founding cornerstones of the crony capitalist edifice that has been built since 1970 - when worker wages stopped growing with economic growth as had been the historic norm, and a reasonable expectation by the American people.
A nice example of Poe's Law in action.
This could be a parody of the thinking of the corporatist shills, and apologists for out present plutocracy, except that the actual shills and apologists often say exactly the same thing, deaf to the ludicrousness of the messages they lip-synch with./p
No, no...you misunderstand me. I'm not saying there should be less government control, just that it's done algorithmically.
Think automated DMV processing, automated welfare distribution, automated parolee management, IRS collections/auditing, and so forth.
Of course, the inevitable argument against this is that too much trust is placed into the programmers hands. This is why it would all have to not just be open source, but clearly laid out and audited by many many programmers and non-programmers alike. Further, the algorithms should have built in mechanisms for refinement and improvement.
As a guy who loves designing algorithms, and is very good at it, I must say you put w-a-a-a-y too much faith in algorithms. Even "open source" algorithms. Consider the Federal Government's determinant sentencing rules (with the Orwellian misname of "guidelines"). They are viewed with almost uniform horror by the judges that must use them to calculate sentences, even by Conservative judges who would be most expected to approve of the often Draconian result. There is nothing secret about these sentencing algorithms. Prosecutors are able to trigger whatever "enhancements" they wish by placing claims in the indictment regardless of merit.
Those who can, do; those who can't, write. Those who can't write work for the Bell Labs Record.
