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

Да, вместо того, чтобы ручками писать все эти скрипты миграций и в особенности классы моделей их лучше просто генерить в одно мгновение, а ни сидеть, копипастить туда‑сюда названия полей и т. п. Называется всё это термином database reverse engineering, который, как и технология судя по всему не очень то прижился, а совершенно напрасно. Под reverse engineering'ом обычно понимается генерация моделей/сущностей на основе таблиц БД. Но для Laravel есть ещё и кодогенераторы миграций.

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

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

За моими плечами 10 лет работы в IT, два года из них на позиции тимлида. На моих глазах IT-сфера развилась от прямолинейного общения до "зефирно-ласкового". Сегодня разработчики вынуждены регулярно посещать ван-ту-ваны и ретроспективы, иметь дорожную карту развития, быть мотивированными и клеить стикеры. Тимлиды обязаны давать конструктивную и доброжелательную обратную связь, решать конфликты и прочее. За всеми этими церемониями мы забываем о серьёзном профессиональном подходе к работе. А что, если окружающие нас коллеги — настоящие профессионалы, способные самостоятельно решать большинство проблем без помощи тимлида? 

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

Привет! Сейчас я CTO стрима в Газпромбанке, но начинал, как и все, в небольшой компании, где из ИТ-отдела было только два программиста. Мы же были аналитиками, тестировщиками и архитекторами, только ещё не знали таких слов. Надо было писать код для автоматизации — мы писали, он работал. Часто даже правильно. Если что-то шло не так — к нам приходили пользователи объяснять лично.

Там я прокачал навыки непосредственно кодинга, перешёл в крупную ИТ-компанию и уже смог заняться всем тем, что вокруг: назовём это инфраструктурным опытом и зачатками менеджмента. Там мне повезло с международными проектами по внедрению, насмотрелся разного. Позже подтянул софт-скиллы и умение объяснять заказчику, что срок «надо завтра» — это очень оптимистичный прогноз.

В 2021 году «завтра» тоже пропало: все захотели аджайла, нулевого TTM и чего-то странного. Мы выстроили диалог с бизнесом так, чтобы у них реализовывались их хотелки, а у нас не копился техдолг. Пришлось пересмотреть очень многое в подходах. Тут уже понадобились программы развития руководителей.

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

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

Меня зовут Никита Дергачев. Я Teamlead COOL TEAM в MedTech компании СберЗдоровье. В этой статье я расскажу, почему важно структурировано выстраивать архитектуру проектов, а также покажу на примере, с помощью каких инструментов можно отслеживать соответствие архитектуры изначальным требованиям.

Обзор новостей по Symfony за октябрь. В этом обзоре Кирилл Несмеянов разберет нововведения: от полезных правил валидации Week и WordCount до именованных сериализаторов и улучшений в компоненте Messenger. Узнаете про обновления в системе переводов, работе с контейнером и Expression Language. А еще - про возможность отправлять уведомления прямо на рабочий стол. Самое время узнать, какие инструменты добавились в арсенал Symfony-разработчика!

OpenShift и Kubernetes (K8s) выбирают чаще всего для оркестровки контейнеров. Эти инструменты сложно сравнивать напрямую, поскольку Kubernetes — открытое решение (open source), а OpenShift — продукт (дистрибутив) на основе Kubernetes. В этой статье рассмотрены их основные функции и отличия, модели развёртывания и пригодность для различных вариантов использования.

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

Никогда не используйте MySQL, всегда используйте PostgreSQL

И вот почему, по результатам нагрузочного тестирования:

PostgreSQL в два раза меньше потребляет ресурса CPU, PostgreSQL в два раза меньше потребляет ресурса RAM, PostgreSQL в полтора раза меньше потребляет ресурса HDD (storage), PostgreSQL в три раза быстрее выполняет запросы, PostgreSQL после выполнения команды очистки (TRUNCATE TABLE) полностью очистил диск , MySQL очистил диск только наполовину.

Наверное MySQL надо уметь готовить ? Наверное. Если кто то напишет рецепт в комментариях, то благодарное человечество, в лице меня лично, скажет большое спасибо.

Одновременно с этим есть PostgreSQL, который можно не уметь готовить и иметь большую (такую же?) эффективность, стоит ли связываться с MySQL ?

В данной статье обсудим проблемы, возникающие при конкурентной работе с данными, а также инструменты для их решения – атомарные инструкции, явные и неявные блокировки и уровни изолированности транзакций, реализованные в OLTP СУБД PostgreSQL, MySQL, SQL Server, Oracle с примерами на Go. Поговорим о деталях их реализации в указанных СУБД. На примере PostgreSQL проведем benchmark-тестирование производительности уровней изоляции с использованием инструмента pgbench

Как удалось ускорить выполнение запроса MySQL почти на порядок с помощью простого изменения формулировки условия.

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

Что же можно сделать в каждой из трех ролей, чтобы все остались довольны (и целы)?

— Итак, скорость нашей команды - 100sp по результатам статистики нескольких прошедших спринтов. Все время мы берем в спринт задач по сумме больше нашей скорости. И все время в конце спринта у нас остаются задачи, которые мы пообещали выдать, но не закончили работу над ними. Давайте подумаем, как мы можем сделать так, чтобы мы успевали выполнять все, что заявляем в начале спринта?

В эти дни проходит внутренняя конференция Aventus IT. И я там был, мёд пиво пил… Шучу. Выступал на тему автоматизации контроля качества кода. И хочу представить вам статью по материалам своего выступления.

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

Со своей стороны, хочу поговорить, про контроль качества кода помимо тестов.

Долго откладывал, но всё-таки добрался до разбора интервью с Taylor Otwell (далее по тексту T - для сокращения) на YouTube-канале ThePrimeTime. Признаюсь, формат интервью с разработчиками мне казался скучным. Редко когда узнаю что-то полезное, но всё-таки у меня канал и комьюнити посвящены Laravel и просто обязан знать все новости, а также планы T. И я не пожалел - несмотря на то что брали интервью его фанаты, и каверзных вопросов не было, интервью было интересным и очень важным. T дал понять, куда движется развитие Laravel и почему был выбран именно этот маршрут. Забегу вперёд - хейтеры Laravel будут очень довольны 😉.

Сразу скажу, что местами при чтении моего обзора будет складываться впечатление что и я хейтер Laravel, но друзья это не так, просто выбрал стиль небольшого (но вредного) критика, чтобы читать было интереснее. На самом деле я уважаю T, его фундаментальный продукт - Laravel, а также труд и вклад в PHP сообщество. Знакомство с миром Laravel сильно изменило мою жизнь к лучшему. Конечно, у меня есть мнение (как наверняка и у вас), как надо сейчас поступать T. Но об этом поговорим как-нибудь в другой раз.

Усталость, осень, плохое настроение — очень важно учитывать в работе человеческий фактор . Если мы не проанализировали, на что он влияет, как мы можем понять критичность того, что мы им не управляем? И как им вообще управлять? Разберёмся вместе с Surf QA Team.

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

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

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

Краткая цель статьи — сделать потоки данных проще, более тестируемыми и управляемыми с DTO и Runtime Model структурой.

Эта статья — набор мыслей и экспрессии опыта моего текущего видения этой проблемы, как комбинации опыта от работы над проектами и может быть, переизобретение колеса:) Но, в то же время, я хотел бы поделиться этими мыслями — и, надеюсь, вдохновить и посмотреть на структуры данных.

Концепт использует немного функционала Entities, описанных Robert C. Martin (Uncle Bob) в Clean Architecture, также Model‑Driven engineering вместе с концептом immutability.

Эта статья:

— разделена на секцию теории и применения, чтобы статью можно было понять разработчикам не знающим язык используемый в примерах (Dart).
— в основном фокусируется на client‑side (frontend, app, server‑side рендеринг) разработчиках, но думаю что может быть интересна и другим разработчикам..
— для примеров используется абстрактное финансовое приложение и язык Dart.

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