Довольно много уже было сказано о популярности NodeJS. Рост количества приложений очевиден – NodeJS довольно прост в освоении, имеет огромное количество библиотек, а также динамично развивающуюся экосистему.

Мы подготовили рекомендации для NodeJS разработчиков, основываясь на OWASP Cheat Sheets, которые помогут вам предусмотреть проблемы с безопасностью при разработке приложений.

Рекомендации к безопасности NodeJS приложений можно разделить на следующие категории:

• Безопасность при разработке приложения;
• Безопасность сервера;
• Безопасность платформы;

DevOps- и SRE-инженеры уже, наверное, не раз слышали о Prometheus.

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

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

Что такое Prometheus?
Зачем он нужен?
Чем он отличается от других систем?

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

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

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

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

1. Вы создаете многократно используемый фрагмент кода (это может быть функция, React компонент, React хук и тд) и делитесь им (для совместной работы или публикуя в опенсорс).
2. Кто-то обращается к вам с просьбой добавить новый функционал. Ваш код не поддерживает предложенный функционал, но мог бы, если бы вы сделали небольшое изменение.
3. Вы добавляете новый аргумент/проп/опцию в свой код и в связанную с ним логику для поддержания работы этого нового функционала.
4. Повторите стадии 2 и 3 несколько раз (или много-много раз).
5. Теперь ваш повторно используемый код тяжело использовать и поддерживать.

Что именно делает код кошмаром для использования и поддержки? Есть несколько аспектов, которые могут сделать ваш код проблемным:

Каков наилучший способ беспроблемного увеличения параллелизма в Node.js-сервисе, который используется в продакшне? Это — вопрос, на который моей команде понадобилось ответить пару месяцев назад.

У нас запущено 4000 контейнеров Node (или «воркеров»), обеспечивающих работу нашего сервиса интеграции с банками. Сервис изначально был спроектирован так, что каждый воркер был рассчитан на обработку только одного запроса за раз. Это снижало воздействие на систему тех операций, которые могли неожиданно заблокировать цикл событий и позволяло нам игнорировать различия в использовании ресурсов различными подобными операциями. Но, так как наши мощности были ограничены одновременным выполнением лишь 4000 запросов, система не могла достойно масштабироваться. Скорость выдачи ответов на большинство запросов зависела не от мощности оборудования, а от возможностей сети. Поэтому мы могли бы улучшить систему и снизить стоимость её поддержки в том случае, если бы нашли способ надёжной параллельной обработки запросов.



Занявшись исследованием этого вопроса, мы не смогли найти хорошего руководства, в котором речь шла бы о переходе от «отсутствия параллелизма» в сервисе Node.js к «высокому уровню параллелизма». В результате мы разработали собственную стратегию перехода, которая была основана на тщательном планировании, на хороших инструментах, на средствах мониторинга и на здоровой дозе отладки. В итоге нам удалось повысить уровень параллелизма нашей системы в 30 раз. Это эквивалентно снижению затрат на поддержку системы примерно на 300 тысяч долларов в год.

Данный материал посвящён рассказу о том, как мы увеличили производительность и эффективность наших Node.js-воркеров, и о том, что мы узнали, пройдя этот путь.

1. Клон Notion

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



www.notion.so

Чему вы научитесь, создавая клон Notion:

• HTML Drag and drop API. Пользователь может «схватить мышкой» draggable элемент и поместить его в droppable зону.
• Как синхронизировать в режиме реального времени данные между компьютером и смартфоном.
• Мы позволяем пользователям создавать, читать, обновлять и удалять записи, тем самым мы тренируем CRUD-навыки.

Привет, Хабр! представляю вашему вниманию перевод статьи «How to make your HTML responsive by adding a single line of CSS» автора Per Harald Borgen.



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

Самое крутое, что для добавления отзывчивости потребуется написать одну строчку кода на CSS

Привет! Я — Ваня, лид платформенной команды в Тинькофф Бизнес.

Мое любимое занятие — открывать вкладку DevTools и проверять, сколько весят артефакты сайта. В этой статье расскажу, как мы сократили вес приложения на 30% силами платформенной фронтенд-команды за один день без изменения кода сайта. Никаких хитростей и регистраций — только nginx, docker и node.js (опционально).

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

• Добавление в имена файлов информации о версии содержащихся в них данных (обычно — в виде хэша данных, находящихся в файлах).
• Установка HTTP-заголовков Cache-Control: max-age и Expires, управляющих временем кэширования материалов (что позволяет исключить повторную валидацию соответствующих материалов для посетителей, возвращающихся на ресурс).

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

filename: '[name]-[contenthash].js'

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

Сегодня мы публикуем первую часть перевода материала, который посвящён созданию собственных синтаксических конструкций для JavaScript с использованием Babel.

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

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



Меня зовут Катя Гаврилова, я основатель рекрутингового агентства DigitalHR. Однажды я выступала на Saint TeamLead Conf в 2018 году, и мой доклад «Роль тимлида в рекрутинге» попал в топ-5 лучших. А уже на Moscow TeamLead Conf доклад «Мало опыта — много собеседований: как проводить интервью, чтобы от вас не скрывали правду» не прошел в топ, но я до сих пор получаю на него хорошие отзывы от разработчиков, поэтому решила поделиться его версией в текстовом варианте. Целевая аудитория — тимлиды и CTO, которые недавно стали подбирать сотрудников к себе в команду.

Эта статья для тех, кто хочет свой запустить it-стартап и понять сколько денег и времени нужно на MVP (минимальную версии), чтобы протестировать идею или сделать рабочий прототип для презентации инвесторам.

После прочтения данной статьи:

• Вам не нужно будет отправлять 10-20 заявок в студии и фрилансерам, общаться с ними чтобы понять цены и как происходит ценообразование.
• Вы поймете почему такой большой разброс цен от 100 тыс руб до 5 млн руб за проектирование и дизайн MVP онлайн-сервиса, какие факторы на это влияют
• У каких специалистов или студий вы можете заказать разработку «под ключ» или отдельно проектирование и дизайн веб-сервиса.
• Вы сможете сами посчитать примерную стоимость и срок под свои задачи через калькулятор в таблице exel.

Для начала перейдём к некоторым соглашениям и обозначим термины.

Интересный факт – 20% населения планеты хотя бы на каком-то уровне говорит на английском языке, а его носителями являются всего 5% населения. При этом, этот язык – пожалуй, главный в интернете. По статистике, на нем написано 55,5% всего размещенного онлайн-контента.

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

Из современного конструктора LEGO можно собрать только одну модель игрушки, например, самолет. Кастомизировать? Можете поменять местами кресла пилотов — вот и вся кастомизация. Лет 30 назад из конструктора можно было собрать примерно все, от самолета до грузовика, при том же количестве деталей как и в современных. Создатели большинства современных методологий в детстве играли в старое Лего. Те, кто сейчас пользуется методологиями — играли уже в современный. Разница в инженерных практиках огромна.



Под катом Филипп Дельгядо (dph) расскажет об инженерном подходе к формированию методологии. Все проекты и команды разные, а лидеры — неповторимы. Подогнать одну методологию под всех не получится — таких просто нет. Придется брать конструктор и строить из него что-то свое, уникальное. В расшифровке одного из лучших докладов TeamLead Conf не будет секретных тайн шаолиньских монахов — только банальности, проверенные опытом. Нас ждет каталог деталей методологии разработки, на что обращать внимание при ее конструировании и внедрении, правила перестраивания методологий. Для всех идей приведены реальные примеры из опыта Филиппа. За свою карьеру он попробовал все — от Visual Basic до хардкорного SQL, разрабатывал крупнейший в России букмекерский движок и Яндекс.Деньги, а сейчас работает над нагруженными проектами на Java. Регулярно делает доклады на разных конференциях, в том числе и на HighLoad++.

Есть в графиках что-то магическое. Изгиб кривой мгновенно раскрывает всю ситуацию — историю развития эпидемии, паники или периода процветания. Эта линия просвещает, пробуждает воображение, убеждает.
― Генри. Д. Хаббард

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

Вряд ли кто-то станет отрицать, что в современном HTML5 вебе JavaScript — самая универсальная и простая технология для визуализации данных. Так что, если вы занимаетесь фронтенд-разработкой, то вы, скорее всего, либо уже имели дело с созданием JS чартов, либо столкнетесь с этим в (скором) будущем.

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



Что ж, приступим: вот лучшие JS библиотеки для визуализации данных!

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

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



Здесь представлено 13 однострочников. Примеры подготовлены с использованием Node.js v11.x. Если вы будете использовать их в другой среде — это может повлиять на их выполнение.

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

Друзья, вот и снова настала весна! Прекрасная летняя погода всё ближе. Продуктивные будни принесли новые результаты, а это значит, что пора снова встретиться!

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

React Russia 2019 – это конференция профессиональных разработчиков, использующих React.js и React Native в России. Являясь логическим продолжением всех наших конференций-митапов React Moscow и React SPB , проводимых с 2016 года при поддержке крупнейших компаний на рынке, мы встречаемся, чтобы поделиться идеями, представить и рассказать о новых решениях и технологиях, поделиться опытом и в совместном общении сделать нашу работу ещё более продуктивной, приятной и эффективной.

Когда и где

1 июня 2019 г. в 10:00
Москва, Кутузовский проспект 32к1, Сбербанк Agile Home

Программа

Привет! Я хотел сказать, что вчера вышла третья наша книга, и тоже очень помогли посты с Хабра (а частично и вошли). История такая: на протяжении примерно 5 лет к нам подходили люди, которые не умели в проектное мышление, не понимали разные вопросы бизнеса и задавали одни и те же вопросы.

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

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

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

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