Недавно услышал термин, который подходит некоторым разработчиком куда лучше общепринятого. Старый общепринятый термин — «full stack developer» и подразумевает он тот факт, что разработчик прекрасно чувствует себя, правя html с css и оптимизируя sql-запросы. Термин этот появился достаточно давно — в те времена, когда кроме css и простенького js с клиентской стороны не было и быть не могло. А на сервере в те времена были PHP-скрипты, которые даже с натяжкой сложными называть было нельзя. В те счастливые времена найти разработчика, разбирающегося «с этими вашими красотами в браузере» и понимающего что такое индексы в базе данных было непросто и такие разработчики весьма ценились.

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

Новый термин — «hybrid developer» и подразумевает он, что разработчика можно попросить и спеть и сплясать. Такие разработчики, как гибридные автомобили — вроде бы и электрокары, но все еще с выхлопными газами и значительно дороже обычных разработчиков. Только не подумайте, что это обидный термин, вовсе нет! Гибридный автомобиль в состоянии проехать 1500 километров без дополнительной зарядки/заправки, что невозможно сделать ни на ДВС ни на батареях по отдельности. В общем, честь вам и хвала, друзья-гибдидные разработчики.

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

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

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

Выбирайте инструменты под задачи, а не подстраивайте задачи под инструмент. Удачных выходных!

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

http://drakon-editor.sourceforge.net/

Сегодня поговорим об эпохе микросервисов.

Микросервисы, как понятие утвердилось недавно по отношению к изобретению пороха или, скажем, по отношению к открытию Америки, но это было ужасно давно по меркам интернета — cобственно, всего-то четыре года назад. Давно, правда? Но сейчас уже всем даже тошнит от любого предложения так или иначе связанного с микросервисами. В домикросервисные времена большие системы тоже масштабировались и разносились на разные сервера. Отдельные части приложения обосабливались и выделялись в отдельное независимые приложения. Только вот раньше этот способ разрабатывать приложения считался обычной эволюцией приложения, а сейчас это микросервисы и архитектуру приложения многие ошибочно начинают с планировки микросервисов. На волне работы с микросервисами многие команды поддались тренду и начали распиливать свои приложения на отдельные независимые части, что лишь усложнило дальнейшую разработку. Например, команда gitlab сначала предприняла попытку вычленить свой сервис непрерывного тестирования в отдельный «микросервис», но вовремя поняв свою ошибку объединила два отдельных приложения назад в одно. И стало только лучше.

А последние пару лет эволюция микросервисов взяла новую веху своего развития. Теперь микросервисы живут отдельными приложениями где-то там, в интернете. И разрабатываемое приложение использует API-приложения третьих лиц для решения своих проблем. И речь даже не о сервисе сохранения фотографий в облаке Амазона и не о нейросетях-как-сервис -- тут-то понятны мотивы и способы монетизации. Речь об обычной функциональности, которую раньше писали сами и мысли не было платить за это, как за отдельный сервис. Сервис определения города по IP-адресу, сервис по отправке емейлов через API, сервис по индексации страниц, сервис по генерации фавиконки… Тысячи их!
И никакого вывода из вышеперечисленного не будет. Можно было бы посоветовать взвешивать риски использования сторонних продуктов, но вы же и так это делаете. А в качестве компенсации отсуствия выводов — ссылка на «awesome» список сервисов, с бесплатным доступом: https://github.com/ripienaar/free-for-dev

Продуктивного дня!

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

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

В полку джаваскриптовых сборщиков прибыло. В этот раз -- библиотека от фейсбуков. Горшочек, не вари.
https://yarnpkg.com/

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

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

Компания «Близард» вот делает серьезный шаг в эту сторону. «Старкрафт» — это вам не «Го». https://deepmind.com/blog/deepmind-and-blizzard-release-starcraft-ii-ai-research-environment/

Хороших выходных!

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

http://telegra.ph/%D0%9A%D0%B0%D0%BA-%D0%B2%D1%8B%D0%B1%D0%B8%D1%80%D0%B0%D1%82%D1%8C-%D0%B0%D1%80%D0%B1%D1%83%D0%B7%D1%8B-11-25

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

http://www.cs.bham.ac.uk/~axj/pub/papers/lambda-calculus.pdf
http://www.cse.chalmers.se/~rjmh/Papers/whyfp.pdf

Хороших выходных!

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

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

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

Хорошего вечера!

Доброго утра, друзья! На новогодние праздники получилось собрать всю волю в кулак и сформулировать мысли об эволюционном подходе к разработке продуктов.
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