Alex decided that he needed a Nico Rosberg to go with his Lewis Hamilton. His F1 collection is more up to date than mine is.
2016-09-30
Alex's F1 Collection
Alex decided that he needed a Nico Rosberg to go with his Lewis Hamilton. His F1 collection is more up to date than mine is.
2016-09-26
Summer TV Series Update
- Zoo: steadily more and more improbable, along with a "meanwhile, 12 years later" ending. Renewed for 2017.
- The Last Ship: Renewed for 2017 (and 2018 somehow).
- Mr. Robot: I have not seen s2e12 yet, but so far it's been reasonable -- the mid-season reveal was worth the wait. Renewed for 2017.
- Dark Matter: Badly titled, fun at times without being tedious. Renewed.
- Stan Lee's Lucky Man: really enjoying this one. Renewed.
DevOps? Let me tell you a story.
(This is a slight edit of a comment I made on Reddit.)
In the beginning, there was no ops, only Dev. Developers were responsible for everything, from building the hardware -- sometimes literally -- through programming the system, through making sure it kept running in production.
Now there are two problems with this state of affairs. Firstly, the more things you have in production, the less time you have for solving interesting new problems. This is exasperated by the second problem: keeping existing systems running is boring. Developers don't like boring. So keeping things running started to bog down the process of making new things.
At this point, a new position was created, that of the Operator. The Operator relieved the Developer of the tedious, boring business of keeping things going. This meant the Developer could go back to the fun of developing.
The Ops people start coming to grips with their responsibilities and start worrying about standardisation, reproducibility, predictability, processes and the like.
Now a curious thing happens when you separate a developer from the consequences of their choices -- they stop caring about them. So suddenly dev is "releasing" stuff that isn't fully baked, trying to dump the responsibility for running this crap on the ops. This leads to the well known trope of "works in dev, production's problem now". QA was invented somewhere around here in an effort to make sure that what dev was throwing over the wall wasn't total crap, but we all know how well that actually works.
So now you have two impediments between a dev and production. You have to get your stuff passed by QA, who are inevitably sticklers for stuff that isn't -- in your opinion -- really that important, and then you have to jump through the hoops that the Ops people put in your way, causing delays while hardware is orderd, built, and provisioned, all the time complaining that the standard Ops environment is ancient and not up to date with the cutting edge tools you are using to build this stuff.
So what did Dev do? They solved the first problem with "Agile". Now a dev is responsible for his own QA, with unit tests and pair programming and user stories. So a dev can say when things are done.
And "DevOps" is about solving the other problem -- instead of having an Ops group, now the developer is responsible for production as well. It is full circle back to the beginning, when Dev did everything.
And already it is breaking. Now instead of DevOps, people are talking about "serverless", where the entire production platform is an outsourced service -- which is just the latest attempt by Dev to avoid both the hindrance of Ops and the consequences of their own decisions.
Now you may be saying, "but it sound stupid when you say it that way." To that I say: A) OK, say it so it doesn't sound stupid, and B) the reason for this is the very nature of development.
By that I mean the vast majority of software developers are self-taught. Most of what they know is stuff they learned banging on their own projects. The corollary of this is that they generally don't accept anything they have not learned themselves. And since most of them are teenagers or early-20's kids, they have not learned anything about large systems and systems with long life spans. So they think nothing of choosing the latest hotness for a development language instead of something more mature -- because re-inventing wheels is more fun than fixing existing ones. These kids land in the real world thinking that there isn't any problem they can't fix with open source and a weekend of hard work. So of course anything that gets in their way is bad.
Ten years later they've learned otherwise, but at that point most of them are out of the business, and those who are left are having their lunch eaten by the next generation of new-hotness-weilding, lessons-from-the-past-ignoring, wheel-reinventing 18 year olds.
And the cycle continues.
TL/DR: DevOps is the latest attempt by developers to hide from both reality and the consequences of their own choices.
Edit: just to give some perspective, I'm a 20-year sysadmin, so I've seen this cycle happen twice.
In the beginning, there was no ops, only Dev. Developers were responsible for everything, from building the hardware -- sometimes literally -- through programming the system, through making sure it kept running in production.
Now there are two problems with this state of affairs. Firstly, the more things you have in production, the less time you have for solving interesting new problems. This is exasperated by the second problem: keeping existing systems running is boring. Developers don't like boring. So keeping things running started to bog down the process of making new things.
At this point, a new position was created, that of the Operator. The Operator relieved the Developer of the tedious, boring business of keeping things going. This meant the Developer could go back to the fun of developing.
The Ops people start coming to grips with their responsibilities and start worrying about standardisation, reproducibility, predictability, processes and the like.
Now a curious thing happens when you separate a developer from the consequences of their choices -- they stop caring about them. So suddenly dev is "releasing" stuff that isn't fully baked, trying to dump the responsibility for running this crap on the ops. This leads to the well known trope of "works in dev, production's problem now". QA was invented somewhere around here in an effort to make sure that what dev was throwing over the wall wasn't total crap, but we all know how well that actually works.
So now you have two impediments between a dev and production. You have to get your stuff passed by QA, who are inevitably sticklers for stuff that isn't -- in your opinion -- really that important, and then you have to jump through the hoops that the Ops people put in your way, causing delays while hardware is orderd, built, and provisioned, all the time complaining that the standard Ops environment is ancient and not up to date with the cutting edge tools you are using to build this stuff.
So what did Dev do? They solved the first problem with "Agile". Now a dev is responsible for his own QA, with unit tests and pair programming and user stories. So a dev can say when things are done.
And "DevOps" is about solving the other problem -- instead of having an Ops group, now the developer is responsible for production as well. It is full circle back to the beginning, when Dev did everything.
And already it is breaking. Now instead of DevOps, people are talking about "serverless", where the entire production platform is an outsourced service -- which is just the latest attempt by Dev to avoid both the hindrance of Ops and the consequences of their own decisions.
Now you may be saying, "but it sound stupid when you say it that way." To that I say: A) OK, say it so it doesn't sound stupid, and B) the reason for this is the very nature of development.
By that I mean the vast majority of software developers are self-taught. Most of what they know is stuff they learned banging on their own projects. The corollary of this is that they generally don't accept anything they have not learned themselves. And since most of them are teenagers or early-20's kids, they have not learned anything about large systems and systems with long life spans. So they think nothing of choosing the latest hotness for a development language instead of something more mature -- because re-inventing wheels is more fun than fixing existing ones. These kids land in the real world thinking that there isn't any problem they can't fix with open source and a weekend of hard work. So of course anything that gets in their way is bad.
Ten years later they've learned otherwise, but at that point most of them are out of the business, and those who are left are having their lunch eaten by the next generation of new-hotness-weilding, lessons-from-the-past-ignoring, wheel-reinventing 18 year olds.
And the cycle continues.
TL/DR: DevOps is the latest attempt by developers to hide from both reality and the consequences of their own choices.
Edit: just to give some perspective, I'm a 20-year sysadmin, so I've seen this cycle happen twice.
2016-09-18
Lounging
Alex lounging around at Nana's. Something about him sitting in this chair -- not this pose, but in general -- reminds me strongly of my father.
2016-09-17
Tomato
Nathan presented the world with two tomato plants after school in June. One had apparently gone to the ISS as a seed, the other had not. This one is with one of his grandparents and is showing signs of fruit. The other went to his other grandmother, and while it produced fruit, the fruit rotted before it could ripen properly. We don't know which seed was from the ISS and which one wasn't.
2016-09-16
Collection
Having a text conversation with my brother, and it came up as to how I stored my open Hot Wheels. There are three more cases behind the one that's propped out, none of them are full-full but that's because I'm sorting as a go. These are the BMWs, all of them I think.
2016-09-14
Subscribe to:
Posts (Atom)