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

Меня, как большого любителя разнообразных игр, всегда возмущал тот факт, что компьютерные игры в большинстве своем совсем не рассчитаны на работу с внешними сервисами. Это в том смысле, что нельзя написать такого бота к игре, (скажем, к «Квейку» или «Контр-Страйку») который бы работал на отдельном сервере и общался с игрой не посредством манипуляциями с игровыми объектами внутри игры (как сейчас делают почти все боты), а с помощью специального 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

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

https://youtu.be/DHyUYg8X31c

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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