Предупреждение: возможно уменьшение удовольствия от игр и фильмов, так как появится осознание и понимание как они устроены.

Как-то захотелось мне сделать игру и у меня возникли вопросы.
Почему мы играем? Из-за каких элементов игры мы получаем фан?

Далее, под словом «фан», имеется ввиду положительные эмоции.

Поиск в интернете точного ответа не дал. Кто-то пишет, что игрокам нравится делать то, что в реальном мире они не могут. Другие пишут, что важен сюжет. По таким описаниям хорошую игру не сделать.

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

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

Проделав этот эксперимент с играми в которые я играл, получился такой набор базовых элементов:

Почти все светодиодные лампы, которые можно купить на Aliexpress, очень плохие: у многих недопустимая пульсация света, низкий индекс цветопередачи, зачастую реальная мощность и световой поток в пять раз меньше обещанных. Я уже был уверен, что на Али хороших ламп нет вообще, но исключение всё же нашлось.

В середине 2018 года мы на «Моём круге» запустили сервис оценки работодателей, с помощью которого каждый сможет узнать, что думают о компании как о работодателе её сотрудники. И сегодня рады представить первый ежегодный рейтинг компаний «Лучшие работодатели в ИТ 2018, по версии «Моего круга». Этот рейтинг мы хотим сделать доброй традицией и выпускать ежегодно.

С момента запуска сервиса порядка 5000 сотрудников поставили свои оценки более чем 900 компаниям. В итоге, на данный момент публичную оценку получили 150 компаний, собравших мнения о себе от 10 и более сотрудников. Именно эти компании и стали участниками нашего нынешнего рейтинга.

Сотрудники оценивают своих работодателей по 12 качествам, по каждому ставят оценку от 1 (полностью не согласен) до 5 (полностью согласен). Из оценок сотрудников вычисляется средняя оценка каждого качества (как среднее взвешенное), а из оценок качеств — средняя оценка компании в целом (как среднее арифметическое). Эти средние оценки компании в целом мы и сравниваем, чтобы построить рейтинг. Подробнее о системе оценок и правилах их расчёта.

Ещё мы сравниваем оценки компаний по каждому из 12 качеств, и если компания вошла в тройку лидеров по данному качеству, мы присваиваем ей соответствующую номинацию.

Компании в рейтинге соревнуются в 4 «весовых» категориях:

• Огромные компании (xbig). Для компаний численностью более 5000 сотрудников, «нормальной» (средней медианной) является оценка 3.6.
• Большие компании (big). Для компаний от 1000 до 5000 сотрудников — 4.2.
• Средние компании (medium). Для компаний от 100 до 1000 сотрудников — 4.5
• Небольшие компании (small). Для компаний от 10 до 100 сотрудников — 4.6.

Однажды в моей команде был настолько слабый парень, что его собирались уволить (уволить разработчика!). Каждый мой коммент на ревью к его коду был гвоздем в крышку гроба. Я почти слышал стук молотка, нажимая «submit review». Он был приятным человеком, я даже переживал за него, но это не мешало мне разносить его старания в щепки. Мое право критиковать его работу казалось очевидным и неотъемлемым. Все просто — я сильнее, я прав. Никто же не хочет сказать, что плохой код — это хорошо, а? Его уволили, предварительно лишая стандартной премии в течение нескольких месяцев.

Я говорил себе: «Но ведь не делать же мне всю работу за него!? Он занимал место более талантливого разработчика. Я все правильно сделал». Но почему-то на душе скребли кошки. И когда мне пришел на ревью очередной pull request, что-то очень сильно поменялось.

Пост-ответ на статью "Иди-ка ты на !@# со своей "токсичностью"".

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

Однако это не помогло бы донести мою мысль. Поэтому давайте разберем поподробнее.

Здравствуйте!

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

Дисклеймер: если вам кажется, что текст направлен определённому человеку, а не аудитории в целом, то так оно и есть, но менять я ничего не буду.

Эта статья написана полностью из головы, что называется на одном дыхании (правда в три захода), потому в ней минимальное количество ссылок и картинок – прошу понять и простить, либо написать в комментарии, возможно я что-то исправлю.

Предисловие

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

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

Содержание

1. Манифест жёсткого программиста
2. Основополагающие принципы манифеста жёсткого программиста
3. Комментарии

Манифест жёсткого программиста

Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:

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

То есть, не отрицая важности того, что справа, мы всё-таки более ценим то, что слева.

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

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



Доклад Катерины Гавриловой на Saint TeamLead Conf дает вполне конкретные, не слишком трудозатратные рекомендации для руководителей, которые хотят нанять к себе в команду своих людей и не потратить на поиски полгода.

Как известно, в 2018 году компания Google провела крупнейший редизайн интерфейса своего почтового сервиса Gmail. Как обычно, довольны им оказались далеко не все — и на этот раз есть вполне объективные причины для недовольства сервисом. Почему загрузка Gmail стала занимать очень много времени, а действия вроде удаления или архивирования цепочки писем могут выполняться 4-6 секунд?

Пару дней назад подобным вопросом задался пользователь Hacker News — и он получил ответ от анонимного сотрудника Google, хлестко проехавшегося по культуре разработки внутри компании и своим коллегам.

С его слов, все это происходит в силу того, что в Google не предусмотрено никаких наказаний за подобные «промахи».

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

Всем привет. Как вы, возможно, знаете, раньше я все больше писал и рассказывал про хранилища, Vertica, хранилища больших данных и прочие аналитические вещи. Сейчас в область моей ответственности упали и все остальные базы, не только аналитические, но и OLTP (PostgreSQL), и NOSQL (MongoDB, Redis, Tarantool).

Эта ситуация позволила мне взглянуть на организацию, имеющую несколько баз данных, как на организацию, имеющую одну распределенную гетерогенную (разнородную) базу. Единую распределенную гетерогенную базу, состоящую из кучи PostgreSQL, Redis-ов и Монг… И, возможно, из одной-двух баз Vertica.

Работа этой единой распределенной базы порождает кучу интересных задач. Прежде всего, с точки зрения бизнеса важно, чтобы с данными, движущимися по такой базе, все было нормально. Я специально не использую здесь термин целостность, consistency, т.к. термин это сложный, и в разных нюансах рассмотрения СУБД (ACID и CAP теорема) он имеет разный смысл.

Ситуация с распределенной базой обостряется, если компания пытается перейти на микросервисную архитектуру. Под катом я рассказываю, как обеспечить целостность данных в микросервисной архитектуре без распределенных транзакций и жесткой связности. (А в самом конце объясняю, почему выбрал для статьи такую иллюстрацию).

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

Эта научная книга года, лучшее что я читал в последнее время.

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

Кто такой тимлид в Яндексе? Чем хороший отличается от плохого и стоит ли приглашать на эту должность человека со стороны — в нашем интервью с Алексеем Шаграевым (ashagraev), занимающим одну из руководящих должностей в поисковых службах Яндекса.

«Это легко. Берём метрику Шварцшильда, ищем символы Кристоффеля, вычисляем их производную, записываем геодезическое уравнение, меняем некоторые декартовы координаты (чтобы не страдать), получаем большое многострочное ОДУ — и решаем его. Примерно так».



Теперь ясно, что чёрные дыры меня засосали. Они бесконечно увлекательны. В прошлый раз я разбирался с визуализацией геометрии Шварцшильда. Меня поглотила проблема точного представления, как кривизна такого пространства-времени влияет на внешний вид неба (поскольку фотоны из удалённых источников движутся вдоль геодезических линий, изогнутых чёрной дырой) для создания интерактивного моделирования. Вот результат (работает в браузере). Хитрость в максимально возможном предрасчёте отклонения световых лучей. Всё работает более-менее нормально, но конечно, такая симуляция далека от идеала, потому что в реальности там не производится никакой трассировки (для неспециалистов: восстановление назад во времени местонахождения световых лучей, падающих в камеру).

Мой новый проект исправляет этот недостаток, отказавшись от эффективности/интерактивности самым простым образом: это рейтрейсер чисто на CPU. Трассировка выполняется максимально точно и максимально долго. Рендеринг изображения вверху занял 15 5 минут (спасибо, RK4) на моём ноутбуке.

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

Карл Дженсен испытал то, что он называет «пробуждением», примерно в 2012-м году.

Он работал программистом в пригороде Денвера, писал код для медицинского оборудования. Работа была напряжённой: ему приходилось документировать каждый шаг для Управления по санитарному надзору за качеством пищевых продуктов и медикаментов США (FDA), а ошибка в коде могла навредить или даже убить пациента.

Дженсен зарабатывал порядка $110 000 в год, у него был определённый соцпакет, но, казалось, что всё это не окупает стресса. Он не мог расслабиться с семьёй после работы; бывало, что целые дни он проводил, обнимаясь с унитазом. Он похудел на 5 кг.

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

Во вторник 10 марта 2017 года Дженсен позвонил своему боссу и предупредил об увольнении после 15 лет работы в компании. Однако он не увольнялся, а уходил на пенсию. Ему было 43.

Заголовок статьи звучит как epic fail, но на самом деле все не так однозначно. Да и в общем и целом эта история закончилась весьма позитивно, хоть и не в Google. Но это уже тема для другой статьи. В этой же статье я расскажу о трех вещах: каким образом проходил мой процесс подготовки, каким образом проходили интервью в Google и почему же на мой взгляд все не так однозначно, как может показаться.

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

Kashnitsky, I., & Schöley, J. (2018). Regional population structures at a glance. The Lancet, 392(10143), 209–210. https://doi.org/10.1016/S0140-6736(18)31194-2

Собственно, вот карта в высоком разрешении (кликабельно).

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

Данные создают цвета

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

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

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

Сегодня Mislav Marohnić объявил о том, что разработчики Github избавились от jQuery на фронтенде GitHub.com. Казалось бы, в самом этом факте нет ничего примечательного, если бы не один интересный момент.

Проблема выбора нового фреймворка для фронтенда была решена радикально — решено было обойтись без фреймворков в принципе. Вместо них были использованы следующие средства:

• querySelectorAll (который предположительно был вдохновлен когда-то именно jQuery),
• fetch для работы с AJAX,
• delegated-events для обработки событий,
• полифиллы для работы с DOM,
• пользовательские элементы (Custom Elements), которые сейчас на подъеме.

Помимо Custom Elements, ничего другого из Web Components было решено не использовать. Разработчики присматривались к Shadow DOM и были бы не против прибегнуть к нему — однако, в силу того, что на полифиллах скорость поиска в DOM оставляет желать лучшего, им пришлось пока отложить эту затею.

Зачем разработчикам в принципе потребовалось все это сделать? По их словам, для того, чтобы «отдавать» посетителям меньше килобайт, иметь возможность использовать более явно выраженный синтаксис для выполнения манипуляций с DOM, а также ради возможности использовать библиотеку Flow.JS для статического анализа типов. По словам разработчиков, процесс ухода с jQuery занял годы.

В прошлых двух статьях мы рассказывали об IIoT — индустриальном интернете вещей — строили архитектуру, чтобы принимать данные от сенсоров, паяли сами сенсоры. Краеугольным камнем архитектур IIoT да и вообще любых архитектур работающих с BigData является потоковая обработка данных. В ее основе лежит концепция передачи сообщений и очередей. Стандартом работы с рассылкой сообщений сейчас стала Apache Kafka. Однако, для того, чтобы разобраться в ее преимуществах (и понять ее недостатки) было бы хорошо разобраться в основах работы систем очередей в целом, механизмах их работы, шаблонах использования и основной функциональности.

Мы нашли отличную серию статей, которая сравнивает функциональность Apache Kafka и другого (незаслуженно игнорируемого) гиганта среди систем очередей — RabbitMQ. Эту серию статей мы перевели, снабдили своими комментариями и дополнили. Хотя серия и написана в декабре 2017 года, мир систем обмена сообщениями (и особенно Apache Kafka) меняется так быстро, что уже к лету 2018-го года некоторые вещи изменились.

Саббатикал — это оплачиваемый или частично оплачиваемый длительный отпуск продолжительностью от трёх месяцев до года (и более) с гарантированным сохранением места за сотрудником.

— Саш, очевидно, работа не приносит тебе удовольствия, — Слава проговаривал бесспорные вещи. Четвертую неделю вместо работы я мчался на очередной детский турнир по футболу. Когда у тебя трое детей, можно 120% своего времени занять их увлечениями. — У меня есть к тебе предложение. Давай отправим тебя в отпуск на год? Я за это время закрою собой бизнес. Доходы, по-прежнему, пополам. Потом ты вернешься с новыми силами, и, может быть, я на год в отпуск схожу.

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