Pessoalmente, em alguns casos o ts acaba ficando com tipos muito complexos... há situações em que quase desisto (e simplesmente uso any), mas acho que isso é por falta de entendimento da linguagem, né? Dependendo da situação, às vezes perco muito tempo só tentando fazer as linhas vermelhas sumirem.
Tentamos trabalhar com 80% de carga e deixar 20% de folga, mas sempre fico pensando em qual critério usar para isso... Às vezes acho que talvez devesse ser simplesmente pelo tempo.
Quando morei por cerca de um ano em Xangai por um tempo, cheguei a visitar Hangzhou a passeio (na época, para ver algo como um espetáculo de impressão). A cidade era limpa, a paisagem do Lago Oeste também era bonita, então pensei que seria realmente um ótimo lugar para viver. Agora parece que também se tornou um bom lugar para empreender.
O SWC se concentra em gerar código JavaScript compatível, como o Babel, e até em fazer bundling; já isto se concentra em transformar código TypeScript em JavaScript ou verificar erros de tipo.
Quando preciso escrever códigos simples, mas difíceis de decorar (tratamento de entrada/saída de arquivos, manipulação de contêineres etc.)
Quando acontece um erro de compilação ou de execução e preciso entender que erro é esse e qual trecho de código o causou
Quando quero reescrever uma função parecida com outra que já fiz, mas com uma funcionalidade um pouco diferente
Quando quero substituir um código que depende de certa biblioteca por outra biblioteca ou por uma função própria
Quando preciso implementar uma funcionalidade específica ou trabalhar em um ambiente específico e preciso de orientação sobre como desenvolver isso
Em casos como os acima, economizei bastante tempo. Muitas vezes isso também não era fácil de encontrar só com a combinação Google + Stack Overflow, e no Stack Overflow em especial, quando havia alguma resposta, sempre apareciam muitos questionamentos nos comentários, ou diziam que era uma forma de implementação de versão antiga e que não deveria mais ser usada, então havia muitas situações realmente irritantes...
Se dividir em períodos de 1 a 2 semanas, parece natural que apenas um número limitado de pessoas acabe conhecendo a visão de uma funcionalidade. Como a diferença entre processo e thread. A ideia é aumentar a produtividade limitando o foco.
Mesmo que a visão seja compartilhada, isso parte do pressuposto de que haverá questionamentos sobre essa visão; mas acho que também assumi naturalmente que, por causa da direção que vai mudando um pouco a cada sprint planning, não se consegue acompanhar como a visão geral está sendo seguida.
Quando isso é dividido em tarefas tão pequenas, o líder que tem a visão do todo acaba ficando com um grande poder. Os engenheiros que estão junto, por outro lado, acabam desmotivados e pensando: "afinal, para onde estamos indo?" Um dos principais pontos fracos do ágil baseado em sprint.
Parece que foi escrito demais apenas da perspectiva do líder, exatamente como diz o título.
O momentum dos engenheiros também é muito influenciado pela direção para a qual o líder está apontando a bandeira. Também parece necessário pensar um pouco mais sobre como apresentar qual é o valor que se quer entregar ao cliente e quais são o output e o outcome de entrega de cada sprint. Claro, são soft skills difíceis, então é raro ver líderes que façam isso bem, e também não há muitos textos bons sobre isso.
Entendo o .NET, mas acho que Rust está mais na mesma posição que Go. De qualquer forma, imagino que os projetos e bibliotecas de JS relacionados a Go que já existiam também tenham influenciado a decisão.
É realmente uma ideia bem original, mas, como disseram em outros comentários, também fico curioso para saber como eles pretendem resolver o problema caso o tráfego dispare.
Pessoalmente, em alguns casos o
tsacaba ficando com tipos muito complexos... há situações em que quase desisto (e simplesmente usoany), mas acho que isso é por falta de entendimento da linguagem, né? Dependendo da situação, às vezes perco muito tempo só tentando fazer as linhas vermelhas sumirem.Tentamos trabalhar com 80% de carga e deixar 20% de folga, mas sempre fico pensando em qual critério usar para isso... Às vezes acho que talvez devesse ser simplesmente pelo tempo.
Quando morei por cerca de um ano em Xangai por um tempo, cheguei a visitar Hangzhou a passeio (na época, para ver algo como um espetáculo de impressão). A cidade era limpa, a paisagem do Lago Oeste também era bonita, então pensei que seria realmente um ótimo lugar para viver. Agora parece que também se tornou um bom lugar para empreender.
Não há conteúdo sobre o desempenho em coreano, mas, pelo que testei, não parece ruim.
Se tiver recursos para contornar proteções anti-bot... acho que vai se tornar o vencedor do mercado.
Parece que a polêmica está bem quente, tanto que o próprio Anders Hejlsberg deixou um comentário
https://github.com/microsoft/typescript-go/…
Sim, é esse mesmo!
Alguém que gostaria que, ao compilar com TypeScript, o resultado saísse direto como binário
Obrigado por apresentar um material tão bom.
O SWC se concentra em gerar código JavaScript compatível, como o Babel, e até em fazer bundling; já isto se concentra em transformar código TypeScript em JavaScript ou verificar erros de tipo.
Parece bem parecido com a minha experiência.
Em casos como os acima, economizei bastante tempo. Muitas vezes isso também não era fácil de encontrar só com a combinação Google + Stack Overflow, e no Stack Overflow em especial, quando havia alguma resposta, sempre apareciam muitos questionamentos nos comentários, ou diziam que era uma forma de implementação de versão antiga e que não deveria mais ser usada, então havia muitas situações realmente irritantes...
Se dividir em períodos de 1 a 2 semanas, parece natural que apenas um número limitado de pessoas acabe conhecendo a visão de uma funcionalidade. Como a diferença entre processo e thread. A ideia é aumentar a produtividade limitando o foco.
Mesmo que a visão seja compartilhada, isso parte do pressuposto de que haverá questionamentos sobre essa visão; mas acho que também assumi naturalmente que, por causa da direção que vai mudando um pouco a cada sprint planning, não se consegue acompanhar como a visão geral está sendo seguida.
Não seria compartilhar a visão geral e, com todo mundo entendendo, dividir o trabalho em pequenas tarefas??
Ótimo texto, obrigado.
Quando isso é dividido em tarefas tão pequenas, o líder que tem a visão do todo acaba ficando com um grande poder. Os engenheiros que estão junto, por outro lado, acabam desmotivados e pensando: "afinal, para onde estamos indo?" Um dos principais pontos fracos do ágil baseado em sprint.
Parece que foi escrito demais apenas da perspectiva do líder, exatamente como diz o título.
O momentum dos engenheiros também é muito influenciado pela direção para a qual o líder está apontando a bandeira. Também parece necessário pensar um pouco mais sobre como apresentar qual é o valor que se quer entregar ao cliente e quais são o output e o outcome de entrega de cada sprint. Claro, são soft skills difíceis, então é raro ver líderes que façam isso bem, e também não há muitos textos bons sobre isso.
Sou leigo em front-end... isso é diferente do swc?
Agora são 8h40 da manhã e, por acaso, acabei de ver que está exatamente 7:40:28 PM EST... que curioso.
Visitar o McDonald's parece ser fácil. Parece que vai ser uma experiência divertida.
Entendo o .NET, mas acho que Rust está mais na mesma posição que Go. De qualquer forma, imagino que os projetos e bibliotecas de JS relacionados a Go que já existiam também tenham influenciado a decisão.
É realmente uma ideia bem original, mas, como disseram em outros comentários, também fico curioso para saber como eles pretendem resolver o problema caso o tráfego dispare.