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

UI в целом такой же на стороне пользователя.

Единственное, теперь на нём мерзко мерцает blank state, когда сначала показывается пустая таблица, а потом она идёт за данными, и если всё не прям шустрое-шустрое, ты успеваешь увидеть ‘You have no teams’ или там ‘Data loading’.

Других фундаментальных прорывов пользовательского интерфейса, достигнутых при помощи доминирующей технологии разработки UI, по сравнению с тем, что мы делали эпохи назад на js.haml и jQuery я пока не разглядел. Мы делали не хуже, но это было понятно.

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

Да, да, я/мы просто не умею это готовить. Старческое брюзжание.

#dimoneverything

Так, ещё одна очевидная вещь. Переписка и общение внутри команды должно быть публичными. Внутри команды, само собой. Под явное табу попадают личные переписки в мессенджерах и личные p2p письма. И, судя по опыту, мысль эта крайне непопулярная. Почти все команды, которые удалось наблюдать, используют приватные сообщения, как основной способ общения с коллегами. Созвоны — в приватных чатах, переклички там же. Обсудить, договориться, спросить. Всё в приватных чатах. А плохо это вот почему:

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

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

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

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

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

Да что вы знаете о хотфиксах?

#dimoneverything

В чате на днях разогрелась дискуссия на тему разницы между фреймворком и библиотекой. Началась она, как водится, совсем не с того, а с разницы между 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 строк кода в минуту. Именно отсюда происходит присловие — «выгоревший, как Фрилансер».

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

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