Go, often called Golang, is a modern programming language that stands out for its simplicity, efficiency, and scalability. Designed by Google, Go was created to address common challenges in software development, making it an excellent choice for developers who need a powerful yet easy-to-use language. Here’s why Go is a fantastic programming language:

1. Simplicity and Readability

One of the most significant advantages of Go is its simplicity. Unlike many other languages that come with complex syntax and unnecessary features, Go focuses on keeping things straightforward. This simplicity makes Go easy to learn, read, and maintain, which is especially beneficial for teams and large-scale projects.

2. Fast Compilation and Execution

Go is a compiled language, meaning it translates code directly into machine code, resulting in fast execution. The Go compiler is incredibly efficient, enabling rapid compilation times that significantly boost development speed. This makes Go an excellent choice for performance-critical applications.

3. Built-in Concurrency Support

Concurrency is a first-class citizen in Go. With goroutines and channels, Go makes it easier than ever to write concurrent programs. Goroutines are lightweight threads managed by the Go runtime, allowing developers to efficiently handle multiple tasks at once without the complexity of traditional threading models.

4. Strong Standard Library

Go comes with a powerful standard library that covers a wide range of functionalities, including networking, file handling, and cryptography. The standard library is well-designed, reducing the need for third-party dependencies and ensuring consistency across projects.

5. Garbage Collection for Memory Management

Go’s garbage collector ensures that developers don’t have to manually manage memory, reducing the risk of memory leaks and improving application stability. The garbage collection mechanism is optimized for performance, making Go an excellent choice for applications that require efficient memory management.

6. Static Typing with Simplicity

Go is statically typed, which helps catch errors early in the development process. However, it avoids the verbosity of other statically typed languages, striking a balance between type safety and ease of use.

7. Excellent Tooling and Ecosystem

Go provides built-in tools for formatting, testing, and performance analysis. Features like go fmt, go test, and go vet streamline the development workflow, ensuring high code quality with minimal effort. The Go ecosystem also includes robust package management with go mod and a thriving community that continuously contributes to its growth.

8. Cross-Platform Compilation

Go’s ability to compile applications for different platforms (Windows, Linux, macOS) with a simple command makes it an attractive choice for developers building cross-platform applications. This feature eliminates the need for complex build processes and ensures seamless deployment across various environments.

9. Cloud and Microservices-Friendly

Go is widely used in cloud computing and microservices architectures due to its efficiency and scalability. Many modern cloud-native platforms, including Kubernetes and Docker, are written in Go, showcasing its suitability for building scalable and high-performance services.

10. Backed by Google and a Strong Community

Go is backed by Google, ensuring ongoing support and continuous improvement. Additionally, the Go community is active and supportive, providing a wealth of resources, open-source projects, and forums where developers can collaborate and learn from one another.

Conclusion

Go is a powerful and pragmatic programming language that excels in simplicity, performance, and scalability. Whether you’re building high-performance web services, cloud-native applications, or system-level utilities, Go provides the right balance of efficiency and ease of use. Its growing adoption in the tech industry is a testament to its strengths, making it a top choice for modern software development.

If you want to know more details about go features, see the repository and click on the star: https://github.com/leogregianin/go-is-good

Kubernetes é uma plataforma de orquestração de contêineres de código aberto. Ele automatiza o deploy, a escalabilidade e o gerenciamento de aplicativos em contêineres.

Qual a sua origem?

O Kubernetes iniciou como um sistema interno de orquestração de contêineres no Google, chamado Borg, que gerenciava a implantação de milhares de aplicativos no Google. Em 2014, o Google abriu o código-fonte de uma versão do Borg e o denominou como Kubernetes, que em grego (κυβερνήτης) significa “timoneiro” ou “piloto” e agora é mantido pela Cloud Native Computing Foundation.

Porque alguns o chamam de K8S?

Esta é uma maneira um tanto nerd de abreviar palavras longas. O número 8 em K8S refere-se às oito letras entre a primeira letra K e a última letra S na palavra Kubernetes. Outros exemplos são I18N para internacionalização e L10N para localização.

Quais as principais peças de um cluster K8S?

Um cluster Kubernetes é um conjunto de máquinas chamadas “nós” que são usadas para executar aplicativos em contêineres. Existem duas peças principais em um cluster Kubernetes, vejamos:

• O primeiro é o plano de controle ou control plane que é responsável por gerenciar o estado do cluster. Em ambientes de produção, o control plane geralmente é executado em vários nós que abrangem diversas zonas do data center. Em ambientes on-premisse você mesmo deve ter o controle sobre ele, em ambientes cloud providers como AWS, Google Cloud ou Azure, a própria cloud gerencia o control plane.
• O segundo é um conjunto de nós de trabalho ou worker. Esses nós executam as cargas de trabalho de aplicativos em contêineres. Os aplicativos em contêineres são executados em um “pod”. Os pods são as menores unidades de um cluster Kubernetes. Um pod hospeda um ou mais contêineres e fornece armazenamento compartilhado e rede para esses contêineres. Os pods são criados e gerenciados pelo control plane do Kubernetes. Eles são os blocos de construção básicos dos aplicativos Kubernetes.

Control Plane

Plano de Controle consiste em vários componentes principais. Eles são o Servidor API (API Server), o etcd, o agendador (Scheduler) e o gerenciador de controle (Controller Manager). O API Server é a principal interface de comunicação entre Control Plane e o restante do Cluster.

O Control Plane expõe uma API RESTful que permite aos clientes interagir com o Control Plane e enviar solicitações para gerenciar o cluster.

etcd é um armazenamento de chave-valor distribuído, ou seja, é o estado persistente do cluster. É utilizado pela API Server e outros componentes do Control Plane para armazenar e recuperar informações sobre o cluster.

O Scheduler é responsável por agendar pods nos nós dos workers do cluster. Ele usa informações sobre os recursos exigidos pelos pods e os recursos disponíveis nos nós do worker para tomar decisões.

O Controller Manager é responsável por executar controladores que gerenciam o estado do cluster, por exemplo, o controlador de réplicas, que garante que o número desejado de réplicas de um pod esteja em execução, e um controlador de deploy, que gerencia as atualizações contínuas e reversões de deploys.

Worker

Os principais componentes do Kubernetes executados nos worker nodes incluem kubelet, container runtime e o kubeproxy.

O kubelet é um daemon executado em cada worker node e é responsável pela comunicação com o Control Plane recebendo instruções de quais pods serão executados no nó e garante que o estado desejado dos pods seja mantido.

O Container runtime executa os contêineres nos worker nodes e é responsável por extrair as imagens dos contêineres de um registro, iniciar, parar e gerenciar os recursos dos contêineres.

O kubeproxy é um proxy de rede executado em cada wroker node e é responsável por rotear o tráfego para os pods corretos, realiza balanceamento de carga para os pods e garante que o tráfego seja distribuído uniformemente entre os pods.

Vantagens

Kubernetes é escalonável e altamente disponível, fornece recursos como autocorreção, reversões automáticas e dimensionamento horizontal. Isso torna mais fácil aumentar ou diminuir nosso aplicativo conforme necessário, permitindo-nos responder rapidamente às mudanças na demanda.

Kubernetes é portátil, nos ajuda a implantar e gerir aplicações de forma consistente e confiável, independentemente da infraestrutura. Ele é executado on-premise, em cloud ou em ambiente híbrido. Fornece uma maneira uniforme de empacotar, implantar e gerenciar aplicativos.

Desvantagens

A desvantagem número um é a complexidade. O Kubernetes é complexo de configurar e operar. O custo inicial é alto para formar uma equipe com conhecimento em orquestração de contêineres. Requer um alto nível de conhecimento e recursos para configurar e gerenciar um ambiente de produção do Kubernetes.

A segunda desvantagem é o custo. O Kubernetes requer um certo nível mínimo de recursos para funcionar, a fim de oferecer suporte a todos os recursos mencionados acima. Provavelmente é um exagero para aplicações menores.

Opção razoável

Uma opção popular que atinge um equilíbrio razoável é transferir o gerenciamento do control plane para um serviço gerenciado do Kubernetes em um cloud provider como Amazon EKS, GKE no Google Cloud e AKS no Azure. Esses serviços permitem que as organizações executem aplicativos Kubernetes sem se preocupar com a infraestrutura.

Eles cuidam de tarefas que exigem conhecimento profundo, como instalar e configurar o control plane, dimensionar o cluster e fornecer manutenção e suporte contínuos. Esta é uma opção razoável para uma organização de médio porte testar o Kubernetes.

Exemplo em código

Como exemplo, fizemos uma aplicação real chamada URL shorter, ou, Encurtador de URL que recebe uma URL e retorna um hash da URL original tornando uma URL curta, que ao ser acessada redireciona para a URL original e grava a quantidade de acessos a URL curta e a URL original.

Por exemplo, a URL de um dos meus artigos no Medium é essa: https://dev.to/leogregianin/python-e-facil-go-e-simples-simples-e-diferente-de-facil-5b9o e poderia ficar somente https://encurtador_de_url.com/abc123.

O objetivo é mostrar como é possível criar uma aplicação utilizando as melhores práticas de desenvolvimento e deploy, utilizando as tecnologias Django para backend e frontend, Django Rest Framework para API, Postgres como banco de dados e Docker e Kubernetes para containerização e orquestração do deploy.

URL shorter é uma aplicação pequena e é utilizada para fins didáticos de como construir uma aplicação e escalar ela utilizando Kubernetes.

Um único pod:

Escalando para 12 réplicas:

App rodando:

O código da aplicação e os arquivos de configuração do Docker e Kubernetes estão em: https://github.com/leogregianin/kubernetes-workshop

Tradução livre do artigo “Python is Easy. Go is Simple. Simple != Easy” escrito por Preslav Rachev no seu blog. O artigo original pode ser lido em: https://preslav.me/2023/11/27/python-is-easy-golang-is-simple-simple-is-not-easy/

Existe um equívoco comum de que simples e fácil se referem à mesma coisa. Afinal, se algo é fácil de usar, seu funcionamento interno deve ser simples de entender, certo? Ou vice-versa? Na verdade, é exatamente o oposto. Embora os dois conceitos apontem para o mesmo resultado, fazer algo parecer fácil requer uma enorme complexidade.

Tomemos como exemplo o Python, uma linguagem conhecida por sua baixa barreira de entrada e, portanto, uma escolha favorita para linguagem de programação de entrada. Escolas, universidades, centros de pesquisa e um grande número de empresas em todo o mundo escolheram Python precisamente por causa de sua acessibilidade a qualquer pessoa, independentemente do seu nível de educação ou formação acadêmica (ou total falta dela). Raramente é necessária muita teoria de tipos ou compreensão de como e onde as coisas são armazenadas na memória, em quais threads algum trecho de código está sendo executado, etc. Além disso, Python é a porta de entrada para algumas das mais profundas bibliotecas científicas e de nível de sistema. Ser capaz de controlar essa quantidade de poder com uma única linha de código fala muito a favor de que ela se torne uma das linguagens de programação mais populares do planeta.

E aí vem o problema: a facilidade de expressar coisas em código Python tem um custo. Por baixo dos panos, o interpretador Python é enorme e muitas operações devem ocorrer para que até mesmo uma única linha de código seja executada. Quando você ouve alguém se referindo ao Python como uma linguagem “lenta”, grande parte da “lentidão” percebida vem do número de decisões que o interpretador toma em tempo de execução. Mas esse nem é o maior problema, na minha opinião. A complexidade do ecossistema de tempo de execução do Python, juntamente com algumas decisões liberais de design em torno do gerenciamento de pacotes, cria um ambiente muito frágil, e as atualizações geralmente levam a incompatibilidades e travamentos de tempo de execução. Não é incomum deixar um aplicativo Python para voltar a ele depois de alguns meses, apenas para perceber que o ambiente mudou o suficiente para que não seja mais possível nem mesmo iniciar o aplicativo.

Claro, isso é uma simplificação grosseira, e até as crianças de hoje em dia sabem que existem contêineres para resolver problemas como esse. Na verdade, graças ao Docker e similares, é possível “congelar” as dependências de uma base de código Python no tempo para que ela possa praticamente rodar para sempre. No entanto, isso tem o custo de transferir a responsabilidade e a complexidade para a infraestrutura do sistema operacional. Não é o fim do mundo, mas também não é algo que deva ser subestimado e ignorado.

Da facilidade à simplicidade

Se resolvêssemos os problemas com Python, acabaríamos com algo como Rust — extremamente performático, mas com uma barreira de entrada notoriamente alta. A ferrugem, na minha opinião, não é fácil de usar e, o que é mais importante, não é simples. Embora esteja em alta hoje em dia, apesar de 20 anos de programação e de ter dado meus primeiros passos em C e C++, não posso olhar para um pedaço de código Rust e dizer com certeza que entendo o que está acontecendo lá.

Descobri Go há cerca de cinco anos, enquanto trabalhava em um sistema baseado em Python. Embora tenha levado algumas tentativas para gostar da sintaxe, imediatamente caí na ideia de simplicidade. O objetivo do Go é ser simples de entender por qualquer pessoa em uma organização — desde o desenvolvedor júnior recém-saído da escola até o gerente de engenharia de nível sênior que apenas ocasionalmente olha o código. Além do mais, sendo uma linguagem simples, Go raramente recebe atualizações de sintaxe — a última significativa foi a adição de genéricos na v1.18, o que ocorre somente após uma década de discussões sérias. Na maior parte, quer você observe o código Go escrito há cinco dias ou cinco anos, ele é basicamente o mesmo e deve funcionar.

A simplicidade requer disciplina. Pode parecer limitante e até um tanto retrógrado no início. Especialmente quando comparado a uma expressão sucinta, como uma lista ou compreensão de dicionário em Python:

temperatures = [
    {"city": "City1", "temp": 19},
    {"city": "City2", "temp": 22},
    {"city": "City3", "temp": 21},
]

filtered_temps = {
    entry["city"]: entry["temp"] for entry in temperatures if entry["temp"] > 20
}

O mesmo código em Go requer mais código, mas idealmente deve ser uma ideia mais próxima do que o interpretador Python está fazendo por baixo dos panos:

type CityTemperature struct {
    City string
    Temp float64
}

// ...

temperatures := []CityTemperature{
    {"City1", 19},
    {"City2", 22},
    {"City3", 21},
}

filteredTemps := make(map[string]float64)
for _, ct := range temperatures {
    if ct.Temp > 20 {
        filteredTemps[ct.City] = ct.Temp
    }
}

Embora você possa escrever código equivalente em Python, uma regra não escrita em programação diz que se a linguagem fornecer uma opção mais fácil (mais concisa, mais elegante), os programadores irão gravitar em torno dela. Mas fácil é subjetivo e simples deve ser igualmente aplicável a todos. A disponibilidade de alternativas para executar a mesma ação leva a diferentes estilos de programação, e muitas vezes é possível encontrar vários estilos na mesma base de código.

Como Go é prolixo e “chato”, ele naturalmente marca outra caixa — o compilador Go tem muito menos trabalho a fazer ao compilar um executável. Compilar e executar um aplicativo Go costuma ser tão rápido, ou até mais rápido, do que carregar o interpretador Python ou a máquina virtual Java antes mesmo de executar o aplicativo real. Não é de surpreender que ser um executável nativo seja tão rápido quanto um executável pode ser. Não é tão rápido quanto seus equivalentes em C/C++ ou Rust, mas com uma fração da complexidade do código. Estou disposto a negligenciar esta pequena “desvantagem” do Go. Por último, mas não menos importante, os binários Go são vinculados estaticamente, o que significa que você pode construir um em qualquer lugar e executá-lo no host de destino — sem quaisquer tempos de execução ou dependências de biblioteca. Por uma questão de conveniência, ainda agrupamos nossos aplicativos Go em contêineres Docker. Ainda assim, eles são significativamente menores e têm uma fração do consumo de memória e CPU de seus equivalentes Python ou Java.

Como usamos Python e Go a nosso favor

A solução mais pragmática que encontramos em nosso trabalho é combinar os poderes da facilidade do Python e da simplicidade do Go. Para nós, Python é um ótimo playground de prototipagem. É onde nascem as ideias e onde as hipóteses científicas são aceitas e rejeitadas. Python é uma escolha natural para ciência de dados e aprendizado de máquina e, como lidamos com muitas dessas coisas, não faz sentido tentar reinventar a roda com outra coisa. Python também tem o Django, que atende ao seu lema de permitir o desenvolvimento rápido de aplicativos como poucas outras ferramentas (é claro, Ruby on Rails e Elixir’s Phoenix merecem uma menção digna de nota aqui).

Suponha que um projeto precise de um mínimo de gerenciamento de usuários e administração interna de dados (como a maioria dos nossos projetos). Nesse caso, começaríamos com um esqueleto do Django por causa do seu Admin integrado, o que é fantástico. Uma vez que a prova de conceito com Django começa a se assemelhar a um produto, identificamos o quanto dele pode ser reescrito em Go. Como o aplicativo Django já definiu a estrutura do banco de dados e a aparência dos modelos de dados, escrever o código Go que o complementa é bastante fácil. Depois de algumas iterações, chegamos a uma simbiose, onde os dois lados coexistem pacificamente no mesmo banco de dados e usam mensagens básicas para se comunicarem. Eventualmente, o “shell” do Django se torna um orquestrador — ele serve aos nossos propósitos de administração e aciona tarefas que são então gerenciadas pela sua contraparte Go. A parte Go atende a todo o resto, desde APIs e endpoints até a lógica de negócios e processamento de trabalhos em background.

É uma simbiose que tem funcionado bem até agora e espero que continue assim no futuro. Em um post futuro, descreverei mais alguns detalhes sobre a arquitetura em si.

Obrigado por ler!

Como funciona o sistema de módulos

O módulo nativo sys fornece acesso a variáveis e funções ​​que interagem com o interpretador. O sys.path é uma variável dentro do módulo sysque contém uma lista de diretórios que o interpretador irá buscar quando algum módulo por requerido nos imports.

Exemplo do que temos dentro do sys.path:

Vou demonstrar dentro do projeto httpx para explicar o que cada índice da lista representa:

O que está demonstrado à direita da tela é o arquivo _main.pye ao lado esquerdo está a árvore de diretórios do projeto.

Portanto, _main.py faz diversos imports, de arquivos locais, de pasta diferentes dentro do projeto, de módulos nativos do Python como functools, json e sys e de outros projetos como click, httpcore e pygments.

(Index 0) O primeiro índice é uma string em branco (‘ ’) e quer dizer que o Python irá buscar o arquivo do import no mesmo diretório que está sendo executado.

No exemplo _main.py está importando a classe Client do arquivo _client.py que está no mesmo diretório, por isso, utiliza-se o ponto (.), se estivesse em outra pasta, o importe seria: from other._client import Client.

(Index 1) O segundo índice do sys.path busca na biblioteca padrão (Stardard Library) de instalação, ou seja, irá buscar os módulos e funções nativas.

No mesmo exemplo, irá encontrar functools, json, sys e typing nesse diretório porque são funções nativas da linguagem.

(Index 2) O terceiro índice buscará na pasta do usuário, cada usuário tem o seu system path e é nele onde o usuário instala os programas para não causar conflitos com programas instalados por outros usuários do sistema operacional.

E por fim, se não encontrar o módulo nos diretórios anteriores, buscará no (Index 3) diretório de bibliotecas do sistema, onde, geralmente, se encontra a maioria dos programas feitos em Python que o sistema operacional utiliza.

Caso não encontre nesses diretórios de exemplo, o Python mostrará uma exceção dizendo que não encontrou o módulo.

É possível adicionar outros diretórios no sys.path, é possível controlar os diretórios com variáveis de ambiente ou exportar o PYTHONPATH. Modifique, somente se souber exatamente o que está fazendo!

O que precisamos

Precisamos que uma única solução, simples, rápida e eficiente, que faça:

• Faça o download de um projeto no PyPI.
• Instale o projeto e todas as suas dependências, sem que ocorra problemas de conflitos de versões das dependências.
• Tenha a verificação de hashes de cada pacote.
• Tenha um arquivo de configuração padronizado.
• Fazer build e upload de um pacote para o PyPI.
• Seja multiplataforma.
• Seja sustentável financeiramente. Sugestão: Financiada pela Python Software Foundation (PSF) (veja os patrocinadores da PSF aqui).

Evolução de 1991 a 2021

A linguagem tem seu primeiro release lançado oficialmente em 1991, e a primeira versão de uma ferramenta para distribuição de pacotes foi a distutils, lançada em setembro de 2000 na versão 1.6. O Distutils permite que você estruture seu projeto para que tenha um setup.pye, com isso, facilita a instalação e distribuição do projeto.

Nesse meio tempo, se quisesse instalar o código de outra pessoa, teria que baixar, instalar e adicioná-lo ao PYTHONPATH manualmente. Em 2003 foi criado, o então cheeseshop e agora, PyPI (Python Package Index), que é um catálogo/repositório online de programas para qualquer pessoa baixar e instalar.

Com um repositório centralizado e milhares de projetos, muitos projetos começaram a ter mais e mais dependências e gerenciá-los era um novo desafio por haver a possibilidade de incompatibilidades e conflitos de versões.

Em 2004 e nos anos seguintes, a comunidade começou a desenvolver um conjunto de ferramentas para extender o distutils para gerenciamento de dependências complexas, reconhecimento automatizado de precedência de versão e uma ferramenta de instalação automática chamada easy_install. Embora nunca tenha chegado à biblioteca padrão, setuptoolstornou-se o meio principal para criar e distribuir pacotes.

Mesmo com todas as ferramentas úteis feitas com o setuptools e easy_install, o problemas de compartilhamento de pacotes e o conflitos de versões ainda ocorriam. Em 2006 começou a ser discutido a possibilidade de construção de ambientes virtuais e em 2007 foi lançado o virtualenv que permitia construir ambientes isolados (ou virtuais) de um projeto a partir de uma instalação de sistema central de Python, com isso, o easy_install instala as dependências do projeto somente naquele ambiente isolado.

Em 2008, o mesmo criador do virtualenv, em alternativa e correções ao easy_install, cria o pip para fácil instalação de pacotes e dependências. O pip utiliza o arquivo requirements.txt para gerenciar as dependências do pacotes.

Em 2011, A Python Software Foundation cria um grupo de trabalho chamado Python Packaging Authority (PyPA) responsável por padronizar o meio de distribuição de pacotes, manter o pip e o virtualenv e também, por manter a infraestrutura do PyPI. A linha do tempo da história do PyPA encontra-se aqui.

Em 2012, a empresa Anaconda Inc. cria o gerenciador de pacote chamado Conda, voltado para a comunidade científica de desenvolvimento, criando uma infraestrutura totalmente separada do pip, virtualenv e PyPI.

Também em 2012, foi criado o pip-tools que é um conjunto de ferramentas para gerenciar e manter compilações determinísticas especificando as dependências por meio de hash ( — require-hashes que o pip implementou em 2016).

Em 2013, com a PEP 427, define-se que o formato binário padrão para distribuição dos pacotes é o formato wheel e é criado o twine para interagir e realizar upload seguros de pacotes para o PyPI.

Em 2014, a PEP 440 descreve como identificar versões de pacotes com um novo schema de versionamento.

Em 2015, é aprovadas a PEP 503 e PEP 508 que descrevem padrões para pacotes e para distribuição no PyPI.

Ainda em 2015, começa o desenvolvimento do flit, que pretendia ser o substituto de todo o ecossistema.

Em 2016 a PEP 518 especifica um novo arquivo de configuração de pacotes chamado pyproject.toml que centraliza e padroniza todos os arquivos de configuração em um só.

Ainda em 2016, o pip lança uma nova versão com a implementação do hashes para cada dependência dentro do requirements.txt.

Em 2017 a PEP 517 aprova builds independentes. Devido problemas antigos do distutils, e a tentativa de se fazer um distutils2, abrindo a possibilidade de não necessariamente utilizar distutils, ou seja, se você quiser usar distutils, ótimo; se você quiser usar outra coisa, isso deve ser fácil de fazer usando métodos padronizados.

Ainda em 2017 é lançado o pipx, ferramenta para instalar e rodar programas sem causar conflitos de dependências com outros pacotes instalados no sistema.

Estamos em 2017, ou seja, 26 anos desde a criação da linguagem e ainda não temos uma solução única e completa para gerenciar e distribuir pacotes.

De acordo com a sátira do xkcd, como está nosso ambiente:

Pipenv nasce ainda em 2017 como um projeto que visa agregar o pip, virtualenv e o Pipfile em um único conjunto de ferramentas para gerenciar ambientes, dependências e pacotes, cria e verifica hashes de arquivo para garantir a conformidade com dependências com os arquivos Pipfile e Pipfile.lock.

Em 2018 nasce o Poetry com a proposta de substituir todas as ferramentas já existentes de empacotamento e distribuição existentes (mesmo que, por debaixo dos panos, utiliza o pip e o virtualenv para instalar e criar ambientes isolados), ou seja, supre a necessidade do distutils, setuptools, virtualenv, pip, faz builds determinísticos igual o pip-tools e pip faz, segue o padrão da PEP 440 sobre semântica de versões, segue os padrão do PyPI da PEP 503 e PEP 508, utiliza o padrão do pyproject.toml da PEP 518 e cria builds independentes da PEP 517.

Portanto, o Poetry (em 2021), é o único projeto que abrange todos as ferramentas do ecossistema e segue todos os padrões definidos nas PEPs.

Em 2020, é lançada uma nova versão do pip, com um novo resolvedor de dependências.

Ainda em 2020, é criado o projeto pdm, que atende a PEP 582, ou seja, não há de se criar ambientes virtuais, cria-se um diretório local de pacotes python para cada projeto chamado __pypackages__ para incluir todos lá dentro. Seguindo a mesma ideia do node_modules do Nodejs.

Em 2021, ainda não temos uma ferramenta oficial, única e completa para todo o ecossistema (o poetry está perto disso) e que atenda todos os requisitos que escrevi no tópico logo acima chamado “O que precisamos”.

Conclusão

A organização PyPA no Github mantém a maioria dos projetos de empacotamento e distribuição, na minha humilde opinião, são vários projetos muito parecidos e para um mesmo objetivo final que são propostos, não vale tal esforço humano e financeiro. Poderíamos aprender com as linguagens citadas na introdução.

Os Correios são o órgão responsável por controlar os CEPs no Brasil e quem deveria, e não o faz, de prover a solução única, eficiente, rápida e de graça (já que são dados públicos) de ser consumida por sistemas e sites.

Por isso, existem diversas APIs que tentam suprir essa defasagem dos Correios, e com isso, surge outro problema: Qual API de CEP devo utilizar no meu sistema?

O intuito do projeto brcep é não depender que uma API específica esteja atualizada e online, e sim, utilizar o brcep para abstrair qualquer inconveniente de uma API e deixá-la que ela se responsabilize por consultar diversas fontes e retornar as informações do CEP de forma exata, rápida e fácil.

Atualmente suporta as API dos ViaCEP , CEPAberto e Correios.

• Código-fonte: https://github.com/leogregianin/brcep
• Docker image: https://hub.docker.com/r/leogregianin/brcep

Sua ajuda é bem-vinda para implementar novas interfaces para outras APIs.

Esse guia é a espinha dorsal de nossa cultura de engenharia. Eles não são nada sofisticados, apenas um conjunto de expectativas básicas que tentamos seguir.

Esta lista ajuda a equipe a construir soluções melhores e com mais rapidez, não importa a idade ou o nível de senioridade.

0. Datilografia != Engenharia de software

Ir diretamente para a escrita de código, na maioria das vezes, leva a um código ruim e a uma engenharia ruim. A maioria das batalhas é vencida na mente e na caneta e no papel antes mesmo de começar.

As pessoas “datilógrafas” se concentram apenas em escrever código para fazer algo funcionar. As pessoas engenheiras de software têm uma visão muito mais ampla, concentrando-se no problema e em todos os aspectos da solução. Dividir a solução em componentes menores, tendo um panorama geral em mente e descobrir como tudo se encaixa no final.

As pessoas com a mente na engenharia do software constroem para escala e sustentabilidade, em vez de apenas criar uma solução de curto prazo.

1. “import lib”

A vida é curta demais para reinventar a roda.

Não perca tempo construindo suas próprias ferramentas ou bibliotecas se já houver algo que faça o mesmo trabalho. Sempre que possível, amplie as bibliotecas existentes e contribua de volta. Isso ajuda a obter uma imagem clara do que o trabalho de outras pessoas faz e como se encaixa no que estamos construindo. Também permite que outras pessoas se beneficiem de seu trabalho, assim como nós nos beneficiamos dos outros trabalhos.

2. Com grandes poderes vêm grandes responsabilidades

Não somente nossos clientes diretos são impactados pelo que geramos no Lucro Rural, o que fazemos trazem mudanças reais para milhões de pessoas.

Cada escolha que fazemos em nossa plataforma e cada recurso que criamos deve ser pensada com muita responsabilidade.

É importante questionar cada escolha, uma vez que afetará milhões de pessoas. Certifique-se de saber o que usar, quando usar e até mesmo por que está usando em primeiro lugar. Às vezes, os problemas mais difíceis têm as soluções mais simples.

3. Fracasse rápido e continue aprendendo

Temos problemas grandes para resolver e muitas maneiras possíveis de resolver cada um deles. A melhor maneira de descobrir qual solução é a melhor é agir rapidamente e testar várias soluções possíveis.

Fracassar rápido significa fazer várias iterações rápidas e aprender com cada uma, em vez de ficar preso/emperrado a uma solução ou decisão. (No entanto, não se trata de construir coisas sem conhecer suas limitações ou problemas!) Sempre que estiver preso/emperrado, converse com outras pessoas — elas podem ter uma solução alternativa mais rápida ou melhor.

4. Conheça a sua casa

“Conhecer sua casa” significa conheçer o problema que está resolvendo, conhecer a plataforma e conhecer os problemas reais dos produtores rurais, isto é uma parte crucial da engenharia.

Não é suficiente saber o que funcionará e quando funcionará. É tão importante saber o que não funciona e quando não funciona.

5. “No meu computador funciona”

Se algo está quebrando, há um problema no código. Nunca é um problema mágico ou uma ocorrência aleatória, porque não é assim que o código funciona. É uma ciência exata, lembra?

Esperamos que nossas pessoas da engenharia descubram o que causou a quebra, não limpem as mãos e passe o problema para outra pessoa. Pense no que está acontecendo por debaixo dos panos.

Essa ideia também é importante para a escolha de tecnologias ou ferramentas. Pense por que algo é melhor e o que o torna melhor. A ferramenta A pode ser boa para resolver o problema B, mas isso não significa que a transição para a ferramenta A resolverá magicamente todos os seus problemas. Geralmente há uma compensação envolvida.

6. Meça o que for mensurável

Medir o que construiu pode não parecer um bom uso do seu tempo, visto que poderia ser gasto na construção do próximo recurso/novidade para a plataforma. No entanto, configurar sistemas para medir um produto fornece dados reais com os quais trabalhar.

As medições também são cruciais quando se começa a construir em escala. Se não medirmos como o produto está respondendo a mais usuários ou solicitações, é fácil ocorrer problemas ocultos que o farão quebrar no futuro.

Depois de ter os dados, podemos usá-los para qualquer coisa — talvez isso nos ajude a decidir sobre o próximo recurso para seu produto ou mostre como otimizar uma determinada seção do produto. Não importa o que nós façamos com os dados, tê-los nos coloca um passo mais perto de tomar melhores decisões baseadas em dados.

7. Automatize tudo o que for repetitivo

Nossa tendência básica deve ser automatizar sempre que possível, em vez de fazer as tarefas manualmente.

A automação nos dá mais tempo para trabalhar na construção do produto real. Queremos que os sistemas façam nossas tarefas repetitivas e tediosas, em vez de ter humanos passando suas noites fazendo essas tarefas. No entanto, tome cuidado para não perder muito tempo com otimização!

8. A otimização prematura é a raiz de todos os males

A otimização é importante, mas não deve ser feita muito cedo. Escolha as batalhas certas para lutar na hora certa.

Se otimizarmos muito cedo, gastará e gastará novamente muito tempo e ainda assim não obterá a solução mais otimizada. Espere até que seu produto esteja totalmente “cozido” e “azeitado” (expressão nossa) e otimize o que precisa ser otimizado.

9. Em caso de dúvida, pergunte!

Emperrado ou confuso? Pergunte! Alguém terá uma solução, ou pelo menos uma ideia para você começar no caminho certo.

Apenas lembre-se, certifique-se de fazer sua pesquisa com antecedência e escolher os próximos passos cuidadosamente. Nunca opte por uma abordagem que você ou outra pessoa certamente pensa que funcionará sem saber por que funcionará ou sem quaisquer dados ou fatos objetivos para apoiá-la.

A biblioteca bancocentralbrasil criada por mim a alguns anos faz a busca das taxas oficiais de Inflação, Selic, Poupança, Dólar, Dólar PTAX, Euro e Euro PTAX atualizadas diariamente e diretamente do site do Banco Central do Brasil.

Instalação

A instalação da biblioteca segue o mesmo padrão da instalação de qualquer outra biblioteca Python, usamos o pip (Python Package Index):

pip install bancocentralbrasil

O pip instalará a única dependência que a biblioteca utiliza, que é a requests.

Utilização

Para importar a biblioteca e começar a utilizá-la:

import bancocentralbrasil

Para buscar os dados do câmbio como o valor do dólar para compra e para venda:

from bancocentral import Cambio

cambio = Cambio()
cambio.get_dolar_compra()
cambio.get_dolar_venda()

Para buscar os dados da taxa Selic atual:

from bancocentral import Selic

selic = Selic()
selic.get_selic_real()

Testes de qualidade do software

A biblioteca contém um alto grau de CD/CI (Continuous delivery e Continuous integration), os testes unitários estão integrados ao serviço do TravisCI e o Code Coverage está integrado ao serviço do Codecov.io.

100% do código-fonte com testes unitários e com 100% de cobertura. \o/

Licença de Uso

O software foi escrito sob a licença MIT, que dá a permissão para uso comercial, livre modificação e distribuição e ao uso privado do código-fonte.

Mais informações

Código-fonte da biblioteca: https://github.com/leogregianin/bancocentralbrasil

A biblioteca “ffn — a financial function library for Python” contém muitas funções úteis para se trabalhar com finanças quantitativas, fornecendo uma vasta gama de utilidades, desde medição e avaliação de desempenho até gráficos e transformações de dados.

O dados são obtidos do Yahoo Finance que fornece todos os dados históricos de todas as Ações, Stocks, FIIs, ETFs e Reits negociados em todas as Bolsas de Valores do mundo.

Instalação

A instalação da biblioteca segue o mesmo padrão da instalação de qualquer outra biblioteca Python, usamos o pip (Python Package Index):

pip install ffn

O pip instalará inicialmente todas as dependências da ffn até que tudo esteja instalado, inclusive a ffn.

Outra opção muito interessante é a instalação da distribuição Anaconda onde ela já disponibiliza pre-instaladas todas as bibliotecas necessárias para análise de dados em geral, bibliotecas muito utilizadas para este fim como Pandas, Numpy, Scipy e outras. Com o Anaconda é possível utilizar o editor Jupyter para programar e trabalhar com o ffn.

Utilização

Para importar a biblioteca e começar a utilizá-la:

import ffn

Para buscar os dados da Apple e da Microsoft desde 2010:

price = ffn.get('aapl,msft', start='2010-01-01')

Vamos comparar o desempenho relativo de cada ação graficamente:

ax = prices.rebase().plot()

Vamos analisar os dados quantitativos de quatro gigantes do mundo da tecnologia: Apple, Microsoft, Amazon e Google.

price = ffn.get('aapl,msft,amzn,goog', start='2010-01-01')

Análise da performance de cada uma:

stats = price.calc_stats()
stats.display()

As estatísticas acima nos mostram que, por exemplo, a Amazon retornou ao acionista 1351% de 04-jan-2010 até 05-set-2019 \o/

Falando em ações do Brasil…

Vamos analisar de maio de 2018 a julho de 2019 como alguns bancos brasileiros performaram.

Dois dos maiores bancos de varejo do Brasil: Itaú (ITUB4) e Bradesco (BBDC4) contra dois bancos digitais em crescente ascensão Banco Inter (BIDI4) e Banco Pan (BPAN4).

import ffn
price = ffn.get(‘bidi4.sa,bpan4.sa,itub4.sa,bbdc4.sa’)
stats = price.calc_stats()
stats.display()

O total de retorno ao acionista do Banco Inter foi de 377,24%, do Banco Pan 453,31% enquanto do Itaú foi de 20,43% e do Bradesco 50,73%.

Mais informações sobre o ffn

A documentação da biblioteca é vasta, existem muitos outros indicadores a analisar. Para visualizar todas as funções disponíveis consulte os links abaixo.

Site oficial: http://pmorissette.github.io/ffn/index.html

Código-fonte da biblioteca: https://github.com/pmorissette/ffn

Quickstart: http://pmorissette.github.io/ffn/quick.html

Documentação da API: http://pmorissette.github.io/ffn/ffn.html

Para ir além

A biblioteca bt (https://github.com/pmorissette/bt), que também utiliza a biblioteca ffn, é um framework Python para realizar backtesting de estratégias de trades. Falaremos mais sobre ela nos próximos artigos.

Cenário

A empresa utiliza um único banco de dados MySQL hospedado no Cloud da AWS para todos os seus clientes. A aplicação conecta diretamente no banco de dados com o driver nativo da linguagem de programação.

Qual o problema disso?

As regras de negócio do software estão todas definidas na aplicação, intrinsecamente conectadas ao emarranhado e macarrônico código-fonte em um gigantesco monolito.

Uma aplicação engessada para ser disponibilizada para outras plataformas como web, celulares ou IoT.

Neste tipo de arquitetura de software não há separação de camadas e foi sendo melhorado e substituído pelos modelos de camadas MVC, MVVM ou MTV (ou MVT) com grande ajuda do mapeamento objeto-relacional ORM.

Além desses modelos, a arquitetura de microserviços e a construção de APIs trouxe ainda mais separação. Podendo ter equipes completamente diversas de backend e frontend no desenvolvimento do mesmo projeto.

Qual a necessidade do cliente?

Antes de mais nada, a empresa necessitava de uma mudança do mindset e uma organização do método de programação adotado na sua equipe como: padrões de projetos, clean code, testes unitários e versionamento do código-fonte.

O projeto necessitava:

1— estar disponível na web.

2— estar disponível para integração com aplicativos nativos para Android e iOS.

3 — ter uma API REST para integrar e ser integrada com outros serviços na nuvem.

4 — ser escalável.

Porque Python e Django?

Python é uma linguagem de programação interpretada, de tipagem dinâmica (ou não) e de propósito geral, ou seja, pode-se trabalhar com ela de diversas formas como ciência de dados, raspagem de dados na web, construção de sites web, desenvolvimento de jogos, construção de APIs, aplicações desktop, scripts para gerenciamento de servidores e muitas outras formas.

A filosofia da linguagem é ser de fácil legibilidade, poderosa e rápida, fácil de aprender e código-fonte aberto. Importe o pacote this para mais detalhes:

>>> import this

Django se descreve como:

um framework web Python de alto nível que incentiva o rápido desenvolvimento e o design limpo e pragmático. Construído por desenvolvedores experientes, ele cuida de grande parte do trabalho de desenvolvimento da web, para que você possa se concentrar em escrever seu aplicativo sem precisar reinventar a roda. É grátis e de código aberto.

Mas porque Python e Django?

Como vou demonstrar na continuidade deste artigo, o Django facilita muito o trabalho na geração dos models a partir do banco de dados já modelado, gerando as classes para cada tabela, além de gerar os forms automaticamente para todos os campos. E para complementar a construção do projeto usamos Django REST Framework para a construção da API.

Porque substituir a linguagem de programação e o framework?

A substituição da linguagem e do framework não é de um dia para outro. Não se apaga tudo e começa escrever de novo do zero.

A estratégia da empresa precisa ser muito bem pensada a longo prazo e a decisão não pode ser com base no último framework da moda.

Django foi escolhido com responsabilidade para o desenvolvimento das APIs, dos novos projetos e na reescrita dos projetos legados.

Instalação do Django e dos pacotes dependentes

Faça o download e a instalação do Python conforme sua plataforma Windows, Mac OS ou Linux/UNIX.

Utilizamos Python 3.6.8, Django 2.1.7 e Django REST Framework 3.9.0

Inicie um ambiente virtual do Python virtualenv para encapsular e isolar o gerenciamento do projeto:

• Windows:

virtualenv venv -p C:\Python36\python.exe
.\venv\Scripts\activate

• Mac/Linux:

virtualenv venv
source /path/to/venv/bin/activate

Instale os pacotes no ambiente virtual pelo gerenciador de pacotes PyPI.

pip3 install django djangorestframework mysqlclient

Você pode especificar a versão do pacote que deseja instalar. Fiz isso pois foi nestas versões dos pacotes que utilizei na implementação desse projeto:

pip3 install django==2.1.7 djangorestframework==3.9.0 mysqlclient

Criação do projeto

1 — Criar um novo projeto Django:

django-admin startproject config .
python .\manage.py startapp projeto

2 — Incluir o novo app no settings.py

INSTALLED_APPS = [
 ‘django.contrib.admin’,
 ‘django.contrib.auth’,
 ‘django.contrib.contenttypes’,
 ‘django.contrib.sessions’,
 ‘django.contrib.messages’,
 ‘django.contrib.staticfiles’,
 ‘projeto’,
]

3 — Configurar o acesso ao banco de dados MySQL no settings.py:

DATABASES = {
 ‘default’: {
 ‘ENGINE’: ‘django.db.backends.mysql’, 
 ‘NAME’: ‘database_name’,
 ‘USER’: ‘root’,
 ‘PASSWORD’: ‘password’,
 ‘HOST’: ‘localhost’,
 ‘PORT’: ‘3306’,
 }
}

4 — Executar o inspectdb do Django:

python .\manage.py inspectdb > models.py

O inspectdb faz a leitura dos metadados do banco de dados e cria todas as classes do model do Django automaticamente. Mapeia todas as tabelas, colunas, tipos de dados, primary keys e foreign keys.

Substitua o arquivo models.py criado pelo inspectdb no lugar o models.py vazio que está no seu projeto.

5 — Registre as classes no django-admin

Após criadas as classes no models.py pelo inspectdb, registre as classes no admin.py para que o admin do Django consiga visualizar e gerenciar as novas classes.

Uma opção é registrar classe a classe:

from django.contrib import admin
from .models import Classe1
from .models import Classe2
...

admin.site.register(Classe1)
admin.site.register(Classe2)
...

Como o assunto deste post é automatizar, vamos automatizar isso também =)

from django.contrib import admin
from django.apps import apps

app = apps.get_app_config(‘projeto’)

for model_name, model in app.models.items():
    admin.site.register(model)

6 — Crie o usuário admin:

python .\manage.py createsuperuser

7 —Criar as migrações dos Models e aplique as alterações no banco de dados:

python .\manage.py makemigrations
python .\manage.py migrate

Criar a API com django-rest-framework

O Django REST Framework (DRF) é um projeto para a construção de APIs, open-source e mantido pela Encode OSS e pela comunidade e financiado por diversas empresas que o utilizam.

O DRF é um projeto independente do Django. O Django foi escrito para servir e facilitar aplicações web tradicionais por meio de templates. Já o DRF foi desenvolvido a partir do Django mas com o propósito de construir web APIs.

Vamos automatizar a construção da API? \o/

Utilizamos o projeto drf_generators com modificações para funcionar nas versões Django 2.x e DRF 3.9.

Este projeto gera todas as Views, Serializers e as rotas (URLs) para a API a partir do Models.py do Django.

1 — Instalação

pip install drf-generators

2 — Incluir o rest_framework e o drf_generators no settings.py

INSTALLED_APPS = [
 ‘django.contrib.admin’,
 ‘django.contrib.auth’,
 ‘django.contrib.contenttypes’,
 ‘django.contrib.sessions’,
 ‘django.contrib.messages’,
 ‘django.contrib.staticfiles’,
 ‘projeto’,
 ‘rest_framework’,
 ‘drf_generators’,
]

3— Executar o comando para a criação das Views, Serializers e URLs:

python .\manage.py generate projeto

Magicamente está tudo pronto!! 🎉 😃 🍻

Os principais verbos HTTP foram implementados (GET, POST, PUT e DELETE) para todas as classes do Models.

Mas ATENÇÃO, a intenção do projeto é iniciar o desenvolvimento da API e evitar o trabalho repetitivo na escrita de cada model, view, serializers e rotas. Não se acomode!

Outras tarefas devem ser feitas a partir de agora, como por exemplo: Autenticação OAuth, JSON Web Token (JWT), documetação da API com Swagger e construir modelos de dados sólidos e robustos.

Conclusão

A decisão da reescrita de um projeto diga-se “legado” deve ser baseado no maior número de dados possível e com muita responsabilidade e deve ser estudado caso a caso, sem fanatismo de linguagem ou framework.

Python, Django e Django REST Framework foram as melhores escolhas para o caso em questão.

Paul coloca no título uma referência a linguagem de programação Python mas não se apegue a isso, de 2004 pra cá mudou muito na área de programação. Entenda a palavra “Python” como qualquer outra linguagem “esotérica”, como ele mesmo descreve.

A reflexão que Graham propõe é que as pessoas que estudam e se dedicam a aprender uma linguagem de programação que não é massivamente utilizada comercialmente, ou que não lhes garantirá um emprego, elas investem tempo nisso pois genuinamente gostam de programar e não estão satisfeitas com as linguagens de programação que elas já conhecem.

Segundo Graham, isso faz dessas pessoas exatamente o tipo de programadores que as empresas deveriam estar interessadas em contratar.

Não é difícil visualizar esse conceito em algumas empresas.

Empresas com a stack essencialmente em uma única linguagem de programação como a Olist buscam programadores Go e Elixir para somar a equipe ou o Google que buscam programadores que tenham experiência em mais de uma linguagem de programação como requisito mínimo.