Как мы собеседовали ChatGPT на позицию QA

Мы — Аня, Оля и Дима, тестировщики в hh.ru. Не так давно мы прочитали про случай, где адвокат использовал ChatGPT для подготовки аргументации стороны обвинения в суде. Ситуация может показаться абсолютно дикой: это же очевидно, что нельзя доверить искусственному интеллекту свою карьеру. Но мы не были бы тестировщиками, если бы не решили проверить, а сможет ли ChatGPT помочь подготовить нас к собеседованию.

Статья: https://habr.com/ru/companies/hh/articles/815143/

Amber - язык программирования, который компилируется в Bash. Это язык программирования высокого уровня, позволяющий легко создавать скрипты. Он особенно хорошо подходит для облачных сервисов.

GitHub: https://github.com/Ph0enixKM/Amber

Геймдев, про который мы забыли: как работали 2D-игры на кнопочных телефонах нулевых

А вы помните, какими были мобильные игры в 2000-х годах? Помните, как разработчики умудрялись уместить целые миры в устройство с небольшим дисплеем, аппаратной клавиатурой, весьма слабым железом и парой сотен килобайт памяти? Но задумывались ли вы, как в своё время работали эти сами игры «под капотом»? В сегодняшней статье-ретроспективе предлагаю вспомнить мобильный геймдев нулевых и узнать, как же работали 2D Java-игры, какие API были доступны и что из себя представлял средний телефон тех лет.

Статья: https://habr.com/ru/companies/timeweb/articles/814975/

Куда уходят программисты?

Почему мы не видим в индустрии большого количества седовласых разработчиков? Куда уходят программисты, когда становятся старше?

Статья: https://apptractor.ru/info/articles/kuda-uhodyat-programmisty.html

7 ежедневных практик лучших разработчиков

1. Копайте глубже
2. Пишите отличные тесты как можно раньше
3. Расставляйте приоритеты
4. Модуляризируйте
5. Хорошо пишите
6. Говорите людям «нет»
7. Уделяйте время наблюдаемости

Статья: https://apptractor.ru/info/articles/7-ezhednevnyh-praktik-luchshih-razrabotchikov.html

Пишем клон Unix примерно за месяц

Недавно мне нужно было немного отдохнуть от "настоящей работы", поэтому я начал новый проект по программированию, который не требовал больших затрат и был чисто развлекательным. 21 апреля я решил посмотреть, сколько Unix-подобной операционной системы для x86_64 я смогу собрать примерно за месяц. Результатом стал Bunnix. Не считая дней, когда я не работал над Bunnix по тем или иным причинам, я потратил на этот проект 27 дней.

Статья: https://drewdevault.com/2024/05/24/2024-05-24-Bunnix.html

Уроки 5 лет аудита кода стартапов

Я хочу поделиться некоторыми из самых удивительных вещей, которые я усвоил в этих наблюдениях, примерно в порядке от наиболее общего к наиболее специфичному для безопасности.

1. Вам не нужны сотни инженеров, чтобы создать отличный продукт
2. Простой обгоняет умного
3. Наши наиболее важные выводы всегда приходили в течение первых и последних нескольких часов аудита
4. За последние 10 лет писать безопасное программное обеспечение стало значительно проще
5. Все действительно серьезные уязвимости безопасности были очевидны
6. Функции безопасности по умолчанию в платформах и инфраструктуре значительно повысили безопасность
7. Монорепозитории легче проверять
8. Вы легко можете потратить весь аудит на поиск уязвимых зависимостей
9. Никогда не десериализуйте ненадежные данные
11. Кастомный фаззинг оказался на удивление эффективным
12. Покупки стартапов немного усложняли безопасность
13. Среди инженеров-программистов всегда был хотя бы один тайный энтузиаст безопасности
14. Быстрые действия по устранению уязвимостей обычно коррелируют с общим техническим операционным превосходством
15. Практически никто не работа с JWT-токенами и вебхуками правильно
16. Все еще используется много MD5, но в основном это ложные срабатывания

Статья: https://apptractor.ru/info/articles/uroki-5-let-audita-koda-startapov.html

Загадочное дело о пропавшей точке

Спустя несколько месяцев после ввода системы в эксплуатацию мне позвонил один из менеджеров, пользовавшихся нашим ПО.

Он сообщил, что в теле одного из отправляемых заказчику писем отсутствует точка. Самое загадочное было то, что такое происходило только с этим конкретным заказчиком; при отправке того же письма другому заказчику точка не исчезала.

Статья: https://habr.com/ru/companies/ruvds/articles/817395/

Три закона сложности программного обеспечения (или почему разработчики всегда ворчат)

1. Хорошо спроектированная система со временем превращается в плохо спроектированную.
2. Сложность - это ров (заполненный негерметичными абстракциями).
3. Не существует фундаментального верхнего предела сложности программного обеспечения.

Статья: https://maheshba.bitbucket.io/blog/2024/05/08/2024-ThreeLaws.html

Работа имеет нормальное распределение, обучение - логнормальное

В этой теории интересно то, что она предполагает, что бизнес-процессы с нормальным распределением - это в некотором смысле исключение, а не норма. В каждом новом процессе, который приходится выполнять человеку, есть хотя бы часть фазы, на которой преобладает обучение. Это так же верно в отношении веб-разработки, как и в отношении обучения работе с автоматами в McDonald's. Требуется особая строгость, чтобы превратить это в деятельность, рутинную и повторяющуюся настолько, что вы получите длинный хвост нормально распределенной, прибыльной деятельности. Опять же, в этом есть смысл: я создаю сайты и веб-приложения на Django и Hugo уже несколько лет, а Python использую гораздо дольше, и сейчас я как бы интуитивно чувствую, сколько времени у меня займет любой из них. Это не потому, что я какой-то гениальный - это потому, что я уже достаточно много раз проходил по негерметичному трубопроводу, чтобы знать, как мне подходить к большинству вещей. Как только я оказываюсь на новой территории, мы снова возвращаемся к негерметичному трубопроводу.

Статья: https://hiandrewquinn.github.io/til-site/posts/doing-is-normally-distributed-learning-is-log-normal/

Про переработки

Не пытайся обменивать свое время на деньги. Меняй его на фан, профессиональный рост и самореализацию. Прямая конвертация труда в деньги обычно происходит по не самому выгодному курсу. Гораздо эффективнее вкладывать эти часы в обучение тому чего ты раньше делать не умел, и в будущем продавать уже эти умения по сильно большему ценнику.

Статья: https://apptractor.ru/info/articles/pro-pererabotki.html

Делаем кондиционер умным с помощью Elixir и Nerves

С каждым днём всё ближе обжигающее японское лето, поэтому я всё больше думал о своей давней идее: дистанционном управлении кондиционером воздуха в моей спальне через Интернет. Простым нажатием кнопки за десять минут до отправления ко сну я мог бы включить кондиционер, который бы превращал спальню в прохладный комфортный оазис к тому моменту, как я почищу зубы и поднимусь на второй этаж. В прошлом году это так и осталось идеей; в этом году я довёл её до реализации.

Перевод: https://habr.com/ru/companies/ruvds/articles/818021/

Openpanel — альтернатива Mixpanel с открытым исходным кодом. Это простой инструмент аналитики для регистрации событий на сайте, в приложениях и на бэкенде. Авторы попытались объединить Mixpanel и Plausible в одном продукте. Сейчас есть аналитика в реальном времени, отслеживание произвольного количества событий, любые кастомные свойства для них, графики, отчеты и воронки, хостинг в любом облаке.

SDK для мобильных платформ (кроме React Native) пока нет, но есть API.

Openpanel на GitHub: https://github.com/Openpanel-dev/openpanel

Не применяйте DRY преждевременно

Многим из нас рассказывали о достоинствах принципа «Не повторяйся» или DRY. Сделайте паузу и подумайте: является ли дублирование действительно избыточным или функциональность должна развиваться независимо со временем? Слишком жесткое применение принципов DRY приводит к преждевременным абстракциям, которые делают будущие изменения более сложными, чем это необходимо.

Внимательно изучите, является ли код действительно избыточным или просто поверхностно похожим. Хотя функции или классы могут выглядеть одинаково, они могут обслуживать разные контексты и бизнес-требования, которые со временем меняются. Подумайте о том, как меняется назначение функций со временем, а не только о том, как сделать код короче. При разработке абстракций не следует преждевременно объединять поведение, которое в долгосрочной перспективе может развиваться отдельно.

Статья: https://testing.googleblog.com/2024/05/dont-dry-your-code-prematurely.html

Воображаемые проблемы — корень плохого программного обеспечения

Существует множество факторов, которые могут стать катализатором плохого программного обеспечения: от используемых инструментов, общения в команде, личной заинтересованности разработчиков в успехе до методологии тестирования.

Я предполагаю, что средфи них есть одна главная проблема, толчок к созданию плохого программного обеспечения, из которого берут начало почти все остальные — воображаемые проблемы.

Статья: https://apptractor.ru/info/articles/voobrazhaemye-problemy-koren-plohogo-programmnogo-obespecheniya.html

А где она, очередь за забором?

С одной стороны рынка огромное предложение, с другой огромный спрос. Казалось бы, что не так... Но спрос он на конфеты, а предложение состоит в основном из пустых внутри фантиков.

Статья: https://habr.com/ru/articles/819389/

Почему не стоит использовать IDE для написания кода

Вот что происходит, когда вы не используете IDE для написания кода.

Статья: https://apptractor.ru/info/articles/pochemu-ne-stoit-ispolzovat-ide-dlya-napisaniya-koda.html

Управление мотивацией для соло-разработчика

Один из самых больших камней преткновения в одиночной работе - это поддержание мотивации. Я веду записи в журнале о том, как управлять своей мотивацией, что работает, а что нет. Вот то, что сработало.

Статья: https://mbuffett.com/posts/maintaining-motivation/

Agile увеличивает риск провала проекта на 268%

Исследование показало, что вероятность провала программных проектов, использующих Agile-методики, на 268% выше, чем у тех, кто их не использует.

Хотя исследование, проведенное по заказу консалтинговой компании Engprax, можно рассматривать как тонко завуалированную рекламу методологии Impact Engineering, оно усиливает подозрения в том, что Agile-манифест может оказаться не совсем тем, за что его выдают.

Новость: https://apptractor.ru/info/analytics/agile-uvelichivaet-risk-provala-proekta-na-268.html

10 правил NASA для написания критически важного кода

У разработчиков NASA одна из самых сложных работ в мире программирования. Они пишут код и разрабатывают критически важные приложения, в первую очередь заботясь о безопасности и надежности.

Статья: https://apptractor.ru/info/articles/10-nasa-critical-rules.html