С историей версий мы начали работать относительно недавно, раньше у нас в аппсторе всегда было написано Bugs and improvement fixes, теперь появился человек, который тестирует различные формулировки в истории и их влияние на основные метрики.
К сожалению, есть несколько проблем, которые усложняют для нас поддержку истории релизов.
* Мы релизим новые версии каждую неделю, и зачастую окончательное понимание, что именно едет в релиз, возникает только в день релиза. А нам нужно ещё перевести историю изменений на несколько десятков языков, что сильно бы замедлило релиз.
* Часть изменений не появляются сразу для всех пользователей. Как Данил указал в статье, часть функций управляется с сервера либо A/B тестируется, соответственно мы не можем объявлять о том, что появилась новая функция, пока не включим ее для всех пользователей. Это довольно сложно контролировать и синхронизировать (нужно чтобы информация о завершенных A/B тестах и включенных на определенную страну фичах появлялась в релизе, который едет в момент раскатки теста или фичи), плюс это не совсем честно: функциональность может зачастую появиться в приложении даже без обновления, если например вы были в контрольной группе теста и вдруг тест раскатили на 100%.
В целом я согласен, что видеть в истории изменений только Fixed bugs and improved performance довольно грустно, но пока мы не можем себе позволить выделить достаточно ресурсов для решения всех перечисленных проблем.
С одной стороны, довольно понятное опасение, такое, действительно, бывает, что в приложении появился баг или пропала понравившаяся фича. С другой стороны, всегда приходится искать компромисс между поддержкой старого кода и написанием нового. Как мне кажется, мы нашли довольно разумный компромисс: обязательное обновление включается для приложений, выпущенных примерно полгода назад, и только в том случае, если телефон поддерживает это обновление (иногда без апгрейда версии iOS или Android нельзя поставить новую версию приложения, а далеко не все производители телефонов обновляют прошивку до последних версий OS). Для таких пользователей мы делаем исключение и не показываем блокер.
В любом случае, ситуация в мобильных приложениях с этой точки зрения существенно лучше, чем, скажем, на веб сайтах: там вообще нет выбора обновляться или нет, вы всегда пользуетесь последней версией, и всегда может пропасть полюбившаяся фича или появиться баг.
Вопрос, который задает автор — «зачем нужен 50/50 гендерный баланс» — сразу подталкивает к определенным выводам («и правда, зачем, все и так неплохо»). Но что если задать другой вопрос: «почему баланс не 50/50, девочек и мальчиков же одинаково»?
Давайте на секунду предположим, что на самом деле и мальчики, и девочки в IT могут быть одинаково успешны, что нет никакого «технического склада ума», присущего мальчикам, нет биологически обусловленных различий. Предположим мы это для того, чтобы сразу исключить вещи, которые мы в таком случае изменить не можем.
А если в среднем по популяции талантливыми разработчицами могут стать столько же девочек, сколько мальчиков — талантливыми разработчиками, то почему баланс не 50/50?
Раз уж мы в качестве мысленного эксперимента исключили влияние биологических факторов, то давайте попробуем подумать, какие ещё могут быть факторы. Представим себе стандартную воронку, где вход в воронку — это рождение девочки, выход — становление ее как профессиональной разработчицы ПО (или тестировщицы, или представительницы любой другой IT-профессии).
Воронка называется так, потому что она представляет собой перевернутый конус (или пирамиду), где на вершине — 100% родившихся девочек, а внизу — те доли процента, которые дошли до конца воронки.
Соответственно на каждом «шаге» воронки какое-то количество девочек отсеивается.
В садике — девочки тусуются с девочками, играют в куклы вместо машинок, у них не формируется представление о механизмах и принципах их работы. Они не играют в войнушку, где вырабатываются начальные навыки лидерства и умения достичь своей цели, зато играют в дочки-матери или в больничку, где вырабатывается эмпатия и умение понимать других людей, их эмоции и так далее. Их интересы смещаются от техники к общению.
Дома — девочки не учатся с папой мастерить инструментами, или строить, или разбираться с роботами и компьютерами. Вместо этого мамы учат их готовить, шить, мастерить украшения. Это не хорошо и не плохо, это данность, потому что десятки поколений так делали, и зачем что-то менять, не так ли? И вот мы видим, что формируется некоторый стереотип того, что девочка должна уметь/хотеть/любить, а что нет.
Дальше школа с их уроками труда, дальше выбор куда поступать с извечным «ну куда ты на физфак пойдешь, там одни парни», и так далее. Человек в своей жизни принимает миллионы мелких решений, и часть из них принимаются потому, что «так принято, так все делают».
И вот мы видим, что все больше и больше девочек выпадают из этой воронки на каждом этапе. У них нет ролевых моделей, к которым им хотелось бы стремиться, у них нет поддержки родителей, друзей, учителей. Их интересы формируются социумом, и это система с положительной обратной связью. «Мне не интересны компьютеры, мне интересна литература, я буду общаться с теми, к кого такие же интересы, и тем самым буду укреплять стереотип». Даже самые целеустремленные и нацеленные на IT девушки рано или поздно, зайдя на хабр, столкнутся с такой вот статьей, где человек прямо говорит «зачем мне как работодателю нанимать девушку» и сделают выбор не в пользу IT, выпадая из воронки.
Все эти неуклюжие «гендерные балансы» и так далее — на самом деле ни что иное, как попытка переломить ситуацию. Невозможно разом взять и выровнять воронку, которая формировалась поколениями. Но компании, у которых есть ресурсы и определенная доля социальной ответственности, пытаются сделать то, что в их силах для того, чтобы ситуацию улучшить. Конкретно этот спущенный сверху баланс 50/50 — это решение безусловно спорное, так как оно отталкивается от равенства результата, а не равенства возможности («equal outcome vs equal opportunities»), но даже такое решение имеет положительные черты: те девушки, которые ещё не приняли решения, не выпали из воронки, будут видеть больше ролевых моделей для себя, у них появится мотивация продолжать. Если они будут наблюдать примеры того, что женщины могут быть успешными в IT-индустрии, причем не единичные персоны, а массово, у них будет больше шансов остаться в воронке.
Конечно же, решать задачу нужно по всем фронтам. В этом смысле меня очень вдохновляет пример Даши Абрамовой, создательницы Кодабры, которая учит программированию детей дошкольного и школьного возраста. Она работает на самом верху воронки, и это мне кажется более эффективным решением. Но и помимо нее есть множество программ, работающих с детьми, и с девочками в частности, в том числе спонсируемых или организованных крупными компаниями.
Ну а что если наш мысленный эксперимент не имеет отношения к делу, и причина дисбаланса все же в гендерных различиях?
Это возможно. Есть исследования разной степени достоверности, как подтверждающие, так и опровергающие такую точку зрения. Но на этот счет у меня 2 мысли:
1) если это так, то мы сможем это понять только после того, как устраним социальные факторы, что и пытаются сделать те, кто стремится к 50/50 балансу
2) и даже если гендерно-обусловленные различия есть, могут ли они обуславливать настолько существенный дисбаланс (как указал автор статьи, «по индустрии этот баланс 90/10»)? Каков бы стал баланс, если убрать социальные факторы? Может он установился бы на уровне 60/40, или 55/45, кто знает?
Никто, к сожалению, не упомянул книгу нынешнего VP of Engineering в Slack Майкла Лоппа (Michael Lopp) под названием «Managing Humans», хотя она, на мой взгляд, сильно полезнее, чем та же «Как пасти котов». В ней нет советов за все хорошее и против всего плохого типа «обязательно найдите свой подход к каждому подчиненному», зато есть множество историй из реальной жизни о том, что происходит в офисах ежедневно и как с этим справляться. Книга написана с юмором, читается на одном дыхании, очень рекомендую.
Плюсую совет про «мифический человеко-месяц», хотя она и более занудная и во многом довольно устаревшая, но все же очень полезная.
Добавлю ещё от себя Peopleware: Productive Projects and Teams, автор Tom DeMarco. Это интересная и легкая книжка про то, как строить команды и управлять ими. Немного устаревшая с точки зрения современных реалий, но не настолько, как мифический человек-месяц. Рассматривает вопросы эффективности работников в разных условиях (от собственного кабинета до опен спейса), эффективность переработок, мотивацию, сопоставляет цели компании и цели работника. Рассказывает как сломать хорошую команду (рецепта как построить у них нет — их мысль в том, что не надо ломать, и есть шанс что сама построится).
Ну и вообще у Тома ДеМарко хорошие книжки, тот же Slack например.
Ну такоооое, парни… По сути, вы прикрыли кучу мусора модным ковриком и написали про это статью.
Какие проблемы решены?
фрондендеры имеют API, над которым у них есть контроль
появилась в каком-то смысле «схема» API, по которой можно валидировать запросы и ответы
swagger-файл можно в некотором смысле считать документацией
утверждается, что ушла зависимость от бэкенда, когда там что-то меняется. В это не верю, простите: если бэкенд сменит формат ответа, все равно ваш фасад на ноде переписывать под этот новый формат.
появилась возможность мокать серверный ответ, собирать ответ несколько API в один ответ фасада, агрегировать данные, играться с форматом ответа сервера
Какие проблемы остались нерешенными:
бэкенд все ещё творит в апи все, что хочет, и не задумывается над тем, в каком виде они отдают данные и в каком виде эти данные вообще нужны клиенту
процесс дебага усложнился — вместо того, чтобы посмотреть в серверном коде, почему отдаются неверные данные, теперь сначала нужно заглянуть в фасад — не там ли проблема?
появилась куча ручной работы — каждый новый серверный API необходимо дублировать
обработка исключений теперь тоже дублируется: отказать может как сервер, так и фасад
огромный недокументированный серверный API превратился в два огромных недокументированных API (добавился API фасада)
появился дополнительный overhead на обработку данных в фасаде, а значит дополнительные сервера, процессорное время etc.
добавление кеширующего слоя в фасаде, который не контролируется сервером, может привести к неожиданным багам, связанным с использованием устаревших данных
Что ещё забыл?
Я понимаю, что в ситуации, когда уже написано огромное количество различных API, и все они без нормальной документации, представленное решение кажется отличным выходом. Не садиться же в конце концов и не переписывать всё заново, не писать документацию к коду, который уже никто не помнит как вообще работает.
Но можно хотя бы сделать шаг в правильном направлении! У нас в компании ситуация была похожей ещё три-четыре года назад (с единственным исключением: у нас с самого начала был типизированный протокол, общий и для клиентов, и для сервера, в котором хотя бы поля были более-менее откомментированы). И тоже было огромное количество легаси, о котором знали буквально три старожила компании. Мы начали с того, что выделили отдельную команду, которая занималась тем, что проектировала API, описывала в документации сценарии его использования, обсуждала протокол как с серверными, так и с клиентскими разработчиками, и только когда все задействованные стороны согласны с проектом API и сопровождающей документацией — тогда изменения в протокол ехали в мастер и становились доступны как серверу, так и клиентам.
Несмотря на кажущуюся бюрократичность процессса, это окупилось сторицей. Любой разработчик, даже новичок, может начать работу над фичей, потому что все клиент-серверное взаимодействие описано в отличной документации, со скриншотами, примерами сообщений и так далее.
Люди, которые переезжают за рубеж, особенно в англоязычные страны, довольно часто с запозданием понимают, что умение читать мануалы на английском и писать на stackoverflow — это далеко не то же, что «владение английским» =) Я с этой проблемой время от времени сталкиваюсь, пытаясь найти архитектора со знанием английского себе в команду.
Перевод отличный и читается легко, в отличие от большинства переводов здесь! И сама книга, по всей видимости, интересная. Правда примечание от переводчика насчет «общества в США» кажется неуместным.
Если телескоп имеет ограниченный спектр, и излучение системы черных дыр тоже, то при движении к нам/от нас часть излучения за счет эффекта Допплера может смещаться за пределы спектра телескопа (например из видимого спектра в инфракрасный или даже радио-диапазон при движении от нас, или в ультрафиолет/рентген при движении к нам), что будет восприниматься как изменение светового потока.
Присоединюсь к вопросу про HandlerSocket. Все условия для такого перехода есть: MySQL, InnoDB, множество быстрых однотипных операций вставки. Почему бы нет?
Сидят в гримерке два клоуна — молодой и старый, выдумывают репризу. Молодой говорит: давайте вы выйдете на манеж, уроните кошелек, нагнетесь, а я выбегу из-за кулисы и дам вам сапогом по ж*пе. Старый печально отвечает: не годится. Слишком тонкая шутка для нашего цирка…
1) от того, что SpaceX — частная компания (она не тратит бюджетные, то есть наши с вами, деньги)
2) от того, что это был испытательный запуск, и ракета была взорвана специально для того, чтобы избежать возможных последствий аномалий, выявленных в ходе испытания (а не взорвалась в результате неудачного коммерческого запуска, похоронив несколько дорогих спутников)
Хотя это похоже на какой-то фейк. Как может получиться, что владельцы будут обязаны пройти какую-то регистрацию, описанную в законопроекте, если законопроект еще не вступил в силу? На основании какого нормативного акта будет создан этот реестр и будет взиматься пошлина? Нельзя же взимать деньги на том основании, что «через полгода закон выйдет, который обяжет вас эти деньги заплатить». Какая-то юридическая нелепость.
В течение шести месяцев до вступления в силу настоящего закона все владельцы сайтов обязаны будут пойти процедуру регистрации владельцев сайтов и представить в регистрирующий орган необходимые документы. В случае непредоставления документов сайт будет заблокирован для прохождения указанной процедуры
Справедливости ради, должен отметить, что в исходном посте есть логическое противоречие:
В Рунете всего около 6 миллионов сайтов. По 1000р с каждого — это будет 6 000 000 000 рублей.
На меня лично зарегано несколько десятков сайтов
Учитывая, что плата взимается за регистрацию владельца, а не сайта, приходим к выводу, что такой простой расчет (6 млн * 1000р) делать нельзя: у одного только автора поста больше 10 сайтов.
Законопроект от этого не становится продуманнее или нужнее, он безусловно идиотский, но не стоит давать сторонникам этого закона повод тыкать нас носом в наши собственные ошибки со словами «Прежде чем законы обсуждать, научитесь считать правильно» (а это кстати их излюбленный прием для таких случаев).
Все идет к тому, что таргетированная реклама будет отображаться где-нибудь на шкафу («Грандиозная распродажа в Tommy Hilfiger!») или над зеркалом («Праздничные скидки на фитнес!»).
Мне, откровенно говоря, все равно, просто эта картинка очень хорошо выражает мое отношение к этой затее. Если угодно, я могу объяснить более развернуто:
Есть вещи, которые призваны решить какую-то проблему. В данном случае цветовое кодирование призвано решить надуманную проблему слишком медленного чтения. Даже если отбросить историю эволюции письменности и предположить, что проблема реально существует и описанный способ эту проблему решает (с чем я не согласен), то все равно мы сталкиваемся с десятком других проблем, например невозможность напечатать текст на чб-принтере, написать от руки и так далее, и все преимущества способа мгновенно сводятся на нет.
С другой стороны, есть вещи, которые пишутся for fun, например язык brainfuck. Такие вещи безусловно имеют право на существование, и описанный автором способ вполне мог бы занять достойное место среди таких забавных экспериментов. Но он был представлен не как веселый эксперимент, а как решение проблемы, потому у меня и возникла такая реакция.
К сожалению, есть несколько проблем, которые усложняют для нас поддержку истории релизов.
* Мы релизим новые версии каждую неделю, и зачастую окончательное понимание, что именно едет в релиз, возникает только в день релиза. А нам нужно ещё перевести историю изменений на несколько десятков языков, что сильно бы замедлило релиз.
* Часть изменений не появляются сразу для всех пользователей. Как Данил указал в статье, часть функций управляется с сервера либо A/B тестируется, соответственно мы не можем объявлять о том, что появилась новая функция, пока не включим ее для всех пользователей. Это довольно сложно контролировать и синхронизировать (нужно чтобы информация о завершенных A/B тестах и включенных на определенную страну фичах появлялась в релизе, который едет в момент раскатки теста или фичи), плюс это не совсем честно: функциональность может зачастую появиться в приложении даже без обновления, если например вы были в контрольной группе теста и вдруг тест раскатили на 100%.
В целом я согласен, что видеть в истории изменений только Fixed bugs and improved performance довольно грустно, но пока мы не можем себе позволить выделить достаточно ресурсов для решения всех перечисленных проблем.
С одной стороны, довольно понятное опасение, такое, действительно, бывает, что в приложении появился баг или пропала понравившаяся фича. С другой стороны, всегда приходится искать компромисс между поддержкой старого кода и написанием нового. Как мне кажется, мы нашли довольно разумный компромисс: обязательное обновление включается для приложений, выпущенных примерно полгода назад, и только в том случае, если телефон поддерживает это обновление (иногда без апгрейда версии iOS или Android нельзя поставить новую версию приложения, а далеко не все производители телефонов обновляют прошивку до последних версий OS). Для таких пользователей мы делаем исключение и не показываем блокер.
В любом случае, ситуация в мобильных приложениях с этой точки зрения существенно лучше, чем, скажем, на веб сайтах: там вообще нет выбора обновляться или нет, вы всегда пользуетесь последней версией, и всегда может пропасть полюбившаяся фича или появиться баг.
Давайте на секунду предположим, что на самом деле и мальчики, и девочки в IT могут быть одинаково успешны, что нет никакого «технического склада ума», присущего мальчикам, нет биологически обусловленных различий. Предположим мы это для того, чтобы сразу исключить вещи, которые мы в таком случае изменить не можем.
А если в среднем по популяции талантливыми разработчицами могут стать столько же девочек, сколько мальчиков — талантливыми разработчиками, то почему баланс не 50/50?
Раз уж мы в качестве мысленного эксперимента исключили влияние биологических факторов, то давайте попробуем подумать, какие ещё могут быть факторы. Представим себе стандартную воронку, где вход в воронку — это рождение девочки, выход — становление ее как профессиональной разработчицы ПО (или тестировщицы, или представительницы любой другой IT-профессии).
Воронка называется так, потому что она представляет собой перевернутый конус (или пирамиду), где на вершине — 100% родившихся девочек, а внизу — те доли процента, которые дошли до конца воронки.
Соответственно на каждом «шаге» воронки какое-то количество девочек отсеивается.
В садике — девочки тусуются с девочками, играют в куклы вместо машинок, у них не формируется представление о механизмах и принципах их работы. Они не играют в войнушку, где вырабатываются начальные навыки лидерства и умения достичь своей цели, зато играют в дочки-матери или в больничку, где вырабатывается эмпатия и умение понимать других людей, их эмоции и так далее. Их интересы смещаются от техники к общению.
Дома — девочки не учатся с папой мастерить инструментами, или строить, или разбираться с роботами и компьютерами. Вместо этого мамы учат их готовить, шить, мастерить украшения. Это не хорошо и не плохо, это данность, потому что десятки поколений так делали, и зачем что-то менять, не так ли? И вот мы видим, что формируется некоторый стереотип того, что девочка должна уметь/хотеть/любить, а что нет.
Дальше школа с их уроками труда, дальше выбор куда поступать с извечным «ну куда ты на физфак пойдешь, там одни парни», и так далее. Человек в своей жизни принимает миллионы мелких решений, и часть из них принимаются потому, что «так принято, так все делают».
И вот мы видим, что все больше и больше девочек выпадают из этой воронки на каждом этапе. У них нет ролевых моделей, к которым им хотелось бы стремиться, у них нет поддержки родителей, друзей, учителей. Их интересы формируются социумом, и это система с положительной обратной связью. «Мне не интересны компьютеры, мне интересна литература, я буду общаться с теми, к кого такие же интересы, и тем самым буду укреплять стереотип». Даже самые целеустремленные и нацеленные на IT девушки рано или поздно, зайдя на хабр, столкнутся с такой вот статьей, где человек прямо говорит «зачем мне как работодателю нанимать девушку» и сделают выбор не в пользу IT, выпадая из воронки.
Все эти неуклюжие «гендерные балансы» и так далее — на самом деле ни что иное, как попытка переломить ситуацию. Невозможно разом взять и выровнять воронку, которая формировалась поколениями. Но компании, у которых есть ресурсы и определенная доля социальной ответственности, пытаются сделать то, что в их силах для того, чтобы ситуацию улучшить. Конкретно этот спущенный сверху баланс 50/50 — это решение безусловно спорное, так как оно отталкивается от равенства результата, а не равенства возможности («equal outcome vs equal opportunities»), но даже такое решение имеет положительные черты: те девушки, которые ещё не приняли решения, не выпали из воронки, будут видеть больше ролевых моделей для себя, у них появится мотивация продолжать. Если они будут наблюдать примеры того, что женщины могут быть успешными в IT-индустрии, причем не единичные персоны, а массово, у них будет больше шансов остаться в воронке.
Конечно же, решать задачу нужно по всем фронтам. В этом смысле меня очень вдохновляет пример Даши Абрамовой, создательницы Кодабры, которая учит программированию детей дошкольного и школьного возраста. Она работает на самом верху воронки, и это мне кажется более эффективным решением. Но и помимо нее есть множество программ, работающих с детьми, и с девочками в частности, в том числе спонсируемых или организованных крупными компаниями.
Ну а что если наш мысленный эксперимент не имеет отношения к делу, и причина дисбаланса все же в гендерных различиях?
Это возможно. Есть исследования разной степени достоверности, как подтверждающие, так и опровергающие такую точку зрения. Но на этот счет у меня 2 мысли:
1) если это так, то мы сможем это понять только после того, как устраним социальные факторы, что и пытаются сделать те, кто стремится к 50/50 балансу
2) и даже если гендерно-обусловленные различия есть, могут ли они обуславливать настолько существенный дисбаланс (как указал автор статьи, «по индустрии этот баланс 90/10»)? Каков бы стал баланс, если убрать социальные факторы? Может он установился бы на уровне 60/40, или 55/45, кто знает?
Плюсую совет про «мифический человеко-месяц», хотя она и более занудная и во многом довольно устаревшая, но все же очень полезная.
Добавлю ещё от себя Peopleware: Productive Projects and Teams, автор Tom DeMarco. Это интересная и легкая книжка про то, как строить команды и управлять ими. Немного устаревшая с точки зрения современных реалий, но не настолько, как мифический человек-месяц. Рассматривает вопросы эффективности работников в разных условиях (от собственного кабинета до опен спейса), эффективность переработок, мотивацию, сопоставляет цели компании и цели работника. Рассказывает как сломать хорошую команду (рецепта как построить у них нет — их мысль в том, что не надо ломать, и есть шанс что сама построится).
Ну и вообще у Тома ДеМарко хорошие книжки, тот же Slack например.
Какие проблемы решены?
Какие проблемы остались нерешенными:
Что ещё забыл?
Я понимаю, что в ситуации, когда уже написано огромное количество различных API, и все они без нормальной документации, представленное решение кажется отличным выходом. Не садиться же в конце концов и не переписывать всё заново, не писать документацию к коду, который уже никто не помнит как вообще работает.
Но можно хотя бы сделать шаг в правильном направлении! У нас в компании ситуация была похожей ещё три-четыре года назад (с единственным исключением: у нас с самого начала был типизированный протокол, общий и для клиентов, и для сервера, в котором хотя бы поля были более-менее откомментированы). И тоже было огромное количество легаси, о котором знали буквально три старожила компании. Мы начали с того, что выделили отдельную команду, которая занималась тем, что проектировала API, описывала в документации сценарии его использования, обсуждала протокол как с серверными, так и с клиентскими разработчиками, и только когда все задействованные стороны согласны с проектом API и сопровождающей документацией — тогда изменения в протокол ехали в мастер и становились доступны как серверу, так и клиентам.
Несмотря на кажущуюся бюрократичность процессса, это окупилось сторицей. Любой разработчик, даже новичок, может начать работу над фичей, потому что все клиент-серверное взаимодействие описано в отличной документации, со скриншотами, примерами сообщений и так далее.
Кто бы сомневался =)
2) от того, что это был испытательный запуск, и ракета была взорвана специально для того, чтобы избежать возможных последствий аномалий, выявленных в ходе испытания (а не взорвалась в результате неудачного коммерческого запуска, похоронив несколько дорогих спутников)
Ну и статью целиком полезно прочитать.
Учитывая, что плата взимается за регистрацию владельца, а не сайта, приходим к выводу, что такой простой расчет (6 млн * 1000р) делать нельзя: у одного только автора поста больше 10 сайтов.
Законопроект от этого не становится продуманнее или нужнее, он безусловно идиотский, но не стоит давать сторонникам этого закона повод тыкать нас носом в наши собственные ошибки со словами «Прежде чем законы обсуждать, научитесь считать правильно» (а это кстати их излюбленный прием для таких случаев).
Вам срочно нужен обряд экзорцизма.
Мне, откровенно говоря, все равно, просто эта картинка очень хорошо выражает мое отношение к этой затее. Если угодно, я могу объяснить более развернуто:
Есть вещи, которые призваны решить какую-то проблему. В данном случае цветовое кодирование призвано решить надуманную проблему слишком медленного чтения. Даже если отбросить историю эволюции письменности и предположить, что проблема реально существует и описанный способ эту проблему решает (с чем я не согласен), то все равно мы сталкиваемся с десятком других проблем, например невозможность напечатать текст на чб-принтере, написать от руки и так далее, и все преимущества способа мгновенно сводятся на нет.
С другой стороны, есть вещи, которые пишутся for fun, например язык brainfuck. Такие вещи безусловно имеют право на существование, и описанный автором способ вполне мог бы занять достойное место среди таких забавных экспериментов. Но он был представлен не как веселый эксперимент, а как решение проблемы, потому у меня и возникла такая реакция.