This article you linked is a critique of the Myers Briggs star-sign consistency nonsense and in support of the reliable and scientifically backed Big 5. Maybe you should read articles all the way to end eh?

The argument made here in reference to the paper is that ARC is a useful strategy when considering performance in relation to physical memory size. The throughput/latency trade-off is important for mobile applications, but as you mention, some implementations of a GC can perform well for latency (which is obviously crucial for a mobile app). The enormous performance penalty as the GC heap size approaches the amount of physical memory, however, is a major issue that cannot be easily worked around on a smaller device (That paper is somewhat dated at 2005, so perhaps there is a GC out there who's performance does not degrade as memory consumption approaches the limit, however I doubt it. It's a bloody hard problem). So the choice is an obvious one; slight over-all performance penalty for good latency and memory footprint performance.

and

are not in conflict. Trump uses profanity to appear honest; and as people associate profanity with honesty they attribute "straight-forward" and "honest" to his persona (I'm not American or pro or anti Trump, just an interested outside observer). Bullshit is an art, and he's better at it than most.

A few comments on this post. Total cost for an Indian developer is 1/3 of the equiv, not 1/5. Performing your own hiring will get you competent people, but it doesn't solve the problems. Software developer is not a career in India, it's a stepping stone to something else. You simply cannot build the depth of experience that you need to do anything good, with no one who is any good sticking around for more than 3 years (I mean in the field, not in the one job). This is the key problem with India. You can't hire good people with experience, because they are now managers.

The way you describe what you are doing it sounds like you know what you want at the end of a fairly long time frame, and your doing one set of pretty basic planning and then acting surprised when that plan doesn't give you what you want at the end of the project. This is pretty typical when groups try to transition to an agile development process, and fail as a result. All you've done is throw away your detailed planning and chunked your work up into sprints.

Try Scaled Agile.

It's what we currently use and is the best tool-box that I've yet come across. Things like SCRUM etc don't define process at the business level (intentionally), nor do they describe how you plan out a project that's going to take a year or so to deliver. Scaled Agile does, and it's a very useful toolbox for getting the whole show to be agile (which is the end goal for a business as it allows the entire business/activity to adapt quickly to changing conditions, both internal and external). At the very least, it's useful to read (all online), as it demonstrates all the extra bits that you would need to transition fully.

I'm so glad you're here as an obvious expert on all things software development process to explain Agile in such detail. It's so comforting to have a real professional help all us struggling dolts see why we've been getting it so wrong! I don't give two shits how you like to run your projects, but maybe you should stick to talking about things you know something about eh?

Garbage, you simply show your ignorance. You know what? Agile is a meaningless term, you have some kind of image in your head of what it is (maybe informed by some group of idiots claiming to do it), and hence you can build this lovely strawman to set fire to. Here is the agile manifesto:

- Individuals and interactions over processes and tools

- Working software over comprehensive documentation

- Customer collaboration over contract negotiation

- Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

No mention of not bothering with requirements, only that the emphasis when creating your processes is on the ability to respond to change. On any project that lasts more than a few months, that just sounds like damned smart idea. "No no! We must continue to follow this plan from a year ago, even though it no longer makes any sense in the current market!" Been there, done that, have the t-shirt. (You always get a t-shirt, no matter how big a balls-up it was).

Yes I have, SCRUM was the process used, and it all worked vastly better than the three failed projects before it (in our extreme waterfall shop). There is nothing magical about SCRUM, or any other process, it's mostly about letting good people do good work. The thing that SCRUM et al, gives you is a tight feedback loop, and that is a very useful thing if you have it all going nicely. I've worked in all kinds of setups, from super heavy process (which I just can't stand, who wants to sit around for 6 months just writing documentation and attending meetings?), to extreme isolation (here are the requirements, give us the result in 6 months), to agile of all different variations. I like SCRUM the best because I like working with other people, I like that the work is chunked, and I like that it deliberately only describes a tiny tiny part of the process. There are so many ways to do anything wrong, so many things that end up working despite human screw-ups, so little hard science around anything people oriented, and so much implied in vague terms like "agile" that these discussions are meaningless. Give me a couple of Devs of at least medium ability, a tester or two that know the product domain, and someone on the business side that is willing to talk product, and I can deliver you a successful project every damn time. Call it what you like.

Yes, and if you follow this golden path, what does it give you? Nothing more than asynchronous behaviour. And there are much better and more robust mechanisms to achieve this (such as co-routines, or their virtual equivalent such as async await in C#, message passing, etc etc). What it doesn't give you is any kind of scalability across multiple cores, and the level of complexity is all out of proportion to the gains. Multithreading particularly in combination with OO, has largely failed, because the paradigms were simply not good enough.

Exactly. What is more new is updating the PLC remotely, IP based networking to PLCs, more standardisation of PLC operating systems, more network connectivity between SCADA networks and the outside world, and far more activity by state actors in industrial automation. At the end of the day, a PLC is a computer hooked up to a network card, connected to another computer running SCADA most likely on windows. There is a lot of security and obscurity that makes compromising these things hard, but there is an awful lot more that the big vendors could be doing to harden things from a PLC security point of view.

How many PLCs do you think run windows? Let me give you a hint; it's a round number. A very round number.

The major source for this exploit is going to be remote update of PLC firmware/logic. By remote, I don't mean "internet" but simply physically remote. This does give you something from a plant operation point of view as it is simply one more task that's automated, and potentially a very expensive task due to the dollars per hour for the task in question. So the tech does get you something, at the increased cost of additional "risk". These risks should be mitigable (security into the network, security of the network, security of the device), but it is certainly true that PLC level security is not what it should be. I expect we'll see things rapidly improve on this front as the IOT mass proliferation leads to many more problems, and hence more focus on the inherent weaknesses in this area, and hence forcing the big players to invest the necessary dollars in making their devices securable. SCADA and industrial automation has simply benefited from obscurity for a very long time and thus not had the selection pressure forcing the required evolution.

LENOVO?!?!! I have a brand new work version of one of these junky bits of rubbish that I would throw down the stairs if it weren't for the hassle of having to configure the new one they would give me. Sure it's quiet, but it's only quiet because the fan is underpowered so that the damn thing can't do any serious work without having to de-clock to stupid slow to reduce heat. Everything on this thing is crap, cheap, rubbishy. The battery lasts an hour if I'm lucky when doing anything slightly taxing. The touchpad is a sad joke of misery. The screen is a pathetic thing, miserable to behold. I have a 4 year old retina mac at home, and it does literally everything better. It's not just mine either, there has been no end of moaning since we all switched from HP to the latest and greatest "Lenovo" thinkpads (what a sad mockery of this once great trademark, come back IBM! All is forgiven!)

Who's laughing? This already exists: I would hazard a guess that there are all kinds of patents around this tech. Seeing as the real innovation looks to be in the cool analog silicon interpreting DNA thing, I'd agree that the "driver" part is pretty much irrelevant.

Many years ago, back in the days of very small quota's but the exciting new prospect of mp3's, your author did something very similar via his University and its habit of allowing all requests that contained the university URL as part of the address. This was very nearly the end for our young adventurer, as the university in question had plans for expulsion, civil, and possibly even criminal charges! (There may have been one or two other indiscretions of a network related nature). Fortunately in this story, the Dean of Engineering saved the day with a general "boy's will be boy's" attitude and a stern warning, so the hero was not thrown to the legal wolves. The point of this is to say that you should never ever assume that your "one cool trick" won't land you in serious hot water.