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

Постановка задачи:

• Разработка должна быть на Node.js. Мы давно используем эту платформу для разработки всех наших проектов, так что здесь это оправданный выбор.
• Все ноды в кластере должны быть равнозначными. Не должно быть специального управляющего звена или мастера. В противном случае остановка мастера может привести к останову всего кластера.
• Задачи должны находиться в таблице MySQL. Это намного гибче и информативнее, чем использовать какой-нибудь MQ. Всегда можно получить доступ ко всем задачам, оценить очередь, переназначить их на другую ноду и т.д.
• Каждый воркер должен уметь обрабатывать несколько задач одновременно.

Сразу привожу ссылку на GitHub того, что получилось: (https://github.com/pipll/node-daemons).

Автор материала, перевод которого мы сегодня публикуем, говорит, что входит в команду мессенджера Hike, которая занимается новыми возможностями приложения. Цель этой команды заключается в том, чтобы воплощать в реальность и исследовать идеи, которые могут понравиться пользователям. Это означает, что действовать разработчикам нужно оперативно, и что им приходится часто вносить изменения в исследуемые ими новшества, которые направлены на то, чтобы сделать работу пользователей как можно более удобной и приятной. Они предпочитают проводить свои эксперименты с применением React Native, так как эта библиотека ускоряет разработку и позволяет использовать один и тот же код на разных платформах. Кроме того, они пользуются библиотекой Redux.

Несколько лет назад, когда я начал работать в Node.js, меня приводило в ужас то, что сейчас известно как «ад коллбэков». Но тогда из этого ада выбраться было не так уж и просто. Однако, в наши дни Node.js включает в себя самые свежие, самые интересные возможности JavaScript. В частности, Node, начиная с 4-й версии, поддерживает промисы. Они позволяют уйти от сложных конструкций, состоящих из коллбэков.



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

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

Многие считают, что метапрограммирование в Python излишне усложняет код, но если использовать его правильно, то можно быстро и элегантно реализовать сложные паттерны проектирования. Помимо этого, такие известные Python-фреймворки, как Django, DRF и SQLAlchemy, используют метаклассы, чтобы обеспечить легкую расширяемость и простое переиспользование кода.

В этой статье расскажу, почему не стоит бояться использовать метапрограммирование в своих проектах и покажу, для каких задач оно подходит лучше всего. Еще больше о возможностях метапрограммирования можно узнать на курсе Advanced Python.

Давайте представим, что вы управляете продуктом, который помогает малому бизнесу осуществлять техническую поддержку своих клиентов. Вы ищете способы увеличить степень вовлечённости (engagement) и возвращаемости (retention) своих клиентов. У вас есть две идеи:

• Дашборд, который позволит владельцам бизнеса мониторить статистику вовлечённости.
• Чат-бот, который поможет владельцам бизнеса автоматизировать коммуникацию с потребителями.

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

Что вы выберете?

Всем привет.

Написал библиотеку для обучения нейронной сети. Кому интересно, прошу.

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

Disclaimer: всё описанное ниже — это только мой опыт, который, как я надеюсь, будет кому-то полезен, но не факт, что описанные шаги окажутся идеальными именно для вас.

Кратко: если у вас на сайте есть загрузка изображений и вы обрабатываете их при помощи популярной библиотеки ImageMagick, то загрузив картинку можно выполнить shell-команду с правами юзера веб-сервера (например: загрузить RAT, майнер, слить исходники, получить доступ к базе, вызвать отказ и т.п.)

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

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

Об этом и о том, как работает асинхронщина в JS под капотом, как Event Loop работает в браузерах и в Node.js, есть ли какие-то различия и, может быть, похожие вещи рассказал Михаил Башуров (SaitoNakamura) в своем докладе на РИТ++. С удовольствием делимся с вами расшифровкой этого познавательного выступления.



О спикере: Михаил Башуров — fullstack веб-разработчик на JS и .NET из Luxoft. Любит красивый UI, зеленые тесты, транспиляцию, компиляцию, технику compiler allowing и улучшать dev experience.

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

Язык TypeScript основан на том же синтаксисе и семантике, которые хорошо знакомы миллионам JavaScript-разработчиков. TypeScript даёт возможность работать с самыми свежими и ещё только появляющимися возможностями JS, включая те, которые имеются в ECMAScript 2015, и те, которые пока существуют лишь в виде предложений. Среди таких возможностей, например, асинхронные функции и декораторы. Всё это направлено на то, чтобы помочь разработчику в создании надёжных и современных приложений.

TypeScript-программа компилируется в обычный JavaScript-код, который может выполняться в любом браузере или в среде Node.js. Этот код будет понятен любому JS-движку, который поддерживает стандарт ECMAScript 3 или более новый.



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

Что лучше использовать при разработке софта — нативные или веб-технологии? Холивар по этому поводу закончится ещё не скоро, но мало кто станет спорить, что нативные функции полезно продублировать для использования в браузерах или WebView. И если когда-то приложения для звонков существовали исключительно отдельно от браузера, то теперь их легко реализовать и в вебе. Разработчик Григорий Кузнецов объяснил, как пользоваться технологией WebRTC для P2P-соединений.


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

У разработчика, который впервые столкнулся с генерированием электронных писем, практически нет шансов написать приложение, которое будет делать это корректно. Около 40 % писем, генерируемых корпоративными приложениями, имеют те или иные нарушения стандартов, и, как следствие, проблемы с доставкой и отображением. На это есть причины: электронная почта технически гораздо сложнее, чем веб, работа почты регулируется несколькими сотнями стандартов и несчетным количеством общепринятых (и не очень) практик, а почтовые клиенты отличаются разнообразием и непредсказуемостью. Тестирование может заметно улучшить ситуацию, но материалов, посвященных тестированию почты, практически нет.

Почта Mail.Ru регулярно взаимодействует со своими пользователями посредством электронных писем. В нашем проекте все компоненты, отвечающие за генерирование писем, и даже единичные рассылки проходят обязательное тестирование. В этой статье мы поделимся своим опытом (и набитыми шишками).

• Какие бывают электронные письма
• Кто участвует в процессе тестирования и контроля
• Почтовое сообщение и почтовый транспорт
• Интерфейс почтовой инфраструктуры и границы тестируемого приложения
• Определение тестируемых параметров
• Типичная структура генерирующего приложения
• Что и когда тестировать
  
  1. Инфраструктура доставки
  2. Генерирующее приложение
  3. Структурный и вёрсточный шаблоны письма
• Базовые требования при проверке инфраструктуры
• Требования к авторизации
• Проверка генерирующего приложения
  
  • Требования к почтовым адресам
  • Требования к заголовкам писем
  • Требования к структуре письма
  • Требования к URI
  • Требования к вёрстке письма
• Проведение сплит-тестов

SSH/HTTPS/OpenVPN/Telegram и всё на одном порту?! Что?!
— Да!

• Хотите скрыть наличее у вас некоторых сервисов?
• В публичной wi-fi сети блокируется всё кроме 443 (https) порта?
• Настроили Telegram Proxy/OpenVPN и не хотите его «светить» ?
• SSH подключение к своему серверу из стран с цензурой?

На все эти вопросы ответ один — Мультиплексирование SSL/TLS соединений, или SSLH.

В посте мы рассмотрим как в 1 команду спрятать кучу сервисов за 1 портом.

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

Большинство разработчиков знают о важных и нужных HTTP-заголовках. Самые известные — Content-Type и Content-Length, это почти универсальные хедеры. Но в последнее время для повышения безопасности начали использоваться заголовки вроде Content-Security-Policy и Strict-Transport-Security, а для повышения производительности — Link rel=preload. Несмотря на широкую поддержку в браузерах, лишь немногие их используют.

В то же время есть много чрезвычайно популярных заголовков, которые вообще не новые и не очень полезные. Мы можем это доказать с помощью HTTP Archive, проекта под управлением Google и спонсируемого Fastly, который каждый месяц при помощи WebPageTest скачивает 500 000 сайтов и выкладывает результаты в BigQuery.

В последнее время использовать VPN стало популярно с чего бы это?, но все инструкции которые мне попадались — могут «осилить» только пользователи хотя бы чуть-чуть знакомые с тем что такое Linux. Компания Google всех порадовала, выпустив прекрасное приложение, которое позволяет вам установить VPN в два клика (правда в два!) на своем личном сервере без каких либо знаний.
(Если у вас нет сервера — не беда, появится)

Автор блога Financial Hacker рассказал о том, как на самом деле устроен процесс разработки высокочастотных стратегий для торговли на бирже — от важности анализа возможных задержек, до вопросов получения данных и тестирования (все с примерами кода). Для примера используется стратегия арбитражной торговли на американских биржах. Мы подготовили адаптированный перевод этого материала.

Привет, читатель! Меня зовут Илья Агеев, я работаю в Badoo уже почти семь лет. Текущая моя должность называется Engineering Director Quality Assurance (директор по контролю качества), и по факту я занимаюсь много чем в компании: контроль качества, релиз-инжиниринг, процессы и методология разработки и даже немного информационная безопасность. Одна из сфер, которая входит в зону моей ответственности, — ревью кода. Об истории и результате нашего процесса (которым стал опенсорсный codeisok) я сегодня и расскажу.

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

Давным-давно в Badoo не было code review. Практически. Первой попыткой обмена информацией об изменённом коде была простая рассылка изменений на почту. К слову, и Git тогда не использовалась.

Летом 2011 года, когда я только пришёл в компанию, для хранения версий кода использовалась SVN. Бывалые рассказывали, что до этого все работали в CVS и что была одна попытка перейти на Mercurial, но она провалилась. Почему — никто не помнит. Я подозреваю, что дело в том, что, когда решили попробовать Mercurial, особой надобности в переходе на другую VCS не было. Всё и так всех устраивало: работает, и ладно. А модный инструмент ради моды никому не нужен.

Главное в платежной системе — взять денежки, перевести записи из одной таблички в ту же самую табличку со знаком «минус». Звучит не очень сложно, пока не пришли юристы. Платежные системы во всем мире облагаются огромным количеством всевозможных отягощений и указаний. Поэтому в рамках разработки платежной системы приходится все время балансировать на грани между тяжелым enterprise и вполне нормальным масштабируемым web-приложением.

Под катом рассказ Филиппа Дельгядо (dph) на Highload++ про опыт, накопившийся за несколько лет работы над платежной системой для российского легального букмекерского бизнеса, про ошибки, но и про некоторые достижения, и про то, как грамотно смешать, но не взбалтывать, web с enterprise.

В наши дни, когда всякие нехорошие элементы так и норовят влезть в ваш трафик и как-то там напакостить, стало модным шифрование трафика. Начинание это благое и полезное, вот только делают его зачастую избыточно. Если шифрование трафика до доверенного сервера, типа своего VPS, — ваша единственная цель, то OpenVPN для такой цели слишком наворочен. Его долго настраивать, легко обнаружить, а главное — есть подводные камни, не зная которых можно получить такую ситуацию, что VPN стоит, а трафик идёт в обход. Всё это потому, что OpenVPN задумывался больше как средство доступа к маленькой сети через Интернет, а не для доступа ко всему Интернету.

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


В основе статьи расшифровка выступления Виталия Фридмана из Smashing Magazine на декабрьской конференции Holy JS 2017 Moscow.