\n \n \n AlfredApp<\/a>\n<\/h3>\n\nThis adds a spotlight like feature with plugins and commands, I particularly enjoy \"screen saver\"(to start it and lock the screen) and \"empty trash\"<\/p>\n\n
\n \n \n BitBar<\/a>\n<\/h3>\n\nThis adds elements to the status bar with the output of the scripts you put on its plugin folder. The project has lots of scripts that you can download but I prefer to use my own, like the one to see how much RAM I have consumed and another that shows how many dockers do I have running at the moment.<\/p>\n\n
\n \n \n Enpass<\/a>\n<\/h3>\n\nIt's a nice password manager that stores the vaults on your computer (with the option to sync using your own accounts on cloud providers) and runs on any major platform.<\/p>\n\n
\n \n \n Shuttle<\/a>\n<\/h3>\n\nA configurable ssh shortcuts that I mainly use to list and access my ~\/.ssh\/config.<\/p>\n\n
\n \n \n Bartender<\/a>\n<\/h3>\n\nFor when you have way too many icons on the status bar.<\/p>\n\n
\n \n \n Gifox<\/a>\n<\/h3>\n\nA nice tool to record the screen and make a gif with it, really useful to explain workflows in Jira.<\/p>\n\n
\n \n \n Terminal stuff\n<\/h1>\n\n\n \n \n iTerm<\/a>\n<\/h3>\n\nThe emulator that everyone should use.<\/p>\n\n
\n \n \n oh-my-zsh<\/a>\n<\/h3>\n\nOf course, you should use zsh with this to have plugins and themes.<\/p>\n\n
\n \n \n zsh-autosuggestions<\/a>\n<\/h3>\n\nThis is hands down my favorite plugin for zsh. It uses your history to suggest autocompletion.<\/p>\n\n
\n \n \n zsh-syntax-highlighting<\/a>\n<\/h3>\n\nIf the command you are writing is not in $PATH it shows in red otherwise in green.<\/p>\n\n
\n \n \n Shellcheck<\/a>\n<\/h3>\n\nA linter for shell scripts.<\/p>\n\n
\n \n \n VSCode extensions\n<\/h1>\n\n\n \n \n Bracket Pair Colorizer<\/a>\n<\/h3>\n\nIt uses different colors for different sets of brackets, it is extremely useful when you have gone a little wild with the if.<\/p>\n\n
\n \n \n Indent Rainbow<\/a>\n<\/h3>\n\nIt uses colors to show each column of indentation making very easy to fix indentation errors(looking at you YAML...).<\/p>\n\n
\n \n \n Code Coverage<\/a>\n<\/h3>\n\nTool to highlight lines not covered by unit tests.<\/p>\n\n
\n \n \n CodeMetrics<\/a>\n<\/h3>\n\nComputes complexity in TypeScript \/ JavaScript files.<\/p>\n\n
\n \n \n Docker<\/a>\n<\/h3>\n\nAdds syntax highlighting, commands, hover tips, and linting for Dockerfile and docker-compose files.<\/p>\n\n
\n \n \n Git Project Manager<\/a>\n<\/h3>\n\nIt allows you to change easily between git projects.<\/p>\n\n
\n \n \n Peacock<\/a>\n<\/h3>\n\nSubtly change the workspace color of your workspace. Ideal when you have multiple VS Code instances and you want to quickly identify which is which. This is probably one of my most used extensions. shootout to <\/p>\n
\n \n \n ![\"john_papa](\"https:\/\/media.dev.to\/dynamic\/image\/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto\/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F138665%2Fcee5c68d-3bd2-4042-af64-5214952d6c30.jpg\")
\n <\/div>\n <\/a>\n \n \nJohn Papa<\/a>Follow\n<\/h2>\n \n Husband, father, & Catholic enjoying life with my family. Working @ Microsoft. Disney fanatic, web and mobile developer<\/a>\n <\/div>\n <\/div>\n<\/div>\n\n\n\n \n \n Rest Client<\/a>\n<\/h3>\n\nA little and simple rest client inside VSCode.<\/p>\n\n
\n \n \n Settings Sync<\/a>\n<\/h3>\n\nSynchronize Settings, Snippets, Themes, File Icons, Launch, Keybindings, Workspaces, and Extensions Across Multiple Machines Using GitHub Gist.<\/p>\n\n
\n \n \n Trailing Spaces<\/a>\n<\/h3>\n\nHighlight trailing spaces.<\/p>\n\n","category":"productivity"},{"title":"Do you really need Kubernetes in your company\/startup?","pubDate":"Mon, 17 Jun 2019 10:37:00 +0000","link":"https:\/\/dev.to\/anortef\/do-you-really-need-kubernetes-in-your-company-startup-1ec0","guid":"https:\/\/dev.to\/anortef\/do-you-really-need-kubernetes-in-your-company-startup-1ec0","description":"
Let me start saying that I love Kubernetes, I even have a personal one for my things but I'm an experienced DevOps and it is in my spare time.<\/p>\n\n
Usually, you want the complexity of the technical solutions your company uses to increase on complexity accordingly to your needs.<\/p>\n\n
You may think: whoa! I need to have autodiscovery between my microservices, a load balancer for the HTTP API and everything must be declared as a code to be maintainable without a shady guy from Ops<\/em><\/p>\n\nAnd of course, you need that, especially the last part, but is really Kubernetes the only thing that can give you that?<\/p>\n\n
\n \n \n Docker-Compose<\/a>\n<\/h3>\n\nIts a tool written in Python that let you define environments using YAML.<\/p>\n\n
The good things about this are that you can use this to make and maintain the developer's local environment and If you have only one production server (very little startup) you can even use the same YAML files used to develop your solution to deploy it into the server.<\/p>\n\n
The bad thing is that it is not really designed to run on a cluster so you are limited to a one and only production machine.<\/p>\n\n
\n \n \n Docker Swarm<\/a>\n<\/h3>\n\nIt's a solution that comes with Docker and allows to manage several machines with Docker as one cluster.<\/p>\n\n
In essence, Swarm and Kubernetes do the same but are not the same. The good thing about Swarm is that you can reuse the same YAML files that you were using with docker-compose and, in the pipeline, add the scaling stuff they need on Swarm.
\nYou can use things like Traefik to manage the access and you can reuse it if you switch to Kubernetes later on.<\/p>\n\n
The only problem is that it lacks good observability when reaching a good size.<\/p>\n\n
\n \n \n Kubernetes<\/a>\n<\/h3>\n\nKubernetes is a generalist container orchestrator, therefore it doesn't deal with Docker concepts but with abstractions that represent concepts inside the ecosystem, like Pods.<\/p>\n\n
The good thing about Kubernetes is that is really easy to manage deploys and release cycles using either Kubernetes definitions (YAML or JSON) or Helm charts (a kind of deploy config on repositories) and you can even, with some tinkering around, use docker-compose files to do the deploys. It is also absurdly robust once correctly set up.<\/p>\n\n
The cons are that it is not an easy piece of software to manage (the internals) and deploy, thus needing a DevOps team taking care of it.<\/p>\n\n
\n \n \n My Conclusions\n<\/h3>\n\n
The key here is to understand where you are, if you are still preparing an MVP to launch and the only thing in your infrastructure is a webserver then you are better off with docker-compose and progressively go up.<\/p>\n\n
Also, if your Kubernetes will have more orchestrator services than services is orchestrating then you may be better off with Swarm.<\/p>\n\n
All I wanted with this is to make people think about the technologies they choose to use, accidental complexity carries a cost and it should not be taken lightly so don't let the hype get you.<\/p>\n\n","category":["kubernetes","devops","docker","hype"]},{"title":"You don't know TDD","pubDate":"Sun, 17 Mar 2019 16:20:22 +0000","link":"https:\/\/dev.to\/anortef\/you-dont-know-tdd-47a","guid":"https:\/\/dev.to\/anortef\/you-dont-know-tdd-47a","description":"
Okay, maybe you think you know what TDD is but let me tell you a story. <\/p>\n\n
Some years ago there was this young developer who thought that, even when she\/he had a lot to learn, she\/he at least got a pretty solid foundation. She\/He knew that coupling is bad and classes should be single responsibility and the methods inside the class should be also single responsibility in order to produce maintainable and extensible software. <\/p>\n\n
To this point, most of us can resonate with this story and laugh at ourselves for being that naive. Of course, we think we write decoupled code now but the truth is most developers don't know what TDD is and they write coupled code, less coupled that some years ago because of practice, but coupled none the less. Proof of that is on your companies repositories and how developers shudder every time they need to change something on the codebase. <\/p>\n\n
\n \n \n TDD is not Unit Testing but Unit Testing is TDD.\n<\/h2>\n\n
TDD, as the name implies, is the practice of developing software aided by tests. One of the tools are Unit Tests but if you only use those you get something like this:<\/p>\n\n
This adds elements to the status bar with the output of the scripts you put on its plugin folder. The project has lots of scripts that you can download but I prefer to use my own, like the one to see how much RAM I have consumed and another that shows how many dockers do I have running at the moment.<\/p>\n\n
\n \n \n Enpass<\/a>\n<\/h3>\n\nIt's a nice password manager that stores the vaults on your computer (with the option to sync using your own accounts on cloud providers) and runs on any major platform.<\/p>\n\n
\n \n \n Shuttle<\/a>\n<\/h3>\n\nA configurable ssh shortcuts that I mainly use to list and access my ~\/.ssh\/config.<\/p>\n\n
\n \n \n Bartender<\/a>\n<\/h3>\n\nFor when you have way too many icons on the status bar.<\/p>\n\n
\n \n \n Gifox<\/a>\n<\/h3>\n\nA nice tool to record the screen and make a gif with it, really useful to explain workflows in Jira.<\/p>\n\n
\n \n \n Terminal stuff\n<\/h1>\n\n\n \n \n iTerm<\/a>\n<\/h3>\n\nThe emulator that everyone should use.<\/p>\n\n
\n \n \n oh-my-zsh<\/a>\n<\/h3>\n\nOf course, you should use zsh with this to have plugins and themes.<\/p>\n\n
\n \n \n zsh-autosuggestions<\/a>\n<\/h3>\n\nThis is hands down my favorite plugin for zsh. It uses your history to suggest autocompletion.<\/p>\n\n
\n \n \n zsh-syntax-highlighting<\/a>\n<\/h3>\n\nIf the command you are writing is not in $PATH it shows in red otherwise in green.<\/p>\n\n
\n \n \n Shellcheck<\/a>\n<\/h3>\n\nA linter for shell scripts.<\/p>\n\n
\n \n \n VSCode extensions\n<\/h1>\n\n\n \n \n Bracket Pair Colorizer<\/a>\n<\/h3>\n\nIt uses different colors for different sets of brackets, it is extremely useful when you have gone a little wild with the if.<\/p>\n\n
\n \n \n Indent Rainbow<\/a>\n<\/h3>\n\nIt uses colors to show each column of indentation making very easy to fix indentation errors(looking at you YAML...).<\/p>\n\n
\n \n \n Code Coverage<\/a>\n<\/h3>\n\nTool to highlight lines not covered by unit tests.<\/p>\n\n
\n \n \n CodeMetrics<\/a>\n<\/h3>\n\nComputes complexity in TypeScript \/ JavaScript files.<\/p>\n\n
\n \n \n Docker<\/a>\n<\/h3>\n\nAdds syntax highlighting, commands, hover tips, and linting for Dockerfile and docker-compose files.<\/p>\n\n
\n \n \n Git Project Manager<\/a>\n<\/h3>\n\nIt allows you to change easily between git projects.<\/p>\n\n
\n \n \n Peacock<\/a>\n<\/h3>\n\nSubtly change the workspace color of your workspace. Ideal when you have multiple VS Code instances and you want to quickly identify which is which. This is probably one of my most used extensions. shootout to <\/p>\n
\n \n \n \n <\/div>\n <\/a>\n \n \nJohn Papa<\/a>Follow\n<\/h2>\n \n Husband, father, & Catholic enjoying life with my family. Working @ Microsoft. Disney fanatic, web and mobile developer<\/a>\n <\/div>\n <\/div>\n<\/div>\n\n\n\n \n \n Rest Client<\/a>\n<\/h3>\n\nA little and simple rest client inside VSCode.<\/p>\n\n
\n \n \n Settings Sync<\/a>\n<\/h3>\n\nSynchronize Settings, Snippets, Themes, File Icons, Launch, Keybindings, Workspaces, and Extensions Across Multiple Machines Using GitHub Gist.<\/p>\n\n
\n \n \n Trailing Spaces<\/a>\n<\/h3>\n\nHighlight trailing spaces.<\/p>\n\n","category":"productivity"},{"title":"Do you really need Kubernetes in your company\/startup?","pubDate":"Mon, 17 Jun 2019 10:37:00 +0000","link":"https:\/\/dev.to\/anortef\/do-you-really-need-kubernetes-in-your-company-startup-1ec0","guid":"https:\/\/dev.to\/anortef\/do-you-really-need-kubernetes-in-your-company-startup-1ec0","description":"
Let me start saying that I love Kubernetes, I even have a personal one for my things but I'm an experienced DevOps and it is in my spare time.<\/p>\n\n
Usually, you want the complexity of the technical solutions your company uses to increase on complexity accordingly to your needs.<\/p>\n\n
You may think: whoa! I need to have autodiscovery between my microservices, a load balancer for the HTTP API and everything must be declared as a code to be maintainable without a shady guy from Ops<\/em><\/p>\n\nAnd of course, you need that, especially the last part, but is really Kubernetes the only thing that can give you that?<\/p>\n\n
\n \n \n Docker-Compose<\/a>\n<\/h3>\n\nIts a tool written in Python that let you define environments using YAML.<\/p>\n\n
The good things about this are that you can use this to make and maintain the developer's local environment and If you have only one production server (very little startup) you can even use the same YAML files used to develop your solution to deploy it into the server.<\/p>\n\n
The bad thing is that it is not really designed to run on a cluster so you are limited to a one and only production machine.<\/p>\n\n
\n \n \n Docker Swarm<\/a>\n<\/h3>\n\nIt's a solution that comes with Docker and allows to manage several machines with Docker as one cluster.<\/p>\n\n
In essence, Swarm and Kubernetes do the same but are not the same. The good thing about Swarm is that you can reuse the same YAML files that you were using with docker-compose and, in the pipeline, add the scaling stuff they need on Swarm.
\nYou can use things like Traefik to manage the access and you can reuse it if you switch to Kubernetes later on.<\/p>\n\n
The only problem is that it lacks good observability when reaching a good size.<\/p>\n\n
\n \n \n Kubernetes<\/a>\n<\/h3>\n\nKubernetes is a generalist container orchestrator, therefore it doesn't deal with Docker concepts but with abstractions that represent concepts inside the ecosystem, like Pods.<\/p>\n\n
The good thing about Kubernetes is that is really easy to manage deploys and release cycles using either Kubernetes definitions (YAML or JSON) or Helm charts (a kind of deploy config on repositories) and you can even, with some tinkering around, use docker-compose files to do the deploys. It is also absurdly robust once correctly set up.<\/p>\n\n
The cons are that it is not an easy piece of software to manage (the internals) and deploy, thus needing a DevOps team taking care of it.<\/p>\n\n
\n \n \n My Conclusions\n<\/h3>\n\n
The key here is to understand where you are, if you are still preparing an MVP to launch and the only thing in your infrastructure is a webserver then you are better off with docker-compose and progressively go up.<\/p>\n\n
Also, if your Kubernetes will have more orchestrator services than services is orchestrating then you may be better off with Swarm.<\/p>\n\n
All I wanted with this is to make people think about the technologies they choose to use, accidental complexity carries a cost and it should not be taken lightly so don't let the hype get you.<\/p>\n\n","category":["kubernetes","devops","docker","hype"]},{"title":"You don't know TDD","pubDate":"Sun, 17 Mar 2019 16:20:22 +0000","link":"https:\/\/dev.to\/anortef\/you-dont-know-tdd-47a","guid":"https:\/\/dev.to\/anortef\/you-dont-know-tdd-47a","description":"
Okay, maybe you think you know what TDD is but let me tell you a story. <\/p>\n\n
Some years ago there was this young developer who thought that, even when she\/he had a lot to learn, she\/he at least got a pretty solid foundation. She\/He knew that coupling is bad and classes should be single responsibility and the methods inside the class should be also single responsibility in order to produce maintainable and extensible software. <\/p>\n\n
To this point, most of us can resonate with this story and laugh at ourselves for being that naive. Of course, we think we write decoupled code now but the truth is most developers don't know what TDD is and they write coupled code, less coupled that some years ago because of practice, but coupled none the less. Proof of that is on your companies repositories and how developers shudder every time they need to change something on the codebase. <\/p>\n\n
\n \n \n TDD is not Unit Testing but Unit Testing is TDD.\n<\/h2>\n\n
TDD, as the name implies, is the practice of developing software aided by tests. One of the tools are Unit Tests but if you only use those you get something like this:<\/p>\n\n
A configurable ssh shortcuts that I mainly use to list and access my ~\/.ssh\/config.<\/p>\n\n
\n \n \n Bartender<\/a>\n<\/h3>\n\nFor when you have way too many icons on the status bar.<\/p>\n\n
\n \n \n Gifox<\/a>\n<\/h3>\n\nA nice tool to record the screen and make a gif with it, really useful to explain workflows in Jira.<\/p>\n\n
\n \n \n Terminal stuff\n<\/h1>\n\n\n \n \n iTerm<\/a>\n<\/h3>\n\nThe emulator that everyone should use.<\/p>\n\n
\n \n \n oh-my-zsh<\/a>\n<\/h3>\n\nOf course, you should use zsh with this to have plugins and themes.<\/p>\n\n
\n \n \n zsh-autosuggestions<\/a>\n<\/h3>\n\nThis is hands down my favorite plugin for zsh. It uses your history to suggest autocompletion.<\/p>\n\n
\n \n \n zsh-syntax-highlighting<\/a>\n<\/h3>\n\nIf the command you are writing is not in $PATH it shows in red otherwise in green.<\/p>\n\n
\n \n \n Shellcheck<\/a>\n<\/h3>\n\nA linter for shell scripts.<\/p>\n\n
\n \n \n VSCode extensions\n<\/h1>\n\n\n \n \n Bracket Pair Colorizer<\/a>\n<\/h3>\n\nIt uses different colors for different sets of brackets, it is extremely useful when you have gone a little wild with the if.<\/p>\n\n
\n \n \n Indent Rainbow<\/a>\n<\/h3>\n\nIt uses colors to show each column of indentation making very easy to fix indentation errors(looking at you YAML...).<\/p>\n\n
\n \n \n Code Coverage<\/a>\n<\/h3>\n\nTool to highlight lines not covered by unit tests.<\/p>\n\n
\n \n \n CodeMetrics<\/a>\n<\/h3>\n\nComputes complexity in TypeScript \/ JavaScript files.<\/p>\n\n
\n \n \n Docker<\/a>\n<\/h3>\n\nAdds syntax highlighting, commands, hover tips, and linting for Dockerfile and docker-compose files.<\/p>\n\n
\n \n \n Git Project Manager<\/a>\n<\/h3>\n\nIt allows you to change easily between git projects.<\/p>\n\n
\n \n \n Peacock<\/a>\n<\/h3>\n\nSubtly change the workspace color of your workspace. Ideal when you have multiple VS Code instances and you want to quickly identify which is which. This is probably one of my most used extensions. shootout to <\/p>\n
\n \n \n \n <\/div>\n <\/a>\n \n \nJohn Papa<\/a>Follow\n<\/h2>\n \n Husband, father, & Catholic enjoying life with my family. Working @ Microsoft. Disney fanatic, web and mobile developer<\/a>\n <\/div>\n <\/div>\n<\/div>\n\n\n\n \n \n Rest Client<\/a>\n<\/h3>\n\nA little and simple rest client inside VSCode.<\/p>\n\n
\n \n \n Settings Sync<\/a>\n<\/h3>\n\nSynchronize Settings, Snippets, Themes, File Icons, Launch, Keybindings, Workspaces, and Extensions Across Multiple Machines Using GitHub Gist.<\/p>\n\n
\n \n \n Trailing Spaces<\/a>\n<\/h3>\n\nHighlight trailing spaces.<\/p>\n\n","category":"productivity"},{"title":"Do you really need Kubernetes in your company\/startup?","pubDate":"Mon, 17 Jun 2019 10:37:00 +0000","link":"https:\/\/dev.to\/anortef\/do-you-really-need-kubernetes-in-your-company-startup-1ec0","guid":"https:\/\/dev.to\/anortef\/do-you-really-need-kubernetes-in-your-company-startup-1ec0","description":"
Let me start saying that I love Kubernetes, I even have a personal one for my things but I'm an experienced DevOps and it is in my spare time.<\/p>\n\n
Usually, you want the complexity of the technical solutions your company uses to increase on complexity accordingly to your needs.<\/p>\n\n
You may think: whoa! I need to have autodiscovery between my microservices, a load balancer for the HTTP API and everything must be declared as a code to be maintainable without a shady guy from Ops<\/em><\/p>\n\nAnd of course, you need that, especially the last part, but is really Kubernetes the only thing that can give you that?<\/p>\n\n
\n \n \n Docker-Compose<\/a>\n<\/h3>\n\nIts a tool written in Python that let you define environments using YAML.<\/p>\n\n
The good things about this are that you can use this to make and maintain the developer's local environment and If you have only one production server (very little startup) you can even use the same YAML files used to develop your solution to deploy it into the server.<\/p>\n\n
The bad thing is that it is not really designed to run on a cluster so you are limited to a one and only production machine.<\/p>\n\n
\n \n \n Docker Swarm<\/a>\n<\/h3>\n\nIt's a solution that comes with Docker and allows to manage several machines with Docker as one cluster.<\/p>\n\n
In essence, Swarm and Kubernetes do the same but are not the same. The good thing about Swarm is that you can reuse the same YAML files that you were using with docker-compose and, in the pipeline, add the scaling stuff they need on Swarm.
\nYou can use things like Traefik to manage the access and you can reuse it if you switch to Kubernetes later on.<\/p>\n\n
The only problem is that it lacks good observability when reaching a good size.<\/p>\n\n
\n \n \n Kubernetes<\/a>\n<\/h3>\n\nKubernetes is a generalist container orchestrator, therefore it doesn't deal with Docker concepts but with abstractions that represent concepts inside the ecosystem, like Pods.<\/p>\n\n
The good thing about Kubernetes is that is really easy to manage deploys and release cycles using either Kubernetes definitions (YAML or JSON) or Helm charts (a kind of deploy config on repositories) and you can even, with some tinkering around, use docker-compose files to do the deploys. It is also absurdly robust once correctly set up.<\/p>\n\n
The cons are that it is not an easy piece of software to manage (the internals) and deploy, thus needing a DevOps team taking care of it.<\/p>\n\n
\n \n \n My Conclusions\n<\/h3>\n\n
The key here is to understand where you are, if you are still preparing an MVP to launch and the only thing in your infrastructure is a webserver then you are better off with docker-compose and progressively go up.<\/p>\n\n
Also, if your Kubernetes will have more orchestrator services than services is orchestrating then you may be better off with Swarm.<\/p>\n\n
All I wanted with this is to make people think about the technologies they choose to use, accidental complexity carries a cost and it should not be taken lightly so don't let the hype get you.<\/p>\n\n","category":["kubernetes","devops","docker","hype"]},{"title":"You don't know TDD","pubDate":"Sun, 17 Mar 2019 16:20:22 +0000","link":"https:\/\/dev.to\/anortef\/you-dont-know-tdd-47a","guid":"https:\/\/dev.to\/anortef\/you-dont-know-tdd-47a","description":"
Okay, maybe you think you know what TDD is but let me tell you a story. <\/p>\n\n
Some years ago there was this young developer who thought that, even when she\/he had a lot to learn, she\/he at least got a pretty solid foundation. She\/He knew that coupling is bad and classes should be single responsibility and the methods inside the class should be also single responsibility in order to produce maintainable and extensible software. <\/p>\n\n
To this point, most of us can resonate with this story and laugh at ourselves for being that naive. Of course, we think we write decoupled code now but the truth is most developers don't know what TDD is and they write coupled code, less coupled that some years ago because of practice, but coupled none the less. Proof of that is on your companies repositories and how developers shudder every time they need to change something on the codebase. <\/p>\n\n
\n \n \n TDD is not Unit Testing but Unit Testing is TDD.\n<\/h2>\n\n
TDD, as the name implies, is the practice of developing software aided by tests. One of the tools are Unit Tests but if you only use those you get something like this:<\/p>\n\n
A nice tool to record the screen and make a gif with it, really useful to explain workflows in Jira.<\/p>\n\n
\n \n \n Terminal stuff\n<\/h1>\n\n\n \n \n iTerm<\/a>\n<\/h3>\n\nThe emulator that everyone should use.<\/p>\n\n
\n \n \n oh-my-zsh<\/a>\n<\/h3>\n\nOf course, you should use zsh with this to have plugins and themes.<\/p>\n\n
\n \n \n zsh-autosuggestions<\/a>\n<\/h3>\n\nThis is hands down my favorite plugin for zsh. It uses your history to suggest autocompletion.<\/p>\n\n
\n \n \n zsh-syntax-highlighting<\/a>\n<\/h3>\n\nIf the command you are writing is not in $PATH it shows in red otherwise in green.<\/p>\n\n
\n \n \n Shellcheck<\/a>\n<\/h3>\n\nA linter for shell scripts.<\/p>\n\n
\n \n \n VSCode extensions\n<\/h1>\n\n\n \n \n Bracket Pair Colorizer<\/a>\n<\/h3>\n\nIt uses different colors for different sets of brackets, it is extremely useful when you have gone a little wild with the if.<\/p>\n\n
\n \n \n Indent Rainbow<\/a>\n<\/h3>\n\nIt uses colors to show each column of indentation making very easy to fix indentation errors(looking at you YAML...).<\/p>\n\n
\n \n \n Code Coverage<\/a>\n<\/h3>\n\nTool to highlight lines not covered by unit tests.<\/p>\n\n
\n \n \n CodeMetrics<\/a>\n<\/h3>\n\nComputes complexity in TypeScript \/ JavaScript files.<\/p>\n\n
\n \n \n Docker<\/a>\n<\/h3>\n\nAdds syntax highlighting, commands, hover tips, and linting for Dockerfile and docker-compose files.<\/p>\n\n
\n \n \n Git Project Manager<\/a>\n<\/h3>\n\nIt allows you to change easily between git projects.<\/p>\n\n
\n \n \n Peacock<\/a>\n<\/h3>\n\nSubtly change the workspace color of your workspace. Ideal when you have multiple VS Code instances and you want to quickly identify which is which. This is probably one of my most used extensions. shootout to <\/p>\n
\n \n \n \n <\/div>\n <\/a>\n \n \nJohn Papa<\/a>Follow\n<\/h2>\n \n Husband, father, & Catholic enjoying life with my family. Working @ Microsoft. Disney fanatic, web and mobile developer<\/a>\n <\/div>\n <\/div>\n<\/div>\n\n\n\n \n \n Rest Client<\/a>\n<\/h3>\n\nA little and simple rest client inside VSCode.<\/p>\n\n
\n \n \n Settings Sync<\/a>\n<\/h3>\n\nSynchronize Settings, Snippets, Themes, File Icons, Launch, Keybindings, Workspaces, and Extensions Across Multiple Machines Using GitHub Gist.<\/p>\n\n
\n \n \n Trailing Spaces<\/a>\n<\/h3>\n\nHighlight trailing spaces.<\/p>\n\n","category":"productivity"},{"title":"Do you really need Kubernetes in your company\/startup?","pubDate":"Mon, 17 Jun 2019 10:37:00 +0000","link":"https:\/\/dev.to\/anortef\/do-you-really-need-kubernetes-in-your-company-startup-1ec0","guid":"https:\/\/dev.to\/anortef\/do-you-really-need-kubernetes-in-your-company-startup-1ec0","description":"
Let me start saying that I love Kubernetes, I even have a personal one for my things but I'm an experienced DevOps and it is in my spare time.<\/p>\n\n
Usually, you want the complexity of the technical solutions your company uses to increase on complexity accordingly to your needs.<\/p>\n\n
You may think: whoa! I need to have autodiscovery between my microservices, a load balancer for the HTTP API and everything must be declared as a code to be maintainable without a shady guy from Ops<\/em><\/p>\n\nAnd of course, you need that, especially the last part, but is really Kubernetes the only thing that can give you that?<\/p>\n\n
\n \n \n Docker-Compose<\/a>\n<\/h3>\n\nIts a tool written in Python that let you define environments using YAML.<\/p>\n\n
The good things about this are that you can use this to make and maintain the developer's local environment and If you have only one production server (very little startup) you can even use the same YAML files used to develop your solution to deploy it into the server.<\/p>\n\n
The bad thing is that it is not really designed to run on a cluster so you are limited to a one and only production machine.<\/p>\n\n
\n \n \n Docker Swarm<\/a>\n<\/h3>\n\nIt's a solution that comes with Docker and allows to manage several machines with Docker as one cluster.<\/p>\n\n
In essence, Swarm and Kubernetes do the same but are not the same. The good thing about Swarm is that you can reuse the same YAML files that you were using with docker-compose and, in the pipeline, add the scaling stuff they need on Swarm.
\nYou can use things like Traefik to manage the access and you can reuse it if you switch to Kubernetes later on.<\/p>\n\n
The only problem is that it lacks good observability when reaching a good size.<\/p>\n\n
\n \n \n Kubernetes<\/a>\n<\/h3>\n\nKubernetes is a generalist container orchestrator, therefore it doesn't deal with Docker concepts but with abstractions that represent concepts inside the ecosystem, like Pods.<\/p>\n\n
The good thing about Kubernetes is that is really easy to manage deploys and release cycles using either Kubernetes definitions (YAML or JSON) or Helm charts (a kind of deploy config on repositories) and you can even, with some tinkering around, use docker-compose files to do the deploys. It is also absurdly robust once correctly set up.<\/p>\n\n
The cons are that it is not an easy piece of software to manage (the internals) and deploy, thus needing a DevOps team taking care of it.<\/p>\n\n
\n \n \n My Conclusions\n<\/h3>\n\n
The key here is to understand where you are, if you are still preparing an MVP to launch and the only thing in your infrastructure is a webserver then you are better off with docker-compose and progressively go up.<\/p>\n\n
Also, if your Kubernetes will have more orchestrator services than services is orchestrating then you may be better off with Swarm.<\/p>\n\n
All I wanted with this is to make people think about the technologies they choose to use, accidental complexity carries a cost and it should not be taken lightly so don't let the hype get you.<\/p>\n\n","category":["kubernetes","devops","docker","hype"]},{"title":"You don't know TDD","pubDate":"Sun, 17 Mar 2019 16:20:22 +0000","link":"https:\/\/dev.to\/anortef\/you-dont-know-tdd-47a","guid":"https:\/\/dev.to\/anortef\/you-dont-know-tdd-47a","description":"
Okay, maybe you think you know what TDD is but let me tell you a story. <\/p>\n\n
Some years ago there was this young developer who thought that, even when she\/he had a lot to learn, she\/he at least got a pretty solid foundation. She\/He knew that coupling is bad and classes should be single responsibility and the methods inside the class should be also single responsibility in order to produce maintainable and extensible software. <\/p>\n\n
To this point, most of us can resonate with this story and laugh at ourselves for being that naive. Of course, we think we write decoupled code now but the truth is most developers don't know what TDD is and they write coupled code, less coupled that some years ago because of practice, but coupled none the less. Proof of that is on your companies repositories and how developers shudder every time they need to change something on the codebase. <\/p>\n\n
\n \n \n TDD is not Unit Testing but Unit Testing is TDD.\n<\/h2>\n\n
TDD, as the name implies, is the practice of developing software aided by tests. One of the tools are Unit Tests but if you only use those you get something like this:<\/p>\n\n
The emulator that everyone should use.<\/p>\n\n
\n \n \n oh-my-zsh<\/a>\n<\/h3>\n\nOf course, you should use zsh with this to have plugins and themes.<\/p>\n\n
\n \n \n zsh-autosuggestions<\/a>\n<\/h3>\n\nThis is hands down my favorite plugin for zsh. It uses your history to suggest autocompletion.<\/p>\n\n
\n \n \n zsh-syntax-highlighting<\/a>\n<\/h3>\n\nIf the command you are writing is not in $PATH it shows in red otherwise in green.<\/p>\n\n
\n \n \n Shellcheck<\/a>\n<\/h3>\n\nA linter for shell scripts.<\/p>\n\n
\n \n \n VSCode extensions\n<\/h1>\n\n\n \n \n Bracket Pair Colorizer<\/a>\n<\/h3>\n\nIt uses different colors for different sets of brackets, it is extremely useful when you have gone a little wild with the if.<\/p>\n\n
\n \n \n Indent Rainbow<\/a>\n<\/h3>\n\nIt uses colors to show each column of indentation making very easy to fix indentation errors(looking at you YAML...).<\/p>\n\n
\n \n \n Code Coverage<\/a>\n<\/h3>\n\nTool to highlight lines not covered by unit tests.<\/p>\n\n
\n \n \n CodeMetrics<\/a>\n<\/h3>\n\nComputes complexity in TypeScript \/ JavaScript files.<\/p>\n\n
\n \n \n Docker<\/a>\n<\/h3>\n\nAdds syntax highlighting, commands, hover tips, and linting for Dockerfile and docker-compose files.<\/p>\n\n
\n \n \n Git Project Manager<\/a>\n<\/h3>\n\nIt allows you to change easily between git projects.<\/p>\n\n
\n \n \n Peacock<\/a>\n<\/h3>\n\nSubtly change the workspace color of your workspace. Ideal when you have multiple VS Code instances and you want to quickly identify which is which. This is probably one of my most used extensions. shootout to <\/p>\n
\n \n \n \n <\/div>\n <\/a>\n \n \nJohn Papa<\/a>Follow\n<\/h2>\n \n Husband, father, & Catholic enjoying life with my family. Working @ Microsoft. Disney fanatic, web and mobile developer<\/a>\n <\/div>\n <\/div>\n<\/div>\n\n\n\n \n \n Rest Client<\/a>\n<\/h3>\n\nA little and simple rest client inside VSCode.<\/p>\n\n
\n \n \n Settings Sync<\/a>\n<\/h3>\n\nSynchronize Settings, Snippets, Themes, File Icons, Launch, Keybindings, Workspaces, and Extensions Across Multiple Machines Using GitHub Gist.<\/p>\n\n
\n \n \n Trailing Spaces<\/a>\n<\/h3>\n\nHighlight trailing spaces.<\/p>\n\n","category":"productivity"},{"title":"Do you really need Kubernetes in your company\/startup?","pubDate":"Mon, 17 Jun 2019 10:37:00 +0000","link":"https:\/\/dev.to\/anortef\/do-you-really-need-kubernetes-in-your-company-startup-1ec0","guid":"https:\/\/dev.to\/anortef\/do-you-really-need-kubernetes-in-your-company-startup-1ec0","description":"
Let me start saying that I love Kubernetes, I even have a personal one for my things but I'm an experienced DevOps and it is in my spare time.<\/p>\n\n
Usually, you want the complexity of the technical solutions your company uses to increase on complexity accordingly to your needs.<\/p>\n\n
You may think: whoa! I need to have autodiscovery between my microservices, a load balancer for the HTTP API and everything must be declared as a code to be maintainable without a shady guy from Ops<\/em><\/p>\n\nAnd of course, you need that, especially the last part, but is really Kubernetes the only thing that can give you that?<\/p>\n\n
\n \n \n Docker-Compose<\/a>\n<\/h3>\n\nIts a tool written in Python that let you define environments using YAML.<\/p>\n\n
The good things about this are that you can use this to make and maintain the developer's local environment and If you have only one production server (very little startup) you can even use the same YAML files used to develop your solution to deploy it into the server.<\/p>\n\n
The bad thing is that it is not really designed to run on a cluster so you are limited to a one and only production machine.<\/p>\n\n
\n \n \n Docker Swarm<\/a>\n<\/h3>\n\nIt's a solution that comes with Docker and allows to manage several machines with Docker as one cluster.<\/p>\n\n
In essence, Swarm and Kubernetes do the same but are not the same. The good thing about Swarm is that you can reuse the same YAML files that you were using with docker-compose and, in the pipeline, add the scaling stuff they need on Swarm.
\nYou can use things like Traefik to manage the access and you can reuse it if you switch to Kubernetes later on.<\/p>\n\n
The only problem is that it lacks good observability when reaching a good size.<\/p>\n\n
\n \n \n Kubernetes<\/a>\n<\/h3>\n\nKubernetes is a generalist container orchestrator, therefore it doesn't deal with Docker concepts but with abstractions that represent concepts inside the ecosystem, like Pods.<\/p>\n\n
The good thing about Kubernetes is that is really easy to manage deploys and release cycles using either Kubernetes definitions (YAML or JSON) or Helm charts (a kind of deploy config on repositories) and you can even, with some tinkering around, use docker-compose files to do the deploys. It is also absurdly robust once correctly set up.<\/p>\n\n
The cons are that it is not an easy piece of software to manage (the internals) and deploy, thus needing a DevOps team taking care of it.<\/p>\n\n
\n \n \n My Conclusions\n<\/h3>\n\n
The key here is to understand where you are, if you are still preparing an MVP to launch and the only thing in your infrastructure is a webserver then you are better off with docker-compose and progressively go up.<\/p>\n\n
Also, if your Kubernetes will have more orchestrator services than services is orchestrating then you may be better off with Swarm.<\/p>\n\n
All I wanted with this is to make people think about the technologies they choose to use, accidental complexity carries a cost and it should not be taken lightly so don't let the hype get you.<\/p>\n\n","category":["kubernetes","devops","docker","hype"]},{"title":"You don't know TDD","pubDate":"Sun, 17 Mar 2019 16:20:22 +0000","link":"https:\/\/dev.to\/anortef\/you-dont-know-tdd-47a","guid":"https:\/\/dev.to\/anortef\/you-dont-know-tdd-47a","description":"
Okay, maybe you think you know what TDD is but let me tell you a story. <\/p>\n\n
Some years ago there was this young developer who thought that, even when she\/he had a lot to learn, she\/he at least got a pretty solid foundation. She\/He knew that coupling is bad and classes should be single responsibility and the methods inside the class should be also single responsibility in order to produce maintainable and extensible software. <\/p>\n\n
To this point, most of us can resonate with this story and laugh at ourselves for being that naive. Of course, we think we write decoupled code now but the truth is most developers don't know what TDD is and they write coupled code, less coupled that some years ago because of practice, but coupled none the less. Proof of that is on your companies repositories and how developers shudder every time they need to change something on the codebase. <\/p>\n\n
\n \n \n TDD is not Unit Testing but Unit Testing is TDD.\n<\/h2>\n\n
TDD, as the name implies, is the practice of developing software aided by tests. One of the tools are Unit Tests but if you only use those you get something like this:<\/p>\n\n
This is hands down my favorite plugin for zsh. It uses your history to suggest autocompletion.<\/p>\n\n
\n \n \n zsh-syntax-highlighting<\/a>\n<\/h3>\n\nIf the command you are writing is not in $PATH it shows in red otherwise in green.<\/p>\n\n
\n \n \n Shellcheck<\/a>\n<\/h3>\n\nA linter for shell scripts.<\/p>\n\n
\n \n \n VSCode extensions\n<\/h1>\n\n\n \n \n Bracket Pair Colorizer<\/a>\n<\/h3>\n\nIt uses different colors for different sets of brackets, it is extremely useful when you have gone a little wild with the if.<\/p>\n\n
\n \n \n Indent Rainbow<\/a>\n<\/h3>\n\nIt uses colors to show each column of indentation making very easy to fix indentation errors(looking at you YAML...).<\/p>\n\n
\n \n \n Code Coverage<\/a>\n<\/h3>\n\nTool to highlight lines not covered by unit tests.<\/p>\n\n
\n \n \n CodeMetrics<\/a>\n<\/h3>\n\nComputes complexity in TypeScript \/ JavaScript files.<\/p>\n\n
\n \n \n Docker<\/a>\n<\/h3>\n\nAdds syntax highlighting, commands, hover tips, and linting for Dockerfile and docker-compose files.<\/p>\n\n
\n \n \n Git Project Manager<\/a>\n<\/h3>\n\nIt allows you to change easily between git projects.<\/p>\n\n
\n \n \n Peacock<\/a>\n<\/h3>\n\nSubtly change the workspace color of your workspace. Ideal when you have multiple VS Code instances and you want to quickly identify which is which. This is probably one of my most used extensions. shootout to <\/p>\n
\n \n \n \n <\/div>\n <\/a>\n \n \nJohn Papa<\/a>Follow\n<\/h2>\n \n Husband, father, & Catholic enjoying life with my family. Working @ Microsoft. Disney fanatic, web and mobile developer<\/a>\n <\/div>\n <\/div>\n<\/div>\n\n\n\n \n \n Rest Client<\/a>\n<\/h3>\n\nA little and simple rest client inside VSCode.<\/p>\n\n
\n \n \n Settings Sync<\/a>\n<\/h3>\n\nSynchronize Settings, Snippets, Themes, File Icons, Launch, Keybindings, Workspaces, and Extensions Across Multiple Machines Using GitHub Gist.<\/p>\n\n
\n \n \n Trailing Spaces<\/a>\n<\/h3>\n\nHighlight trailing spaces.<\/p>\n\n","category":"productivity"},{"title":"Do you really need Kubernetes in your company\/startup?","pubDate":"Mon, 17 Jun 2019 10:37:00 +0000","link":"https:\/\/dev.to\/anortef\/do-you-really-need-kubernetes-in-your-company-startup-1ec0","guid":"https:\/\/dev.to\/anortef\/do-you-really-need-kubernetes-in-your-company-startup-1ec0","description":"
Let me start saying that I love Kubernetes, I even have a personal one for my things but I'm an experienced DevOps and it is in my spare time.<\/p>\n\n
Usually, you want the complexity of the technical solutions your company uses to increase on complexity accordingly to your needs.<\/p>\n\n
You may think: whoa! I need to have autodiscovery between my microservices, a load balancer for the HTTP API and everything must be declared as a code to be maintainable without a shady guy from Ops<\/em><\/p>\n\nAnd of course, you need that, especially the last part, but is really Kubernetes the only thing that can give you that?<\/p>\n\n
\n \n \n Docker-Compose<\/a>\n<\/h3>\n\nIts a tool written in Python that let you define environments using YAML.<\/p>\n\n
The good things about this are that you can use this to make and maintain the developer's local environment and If you have only one production server (very little startup) you can even use the same YAML files used to develop your solution to deploy it into the server.<\/p>\n\n
The bad thing is that it is not really designed to run on a cluster so you are limited to a one and only production machine.<\/p>\n\n
\n \n \n Docker Swarm<\/a>\n<\/h3>\n\nIt's a solution that comes with Docker and allows to manage several machines with Docker as one cluster.<\/p>\n\n
In essence, Swarm and Kubernetes do the same but are not the same. The good thing about Swarm is that you can reuse the same YAML files that you were using with docker-compose and, in the pipeline, add the scaling stuff they need on Swarm.
\nYou can use things like Traefik to manage the access and you can reuse it if you switch to Kubernetes later on.<\/p>\n\n
The only problem is that it lacks good observability when reaching a good size.<\/p>\n\n
\n \n \n Kubernetes<\/a>\n<\/h3>\n\nKubernetes is a generalist container orchestrator, therefore it doesn't deal with Docker concepts but with abstractions that represent concepts inside the ecosystem, like Pods.<\/p>\n\n
The good thing about Kubernetes is that is really easy to manage deploys and release cycles using either Kubernetes definitions (YAML or JSON) or Helm charts (a kind of deploy config on repositories) and you can even, with some tinkering around, use docker-compose files to do the deploys. It is also absurdly robust once correctly set up.<\/p>\n\n
The cons are that it is not an easy piece of software to manage (the internals) and deploy, thus needing a DevOps team taking care of it.<\/p>\n\n
\n \n \n My Conclusions\n<\/h3>\n\n
The key here is to understand where you are, if you are still preparing an MVP to launch and the only thing in your infrastructure is a webserver then you are better off with docker-compose and progressively go up.<\/p>\n\n
Also, if your Kubernetes will have more orchestrator services than services is orchestrating then you may be better off with Swarm.<\/p>\n\n
All I wanted with this is to make people think about the technologies they choose to use, accidental complexity carries a cost and it should not be taken lightly so don't let the hype get you.<\/p>\n\n","category":["kubernetes","devops","docker","hype"]},{"title":"You don't know TDD","pubDate":"Sun, 17 Mar 2019 16:20:22 +0000","link":"https:\/\/dev.to\/anortef\/you-dont-know-tdd-47a","guid":"https:\/\/dev.to\/anortef\/you-dont-know-tdd-47a","description":"
Okay, maybe you think you know what TDD is but let me tell you a story. <\/p>\n\n
Some years ago there was this young developer who thought that, even when she\/he had a lot to learn, she\/he at least got a pretty solid foundation. She\/He knew that coupling is bad and classes should be single responsibility and the methods inside the class should be also single responsibility in order to produce maintainable and extensible software. <\/p>\n\n
To this point, most of us can resonate with this story and laugh at ourselves for being that naive. Of course, we think we write decoupled code now but the truth is most developers don't know what TDD is and they write coupled code, less coupled that some years ago because of practice, but coupled none the less. Proof of that is on your companies repositories and how developers shudder every time they need to change something on the codebase. <\/p>\n\n
\n \n \n TDD is not Unit Testing but Unit Testing is TDD.\n<\/h2>\n\n
TDD, as the name implies, is the practice of developing software aided by tests. One of the tools are Unit Tests but if you only use those you get something like this:<\/p>\n\n
A linter for shell scripts.<\/p>\n\n
\n \n \n VSCode extensions\n<\/h1>\n\n\n \n \n Bracket Pair Colorizer<\/a>\n<\/h3>\n\nIt uses different colors for different sets of brackets, it is extremely useful when you have gone a little wild with the if.<\/p>\n\n
\n \n \n Indent Rainbow<\/a>\n<\/h3>\n\nIt uses colors to show each column of indentation making very easy to fix indentation errors(looking at you YAML...).<\/p>\n\n
\n \n \n Code Coverage<\/a>\n<\/h3>\n\nTool to highlight lines not covered by unit tests.<\/p>\n\n
\n \n \n CodeMetrics<\/a>\n<\/h3>\n\nComputes complexity in TypeScript \/ JavaScript files.<\/p>\n\n
\n \n \n Docker<\/a>\n<\/h3>\n\nAdds syntax highlighting, commands, hover tips, and linting for Dockerfile and docker-compose files.<\/p>\n\n
\n \n \n Git Project Manager<\/a>\n<\/h3>\n\nIt allows you to change easily between git projects.<\/p>\n\n
\n \n \n Peacock<\/a>\n<\/h3>\n\nSubtly change the workspace color of your workspace. Ideal when you have multiple VS Code instances and you want to quickly identify which is which. This is probably one of my most used extensions. shootout to <\/p>\n
\n \n \n \n <\/div>\n <\/a>\n \n \nJohn Papa<\/a>Follow\n<\/h2>\n \n Husband, father, & Catholic enjoying life with my family. Working @ Microsoft. Disney fanatic, web and mobile developer<\/a>\n <\/div>\n <\/div>\n<\/div>\n\n\n\n \n \n Rest Client<\/a>\n<\/h3>\n\nA little and simple rest client inside VSCode.<\/p>\n\n
\n \n \n Settings Sync<\/a>\n<\/h3>\n\nSynchronize Settings, Snippets, Themes, File Icons, Launch, Keybindings, Workspaces, and Extensions Across Multiple Machines Using GitHub Gist.<\/p>\n\n
\n \n \n Trailing Spaces<\/a>\n<\/h3>\n\nHighlight trailing spaces.<\/p>\n\n","category":"productivity"},{"title":"Do you really need Kubernetes in your company\/startup?","pubDate":"Mon, 17 Jun 2019 10:37:00 +0000","link":"https:\/\/dev.to\/anortef\/do-you-really-need-kubernetes-in-your-company-startup-1ec0","guid":"https:\/\/dev.to\/anortef\/do-you-really-need-kubernetes-in-your-company-startup-1ec0","description":"
Let me start saying that I love Kubernetes, I even have a personal one for my things but I'm an experienced DevOps and it is in my spare time.<\/p>\n\n
Usually, you want the complexity of the technical solutions your company uses to increase on complexity accordingly to your needs.<\/p>\n\n
You may think: whoa! I need to have autodiscovery between my microservices, a load balancer for the HTTP API and everything must be declared as a code to be maintainable without a shady guy from Ops<\/em><\/p>\n\nAnd of course, you need that, especially the last part, but is really Kubernetes the only thing that can give you that?<\/p>\n\n
\n \n \n Docker-Compose<\/a>\n<\/h3>\n\nIts a tool written in Python that let you define environments using YAML.<\/p>\n\n
The good things about this are that you can use this to make and maintain the developer's local environment and If you have only one production server (very little startup) you can even use the same YAML files used to develop your solution to deploy it into the server.<\/p>\n\n
The bad thing is that it is not really designed to run on a cluster so you are limited to a one and only production machine.<\/p>\n\n
\n \n \n Docker Swarm<\/a>\n<\/h3>\n\nIt's a solution that comes with Docker and allows to manage several machines with Docker as one cluster.<\/p>\n\n
In essence, Swarm and Kubernetes do the same but are not the same. The good thing about Swarm is that you can reuse the same YAML files that you were using with docker-compose and, in the pipeline, add the scaling stuff they need on Swarm.
\nYou can use things like Traefik to manage the access and you can reuse it if you switch to Kubernetes later on.<\/p>\n\n
The only problem is that it lacks good observability when reaching a good size.<\/p>\n\n
\n \n \n Kubernetes<\/a>\n<\/h3>\n\nKubernetes is a generalist container orchestrator, therefore it doesn't deal with Docker concepts but with abstractions that represent concepts inside the ecosystem, like Pods.<\/p>\n\n
The good thing about Kubernetes is that is really easy to manage deploys and release cycles using either Kubernetes definitions (YAML or JSON) or Helm charts (a kind of deploy config on repositories) and you can even, with some tinkering around, use docker-compose files to do the deploys. It is also absurdly robust once correctly set up.<\/p>\n\n
The cons are that it is not an easy piece of software to manage (the internals) and deploy, thus needing a DevOps team taking care of it.<\/p>\n\n
\n \n \n My Conclusions\n<\/h3>\n\n
The key here is to understand where you are, if you are still preparing an MVP to launch and the only thing in your infrastructure is a webserver then you are better off with docker-compose and progressively go up.<\/p>\n\n
Also, if your Kubernetes will have more orchestrator services than services is orchestrating then you may be better off with Swarm.<\/p>\n\n
All I wanted with this is to make people think about the technologies they choose to use, accidental complexity carries a cost and it should not be taken lightly so don't let the hype get you.<\/p>\n\n","category":["kubernetes","devops","docker","hype"]},{"title":"You don't know TDD","pubDate":"Sun, 17 Mar 2019 16:20:22 +0000","link":"https:\/\/dev.to\/anortef\/you-dont-know-tdd-47a","guid":"https:\/\/dev.to\/anortef\/you-dont-know-tdd-47a","description":"
Okay, maybe you think you know what TDD is but let me tell you a story. <\/p>\n\n
Some years ago there was this young developer who thought that, even when she\/he had a lot to learn, she\/he at least got a pretty solid foundation. She\/He knew that coupling is bad and classes should be single responsibility and the methods inside the class should be also single responsibility in order to produce maintainable and extensible software. <\/p>\n\n
To this point, most of us can resonate with this story and laugh at ourselves for being that naive. Of course, we think we write decoupled code now but the truth is most developers don't know what TDD is and they write coupled code, less coupled that some years ago because of practice, but coupled none the less. Proof of that is on your companies repositories and how developers shudder every time they need to change something on the codebase. <\/p>\n\n
\n \n \n TDD is not Unit Testing but Unit Testing is TDD.\n<\/h2>\n\n
TDD, as the name implies, is the practice of developing software aided by tests. One of the tools are Unit Tests but if you only use those you get something like this:<\/p>\n\n
It uses different colors for different sets of brackets, it is extremely useful when you have gone a little wild with the if.<\/p>\n\n
\n \n \n Indent Rainbow<\/a>\n<\/h3>\n\nIt uses colors to show each column of indentation making very easy to fix indentation errors(looking at you YAML...).<\/p>\n\n
\n \n \n Code Coverage<\/a>\n<\/h3>\n\nTool to highlight lines not covered by unit tests.<\/p>\n\n
\n \n \n CodeMetrics<\/a>\n<\/h3>\n\nComputes complexity in TypeScript \/ JavaScript files.<\/p>\n\n
\n \n \n Docker<\/a>\n<\/h3>\n\nAdds syntax highlighting, commands, hover tips, and linting for Dockerfile and docker-compose files.<\/p>\n\n
\n \n \n Git Project Manager<\/a>\n<\/h3>\n\nIt allows you to change easily between git projects.<\/p>\n\n
\n \n \n Peacock<\/a>\n<\/h3>\n\nSubtly change the workspace color of your workspace. Ideal when you have multiple VS Code instances and you want to quickly identify which is which. This is probably one of my most used extensions. shootout to <\/p>\n
\n \n \n \n <\/div>\n <\/a>\n \n \nJohn Papa<\/a>Follow\n<\/h2>\n \n Husband, father, & Catholic enjoying life with my family. Working @ Microsoft. Disney fanatic, web and mobile developer<\/a>\n <\/div>\n <\/div>\n<\/div>\n\n\n\n \n \n Rest Client<\/a>\n<\/h3>\n\nA little and simple rest client inside VSCode.<\/p>\n\n
\n \n \n Settings Sync<\/a>\n<\/h3>\n\nSynchronize Settings, Snippets, Themes, File Icons, Launch, Keybindings, Workspaces, and Extensions Across Multiple Machines Using GitHub Gist.<\/p>\n\n
\n \n \n Trailing Spaces<\/a>\n<\/h3>\n\nHighlight trailing spaces.<\/p>\n\n","category":"productivity"},{"title":"Do you really need Kubernetes in your company\/startup?","pubDate":"Mon, 17 Jun 2019 10:37:00 +0000","link":"https:\/\/dev.to\/anortef\/do-you-really-need-kubernetes-in-your-company-startup-1ec0","guid":"https:\/\/dev.to\/anortef\/do-you-really-need-kubernetes-in-your-company-startup-1ec0","description":"
Let me start saying that I love Kubernetes, I even have a personal one for my things but I'm an experienced DevOps and it is in my spare time.<\/p>\n\n
Usually, you want the complexity of the technical solutions your company uses to increase on complexity accordingly to your needs.<\/p>\n\n
You may think: whoa! I need to have autodiscovery between my microservices, a load balancer for the HTTP API and everything must be declared as a code to be maintainable without a shady guy from Ops<\/em><\/p>\n\nAnd of course, you need that, especially the last part, but is really Kubernetes the only thing that can give you that?<\/p>\n\n
\n \n \n Docker-Compose<\/a>\n<\/h3>\n\nIts a tool written in Python that let you define environments using YAML.<\/p>\n\n
The good things about this are that you can use this to make and maintain the developer's local environment and If you have only one production server (very little startup) you can even use the same YAML files used to develop your solution to deploy it into the server.<\/p>\n\n
The bad thing is that it is not really designed to run on a cluster so you are limited to a one and only production machine.<\/p>\n\n
\n \n \n Docker Swarm<\/a>\n<\/h3>\n\nIt's a solution that comes with Docker and allows to manage several machines with Docker as one cluster.<\/p>\n\n
In essence, Swarm and Kubernetes do the same but are not the same. The good thing about Swarm is that you can reuse the same YAML files that you were using with docker-compose and, in the pipeline, add the scaling stuff they need on Swarm.
\nYou can use things like Traefik to manage the access and you can reuse it if you switch to Kubernetes later on.<\/p>\n\n
The only problem is that it lacks good observability when reaching a good size.<\/p>\n\n
\n \n \n Kubernetes<\/a>\n<\/h3>\n\nKubernetes is a generalist container orchestrator, therefore it doesn't deal with Docker concepts but with abstractions that represent concepts inside the ecosystem, like Pods.<\/p>\n\n
The good thing about Kubernetes is that is really easy to manage deploys and release cycles using either Kubernetes definitions (YAML or JSON) or Helm charts (a kind of deploy config on repositories) and you can even, with some tinkering around, use docker-compose files to do the deploys. It is also absurdly robust once correctly set up.<\/p>\n\n
The cons are that it is not an easy piece of software to manage (the internals) and deploy, thus needing a DevOps team taking care of it.<\/p>\n\n
\n \n \n My Conclusions\n<\/h3>\n\n
The key here is to understand where you are, if you are still preparing an MVP to launch and the only thing in your infrastructure is a webserver then you are better off with docker-compose and progressively go up.<\/p>\n\n
Also, if your Kubernetes will have more orchestrator services than services is orchestrating then you may be better off with Swarm.<\/p>\n\n
All I wanted with this is to make people think about the technologies they choose to use, accidental complexity carries a cost and it should not be taken lightly so don't let the hype get you.<\/p>\n\n","category":["kubernetes","devops","docker","hype"]},{"title":"You don't know TDD","pubDate":"Sun, 17 Mar 2019 16:20:22 +0000","link":"https:\/\/dev.to\/anortef\/you-dont-know-tdd-47a","guid":"https:\/\/dev.to\/anortef\/you-dont-know-tdd-47a","description":"
Okay, maybe you think you know what TDD is but let me tell you a story. <\/p>\n\n
Some years ago there was this young developer who thought that, even when she\/he had a lot to learn, she\/he at least got a pretty solid foundation. She\/He knew that coupling is bad and classes should be single responsibility and the methods inside the class should be also single responsibility in order to produce maintainable and extensible software. <\/p>\n\n
To this point, most of us can resonate with this story and laugh at ourselves for being that naive. Of course, we think we write decoupled code now but the truth is most developers don't know what TDD is and they write coupled code, less coupled that some years ago because of practice, but coupled none the less. Proof of that is on your companies repositories and how developers shudder every time they need to change something on the codebase. <\/p>\n\n
\n \n \n TDD is not Unit Testing but Unit Testing is TDD.\n<\/h2>\n\n
TDD, as the name implies, is the practice of developing software aided by tests. One of the tools are Unit Tests but if you only use those you get something like this:<\/p>\n\n
Tool to highlight lines not covered by unit tests.<\/p>\n\n
\n \n \n CodeMetrics<\/a>\n<\/h3>\n\nComputes complexity in TypeScript \/ JavaScript files.<\/p>\n\n
\n \n \n Docker<\/a>\n<\/h3>\n\nAdds syntax highlighting, commands, hover tips, and linting for Dockerfile and docker-compose files.<\/p>\n\n
\n \n \n Git Project Manager<\/a>\n<\/h3>\n\nIt allows you to change easily between git projects.<\/p>\n\n
\n \n \n Peacock<\/a>\n<\/h3>\n\nSubtly change the workspace color of your workspace. Ideal when you have multiple VS Code instances and you want to quickly identify which is which. This is probably one of my most used extensions. shootout to <\/p>\n
\n \n \n \n <\/div>\n <\/a>\n \n \nJohn Papa<\/a>Follow\n<\/h2>\n \n Husband, father, & Catholic enjoying life with my family. Working @ Microsoft. Disney fanatic, web and mobile developer<\/a>\n <\/div>\n <\/div>\n<\/div>\n\n\n\n \n \n Rest Client<\/a>\n<\/h3>\n\nA little and simple rest client inside VSCode.<\/p>\n\n
\n \n \n Settings Sync<\/a>\n<\/h3>\n\nSynchronize Settings, Snippets, Themes, File Icons, Launch, Keybindings, Workspaces, and Extensions Across Multiple Machines Using GitHub Gist.<\/p>\n\n
\n \n \n Trailing Spaces<\/a>\n<\/h3>\n\nHighlight trailing spaces.<\/p>\n\n","category":"productivity"},{"title":"Do you really need Kubernetes in your company\/startup?","pubDate":"Mon, 17 Jun 2019 10:37:00 +0000","link":"https:\/\/dev.to\/anortef\/do-you-really-need-kubernetes-in-your-company-startup-1ec0","guid":"https:\/\/dev.to\/anortef\/do-you-really-need-kubernetes-in-your-company-startup-1ec0","description":"
Let me start saying that I love Kubernetes, I even have a personal one for my things but I'm an experienced DevOps and it is in my spare time.<\/p>\n\n
Usually, you want the complexity of the technical solutions your company uses to increase on complexity accordingly to your needs.<\/p>\n\n
You may think: whoa! I need to have autodiscovery between my microservices, a load balancer for the HTTP API and everything must be declared as a code to be maintainable without a shady guy from Ops<\/em><\/p>\n\nAnd of course, you need that, especially the last part, but is really Kubernetes the only thing that can give you that?<\/p>\n\n
\n \n \n Docker-Compose<\/a>\n<\/h3>\n\nIts a tool written in Python that let you define environments using YAML.<\/p>\n\n
The good things about this are that you can use this to make and maintain the developer's local environment and If you have only one production server (very little startup) you can even use the same YAML files used to develop your solution to deploy it into the server.<\/p>\n\n
The bad thing is that it is not really designed to run on a cluster so you are limited to a one and only production machine.<\/p>\n\n
\n \n \n Docker Swarm<\/a>\n<\/h3>\n\nIt's a solution that comes with Docker and allows to manage several machines with Docker as one cluster.<\/p>\n\n
In essence, Swarm and Kubernetes do the same but are not the same. The good thing about Swarm is that you can reuse the same YAML files that you were using with docker-compose and, in the pipeline, add the scaling stuff they need on Swarm.
\nYou can use things like Traefik to manage the access and you can reuse it if you switch to Kubernetes later on.<\/p>\n\n
The only problem is that it lacks good observability when reaching a good size.<\/p>\n\n
\n \n \n Kubernetes<\/a>\n<\/h3>\n\nKubernetes is a generalist container orchestrator, therefore it doesn't deal with Docker concepts but with abstractions that represent concepts inside the ecosystem, like Pods.<\/p>\n\n
The good thing about Kubernetes is that is really easy to manage deploys and release cycles using either Kubernetes definitions (YAML or JSON) or Helm charts (a kind of deploy config on repositories) and you can even, with some tinkering around, use docker-compose files to do the deploys. It is also absurdly robust once correctly set up.<\/p>\n\n
The cons are that it is not an easy piece of software to manage (the internals) and deploy, thus needing a DevOps team taking care of it.<\/p>\n\n
\n \n \n My Conclusions\n<\/h3>\n\n
The key here is to understand where you are, if you are still preparing an MVP to launch and the only thing in your infrastructure is a webserver then you are better off with docker-compose and progressively go up.<\/p>\n\n
Also, if your Kubernetes will have more orchestrator services than services is orchestrating then you may be better off with Swarm.<\/p>\n\n
All I wanted with this is to make people think about the technologies they choose to use, accidental complexity carries a cost and it should not be taken lightly so don't let the hype get you.<\/p>\n\n","category":["kubernetes","devops","docker","hype"]},{"title":"You don't know TDD","pubDate":"Sun, 17 Mar 2019 16:20:22 +0000","link":"https:\/\/dev.to\/anortef\/you-dont-know-tdd-47a","guid":"https:\/\/dev.to\/anortef\/you-dont-know-tdd-47a","description":"
Okay, maybe you think you know what TDD is but let me tell you a story. <\/p>\n\n
Some years ago there was this young developer who thought that, even when she\/he had a lot to learn, she\/he at least got a pretty solid foundation. She\/He knew that coupling is bad and classes should be single responsibility and the methods inside the class should be also single responsibility in order to produce maintainable and extensible software. <\/p>\n\n
To this point, most of us can resonate with this story and laugh at ourselves for being that naive. Of course, we think we write decoupled code now but the truth is most developers don't know what TDD is and they write coupled code, less coupled that some years ago because of practice, but coupled none the less. Proof of that is on your companies repositories and how developers shudder every time they need to change something on the codebase. <\/p>\n\n
\n \n \n TDD is not Unit Testing but Unit Testing is TDD.\n<\/h2>\n\n
TDD, as the name implies, is the practice of developing software aided by tests. One of the tools are Unit Tests but if you only use those you get something like this:<\/p>\n\n
Adds syntax highlighting, commands, hover tips, and linting for Dockerfile and docker-compose files.<\/p>\n\n
\n \n \n Git Project Manager<\/a>\n<\/h3>\n\nIt allows you to change easily between git projects.<\/p>\n\n
\n \n \n Peacock<\/a>\n<\/h3>\n\nSubtly change the workspace color of your workspace. Ideal when you have multiple VS Code instances and you want to quickly identify which is which. This is probably one of my most used extensions. shootout to <\/p>\n
\n \n \n \n <\/div>\n <\/a>\n \n \nJohn Papa<\/a>Follow\n<\/h2>\n \n Husband, father, & Catholic enjoying life with my family. Working @ Microsoft. Disney fanatic, web and mobile developer<\/a>\n <\/div>\n <\/div>\n<\/div>\n\n\n\n \n \n Rest Client<\/a>\n<\/h3>\n\nA little and simple rest client inside VSCode.<\/p>\n\n
\n \n \n Settings Sync<\/a>\n<\/h3>\n\nSynchronize Settings, Snippets, Themes, File Icons, Launch, Keybindings, Workspaces, and Extensions Across Multiple Machines Using GitHub Gist.<\/p>\n\n
\n \n \n Trailing Spaces<\/a>\n<\/h3>\n\nHighlight trailing spaces.<\/p>\n\n","category":"productivity"},{"title":"Do you really need Kubernetes in your company\/startup?","pubDate":"Mon, 17 Jun 2019 10:37:00 +0000","link":"https:\/\/dev.to\/anortef\/do-you-really-need-kubernetes-in-your-company-startup-1ec0","guid":"https:\/\/dev.to\/anortef\/do-you-really-need-kubernetes-in-your-company-startup-1ec0","description":"
Let me start saying that I love Kubernetes, I even have a personal one for my things but I'm an experienced DevOps and it is in my spare time.<\/p>\n\n
Usually, you want the complexity of the technical solutions your company uses to increase on complexity accordingly to your needs.<\/p>\n\n
You may think: whoa! I need to have autodiscovery between my microservices, a load balancer for the HTTP API and everything must be declared as a code to be maintainable without a shady guy from Ops<\/em><\/p>\n\nAnd of course, you need that, especially the last part, but is really Kubernetes the only thing that can give you that?<\/p>\n\n
\n \n \n Docker-Compose<\/a>\n<\/h3>\n\nIts a tool written in Python that let you define environments using YAML.<\/p>\n\n
The good things about this are that you can use this to make and maintain the developer's local environment and If you have only one production server (very little startup) you can even use the same YAML files used to develop your solution to deploy it into the server.<\/p>\n\n
The bad thing is that it is not really designed to run on a cluster so you are limited to a one and only production machine.<\/p>\n\n
\n \n \n Docker Swarm<\/a>\n<\/h3>\n\nIt's a solution that comes with Docker and allows to manage several machines with Docker as one cluster.<\/p>\n\n
In essence, Swarm and Kubernetes do the same but are not the same. The good thing about Swarm is that you can reuse the same YAML files that you were using with docker-compose and, in the pipeline, add the scaling stuff they need on Swarm.
\nYou can use things like Traefik to manage the access and you can reuse it if you switch to Kubernetes later on.<\/p>\n\n
The only problem is that it lacks good observability when reaching a good size.<\/p>\n\n
\n \n \n Kubernetes<\/a>\n<\/h3>\n\nKubernetes is a generalist container orchestrator, therefore it doesn't deal with Docker concepts but with abstractions that represent concepts inside the ecosystem, like Pods.<\/p>\n\n
The good thing about Kubernetes is that is really easy to manage deploys and release cycles using either Kubernetes definitions (YAML or JSON) or Helm charts (a kind of deploy config on repositories) and you can even, with some tinkering around, use docker-compose files to do the deploys. It is also absurdly robust once correctly set up.<\/p>\n\n
The cons are that it is not an easy piece of software to manage (the internals) and deploy, thus needing a DevOps team taking care of it.<\/p>\n\n
\n \n \n My Conclusions\n<\/h3>\n\n
The key here is to understand where you are, if you are still preparing an MVP to launch and the only thing in your infrastructure is a webserver then you are better off with docker-compose and progressively go up.<\/p>\n\n
Also, if your Kubernetes will have more orchestrator services than services is orchestrating then you may be better off with Swarm.<\/p>\n\n
All I wanted with this is to make people think about the technologies they choose to use, accidental complexity carries a cost and it should not be taken lightly so don't let the hype get you.<\/p>\n\n","category":["kubernetes","devops","docker","hype"]},{"title":"You don't know TDD","pubDate":"Sun, 17 Mar 2019 16:20:22 +0000","link":"https:\/\/dev.to\/anortef\/you-dont-know-tdd-47a","guid":"https:\/\/dev.to\/anortef\/you-dont-know-tdd-47a","description":"
Okay, maybe you think you know what TDD is but let me tell you a story. <\/p>\n\n
Some years ago there was this young developer who thought that, even when she\/he had a lot to learn, she\/he at least got a pretty solid foundation. She\/He knew that coupling is bad and classes should be single responsibility and the methods inside the class should be also single responsibility in order to produce maintainable and extensible software. <\/p>\n\n
To this point, most of us can resonate with this story and laugh at ourselves for being that naive. Of course, we think we write decoupled code now but the truth is most developers don't know what TDD is and they write coupled code, less coupled that some years ago because of practice, but coupled none the less. Proof of that is on your companies repositories and how developers shudder every time they need to change something on the codebase. <\/p>\n\n
\n \n \n TDD is not Unit Testing but Unit Testing is TDD.\n<\/h2>\n\n
TDD, as the name implies, is the practice of developing software aided by tests. One of the tools are Unit Tests but if you only use those you get something like this:<\/p>\n\n
Subtly change the workspace color of your workspace. Ideal when you have multiple VS Code instances and you want to quickly identify which is which. This is probably one of my most used extensions. shootout to <\/p>\n
\n <\/div>\n <\/a>\n \nJohn Papa<\/a>Follow\n<\/h2>\n \n Husband, father, & Catholic enjoying life with my family. Working @ Microsoft. Disney fanatic, web and mobile developer<\/a>\n <\/div>\n <\/div>\n<\/div>\n\n\n\n \n \n Rest Client<\/a>\n<\/h3>\n\nA little and simple rest client inside VSCode.<\/p>\n\n
\n \n \n Settings Sync<\/a>\n<\/h3>\n\nSynchronize Settings, Snippets, Themes, File Icons, Launch, Keybindings, Workspaces, and Extensions Across Multiple Machines Using GitHub Gist.<\/p>\n\n
\n \n \n Trailing Spaces<\/a>\n<\/h3>\n\nHighlight trailing spaces.<\/p>\n\n","category":"productivity"},{"title":"Do you really need Kubernetes in your company\/startup?","pubDate":"Mon, 17 Jun 2019 10:37:00 +0000","link":"https:\/\/dev.to\/anortef\/do-you-really-need-kubernetes-in-your-company-startup-1ec0","guid":"https:\/\/dev.to\/anortef\/do-you-really-need-kubernetes-in-your-company-startup-1ec0","description":"
Let me start saying that I love Kubernetes, I even have a personal one for my things but I'm an experienced DevOps and it is in my spare time.<\/p>\n\n
Usually, you want the complexity of the technical solutions your company uses to increase on complexity accordingly to your needs.<\/p>\n\n
You may think: whoa! I need to have autodiscovery between my microservices, a load balancer for the HTTP API and everything must be declared as a code to be maintainable without a shady guy from Ops<\/em><\/p>\n\nAnd of course, you need that, especially the last part, but is really Kubernetes the only thing that can give you that?<\/p>\n\n
\n \n \n Docker-Compose<\/a>\n<\/h3>\n\nIts a tool written in Python that let you define environments using YAML.<\/p>\n\n
The good things about this are that you can use this to make and maintain the developer's local environment and If you have only one production server (very little startup) you can even use the same YAML files used to develop your solution to deploy it into the server.<\/p>\n\n
The bad thing is that it is not really designed to run on a cluster so you are limited to a one and only production machine.<\/p>\n\n
\n \n \n Docker Swarm<\/a>\n<\/h3>\n\nIt's a solution that comes with Docker and allows to manage several machines with Docker as one cluster.<\/p>\n\n
In essence, Swarm and Kubernetes do the same but are not the same. The good thing about Swarm is that you can reuse the same YAML files that you were using with docker-compose and, in the pipeline, add the scaling stuff they need on Swarm.
\nYou can use things like Traefik to manage the access and you can reuse it if you switch to Kubernetes later on.<\/p>\n\n
The only problem is that it lacks good observability when reaching a good size.<\/p>\n\n
\n \n \n Kubernetes<\/a>\n<\/h3>\n\nKubernetes is a generalist container orchestrator, therefore it doesn't deal with Docker concepts but with abstractions that represent concepts inside the ecosystem, like Pods.<\/p>\n\n
The good thing about Kubernetes is that is really easy to manage deploys and release cycles using either Kubernetes definitions (YAML or JSON) or Helm charts (a kind of deploy config on repositories) and you can even, with some tinkering around, use docker-compose files to do the deploys. It is also absurdly robust once correctly set up.<\/p>\n\n
The cons are that it is not an easy piece of software to manage (the internals) and deploy, thus needing a DevOps team taking care of it.<\/p>\n\n
\n \n \n My Conclusions\n<\/h3>\n\n
The key here is to understand where you are, if you are still preparing an MVP to launch and the only thing in your infrastructure is a webserver then you are better off with docker-compose and progressively go up.<\/p>\n\n
Also, if your Kubernetes will have more orchestrator services than services is orchestrating then you may be better off with Swarm.<\/p>\n\n
All I wanted with this is to make people think about the technologies they choose to use, accidental complexity carries a cost and it should not be taken lightly so don't let the hype get you.<\/p>\n\n","category":["kubernetes","devops","docker","hype"]},{"title":"You don't know TDD","pubDate":"Sun, 17 Mar 2019 16:20:22 +0000","link":"https:\/\/dev.to\/anortef\/you-dont-know-tdd-47a","guid":"https:\/\/dev.to\/anortef\/you-dont-know-tdd-47a","description":"
Okay, maybe you think you know what TDD is but let me tell you a story. <\/p>\n\n
Some years ago there was this young developer who thought that, even when she\/he had a lot to learn, she\/he at least got a pretty solid foundation. She\/He knew that coupling is bad and classes should be single responsibility and the methods inside the class should be also single responsibility in order to produce maintainable and extensible software. <\/p>\n\n
To this point, most of us can resonate with this story and laugh at ourselves for being that naive. Of course, we think we write decoupled code now but the truth is most developers don't know what TDD is and they write coupled code, less coupled that some years ago because of practice, but coupled none the less. Proof of that is on your companies repositories and how developers shudder every time they need to change something on the codebase. <\/p>\n\n
\n \n \n TDD is not Unit Testing but Unit Testing is TDD.\n<\/h2>\n\n
TDD, as the name implies, is the practice of developing software aided by tests. One of the tools are Unit Tests but if you only use those you get something like this:<\/p>\n\n
\n \n \n Rest Client<\/a>\n<\/h3>\n\nA little and simple rest client inside VSCode.<\/p>\n\n
\n \n \n Settings Sync<\/a>\n<\/h3>\n\nSynchronize Settings, Snippets, Themes, File Icons, Launch, Keybindings, Workspaces, and Extensions Across Multiple Machines Using GitHub Gist.<\/p>\n\n
\n \n \n Trailing Spaces<\/a>\n<\/h3>\n\nHighlight trailing spaces.<\/p>\n\n","category":"productivity"},{"title":"Do you really need Kubernetes in your company\/startup?","pubDate":"Mon, 17 Jun 2019 10:37:00 +0000","link":"https:\/\/dev.to\/anortef\/do-you-really-need-kubernetes-in-your-company-startup-1ec0","guid":"https:\/\/dev.to\/anortef\/do-you-really-need-kubernetes-in-your-company-startup-1ec0","description":"
Let me start saying that I love Kubernetes, I even have a personal one for my things but I'm an experienced DevOps and it is in my spare time.<\/p>\n\n
Usually, you want the complexity of the technical solutions your company uses to increase on complexity accordingly to your needs.<\/p>\n\n
You may think: whoa! I need to have autodiscovery between my microservices, a load balancer for the HTTP API and everything must be declared as a code to be maintainable without a shady guy from Ops<\/em><\/p>\n\nAnd of course, you need that, especially the last part, but is really Kubernetes the only thing that can give you that?<\/p>\n\n
\n \n \n Docker-Compose<\/a>\n<\/h3>\n\nIts a tool written in Python that let you define environments using YAML.<\/p>\n\n
The good things about this are that you can use this to make and maintain the developer's local environment and If you have only one production server (very little startup) you can even use the same YAML files used to develop your solution to deploy it into the server.<\/p>\n\n
The bad thing is that it is not really designed to run on a cluster so you are limited to a one and only production machine.<\/p>\n\n
\n \n \n Docker Swarm<\/a>\n<\/h3>\n\nIt's a solution that comes with Docker and allows to manage several machines with Docker as one cluster.<\/p>\n\n
In essence, Swarm and Kubernetes do the same but are not the same. The good thing about Swarm is that you can reuse the same YAML files that you were using with docker-compose and, in the pipeline, add the scaling stuff they need on Swarm.
\nYou can use things like Traefik to manage the access and you can reuse it if you switch to Kubernetes later on.<\/p>\n\n
The only problem is that it lacks good observability when reaching a good size.<\/p>\n\n
\n \n \n Kubernetes<\/a>\n<\/h3>\n\nKubernetes is a generalist container orchestrator, therefore it doesn't deal with Docker concepts but with abstractions that represent concepts inside the ecosystem, like Pods.<\/p>\n\n
The good thing about Kubernetes is that is really easy to manage deploys and release cycles using either Kubernetes definitions (YAML or JSON) or Helm charts (a kind of deploy config on repositories) and you can even, with some tinkering around, use docker-compose files to do the deploys. It is also absurdly robust once correctly set up.<\/p>\n\n
The cons are that it is not an easy piece of software to manage (the internals) and deploy, thus needing a DevOps team taking care of it.<\/p>\n\n
\n \n \n My Conclusions\n<\/h3>\n\n
The key here is to understand where you are, if you are still preparing an MVP to launch and the only thing in your infrastructure is a webserver then you are better off with docker-compose and progressively go up.<\/p>\n\n
Also, if your Kubernetes will have more orchestrator services than services is orchestrating then you may be better off with Swarm.<\/p>\n\n
All I wanted with this is to make people think about the technologies they choose to use, accidental complexity carries a cost and it should not be taken lightly so don't let the hype get you.<\/p>\n\n","category":["kubernetes","devops","docker","hype"]},{"title":"You don't know TDD","pubDate":"Sun, 17 Mar 2019 16:20:22 +0000","link":"https:\/\/dev.to\/anortef\/you-dont-know-tdd-47a","guid":"https:\/\/dev.to\/anortef\/you-dont-know-tdd-47a","description":"
Okay, maybe you think you know what TDD is but let me tell you a story. <\/p>\n\n
Some years ago there was this young developer who thought that, even when she\/he had a lot to learn, she\/he at least got a pretty solid foundation. She\/He knew that coupling is bad and classes should be single responsibility and the methods inside the class should be also single responsibility in order to produce maintainable and extensible software. <\/p>\n\n
To this point, most of us can resonate with this story and laugh at ourselves for being that naive. Of course, we think we write decoupled code now but the truth is most developers don't know what TDD is and they write coupled code, less coupled that some years ago because of practice, but coupled none the less. Proof of that is on your companies repositories and how developers shudder every time they need to change something on the codebase. <\/p>\n\n
\n \n \n TDD is not Unit Testing but Unit Testing is TDD.\n<\/h2>\n\n
TDD, as the name implies, is the practice of developing software aided by tests. One of the tools are Unit Tests but if you only use those you get something like this:<\/p>\n\n
Synchronize Settings, Snippets, Themes, File Icons, Launch, Keybindings, Workspaces, and Extensions Across Multiple Machines Using GitHub Gist.<\/p>\n\n
\n \n \n Trailing Spaces<\/a>\n<\/h3>\n\nHighlight trailing spaces.<\/p>\n\n","category":"productivity"},{"title":"Do you really need Kubernetes in your company\/startup?","pubDate":"Mon, 17 Jun 2019 10:37:00 +0000","link":"https:\/\/dev.to\/anortef\/do-you-really-need-kubernetes-in-your-company-startup-1ec0","guid":"https:\/\/dev.to\/anortef\/do-you-really-need-kubernetes-in-your-company-startup-1ec0","description":"
Let me start saying that I love Kubernetes, I even have a personal one for my things but I'm an experienced DevOps and it is in my spare time.<\/p>\n\n
Usually, you want the complexity of the technical solutions your company uses to increase on complexity accordingly to your needs.<\/p>\n\n
You may think: whoa! I need to have autodiscovery between my microservices, a load balancer for the HTTP API and everything must be declared as a code to be maintainable without a shady guy from Ops<\/em><\/p>\n\nAnd of course, you need that, especially the last part, but is really Kubernetes the only thing that can give you that?<\/p>\n\n
\n \n \n Docker-Compose<\/a>\n<\/h3>\n\nIts a tool written in Python that let you define environments using YAML.<\/p>\n\n
The good things about this are that you can use this to make and maintain the developer's local environment and If you have only one production server (very little startup) you can even use the same YAML files used to develop your solution to deploy it into the server.<\/p>\n\n
The bad thing is that it is not really designed to run on a cluster so you are limited to a one and only production machine.<\/p>\n\n
\n \n \n Docker Swarm<\/a>\n<\/h3>\n\nIt's a solution that comes with Docker and allows to manage several machines with Docker as one cluster.<\/p>\n\n
In essence, Swarm and Kubernetes do the same but are not the same. The good thing about Swarm is that you can reuse the same YAML files that you were using with docker-compose and, in the pipeline, add the scaling stuff they need on Swarm.
\nYou can use things like Traefik to manage the access and you can reuse it if you switch to Kubernetes later on.<\/p>\n\n
The only problem is that it lacks good observability when reaching a good size.<\/p>\n\n
\n \n \n Kubernetes<\/a>\n<\/h3>\n\nKubernetes is a generalist container orchestrator, therefore it doesn't deal with Docker concepts but with abstractions that represent concepts inside the ecosystem, like Pods.<\/p>\n\n
The good thing about Kubernetes is that is really easy to manage deploys and release cycles using either Kubernetes definitions (YAML or JSON) or Helm charts (a kind of deploy config on repositories) and you can even, with some tinkering around, use docker-compose files to do the deploys. It is also absurdly robust once correctly set up.<\/p>\n\n
The cons are that it is not an easy piece of software to manage (the internals) and deploy, thus needing a DevOps team taking care of it.<\/p>\n\n
\n \n \n My Conclusions\n<\/h3>\n\n
The key here is to understand where you are, if you are still preparing an MVP to launch and the only thing in your infrastructure is a webserver then you are better off with docker-compose and progressively go up.<\/p>\n\n
Also, if your Kubernetes will have more orchestrator services than services is orchestrating then you may be better off with Swarm.<\/p>\n\n
All I wanted with this is to make people think about the technologies they choose to use, accidental complexity carries a cost and it should not be taken lightly so don't let the hype get you.<\/p>\n\n","category":["kubernetes","devops","docker","hype"]},{"title":"You don't know TDD","pubDate":"Sun, 17 Mar 2019 16:20:22 +0000","link":"https:\/\/dev.to\/anortef\/you-dont-know-tdd-47a","guid":"https:\/\/dev.to\/anortef\/you-dont-know-tdd-47a","description":"
Okay, maybe you think you know what TDD is but let me tell you a story. <\/p>\n\n
Some years ago there was this young developer who thought that, even when she\/he had a lot to learn, she\/he at least got a pretty solid foundation. She\/He knew that coupling is bad and classes should be single responsibility and the methods inside the class should be also single responsibility in order to produce maintainable and extensible software. <\/p>\n\n
To this point, most of us can resonate with this story and laugh at ourselves for being that naive. Of course, we think we write decoupled code now but the truth is most developers don't know what TDD is and they write coupled code, less coupled that some years ago because of practice, but coupled none the less. Proof of that is on your companies repositories and how developers shudder every time they need to change something on the codebase. <\/p>\n\n
\n \n \n TDD is not Unit Testing but Unit Testing is TDD.\n<\/h2>\n\n
TDD, as the name implies, is the practice of developing software aided by tests. One of the tools are Unit Tests but if you only use those you get something like this:<\/p>\n\n
And of course, you need that, especially the last part, but is really Kubernetes the only thing that can give you that?<\/p>\n\n
\n \n \n Docker-Compose<\/a>\n<\/h3>\n\nIts a tool written in Python that let you define environments using YAML.<\/p>\n\n
The good things about this are that you can use this to make and maintain the developer's local environment and If you have only one production server (very little startup) you can even use the same YAML files used to develop your solution to deploy it into the server.<\/p>\n\n
The bad thing is that it is not really designed to run on a cluster so you are limited to a one and only production machine.<\/p>\n\n
\n \n \n Docker Swarm<\/a>\n<\/h3>\n\nIt's a solution that comes with Docker and allows to manage several machines with Docker as one cluster.<\/p>\n\n
In essence, Swarm and Kubernetes do the same but are not the same. The good thing about Swarm is that you can reuse the same YAML files that you were using with docker-compose and, in the pipeline, add the scaling stuff they need on Swarm.
\nYou can use things like Traefik to manage the access and you can reuse it if you switch to Kubernetes later on.<\/p>\n\n
The only problem is that it lacks good observability when reaching a good size.<\/p>\n\n
\n \n \n Kubernetes<\/a>\n<\/h3>\n\nKubernetes is a generalist container orchestrator, therefore it doesn't deal with Docker concepts but with abstractions that represent concepts inside the ecosystem, like Pods.<\/p>\n\n
The good thing about Kubernetes is that is really easy to manage deploys and release cycles using either Kubernetes definitions (YAML or JSON) or Helm charts (a kind of deploy config on repositories) and you can even, with some tinkering around, use docker-compose files to do the deploys. It is also absurdly robust once correctly set up.<\/p>\n\n
The cons are that it is not an easy piece of software to manage (the internals) and deploy, thus needing a DevOps team taking care of it.<\/p>\n\n
\n \n \n My Conclusions\n<\/h3>\n\n
The key here is to understand where you are, if you are still preparing an MVP to launch and the only thing in your infrastructure is a webserver then you are better off with docker-compose and progressively go up.<\/p>\n\n
Also, if your Kubernetes will have more orchestrator services than services is orchestrating then you may be better off with Swarm.<\/p>\n\n
All I wanted with this is to make people think about the technologies they choose to use, accidental complexity carries a cost and it should not be taken lightly so don't let the hype get you.<\/p>\n\n","category":["kubernetes","devops","docker","hype"]},{"title":"You don't know TDD","pubDate":"Sun, 17 Mar 2019 16:20:22 +0000","link":"https:\/\/dev.to\/anortef\/you-dont-know-tdd-47a","guid":"https:\/\/dev.to\/anortef\/you-dont-know-tdd-47a","description":"
Okay, maybe you think you know what TDD is but let me tell you a story. <\/p>\n\n
Some years ago there was this young developer who thought that, even when she\/he had a lot to learn, she\/he at least got a pretty solid foundation. She\/He knew that coupling is bad and classes should be single responsibility and the methods inside the class should be also single responsibility in order to produce maintainable and extensible software. <\/p>\n\n
To this point, most of us can resonate with this story and laugh at ourselves for being that naive. Of course, we think we write decoupled code now but the truth is most developers don't know what TDD is and they write coupled code, less coupled that some years ago because of practice, but coupled none the less. Proof of that is on your companies repositories and how developers shudder every time they need to change something on the codebase. <\/p>\n\n
\n \n \n TDD is not Unit Testing but Unit Testing is TDD.\n<\/h2>\n\n
TDD, as the name implies, is the practice of developing software aided by tests. One of the tools are Unit Tests but if you only use those you get something like this:<\/p>\n\n
It's a solution that comes with Docker and allows to manage several machines with Docker as one cluster.<\/p>\n\n
In essence, Swarm and Kubernetes do the same but are not the same. The good thing about Swarm is that you can reuse the same YAML files that you were using with docker-compose and, in the pipeline, add the scaling stuff they need on Swarm.
\nYou can use things like Traefik to manage the access and you can reuse it if you switch to Kubernetes later on.<\/p>\n\n
The only problem is that it lacks good observability when reaching a good size.<\/p>\n\n