User
Среди применяемых в PostgreSQL методов доступа к данным Index Only Scan стоит особняком, считаясь у многих разработчиков "волшебной пилюлей" для ускорения работы запроса - мол, "Index Scan - плохо, Index Only Scan - хорошо, как только получим его в плане - все станет замечательно".
Как минимум, это утверждение неверно. Как максимум, при определенных условиях может вызвать проблемы чуть ли не на ровном месте.
Всем привет!
Меня зовут Владимир Олохтонов, я руковожу командой разработки в отделе Message Bus, который является частью платформы Ozon. Мы занимаемся разработкой самых разных систем вокруг Kafka, etcd и Vault. В этой статье я расскажу о том, как мы строили линейно масштабируемую gRPC-прокси перед Kafka, способную обслуживать миллионы запросов в секунду, используя Go.
Если вы знаете, что такое Site Reliability Engineering, вам может быть интересно, как эти практики связаны с DevOps. Важно сразу оговориться, что мы не ставим между ними слово «против». Хотя у этих подходов есть некоторые отличия в том, как лучше делать и быстрее доставлять программное обеспечение. В этом посте разберём каждый подход и выясним, чем отличаются DevOps и SRE. Вы заметите, что у подхода SRE есть своё мнение по поводу запуска производственных систем, в то время как DevOps больше фокусируется на людях, процессах и инструментах — именно в этом порядке.
SRE объединяет группы разработчиков программного обеспечения и инженеров эксплуатации и помогает создавать надежные, отказоустойчивые и масштабируемые системы. Некоторые из преимуществ этой методологии:
• Улучшаются коммуникации в команде
• Совершенствуется культура
• Уменьшается доля ручного труда
• Клиенты чаще остаются довольны
Алексей Барабанов, IT-директор «Хлебница» и спикер курса «RabbitMQ для админов и разработчиков», подготовил конспект, который поможет научиться запускать и настраивать RabbitMQ в Docker. Вы поймёте, как конфигурировать параметры запуска, а также узнаете о возможностях управления через веб-интерфейс.
Привет, Хабр! Меня зовут Александр Лукьянченко, я тимлид команды, которая занимается платформой в Авито. В этой статье я расскажу о проблемах, которые возникали у нас при построении платформы для инженеров и том, какие технические решения мы использовали, чтобы эти проблемы устранить. Текст охватывает ту часть наших наработок, которые потенциально можно переиспользовать другим компаниям.
Не откладываем рефакторинг в долгий ящик, чтобы сэкономить на поддержании продукта. Иначе – риск израсходовать горы бюджета, когда рефакторить будет слишком поздно.
Людские пробки в метро
На московских улицах присутствуют всем известные автомобильные пробки.
Их возникновение связано как с избыточностью самих автомобилей, так и с безалаберностью отдельных водителей.
Так в узких местах водители начинают избыточно маневрировать, выгадывая себе место в потоке, при этом снижая скорость и так замедленного в сужении потока.
Занятно то, что если бы все ехали спокойно и равномерно, то поток двигался бы быстрее.
Похожая ситуация с неконструктивным и эгоистичным поведением людей встречается не только на автодорогах, но и в общественном транспорте.
Примером того является возникновение толпы людей перед эскалаторами в московском метрополитене.
Каждый ездивший в московском метро в час‑пик наблюдал такую картину, что перед эскалатором собралась большая толпа, но при этом сам эскалатор заполнен едва на половину. Это отлично видно при взгляде из очереди на поднимающий эскалатор (см.рис.1)
Традиционно после выпуска большого зарплатного исследования мы собираем зарплаты, которые разработчики оставляли в нашем зарплатном калькуляторе и смотрим на них в разрезе квалификаций и языков программирования. Ниже рассказываем про оклады разработчиков во второй половине 2022 и сравниваем их с первым полугодием 2022.
В феврале мы выяснили, что во второй половине 2022 года зарплаты IT-специалистов выросли на 7% за счет роста показателей в регионах. Это было исследование про доходы, а что с расходами? Чтобы это узнать, мы взяли зарплаты разработчиков в российских городах, которые они оставили в нашем зарплатном калькуляторе, и наложили на них стоимость жизни в этих городах.
Если интересно, где в России выгоднее всего живется IT-специалистам — заглядывайте под кат.
Изначально хотел назвать статью «Почему у айтишников большие зарплаты и когда это закончится». Статья создана по мотивам внутренних митапов и докладов.
Я работаю архитектором решений, пишу книги, читаю курсы. Часто студенты, коллеги, знакомые задают вопрос о том, куда будет развиваться IT, не закончится ли оно завтра. Есть модные темы, которые не успев начаться сразу заканчиваются. IT у нас работает с прошлого столетия. Видимо, есть какой-то источник, который подпитывает интерес, может ли он исчерпаться и когда? Попробуем найти топливо IT, промоделировать развитие индустрии и предсказать признаки, по которым можно будет определить, что отрасль движется к стабилизации или деградации.
Иными словами, попробуем заглянуть в будущее. Однако для этого надо слегка откатиться назад, чтобы посмотреть, как IT-отрасль развивалась. Тогда будет проще оценить, что нас ждёт впереди.
За последнее время мне довелось провести немало технических собеседований на позицию DevOps инженера, в связи с чем появилась идея формализовать полученные выводы в этой статье. Хочу поделиться своими наблюдениями, субъективным мнением, и задать самому себе вопросы, ответы на которые, возможно, мне помогут получить читатели данной статьи.
На недавнем Laracon NYC я читал доклад о гексагональной архитектуре. Несмотря на то, что я получил позитивную реакцию слушателей, мне кажется, что остались люди, которые хотели бы получить чуть более полное представление о том, что это такое. Разумеется, с примерами. Это моя попытка расширить тот доклад.По моему мнению, данная архитектура является отличным примером того, как должна строиться структура приложения. Более того, когда я писал свои проекты на 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.
