Привет, Хабр! Мы с почином — в блоге SSP SOFT стартует новая рубрика с анонсами выхода книг по программированию и операционным системам от издательства «БХВ-Петербург». Узнав об этой инициативе, издатель подарил всем читателям Хабра специальную скидку по промокоду, который вы найдете в тексте. Начнем рубрику, пожалуй, с пары новых книг про Python, которые вышли за последний месяц. Ревью книг — не копия текста с сайта издательства, а сугубо наше мнение, после прочтения.
Совершенный код *
Как Макконнелл завещал
Новости
Как мы упростили работу с данными с помощью пайплайна: пошаговый план
Привет, меня зовут Руслан Шкарин. Я Senior Software Engineer и это моя первая статья в DIY-медиа вАЙТИ от beeline cloud. Расскажу, как занимался построением пайплайна для сбора и анализа логов системы в реальном времени для сервиса, который обходил сотни тысяч веб-страниц и парсил контактные данные.
Как облегчить жизнь программисту при написании тестов
Наверняка, многие из вас работали или хотя бы слышали о том, что есть разработчики, которые работают над проектом в одиночку. Ну как в одиночку… Есть скрам, аналитик, продакт, еще кто-то вплоть до директора, а вот программист один, даже тестировщика нет. В этом случае оптимальным видом тестирования, на мой взгляд, является интеграционное тестирование с использованием тест-контейнеров.
Привет, Хабр! Меня зовут Николай Пискунов — ведущий разработчик в подразделении Big Data. И сегодня в блоге beeline cloud поговорим о Spring boot и интеграционном тестировании. Расскажу, как упростить жизнь при написании тестов.
Async/await, There is no thread – легко обмануть тех, кто сам обманываться рад
Когда нам показывают на некотором примере, что асинхронная операция не создает потока, нам пытаются внушить, что асинхронная операция НИКОГДА не создает потока и в принципе не может его создать, но это не правда! Простой пример с работающим кодом доказывает обратное. Давайте разберем этот пример.
Логика тех, кто поддается такому внушению мне вполне понятна, они хотят упростить себе жизнь, сократить объем теории, с которой надо разбираться.
Интересно было бы понять логику тех, кто поддерживает такое внушение, выдавая обрезанную теорию за полноценную, вполне осознавая, что все не так просто, как хотелось бы.
Истории
Книга «Жемчужины разработки. Чему мы научились за 50 лет создания ПО»
Совершенное программное обеспечение невозможно создать без изучения накопленного опыта.
Опыт — главный учитель, но медленный и нередко болезненный. Но зачем же нам повторять ошибки? Книга «Жемчужины разработки» поможет совершенствоваться быстрее и избежать многих проблем, обучаясь на опыте других людей, которые уже поднялись по кривой обучения. Карл Вигерс сформулировал 60 кратких практических уроков, которые подойдут для любых проектов, независимо от роли, отрасли, технологии или методологии.
Идеи и конкретные рекомендации охватывают шесть важнейших элементов успеха: требования, дизайн, управление проектами, культуру и командную работу, качество и совершенствование процессов. Для каждого из направлений Вигерс предлагает «первые шаги», позволяющие осмыслить собственный опыт, уроки с основными идеями, реальными примерами и действенными решениями и «следующие шаги» для внедрения опыта в вашем проекте, команде или организации. Эти знания нельзя получить в университете!
А ты хорошо знаешь Go? Держи пару полезностей по оптимизации кода
Привет, Хабр!
Эта статья — моя подборка приёмов и техник, которые помогут писать лаконичный и производительный код на Go без лишних костылей и велосипедов.
Речь пойдёт о:
полезностях для конкурентного программирования
приёмах в Go в целом, таких как использование iota
, работа с ошибками, вывод интерфейса и т.д.
методах оптимизации работы со слайсами
Обсудим, как избежать ненужной аллокации памяти, как быть с состоянием гонки, поговорим про компактность и лаконичность кода и ещё про массу полезных штук.
Книга «Грокаем Continuous Delivery»
Привет, Хаброжители!
Код должен быть готов к релизу всегда!
Пайплайн Continuous Delivery автоматизирует процессы контроля версий, тестирования и развертывания при минимальном вмешательстве разработчика. Освойте инструменты и методы непрерывной доставки, и вы сможете быстро и последовательно добавлять функции и выпускать обновления.
«Грокаем Continuous Delivery» — это руководство по настройке и работе с пайплайном непрерывной доставки. В каждой главе рассматривается отдельный сценарий, с которым вы столкнетесь при создании системы CD, и приводятся реальные примеры, например автоматическое масштабирование и тестирование унаследованных приложений. Кристи Уилсон сопровождает каждый шаг иллюстрациями, кристально четкими объяснениями и практическими упражнениями для закрепления полученных знаний.
Как работает код, который спит месяц
В первой части этого небольшого цикла статей мы говорили о том, что механизм устойчивого выполнения (durable execution) сохраняет состояние программы в журнале, а также о связанных с этим сложностях в случае обновлений служебного кода, ведущих к утрате журналом актуальности. Мы увидели, что ограничение времени выполнения обработчика существенно облегчает эту проблему. Но… не ведёт ли это к потере одного из наиболее интересных свойств устойчивого выполнения — возможности создавать бизнес-процессы, работающие с длительными паузами? В Restate мы считаем, что при использовании правильных примитивов можно ничего не потерять.
Тем не менее, если вы любите писать код с долгими периодами ожидания, потому что он хорошо согласуется с вашей моделью мышления, то Restate поможет вам реализовать это в полной мере. Если же вы цените устойчивое выполнение, но скептично относитесь к долго выполняющимся обработчикам и проблемам с их версионированием, то для этого есть решение. Ниже описаны несколько способов получить те же свойства путём добавления в этот механизм устойчивого обмена сообщениями и состояния.
При полной луне этот код работал иначе
На Github есть один баг, он называется «Эффект гистерезиса в методе подъема на холм применительно к пулу потоков» – очень интересное чтение. Подъем на холм – это алгоритмическая техника: у вас есть холм (некая проблема), вы понемногу улучшаете ситуацию (поднимаетесь), пока не достигнете определенного максимально приемлемого решения (вершины холма).
Себастьян, автор описания бага, говорит, что у пула потоков прослеживается влияние эффекта гистерезиса. «Гистерезис – это зависимость состояния системы от предшествующих событий». Нечто странное происходит по той причине, что до этого произошло еще что-то… но что именно?
Edge ML для людей с ограниченными возможностями
С развитием технологий появились новые возможности для людей с ограниченными возможностями. Edge Machine Learning (Edge ML) представляет собой передовую технологию, которая приближает алгоритмы машинного обучения к источнику данных, что сокращает задержку и улучшает возможности обработки данных в реальном времени.
В этой статье мы рассмотрим потенциал применения Edge ML для решения уникальных проблем, с которыми сталкиваются люди с особыми потребностями. Edge ML может способствовать созданию более поддерживающей и доступной среды, что так важно для поддержки людей, которые и так оказались в непростом положении. Мы рассмотрим различные аспекты, вызовы и потенциальные улучшения, формирующие эволюцию модели Edge ML. Эта модель сфокусирована на двух основных задачах: выявлении случаев запугивания и предоставлении успокаивающей поддержки.
Приступим (:
Почему проверять результат вызова malloc c помощью assert плохая идея
Указатель, который вернула функция malloc, необходимо проверить перед использованием. Неправильным решением будет использовать для этого макрос assert. В этой статье мы разберём, почему это является антипаттерном.
Сохраняем простоту кода и ускоряем разработку за счет отказа от оверинжиринга
Мой совет: если хотите ускориться, пишите код как можно проще и как можно чище.
Как построить работу над кодом
Чтобы всем было удобно его писать, обсуждать и рефакторить — без распухшего бэклога и лица девопса.
Мне кажется, что если спросить 10 случайных разработчиков о том, как у них в командах устроена работа над кодом, то в 9 случаев ответ будет «Ну, как придётся. Как привыкли!».
Это удивительно для отрасли, в которой есть настоящий культ менеджерских практик: по ним пишут книги, проводят конференции, им учат. Но редко когда учат практикам хорошей работы над кодом! В крайнем случае в команде найдется опытный лид или человек с хорошим системным мышлением, который при этом готов и помочь коллегам стать лучше.
Напомню вам базовые правила, с которых нужно начинать работу в этом направлении. Побуду вашим системным лидом на полчаса, так сказать!
Ближайшие события
Как на самом деле Async/Await работают в C#. Часть 6. Анализ результатов компиляции асинхронных вызовов
В этой статье мы продолжим разбирать содержание работы Stephen Toub-а: «How Async/Await Really Works in C#». В этот раз, в след за автором исходного Поста мы рассмотрим код, который генерирует C# компилятор для реализации асинхронных вызовов и множество связанных с этим сущностей-понятий-приемов, таких как: контекст исполнения, боксинг, стейт машина, стек, потоки, … Эта 6-я часть, пожалуй, основная часть всей работы, которая непосредственно отвечает на вопрос: «Как на самом деле Async/Await работают (и компилируются) в C#»
Там, где мне придется цитировать содержание исходного текста в переводе (то есть более-менее дословно переводить), оно будет выделено подчеркнутым курсивом.
Возможно вам будет интересно сравнить эту мою работу с первоначальным переводом.
Не пора ли валить с gnu libc на что‑то другое?
Пользуюсь открытым ПО значительное время. Сижу на Линуксе.
Но в последнее время настолько часто сталкиваюсь с различными багами, что думается иногда, а как оно вообще в принципе работает?
Последний эпизод коснулся совсем уж системного кода - стандартной библиотеки libc от GNU. Системнее может быть только ядро.
История такая. Собрал Хромиум (не быстро). Когда наконец сборка завершилась с попутным решением проблем, думал: ну вот наконец щас запущу, посмотрю как работают интересующие меня вещи. И тут произошёл облом. Хром падал почти в самом начале запуска с ошибкой доступа к памяти. Довольно быстро удалось выяснить, что падение происходит из-за ошибки обращения по нулевому указателю. И происходит оно в динамическом загрузчике, то бишь в libdl, при загрузке библиотеки через dlopen. libdl.so является одной из компонент пакета стандартной библиотеки и понятно, самой системной библиотекой в ОС. Подробности всей ситуации я описал в вопросе на stackoverflow.
Вкратце: при загрузке библиотеки libXcursor.so подтягиваются непонятно откуда взявшиеся зависимости, не имеющие никакого отношения к упомянутой библиотеке. И зависимости эти не инициализированы корректно. Откуда и происходит обращение по нулевому указателю. Впоследствии выяснилось, что проблема начинается с несовпадающих версий библиотек libQt5Core, в результате чего libdl делает полный отбой с попыткой отката всех изменений.
Но, видимо, этот откат реализован из рук вон плохо, поскольку после него начинают происходить весьма странные вещи. И загрузка неинициализированной зависимости с нулевыми указателями лишь одна из них. Я ещё сделал пробник в виде простого приложения, которое пытается воспроизвести ситуацию. И в этом пробнике также происходил сбой, но уже при инициализации (вызов init или конструктор в их терминологии) либы libpthread.so (тоже очень системная) - потерян адрес глобального на процесс хранилища либ.
ИБ и ИТ, давайте жить дружно. Вот как это возможно
Однако есть способы сделать безопасность своим союзником на пути к качеству. В этой статье — о дихотомии разработки и безопасности. О том, что, вообще говоря, миры информационной безопасности и архитектуры ИТ-систем не столь далеки друг от друга, как может показаться. И что на самом деле практики безопасности пересекаются с практиками повышения качества кодовой базы, а ПО можно сделать безопасным без потери качества. Поскольку я сама довольно долго занималась системной разработкой, после чего ушла в безопасность и сейчас работаю в команде собственной микроядерной операционной системы «Лаборатории Касперского» KasperskyOS, то отлично знаю, что хотела бы услышать еще тогда, когда ИБ была для меня другой стороной :)
Baldur и Thor снова в игре: Путь к совершенному ПО
При написании высококачественного программного обеспечения не обойтись без этапа формальной верификации. Несмотря на то, что наша жизнь уже была в некоторой степени упрощена, благодаря таким помощникам доказательства как Coq и Isabelle/HOL, обучающим модель предсказывать один шаг доказательства за раз, оптимизация формальной верификации еще не была достигнута.
Новый метод автоматической генерации доказательств – модель Baldur. Данный метод основывается на использовании больших языковых моделей, возможности восстановления доказательства и исправления благодаря указанию ошибки и добавлению контекста.
Baldur превосходит все существующие подходы, он может самостоятельно полностью за раз доказывать 47.9% теорем, и даже этот результат – не предел.
В данной статье я познакомлю Вас со всей теоретической и практической подноготной данной модели, этапами реализации и оценки метода, чтобы стать чуточку ближе к созданию идеального ПО!
Приятного прочтения :)
Следует ли проверять указатель на NULL перед вызовом функции free?
Короткий ответ: нет. Тем не менее, раз про это вновь и вновь спрашивают на Reddit, Stack Overflow и других сайтах, пришло время подробно разобрать эту тему. Оказывается, есть много интересного, о чём можно порассуждать.
Async/Await в C#. Часть 5. Функция-перечисление и цикл через рекурсию, асинхронный вызов без Async/Await
В одной из предыдущих статей, посвященных анализу этого (все того же) Поста, я написал что «не возьмусь переписать всю эту хитрую логику, связанную с формированием последовательности вызовов сгенерированной функции на человеческом языке». Но подробно разбирая 5-ю главу того Поста у меня это вроде бы все-таки получилось сделать. Прошу вас оценить результаты этого труда.
Там где мне придется цитировать (назовем это так) содержание исходного текста в переводе, оно будет выделено подчеркнутым курсивом.В предыдущей статье я попробовал поэкспериментировать с особым форматированием, но это не всегда удобно читателю, на сколько я понимаю.
Ускоряем анализ данных в 170 000 раз с помощью Python
В статье «Ускоряем анализ данных в 180 000 раз с помощью Rust» показано, как неоптимизированный код на Python, после переписывания и оптимизации на Rust, ускоряется в 180 000 раз. Автор отмечает: «есть множество способов сделать код на Python быстрее, но смысл этого поста не в том, чтобы сравнить высокооптимизированный Python с высокооптимизированным Rust. Смысл в том, чтобы сравнить "стандартный-Jupyter-notebook" Python с высокооптимизированным Rust».
Возникает вопрос: какого ускорения мы могли бы достичь, если бы остановились на Python?
Под катом разработчик Сидни Рэдклифф* проходит путь профилирования и итеративного ускорения кода на Python, чтобы выяснить это.
*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.
Вклад авторов
-
fillpackart 976.6 -
Andrey2008 923.6 -
PsyHaSTe 619.4 -
AloneCoder 567.2 -
valemak 474.0 -
kesn 393.0 -
spiff 370.0 -
Tomcat 356.0 -
alizar 316.8 -
Delka 301.0