В преддверии DevOpsConf Виталий Хабаров взял интервью у Дмитрия Столярова (distol), технического директора и соучредителя компании «Флант». Виталий расспросил Дмитрия про то, чем занимается «Флант», про Kubernetes, развитие экосистемы, поддержку. Обсудили, зачем нужен Kubernetes и нужен ли вообще. А еще про микросервисы, Amazon AWS, подход «Мне повезет» в DevOps, будущее самого Kubernetes, почему, когда и как он захватит мир, перспективы DevOps и к чему готовиться инженерам в светлом и близком будущем с упрощением и нейросетями.

Оригинал интервью в виде подкаста послушайте на DevOps Дефлопе — русскоязычном подкасте о DevOps, а ниже — текстовая версия.



Здесь и далее вопросы задает Виталий Хабаров инженер из Express42.

Примерно в каждой второй теме на Хабре, касающейся космонавтики или электроники, всплывает тема радиационной стойкости. Через новости об отечественной космонавтике красной нитью проходит тематика импортозамещения радстойкой элементной базы, но в то же самое время Элон Маск использует дешевые обычные чипы и гордится этим. А изральтяне в «Берешите» использовали радстойкий процессор и тоже гордятся этим. Да и в принципе микроэлектронная отрасль в России живет по большей части за счет госзаказа с соответствующими требованиями. Наблюдение за регулярными спорами насчет того, как надо правильно строить спутники, показывает, что подготовка участников обычно невысока, а их аргументация отягощена стереотипами, случайно услышанными вырванными из контекста фактами и знаниями, устаревшими много лет назад. Я подумал, что читать это больше нет сил, поэтому, дорогие аналитики, устраивайтесь поудобнее на своих диванах, и я начну небольшой (на самом деле большой) рассказ о самых популярных заблуждениях на тему того, что такое радиационная стойкость интегральных микросхем.


Рисунок 1. Непременная красивая картинка про космическое излучение и хрупкую Землю.

Поскольку многие из нас готовятся к конференции PyCon, мы хотели немного рассказать, как Python используется в Netflix. Мы применяем Python на всём жизненном цикле: от принятия решения, какие сериалы финансировать, и заканчивая работой CDN для отгрузки видео 148 миллионам пользователей. Мы вносим свой вклад во многие пакеты Python с открытым исходным кодом, некоторые из которых упомянуты ниже. Если что-то вас интересует, посмотрите наш сайт вакансий или ищите нас на PyCon.

Управление временем – это на самом деле не решение, а часть проблемы

Автор статьи: Адам М. Грант, американский ученый-психолог и писатель; профессор Уортонской школы бизнеса; автор трёх бестселлеров Нью-Йорк Таймс, а также книги «В работу с головой. Паттерны успеха от IT-специалиста».

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

«Это прозвучит, как шутка, но на самом деле всё серьёзно, — признался он. – Единственное, что мне пришло в голову – пить меньше воды, чтобы не бегать так часто в туалет».

Часть 1. Общий алгоритм поиска

Введение

Поиск пути — это одна из тех тем, которые обычно представляют самые большие сложности для разработчиков игр. Особенно плохо люди понимают алгоритм A*, и многим кажется, что это какая-то непостижимая магия.

Цель данной статьи — объяснить поиск пути в целом и A* в частности очень понятным и доступным образом, положив таким образом конец распространённому заблуждению о том, что эта тема сложна. При правильном объяснении всё достаточно просто.

Учтите, что в статье мы будем рассматривать поиск пути для игр; в отличие от более академических статей, мы опустим такие алгоритмы поиска, как поиск в глубину (Depth-First) или поиск в ширину (Breadth-First). Вместо этого мы постараемся как можно быстрее дойти от нуля до A*.

От переводчика: опубликовали для вас статью Марии Перна (Maria Antonietta Perna), которая рассказывает о типовых задачах по JavaScript, чаще всего предлагаемых соискателям-разработчикам на собеседованиях. Статья будет полезна, в первую очередь, начинающим программистам. Ниже даны примеры решения задач, если вам кажется, что они не слишком хороши, и есть вариант получше — предлагайте альтернативу в комментариях.

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

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

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

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

Я в тестировании 12 лет, работал в Naumen и Яндексе. Сейчас руковожу отделом тестирования из 150 человек в Контуре и продолжаю работать тестировщиком в одной из команд.

После полугодовых performance review менеджеры из разных команд рассказали, какие цели поставили своим тестировщикам. У каждого пятого была такая: «Научиться оценивать сроки на тестирование задач». Часто такой «оценки сроков» хотят не только от тестировщиков, но и от разработчиков.

Оценка сроков в 95 % случаев. Спасибо, xkcd.

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

Сейчас объясню, как это работает.

Девушка на скутере. Иллюстрация freepik, логотип Nomad от HashiCorp

Kubernetes — это 300-килограммовая горилла для оркестровки контейнеров. Она работает в некоторых самых крупных контейнерных системах в мире, но дорого обходится.

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

Некоторое время назад на Quora я отвечал на вопрос: как успевать записывать за лектором конспект по математике на LaTeX. Там я объяснил свой рабочий процесс по конспектированию в LaTeX с помощью Vim и Inkscape (для рисунков). Но с тех пор многое изменилось, так что я хочу опубликовать несколько постов в блоге с описанием нового процесса. Это первая из статей.

Я начал использовать LaTeX для конспектирования во втором семестре курса математики, и с тех пор написал более 1700 страниц. Вот несколько примеров, как выглядит конспект:

Рассказывает Светлана Каюшина, руководитель отдела документирования и локализации.

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

Когда я занимался изучением производительности алгоритмов, мне попалось вот это видео с мок-интервью Google. Оно не только дает представление, как проходят собеседования в крупных технологических корпорациях, но и позволяет понять, как решаются алгоритмические задачи, причем максимально эффективно.

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

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

Давно я хотел написать эту статью. Все думал — с какой стороны зайти правильнее? Но, вдруг, недавно, на Хабре появилась подобная статья, которая вызвала бурю в стакане. Больше всего меня удивил тот факт, что статью начали вбивать в минуса, хотя она даже не декларировала что-то, а скорее поднимала вопрос об использовании кодов ответа web-сервера в REST. Дебаты разгорелись жаркие. А апофеозом стало то, что статья ушла в черновики… килобайты комментариев, мнений и т.д. просто исчезли. Многие стали кармо-жертвами, считай, ни за что :)

В общем, именно судьба той статьи побудила меня написать эту. И я очень надеюсь, что она будет полезна и прояснит многое.

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

Автор материала, перевод которого мы публикуем сегодня, работает DevOps-инженером. Он говорит, что ему приходится пользоваться Docker. В частности, эта платформа для управления контейнерами применяется на разных этапах жизненного цикла Node.js-приложений. Использование Docker, технологии, которая, в последнее время, является чрезвычайно популярной, позволяет оптимизировать процесс разработки и вывода в продакшн Node.js-проектов.



Сейчас мы публикуем цикл статей о Docker, предназначенных для тех, кто хочет освоить эту платформу для её использования в самых разных ситуациях. Этот же материал сосредоточен, в основном, на профессиональном применении Docker в Node.js-разработке.

TL;DR Привет. Меня зовут Богдан и я изучаю проблемы чтения кода. Я только что закочнил первую рабочую версию «codecrumbs» — визуального инструмента для изучения исходного кода с помощью «хлебных крошек». Гитхаб репозиторий можно посмотреть тут.

Проблема

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

Конструкция async/await представляет собой сравнительно новый подход к написанию асинхронного кода в JavaScript. Она основана на промисах и, в результате, не блокирует главный поток. Новшество этой конструкции заключается в том, что благодаря ей асинхронный код становится похожим на синхронный и ведёт себя подобным образом. Это открывает перед программистом замечательные возможности.



До появления async/await при разработке асинхронных механизмов программ использовались коллбэки и промисы. Автор материала, перевод которого мы публикуем сегодня, предлагает сначала вспомнить о том, как писать код по-старому, а потом, на реальном примере, изучить применение async/await.

Nvidia представили open source платформу Rapids, задача которой ускорить работу алгоритмов машинного обучения на GPU. Рассказываем об особенностях инструмента и его аналогах.

Недавно я начал изучать machine learning. Начал с прекрасного, на мой взгляд, курса от Andrew Ng. И чтобы не забыть, а так же повторить выученное решил создать репозиторий Machine Learning in Octave. В нем я собрал математические формулы для гипотез, градиентных спусков, "cost function"-ов, сигмоидов и прочих фундаментальных для машинного обучения "штук". Так же добавил туда упрощенные и доработанные примеры реализации некоторых популярных алгоритмов (нейронная сеть, линейная/логистическая регрессия и пр.) для MatLab/Octave. Надеюсь эта информация будет полезна для тех из вас, кто планирует начать изучение machine learning-а.

Массачусетский Технологический институт. Курс лекций #6.858. «Безопасность компьютерных систем». Николай Зельдович, Джеймс Микенс. 2014 год

Computer Systems Security — это курс о разработке и внедрении защищенных компьютерных систем. Лекции охватывают модели угроз, атаки, которые ставят под угрозу безопасность, и методы обеспечения безопасности на основе последних научных работ. Темы включают в себя безопасность операционной системы (ОС), возможности, управление потоками информации, языковую безопасность, сетевые протоколы, аппаратную защиту и безопасность в веб-приложениях.

Лекция 1: «Вступление: модели угроз» Часть 1 / Часть 2 / Часть 3
Лекция 2: «Контроль хакерских атак» Часть 1 / Часть 2 / Часть 3
Лекция 3: «Переполнение буфера: эксплойты и защита» Часть 1 / Часть 2 / Часть 3
Лекция 4: «Разделение привилегий» Часть 1 / Часть 2 / Часть 3
Лекция 5: «Откуда берутся ошибки систем безопасности» Часть 1 / Часть 2
Лекция 6: «Возможности» Часть 1 / Часть 2 / Часть 3
Лекция 7: «Песочница Native Client» Часть 1 / Часть 2 / Часть 3
Лекция 8: «Модель сетевой безопасности» Часть 1 / Часть 2 / Часть 3
Лекция 9: «Безопасность Web-приложений» Часть 1 / Часть 2 / Часть 3
Лекция 10: «Символьное выполнение» Часть 1 / Часть 2 / Часть 3
Лекция 11: «Язык программирования Ur/Web» Часть 1 / Часть 2 / Часть 3
Лекция 12: «Сетевая безопасность» Часть 1 / Часть 2 / Часть 3
Лекция 13: «Сетевые протоколы» Часть 1 / Часть 2 / Часть 3