Мантры программирования - это не догмы, а выражения
Я считаю, что многих споров вокруг практик разработки программного обеспечения можно избежать, если просто понять, что все наши мантры нужно понимать как пословицы, а не как законы.
Если вы разбираетесь в пословицах, то знаете, что у каждой пословицы есть и противоположная по смыслу.
Это значит, что можно говорить DRY - Don't Repeat Yourself, а также WET - Write Everything Twice.
Статья: https://lukeplant.me.uk/blog/posts/programming-mantras-are-proverbs/
Я считаю, что многих споров вокруг практик разработки программного обеспечения можно избежать, если просто понять, что все наши мантры нужно понимать как пословицы, а не как законы.
Если вы разбираетесь в пословицах, то знаете, что у каждой пословицы есть и противоположная по смыслу.
Это значит, что можно говорить DRY - Don't Repeat Yourself, а также WET - Write Everything Twice.
Статья: https://lukeplant.me.uk/blog/posts/programming-mantras-are-proverbs/
Luke Plant's home page
Programming mantras are proverbs
Proverbs are supposed to encapsulate a bit of wisdom, but you still need know when to apply it.
Как разместить дата-центр в обувной коробке
Потребность мира в вычислениях требует колоссальных объемов энергии, которые скоро превысят возможности планеты. Сверхпроводники дают возможность резко снизить потребление энергии, поскольку они не рассеивают ее при прохождении тока. Хотя для их работы требуются криогенные температуры, они дают множество преимуществ, таких как соединения с нулевым сопротивлением, цифровая логика, построенная на ультракоротких импульсах, требующих минимального количества энергии, и возможность невероятной плотности вычислений благодаря простоте укладки 3D-чипов. Сверхпроводящие компьютеры могут быть более энергоэффективными, чем их классические собратья в больших масштабах.
Статья: https://spectrum.ieee.org/superconducting-computer
Потребность мира в вычислениях требует колоссальных объемов энергии, которые скоро превысят возможности планеты. Сверхпроводники дают возможность резко снизить потребление энергии, поскольку они не рассеивают ее при прохождении тока. Хотя для их работы требуются криогенные температуры, они дают множество преимуществ, таких как соединения с нулевым сопротивлением, цифровая логика, построенная на ультракоротких импульсах, требующих минимального количества энергии, и возможность невероятной плотности вычислений благодаря простоте укладки 3D-чипов. Сверхпроводящие компьютеры могут быть более энергоэффективными, чем их классические собратья в больших масштабах.
Статья: https://spectrum.ieee.org/superconducting-computer
Fortran и COBOL снова вошли в Индекс TIOBE
Индекс TIOBE призван отразить относительную популярность компьютерных языков, поэтому стало неожиданностью появление в Топ-20 двух языков, появление которых датируется пятидесятыми годами.
1. Войдя в Топ-20 в апреле 2021 года, Fortran продолжает расти и теперь поднялся на самую высокую за всю историю позицию — №10. Это действительно достижение для языка, который впервые был выпущен в октябре 1956 года с полным названием «Система трансляции формул IBM» (The IBM Formula Translating System).
2. "Основная причина воскрешения Fortran — растущая важность численных/математических вычислений. Несмотря на множество конкурентов в этой области, у Fortran есть причины для существования. В джунглях языков Фортран кажется быстрым, имеющим встроенную поддержку математических вычислений, зрелым и бесплатным. Тихо, медленно, но верно Фортран завоевывает позиции. Это удивительно, но неоспоримо".
3. Другой legacy-язык, который растет в индексе TIOBE — это COBOL. В январе 2024 года он вновь вошел в Топ-20 ,потом выпал, а в этом месяце снова оказался там на 20 месте.
4. Разработанный в 1959 году, COBOL до сих пор широко используется в legacy-системах, лежащих в основе критически важных бизнес-операций в таких отраслях, как банковское дело, страхование и здравоохранение. Его наивысшая позиция в индексе TIOBE была №8 в 2001 году, и хотя можно было бы ожидать, что он уже давно сошел со сцены, исследование 2022 года, проведенное по заказу поставщика COBOL компании Micro Focus, показало, что организации все еще держатся за свой COBOL-код, и что количество приложений на COBOL на самом деле не сокращается, а растет.
И что: старый, но не устаревший (С) И эти люди говорят про legacy код годичной давности 😀
Индекс TIOBE призван отразить относительную популярность компьютерных языков, поэтому стало неожиданностью появление в Топ-20 двух языков, появление которых датируется пятидесятыми годами.
1. Войдя в Топ-20 в апреле 2021 года, Fortran продолжает расти и теперь поднялся на самую высокую за всю историю позицию — №10. Это действительно достижение для языка, который впервые был выпущен в октябре 1956 года с полным названием «Система трансляции формул IBM» (The IBM Formula Translating System).
2. "Основная причина воскрешения Fortran — растущая важность численных/математических вычислений. Несмотря на множество конкурентов в этой области, у Fortran есть причины для существования. В джунглях языков Фортран кажется быстрым, имеющим встроенную поддержку математических вычислений, зрелым и бесплатным. Тихо, медленно, но верно Фортран завоевывает позиции. Это удивительно, но неоспоримо".
3. Другой legacy-язык, который растет в индексе TIOBE — это COBOL. В январе 2024 года он вновь вошел в Топ-20 ,потом выпал, а в этом месяце снова оказался там на 20 месте.
4. Разработанный в 1959 году, COBOL до сих пор широко используется в legacy-системах, лежащих в основе критически важных бизнес-операций в таких отраслях, как банковское дело, страхование и здравоохранение. Его наивысшая позиция в индексе TIOBE была №8 в 2001 году, и хотя можно было бы ожидать, что он уже давно сошел со сцены, исследование 2022 года, проведенное по заказу поставщика COBOL компании Micro Focus, показало, что организации все еще держатся за свой COBOL-код, и что количество приложений на COBOL на самом деле не сокращается, а растет.
И что: старый, но не устаревший (С) И эти люди говорят про legacy код годичной давности 😀
Как Google проводит Code Review
Чаще всего, когда инженеры впервые узнают об этом процессе, я слышу такие фразы: "Вау, эти инструменты выглядят потрясающе" и "Этот процесс утверждения кажется утомительным".
Статья: https://graphite.dev/blog/how-google-does-code-review
Чаще всего, когда инженеры впервые узнают об этом процессе, я слышу такие фразы: "Вау, эти инструменты выглядят потрясающе" и "Этот процесс утверждения кажется утомительным".
Статья: https://graphite.dev/blog/how-google-does-code-review
Как писать коммит сообщения
Руководство по составлению сообщений для коммитов должно быть сосредоточено на информации, а не на типографике. Что вы включаете, а что опускаете? Правило, гласящее "объясните, почему и что", должно было занимать большую часть списка, а не быть брошенным в конце.
Статья: https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/commit-messages/
Руководство по составлению сообщений для коммитов должно быть сосредоточено на информации, а не на типографике. Что вы включаете, а что опускаете? Правило, гласящее "объясните, почему и что", должно было занимать большую часть списка, а не быть брошенным в конце.
Статья: https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/commit-messages/
Как мы собеседовали ChatGPT на позицию QA
Мы — Аня, Оля и Дима, тестировщики в hh.ru. Не так давно мы прочитали про случай, где адвокат использовал ChatGPT для подготовки аргументации стороны обвинения в суде. Ситуация может показаться абсолютно дикой: это же очевидно, что нельзя доверить искусственному интеллекту свою карьеру. Но мы не были бы тестировщиками, если бы не решили проверить, а сможет ли ChatGPT помочь подготовить нас к собеседованию.
Статья: https://habr.com/ru/companies/hh/articles/815143/
Мы — Аня, Оля и Дима, тестировщики в hh.ru. Не так давно мы прочитали про случай, где адвокат использовал ChatGPT для подготовки аргументации стороны обвинения в суде. Ситуация может показаться абсолютно дикой: это же очевидно, что нельзя доверить искусственному интеллекту свою карьеру. Но мы не были бы тестировщиками, если бы не решили проверить, а сможет ли ChatGPT помочь подготовить нас к собеседованию.
Статья: https://habr.com/ru/companies/hh/articles/815143/
Amber - язык программирования, который компилируется в Bash. Это язык программирования высокого уровня, позволяющий легко создавать скрипты. Он особенно хорошо подходит для облачных сервисов.
GitHub: https://github.com/Ph0enixKM/Amber
GitHub: https://github.com/Ph0enixKM/Amber
🔥2
Геймдев, про который мы забыли: как работали 2D-игры на кнопочных телефонах нулевых
А вы помните, какими были мобильные игры в 2000-х годах? Помните, как разработчики умудрялись уместить целые миры в устройство с небольшим дисплеем, аппаратной клавиатурой, весьма слабым железом и парой сотен килобайт памяти? Но задумывались ли вы, как в своё время работали эти сами игры «под капотом»? В сегодняшней статье-ретроспективе предлагаю вспомнить мобильный геймдев нулевых и узнать, как же работали 2D Java-игры, какие API были доступны и что из себя представлял средний телефон тех лет.
Статья: https://habr.com/ru/companies/timeweb/articles/814975/
А вы помните, какими были мобильные игры в 2000-х годах? Помните, как разработчики умудрялись уместить целые миры в устройство с небольшим дисплеем, аппаратной клавиатурой, весьма слабым железом и парой сотен килобайт памяти? Но задумывались ли вы, как в своё время работали эти сами игры «под капотом»? В сегодняшней статье-ретроспективе предлагаю вспомнить мобильный геймдев нулевых и узнать, как же работали 2D Java-игры, какие API были доступны и что из себя представлял средний телефон тех лет.
Статья: https://habr.com/ru/companies/timeweb/articles/814975/
Куда уходят программисты?
Почему мы не видим в индустрии большого количества седовласых разработчиков? Куда уходят программисты, когда становятся старше?
Статья: https://apptractor.ru/info/articles/kuda-uhodyat-programmisty.html
Почему мы не видим в индустрии большого количества седовласых разработчиков? Куда уходят программисты, когда становятся старше?
Статья: 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
1. Копайте глубже
2. Пишите отличные тесты как можно раньше
3. Расставляйте приоритеты
4. Модуляризируйте
5. Хорошо пишите
6. Говорите людям «нет»
7. Уделяйте время наблюдаемости
Статья: https://apptractor.ru/info/articles/7-ezhednevnyh-praktik-luchshih-razrabotchikov.html
🤮2😁1
Пишем клон Unix примерно за месяц
Недавно мне нужно было немного отдохнуть от "настоящей работы", поэтому я начал новый проект по программированию, который не требовал больших затрат и был чисто развлекательным. 21 апреля я решил посмотреть, сколько Unix-подобной операционной системы для x86_64 я смогу собрать примерно за месяц. Результатом стал Bunnix. Не считая дней, когда я не работал над Bunnix по тем или иным причинам, я потратил на этот проект 27 дней.
Статья: https://drewdevault.com/2024/05/24/2024-05-24-Bunnix.html
Недавно мне нужно было немного отдохнуть от "настоящей работы", поэтому я начал новый проект по программированию, который не требовал больших затрат и был чисто развлекательным. 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
Я хочу поделиться некоторыми из самых удивительных вещей, которые я усвоил в этих наблюдениях, примерно в порядке от наиболее общего к наиболее специфичному для безопасности.
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/
Спустя несколько месяцев после ввода системы в эксплуатацию мне позвонил один из менеджеров, пользовавшихся нашим ПО.
Он сообщил, что в теле одного из отправляемых заказчику писем отсутствует точка. Самое загадочное было то, что такое происходило только с этим конкретным заказчиком; при отправке того же письма другому заказчику точка не исчезала.
Статья: https://habr.com/ru/companies/ruvds/articles/817395/
Три закона сложности программного обеспечения (или почему разработчики всегда ворчат)
1. Хорошо спроектированная система со временем превращается в плохо спроектированную.
2. Сложность - это ров (заполненный негерметичными абстракциями).
3. Не существует фундаментального верхнего предела сложности программного обеспечения.
Статья: https://maheshba.bitbucket.io/blog/2024/05/08/2024-ThreeLaws.html
1. Хорошо спроектированная система со временем превращается в плохо спроектированную.
2. Сложность - это ров (заполненный негерметичными абстракциями).
3. Не существует фундаментального верхнего предела сложности программного обеспечения.
Статья: https://maheshba.bitbucket.io/blog/2024/05/08/2024-ThreeLaws.html
mahesh’s blog
Three Laws of Software Complexity (or: why software engineers are always grumpy)
I posit that most software engineers (particularly those working on infrastructural systems) are destined to wallow in unnecessary complexity due to three fundamental laws.
Работа имеет нормальное распределение, обучение - логнормальное
В этой теории интересно то, что она предполагает, что бизнес-процессы с нормальным распределением - это в некотором смысле исключение, а не норма. В каждом новом процессе, который приходится выполнять человеку, есть хотя бы часть фазы, на которой преобладает обучение. Это так же верно в отношении веб-разработки, как и в отношении обучения работе с автоматами в McDonald's. Требуется особая строгость, чтобы превратить это в деятельность, рутинную и повторяющуюся настолько, что вы получите длинный хвост нормально распределенной, прибыльной деятельности. Опять же, в этом есть смысл: я создаю сайты и веб-приложения на Django и Hugo уже несколько лет, а Python использую гораздо дольше, и сейчас я как бы интуитивно чувствую, сколько времени у меня займет любой из них. Это не потому, что я какой-то гениальный - это потому, что я уже достаточно много раз проходил по негерметичному трубопроводу, чтобы знать, как мне подходить к большинству вещей. Как только я оказываюсь на новой территории, мы снова возвращаемся к негерметичному трубопроводу.
Статья: https://hiandrewquinn.github.io/til-site/posts/doing-is-normally-distributed-learning-is-log-normal/
В этой теории интересно то, что она предполагает, что бизнес-процессы с нормальным распределением - это в некотором смысле исключение, а не норма. В каждом новом процессе, который приходится выполнять человеку, есть хотя бы часть фазы, на которой преобладает обучение. Это так же верно в отношении веб-разработки, как и в отношении обучения работе с автоматами в McDonald's. Требуется особая строгость, чтобы превратить это в деятельность, рутинную и повторяющуюся настолько, что вы получите длинный хвост нормально распределенной, прибыльной деятельности. Опять же, в этом есть смысл: я создаю сайты и веб-приложения на Django и Hugo уже несколько лет, а Python использую гораздо дольше, и сейчас я как бы интуитивно чувствую, сколько времени у меня займет любой из них. Это не потому, что я какой-то гениальный - это потому, что я уже достаточно много раз проходил по негерметичному трубопроводу, чтобы знать, как мне подходить к большинству вещей. Как только я оказываюсь на новой территории, мы снова возвращаемся к негерметичному трубопроводу.
Статья: https://hiandrewquinn.github.io/til-site/posts/doing-is-normally-distributed-learning-is-log-normal/
hiandrewquinn.github.io
Doing is normally distributed, learning is log-normal
There are few things I think about more than the essays on gwern.net, and there are few with as satisfying a theoretical payout to contemplate in my orb as his essay on “leaky pipelines”, aka log-normal distributions.
The skulk: Say you’re working on a Laravel…
The skulk: Say you’re working on a Laravel…
Про переработки
Не пытайся обменивать свое время на деньги. Меняй его на фан, профессиональный рост и самореализацию. Прямая конвертация труда в деньги обычно происходит по не самому выгодному курсу. Гораздо эффективнее вкладывать эти часы в обучение тому чего ты раньше делать не умел, и в будущем продавать уже эти умения по сильно большему ценнику.
Статья: https://apptractor.ru/info/articles/pro-pererabotki.html
Не пытайся обменивать свое время на деньги. Меняй его на фан, профессиональный рост и самореализацию. Прямая конвертация труда в деньги обычно происходит по не самому выгодному курсу. Гораздо эффективнее вкладывать эти часы в обучение тому чего ты раньше делать не умел, и в будущем продавать уже эти умения по сильно большему ценнику.
Статья: https://apptractor.ru/info/articles/pro-pererabotki.html
👍5
Делаем кондиционер умным с помощью Elixir и Nerves
С каждым днём всё ближе обжигающее японское лето, поэтому я всё больше думал о своей давней идее: дистанционном управлении кондиционером воздуха в моей спальне через Интернет. Простым нажатием кнопки за десять минут до отправления ко сну я мог бы включить кондиционер, который бы превращал спальню в прохладный комфортный оазис к тому моменту, как я почищу зубы и поднимусь на второй этаж. В прошлом году это так и осталось идеей; в этом году я довёл её до реализации.
Перевод: https://habr.com/ru/companies/ruvds/articles/818021/
С каждым днём всё ближе обжигающее японское лето, поэтому я всё больше думал о своей давней идее: дистанционном управлении кондиционером воздуха в моей спальне через Интернет. Простым нажатием кнопки за десять минут до отправления ко сну я мог бы включить кондиционер, который бы превращал спальню в прохладный комфортный оазис к тому моменту, как я почищу зубы и поднимусь на второй этаж. В прошлом году это так и осталось идеей; в этом году я довёл её до реализации.
Перевод: https://habr.com/ru/companies/ruvds/articles/818021/
Openpanel — альтернатива Mixpanel с открытым исходным кодом. Это простой инструмент аналитики для регистрации событий на сайте, в приложениях и на бэкенде. Авторы попытались объединить Mixpanel и Plausible в одном продукте. Сейчас есть аналитика в реальном времени, отслеживание произвольного количества событий, любые кастомные свойства для них, графики, отчеты и воронки, хостинг в любом облаке.
SDK для мобильных платформ (кроме React Native) пока нет, но есть API.
Openpanel на GitHub: https://github.com/Openpanel-dev/openpanel
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
Многим из нас рассказывали о достоинствах принципа «Не повторяйся» или DRY. Сделайте паузу и подумайте: является ли дублирование действительно избыточным или функциональность должна развиваться независимо со временем? Слишком жесткое применение принципов DRY приводит к преждевременным абстракциям, которые делают будущие изменения более сложными, чем это необходимо.
Внимательно изучите, является ли код действительно избыточным или просто поверхностно похожим. Хотя функции или классы могут выглядеть одинаково, они могут обслуживать разные контексты и бизнес-требования, которые со временем меняются. Подумайте о том, как меняется назначение функций со временем, а не только о том, как сделать код короче. При разработке абстракций не следует преждевременно объединять поведение, которое в долгосрочной перспективе может развиваться отдельно.
Статья: https://testing.googleblog.com/2024/05/dont-dry-your-code-prematurely.html
Google Testing Blog
Don't DRY Your Code Prematurely
This is another post in our Code Health series. A version of this post originally appeared in Google bathrooms worldwide as a Google Tes...
Воображаемые проблемы — корень плохого программного обеспечения
Существует множество факторов, которые могут стать катализатором плохого программного обеспечения: от используемых инструментов, общения в команде, личной заинтересованности разработчиков в успехе до методологии тестирования.
Я предполагаю, что средфи них есть одна главная проблема, толчок к созданию плохого программного обеспечения, из которого берут начало почти все остальные — воображаемые проблемы.
Статья: https://apptractor.ru/info/articles/voobrazhaemye-problemy-koren-plohogo-programmnogo-obespecheniya.html
Существует множество факторов, которые могут стать катализатором плохого программного обеспечения: от используемых инструментов, общения в команде, личной заинтересованности разработчиков в успехе до методологии тестирования.
Я предполагаю, что средфи них есть одна главная проблема, толчок к созданию плохого программного обеспечения, из которого берут начало почти все остальные — воображаемые проблемы.
Статья: https://apptractor.ru/info/articles/voobrazhaemye-problemy-koren-plohogo-programmnogo-obespecheniya.html
👍1