[books.business] Отличная книга "Дилемма инноватора: Как из-за новых технологий погибают сильные компании"

За несколько дней практически залпом проглотил отличнейшую книгу Клейтона Кристенсена "Дилемма инноватора: Как из-за новых технологий погибают сильные компании". Как раз тот случай, когда после прочтения жалеешь, что не прочитал ее лет на 10 раньше. Ну или хотя бы на 5 лет раньше.

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

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

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

В общем, книга из категории must read. По крайней мере для тех, кто хоть как-то интересуется продуктовой разработкой, а так же управлением продуктовым бизнесом. Еще лучше, если до прочтения "Дилеммы инноватора" будет изучена хрестоматия Генри Минцберга "Структура в кулаке". Тогда будут лучше понятны рассуждения о том, почему корпоративная культура успешных компаний-лидеров препятствует освоению новых технологий. И почему маленькие дочерние предприятия могут сильно помочь своим родительским компаниям. (Компании-лидеры -- это механистические бюрократии, они ориентированы на оптимизацию расходов и снижение издержек при эксплуатации уже выверенной и работающей бизнес-модели. Тогда как маленькие дочерние компании -- это адхократии, которые быстро находят новые бизнес-модели.)

Пожалуй, у книги есть всего два небольших недостатка. Первый -- это ее объем. Как по мне, можно было бы сократить раза в три, слишком уж много повторений одного и того же, но под чуть-чуть разными углами. Впрочем, это характерно для большинства западных книг, в которых одна и так же мысль повторяется снова и снова. Уж не знаю, для повышения гонорара автора книги или для того, чтобы до определенной категории читателей все-таки материал дошел. Второй недостаток -- это то, что книга базируется на достаточно старых примерах середины и конца XX-века. Она бы сильно выиграла, если бы в новые издания вошли более современные примеры. Например, крах Kodak-а после появления и развития цифровой фотографии. Но это уже чистой воды придирки.

PS. Если найду время, постараюсь написать, как можно ценить появление новых языков программирования и их влияние на индустрию с точки зрения идей из "Дилеммы инноватора". Как по мне, Java и Go полностью вписываются в теорию "подрывных" технологий. Хотя в софтостроении есть своя специфика, которую нельзя не учитывать.

[prog.c++] doctest vs Catch2: влияние на скорость компиляции

Для so_5_extra мы использовали Catch/Catch2 в качестве фреймворка для unit-тестирования. Catch2, конечно же, отличная штука. Но вот время компиляции самих unit-тестов -- это ахилесова пята. Особенно в таком проекте, как so_5_extra, который сам весь на шаблонах, да еще и часть компонентов оттуда базируются на Asio, которая вся из шаблонов.

В общем, с ростом количества тестов для so_5_extra, увеличение времени компиляции меня задолбало настолько, что в версии 1.1 попробовал использовать конкурирующий инструмент, doctest. Гораздо менее раскрученный и известный. Но зато более шустрый.

Вот результаты сегодняшних замеров. Полная сборка so_5_extra-1.1 под Windows с VC++15.6 на реальном железе:

• Catch2: 37m 55s;
• doctest: 26m 30s.

Но еще круче разница выглядит под виртуалкой, которую я кручу на этой же Windows-машине. ArchLinux с GCC 7.3:

• Catch2: 1h 21m 17s;
• doctest: 36m 25s.

В общем, явно с Catch2 в проекте so_5_extra мы попрощаемся. Может быть Catch2 обладает большей функциональностью, но нам и doctest-а более чем хватает. А времени doctest экономит сильно больше.

PS. В so_5_extra-1.1 будет сделан переход на asio-1.12.0. Плюс, наверное, будет добавлен еще один диспетчер (autoscaling_thread_pool, автоматически увеличивает и уменьшает количество нитей в пуле в зависимости от загрузки). Если кто-то хочет видеть что-то еще, то дайте знать.

[prog] А кому-нибудь приходится иметь дело с HTTP/2?

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

В частности интересует такой аспект: применяется ли HTTP/2 для реализации взаимодействия микросервисов?

Или же пока еще повсеместно HTTP 1.0/1.1 применяются и до широкого распространения HTTP/2 пока еще далеко?

[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, они-то в файл записываются или нет?"

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