Depois de configurar o cf tunnel, parou completamente de acumular logs do fail2ban nas portas 80 e 443, então removi isso de vez e nunca mais pensei no assunto.
Comprei o próprio domínio pela Cloudflare, configurei o SSO também na Cloudflare e bloqueei o uso dos serviços para quem não passar pelo SSO, então deixei a Cloudflare tankar todos os ataques no meu lugar.
Como ali só entram serviços que eu uso sozinho, essa configuração já é mais do que suficiente na prática.
Se a Cloudflare cair, decidi aceitar esse nível de risco.
Eu já estava sentindo uma queda no desempenho do Opus 4.6, então parece que era por causa da proximidade do lançamento do novo modelo.
A mágica de reduzir a experiência uma vez para aumentar bastante o nível de satisfação...
São os itens 3 e 4. Escrever a especificação em detalhes tem profundidade infinita. O ponto é que existe um nível adequado para cada organização. Quando olhamos a história de como serviços de sucesso foram criados, sei que em 99% dos casos o principal é justamente não colocar energia demais em escrever a especificação com precisão absoluta. A ideia é não ficar preso a isso. Basta ver como Summoners War, Dungeon & Fighter, Zigbang e Lineage foram feitos.
Pelo que vi, parece que o Sr. Kim Ho-dong já passou por um estresse enorme em 2019 também. Lendo o texto, dá para ver que havia gente folgada e sem noção demais. (Ainda deve ter, né?) https://hamonikr.org/Free_Board/63139
Eu também concordo. Às vezes, em serviços, o DB acaba sendo tratado como mais importante do que o necessário e, em alguns casos, até se faz um investimento excessivo em design, como se quebrar a normalização fosse causar um grande desastre.
Não se trata de dizer para não usar DB, mas sim de refrescar um pouco a visão sobre por que ele é usado e qual é, afinal, a essência do serviço.
No fim, equilíbrio é sempre importante.
Pois é. Dá para encarar isso como uma sugestão de que, no início do negócio, quando ainda não há muitos usuários, em vez de comprar um banco de dados ou deixar tudo complexo, talvez seja possível levar a empresa até se firmar usando apenas I/O básico de arquivos.
Acho que é um texto muito bom. Especialmente materiais com esses 'números' são valiosos. Estamos numa época em que não é fácil encontrar desenvolvedores que tenham 'ao menos uma noção aproximada' de que tipo de overhead existe no código que criamos e na stack tecnológica que usamos, então li com prazer.
Acho que a analogia é adequada. Meu projeto também é, na prática, composto apenas por duas coisas: o intent da pessoa e o snapshot.
No fim das contas, eu já pensava que o caminho que meu projeto deve seguir é como calcular a intenção humana (por exemplo, pressionamentos de tecla e cliques do mouse) e fazer com que ela adquira algum significado.
A ideia é atraente, mas, pela minha experiência, quase nunca vi dar certo esse tipo de tentativa idealista..
Por enquanto, acho que o Feedly continua sendo o mais equilibrado, e os recursos de IA dele também são bons.
Isso é conteúdo básico que aparece na maioria dos livros sobre métodos ágeis, como Extreme Programming de Kent Beck e Scrum de Jeff Sutherland. Você também pode olhar as user stories. Muita gente aparentemente não sabe que a base do ágil são sprints curtos e demos para se adaptar rapidamente aos requisitos do cliente.
Entendo e concordo com a sua opinião.
Claramente há partes que não podem ser substituídas por código.
Nesse sentido, tentando explicar de uma forma um pouco diferente, o que eu queria dizer é que um código com alta legibilidade faz com que não seja necessário produzir documentação.
A documentação que se acumula ao longo do tempo no software também gera carga cognitiva para os desenvolvedores. O ponto principal é reduzir o trabalho de ficar alternando entre código e documentação.
Não acho que seja possível deixar apenas o código.
Acredito que isso pode variar conforme o contexto e a situação enfrentada.
Obrigado pelo comentário.
Parece que este comentário mostra o pensamento engessado dos desenvolvedores coreanos e o nível do GeekNews.
Depois de configurar o cf tunnel, parou completamente de acumular logs do fail2ban nas portas 80 e 443, então removi isso de vez e nunca mais pensei no assunto.
Comprei o próprio domínio pela Cloudflare, configurei o SSO também na Cloudflare e bloqueei o uso dos serviços para quem não passar pelo SSO, então deixei a Cloudflare tankar todos os ataques no meu lugar.
Como ali só entram serviços que eu uso sozinho, essa configuração já é mais do que suficiente na prática.
Se a Cloudflare cair, decidi aceitar esse nível de risco.
Eu já estava sentindo uma queda no desempenho do Opus 4.6, então parece que era por causa da proximidade do lançamento do novo modelo.
A mágica de reduzir a experiência uma vez para aumentar bastante o nível de satisfação...
São os itens 3 e 4. Escrever a especificação em detalhes tem profundidade infinita. O ponto é que existe um nível adequado para cada organização. Quando olhamos a história de como serviços de sucesso foram criados, sei que em 99% dos casos o principal é justamente não colocar energia demais em escrever a especificação com precisão absoluta. A ideia é não ficar preso a isso. Basta ver como Summoners War, Dungeon & Fighter, Zigbang e Lineage foram feitos.
Concordo. O ágil continua válido. Parece papo de gente que nunca trabalhou na prática e fala ao vento.
Se o SQLite quebrar, não tem o que fazer..
Pelo que vi, parece que o Sr. Kim Ho-dong já passou por um estresse enorme em 2019 também. Lendo o texto, dá para ver que havia gente folgada e sem noção demais. (Ainda deve ter, né?)
https://hamonikr.org/Free_Board/63139
Eu também concordo. Às vezes, em serviços, o DB acaba sendo tratado como mais importante do que o necessário e, em alguns casos, até se faz um investimento excessivo em design, como se quebrar a normalização fosse causar um grande desastre.
Não se trata de dizer para não usar DB, mas sim de refrescar um pouco a visão sobre por que ele é usado e qual é, afinal, a essência do serviço.
No fim, equilíbrio é sempre importante.
Na Coreia, ágil não é nada além — nem menos — de uma ferramenta para pressionar os prazos dos desenvolvedores.
Ah... que bom. Até agora não tinha, então eu estava usando só fazendo com o app Atalhos.
Pois é. Dá para encarar isso como uma sugestão de que, no início do negócio, quando ainda não há muitos usuários, em vez de comprar um banco de dados ou deixar tudo complexo, talvez seja possível levar a empresa até se firmar usando apenas I/O básico de arquivos.
As pérolas nas respostas são um bônus.
Acho que é um texto muito bom. Especialmente materiais com esses 'números' são valiosos. Estamos numa época em que não é fácil encontrar desenvolvedores que tenham 'ao menos uma noção aproximada' de que tipo de overhead existe no código que criamos e na stack tecnológica que usamos, então li com prazer.
Acho que a analogia é adequada. Meu projeto também é, na prática, composto apenas por duas coisas: o intent da pessoa e o snapshot.
No fim das contas, eu já pensava que o caminho que meu projeto deve seguir é como calcular a intenção humana (por exemplo, pressionamentos de tecla e cliques do mouse) e fazer com que ela adquira algum significado.
Eu ia vir escrever um post quando vi o lançamento, mas vocês já tinham publicado.
Fico curioso para saber quão bom será o desempenho.
Como o código existente ainda permanece, é possível verificar diretamente qual é a implementação.
https://gitlab.com/sebuls/libhwp
A ideia é atraente, mas, pela minha experiência, quase nunca vi dar certo esse tipo de tentativa idealista..
Por enquanto, acho que o Feedly continua sendo o mais equilibrado, e os recursos de IA dele também são bons.
rip
Isso é conteúdo básico que aparece na maioria dos livros sobre métodos ágeis, como Extreme Programming de Kent Beck e Scrum de Jeff Sutherland. Você também pode olhar as user stories. Muita gente aparentemente não sabe que a base do ágil são sprints curtos e demos para se adaptar rapidamente aos requisitos do cliente.
Entendo e concordo com a sua opinião.
Claramente há partes que não podem ser substituídas por código.
Nesse sentido, tentando explicar de uma forma um pouco diferente, o que eu queria dizer é que um código com alta legibilidade faz com que não seja necessário produzir documentação.
A documentação que se acumula ao longo do tempo no software também gera carga cognitiva para os desenvolvedores. O ponto principal é reduzir o trabalho de ficar alternando entre código e documentação.
Não acho que seja possível deixar apenas o código.
Acredito que isso pode variar conforme o contexto e a situação enfrentada.
Obrigado pelo comentário.