Forem: Filipe Roberto Beck

Git push/pull de forma prática

Filipe Roberto Beck — Tue, 23 Feb 2021 02:38:33 +0000

Olá, Devs! Gostaria de compartilhar uma forma prática que encontrei para trabalhar com nomes de branches longos. Desde que a grande maioria das vezes o branch remoto a ser atualizado é o mesmo branch local, é possível substituir o nome do branch por HEAD, como git push origin HEAD, por exemplo. Mas eu queria algo que se resumisse à apenas um comando. Então, criei um alias para alvejar sempre o mesmo branch e evitar ter que escrever qualquer coisa a mais. Criei um alias nomeado pushb para atualizar o mesmo branch remoto e outro de nome pullb (não tão usado) para receber as atualizações.

alias.pushb - !git push origin $(git branch --show-current)
alias.pullb - !git pull origin $(git branch --show-current)

Se, por exemplo, o nome do branch local é feature/validate-payment-method-schema, ao invés de ter que digitar:

git push origin feature/validate-payment-method-schema

git push origin HEAD

Basta digitar:

git pushb

Bem mais simples, não? E o comando pode ser usado com qualquer outra opção do git, como -f, por exemplo.

Espero que essa dica possa ajudar outros tanto quanto está me ajudando :)

@willSet/@didSet (sem bugs dessa vez)

Filipe Roberto Beck — Fri, 22 Jan 2021 00:37:26 +0000

Nesse post eu mostrei um exemplo de implementação do decorator @willSet e @didSet. Depois de editar o código 3 vezes devido à bugs, resolvi criar um novo post só postar a versão sem bugs. Estou usando em um projeto de integração da WebAudio API com React. O arquivo é esse.

Web Audio com React

Filipe Roberto Beck — Tue, 18 Aug 2020 00:46:31 +0000

Estou usando o react-reconciler para integrar a API Web Áudio com React. Um preview de como está ficando a implementação de uma reprodução do exemplo Step Sequencer da MDN:

Eu uso a extensão Web Audio inspector do Chrome para visualizar o grapho de áudio

Alguns vídeos que postei no Facebook:

PNPM Package Manager

Filipe Roberto Beck — Sat, 11 Jul 2020 22:33:31 +0000

Estava lendo as atualizações do VSCode e achei isso:

PNPM é um gerenciador de pacotes como o npm e yarn, mas com a grande vantagem de usar um sistema de arquivos endereçável por conteúdo, compartilhando os arquivos entre projetos e entre diferentes versões do pacote.

Typescript - `willSet` e `didSet` com decorators

Filipe Roberto Beck — Thu, 09 Jul 2020 20:46:14 +0000

EDITADO(1): Atualizei o exemplo para permitir o uso de @willSet() e @didSet() em sequência
EDITADO(2): Atualizei o exemplo para invocar @willSet das superclasses depois e @didSet das superclasses antes
EDITADO(3): Agora foi

Achei no Github uma lib bem interessante, chamada classy, para observar mutações em propriedades de forma similar à linguagem Swift usando decorators. Ela é mais abrangente, fornecendo os decorators @classy para a classe e @property para as propriedades, com a possibilidade de definir get e set também. Eu queria algo mais simples, sem a necessidade de decorar a classe, sem get e set e usando diretamente os decorators @willSet e @didSet. O link com o código e exemplos está aqui

Esse recurso é útil quando a propriedade não precisa ser computada mas tem efeitos colaterais. Isso evita a necessidade de criar um setter para os efeitos colaterais e uma propriedade armazenada de nome similar que será atribuída pelo setter antes de manipular os efeitos colaterais.

Gostaria de fazer um app?

Filipe Roberto Beck — Tue, 05 May 2020 20:17:42 +0000

Em 2010 eu estava aprendendo a programar para MacOS/iOS e decidi tentar implementar uma versão 360° do clássico "jogo da cobrinha", onde você controla uma serpente que vai aumentando de tamanho conforme você pega umas pelotas espalhadas pelo cenário, e precisa cuidar para não colidir com as paredes e com o próprio corpo.

Link para um vídeo demonstrativo: https://www.facebook.com/filipe.roberto.beck/videos/326847864065401

Na época, usei basicamente C e C++. Agora, quero refazer (e terminar) em Javascript. Se alguém quiser contribuir com as imagens, ficarei muito agradecido. A príncipio, as imagens necessárias serão:

1 Cabeça
1 Escamas
1 Fundo (disposto em mosaico)
1 Bloco para parede (disposto em fila)

Também seria legal algumas imagens para o logo e tela de recordes.

Caso alguém queira contribuir, é só me enviar uma mensagem 🙂. Se não souber português, não tem problema. Podemos usar um Dependency Inversion Pattern e nos comunicar através da interface Google Translator 🤡

Versionamento semântico com NPM

Filipe Roberto Beck — Sat, 18 Apr 2020 20:12:45 +0000

Vou tentar explicar os conceitos sobre versionamento semântico que considero mais úteis para o usuário. Para informações detalhadas, acesse as fontes no final do artigo.

Versionamento semântico é um padrão de versionamento de APIs que permite a separação entre mudanças que quebram a compatibilidade com versões anteriores (major), mudanças que adicionam funcionalidades sem quebrar a retrocompatibilidade (minor) e mudanças que não afetam a funcionalidade (patch). Consiste basicamente de 3 números separados por ponto.

Patch

É o 3° número. Qualquer atualização que não adicione, remova, ou modifique alguma funcionalidade deve incrementar esse dígito. Ex.: correções de bugs.
Se você quiser manter a versão major e minor de sua dependência e atualizar apenas o patch, inclua um ~ antes da versão no arquivo package.json. Ex.: ~3.4.1 - instala ou atualiza a versão 3.4 que contenha o patch mais alto a partir de 1.

Minor

É o 2° número. Qualquer atualização que adicione funcionalidades sem quebrar o código que usa versões anteriores deve incrementar esse dígito. Ex.: adição de métodos em uma classe.
Se você quiser manter a versão major e atualizar a minor e patch de sua dependência, inclua um ^ antes da versão no arquivo package.json. Ex.: ^3.4.1 - instala ou atualiza a versão 3 que contenha o minor e patch mais alto a partir de 4.1.

Major

É o 1° número. Qualquer atualização que quebre a retrocompatibilidade deve incrementar esse dígito. Ex.: Remoção de uma função ou a remoção/renomeação de um método de classe.
Se você quiser manter a sua dependência sempre atualizada com a última versão, use um * como versão no arquivo package.json.

Fontes:

Documentação oficial: https://semver.org
Documentação do NPM: https://docs.npmjs.com/about-semantic-versioning

Ferramenta para testar a sintaxe: https://semver.npmjs.com/

Typescript - testando dados internos

Filipe Roberto Beck — Wed, 25 Mar 2020 18:57:40 +0000

No post anterior eu disse que abri uma issue no projeto da linguagem Typescript para permitir a exposição de dados internos e facilitar os testes unitários, mas o time da Microsoft acha que é um recurso fora de escopo por não estar de acordo com as semânticas definidas pelo Javascript. Então, criei um pacote no npm com essas atualizações e dei o nome de typescript-x (precisei criar um escopo porque o nome era muito similar a um já existente). Já estou usando ele para testar o pacote ts-infer e esse commit mostra como estou fazendo para usá-lo. Quero destacar dois pontos:

Inferência pelo VSCode

Após instalar o pacote, com npm install @filipe.beck/typescript-x, é necessário adicioná-lo em .vscode/settings.json:

{
  "typescript.tsdk": "node_modules/@filipe.beck/typescript-x/lib"
}

Depois disso, pressione F1 e selecione a versão adequada:

Configuração do projeto

Eu criei uma pasta test com um arquivo tsconfig.json extendendo a configuração original e adicionando a opção testEnvironment. Essa opção vai exportar todos os membros de módulos e publicar todos os membros de classes.

{
  "extends": "../tsconfig",
  "compilerOptions": {
    "testEnvironment": true,
    "outDir": "./js-environment"
  },
  "include": ["./"]
}

E é isso. Com essa configuração, posso acessar todos os dados internos dos módulos ao realizar os testes e manter os arquivos de release intactos.

Adeus, rewire

Filipe Roberto Beck — Sun, 22 Mar 2020 00:38:31 +0000

Acabei de criar uma issue no projeto da linguagem Typescript sugerindo a adição de uma opção que permite expor todos os membros de módulos e classes. Já criei uma implementação inicial que, até o momento, está funcionando como esperado (tanto a emissão dos arquivos quanto a inferência).

Qualquer contribuição será muito bem vinda 😀

Testando tipos genéricos com ts-infer

Filipe Roberto Beck — Wed, 29 Jan 2020 01:34:13 +0000

Entre as linguages de programação que conheço, Typescript é a mais flexível em relção à genéricos. Um exemplo da "magia negra" que pode ser feita está no artigo How to master advanced TypeScript patterns de Pierre-Antoine Mills, criador do ts-toolbel. A complexidade pode crescer ao ponto de se tornar trabalhoso testar se a definição genérica está bem formada. Se formos automatizar com testes unitários usando ts-jest, por exemplo, podemos detectar erros criando testes que instanciam os tipos conforme o esperado e o próprio compilador se encarregará de falhar caso a definição esteja mal formada. Porém, há dois problemas com essa abordagem:

Detecção da unidade de teste: ocorre um erro de sintaxe na compilação do arquivo, e não no teste da unidade, além de encerrar a execução do script. O log de saída do teste mostra a linha onde o erro ocorreu, e não o teste onde ocorreu e o resultado esperado.
Testes de cenários inválidos: não é possível verificar se as restrições do tipo genérico estão bem definidas. Se você quiser confirmar se um valor inválido está realmente sendo tratado como erro, não há recursos para isso.

Para tentar resolver esses dois problemas, criei uma lib, ts-infer, que é bem simples de usar. Ela funciona fazendo uso da API do Typescript e do comentário // @ts-ignore. O comentário // @ts-ignore é usado para evitar erros na compilação pelo ts-jest dentro dos callbacks fornecidos para as funções do pacote. Dentro da função, as ocorrências desse comentário serão removidas e o callback será recompilado para que o erro possa ser inferido.

Atualmente, há duas funções exportadas pelo pacote: infer e diagnose. Segue um exemplo de uso:

// `TypeOfProps` infere a união entre os tipos
// das propriedades de uma classe ou interface.
test('união de `Object.TypeOfProps` em conformidade', () => {
  const invalidInferences = () => {
    // A função `infer()` lança uma exceção se encontrar erros de compilação.
    infer(() => {
      interface TProps {
        a: number
        b: any[]
        c: 'c'
        d: never
      }
      // `TypeOfProps` de `<TProps>` deve ser `number | string | any[]`
      let abc: Object.TypeOfProps<TProps>
      // A linha abaixo será removida por `infer()`
      // @ts-ignore
      abc = true
    })
  }

  expect(invalidInferences).toThrow()
})
// `PickPropsWithTypes` infere um subconjunto contendo apenas
// as propriedades que extendam um determinado tipo
test('propriedades de `Object.PickPropsWithTypes` em conformidade', () => {
  // A função `diagnose()` retorna um array com os diagnósticos dos erros encontrados
  const invalidInferences = diagnose(() => {
    interface Inter {
      a: string
      b: number
      c: string
      d: boolean
      e: Object
    }
    // `PickPropsWithTypes` de `<Inter, string | number>`
    // deve ser `{ a: string, b: number, c: string }` 
    let pickedProps: Object.PickPropsWithTypes<Inter, string | number>

    pickedProps = {
      // A linha abaixo será removida por `diagnose()`
      // @ts-ignore
      d: true
    }

    pickedProps = {
      // A linha abaixo será removida por `diagnose()`
      // @ts-ignore
      e: {}
    }
  })

  expect(invalidInferences.length).toBe(2)
})

A função infer() dentro do primeiro teste lança uma exceção se o callback fornecido apresentar erros de compilação. Já a função diagnose() no segundo teste retorna uma array com os diagnósticos dos erros encontrados. Ambas removem os comentário // @ts-ignore e depois compilam o callback.

Atuais problemas:

O escopo do callback fornecido se resume às declarações locais desse callback e declarações de importação top-level do arquivo de teste.
É criado um arquivo temporário contendo o código do callback e das importações top-level no mesmo diretório do arquivo de teste.
Baixa performance. O processo de compilação é realizado para cada callback fornecido.

Pretendo fixar esses 3 problemas em uma próxima versão compilando o arquivo de teste inteiro na primeira execução e depois extrair os erros de cada callback. Isso elimina a restrição do escopo, a necessidade de criar um arquivo temporário e o problema de performance.

VSCode - Extensão DEV Community

Filipe Roberto Beck — Mon, 27 Jan 2020 05:37:20 +0000

Estava criando um repositório git para organizar as minhas postagens e usar o vscode para editar os arquivos e depois copiar e colar no editor online, então resolvi pesquisar por alguma extensão relacionada e acabei encontrando uma bem interessante: DEV Community. Basta pesquisar por dev.to e será a primeira da lista (até a data deste post, pelo menos). Aparecerá um novo item na barra lateral de ações cujo conteúdo contém inicialmente as opções de logar, onde você deverá fornecer uma chave para autenticação com a API para manipulação das postagens, e uma outra opção para criar essa chave, onde você será redirecionado para as configurações da sua conta.

Para criar a chave, clique na opção e siga as instruções no site que abrirá (é só digitar a descrição da chave e clicar em gerar). Para logar, clique na opção e cole a chave que você criou.

Após logar você verá uma lista com as suas postagens. Clique em alguma para mostrar seu conteúdo.

Recursos disponíveis:

Edição: Após editar, basta salvar da mesma forma que você faria com qualquer outro arquivo e sua postagem será salva remotamente. Para adicionar uma imagem, clique em Upload images no canto inferior esquerdo do editor e escolha uma imagem para subir pro Imgur. Quando o upload terminar, uma marcação com a url da imagem será criada na posição do cursor.
Preview: Para um preview local, pressione Ctrl + Shift + V para abri-lo em uma nova aba ou Ctrl + K V para abrir lado a lado. A aparência será determinada pelas extensões de visualização de arquivos .md que você tem instalado. Para um preview remoto, basta atualizar a página do seu post após salvar as edições que as mudanças já serão refletidas.
Publicação: Para publicar, modifique o valor do campo published para true na seção meta yaml no topo do post e salve, ou clique com o botão direito no título do post no menu lateral e selecione a opção de publicar.
Criação de novo post: Clique no botão + no menu lateral. Um novo documento com uma seção meta yaml default será criado. Salve e o post será criado remotamente.
Remoção de post: Clique com o botão direito no título do post no menu lateral e selecione a opção de deletar.

Assincronismo, concorrência e paralelismo

Filipe Roberto Beck — Sun, 26 Jan 2020 02:53:34 +0000

Antes de prosseguirmos, vamos esclarecer o que é uma thread: Segundo o Wikipedia, thread é um "fio de execução, também conhecida como linha ou encadeamento de execução". É um fluxo de execução independente que roda de forma assíncrona em relação à outras threads, intercalando as execuções entre elas quando houver um único núcleo, ou executando cada uma em um núcleo separado quando houver mais de um (ou uma combinação dos dois - o que é mais frequente, pois o número de threads geralmente excede o número de núcleos). Em resumo, conceitualmente um grupo de threads em execução rodam de forma independente e ao mesmo tempo.

Algo que pode gerar confusão é que assincronismo, concorrência e paralelismo não são necessariamente exclusivos. Uma atividade paralela também é concorrente, o que por sua vez também é assíncrona. Um é subgrupo do outro, conforme mostra a imagem acima. Vamos esclarecer um a um, do mais geral ao mais específico.

Assincronismo: É qualquer atividade onde a ordem das operações não pode ser determinada. Pode ser duas threads em execução, mas também pode ser uma única thread consumindo eventos de uma fila como, por exemplo, uma aplicação de interface gráfica. Nesse caso, a ordem dos eventos depende do usuário e o programa age de forma diferente dependendo se o próximo evento é uma tecla digitada, um movimento do mouse ou uma ação de fechar.

Concorrência: Refere-se à várias threads em execução simultânea, podendo estarem rodando em núcleos distintos ou intercalando as execuções em um único núcleo. Dois processos executando em um sistema operacional são dois fios de execução concorrendo por clocks da CPU.

Paralelismo: Refere-se à várias threads executando em núcleos distintos. Dois processos executando em uma CPU dual-core, cada uma em um núcleo, são dois fios de execução executando de forma paralela.