I hope you are joking. NoSQL has even less functionality than SQL. The vendor wouldn't allow us to define views, I would note. Views could have simplified some of it. It was just a dysfunctional organization that threw labor at problems instead planning, and that section didn't have any IT experts. I probably had more IT experience and education than anyone there, which is not bragging, only a testament to the backwardness of that group.
The stolen file reads: "Trump is an arrogant classless bigoted blowhard who often changes his position and rarely offers specifics. Thus, he's a lot like Putin."
Peoples were literally being marked for death through her insecure email server.
One of the biggest facts that right-wingers AVOID is that the State Department server was NO MORE SECURE than a commercial/private server, and in fact the State Dept. server was (eventually) hacked.
One could argue that such messages should have been sent over the separate secure system (not email), but that's a DIFFERENT ISSUE than whether the "regular" office email system was more secure or not than her personal server.
Even though law enforcement had insufficient evidence to hold him, he was almost certainly suspicious enough to have his Internet/phone usage and weapons purchases spied on.
Like other slashdotters here, I too suspect this story is largely BS.
But I have been in a position that could have been about 70% automated. I decided to get out because either I'd be stuck doing it the boring repetitious way, or automate myself out of a job.
The reason it wasn't automated is because the senior "IT guy", I'll call Bob, only knew SQL and only allowed me to do most things in SQL. Lobbying for better tools backfired on me because middle management knew this guy well and trusted his judgment and didn't understand IT. My explanations flew way over their heads. Our immediate boss didn't even know what "business logic" was.
Bob could bend SQL to do almost anything. But the code was very verbose, repetitious, and ugly. His body had to be constantly moving: a Don Knotts kind of nervousness, and mass typing suited him fine (future Carpal Tunnel for sure). He WANTED verbose code.
I began planning ways to simplify my job by a combination of SQL generator scripts, MS-Access for intermediate processing, and building end-user "wizard" and QBE web interfaces to get the queries, reports, and data they wanted by themselves, even though I knew they'd be a hard sell.
Fortunately the economy improved and I found a new gig.
I could perhaps have earned a decent living using my secret SQL generators and be living easy; but I knew I'd get bored. Plus, this SQL guy was kind of a jerk.
Strong-typed language tend to take longer to develop in for smaller projects, in my experience, in part because they are more verbose, taking longer to type AND to read. There's more "eye clutter" to slow one down, at least to my eyes. (People vary that way, some can read verbose code fast.)
The compile step can also slow one down with compile-oriented languages. Dynamic languages can run a single (changed) script (module) without having to re-compile the entire application. This is especially useful if dealing with a screwy API that you have to use trial-and-error to figure out.
If the project is not "mission critical", then it's often just quicker and easier to use a dynamic language. And maintenance can be smooth if written well. I will agree that bad coders can probably mess up dynamic coding more than compiled projects.
It's more a matter of trade-offs. The hard part is knowing which set of trade-offs is the best fit for your organization or team. Drupal and Joomla target larger organizations and thus may be overkill for smaller shops.
Certain projects are better done with dynamic (loose-typed) languages in my opinion. It depends on the project. It's a matter of using the right tool for the job.
I think I spotted the mistake in his reasoning: he wants to optimize tools for newbies instead for seasoned professionals.
The thing is, the best tool for learning quick and the best tool for general productivity may not be the same thing. A quicker ramp-up time does not necessarily mean a taller peak (when the worker is experienced).
It's economically logical to design the tools for the longest portion of a practitioner's career rather than for the shorter portion when they are starting out. You'll get more total productivity into the economy that way.
As an analogy, a 3-wheeled bicycle is far easier to learn to ride. However, it's not as efficient and nimble as a 2-wheeler. That's why kids are put through the rough and tumble of learning to ride a 2-wheeler: sacrifice now for benefits later. (Fortunately training wheels allow the bicycle to be kind of a hybrid for a while.)
As an educator, he seems to be over-focusing on the starting portion.
Neither I or my colleagues are in any way anti-social or socially awkward.
In my experience the best IT people (in terms of efficiency and problem solving) are usually not the best "people" people and vice versa. I believe it's very difficult to master BOTH technical skills and people skills.
Brains have limited processing power just like any computer, and if a brain does a lot of X, then it cannot spend resources on Y.
Nerds tend to naturally and habitually think about tech (logic, machines, protocols, etc.) while social people think a lot about people and (local) social issues.
Now, there are the relatively rare people who master both, but they may just have really lucky genetics. We cannot assume that some kind of special education could make the nerds be social experts and vice versa. I've never seen it happen.
Sometimes I ask my wife how she makes social decisions when she outsmarts me in that. The explanations are often long and involved: it's clear her brain spends a lot of "CPU cycles" doing social observing and social computations to arrive at her decisions. It's not free.
Slashdot Mirror
No, that was a pretzel, and the pretzel won.
That's the most corporate-speak way to say "blew up" I've ever seen. Their marketers deserve a PHB award.
...making a delivery.
Didn't W do that, and get hypnotized?
We don't really know what Trump's foreign policy is: he keeps changing his plans. He's the wildest of wild-cards.
I hope you are joking. NoSQL has even less functionality than SQL. The vendor wouldn't allow us to define views, I would note. Views could have simplified some of it. It was just a dysfunctional organization that threw labor at problems instead planning, and that section didn't have any IT experts. I probably had more IT experience and education than anyone there, which is not bragging, only a testament to the backwardness of that group.
Firing wouldn't change anything. The dude needed to be monitored.
The stolen file reads: "Trump is an arrogant classless bigoted blowhard who often changes his position and rarely offers specifics. Thus, he's a lot like Putin."
One of the biggest facts that right-wingers AVOID is that the State Department server was NO MORE SECURE than a commercial/private server, and in fact the State Dept. server was (eventually) hacked.
One could argue that such messages should have been sent over the separate secure system (not email), but that's a DIFFERENT ISSUE than whether the "regular" office email system was more secure or not than her personal server.
They were BOTH Chevy's, not Lexuses.
I'm sure the US (tries to) bust into the Russian political stuff also.
Excellent! If UAE wants to help pay for it and share some credit in exchange, as an American taxpayer I find that a good deal, if it plays out right.
The risk, though, is that political entanglements will get in the way someday, and delay things.
The Soviet Union showed you don't need religion to justify mass evil, merely dogma, ANY dogma.
It's essentially a variation of: "Having X in place is so very very important that we have to kill lots of people to get X."
Even though law enforcement had insufficient evidence to hold him, he was almost certainly suspicious enough to have his Internet/phone usage and weapons purchases spied on.
Like other slashdotters here, I too suspect this story is largely BS.
But I have been in a position that could have been about 70% automated. I decided to get out because either I'd be stuck doing it the boring repetitious way, or automate myself out of a job.
The reason it wasn't automated is because the senior "IT guy", I'll call Bob, only knew SQL and only allowed me to do most things in SQL. Lobbying for better tools backfired on me because middle management knew this guy well and trusted his judgment and didn't understand IT. My explanations flew way over their heads. Our immediate boss didn't even know what "business logic" was.
Bob could bend SQL to do almost anything. But the code was very verbose, repetitious, and ugly. His body had to be constantly moving: a Don Knotts kind of nervousness, and mass typing suited him fine (future Carpal Tunnel for sure). He WANTED verbose code.
I began planning ways to simplify my job by a combination of SQL generator scripts, MS-Access for intermediate processing, and building end-user "wizard" and QBE web interfaces to get the queries, reports, and data they wanted by themselves, even though I knew they'd be a hard sell.
Fortunately the economy improved and I found a new gig.
I could perhaps have earned a decent living using my secret SQL generators and be living easy; but I knew I'd get bored. Plus, this SQL guy was kind of a jerk.
Strong-typed language tend to take longer to develop in for smaller projects, in my experience, in part because they are more verbose, taking longer to type AND to read. There's more "eye clutter" to slow one down, at least to my eyes. (People vary that way, some can read verbose code fast.)
The compile step can also slow one down with compile-oriented languages. Dynamic languages can run a single (changed) script (module) without having to re-compile the entire application. This is especially useful if dealing with a screwy API that you have to use trial-and-error to figure out.
If the project is not "mission critical", then it's often just quicker and easier to use a dynamic language. And maintenance can be smooth if written well. I will agree that bad coders can probably mess up dynamic coding more than compiled projects.
There's a catchy song in there somewhere
"Oh Susanna, dontcha cry for me, for I come to Allahbama with explosives strapped to me..."
Kind of ironic they're being attacked by 72 virgins.
It's more a matter of trade-offs. The hard part is knowing which set of trade-offs is the best fit for your organization or team. Drupal and Joomla target larger organizations and thus may be overkill for smaller shops.
Don't give Cheney any new ideas.
I try to take a schmoozer along, and I play the quiet note-taker.
Certain projects are better done with dynamic (loose-typed) languages in my opinion. It depends on the project. It's a matter of using the right tool for the job.
Correction: "3-wheeled bicycle" should be "tricycle".
I think I spotted the mistake in his reasoning: he wants to optimize tools for newbies instead for seasoned professionals.
The thing is, the best tool for learning quick and the best tool for general productivity may not be the same thing. A quicker ramp-up time does not necessarily mean a taller peak (when the worker is experienced).
It's economically logical to design the tools for the longest portion of a practitioner's career rather than for the shorter portion when they are starting out. You'll get more total productivity into the economy that way.
As an analogy, a 3-wheeled bicycle is far easier to learn to ride. However, it's not as efficient and nimble as a 2-wheeler. That's why kids are put through the rough and tumble of learning to ride a 2-wheeler: sacrifice now for benefits later. (Fortunately training wheels allow the bicycle to be kind of a hybrid for a while.)
As an educator, he seems to be over-focusing on the starting portion.
In my experience the best IT people (in terms of efficiency and problem solving) are usually not the best "people" people and vice versa. I believe it's very difficult to master BOTH technical skills and people skills.
Brains have limited processing power just like any computer, and if a brain does a lot of X, then it cannot spend resources on Y.
Nerds tend to naturally and habitually think about tech (logic, machines, protocols, etc.) while social people think a lot about people and (local) social issues.
Now, there are the relatively rare people who master both, but they may just have really lucky genetics. We cannot assume that some kind of special education could make the nerds be social experts and vice versa. I've never seen it happen.
Sometimes I ask my wife how she makes social decisions when she outsmarts me in that. The explanations are often long and involved: it's clear her brain spends a lot of "CPU cycles" doing social observing and social computations to arrive at her decisions. It's not free.
Just tell him to use his head to pound nails instead. I doubt he'll even feel it.