Привет, Хабр! Представляю вашему вниманию перевод статьи «ConfigureAwait FAQ» автора Стивен Тауб.



Async/await добавили в .NET более семи лет назад. Это решение оказало существенное влияние не только на экосистему .NET — оно также находит отражение во многих других языках и фреймворках. На данный момент реализовано множество усовершенствований в .NET с точки зрения дополнительных языковых конструкций, использующих асинхронность, реализованы API-интерфейсы с поддержкой асинхронности, произошли фундаментальные улучшения в инфраструктуре, благодаря которым async/await работает как часы (в особенности, улучшены возможности производительности и диагностики в .NET Core).

ConfigureAwait — один из аспектов async/await, который продолжает вызывать вопросы. Надеюсь, у меня получится ответить на многие из них. Я постараюсь сделать эту статью читаемой от начала до конца, и вместе с тем выполнить ее в стиле ответов на часто задаваемые вопросы (FAQ), чтобы на нее можно было ссылаться в последующем.

Я выложил на Github новый проект A Simple GPU Hash Table.

Это простая хэш-таблица для GPU, способная обрабатывать в секунду сотни миллионов вставок. На моём ноутбуке с NVIDIA GTX 1060 код вставляет 64 миллиона случайно сгенерированных пар ключ-значение примерно за 210 мс и удаляет 32 миллиона пар примерно за 64 мс.

То есть скорость на ноутбуке составляет примерно 300 млн вставок/сек и 500 млн удалений/сек.

Таблица написана на CUDA, хотя ту же методику можно применить к HLSL или GLSL. У реализации есть несколько ограничений, обеспечивающих высокую производительность на видеокарте:

• Обрабатываются только 32-битные ключи и такие же значения.
• Хэш-таблица имеет фиксированный размер.
• И этот размер должен быть равен двум в степени.

Для ключей и значений нужно зарезервировать простой разграничивающий маркер (в приведённом коде это 0xffffffff).

Не только содержание, но и структура текста должна быть осмысленна.

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

• Заголовок
• Суть статьи
  На основе этих нескольких предложений вместе с заголовком читатель должен понять, интересно ли ему читать эту статью дальше.
• Краткое изложение
  Здесь в максимально сжатом виде, тезисно, но с необходимой точностью и полнотой должна быть отражена суть данной статьи — от нескольких предложений до нескольких страниц. Кому-то, кто глубоко в теме этого может быть достаточно для понимания всей статьи. Но в любом случае читателю полезно представлять в самом общем виде, о чем эта статья, и какие выводы он получит в конце.
  
• Логика статьи
  Если статья длинная, содержит много разделов и сложную логику, то эта глава может быть также полезной. По сути это расширенное оглавление. Здесь кратко, на одной-двух страничках, излагается логика рассуждения, сухо, без деталей. Опять-таки, кому-то этого будет достаточно для того, чтобы все понять. Если сложно, то читатель может это пропустить (как оглавление) и читать дальше.
• Упрощенное изложение
  Если статья достаточно сложная, то многим было бы удобно сначала понять концептуально, что же хочет сказать автор. Поэтому неплохо сначала изложить все так, как если бы вы рассказывали студентам, упуская сложные доказательства, и, возможно, не столь формальным и строгим языком. Для очень многих такой уровень изложения может быть достаточным, и они остановятся здесь.
• Строгое изложение
  Здесь строго профессиональное изложение.
  

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

Обычно после конференций мы делимся впечатлениями с теми, кто на конференцию не пошел. Самый популярный формат — список топовых докладов с краткими заметками, который рассылается в Слаке и по почте.

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

Привет, Хабр! Я ведущий разработчик системы локализации в Badoo. Мы работаем с несколькими большими проектами: Badoo, Bumble, Lumen и Chappy. Сейчас в системе локализации у нас находятся 150 000 фраз и текстов, переведённых на 52 языка. При этом каждое из наших приложений имеет свою аудиторию, свои рынки, свой стиль общения с пользователями, версии для веба и для мобильных платформ.

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

Статья написана по мотивам моего доклада на конференции Highload++ в ноябре.

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

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

Ну и "вишенкой на торте" можно считать удобство и простоту используемого инструмента, что тоже немаловажно.

Для решения этих задач и была разработана кросс-платформенная open-source .NET библиотека Unchase.FluentPerformanceMeter.

Всем привет! В данной статье рассмотрим разработку фронта простенького блога на Vue с использованием всех прелестей Vue включая Vuex и Router. А также поговорим про структуру приложения и работу с контейнером и роутером.

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

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

Если сравнить зарплату разработчика программного обеспечения квалификации middle в Москве, Лос-Анджелесе и Сан-Франциско, взяв данные по зарплатам, которые оставляют сами разработчики на специализированных сервисах по мониторингу зарплат, то увидим: 

• В Москве зарплата такого разработчика на конец 2019 года составляет 130 000 руб. в месяц (по данным сервиса зарплат на moikrug.ru)
  
• В Сан-Франциско — 9 404 долларов США в месяц, что примерно равно 564 000 руб. в месяц (по данным сервиса зарплат на glassdoor.com).
  

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

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

Хотя люди обычно признают удобства ФП фич, ведь намного приятнее писать:

int Factorial(int n)
{
    Log.Info($"Computing factorial of {n}");
    return Enumerable.Range(1, n).Aggregate((x, y) => x * y);
}

чем ужасные императивные программы вроде

int Factorial(int n)
{
    int result = 1;
    for (int i = 2; i <= n; i++)
    {
        result *= i;
    }
    return result;
}

Так ведь? С одной стороны да. А с другой именно вторая программа в отличие от первой является функциональной.

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

Понятное для тех, кто захочет разобраться, конечно. Пост состоит из трех частей. Для понимания сути явления, достаточно ознакомиться только со второй частью.

1. Вводная (зачем, да почему)
2. Конкретные расчеты
3. Философско-практическая часть.

1. Вводная (зачем, да почему)

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

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

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

Однако, кроме низкой задержки, важно обеспечить зрителям хорошее качество трансляции, ведь за это они и платят. В реальной жизни, каналы между Edge серверами и подписчиками могут быть разными по пропускной способности и качеству. Например, мы публикуем поток разрешением 720p с битрейтом 2 Мбит/с, а пользователь играет его на Android-смартфоне, используя 3G подключение в зоне неуверенного приема сигнала, и максимальное разрешение, при котором картинка будет плавной, всего 360p с битрейтом 400 Мбит/с.

Привет, Хабр! Представляю вашему вниманию перевод статьи «Learn responsive web design in 5 minutes» автора Per.

В этой статье я научу вас многим приёмам отзывчивого дизайна за 5 минут. Этого, очевидно, недостаточно для правильного изучения, но здесь вы найдёте обзор на следующие наиболее важные методы:

• Относительные единицы измерения CSS
• Медиа-запросы
• Flexbox
• Отзывчивая типографика

Знакомьтесь, это обычный «литровый» пакет молока:

• Проверка на внимательность: там 900 грамм. Рядом несколько по 950. Но пакет может быть воспринят как литровый.
• Проверка на знание физики. Рядом лежит похожий кефир. Объём измеряется в миллилитрах, масса — в граммах. Плотность кефира трагически выше плотности воды. То есть 900 грамм кефира 3,2% жирности — это примерно 874,5 миллилитров.

Второй пациент:



25 лет гарантии. Круто, правда? Есть одна проблема. Надо сохранять чек. Проверка, опять же, на знание физики. Чек у них печатается на обычной кассовой термоленте (я проверил на месте). У меня в офисе лежит много чеков. Мы их ксерокопируем, потому что через год-два они полностью выцветают. Самый старый чек, который видел коллега, держался 3 года в папке в архиве. UPD: смотрите самый низ топика, Икея ответила.

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

Осторожно, трафик: под катом много находок с фотографиями.

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

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