Tenho costume de guardar algumas ideias valiosas que fui aprendendo na vida em frases curtas e memoráveis, ao menos para mim.
Uma das ideias que guardo em uma frase desse tipo é:
> "Só existe zero, um e infinito."
A ideia escondida nesta "minha" frase é: As coisas podem acontecer nunca, pode acontecer uma vez, ou podem acontecer infinitas vezes. Se acontecerem duas vezes, a terceira vez e daí em diante, até o infinito, são garantidas.
Durante muito tempo utilizei apenas Linux para tudo; servidor e desktop.
Porém, há pouco mais de um ano, comecei a trabalhar para uma empresa que forneceu um notebook deles para executar o trabalho.
Tive que voltar a utilizar o Windows.
Ainda bem que hoje em dia existe o WSL!
(Não é perfeito. Não é rápido. Mas é bom o suficiente para eu agradecer a existência.)
Para quem ainda não está familiarizado com o assunto...
Não estou falando do World Surf League, nem do Medina ou da Tatiana. : ))
O WSL em questão é o Windows Subsystem for Linux, ou Subsistema Windows para Linux.
Um recurso que permite executar um ambiente Linux dentro do Windows de forma nativa, sem a necessidade de máquinas virtuais pesadas ou de dual boot, soluções que utilizei no passado.
Enfim... Com o tal WSL não me sinto um peixe fora d'água utilizando o Windows.
No Linux a pasta raiz, onde estão todas as subpastas e arquivos do sistema, é a "/".
No Windows a pasta raiz (simplificando) é a "C:\".
Acontece que, ao acessar o Linux com o WSL o conteúdo que vemos na pasta raiz é diferente do que vemos na pasta raiz do Windows, mesmo estando na mesma máquina.
OK. Confesso que era até esperado isso. Cada ambiente possui sua própria árvore de diretórios e seu próprio sistema de arquivos.
Mas, e aí? Como vemos no Windows um arquivo que criei no Linux, ou vice-versa?
Compartilho uma SKILL criada durante o desenvolvimento de um parser básico do formato binário Microsoft Word (`.doc`) para Markdown. Útil tanto para agentes de IA quanto para desenvolvedores que precisam entender ou depurar esse formato:
https://github.com/anselmobd/ms-doc-format-skill
O repositório reúne anotações práticas, exemplos e um utilitário (`dump_fkp.py`) para inspecionar arquivos `.doc`. Foi organizado como uma SKILL para que agentes (ou automações) possam consultá‑lo automaticamente e, ao mesmo tempo, sirva de referência rápida para quem implementa parsers.
Se for útil para seus agentes ou fluxos de automação, confira o repositório e contribua com casos reais ou sugestões.
Necessidade: Remover arquivos da pasta atual quando já existe uma cópia idêntica (mesmo nome e mesmo conteúdo) em algum subdiretório.
Solução: Uma daquelas linhas de shell que parecem feitiçaria, mas resolvem o problema. 😄
find . -maxdepth 1 -type f -exec sh -c '
arq="$1"
nome=$(basename "$arq")
find . -mindepth 2 -type f -name "$nome" | while read -r outro; do
cmp -s "$arq" "$outro" && rm "$arq" && break
done
' _ {} \;
Explicando o comando passo a passo:
Sim! Muita! E novas coisas a cada ano (para não dizer "a cada dia").
Quando ouço reclamações quanto a isso — e são tão comuns que eu também me pego reclamando — lembro de como foi meu aprendizado no início (lá no milênio passado) e de como tudo se transformou.
Foi doloroso, mas também valioso.
Acompanhando a aula de um curso on-line, o professor abordou o tema de versionamento de código.
Além de apresentar a principal ferramenta da área, o Git, ele citou soluções antigas de controle de versão e técnicas utilizadas quando nenhuma solução específica para esse fim estava disponível.
Foi nesse ponto que me lembrei de uma história do fundo do baú sobre "controle de versão". De uma época em que eu nem sabia da existência de "controle de versão".
A história data de antes de eu ter meu primeiro HD.
Sim, houve uma breve época em que tudo o que tudo que tínhamos eram disquetes.
E eramos muito feliz com os disquetes!
Afinal, antes disso, eram fitas cassete ou outros tipos de fitas, magnéticas ou perfuradas.
Ou então, quem tinha acesso a um "computador" (não um "microcomputador"), talvez já tivesse passado pela interessante experiência de utilizar cartões perfurados, cada um representando uma linha de código do seu programa.
Opa!
Desculpem-me ter entrado nesse momento "revival".
Voltemos aos "modernos" disquetes.
O disquete era a principal memória de armazenamento dos micros.
Trabalhávamos, meu saudoso amigo Flávio e eu, com dois projetos em um disquete.
Quanto achávamos importante manter histórico de algum arquivo dos projetos, simplesmente salvávamos uma cópia com outro nome. Isso não era um "controle de versão", era apenas um "cuidado".
Mas, pensamos: E se o disquete "morrer"?
Então, tivemos a "grande" ideia de utilizar dois disquetes ao invés de um.
Assim teríamos "sempre" as últimas duas versões completas dos projetos.
Acabava de nascer nosso primeiro "controle de versão".
Há uns dias a Google divulgou que seu chip quântico, Willow, resolve em 5 minutos um problema que levaria 10 septilhões de anos para ser processado por um
supercomputador.
"Septilhões de anos?!"
"Como assim? Como eles calcularam isso? Como provar se isso é verdade?"
Então, comecei e pensar em como testar se isso é verdade?
Bem... Seria só fazer uma tarefa extremamente rápida nesse tal chip quântico e ao mesmo em um supercomputador.
Blz!
Porém...
Nesta semana encarei um teste de SQL em que me pediram para desenvolver uma query, a princípio simples, mas que deu um nó na minha cabeça ao tentar resolver.
O que me ajudou a chegar a uma solução, depois de alguma pesquisa, foi numerar as linhas, no sentido de atribuir valores inteiros aos registros retornados por um select.
Como eu não tinha o costume de utilizar os recursos de numeração de linhas do SQL, resolvi estudar para melhorar meu conhecimento nesse assunto.
O objetivo deste artigo é dividir com vocês o resultado desse estudo.
[22/11/2024 Uma revisão foi publicada em Medium]
Utilizar um "cache de função" significa armazenar os resultados das chamadas de uma função, evitando reprocessamentos demorados para os mesmos argumentos.
A ideia é armazenar os argumentos (parâmetros) recebidos pela função e o resultado do processamento retornado pela função.
Assim, quando a função recebe novamente os mesmos argumentos, em vez de executar seu processamento para encontrar o resultado, apenas retorna o resultado previamente armazenado.
def vezes_proximo(numero):
print('número =', numero)
proximo = numero + 1
print('próximo =', proximo)
resultado = numero * proximo
print('resultado =', resultado)
return resultado
Ao executarmos essa função pela primeira vez, imprimindo seu retorno:
print(vezes_proximo(2))
Obteremos as seguintes informações:
número = 2
próximo = 3
resultado = 6
6
E sempre que executarmos novamente exatamente o mesmo comando, obteremos o mesmo resultado, como esperado!
print(vezes_proximo(2))
número = 2
próximo = 3
resultado = 6
6
Porém, como evitar esse reprocessamento quando não desejado?
É justamente para isso que utilizamos um cache de função.
Explorando os recursos da biblioteca openpyxl, que permite ao Python ler e escrever em planilhas no formato ".xlsx" (Excel), desenvolvi um script básico para demonstração.
Se você está interessado em manipulação de dados com Python, confira o repositório no GitHub:
https://github.com/anselmobd/opyxl_tst.git
O Minecraft, um dos jogos mais populares da história, com mais de 300 milhões de cópias vendidas, supera até mesmo gigantes como Tetris e Grand Theft Auto. Para quem ainda não conhece, este tutorial básico oferece um guia inicial:
Porque este jogo serve de palco para a criatividade de pessoas "maravilhosamente loucas", como Matt, que construiu uma rede neural utilizando apenas os recursos do Minecraft!
Em época de "big data", em que convivemos com tantos dados, tão naturalmente, armazená-los parece que é algo automático, que simplesmente acontece magicamente, mas a história do armazenamento de dados sempre foi cheia de grandes desafios técnicos.
Já estamos perdendo o contato com os HDs (hard disks), onde, pelas últimas décadas, armazenamos tudo de digital que tínhamos.
Muitos, hoje em dia, já trabalham com computadores que só utilizam SSD (que armazena dados em chips de memória, não em discos).
E muitos mais ainda, só utilizam celulares e, talvez, tablets, onde dados são armazenados desde "sempre" apenas em chips de memória, ou, como é cada vez mais comum, na nuvem.
Porém, hoje vou relembrar o início da era da armazenagem de dados em discos. Talvez possa dizer, o primeiro "HD".
Na época, o "HD" era uma grande revolução. Uma avanço incrível na velocidade de acesso à informação. Afinal, antes só se armazenavam dados em fitas, magnética ou perfurada, ou tecnologias mais limitadas ainda.
O IBM 350 foi o revolucionário primeiro equipamento de armazenagem de dados em discos, "HD".
Há cerca de 2.500 anos, os filósofos gregos já se envolviam em desafios de lógica, explorando problemas que exigiam um pensamento estruturado para alcançar conclusões corretas.
Conhecidos como "problemas de lógica", esses exercícios demandavam a aplicação de regras de dedução e análise para chegar a uma solução baseada nas informações fornecidas.
Em 1847, o matemático inglês George Boole introduziu os conceitos de lógica simbólica, demonstrando que a lógica podia ser representada por equações algébricas.
Boole introduziu três operadores fundamentais: E, OU e NÃO (em inglês, AND, OR e NOT), os quais eram utilizados em um domínio restrito a apenas dois valores: 1 e 0, representando respectivamente Verdadeiro e Falso, ou Sim e Não.
Atualmente conhecida como álgebra booleana, essa estrutura matemática para lidar com o raciocínio lógico se tornou fundamental, não apenas na matemática e na filosofia, mas também na ciência da computação.
Em 1937, cerca de 75 anos após a morte de Boole, o matemático estadunidense Claude Shannon, então estudante no MIT, estabeleceu a relação entre a álgebra booleana e os circuitos eletrônicos, associando os estados lógicos (Sim e Não) a diferentes potenciais elétricos no circuito.
A maioria das pessoas sabe que se utiliza "Fire Wall" para aumentar a segurança de uma infraestrutura de rede.
Mas, será que uma "Lava Lamp Wall" também pode nos ajudar nisso?
A curiosa resposta é: Sim!
Não domino os detalhes técnicos, mas vou resumir o que entendi ao ler sobre isso há alguns anos.
A Cloudflare, uma empresa que oferece uma variedade de serviços de segurança e desempenho para websites e aplicativos, precisa um gerador randômico (aleatório), totalmente imprevisível, para gerar suas chaves de segurança, utilizadas por muitos serviços importantes utilizados ao redor do mundo.
Hoje é o dia internacional da felicidade e primeiro dia do outono.
Não sei se é por acaso que esses dias coincidem, mas fica a reflexão:
Temos que aprender com o outono a deixar para trás as pequenas coisas cujos prazos de validade já venceram.
Às vezes essas pequenas coisas são tantas, que nos impedem de ser felizes.
Não desperdice seu
recurso mais precioso, o tempo, pensando que, se tivesse investido
sabiamente seu tempo no passado, estaria melhor no presente.
Pense apenas em investir sabiamente seu tempo no presente, para "estar melhor" no futuro.
Observações:
- Muita atenção e cuidado ao definir o que é "estar melhor" para você.
- Ao invés de carregar o passado nas costas, carregue apenas uma anotação do que aprendeu com ele.
- 99% da "sorte na vida" é construída com (o título deste artigo) "Escolhas sábias e ação!"
No Brasil, ao nos referirmos à uma data falamos, por exemplo, "14 de março de 2024". Ou, numericamente, "14/03/2024".
Porém, os britânicos (sei lá por que motivo ☺) ao se referirem à uma data, trocam a posição do dia com a do mês, falando "March 14, 2024". Ou, numericamente, "3-14-2024".
Com isso, o dia do ano "14 de março" é escrito por eles como "3-14".
De todos os dias do ano, trocando ou não a ordem do dia e mês, "3-14" é a representação numérica que mais lembra o valor do número Pi (π).
π = 3,1415926535...
Por isso o "3-14", o nosso "14 de março", foi o dia escolhido como o Dia do Pi.
Mas... Por que esse número merece um dia só para ele?
--
Vou lembrar (aos mais distraídos nas aulas de matemática ☺) o que é Pi (π).
E também vou citar alguns marcos históricos na busca do cálculo do Pi (π).
Python oferece historicamente várias formas de formatar um texto.
Desde o uso do operador percentual "%", passando pelo método ".format" e finalmente utilizando "f-string".
Desde o lançamento da "f-string", os mantenedores do Python informam que esta é a forma mais rápida de formatar um texto.
A partir de então, sempre que eu trabalhava em uma rotina que utilizava "%" ou ".format", eu convertia para "f-string".
Porém, em um caso específico, e muito comum em vários tipos de aplicação, a legibilidade piorava, em comparação à versão que eu mais utilizava, ".format".
Para melhorar a legibilidade utilizando "f-string" eu acabava precisando adicionar mais linhas de código fonte.
Como isso acontecia em funções executadas muitas vezes, achei melhor testar o impacto dessa mudança na performance da função.
Aproveitei e medi também a performance das formas mais antigas de formatação.
Ao final dos testes, tive que escolher entre legibilidade e velocidade.
Resolvi trazer para vocês a análise que fiz, pois pode ser útil para outros programadores em contextos similares.
O dia 29 de fevereiro de 2024, dia em que escrevo este artigo, está causando problemas em sistemas de software em todo o mundo.
Um lembrete para todo programador prestar atenção
redobrada quando lida com datas.
Alguns exemplos:
- Na
Suécia, os pagamentos com cartão pararam de funcionar em uma importante
cadeia de supermercados. A ICA é a maior rede de supermercados do país
nórdico e hoje os clientes só podem usar dinheiro.
- Na Colômbia,
as passagens aéreas foram impressas incorretamente pela maior companhia
aérea do país. A companhia aérea Avianca imprimiu passagens com data de
01/03 em vez de 29/02, graças ao seu sistema não contabilizar o dia
bissexto.
- Um jogo de corrida da EA Sports, WRC (World Rally Championship), não pode ser jogado hoje. Simplesmente trava.
Recebi essas curiosas informações pela newsletter do The Pragmatic Engineer, que você pode assinar nessa página: The Pragmatic Engineer
"Ótima explicação sobre LLM para um leigo como eu.", foi o que disse um amigo meu ao me indicar um site no final do ano passado.
Demorei muito a ir conferir a dica, mas achei tão legal que precisava compartilhar.
Lembrando:
LLM, ou Large Language Model (Grande Modelo de Linguagem), é um modelo
de aprendizado de máquina treinado para aprender a partir de enormes
bases de dados públicos, permitindo gerar linguagem para diversos fins.
Este modelo é fundamental para tecnologias como o ChatGPT e o Gemini
(ex-Bard), entre outros.
O artigo indicado é o "Generative AI
exists because of the transformer", do site do jornal Financial Times, disponível neste link.
Infelizmente
o conteúdo é em inglês, mas, hoje em dia dá para ligar o tradutor no
browser e se virar muito bem com os textos em inglês. Nos exemplos as palavras serão traduzidas separadamente e acaba ficando estranho, pois serão palavras em português concatenadas seguindo regras do inglês, mas nada que impeça o entendimento para quem utilizar a tradução.
Confiram!