[books] Прочел книгу про Pixar под претенциозным названием...

..."PIXAR. Перезагрузка. Гениальная книга по антикризисному управлению" за авторством Лоуренса Леви.

Сразу скажу, что ничего гениального в ней нет. Ну вот вообще. Как и нет чего-то именно про антикризисный менеджмент. Так что пусть название не вводит вас в заблуждение.

Книгу написал бывший финансовый директор Pixar-а, который был приглашен Стивом Джобсом в Pixar в конце 1994-го года. И который проработал финансовым директором до 1999-го, после чего от оперативного управления финансами Pixar Лоуренс Леви ушел, но зато вошел в совет директоров компании. За это время Леви успел поучаствовать в очень знаковых событиях в жизни Pixar-а: выводе компании на IPO, пересмотре контракта с Disney после успеха первой части "Истории игрушек", продаже Pixar-а Disney-ю. Поэтому речь в книге идет о том, что связано с этими событиями. Собственно про управление и, тем более, про антикризисное управление лично я в книге ничего не нашел :)

Тем не менее, книга не самая плохая. Читается легко. Некоторые воспоминания и внутренние переживания автора, местами, мне казались неинтересными и я бы их из текста убрал. Но общей картины они не портят.

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

Во-первых, я почему-то после прочтения биографий Стива Джобса считал, что Джобс был основателем и главным двигателем Pixar-а. Оказалось, что это сильно не так. Pixar была подразделением компании Джорджа Лукаса, которое затем было выделено в отдельную структуру и продано Джобсу. Первоначально Pixar развивалась как компания по производству специфического компьютерного железа и софта для компьютерной графики. Компьютерная анимация была лишь побочным продуктом. Но из-за того, что железо так никому продать и не удалось, компания, в итоге, сконцентировалась именно на анимации. В общем, для меня стало открытием, что Pixar не было детищем Джобса, вроде Apple или NeXT-а. Более того, даже в 1995-м, когда компания напряженно готовила к выходу "Историю игрушек" и, одновременно, готовилась к IPO, отношение к Джобсу внутри компании было настороженным и даже негативным. Сам Джобс регулярно стал появляться в Pixar только в 1995-ом, до этого его там месяцами не видели.

Во-вторых, оказалось, что Pixar за все время своего существования до IPO 1995-го не была прибыльной (вроде как даже в составе Lucasfilm и Industrial Light & Magic это подразделение не было прибыльным). И в течении всего этого времени она жила за счет инвестиций. Сперва Джорджа Лукаса, затем Стива Джобса. Джобс вложил в компанию порядка $50 миллионов собственных средств. Получается, что 16 лет (ну пусть даже 9 лет с момента покупки Pixar-а Джобсом) убыточности перед тем, как стать мегауспешной компанией... Это внушать. Н - Настойчивость.

В-третьих, нам, технарям, крайне полезно узнавать про то, какой вклад в успех бизнеса вносят люди, не имеющие отношения к "основной деятельности". Вроде финансовых директоров. Вот просто полезно и все.

Ну и еще один момент был в книге, который сильно удивил. Когда Леви пришел в Pixar, он взял пару месяцев на то, чтобы познакомиться с компанией. Просто ходил, смотрел, изучал. Становился "тенью" того или иного сотрудника: т.е. ходил за сотрудником, слушал, что сотрудник говорит, смотрел, что делает. В общем, финансовый директор в течении двух месяцев совершал глубокое погружение в новую компанию, для того, чтобы детально разобраться с тем, с чем ему нужно иметь дело. И только после этого он начал предпринимать какие-то самостоятельные действия.

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

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

[prog.c++] RESTinio 0.4.3

У нас очередная приятная новость: релиз очередной версии RESTinio, на этот раз 0.4.3. Главное нововведение -- поддержка операции sendfile. Выполняется средствами системного вызова sendfile() на Linux/FreeBSD/macOS или TransmitFile на Windows. Плюс незадолго до этого у нас был еще один маленький релиз версии 0.4.2, в которой добавились новые перегрузки для restinio::run().

В общем, наша маленькая библиотека для встраивания HTTP/Websocket сервера в C++ приложения стала еще более функциональной.

Мы же собираемся приступать к разработке следующей версии. Свой список хотелок у нас есть. Но было бы интересно услышать и мнение потенциальных или актуальных пользователей: чего именно вам не хватает в RESTinio и/или что мешает вам начать использовать RESTinio?

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

[prog.c++] Async processing of incoming and outgoing HTTP-requests with RESTinio and libcurl

We started development of RESTinio because sometimes we had to implement REST-like interfaces for legacy systems with one common feature: long response times. We can make a request to a distant system and response can arrive after a dozen of seconds, sometimes after a several dozen of seconds. It is not appropriate to block a work thread that handles incoming HTTP-request for such a long time. That’s why we needed an embeddable C++ HTTP-server which supports async request processing. After experimenting with some existing solutions we decided to build our own solution with very simple goals: it should be user-friendly and very easy to use, but should provide reasonably good performance and be cross-platform. So RESTinio was born.

Time shows that a situation when someone needs to deal with long-responding distant hosts is not unique. Recently we received an interesting question about integration of async processing of incoming HTTP-requests via RESTinio with async processing of outgoing HTTP-requests via libcurl.

Answering this question we prepared a demo that includes some simple C++ applications showing how async processing of incoming and outgoing HTTP-request can be done. Source code for the demo can be found here. This post briefly describes the major aspects of using RESTinio and curl_multi interface from libcurl.

[prog.memories] Байка про студентку и матрицу 100x100

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

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

Дал он как-то студентке математического факультета задание: написать программу, в которой создается матрица 100x100, пользователь с клавиатуры вводит значения для этой матрицы построчно, затем (тут я деталей уже не помню, ну да не суть) распечатываются элементы главной диагонали.

Время действия — самое начало 90-х, когда персональные компьютеры в отдельных ВУЗ-ах только-только начинали появляться. Поэтому для студентов-математиков программирование было непрофильным предметом, но поскольку это веяние времени, то хоть как-то, да изучать программирование приходилось.

Так вот что было: одно занятие в дисплейном классе эта студентка сидит, что-то делает. Второе занятие, третье... И все более и более сосредоточено, ни на что не отвлекаясь, ни с кем не общаясь. Приходит время сдавать работу, а она говорит «Я не успела». Преподаватель спрашивает: «Да как же ты не успела, тут же задание простое, а ты каждое занятие за компьютером, от звонка до звонка?»

Ответ был шедевральным: «Я не успеваю вводить данные». А сама при этом чуть не плачет... Мол, каждый раз стараюсь, стараюсь, у меня уже все данные подготовлены, я уже научилась их вводить практически не глядя, а времени на ввода данных все равно не хватает.

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

Когда преподаватель пришел в себя и обрел дар речи, он спросил, а почему же она для отладки не могла сделать матрицу поменьше, например, 5x5, на что студентка не менее шедеврально ответила: «Но ведь в условии было сказано, что матрица 100x100, а с матрицей 5x5 — это уже другая задача».

ИМХО, пример ТС-а с суммой чисел от 1 до 100 ничем не отличается от этой истории с матрицей 100x100.

Собственно, достоверность этой истории я под сомнение никогда не ставил. Поскольку на первом курсе дабы получить доступ к компьютерам (а тогда это было вовсе не просто) мы практиковали "дружескую" помощь студентам-математикам. Мол, мы им быстренько делаем их лабораторную, они затем уступают нам компьютер. А т.к. у нас на математическом факультете на чистой математике из 75 человек 72 были девушки, то помогали мы, в основном, девушкам. И уж какие там были экземпляры с абсолютным непониманием программирования вообще и алгоритмов в частности, я насмотрелся вдоволь.

О чем эта байка говорит и почему она до сих пор мне нравится? Говорит она, по моему мнению, о том, что писать программы, как писать картины или писать стихи дано не всем. Конечно, ценой целенаправленных упражнений и большого труда можно достичь какого-то уровня. Но если в мозгах просто отсутствуют какие-то извилины, отвечающие за автоматическое выделение каких-то абстракций и последовательностей действий, то это будет разве что "какой-то уровень".

И я здесь говорю без какого-либо шовинизма или попыток изобразить некоторую "илитарность". Вот мне, например, не дано писать музыку, сочинять стихи, ставить рекорды в тяжелой атлетике... Да что-там, просто скрупулезно выполнять одну и ту же работу день ото дня и то не могу. Вот нет у меня соответствующих способностей. И это нормально, так же нормально, как и то, что у кого-то нет понимания, что одно и то же решение подойдет как для матрицы 100x100, так и для матрицы 5x5.

---

PS. Ну а чтобы закончить не менее пафосной ноте расскажу историю, которая произошла лично со мной. И за правдивость которой я отвечаю лично. Итак, тот же университет, только несколькими годами ранее, наверное 1992-й или 1993-й. Перед началом занятия по физкультуре мы сидим на скамеечке в спортзале, ждем пока уйдет предыдущая секция. Тут ко мне подходит один парень с другого факультета с тетрадочкой в руке и спрашивает: "Ты на программиста же учишься, язык C знаешь?" Я говорю, что знаю. Тогда он показывает мне строчку в программе, написанной от руки в тетрадке и говорит: "Я вот не понимаю, когда я буфер в файл записываю, туда запятые попадают?" Я долго не врубаюсь, потом начинаю мямлить что-то вроде "Ну, если в буфере запятые есть, то попадают". Вижу, что этот ответ его приводит в полное замешательство и начинаю выяснять, про какие запятые идет речь. Он еще раз тычет в строчку кода, а там что-то вроде:

fwrite(buf, 1, len, f);

И он мне говорит: "Вот я понимаю, что buf -- это буфер, 1 -- это размер одного символа, len -- это количество символов в буфере, а f -- это файл в который нужно все записать. Это я все понимаю. А вот запятые между buf, 1 и len, они-то в файл записываются или нет?"

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

[life.cinema] Очередной кинообзор (2018/02)

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

Девушка в тумане (La ragazza nella nebbia, 2017). Добротно. Может не шедевр, но посмотрел с удовольствием.

Три билборда на границе Эббинга, Миссури (Three Billboards Outside Ebbing, Missouri, 2017). Ну да, очень качественно. Ну да, посмотреть интересно. Но откуда столько восторгов по поводу этого фильма не сильно понятно.

Парадокс Кловерфилда (The Cloverfield Paradox, 2018). Тут моя обычная история с фильмами от Netflix -- размах на рубль, удар на копейку. Завязка и ожидания большие, развитие и финал так себе. Хотя как фрагмент мозаики из "Монстро" и "Кловерфилд, 10" вполне можно посмотреть.

Обитель теней (Marrowbone, 2017). Пытались сделать достойный фильм. Посмотреть вполне можно. Для меня основные сюжетные ходы сюрпризом не стали, т.к. все это, путь и кусками, но уже встречались в других фильмах. Так что меня не зацепило.

Дикий (Braven, 2018). Редкая муть. На финале так вообще заржал в голос от маразма происходящего.

[prog.c++] Серия статей на Хабре про интеграцию RESTinio и libcurl

Мы начинаем публиковать серию статей про то, как можно подружить асинхронный от природы RESTinio и асинхронный вариант libcurl под названием curl_multi. Общее название серии: "Асинхронные HTTP-запросы на C++: входящие через RESTinio, исходящие через libcurl." Серия будет состоять из следующих частей:

• Часть 1. delay_server.
• Часть 2. bridge_server_1.
• Часть 3. bridge_server_2.

Кому не нравится Хабр, тот может оставить свое мнение здесь (но прошу учитывать disclaimer) из первой части статьи.

Репозитории с исходниками из статей:

• исходники с комментариями на русском;
• исходники с комментариями на английском. Тут немного другая реализация bridge_server_2, сделанная на базе комментариев с Хабра.

[prog.thoughts] Запись "_ = some()" в С++ -- это извращение или нет?

В связи с тем, что в C++ завезли атрибут [[nodiscard]], да и в чистом C благодаря расширениям компиляторов ряд функций помечается соответствующим образом, становится актуальным явное обозначение в коде тех мест, где возвращаемое значение функции намеренно игнорируется.

Только вот использовать для этого запись вида:

(void)::pipe(pipefd_); (void)::fcntl(write_pipefd(), F_SETFL, O_DIRECT | O_NONBLOCK); (void)::fcntl(read_pipefd(), F_SETFL, O_DIRECT | O_NONBLOCK);

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

_ = ::pipe(pipefd_); _ = ::fcntl(write_pipefd(), F_SETFL, O_DIRECT | O_NONBLOCK); _ = ::fcntl(read_pipefd(), F_SETFL, O_DIRECT | O_NONBLOCK);

Что достигается очень простой вспомогательной конструкцией:

// Вспомогательная штука, чтобы подавить предупреждения об игнорировании // возвращаемого значения. namespace {    struct just_ignore_t {       template<typename T> void operator=(T) {}    } _; }

Правда, боюсь, если это и найдет свое применение в C++, то очень ограниченное. Но смотрится прикольно :)