Помните идиому с наточкой топора и вырубкой леса? Ну, в которой абстрактному разработчику некогда наточить топор, потому что лес рубить надо. Тут есть и обратная сторона этой проблемы — преждевременная наточка топора. Топор нужно точить, когда будет точно понятно, что затраты на заточку топора будут окупаться скоростью вырубки леса. А для этого нужно:

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

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

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

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

#экстрапиар от подписчиков, ребята. И начнём мы с очень крутого проекта.

https://github.com/pathephone/pathephone-desktop

Это p2p музыкальный проигрыватель. Использует IPFS для создания распределенного пространства данных. Удивительно очевидный и вообще неуникальный проект. Но вместе с этим это гениальное применение распределённых технологий.

Автор говорит, что этот проект является одновременно и хобби-проектом и демкой для собеседований.

Мне кажется, проект как минимум заслуживает звездочку. А кроме использования по назначению, проект можно улучшать, общаясь в issue-секции и отправляя пулл реквесты.

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

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


Или есть совершенно капитанская мысль о том, что простое делать просто, сложное делать сложно. Гениальная мысль, правда? Смысл в том, что если вы решили сложно сделать простое, то вы зря усложняете. Если же вы сложное решили сделать просто, значит вы просто не поняли задачу. Возникает сразу куча разных возражений, вроде рефакторинга, унаследованного кода, некомпетентных управленцев и тупых пользователей из-за которых мысль так и остается недоформулированной. И писал я заметку об этом уже раза три и все три раза удалял сразу после прочтения. Один раз даже пытался привязать эту проблему к проблеме «P NP», мол сложность формулировки задачи сопоставима со сложностью решения. Но там тоже корабль доводов и аллегорий разбивался о скалы непонимания и исключений из правил просто в труху.

Мысли вроде бы хорошие, но вряд ли появятся на канале.

Игры в рубрике #экстрапиар.

Мултиплеерная игра на Phaser.js: https://github.com/DmytroVasin/bomber
Автор говорит, что ничего сложного в ней нет, но было интересно потыкать в браузерные игры. А еще он обещал добавить ботов, чтобы можно было бы оценить игру и самому. Но уверен, что ближайшие пару часов после заметки будет возможность поиграть и без ботов.

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

https://dev.to/riter/sql-tests-in-your-smart-framework-48ob

#экстрапиар об работе над несколькими проектами

Одной из самых полезных штук в работе над несколькими проектами сразу — общие и одинаковые задачи.

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

А у нас некоторое время назад стала задача о работе с картинками причём в довольно объемно. Один из унаследованных проектов имел одиннадцать разных версий одной и той же картинки (ну, там маленькая, большая, с вотермаркой, черно-белая, размытая и всякое такое) и всего таких картинок было порядка надцати миллионов. Задача была поменять три версии картинки и добавить ещё две. Лежало это добро, как полагается на амазоне со всеми вытекающими отсюда последствиями.

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

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

При таком подходе, помимо проблем разработки, были ещё проблемы администрирования: бекапить внезапно нужно ещё и файлы, виртуализация внезапно становилась не до конца изолированной. Хотелось это делать как можно реже.

Хорошим решением было бы использование готовых библиотек и не выделываться, как и поступает большинство проектов. Мы пошли пути dragonfly стандарта и собственного сервиса и правильно сделали.

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

Когда мы делали сервис публичным, мы позаботились о том, чтобы его можно было безболезненно мигрировать туда и оттуда, поставить на сервера клиента, если так хочется и безопасно грузить картинки прям из браузера в сервис, минуя запрос от одного сервера к другому. В остальных приложениях удалили вообще все, что связано с загрузкой файлов, чем сильно облегчили им жизнь. Ещё сделали необходимое API, куда ж без него.

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

Хе-хе, сервис расхвалил, а ссылку-то оставить забыл. Пиарщик из меня тот ещё.

https://vault8.io

Завтра-послезавтра (14-15 октября) в Днепре будет проходить крупная конференция, на которой я выступаю. Доклад мой назначен на понедельник, но на конференции я планирую быть оба дня. Рассказывать буду о том, как организовать процесс разработки без отдельного стейджинга с красивым названием «Бесшовное тестирование» или как-то так. Хотите увидеться — пишите мне личным сообщением. Буду рад видеть всех.

Что мы все о программировании да о программировании? Давайте в этот раз просто подумаем и поможем ста мудрецам спастить от неминуемой гибели от рук палача.

Итак, все сто мудрецов выстроены в одну колонну (каждый видит тех и только тех, кто стоит перед ним), и на головы им будут надеты шляпы одного из k > 0 цветов, выбранных независимо и случайным образом. Каждый из мудрецов в колонне, начиная с последнего, должен будет либо назвать цвет своей шляпы, либо сказать «пас».

Мудрецы считаются прошедшими тест, если хотя бы один из них назовёт цвет верно и не будет никого, кто назвал цвет неверно.

Вопрос: как должны договориться мудрецы между собой до испытания, чтобы максимизировать вероятность успеха? И какова эта вероятность? Естественно, нельзя ориентироваться ни на какие дополнительные данные, вроде высоты голоса ранее ответивших, интервал времени перед ответом и тому подобное. Решаем честно.

Для случая k = 1 всё достаточно просто: если известно, что шляпы бывают только одного цвета, то именно его надо называть. С вероятностью 100% ответ будет правильным, поэтому мудрецы пройдут тест.

Чем хороша эта задача? А тем, что кажется, что она не имеет разумного решения. Судите сами: первый отвечающий, который видит перед собой 99 шляп, ничего не знает о цвете своей шляпы. Поэтому он, не имея права назвать какой-то цвет (если назовёт, то с вероятностью 1-1/k все проиграют), вынужден сказать «пас». Но у второго совершенно такая же ситуация: он видит перед собой 98 шляп, он заранее знал, что первый скажет «пас», поэтому он тоже вынужден говорить «пас». И так далее. Возникает иллюзия, что выиграть невозможно. И тем интереснее догадаться, как же действовать мудрецам.

Ниже поста кнопочка с комментариями, предлагаю обсуждать там. Если попрёт — будут еще. #экстраразминка

Три добродетели разработчиков: способность структурировать информацию, умение делать логические выводы и третье не помню. Вероятно, забывчивость.

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

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

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

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

Предложение переписать все нахрен ни в каких случаях недопустимо от человека только что присоединившегося к проекту.

Наверное, вы заметили, что последнее время постов в «Экстраполяцию» было не так уж и много. И этому есть банальная причина. Модная клавиатура макбука последнего ведет себя неподобающе и некоторые кнопки требуют особого внимания, из-за чего печатать банально нет никакого желания. Предыдущий пост я вообще писал с телефона, представляете? Официальные сервисы даже готовы поменять клавиатуру на такую же по гарантии, но быть «минимум три недели» без рабочего иструмента я, наверное, не готов.

Че делать-то? Есть какие-нибудь идеи? Буду рад услышать ваших советов личным сообщением (@aratak). Нахожусь я в Киеве, если что, советы актуальны для него.

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

https://goo.gl/forms/2u4qAm2Vm9veal7i1

Клавиатура все еще не вызывает желания печатать, поэтому копипаста от автора в рубрику #экстрапиар.

Лично я работаю с эрлангом через эликсир, но вообще не работаю с джавой (или явой?), поэтому до конца крутость этой библиотеки оценить не могу. Я точно знаю, что среди нас есть такие ребята, которым близки оба этих мира и было бы круто услышать их мнения об этой библиотеке. Она крутая? Велосипед? Пишите мне в личку, а там сделаем пост с опровержением или подтверждением если что.

—
Пишу библиотеку и всё сопутствующее для комфортной работы из JVM с Erlang/Elixir. Для работы используется протокол Erlang Distribution Protocol.

В отличии от Ericson’кого jinterface более дружелюбный API, есть полезняшки из разряда POJO serialization/deserialization, Spring Boot starter, куча утилит, ну и главная фича, ради которой это всё и делалось — под капотам юзаю Netty, а нетормозного jinterface.

ссылка на проект:
https://appulse.io
—

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

Вот вам еще один клевый термин с этим словом: «Презумпция калофикации». Ну, это когда код говно уже заранее, когда еще не открывал его. И попробуй-ка доказать обратное.

— Чем занимаешься сейчас?
— Занимаю сейчас своим проектом
— А каким? Расскажи, интересно.
— Сейчас не могу ничего рассказать, потом все увидишь.

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

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

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

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

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

Нашел и прислал ссылку Андрей, тот самый, который рассказывал о его опыте работы с «проклятыми кастомными селектами» в «Экстраполяции».

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

https://www.psychologytoday.com/us/blog/ulterior-motives/200905/if-you-want-succeed-don-t-tell-anyone

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

Собеседуя матёрых разработчиков, нет смысла докапываться до того, знают ли они принципы сортировки данных, разбираются ли они в красно-черных деревьях или любое другое выводимое или табличное знание. Считается, что умудренный опытом разработчик либо досконально знает такие штуки либо уже пару раз их успел забыть. И если забыл, то ему ничего не стоит это вспомнить с интернетом под рукой. Значительно важнее как такие разработчики себя ведут в диалогах на переговорах, дискуссиях или митапах. Очень важно как они умеют рассказывать о своих знаниях, как они могут объяснить какую-то сложную штуку коллеге или донести свою мысль аудитории. Тестовое задание (или скорее просто собеседование) должно это хорошо демонстрировать.

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

Ума не приложу что конкретно проверяет тестовое задание «сделайте мне чятик на рельсах», которое выдается опытному разработчику и «расскажите какая сложность нахождения значения в ассоциативном массиве» для джунов.

Ребята, среди нас же есть проектные и продуктовые менеджеры, сейлзы? А какие вы ресурсы читаете? Ну, там бложики, каналы в телеграме, соцсети каких-то личностей особых. Скиньте личным сообщением мне (@aratak), пожалуйста.

Ребята, экстраполяция, конечно, экстраполяцией, она никуда не делась и все по-старому. Но я буду рад вас видеть еще и в соцсетях в традиционном смысле этого слова. Например, в фейсбуке (https://www.facebook.com/alexey.osipenko) или в инстаграм (https://www.instagram.com/aratak/). Программирования там мало, потому как оно все тут сосредоточено. А вот непрограммирование в экстраполяцию не попадает, а попадает все туда.

В общем, добро пожаловать.

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

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