O Cursor é muito bom, mas... no meu caso, como trabalho em vários dispositivos,
senti falta de um recurso de sincronização de configurações.
Dizem que existe uma gambiarra para sincronizar extensões ou os próprios arquivos de configuração
a partir de um drive de rede usando links simbólicos,
mas no VS Code isso sincroniza com um clique, então ter que passar por esse processo acaba sendo meio incômodo.
O desempenho se degrada, a manutenção fica mais difícil e, quando ocorre uma falha, há muitos pontos de gerenciamento, o que dificulta rastrear a causa.
Isso acaba gerando uma situação exatamente oposta ao objetivo original do k8s, que é reduzir os pontos de gerenciamento e o esforço operacional.
Ah, lendo um pouco mais o texto, acho que fiquei confuso porque havia uma parte falando que o editor ficaria mais rápido.
O tsc ficou 10 vezes mais rápido. Ou seja, o tempo de transpilaçāo de ts -> js foi muito reduzido.
Ao carregar um projeto grande desenvolvido em ts, como o VSCode, a velocidade fica muito maior. Ou seja, significa que a lógica que compartilha recursos do tsc, como a verificação de sintaxe do ts, ficou mais rápida.
Isso não quer dizer que a velocidade de funcionamento do VSCode tenha aumentado.
Era esse o conteúdo, então.
Como substituí o Cmd+K do vscode por Cmd+R, quase não uso, mas todo mundo continua dando depoimentos sobre aumento de produtividade... aff, será que preciso migrar?
No livro <Phoenix Project>, que já foi mencionado várias vezes no GeekNews, aparece uma ideia parecida. Quanto mais perto de 100% da capacidade, mais o tempo de resposta aumenta de forma exponencial.
Concordo totalmente com o que este texto propõe, e também concordo com o problema que você mencionou,
na verdade esse também é um ponto sobre o qual venho refletindo.
Variava de squad para squad, mas quando os membros do time participavam ativamente do sprint planning, o problema que você mencionou não costumava acontecer. Compartilhávamos o contexto do projeto e, a cada sprint, também as mudanças de cenário, para que todos pudessem entender bem as tarefas que iam mudando; ao mesmo tempo, eu pedia que o trabalho fosse dividido de forma bem detalhada.
Como você disse, do ponto de vista da gestão, considerando acompanhamento do progresso, medição da velocidade de trabalho, resposta a situações inesperadas e o custo de oportunidade quando o trabalho não sai como planejado, no fim das contas realmente funciona melhor quando as tarefas são quebradas em partes menores.
Como alguém que trabalha na área de ciências da vida, gostaria de compartilhar brevemente os resultados do uso.
> O modo de pesquisa é oferecido em 2 opções.
Quick summary
O tempo necessário é de cerca de 5~6 minutos (com base em 4070 ti super, 16GB, Mistral e Gemma 3:12b)
Há alucinações, então ele gera as próprias referências, mas as refs com links no documento parecem ter fontes bem definidas.
Existe uma intenção de responder às perguntas com foco em novas tecnologias. Em especial, ele tenta relacionar tudo com IA.
Detailed Report
O tempo necessário é de cerca de 1 hora (4070 ti super 16GB, Gemma 3:12b)
É como se gerasse um único artigo de revisão. Porém, há o problema de a quantidade de referências cair bastante. Mesmo que o conteúdo esteja correto, fica difícil sustentá-lo sem evidências, então ainda precisa de alguma melhoria. (Parece que ele faz um processo de refinamento para melhorar a qualidade do texto, e nesse processo os links de Ref acabam se perdendo.)
Ainda assim, ele claramente fornece conteúdo de qualidade superior ao Quick summary.
No arquivo de configuração, é possível ajustar várias opções. Dá para limitar o banco de dados de busca apenas ao PubMed, elevando ainda mais a qualidade do material. Também é possível configurar quantos textos serão pesquisados de uma vez e quantos chunks serão criados ao usar RAG.
Considerando que ainda está na versão 0.01V, é muito impressionante que uma máquina local consiga gerar relatórios nesse nível. Especialmente na área de ciências biológicas, chatbots costumam usar descrições generalizadas, mas os relatórios gerados por esse programa usam uma redação extremamente científica.
No momento, esse programa não oferece suporte a coreano. Mesmo fazendo perguntas em coreano, o relatório é gerado em inglês.
Além disso, ao receber a resposta em PDF por meio da exportação para PDF, há o problema de o coreano não aparecer.
Se forem resolvidos apenas o problema de as refs desaparecerem durante a geração do relatório e o problema das alucinações, acho que será uma ferramenta realmente poderosa.
Se ao abrir mão do suporte a regex ele consegue ser só 2 vezes mais rápido que o ripgrep, a utilidade acaba ficando um pouco menor.
Acho que vou continuar usando o ripgrep mesmo, já que ele aceita regex.
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.
O Cursor é muito bom, mas... no meu caso, como trabalho em vários dispositivos,
senti falta de um recurso de sincronização de configurações.
Dizem que existe uma gambiarra para sincronizar extensões ou os próprios arquivos de configuração
a partir de um drive de rede usando links simbólicos,
mas no VS Code isso sincroniza com um clique, então ter que passar por esse processo acaba sendo meio incômodo.
Troquei o VS Code que usei por 5 anos e estou gostando.
Muito legal. Se o sqlite fizesse isso. Acho que ia dar um rebuliço de verdade. Claro, junto viriam também as vulnerabilidades de segurança.
O desempenho se degrada, a manutenção fica mais difícil e, quando ocorre uma falha, há muitos pontos de gerenciamento, o que dificulta rastrear a causa.
Isso acaba gerando uma situação exatamente oposta ao objetivo original do k8s, que é reduzir os pontos de gerenciamento e o esforço operacional.
Ah, lendo um pouco mais o texto, acho que fiquei confuso porque havia uma parte falando que o editor ficaria mais rápido.
tscficou 10 vezes mais rápido. Ou seja, o tempo de transpilaçāo dets -> jsfoi muito reduzido.ts, como o VSCode, a velocidade fica muito maior. Ou seja, significa que a lógica que compartilha recursos dotsc, como a verificação de sintaxe dots, ficou mais rápida.Como substituí o
Cmd+Kdo vscode porCmd+R, quase não uso, mas todo mundo continua dando depoimentos sobre aumento de produtividade... aff, será que preciso migrar?No livro <Phoenix Project>, que já foi mencionado várias vezes no GeekNews, aparece uma ideia parecida. Quanto mais perto de 100% da capacidade, mais o tempo de resposta aumenta de forma exponencial.
Concordo totalmente com o que este texto propõe, e também concordo com o problema que você mencionou,
na verdade esse também é um ponto sobre o qual venho refletindo.
Variava de squad para squad, mas quando os membros do time participavam ativamente do sprint planning, o problema que você mencionou não costumava acontecer. Compartilhávamos o contexto do projeto e, a cada sprint, também as mudanças de cenário, para que todos pudessem entender bem as tarefas que iam mudando; ao mesmo tempo, eu pedia que o trabalho fosse dividido de forma bem detalhada.
Como você disse, do ponto de vista da gestão, considerando acompanhamento do progresso, medição da velocidade de trabalho, resposta a situações inesperadas e o custo de oportunidade quando o trabalho não sai como planejado, no fim das contas realmente funciona melhor quando as tarefas são quebradas em partes menores.
Não entendi. Nem de longe tem nível acadêmico, e nem chega ao nível de programação de uma criança do ensino fundamental — por que compartilhar isso...
> O modo de pesquisa é oferecido em 2 opções.
novas tecnologias. Em especial, ele tenta relacionar tudo com IA.No arquivo de configuração, é possível ajustar várias opções. Dá para limitar o banco de dados de busca apenas ao PubMed, elevando ainda mais a qualidade do material. Também é possível configurar quantos textos serão pesquisados de uma vez e quantos chunks serão criados ao usar RAG.
Considerando que ainda está na versão 0.01V, é muito impressionante que uma máquina local consiga gerar relatórios nesse nível. Especialmente na área de ciências biológicas, chatbots costumam usar
descrições generalizadas, mas os relatórios gerados por esse programa usam uma redação extremamente científica.No momento, esse programa não oferece suporte a coreano. Mesmo fazendo perguntas em coreano, o relatório é gerado em inglês.
Além disso, ao receber a resposta em PDF por meio da exportação para PDF, há o problema de o coreano não aparecer.
Se forem resolvidos apenas o problema de as refs desaparecerem durante a geração do relatório e o problema das alucinações, acho que será uma ferramenta realmente poderosa.
kkkkkk
Fiquei saturado com a grande quantidade de plugins do Obsidian,
e acabei migrando para o Reflect — estou muito satisfeito.
Em algum momento, comecei a mexer menos com TS, mas ao ver uma notícia dessas, fico curioso de novo.
Por isso, eu reservo totalmente as tardes de sexta-feira para tempo de desenvolvimento pessoal!
Concordo fortemente com este comentário. Havia (ou há) o risco de ocorrer microgerenciamento das partes técnicas. Realmente não é nada fácil.
Se ao abrir mão do suporte a regex ele consegue ser só 2 vezes mais rápido que o ripgrep, a utilidade acaba ficando um pouco menor.
Acho que vou continuar usando o ripgrep mesmo, já que ele aceita regex.
GOAT.. caramba
O avanço da China é assustador mesmo.
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.