Программирование *

Я программист. Меня всё время отвлекают, и я хочу об этом поговорить.

Вы когда-нибудь задумывались, что сильнее всего подрывает эффективность работы? Много чего. Но мы часто недооцениваем один фактор, который выделяется на фоне остальных.

Каждое короткое сообщение, которое вы отправляете коллеге в Slack, отнимает у него 23 минуты продуктивной работы. И это далеко не всё.

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

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

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

И вот пару лет назад я встретил еще одну интересную задачу по написанию регулярного выражения для определения делится ли искомое число на 7. Само число при этом написано в двоичном виде. Признаки делимости на 7 существуют и для двоичной и для десятичной записи, но как правило они требуют производить операции умножения, сложения и рекурсивно проверять делимость уже получившегося в итоге этих действий меньшего числа, что не очень подходит для написания регулярного выражения. Я предполагал, что каким то образом могут помочь сложные операторы: условное сопоставление (позиционные проверки), обратные ссылки итд, но не разобрался как их использовать конкретно для данной задачи. Гораздо больше я думал в сторону более простой регулярки с использованием только оператора ИЛИ, квантификаторов и скобок. Остановился на построении графа остатков от деления следуя, по которому можно получить остаток заданного числа, но уперся в то, что всякое выражение с использованием скобок, но без ссылок - это в итоге дерево и поэтому произвольный граф туда не ложится. Это как пытаться хранить произвольный граф в JSON или XML - можно, но нужно будет вводить идентификаторы узлов и поля ссылок, а в то же время хранение простого дерева этого не потребует.

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

Введение

Уже скоро, 18 марта, выйдет новая версия Java. Поэтому предлагаю посмотреть, какие в ней будут новшества, включая финализацию давно ожидаемых Stream Gatherers!

Эта стать была написана в качестве комментария к одной статье, какой уже не помню, но написанную в духе мы все умрём ИИ заменит всех программистов. Комментарий оказался весьма жирным и я решил оформить его в качестве статьи. Но когда я закончил правки, мне в голову пришла гениальная мысль — да какой в этом смысл? И текст телепортировался в мусоруку место для очень нужных вещей.

Время шло. Статьи наподобие вышеуказанной попадались всё чаще. Сегодня вышла очередная CEO Anthropic: через полгода 90% кода будет писать ИИ. Через год — 100%

А так как в текущий момент я не пишу код рефлексирую о бессмысленности своего существования, я вспомнил про свою кладовку…

Честно сказать — сам пользуюсь постоянно всякими ИИ. Но использую их в качестве продвинутого поиска. Например, я точно знаю, что так можно сделать — но искать как синтаксически верно это реализовать лень. В этом ИИ мне помогает.

Или я хочу какую‑нибудь зубодробительную конструкцию — но не знаю можно ли сделать так в текущем языке или нет. ИИ и тут мне помогает.

Но вот писать код за меня…. Тут как говорится «наши полномочии всё…»

Почему так думаю и попытался изложить в текстовом виде.

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

Изначально Яндекс Доставка была тарифом внутри Яндекс Такси. Но спрос был таким большим, что довольно быстро стало ясно: надо развивать доставку как отдельный продукт, покрывающий множество пользовательских сценариев. И с 2019 года Яндекс Доставка стала самостоятельным сервисом.

Доставка день в день — это не только сценарий «сходи за меня в магазин», но и возможность передать посылку с помощью сервиса. Эти сценарии объединяет то, что они происходят в рамках одного города. Про этот вид доставки мы и поговорим: я расскажу, что уже изобретено для этого сценария, а чего нам не хватало и какие задачи предстояло решить с помощью алгоритмов доставки.

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

Равенства следующие:

Некоторые, возможно, ещё помнят, что в углублённой школьной (или вузовской) программе встречалось равенство . Собственно, оно тут и применяется. Кстати, согласно Википедии, это равенство называется тождеством Никомаха, древнегреческого математика (около 60-120 гг. н.э.).

На основе этих равенств можно сформулировать задачу:

Сколько существует способов расположить 1 квадратик со стороной 1, 2 квадратика со стороной 2, 3 квадратика со стороной 3, … , 8 квадратиков со стороной 8, 9 квадратиков со стороной 9 в квадрате со стороной 45, чтобы они не пересекались?

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

Сегодня рассмотрим, почему free() не всегда освобождает память, как работает malloc(), когда glibc действительно возвращает память в ОС, и как избежать фрагментации хипа. А так же напишем кастомный аллокатор.

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

В чем может быть проблема? Ответ на этот вопрос у меня есть

Для привлечения внимания расскажу историю. Уже много лет живу далеко за пределами нашей всеми любимой родины. И на днях, понадобилось мне войти в старую почту gmail... Логин и пароль надежно сохранены. Однако Google не торопится впускать нас в собственную почту.
— Нам кажется что это не вы, подтвердите что это вы. Введите номер телефона когда-то использовавшийся при регистрации.
Что ж, и это можно. Ввожу номер.
— Увы, мы не можем отправить СМС на этот номер. Хотите завести другой аккаунт?

Мне недавно встретился код вывода количества FPS на экран, написанный начинающим программистом, и в этом коде был базовый класс, класс-потомок, виртуальные функции, конструктор с множеством параметров, variant. Код позволял выводить любое количество счетчиков FPS на экран разными шрифтами, но все, что было на самом деле нужно, это простая функция на 3 строки, считающая количество FPS и выводящая его на экран.

Меня давно интересовал вопрос, насколько сложно написать собственный загрузчик операционной системы. Я не говорю о простой программе, выводящей «Hello, World!», а о полноценном загрузчике, который передаёт управление от встроенного программного обеспечения компьютера ядру операционной системы. Современные загрузчики представляют собой сложные программы, способные загружать множество операционных систем различными способами, учитывая массу нюансов, связанных с программным и аппаратным обеспечением. Читая их исходный код, легко утонуть в деталях и потерять понимание сути и реализации.

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

Сейчас среди Java/Kotlin команд распространено применение Чистой (ака Гексагональной, ака Луковой — Clean, Hexagonal, Onion) архитектуры для разработки бакэндов прикладных приложений (да и Android‑приложений тоже). Однако это семейство архитектур в контексте прикладной разработки зачастую не даёт никаких преимуществ, а только привносит лишние церемонии и тем самым замедляет её.

В этом посте я подробно разбираю, почему, на мой взгляд Чистая архитектура не является лучшим выбором по умолчанию для прикладных приложений, и кратко рассказываю об альтернативной архитектуре (спойлер: Промышленная функциональная архитектура), которую использую в качестве дефолтной последние 3 года и пока что доволен.

Но перед тем как перейти к Чистой архитектуре, сначала надо разобрать принцип инверсии зависимостей (Dependency Inversion Principle, DIP).

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

Ниже небольшой обзор и скриншоты в работе под FreeBSD, что наверное создателей немного удивит. Но я предупреждал ;-)

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

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

Допустим, вы генерируете карту для стратегической игры, но не хотите, чтобы границы карты были заполнены непроходимой пустотой (как в олдскульных RTS). Разве не будет здорово, если граница будет заполнена водой, как на этой карте из одного моего заброшенного проекта?