In the tech world, there's always a plethora of popular tools that have been around for some time, but some people including me just don't have the time/capacity/resource/insert-reason-here to try it out.
For me, it's Docker.
I strongly advice you to use it, or some similar tool that solve the same dependency hell problem.
It is not a matter of opinion, the problem is there and we can not ignore it.
The hype is still going strong as of now ...
It is not a hype. It is a tool that broke a paradigm, in the right moment that it was needed.
... people are starting to use Docker in development as well.
Which is good, because:
You can exactly reproduce the context of a prod error in your local machine without just a few commands. Those old programmers know that the most frequent phrase in the past was "But it works for me locally..." when they were argued to fix a prod issue.
It allows you to quickly setup the development frameworks and tools as needed for a project. Think what you would do if you have to work as freelancer for many projects as one, and they use distinct versions of the same frameworks and tools. Install and uninstall every time you need to work some hours in a project?
It allows you to have your machine clean, which speeds up the machine. Some systems like windows starts to be slow when there are many programs installed because of the amount of files in the system or app folders / partitions.
It allows you to restore your dev environment quickly after loosing the system. It might be that your hard disk died, or the system is slow or you want to change it. After reinstall you install docker, your code editor, check out some repos from git and everything is running. No need to spend hours configuring your frameworks or tools.
But if you don't want to worry is ok, at the end somebody else in your company is in charge of the IT, and it should provide a solution to you. By the way, many dev environments are moving to the cloud also, like: VSO, coder, etc..
I think that is a matter of time that "all" the customers start to ask for equivalent technologies that fit the same paradigm shift.
At the end, if we don't learn how to build your dev environments aligned to the deployments ... we will need to pay for it... It is a decision to take for everyone.
It makes a good presentation of all those paradigms and the context where they are useful. Not a compendium, just an introduction.
I am confident that many people might have creativity peaks that can bring the current paradigms down just by being informed on the current problems and where everything fits into.
And that's what be the main concern of this post. I guess nobody needs to be an expert in docker, git or anything other tool it with success to build new creative and useful stuffs.
The Full-Stack way of thinking should not be ... "I need to be an expert on everything", just I need to know what is everything for and which problem it solves for my team or the industry. Of course more deep knowledge on every stuff gives you more control and increase the possibilities of success. But the knowledge adquision process should be Breadth-first and just Depth-first when required by a project milestone or a debugging process.
That's why I have always preferred books who present introductions to those that present exhaustive compilations of something.
I am waiting for some math guru to write a similar book for the math branches and their current applications to the industry. Many paradigms have been broken with this kind of reasoning:
That was applied with success in this field, but that other field has some similarities with it. What if we apply that also here ?
Paradigms, architectural styles/patterns, and design patterns are really essential to properly solve a problem.
I really feel thankful being a software architect, so that I can realize when someone jumping for microservices solution (with docker, kubernetes, and whatever super duper tech) just cuz it's fancy 🤦
Or automating tests with Selenium just cuz big company X are using it 🤮
As you said, understanding the tech might be important to finish a specific project, but realizing the problems which the tech solves is x10 billion more important.
I guess it's time to write an article on "Why Software Architecture REALLY Matters for All Developers".
Looking forward to the article! I love it when an article breaks down the tiny problems from the top level to see the big picture (in this case, software architecture). I would love to learn.
Whoa, TIL! Thanks for the info about Docker. Will definitely try it out someday...
It is not a hype.
Poor choice of word, I guess. What I meant was the popularity. Hype kind of takes the meaning not in a good way.
At the end, if we don't learn how to build your dev environments aligned to the deployments
Sure, knowing only how to build the development is bad on its own. But never actually tried building one for production has the same degree of sin, IMO. My idea is that one should know the benefit of using Docker in production first, then running it in development. As mentioned in OP, I haven't had any necessity to do it yet. Once I actually tried running one on prod, I would definitely see the benefit of running it in development.
As mentioned in OP, I haven't had any necessity to do it yet
I guess those are the best paradigm shifts for tools. That tool that we think we don't need, and at the end we can not live without them.
I had such a similar feeling during the rise of version control software, unit tests, etc.. I did programs at least six years without all of that and 24 years later I don't imagine living without them.
tool that we think we don't need, and at the end we can not live without them.
In hindsight, there are tools that we think we needed, but as it turns out it has become irrelevant or replaced by better ones. On the top off my head: Coffeescript (ES6 and Typescript made it irrelevant), jQuery (browser maturity/frontend framework made it irrelevant), Browserify (Webpack/other better bundler tools made it irrelevant). Obviously, I'm not saying Docker is going to be one of them LOL, I'm just saying that the statement could go both ways.
But I truly agree with you with version control, unit tests. There are certain things that we could invest early and it turned out to be really essential. I think it takes experience to know if which tool is which, and with Docker I'm going to agree with you because my devops skills as a frontend dev is totally 👎🏼 😂 Thanks for the detailed info tho!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I strongly advice you to use it, or some similar tool that solve the same dependency hell problem.
It is not a matter of opinion, the problem is there and we can not ignore it.
It is not a hype. It is a tool that broke a paradigm, in the right moment that it was needed.
Which is good, because:
You can exactly reproduce the context of a prod error in your local machine without just a few commands. Those old programmers know that the most frequent phrase in the past was "But it works for me locally..." when they were argued to fix a prod issue.
It allows you to quickly setup the development frameworks and tools as needed for a project. Think what you would do if you have to work as freelancer for many projects as one, and they use distinct versions of the same frameworks and tools. Install and uninstall every time you need to work some hours in a project?
It allows you to have your machine clean, which speeds up the machine. Some systems like windows starts to be slow when there are many programs installed because of the amount of files in the system or app folders / partitions.
It allows you to restore your dev environment quickly after loosing the system. It might be that your hard disk died, or the system is slow or you want to change it. After reinstall you install docker, your code editor, check out some repos from git and everything is running. No need to spend hours configuring your frameworks or tools.
But if you don't want to worry is ok, at the end somebody else in your company is in charge of the IT, and it should provide a solution to you. By the way, many dev environments are moving to the cloud also, like: VSO, coder, etc..
Read this.
I think that is a matter of time that "all" the customers start to ask for equivalent technologies that fit the same paradigm shift.
At the end, if we don't learn how to build your dev environments aligned to the deployments ... we will need to pay for it... It is a decision to take for everyone.
Truth been told 👌
Docker is one of the tech killers of this century.
Not just that... Often, they continue to make more amazing stuff!
That would be a good survey.
I did really like a book that a friend did borrow me:
Software Paradigms from Stephen H. Kaisler
It makes a good presentation of all those paradigms and the context where they are useful. Not a compendium, just an introduction.
I am confident that many people might have creativity peaks that can bring the current paradigms down just by being informed on the current problems and where everything fits into.
And that's what be the main concern of this post. I guess nobody needs to be an expert in docker, git or anything other tool it with success to build new creative and useful stuffs.
The Full-Stack way of thinking should not be ... "I need to be an expert on everything", just I need to know what is everything for and which problem it solves for my team or the industry. Of course more deep knowledge on every stuff gives you more control and increase the possibilities of success. But the knowledge adquision process should be Breadth-first and just Depth-first when required by a project milestone or a debugging process.
That's why I have always preferred books who present introductions to those that present exhaustive compilations of something.
I am waiting for some math guru to write a similar book for the math branches and their current applications to the industry. Many paradigms have been broken with this kind of reasoning:
So the question should not about the tools or frameworks, the should be a about the paradigm shift that originated them and the problem they solve.
A good exercise for that is reviewing the tech comparison charts of wikipedia, the software reviews, etc.
Absolutely true!
Paradigms, architectural styles/patterns, and design patterns are really essential to properly solve a problem.
I really feel thankful being a software architect, so that I can realize when someone jumping for microservices solution (with docker, kubernetes, and whatever super duper tech) just cuz it's fancy 🤦
Or automating tests with Selenium just cuz big company X are using it 🤮
As you said, understanding the tech might be important to finish a specific project, but realizing the problems which the tech solves is x10 billion more important.
I guess it's time to write an article on "Why Software Architecture REALLY Matters for All Developers".
Looking forward to the article! I love it when an article breaks down the tiny problems from the top level to see the big picture (in this case, software architecture). I would love to learn.
Whoa, TIL! Thanks for the info about Docker. Will definitely try it out someday...
Poor choice of word, I guess. What I meant was the popularity. Hype kind of takes the meaning not in a good way.
Sure, knowing only how to build the development is bad on its own. But never actually tried building one for production has the same degree of sin, IMO. My idea is that one should know the benefit of using Docker in production first, then running it in development. As mentioned in OP, I haven't had any necessity to do it yet. Once I actually tried running one on prod, I would definitely see the benefit of running it in development.
I guess those are the best paradigm shifts for tools. That tool that we think we don't need, and at the end we can not live without them.
I had such a similar feeling during the rise of version control software, unit tests, etc.. I did programs at least six years without all of that and 24 years later I don't imagine living without them.
In hindsight, there are tools that we think we needed, but as it turns out it has become irrelevant or replaced by better ones. On the top off my head: Coffeescript (ES6 and Typescript made it irrelevant), jQuery (browser maturity/frontend framework made it irrelevant), Browserify (Webpack/other better bundler tools made it irrelevant). Obviously, I'm not saying Docker is going to be one of them LOL, I'm just saying that the statement could go both ways.
But I truly agree with you with version control, unit tests. There are certain things that we could invest early and it turned out to be really essential. I think it takes experience to know if which tool is which, and with Docker I'm going to agree with you because my devops skills as a frontend dev is totally 👎🏼 😂 Thanks for the detailed info tho!