DEV Community: Guilherme Siquinelli

Angular Typed Forms, a melhor forma de tipar seus formulários

Guilherme Siquinelli — Tue, 06 Aug 2024 06:17:58 +0000

Fora abstrações, existem 3 classes para trabalhar com formulários no Angular.

FormControl
FormGroup
FormArray

Geralmente nossos formulários representam alguma entidade ou modelo da nossa aplicação, principalmente quando falamos de CRUDs, como você pode ver no vídeo.

Porém, o vídeo mostra um exemplo de formulário onde os tipos são inferidos pelo formulário já estarem preenchidos, mas como sabemos, a vida real não é assim que acontece, quem preenche o formulário são os usuários ou o banco de dados. Não acaba aqui, para adicionar a tipagem no formulário não basta apenas colocar nossa classe ou interface como generics, pois o FormGroup não aceita.

Fora que ainda sim, os tipos que importam de verdade, os relacionados a nossas interfaces, ficaram como any.

🤷‍♂️

Nós não queremos saber se é um FormGroup ou um FormControl, o que queremos saber é:

Isso é uma string ou um número?

Para que funcione a interface do mundo real, seria algo assim:

Ou seja, precisamos criar uma segunda interface se adequando.

Praticamente inviável na minha humilde opinião. 🤨

  ___________________________________
 /                                   \
(  mas como isso pode ser resolvido?  )
 \___________________________________/
         \   ^__^
          \  (oo)\_______
             (__)\       )\/\
                 ||----w |
                 ||     ||

Como não encontrei nada parecido na documentação, tive de escrever eu mesmo um tipo que contorne esta dificuldade, que permite setar a interface no FormGroup root e tudo resolvido, e apesar deu ter usado recursividade, ficou mais simples do que imaginei que pudesse ficar.

import {FormArray, FormControl, FormGroup} from '@angular/forms'

export type DetectType<T> = T extends Array<infer U>
  ? FormArray<DetectType<U>>
  : T extends object
  ? FormGroup<TypedForm<T>>
  : FormControl<T>

export type TypedForm<T> = {
  [K in keyof T]: DetectType<T[K]>
}

E veja, funciona mesmo! 🙂

Bom, já vimos que funciona bem com o exemplo de tipo mostrado na documentação, agora vamos adentrar um pouco mais a vida real...

É uma prática comum que objetos como endereço e opções estejam segmentados em outros tipos separados, pois podem ser reutilizados em outras partes da aplicação, desta forma:

type Address = {
  number: number
  street: string
}

type FoodOption = {
  food: string
  price: number
}

type CoolParty = {
  address: Address
  forma1: boolean
  foodOptions: Array<FoodOption>
}

E bom, se o tipo pode ser reaproveitado em outros lugares da aplicação, o formulário também, certo? Minha recomendação é que estes formulários sejam quebrados em partes e usados em conjunto.

É desta forma que costumo fazer:

export class AddressForm extends FormGroup<TypedForm<Address>> {
  constructor() {
    super({
      number: new FormControl(),
      street: new FormControl(),
    })
  }
}

export class FoodOptionForm extends FormGroup<TypedForm<FoodOption>> {
  constructor() {
    super({
      food: new FormControl(),
      price: new FormControl(),
    })
  }
}

export class PartyForm extends FormGroup<TypedForm<CoolParty>> {
  constructor() {
    super({
      address: new AddressForm(),
      forma1: new FormControl(),
      foodOptions: new FormArray<FoodOptionForm>([]),
    })
  }

  addOption() {
    this.controls.foodOptions.push(new FoodOptionForm())
  }

  removeOption(index: number) {
    this.controls.foodOptions.removeAt(index)
  }
}

Isso mesmo, orientação a objetos funciona muito bem pra isso!

E repare outro benefício, na classe PartyForm, criei os métodos addOption e removeOption, que adiciona uma nova opção ou remove do array foodOptions, isso será útil na implementação.

Dá pra melhorar ainda?

Dá sim, vamos facilitar o momento de alteração dos dados, permitindo preencher os dados já no momento da criação da instância.

export class AddressForm extends FormGroup<TypedForm<Address>> {
  constructor(address?: Partial<Address>) {
    super({
      number: new FormControl(),
      street: new FormControl(),
    })

    if (address) {
      this.patchValue(address)
    }
  }
}

export class FoodOptionForm extends FormGroup<TypedForm<FoodOption>> {
  constructor(option?: Partial<FoodOption>) {
    super({
      food: new FormControl(),
      price: new FormControl(),
    })

    if (option) {
      this.patchValue(option)
    }
  }
}

export class PartyForm extends FormGroup<TypedForm<CoolParty>> {
  constructor(party?: Partial<CoolParty>) {
    super({
      address: new AddressForm(),
      forma1: new FormControl(),
      foodOptions: new FormArray<FoodOptionForm>([]),
    })

    if (party) {
      this.patchValue(party)
    }
  }

  addOption(option?: Partial<FoodOption>) {
    this.controls.foodOptions.push(new FoodOptionForm(option))
  }

  removeOption(index: number) {
    this.controls.foodOptions.removeAt(index)
  }
}

Recomendo esta forma de trabalhar com formulário, fica bem prático!

Espero que essa dica seja útil a você leitor.

Um abraço

Numerical formatting from 0 to 99 with autocomplete sorted correctly. TypeScript series: Template literal types

Guilherme Siquinelli — Sun, 27 Aug 2023 22:12:09 +0000

type N = 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

type Note = `0${N}` | `${N}0` | `${N}${N}`

API da Web para Ativação de interação do usuário com a página

Guilherme Siquinelli — Sat, 15 Jul 2023 01:41:39 +0000

Por padrão, o navegador não permite a execução de alguns tipos de conteúdos ou ações sem que antes o usuário tenha ativado algum tipo interação com a página.

Sendo mais específico, algum tipo de interação precisa ser alguma das que listarei abaixo e com alguns requisitos, como:

Eventos de ativação aceitos como interação

keydown (exceto para a tecla Esc ou nenhuma tecla que sirva de atalho para o agente do usuário)
mousedown
pointerdown (apenas se a propriedade pointerType for "mouse")
pointerup (apenas se pointerType não for "mouse")
touchend

Quando algum destes eventos é acionado, o agente do usuário diferencia entre dois tipos de estados de ativação possíveis:

Ativação permanente
Ativação transitória

Ativação transitória

Trata-se de um estado em que a janela indica que um usuário pressionou recentemente um botão, moveu o mouse, usou um menu ou realizou alguma outra interação. Ela expira após um tempo limite (se não for renovada por outra interação) e também pode ser consumida por algumas APIs, como a Window.open().

Aqui está uma lista de APIs da Web que requerem ativação transitória:

Window.open()
Window.showOpenFilePicker()
Window.showSaveFilePicker()
Window.showDirectoryPicker()
Window.getScreenDetails()
Window.queryLocalFonts()
Clipboard.read()
Clipboard.readText()
Clipboard.writeText()
Document.requestStorageAccess()
Element.requestFullScreen()
Element.requestPointerLock()
GPUAdapter.requestAdapterInfo()
HID.requesstDevice()
HTMLInputElement.showPicker()
HTMLVideoElement.requestPictureInPicture()
IdleDetector.requestPermission()
MediaDevices.selectAudioOutput()
MediaStreamTrack.sendCaptureAction()
MediaDevices.getViewportMedia()
MediaDevices.getDisplayMedia()
Navigator.share()
PaymentRequest.show()
PresentationRequest.start()
RemotePlayback.prompt()
USB.requestDevice()
Keyboard.lock()
XRSystem.requestSession()

Ativação permanente

Este estado indica que um usuário pressionou algum botão, moveu um mouse, usou um menu ou realizou algum outro tipo de interação. Ao contrário da transitória, este estado não é redefinido depois de ter sido definido inicialmente.

Lista de APIs da Web que requerem ativação permanente:

Navigator.vibrate()
VirtualKeyboard.show()
autoplay em mídias (especialmente para AudioContext)

API da Web `UserActivation`

Para determinar programaticamente se uma página tem ativação permanente ou transitória do usuário, a API UserActivation fornece duas propriedades que estão disponíveis para consumo usando navigator.userActivation:

UserActivation.hasBeenActive (indica se a página tem ativação permanente)
UserActivation.isActive (indica se a página tem ativação transitória)

Desta forma podemos usar as APIs da Web listadas acima apenas quando uma das respectivas propriedades acima requeridas for verdadeira.

Usando algum dos eventos de interação apresentados no início do artigo, podemos verificar alguma das duas propriedades acima como validação e só então, caso haja interação, o uso da API desejada pode ser utilizada sem nenhum problema.

Assim temos um software mais estável e o mais importante, que respeita seu usuário!

Obrigado a você que leu até aqui e aproveite para deixar um comentário dizendo o que achou do conteúdo.

Abraços!

Injeção de dependências para uma Arquitetura limpa

Guilherme Siquinelli — Wed, 24 May 2023 02:27:05 +0000

Parafraseando Robert C. Martin em seu livro Arquitetura limpa, mais precisamente no capítulo 5, quando fala sobre inversão de dependência (pag 44). O paradigma OO geralmente proporciona maior facilidade para a aplicação da inversão de dependências, este é um dos princípios SOLID e permite direcionar as dependências do código. Assim não precisamos alinhá-las junto ao fluxo da aplicação de forma acoplada e por consequência dificultando mudanças no projeto.

A possibilidade de escolher responsáveis para determinadas tarefas e trocá-los a qualquer momento nos dá poder! E o que fazemos com ele? Por exemplo, você pode reorganizar as dependências do código para que regras de negócio não dependam de componentes front-end ou da técnica adotada e usada até este momento do projeto para acesso a dados.

Note o domínio (regras de negócio) no canto inferior esquerdo, isolado. Enquanto a camada data-access (acesso a dados) faz o intermédio entre ela e as camadas feature e a aplicação, que é onde estão nossos componentes front-end.

Pode não ser intuitivo aos primeiros olhares, mas isso faz com que essas camadas se tornem plug-ins para as regras de negócio, que é onde há menos mudanças e maior valor no software.

Além disso, as regras de negócio, a UI e o acesso a dados podem ser transpilados em pacotes separados e independentes, unidades publicáveis com as mesmas dependências. Contudo, o pacote de regras de negócio não dependerá dos pacotes que contém a UI e o acesso a dados.

Significa que as regras de negócio podem ser implantadas independentemente da UI e da camada de acesso a dados. Que por sua vez, permite que haja deploy em momentos diferentes, independentes, permitindo que times diferentes trabalhem em seus respectivos pacotes sem impactos entre eles. Pois mudanças em componentes da UI ou do acesso a dados, por exemplo, não devem ter nenhum efeito negativo sobre as regras de negócio.

Veja este repositório: getlab, ele está dividido em pacotes como camadas e suas respectivas responsabilidades, como abordado até agora. A branch main, a camada de acesso a dados, está usando Storage do navegador como base de dados.

Para fazer a substituição de Storage para acesso a uma API REST com persistência em uma base NoSQL, foi necessário implementar as classes responsáveis por isso, ou seja, classes concretas para TeamRepository e ScheduleRepository, depois substituí-las nos registros de dependências. Como está na branch mongodb.

Se antes estávamos usando desta forma

register({
  for: TeamRepository,
  use: TeamStorageRepositoryImpl,
});

Podemos apenas alterar quem será usado a partir de agora

register({
  for: TeamRepository,
  use: TeamHttpRepositoryImpl,
});

Veja o código

Agora sempre que pedirmos TeamRepository, teremos uma instância de TeamHttpRepositoryImpl

const teamRepository = inject(TeamRepository)
// TeamHttpRepositoryImpl

Sem que nenhuma alteração em regras de negócios ou componentes da UI fossem necessárias.

Conclusão

Vimos que devemos dividir as responsabilidades do código em camadas, vimos também que uma responsabilidade não deve interferir em outras e que principalmente devemos proteger a camada onde estão nossas regras de negócios. Com isso é possível ter times trabalhando de forma isolada e independentes. Mas como isso pode ser feito?

Vejo duas soluções / oportunidades

Apresentar o design pattern Dependency Injection (Injeção de Dependências);
Falar sobre divisão de camadas utilizando arquitetura em monorepos;

Digo isso pois em uma aplicação Front-end comum, não basta dividir o código em camadas de diretórios para que seja possível executar build como pacotes independentes e é neste ponto que entra a arquitetura de monorepos, no entanto, é um tema que gera assunto para um outro artigo inteiro, então escreverei o próximo aprofundando estes dois assuntos, combinado?

Abraços

SOLID explicado com TypeScript

Guilherme Siquinelli — Sun, 21 May 2023 23:16:30 +0000

Alguns princípios foram criados para ajudar pessoas desenvolvedoras a criar sistemas que sejam fáceis de entender, manter e evoluir ao longo do tempo.

Princípios

Single Responsibility Principle (Princípio da Responsabilidade Única):
Diz que uma classe deve ter apenas uma única responsabilidade e assim, um único motivo para mudar.
Open-Closed Principle (Princípio do Aberto-Fechado):
Diz que uma classe deve estar aberta para novos cenários, mas fechada para modificação.
Liskov Substitution Principle (Princípio da Substituição de Liskov):
Diz que os objetos de uma classe derivada devem ser substituíveis por objetos de sua classe base sem alterar o comportamento do software.
Interface Segregation Principle (Princípio da Segregação de Interface):
Diz que interfaces devem ser separadas para que classes possam depender apenas dos métodos que utilizam.
Dependency Inversion Principle (Princípio da Inversão de Dependência):
Diz que módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações.

Ao seguir esses princípios, conseguimos criar sistemas mais flexíveis, robustos e fáceis de manter, alterar e evoluir ao longo do tempo.

Vamos mergulhar um pouco mais fundo.

Single Responsibility Principle

Ter uma responsabilidade única significa que uma classe deve ter apenas um motivo para mudar. Se uma classe tiver mais de uma responsabilidade, mudanças em uma responsabilidade podem afetar outras responsabilidades, o que pode levar a um código mais complexo e difícil de manter.

Darei um exemplo mais claro sobre o que podem ser consideradas responsabilidades diferentes.

Suponha que tenhamos uma classe chamada User que é responsável tanto pela autenticação do usuário quanto pelo envio de notificações por e-mail.

abstract class User {
  abstract login(email: string, password: string): void
  abstract sendCode(email: string, code: string): void
}

Ela possui responsabilidades diferentes e não segue o princípio SRP. Podemos dividir as responsabilidades em duas classes diferentes.

abstract class Auth {
  abstract login(email: string, password: string): void
}

abstract class Email {
  abstract send(email: string, message: string): void
}

Assim, caso haja uma mudança em uma das responsabilidades, a outra não será afetada, o código estará mais organizado, fácil de entender, testar e manter. O que facilita sua reutilização, pois as classes que têm apenas uma responsabilidade podem ser usadas em diferentes partes.

Open-Closed Principle

Uma classe deve permitir ser estendida para atender a novos requisitos, sem necessidade de alteração, ou seja, deve permitir adicionar novas funcionalidades usando herança, sem afetar o comportamento existente. Por exemplo, temos uma classe abstrata contendo alguns métodos básicos para comunicação com alguma fonte de dados.

abstract class Repository<T, K extends keyof T> {
  abstract findAll(): T[];
  abstract findOne(key: T[K]): T[];
  abstract create(entity: Omit<T, K>): void;
  abstract update(key: T[K], entity: Partial<T>): void;
  abstract remove(key: T[K]): void;
}

Então criamos uma abstração específica com um método contextual, sem alterar Repository.

abstract class UserRepository extends Repository<User, 'id'> {
  abstract findOneByEmail(email: string): User
}

Para seguir o OCP, a classe deve depender de abstrações em vez de implementações concretas. Isso significa que a classe deve depender de interfaces ou classes abstratas em vez de depender diretamente de classes concretas. As extensões podem ser adicionadas por meio da criação de novas implementações de interfaces ou classes abstratas, sem afetar o existente.

Liskov Substitution Principle

Uma classe derivada deve ser capaz de substituir sua classe base sem introduzir erros ou comportamentos inesperados. Classes derivadas devem manter a mesma semântica que suas classes base, ou seja, implementações devem cumprir os mesmos contratos definidos em suas abstrações. Caso uma subclasse não possa cumprir essas condições, ela não deve ser considerada apta de implementação da classe base.

Por exemplo, criamos um caso de uso para autenticação.

class SignInUseCase {
  constructor(private repository: AuthRepository) {}

  execute(credential: UserCredential) {
    return this.repository.signIn(credential);
  }
}

Em seguida, criamos uma abstração que será o contrato para garantir que a classe concreta de AuthRepository cumpra o acordo de implementação para o método signIn.

abstract class AuthRepository {
  abstract signIn(value: UserCredential): Observable<AuthResponse>;
}

Agora podemos criar implementações diferentes para AuthRepository que cumpram o contrato, recebendo UserCredential e retornando Observable<AuthResponse>.

Como uma implementação que envia uma requisição HTTP.

class AuthHttpRepositoryImpl implements AuthRepository {
  constructor(private http: HttpClient) {}

  signIn(value: UserCredential) {
    return this.http.post<AuthResponse>('/api/auth', value);
  }
}

E outra como stub, usada apenas durante a execução de testes automatizados.

class AuthStubRepositoryImpl implements AuthRepository {
  signIn(value: UserCredential) {
    return of({ accessToken: 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2Vybm...' });
  }
}

Então se uma classe A depende da classe base B, então uma classe derivada C de B deve ser capaz de ser usada como B, sem afetar o software.

A: SignInUseCase
B: AuthRepository
C: AuthHttpRepositoryImpl e AuthStubRepositoryImpl

Assim o código se torna mais flexível e escalável, pois novas classes derivadas podem ser adicionadas sem efeitos colaterais indesejados, além de ajudar na prevenção de bugs, pois classes derivadas devem ser testadas com relação aos contratos definidos nas classes base.

Interface Segregation Principle

Uma classe deve ter interfaces específicas para as suas funcionalidades, em vez de depender de uma única interface que contenha todas as funcionalidades possíveis.

Por exemplo, se uma classe precisa apenas de um método de leitura de dados, ela deve implementar uma interface que contenha apenas esse método, em vez de depender de uma interface que contenha também métodos de escrita e exclusão de dados.

abstract class UserRepository implements FindOneBy<User> {
  abstract findOneBy<K extends keyof User>(key: K, value: User[K]): Observable<User>;
}

O código se torna mais coeso e menos acoplado, pois dependem apenas de interfaces que precisam, pois temos interfaces mais granulares e específicas, o que facilita a manutenção e reutilização de código. O ISP incentiva a modularidade para que interfaces possam ser adicionadas para atender a novas funcionalidades, sem afetar classes existentes.

Dependency Inversion Principle

Uma classe de alto nível deve depender de uma interface ou classe abstrata ao invés de depender de uma classe concreta de baixo nível.

Um bom exemplo é a implementação que apresentei no Princípio da Substituição de Liskov em que a classe SignInUseCase depende de AuthRepository, que é uma classe abstrata. A substituição entre AuthHttpRepositoryImpl e AuthStubRepositoryImpl quando conveniente, é possível utilizando a técnica de injeção de dependências.

Então, em vez de uma classe de alto nível depender diretamente de uma classe de acesso a dados específica, ela deve depender de uma abstração genérica que represente as funcionalidades que ela precisa.

Alguns frameworks trabalham desta forma por padrão, como é o caso do Angular, quando este não é o padrão do framework que utilizamos podemos usar alguma biblioteca, como a Inversify ou tsyringe da Microsoft.

Assim o código se torna mais flexível e reutilizável, pois os módulos de alto nível são desacoplados dos módulos de baixo nível. Permitindo que diferentes implementações de baixo nível possam ser usadas com a mesma classe de alto nível, sem afetar o código a classe.

Este princípio recomenda um design orientado a interfaces, que é uma abordagem mais modular e escalável para o desenvolvimento de software. Permitindo que equipes diferentes trabalhem sem que uma dependa diretamente do código da outra.

Espero que este conteúdo tenha agregado positivamente com seu conhecimento,

Um abraço.

[]s

Criando um pacote NPM

Guilherme Siquinelli — Sun, 26 Mar 2023 00:29:50 +0000

Você pode adicionar um arquivo package.json ao seu pacote para facilitar o gerenciamento e a instalação por outras pessoas. Os pacotes publicados no registro devem conter um arquivo package.json.

Um arquivo package.json:

lista os pacotes dos quais seu projeto depende
especifica versões de um pacote que seu projeto pode usar usando regras de versão semântica
torna sua compilação reproduzível e, portanto, mais fácil de compartilhar com outros desenvolvedores

Observação
Para facilitar a localização do pacote no site do npm, recomendamos incluir uma descrição personalizada no arquivo package.json.

Campos `package.json`

Os campos `name` e `version` são obrigatórios

Um arquivo package.json deve conter os campos "name" e "version".

O campo "name" contém o nome do seu pacote e deve estar em letras minúsculas e uma palavra, e pode conter hífens e sublinhados.

O campo "version" deve estar no formato x.x.x e seguir o diretrizes de versão semântica.

Campo Author

Se você quiser incluir as informações do autor do pacote no campo "author", use o seguinte formato (e-mail e site são opcionais):

Seu nome email@example.com (http://example.com)

Examplo

{
  "name": "meu-maravilhoso-pacote",
  "version": "1.0.0",
  "author": "Guilherme Siquinelli <email@guiseek.dev>"
}

Criando um novo arquivo `package.json`

Você pode criar um arquivo package.json executando um questionário CLI ou criando um arquivo package.json padrão.

Executando um questionário CLI

Para criar um arquivo package.json com os valores que você fornecer, use o comando npm init.

No terminal, navegue até o diretório raiz do seu pacote.
```
cd /caminho/para/pacote
```
Execute o seguinte comando:
```
npm init
```
Responda às perguntas do questionário da linha de comando.

Personalizando o questionário `package.json`

Se você espera criar muitos arquivos package.json , pode personalizar as perguntas feitas e os campos criados durante o processo init para que todos os arquivos package.json contenham um conjunto padrão de informações.

Em seu diretório pessoal (home), crie um arquivo chamado .npm-init.js.
Para adicionar perguntas personalizadas, usando um editor de texto, adicione perguntas com a função prompt:
```
module.exports = prompt("qual é o seu sabor de sorvete preferido, amigo?", "Gosto de todos");
```

Para adicionar campos personalizados, usando um editor de texto, adicione os campos desejados ao arquivo .npm-init.js:

module.exports = {
    customField: 'Example custom field',
    otherCustomField: 'This example field is really cool'
}

Para saber mais sobre como criar personalizações npm init avançadas, consulte o init-package-json GitHub repository.

Criando um arquivo `package.json` padrão

Para criar um package.json padrão usando informações extraídas do diretório atual, use o comando npm init com a sinalização --yes ou -y. Para obter uma lista de valores padrão, consulte "Valores padrões extraídos do diretório atual".

Na linha de comando, navegue até o diretório raiz do seu pacote.
```
cd /caminho/para/pacote
```
Execute o seguinte comando:
```
npm init --yes
```

Resultado:

{
  "name": "seu-maravilhoso-pacote",
  "description": "",
  "version": "1.0.0",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "repository": {
    "type": "git",
    "url": "https://github.com/seu-usuario/seu-maravilhoso-pacote.git"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "bugs": {
    "url": "https://github.com/seu-usuario/seu-maravilhoso-pacote/issues"
  },
  "homepage": "https://github.com/seu-usuario/seu-maravilhoso-pacote"
}

Valores padrão extraídos do diretório atual

name: o nome do diretório atual
version: sempre 1.0.0
description: informações do README ou uma string vazia ""
scripts: por padrão, cria um script test vazio
keywords: vazio
author: vazio
license: ISC
bugs: informações do diretório atual, se presente
homepage: informações do diretório atual, se presente

Definir opções de configuração para o comando init

Você pode definir opções de configuração padrão para o comando init. Por exemplo, para definir o e-mail padrão do autor, o nome do autor e a licença, na linha de comando, execute os seguintes comandos

npm set init-author-email "example-user@example.com"
npm set init-author-name "example_user"
npm set init-license "MIT"

Como iniciar um projeto TypeScript

Guilherme Siquinelli — Sat, 25 Mar 2023 04:45:35 +0000

Os requisitos básicos para que possamos utilizar TypeScript em um projeto são

Instalar NodeJS
Criar um diretório (pasta) para seu projeto
Configurar o NPM no projeto
Adicionar TypeScript como dependência do projeto
Configurar tsconfig.json no projeto
Nosso arquivo principal
Nossos scripts
Concluindo

Então vamos lá.

Instalar NodeJS

Para instalar o NodeJS recomendo acessar o site oficial, faça o download da última versão LTS e instale em seu computador.

Criar um diretório para seu projeto

Isso pode ser feito utilizando a interface gráfica do seu sistema operacional ou pelo terminal de comandos e caso opte pelo terminal, abra seu VSCode e em seguida abra o terminal clicando no menu superior
"Terminal > New terminal" e então vamos para o comando

Dica
Não é uma boa prática o uso de caracteres especiais como acentos ou espaços para evitar erros de codificação. O ideal é que sejam utilizadas apenas letras e hífen para separação entre palavras.

mkdir nome-do-projeto

Após criado, vamos abrir o projeto recém criado no VSCode

code nome-do-projeto -r

O parâmetro -r indica que queremos abrir usando a mesma janela, evitando termos 2 janelas do VSCode abertas.

Configurar o NPM no projeto

O NPM (Node Package Manager) é o gerenciador de pacotes e com ele podemos usar bibliotecas escritas por outras pessoas ou publicar nossas próprias bibliotecas (escritas em JavaScript ou TypeScript) para que outros projetos usem.

Bibliotecas usadas são dependências, e se tornam necessárias para que nosso código funcione, além disso também devemos informar suas respectivas versões.

Quando executamos o comando npm install estamos fazendo download destas dependências.

Também definimos scripts úteis. São comandos que deixarão nosso fluxo de desenvolvimento mais prático e fazemos isso configurando um objeto { "chave": "valor" } onde a chave é um apelido que podemos escolher como desejarmos, já o valor será o comando que será executado quando invocado através do comando npm run chave

Ao executar

npm init

Responderemos algumas perguntas

Nome do projeto, padrão é o nome do diretório
Versão do projeto, padrão é 1.0.0
Descrição do projeto, padrão em branco
Ponto de entrada principal, o padrão é index.js
Comando para execução de testes
Link do repositório git, padrão em branco
Palavras chaves, padrão em branco
Autor, padrão em branco
Licença, padrão é ISC mas recomendo a GPLv3 Tradução

Adicionar TypeScript como dependência do projeto

npm i -D typescript

O parâmetro -D indica que será uma dependência necessária apenas durante o desenvolvimento e não depois que estiver em produção. Este é o caso do TypeScript, visto que enviamos para produção apenas o código JavaScript gerado a partir do que escrevemos em TypeScript.

Configurar `tsconfig.json` no projeto

Este arquivo indica que esse diretório é a raiz do projeto TypeScript e especifica os arquivos raiz e as configurações de compilação necessárias para o projeto, mais informações neste link

Nosso arquivo principal

Vamos cria-lo com o seguinte comando

code src/index.ts

Em seguida vamos salva-lo.

Agora que temos nosso arquivo no diretório src, vamos alterar nosso tsconfig.json descomentando as linhas 48, 50 e 56 e configurando desta forma

tsconfig.json

  "sourceMap": true,
  "outDir": "./dist",
  "sourceRoot": "./src",

Isso define que o compilador deve procurar arquivos no diretório "src" e o resultado deverá ser salvo no diretório "dist".

Nossos scripts

Um padrão muito utilizado são os comandos "dev" e "build", faremos isso alterando o objeto "scripts": {} no arquivo package.json, com os comandos tsc e tsc -watch, respectivamente.

package.json

  "scripts": {
    "build": "tsc",
    "dev": "tsc -watch",
    "test": "echo \"Error: no test specified\" && exit 1"
  },

A partir de agora podemos desenvolver utilizando o comando npm run dev e toda vez que alterarmos algum arquivo dentro do diretório "src", o compilador do TypeScript irá entrar em ação, colocando o resultado no diretório "dist".

Concluindo

Para saber se está tudo funcionando, adicione um log

src/index.ts

console.log('foi')

E execute

npm run build

Provavelmente foi criado um diretório "dist" com um arquivo index.js e agora executamos

node dist/index.js

Se você viu escrito "foi" no seu terminal, tivemos êxito e temos nosso projeto configurado!

DOM Parser, parse de string para elementos DOM

Guilherme Siquinelli — Sat, 17 Dec 2022 01:31:52 +0000

Faça conversão de código XML ou HTML a partir de texto (string) para um documento DOM

Como funciona

A execução pode ser feita para XML ou HTML, de acordo com o tipo e retornará como resultado um documento (Document). O tipo é informado como parâmetro e são aceitas as opções "text/html" , que por sua vez, invocará o parser HTML ou então "text/xml", "application/xml", "application/xhtml+xml" e "image/svg+xml", qualquer uma das anteriores invocará o parser XML.

Para o parser XML, caso a string não possa ser processada, o documento retornado deverá conter elementos descrevendo do erro retornado.

💬 Note
Scripts não são executados durante o processamento e o resultado sempre será no formado UTF-8.

Caso seja informado um tipo diferente dos mencionados acima, uma exceção TypeError será retornada.

Interface

type DOMParserSupportedType =
    | "application/xhtml+xml"
    | "application/xml"
    | "image/svg+xml"
    | "text/html"
    | "text/xml";

interface DOMParser {
    parseFromString(string: string, type: DOMParserSupportedType): Document;
}

Exemplos

Texto para elementos HTML

export function parseToHTML(value: string) {
    const parser = new DOMParser()
    return parser.parseFromString(value, 'text/html')
}

Texto para elementos SVG

export function parseToSVG(value: string) {
    const parser = new DOMParser()
    return parser.parseFromString(value, 'image/svg+xml')
}

Casos de uso

Vamos supor que eu esteja usando Vite em um projeto e quero criar componentes da web nativos e, os templates ficarão em arquivos separados, algo como isso:

src/elements
├── form
│   ├── control.html
│   ├── control.ts
│   ├── error.html
│   ├── error.ts
│   ├── label.html
│   └── label.ts

Fazendo import de arquivos HTML, ele é recebido como string

import textTemplate from './error.html?raw'

console.log(typeof textTemplate);
// string

Meu arquivo HTML usa o elemento template, então, antes de inserir ao shadowRoot, eu quero encontrar o template usando querySelector e depois clonar o elemento. Para que a busca funcione, precisamos que sejam elementos DOM, correto?

Desta forma eu poderia fazer:

const shadow = this.attachShadow({ mode })
const docTemplate = parseToHTML(textTemplate)
const template = docTemplate.querySelector('template')
shadow.appendChild(template.content.cloneNode(true))

Espero ter ajudado, valeu!
[]s

Arquitetura Front-end

Guilherme Siquinelli — Mon, 19 Sep 2022 09:46:00 +0000

Atualmente, com necessidades mais complexas e equipes numerosas, problemas e erros difíceis de resolver aparecem. É uma tendência natural que projetos se tornem obsoletos com o passar do tempo e, a dificuldade de mantê-los atualizados aumenta quando temos um número alto de dependências, fazendo com que a entropia do projeto cresça, afinal de contas é muito mais fácil adicionar uma biblioteca a um projeto, do que remover uma que está sendo usada em produção e em diversos lugares da aplicação.

É aqui que a arquitetura de software entra em cena, pois ela vê o software como ponto principal para que o produto consiga gerar o valor esperado, planejando um design de alto nível que será o alicerce, a estrutura sobre a qual o software será desenvolvido.

Fazendo uma analogia entre o desenvolvimento de software e a construção de um prédio, o arquiteto faz o desenho considerando suas necessidades estruturais e o uso que é previsto para ele, tanto em casos como intensidade. Então entrega aos engenheiros e técnicos que irão trabalhar na construção.

Isso é muito importante na engenharia de software, porque diferente de um prédio, o software segue sendo construído e modificado sempre, e não concluído em 1 ou alguns poucos anos. É muito comum que novos planos apareçam com mudanças no escopo, o mercado digital é muito mais rápido, não só pelas variações de oferta e demandas, mas também por evoluções de tecnologias usadas.

A arquitetura de software facilita o desenvolvimento de produtos mais robustos e sofisticados, criando diretrizes claras que permitem aos engenheiros saber a todo momento que tipo de código precisam construir para obter os resultados esperados.

Tendo uma visão ampla sobre a vida útil de um software, os arquitetos podem incluir já nos estágios iniciais estruturas chaves que se feitas quando o produto estiver em produção, demandam alto custo de implementação, darei um exemplo. É comum que startups de tecnologia se concentrem mais na funcionalidade e na entrega de resultados imediatos do que na arquitetura e no ciclo de vida de seus produtos.
Isso faz com que elas comecem a usar técnicas que não escalam bem e frameworks fáceis de usar ou que dependem muito de terceiros. Quando aparecem milhares ou milhões de usuários e os investidores exigem escalabilidade com estabilidade, as coisas se complicam.

Alterar a estrutura de uma aplicação que ninguém usa e uma mudança global que afeta milhões de usuários ao mesmo tempo são coisas completamente diferentes, assim como mudar de servidor algo em desenvolvimento ou em produção com uso intensivo, pois em casos de falhas, mudanças assim poderiam custar milhões em perdas. Certamente não é a mesma coisa alterar a linguagem de programação de um aplicativo quando apenas algumas pessoas trabalham nele, que realizar isso com centenas de colaboradores envolvidos.

É pra isso que existe a arquitetura de software, ela ajuda na tomada de decisões críticas a tempo de escolher quais riscos desejam ser assumidos e afetando para sempre o rumo do projeto.

📅 Publicação: 17/09/2022 por Guilherme Siquinelli

ENV vars with Angular & Nx

Guilherme Siquinelli — Thu, 21 Jul 2022 06:13:11 +0000

Primeiro, instale @types/node para que possamos usar process.env em nosso código.

npm install --save-dev @types/node

# Or with yarn
yarn add --dev @types/node

Em seguida, atualize os targets build e serve (no arquivo project.json ou angular.json), para o seguinte.

{
  "build": {
    // NOTA: altere o executor para um que suporte configurações personalizadas do webpack.
    "executor": "@nrwl/angular:webpack-browser",
    // recorte
    "options": {
      // NOTE: This file needs to be created.
      "customWebpackConfig": {
        "path": "apps/myapp/webpack.config.js"
      }
      // recorte
    }
  },
  "serve": {
    // NOTA: altere o executor para um que suporte configurações personalizadas do webpack.
    "executor": "@nrwl/angular:webpack-server"
    // recorte
  }
}

Então, podemos usar DefinePlugin em nossa configuração webpack personalizada.

// apps/myapp/webpack.config.js
const webpack = require('webpack');

function getClientEnvironment(configuration) {
  // Grab NODE_ENV and MY_APP_* environment variables and prepare them to be
  // injected into the application via DefinePlugin in webpack configuration.
  const MY_APP = /^MY_APP_/i;

  const raw = Object.keys(process.env)
    .filter((key) => MY_APP.test(key))
    .reduce(
      (env, key) => {
        env[key] = process.env[key];
        return env;
      },
      {
        NODE_ENV: process.env.NODE_ENV || configuration,
      }
    );

  // Stringify all values so we can feed into webpack DefinePlugin
  return {
    'process.env': Object.keys(raw).reduce((env, key) => {
      env[key] = JSON.stringify(raw[key]);
      return env;
    }, {}),
  };
}

module.exports = (config, options, context) => {
  config.plugins.push(
    new webpack.DefinePlugin(getClientEnvironment(context.configuration))
  );
  return config;
};

Agora, quando definimos variáveis em nosso arquivo .env, como...

# apps/myapp/.env
MY_APP_API_URL=http://localhost:3333

Finalmente, podemos usar variáveis de ambiente em nosso código. Por exemplo:

// apps/myapp/src/main.ts
import { enableProdMode } from '@angular/core';
import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';
import { AppModule } from './app/app.module';

if (process.env['NODE_ENV'] === 'production') {
  enableProdMode();
}

// This is defined in our .env file.
console.log('>>> MY_APP_API_URL', process.env['MY_APP_API_URL']);

platformBrowserDynamic()
  .bootstrapModule(AppModule)
  .catch((err) => console.error(err));

Você também deve atualizar os arquivos tsconfig.app.json e tsconfig.spec.json para incluir tipos do node.

{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    // recorte
    "types": ["node"]
  }
  // recorte
}

Agora basta servir a aplicação e sua variável estará no console do browser : )

Nota:
Isso foi testado em ambiente com versões:
  "@nrwl/angular": "^14.4.3",
  "@nrwl/workspace": "14.4.3"

valeu
[]s

Você é autodidata?

Guilherme Siquinelli — Sat, 16 Jul 2022 16:17:49 +0000

Antes de qualquer coisa, vamos quebrar um mito aqui.

Pessoas autodidatas não são pessoas que lêem uma única vez sobre algum assunto, absorvem, entendem e aprendem tudo o que leu pra sempre, como alguém que tivesse memória fotográfica, não. Pessoas autodidatas não são gênios.

Pessoas autodidatas são pessoas teimosas, insistentes, perseverantes e por último e mais importante, são pessoas que não acham que errar é um problema.

Elas têm o erro como o primeiro passo para solução, descobrir que está fazendo algo errado, é descobrir que está fazendo algo que ela julgava estar da forma correta, da forma errada. Aceitar o erro não é uma tarefa difícil para ela, mas sim uma oportunidade de fazer da forma certa.

O segundo passo é identificar onde está o erro ou o quê está sendo feito errado e mais uma vez, isso nem de longe é motivo pra se aborrecer, pelo contrário, quando uma pessoa autodidata encontra onde está o erro, isso é motivo de alegria, como alguém que encontra a pista perfeita num jogo de palavras cruzadas.

O terceiro passo é entender o problema, o motivo pelo qual a forma que estava sendo feita não funcionava, e então tentar de alguma outra forma que faça mais sentido para atingir o objetivo do que se está fazendo.

O que é, então, ser autodidata?

Ser autodidata é fazer ciência com as suas ações, experimentando com a ajuda da razão, a lógica misturada a tentativa e erro até que chegue o momento em que os erros não apareçam mais naquela situação.

Quando alguém se sujeita a não ser autodidata, (sim, usei o termo sujeita, pois automaticamente ela está sujeita a algo que ela não controla) ela está sujeita a limitação do que lhe é entregue como verdade. Mas e quando algo que ela aprendeu apresenta inconsistências, apresentando resultados inesperados e nos piores casos, resultados indesejados? Qual a solução? buscar quem ensinou, reclamar e pedir pra ensinar da forma correta para que não apresente mais erros? não é bem assim que as coisas funcionam no mundo real...

E antes que eu me esqueça, é importante colocar alguns pingos nos i 's... Não estou dizendo que pessoas autodidatas devem aprender apenas com seus próprios erros, abandonando todo conhecimento externo... não, jamais, isso seria loucura!
Muito pelo contrário, pessoas autodidata também procuram por pessoas com maior domínio em determinados assuntos com a finalidade de absorver ensinamentos que lhe serão entregues, este método na maior parte das vezes tende a ser menos inconsistente inicialmente, devido ao conhecimento que é transmitido de indivíduo para indivíduo ter sido sujeito a testes por pessoas e situações diferentes e em diferentes contextos.

O Ponto aqui é única e exclusivamente sobre não se limitar, sobre ser crítico, curioso, saber experimentar, aprimorar seu raciocínio lógico e outro detalhe de extrema importância, sobre praticar! A prática é a maior de todas as professoras, é quando ela entra em cena que os mitos caem por terra, vale citar um comentário que uma amiga, Ana Elisa, me disse há um tempo atrás, muito pertinente.

Na teoria, teoria e prática são a mesma coisa. Na prática, não.
– Ana Elisa

É na prática que as coisas não funcionam e você precisa resolver o problema, é na prática que você tenta até acertar. É na prática que o problema é resolvido.

Autodidata e cursos

Pessoas autodidatas não fazem cursos? Sim, fazem, não há motivos para não fazê-los, desde que seja acessível a seu contexto.

Lev Vygotsky, psicólogo bielo-russo influenciou o que depois de sua morte se tornou a corrente pedagógica chamada de socioconstrutivismo ou sociointeracionismo. Para ele, a formação se dá numa relação dialética entre o sujeito e a sociedade a seu redor - ou seja, a pessoa modifica o ambiente e o ambiente modifica a pessoa.

Exemplo

Uma criança nasce com as condições biológicas de falar, mas só desenvolverá a fala se aprender com os mais velhos da comunidade
– Teresa Rego

Ainda segundo o psicólogo, toda relação de uma pessoa com o mundo é feita por meio de instrumentos técnicos - como, por exemplo, as da linguagem - que trazem consigo conceitos consolidados da cultura à qual a pessoa está inserida.

Todo aprendizado é necessariamente mediado, seja por uma pessoa dando aula, um livro ou artigo que outra pessoa escreveu e até ferramentas utilizadas no processo de aprendizagem. Isso torna o papel do ensino e do professor mais ativo e determinante. Piaget disse que cabe a instituição facilitar o processo que só pode ser conduzido pela própria pessoa, ao contrário, Vygotsky diz que é importante o primeiro contato de uma criança com novas atividades, habilidades ou informações terem a participação de alguém, e então, a criança "se apropria" dele, tornando-o voluntário e independente.

Cursos são excelentes locais que nos dão um empurrão a mais. Outro ótimo ponto chave que não podemos nos esquecer é o network construído durante a interação com outras pessoas, que é muito valioso, arrisco dizer que seja muitas vezes fator decisivo pro caminho que vem pela frente.

Escolha a dedo onde irá se inscrever, avalie se o conteúdo programático se encaixa com seu objetivo e se os profissionais envolvidos são competentes.

Existe uma receita de bolo?

Alguns meses atrás, em uma conversa de mentoria, listei de forma rápida alguns itens que no momento entendia serem válidos, sempre que houvesse alguma dúvida, para serem lidos na tentativa de identificar se estamos no rumo ideal, que são estes:

Aprenda aprender e onde aprender.
Aprenda consultar e onde consultar.
Aprenda registrar e onde registrar.
Aprenda documentar, entenda que seu colega amanhã pode ser você ontem.
Pense a longo prazo sempre e faça da melhor forma, ah... a melhor forma é relativa contexto e recursos disponíveis naquele dado momento.
Aprenda automatizar tarefas repetitivas.
Não tente, consiga. Pense no passado para encontrar o futuro.
Argumente como se estivesse certa(o) mas ouça como se estivesse errada(o).
Quando souber, fale mais do que ouve e quando não souber, ouça mais do que fale, mas saiba quando sabe e saiba quando não sabe.
Questione, você pode estar certa(o).
Peça conselhos a quem discorda de você..

Técnicas de aprendizado

Uma das características do autodidata é ter boas referências de estudo e consulta, isso é extremamente relevante quando estamos falando de encontrar a resposta que buscamos de forma eficiente e assertiva.

Ficar pesquisando no Google todas as vezes que lhe surge uma dúvida não é a forma mais eficiente, você pode criar um catálogo, usando o favoritos do seu navegador por exemplo. Contendo boas referências sobre determinados assuntos, e quando algum destes aparecer como dúvida, você já sabe onde vai encontrar a resposta!

Posso dar um exemplo que entendo ser um tanto óbvio, contudo tenho visto que não é tão óbvio assim. Como sou engenheiro web, frequentemente aparece alguma dúvida sobre o uso de algum atributo ou outro, o HTML é enorme, e quando a dúvida é muito específica acaba sendo difícil encontrar uma resposta com uma solução assertiva de forma rápida vinda de uma fonte confiável, e também, porque eu perderia meu precioso tempo de vida, procurando outra fonte confiável se eu já sei o endereço da documentação oficial!? Quando conhecemos alguma fonte certeira, vá direto nela!

Mais importante que "decorar" tudo que você lê, é saber onde você vai encontrar as melhores respostas de forma ágil. Melhor ainda é se você optar por escrever um artigo, um post, enfim, publicar algo sobre o assunto, ou melhor ainda: Submeta uma palestra para comunidade, passando tudo que aprendeu para outras pessoas! Apesar disso aparentar algo inalcançável para alguns ou caridosa para outros, no final das contas, acaba sendo para benefício próprio. É uma das minhas técnicas de estudo, não só minha, mas de muita gente no ecossistema de desenvolvimento de software.

Existem diversas técnicas de estudo, uma bem conhecida é a criada pelo físico renomado e que infelizmente já não está mais entre nós, Richard Feynman.

Técnica Feynman

Existem técnicas para se aprender com eficiência, uma delas que se encaixa perfeitamente no modelo de submissão de palestras para comunidade é a técnica de Richard Feynman.

Essa técnica é dividida em quatro etapas:

Escolha um conceito;
Ensine ou finja ensinar a uma criança;
Identifique falhas na compreensão;
Revise e simplifique.

A teoria dele é que existem dois tipos de sabedoria:
Uma delas é focada em saber apenas o nome, e a outra é focada em entender.
Assim, em vez de apenas memorizar datas, nomes e conceitos, ele orienta a ter de fato uma compreensão profunda sobre o tema.

Passo a passo da técnica:

Escolha um conceito ou assunto
A proposta é aprender e vale para todos os assuntos. Dessa forma, escolha um tema que desejar, pode ser uma lei, uma fórmula matemática, uma escola literária, um tipo de meditação ou qualquer outro conceito. Quanto mais específico, melhor.

Liste o nome do conceito no cabeçalho de uma folha e abaixo dele escreva tudo o que você sabe sobre ele. Ao longo da técnica, você provavelmente irá aprender mais coisas sobre o conceito, anote também na folha.
Ensine para uma criança
A segunda etapa consiste em ensinar ou simular a explicação do conceito para uma criança. Você pode fazer isso de forma escrita ou oral, mas é importante transmitir essas informações de forma clara e simples.

Evite: terminologias complexas e jargões;
Seja: breve e criativo.

Certamente você encontrou lacunas no seu conhecimento e teve coisas que não soube explicar. Aqui é o ponto onde o aprendizado acontece, e você deve se perguntar: “o que deixei passar?” e “o que eu ainda não sei?”
Identifique falhas na compreensão
Feito isso, anote as falhas na compreensão e volte para a pesquisa. Utilize suas anotações iniciais, recorra ao google, consulte livros, apostilas, slides, etc... Estude!
Revise e simplifique
A última fase consiste em revisar todo o conteúdo e simplificar sua linguagem e organização. Após isso, leia em voz alta o que foi escrito e veja se há linearidade e coerência na sua explicação.

Originalmente, Feynman aplicou a sua técnica para explicar os fundamentos da física de partículas, algo que é extremamente difícil. Esse seu trabalho ajudou outros cientistas a rastrear os movimentos das partículas a partir de ilustrações e equações visuais.

Professor Pier

Outra lenda que tem excelentes dicas sobre como aprender, é o Pierluigi Piazzi ou Professor Pier.

Este foi o primeiro vídeo que assisti dele, me lembro que fiquei abismado com as palavras dele fazendo meu tico e teco darem um empurrão um ao outro, acreditando ainda mais que o futuro é autodidata, ainda mais com a ajuda desse mar de informações espalhadas na rede que chamamos de Internet. Temos muito a agradecer ao Sir. Tim Berners-Lee, por essa imensurável contribuição ao nosso mundo.

Mas e você, é autodidata?

Comente aí embaixo qual sua melhor técnica de estudo para que ajude outras pessoas a tentarem de outra forma, afinal, cada um deve encontrar qual seu melhor método de aprender.

Por que os desenvolvedores precisam de um plano de carreira

Guilherme Siquinelli — Sat, 08 Jan 2022 13:33:22 +0000

Se você não tem destino, não importa em que direção você está viajando.
Geralmente esta não é uma tarefa difícil, pois nos mantém numa zona de conforto "boa".

"Acho que todos deveriam experimentar uma derrota pelo menos uma vez na carreira. Você aprende muito com isso."
-- Lou Holtz

Esta é uma frase já traduzida dele, que é um jogador de futebol americano, mas sem mais devaneios, é hora de adentrar ao assunto que trataremos.

Desenvolvedores muitas vezes reviram os olhos quando lhes pergunto se eles tem um plano de carreira ou sabem qual é o papel dos seus sonhos. Planos de carreira parecem muito comerciais e enfadonhos para desenvolvedores interessados em codificar.

Provavelmente você obterá uma resposta diferente se perguntar a alguém se essa pessoa gostaria de receber mais dinheiro, de ter uma carreira de sucesso ou trabalhar em uma função que goste.

Perguntas diferentes, mas a solução é a mesma. Você precisa saber para onde está indo e, em seguida, fazer um plano de como chegar lá.

Às vezes, para obter uma resposta diferente, você precisa perguntar de uma maneira diferente e inverte-la negativamente é uma forma.

Você desistiu de sua carreira ou progressão?

É esta função em que você ficará feliz trabalhando pelo resto de sua carreira?

Usar uma pergunta negativa ajuda o desenvolvedor a ver se ele não tem um plano que está escolhendo para permanecer em sua função atual.
O desenvolvedor é a única pessoa que pode fazer o trabalho necessário e imprescindível para progredir na carreira. Claramente existem outros envolvidos no processo, porém, de nada importa se o maior interessado não agir conforme a premissa.

Planos

Se você não sabe para onde está indo ou a função que deseja, acabará desempenhando a função que outra pessoa deseja que você desempenhe. Essa função irá beneficiar a empresa e, se você tiver sorte, irá beneficiar você também.

Na maioria das vezes, o desenvolvedor obterá um benefício mínimo porque será colocado em uma função usando habilidades que possui atualmente. É improvável que essas sejam as habilidades, conhecimentos ou experiência para que você obtenha uma nova função ou seja promovido.

Os desenvolvedores deixam a responsabilidade por suas carreiras e recompensas para outras pessoas. Eles fazem isso por não terem um plano ou meta para sua carreira e se um desenvolvedor não tiver um plano; significa que o desenvolvedor está seguindo um plano criado pela empresa para qual trabalha.

No livro Alice no País das Maravilhas de Lewis Carroll, um Gato falante pergunta a Alice para onde ela está indo.

Gato: Aonde você vai?

Alice: Qual caminho devo seguir?

Gato: Isso depende de para onde você está indo.

Alice: Não sei.

Gato: Então não importa para onde você vai.

Um desenvolvedor sem plano está dizendo que não importa para onde vá sua carreira ou a função que deseja desempenhar um dia, pois não está se importando o suficiente para influenciar de alguma forma que este rumo não seja perdido.

O planejamento é essencial

Criar um plano é sair da roda do hamster. e avaliar sua carreira. Saber onde você está agora e pensar para onde você quer chegar.

Depois de saber aonde quer chegar, você pode fazer um plano para obter as habilidades, conhecimentos, experiências e contatos para chegar lá.

Nenhum plano de carreira sobrevive ao contato com o trabalho, mas isso significa que você já pensou sobre isso. Conforme o ano avança, suas metas, planos e atividades podem mudar conforme suas prioridades e oportunidades mudam.

Depois de identificar o rumo que deseja para sua carreira, é provável que você perceba oportunidades que o ajudarão com seus objetivos.
Mencionar seus objetivos de carreira para seu gerente e outros colegas convida mais pessoas a ajudar em sua carreira, porque elas também podem procurar oportunidades (se você tiver construído um bom relacionamento)

Planos dão feedback

Você pode lidar com um plano que falhou porque o motivo é que o plano não foi bom ou a execução não foi boa.

É um problema de lógica ou de execução. Você pode refletir sobre isso e, em seguida fazer a mudança necessária. Se você não tem nenhum plano e sua carreira estagna - como saber qual é o problema?

Muitos desenvolvedores não buscam nada e o alcançam, mas no final do ano ficam desapontados por não terem progredido.

Hábitos

Qualquer objetivo significativo ou progressão na carreira envolve a obtenção de novas habilidades, novos conhecimentos, novas experiências e, possivelmente, novas pessoas (conexões, rede e relacionamentos).

Você constrói habilidades, conhecimentos e experiências fora de seu trabalho diário, onde usa habilidades que já possui.

Você precisa colocar as ações em seu calendário e fazer com que essas melhorias se tornem um hábito regular.

Qualquer plano que você seguir precisa ser dividido em tarefas e registradas no diário para então serem transformadas em hábitos.

Espero que esta reflexão também ajude outras pessoas desenvolvedoras.

Post original em inglês