So we offshored all our application development to India, all our electronics manufacturing to China, all our security development to eastern Europe and Russia, and now we are worried about our gadgets being compromised?
Did I say bet the company? No, I said experiment. Experiments can be small and controlled so they are compared against real world usage of your legacy systems.
I worked at a small business where the IT manager had your mentality. It was a Mac office (for historic reasons) and he kept delaying and delaying upgrades because he didn't want to deal with the disruptions caused by the Apple switch to x86. He even went so far as to purchase a bunch of desktops before they went out of production so he would have spares.
The end result, was that several years later the business could no longer upgrade *any* of their critical desktop software without triggering a 250K project to overall literally every machine and server in the office. The interim versions of all the business-critical software were no longer available, so there was no longer an incremental upgrade path.
You experiment in order to learn. Technology changes. Business changes. You need to be prepared for the change, and a constant allocation for experimentation is the best way to do it, AND to make sure that your individual skills are staying relevant.
Or, if you prefer, you can be your generation's version of those high-demand COBOL mainframe developers when you're 70, and hope that your business doesn't simply lift and replace the entire stack leaving you out of work.
No, that's not what backups are for. Backups are for disaster recovery. How long does it take you to recover from a backup? Have you tested it? In production?
How long will the business tolerate downtime? Can you be back and running within the acceptable limit?
Again, if you're not testing this stuff, you're shooting yourself in the foot and you will have a catastrophic failure at some point in the future.
And in the meantime you went out of business because the startups had enough funding to last long enough to steal all your customers, or enough VCs were willing to spin up enough startups.
Of the 1955 Fortune 500 companies, 9/10 have gone out of business or been acquired. They all were the definition of having customers and cashflow.
If your company involves technology at all, and you are not continuously experimenting, then you will be disrupted by someone who you don't even see as a competitor. Buggy whip makers didn't see the car as competition. Train networks didn't see trucks and planes coming. The recording and movie industries didn't predict what the internet would do to their business.
In today's landscape if you're sitting still, you're falling behind. You just don't see it yet.
Perhaps the cost of a Lamda service that runs once a month is substantially lower than keeping a dedicated box up and running. Perhaps 18 of your servers can go away and be cloud managed. Perhaps next month your company will make an acquisition and you need to start scaling. I don't know your infrastructure, but you also don't know what opportunities do exist. You're making biased assumptions that are just as bad as the biased assumptions you so despise in your junior staff.
I repeat, since you did not read the first time: (and notice I do not use the word "cloud" or "server" anywhere in this statement because it's a truism across tech):
"If you're not taking time to experiment and find what will work for your company, then you are destined to fall behind and lose to a startup who will do it faster and cheaper because they don't have the legacy technical debt to deal with."
If youâ(TM)re not taking time to experiment and find what will work for your company, then you are destined to fall behind and lose to a startup who will do it faster and cheaper because they donâ(TM)t have the legacy technical debt to deal with.
Almost every one of Adobe's Creative Cloud products are for both Windows and OSX. What would they have to lose by selling Linux versions as well?
I guarantee you they have spent many times your annual paycheck in order to evaluate if they'll number of licenses they sell for Linux will pay off the development costs of making Linux versions of their desktop software.
For a totally contrary perspective to your argument, in the "enterprise" space (Microsoft Azure and Adobe Marketing Cloud respectively) both companies do a huge amount of revenue on Linux stacks.
Sure they can. In most US jurisdictions if you call in a false fire alarm, they can charge you for the cost of the fire department response. Why would police be different?
Wrong. Every one of these networks has a "conversion pixel" which is the tracking script they put on the order confirmation page to collect purchase info. They're just really shitty at identifying the product you purchased vs the catalog of products they know about. Mostly this is because they are lazy and the people paying for the ads aren't demanding better.
There's plenty of frameworks and libraries to do that. Also, if you separate your content authoring servers from your content publishing servers, you usually get that (Drupal, WordPress, and many others CMS platforms can easily be setup this way. AEM for example (very very expensive) works that way by default). This only protects against certain types of attacks of course. For example, there's no way to inject SQL through a Wordpress flaw if your public-facing publishing server only has read-access to the database. (though there could still be tons of other types of security flaws).
Website security is a hard problem. The many-eyes approach helps to avoid the common pitfalls when you roll your own solution. As with anything else, there's a tradeoff in risk, maintainability, cost, and a thousand other factors that vary by situation.
The fact that the debate in this thread is happening proves my point. Yes, people should be trained to do paramertized queries. But SQL-injection is just one of many potential security flaws that takes time to learn, understand, and ensure you follow best practices to avoid the security risk. Well-supported frameworks most likely have already gone through those growing pains and have the benefit of many-eyes. Something your roll-it-myself solution most likely would not have.
I think it's a tradeoff. Do you need blogs, commenting, authentication, permission systems, easily updatable content by non-technical users, etc? For example, rolling your own authentication system is easy. Rolling your own that isn't vulnerable to DDOS and SQL-injection attacks is a really hard problem that people have already solved within most frameworks or CMS systems. In this case, a CMS might be worthwhile. However, ff you just need a couple of static pages that don't require regular changes, then skip it. But if the client can't be bothered to spend the money and time for regular maintenance and security patches, then they should just be directed to a WYSIWYG end-to-end system that offers the whole thing as a managed service.
ESPN is doing it. You can get ESPN as a $X add-on to Sling. For some reason they want to stay out of direct-billing, probably because of the customer support costs.
My manager and peers are constantly amazed at how much work I get done. The secret? Working in an open plan means I overhear conversations and know about upcoming initiatives that will impact my team and my projects. I'm aware of the business needs and big picture, so can plan more successful deliveries.
Different people excel in different kinds of working conditions. There is no one-size-fits-all. Even though I'm an introvert, I would absolutely hate working from home or working in cubicles and would quickly be looking for another job should I find myself in that situation.
As a security measure to prevent account hijacking, most services these days require a confirmation email sent to the original address when you change the email address one file.
Kinda makes it hard when you can no longer access the original email.
The problem with your argument is that the demos today are exactly the same as the demos from 15 years ago (seriously I was doing this same basic automation commands for light on/off with off the shelf x10 equipment and perl web interfaces at university in 2010 - and that want even in the CS program).
Voice recognition libraries were available even then with Dragonspeak integration. Add the contextual understanding and there might be something here - but as of right now he's bragging about problems solved since before we had iPhones.
Slashdot Mirror
So we offshored all our application development to India, all our electronics manufacturing to China, all our security development to eastern Europe and Russia, and now we are worried about our gadgets being compromised?
Color me surprised.
Did I say bet the company? No, I said experiment. Experiments can be small and controlled so they are compared against real world usage of your legacy systems.
Right, and removing half of the middle of a plane wouldn't have any effect on structural integrity or weight.
Without experimenting, how do you know that *any* technology will fit *your* needs?
I worked at a small business where the IT manager had your mentality. It was a Mac office (for historic reasons) and he kept delaying and delaying upgrades because he didn't want to deal with the disruptions caused by the Apple switch to x86. He even went so far as to purchase a bunch of desktops before they went out of production so he would have spares.
The end result, was that several years later the business could no longer upgrade *any* of their critical desktop software without triggering a 250K project to overall literally every machine and server in the office. The interim versions of all the business-critical software were no longer available, so there was no longer an incremental upgrade path.
You experiment in order to learn. Technology changes. Business changes. You need to be prepared for the change, and a constant allocation for experimentation is the best way to do it, AND to make sure that your individual skills are staying relevant.
Or, if you prefer, you can be your generation's version of those high-demand COBOL mainframe developers when you're 70, and hope that your business doesn't simply lift and replace the entire stack leaving you out of work.
No, that's not what backups are for. Backups are for disaster recovery. How long does it take you to recover from a backup? Have you tested it? In production?
How long will the business tolerate downtime? Can you be back and running within the acceptable limit?
Again, if you're not testing this stuff, you're shooting yourself in the foot and you will have a catastrophic failure at some point in the future.
If you don't experiment and measure results, then both the junior and senior developers are spouting opinions.
And in the meantime you went out of business because the startups had enough funding to last long enough to steal all your customers, or enough VCs were willing to spin up enough startups.
Of the 1955 Fortune 500 companies, 9/10 have gone out of business or been acquired. They all were the definition of having customers and cashflow.
If your company involves technology at all, and you are not continuously experimenting, then you will be disrupted by someone who you don't even see as a competitor. Buggy whip makers didn't see the car as competition. Train networks didn't see trucks and planes coming. The recording and movie industries didn't predict what the internet would do to their business.
In today's landscape if you're sitting still, you're falling behind. You just don't see it yet.
"only 36 servers" is a red herring.
Perhaps the cost of a Lamda service that runs once a month is substantially lower than keeping a dedicated box up and running. Perhaps 18 of your servers can go away and be cloud managed. Perhaps next month your company will make an acquisition and you need to start scaling. I don't know your infrastructure, but you also don't know what opportunities do exist. You're making biased assumptions that are just as bad as the biased assumptions you so despise in your junior staff.
I repeat, since you did not read the first time: (and notice I do not use the word "cloud" or "server" anywhere in this statement because it's a truism across tech):
If youâ(TM)re not taking time to experiment and find what will work for your company, then you are destined to fall behind and lose to a startup who will do it faster and cheaper because they donâ(TM)t have the legacy technical debt to deal with.
Almost every one of Adobe's Creative Cloud products are for both Windows and OSX. What would they have to lose by selling Linux versions as well?
I guarantee you they have spent many times your annual paycheck in order to evaluate if they'll number of licenses they sell for Linux will pay off the development costs of making Linux versions of their desktop software.
For a totally contrary perspective to your argument, in the "enterprise" space (Microsoft Azure and Adobe Marketing Cloud respectively) both companies do a huge amount of revenue on Linux stacks.
In defense of the poor schmuck who wrote the code, a cancel message probably wasnâ(TM)t in the spec.
CYA across the board by everyone involved is what lead to the system failure here.
Sure they can. In most US jurisdictions if you call in a false fire alarm, they can charge you for the cost of the fire department response. Why would police be different?
Have you even used OSX?
https://imgur.com/a/qsY7q
There's a gradient and drop shadows there on the window header and every button has both a border and subtle drop shadow.
Bullshit. I've been using Sleep Cycle on the iPhone for 5 years and it suffers from exactly zero if the problems you described.
Re-read the thread and who the authors are of the various comments. I never said anything about parameterized queries being subject to SQL injection.
Wrong. Every one of these networks has a "conversion pixel" which is the tracking script they put on the order confirmation page to collect purchase info. They're just really shitty at identifying the product you purchased vs the catalog of products they know about. Mostly this is because they are lazy and the people paying for the ads aren't demanding better.
There's plenty of frameworks and libraries to do that. Also, if you separate your content authoring servers from your content publishing servers, you usually get that (Drupal, WordPress, and many others CMS platforms can easily be setup this way. AEM for example (very very expensive) works that way by default). This only protects against certain types of attacks of course. For example, there's no way to inject SQL through a Wordpress flaw if your public-facing publishing server only has read-access to the database. (though there could still be tons of other types of security flaws).
Website security is a hard problem. The many-eyes approach helps to avoid the common pitfalls when you roll your own solution. As with anything else, there's a tradeoff in risk, maintainability, cost, and a thousand other factors that vary by situation.
The fact that the debate in this thread is happening proves my point. Yes, people should be trained to do paramertized queries. But SQL-injection is just one of many potential security flaws that takes time to learn, understand, and ensure you follow best practices to avoid the security risk. Well-supported frameworks most likely have already gone through those growing pains and have the benefit of many-eyes. Something your roll-it-myself solution most likely would not have.
I think it's a tradeoff. Do you need blogs, commenting, authentication, permission systems, easily updatable content by non-technical users, etc? For example, rolling your own authentication system is easy. Rolling your own that isn't vulnerable to DDOS and SQL-injection attacks is a really hard problem that people have already solved within most frameworks or CMS systems. In this case, a CMS might be worthwhile. However, ff you just need a couple of static pages that don't require regular changes, then skip it. But if the client can't be bothered to spend the money and time for regular maintenance and security patches, then they should just be directed to a WYSIWYG end-to-end system that offers the whole thing as a managed service.
ESPN is doing it. You can get ESPN as a $X add-on to Sling. For some reason they want to stay out of direct-billing, probably because of the customer support costs.
My manager and peers are constantly amazed at how much work I get done. The secret? Working in an open plan means I overhear conversations and know about upcoming initiatives that will impact my team and my projects. I'm aware of the business needs and big picture, so can plan more successful deliveries.
Different people excel in different kinds of working conditions. There is no one-size-fits-all. Even though I'm an introvert, I would absolutely hate working from home or working in cubicles and would quickly be looking for another job should I find myself in that situation.
As a security measure to prevent account hijacking, most services these days require a confirmation email sent to the original address when you change the email address one file.
Kinda makes it hard when you can no longer access the original email.
The problem with your argument is that the demos today are exactly the same as the demos from 15 years ago (seriously I was doing this same basic automation commands for light on/off with off the shelf x10 equipment and perl web interfaces at university in 2010 - and that want even in the CS program).
Voice recognition libraries were available even then with Dragonspeak integration. Add the contextual understanding and there might be something here - but as of right now he's bragging about problems solved since before we had iPhones.