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

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

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

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

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

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

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

Хорошим решением было бы использование готовых библиотек и не выделываться, как и поступает большинство проектов. Мы пошли пути 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/). Программирования там мало, потому как оно все тут сосредоточено. А вот непрограммирование в экстраполяцию не попадает, а попадает все туда.

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

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

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

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

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

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

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

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

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

Основной принцип все же соблюдается — необходимо думать на несколько ходов вперёд.

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

Сообщество стонет, сообщество пытается решить проблему, как умеет. И тут-то и начинается жесть.

Дело в том, что современные верстальщики очень быстро учатся программировать (и это очень хорошо) и пытаются решать проблемы вёрстки патернами программирования. Это когда:

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

— Начинают использовать css-фреймворки. Ничего не меняется, а редактировать стили фреймворков ещё страшнее.

— Ищут спасения в генерации стилей всякими sass или less. Становится неочевидно хуже, ведь писать приходится меньше букв, а код все так же страшно менять.

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

Расскажите мне, дорогие друзья, как вы боретесь с постоянно растущей и пухнущей таблицей стилей. Лучше всего личным сообщением (@aratak) и с хештегом, чтобы не потерять (#cssэкстраполяция). Мне очень интересно и, уверен, многим тоже.