Привет, Хабр!

Если у вас в команде код-ревью — это унылое ожидание и пассивно-агрессивные комментарии уровня «не по канону», значит, что-то пошло не так. А если ревью не просто тормозит, но ещё и убивает мотивацию — то вы откладываете техдолг не только в коде, но и в культуре.

Типичная проблема новичков при изучении языка программирования — они тонут в море учебных материалов. Интернет предлагает тонны статей, курсов и книг по C++, но как выбрать действительно стоящие?

Меня зовут Владислав Столяров, я руководитель команды анализа безопасности продуктов в мультипродуктовой экосистеме МойОфис. Наши решения — Документы Настольные и Документы Онлайн — во многом работают благодаря C++, так что мне есть чем поделиться. В этой статье расскажу, что делать, если вы вдруг решили залететь в плюсы, но уже чувствуете, как накрывает экзистенциальный кризис от обилия информации.

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

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

В прошлой статье мы рассмотрели теоретическую основу такого понятия как полиморфизм. Теперь же перейдем к рассмотрению что там «под капотом».

После выхода первой статьи про svg-виджеты для tcl/tk прошло более года. За это время вышел не только tcl/tk версии 9.0, но и сам пэт-проект возмужал и продолжает взрослеть. Напомним, что проект svgwidgets, примеры и интерпретаторы tcl/tk с необходимыми пакетами для работы с svg-виджетами можно найти на github-е.
В проекте svgwidgets на github-е можно найти версию интерпретатора tclexecomp как для linux64 (папка tclexexcomp902), собранного из исходников tcl/tk-9.0.2, так и версию интерпретатора на базе tcl/tk-8.6 для платформ Linux64 и Win64 (папка tclexecomp200).
К ранее созданному на github-е подкаталогу examples/CryptoArmPKCS_Test, в котором выложен исходный код криптографической утилиты для работы с электронной подписью cryptoarmpkcs, который предназначен для запуска на платформе Linux64 в среде tcl/tk-9, добавлены аналогичные папки для запуска утилиты cryptoarmpkcs в среде tcl/tk-8.6 на платформах Linux64 (папка examples/CryptoArmPKCS_Test_Tk86) и Win64 (папка examples/CryptoArmPKCS_Test_Tk86_Win64). Для запуска этой утилиты ничего дополнительного устанавливать на свой компьютер не требуется. Достаточно выбрать соответствующий интерпретатор из папки tclexecomp200 или tclexexcomp902 и выполнить файл mainguipkcs_svg.tcl из соответствующей папки ~/examples/CryptoArmPKCS_Test, например:

C:>C:\Temp\tclexecomp64_v200_svg_Win64.exe c:\Temp\CryptoArmPKCS7_Test_Tk86_Win64\mainguipkcs_svg.tcl

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

Пользователь Reddit опубликовал в r/rustjerk сгенерированный ИИ пост под названием «Почему наш CTO запретил использовать Rust после одного переписывания кода». Очевидно, что этот рассказ выдуман, но у меня есть история похожая на него в том смысле, что успех проекта на Rust привёл к прекращению использования этого языка в компании.

Несколько лет назад я работал в стартапе-«единороге», во время пандемии развивавшемся невероятно быстро. Его основное приложение было написано на Ruby on Rails, а часть инструментария для работы с видео — на Node.js, но мы никак не применяли быстрые компилируемые языки наподобие Rust и Go. Через пару месяцев после моего прихода в компанию нам нужно было реализовать работающий в реальном времени сервис, который бы позволял нам получать информацию о том, кто из пользователей находится онлайн (то есть в профиле есть зелёная точка) и чем они занимаются (например: N пользователей смотрят презентацию X, M пользователей находятся в разделе маркетинга и так далее). Ничего особо сложного, но мы рассчитывали на изначальный рост до ста тысяч пользователей. Эта цель тоже не особо сложна, но большинство разработчиков согласилось, что Ruby — не лучший выбор для этого.

Привет, меня зовут Галя Ширанкова и я product unit lead в Авито. Я работала во многих больших компаниях — Ланит, Т1, МТС, ВК — и полученный опыт позволил мне увидеть, какие ошибки совершают лиды, особенно в начале карьеры. В статье рассказываю, с чем сталкиваются на своём пути начинающие тимлиды, и даю советы, как справляться с этими сложностями. Материал будет полезен тем, кто только стал лидом, планирует карьерный рост или управляет молодыми лидами — отвечает за их онбординг и растит сотрудников на новой позиции.

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

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

Моя схема:

✅ календарь с бывшей женой - только ключевое по сыну - переезды, врачи, собрания.
✅ календарь с моей женой: наша личная жизнь - свидания, поездки, дела. Без сына.
✅ семейный календарь (я + жена + сын): всё, что касается сына в мои недели.

Зачем так сложно? Границы. Приватность новой семьи, уважение к бывшей жене и прозрачность в делах сына.

Ручное управление тремя этими календарями неудобно. Я устал быть курьером между мирами новой семьи и бывшей жены. Автоматизация синхронизации календарей через Google Apps Script (GAS) стала спасением: события из календаря с бывшей автоматически попадают в семейный, но только если касаются сына в моё время.

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

Со временем число текстов в блоге YADRO неуклонно растет. А моя оперативная память редактора остается неизменной: пара-тройка последних месяцев плюс несколько ярких вспышек пораньше. Зато растет FOMO — тревога, что я мог бы найти новые возможности для развития блога, будь мой фокус шире. Поможет ли здесь искусственный интеллект? «Отличный кейс!» — ответила ChatGPT, и я начал первую версию проекта.

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

На прошлой неделе в Софии, столице Болгарии, закончилась работа над стандартом C++26, который помимо контрактов, std::execution и всего прочего теперь включает и рефлексию.

В этой статье будет продемонстрирован один из примеров её использования: преобразование строк в формате JSON в объекты C++ на этапе компиляции.

Как вы, наверно, знаете, из-за наличия в компьютере различных кэшей (L1, L2, L3...) и того, что операции с памятью выполняются с линиями кэша размером примерно 64 байт каждая, для обеспечения максимальной производительности мы должны писать программы, обеспечивающие локальность.

(Разумеется, диск здесь не показан)

Но насколько хорошо вы это осознаёте? Допустим, у нас есть массив чисел с плавающей запятой и массив индексов первого массива. Есть программа, складывающая числа из первого массива в порядке, определяемом вторым массивом. То есть в этом примере мы будем складывать ε + α + δ + ζ + β + γ в таком порядке:

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

1. Насколько большим должен быть массив, чтобы разница производительности вычисления в двух порядках стала заметной?

2. Сколько в среднем тратится на каждый элемент в порядке от первого до последнего?

3. Насколько медленнее произвольный порядок последовательного в случае массивов, умещающихся в RAM?

4. Насколько медленнее произвольный порядок последовательного в случае массивов, не умещающихся в RAM?

5. Достаточно ли стандартного тасования Фишера-Йейтса для массивов перемешанных индексов для получения произвольного порядка?

6. Насколько медленнее порядок от первого до последнего в случае массивов, не умещающихся в RAM, при использовании файлов с отображением в память?

7. Максимально ли быстры файлы с отображением в память?

Если вы уже знаете ответы на эти вопросы, то это замечательно! Если же нет, то делайте ваши предположения и проверьте их, прочитав пост.

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

1. Когда сложившаяся архитектура подлежит масштабным изменениям.

2. Что не менее важно, когда лучше оставить, как есть.

3. Ключевые признаки проблем в архитектуре.

4. Основные способы исправления таких проблем.

Но для начала мы вспомним, что было в предыдущих сериях. В первой части мы прошлись по теории и выяснили:

1. Что техническая реализация заметно влияет на успехи бизнеса, хоть и не очень критично;

2. Что из всех аспектов технической реализации наибольший вклад в успех вносит именно архитектура;

3. Что самое важное свойство архитектуры — максимальная независимость команд друг от друга;

4. Что это свойство вытекает напрямую из двух фундаментальных характеристик программного обеспечения: coupling и cohesion, где coupling — характеристика связи двух точек системы/кодовой базы; а cohesion — характеристика того, насколько плотно упакованы такие связи в компоненты.

Во второй части мы уже перешли к практике построения архитектуры с нуля. Мы узнали:

1. Что попытки угадать с архитектурой до старта проекта обычно проваливаются.

2. Что маленькие команды работают буквально в разы эффективнее, чем большие.

3. Что лучший способ разделить софт между командами - делать это постепенно. Начать с одной команды и уже затем дробить систему по обнаруженным в процессе разработки границам.

Теперь перейдем к вопросу, что же делать, если «все уже украдено до нас».

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

Привет, Хабр!

В этой статье разбираем один из самых коварных способов убить базу — плохие JOIN'ы. Казалось бы, простое дело: связать пару таблиц — и вперёд. Но если в ON засунуть LOWER(email), забыть про индексы или перепутать LEFT JOIN с INNER — сервер мигом начнет дышать на ладан.