1. VERSÃO 1 ASSUNTOS SUGERIDOS
1.1. NoSQL
1.1.1. Cassandra
1.1.2. MongoDB
1.1.3. RavenDB
1.1.4. Neo4J
1.1.5. Redis
1.2. Programação funcional
1.2.1. F#
1.2.2. Clojure
1.3. Mobile
1.3.1. Flutter
1.3.2. React Native
1.3.3. Android Nativo
1.3.4. IOS Nativo
1.4. Infraestrutura
1.4.1. Docker
1.4.2. Kubernetes
1.4.2.1. Open shift
1.4.2.2. Rancher
1.4.3. Elastic Search
1.4.3.1. Kibana
1.4.4. Monitoramento
1.4.4.1. netdata.io
1.4.4.2. Grafana
1.4.5. Linux
1.5. UX/UI
1.5.1. Crazy8
1.5.2. Storelling
1.6. Cloud
1.6.1. Azure
1.6.2. AWS
1.6.3. Google Cloud
1.7. Linguagens
1.7.1. Python
1.7.2. C#
1.7.3. Java
1.7.4. Rust
1.7.5. Erlang
1.7.6. Kotlin
1.7.7. Javascript
1.7.8. Dart
1.7.9. Swift
1.8. Arquitetura de software
1.8.1. Domain Driven Design
1.8.2. Command and Query Responsibility Segregation
1.8.3. Mensageira
1.8.3.1. RabbitMQ
1.8.3.2. Kafka
1.8.3.3. gRPC
1.8.4. Microsserviços
1.9. Técnicas de programação
1.9.1. Test Driven Development
1.9.2. Behaviour Driven Development
1.9.3. Clean Code
2. EINPROZIT
2.1. VERSÃO 1 ASSUNTOS SUGERIDOS
2.1.1. NoSQL
2.1.1.1. Cassandra
2.1.1.2. MongoDB
2.1.1.3. RavenDB
2.1.1.4. Neo4J
2.1.1.5. Redis
2.1.2. Programação funcional
2.1.2.1. F#
2.1.2.2. Clojure
2.1.3. Mobile
2.1.3.1. Flutter
2.1.3.2. React Native
2.1.3.3. Android Nativo
2.1.3.4. IOS Nativo
2.1.4. Infraestrutura
2.1.4.1. Docker
2.1.4.2. Kubernetes
2.1.4.2.1. Open shift
2.1.4.2.2. Rancher
2.1.4.3. Elastic Search
2.1.4.3.1. Kibana
2.1.4.4. Monitoramento
2.1.4.4.1. netdata.io
2.1.4.4.2. Grafana
2.1.4.5. Linux
2.1.5. UX/UI
2.1.5.1. Crazy8
2.1.5.2. Storelling
2.1.6. Cloud
2.1.6.1. Azure
2.1.6.2. AWS
2.1.6.3. Google Cloud
2.1.7. Linguagens
2.1.7.1. Python
2.1.7.2. C#
2.1.7.3. Java
2.1.7.4. Rust
2.1.7.5. Erlang
2.1.7.6. Kotlin
2.1.7.7. Javascript
2.1.7.8. Dart
2.1.7.9. Swift
2.1.8. Arquitetura de software
2.1.8.1. Domain Driven Design
2.1.8.2. Command and Query Responsibility Segregation
2.1.8.3. Mensageira
2.1.8.3.1. RabbitMQ
2.1.8.3.2. Kafka
2.1.8.3.3. gRPC
2.1.8.4. Microsserviços
2.1.9. Técnicas de programação
2.1.9.1. Test Driven Development
2.1.9.2. Behaviour Driven Development
2.1.9.3. Clean Code
2.2. VERSÃO 2 ASSUNTOS (AZUL) MOTIVAÇÃO (AMARELO) DINÂMICA (VERDE)
2.2.1. PROGRAMAÇÃO FUNCIONAL
2.2.1.1. F#
2.2.1.2. Clojure
2.2.1.3. Elixir
2.2.1.4. Aprender e testar uma linguagem funcional
2.2.1.5. Conhecer um novo paradigma de programação
2.2.2. TESTES
2.2.2.1. Tipos de testes
2.2.2.1.1. Unitários
2.2.2.1.2. Integração
2.2.2.1.3. Aceitação
2.2.2.1.4. ETC
2.2.2.2. Aplicar TDD
2.2.2.2.1. Tentar aplicar a técnica de fato para validar quando se deve ou não utilizá-la
2.2.2.2.2. Resolver problema do boliche
2.2.2.3. Aplicar BDD
2.2.2.3.1. Tentar aplicar a técnica de fato para validar quando se deve ou não utilizá-la
2.2.3. CONCEITOS DE ARQUITETURA
2.2.3.1. SOLID
2.2.3.2. CLEAN CODE
2.2.3.3. MVC
2.2.3.4. MVVM
2.2.3.5. MVP
2.2.3.6. HEXAGONAL
2.2.3.7. CQRS
2.2.3.8. REDUX
2.2.3.9. PATTERNS
2.2.3.10. Nivelar conhecimento sobre arquiteturas de software para facilitar manutenção de códigos fontes
2.2.3.11. Passar pelos conceitos verificando exemplos práticos de projetos já executados
2.2.4. NOSQL
2.2.4.1. VER EXEMPLO DE UM BANCO CHAVE-VALOR
2.2.4.2. VER EXEMPLO DE UM BANCO FAMÍLIA DE COLUNAS
2.2.4.3. VER EXEMPLO DE UM BANCO DOCUMENTOS
2.2.4.4. VER EXEMPLO DE UM BANCO GRAFOS
2.2.4.5. Aprender os tipos de bancos de dados NoSQL e saber quando utilizar cada tipo de banco
2.2.4.6. Verificar conceito de cada banco, selecionar um do tipo, instalar (preferência em docker) e fazer uma aplicação simples para salvar e buscar dados
2.2.5. INFRAESTRUTURA
2.2.5.1. DOCKER
2.2.5.1.1. Aprender a utilizar a ferramenta para utilização em ambiente de desenvolvimento e também saber montar um container para produção
2.2.5.2. KUBERNETES
2.2.5.3. CI/CD
2.2.5.3.1. Aprender a ferramenta mais utilizada no momento para gerenciamento de containers
2.2.5.3.2. Montar uma esteira de desenvolvimento executando testes e implantação em ambiente de produção
2.2.6. FERRAMENTAS E TECNOLOGIAS
2.2.6.1. MONITORAMENTO
2.2.6.1.1. NETDATA.IO
2.2.6.1.2. GRAFANA
2.2.6.2. GRAPHQL
2.2.6.2.1. Aprender um novo protocolo de comunicação e verificar quando se utilizar
2.2.6.3. RABBITMQ
2.2.6.3.1. Aprender a ferramenta e os conceitos de mensageria
2.2.6.4. KAFKA
2.2.6.4.1. Verificar porque o concorrente do RabbitMQ é tão utilizado validando performance dos dois
2.2.6.5. gRPC
2.2.6.5.1. Aprender um novo protocolo de comunicação e verificar quando se utilizar
2.2.7. UX/UI
2.3. Arquitetura de Software
2.3.1. Arquitetura de software
2.3.1.1. Antifrágil: coisas que se beneficiam com o caos
2.3.1.1.1. Prólogo
2.3.1.1.2. Livro II: a modernidade e a negação da antifragilidade
2.3.1.1.3. Livro I: O antifrágil: uma introdução
2.3.1.2. Arquitetura de software
2.3.1.2.1. O que é?
2.3.1.2.2. O que faz?
3. Arquitetura de Software
3.1. Arquitetura de software
3.1.1. Antifrágil: coisas que se beneficiam com o caos
3.1.1.1. Prólogo
3.1.1.1.1. Tudo o que surgir a partir de eventos aleatórios (ou de certos impactos) e que apresentar mais vantagens do que desvantagens será antifrágil; o inverso será frágil
3.1.1.1.2. O fragilista (planejamento médico, econômico, social) é aquele que faz você envolver-se em políticas e ações, todas artificiais, mas quais os benefícios são pequenos e visíveis, e os efeitos colaterais são potencialmente graves e invisíveis
3.1.1.1.3. Um homem é moralmente livre quando [...] julga o mundo, e julga outros homens, com uma sinceridade intransigente.
3.1.1.1.4. Tríade
3.1.1.2. Livro II: a modernidade e a negação da antifragilidade
3.1.1.2.1. Ilusão central da vida: que a aleatoriedade é arriscada, que é algo ruim - e que a eliminação da aleatoriedade é feita eliminando-se a aleatoriedade
3.1.1.2.2. O pequeno é mais antifrágil que o grande. Governo descentralizado é mais antifrágil do que um grande governo central
3.1.1.2.3. Variações de baixo pra cima
3.1.1.2.4. A exceção, o evento raro, desempenha papel insignificante no conjunto e a longo prazo
3.1.1.2.5. Fonte de todos erros prejudiciais: confundir a ausência de evidência (de danos) com a evidência de ausência 128
3.1.1.2.6. Aleatoriedade distribuída em pequenas partes é antifrágil
3.1.1.2.7. Controle muito de perto e minucioso é instável
3.1.1.2.8. Burro com água e comida à uma mesma distância morre, precisa de um empurrão (aleatoriedade) para sobreviver
3.1.1.2.9. A poda de uma árvore deixa ela mais forte
3.1.1.2.10. Não há estabilidade sem volatilidade
3.1.1.2.11. Evitar ficar cego à antifragilidade natural dos sistemas
3.1.1.2.12. Superintervenção e subintervenção
3.1.1.2.13. Procrastinação é nossa defesa natural para que as coisas se resolvam sozinhas com sua antifragilidade
3.1.1.2.14. Saber distinguir ruído de sinal
3.1.1.2.15. Iatrogenia
3.1.1.3. Livro I: O antifrágil: uma introdução
3.1.1.3.1. O frágil é o pacote que sairia, na MELHOR das hipóteses, ileso
3.1.1.3.2. O robusto é o pacote que sairia, na MELHOR e na PIOR das hipóteses, ileso
3.1.1.3.3. O antifrágil é o pacote que sairia, na PIOR das hipóteses, ileso
3.1.1.3.4. Mitridização: exposição a uma pequena dose de uma substância que, ao longo do tempo, nos torna imunes a quantidades adicionais e maiores dessa mesma substância
3.1.1.3.5. Hormese: pequena dose de uma substância nociva que é benéfica ao organismo, agindo como medicamento
3.1.1.3.6. O seres humanos não conseguem reconhecer as situações fora dos contextos em que costumam aprender
3.1.1.3.7. Como você consegue inovar? Tente ficar em apuros!
3.1.1.3.8. Sobrecompensação: um processo estocástico submetido a uma berreira absorvente terá uma média observada superior à barreira
3.1.1.3.9. Orgânico vs mecânico Biológico vs sintético Antifrágil vs frágil
3.1.1.3.10. Opacidade causal: é difícil vislumbrar a conexão entre causa e efeito, fazendo com que muitos dos métodos convencionais de análise, além da lógica convencional, se tornem inaplicáveis
3.1.1.3.11. Não podemos isolar qualquer relação causal em um sistema complexo
3.1.1.3.12. Influência de agentes estressores
3.1.1.3.13. Para o não orgânico, o não complexo, digamos, um objeto sobre a mesa, o equilíbrio (como é tradicionalmente definido) acontece em um estado de inércia. Assim para algo orgânico, o equilíbrio (nesse sentido) só acontece com a morte
3.1.1.3.14. O frágil precisa ser muito preditivo em sua abordagem e, inversamente, os sistemas preditivo causam fragilidade
3.1.1.3.15. Quando você quer desvios, e não se preocupa com a possível dispersão de resultados que o futuro pode trazer,ja que a maioria será útil, você é antifrágil
3.1.1.3.16. Além disso, o elemento aleatório da tentativa e erro não é totalmente aleatório se for conduzido de forma racional, utilizando os erros como fonte de informação. Se cada tentativa lhe fornecer informações sobre o que não funciona, você começa a focar em uma solução - portanto, cada tentativa se torna mais valiosa, mais como uma despesa do que como um erro. E é claro que você fará descobertas ao longo do caminho.
3.1.1.3.17. Camadas, unidades, hierarquia estrutura fractal... Benefícios pra um não necessariamente é para outros
3.1.2. Arquitetura de software
3.1.2.1. O que é?
3.1.2.1.1. Perspectiva descritiva
3.1.2.1.2. Perspectiva ativa
3.1.2.2. O que faz?
3.1.2.2.1. Desenvolver
3.1.2.2.2. Manter
3.1.2.2.3. Atualizar
3.1.2.2.4. Entregar
3.1.2.2.5. Operacionalizar
4. VERSÃO 2 ASSUNTOS (AZUL) MOTIVAÇÃO (AMARELO) DINÂMICA (VERDE)
4.1. PROGRAMAÇÃO FUNCIONAL
4.1.1. F#
4.1.2. Clojure
4.1.3. Elixir
4.1.4. Aprender e testar uma linguagem funcional
4.1.5. Conhecer um novo paradigma de programação
4.2. TESTES
4.2.1. Tipos de testes
4.2.1.1. Unitários
4.2.1.2. Integração
4.2.1.3. Aceitação
4.2.1.4. ETC
4.2.2. Aplicar TDD
4.2.2.1. Tentar aplicar a técnica de fato para validar quando se deve ou não utilizá-la
4.2.2.2. Resolver problema do boliche
4.2.3. Aplicar BDD
4.2.3.1. Tentar aplicar a técnica de fato para validar quando se deve ou não utilizá-la
4.3. CONCEITOS DE ARQUITETURA
4.3.1. SOLID
4.3.2. CLEAN CODE
4.3.3. MVC
4.3.4. MVVM
4.3.5. MVP
4.3.6. HEXAGONAL
4.3.7. CQRS
4.3.8. REDUX
4.3.9. PATTERNS
4.3.10. Nivelar conhecimento sobre arquiteturas de software para facilitar manutenção de códigos fontes
4.3.11. Passar pelos conceitos verificando exemplos práticos de projetos já executados
4.4. NOSQL
4.4.1. VER EXEMPLO DE UM BANCO CHAVE-VALOR
4.4.2. VER EXEMPLO DE UM BANCO FAMÍLIA DE COLUNAS
4.4.3. VER EXEMPLO DE UM BANCO DOCUMENTOS
4.4.4. VER EXEMPLO DE UM BANCO GRAFOS
4.4.5. Aprender os tipos de bancos de dados NoSQL e saber quando utilizar cada tipo de banco
4.4.6. Verificar conceito de cada banco, selecionar um do tipo, instalar (preferência em docker) e fazer uma aplicação simples para salvar e buscar dados
4.5. INFRAESTRUTURA
4.5.1. DOCKER
4.5.1.1. Aprender a utilizar a ferramenta para utilização em ambiente de desenvolvimento e também saber montar um container para produção
4.5.2. KUBERNETES
4.5.3. CI/CD
4.5.3.1. Aprender a ferramenta mais utilizada no momento para gerenciamento de containers
4.5.3.2. Montar uma esteira de desenvolvimento executando testes e implantação em ambiente de produção
4.6. FERRAMENTAS E TECNOLOGIAS
4.6.1. MONITORAMENTO
4.6.1.1. NETDATA.IO
4.6.1.2. GRAFANA
4.6.2. GRAPHQL
4.6.2.1. Aprender um novo protocolo de comunicação e verificar quando se utilizar
4.6.3. RABBITMQ
4.6.3.1. Aprender a ferramenta e os conceitos de mensageria
4.6.4. KAFKA
4.6.4.1. Verificar porque o concorrente do RabbitMQ é tão utilizado validando performance dos dois
4.6.5. gRPC
4.6.5.1. Aprender um novo protocolo de comunicação e verificar quando se utilizar
4.7. UX/UI
5. SONHO MEU
5.1. NÍVEIS DE MATURIDADE
5.2. PROMOVER ACADEMIES
5.3. MENTORIA
5.3.1. COACHING PARA ARQUITETOS
5.3.1.1. ACOMPANHAR TRABALHO DE ARQUITETO PARA VER SE GOSTA (NÃO É SÓ DESENVOLVIMENTO)
5.3.1.2. ACOMPANHAR DIFERENTES TRABALHOS DE ARQUITETURA (DOMÍNIO, CORPORATIVO, SOLUÇÕES)
5.3.2. MENTORIA PARA DESENVOLVEDORES
5.3.2.1. ACOMPANHAR UM DESENVOLVEDOR SENIOR
5.3.2.1.1. CADENCIADO (1X POR SEMANA)
5.4. ÁREAS
5.4.1. ARQUITETURA DE SOFTWARE
5.4.1.1. WEB
5.4.1.1.1. BACKEND
5.4.1.1.2. FRONTEND
5.4.1.2. MOBILE
5.4.1.2.1. ANDROID
5.4.1.2.2. IOS
5.4.1.2.3. FLUTTER
5.5. RADAR DE CONHECIMENTO
5.6. SER PONTO DE REFERENCIA PARA DÚVIDAS
5.7. EXCELENCIA TÉCNICA
5.7.1. DIRECIONAR EQUIPE DE PROJETOS DE FÁBRICA
5.7.2. DESENVOLVER E MANTER FRAMEWORKS, BIBLIOTECAS PARA AUXILIAR NOS PROJETOS
5.7.3. AJUDAR OUTSOURCING EM PROBLEMAS DO DIA D DIA
5.8. CONSULTORIA
5.9. SERVIÇOS PARA OFERTAR
6. IDEIA
6.1. ÁREAS
6.1.1. ARQUITETURA
6.1.1.1. MOBILE
6.1.1.2. WEB
6.1.1.2.1. MICROSSERVIÇOS
6.1.1.2.2. ESCALABILIDADE
6.1.2. DESENVOLVIMENTO WEB
6.1.2.1. BACKEND
6.1.2.2. FRONTEND
6.1.3. DESENVOLVIMENTO MOBILE
6.1.3.1. FLUTTER
6.1.3.2. IOS NATIVO
6.1.3.3. ANDROID NATIVO
6.1.4. UX/UI
6.2. RADAR DE CONHECIMENTO
6.2.1. É COMO MANTEMOS NOSSA BASE DE CONHECIMENTO
6.3. SERVIÇOS
6.3.1. PESSOAS
6.3.1.1. MENTORIA
6.3.1.1.1. PARA ARQUITETOS
6.3.1.1.2. PARA DESENVOLVEDORES
6.3.1.1.3. PARA QAS
6.3.1.1.4. PARA UX
6.3.1.2. HELP
6.3.1.2.1. AJUDAR NA RESOLUÇÃO DE PROBLEMAS ESPECÍFICOS
6.3.1.3. TREINAMENTOS
6.3.1.3.1. DESIGN PATTERNS
6.3.1.3.2. DOMAIN DRIVEN DESIGN
6.3.2. EMPRESAS
6.3.2.1. CONSULTORIA
6.3.2.1.1. MODELO DE MATURIDADE
6.3.2.1.2. TO-BE ARQUITETURA
6.3.2.2. CRIAÇÃO E MANUTENÇÃO DE FRAMEWORKS E BIBLIOTECAS COMPARTILHADAS
6.4. VALORES E PRINCÍPIOS
6.4.1. CENTRO DE EXCELÊNCIA TÉCNICA
6.4.2. DIRECIONAR E MANTER PRINCÍPIOS, PADRÕES E PRÁTICAS DE DESENVOLVIMENTO FOMENTADO QUALIDADE E PRODUTIVIDADE