Итак, по реакции публики я увидел, что первое действие вполне «зашло», поэтому продолжу. Общий хронометраж моих разговоров составил (по «действиям»): 7:10, 18:23, 42:14, 3:51. Непродолжительность финального фрагмента связана с тем, что я понял, что с той стороны находятся исключительно непробиваемые личности. Я мог бы еще часами «ходить» по городу, но мои силы уже были на исходе. Поэтому я сознался в содеянном сам и попрощался.

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

Каждый слышал о современных телефонных мошенниках. Многие слышали о том, как вроде бы не глупые знакомые попадались на их удочки. Как не стать жертвой? Наверное, было бы полезно заранее знать сценарии таких «разводов», чтобы быть морально готовым. Не только не попасться на крючок. Но и суметь «поддержать беседу». Зачем отпускать сразу таких собеседников? Пускай немного помучаются, потратят время на, кажется, уже почти готовую жертву. Быть может, этой тратой времени вы сможете спасти пару реальных жертв этих поганцев.

Такие звонки мне поступают иногда. И надо сказать, всегда я сразу посылал таких звонящих. Но после прошлого, который случился примерно месяц назад, подумал, правильно ли я делаю? Решил попробовать в следующий раз сделать над собой усилие, провести более подробное «интервью». И вот, сегодня этот следующий раз произошел.

В предыдущей статье мы научились запускать Hello World ядро и написали пару функций для работы со строками. Теперь пришло время расширить библиотеку С чтобы можно было реализовать kprintf и другие необходимые функции. Поехали!

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

Быстро сказка сказывалась, да долго дело делалось.

Более полутора лет назад, захотелось собрать собственный NAS, а началом, для сбора NASа, послужило наведение порядка в серверной комнате. При разборе кабелей, корпусов, а также, переселении лампового 24 дюймового монитора от HP на свалку и прочего, прочего, был найден кулер от Noctua. Из которого, путём неимоверных усилий, изъял два вентилятора – 120 и 140 мм. 120 мм вентилятор почти сразу же, уехал в домашний сервер, так как, тихий и мощный. А вот, что делать со 140 мм вентилятором, мыслей пока не было. Поэтому, отправился он прямиком на полку – в запас.

В инструментах разработчика браузера хром есть вкладка «Audit». На ней расположился инструмент который называется Lighthouse, служит он для анализа насколько хорошо сделано веб приложение.


Недавно я решил протестировать одно приложение и ужаснулся результатам. Сразу по нескольким разделам оценка находилась в красной зоне. Я принялся изучать что же с моим приложением не то. И нашел в результатах анализа большой список очень полезных рекомендаций, выполнил их и получил 500 баллов. В результате приложение стало запускаться значительно быстрее, а я пересмотрел несколько концепций относительно метода построения приложений. А в этой статье я хочу поделиться самыми интересными решениями к которым я пришел.

В этом руководстве мы научимся использовать видео в Вебе, как это принято в 2019. Chrome и Firefox начали поддерживать новый кодек AV1 — для них видео можно сделать в два раза меньше.

Отдельно поговорим, как заменить GIF на видео в AV1 и H.264 — тогда его размер упадёт в 20-40 раз.



YouTube уже использует его в TestTube. Netflix заявил, что AV1 будет «их основным кодеком следующего поколения».

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

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

Сложилось так, что потребовалось контролировать около 30 VDS-ок на Debian, которые мне благополучно «передали» под надзор (а я как бы больше программист, чем *nix-администратор). И первая мысль, что пришла в голову после базовых операций по смене и проверке доступов, была «Если я что-то упустил, хочу оперативно знать о подключениях». Есть рецепты (в том числе на Хабре) связывания события авторизации по SSH и почтовых уведомлений, которые я использовал как базу, но мне хотелось все-таки оперативности и некоторой информативности. В общем получил я в итоге вот такую «систему», которая в течение месяца вполне успешно работает и сообщает мне о любом факте авторизации.

1. С помощью мануалов по API-телеграм получен токен и чат-ид для бота уведомлений (тут распространяться не буду, это все легко и просто находится в 1-2 строке поисковика).
2. Создано два скрипта, код от которых будет размещен ниже. В принципе можно все сунуть и в один файл, но т.к. я хотел модульности, то я вынес в отдельный скрипт функцию отправки уведомления в телеграм-бота.
3. В два файла настроек добавил вызов скрипта регистрации события входа на сервер и перезапустил службу SSH.

На все про все уходит минут 5-10, не больше. Ну а теперь собственно техничка.

PS. Все выполнялось на Debian9 x 64 (если это важно).

Предисловие

Мое веб-приложение хранит данные в localStorage. Это было удобно, пока не захотелось, чтобы пользователь, заходя на сайт с разных устройств, видел одно и то же. То есть, понадобилось удаленное хранилище.

Но приложение «хостится» на GitHub Pages и не имеет серверной части. Я решил не делать сервер, а данные хранить у третьей стороны. Это дает существенные преимущества:

1. Не нужно платить за сервер, не болит голова о его стабильности и доступности.
2. Меньше кода, меньше ошибок.
3. Пользователю не нужно регистрироваться в моем приложении (это многих раздражает).
4. Приватность выше, и пользователь знает, что его данные хранятся в месте, которому он, скорее всего, доверяет больше, чем мне.

Сначала выбор пал на remoteStorage.js. Они предлагают открытый протокол обмена данными, достаточно приятное API, возможность интеграции с Google Drive и Dropbox, а также свои сервера. Но этот путь оказался тупиковым (почему — отдельная история).

В итоге решил использовать Google Drive напрямую, и Google API Client Library (далее GAPI) как библиотеку для доступа к нему.

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

Надеюсь, данная статья сэкономит вам время, если вы решите использовать Google Drive в вашем приложении.

Всем привет!

Продолжаем цикл статей по разработке браузерного движка.

В данной статье я расскажу как создать самый быстрый HTML-парсер c DOM. Мы рассмотрим HTML спецификацию и чем она плоха относительно производительности и потребления ресурсов при разборе HTML.

С данной темой я докладывался на прошедшем HighLoad++. Конференцию не каждый может посетить, плюс в статье больше деталей.

Я предполагаю, что читатель обладает базовыми знаниями об HTML: теги, ноды, элементы, пространство имён.

Верстать электронные письма — это боль. Верстать и тестировать адаптивные письма с интерактивом (например, с формами и слайдерами) — боль в квадрате. Однако, не всё не так плохо, если выбрать правильные инструменты. В статье расскажу об email-фреймворках — MJML и Foundation for Emails — и моих любимых ресурсах для тестирования рассылки — Litmus и Email On Acid.

Как известно, HTTP 1.1 — это текстовой протокол передачи данных. HTTP сообщения закодированы, используя ISO-8859-1 (которую условно можно считать расширенной версией ASCII, содержащей умляуты, диакритику и другие символы, используемые в западноевропейских языках). При этом в теле сообщений можно использовать другую кодировку, которая должна быть обозначена в заголовке «Content-Type». Но что делать, если нам необходимо задать non-ASCII символы не в теле сообщения, а в самих заголовках? Наверное, самый распространенный кейс — это проставление имени файла в «Content-Disposition» заголовке. Это, казалось бы, довольно распространенная задача, но ее реализация не так очевидна.

TL;DR: Используйте кодировку, описанную в RFC 6266, для «Content-Disposition» и преобразуйте текст в латиницу (транслит) в остальных случаях.

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



PDF-версия документа состоит более чем из 120 страниц, содержит оглавление, немного картинок и всё необходимое форматирование. Просто закидывайте файлик в читалку и готово. Или в папочку с литературой. Или… решать вам.

Скачать PDF-версию [ 1.8 Мб ]

Сегодня мы хотим представить вашему вниманию новое руководство того же автора, посвящённое JavaScript.


Мы планируем это руководство перевести, но, прежде чем приняться за работу, хотели бы предложить вам поучаствовать в небольшом опросе

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

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

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

Привет, Хабр! Представляю вашему вниманию перевод статьи "Wormholes in JavaScript" автора Mathius Buus.

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

Однако, такая абстракция довольно обманчива. Она уводит нас от понимания того, что компьютер обрабатывает разные математические операции с разной скоростью. Если вы пишете на JavaScript (или на любом другом языке) и заботитесь о производительности написанных вами алгоритмов, очень важно понимать как работают компьютеры под капотом.

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

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

Вероятно, вы уже знакомы с блоковой моделью CSS для обычных элементов. Давайте начнем с аналогичного «общего обзора» для CSS Grid:


В основе структуры CSS Grid находится основной контейнер, представляющий собой обычный div, имеющий margin, border и padding. Для создания CSS grid контейнера добавим свойство display: grid. Элементы сетки — это потомки, размещенные внутри родительского контейнера. Они обычно определяются как список, описывающий header, sidebar, footer или другие аналогичные элементы макета сайта, зависящие от его дизайна.

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

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

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

Сегодня мы представляем вашему вниманию перевод материала, в котором рассмотрены опенсорсные JavaScript-библиотеки для визуализации данных.

Мы попробуем разобраться — как можно снизить нагрузку на серверное железо, обеспечив при этом максимальную производительность Web-приложения.

В разработке больших высоконагруженных проектов с огромным онлайном часто приходится думать, как снизить нагрузку на сервера, особенно при работе в webSocket'ами и динамически изменяемыми интерфейсами. К нам приходит 100500 пользователей и мы имеем 100500 открытых соединений по сокетам. А если каждый из них откроет по 2 вкладки — это уже *201000 соединений. А если пять?

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

На прошлой неделе были опубликованы два новых стандарта для беспарольной аутентификации на сайтах, в мобильных и веб-приложениях: WebAuthn API и CTAP. Оба были одобрены Microsoft, Mozilla и Google.

Подробнее об них расскажем ниже.