- A comunicação é uma necessidade básica dos seres humanos.
- A forma de comunicação evolui ao longo do tempo.
- A comunicação possui três elementos fundamentais: remetente, mensagem e destinatário.
- O remetente é aquele que envia a informação, o destinatário é aquele que recebe a informação e a mensagem é a informação propriamente dita.
- O destinatário pode confirmar a chegada através de resposta única ou múltiplas respostas.
- O nosso modelo de comunicação é muito semelhante com a comunicação das aplicações que criamos.
- O modelo cliente-servidor segue os pilares da comunicação.
- Os termos síncrono e assíncrono referem-se ao fluxo de uma aplicação.
Você como uma pessoa desenvolvedora é, sem dúvidas, atenta nas novidades das tecnologias que você utiliza no dia a dia. Mas você já se perguntou como funciona para alguma pessoa dar sugestão de um novo método, uma nova funcionalidade ou até mesmo alteração em alguma tecnologia?
Isso é possível utilizando um padrão adotado pela maioria das linguagens chamado RFC ou Request For Comments. Se formos traduzi-lo, significa "Pedidos para Comentários". Esta mecânica é utilizada em muitas tecnologias como por exemplo PHP, Rust, React e o EcmaScript.
É valido lembrar que cada tecnologia possui seus próprios padrões de RFC como templates, fases de discussão e votação. O RFC é um conceito que é aplicado em diversos cenários!
A área de administração de sistemas ou "devops" é uma área vasta da computação e que envolve a administração de servidores (físicos ou na nuvem), instalação e operação de servidores (web, e-mail, DNS entre outros), configuração de redes, instalação e operação de sistemas (PHP, Python, Ruby, Node.js entre outros), gerenciamento de acesso via SSH, segurança (firewall, proxy), gerenciamento de permissões, instalação e operação de banco de dados (MySQL, PostgreSQL, Elasticsearch entre outros), gestão de logs (manualmente ou com Logstash), backups, monitoramento, cloud computing (AWS, GCP, Azure), conteinerização (Docker, Kubernetes) entre outras disciplinas.
Para se tornar um bom sysadmin é necessário uma base sólida em sistemas operacionais, redes, segurança da informação e um pouco de programação. Recomenda-se também um conhecimento sólido em ambientes Linux e de ferramentas de software livre.
- Arquitetura de Software: A diferença entre Arquitetura e Design - Eduardo Rabelo 📖 ⭐
- Software Architecture - The Difference Between Architecture and Design - Mohamed Aladdin 📖 ⭐
- Knocking down the Ivory Tower - Christopher Laine 📖
- The Ivory Tower Architect - Deep Shah 📖
- Modeling Software Architecture With C4 📖 ⭐
- [Software Architecture: The Most Important Architectural Patterns You Need to Know 📖 ⭐](https://levelup.gitconnected.com/software-architecture-the-important-architectural-patterns-you-need-to-know-a1f5e
- A História da Matemática da BBC - https://youtu.be/Ztz6VX0kIPc
- Grandes Pensadores: Galois - https://youtu.be/hBmIvx0-830
- Grandes Pensadores: Pierre de Fermat - https://youtu.be/39vQgSKuQg8
- Grandes Pensadores: Euclides - https://youtu.be/QM3HUpIwaYs
- História da Álgebra - UNIVESP - https://youtu.be/4AskeZ3RjfQ
- História da Matemática - UNIVESP - https://www.youtube.com/playlist?list=PLxI8Can9yAHfiV5_hrnTtTfWnbxT10w1E
- SciCast #260: Números Complexos (história do Tartaglia e Cardano) - https://www.deviante.com.br/podcasts/scicast-260/
- Nome: Marcel Gonçalves dos Santos
- E-mail: [email protected]
- Celular: (11) 98296-2837
- Site: http://www.pensandonaweb.com.br
- Twitter: https://twitter.com/marcelgsantos
- GitHub: https://github.com/marcelgsantos
- LinkedIn: https://www.linkedin.com/in/marcelgsantos
- SpeakerDeck e SlideShare: https://speakerdeck.com/marcelgsantos
- DDD – Introdução a Domain Driven Design - Daniel Cukier 📖 ⭐
- Desmistificando o DDD - Grazi Bonizi 📖 ⭐
- Destilando um domínio com DDD - Grazi Bonizi 📖 ⭐
- DDD Aplicado – Case Qualyteam - Grazi Bonizi 📖
- Complexidade Acidental
- Introdução a Domain-Driven Design - Maicon Pereira
▶️ ⭐ - Big Ball of Mud - Brian Foote and Joseph Yoder 📖 ⭐
- Big Ball of Mud - Felipe de Freitas Batista 📖
- PSR — Padrões necessários para ter um código de qualidade - Dhyogo Almeida ⭐
- PHPFIG - PHP Standards Recommendations
- PHPFIG - PSR 1 ⭐
- PHPFIG - PSR 4
- PHPFIG - PSR 12 ⭐
- Código Limpo: dicas práticas para turbinar a escrita, leitura e escalabilidade de um código - Zup ⭐
- #1 — Clean Code: O que é? Porque usar? - João Roberto da Paixão ⭐
- [#2 — Clean Code: Boas práticas para escrever códigos impecáveis! - João Roberto da Paixão](https://medium.com/desenvolvendo-com-paixao/2-clean-code-boas-pr%C3%A1ticas-para-escrever-c%C3%B3digos-impec%C3%A1veis-361997b3c8b5
- Cada commit deve conter uma alteração lógica única.
- Não faça diversas alterações lógicas em um único commit como corrigir um bug e implementar uma nova funcionalidade, por exemplo. Neste caso, prefira criar commits separados.
- Não separe uma alteração lógica única em vários commits.
- A implementação de uma funcionalidade e os seus testes devem estar em um mesmo commit, por exemplo.
- Realize o commit o quanto antes e frequentemente.
- Esta prática traz vantagens como: