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

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

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

Как я писал в предисловии предыдущей статьи, я нахожусь в поисках языка, в котором я мог бы писать поменьше, а безопасности иметь побольше. Моим основным языком программирования всегда был C#, поэтому я решил попробовать два языка, симметрично отличающиеся от него по шкале сложности, про которые до этого момента приходилось только слышать, а вот писать не довелось: Haskell и Go. Один язык стал известен высказыванием "Avoid success at all costs"*, другой же, по моему скромному мнению, является полной его противоположенностью. В итоге, хотелось понять, что же окажется лучше: умышленная простота или умышленная строгость?

Я решил написать решение одной задачки, и посмотреть, насколько это просто на обоих языках, какая у них кривая обучения для разработчика с опытом, сколько всего надо изучить для этого и насколько идиоматичным получается "новичковый" код в одном и другом случае. Дополнительно хотелось понять, сколько в итоге мне придется заплатить за ублажание хаскеллевского компилятора и сколько времени сэкономит знаменитое удобство горутин. Я старался быть настолько непредвзятым, насколько это возможно, а субъективное мнение приведу в конце статьи. Итоговые результаты меня весьма удивили, поэтому я решил, что хабровчанам будет интересно почитать про такое сравнение.

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

Прежде чем заняться реализацией runtime и изучением стандартной библиотеки, необходимо освоить абстрактный ассемблер Go. Надеюсь, это руководство поможет вам быстро овладеть нужными знаниями.

Оценивая свою работу, я недавно много размышлял о том, как мне писать хороший код. Учитывая, что никто не интересуется тем, как писать плохой код, возникает вопрос: как узнать, что ты написал на Go хороший код? Если есть какая-то шкала между хорошо и плохо, то как понять, какие части шкалы относятся к хорошему? Каковы его свойства, атрибуты, отличительные признаки, паттерны и идиомы?

Автор статьи, перевод которой мы сегодня публикуем, говорит, что сейчас можно наблюдать рост популярности таких сервисов аутентификации, как Google Firebase Authentication, AWS Cognito и Auth0. Индустриальным стандартом стали универсальные решения наподобие passport.js. Но, учитывая сложившуюся ситуацию, обычным явлением стало то, что разработчики никогда в полной мере не понимают того, какие именно механизмы принимают участие в работе систем аутентификации.

Этот материал посвящён проблеме организации аутентификации пользователей в среде Node.js. В нём на практическом примере рассмотрена организация регистрации пользователей в системе и организация их входа в систему. Здесь будут подняты такие вопросы, как работа с технологией JWT и имперсонация пользователей.



Кроме того, обратите внимание на этот GitHub-репозиторий, в котором содержится код Node.js-проекта, некоторые примеры из которого приведены в этой статье. Этот репозиторий вы можете использовать в качестве основы для собственных экспериментов.

Темой нашей сегодняшней статьи будет Virtual Patching.

Virtual Patching — это слой политики безопасности, предназначенный для обнаружения и предотвращения эксплуатации эксплойта для известной уязвимости.

Введение в проблематику

В своей практике работы с разными типами заказчиков – от крупных международных компаний до небольших фирм или даже ИП – мы наблюдаем схожие проблемы при попытке системно работать с уязвимостями.

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

Не смотря на то, что в последнем публиковавшемся перечне уязвимостей OWASP Top 10 2017 CSRF атаки отнесены к разряду “Удалены, но не забыты”, мы решили, что не будет лишним еще раз напомнить о том, как защититься от CSRF атак, опираясь на те же правила, предоставляемые OWASP.

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

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

REST — чрезвычайно популярная архитектура веб-приложений. Для вызова функций на сервере используются обычные HTTP-запросы с задаваемыми параметрами (для структуризации параметров обычно используют JSON или XML), при этом, строгого стандарта для REST-архитектуры не существует, что добавляет ей гибкости (и, конечно, немного хаоса).

Многие приложения используют JSON Web Tokens (JWT), чтобы позволить клиенту идентифицировать себя для дальнейшего обмена информацией после аутентификации.

JSON Web Token – это открытый стандарт (RFC 7519), который определяет компактный и автономный способ безопасной передачи информации между сторонами в виде объекта JSON.

Каков наилучший способ беспроблемного увеличения параллелизма в Node.js-сервисе, который используется в продакшне? Это — вопрос, на который моей команде понадобилось ответить пару месяцев назад.

У нас запущено 4000 контейнеров Node (или «воркеров»), обеспечивающих работу нашего сервиса интеграции с банками. Сервис изначально был спроектирован так, что каждый воркер был рассчитан на обработку только одного запроса за раз. Это снижало воздействие на систему тех операций, которые могли неожиданно заблокировать цикл событий и позволяло нам игнорировать различия в использовании ресурсов различными подобными операциями. Но, так как наши мощности были ограничены одновременным выполнением лишь 4000 запросов, система не могла достойно масштабироваться. Скорость выдачи ответов на большинство запросов зависела не от мощности оборудования, а от возможностей сети. Поэтому мы могли бы улучшить систему и снизить стоимость её поддержки в том случае, если бы нашли способ надёжной параллельной обработки запросов.



Занявшись исследованием этого вопроса, мы не смогли найти хорошего руководства, в котором речь шла бы о переходе от «отсутствия параллелизма» в сервисе Node.js к «высокому уровню параллелизма». В результате мы разработали собственную стратегию перехода, которая была основана на тщательном планировании, на хороших инструментах, на средствах мониторинга и на здоровой дозе отладки. В итоге нам удалось повысить уровень параллелизма нашей системы в 30 раз. Это эквивалентно снижению затрат на поддержку системы примерно на 300 тысяч долларов в год.

Данный материал посвящён рассказу о том, как мы увеличили производительность и эффективность наших Node.js-воркеров, и о том, что мы узнали, пройдя этот путь.

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



Автор статьи, перевод которой мы сегодня публикуем, хочет рассказать о нескольких мощных, но малоизвестных клиентских фреймворках и библиотеках, основанных на JavaScript. Конечно, «большая тройка», в лице Angular, React и Vue, никуда не делась, но в мире веб-разработки есть и другие инструменты, достойные внимания. Такие, например, как Svelte, Preact и Riot. Вопрос выбора подходящего средства зависит от многих факторов. Среди них — знания разработчика, особенности проекта, ситуация на рынке. Поэтому давайте рассмотрим малоизвестные фреймворки, расширив тем самым свободу выбора тех, кто ищет подходящий инструмент для своего очередного проекта.

В этом году, на конференции Forward.js, посвящённой JavaScript, я выступал с докладом «You don’t know Node». Во время выступления я задал аудитории несколько вопросов о Node, и большинство присутствующих не смогли ответить на многие из них. А ведь мой доклад слушали технические специалисты. Никаких подсчётов я не производил, но выглядело всё именно так, да и несколько слушателей, которые подошли ко мне после выступления, это подтвердили.

Проблема, которая заставила меня сделать то выступление, заключается в том, что, по-моему, система обучения Node выстроена неправильно. Большинство учебных материалов сосредоточено на пакетах Node, но не на самой платформе. Часто этих пакеты служат обёртками для модулей Node (вроде http или stream). Как результат, тот, кто не знает Node и сталкивается с проблемой, источником которой может оказаться не некий пакет, а платформа, оказывается в крайне невыгодном положении.

В компании Klarna прилагают большие усилия к тому, чтобы помочь разработчикам в создании высококачественных и безопасных сервисов. Один из инструментов, который предназначен для разработчиков, представляет собой платформу для выполнения A/B-тестов. Важнейшим компонентом этой системы является множество процессов, которые, для каждого поступающего запроса, принимают решение о том, к какой разновидности тестов (A или B) направить запрос. Это, в свою очередь, определяет то, каким цветом вывести кнопку, какой макет показать пользователю, или даже то, какой пакет сторонней разработки использовать. Эти решения оказывают непосредственное воздействие на впечатления пользователей.



В Klarna используют платформу Node.js. Статья, перевод которой мы публикуем сегодня, посвящена тем урокам, которые специалистам компании удалось извлечь из опыта оптимизации производительности своего сервиса.

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

Для новичков: Pandas — это высокопроизводительный набор инструментов для анализа данных на Python с простыми и удобными структурами данных. Название произошло от понятия «panel data», эконометрического термина, которым называют данные о наблюдениях одних и тех же субъектов в течение разных периодов времени.

Здесь можно скачать Jupyter Notebook с примерами из статьи.

Начнём этот материал с вопроса. ES2015-модуль increment содержит следующий код:

// increment.js
let counter = 0;
counter++;

export default counter;

В другом модуле, который мы назовём consumer, вышеприведённый модуль импортируется 2 раза:

// consumer.js
import counter1 from './increment';
import counter2 from './increment';

counter1; // => ???
counter2; // => ???

А теперь, собственно, вопрос. Что попадёт в переменные counter1 и counter2 после выполнения модуля consumer?



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

Typhon freight hauler concept, Anton Swanepoel

Меня зовут Дмитрий Сугробов, я разработчик в «Леруа Мерлен». В статье расскажу, зачем нужен Helm, как он упрощает работу с Kubernetes, что поменялось в третьей версии и как с его помощью обновлять приложения в продакшене без простоя.

Это конспект по мотивам выступления на конференции @Kubernetes Conference by Mail.ru Cloud Solutions — если не хотите читать, смотрите видео.

Если ваша компания только внедряет DevOps или инструменты CI/CD, вам может быть полезно познакомиться с самыми распространенными ошибками, чтобы не повторить их и не наступать на чужие грабли. 

Команда Mail.ru Cloud Solutions перевела статью Avoid These Common Pitfalls When Transitioning to CI/CD by Jasmine Chokshi с дополнениями.