А вы знаете, что миллионы человек тащат лишнюю 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. В этой статье я хочу поделиться этим списком, возможно кому-то это поможет быстрее погрузиться в эту тему.

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

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

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

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

Эти источники позволяют выбрать наиболее подходящий подход к обучению и материалы для своего учебного процесса. Некоторые из них включают в себя курсы по Docker, Kubernetes, Ansible, Jenkins, Git и другим инструментам, необходимым для успешной работы в области DevOps.

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

В статье я собрал большой список курсов, книг, репозиториев и ресурсов, которые помогут вам стать DevOps-инженером🧑‍💻.

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

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

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

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

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

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

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

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

С развитием веба сайты превратились в сложные приложения, которыми ежедневно пользуются десятки и сотни миллионов людей: почта, облачные хранилища, соцсети, маркетплейсы, стриминговые платформы и т. д. И каждое из них должно работать корректно. Как это сделать? Конечно писать хороший код, а потом и тестировать его. Хотя кто‑то обходится без тестов, тем не менее тестирование — важная часть инженерных практик наравне с мониторингом. Оно помогает нам заблаговременно находить и исправлять баги (или незапланированные фичи) в приложениях. Основная цель тестирования — получить гарантию корректной работы любого ПО .

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

Всем привет! Меня зовут Миша, работаю фронтэнд‑разработчиком в VK в команде Облака Mail.ru, и я хочу разобрать различные виды тестов, дать их сравнительный анализ и применимость. Сразу скажу, тут не будет практики написания тестов. Потому что это нереально сделать внутри одной статьи, необходимо разобрать: теорию тестирования, классов эквивалентности, различие подходов/методов к тестированию, комбинаторику состояний, правильное использование моков и стабов, понимание чистых функций, знание архитектуры приложения. Поэтому предлагаю сконцентрироваться на видах тестирования и начать с «идеального теста».

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

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

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

Итак, сегодня мне написал человек, имя которого совпадает с СЕО с моей работы, в которой я работал пару лет назад. И сообщил, что в компании произошла утечка данных, в связи с чем начато расследование ФСБ и со мной свяжется сотрудник, чтобы провести проверку в моем отношении, т.к. проверяют всех - и текущих сотрудников и бывших.

Также просит не распространять информацию среди сотрудников компании, т.к. это помешает проведению проверки.

Это пахнет. Но может быть и правдой. И как быть? Если это настоящая проверка - действительно не стоит лишний раз болтать. Но вдруг это проверка не настоящая?

Целью этой статьи является изучение архитектурного паттерна Entity Component Systems на практике. Я подготовил пошаговое руководство по созданию небольшой игры, с помощью которого вы познакомитесь с основными принципами разработки на Ecs.

Мне не раз попадались такие проекты, от кода которых берет оторопь. Такое чувство, что сами авторы не смогут объяснить - почему у них все выглядит именно так. В этот момент у меня возникает вопрос: как так получилось? Если вас он тоже волнует, то могу пожелать лишь приятного чтения.

Недавно у меня было телефонное собеседование, на котором мне задавали разнообразные вопросы по Java. Это стандартное собеседование, и большинство вопросов тоже было вполне стандартным:

Что такое полиморфизм?

В чём разница между List и Set? Когда стоит использовать первое, а когда второе?

Где можно столкнуться со взаимной блокировкой (deadlock)?

В чём разница между строгой и слабой типизацией?

В основном вопросы были вполне закономерными. Лично мне не нравится вопрос про полиморфизм, ведь он настолько тесно связан с большинством объектно-ориентированных языков и наследованием, что многие люди, используя его (например, при переопределении или перегрузке метода), даже не думают «О! Это же полиморфизм в действии!». Вместо этого я бы задал вопрос «Что такое наследование, и где оно используется», потому что в большинстве объектно-ориентированных языков для него есть ключевое слово или паттерн. Но это уже мои личные предпочтения, и я вполне понимаю логику проводившей собеседование компании.

В этой статье представлены такие паттерны, как Abstract Document, Monad, Object Mother, Object Pool, Step Builder. Примеры приведены на .NET 7 и C#. Приятного чтения.

Продолжение в статье "Сто паттернов для разработки корпоративных программ. Часть 2.2".

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

На момент написания статьи, последняя стабильная версия React 18.2.0. За 10 лет разработчики Facebook проделали колосальный объем работы, было реализовано много фич и сделано не мало оптимизаций. За эти годы, так же, происходили и кардинальные архитектурные изменения. Очевидно, одной статьи мало, чтобы покрыть всю механику React, поэтому, данная публикация станет первой в серии статей о внутреннем устройстве React. Здесь мы познакомимся с основными сущностями и архитектурными решениями.