Для начала, давайте разберемся с двумя важнейшими эпидемиологическими понятиями: смертностью и летальностью. Сразу оговорюсь, что в википедии (как русской, так и английской) приведено ошибочное определение летальности, которое сбивает с толку.

Летальность — это вероятность умереть, если у пациента диагностирована болезнь. Вот цитата из научной статьи:

one of the most important epidemiologic quantities to be determined is the case fatality ratio—the proportion of cases who eventually die from the disease.

Смертность — это отношение числа умерших от болезни к размеру популяции за какой-то промежуток времени. Обычно, считают сколько смертей на 100 тыс. населения за единицу времени. Смертность непосредственно связана с летальностью: это произведение вероятности заболеть (за определенный временной период) на летальность. В самом деле, для того, чтобы умереть от болезни надо сначала ей заразиться, а потом уж, если не повезет…

Вступление

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

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

• Сколько людей заболеют коронавирусом в вашем регионе?
• Что случится, когда они начнут заболевать?
• Что вы должны делать?
• Когда?

Когда вы закончите читать статью, вы придёте к следующим выводам:

• Коронавирус приближается к вам.
• Он приближается с экспоненциальной скоростью: сперва постепенно, а потом внезапно.
• Это вопрос нескольких дней. Может быть, неделя или две.
• Когда это случится, ваша система здравоохранения будет перегружена.
• Ваши сограждане будут лечиться в коридорах.
• Изможденные медицинские работники сломаются. Некоторые погибнут.
• Им придётся решать, кто из пациентов получит лечение, а кто умрет.
• Единственный способ предотвратить это — социальная изоляция уже сегодня. Не завтра. Сегодня.
• Это значит держать как можно больше людей дома, начиная с сегодняшнего дня.

Если вы политик, общественный деятель или руководитель, у вас есть власть и ответственность, чтобы предотвратить описанное выше.

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

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

Итак, давайте разбираться.

Когда мы перешли от разработки веб-сайтов, страницы которых формируются на сервере, к созданию одностраничных веб-приложений, которые рендерятся на клиенте, мы приняли определённые правила игры. Одно из них — аккуратное обращение с ресурсами на устройстве пользователя. Это значит — не блокировать главный поток, не «раскручивать» вентилятор ноутбука, не сажать батарею телефона. Мы обменяли улучшение интерактивности веб-проектов, и то, что их поведение стало больше похоже на поведение обычных приложений, на новый класс проблем, которых не существовало в мире серверного рендеринга.

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

Говоря объективно, признаю, шрифты — не моя сильная сторона. Я предпочитаю более практичный подход и не зацикливаюсь на дизайне (посмотрите на этот сайт и убедитесь, что так и есть) и прежде не чувствовал необходимости в использовании нестандартных шрифтов. Конечно, они выглядят немного приятнее и «брендируют» текст. Но для основного текста толку в них мало. Я никогда не оценивал статью (или иначе относился к её содержанию), только потому что для её подачи использовался красивый шрифт. Тем не менее, мне было полностью понятно негативное влияние дополнительных шрифтов на производительность и скорость загрузки страницы, так что, возможно, из-за этого я предвзят.

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

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

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

Некоторые люди как-то неправильно поняли WebAssembly. Есть те, кто считает, что раз браузеры уже поддерживают выполнение WebAssembly (ещё с 2017 года), значит всё уже готово. Даже и близко ещё нет, готов лишь MVP (минимально жизнеспособный продукт). Я могу предположить откуда произрастает корень этого заблуждения: после релиза MVP его разработчики пообещали поддерживать обратную совместимость на уровне «любой написанный сейчас код будет работать и в будущем». Но это ведь не значит, что разработка WebAssembly закончена, совсем нет! Множество фич разрабатывается прямо сейчас и планируется к разработке в ближайшем будущем. И когда они будут реализованы — всё очень сильно изменится.

Все эти фичи можно попробовать представить себе в виде дерева навыков в какой-нибудь игре. У нас есть пару «базовых» (уже реализованные фичи) и целое дерево со множеством веток и листьев, которые будут со временем открываться, давая нам всё больше и больше могущества.

Давайте посмотрим на то, что у нас уже есть сейчас и что нам ещё предстоит открыть.
(Под катом много картинок, трафик)

Всем привет.

Я наконец-то изыскал время и написал вторую часть своей истории об IT-эмиграции. Первую часть можно прочитать тут — История переезда системного администратора в Германию. Часть первая: поиск работы и виза. В этой части я опишу подробно, как мы с сестрой обустраивались на новом месте, какие ошибки при этом допускали и сколько нам эти ошибки стоили.

Итак, поехали.

У нас было два загранпаспорта, национальная виза, контракт на работу, договор на учебу и целое множество вещей всех сортов и расцветок, а также лысый кот, длинный список дел, норовящая развалиться машина и несколько тысяч евро. Не то чтобы всё это было так уж необходимо для переезда в Германию, но если уж начал эмигрировать из России, то становится трудно остановиться. Единственное, что вызывало у меня опасение — это жилье. Ничто в мире не бывает более беспомощным, безответственным и порочным, чем поиск квартиры во Франкфурте. Я знал, что рано или поздно мы столкнемся и с этим.

Об авторе: Рэйчел Эндрю — не только главный редактор журнала Smashing Magazine, но и веб-разработчик, писатель и спикер. Она автор ряда книг, в том числе The New CSS Layout, один из разработчиков системы управления контентом Perch. Пишет о бизнесе и технологиях на своём сайте rachelandrew.co.uk.

Краткое содержание: в этой статье мы рассмотрим свойства выравнивания во Flexbox и некоторые основные правила, как работает выравнивание по основной и поперечной осям.

В первой статье этого цикла я рассказала, что происходит при объявлении свойства display: flex для элемента. Сейчас рассмотрим свойства выравнивания и как они работают с Flexbox. Если вы когда-либо приходили в замешательство, применить align или justify, надеюсь, эта статья многое прояснит!

История выравнивания во Flexbox

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

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

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

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

Привет Всем! Я недавно запустил на GitHub проект JavaScript Algorithms and Data Structures, который содержит примеры классических алгоритмов и структур данных написанных на JavaScript с объяснениями, примерами и ссылками для дальнейшего изучения (в частности на соответствующие YouTube видео).

Основная задача проекта — помочь программистам в изучении и применении алгоритмов и сделать это на JavaScript-е.

С момента появления Node.js диагностика совершенствовалась в несколько этапов, от отладки приложений до глубокого анализа производительности. В этот раз речь пойдет о стратегиях использования таких инструментов, как core dump debuggers, flame graphs, ошибках в production и утечке памяти.


Мы расшифровали для Хабра доклад Николая Матвиенко из Grid Dynamics с нашей конференции HolyJS. Далее повествование идёт от лица спикера.

В связи с последними событиями в России хочу рассказать вам о классном self-hosted VPN-сервере. После простой установки, без особого труда и углубленных знаний вы сможете создавать пользователей, генерировать VPN-профили и смотреть графики использования сети.

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

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

Общий принцип — Не делай брак.
Не бери брак. Не передавай брак.
Тойота.

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

«Почти» по сетке

Сетка призвана упрощать вёрстку и определять местоположение ключевых элементов. В некоторых случаях дизайнеры намеренно отходят от 12-колоночного грида для создания неординарного дизайна.

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

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



Сегодня, во второй части перевода, Томаш Рудски расскажет о наиболее распространённых SEO-ошибках, которым подвержены сайты, основанные на JavaScript, обсудит последствия грядущего отказа Google от механизма AJAX-сканирования, поговорит о предварительном рендеринге и об изоморфном JavaScript, поделится результатами экспериментов по индексированию. Здесь, кроме того, он затронет тему особенностей ранжирования сайтов различных видов и предложит вспомнить о том, что помимо Google есть и другие поисковики, которым тоже приходится сталкиваться с веб-страницами, основанными на JS.

Последние четыре года я работал разработчиком программного обеспечения в Google, но 1 февраля уволился, потому что они не сделали мне подарок на Рождество.

Шучу, на самом деле всё немного сложнее.

Первые два года

Первые два года я любил Google.

Когда при ежегодном опросе сотрудников мне задавали вопрос, вижу ли я себя в Google через пять лет, я отвечал «разумеется, без вариантов».

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


Мой обычный день в Google.
— Ещё тортика, господин Программист? Он бесплатен в любом количестве.
— Не сегодня, Пьер. Я опаздываю на массаж, он тоже бесплатный.

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

Всем привет! Зовут меня Дмитрий Григоров. Работаю фронтедером в Райффайзенбанке в команде RBO PRO. Я расскажу и покажу вам, как можно творчески применять данные возможности CSS. В статье мы рассмотрим следующие темы:

• Фоны и рамки;
• Фигуры;
• Визуальные эффекты.

Продолжение: Рассказ о том, как не дать мне украсть номера кредиток и пароли у посетителей ваших сайтов

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

То, о чём я хочу рассказать, было на самом деле. Или, может быть, моя история лишь основана на реальных событиях. А возможно всё это — выдумка.

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

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

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

Чтобы разобраться в секретах этой магии, мы обратились к эксперту, человеку, который неоднократно залезал внутрь webpack, — Алексею Иванову. Он готов объяснить, как выглядит бандл изнутри, как на него влияют разные настройки, к чему и почему могут привести некоторые из них, а также рассказать, как все это отладить и оптимизировать.


В основе материала — доклад Алексея Иванова на конференции HolyJS 2017, проходившей в Санкт-Петербурге 2-3 июня.