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

Давайте скажем, что IDE — это такой вот богатый и многофункциональный способ редактировать файлы и делать что-то ещё в довесок. А текстовый редактор умеет лишь редактировать файлы.

Если мы возьмём, какой-то редактор (скажем, vim) вообще без плагинов, то это очевидно будет просто текстовый редактор. Затем скажем, что если добавить к виму парочку любых плагинов, то он останется всё ещё текстовым редактором (но уже с плагинами). Если мы продолжим добавлять к нему плагины, то с каждым новым вим будет оставаться редактором, просто с ещё одним плагином. С другой стороны, найдётся такой набор плагинов (скорее всего огромный набор), когда вим по функциональности и возможностям не будет уступать своим братьям, которые точно называются IDE. Если мы удалим из такого полнофункционального вима плагин-два, то он не перестанет быть полноценным IDE, даже если такое повторим несколько раз.

Такой парадокс не работает с ортогональными понятиями и, само собой, предполагается, что любой редактор — это просто маленькая IDE и наоборот. Как-то так.

Из рабочей переписки.

«Жаль что те, кто могут управлять разработкой продукта, уже работают тестировщиками, верстальщиками и админами»

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

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

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

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

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

#перечитываяэкстраполяцию

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

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

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

#dimoneverything

Вы только представляете? Собирались лишить глаз только за то, что она робот! Это же не расизм, потому что у робота нет расы. И не феминизм, потому что у робота нет пола. Роботизм? Нам срочно надо отдельное слово какое-то для такого.

https://tjournal.ru/news/459178

По аналогии с термином «пуленепробиваемый дизайн», сформулируем «пуленепробиваемый код».

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

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

Это и есть пуленепробиваемый код.

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

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

#перечитываяэкстраполяцию

Уж не знаю как на счет прошлой заметки, с несьъедобными грибами, но эта ошибка наверняка была с последствиями.

Пора уже постоянную рубрику делать в Экстраполяции. Назовём её #продакшенхотфикс

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

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

#перечитываяэкстраполяцию

Ребята, мы тут, в рамках эксперимента, запилили приложение для слэка, которое помечает любое сообщение, как задачу. Никаких внешних сервисов, никаких зависимостей. Просто правой кнопочкой и «Create Task». Само собой, бесплатное. Отзывы и предложения можно прям в личку (@aratak).

https://slack.riter.co

Ещё один совет на одну звёздочку экспертности из десяти. Назову его «нейтральная среда разработки».

У разработчиков очень часто разнятся мнения и предпочтения и это очень хорошо. Одни любят запускать приложения в докерах, у других маки с обвешенными IDE, третьи вообще в виме через SSH на удалённом сервере код редактируют. Может ещё кто в браузере редактор запускает. А через год придумают ещё какой-то способ, который сейчас вообще тяжело предусмотреть.

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

1. Сделайте глобальный .gitignore и добавьте туда всё, что специфично для вашего конкретного компьютера. Всякие там Thumbs.db, .DS_Store, *.wsp или .rubymine.

2. Опишите в файле README.md (или даже лучше в CONTRIBUTING.md) всё то, что важно для вашего проекта. «Мы используем вот такой вот линтер и запускается он вот так», «создаётся мерж реквест вот так-то и вот в этой папочке описано что за этим следует», «Мы предпочитаем yarn, а не npm» и всякое такое.

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

4. Научитесь запускать проект без докера. Как говорит наш девопс, «запуск проекта с докером, это как без докера, только с докером». Строго говоря, полагаться нужно не только на докер-инфрастуктуру. Например, все запускаемые процессы можно описывать в ставшим уже стандартом файле ./Procfile, а не в docker-compose.yml.

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

Во многих языках есть штука, которую называют «тернарным оператором». Как правило, эта штука записывается, как 'c ? t : f'. Штука замечательная, без споров, но вот её название звучит как-то коряво.
Даже если вы не знаете латинского, то совершенно очевидно, что смысл слова «тернарный» означает «тройной», что по сути сводит смысл оператора к тому, что у этого оператора три, вместо двух аргументов. Ну, вот оператор сложения (a+b) — с двумя аргументами, но мы не называем его «бинарным оператором», так как таких операторов у нас много и совершенно непонятно о каком конкретно операторе речь. А вот тернарник у нас один, и все как-то привыкли, что «тернарный оператор» — это на самом деле «условный оператор в тернарной форме».
Это если бы в маленьком городке жил один негр по имени Степан Илларионович, а всё село его бы вместо этого называло «Негр». Потому что он у них такой один. Вот такое себе легкое проявление расизма в программировании, ребята.

#перечитываяэкстраполяцию

Хочу к вам в ваш информационный пузырь.

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

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

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

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

Всех обнял ❤️

У каких-нибудь коренных племен каких-нибудь островов какой-нибудь Новой Зеландии может быть свой язык, терминология которого в корне не совпадает с другими языками. Сам принцип построения предложений и формулировка мысли может в корне несоответствовать тому, к чему мы привыкли. Скажем, у такого племени нет понятия «лево» и «право», а ориентируются в пространстве аборигены исключительно по сторонам света. У них есть понятие «южнее» или «восточнее», а приложение-навигатор будет объяснять не относительное положение поворота, а абсолютное. «Через сто метров держитесь южнее» или как-то так. Давайте для сгущения красок этой аллегории предположим, что у этого же племени не существует вопросительных предложений, а только лишь утвердительные. И вместо вопроса, допустим, «Как пройти в библиотеку?» на этом языке канонично говорить «Ты мне должен показать дорогу в библиотеку». И, чтобы еще сильнее вас запутать, давайте скажем, что этот язык напрочь лишен местоимений и числительных. Пример с библиотекой с этим новым правилом будет звучать, как «Чака должен показать Фасимбе дорогу в библиотеку». А Чака такой в ответ «Обезьяноподобным шагом на юго-восток и потом медвежий шаг на юг».

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

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

#перечитываяэкстраполяцию

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

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

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

https://userinyerface.com/game.html

«Культура нации/сообщества сохраняет свой опыт преимущественно в форме своих национальных неврозов и табу.

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

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

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

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

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

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

#dimoneverything из интернетов

​​Если вы собираетесь выполнять проект за один присест, у вас всегда будут проблемы. Лучшее, что можно с ним сделать — это разделить его на 6 этапов, и сложить их в отделы. А когда вы распределите его на 6 этапов, вот тогда можно просить предоплату. Только не надо прятать проект в дальний ящик, чтобы начальника не напугать. А вообще я слышал, что лучший способ - это скормить работу фрилансерам. Фрилансеров надо несколько дней не кормить, а после этого они возьмутся за проект за милую душу. Но для того, чтобы заказ хорошо выполнялся, надо сперва получить ТЗ и скоординировать правки. Конечно, этим можно заняться и потом, но кому охота потом править работу из чистого альтруизма? А проект они выполнят без проблем. Для того, чтобы за раз избавиться от одного задания надо как минимум 16 субподрядчиков, по-этому остерегайтесь владельцев фиктивных компаний. Тендер стоимостью в 20 тысяч фрилансеры сожрут примерно дней за восемь. Это значит, что один фрилансер пишет около 2 строк кода в минуту. Именно отсюда происходит присловие — «выгоревший, как Фрилансер».

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

#перечитываяэкстраполяцию

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

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

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

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

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

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

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

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

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

И последнее, чем хочется поделиться, так это разрдажающим сообщением «Ну чё, как дела?» от постановщика задачи в том же чате, в котором задача и ставилась. Похоже, от этого никуда не денешься, это можно только автоматизировать 🙂

#экстрапиар