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

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

Наконец случилось чудо. В одну из очередных попыток я нащупал способ, который позволил продолжать развиваться, делать успехи, осознавать их и разжигать мой огонь всё сильнее и сильнее. Сегодня мне сложно представить день, проведенный без английского языка. И мне не хочется говорить без “изучения”, поскольку не сказал бы, что я именно учу. Скорее — постепенно “прошиваюсь” английским, как это обычно происходит с новорожденным детьми, которые постепенно начинают говорить, слушая и наблюдая за своими родителями. В настоящее время мой словарный запас не такой большой: 9 — 12 тысяч слов (зависит от теста). Я свободно смотрю видео на Ютубе разнообразной тематики (видеоуроки, спорт, фитнес, музыка, путешествия, кулинария, обзоры и т.д.), читаю документацию, компьютерную и популярную литературу, публицистику.

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

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

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

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

Привет! Меня зовут Виталий, я тимлид в KTS, и за годы работы я провел больше 100 собеседований.

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

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

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

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

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

GraphQL — невероятная технология, привлёкшая много внимания с тех пор, когда я начал в 2018 году использовать её в продакшене. Вам не придётся долго листать мой блог, чтобы увидеть, как я раньше продвигал её. После создания множества React SPA поверх путаницы нетипизированных JSON REST API технология GraphQL показалась мне глотком свежего воздуха. Я искренне поддерживал хайп вокруг GraphQL.

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

В статье для примеров я буду использовать код на Ruby с превосходной библиотекой graphql-ruby, но я уверен, что многие из перечисленных проблем не зависят от выбора языка/библиотеки GraphQL.

Если вы знаете более качественные решения или способы, напишите мне комментарий.

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

Статья подготовлена по материалам внутреннего митапа по информационной безопасности.

А вы знаете, что миллионы человек тащат лишнюю npm-зависимость зря? Сегодня я покажу вам, как настроить самые что ни на есть "lean" хуки для гита.

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

Если это Senior Full Stack разработчик с опытом администрирования Linux, то установка и настройка конфигов Nginx, PHP-fpm, MariaDB для него не будут проблемой (а может и с Docker даже знаком?). 

Разработчик Middle уровня (особенно без опыта с backend) возможно пользуется одним из готовых решений под Windows/MacOS.

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

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

А потом, еще через некоторое время, из-за разных конфигов или окружения возникали и новые проблемы из разряда “на моем компьютере же все работает”, которые в том числе могут появиться из-за разных настроек готовых сборок.

Занимаясь веб-разработкой в it-компании Intelsy на аутсорс- и аутстафф-проектах, я постоянно подключаю и использую библиотеки. Решил собрать воедино всю накопленную информацию по этой теме и поделиться с теми, кому это может быть нужно: с опытными или начинающими разработчиками, с целыми командами - для облегчения работы и ее усовершенствования.

Погружение в мир контейнеризации с докером — это путь к оптимизации развёртыванию приложений, а также ключ к упрощению жизни разработчиков и системных администраторов. Меня зовут Андрей Аверков, в IT c 2008 начинал пусть с аналитика-проектировщика IT систем, 11 лет в роли разработчика и последние годы на руководящих должностях. Сейчас я тимлид команды разработки из 9 человек в группе компании Кокос. Мы занимаемся созданием и поддержкой CPA платформ (gdeslon.ru, fxpartners.ru, ads.mobisharks.com), а также проектом по генерации лендингов — lpgenerator.ru. У нас большой опыт в разделении продуктов на части, поэтому, сегодня мы собрали самое основное и необходимое для работы с Docker. В нашей шпаргалке вы найдете все необходимое для успешного старта с докером: от базовых концепций и установки до продвинутых техник работы с контейнерами.

Привет, Хабр! Технический долг есть в любом крупном проекте. Он возникает, когда копятся компромиссные решения, проблемы в коде или архитектуре. Важно, что эти решения и проблемы усложняют и удорожают поддержку и обновление кода в будущем. Это своеобразные «проценты». Чем больше долг, тем больше «процентов» приходится платить.

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

На большей части проектов сейчас востребованы знания по тест-дизайну и тестированию API.

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

Считается, что построение CI/CD - задача для DevOps. Глобально это действительно так, особенно если речь идет о первоначальной настройке. Но часто с докручиванием отдельных этапов процесса сталкиваются и разработчики. Умение поправить что-то незначительное своими силами позволяет не тратить время на поход к коллегам (и ожидание их реакции), т.е. в целом повышает комфорт работы и дает понимание, почему все происходит именно так.

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

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

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

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

Мое наблюдение состоит в том, что мы — разработчики и продукты, сильно переусложняем, осознанно или нет, но всякие «„Архитектурные комитеты“, „Планирования“, „Апрувы у 50 отделов“ и деплои в 2-часовые окна, простыни текста сопровождающие простейшие фичи — это просто какой‑то бич современной разработки. Умные дяди с 20 летним опытом за плечами, с невозмутимыми лицами сутки напролет на созвонах обсасывают простейшие вещи вроде замены кнопки. Что это? Следствие усложнения программного обеспечения или засилие не тех людей не на тех местах? Или следствие входа в индустрию новичков, стремящихся простое сделать сложным?

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