- Replit – Build apps and sites with AI
- Replit is an AI-powered platform for building professional web apps and websites.
Платная подписка на Replit на год
Решил подписаться до 1 декабря, пока действуют скидки в честь «чёрной пятницы», чтобы попробовать инструменты AI-программирования.
Выбрал его потому, что у меня нет нормального компьютера,
- нет необходимости устанавливать компиляторы или интерпретаторы локально; запуск и проверка результатов в браузере
- изучайте программирование без забот о настройке среды.
- совместные проекты по программированию. (Если я поделюсь ссылкой, мы сможем вместе заниматься парным программированием) — При необходимости, кто угодно может присоединиться.
- быстрое создание прототипов и тестирование кода.
- интерактивное обучение программированию студентов.
- хостинг лёгких веб-приложений или API.
Надо будет ещё снять видео об этом. https://replit.com/
Взгляд на мир. (Различные новости)
Экономика
29.11.2024 (пт) Утренний распорядок (Hankyung) : снижение процентной ставки в Южной Корее с 3,25% до 3,0% / рост разрыва в доходах, снижение потребления / X-ble Shoulder (носимый робот) / ETF на акции с условиями показывают 20%-ный рост (говорят, что их покупают иностранцы)
>> В конце концов, если иностранцы не покупают, то нет способа поднять цены на акции.
IT
- 지금 주목해야 할 ‘생성 AI 소비 트렌드’ TOP 4 | 요즘IT
- 미국의 주요 기업들이 올해 3분기 실적을 발표했습니다. 실적 발표 자리에서 소위 빅테크 기업들은 생성 AI에 대한 투자를 지속할 것임을 예고했습니다. 천문학적인 금액이 쏟아지고 있는 만큼, 생성 AI 산업을 구성하는 트렌드는 빠른 속도로 변화하고 있는데요. 이번 글에서는 지난 8월 안드레센 호로위츠가 발표한 자료를 토대로 사용자들이 실제 어떤 생성 AI 서비스를 사용하고 있는지, 소비 트렌드를 살펴보고자 합니다.
- 코드 작성 시간 절반으로 줄여줄 5가지 개발 툴 | 요즘IT
- 여러분은 매일 코드 작성과 디버깅에 얼마나 많은 시간을 소비하나요? 지금부터 소개해 드릴 AI와 자동화 툴 5가지만 제대로 활용해도 그 시간을 절반으로 줄일 수 있습니다. 개발자의 하루는 해결해야 할 문제로 가득하니까요. 코드 작성을 도와주는 GitHub Copilot부터 코드 품질을 한눈에 개선해 주는 SonarQube까지. 이 툴들은 어떻게 여러분의 개발 생산성과 코드 품질을 끌어올려 줄까요?
10 привычек, которым следует следовать, чтобы стать хорошим разработчиком
>> Именно это я чувствовал, создавая и поддерживая платформу телематики/кластеров, но я не смог должным образом выполнить это. Не нужно бояться перемен, и если, как здесь, разбить задачу на мелкие части, это станет возможным.
Оригинал: на корейском , на английском
1. Поддерживайте размер коммитов как можно меньше, до такой степени, что вы можете подумать: “Действительно ли нужно делать его настолько маленьким?”
Потому что вы никогда не знаете, когда вам придётся откатывать определённые изменения. Знание точного местонахождения бага, возникшего 6 дней назад, и возможность откатить только этот коммит без сложных конфликтов слияния — это большое облегчение. Мой критерий прост: если код компилируется, его можно коммитить.
2. Следуйте заветам Кента Бека: “Чтобы сделать желаемое изменение, сначала упростите это изменение (предупреждение: это может быть сложно), а затем сделайте упрощённое изменение.”
"Чтобы сделать желаемое изменение, сначала упростите это изменение (предупреждение: это может быть сложно), а затем сделайте упрощённое изменение."
Постарайтесь, чтобы более половины всех коммитов были рефакторингом. Непрерывный рефакторинг — это поиск и внедрение улучшений, которые можно сделать менее чем за 10 минут. Благодаря этим небольшим улучшениям вы сможете решать сложные задачи простым изменением кода в будущем. Следует избегать масштабного рефакторинга.
3. Весь код — это долг.
Неразвёрнутый код — это долг из долгов. Необходимо убедиться, что код работает правильно и, по крайней мере, не ломает другие функции. Тестирование даёт уверенность, а развёртывание в продакшене обеспечивает проверку. Частые развёртывания могут немного увеличить затраты на хостинг, но это того стоит, поскольку вы можете убедиться, что ваша последняя работа действительно принесла прогресс. Один из принципов Agile гласит: “работающее программное обеспечение — основной показатель прогресса”. Здесь слова “работает” и “прогресс” имеют решающее значение, поэтому я дал своё собственное определение. “Работает” означает уровень, пригодный для развёртывания, а любой код, который вносит вклад в какую-либо функцию, — это “прогресс”.
4. Задайте себе вопрос: тестируете ли вы функциональность фреймворка? Если да, то не делайте этого.
Фреймворк уже протестирован гораздо более опытными людьми, чем вы, и вы должны доверять тому, что хук useState() работает так, как задумано. Если поддерживать размер компонентов небольшим, то фреймворк будет обрабатывать большинство важных задач, и не потребуется много тестов. По мере увеличения размера компонентов растёт сложность, и вам придётся писать всё больше тестов.
5. Если определённая функция не подходит никуда, создайте новый модуль (или класс, или компонент) и найдите для неё подходящее место позже.
Лучше создать новую независимую структуру, чем насильно вставлять её туда, где она не подходит. В худшем случае она останется независимым модулем, что не так уж плохо.
6. Если вы не знаете, как должен выглядеть API, сначала напишите тесты.
Это заставит вас думать с точки зрения “клиента”, в данном случае — вас самих. Вы сможете найти случаи, которые вы не обнаружили бы, если бы сначала написали код, а затем протестировали его. Вам не нужно быть слишком догматичным в TDD, и вы можете работать с более крупными блоками (например, писать несколько строк кода до прохождения теста). Количество кода в состоянии ошибки не всегда должно быть небольшим. Если вы знаете, что вы делаете, не позволяйте принципам снижать производительность.
7. Копирование-вставка допустимо один раз.
Не делайте второго дублирования (то есть третьего копирования). К этому моменту у вас будет достаточно примеров для создания хорошей абстракции. Объединение необходимо, так как слишком велик риск того, что реализации одной и той же функции будут разными. Лучше несколько неуклюжая параметризация, чем многократная реализация похожих функций. Если подобная ситуация повторится, будет проще улучшить параметры, чем объединять четыре разных реализации.
8. Дизайн устаревает.
Рефакторинг может замедлить этот процесс, но в конце концов вам придётся изменить способ работы. Не слишком расстраивайтесь, когда вам придётся отказаться от того, что вы когда-то ценили и чем гордились. В то время вы делали всё возможное, и вам не нужно винить себя в том, что вы не смогли сделать это идеально, чтобы изменения не потребовались. Большая часть разработки программного обеспечения заключается в изменении программного обеспечения. Примите это и двигайтесь вперёд. Идеального дизайна не существует, а изменения — это основа разработки программного обеспечения. Ваша способность эффективно вносить изменения определяет ваши навыки как разработчика.
9. Технический долг можно разделить на три категории:
1) то, что мешает текущей работе, 2) то, что будет мешать будущей работе, 3) то, что может помешать будущей работе. Все остальные классификации — это подмножества этих трёх. Сведите к минимуму #1 и сосредоточьтесь на #2. Не обращайте внимания на #3.
10. Тестируемость тесно связана с хорошим дизайном.
Трудность тестирования — это сигнал о необходимости изменения дизайна. Иногда это может быть дизайн теста. Например, если трудно имитировать em.getRepository(User).findOneOrFail({id}), лучше вынести этот вызов в отдельную функцию, которую можно имитировать, или написать утилиту для тестирования, которая позволяет легко имитировать методы менеджера сущностей. Тесты не пишутся потому, что их не хочется писать, а потому, что их трудно писать.
Комментарии0