That's how most malware is spread. But WannaCry, according to reports, was a fully automated exploit that did NOT need users to open an attachment or click on a link.
If a Windows computer running SMB was exposed to the internet, it could be infected and from there infect machines connected on the internal network.
The lack of human interaction needed was how it spread so quickly.
They certainly didn't waste any money on design, did they? It kind of looks like a plastic "Future Phone" you could have bought at RadioShack back in the day...
Of course they're seeing "nuances". The whole thing was a carefully crafted wedge issue upon which the Republicans could scream and shout. And ridiculously, they were screaming about a health care bill based almost entirely on a Republican health care bill -- RomneyCare.
But the ACA is government intrusion! (Actually, it is, in a good way.) It's dying! (CBO says it's stable, though it is having issues in some Republican-based states who fought it in the first place.) It's raised my rates! (It's true that rates have increased, though not as much as rates would have increased without it. And part of that is through elimination of "insurance" plans that some people paid for that covered basically nothing at all.)
Regardless, now that the Republicans COULD pass the same bill, they're stalling why they try to figure out the actual political impact of kicking millions of registered voters off the ACA and off of Medicaid, not to mention dramatically raising insurance rates for millions of others.
So much for "more people will have more access to more affordable health care."
As I mentioned above, If your employee is going to be developing apps that move information from an endpoint to a screen on the app, letting the user fill it out, and then submitting validated data, then give them that sort of problem. Give them an API endpoint, a spec, some credentials, and tell 'em to come back in tomorrow with a demo app that works. Then code review the projects.
Extra points for proper validation techniques, clean code, use of a git repo, proper error checking, and so on. Bonus points for a clean UI design, use of modern techniques like RFP or MVVM, assistive, localized interface design, and so on.
Then if they pass the code review, hire them on a 3-month probationary basis to see if they meld well with your culture and teams.
Essentially, you weed out the qualified applicants by giving them math problems involving Fibonacci sequences and quadratic equations.
You know, the kind of stuff that I as an iOS developer doing banking apps talking to OAuth2 services and JSON backends databases do daily.
I "might" do this sort of thing if I was hiring and had someone in front of me with no sample code, OSS contributions, side-projects, or apps to their credit... but using it to weed out initial candidates... even those with the above credentials... is just stupid.
And it's ESPECIALLY stupid if those problems are not indicative of the problems they're going to be solving if they're hired.
If, say, your employee is going to be developing apps that move information from an endpoint to a screen on the app, letting the user fill it out, and then submitting validated data, then why by god don't you give them that sort of problem? Give them an API endpoint, a spec, some credentials, and tell 'em to come back in tomorrow with a demo app that works. Then code review the projects.
Extra points for proper validation techniques, clean code, use of a git repo, proper error checking, and so on. Bonus points for a clean UI design, use of modern techniques like RFP or MVVM, assistive, localized interface design, and so on.
You might find more of the "qualified" candidates that can do the work you need as opposed to just those skilled at answering puzzle questions on the fly.
I take exception to the expectation that they're supposed to complete a company assignment on their own time. Where I work now they tend to run a "book club" where once a week the current group gets together and discusses the latest chapter or so, asks or answers question, and a moderator/mentor is often present to explain why we do what was discussed.
(Or why, after consideration, we decided NOT to do that...)
If you're looking at someone else's code (or even your own, a year later), would you rather see...
for (i = 0; i 3; i++)// Loop three times {
some_fn(i); }
Or...
for t in 0.. MAX_TASKS {
scheduler.grantTimesliceToTask(t); }
Not only was the first comment worthless, the second version is entirely readable and understandable without it. Refactored and with a good comment, the code might be...// BUG-484 Background tasks stalled while waiting for network requests, so... scheduler.serviceBackgroundTasks()
Again, and as mentioned, the what is now obvious, but the comment explains WHY you're doing this rather odd thing at this point in time.
"Breaking code into small units results in excessive call / return pairs and consequent poor performance..."
Or not, depending on your environment. Breaking OOP code into small parts, for example, can make an object easier to subclass. And in some modern languages, like Swift, smaller functions may in fact be inlined into other functions and loops by the compiler/optimizer.
Creating massive functions simply because you assume that such code is more performant is a classic case of pre-optimization and, 99 times out of 100, doesn't matter anyway. Whereas code readability and maintainability matters a great deal.
"Rightful liberty is unobstructed action according to our will within limits drawn around us by the equal rights of others." - Thomas Jefferson
As Jefferson indicates, freedom and rights are always in tension, your rights verses those of others. You live in a society, among others, and as such you have no "right" or "freedom" to do whatever you wish, without regard to the harm to your actions might inflict on others. Hence rules and laws, and thus those that enforce them.
Further, you and I both benefit from a stable, peaceful society that provides public goods and services like roads, clean water, sewage and waste treatment, and so on.
You argue against "collectivist" societies and systems, without providing a good alternative to the benefits they provide. Perhaps you're of a pure libertarian or capitalist bent, but somehow choose to ignore the unchecked power and corruption such systems have historically given to business and corporations, who in turn care nothing for an individual's "rights".
In the Android camp, phones like Lenovo's Moto Z and Moto Z Force and China's LeEco have already scrapped the 3.5mm headphone jack; to listen to music on the company's three latest phones, users need to plug in USB Type-C headphones, go wireless, or use a dongle.
What's with the "incompatible" proprietary chip remark? The W1 helps automatic pairing with iOS and OS X devices, but AirPods are entirely compatible with older iPhones, iPads, Macs, and even Android phones. They work better with Apple devices, but Bluetooth is Bluetooth.
I have some and I'll give them 4 stars. Bumping the battery life would take it up to 4.5, and using the built-in microphone to check ambient sound levels and automatically raising or lowering the volume to match would take it up to 5.
Our shop has done several major projects in Swift, and (despite the pain thus far in migrating from, say, 2.2 to 3,0) will continue to recommend to our clients that all new development be done in Swift.
One of the major talking points that seems to be holding up is that Swift code seems to have about half to a third the bugs found in a typical Obj-C program.
The one thing I miss from Obj-C is a good built-in implementation of KVO for Swift object and structs.
In Swift arrays, dictionaries and strings are structures with value-semantics. As to why, well, to quote the Swift language reference manual: "One of the primary reasons to choose value types over reference types is the ability to more easily reason about your code. If you always get a unique, copied instance, you can trust that no other part of your app is changing the data under the covers. "
Behind the scenes, however, structures (including strings) are passed by pointer. Swift then uses copy on write so that the objects are completely copied only if and when the program attempts to change a value in them.
As such, a string parameter to a function has value semantics, but it behaves as if it's an immutable pass-by-reference object from a performance standpoint. Kind of the best of both worlds.
An exception would be a parameter specified as inout. (e.g. func f(s:inout String) )
Swift is an open-source cross-platform language (there's even a Linux server version), but the Cocoa and Cocoa Touch APIs on OS X and iOS are platform specific.
Cite? Smoking seems to go hand in hand with several other health-related problems and I suspect that, as a group, the VAST majority won't live to be 77.
Slashdot Mirror
Tell that to Costco. Living wages and benefits... and still growing.
That's how most malware is spread. But WannaCry, according to reports, was a fully automated exploit that did NOT need users to open an attachment or click on a link.
If a Windows computer running SMB was exposed to the internet, it could be infected and from there infect machines connected on the internal network.
The lack of human interaction needed was how it spread so quickly.
They certainly didn't waste any money on design, did they? It kind of looks like a plastic "Future Phone" you could have bought at RadioShack back in the day...
"No wireless. Less space than a Nomad. Lame."
"There’s no chance that the iPhone is going to get any significant market share. No chance."
Of course they're seeing "nuances". The whole thing was a carefully crafted wedge issue upon which the Republicans could scream and shout. And ridiculously, they were screaming about a health care bill based almost entirely on a Republican health care bill -- RomneyCare.
But the ACA is government intrusion! (Actually, it is, in a good way.) It's dying! (CBO says it's stable, though it is having issues in some Republican-based states who fought it in the first place.) It's raised my rates! (It's true that rates have increased, though not as much as rates would have increased without it. And part of that is through elimination of "insurance" plans that some people paid for that covered basically nothing at all.)
Regardless, now that the Republicans COULD pass the same bill, they're stalling why they try to figure out the actual political impact of kicking millions of registered voters off the ACA and off of Medicaid, not to mention dramatically raising insurance rates for millions of others.
So much for "more people will have more access to more affordable health care."
As I mentioned above, If your employee is going to be developing apps that move information from an endpoint to a screen on the app, letting the user fill it out, and then submitting validated data, then give them that sort of problem. Give them an API endpoint, a spec, some credentials, and tell 'em to come back in tomorrow with a demo app that works. Then code review the projects.
Extra points for proper validation techniques, clean code, use of a git repo, proper error checking, and so on. Bonus points for a clean UI design, use of modern techniques like RFP or MVVM, assistive, localized interface design, and so on.
Then if they pass the code review, hire them on a 3-month probationary basis to see if they meld well with your culture and teams.
Essentially, you weed out the qualified applicants by giving them math problems involving Fibonacci sequences and quadratic equations.
You know, the kind of stuff that I as an iOS developer doing banking apps talking to OAuth2 services and JSON backends databases do daily.
I "might" do this sort of thing if I was hiring and had someone in front of me with no sample code, OSS contributions, side-projects, or apps to their credit... but using it to weed out initial candidates... even those with the above credentials... is just stupid.
And it's ESPECIALLY stupid if those problems are not indicative of the problems they're going to be solving if they're hired.
If, say, your employee is going to be developing apps that move information from an endpoint to a screen on the app, letting the user fill it out, and then submitting validated data, then why by god don't you give them that sort of problem? Give them an API endpoint, a spec, some credentials, and tell 'em to come back in tomorrow with a demo app that works. Then code review the projects.
Extra points for proper validation techniques, clean code, use of a git repo, proper error checking, and so on. Bonus points for a clean UI design, use of modern techniques like RFP or MVVM, assistive, localized interface design, and so on.
You might find more of the "qualified" candidates that can do the work you need as opposed to just those skilled at answering puzzle questions on the fly.
I take exception to the expectation that they're supposed to complete a company assignment on their own time. Where I work now they tend to run a "book club" where once a week the current group gets together and discusses the latest chapter or so, asks or answers question, and a moderator/mentor is often present to explain why we do what was discussed.
(Or why, after consideration, we decided NOT to do that...)
If you give someone Clean Code then at some point it's going to be pretty obvious during code review whether or not they read the book.
If you're looking at someone else's code (or even your own, a year later), would you rather see...
for (i = 0; i 3; i++) // Loop three times
{
some_fn(i);
}
Or...
for t in 0.. MAX_TASKS {
scheduler.grantTimesliceToTask(t);
}
Not only was the first comment worthless, the second version is entirely readable and understandable without it. Refactored and with a good comment, the code might be... // BUG-484 Background tasks stalled while waiting for network requests, so...
scheduler.serviceBackgroundTasks()
Again, and as mentioned, the what is now obvious, but the comment explains WHY you're doing this rather odd thing at this point in time.
"Breaking code into small units results in excessive call / return pairs and consequent poor performance..."
Or not, depending on your environment. Breaking OOP code into small parts, for example, can make an object easier to subclass. And in some modern languages, like Swift, smaller functions may in fact be inlined into other functions and loops by the compiler/optimizer.
Creating massive functions simply because you assume that such code is more performant is a classic case of pre-optimization and, 99 times out of 100, doesn't matter anyway. Whereas code readability and maintainability matters a great deal.
"Rightful liberty is unobstructed action according to our will within limits drawn around us by the equal rights of others." - Thomas Jefferson
As Jefferson indicates, freedom and rights are always in tension, your rights verses those of others. You live in a society, among others, and as such you have no "right" or "freedom" to do whatever you wish, without regard to the harm to your actions might inflict on others. Hence rules and laws, and thus those that enforce them.
Further, you and I both benefit from a stable, peaceful society that provides public goods and services like roads, clean water, sewage and waste treatment, and so on.
You argue against "collectivist" societies and systems, without providing a good alternative to the benefits they provide. Perhaps you're of a pure libertarian or capitalist bent, but somehow choose to ignore the unchecked power and corruption such systems have historically given to business and corporations, who in turn care nothing for an individual's "rights".
The price increase in the UK is due to the exchange rate.
Also, rumor mill says the Samsung Galaxy S8 will also be USB-C only.
I have the AirPods and while they're not perfect, I find that they're much better than the standard EarPods.
And nothing is more vexing than having to sit there and untangle a set of wired earphones each and every time I want to use them...
In the Android camp, phones like Lenovo's Moto Z and Moto Z Force and China's LeEco have already scrapped the 3.5mm headphone jack; to listen to music on the company's three latest phones, users need to plug in USB Type-C headphones, go wireless, or use a dongle.
The writing is on the wall.
What's with the "incompatible" proprietary chip remark? The W1 helps automatic pairing with iOS and OS X devices, but AirPods are entirely compatible with older iPhones, iPads, Macs, and even Android phones. They work better with Apple devices, but Bluetooth is Bluetooth.
I have some and I'll give them 4 stars. Bumping the battery life would take it up to 4.5, and using the built-in microphone to check ambient sound levels and automatically raising or lowering the volume to match would take it up to 5.
RMS didn't "allow" software to run on Windows, someone ported it to Windows. (Kind of a big difference.)
You (or someone else) are free to pull the source and do a Windows port.
Like these guys did....
http://www.infoworld.com/artic...
Our shop has done several major projects in Swift, and (despite the pain thus far in migrating from, say, 2.2 to 3,0) will continue to recommend to our clients that all new development be done in Swift.
One of the major talking points that seems to be holding up is that Swift code seems to have about half to a third the bugs found in a typical Obj-C program.
The one thing I miss from Obj-C is a good built-in implementation of KVO for Swift object and structs.
As in Grand Central Dispatch?
There are, in fact, several GitHub projects where people are experimenting with Qt and GTK.
In Swift arrays, dictionaries and strings are structures with value-semantics. As to why, well, to quote the Swift language reference manual: "One of the primary reasons to choose value types over reference types is the ability to more easily reason about your code. If you always get a unique, copied instance, you can trust that no other part of your app is changing the data under the covers. "
Behind the scenes, however, structures (including strings) are passed by pointer. Swift then uses copy on write so that the objects are completely copied only if and when the program attempts to change a value in them.
As such, a string parameter to a function has value semantics, but it behaves as if it's an immutable pass-by-reference object from a performance standpoint. Kind of the best of both worlds.
An exception would be a parameter specified as inout. (e.g. func f(s:inout String) )
Swift is an open-source cross-platform language (there's even a Linux server version), but the Cocoa and Cocoa Touch APIs on OS X and iOS are platform specific.
Cite? Smoking seems to go hand in hand with several other health-related problems and I suspect that, as a group, the VAST majority won't live to be 77.