Just change your title around; how about "cloud deployment coordinator" instead of sys admin. Same shit but with new polish. I got it: "Cloud Synergizer"! A title that's pure PHB sugar.
I like the analysis part, especially the trickier screens or flows, but want to keep a foot in the code side. Although perhaps I should let go of that final connection. It's kind of like cutting the umbilical cord to youth: I'm hesitant to admit my coding days may be finally over.
I guess I wasn't clear on what I meant by "team friendly". I meant organizing both team members and the architecture around the needs and abilities of the team in order for the team to be as productive as possible. This also applies to regular level coders coding for future maintainers. One has to kind of get into others' thinking processes to make it easy to grok and change for THEM. That's mostly the kind of "people skills" I'm talking about. I didn't really mean "budy budy" type of friendly, at least not as the primary metric.
Seriously, all of the space stations have had leaks. Most were caused by micrometeorites that hit them. How many have blown apart because of that? NONE.
Just because a catastrophe hasn't happened (yet) doesn't mean the risk level is acceptable. Let's say a space station with an average duration of 10 years has a 10% chance of bursting. After 3 space stations, you'd have roughly a 30% chance of at least 1 bursting. Therefore, even with a 10% chance per station, after 3 actual stations you likely would NOT have a bursting failure. Yet, 10% is still ugly odds.
But a good technology person can deliver a lot more than an entire team of their more average peers.
I believe this is mostly a myth. While there are people who can crank out code and/or applications really fast, the results are often not maintainable because they are either not designed with other maintainers in mind, or use a technique that typical maintenance staff is not familiar with. You want "team-friendly" developers, not lone keyboard cowboys.
For example, I've built up libraries of code that allow me to throw together typical CRUD apps really quick. However, most others are not familiar with my library and related conventions such that they have a notable learning curve. Second, the conventions it uses may not be liked by a given organization. Each org is persnickety about different things.
There may be a few wizards that are both quick and team-friendly, but they are pretty rare in my observation. Technical wizardry and people/team skills just don't occur in the same person. I'm just the messenger.
TFA: "In terms of job opportunities, it's probably no surprise that Millennials have the edge. Those between 25-30 years old get the most job offers, reports Hired's 2017 State of Global Tech Salaries. After the age of 45, the average salary and number of job offers decline. After 50, most IT pros see a significant decline in salary in line with their experience."
Just like the NBA: churn and burn. It may be better to become a domain expert with IT knowledge rather than a "direct" IT expert. For example, accounting and chemistry don't change nearly as quick as direct IT. Thus, domain experience is more likely to be valued after age 45. I don't see bunches of accounting and chemistry fads equivalent to IT fads. There's no "Quarks are Obsolete! Learn NoQuarksNeeded 2.0 in 21 Days Head First Unleashed" books in the chemistry section. (Hmmm, maybe there's room for con artists in those industries.)
IT is closer to the clothing fashion industry than real topics. That's why they want younglings. I've seen several dozens of way to do plain old CRUD screens over the years. Do we really need 38 ways to do the same thing and throw out #1 thru #37 to get 38? Plus, they often grow more complicated over time, not less. De-evolution. "It's agile functional separation of scale-able and cloud-able concerns that provides nimble global synergy..." Yeah right, shuddup[1]. The cloud, for example, is often used as an excuse to do really stupid unproven shit in order to out-buzzword your conpetition[2]. Con artists rule over IT.
[1] and git off my lawn [2] misspelling intentional
*shrug* It's kind of the problem that every web company everywhere faces.
No, most use dynamic CMS's, the very things we were looking to avoid in this thread. Some CMS's do have dynamic replication built in, but somebody had to build them in, and it only partly solves the security problems we were trying to avoid by going static-file.
In the worst case, you could keep a local copy, write a script to check for changes against your new revision, then upload anything that changed.
Worse case? We want timely file replication all the time. Co's I'm familiar with want stuff up within 15 minutes at times. If there is two-way checking, then you not only have bandwidth issues, but a potential pathway for hackers, which is what we were trying to avoid by going static-file.
If you work some examples out on paper, assume there will be burps and hiccups in the network etc., and see how it recovers itself. I can see folder-level check-sums being used and other such gizmos, but that requires sophisticated algorithms in order to be reliable, bandwidth-friendly, and timely, and likely have host-side processes. It starts to look like a database and thus one is reinventing database-ish tech. The more complicated it is, the more it is subject to the same kinds of attacks database-oriented CMS are subject to. Databases use things like check-sums and sequential transaction ID's to make sure stuff doesn't get lost when they implement replication. Files are not typically indexed on the attributes needed to do such timely. If they were, they'd start to be databases such that you might as well use a common database rather than be stuck with a specialized database staff won't be familiar with.
I know there are LAN-oriented tools for syncing files, but we are not talking LAN. Their techniques assume fast and cheap networking and/or lots of control over both servers.
I'm willing to bet AWS has some support for something like this too
Probably, but it's probably non-trivial to implement and has holes.
I toldja this was coming. Eventually everyone in the work-place will have to have one to compete with countries that make it wide-spread.
And soon after, we'll even skip the screen and hook into the optic nerve. (All your damned JS libraries will be obsolete yet again. Lobe.js will be in:-)
But you have to transfer that info from source to the destination server. The CPU is not the bottleneck.
Take server A and server B with only an SFTP connection between them. How do you know what is different between them, in terms of the web content folder tree?
I agree most of the time we only need to send a "delta set" of changes, but there should be a consistency check at least once a week because bleep can happen. If we over-complicate the info exchange between the servers, then we have the security problems we are trying to avoid by going static.
He could start by focusing on a topic where his team only has to collect content on a particular subject matter. They could even use Google to get content leads. Focus on something historical or static (at first) to avoid having a moving target, like ancient history, Shakespeare, math, etc. When the concept is proven, he can get more resources/investors.
There is already a practical example of this: existing AI can flag videos, ads, social network posts etc. as "suspicious" so that a human examiner can review it for a keep/cut decision. This reduces the need for an army of human reviewers. Such filter bots will get incrementally better over time so that increasingly less human intervention is needed (or more content can be reviewed without hiring more reviewers). The suspicious-content detection bots are still "useful" even though they are not human.
It uses tools and/or conventions more typical of a regular office and thus allows AI problems to be split up and analyzed in a modular team-oriented fashion. Tables are easier to relate to than traditional neural nets (without a lot of training, at least). TOAI allows compartmentalizing AI tasks to distribute to staff (tasks, sub-tasks, etc.), and encourages a kit-oriented approach (modularization).
For example, you may have 3 sub-teams: 1) pattern/test makers, 2) results examiners, and 3) coordinators.
The first group focuses on making the individual tests (patterns or "factors"), the second group focuses on determining which tests are most or least useful for given situations, and the 3rd group be the coordinators who split up the problems and/or AI decision flow between groups and/or template sets (filters).
Why the fuck can't we type in a question [in Google] and get a decent answer? There's all sorts of pre-processing you can do with the computing we have now to put a lot more semantics in there...
If he knows how to build a better search engine than Google, then form a company and kick Google's ass. Or, go to work for Bing. Wasn't question answering supposed to be wolframalpha's forte?
AI still lacks what we usually call "common sense" and screws up a lot of things because of that. The tech isn't there yet.
Sites for medium or large orgs can have several thousands of files. I don't see how a simple tool can scan & compare those in a timely manner. Managers like to see some changes show up pretty quick. There may need to be a "quick mode" and a slower but more thorough clean-up mode/process, like a nightly batch.
dropped to a temperature of about 90K, barely above liquid nitrogen. No terrestrial life will contaminate anything at that temperature.
Not necessarily. Spores could survive in a frozen state, and then later if a liquid water volcano or similar erupts, the spores could awake and seep toward the core. Unlikely and/or many years away, but not impossible.
I saw an actual mock-up from JPL in a museum. It is big. Without putting it next to an actual school-bus it's hard to say how accurate that description is, though. I'm not used to comparing probes to vehicles, and thus its hard to mentally compare.
Slashdot Mirror
I thought devops was a waning fad already.
Just change your title around; how about "cloud deployment coordinator" instead of sys admin. Same shit but with new polish. I got it: "Cloud Synergizer"! A title that's pure PHB sugar.
I like the analysis part, especially the trickier screens or flows, but want to keep a foot in the code side. Although perhaps I should let go of that final connection. It's kind of like cutting the umbilical cord to youth: I'm hesitant to admit my coding days may be finally over.
I called it 3 years ago! (Well, okay C2 called it, but I get repost cred. Biggest repost ever, believe me!)
I guess I wasn't clear on what I meant by "team friendly". I meant organizing both team members and the architecture around the needs and abilities of the team in order for the team to be as productive as possible. This also applies to regular level coders coding for future maintainers. One has to kind of get into others' thinking processes to make it easy to grok and change for THEM. That's mostly the kind of "people skills" I'm talking about. I didn't really mean "budy budy" type of friendly, at least not as the primary metric.
Just because a catastrophe hasn't happened (yet) doesn't mean the risk level is acceptable. Let's say a space station with an average duration of 10 years has a 10% chance of bursting. After 3 space stations, you'd have roughly a 30% chance of at least 1 bursting. Therefore, even with a 10% chance per station, after 3 actual stations you likely would NOT have a bursting failure. Yet, 10% is still ugly odds.
Whoever the hell "foobar@example.com" is, they have received a shitload of shit from our team over the years.
True, but a good bullshit artist can convince a PHB they do.
I believe this is mostly a myth. While there are people who can crank out code and/or applications really fast, the results are often not maintainable because they are either not designed with other maintainers in mind, or use a technique that typical maintenance staff is not familiar with. You want "team-friendly" developers, not lone keyboard cowboys.
For example, I've built up libraries of code that allow me to throw together typical CRUD apps really quick. However, most others are not familiar with my library and related conventions such that they have a notable learning curve. Second, the conventions it uses may not be liked by a given organization. Each org is persnickety about different things.
There may be a few wizards that are both quick and team-friendly, but they are pretty rare in my observation. Technical wizardry and people/team skills just don't occur in the same person. I'm just the messenger.
Just like the NBA: churn and burn. It may be better to become a domain expert with IT knowledge rather than a "direct" IT expert. For example, accounting and chemistry don't change nearly as quick as direct IT. Thus, domain experience is more likely to be valued after age 45. I don't see bunches of accounting and chemistry fads equivalent to IT fads. There's no "Quarks are Obsolete! Learn NoQuarksNeeded 2.0 in 21 Days Head First Unleashed" books in the chemistry section. (Hmmm, maybe there's room for con artists in those industries.)
IT is closer to the clothing fashion industry than real topics. That's why they want younglings. I've seen several dozens of way to do plain old CRUD screens over the years. Do we really need 38 ways to do the same thing and throw out #1 thru #37 to get 38? Plus, they often grow more complicated over time, not less. De-evolution. "It's agile functional separation of scale-able and cloud-able concerns that provides nimble global synergy..." Yeah right, shuddup[1]. The cloud, for example, is often used as an excuse to do really stupid unproven shit in order to out-buzzword your conpetition[2]. Con artists rule over IT.
[1] and git off my lawn
[2] misspelling intentional
No, most use dynamic CMS's, the very things we were looking to avoid in this thread. Some CMS's do have dynamic replication built in, but somebody had to build them in, and it only partly solves the security problems we were trying to avoid by going static-file.
Worse case? We want timely file replication all the time. Co's I'm familiar with want stuff up within 15 minutes at times. If there is two-way checking, then you not only have bandwidth issues, but a potential pathway for hackers, which is what we were trying to avoid by going static-file.
If you work some examples out on paper, assume there will be burps and hiccups in the network etc., and see how it recovers itself. I can see folder-level check-sums being used and other such gizmos, but that requires sophisticated algorithms in order to be reliable, bandwidth-friendly, and timely, and likely have host-side processes. It starts to look like a database and thus one is reinventing database-ish tech. The more complicated it is, the more it is subject to the same kinds of attacks database-oriented CMS are subject to. Databases use things like check-sums and sequential transaction ID's to make sure stuff doesn't get lost when they implement replication. Files are not typically indexed on the attributes needed to do such timely. If they were, they'd start to be databases such that you might as well use a common database rather than be stuck with a specialized database staff won't be familiar with.
I know there are LAN-oriented tools for syncing files, but we are not talking LAN. Their techniques assume fast and cheap networking and/or lots of control over both servers.
Probably, but it's probably non-trivial to implement and has holes.
I toldja this was coming. Eventually everyone in the work-place will have to have one to compete with countries that make it wide-spread.
And soon after, we'll even skip the screen and hook into the optic nerve. (All your damned JS libraries will be obsolete yet again. Lobe.js will be in :-)
Now we get all the holes of Windows AND Linux in one OS. Jeenius!
I'm skeptical, it's a lot of info about files that needs to transfer.
Pandemic Jar Jar debate? Somebody's gonna think we're nerds.
Chairman Meow?
But you have to transfer that info from source to the destination server. The CPU is not the bottleneck.
Take server A and server B with only an SFTP connection between them. How do you know what is different between them, in terms of the web content folder tree?
I agree most of the time we only need to send a "delta set" of changes, but there should be a consistency check at least once a week because bleep can happen. If we over-complicate the info exchange between the servers, then we have the security problems we are trying to avoid by going static.
He could start by focusing on a topic where his team only has to collect content on a particular subject matter. They could even use Google to get content leads. Focus on something historical or static (at first) to avoid having a moving target, like ancient history, Shakespeare, math, etc. When the concept is proven, he can get more resources/investors.
There is already a practical example of this: existing AI can flag videos, ads, social network posts etc. as "suspicious" so that a human examiner can review it for a keep/cut decision. This reduces the need for an army of human reviewers. Such filter bots will get incrementally better over time so that increasingly less human intervention is needed (or more content can be reviewed without hiring more reviewers). The suspicious-content detection bots are still "useful" even though they are not human.
The future may be table-oriented AI (TOAI).
It uses tools and/or conventions more typical of a regular office and thus allows AI problems to be split up and analyzed in a modular team-oriented fashion. Tables are easier to relate to than traditional neural nets (without a lot of training, at least). TOAI allows compartmentalizing AI tasks to distribute to staff (tasks, sub-tasks, etc.), and encourages a kit-oriented approach (modularization).
For example, you may have 3 sub-teams: 1) pattern/test makers, 2) results examiners, and 3) coordinators.
The first group focuses on making the individual tests (patterns or "factors"), the second group focuses on determining which tests are most or least useful for given situations, and the 3rd group be the coordinators who split up the problems and/or AI decision flow between groups and/or template sets (filters).
"Google, how many people are currently on my lawn?"
If he knows how to build a better search engine than Google, then form a company and kick Google's ass. Or, go to work for Bing. Wasn't question answering supposed to be wolframalpha's forte?
AI still lacks what we usually call "common sense" and screws up a lot of things because of that. The tech isn't there yet.
Sites for medium or large orgs can have several thousands of files. I don't see how a simple tool can scan & compare those in a timely manner. Managers like to see some changes show up pretty quick. There may need to be a "quick mode" and a slower but more thorough clean-up mode/process, like a nightly batch.
Not necessarily. Spores could survive in a frozen state, and then later if a liquid water volcano or similar erupts, the spores could awake and seep toward the core. Unlikely and/or many years away, but not impossible.
Can anyone by chance find a Youtube vid of those band screens during the dive?
I saw an actual mock-up from JPL in a museum. It is big. Without putting it next to an actual school-bus it's hard to say how accurate that description is, though. I'm not used to comparing probes to vehicles, and thus its hard to mentally compare.