Frontend developer (React, MobX)
Разработка приложений и написание кода есть процесс достаточно увлекательный и результатом такой интересной разработки может стать беспорядочный код, представляющий собой спагетти-архитектуру, в которой сложно разобраться, и которая нуждается в некоторой структуризации.
Привет! Меня зовут Виталий, я тимлид в 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 летним опытом за плечами, с невозмутимыми лицами сутки напролет на созвонах обсасывают простейшие вещи вроде замены кнопки. Что это? Следствие усложнения программного обеспечения или засилие не тех людей не на тех местах? Или следствие входа в индустрию новичков, стремящихся простое сделать сложным?
В статье мы разберем что такое „переусложнение“, дадим ему определение и на реальных примерах разберем во что это выражается и как с этим бороться.
Я поработал и с мобилкой и бекэндом и фронтендом и теперь задумался, а куда же двигаться дальше... Если кого-то посещают похожие мысли или просто интересно, прошу под кат.
С развитием веба сайты превратились в сложные приложения, которыми ежедневно пользуются десятки и сотни миллионов людей: почта, облачные хранилища, соцсети, маркетплейсы, стриминговые платформы и т. д. И каждое из них должно работать корректно. Как это сделать? Конечно писать хороший код, а потом и тестировать его. Хотя кто‑то обходится без тестов, тем не менее тестирование — важная часть инженерных практик наравне с мониторингом. Оно помогает нам заблаговременно находить и исправлять баги (или незапланированные фичи) в приложениях. Основная цель тестирования — получить гарантию корректной работы любого ПО .
При этом тестировать современный фронтенд сложно: неуправляемая асинхронность (событийная модель браузера), различие браузеров, тяжелое окружение — это лишь малая часть сложностей. Можно ли все возложить на ручных тестировщиков или исправлять баги после жалоб пользователей? Однозначно нет. В большинстве случаев такой подход в скором времени приведет к оттоку пользователей: не все пишут о багах, просто уходят к конкурентам. Безусловно, ручное тестирование остается важным элементом разработки, но тестировщики не могут держать сотни или тысячи сценариев, которые нужно пройти перед релизом или запуском новой фичи. Так где нам получить гарантии, что ключевые сценарии приложения работают корректно? Автоматическое тестирование.
Всем привет! Меня зовут Миша, работаю фронтэнд‑разработчиком в VK в команде Облака Mail.ru, и я хочу разобрать различные виды тестов, дать их сравнительный анализ и применимость. Сразу скажу, тут не будет практики написания тестов. Потому что это нереально сделать внутри одной статьи, необходимо разобрать: теорию тестирования, классов эквивалентности, различие подходов/методов к тестированию, комбинаторику состояний, правильное использование моков и стабов, понимание чистых функций, знание архитектуры приложения. Поэтому предлагаю сконцентрироваться на видах тестирования и начать с «идеального теста».
Всем доброго дня. Решил написать историю своих мучений, надеюсь кому-то поможет не повторить моих ошибок.
Это небольшой пост про очередной вид мошенничества и способы борьбы с ним.
Для человека информационно чистоплотного я ничего нового не скажу. Но все-таки считаю важным об этом рассказать и предложить способы проверки. В целом типичный телефонный развод, но удивила таргетированность: выяснить где человек работал, выяснить кто является руководителем компании, построить схему так, чтобы она вызывала минимум подозрений...
Итак, сегодня мне написал человек, имя которого совпадает с СЕО с моей работы, в которой я работал пару лет назад. И сообщил, что в компании произошла утечка данных, в связи с чем начато расследование ФСБ и со мной свяжется сотрудник, чтобы провести проверку в моем отношении, т.к. проверяют всех - и текущих сотрудников и бывших.
Также просит не распространять информацию среди сотрудников компании, т.к. это помешает проведению проверки.
Это пахнет. Но может быть и правдой. И как быть? Если это настоящая проверка - действительно не стоит лишний раз болтать. Но вдруг это проверка не настоящая?
Целью этой статьи является изучение архитектурного паттерна Entity Component Systems на практике. Я подготовил пошаговое руководство по созданию небольшой игры, с помощью которого вы познакомитесь с основными принципами разработки на Ecs.
