Доброго утра, друзья! На новогодние праздники получилось собрать всю волю в кулак и сформулировать мысли об эволюционном подходе к разработке продуктов.
http://telegra.ph/Эволюция-и-аджайл-01-03

Делимся хорошими репозиториями.

Джаваскрипт не является самым-самым языком вселенной и все такое, хотя в нескольких номинациях он безусловный лидер. Одна из таких вот номинаций — «самый неоднозначный язык». В ней джаваскрипт на несколько корпусов оторвался от всех остальных.

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

https://github.com/ryanmcdermott/clean-code-javascript

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

http://atpaino.com/dtc.html

Сахар, соль и уксус в программировании.

Полвека назад был придуман термин «синтаксический сахар», который я уверен не нуждается в каком-либо дополнительном представлении. Только вот изначально термин представлял собой нечто такое, что никак не изменяло базовый набор возможностей, а только лишь упрощал работу. Допустим, конструкция +=, вместо обычного a = a + x. Синтаксическая соль, как настоящий антагонист, должен был усложнять жизнь разработчикам в тех местах, где легко ошибиться. Самая простая демонстрация соленого правила написания — обязательная точка с запятой в конце каждой операции. Считалось, что таким образом разработчик будет допускать значительно меньше авто-ошибок.

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

Сахар и соль — не две противоположности, а ортогональные понятия. Соль в слабой концентрации значительно полезней сахара в больших количествах. И «синтаксический уксус» — гиперболизация сахара, а не соли.

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

http://telegra.ph/V-Ispanii-vse-razrabotchiki--senory-02-01

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

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

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

https://www.theguardian.com/technology/2017/jan/27/ai-artificial-intelligence-watchdog-needed-to-prevent-discriminatory-automated-decisions

Синтаксический сахар, соль и уксус. Часть 2.

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

Приготовления же блюда имеет вполне четкий алгоритм и структуру. Отклонение от норм приготовления приложения чревато тем, что в итоге получается совсем не то что задумывалось изначально по рецепту. Особенно, если повар начинает поощрять пользователей и потакать им в их прихотях. (Я сказал «приложения»? Конечно же имел в виду «блюда»!) И конечно же разумной стратегией разработчиков будет изменение приложения с выверенной точностью, создатели должны поощрять те действия пользователя, которые считаются правильными. Назовём это «интерфейсным сахаром».

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

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

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

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

Превосходное эссе на тему преимущества различных концепций в программировании.

http://tonsky.livejournal.com/308320.html (пару минут чтения)

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

http://telegra.ph/Gvozdi-mikroskopy-i-lyubov-k-peremenam-02-23

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

https://youtu.be/DHyUYg8X31c

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

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

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

👆🖕🤘✋✌️☝️ вам друзья!

http://blog.jonnew.com/posts/poo-dot-length-equals-two

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

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

Вот карта: https://goo.gl/V2hJT5

Карту можно свободно редактировать, достаточно быть в своем гугл аккаунте. Добавьте, пожалуйста, места, в которых вы работали/работаете.

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

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

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

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

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

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

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

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

В переписке важно соблюдать некие нормы, при котором читающему ваши тексты не хотелось бы выколоть себе глаза. В переписке к современным полноцветным смайликам должны применяться все правила, которые применяются к обычным картинкам все в той же переписке. Давайте рассмотрим все случаи:
- в деловой переписке использовать категорически нельзя.
- в публичных переписках использовать нельзя.
- в личной переписке использовать можно, только крайне осторожно. Супруге можно «❤️» отправить. Или одногруппнику — «🍺».

К стикерам в чатах применимы точно те же правила, так как это все те же картинки.

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

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

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

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

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

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

Как правильно заниматься самолечением такого синдрома:
1. Перестать возмущаться
2. Сформулировать насущную проблему.
3. Задавать вопросы «А почему именно так?»

Не болейте!