My interpretation was that you are saying PHP is "good" because it made you money, NOT because it's a good language/tool. Thus, I used fires and fire-fighting as a sarcastic and exaggerated analogy.
Microsoft's crappiness is certainly a "jobs program" for techies, but that's not the same as being a good product set.
I don't claim it can't happen, only that it's hit and miss and nobody can come up with clear guidelines to make it more likely to succeed beyond "keep trying, after N projects it will finally click." But that means N - 1 projects are crappy; a lot of collateral damage that makes our Middle East policy look sane in comparison.
and aren't afraid to refactor if we need to.
ANY paradigm/technique can be "refactored" to improve it or make it fit better when it doesn't work very well.
"Oracle" another government created monstrosity out to screw the people no matter what!
Government-created? No. Private org.
If you mean many of their customers are gov't entities, you are correct.
Oracle's RDBMS was actually revolutionary when it came out. Before that you had difficult-to-use DB's such as IMS and CODASYL's pasta-like children.
SQL is not perfect, but it was a big step up. SQL was invented/defined by IBM, but they dragged their feet on in it, fearing it would hurt their IMS cash cow. Oracle released the first commercial RDBMS, and it was a hit because the alternatives sucked.
You have to give them credit for that, even though they are slimy with regard to lawyers and sales gimmicks.
Google should purchase the PostgreSql organization, improve the database's compatibility with Oracle, improve the documentation, and stick links to it everywhere. If anybody googles with "Oracle" in the search phrase, include a link to PostgreSql in their ads.
Cite the specific criminal law, per exact text, that she allegedly violated.
Likely nobody is concerned about Collin Powell because he isn't flaunting his actions by running for President.
Prosecutors only go after presidential candidates? You are making some ridiculous claims. They just busted a Navy tech for publishing secrets. He wasn't running for prez.
PHP is full of warts but I love it. It's made me a boatload of money over the years and I've never regretted learning and using it. It makes my house payment (and more) every month. Hard for me to complain about that.
Fire Fighter: "Fires create a lot of havoc for some people, but I love them. Fires have made me boatloads of money and paid for my house. Burn on!"
I did mention UI's when I said: "The input screens and/or update ordering may not match the table divisions"
But that's not something users (data entry operators) are concerned with. My suggestions are not about how to design front ends.
I'll give a more explicit example. Suppose a given draft table has columns A, B, C, D, E, and F.
There are currently 3 draft CRUD screens in the design, Screen 1 that updates columns A and B, Screen 2 that updates columns C and D, and Screen 3 that updates columns E and F.
A new architect comes along and decides to add "higher normalization" by splitting the table into 3 tables that match the screens: table T1 has columns A and B, table T2 columns C and D, and table T3 with columns E and F.
It's perhaps okay for now, but later the screens are changed into two screens where the first one modifies columns A, B, and D, while screen 2 modifies C, E, and F.
Not only do the new screens no longer match the existing (split) tables, but now each screen has to access two tables where before it only had to access one. The split has served no useful purpose and makes the app more complicated and slower.
Perhaps there is or was some "conceptual" value in the split, but it's either no longer relevant, or of small value.
One could make 3 views instead if there is some conceptual value in splitting and leave the original "wide" table in place.
And I don't see what your "IP" example saves. You still have to modify the middle layer. Unless there is a high "share count" to modified parts, it's a waste of layers. Use subroutines or views for JUST the highly shared parts rather than put a middle layer for everything for speculative future sharing. Factor out actual duplication only.
I don't understand. I'm talking about application developers and DBA interaction. What do data-entry operators have to do with anything? I said nothing about UI's. There appears to a misunderstanding here. And I'm not against views.
[Re: JavaScript sucking] Son, you only say that because you've never poked the Cold Fusion bear. In earlier versions, it didn't even have subroutines.
BOTH are a matter of wrong-tool-for-the-job.
ColdFusion (CF) was originally intended for HTML templating to make it easier for graphics designers and HTML-only coders to code for RDBMS-supplied content without having to bother the app dev for minor changes. It worked so well that CF started to be used for more general or complicated programming, and that's where you found ugly limits*.
Similarly, JavaScript was originally designed as a light-duty glue language to handle browser events not built into the HTML standard(s). It worked well enough that people started using it as a systems language to implement entire GUI engines, and found ugly limits (which I rant about in detail elsewhere on this story).
The same pattern played out in JS and CF:
1. A tool is designed for a niche 2. It's highly successful in its niche 3. Popularity causes uses outside of original goal 4. People complain about the ill fit, summarily blaming the tool 5. Tablizer chews them out for painting with a wide brush
A similar thing happened with VB classic. It was intended for smallish internal applications, but people tried to build enterprise-sized or packaged software with it, and it choked under the weight and got a bad general reputation.
A similar thing also happened with IBM's RPG (Report Program Generator). It was intended to simplify the generation of reports. It was successful enough that others started using it for general application programming, and vendors wrote entire applications in it. Many programmers complained about it and bad-mouthed it in general.
* CF is still well-suited for the original goal. In additional to built-in CF XML tags for populating HTML with data, one can build custom XML tags so that HTML designers/coders can use XML for common tasks for a shop instead of having to learn a "regular" programming language. One can argue they "should" learn regular languages, but if they won't or can't, CF is a nice tool for them. It has full subroutines now, and a feature set comparable to ASP classic. With some exceptions, one can even code in a JavaScript-like variant of it if you don't like XML.
Of course those frameworks have crazy kludge on the inside - that's the point of the abstraction layer.
The complexity, bugs, and instability of the underlying layer is leaking into the abstraction layer. You can only hide so much crap behind an abstraction layer. If the bottom layer were a fixed target, then one could eventually throw enough labor into the abstraction layer to work around all the problems. But it's a moving target.
and yet somehow these are also reasons why you are better off trying to solve the same problems yourself.
I don't understand what you are saying here. I'm not against abstraction layers, only saying they can only fix/hide so much.
In the end, we are responsible for delivering software with high-level functionalities on a fixed timeline and budget
I am not talking about individual projects, but rather that we need industry-wide standards better tuned to our needs. Essentially everyone wants to have/build desktop-like applications that are housed on networks instead of local harddrives/storage.
HTML/DOM/JS was NOT originally built for that at all. They have been stretched like the mother of all taffy try to become desktoppy, but the results so far are really ugly for users, developers, and bandwidth.
I'd like to see universities experiment with multiple draft GUI-over-network standards to try to find/build a standard that actually has the correct goal in mind.
Ideas to try include but are not limited to:
1. Moving the formatting/flow calculations to the server, making the client a dumb (simple) coordinate plotter of vectors and polygons.
2. Add interactive elements to PostScript and/or PDF.
3. Improve on X Window standard to handle input feedback latency better.
4. Create a GUI Markup language with more of the common desktop GUI idioms like drag-and-drop, MDI (sub-windows), data tables, expansion trees, menus, tool-bars, panel tabs, right-click menus, etc. The browser/client shouldn't have to re-load the implementation code for these on every website it visits. That's not rational.
5. Fail-friendly animations. Certain fancy animations could be built into the standard, or perhaps as add-ons, but in such a way that if they are not implemented in a given client/browser, then useful behavior still exists. For example, a button could be defined as throbbing if the mouse hovers over it. But if a client doesn't want to implement throbbing, it can default to a shade change or an outline color change on hover. In other words, throbbing is indicated as the preferred way to indicate hovering, but still have a default way to indicate hovering if the preferred indicator is not available or not installed.
The result may end up borrowing from lessons of each of these experiments and others.
These experiments will only happen if enough agree our current standards suck badly. It appears to me that most developers don't care because esoteric messes are job security. Easier UI building will put many of us out of work. I care because I'd rather focus on business logic (domain issues) rather then buggy scroll-bars, text that mushes together on IE 9.48237 but not IE 9.48238, dialog boxes that pop up blank on Chrome version 7.34928 or whatnot.
GUI's have been around 40 odd years, building them shouldn't be fucking rocket science anymore. That's not rational.
Rockets are actually easier because physics doesn't change and is the same everywhere, but not DOM. Rocket engineers are probably saying, "Guys, fix your damned rocket: this isn't DOM Science!"
If you can not work with OOP and/functional concepts, your mind is stuck in simple thinking, you only get around that by actually using the stuff you hate.
Ironic, because OOP used to be touted as being "more natural": it allegedly fit our conceptual high-level view of objects of the real world, including easy-to-digest taxonomies, like "employee" and "contract worker" being a sub-class of "person", and traits of "person" magically trickle down to employee and contract-worker to give us magic re-use. (In practice we need set-based feature selection and trees proved too blunt an instrument.)
Now it's an esoteric dark art that requires extra discipline like spinach and exercise.
How about proponents scientifically prove a technique is better rather than just claim it loudly. Objectively measure important, useful, relevant, and wide-ranging factors; and show how the technique improves those factors (better score).
Without science to check claims, trolls are indistinguishable from Einsteins.
As mentioned nearby, I generally agree that money influences scientific paper results.
But there's zero evidence the current climate change findings are significantly influenced by such forces.
And peer review eventually corrects poor findings. If a paper's result is something few care about, few bother to check and confirm. But if it is deemed important, eventually others do check. Correcting something important DOES get one scientific recognition, and thus more funding.
You can lie to some of the people all of the time, and to all of the people some of the time, but you cannot lie to all of the people all of the time.
Using a private server has only one possible use which is to illegally bypass this.
Illegal? You are NOT a lawyer, stop pretending to be one. C. Powell did the same thing; I don't see conservatives calling him "a crook". And the State Dept. did NOT say it was outright forbidden, only that she didn't go about getting permission by the policy book. Their policy book is NOT federal law. You are flat wrong, dude!
Of course it is her job, even where she delegates it is her responsibility to see to it those tasks are done correctly.
I will agree she appears to have delegated poorly, but that's indirect "negligence". There SHOULD be a dedicated security manager whose job is to inform and inspect (or delegate inspections). The Sec. of State should NOT be an administrative position in charge of infrastructure and routine security inspections. That's outright dumb. The S-of-S job is to work with and negotiate with world leaders. GOP and Comey are more interested in blaming than fixing the organization. The org is factored wrong, forcing the CEO to spend time on grunty tasks.
For example, Communications from foreign embassies, diplomats, and government officials are all classified upon creation.
Reminds me when I wrote a full-screen text editor in Fortran for the Prime mini-computer the org had because I got tired of the command-line editor. It caught on and clerks started using it for customer support call screen text editing. (One could purchase FSE's, but the org was a penny-pincher.)
my point is that abstracting yourself from the DOM is a good thing if you are worried about browser cross-compatibility.
But browsers change. Changes to their DOM engine in the future can and do break abstractions. Vendor security fixes quite often introduce unintended consequences, for example.
And the bigger the abstraction layer, the more that can go wrong. I run into UI gizmos on other big-name sites that are broken or half broken all the time. They too used a library.
The DOM is already a UI abstraction layer. The UI libraries people put on top of it are also an abstraction layer. Thus, it's a double layering, and both lawyers either suck or are unstable over time. Too many layers.
Somebody else has already spent more man-hours than you will ever have at your disposal on making abstraction layers to these things
Not enough, they suck. And even if they had an army of a billion techs, they still cannot anticipate future browser changes. Works today but trips tomorrow. And the libraries often fall out of style after a few years and lose support. You can say, "well X didn't fall", but how is one going to know ahead of time.
Maybe the newer generation just got used to unstable UI's and accept fiddling and fudging and launching the app in browser B when it hoses up under A. Maybe I should just embrace UI suckage like the youngbies do and live with shit.
You look at the guts of the libraries and see shit like:
if (chrome) {
if (version between 3.85 and 4.1) {
fudge.fiddle(x, y, z, shoesize);
} else {
fiddle. kludge(x);
} } else if (IE or Opera) {
if (ie.version < 8.3) {
kludgify(fiddleFactory(x, y));
}
foo.bar() } else if (firefox) {
thingy2.rotate();
margin.delete(); } else { // guess by checking return results
stuff = try.dom.activity7(); // I'm not making that up: code often does // feature detection by trying the feature itself: // The test-pilot approach to programming. ... // (Slashdot F'd my indents.) }
Just admit it, we are collectively doing it wrong. Humanity fucked up our UI "standard". The HTML stack was fine for general simple brochure-like pages, but is a crappy desktop app wannabe.
Hence if you need to refactor you did not understand the domain model beforehand.
An architect can't always know everything. We move, they move, we all scream for ice-cream.
And even if one knows the current domain, it's very difficult to anticipate future changes. Change requests come out of left field all the time that go against the grain of the current system. If a technique requires a well-functioning crystal ball or perfect knowledge, then it's focked.
It's better not to try to lace everything together with an overriding global domain model. If a given task can remain mostly independent, it should. If it gets what it needs and only what it needs from the community, then it's not tied to side issues and more protected against change requests that don't (and shouldn't) affect it.
Ask yourself, does X truly need to know or care about Y? If not, cut the wires.
Because she was the secretary of state and such content was inevitable if she illegally used a private server for business.
The "regular" office email server was NOT designed for classified info either. Outside of the archive problem, the home-ness of the server is moot to my question. If she had used the in-office server, classified stuff would still end up on the "wrong server".
because she was the secretary of state and her job was to know the rules for determining information is and is not classified
Please elaborate, perhaps with an example/scenario. I find that statement too general. Knowing the rules doesn't necessarily mean it's her job to monitor and enforce them anymore than its her to job to inspect the building's plumbing.
If she got fact X from person Y, is it her job to verify that fact X is not classified? There may be situations where she "should have known", but nobody has supplied specifics such that we don't know how realistic it is for her to have known. It's probably highly situational such that details and context matter.
If the base tables are normalized, you can update them through a de-normalizing view.
I had a long debate with a dude once over how much to normalize. After a heated debate, we both eventually agreed that IF the RDBMS were well designed, everyone could have the views they want: low-normalized and/or high-normalized, and they'd all be update-able (within reason). It wouldn't be either/or.
One would be able to select (and perhaps make) the "view-name-space" they wanted and everyone would be happy: it's all virtual and relative.
If the RDBMS ran faster with the de-normalized version (or vice versa) under the hood, the DBA could decide run (change) it that way and the views would continue to work as-is: nobody would know it was changed under the hood.
But in practice RDBMS don't support such virtualization/abstraction well, and with the way they are now, a "lowish" normalization is usually better.
Tablizer has quite a reputation outside of Slashdot for his thoughtful criticisms of OOP. It's difficult to claim that he doesn't understand it...
It's entirely possible I outright "don't get" OOP for domain modelling (OODM), despite trying to figure it since the late 90's. OODM appears to make the design more complicated to my eyes and fingers. It's supposed to make the design better able to handle future changes in requirements*, but "refactoring" is now accepted as a common ritual when the design turns out to be wrong. If it made the system change-friendly, you wouldn't NEED to refactor much. Constant refactoring means OODM failed at its primary stated goal*.
Part of the problem is that it seems to be trying to make universal/global modelling decisions, and then later one finds out it's the wrong universal model due to new requirements and/or "philosophizing wrong" and have to rework it. Focusing on a task at hand means one only has to model a local temporal little world and is not committed to universal modelling declarations. There's no Grand Taxonomy Burden. No crystal ball needed.
Relational modelling also requires global modelling to some extent, but it's mostly driving by repetition factoring (avoiding duplicate info) and NOT by an intended global description of reality.
Other experienced people have come to similar conclusions. They too found use in OOP, but not in domain modelling. Sometimes it helps organize certain code better, but the reason has little or nothing to do with modelling real word things. It simply packages certain services and related state nicely code-wise.
Maybe OODM is somehow "better", but some of us, perhaps many of us, are somehow inherently color-blind to its benefits. I'd be hesitant to claim one-technique-fits-all-minds.
* Although the alleged benefits and their ranking vary per proponent, which also highlights the fishiness.
Why doesn't the C family offer a modernized replacement for it's ugly case/switch statement? Keep the old one for backward compatibility, but add a new one with different keywords that doesn't need "break", and has "set lists". Even VB did it better. Maybe something like:
select(a) {
when 1,2,3 {...}
when 4 {...}
when 5,6 {...}
otherwise {...}
}
Slashdot Mirror
Most our org's PS scripts are in VB-Script. Is there an interpreter for it on Linux?
Check your other engine also.
My interpretation was that you are saying PHP is "good" because it made you money, NOT because it's a good language/tool. Thus, I used fires and fire-fighting as a sarcastic and exaggerated analogy.
Microsoft's crappiness is certainly a "jobs program" for techies, but that's not the same as being a good product set.
We all have a little Hillary in us ;-)
I don't claim it can't happen, only that it's hit and miss and nobody can come up with clear guidelines to make it more likely to succeed beyond "keep trying, after N projects it will finally click." But that means N - 1 projects are crappy; a lot of collateral damage that makes our Middle East policy look sane in comparison.
ANY paradigm/technique can be "refactored" to improve it or make it fit better when it doesn't work very well.
Make a best guess.
Government-created? No. Private org.
If you mean many of their customers are gov't entities, you are correct.
Oracle's RDBMS was actually revolutionary when it came out. Before that you had difficult-to-use DB's such as IMS and CODASYL's pasta-like children.
SQL is not perfect, but it was a big step up. SQL was invented/defined by IBM, but they dragged their feet on in it, fearing it would hurt their IMS cash cow. Oracle released the first commercial RDBMS, and it was a hit because the alternatives sucked.
You have to give them credit for that, even though they are slimy with regard to lawyers and sales gimmicks.
Google should purchase the PostgreSql organization, improve the database's compatibility with Oracle, improve the documentation, and stick links to it everywhere. If anybody googles with "Oracle" in the search phrase, include a link to PostgreSql in their ads.
Cite the specific criminal law, per exact text, that she allegedly violated.
Prosecutors only go after presidential candidates? You are making some ridiculous claims. They just busted a Navy tech for publishing secrets. He wasn't running for prez.
Fire Fighter: "Fires create a lot of havoc for some people, but I love them. Fires have made me boatloads of money and paid for my house. Burn on!"
Correction,
I did mention UI's when I said: "The input screens and/or update ordering may not match the table divisions"
But that's not something users (data entry operators) are concerned with. My suggestions are not about how to design front ends.
I'll give a more explicit example. Suppose a given draft table has columns A, B, C, D, E, and F.
There are currently 3 draft CRUD screens in the design, Screen 1 that updates columns A and B, Screen 2 that updates columns C and D, and Screen 3 that updates columns E and F.
A new architect comes along and decides to add "higher normalization" by splitting the table into 3 tables that match the screens: table T1 has columns A and B, table T2 columns C and D, and table T3 with columns E and F.
It's perhaps okay for now, but later the screens are changed into two screens where the first one modifies columns A, B, and D, while screen 2 modifies C, E, and F.
Not only do the new screens no longer match the existing (split) tables, but now each screen has to access two tables where before it only had to access one. The split has served no useful purpose and makes the app more complicated and slower.
Perhaps there is or was some "conceptual" value in the split, but it's either no longer relevant, or of small value.
One could make 3 views instead if there is some conceptual value in splitting and leave the original "wide" table in place.
And I don't see what your "IP" example saves. You still have to modify the middle layer. Unless there is a high "share count" to modified parts, it's a waste of layers. Use subroutines or views for JUST the highly shared parts rather than put a middle layer for everything for speculative future sharing. Factor out actual duplication only.
I don't understand. I'm talking about application developers and DBA interaction. What do data-entry operators have to do with anything? I said nothing about UI's. There appears to a misunderstanding here. And I'm not against views.
BOTH are a matter of wrong-tool-for-the-job.
ColdFusion (CF) was originally intended for HTML templating to make it easier for graphics designers and HTML-only coders to code for RDBMS-supplied content without having to bother the app dev for minor changes. It worked so well that CF started to be used for more general or complicated programming, and that's where you found ugly limits*.
Similarly, JavaScript was originally designed as a light-duty glue language to handle browser events not built into the HTML standard(s). It worked well enough that people started using it as a systems language to implement entire GUI engines, and found ugly limits (which I rant about in detail elsewhere on this story).
The same pattern played out in JS and CF:
1. A tool is designed for a niche
2. It's highly successful in its niche
3. Popularity causes uses outside of original goal
4. People complain about the ill fit, summarily blaming the tool
5. Tablizer chews them out for painting with a wide brush
A similar thing happened with VB classic. It was intended for smallish internal applications, but people tried to build enterprise-sized or packaged software with it, and it choked under the weight and got a bad general reputation.
A similar thing also happened with IBM's RPG (Report Program Generator). It was intended to simplify the generation of reports. It was successful enough that others started using it for general application programming, and vendors wrote entire applications in it. Many programmers complained about it and bad-mouthed it in general.
* CF is still well-suited for the original goal. In additional to built-in CF XML tags for populating HTML with data, one can build custom XML tags so that HTML designers/coders can use XML for common tasks for a shop instead of having to learn a "regular" programming language. One can argue they "should" learn regular languages, but if they won't or can't, CF is a nice tool for them. It has full subroutines now, and a feature set comparable to ASP classic. With some exceptions, one can even code in a JavaScript-like variant of it if you don't like XML.
The complexity, bugs, and instability of the underlying layer is leaking into the abstraction layer. You can only hide so much crap behind an abstraction layer. If the bottom layer were a fixed target, then one could eventually throw enough labor into the abstraction layer to work around all the problems. But it's a moving target.
I don't understand what you are saying here. I'm not against abstraction layers, only saying they can only fix/hide so much.
I am not talking about individual projects, but rather that we need industry-wide standards better tuned to our needs. Essentially everyone wants to have/build desktop-like applications that are housed on networks instead of local harddrives/storage.
HTML/DOM/JS was NOT originally built for that at all. They have been stretched like the mother of all taffy try to become desktoppy, but the results so far are really ugly for users, developers, and bandwidth.
I'd like to see universities experiment with multiple draft GUI-over-network standards to try to find/build a standard that actually has the correct goal in mind.
Ideas to try include but are not limited to:
1. Moving the formatting/flow calculations to the server, making the client a dumb (simple) coordinate plotter of vectors and polygons.
2. Add interactive elements to PostScript and/or PDF.
3. Improve on X Window standard to handle input feedback latency better.
4. Create a GUI Markup language with more of the common desktop GUI idioms like drag-and-drop, MDI (sub-windows), data tables, expansion trees, menus, tool-bars, panel tabs, right-click menus, etc. The browser/client shouldn't have to re-load the implementation code for these on every website it visits. That's not rational.
5. Fail-friendly animations. Certain fancy animations could be built into the standard, or perhaps as add-ons, but in such a way that if they are not implemented in a given client/browser, then useful behavior still exists. For example, a button could be defined as throbbing if the mouse hovers over it. But if a client doesn't want to implement throbbing, it can default to a shade change or an outline color change on hover. In other words, throbbing is indicated as the preferred way to indicate hovering, but still have a default way to indicate hovering if the preferred indicator is not available or not installed.
The result may end up borrowing from lessons of each of these experiments and others.
These experiments will only happen if enough agree our current standards suck badly. It appears to me that most developers don't care because esoteric messes are job security. Easier UI building will put many of us out of work. I care because I'd rather focus on business logic (domain issues) rather then buggy scroll-bars, text that mushes together on IE 9.48237 but not IE 9.48238, dialog boxes that pop up blank on Chrome version 7.34928 or whatnot.
GUI's have been around 40 odd years, building them shouldn't be fucking rocket science anymore. That's not rational.
Rockets are actually easier because physics doesn't change and is the same everywhere, but not DOM. Rocket engineers are probably saying, "Guys, fix your damned rocket: this isn't DOM Science!"
Ironic, because OOP used to be touted as being "more natural": it allegedly fit our conceptual high-level view of objects of the real world, including easy-to-digest taxonomies, like "employee" and "contract worker" being a sub-class of "person", and traits of "person" magically trickle down to employee and contract-worker to give us magic re-use. (In practice we need set-based feature selection and trees proved too blunt an instrument.)
Now it's an esoteric dark art that requires extra discipline like spinach and exercise.
How about proponents scientifically prove a technique is better rather than just claim it loudly. Objectively measure important, useful, relevant, and wide-ranging factors; and show how the technique improves those factors (better score).
Without science to check claims, trolls are indistinguishable from Einsteins.
As mentioned nearby, I generally agree that money influences scientific paper results.
But there's zero evidence the current climate change findings are significantly influenced by such forces.
And peer review eventually corrects poor findings. If a paper's result is something few care about, few bother to check and confirm. But if it is deemed important, eventually others do check. Correcting something important DOES get one scientific recognition, and thus more funding.
You can lie to some of the people all of the time, and to all of the people some of the time, but you cannot lie to all of the people all of the time.
Illegal? You are NOT a lawyer, stop pretending to be one. C. Powell did the same thing; I don't see conservatives calling him "a crook". And the State Dept. did NOT say it was outright forbidden, only that she didn't go about getting permission by the policy book. Their policy book is NOT federal law. You are flat wrong, dude!
I will agree she appears to have delegated poorly, but that's indirect "negligence". There SHOULD be a dedicated security manager whose job is to inform and inspect (or delegate inspections). The Sec. of State should NOT be an administrative position in charge of infrastructure and routine security inspections. That's outright dumb. The S-of-S job is to work with and negotiate with world leaders. GOP and Comey are more interested in blaming than fixing the organization. The org is factored wrong, forcing the CEO to spend time on grunty tasks.
Link/citation?
Reminds me when I wrote a full-screen text editor in Fortran for the Prime mini-computer the org had because I got tired of the command-line editor. It caught on and clerks started using it for customer support call screen text editing. (One could purchase FSE's, but the org was a penny-pincher.)
But browsers change. Changes to their DOM engine in the future can and do break abstractions. Vendor security fixes quite often introduce unintended consequences, for example.
And the bigger the abstraction layer, the more that can go wrong. I run into UI gizmos on other big-name sites that are broken or half broken all the time. They too used a library.
The DOM is already a UI abstraction layer. The UI libraries people put on top of it are also an abstraction layer. Thus, it's a double layering, and both lawyers either suck or are unstable over time. Too many layers.
Not enough, they suck. And even if they had an army of a billion techs, they still cannot anticipate future browser changes. Works today but trips tomorrow. And the libraries often fall out of style after a few years and lose support. You can say, "well X didn't fall", but how is one going to know ahead of time.
Maybe the newer generation just got used to unstable UI's and accept fiddling and fudging and launching the app in browser B when it hoses up under A. Maybe I should just embrace UI suckage like the youngbies do and live with shit.
You look at the guts of the libraries and see shit like:
Just admit it, we are collectively doing it wrong. Humanity fucked up our UI "standard". The HTML stack was fine for general simple brochure-like pages, but is a crappy desktop app wannabe.
An architect can't always know everything. We move, they move, we all scream for ice-cream.
And even if one knows the current domain, it's very difficult to anticipate future changes. Change requests come out of left field all the time that go against the grain of the current system. If a technique requires a well-functioning crystal ball or perfect knowledge, then it's focked.
It's better not to try to lace everything together with an overriding global domain model. If a given task can remain mostly independent, it should. If it gets what it needs and only what it needs from the community, then it's not tied to side issues and more protected against change requests that don't (and shouldn't) affect it.
Ask yourself, does X truly need to know or care about Y? If not, cut the wires.
Can you present a specific case of that happening, or at least definitive evidence that such did happen?
The "regular" office email server was NOT designed for classified info either. Outside of the archive problem, the home-ness of the server is moot to my question. If she had used the in-office server, classified stuff would still end up on the "wrong server".
Please elaborate, perhaps with an example/scenario. I find that statement too general. Knowing the rules doesn't necessarily mean it's her job to monitor and enforce them anymore than its her to job to inspect the building's plumbing.
If she got fact X from person Y, is it her job to verify that fact X is not classified? There may be situations where she "should have known", but nobody has supplied specifics such that we don't know how realistic it is for her to have known. It's probably highly situational such that details and context matter.
I had a long debate with a dude once over how much to normalize. After a heated debate, we both eventually agreed that IF the RDBMS were well designed, everyone could have the views they want: low-normalized and/or high-normalized, and they'd all be update-able (within reason). It wouldn't be either/or.
One would be able to select (and perhaps make) the "view-name-space" they wanted and everyone would be happy: it's all virtual and relative.
If the RDBMS ran faster with the de-normalized version (or vice versa) under the hood, the DBA could decide run (change) it that way and the views would continue to work as-is: nobody would know it was changed under the hood.
But in practice RDBMS don't support such virtualization/abstraction well, and with the way they are now, a "lowish" normalization is usually better.
It's entirely possible I outright "don't get" OOP for domain modelling (OODM), despite trying to figure it since the late 90's. OODM appears to make the design more complicated to my eyes and fingers. It's supposed to make the design better able to handle future changes in requirements*, but "refactoring" is now accepted as a common ritual when the design turns out to be wrong. If it made the system change-friendly, you wouldn't NEED to refactor much. Constant refactoring means OODM failed at its primary stated goal*.
Part of the problem is that it seems to be trying to make universal/global modelling decisions, and then later one finds out it's the wrong universal model due to new requirements and/or "philosophizing wrong" and have to rework it. Focusing on a task at hand means one only has to model a local temporal little world and is not committed to universal modelling declarations. There's no Grand Taxonomy Burden. No crystal ball needed.
Relational modelling also requires global modelling to some extent, but it's mostly driving by repetition factoring (avoiding duplicate info) and NOT by an intended global description of reality.
Other experienced people have come to similar conclusions. They too found use in OOP, but not in domain modelling. Sometimes it helps organize certain code better, but the reason has little or nothing to do with modelling real word things. It simply packages certain services and related state nicely code-wise.
Maybe OODM is somehow "better", but some of us, perhaps many of us, are somehow inherently color-blind to its benefits. I'd be hesitant to claim one-technique-fits-all-minds.
* Although the alleged benefits and their ranking vary per proponent, which also highlights the fishiness.
Why doesn't the C family offer a modernized replacement for it's ugly case/switch statement? Keep the old one for backward compatibility, but add a new one with different keywords that doesn't need "break", and has "set lists". Even VB did it better. Maybe something like:
select(a) {
when 1,2,3 {...}
when 4 {...}
when 5,6 {...}
otherwise {...}
}