С 1 июля 2019 года в России введена обязательная маркировка группы товаров. С 1 марта 2020 года под этот закон должна была попасть обувь. Не все успели подготовиться, и в результате запуск перенесли на 1 июля. Lamoda среди тех, кто успел.

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

Автор статьи, перевод которой мы публикуем сегодня, хочет рассказать о том, как упаковывать в контейнеры Docker веб-приложения, основанные на React, Express и MongoDB. Здесь будут рассмотрены особенности формирования структуры файлов и папок таких проектов, создание файлов Dockerfile и использование технологии Docker Compose.

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

Вероятно, многие из вас слышали о таком новшестве в экосистеме JavaScript, как сервис-воркеры (Service Workers), которые являются ключевым элементом современной веб-разработки. Сервис-воркеры становятся все более востребованными, в первую очередь, благодаря популярности прогрессивных веб-приложений (Progressive Web Applications — PWA).

Когда я впервые услышал о них, я задался вопросом: «Когда мы должны использовать сервис-воркеры? В каким сценариях или контексте мы можем их использовать?»

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

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

Когда в Sports.ru понадобился свой WYSIWYG-редактор, мы решили сделать его на основе библиотеки ProseMirror. Одной из ключевых особенностей этого инструмента является модульность и широкие возможности кастомизации, поэтому с его помощью можно очень тонко подогнать редактор под любой проект. В частности, ProseMirror уже используют в The New York Times и The Guardian. В этой статье мы расскажем о том, как с помощью ProseMirror написать свой WYSIWYG-редактор.

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

Если ваша компания делает несколько продуктов в едином стиле, однажды вам в голову придет идея сделать библиотеку с общим кодом. Например, с UI-компонентами, сервисом авторизации или для работы со сторонними API. Возможно, вы зададитесь вопросами: кто должен поддерживать этот код? Как доносить изменения до пользователей? В конце концов, как вообще заставить их пользоваться вашей библиотекой?

С 2015 года я работаю в Тинькофф в отделе сервисов для бизнеса. За это время наша команда выросла с 3 до 60+ разработчиков, а экосистема Тинькофф Бизнес — с 3 до 50 веб-приложений. На разных этапах нашего развития мы подходили к работе с общим кодом по-разному, об этом я и хочу рассказать в этой статье.

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


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

Привет, Хабр! Представляю вашему вниманию перевод статьи "Everything you need to know about Node.js" автора Jorge Ramón.

В наши дни платформа Node.js является одной из самых популярных платформ для построения эффективных и масштабируемых REST API's. Она так же подходит для построения гибридных мобильных приложений, десктопных программ и даже для IoT.

Я работаю с платформой Node.js более 6 лет и я на самом деле люблю её. Этот пост главным образом пытается быть путеводителем по тому, как Node.js работает на самом деле.

На днях столкнулся с задачей примонтировать в OSX 10.14 iPad в качестве внешнего диска, с возможностью осуществлять файловые операции из консоли. В интернете я нашел довольно много инструкций как это сделать с помощью файловой системы ifuse. К сожалению с iOS 12 ничего не вышло. Устройство было разблокировано, доступ к данным разрешен, но несмотря на это возникала ошибка:

Failed to connect to lockdownd service on the device.
Try again. If it still fails try rebooting your device.

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

Каждый день миллионы разработчиков, создавая свои JavaScript-приложения, обращаются к npm (или к Yarn). Выполнение команд наподобие npm init или npx create-react-app стало привычным способом начала работы над практически любым JavaScript-проектом. Это может быть сервер, клиент, или даже настольное приложение.

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



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

Если вы совершенно не знакомы с npm — знайте, что интересующая нас программа устанавливается вместе с Node.js. Если вы работаете в Windows, то, чтобы воспроизвести кое-что из того, о чём здесь пойдёт речь, рекомендуется установить Git Bash.

Доброго времени суток, хабравчане!

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

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

Сервис с распознаванием лиц «Look-A-Like» обслуживал тысячи пользователей одновременно

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

В рамках работы в MyHeritage мы разработали сервис doppelgänger для Евровидения 2019 года, с помощью которого, загрузив селфи, можно узнать на кого из участников конкурса вы похожи больше всего.

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

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

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

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

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

Предыстория

За последние пару лет я поучаствовал в немалом количестве собеседований. На каждом из них я спрашивал соискателей о принципе единственной ответственности(далее SRP). И большинство людей о принципе ничего не знают. И даже из тех, кто мог зачитать определение, почти никто не мог сказать как они используют этот принцип в своей работе. Не могли сказать, как SRP влияет на код, который они пишут или на ревью кода коллег. Некоторые из них также имели заблуждение, что SRP, как и весь SOLID, имеет отношение только к объектно ориентированному программированию. Также, зачастую люди не могли определить явные случаи нарушения этого принципа, просто потому что код был написан в стиле, рекомендованном известным фреймворком.
Redux — яркий пример фреймворка, гайдлайн которого нарушает SRP.

Представляем вам перевод статьи автора Thomas Lombart, которая была опубликована на сайте medium.freecodecamp.org. Перевод публикуется с разрешения автора.


Пример использования метода reduce для сокращения массива

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

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

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

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

Привет, Хабр! В Iponweb мы не только творим магию с помощью Kubernetes, но и создаем сложные пользовательские интерфейсы. Основной фреймворк, который мы используем, — Angular (а также AngularJs для legacy частей), поэтому удобство разработки для нас — не пустой звук. Мы решили перевести статью Марка Пиесзака, которая призвана повысить удобство отладки JS-кода.

Кеннет Аучнберг, программный менеджер команды VSCode, недавно зарелизил расширение, которое позволяет запускать и отлаживать любое JS-приложение прямо в VSCode IDE!

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

В последнее время веб-разработка разделилась. Теперь мы все не full-stack программисты — мы фронтендеры и бэкендеры. А самое сложное в этом, как и везде, это проблема взаимодействия и интеграции.

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

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

В октябре прошлого года «Мой круг» пригласили на РИФ Воронеж сделать доклад про профессиональное выгорание среди ИТ-специалистов. Как всегда, мы подошли основательно, провели по этой теме соцопрос среди пользователей «Моего круга» и «Хабра» и сегодня рады поделиться своим исследованием. Посмотрим, насколько ИТ-специалисты подвержены выгоранию, какие его признаки выделяют, на какие причины указывают, как выходят из него.

Большинство вопросов анкеты строилось на материалах мастер-класса Наталии Дзеружинской, доктора медицинских наук, профессора, врача-психиатра высшей квалификационной категории, проведённого ею в рамках «Школы менеджеров «Стратоплан»» (видеозаписи 5 мастер-классов школы).

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

Как мы узнали, более 50% ИТ-специалистов имеют опыт профессионального выгорания, причём половина из них прошли через этот опыт 2 и более раза. Для работодателя подобное выгорание сотрудников имеет довольно серьёзные последствия: до 20% сотрудников находятся регулярно в подобном состоянии, только 25% выгорающих остаётся на прежнем месте работы. А значит, довольно большая часть сотрудников работает крайне неэффективно и мешает другим, плюс постоянно нужно вкладывать средства в рекрутинг и адаптацию новых сотрудников взамен выгоревших. Если работодатель научится управлять процессом выгорания, то сможет экономить много материальных и моральных сил для своей компании.