Agora parece um pouco aquela época em que os smartphones estavam se popularizando e a UX começava a mudar para o mobile first. A estrutura ainda não está totalmente consolidada, mas dá para ver mudanças interessantes surgindo por toda parte.
Também li muito bem o post do blog.
Como alguém que está desenvolvendo um terminal por motivações parecidas, fiquei com algumas dúvidas.
Pessoalmente, acho que talvez nunca tenha havido uma época em que o ambiente de DX mudasse tão rápido como agora, e fosse tão diferente para cada desenvolvedor.
Não sei se o criador também sentiu isso, mas acho que, em momentos assim, é mais vantajoso que o controle esteja nas minhas mãos,
e, quando pensei em qual seria a base da DX na era da IA, concluí que ela seria baseada no terminal.
Usei todos os terminais que estão em alta recentemente, mas a entrada em coreano ainda é fraca na maioria deles, e a DX/UX para usar agentes era inconveniente; por isso cheguei à conclusão de que eu também deveria desenvolver o meu próprio. Segui por esse caminho e acho que, com meu terminal, consegui garantir uma produtividade melhor do que outras pessoas.
No meu caso, para obter controle total,
pensei que também deveria minimizar as dependências de bibliotecas externas, então optei por desenvolver tudo em Zig por conta própria (exceto casos inevitáveis, como WebView).
Vendo o post do blog e o código, fiquei curioso sobre o motivo de vocês terem escolhido Rust e bibliotecas externas existentes no ecossistema Rust, como rataui, em vez de desenvolver tudo internamente.
Pelo texto, parece que também houve problemas causados por dependências de bibliotecas externas.
E, como o WebView é um WebView nativo, a maioria dos ambientes web não é Safari, então parece difícil fazer testes E2E completos nessa parte. Vocês simplesmente delegam isso a ferramentas externas de teste? Ou têm planos de incluir CEF no futuro? Também fiquei curioso sobre isso.
Eu também já uso meu terminal há algum tempo e entrei em uma fase de estabilização, então estou pensando bastante em adicionar recursos, planejar funcionalidades e melhorar a UX. Mas, durante o desenvolvimento, deve ter havido muitos crashes e vários bugs.
Também gostaria de saber em que momento, depois do início do desenvolvimento, ele ficou estável o suficiente para que a execução passasse a ser feita no terminal desenvolvido por vocês, em vez de em um terminal externo.
É verdade. Quando chega à entrevista, parece que eles dão mais peso a esse tipo de aspecto do que nas etapas anteriores do recrutamento.
Embora seja difícil chegar até lá, haha.
Se você conseguir chegar ao ponto de fazer a entrevista, acho que, mais do que habilidade de programação, é melhor desenvolver e destacar as outras competências necessárias, como é o ponto principal deste texto.
Há um tempo, tentei criar e publicar um jogo com renphy.
Existe algo chamado GitHub Blog; o GitHub hospeda de graça um site estático, acho que um por conta.
(O link do site provavelmente é fixo.)
Pelo que sei, usando isso é possível publicar sites estáticos com facilidade.
Na verdade, quando você acaba ficando do outro lado e passa a contratar desenvolvedores, percebe que o processo não gira só em torno de razão e lógica de forma rigorosa; personalidade e intuição também pesam bastante, rs. Surpreendentemente, se não for o caso de precisar trazer um gênio de uma área muito específica, a questão mais importante acaba sendo: "será que, trabalhando com essa pessoa, vou conseguir colaborar bem sem passar por estresse desnecessário?"
Não, não há essa menção.
Achar que isso não significa ser favorável a open weights da China é a minha opinião.
No entanto, não é que eu seja a favor de open weights,
mas sim que espero que os EUA também vençam em open weights.
É um texto com o qual eu me identifico.
Mas, quando eu era um candidato em busca de emprego, ao ver um texto assim, ele só soava para mim como um discurso bonito de quem já tinha conseguido trabalho primeiro.
E faz sentido, porque do ponto de vista de quem está procurando emprego, ao se candidatar como desenvolvedor a uma empresa, é mais fácil provar habilidade de programação do que comprovar capacidades como documentação, persuasão e comunicação.
E nas empresas também parecia que, na contratação de iniciantes, valorizavam mais habilidades de programação, como portfólio e nota em teste de coding.
Do ponto de vista das empresas, provavelmente também era porque aquilo era tudo o que permitia comparar e avaliar visivelmente aquela enorme quantidade de candidatos iniciantesT_T
A fly.io é um serviço que eu acompanhava com interesse pelo GeekNews desde o começo da abertura,
mas pelo visto estão mudando a estratégia para se adaptar à era da IA.
É disso que se trata, mas hmm... recentemente tive a experiência de criar uma página web com o recurso Sites no Codex, e acho que não vai ser fácil.
Como no comentário do HN abaixo, o mercado-alvo também parece estreito demais.
O enorme novo mercado em que até avós e avôs criam apps será ocupado por serviços como o Lovable, e é improvável que não desenvolvedores usem o Sprites.
No fim, ele só conseguirá atrair uma parte dos desenvolvedores existentes.
Nunca vi ninguém dizer que a programação foi resolvida; o que aparece nas notícias são apenas pessoas famosas falando que, daqui a 1, 3 ou 5 anos, as coisas serão assim ou assado.
Na postagem no X, não há nenhuma menção do tipo: "mas, claro, isso não significa apoiar open weights chineses".
O conteúdo diz que ele espera que os EUA vençam tanto em modelos proprietários quanto em modelos abertos.
A é B. B é C. Então A se torna C? Para começo de conversa, a própria premissa de que podemos saber o que é talento e se ele é alto ou baixo pode ser um equívoco nosso.
Pensando que o ESP32-S3 é um chip que custa algo em torno de dez mil won no Ali, dá para enxergar possibilidades interessantes.
Por exemplo, no caso de uma máquina de lavar, imagino que poderia surgir um produto com um modelo pequeno que entendesse apenas o manual, os ciclos de lavagem, os tipos de sabão e as características de cada função, e que explicasse o uso conversando com o usuário mesmo sem conexão à internet.
Para acrescentar sobre a motivação de desenvolvimento: o ponto de partida foi o gargalo que encontrei ao rodar quatro sessões de Claude, Codex, Gemini e Grok em três máquinas multiplataforma — “a execução escala horizontalmente, mas a entrega fica presa a uma única pessoa”. Não é um substituto para tmux/SSH, e sim uma ferramenta complementar — o objetivo não é “acesso ao terminal”, mas “endereçamento de sessões + confirmação de entrega”. Fiquem à vontade para perguntar qualquer coisa.
Agora parece um pouco aquela época em que os smartphones estavam se popularizando e a UX começava a mudar para o mobile first. A estrutura ainda não está totalmente consolidada, mas dá para ver mudanças interessantes surgindo por toda parte.
Já favoritei na hora. Acho que vou dar uma olhada todos os dias.
Gostaria de perguntar se vocês estão considerando oferecer suporte em coreano :)
Concentre-se apenas em saber se você está melhorando em relação a quem era no passado.
Fiquei curioso sobre como eles filtram as conversas do Slack para incluí-las na base de conhecimento e sobre a implementação concreta disso.
Também li muito bem o post do blog.
Como alguém que está desenvolvendo um terminal por motivações parecidas, fiquei com algumas dúvidas.
Pessoalmente, acho que talvez nunca tenha havido uma época em que o ambiente de DX mudasse tão rápido como agora, e fosse tão diferente para cada desenvolvedor.
Não sei se o criador também sentiu isso, mas acho que, em momentos assim, é mais vantajoso que o controle esteja nas minhas mãos,
e, quando pensei em qual seria a base da DX na era da IA, concluí que ela seria baseada no terminal.
Usei todos os terminais que estão em alta recentemente, mas a entrada em coreano ainda é fraca na maioria deles, e a DX/UX para usar agentes era inconveniente; por isso cheguei à conclusão de que eu também deveria desenvolver o meu próprio. Segui por esse caminho e acho que, com meu terminal, consegui garantir uma produtividade melhor do que outras pessoas.
No meu caso, para obter controle total,
pensei que também deveria minimizar as dependências de bibliotecas externas, então optei por desenvolver tudo em Zig por conta própria (exceto casos inevitáveis, como WebView).
Vendo o post do blog e o código, fiquei curioso sobre o motivo de vocês terem escolhido Rust e bibliotecas externas existentes no ecossistema Rust, como rataui, em vez de desenvolver tudo internamente.
Pelo texto, parece que também houve problemas causados por dependências de bibliotecas externas.
E, como o WebView é um WebView nativo, a maioria dos ambientes web não é Safari, então parece difícil fazer testes E2E completos nessa parte. Vocês simplesmente delegam isso a ferramentas externas de teste? Ou têm planos de incluir CEF no futuro? Também fiquei curioso sobre isso.
Eu também já uso meu terminal há algum tempo e entrei em uma fase de estabilização, então estou pensando bastante em adicionar recursos, planejar funcionalidades e melhorar a UX. Mas, durante o desenvolvimento, deve ter havido muitos crashes e vários bugs.
Também gostaria de saber em que momento, depois do início do desenvolvimento, ele ficou estável o suficiente para que a execução passasse a ser feita no terminal desenvolvido por vocês, em vez de em um terminal externo.
O que pessoas sem competência sempre mencionam é a capacidade de colaboração…
O link de instalação do multiplexador está sendo cortado... Consulte este item no README para instalar apenas o multiplexador.
É verdade. Quando chega à entrevista, parece que eles dão mais peso a esse tipo de aspecto do que nas etapas anteriores do recrutamento.
Embora seja difícil chegar até lá, haha.
Se você conseguir chegar ao ponto de fazer a entrevista, acho que, mais do que habilidade de programação, é melhor desenvolver e destacar as outras competências necessárias, como é o ponto principal deste texto.
O que você quer mostrar na demo é a excelência da lógica de matching? Ou apenas que algo assim existe?
Há um tempo, tentei criar e publicar um jogo com renphy.
Existe algo chamado GitHub Blog; o GitHub hospeda de graça um site estático, acho que um por conta.
(O link do site provavelmente é fixo.)
Pelo que sei, usando isso é possível publicar sites estáticos com facilidade.
Na verdade, quando você acaba ficando do outro lado e passa a contratar desenvolvedores, percebe que o processo não gira só em torno de razão e lógica de forma rigorosa; personalidade e intuição também pesam bastante, rs. Surpreendentemente, se não for o caso de precisar trazer um gênio de uma área muito específica, a questão mais importante acaba sendo: "será que, trabalhando com essa pessoa, vou conseguir colaborar bem sem passar por estresse desnecessário?"
Não, não há essa menção.
Achar que isso não significa ser favorável a open weights da China é a minha opinião.
No entanto, não é que eu seja a favor de open weights,
mas sim que espero que os EUA também vençam em open weights.
É um texto com o qual eu me identifico.
Mas, quando eu era um candidato em busca de emprego, ao ver um texto assim, ele só soava para mim como um discurso bonito de quem já tinha conseguido trabalho primeiro.
E faz sentido, porque do ponto de vista de quem está procurando emprego, ao se candidatar como desenvolvedor a uma empresa, é mais fácil provar habilidade de programação do que comprovar capacidades como documentação, persuasão e comunicação.
E nas empresas também parecia que, na contratação de iniciantes, valorizavam mais habilidades de programação, como portfólio e nota em teste de coding.
Do ponto de vista das empresas, provavelmente também era porque aquilo era tudo o que permitia comparar e avaliar visivelmente aquela enorme quantidade de candidatos iniciantesT_T
É uma realidade triste em muitos sentidos.
Anunciar uma grande mudança na empresa e trocar o CEO ao mesmo tempo parece meio estranho.
Docker Without Docker - Introdução à tecnologia base da Fly.io
A fly.io é um serviço que eu acompanhava com interesse pelo GeekNews desde o começo da abertura, mas pelo visto estão mudando a estratégia para se adaptar à era da IA.
Sprites - sandboxes com estado
É disso que se trata, mas hmm... recentemente tive a experiência de criar uma página web com o recurso Sites no Codex, e acho que não vai ser fácil.
Como no comentário do HN abaixo, o mercado-alvo também parece estreito demais.
Nunca vi ninguém dizer que a programação foi resolvida; o que aparece nas notícias são apenas pessoas famosas falando que, daqui a 1, 3 ou 5 anos, as coisas serão assim ou assado.
Na postagem no X, não há nenhuma menção do tipo: "mas, claro, isso não significa apoiar open weights chineses".
O conteúdo diz que ele espera que os EUA vençam tanto em modelos proprietários quanto em modelos abertos.
A é B. B é C. Então A se torna C? Para começo de conversa, a própria premissa de que podemos saber o que é talento e se ele é alto ou baixo pode ser um equívoco nosso.
Pensando que o ESP32-S3 é um chip que custa algo em torno de dez mil won no Ali, dá para enxergar possibilidades interessantes.
Por exemplo, no caso de uma máquina de lavar, imagino que poderia surgir um produto com um modelo pequeno que entendesse apenas o manual, os ciclos de lavagem, os tipos de sabão e as características de cada função, e que explicasse o uso conversando com o usuário mesmo sem conexão à internet.
Para acrescentar sobre a motivação de desenvolvimento: o ponto de partida foi o gargalo que encontrei ao rodar quatro sessões de Claude, Codex, Gemini e Grok em três máquinas multiplataforma — “a execução escala horizontalmente, mas a entrega fica presa a uma única pessoa”. Não é um substituto para tmux/SSH, e sim uma ferramenta complementar — o objetivo não é “acesso ao terminal”, mas “endereçamento de sessões + confirmação de entrega”. Fiquem à vontade para perguntar qualquer coisa.
Ótimo texto.