Появилось новое слово в лексиконе: «bulk-approve».

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

#dimoneverything

​​Эйнштейн помогает с пулл реквестом.

Задачи, о которых просят пользователи.

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

Есть две крайности, ударяться в которые будет очень плохо.

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

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

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

90% кодревью на практике неотличимы от code-style тестов, которое вроде бы должен делать CI. В смысле, замечания, которые люди пишут в пулл-реквесты, такие же, как должен был бы написать сильно продвинутый CI. Мол, а тесты где? А тесты твои не тестят нифига — ты попробуй, код свой удали, и посмотри, проходят? Да, проходят. Вот и выкинь свои моки. Отступы поправь. Английский выучи, индус, прежде, чем многострочные комменты писать — тут the надо. Метод приватным сделай. В раутах весь ресурс не открывай. И индекс на поле поставь.

Понятное дело, что кодревью должен быть другим, но речь тут о практике, а не о теории.

#dimoneverything

Ещё одна #экстравакансия, на этот раз ищу я и ищу фронтендера с большой буквы Ф в продуктовую разработку.

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

Работа будет удаленная, само собой, но увидеться и поработать вместе недельку-другую можно будет в Киеве. Пишите мне в личку (@aratak) и отправляйте это сообщение знакомым джаваскриптизёрам. Спасибо.

Ребята, я читал и плакал. Дмитрий, в рамках тега #dimoneverything решил попробовать слегка по-другому мысли свои передать и у него это получилось просто превосходно.

https://telegra.ph/Full-stek-matros-08-29

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

https://hackodessa.photolab.me/

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

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

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

Во, и название придумалось, «Метод второй производной». Как вам?

В этом году я не достаточно крут, чтобы выступать на конференции, но конференция от этого хуже точно не становится.

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

http://bit.ly/2lM3jPP

P.S. Скидка в 10 процентов по коду extrapolation.

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

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

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

#dimoneverything

Центр вселенной и пуп мира.

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

Более приближенный к интернету пример: составить психологическую картину личности со всеми его мыслями, тайными желаниями, сексуальными потребностями и насущными проблемами можно лишь по ретвитам и репостам. Далеко не все способны красиво и четко сформулировать свою мысль или желание, а вот прочитать чужую и согласиться с ней - пожалуйста. Итого мы имеем одну четко и ясно сформулированную мысль и группу пользователей, которые с ней согласны. И не просто согласны, а согласны до такой степени, что будь они чуточку образованнее и собранней, это была бы их мысль. Социальные сети с возможностью репоста стали чем-то вроде хаотично разбросанных мыслей в виде ленты сообщений от твоих "друзей". Мысли генерировать в состоянии лишь единицы, тысячи же лишь могут пропустить мысль через сито своего восприятия и получить на выходе соответствие или отвергнуть ее, как непонятую, не соответствующую своим мыслям. Кстати, именно поэтому сервисы, требующие от пользователя выдавать необходимую единицу смысла менее популярны сервисов, где основным средством самовыражения есть возможность лаконично изъяснить свои мысли за счет чужого умения красиво эти самые мысли формулировать. Наугад взятый фолловер из твиттера, на 50 процентов состоит из ретвитов, на 25 процентов из публикаций сервисов а-ля "мне понравилось видео на ютубе" или "я на автостанции 'Южный' стал майором", еще на двадцать - из ответов на другие такие де твиты. И именно львиная доля этих сообщений и есть тот набор мыслей, который мог бы быть авторским при других обстоятельствах. Действительно ли представленный индивидуум настолько умен и интересен, как он заявляет о себе с помощью набора чужих мыслей? Вспоминается история в которой начинающий дизайнер в резюме прикреплял работы известных дизайн-студий, мотивируя это тем, что он тоже так может.

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

Осознание своего собственного 'я' и, как следствие, своего собственного мнения делает убежденность в объективности своего мнения непоколебимым. Любой диалог и процесс обмена информацией между двумя индивидуумами сводится к формированию и в последствии убеждения собеседника в объективности своего субъективного мнения. Объективности не существует. Точно так, как не существует Вселенского Разума или жизни вне биологической или какой-нибудь другой оболочки. Существуют только множество проекций реальности через эгоцентричное осознание индивидуумов.

И будучи одним из таких индивидуумов, я даже не уверен, что мир вокруг не есть плодом моего воображения.

Сервисы и микросервисы.

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

А вот с микросервисом немного сложнее. В подавляющем большинстве случаев микросервисная архитектура — вынужденное решение, когда монолитное приложение распухло и мешает ходить. На микросервисы переходят, усиленно рефакторя и деребеня существующее приложение, состоящего из одного большого куска кода. Само собой, что в этом самом куске кода всё настолько переплетено, что потянуть за нить и не запутать клубок практически невозможно. В итоге микросервисы получаются сильно связные, а данные одного являются неотъемлемой частью второго. Короче, без микросервисов было бы лучше и с монолитом отлично живётся.

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

Есть фраза-паразит, которая даёт понять, что автор вообще не разбирается в вопросе и понятия не имеет о чем говорит. На самом деле таких фраз несколько и есть одна самая бесячая среди этих фраз. Это фраза «на самом деле».

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

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

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

В общем, удачных аналогий не существует. Аналогия либо неудачная либо не аналогия.

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

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

Здесь очень важны опасные слова "на самом деле". Если вы скажете, что всякая дружба осознанно гомосексуальна, все поймут, что это ложь. Если вы спрячетесь за вышеприведенными словами, получится, что друзья и сами ничего не знают об ее истинной сути. Это уже нельзя ни доказать, ни опровергнуть. Само отсутствие свидетельств окажется свидетельством. Дыма нет – значит, огонь хорошо скрыли. Конечно, если огонь вообще есть. С таким же правом можно сказать: "Если бы в кресле лежала невидимая кошка, оно казалось бы пустым. Оно пустым кажется. Следовательно, в нем лежит невидимая кошка"»

Клайв Льюис, «Любовь».

#dimoneverything

«Студентов, ранее изучавших Бейсик, практически невозможно обучить хорошему программированию. Как потенциальные программисты они подверглись необратимой умственной деградации».
Эдсгер Вибе Дейкстра.

Минутка ностальгии.

Много лет назад моим окном в тот мир, частью которого я отчаянно хотел стать, был журнал Ксакеп (Xakep). Я читал его весь, частенько один номер по несколько раз. И в этом журнале была юмористическая рубрика, которую вёл Даниил Шеповалов. Даня этот гнал чернуху со страшной силой, и в том возрасте это было очень свежо и весело.

Так вот, в одном из вопросов там была очень забавная шутка.

«Через пять лет я удочерю 17-летнюю девочку из сиротского приюта и на практике покажу ей, почему "жизнь - дерьмо!" и "все мужики - козлы!". Ну а после удовлетворения всех своих извращенных фантазий, естественно, продам ее в рабство на плантации сахарного тростника. ("Слово "дерьмо" возможно является бранным выражением и его употребление в литературном языке нежелательно", - вот что выдал Ворд, подчеркнув красной волнистой линией это чудесное существительное. "Какое же все-таки счастье, что программы пока что не умеют проверять смысловую нагрузку текста", - подумал Даня)

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

Я сейчас отправил пулл-реквест, на который код-климат сказал мне, что у меня там новые проблемы в коде. Проблемами являлось то, что я не написал .freeze после объявления константы, несколько строк написал в двойных, а не в одинарных кавычках и одной строкой превысил 80 символов.

То же самое он говорит и другим ребятам, и мы дружно шлём туда всякое дерьмо («слово "дерьмо" возможно является бранным выражением и его употребление в литературном языке нежелательно»), но везде написано .freeze, кавычки одинарные и строки короткие. В коде всё по смыслу, как в текстах Шеповалова и групповуха немощи по Петровичу, и одно и тоже, сделанное пятью разными способами в разных местах, и тыща sql-запросов на один http request...

Но код-климат бдительно запрещает разработчикам использовать в текстах слово «дерьмо».

Ну хоть что-то у нас в безопасности.

#dimoneverything

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

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

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

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

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

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