​​Ребята, доброе утро!
В армии существует замечательный, на мой взгляд, критерий, по которому не сложно отличить хорошего бойца от плохого. Речь о выражении «я бы с ним в разведку не пошел». И ведь действительно, когда спрашивают о состоятельности боевого товарища, то критериев может быть масса, и у каждого эти критерии разнятся в зависимости от полученного опыта и достоинств. Одному важно метко ли стреляет его напарник и быстро ли он бегает. Другому важно, чтобы напарник молчал и вкусно готовил, а третьему необходимо в напарники того, кто не боится змей и умеет управлять боевым вертолетом. Пытаться составить мало-мальски универсальный список качеств и свойств бойцов, мы очень скоро скатимся в перечисление характеристик какой-нибудь RPG вроде «Фалаута» или «Скайрима». И отличить хорошего бойца от плохого будет крайне сложно.
А вот такая субъективная оценка товарища по оружию очень легко даст понять хороший ли боец вот этот вот джаваскрипт-разработчик или не очень хороший. Согласен ли ты работать в проекте, где он будет тимлидом? Можно ли ему доверить задачу, которую потом спросят с тебя?
Если оба ответа — «нет», то такого бойца нужно срочно переводить в стройбат и не подпускать с продакшену.

Ребята, технический пост.

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


В общем, предложили мне (в очередной раз) опубликовать рекламу в «Экстраполяции». Обычно в таких случаях я просто закатываю глаза к небу и отвечаю что-то вроде «нет, рекламы на канале не бывает». А в этот раз как-то настойчиво предлагали, с уверенностью, что такая реклама на канале вообще бывает. Рекламодатель сильно удивился отказу и прислал ссылку на пост с подбором различных каналов, где четко и ясно написано, что это не реклама и исключительно моё мнение. Говорит, что думал, что это «такой нейтив». Мол, купили моё мнение и рекламирую я каналы под видом независимого и неподкупного.

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

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

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

Читайте только самое лучшее, друзья!

​​Месяц назад в нашем уютном канале была статья о лакмусовых бумажках в программировании. В ней рассказывалось о неких критериях написания кода, по которым можно сказать, что что-то идет не так. Помните же? Сегодня будет еще одна лакмусовая бумажка от программирования. Очень похоже на то, что это прям целая рубрика будет. И назовем ее, скажем, «Две полоски», по аналогии со всеми известным процессом :-) В эту рубрику также принимаются ваши критерии и советы, пишите личным сообщением с пометкой #двеполоски.
Итак, критерий.

Временных решений не бывает.

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

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

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

Пишите грамотно и пусть ваши собеседники не знают о ваших лингвистических пристрастиях!

P.S. Скриншот мой, правил много.

​​Ребята, возможность эту можно найти в системных настройках, в разделе «клавиатура». Не все нашли :-)

В телеграме работа с публичными каналами кардинально отличается от привычных площадок. В ютубе, например, все блоггеры, как один, начали просить нажимать на колокольчик, чтобы мгновенно узнавать о новой публикации, новостные ресурсы начали добавлять бесячую браузерную нотификацию о новых постах. А в телеграме же с точностью до наоборот. Пользователей просят нажимать «mute», чтобы новые посты не раздражали. Даже тем, кто не убрал звук оповещений, сообщение не приходит благодаря особому тихому режиму отправки сообщений. Попробуйте отжать «mute» на недельку на канале и убедитесь сами — появится значок непрочитанного сообщения, но форсированное уведомление приходить не будет. За другие каналы ручаться не могу :-)

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

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

Я уверен, мы можем стать одним из лучших айтишных сообществ рунета. Попробуем?

​​

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

О сторипоинтах

tl;dr: Sp = t • Grade

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

#полныйаджайл

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

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

Спасибо!

​​

В эфире наша уже постоянная рубрика «Полный Аджайл» с заметками по техпроцессам разработки от читателей.

О мотивации менеджеров и коллективной стратегии

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

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

#полныйаджайл

​​Сегодня мы обсудим классическую задачу на понимание ложных убеждений (false belief task).

Ребёнку показывают двух кукол, Салли и Энн; у Салли есть корзинка, а у Энн — коробка. Ребёнок видит, как Салли кладёт свой шарик в корзинку и уходит. Пока Салли нет, озорница Энн перекладывает шарик из корзинки в свою коробку и тоже уходит. Теперь Салли возвращается. Ребёнка спрашивают: «Где Салли будет искать свой шарик»?

Совершенно очевидно, что Салли будет искать шарик в корзине, потому как наблюдателю известно, что Салли не ведает о том, что Энн перепрятала шар. И очевидно это тем, кто наблюдает за наблюдателем и видит, что он видит и какой вопрос ему задают.

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

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

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

​​#личностноеразвитие

Про повышения. Большинство наемных сотрудников считает, что руководство его заметит, оценит и повысит зарплату. Это большое заблуждение. Ни один руководитель в здравом уме не будет увеличивать расходную часть, тем самым уменьшая доходную. Если вы встречали компанию в которой происходит периодическая оценка персонала и сама компания инициирует повышения, то это заслуга HR департамента и им удалось "продать" руководству эту необходимость. Например, еще лет 5 назад, в IT был бурный рост ставок и дабы гребец не сбежал, его повышали. С тех пор ставки доросли до своего максимума, рынок немного стабилизировался.

Как же получить повышение? Ответ очевиден и прост, только вот признавать его мало кто желает... Надо показать свою ценность. Больше и усердней работать? Нет. Нужно решать задачи бизнеса. Тут возможны разные сценарии. Можно прийти с анализом, мол, такой-то процесс неэффективен, эта система работает недостаточно быстро, там затраты можно снизить, а тут можно малой кровью сделать продукт лучше. Это, безусловно, лучше чем не делать ничего или ныть о том как все плохо. У этого подхода есть недостаток: то что сотрудник считает важным, может таким не являться для руководителя. При отказе же, сотрудник демотивируется и может впасть в депрессию.

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

@noTieinIT

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

Уверен, что подавляющее большинство подписчиков канала мастерски умеют определять говнокод, особенно чужой, ведь это самый первый навык, которым овладевает разработчик в нашей профессии. Что для вас говнокод? Что такое костыль по вашему мнению? Присылайте личным сообщением мне (@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-верстальщиками.


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