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

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

Иными словами, попробуем заглянуть в будущее. Однако для этого надо слегка откатиться назад, чтобы посмотреть, как IT-отрасль развивалась. Тогда будет проще оценить, что нас ждёт впереди.

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

1. Видео с доклада
2. Слайды

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

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

Гексагональная архитектура, ни в коем случае не новый подход к разработке с применением фреймворков. Напротив, это всего лишь обобщение «лучших практик» — практик новых и старых. Я обернул эти слова в кавычки, чтобы люди не воспринимали их совсем буквально. Лучшие практики, которые работают для меня, могут не работать для вас — все зависит от задачи и преследуемых целей.

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

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

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

Я составил список своих задач и разбил их на категории. Кстати говоря, добрую половину этих задач я повесил на себя сам.

В своём прошлом посте я рассказал теорию своего подхода к декомпозиции систем на модули. Теперь пришло время проверить её на практике.

Кэмп - реальный проект, который стоил семизначную сумму для заказчика, выполнялся командой из 12 человек (включая двух бакэндеров) и сейчас запущен в промышленную эксплуатацию. Суммарно на выполнение проекта было затрачено 5500 человеко/часов, из которых 950 - на бакенд.

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

Меня зовут Александр Пряхин, я TechUnit Lead в Авито. В IT работаю уже 14 лет. Из них 8 лет руковожу командами. Параллельно с этим преподаю и менторю. Сегодня разберём, как готовить демонов на PHP — от А до Я, и почему это актуально.

Недавно я решил зайти на сайт cybersport.ru (проект VK GROUP), где хотел посмотреть результаты матчей наших мальчиков по Dote. Мой взгляд упал на статью "Когда будет новый сайт". Там помимо общей информации было пару фраз про PHP и Symfony, которые меня расстроили.

Вместе с окончанием мартовского коммитфеста, закончился прием изменений в 16-ю версию. Пришла пора посмотреть, что в нем было нового и интересного.

Надеюсь, что представленный материал вместе с предыдущими статьями серии (2022-07, 2022-09, 2022-11, 2023-01) поможет сформировать представление о новинках PostgreSQL 16.

Всех приветствую!

Это продолжение серии статей, где мы рассмотрим еще несколько методов, которые помогут улучшить производительность приложения. Мы поговорим о том, как использовать entity manager, unit of work, bulk inserts и batching processing для более эффективной работы с базой данных.

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

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

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

Что имеем?

• — pk_id ( первичный ключ )
• — id ( поле заполненное разными числами )
• — value ( поле заполненной с помощью rand() )

Вячеслав Смирнов — Ускоряем Apache JMeter

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

Apache JMeter является популярным инструментом тестирования производительности с большим количеством компонентов и возможностей. Одни и те же операции в Apache JMeter можно выполнить несколькими способами.

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

Пользуясь средствами профилирования Java-приложений, такими как Java Flight Recorder, jVisualVM, SJK, имея доступ к исходным кодам инструмента, написав синтетические тесты и взяв примеры из практики, мы подготовили отчёт по тестированию производительности инструмента для тестирования производительности.

Доклад будет интересен инженерам по тестированию производительности, использующим Apache JMeter, как начинающим, так и опытным, а также разработчикам, использующим JVM/JDK в работе и занимающихся профилированием и оптимизацией кода.

Всем привет! Я сегодня расскажу, как ускорить Apache JMeter.

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

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

APM расшифровывается как Application Performance Monitoring (мониторинг производительности приложений). Если на вашем пути встречается эта аббревиатура, то речь скорее всего идет о измерении производительность вашего приложения и ваших серверов. Как они справляются, сколько памяти они потребляют, где узкие места? И это далеко не все. С помощью APM можно настроить специальные уведомления, которые будут оповещать вас, например, о том, что потребление памяти достигло очень высоких показателей или удаленный вызов занимает слишком много времени. Триггеры для подобных уведомлений могут опираться на довольно широкий набор показателей и событий. Но давайте не будем забегать вперед.

Всем привет. Как вы, возможно, знаете, раньше я все больше писал и рассказывал про хранилища, Vertica, хранилища больших данных и прочие аналитические вещи. Сейчас в область моей ответственности упали и все остальные базы, не только аналитические, но и OLTP (PostgreSQL), и NOSQL (MongoDB, Redis, Tarantool).

Эта ситуация позволила мне взглянуть на организацию, имеющую несколько баз данных, как на организацию, имеющую одну распределенную гетерогенную (разнородную) базу. Единую распределенную гетерогенную базу, состоящую из кучи PostgreSQL, Redis-ов и Монг… И, возможно, из одной-двух баз Vertica.

Работа этой единой распределенной базы порождает кучу интересных задач. Прежде всего, с точки зрения бизнеса важно, чтобы с данными, движущимися по такой базе, все было нормально. Я специально не использую здесь термин целостность, consistency, т.к. термин это сложный, и в разных нюансах рассмотрения СУБД (ACID и CAP теорема) он имеет разный смысл.

Ситуация с распределенной базой обостряется, если компания пытается перейти на микросервисную архитектуру. Под катом я рассказываю, как обеспечить целостность данных в микросервисной архитектуре без распределенных транзакций и жесткой связности. (А в самом конце объясняю, почему выбрал для статьи такую иллюстрацию).

Привет Хабр! Последняя статья про инструменты для профилирования php датируется аж  2018 годом. Но все перечисленные решения разработаны много лет назад и имеют недостатки: древний интерфейс btp (аналог pinba), оверхед xhprof и необходимость ручного запуска phpspy на stage.

Я тимлид в рекомендательном сервисе Zoon и перед моей командой стояла цель найти инструменты, которые профилируют весь код на проде 24/7 и хранят данные. Инструменты, с которыми могут работать рядовые разработчики, без доступа к проду. Инструменты, которые позволяют находить "бутылочные горлышки" за 30 секунд.

В конце 2021 года показался свет в конце туннеля, в виде системы на основе семплирующего eBFP профайлера: prodfiler. 

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