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

Ох, не зря в названии намёк на нетленку Фаулера. И когда фронтенд-приложения успели стать настолько сложными, что мы начали рассуждать о высоких материях? Node.js… фронтенд… погодите, но Нода же на сервере, это бэкенд, а там ребята и так всё знают!



Давайте по порядку. И сразу небольшой дисклеймер: статья написана по мотивам моего выступления на Я.Субботнике Pro для фронтенд-разработчиков. Если вы занимаетесь бэкендом, то, возможно, ничего нового для себя не откроете. Здесь я попробую обобщить свой опыт фронтендера в крупном энтерпрайзе, объяснить, почему и как мы используем Node.js.

Доброго времени суток, друзья!

Представляю Вашему вниманию перевод статьи «What JavaScript Developers Should Know About Curl» автора Valery Karpov.

Curl — это популярный инструмент командной строки, часто используемый для отправки HTTP-запросов. Curl поддерживает большое количество протоколов, однако как Node.js-разработчик вы, скорее всего, будете использовать его для отпраки http-запросов к RESTful API.

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

Если вы изучаете веб совсем недавно, но уже успели увидеть различные красивые эффекты на сайте, по типу системы частиц или какие либо игры разработанные на canvas'e и вас это заинтриговало, но изучать что-то новое очень страшно, то я вам готов продемонстрировать, как за 50 строк js кода можно сделать что-то интересное на canvas'e.



Скажу сразу, я хочу объяснить логику работы с canvas'ом. Код очень простой, я надеюсь, это подтолкнет вас к изучению такого инструментария как canvas. А так же это очень хорошая практика для начинающего JS программиста.

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


Что нам нужно сделать?

Поток — это концепция, которая была сначала реализована в UNIX системах для передачи данных из одной программы в другую в операциях ввода/вывода. Это позволяет каждой программе быть очень специализированной в том, что она делает — быть независимым модулем. Сочетание таких простых программ помогает в создании более сложных систем путем «объединения» их в цепочку вызовов.

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

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

Модуль stream предоставляет базовый API по работе с потоками в Node.JS. Документации Node.JS вполне достаточно, чтобы разобраться в данном вопросе, но мы попытаемся составить что-то вроде шпаргалки с пояснениями некоторых моментов.

Всем добрый день!

Бывало ли у вас такое, что вы долго думали над какой-то рабочей (или личной ситуацией), а потом вдруг раз! и все как будто раскладывалось по полочкам? У нас такое бывало неоднократно.

Вместо пролога. Более того, это в некотором смысле наша профессия — раскладывать по полочкам сложные ситуации. Потому что последние 7 лет мы с коллегами занимаемся обучением IT-специалистов и руководителей навыкам управления людьми и тому, что называется soft skills.

За время работы у нас накопилось какое-то количество инструментов, которыми мы решаем разные управленческие кейсы. И этими инструментами мы и задумали поделиться.

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

Все инструменты, о которых мы будем писать, очень простые. Либо это матрицы 2 на 2, либо 4 вопроса, либо что-то в таком же духе. Поскольку мы много работаем с менеджерами, то обнаружили, что матрицы 3 на 3 некоторым менеджерам уже сложновато воспринимать (хей, мы сами были менеджерами, знаем о чем говорим :)), а 2 на 2 — в самый раз, отлично заходят.

Какие-то инструменты придумали мы, какие-то позаимствовали у других умных людей, какие-то не знаем, откуда появились в нашей голове. Но они все полезные, да.

Являются ли эти инструменты серебряными пулями? Ясен пясен, нет. Но они совершенно точно помогают прояснить ситуацию, навести дистинкции и понять, в какую сторону думать. А решения все равно придется придумывать вам. До тех пор, пока не появится, наконец, справочник юных сурков по менеджменту.

Итак, довольно лишних слов, давайте перейдем к первому инструменту (всего мы планируем разобрать около 15 разных полезных концептов):

Привет, Хабр!

Меня зовут Артём Сайгин, я веду телеграм канал Growth Lab, в котором делюсь опытом роста IT-продуктов.

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

Также в конце статьи вы найдёте список книг по SEO, бесплатные курсы, чек-листы SEO-аудита, SEO-сервисы и расширения.

Добавляйте в закладки, чтобы не потерять.



Отмечу, что список материалов будет пополняться. Если я не добавил стоящий материал, свяжитесь со мной — добавлю.

Приступим!

Программирование на стороне клиента давно стало нормой, а объем JavaScript кода и его сложность постоянно растут. Часто тестирование применяется только на серверной стороне, но при этом не стоит забывать о тестировании клиентского кода. Для тестирования JavaScript как на стороне клиента, так и для Node.js можно с успехом применять Jasmine.

Jasmine это BDD фреймворк (Behavior-Driven Development — Разработка на Основе Поведений) для тестирования JavaScript кода, позаимствовавший многие черты из RSpec.

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

Как этого достичь? Что мы можем сделать, чтобы оптимизировать время сборки?

Эта статья — обзор существующих в экосистеме webpack инструментов для ускорения сборки, опыт их применения и советы.

Оптимизации размера бандла и производительности самого приложения в этой статье не рассматриваются.

Axios — это широко известная JavaScript-библиотека. Она представляет собой HTTP-клиент, основанный на промисах и предназначенный для браузеров и для Node.js. Если вы работали в последние несколько лет JavaScript-программистом, то вы, совершенно определённо, этой библиотекой пользовались. В октябре 2019 года пакет Axios был загружен из npm 25 миллионов раз. Кажется, что будущее Axios безоблачно. Но что если я скажу вам, что Axios — это мёртвый проект. Именно этому было посвящено одно обсуждение на Reddit. А именно, речь идёт о следующем:

• В GitHub-репозитории Axios наблюдается весьма низкий уровень активности разработчиков.
• Проблемы и PR игнорируются.
• Команда разработчиков хранит молчание.

Ситуацию ухудшает и широко обсуждаемая уязвимость. Об этой уязвимости сообщено 2017 году. Авторы проекта игнорировали её более двух лет.

Когда библиотека Axios стала популярной, в браузерах не было API, реализующего HTTP-клиент, основанный на промисах. Стандартный интерфейс XML HTTP Request (XHR) был неудобным, работать с ним было тяжело. Разработчики с радостью приняли Axios из-за того, что эта библиотека облегчала им жизнь.



В 2015 вышел API Fetch. Почему же мы, в 2019 году, до сих пор используем Axios? Давайте сравним эти две технологии.

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

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

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

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

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

Взявшись за написание небольшого, но реального и растущего проекта, мы «на собственной шкуре» убедились, насколько важно то, чтобы программа не только хорошо работала, но и была хорошо организована. Не верьте, что продуманная архитектура нужна только большим проектам (просто для больших проектов «смертельность» отсутствия архитектуры очевидна). Сложность, как правило, растет гораздо быстрее размеров программы. И если не позаботиться об этом заранее, то довольно быстро наступает момент, когда ты перестаешь ее контролировать. Правильная архитектура экономит очень много сил, времени и денег. А нередко вообще определяет то, выживет ваш проект или нет. И даже если речь идет всего лишь о «построении табуретки» все равно вначале очень полезно ее спроектировать.

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

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

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.

CSS Refresher

Это большая коллекция практических советов и заметок по вёрстке. Своеобразная памятка для тех, кто каждодневно использует CSS. Освещаются самые разные темы, от деталей поведения плавающих элементов до использования SVG и спрайтов. Проект постоянно обновляется, активное сообщество github также принимает в нем участие, там добавляются интересные замечания, о которых, возможно, вы и не слышали.

От переводчика

Приветствую всех, меня зовут Максим Иванов, и сегодня я подготовил для вас перевод заметок разработчика из Сан-Франциско Васанта Кришнамурти (Vasanth Krishnamoorthy) «CSS Refresher». Web-программирование одна из самых быстро развивающихся отраслей в наше время. Казалось бы, возьми какой-нибудь видеокурс на tuts+ и освой html-верстку, однако, как говорил разработчик Opera Software Вадим Макеев, выступая на конференции CodeFest, они все равно это делают плохо. Но давайте посмотрим, может мы итак все это знаем.

Содержание

1. Позиционирование (position)
2. Отображение элемента в документе (display)
3. Плавающие элементы (float)
4. CSS селекторы
5. Эффективные селекторы
6. Переотрисовка и перерасчет
7. CSS3 свойства
8. CSS3 медиа-запросы
9. Адаптивный web-дизайн
10. CSS3 переходы
11. CSS3 анимации
12. Масштабируемая векторная графика (SVG)
13. CSS спрайты
14. Вертикальное выравнивание
15. Известные проблемы

// <какой-то код>
 
int main ()
{
        constexpr int a = f ();
        constexpr int b = f ();
 
        static_assert (a != b, "fail");
}

Можно ли в приведенном выше фрагменте вместо комментария вставить такое определение f (), чтобы a получила значение, отличное от b?

“Разумеется, нет!” — скажете вы, немного подумав. Действительно, обе переменные объявлены со спецификатором constexpr, а значит, f () тоже должна быть constexpr-функцией. Всем известно, что constexpr-функции могут выполняться во время компиляции, и, как следствие, не должны зависеть от глобального состояния программы или изменять его (иными словами, должны быть чистыми). Чистота означает, что функция при каждом вызове с одними и теми же аргументами должна возвращать одно и то же значение. f () оба раза вызывается без аргументов, поэтому должна оба раза вернуть одно и то же значение, которое и будет присвоено переменным a и b… правильно?

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

Я ошибался.

Внимание! Реклама! Пост оплачен Капитаном Очевидность!

Ниже под катом вы найдёте 15 пунктов, описывающих правильную организацию ресурсов, доступных по протоколу HTTP — веб-сайтов, «ручек» бэкенда, API и прочая. «Правильный» здесь означает «соответствующий рекомендациям и спецификациям». Большая часть ниженаписанного почти дословно переведена из официальных стандартов, рекомендаций и best practices от IETF и W3C.



Вы не найдёте здесь абсолютно ничего неочевидного. Нет, серьёзно, каждый веб-разработчик теоретически эти 15 пунктов должен освоить где-то в районе junior developer-а и/или второго-третьего курса университета.

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

Вступление

Давно хотел написать статью про образование в Computer Science, но руки не доходили. Решил все-таки это наконец сделать. Итак, о чем пойдет речь? Речь о том, что из себя представляет диплом MSc Computer Science топовых университетов США (во всех подробностях, включая основные курсы, книги и проекты) и как ему соответствовать.

Почему именно MSc? Это — некая развилка: с одной стороны после MSc — вы уже готовый к жизни инженер (да, речь идет о инженерной подготовке, как мне кажется это самое больное место в нашей системе образования), с другой — можно спокойно идти по пути PhD. Как известно, в PhD программу можно попасть и не особо умея программировать — особенно это касается теоретического Computer Science. С другой стороны найти работу программиста тоже дело не очень сложное, и часто не требует мощного образования. Но достигнув уровня MSc — вы получаете возможность разбираться как во всех новый идеях в Computer Science, так и возможность их воплотить в практику. То есть с одной стороны круто разобраться в каком-нибудь deep learning и сделать в нем что-то новое, а также взять и написать свою операционную систему (кто так сделал?). Причем вы не зажаты в рамки узкой специализации (если конечно продолжаете учиться). То есть вы теперь — универсальный солдат, готовый на все.

Надеюсь что эта статья будет полезна:
1. Студентам, которые хотят соответствовать высоким стандартам топ вузов США, или собирающиеся туда в аспирантуру по Computer Science
2. Профессионалам, которые хотят закрыть «дыры» и пробелы
3. Может кто-то из преподавателей возьмет на заметку для своих курсов.
4. Студентам, аспирантам американских вузов — хотелось бы тоже получить фидбэк, особенно касается последних трендов в образовании

Что же здесь будет написано? Минимум философии и общих мыслей: конкретная программа undergraduate и graduate курсов, конечно из дисциплин наиболее мне близких. Все курсы были лично прочувствованы на собственной шкуре, по этому и пишу. (Я пытался записаться на все интересные курсы, которые были, но мой основной упор — системное программирование, базы данных и искусственный интеллект. Отсюда конечно некий bias, но пытаюсь предложить более-менее универсальную программу).

В этой статье я кратко расскажу, как именно преобразуются координаты точек при повороте камеры в 3D играх, css-преобразованиях и вообще везде, где есть какие-то вращения камеры или предметов в пространстве. По совместительству это будет кратким введением в линейную алгебру: читатель узнает, что такое (на самом деле) вектор, скалярное произведение и, наконец, матрица поворота.

Синтаксис CSS несложен, и для понимания его совсем не нужно иметь степень доктора в области IT. Однако, это один из немногих популярных языков, который не является логичным в самом прямом смысле этого слова. В отличие от других языков веб-программирования, таких как JavaScript и PHP, в CSS проблемы не решаются с помощью обычной логики. Алгоритмы типа «если X, то сделать Y, в противном случае сделать Z» или «выбрать все Y, затем сделать с ними X» не могут быть осуществлены в таком языке, как CSS. Проще говоря, это язык, созданный для оформления, язык для дизайнеров, а не девелоперов. Некоторые из опытных программистов, с которыми я работал, именно по этой причине тратили много усилий на то, чтобы освоить CSS.

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

В предпраздничные дни выдалась минутка, захотелось отвлечься — окунуться в мир занятных идей, отстранясь от забот праздника. В итоге, — идея: не ожидая пришествия html5, — смастерить спойлер «по клику» посредством css и HTML.