DEV Community: Hildeberto

Abraçar mudanças (IV)

Hildeberto — Mon, 07 Nov 2022 11:11:53 +0000

Este é o quarto artigo de uma série sobre Git. Veja os outros artigos:

I - Controle de versão
II - Configuração
III - O que há por baixo dos panos
IV - Comandos mais usados
V - Fluxo de trabalho
VI - Serviços Git na web
VII - Contribuindo com código aberto

Comandos mais usados

Há muito material disponível na rede, sobre comandos do git. Vou apenas colocar os que achei mais interessantes na última pesquisa que fiz.

Git fichas

Um ótimo projeto, para um conhecimento granular dos comandos git é o Git Fichas, criado e mantido por Jessica Temporal.

Posts da Jéssica sobre git, na plataforma dev.to:

Outras referências

São algumas recomendações para o aprendizado dos comandos mais usados no git.

Abraçar mudanças (III)

Hildeberto — Mon, 28 Dec 2020 15:01:52 +0000

Este é o terceiro artigo de uma série sobre Git. É um assunto extenso que será dividido em:

I - Controle de versão
II - Configuração
III - O que há por baixo dos panos
IV - Comandos mais comuns
V - Fluxo de trabalho
VI - Serviços Git na web
VII - Contribuindo com código aberto

O que há por baixo dos panos

O Repositório do Git é uma pasta, denominada .git/, criada pelo comando git init numa pasta "raiz", em que se quer rastrear mudanças.

O repositório é controlado pelo Git, e raramente o usaremos diretamente. Através de um sistema de arquivos "paralelo" ao do sistema operacional e um banco de dados do tipo "chave-valor", são gerenciados os elementos necessários para o controle de versões.

Cada elemento no repositório tem um identificador único (hash), para manter a integridade dos dados. Ali, os dados serão sempre incluídos (não há exclusão). Pastas e arquivos rastreados, marcações sobre as alterações, metadados e objetos internos, usados pelo Git para cumprir suas funções.

Uma das maiores contribuições do Git, em relação ao controle de versão, é a forma como armazena as alterações, cujas consequências principais são a economia de espaço em disco e a capacidade de "ramificar" facilmente o trabalho, muito menos custoso que as ferramentas anteriores (CVS, SVN).

Commit

Um dos elementos principais do controle de versão são as confirmações de alterações selecionadas, comumente chamadas "commits", que são tratadas pelo Git como instantâneos ou "snapshots", que propiciam a maior parte da funcionalidade da ferramenta.

Os arquivos da pasta em que se encontra o repositório, também chamada área de trabalho (working area), podem estar em algum desses estados:

Não rastreado (untracked): enquanto não for adicionado, ao menos uma vez, ao índice de confirmações (Stage index)
Não modificado (unmodified): já é rastreado pelo repositório, mas não teve alteração, do último "commit" até o momento
Modificado (modified): já é rastreado pelo repositório e teve alteração, desde o último "commit"
Confirmado (staged): novo arquivo adicionado ao rastreameno do repositório ou arquivo já rastreado, modificado desde o último "commit" e adicionado ao índice de confirmações (stage index)

Vale ressaltar, aos falantes de português, que a palavra "stage" significa "palco" e "to stage", "encenar". Por que traduzir como "confirmação", ou "confirmado"? "Entrar em cena" é **confirmar a participação do ator no espetáculo**...

O "commit" registra, num formato interno, as confirmações adicionadas ao índice, atribuindo-lhes um identificador único (hash), e associando a uma mensagem fornecida que, geralmente, explica as alterações enviadas ao repositório.

O instantâneo do repositório registra os arquivos não modificados, através do identificador (hash) do último "commit" daquele arquivo, e, dos arquivos modificados, além da última modificação até então, registra "o que" mudou (a diferença entre o anterior e o atual).

A economia de espaço em disco é notória, com essa opção. Não é necessário replicar o arquivo em diferentes instantâneos. Com os identificadores é possível obter um histórico completo do que aconteceu àquele arquivo, e se necessário, reverter a um momento anterior, de qualquer arquivo rastreado.

As alterações armazenadas seguem a seguinte diagramação:

O registro de inclusão, o primeiro commit de um arquivo, vai armazená-lo completo. As alterações seguintes armazenarão apenas o que foi modificado (inclusões, alterações e exclusões de texto, arquivo renomeado, excluído, etc.), sempre através de identificadores únicos (hashs), em cada confirmação.

Ramificações

Outro elemento crucial do Git, favorecido pela arquitetura da ferramenta, é a facilidade de criar ramificações (branches) do trabalho no repositório. Tais ramificações são criadas com o identificador do commit de origem, e terão seus próprios commits, separados do ramo principal.

Novamente, um ganho de espaço em disco considerável. Nas ferramentas anteriores, o custo de uma ramificação era altíssimo (duplicação), além da complexidade para reunir a ramificação ao ramo principal, equivalentemente custosa. Isso foi superado pelo Git e sua arquitetura.

Trabalhar numa ramificação significa ter todos os elementos do ramo principal disponíveis e, sobre eles, construir novidades e alterações sem afetar diretamente o que já existia.

Num determinado momento, em que a ramificação evolui ao ponto em que se quer que faça parte do ramo principal, a reunião (merge) do trabalho é feita de maneira praticamente transparente.

Geralmente, as ramificações são polêmicas entre os desenvolvedores. Entre os que não usam em nenhuma ocasião e os que usam para tudo, há que se ter boa noção de que o trabalho remoto, em equipe, necessita de uma organização ajustada, e que as ramificações ajudam a minimizar a complexidade de tal tarefa.

Distribuído

Outra distinção do Git em relação aos seus concorrentes é a sua natureza distribuída. As operações locais podem ser sincronizadas num repositório remoto.

Essa sincronização, quase sempre, é de ramificações e instantâneos, bem menos custosos para transmissão em rede, por não replicarem os arquivos de forma completa.

Falaremos sobre as ramificações e a distribuição do trabalho, com mais detalhes, em artigo posterior.

Referência:

Git internals, no Git Book

No próximo artigo, uma geral sobre os comandos mais usados.

Abraçar mudanças (II)

Hildeberto — Sat, 19 Dec 2020 14:18:51 +0000

Este é o segundo artigo de uma série sobre Git. É um assunto extenso que será dividido em:

I - Controle de versão
II - Configuração
III - O que há por baixo dos panos
IV - Comandos mais comuns
V - Fluxo de trabalho
VI - Serviços Git na web
VII - Contribuindo com código aberto

Configuração

O comando responsável pela configuração é o git config. O Git tem muitos níveis possíveis de configuração. Trataremos aqui: no repositório, no usuário e no sistema.

Esses níveis são expostos por arquivos-texto que contêm as opções de configuração vigentes. As configurações que não estiverem declaradas nesses arquivos, usarão um valor padrão.

Uma configuração no nível do sistema é gravada pelo comando git config --system, seguido do nome da configuração e do seu valor. Esse par "nome-valor" será salvo no arquivo /etc/gitconfig. E necessário ter permissão de superusuário para configurar o Git nesse nível.

Os valores aplicados serão usados para todos os usuários do sistema operacional. Como exemplo, abaixo o comando que utilizará o valor "main" como nome da ramificação principal, na criação de um repositório:

sudo git config --system init.defaultBranch main

A configuração no nível de usuário é gravada pelo comando git config --global, seguido do nome da configuração e do seu valor. Será salva no arquivo ~/.gitconfig ou ~/.config/git/config, a depender do sistema operacional, sendo o ~, o símbolo da pasta padrão do usuário conectado. Os valores aplicados serão usados para o usuário conectado. Exemplos comuns:

git config --global user.name "Hildeberto" e
git config --global user.email "hildeberto@gmail.com"

usados para ajustar nome e email que serão usados para atribuir as modificações nos repositórios.

git config --global alias.st 'status'

usado para declarar um "alias" (apelido, outra forma de se referir) para o comando "status", que a partir de então pode ser referenciado apenas como "st", ou seja um git st obterá o mesmo resultado que um git status. (falaremos sobre "alias" com mais detalhes)

A configuração no nível de repositório é gravada pelo comando git config --local, seguido do nome da configuração e do seu valor. Será gravado no arquivo .git/config, na pasta do repositório. Os valores aplicados serão usados para aquele repositório específico. Exemplo:

git config --local user.name "Outronome"

vai registrar as alterações do repositório com outro nome de usuário, que aquele definido no nível de usuário.

Para obter a configuração vigente para o repositório em que está localizado, use o comando git config --list.

Qualquer configuração pode ser sobrescrita, ajustada por um valor diferente, por uma configuração de nome igual, na seguinte ordem de precedência: repositório, usuário, sistema.

Ou seja, o que é configurado no nível do repositório sobrescreve a mesma configuração no nível de usuário ou do sistema.

Praticamente tudo é configurável no Git. O comando git help --config listará todas as opções de configuração disponíveis. Mais detalhes podem ser obtidos com o comando git help config.

Referência

Git Configuration (https://www.git-scm.com/book/en/v2/Customizing-Git-Git-Configuration)

No próximo artigo, vamos ver como é a ferramenta "por baixo dos panos".

Abraçar mudanças (I)

Hildeberto — Sat, 19 Dec 2020 13:22:50 +0000

Este é o primeiro artigo de uma série sobre Git. É um assunto extenso que será dividido em:

I - Controle de versão
II - Configuração
III - O que há por baixo dos panos
IV - Comandos mais comuns
V - Fluxo de trabalho
VI - Serviços Git na web
VII - Contribuindo com código aberto

Controle de versão

Nos processos de escrita, nos defrontamos constantemente com um desafio: precisamos produzir (incluir, alterar ou excluir texto); para testar novas possibilidades, descartar coisas que não fazem mais sentido, aplicar novas aprendizagens, é necessário manter versões anteriores, para que se possa perceber a evolução em que a obra foi processada e, eventualmente, retornar a um estágio anterior, desistindo de tais mudanças.

A forma viva dos escritos é o rascunho. A escrita acontece enquanto processo. Tudo é rascunho, até que nos comprometemos com um "momento", para dar a obra como "acabada". Não costumamos enxergar a gradação e evolução numa obra acabada, mas elas estão lá.

Daí, decorre uma lição importante: não se apegue demais ao que escreve, pois tudo flui. Mesmo a obra dada como acabada por um autor, ainda poderá evoluir (ou degradar), ser escrita de forma diferente, seja pelo mesmo autor, seja por outros.

Códigos em linguagens de programação, se beneficiam muito do que chamaremos "controle de versão". É necessário testar antes de distribuir, sempre mantendo a possibilidade de reversão de quaisquer mudanças, e, em algum momento, há o comprometimento com uma estabilidade temporária, que poderá ser distribuída a terceiros.

A ferramenta mais utilizada atualmente para controle de versão é o Git. O objetivo é a fácil recuperação em caso de erros ou perda de arquivos. Os meios: histórico e documentação das mudanças, comparação de diferenças e possibilidade de desfazer alterações, todas elas disponíveis nessa ferramenta.

Termos comuns do Git

Repository (repositório): Uma pasta de arquivos, nomeada .git, criada e controlada pela ferramenta, que armazena objetos internos, metadados e os arquivos e pastas que queremos rastrear. Tem, por padrão uma ramificação (branch) inicial, atualmente denominada "main"
Clone: Cópia, duplicação de um repositório
Working area (área de trabalho): Uma lista de arquivos da pasta sendo rastreada, em que cada arquivo tem um estado, na ramificação ativada no momento: "não rastreado" (untracked), "não modificado" (unmodified), "modificado" (modified) ou "confirmado" (staged)
Index (índice, sumário): Um arquivo do repositório que armazena informação sobre quais alterações farão parte do próximo envio ao repositório. Também conhecida como Staging Area (área de preparação)
Commit (envio, entrega): Confirmação das mudanças incluídas no índice, que são enviadas ao repositório, na forma de "instantâneos" (snapshots, no sentido fotográfico). Um momento de comprometimento
Branch (ramo, galho): Uma ramificação (versão) obtida a partir do ramo principal ou de outra ramificação, cujas confirmações de alterações estão separadas do ramo de origem
Push (empurrar): Transferir arquivos de um repositório fonte (atual) para outro repositório (local ou remoto)
Pull (puxar, extrair): Trazer as últimas mudanças de um repositório (local ou remoto) para o repositório atual.

No próximo artigo, começamos a desentranhar a ferramenta, iniciando pela sua configuração.

Porquê Linux?

Hildeberto — Thu, 08 Aug 2019 22:43:01 +0000

Para quaisquer linguagens de programação, exceto provavelmente para linguagens mantidas pela e para Apple, o melhor ambiente operacional para a atividade de desenvolvimento de sistemas é o Linux.

O Windows 10 agora permite instalações Linux (WSL), tentando convencer aos desenvolvedores que não precisam mais instalar um Linux em dual boot, ou mesmo desinstalar o Windows.

Eu afirmo que, qualquer que seja sua escolha, será uma boa escolha. Se quiser experimentar, não vai faltar opção. Eu mesmo já usei CentOS, Red Hat, Debian, Ubuntu, entre outros. O Linux suporta a grande maioria dos servidores corporativos atualmente em atividade. Desde a pequena empresa até os grandes Cloud Providers. Nessas máquinas rodam nossos sistemas.

Desenvolver no mesmo ambiente operacional onde o sistema vai rodar é um importante motivo pelo qual você deve usar esse mesmo ambiente para programar. Além disso, é um ambiente estável, maduro, mais seguro, mais customizável. Enfim, se você não acha que já respondi à pergunta inicial, não perca mais seu tempo.

Minha escolha atual de ambiente operacional para desenvolvimento é o Xubuntu 18.04.2 LTS, versão desktop. Trata-se de uma distribuição Debian-like, com uma interface gráfica (Xfce) leve e eficiente. A interface gráfica, no meu caso, é a mais simples possível. Faço poucas configurações visuais, embora haja muitas disponíveis. (Fontes e temas são fáceis de configurar, e é onde preciso mexer, com certeza.)

Aí é só instalar seu editor de textos ou IDE preferida, um multiplexador de terminal (você deverá usar bastante no processo de desenvolver, não tem jeito), e você estará pronto para começar. Em breve vou detalhar algumas ferramentas que tornam a vida do desenvolvedor mais fácil. Para instalação de linguagens de programação, por exemplo.

Porquê Python?

Hildeberto — Thu, 18 Apr 2019 11:46:54 +0000

Fonte

Por volta de 2010, num período em que eu estava coordenando a equipe de desenvolvimento, e, seguindo orientações dos projetos nacionais da instituição, fizemos todos diversos treinamentos, com o intuito de definir um "processo de desenvolvimento" (concluído, fortemente baseado em RUP) e usar a linguagem de programação Java, para desenvolver os sistemas que seriam usados ora em diante.

Após esse treinamento eu, que já tinha programado em Cobol, C, Pascal, Clipper, Object Pascal, PL/SQL, PHP, até Bash, me senti profundamente incomodado com aquela direção. Uma linguagem tão verbosa, e naquela época, cheia de configurações em arquivos XML, não deveria estar conquistando tanto terreno corporativo. Mas fui voto vencido. Eu participei em cerca de 60 horas de treinamento e não consegui ter nenhum sentimento positivo com Java.

Em 2011, precisávamos definir um CMS para ser usado na intranet. Até pensamos em criar um, usando Java, mas acabamos decidindo não reinventar a roda. Os candidatos eram codificados em Java, Python e Ruby. A equipe já conhecia o Java e partimos num treinamento do Plone, que usa Python como linguagem principal. Em 24 horas de treinamento, eu estava completamente apaixonado.

Porquê Python?

Python é uma linguagem de programação de alto nível, criada em 1991, por Guido van Rossum. Monty Python era um grupo de comediantes ingleses, que inspirou o nome da linguagem.

Uma simples consulta no DuckDuckGo vai trazer várias fontes de referência, com excelentes artigos, palestras e até vídeos, que exaurem bastante bem o assunto da pergunta-título. Cito alguns tópicos que você vai encontrar nesse material:

Linguagem de programação livre e de código aberto, com governança democrática através da Python Software Foundation (equivalente ao que conhecemos por Organização Não-Governamental Sem Fins Lucrativos)
Ideal para iniciantes, pela legibilidade e simplicidade
Com pouco código, rapidamente, você consegue bastante resultado (NÃO É verbosa!)
Tão boa de ensinar como é de aprender. Várias instituições de ensino estão adotando a linguagem como a primeira a ser ensinada aos seus alunos
A versatilidade da linguagem impressiona. É usado para:
- qualquer situação que necessite automação de tarefas repetíveis
- desenvolvimento para janelas (Windows, Linux, Android, iOS)
- desenvolvimento web (frontend, backend)
- análise e manipulação de imagens, vídeos e textos
- inteligência artificial e aprendizado de máquina
- química, biologia, matemática, estatística
- arte digital, música eletrônica, jogos
- operações em servidores
- entre outras tantas possibilidades...
Um conjunto de bibliotecas de código aberto invejável, que garantem a versatilidade citada anteriormente
É uma linguagem desejada no mercado de trabalho. Empresas como Google, Facebook, DreamWorks, Canonical, Red Hat, NASA, são algumas das maiores, que podem ser citadas aqui.
Aprender Python ajuda no aprendizado das outras linguagens
Interage facilmente com outras linguagens
Comunidade de usuários diferenciada em relação à inclusão de pessoas ao ecossistema da linguagem.
A comunidade Python Brasil reúne grupos de usuários em todo o Brasil, interessados em difundir e divulgar a linguagem de programação. Veja a lista e procure a mais próxima de você!
Tem comunidade Python na Paraíba!

Aprenda Python gratuitamente online:

Python para zumbis

Porquê programar?

Hildeberto — Thu, 18 Apr 2019 11:33:52 +0000

Meu desafio pessoal na área de desenvolvimento de sistemas iniciou em 1986, e consistiu, na época, aprender Clipper; para mudar um sistema "corporativo", que emitia folha de pagamento, controlava estoque, imprimia pedidos e notas fiscais, entre outras funcionalidades, com o qual eu já trabalhava como usuário.

Lembro que desejava fortemente alterar coisas do programa. Sequências de menus, disposição de telas, fluxo de certas rotinas, etc. Essas mudanças facilitariam o meu trabalho e o de outros funcionários do escritório. Incentivado pelo próprio desenvolvedor daquele sistema, que me deu acesso ao código, parti para o desafio adolescente que me faria tomar um "rumo" na vida.

Porquê programar?

Mitchel Resnick, diretor do grupo Lifelong Kindergarten, do MIT Media Lab, afirma que a programação é uma das habilidades do século 21, e deveria ser tão importante quanto ler ou escrever. Segundo ele, em um mundo repleto de tecnologia, quem não aprender a programar será programado. Software está cada vez mais em tudo, e a "Internet das coisas" é um próximo passo no caminho da nossa sociedade tecnológica. A importância de aprender a codificar vai além das oportunidades de emprego. Uma das possibilidades desse aprendizado é ver o mundo de outras maneiras.

Outra possibilidade importante, que gosto de ressaltar, é que quem aprende a programar aprimora sua proteção digital, seja individual ou corporativa. Utilizar programas dos quais você pode acessar o código fonte, é uma das formas de garantir melhor sua segurança. Ter certeza que aquele aplicativo que você usa, na empresa ou no seu celular, não está roubando dados sem que ninguém perceba.

Codificar permite, ainda, que se possa contribuir na construção do mundo tecnológico, através da participação em projetos de código aberto, principalmente. E mesmo que não seja um projeto "open source", é possível influenciar a sociedade, a cultura e a economia, entre outras áreas, através da programação de sistemas e aplicativos. Mesmo que não seja sua preocupação "melhorar o mundo", vocẽ vai poder melhorar sua própria vida, criando automatização para tarefas chatas, demoradas e/ou repetitivas, o que vai te possibilitar mais tempo para outras coisas, quiçá mais importantes.

Por último, mas não menos importante, programar pode (e deve) ser divertido!

DEV Community: Hildeberto

Abraçar mudanças (IV)

Comandos mais usados

Git fichas

Outras referências

Abraçar mudanças (III)

O que há por baixo dos panos

Commit

Ramificações

Distribuído

Abraçar mudanças (II)

Configuração

Referência

Abraçar mudanças (I)

Controle de versão

Termos comuns do Git

Porquê Linux?

Porquê Python?

Porquê Python?

Aprenda Python gratuitamente online:

Porquê programar?

Porquê programar?

Aprenda programação online