Привет, Хабр!

Каждый современный браузер сейчас позволяет работать с ES6 Modules.

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

Под катом рассказ о том, как я смог уменьшить размер приложения на 11% без ущерба для старых браузеров и своих нервов.

Всем привет!

За время моей работы с вебпаком у меня накопилась пара интересных советов, которые помогут вам приготовить отлично оптимизированное приложение. Приступим!

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

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

Продолжение.

Рады анонсировать новую Open Source-разработку компании «Флант» для DevOps-специалистов и не только — kubedog. Это написанная на Go библиотека и CLI на её основе для отслеживания событий ресурсов Kubernetes и сбора их логов.


На данный момент библиотека поддерживает слежение за следующими ресурсами: Pod (и Container), Job, Deployment, StatefulSet и DaemonSet. События и логи передаются через callback’и.

Открытые вакансии на должность разработчика в Яндексе есть всегда. Компания развивается, и хороших программистов не хватает постоянно. И претендентов на эти должности тоже хоть отбавляй. Главная сложность – отобрать действительно подходящих кандидатов. И в этом плане Яндекс мало чем отличается от большинства крупных IT-компаний. Так что базовые принципы, описываемые в этой статье, могут быть применимы не только к Яндексу.

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

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

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

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

Знаете что? Пусть катятся к черту.

— За что тебя приняли, за то и уволят. – тяжело вздохнув, сказал Боб. – Слышал такую фразу?

— Нет. – угрюмо ответил Джон.

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

— У меня своя версия. – тихо сказал Джон. – Кажется, дело было в скраме.

— Да, дело было в скраме. – кивнул Боб, все еще глядя в окно. – И я, если честно, уже не могу про него слышать. Не хочу говорить высокопарных слов, но ты меня обманул.

— Я? – недоуменно спросил Джон.

— Ты и скрам. Твой скрам. Твоя инициатива. – Боб повернулся и в упор уставился на Джона. Которая будет стоит мне проекта. И кучи денег.

«Цель этого курса — подготовить вас к вашему техническому будущему.»

Привет, Хабр. Помните офигенную статью «Вы и ваша работа» (+219, 2365 в закладки, 360k прочтений)?

Так вот у Хэмминга (да, да, самоконтролирующиеся и самокорректирующиеся коды Хэмминга) есть целая книга, написанная по мотивам его лекций. Давайте ее переведем, ведь мужик дело говорит.

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

Мы уже перевели 12 (из 30) глав.
За перевод спасибо Валерию Дмитрущенкову, который откликнулся на мой призыв в «предыдущей главе». Кто хочет помочь с переводом — пишите в личку или на почту magisterludi2016@yandex.ru (Кстати, мы еще запустили перевод еще одной крутейшей книги — «The Dream Machine: История компьютерной революции»)

Глава 29. Вы получаете то, что вы измеряете

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

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

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

Сподвигла меня на это разразившаяся (при моём активном участии) в минувшие выходные история с «нейроинтерфейсами» компании Bitronics Lab — детскими учебными наборами для снятия ЭЭГ и мышечной активности, которые при ближайшем рассмотрении оказались попросту небезопасны в использовании из-за несоблюдения их производителем базовых требований к электробезопасности медицинского оборудования.

История это очень показательна в том, что она демонстрирует, как по мере роста сложности система, составленная из кажущихся её авторам безопасными компонентов, становится опасной — причём на примере системы простой, бытовой и интуитивно понятной, а не атомного реактора или реактивного лайнера, которые любят брать в качестве примеров авторы книг вроде моей любимой "Inviting Disaster".

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

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



Казалось бы, что может пойти не так?

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

Исследование показало, что люди предпочитают сложные методы, потому что привыкли к ним

Незаконное обвинение Салли Кларк в убийстве двоих её сыновей – знаменитый пример неправильного использования статистики в суде

В 1999 году британский солиситор Салли Кларк попала под суд за убийство двух своих малолетних сыновей. Она утверждала, что оба они стали жертвами синдрома внезапной младенческой смерти. Эксперт, свидетель обвинения, Рой Мидоу, утверждал, что шансы на то, что этот синдром заберёт жизни двух младенцев из богатой семьи, составляли 1 к 73 млн, что уравнивало их с шансом ставить на скачках на лошадь с коэффициентом 80 к 1 четыре года подряд и всё время выигрывать. Жюри присяжных приговорило Кларк к пожизненному заключению.

Значительную часть своей профессиональной жизни я выступаю против использования Protocol Buffers. Они явно написаны любителями, невероятно узкоспециализированы, страдают от множества подводных камней, сложно компилируются и решают проблему, которой на самом деле нет ни у кого, кроме Google. Если бы эти проблемы протобуферов остались в карантине абстракций сериализации, то мои претензии на этом и закончились бы. Но, к сожалению, плохой дизайн Protobuffers настолько навязчив, что эти проблемы могут просочиться и в ваш код.

Узкая специализация и разработка любителями

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

Давай просто не будем обсуждать эту тему. Полное раскрытие: мне доводилось работать в Google. Это было первое (но, к сожалению, не последнее) место, где я когда-либо использовал Protobuffers. Все проблемы, о которых я хочу поговорить, существуют в кодовой базе Google; это не просто «неправильное использование протобуферов» и тому подобная ерунда.

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

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

Anthony Smith Images / Shutterstock.com

Мы создаём Kubernetes как облачный сервис и пристально следим за актуальными инструментами разработчиков контейнерных приложений. В этом посте мы расскажем про инструменты, которые сильно облегчают работу с развёртываниями Kubernetes и помогают построить CI/CD.

29 сентября мы провели Deerploy DevOps MeetUp, а сегодня публикуем видео выступлений.

«Доставляем в Kubernetes. Непрерывно и по-своему», Евгений Дехтярёв, 2ГИС

(Начальное название статьи «Алгоритм работы протокола SSH» было изменено по рекомендациям Vindicar, Karroplan и других участников хабросообщества)

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

Попытаюсь внести немного ясности в работу протокола SSH, а заодно рассмотреть роль алгоритма RSA и ключей авторизации пользователя…

Китайцы, как правило, очень добрые люди. Проблема с ними в том, что у них совершенно другая культура и они не понимают многого, что считается нормой у нас. Как и наоборот, кстати. Они бы и рады вписаться в общество и быть вежливыми, но главное для них — понять, как это. Работает это так: они пробуют что-то сделать и, если их никто не поправляет или никто на них косо не смотрит, решают, что это допустимо. Либо же повторяют то, что делает большинство.

Мы решили помочь братскому народу освоиться в России и подготовили памятку. Она доступна по лицензии CC BY-SA. Вы можете скачать её и повесить у себя в отеле, магазине, добавить в буклет или книгу.

Вот памятка:


А теперь пояснения.

У Grafana есть возможность показывать статус, у Grafana есть возможность показывать данные во времени. Однако, как это ни парадоксально, у Grafana до настоящего момента не было удобного способа показывать статус во времени!

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


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

Выглядит интересно? Но начнём с того, как мы вообще к этому пришли.