Привет!

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

Для разминки — небольшая задачка. Представьте себе беспроводную сеть Wi-Fi, состоящую из точки доступа (AP) и двух одинаковых клиентских устройств (STA1 и STA2).

Читаем надписи на коробках:
AP: 1733,3 Мбит/c
STA1, STA2: 866,7 Мбит/c

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

В последнее время процесс запуска онлайн-игр в КНР изрядно усложнился. В этой статье я пошагово разберу весь процесс «от и до».

Сразу скажу — так как мы полностью белые и пушистые, то всем требованиям мы пытаемся полностью соответствовать. Имея связи, контакты и «гуанси» некоторые моменты можно проскочить.

P.S.: Все изображения документов найдены в интернете и используются исключительно в целях наглядности

Недавно мне передали на поддержку проект на express.js. При изучении кода проекта я обнаружил немного запутанную работу с аутентификацией/авторизацией которая базировалась, как и 99,999% случаев, на библиотеке passport.js. Этот код работал, и следуя принципу «работает — не трогай», я оставил его как есть. Когда через пару дней мне дали задание добавить еще две стратегии авторизации. И тогда я начал вспоминать, что уже делал аналогичную работу, и это занимало несколько строк кода. Полистав документацию на сайте passport.js, я почти не сдвинулся с места в понимании того, что и как нужно делать, т.к. там рассматривались случаи, когда используется ровно одна стратегия, для которой, для каждой в отдельности, и даются примеры. Но как соединить несколько стратегий, зачем нужно использовать метод logIn() (что то же самое, что login()) — по-прежнему не прояснялось. Поэтому, чтобы разобраться сейчас, и не повторять тот же поиск еще и еще раз, — я составил для себя эти заметки.

Вычислять факт попадания в играх на основе полученной меткости можно по разному:

• сравнивая с одним псевдослучайным числом (которое тоже можно получать по разному [1]);
• сравнивая с наибольшим или наименьшим из двух псевдослучайных чисел;
• сравнивая среднее из двух и более случайных чисел (среднее тоже можно считать по разному).

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

Точно также по разному можно рассчитывать наносимый урон, особенно на основе дайсов (кубиков).

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

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

Спешу поделиться радостью: вот и настали те времена, когда можно полностью отказаться от win в пользу linux. Последней преградой был Photoshop — единственная софтина, без которой некоторым девелоперам, например, фронтэнд-девелоперам, верстальщикам (и прочим стропальщикам), приходилось туговато. Photoshop-то уже издавна запустили под wine, но оставалась одна проблемка: у меня никак не хотела включаться аппаратная поддержка GPU. А без нее и тормоза дикие на серьезных макетах, и отсутствие многих плюшек (фильтры, трансформации и прочая магия). После долгих неудачных экспериментов, наконец, удалось заставить Photoshop увидеть GPU и работать с ним «на полную катушку».

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

Выглядит он примерно так:

А зачем, почему, где взять и как пользоваться я расскажу ниже.

Есть 100500 способов и инструментов создать простого serverless чат-бота для телеграм. А наш все-равно будет проще, хотя бы по числу кликов в интерфейсе. Сам бот будет написан на Python, а выполнятся будет на serverless движке Swifty.

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

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

Ну вот, сделали. Испытали на себе, убедились в полезности, выкладываем на всеобщее обозрение и всеобщее пользование. Бесплатно, разумеется. Сервис по управлению собственной жизнью.

Привет, сообщество! Мы в Хекслете составили список из пяти бесплатных автоматизированных онлайн-платформ для новичков.

На русском:

HTML Academy
«Академия» учит верстать сайты. Основной контент в формате подписки (390 рублей в месяц) и интенсивов (от 12500 рублей), но есть несколько бесплатных автоматизированных курсов по основам HTML, CSS и JavaScript.

В HTML Academy не столько задания для прокачки в программировании, сколько для знакомства с основами веб-разработки. Но это идеальный формат для тех, кто никогда не писал код и хочет попробовать. Большое количество веб-разработчиков начинало путь именно здесь.

Code Basics
Это новый бесплатный сервис от Хекслета. Его основная идея — через решение простых заданий прямо в браузере погружать новичков в основы программирования. Сейчас есть уроки по PHP, JavaScript и Python, ближайшее время появятся — новые. Платформа подойдет лучше всего для изучения основ синтаксиса, и меньше — для прокачки алгоритмов.

Обучение построено вокруг чередования небольших порций теории (3-4 абзаца) и закрепления практики в тренажере. У каждого практического задания есть решение учителя, которое можно сравнить со своим после успешного прохождения и раздел для обсуждения задания.

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

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

(Иллюстрация)

Senior web developer’ы Антон и Алексей продолжают рассказ о непростой борьбе с Nuxt. В предыдущем раунде битвы с этим фреймворком они показали, как запустить проект на Nuxt так, чтобы все были счастливы. В новой статье поговорим о реальном применении фреймворка.

Мы начали переписывать проект с огромным техническим долгом. Месячная аудитория составляла 6-7 млн. уникальных посетителей, но существующая платформа доставляла слишком много проблем. Поэтому было решено отправить ее на пенсию. Само собой, производительность была нашим наибольшим опасением, но также не хотелось просесть по SEO.

После пары раундов обсуждения решили не полагаться на традиционный подход с только серверным рендерингом — но и не загонять себя в ловушку клиентского рендеринга. Как итог мы начали строить решение на базе Nuxt.js.

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

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

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

Товарищи инженеры, уже четвертый год пошел, как я взялся преподавать в Киевском политехническом институте. За это время у меня накопилось огромное количество примеров кода и материалов, примерно на 90 лекций. Должен сказать, что за весь период своей профессиональной деятельности (а это 24 года почти ежедневного написания кода), я никогда не подымал свой уровень программирования, как за последние годы, работая со студентами. Если раньше мне казалось, что написать кратко, сложно и внушительно — это верх мастерства, то теперь я осознал, что мой код должны понимать студенты после минимальных объяснений, иначе он никуда не годится. Я пришел к выводу, что способность эту можно и нужно распространить не только на обучающий код, но и на весь рабочий код. Более того, обучающий код не должен существенно отличаться от рабочего кода, потому, что мы учим будущих инженеров делать настоящие системы, а не учебные. А после многочисленных просьб, я решил записывать все лекции в виде скринкастов, которые сразу после завершения лекции отправляются на ютюб. За этот учебный год я планирую записать 100 лекций, из которых уже опубликованы 23, готовы материалы еще для 67 лекций и новых 10 лекций еще в процессе подготовки.

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

Адам Голаб, эксперт по React и JS, составил пошаговый учебный план, который поможет вам стать разработчиком с нуля либо укажет направление для дальнейшего повышения навыков в профессии.

План Адама представляет собой список основных пунктов, которые вам нужно изучить самостоятельно. Мы добавили описание, а в некоторых сложных моментах указали ссылки на дополнительные справочные материалы, с помощью которых вы получите ответ на вопрос: «Что я должен узнать как React-разработчик?».

Типичный запрос в техподдержку Voximplant: «Почему видеозвонок между двумя Chrome выглядит лучше, чем видеозвонок между MS Edge и нативным iOS-приложением»? Коллеги обычно отвечают нейтральное — «потому что кодеки». Но мы, айтишники, любопытны. Даже если я не разрабатываю новый Skype-for-web, чтение «какой браузер что может» и как они разбивают одно видео на несколько потоков разного качества обогащает картину мира и дает свежую тему для обсуждения в курилке. Удачно подвернувшаяся статья от широко известного в узких кругах Dr Alex (с лучшим объяснением термина «media engine» из всех, что я видел), немного нашего опыта, пара вечеров в «Циферблате» — и адаптированный для Хабра перевод ждет под катом!

Это вторая часть серии. Первую часть можно посмотреть здесь.

После того, как вы провели soft launch своей игры, получили первые данные и обратную связь и внесли необходимые изменения в приложение, пришло время подготовиться к глобальному запуску. Многие думают, что его очень сложно организовать правильно. Но есть шаги, которые вы можете предпринять, чтобы все прошло гладко. Давайте их рассмотрим.

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

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

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

Сегодня, в переводе 17 части материалов, посвящённых особенностям всего, что так или иначе связано с JavaScript, речь пойдёт о веб-компонентах и о различных стандартах, которые направлены на работу с ними. Особое внимание здесь будет уделено технологии Shadow DOM.

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

Зачастую смартфоны не могут похвастаться хорошим звуком, включая «музыкальные смартфоны с ЦАП» в сравнении с отдельными Hi-Fi плеерами. Этот материал о причинах и их возможных решениях. Наиболее подробно будет описана та часть, которая критичная именно для смартфонов.