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

Уверен, что подавляющее большинство подписчиков канала мастерски умеют определять говнокод, особенно чужой, ведь это самый первый навык, которым овладевает разработчик в нашей профессии. Что для вас говнокод? Что такое костыль по вашему мнению? Присылайте личным сообщением мне (@aratak) с пометкой #айтермин ваше определение этих замечательных определений.

Свою версию вместе с вашими присланными можно будет почитать по тегу ближайшие недели.

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

Вообще, процесс бекапа не так интересен, как процесс восстановления из бекапа. Поэтому постановка вопроса «делаете ли бекапы» в корне не верен. Правильный вопрос: «Умеете ли вы восстанавливать из бекапов?».

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

​​Короткие новости по рубрике #айтермин

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

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

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

Если вам есть что сказать по этой теме, пишите личным сообщением мне (@aratak) с пометкой тегом.

Продолжение следует!

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

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

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

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

#айтермин

​​Сегодня, на правах субботнего вечернего поста, хочу высказать свое «фи» современному ИИ. До человеческих способностей ему еще ой как далеко :-)

​​Лайвхаки от экстраполяции.

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

Самая, на мой взгляд, удобная функция на кнопке caps lock — переключение языков. В старых системах это решалось сторонними программами, где на уровне драйверов клавиатуры клавиша caps lock вдруг становилась какой-нибудь клавишей 'f15', но в последних версиях операционной системы это работать перестало.

Вместо этого появилась встроенная в систему возможность переключать язык по капслоку. Прелесть будет состоять в том, что можно оставить старое-доброе 'cmd+space' для переключения и в дополнение к нему — 'caps lock'. И плавно привыкать к капслоку.

Разработчик должен многое уметь и многое знать, постоянно развиваться. И именно поэтому фронтенд-девелопера стоит переименовать в простого джаваскрипт-разработчика, и ни в коем случае не в react/angular-разработчика. Еще стоит отличать javascript-разработчика от typescript-разработчика, а от elm-разработчика не требовать знать coffeescript. Само собой, разработчик может знать несколько языков, тогда он будет гордо носить титулы, например, typescript-разработчика и elm-разработчика одновременно.

Конечно, тенденции серверной разработки говорят нам, что вполне успешно могут существовать scala-разработчики, которые вообще не умеют писать на java или elixir-разработчики, которые ни в зуб ногой в erlang. И это нормально.

Теперь ограничим это множество с другой стороны. Инструментарных разработчиков, вне зависимости от вероисповедания, вроде django-разработчиков, rails-разработчиками и angular-разработчиками нужно отправлять куда-нибудь учиться, а не программировать. Вместе под руку с операторами фотошопа, администраторов mysql и css-верстальщиками.


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

​​Проклятые кастомные селекты.

Когда дизайн требует чего-то этакого от инпутов, верстальщики приседают в шпагате и делают довольно сумасшедшие вещи, типа картинки внутри инпута, но оставляют тег <input>. Но если появляются стили для выпадающего списка, тег <select> и его друзья <option> отправляются на помойку и вылезают <div> и джаваскрипт. Ну не пускают браузеры даже в распоследнем html/css кастомизировать селекты. Как же это печалит!

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

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

К слову, когда браузеры были еще маленькими, эксплорер только мечтал о седьмой версии и хрома вообще не существовало, селекты были еще более независимыми. Некоторые браузеры, видимо в силу каких-то внутренних ограничений, отказывались реализовывать выпадающие списки стандартными способами и в ход шли костыли. Такие топорные дубовые неотшлифованные тяжелые костыли. Никакой речи о дополнительных стилях к селекту вообще не шло, там проблемы были намного серьезнее. Например, никакой див с абсолютным позиционированием и с увеличенным z-индексом не мог быть выше селект-инпута просто потому, что выпадающий список не являлся частью документа. Все селекты рендерились отдельно от всего документа и, собственно, поверх документа. Если вдруг хотелось сделать что-то вроде модального окна, то дополнительным джаваскриптом, при открытии любого модального див-элемента, всем выпадающим спискам на странице делался ниндзя-прием в виде 'visibility: hidden'. Еще можно было заметить на тормозящих компьютерах, что расчет позиции селекта на странице слегка отставал при скроллировании страницы. Селект немного позже рассчитывал свою позицию, чем это делала сама страница и перемещался с легким запозданием.

Очень хороший пример костыля в рубрику #айтермин.

​​

 Дополнение к прошлому посту.
Короче, картинок было две — логотип рубрики и иллюстрация к тексту. Опубликовалась один логотип. По всей видимости, добавить две картинки к посту нельзя. Исправляюсь отдельным постом.

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

Сейчас пишу кастомные селекты.

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

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

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

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

Количество поздравлений с наступившим годом от телеграм-каналов просто умопомрачительное. Читать я их перестал где-то после третьего. А «Экстраполяция» от большинства каналов отличается тем, что очень любит и ценит вас, чтобы по-просту спамить бесполезным сообщениями или рекламой, например.

Так что, во-первых с Новым Годом вас, друзья мои. 🎄

А во-вторых — полезная ссылка. Можно сказать, свежачок с анализом современного джаваскрипта, сделанного на основе опроса разработчиков.

«Джаваскрипт ты можешь не любить, но уважать его обязан», как сказал классик.

https://medium.freecodecamp.org/i-just-asked-23-000-developers-what-they-think-of-javascript-heres-what-i-learned-9a06b61998fa

Лайвхаки от Экстраполяции

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

Так вот, под Макось существует два официальных клиента. Один ужасный кросплатформенный монстр. А второй — нативный красавец. Почему-то подавляющее большинство знакомых ставят себе кросплатформенного уродца, вместо быстрого и симпатичного удальца. Удаляйте чудище и ставьте себе принцессу: https://macos.telegram.org/

Под Айос официальных клиентов тоже два, но тут оба красавца. Приложение, которое ставят себе подавляющее большинство владельцев айфонов, безусловно на порядок лучше любых вайберов, скайпов и ватсапов, но по сравнению с «Telegram X» слегка медленновато и не имеет ночной темы. Качайте: https://itunes.apple.com/ru/app/telegram-x/id898228810?mt=8

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

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

Ну не даются новостные заметки Экстраполяции, что тут поделаешь! Стоит отложить пост на пару дней, так уже старье, боян и уже неправда. Может, пригласить внештатного редактора для новостных заметок (🗣) или ну их к чертям, эти новости (😈)?

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

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

Так же периодически будут всплывать рубрики «Полный аджайл» (#полныйаджайл), «Лайвхаки от Экстраполяции» (эта рубрика еще без тега, поэтому давайте новый сделаем: #экстрахак). И есть еще одна рубрика с дурацким названием «Айтермин» (#айтермин). Если вам есть что сказать по этому поводу, присылайте мне личным сообщением (@aratak) ваши мысли с соответствующим хештегом. По указанному хештегу я потом смогу эти ваши мысли найти и не забыть опубликовать.

Ну, и в конце у меня к вам серьезная просьба. Один из проектов, над которым я работаю, уже достаточно хорош, чтобы добавить его в producthunt.com. Так мы и сделали и мне нужна ваша помощь. Нужно проголосовать за проект по ключевому слову «riter» на продактханте. Ссылки не даю, сами понимаете, это же продактхант. Буду вам очень признателен.

Мне тут подсказывают, что ограничения на ссылки на продактханте уже нет. Поэтому вот ссылка: https://www.producthunt.com/posts/riter

Но вы все-равно не кликайте, а скопируйте и вставьте :-) Спасибо!

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

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

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

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

И опять о художественной литературе. О фантастике.

В этом жанре ярче других выражена градация и разделения общества на разные классы, уровни и привилегии. Фракции в «Дивергенте», рационалы, эмоционалы и пестуны из «Сами Боги», специализации в «Геноме», уровни магов и стороны света в «Дозорах». В жизни такого встретить не часто получается, а вот писатели могут проводить четкие границы сколько им вздумается. Компьютерные игры все, как один, идут туда же. Уровни исчисляются целым положительным индексом, урон — единицами, а защита — поглощенным уроном. Не то чтобы это как-то плохо было, просто желание описать систему до ее появления неизбежно выливается в необходимость четких категорий и градаций.

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

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

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