Терминал сбора данных Zebra WT-40 со сканером-кольцом. Нужен для того, чтобы была возможность быстро сканировать товар, при этом укладывать физически короба на паллету (свободные руки).

На протяжении нескольких лет мы очень быстро открывали магазины и росли. Закончилось это тем, что сейчас наши склады принимают и отправляют порядка 20 тысяч паллет в день. Естественно, сегодня у нас уже больше складов: два больших в Москве — 100 и 140 тысяч квадратных метров, но есть и небольшие в других городах.

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

Именно поэтому два главных множителя эффективности — это продуманный алгоритм действий (процесс) и настроенные ИТ-системы. Желательно «как часы», но «работающие чуть менее, чем идеально» тоже вполне подойдёт. Всё же мы в реальном мире.

История началась шесть лет назад, когда мы присмотрелись к тому, как именно поставщики разгружают фуры у нас на складе. Это было настолько нелогично, но привычно, что сотрудники даже не замечали неоптимальности процесса. Более того, в тот момент у нас не было промышленной системы управления складом, и в основном логистические операции мы доверяли 3PL-операторам, которые использовали свой софт и опыт в построении процессов.

"Кто ни разу не ошибался в индексировании цикла, пусть первый бросит в деструкторе исключение."

— Древняя мудрость

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

В конце концов, это просто некрасиво.

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

Данная работа ставит своей целью пролить свет на отнюдь не новую, но пока что не слишком распространённую идею, которая вполне способна произвести очередной прорыв в области написания программ на языке C++.

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

В идеале хотелось бы определить структуру С++

struct Person {
 std::string name;
 int age;
 bool student;
} person;

передать экземпляр person в метод отображения вместе с данными json_data

map_json_to_struct(person, json_data)

после чего просто пользоваться заполненной структурой

std::cout << person.name << " : " << person.age;

StructMapping пытается решить эту задачу.

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

Сам я научился ездить за 2,5 часа и после этого поехал с работы домой через весь город — полтора десятка километров. С того момента я обучил ещё 17 человек — и лишь немногим из них потребовалось больше полутора часов, чтобы поехать самостоятельно.

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

Приведу несколько задач, в основном из физики. Мне они нравятся. Надеюсь они понравятся и Вам.

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

Для большинства задач я не привожу решения. Самое полезное – найти самому решение. Конечно, задачи не для профессионального физика, исключая задачу о ленте и о пушке.

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

Часть 1: Web / Android

Примечание: данная статья является переводом на русский язык оригинальной статьи «DevOps tools are not only for DevOps. Building test automation infrastructure from scratch». Однако все иллюстрации, ссылки, цитаты и термины сохранены на языке оригинала, чтобы избежать искажения смысла при переводе на русский язык. Желаю вам приятного изучения!

Примечание переводчика: в текущий момент я подготавливаю материалы для обещанной статьи по монадам. К сожалению, это занимает довольно много времени, не говоря о том, что я всё же должен заниматься основной работой и уделять время семье, но процесс идёт. А пока представляю вам перевод небольшой свежей заметки от замечательного товарища Mark Seemann'а, которая мне показалась любопытной.

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

Церемонность

Люди, которые предпочитают динамически типизированные языки статически типизированным, часто подчеркивают тот факт, что отсутствие церемонности делает их продуктивнее. Это звучит логично, однако, это ложная дихотомия.

Церемония — это то, что вы делаете до того, как начнете делать то, что вы действительно собирались сделать.

Venkat Subramaniam

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

Это привело меня к мысли о том, что существует злосчастная Зона Церемонности:

Конечно же, эта диаграмма всего лишь упрощение, но я надеюсь, что она демонстрирует суть. C++, Java и C♯ — языки, которые требуют церемонности. Справа от них находятся языки, которые мы могли бы назвать транс-церемониальными, включая F♯ и Haskell.

В C++20 вот-вот появится возможность работать с корутинами из коробки. Нам в Яндекс.Такси эта тема близка и интересна (под собственные нужды мы разрабатываем асинхронный фреймворк). Поэтому сегодня мы на реальном примере покажем читателям Хабра, как можно работать с C++ stackless корутинами.

В качестве примера возьмём что-то простое: без работы с асинхронными сетевыми интерфейсами, асинхронными таймерами, состоящее из одной функции. Например, попробуем осознать и переписать вот такую «лапшу» из колбеков:

void FuncToDealWith() {
    InCurrentThread();

    writerQueue.PushTask([=]() {
        InWriterThread1();

        const auto finally = [=]() {
            InWriterThread2();
            ShutdownAll();
        };

        if (NeedNetwork()) {
            networkQueue.PushTask([=](){
                auto v = InNetworkThread();
                if (v) {
                    UIQueue.PushTask([=](){
                        InUIThread();
                        writerQueue.PushTask(finally);
                    });
                } else {
                    writerQueue.PushTask(finally);
                }
            });
        } else {
            finally();
        }
    });
}