усы2

Стой под стрелой

Поступки и мысли, о которых могу вспомнить не краснея

The Blessing of Interactive Development
усы2
tonsky
Написал, почему интерактивная разработка — это круто. Стремитесь

http://tonsky.me/blog/interactive-development/

Проблема с ярлыками
усы2
tonsky

Чем отличаются эти две иконки?

Если у вас есть какой-никакой опыт с компьютерами, вопрос покажется вам слишком простым. Однако, есть проблема.

Ярлык — абстрактное понятие. Его можно понять, но для этого требуется усилие и определенный склад ума. Ярлык противоречит бытовому опыту. В жизни, если у вас есть книга, то она либо стоит на полке («все книги»), либо лежит на столе («десктоп»), либо мы ее сейчас читаем («открыта сейчас»). Можно сказать, что у книги есть состояние, ее можно переводить из одного в другое, но — на что можно всегда положиться — книга одна и она всегда в каком-то одном месте.

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

Положение усугубляется тем, что ярлык нарочно выглядит так же, как и исходный объект, но работает по-другому.

Т.е. есть сильная визуальная метафора (иконка), и есть некий тонкий скрытый нюанс, который кардинально меняет ее поведение. Из-за этого диссонанса (выглядит одинаково, работает по-разному) надо держать в уме дополнительную переменную — тип объекта. Если про него забыть, а это очень легко, сразу появляется ненадежность: может работать так, а может иначе, как именно — не предугадаешь.

Ненадежность в интерфейсе — страшная беда. Она рождает страх, неуверенность, осложняет формирование привычки и сильно поднимает порог обучения. Обучиться надежному действию (нажми кнопку — потечет вода) на порядки проще, чем ненадежному (сначала нажми сюда, чтобы войти в режим настройки, затем сюда, чтобы выбрать дату, затем сюда чтобы скорректировать день). Хуже всего это в интерфейсах, которыми пользуются нечасто — у мозга просто недостаточно усилий, чтобы запомнить все контексты и переходы. Даже если потратить время и «разобраться», через неделю все выветрится.

Что делать? Делать интерфейс надежным (вещи всегда ведут себя одинаково и предсказуемо). Качество интерфейса, в котором хотя бы часть элементов работает всегда одинаково (всегда-всегда, без контекстов, условий, попапов и прочих «но») вырастает на порядки (см. мой пост Единственная надежная кнопка).

Дальше: не вводить абстарктных концепций. Ориентироваться на бытовой опыт. Проще всего с иконками: если у тебя приложение есть, есть и его иконка. Ярлыков нет, иконка одна и где-то в одном месте лежит: в панели быстрого запуска, на десктопе, в папке Хлам. Это очень простая и прямолинейная концепция: иконка=приложение, папки/панели/экраны=место.

Так работает, например, iOS, который перепридумывали с нуля, выбросив наследие десктопных компьютеров:

У каждой иконки может быть только одно место. «Вид» удаления только один, и он совсем удаляет:

А вот Android сохранил ярлыки и создал путаницу:

Даже в свежайшей 6-й версии они путают пользователя тем же вопросом, что и Windows 95: удалять ярлык или приложение? Такие вопросы можно задавать только бородатым 40-летним сисадминам.

Тут же возникла и печальная рассогласованность: чтобы убрать приложение с десктопа в нижнюю кнопку, надо перетащить его наверх.

Формально, как программист, я понимаю ход мысли, но это очень, очень сложно и нелогично на бытовом уровне. У меня на столе лежит книга и я хочу убрать ее на полку. Зачем перетаскивать ее в мусорное ведро, да еще и в другом конце комнаты?

Но прогресс не стоял бы на месте, если бы в Гугле не придумали как сделать хуже чем было в Windows в 95-м году. Ярлык сейчас от приложения визуально не отличается совершенно:

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

Полноты ради, у Windows Phone та же проблема, но с десктопа нельзя приложение совсем удалить, только ярлык. Плюс в том, что хотя бы не нужно принимать решение (Удалить или Удалить?). Это значит, что человек сможет пользоваться своим телефоном без услуги «звонок другу», но все-таки приложения будут копиться. Это все-таки лучше, т.к. прямо сейчас жить можно, а проблему можно решить позже — очень правильное качество «скромных» интерфейсов.

В обсуждении просьба помнить, что это пост о конкретном интерфейсном аспекте, а не о том, что «Андроид говно» (конечно говно, даже windows phone лучше). Просто единственный нормальный пример, где нет этой проблемы — iOS, в остальных местах она везде есть (особенно на десктопах). Также, не надо мне пожалуйста рассказывать что я тупой и не разобрался. Или что вы лично разобрались и не видите проблемы. Это искаженное восприятие и отсутствие эмпатии. Некоторые вещи должны (и могут) быть сделаны так, чтобы не надо было разбираться.

Влезай — убъет. Правила жизни
усы2
tonsky
Стой под стрелой. Мочи манту. Корми животных. Дели на ноль. Кури. Зарекайся. Ходи за гаражи. Лезь в драку. Понижай градус. Пей из-под крана. Плюй в колодец. Суй нос в чужие дела. Тяни резину. Прислоняйся. Сори. Бей девочек. Перечь старшим. Надевай белое. Ходи по газонам. Сутулься. Лезь на рожон. Свисти в доме. Входи к посторонним. Суди по обложке. Плюй против ветра. Держи зла. Ищи виноватого. Гуляй с незнакомыми. Пытайся повторить это дома. Рой яму другому. Выноси сор из избы. Сидишь на суку — руби.

ClojureCup 2015
усы2
tonsky

По традиции, мы опять упоролись хакатоном.

TL;DR видео-демка

(Ссылка на голосование внизу поста)

Про идею

Меня давно волновало, что все сервисы для докладчиков какие-то, ну, никакие. Да, хочется поделиться слайдами после доклада (speakerdeck, slideshare), но хочется чтобы у презентации какая-то жизнь была после этого, а не «слил и забыл». Или можно «делать слайды» (google docs, prezi, slides.com), но мне вот не кажется, что ключ к крутому докладу в эффектных слайдах или головокружительных переходах. Т.е. это вишенка, но на торте, которого сейчас ни у кого нет. А то что есть — всё в разных уголках, сделал на google docs, показал из pdf, залил на slideshare, на вопросы отвечаешь в ЖЖ.

Так родился Deckatron — сервис презентаций, на котором можно придумать, создать, показать, ответить на вопросы, опубликовать свою презентацию и украсть чужую.

Начинается все с markdown-редактора. Текст накидывается прямо на сайте, и markdown, на мой взгляд, идеальный формат для того, чтобы быстренько записать, упорядочить разрозненные мысли и составить план. Беда всех редакторов слайдов — в них невозможно «думать», слишком много возни, чтобы поправить текст, поменять порядок, добавить пару мыслей. У нас вся презентация — один сплошной текстовый документ. Что может быть проще?

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

У редактора есть WYSIWYG, так что в реальном времени видно, что там получается из слайдов (не переносится ли заголовок, входит ли код, не мешает ли фон). Подготовка заканчивается выбором цветовой темы.

Дальше по идее должен идти режим репетиции, но я пока не уверен, чем он должен от режима презентации отличаться. В любом случае, здесь у нас пока пусто.

И наконец презентация! Тут у нас все для этого и даже больше. Полноэкранный режим — разумеется.

Есть еще режим зрителя: когда ты заходишь на главную страницу, там есть секция «Live right now», т.е. презентации, которые прямо сейчас идут.

Если в такую ткнуть, она тоже откроется на полный экран и можно видеть, как докладчик переключает слайды в реальном времени. Удобно, если сидишь за колонной в зале, например. Плюс видно, сколько человек смотрит прямо сейчас (такое же есть на slides.com)

Ну и вторая важная фича — вопросы докладчику. Пока идет доклад, можно открыть специальный попап, задать вопрос или проголосовать за чужой (ради этого, например, существует целый отдельный сервис sli.do).

В конце доклада вставляется специальный слайд, на котором показаны наиболее популярные вопросы (да, больше не надо специально делать слайд «Вопросы?»). Естественно, всё это в реальном времени, без перезагрузок, на server push и вебсокетах. Мне нравится, как традиция (слайд в конце со словом «вопросы») реализуется современными технологиями на качественно новом уровне и начинает буквально выполнять ту функцию, которую она до этого только обозначала.

Наконец, что происходит после доклада? У вас хорошая порция материала, он уже структурирован, глупо выбрасывать его. Выложить слайды часто недостаточно. Видео делают долго (а ажиотаж штука быстро протухающая), да и смотреть его потом часто мучительно медленно. Декатрон позволяет доклад грамотно выложить — разбавить слайды комментариями, чтобы получился такой блог-пост с картинками. Можно начать с поста, потом добавить слайдов, можно сделать слайды, потом дописать комментарии — как больше нравится. Главное, что другие люди смогут это прочитать и извлечь пользу. Идея родилась два с половиной года назад, опробована тут, тут и тут.

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

Наконец, уже просто веселухи ради, мы прикрутили кнопку «Fork this deck», которой можно скопировать себе презентацию и поправить как угодно. Осмысленный вариант использования — самому делать вторую/третью/четвертую версию однажды уже рассказанного доклада. Неосмысленный — социализация, что ли?

Про реализацию

Мы сделали это все за двое суток командой из четырех человек. Clojure, ClojureScript, Http-kit, Rum, Transit, Instaparse. Без DataScript-а.

Экраны мы проектировали в Precursor (проект, выросший из ClojrueCup, между прочим), его даже можно посмотреть

Очень много углов срезано, держится буквально на соплях. Из страшного — markdown парсер мы писали сами, и он получился, что называется, «с особенностями». Синхронизация данных работает только по оптимистичному пути — если что-то пойдет не так, в лучшем случае undefined behaviour. Презентации хранятся в обычных файлах. Логинов нет, аутентификация по автоматически выдаваемой куке.

Короче, все, что не портит в первом приближении user experience, сделано по максимально простому пути. Фокус — на фичах, а не техническом совершенстве, которое, скорее всего, на таких масштабах никто не сможет оценить.

Из хорошего — мы сделали довольно изящную систему синхронизации. Взяли clojure.data/diff чтобы вычислять дельты между произвольными словарями и написали функцию patch которая может эти дельты применять. Дальше, на любое изменение мы шлем, бродкастим и применяем эти дельты где можем. Кайф в том, что механизм универсальный и автоматический, поэтому вся работа со стейтом локальная, ничем не ограниченая (меняй как хочешь), и где-то в фоне по волшебству просасывается ко всем. Например, вопросы на слайды я добавил где-то за час (из него минут 20 я сердечко для лайков искал), и написал 0 строк кода чтобы они были риалтаймовыми — они по-другому просто получиться не могли. В идеальном мире, конечно, данные будут не словарями, а CRDT, а редактор текста вообще OP, и тогда это еще и надежно заработает, но за два дня такого не успеть (ну или нужен опыт работы со swarm.js, которого не было).

Что я хочу сказать — в будущем, когда клиент-серверное общение будет настраиваться одной кнопкой по принципу «вот ip сервера, общайтесь», и дальше оно как-то само, в фоне, с fallback на localStorage и прочими оптимизациями, тогда заживем. Стоимость веб-приложений упадет до нуля практически (ну, если еще вместо box модели нормальные констрейнты прикрутят).

Заключение

Я больше всего горжусь идеей — мне кажется, это вполне серьезное продуктовое предложение, без скидок на хакатон. Т.е. если бы оно работало, я бы им только и пользовался. Плюс то, что все собрано в одном месте, ценно само по себе. Мне нравится, что презентацию можно начать, сделать, доложить и опубликовать, не выходя из одной вкладки в браузере. Презентационным платформам пора бы запрыгнуть на поезд Web 2.0 и начать думать дальше PowerPoint модели.

Ну и я очень доволен, что мы сделали достаточно много фич, по крайней мере, чтобы показать поддержку полного цикла жизни презентации. Продуктивно и организованно провели два дня. Жалею только, что кнопка «Read» стоит до «Present», а не после.

ВАЖНО!

Как обычно, нам нужен ваш голос. Да-да, именно ваш! Если идея вас впечатлила, пройдите на clojurecup.com/voting, залогиньтесь через github и проголосуйте за Deckatron (команда The Other Guys).

В главных ролях:

Олександр Шишко, Михаил Акованцев, Ренат Идрисов и я.

Предыдущие серии: 2013, 2014


Ну, за независимость!
усы2
tonsky
Управлять зависимостями трудно. Сам факт того, что такое понятие существует, уже намекает, что там есть с чем повозиться (простите мне чересчур мягкую формулировку, я сдерживаюсь изо всех сил). Поэтому один из важных принципов разработки — не тащить зависимости. В институте учат, что переиспользование кода — главная благодетель (и эта мантра наделала ужас сколько вреда). Так вот, переиспользование кода из сторонней библиотеки — тот случай, когда копипаста лучше переиспользования. Бывают библиотеки, большие и сложные, дающие бонус только целиком. Зато он существенный, и без него никак. Тяжелая алгоритмика. Новые качества. Тогда — конечно. А всякие утилитки, функции на десять строчек, удобные оберточки над платформой — задумайтесь, выдохните, и не тащите. Скопируйте одну функцию, если правда удобно. Я уж не говорю про случаи, когда быстрее сделать, чем искать, какая библиотека это уже делает (может это форма социализации такая, использовать чужой код, даже тривиальный? Или неуверенность в себе?). Особо остро выделяются свалки, где много разного, а раз много, значит каждый релиз что-то да сломают. Вообще, жалко, что так мало у нас ценят законченные вещи. Доделанные до конца, с фиксированым скоупом, а значит стабильные, не меняющиеся.

Есть еще конфликты версий, но с этим проще. Следуйте принципу: в своем приложении творите что душе угодно, тащите сколько угодно хлама, если времени не жалко потом его обновлять. Но если делаете библиотеку — у нее не должно быть зависимостей. От слова совсем. Полностью самодостаточный код, зависит только от платформы. Да, несправедливо по отношению к авторам библиотек — не вкусить им плодов прогресса и удобства опенсорсных АПИ (гг). Но эта жертва сэкономит непропорционально много времени всем остальным. Если подумать не о себе, а о потенциальных заинтересованных в библиотеке коллегах, понятно, что у них в приложении организационные вопросы уже как-то решены — логирование, коммуникация, хранение стейта, управление подсистемами, event loop. Если автор библиотеки пытается что-то из этого заиспользовать в библиотеке (упростить жизнь себе? помочь пользователям?), очевидно, он будет только мешать. Крепитесь, это не так уж страшно.

Как вы лодку назовете...
усы2
tonsky

Не плодите имен. Бывает, что одну и ту же вещь называют двумя-тремя-четырьмя разными способами. Например, переменная окружения, ее имя в коде, ее имя в логе, имя ключа в JSON, глобальное имя в JS и так далее:

resourcePrefix = getenv(“RESOURCE_PREFIX”)
log.info(“resource prefix: “ + resourcePrefix)
JSON payload = { “resource_prefix”: resourcePrefix }

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

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

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

Наконец, третье. Процесс переименования сам по себе бесполезен. Он занимает реальные строчки кода, вводит новые сущности. Даже так: вводит новые имена, что когнитивно дороже, чем сущности. Тут работает более общее правило: любое усложнение, любое действие, любое решение — у всего должна быть причина. Конкретная причина, конкретное объяснение, вербальное, формулируемое. Очень легко проверить — просто сформулируйте словами. Здесь же действие налицо, а причина очень зыбкая, почти эфемерная.

Императив достаточно простой: используйте одно и то же имя. Тащите в код переменную окружения COMPANY_RESOURCE_PREFIX? Так и назовите: String COMPANY_RESOURCE_PREFIX = …;. И в JSON засуньте под тем же именем. И в БД. Так же и со всем остальным: имя таблицы и имя ORM-класса. Имя файла и имя переменной с его содержимым. Ключ в хэше и ключ в БД. Это упрощение, а упрощения окупаются многократно.

Да, это не всегда это возможно — в некоторых ситуациях определенные виды имен запрещены. Я могу долго рассуждать, сколько вреда несут искусственные, ничем не оправданные ограничения на имена, придуманные во времена телетайпов и даже тогда взятые, как правило, с потолка; сколько сил и энергии вообще на это тратят программисты, как часто подобные соглашения античеловечны (почему у кого-то нельзя пробел? Дефис? Юникод? И т.п.). Тут ничего не поделаешь, конечно. Моя задача — посеять правильную идею.


Единственная надежная кнопка
усы2
tonsky
Одна из причин, почему смартфон — прибор для гораздо более широкой аудитории, чем традиционный ПК — надежно работающие кнопки. Что бы ни происходило, в каком бы состоянии ни находились телефон, приложение, соединение с интернетом, блютусом и USB, в одно нажатие вы всегда можете выключить телефон, и вы всегда можете «вернуться на базу» — некое хорошо знакомое стартовое состояние, домашний экран. Ключевые слова «надежно» и «в любой момент». Что бы ни происходило, как бы плохо ни было написано приложение, в какую бы непридвиденную комбинацию внешних условий оно ни попало, телефон гарантирует вам работу двух этих кнопок.

В то же время на ПК даже самая надежная кнопка, даже в идеальных тепличных условиях, нет-нет да и выдаст что-то неожиданное. Иногда запускает приложение, а иногда (как известно, в самый неподходящий момент) показывает окно с обновлениями, подсказками, скажет, что потеряло каталог, не хватает прав или еще что-то. Иногда закрывает приложение, а иногда просит сохранить файлы, согласиться с потерей табов, ответить, надо ли перезапускать при старте. _Внутри_ компьютера нет ни одной надежно работающей кнопки. Единственно надежно работающая кнопка на компьютере — это Reset. Возможно, именно сквозная ненадежность всего и вся разработала у людей страх компьютеров.

Естественно, если спросить ПК-программиста, то ничего странного в этой ситуации нет, для него это более чем нормально. Подозреваю, эта культура идет от старых представлений об искусственном интеллекте, диалоге человека и машины как равных. Предполагается, что человек спокойно сидит, сосредоточен только на диалоге и полностостью вложил все свои ресурсы на извлечение из беседы результата. Это очень удобно, потому что спокойно можно свалить на человека часть работы, а ошибки и сложности списать на его недостаточную тренированность или вовлеченность (пресловутое «юзеры тупые!»). Мы, как программисты, глубоко впитали эту модель взаимодействия, и, на мой взгляд, недостаточно часто пытаемся ее отрефлексировать.

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

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

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

Мораль очень простая: всегда ставьте человека на первое место, а компьютер на второе, третье, четвертое. Человек нажал «Выход» — надо выходить, как бы ни хотелось с ним именно в данный момент поговорить.

P.S. в комменты пришел тот самый «ленивый программист» и оправдывает проблемы UI тем что работа программиста тяжелая

Потрачено
усы2
tonsky
Пишешь веб — наешься интернет эксплорера. Такой крутой, что можешь забить на эксплорер? Наешься адаптивности под мобилки. Пишешь веб в контролируемом окружении? Наешься джаваскрипта и тормозов. Убежал на iOS? Замучаешься с Objective-C. Передумал и взял Андроид? Наешься квадрилиона девайсов, все разные. Пишешь desktop UI? Готовсья, что нормального фреймворка нет от слова нигде. Окей, бэкенд? Наешься администрирования линукса, зоопарка языков, сборок, dependency hell и опенсорса. Big data? Хадуп и докер, прости господи. Игры на PC? Привет от C++ и зоопарка железа. Консоли? Баги, лимиты, отсталый инструментарий.

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

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

Just saying. Компьютеры вокруг нас, а программирование нет.

Веб послезавтра
усы2
tonsky
Новый пост в англоязычном блоге про то, как должен выглядеть мировой паутин (спойлер: не так, как получилось) и как его таким сделать. Без React-а:

http://tonsky.me/blog/the-web-after-tomorrow/

БД на диване
усы2
tonsky
Я тут слушаю по субботам подкаст, пока в квартире убираюсь, DevZen. У нас с ними своеобразный симбиоз: они мои посты иногда обсуждают, а я из их высказываний иногда черпаю темы для новых постов. В этот раз был совершенно некрасивый наезд на дашборд CouchBase, мол, зачем оно такое нужно, если правильные админы первым делом метрики в graphite сливают.

Я согласен, что дружить с внешним миром надо уметь, но Валера (в основном) совершенно не понял прикола, что это за дашборд. Между тем это очень концептуально важная штука: CouchBase это программа, хардкорная, серверная, все дела, для серьезных продакшнов, которая сразу работает. То есть ее установка это apt-get install и после этого пара кликов мышкой в веб-интерфейсе. Даже настройка кластера в эти пару кликов укладывается. То есть это примерно как скачать программу из аппстора, сравнимый уровень головняка. Я понимаю, что это непривычно, и что так почти никто не делает. Но так можно, и это революционно.



И кайф не только в установке. Сам CouchBase это предельно простой продукт, распределенный кэш ключ-значение. Я подозреваю что там функционального кода раза в 3 меньше чем навернутой вокруг него админки. В нормальном продукте так и должно быть. Это программа, которая сама знает о своей эксплуатации, мониторит ее, репортит, дает UI для управления. У них там графики нагрузки (десятки метрик, возможность zoom in к чему-то конкретному и zoom out к общей картине), мониторинг хост-системы, схема кластера, UI для переконфигурации. Все это живое и web 2.0. По сути это базовый алгоритм и навернутый вокруг него сложный пульт, покрывающий все эксплутационные потребности от начала до конца. Законченная программа, от и до, под ключ.



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

И не надо мне говорить, что сливание в одно место, унификация, единый стандарт решают. Не решают. Метрики можно слить, а вот состояние кластера уже вряд ли. Топ 20 горячих ключей тоже непонятно куда пристроить. UI для перебалансировки точно ни с чем не унифицируется. Ну и так далее.

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

Да, можно повторить только read-only часть, экспортнув метрики в Graphite, но это во-первых надо работать (вы уверены, что настроите свой мониторинг заранее, авансом, с первого раза правильно и полно?), а во-вторых непонятно зачем графики нужны без возможности сразу на ситуацию повлиять. Плюс мне не очень понятен постулат, что ваш локальный админ, у которого стопятьсот дел помимо CouchBase, вдруг настроит мониторинг и репортинг для кластера сразу полнее и надежнее, чем это сделали авторы самого CouchBase, которые свою карьеру строят на том, что только о нем и думают.

без темы
усы2
tonsky
JFYI история с МТС закончилась положительно после того, как я написал им в Твиттере. Сила социальных медиа, понимаешь. Это еще предстоит осмыслить. Почему-то саппорт по телефону даже не предлагал вариант «создать заявку».


Clean не нужен
усы2
tonsky
Когда-нибудь задумывались, зачем в билд-системах команда clean? То есть, понятно, почему она в них была, но почему она до сих пор есть? Почему иногда билд собирается только с чистого листа?

Это все от бедности. Сравнение файлов по дате модификации. Переписывание билд-артефактов. Инкрементальный билд это кэш, а инвалидация кэша — одна из самых сложных задач в CS. Естественно, она всегда будет решаться с ошибками.

Единственная вещь, которая идеально кэшируется это неизменяемые данные. get_cached(file_name) будет ломаться, get_cached(digest(file_content)) нет. Естественно, туда можно (нужно) еще всего напихать, типа окружения, версии компилятора, флагов, цели. Но смысл в том, что кэш по контенту работает сам, успевай только мусор подбирать. Главное — корректность.

Это подтверждает успех гуглового Bazel: ненадежные билды на makefiles вдруг стали железно надежными, стоило им перейти на такую схему. Это может быть и было дорого на 386-х, но сейчас один фильм на диске весит столько, сколько ваши разработчики не нагенерируют артефактов за все время жизни проекта.

Я очень жалею, что в ClojureScript не используется подобная схема, хотя казалось бы, кому, из всех людей. (Clojure здесь ловко выкрутилась — грузит файлы из исходников на лету). Билды портятся, приходится стирать и начинать все заново. Я не хочу ничего знать об этом, компьютер вычислительная машина, он должен работать надежно и предсказуемо. Билд это не гадание на нейронных сетях, вход, выход, алгоритм, все детерменировано. Избавьте меня.

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

Ладно мы, динамщики, у нас билды недолгие, единственно противно что ломаются при рассинхроне. Но все вот эти ребята, которые на C++ игры пишут и у которых ночной «чистый» билд по шесть часов, они как до сих пор к этой схеме не пришли? Это же классическое «лучше день потерять». Причем даже терять много не придется, система простая как тряпка. Зато окупаемость, о, мне сложно представить ее масштабы.

В идеале, конечно, понятия билда вообще не должно существовать. Билды не имеют отношения к работе программиста, это просто формальный, неудачный шаг. Зато их отсутствие целый пласт проблем снимает. JS, Python, Clojure все делают правильно. Но если уж делать билд, непонятно, почему не сделать его надежным и правильным. Таким, чтобы не было отдельного понятия «инкрементальный билд», чтобы любой билд был инкрементальным, быстрым, с распределенным кэшем. И чтобы я больше ничего о команде clean не слышал.

Перенос номера сотового на практике
усы2
tonsky
В один прекрасный день я купился на безлимитный, безроуминговый интернет и лимитный, но тоже безроуминговый (по России) телефон от Йоты. До этого я лет десять, наверное, был абонентом МТС и даже переезжая в Ульяновск и обратно сумел сохранить новосибирскую симку. Оставим в стороне факт, что если я хочу переехать в другой город, но остаться у того же оператора, мне нужна новая симка. Глупо, но глупости полно кругом, одной больше, одной меньше.

Решил перенести номер. Заявление можно написать сразу в Йоте, они утрясают все детали с отключением от МТС-а сами. Предупредили: проверьте, что баланс положительный, иначе беда. Положил денег с запасом. Жду. Номер переносится 10 дней. Жду. Пробую вставить Йотовскую симку. У Йоты нет личного кабинета, есть только приложение для Айфона и Андроида. Плебеи с Виндоус Телефоном пишут в чат техподдержки, чтобы выбрать тариф.



Балуюсь, пробую включить перенаправление вызовов с МТС-овского номера. Перенаправление у МТС не работает. Пролетает 10 дней. Приходит последняя жалобная смска от МТС: может, все-таки передумали?



Не передумал. Проверяю баланс МТС. Около 50 рублей. В полночь старая симка умирает, личный кабинет блокируется, номер переносится, ура, я счастливый обладатель Йоты.

Почти два месяца безмятежно пользуюсь новым оператором. Интернет денег не просит, 4G ловит, правда, хуже, чем у МТС. Езжу в Москву, звоню, сижу в интернете.

И вот приходит смс от Йоты: чувак, у тебя долг перед МТС, давай разберись, а то нехорошо выходит.



Интересно. Ищу, куда позвонить. У МТС на сайте ни на главной, ни в «о компании», нет вообще ни одного телефонного номера. Гуглю, звоню. Оказывается, через три недели после отключения у меня списали 150 рублей за услугу БИТ. Такая вот услуга, списывается раз в месяц. Окей, выясняю долг (97 рублей 59,96 копеек). Убеждаюсь, что гудок не подключен и дальше никаких списаний не будет (ну и что, что у меня даже симки уже нет, мало ли). Сообщают, что платить надо строго по номеру лицевого счета и строго в салонах МТС. Присылают номер счета смской.



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



Проходит 4 дня. Приходит смс от МТС. Уважаемый, вы у нас конечно не обслуживаетесь, но денег должны.



Интересно. Черт с ней, с пунктуацией. Гуглю номер МТС, звоню. Долг никуда не делся. Сообщаю, что платил. Рекомендуют позвонить по номеру с чека. Весь день названиваю по номеру с чека. Не берут трубку. Платежная система ТелеПэй. Названиваю по 8800 номеру ТелеПэй. Не берут трубку (целый день, Карл!). Я, в принципе, догадывался, что платежные терминалы это такие ящики для засовывания денег, без каких-либо гарантий. Убедился.

Окей, черт с ними со ста рублями. Иду в офис МТС (другой, на всякий случай). Объясняю ситуацию. В терминале платить отказываюсь, стою в очереди, рекламирую соседям тарифы от Йоты. Меня быстренько берутся обслуживать, достаю 100 рублей. Проблемы со связью. Жду 20 минут. Прихожу еще раз. Еще раз объясняю ситуацию. Выясняется, что проблемы не со связью, а с лицевым счетом. При попытке положить на него деньги возникает ошибка. Жалуюсь, что у меня из-за этих их ошибок отключат Йотовский номер. «Да ну, ерунда какая, не может такого быть», — заверяет меня девушка.

Возвращаюсь домой, гуглю номер МТС, звоню. Меня сразу предупреждают: не погасите задолженность — вас отключит Йота. Объясняю ситуацию. Меня заверяют, что никаких причин не принимать у меня деньги у МТС нет. Более того, МТС очень хочет моих денег.

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

Прихожу домой. Ситуация патовая. Моих денег хотят, но не могут взять. Злиться не на кого. Надо извлечь из этого какой-то урок, но непонятно, какой.

Завтра отключат симку.


Новый доклад «ФП в браузере: Redux»
усы2
tonsky
Текст и слайды: http://tonsky.me/talks/2015-frontendconf/


без темы
усы2
tonsky
Вслед http://ermouth.livejournal.com/641180.html

На меня вот эта книга очень сильно повлияла в детстве:



Программировать она не учит, практически совсем. Листинги есть в каждом совете, но их как-то особо не разбирают даже. Там истории интереснее, чем собственно программы — как и должно быть, по идее. То Мцыри печатают, то ищут стратегию для тройственной дуэли из «Хороший, плохой, злой», иногда просто байки травят. Интересно не само программирование, а то, вокруг чего оно используется.

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

ФП в Киеве есть
усы2
tonsky
Был две недели назад в Киеве, прочитал на митапе в Grammarly доклад, продолжение «ФП в браузере». Доклад про то, как сделать векторный редактор на React.js и Immutable.js.

Коротко:

На JS жить можно, с правильной архитектурой писать вполне терпимо. Я ожидал больше страданий. Запилил мультиметоды и атомы, впрочем.

Immutable.js нормальная штука, не хватает только сериализации/десериализации структур в строку, очень странно что они это упустили. Пришлось писать самому.

Еще смешно: Immutable.js портировали реализацию персистентных структур из ClojureScript, при этом писали на чистом JS и умудрились сделать ее в 2-3 раза медленнее, чем на ClojureScript. Вот вам и про преимущества ручного кода перед компилируемым.

Код: https://github.com/tonsky/vec (650 loc)

Живая версия:



Видеозапись:
http://www.youtube.com/watch?v=lDkrXTDwbJQ (разбор кода)
http://www.youtube.com/watch?v=tUtLe1VlkYc (ответы на вопросы)

В Киеве классно:


Не моноспейсом единым
усы2
tonsky
Как вы знаете, я сторонник точки зрения, что код — это еще и красиво (раз, два, три). А что может быть красивее, чем листинги в пейперах по Хаскелю? Встречайте:



Собственно, что я сделал? Взял шрифт из LaTeX (Latin Modern Roman), выкинул всю подсветку (курсив только натыкал кое-где, случайно почти, каюсь). Стрелочки — это не лигатуры, это настоящие юникодные стрелки из UnicodeSyntax. Единственная свинья — в Хаскеле народу чуждо чувство прекрасного и они отказались заменять (\...) на (λ...).

Это вполне рабочая тема для Atom. Код пишется. Форматируется, естественно, табами. Пока это самая слабая часть, хочется семантического выравнивания.

Круто? Распробую — напишу, в чем подвох.

О пользе чистых начал
усы2
tonsky

Тут в Гугл Плюсе Евгений Охотников сетует, что наработки 80–90-х годов нельзя переиспользовать в вебе:

Ну вот, допустим, кто-то 20-ть лет назад сделал движок текстового или графического редактора. Не суть важно, на C++, Eiffel, Java или Delphi. Для десктопа, понятное дело, т.к. Web тогда только зарождался. Какое-то время этот движок был актуальным и мог быть портирован под разные платформы путем адаптации GUI-библиотеки (или же путем написания слоя между движком и конкретной GUI-библиотекой).

Но с окончательной победой Web-приложений над здравым смыслом (т.е. где-то лет 10 назад по моим субъективным наблюдениям), у разработчиков такого движка встал бы серьезный вопрос: а как все имеющиеся наработки портировать под Web? В котором на клиенте нормально живет только JS, а технологии обмена информацией между клиентом и сервером где-то на уровне каменного века? :)

Кроме как путем серьезнейшей переделки потрохов не получится, имхо. Что, как мне представляется, хорошо видно на примере MS Office, который вышел в Web относительно недавно. И где потребовалось много времени и сил на то, чтобы переиспользовать старый код в Office 365, дописав к нему новых клиентов (своих для каждой платформы).

Все так, но это скорее хорошо, чем плохо.

Любая система рано или поздно упирается в локальный максимум, из которого уже не может выбраться эволюционным путем. Интерфейсы в 80-х мало кто понимал. Отчаянное время. Но и сейчас мы далеки от конечного равновесия: никто не обещает, что через пять лет все опять кардинально не поменяется. Мы пока просто не знаем, как должны выглядеть интерфейсы, программы, да и вообще компьютеры. Делать ставку на долгую поддержку в такой период глупо — наследственность тянет через себя не только хорошие вещи, но и давно неактуальные, а также откровенно плохие. Если вы знакомы с современным Фотошопом, в этом видео видно, откуда растут уши у его многочисленных странностей: Undo по Cmd+Shift+Z, кнопки Preview в эффектах, дурацкие модальные окошки с No pixels selected. Все они прожили по 25 лет.

Чем дольше существует система, тем сильнее обостряется конфликт между новыми потребностями и грузом прошлого. Кода много, его невыгодно переадаптировать, репутация питается только былыми заслугами, программа переходит в режим доживания. Становится выгодно начать с чистого листа. Так за последние 5 лет появились легкие и современные альтернативы Адоби: Скетч, Пиксельматор. Из ниоткуда. Но их экономика понятна: полное переписывание это всегда улучшение минимум на порядок. Новые программы удобнее и актуальнее.

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

Возникает чисто практический вопрос: разве это не безумная прорва работы, сделать что-то хотя бы минимально ценное для пользователя, тот же графический пакет или текстовый редактор? Да, но это и есть проблема: так не должно быть. Нет никаких предпосылок к тому, чтобы разработка Иллюстратора была десятилетней эпопеей на миллионы человеко-часов. Просто наши инструменты несовершенны: разработчики на C++ борются с проблемами, которые присущи не предметной области, а самому инструменту. Включая размер кода, который очень быстро сам по себе становится проблемой. Фокус не в том, где взять столько усилий, сколько вбухивает Адоби. Фокус в том, чтобы делать то же самое быстрее и проще. Этому не научишься, если постоянно доделывать один монолит, поэтому даже хорошо, что GTK не натягивается на HTML. Каждый следующий виток снимает еще одну головную боль, и постепенно, раз за разом, мы придем к нужному состоянию, когда студент сможет написать базовую версию Фотошопа за летние каникулы.


Критерий разумности
усы2
tonsky
Меня в комментариях к предыдущему посту спрашивают, как определить, когда программа что-то по делу спрашивает, а когда нет. Как не проявить излишнюю инициативу и не вступить в конфликт с интересами пользователя? Не истратим ли мы ему интернет, если будем все время что-то обновлять, подкачивать, держать в курсе. Хорошо ли, что Windows сам устанавливает апдейты и перезагружается?

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

Любое движение в направлении моих желаний, моих потребностей — хорошо, это очередной маленький шажок в мир будущего, все, что нет — плохо. Перезагрузка — плохо, потому что мне не нужно перезагружать компьютер. Перезагрузка во время, когда я не сижу за компьютером — хорошо, потому что это технология обеспечивает свои потребности и не маячит у меня перед глазами. Однако нюансы: Windows, во-первых, не может нормально определить, пользуюсь я сейчас компьютером или нет, то есть может прервать мою работу, и во-вторых, она не может все вернуть ровно в том виде, в каком оно было. Она даже ворд назад с тем же файлом открыть не сможет. Хуже всего, она может _потерять_ то, что я написал, а это самый страшный грех для программ на свете. Когда перезагрузка от этих недостатков избавится, станет хорошо.

В этом смысле очень легко понять, что не так с cabal update: я не хочу ведь обновлять <что она там обновляет>, верно? Я пишу код, мне хочется писать код, а эта штука встает на пути, мешает. У меня ведь нет цели в жизни «запускать cabal update», это каприз технологии, ничего со мной общего не имеющий. Если так-то, по чесноку, даже система сборки мне не очень нужна — мне нужен код, но у меня нет задачи его собирать. Вернее даже, мне нужна работающая программа. Системы программирования будущего уберут всю эту ересь, программа будет запускаться, работать и разрабатываться в одном непрерывном процессе, как скульптор лепит скульптуру.

Конечно, мы, программисты, так привыкли, что вот оно все так работает: обо всем нужно просить, явно вызывать, дергать, соединять, настраивать и устанавливать. Руками надежнее, потому что инструменты все ненадежные и тупые — могут съесть платный трафик, забыть обновиться, стереть что-то. Нам кажется, это так и должно быть — но это все временное. Морской капитан 18 века тоже бы не согласился, что паруса и мачты не нужны. Знание Linux, владение командной строкой, API — это местечковые артефакты, всего этого не будет в светлом будущем. Компьютеры будущего будут несравнимо прямее и проще устроены, даже для программистов, с гораздо меньшим количеством ручного управления — и гораздо надежнее, потому что минус человеческий фактор. И это не в ущерб низкоуровневости, скорее она тоже упростится.

Люди не придут к компьютерам, как нам когда-то казалось. То, как мы стали «компьютерно грамотными» — ни одно поколение такого больше не повторит. Не будет дома по-особому пахнущего уголка с жужжащей черной коробкой, никто не будет обучаться Ворду и Экселю, по крайней мене не в большей степени, чем пишущей машинке. В Фейсбуке отказались от термина «пользователи», теперь это просто люди — действительно, странно называть особым словом человека, пользующегося компьютером. Мы же не называем особым словом смотрящих телевизор, или разговаривающих по смартфону. Компьютеры растворятся и придут со стороны бытовых предметов — в одном ряду с миксером, журнальным столиком и ковриком для ванной. В конечном итоге, смысл существования Windows не в том, чтобы существовал Windows. Сам по себе он никому не нужен. Так получилось, что в переходный период без него было нельзя, но не ошибайтесь, что это что-то значимое происходит.

?

Log in