3 ms·

I recall averting what would have been a rather opaque security weakness by pointing out that occasionally someone would goof and vary the default locale of som

I recall averting what would have been a rather opaque security weakness by pointing out that occasionally someone would goof and vary the default locale of some JVM instances. (With a particular knock-on effect that I'll omit here.) Paying attention to the system you'll land on is something that can go lost even to senior developers. And, therein, details, details, details... Another reason to have a strong ops (or devops) team: Providing/enforcing proper, intended, and thoughtful context and runtime. P.S. As I now recall, there was also the use case for locale to deliberately vary, although that use case / those instances should have remained orthogonal to those of other locales. Nonetheless, one more possible driver of a mistake that would enable this weakness to occur.

lmm 13y ago
> Another reason to have a strong ops (or devops) team: Providing/enforcing proper, intended, and thoughtful context and runtime. I have to disagree, actually. This kind of problem is exactly where you really benefit from having full-stack people who understand both sides of the system; it would have been very hard for an ops person who didn't know about Java's quirks or a pure dev who didn't know about the unix filesystem to diagnose.
- pasbesoin 13y ago
  I see your point. And... I had to escalate to a very senior person of that sort (full stack, or full picture -- in detail) in order to get that particular problem paid attention to and resolved. (Such a perspective is also how I determined the problem in the first place -- which actually resulted from a botched fix to a prior problem that I'd identified.) However, despite the variance -- or risk of same -- that I described, in general we had some very capable and dedicated devops people who put a lot of effort and care into our environments. I get rather uncomfortable considering how things would have been had that not been the case. It's been a while, and maybe I'm mixing my stories a bit. But I left that role and product mix -- which had very significant security requirements and ramifications -- quite impressed with the role those devops folks played in keeping us safe. Perhaps what I meant by "strong" goes somewhat in the direction of your description of "full stack". Our senior devops people tended to trend in that direction. And we didn't have "turf wars". Instead, devops was a partner often throughout the development lifecycle. It helped make sure that the final destination was appropriate, safely, and consistently configured. (My "locale" situation aside; and in such an instance, the setting would subsequently receive heightened and sustained scrutiny, putting a curb on unintended variance of the setting as well as fixing the code that such variance would impact.) Strong in knowledge and ability, as opposed to simply or foremost in an authority to dictate.
  - lmm 13y ago
    I think we agree that it's good to have these skills somewhere on your team, and to work together during development. I just don't think dividing people into "ops" and "dev" is helpful. There it was something like one guy who spent 80% of his time on traditionally-ops stuff and 20% development, another guy who was 70% development and 30% database admin, one who was basically full-time ops but happened to be the maintainer of an open-source library that we used in our products, one who had been hired as a developer but was starting to pick up ops tasks because he preferred that...

lmm 13y ago

> Another reason to have a strong ops (or devops) team: Providing/enforcing proper, intended, and thoughtful context and runtime. I have to disagree, actually. This kind of problem is exactly where you really benefit from having full-stack people who understand both sides of the system; it would have been very hard for an ops person who didn't know about Java's quirks or a pure dev who didn't know about the unix filesystem to diagnose.

pasbesoin 13y ago
I see your point. And... I had to escalate to a very senior person of that sort (full stack, or full picture -- in detail) in order to get that particular problem paid attention to and resolved. (Such a perspective is also how I determined the problem in the first place -- which actually resulted from a botched fix to a prior problem that I'd identified.) However, despite the variance -- or risk of same -- that I described, in general we had some very capable and dedicated devops people who put a lot of effort and care into our environments. I get rather uncomfortable considering how things would have been had that not been the case. It's been a while, and maybe I'm mixing my stories a bit. But I left that role and product mix -- which had very significant security requirements and ramifications -- quite impressed with the role those devops folks played in keeping us safe. Perhaps what I meant by "strong" goes somewhat in the direction of your description of "full stack". Our senior devops people tended to trend in that direction. And we didn't have "turf wars". Instead, devops was a partner often throughout the development lifecycle. It helped make sure that the final destination was appropriate, safely, and consistently configured. (My "locale" situation aside; and in such an instance, the setting would subsequently receive heightened and sustained scrutiny, putting a curb on unintended variance of the setting as well as fixing the code that such variance would impact.) Strong in knowledge and ability, as opposed to simply or foremost in an authority to dictate.
- lmm 13y ago
  I think we agree that it's good to have these skills somewhere on your team, and to work together during development. I just don't think dividing people into "ops" and "dev" is helpful. There it was something like one guy who spent 80% of his time on traditionally-ops stuff and 20% development, another guy who was 70% development and 30% database admin, one who was basically full-time ops but happened to be the maintainer of an open-source library that we used in our products, one who had been hired as a developer but was starting to pick up ops tasks because he preferred that...