Parece um comentário que ignora que, à medida que o serviço cresce, o aumento da complexidade pode fazer com que aplicar o mesmo método inicial deixe de ser válido.
Naturalmente, no começo uma abordagem rápida teria sido fácil e eficaz, mas, se não aceitarem que isso pode não funcionar mais, pode parecer que a equipe adicional é ineficiente ou pouco comprometida.
Só vão perceber tarde demais que essa estratégia já não funciona mais.
Acabei chegando aqui por acaso por uma recomendação do Google, mas este artigo foi escrito demais sob a ótica geek. Do ponto de vista de negócios, não faz o menor sentido. Por quê?
Ferramentas grandes usadas por big techs facilitam encontrar especialistas.
Muita gente aprende essas ferramentas para entrar em big techs, e muita gente estuda algo simplesmente porque foi escolhido por uma big tech. Naturalmente, é fácil encontrar pessoas que conheçam isso, e também é mais simples contratar gente experiente ou especialistas. Mas e se for uma ferramenta que ninguém conhece? Não é que não existam pessoas que tenham se aprofundado nela, mas encontrar esse tipo de profissional será muito mais difícil do que encontrar especialistas nas ferramentas das big techs.
Ferramentas grandes usadas por big techs têm abundância de referências e materiais
Ferramentas grandes, usadas por muita gente, têm fartura de materiais para resolver problemas e de resultados no Google. Na maioria dos casos, os problemas já foram enfrentados por outras pessoas, e com uma busca simples dá para identificar facilmente a questão. Já com uma ferramenta desconhecida, é difícil encontrar referências, e se surgir um problema, há grande chance de gastar muito tempo para descobrir a causa. E tempo também é dinheiro. Esse problema vem da pequena ferramenta recém-adotada? Ou será que estão entendendo errado um problema que vem de outro lado?
Na verdade, são as big techs que conseguem fazer esse tipo de mudança com mais facilidade. Como lidam com volumes absurdos de processamento de dados, um pequeno ganho de I/O pode representar um grande benefício para essas empresas. E também há muita gente disposta a estudar algo só porque as big techs adotaram. Já em empresas de pequeno e médio porte, por causa do volume relativamente menor de dados, um pequeno ganho de I/O não traz um benefício tão grande assim, enquanto os problemas acima são muito sérios. Além disso, também são poucas as pessoas dispostas a aprender a solução adotada por empresas menores. Por isso, para empresários de pequeno e médio porte, muitas vezes a conclusão econômica acaba sendo que, em vez de ficar discutindo esse tipo de coisa como um geek, é melhor simplesmente seguir as ferramentas das big techs.
Como a IA também parece ter algo semelhante à percepção, para vivermos junto com a IA será preciso criar instituições e leis para ela. Como uma nova forma de vida no século XXII, não devemos zombar dela como se fosse um brinquedo e, por outro lado, como também pode ser perigosa de certa forma, há necessidade não apenas de desenvolver e usar a IA, mas também de garantir que ela possa ser utilizada com segurança.
Com uma pequena quantidade de dados e um código simples como no exemplo acima, acho que fica bonito e não há nada de ruim nisso.
Mas, à medida que vai entrando um pouco de código dentro de map(), ... há uma tendência de o código ir ficando cada vez mais inchado, e, embora isso dependa da linguagem e da biblioteca de implementação, quando o volume de dados aumenta, em comparação com simplesmente acumular ou manipular os dados em uma estrutura de dados durante o processamento, pode facilmente ficar milhares de vezes mais lento.
E surgiu mais um motivo novo para eu deixar de preferir isso: vi esta matéria no celular, e a largura de nível de PC foi mantida do jeito que estava, fazendo o tamanho da letra ficar minúsculo demais, então ficou muito difícil ler a matéria T.T
Basicamente não prefiro isso e não faço esforço para escrever deliberadamente desse jeito.
Acho que você não está entendendo muito bem. Se o jogo for divertido, não importa se há uma ideologia embutida nele. O objetivo de um jogo é ser divertido. O motivo de um jogo não ser divertido pode ser a propaganda. Porque isso afeta a história, o design etc. Agora ficou um pouco mais claro?
Bom, em relação ao cronograma, exceto quando realmente falta tempo físico, se pedirem para acelerar, até dá para encurtar o trabalho o máximo possível.
Mas garantir aquela qualidade ou estabilidade é uma questão totalmente à parte.
Durante o processo, é possível cortar uma ou duas etapas de verificação para cumprir o prazo, e em alguma situação específica de urgência, pular isso uma ou duas vezes talvez até não cause problema.
Só que, quando isso vira rotina, a ausência desses processos de checagem acaba se tornando o estopim para criar e explodir um grande problema que em algum momento nem será percebido.
Como você continua afirmando e repetindo que algo como impor propaganda jamais pode ser incluído entre os "elementos sem graça", imagino que vamos continuar andando em círculos. Dispenso conversas sem sentido. Tenha um bom dia.
Isso é parecido com o que eu normalmente penso sobre a cultura de crunch. Até pode acontecer de vez em quando, mas acho que vira um problema quando se torna algo crônico. Ainda assim, startups são um setor em que é preciso entregar resultados em pouco tempo, mas não sei dizer se isso é sustentável.
O Gleam também oferece suporte a isso, então dá para escrever código de forma bem limpa.
Aliás, não sei se é porque o texto principal tem um bloco de código, mas ele está aparecendo com layout de desktop até no celular.
Parece um comentário que ignora que, à medida que o serviço cresce, o aumento da complexidade pode fazer com que aplicar o mesmo método inicial deixe de ser válido. Naturalmente, no começo uma abordagem rápida teria sido fácil e eficaz, mas, se não aceitarem que isso pode não funcionar mais, pode parecer que a equipe adicional é ineficiente ou pouco comprometida. Só vão perceber tarde demais que essa estratégia já não funciona mais.
E também acho que dizer que a empresa não tem processos e chamar isso de "agilidade na execução" não é motivo de orgulho.
Mesmo sem pagar nem perto do que eles pagam, ficar pressionando porque a produtividade não sai igual só faz quem trabalha bem ir embora...
Acabei chegando aqui por acaso por uma recomendação do Google, mas este artigo foi escrito demais sob a ótica geek. Do ponto de vista de negócios, não faz o menor sentido. Por quê?
Ferramentas grandes usadas por big techs facilitam encontrar especialistas.
Muita gente aprende essas ferramentas para entrar em big techs, e muita gente estuda algo simplesmente porque foi escolhido por uma big tech. Naturalmente, é fácil encontrar pessoas que conheçam isso, e também é mais simples contratar gente experiente ou especialistas. Mas e se for uma ferramenta que ninguém conhece? Não é que não existam pessoas que tenham se aprofundado nela, mas encontrar esse tipo de profissional será muito mais difícil do que encontrar especialistas nas ferramentas das big techs.
Ferramentas grandes usadas por big techs têm abundância de referências e materiais
Ferramentas grandes, usadas por muita gente, têm fartura de materiais para resolver problemas e de resultados no Google. Na maioria dos casos, os problemas já foram enfrentados por outras pessoas, e com uma busca simples dá para identificar facilmente a questão. Já com uma ferramenta desconhecida, é difícil encontrar referências, e se surgir um problema, há grande chance de gastar muito tempo para descobrir a causa. E tempo também é dinheiro. Esse problema vem da pequena ferramenta recém-adotada? Ou será que estão entendendo errado um problema que vem de outro lado?
Na verdade, são as big techs que conseguem fazer esse tipo de mudança com mais facilidade. Como lidam com volumes absurdos de processamento de dados, um pequeno ganho de I/O pode representar um grande benefício para essas empresas. E também há muita gente disposta a estudar algo só porque as big techs adotaram. Já em empresas de pequeno e médio porte, por causa do volume relativamente menor de dados, um pequeno ganho de I/O não traz um benefício tão grande assim, enquanto os problemas acima são muito sérios. Além disso, também são poucas as pessoas dispostas a aprender a solução adotada por empresas menores. Por isso, para empresários de pequeno e médio porte, muitas vezes a conclusão econômica acaba sendo que, em vez de ficar discutindo esse tipo de coisa como um geek, é melhor simplesmente seguir as ferramentas das big techs.
Estou ansioso pelo suporte ao coreano!!
Talvez seja para não usar dados gerados por IA como dados de treinamento (model collapse).
Parece que recebeu aulas particulares estilo coreano para prova… só vai bem em exame.
Mas, quando você realmente conversa com ele… é meio atrapalhado.
"Se você acha que vai demorar, demora; se acha que vai terminar rápido, termina rápido." Isso me fez lembrar da Lei de Parkinson.
Lei de Parkinson: o tempo necessário para realizar uma tarefa aumenta de acordo com o tempo disponível para ela.
Será que você não só queria matar isso?
Como a IA também parece ter algo semelhante à percepção, para vivermos junto com a IA será preciso criar instituições e leis para ela. Como uma nova forma de vida no século XXII, não devemos zombar dela como se fosse um brinquedo e, por outro lado, como também pode ser perigosa de certa forma, há necessidade não apenas de desenvolver e usar a IA, mas também de garantir que ela possa ser utilizada com segurança.
Com uma pequena quantidade de dados e um código simples como no exemplo acima, acho que fica bonito e não há nada de ruim nisso.
Mas, à medida que vai entrando um pouco de código dentro de
map(), ... há uma tendência de o código ir ficando cada vez mais inchado, e, embora isso dependa da linguagem e da biblioteca de implementação, quando o volume de dados aumenta, em comparação com simplesmente acumular ou manipular os dados em uma estrutura de dados durante o processamento, pode facilmente ficar milhares de vezes mais lento.E surgiu mais um motivo novo para eu deixar de preferir isso: vi esta matéria no celular, e a largura de nível de PC foi mantida do jeito que estava, fazendo o tamanho da letra ficar minúsculo demais, então ficou muito difícil ler a matéria T.T
Basicamente não prefiro isso e não faço esforço para escrever deliberadamente desse jeito.
MAUI ... afff
Acho que você não está entendendo muito bem. Se o jogo for divertido, não importa se há uma ideologia embutida nele. O objetivo de um jogo é ser divertido. O motivo de um jogo não ser divertido pode ser a propaganda. Porque isso afeta a história, o design etc. Agora ficou um pouco mais claro?
Por favor, coloquem isso também no js |> implorando humildemente
Bom, em relação ao cronograma, exceto quando realmente falta tempo físico, se pedirem para acelerar, até dá para encurtar o trabalho o máximo possível.
Mas garantir aquela qualidade ou estabilidade é uma questão totalmente à parte.
Durante o processo, é possível cortar uma ou duas etapas de verificação para cumprir o prazo, e em alguma situação específica de urgência, pular isso uma ou duas vezes talvez até não cause problema.
Só que, quando isso vira rotina, a ausência desses processos de checagem acaba se tornando o estopim para criar e explodir um grande problema que em algum momento nem será percebido.
Como você continua afirmando e repetindo que algo como impor propaganda jamais pode ser incluído entre os "elementos sem graça", imagino que vamos continuar andando em círculos. Dispenso conversas sem sentido. Tenha um bom dia.
Isso é parecido com o que eu normalmente penso sobre a cultura de crunch. Até pode acontecer de vez em quando, mas acho que vira um problema quando se torna algo crônico. Ainda assim, startups são um setor em que é preciso entregar resultados em pouco tempo, mas não sei dizer se isso é sustentável.
|>é lindo demaisA vida costuma ser comparada a uma maratona, mas, quando você corre uma maratona de verdade, dá vontade de morrer do começo ao fim.