- Replit – Build apps and sites with AI
- Replit is an AI-powered platform for building professional web apps and websites.
Assinatura paga do Replit por 1 ano
Preciso usar uma ferramenta de programação de IA, então me inscrevi por causa da promoção de Black Friday até 01/12.
A razão pela qual eu escolhi isso é que eu não tenho um computador decente,
- Execução e verificação de resultados no navegador sem necessidade de instalar compiladores ou interpretadores localmente
- Aprenda programação sem se preocupar com a configuração do ambiente.
- Projetos de codificação colaborativos. (Posso compartilhar o link para programação em pares) - Se precisar, qualquer um pode participar.
- Prototipagem e teste rápidos de código.
- Ensina codificação a alunos de forma interativa.
- Hospedagem de aplicativos web leves ou APIs.
Preciso gravar um vídeo com isso no futuro. https://replit.com/
Vamos ver o mundo. (Várias notícias)
Economia
2024-11-29 (Sex) Rotina matinal (Hankyeong) : Redução da taxa de juros coreana de 3,25% -> 3,0% / Aumento da disparidade de renda, redução do consumo / X-ble Shoulder (robô vestível) / ETF de ações de conceito navegando a 20% (diz-se que estrangeiros estão comprando)
>> Afinal, se os estrangeiros não comprarem, não há como a ação subir.
TI
- 지금 주목해야 할 ‘생성 AI 소비 트렌드’ TOP 4 | 요즘IT
- 미국의 주요 기업들이 올해 3분기 실적을 발표했습니다. 실적 발표 자리에서 소위 빅테크 기업들은 생성 AI에 대한 투자를 지속할 것임을 예고했습니다. 천문학적인 금액이 쏟아지고 있는 만큼, 생성 AI 산업을 구성하는 트렌드는 빠른 속도로 변화하고 있는데요. 이번 글에서는 지난 8월 안드레센 호로위츠가 발표한 자료를 토대로 사용자들이 실제 어떤 생성 AI 서비스를 사용하고 있는지, 소비 트렌드를 살펴보고자 합니다.
- 코드 작성 시간 절반으로 줄여줄 5가지 개발 툴 | 요즘IT
- 여러분은 매일 코드 작성과 디버깅에 얼마나 많은 시간을 소비하나요? 지금부터 소개해 드릴 AI와 자동화 툴 5가지만 제대로 활용해도 그 시간을 절반으로 줄일 수 있습니다. 개발자의 하루는 해결해야 할 문제로 가득하니까요. 코드 작성을 도와주는 GitHub Copilot부터 코드 품질을 한눈에 개선해 주는 SonarQube까지. 이 툴들은 어떻게 여러분의 개발 생산성과 코드 품질을 끌어올려 줄까요?
10 hábitos a serem mantidos para se tornar um bom desenvolvedor
>> Isso mesmo que senti ao criar e manter a plataforma de telemática/cluster, mas não consegui colocá-lo em prática. Não devemos temer a mudança, e se dividirmos isso em partes menores, como aqui, parece que será possível.
1. Mantenha seus commits pequenos, até o ponto de você pensar: \"Posso fazer isso tão pequeno?\"
Porque você nunca sabe quando precisará reverter uma alteração específica. Saber exatamente onde um bug ocorreu há 6 dias e poder revertê-lo sem conflitos de mesclagem complexos traz grande alívio. Meu critério é simples: qualquer código que compile pode ser confirmado.
2. Pratique o ditado de Kent Beck: \"Para fazer a mudança desejada, primeiro torne a mudança mais fácil (atenção: isso pode ser difícil), e então faça a mudança mais fácil.\"
\"Para fazer a mudança desejada, primeiro torne a mudança mais fácil (atenção: isso pode ser difícil), e então faça a mudança mais fácil.\"
Faça com que mais da metade de todos os seus commits sejam refatorações. Refatoração contínua significa encontrar e aplicar melhorias que podem ser feitas em menos de 10 minutos. Essas pequenas melhorias permitem que você resolva grandes solicitações com alterações simples mais tarde. Grandes refatorações devem ser evitadas.
3. Todo código é dívida.
Código não implantado é a dívida das dívidas. Você deve verificar se o código está funcionando corretamente e, pelo menos, não está quebrando outros recursos. Os testes fornecem confiança e as implantações de produção fornecem verificação. O custo de hospedagem pode aumentar um pouco com implantações frequentes, mas vale a pena verificar se seu último trabalho foi realmente um avanço. Um dos princípios ágeis é que \"software funcionando é a principal medida de progresso\". As palavras \"funcionando\" e \"progresso\" têm um significado crucial aqui, então criei minhas próprias definições. \"Funcionando\" significa um nível de implantação, e qualquer código que contribua para um recurso é \"progresso\".
4. Pergunte a si mesmo se você está testando os recursos da estrutura. Se sim, não faça isso.
A estrutura já foi testada por pessoas muito mais experientes que você, e você deve confiar que o hook useState() funciona como pretendido. Manter os componentes pequenos significa que a estrutura cuida da maior parte do trabalho pesado, então você não precisa de muitos testes. Quanto maior o componente, maior a complexidade e mais testes você precisará escrever.
5. Se uma função específica não se encaixa em lugar nenhum, crie um novo módulo (ou classe ou componente) e encontre o local apropriado mais tarde.
É melhor criar uma nova estrutura independente do que forçá-la a se encaixar onde você sente que não se encaixa. Mesmo no pior dos casos, permanecer como um módulo independente não é tão ruim.
6. Se você não sabe como uma API deve ser, escreva o teste primeiro.
Isso o força a pensar do ponto de vista do \"cliente\", que neste caso é você mesmo. Você pode encontrar casos que não teria encontrado se tivesse escrito o código primeiro e depois o teste. Você não precisa ser muito dogmático sobre TDD, e está tudo bem trabalhar em unidades maiores (por exemplo, escrever várias linhas de código antes de passar no teste). A quantidade de código em estado de falha não precisa ser pequena o tempo todo. Se você sabe o que está fazendo, não deixe que os princípios reduzam sua produtividade.
7. Copiar e colar uma vez está ok.
Não faça uma segunda duplicata (ou seja, a terceira cópia). Nesse ponto, você terá exemplos suficientes para criar uma boa abstração. O risco de implementações da mesma funcionalidade divergirem é muito alto, então a integração é necessária. Uma parametrização um tanto desajeitada é melhor do que implementar funcionalidades semelhantes várias vezes. Se essa situação acontecer novamente, será mais fácil melhorar os parâmetros do que integrar quatro implementações diferentes.
8. O design envelhece.
A refatoração pode retardar sua velocidade, mas eventualmente você precisará mudar a maneira como funciona. Não fique muito chateado quando tiver que descartar algo que você valorizou e se orgulhou no passado. Você fez o seu melhor na época, e não precisa se culpar por não ter sido perfeito o suficiente para não precisar de alterações. A maior parte do desenvolvimento de software é alterar o software. Aceite isso e siga em frente. Não existe um design perfeito, e a mudança é o cerne do desenvolvimento de software. Sua capacidade de mudar habilmente determina sua capacidade como desenvolvedor.
9. A dívida técnica pode ser categorizada em três:
1) Aqueles que estão impedindo o trabalho atual, 2) Aqueles que vão impedir o trabalho futuro, 3) Aqueles que podem impedir o trabalho futuro. Todas as outras classificações são subconjuntos desses três. Minimize o #1 e concentre-se no #2. Não se preocupe com o #3.
10. A capacidade de teste está intimamente relacionada a um bom design.
A incapacidade de testar facilmente é um sinal de que você precisa mudar o design. Às vezes, esse pode ser o design do teste. Por exemplo, se em.getRepository(User).findOneOrFail({id}) for difícil de simular, seria melhor separar essa chamada em uma função separada que possa ser simulada ou escrever uma utilidade de teste que possa simular facilmente os métodos do gerenciador de entidades. A razão pela qual os testes não são escritos não é porque não querem escrever testes, mas porque é difícil escrevê-los.
Comentários0