Для работы с проектами существует куча редакторов кода и IDE (VSCode, NeoVim, SublimeText, WebStorm и т.д.). В данный момент наиболее популярны VSCode и Webstorm и у каждого есть свои плюсы и минусы. Webstorm является примером прекрасного IDE от компании JetBrains, где многие вспомогательные модули идут “из коробки”. К сожалению, сейчас нет возможности легально получить доступ к этому продукту гражданам России, поэтому многим приходится искать альтернативу. Такой альтернативой вполне может стать Visual Studio Code от компании Microsoft, который имеет открытую кодовую базу, полностью бесплатный и гибко настраиваемый под ваши нужды. В данной статье мы рассмотрим пример настройки рабочего пространства VSCode для комфортной работы с нашими проектами. Я покажу вам, какими расширениями я пользуюсь для лучшего удобства и продуктивности. Эти расширения я использую давно и они хорошо зарекомендовали себя, но возможно некоторые из них могут не подойти под ваш стиль работы и написания кода. Итак, начнем!
Пользователь
Применение статических анализаторов архитектуры на примере гексагональной архитектуры
Отсутствие четкой структурированной архитектуры проектов — не редкость в ИТ. Одни этим пренебрегают из-за маленького масштаба проекта, другие — из-за сжатых сроков разработки, третьи — из-за отсутствия экспертизы в этом вопросе. Вместе с тем, движение по этому пути — практически всегда история с «отложенными последствиями»: со временем такие проекты становится сложно поддерживать, масштабировать, администрировать и фиксить.
Меня зовут Никита Дергачев. Я Teamlead COOL TEAM в MedTech компании СберЗдоровье. В этой статье я расскажу, почему важно структурировано выстраивать архитектуру проектов, а также покажу на примере, с помощью каких инструментов можно отслеживать соответствие архитектуры изначальным требованиям.
Вышла Grafana 11.3: дашборды на базе Scenes, обновления визуализаций, панелей, и многое другое
Встречайте! Вышла Grafana 11.3, являющая публике дашборды на основе библиотеки Scenes — а это основа того, каким мы видим будущее дашбордов Grafana.
Но и без этого Grafana изменилась весьма заметно! Улучшен пользовательский интерфейс, включая возможность вызывать API из любого элемента на холсте с помощью новой опции «Действия» во многих визуализациях. Также появились правила записи для управляемых Grafana алертов, и теперь все могут использовать Explore Logs, часть набора приложений Explore в Grafana, представленного на ObservabilityCON, который быстро и легко извлекает аналитику из ваших данных — без каких-либо сложных языков запросов.
Feature-Sliced Design (FSD): Основы и практические примеры архитектуры
Когда я только начинал свою карьеру фронтенд-разработчика, часто сталкивался с проблемами поддержки кода в проектах. Со временем я понял, что структура кода имеет решающее значение. Так я узнал о Feature-Sliced Design. Этот подход помогает разбивать проект на функциональные части, что упрощает работу с кодом и его сопровождение. Давайте разберемся как это работает.
Keycloak Starter. Удобный способ аутентификации и авторизации
Это статья-туториал. Рассмотрим в ней, как сделать компонент, который поможет забыть о необходимости дублировать механизмы аутентификации и авторизации. Цель статьи - реализовать starter, который можно будет легко и удобно подключить к Spring Boot проекту. Предлагаемая цель актуальна?
Сравнение операторов RxJava 3 и Kotlin Coroutines Flow
Привет, Хабр! Меня зовут Константинов Александр, я Android-разработчик в «Студии Олега Чулакова». Сегодня мы сравим операторы RxJava 3 и Flow. Статья будет полезна как для изучения операторов, так и для более легкого перехода с RxJava на Flow.
Envoy Proxy — один за всех Load Balancer
В современной инфраструктуре нет недостатка в решениях для балансировки и межсервисных коммуникаций. Почти все используют nginx, HAProxy, есть адепты Treafik, а публичные облака предлагают Load Balancer как сервис. Но что делать, если инструменты не справляются с ростом масштабов и необходимо автоматизируемое cloud-native-решение?
Я Дмитрий Самохвалов, архитектор в K2 Cloud. В этой статье поделюсь, как мы из-за ограничений старых систем для динамической конфигурации перешли с работающих решений nginx и HAProxy на модный Envoy. Расскажу, почему сочли это решение подходящим, какие возможности есть у Envoy, каким был опыт внедрения и оставлю рекомендации для эффективного перехода. Будет полезно разработчикам cloud-native-приложений и инфраструктуры, а также всем, кто хочет создать единое платформенное решение для взаимодействия сервисов и инфраструктуры.
Как не сломать мониторинг своими руками
Проблема наблюдаемости (observability) возникает во всех организациях. Я помогу вам научиться не на своих, а на моих ошибках, подскажу, как обойти грабли и подводные камни. Здесь вы найдёте подборку антипаттернов, которая поможет избежать проблем в будущем.
Меня зовут Кирилл Борисов, я в IT около 13 лет. Создавал DevOps-процессы и инфраструктуру в больших проектах, руководил группой сопровождения. Сейчас SRE-инженер в VK, в проекте VK Реклама.
Аптайм вахтер: мониторинг веб-сервисов с помощью Globalping и уведомлениями в Telegram
Представьте: ваш сервис должен работать безотказно 24/7, быть доступным из любой точки мира, а любые проблемы нужно обнаруживать мгновенно. Как убедиться, что сайт одинаково быстро работает в Нью-Йорке, Токио и Москве? Как отследить проблемы маршрутизации или цензуры в разных странах?
Стандартные системы аналитики могут помочь с базовым мониторингом доступности, но что если вам нужно больше? Что если нет возможности установить счетчик или вас не устраивает способ доставки уведомлений?
Как мы в МТС создали библиотеку для работы с графовыми нейронными сетями
Привет, Хабр! Меня зовут Диана Павликова, я работаю ML-инженером. Часто к нам приходят задачи, когда нужно повысить качество работы модели там, где обычными способами это сделать уже не получается. Мы решили применить что-то новое, поэтому обратились к теории графов и написали CoolGraph — open source библиотеку для работы с графовыми нейронными сетями. В этой статье я расскажу, как мы пришли к идее ее создания, как графы помогают улучшить результат, какую архитектуру мы выбрали и для каких задач подойдет этот инструмент. Все подробности — под катом.
Тернистый путь к единому хранилищу метрик
Метрики — один из трёх базовых типов телеметрии и основа мониторинга любого приложения. Но что, если необходимо собирать их в рамках крупной и высоконагруженной экосистемы? Как собрать метрики с десятков тысяч хостов разных ЦОДов и сотен типов приложений? И как упростить инженерам настройку правил алертинга и создание дашбордов?
Привет, Хабр! Я Филипп Бочаров, руководитель стрима мониторинга и наблюдаемости в МТС Digital. Мы занимаемся всеми типами телеметрии: логами, трассировкой и, конечно, метриками. Единое хранилище метрик экосистемы — часть нашей платформы наблюдаемости. Для этих целей мы используем агент Telegraf и большой кластер VictoriaMetrics, принимающий 10+ миллионов сэмплов в секунду.
В этой статье расскажу, как мы реализовали централизованное управление конфигурацией агентов, удобный интерфейс для настройки алертинга и правил сбора метрик. Покажу, как менялась архитектура решения с ростом нагрузки, как мы боролись с отставанием и потерей данных. Посмотрим, как это позволило собрать все метрики в единое хранилище и построить дашборды здоровья по ключевым продуктам.
Как мы сделали базу знаний Smarty на основе RAG
За 15 лет работы red_mad_robot база знаний компаний сильно масштабировалась. Появление новых артефактов и рост количества проектов усложнили актуализацию знаний для сотрудников. Времени на обновление данных часто не хватает, поиск материалов стал сложнее, а часть информации вообще канула в лету вместе с ушедшими сотрудниками. В итоге пересылка документов в чатах и многочисленные гугл-таблички стали самым простым, но не самым удобным и тем более безопасным вариантом.
Но мы ведь роботы, и там, где белковые пересылают документы в чатах, мы создаём умные сервисы. Так родилась база знаний Smarty.
Ошибки в Go: проблема и элегантное решение с библиотекой try
Все мы знаем: Go — это классный язык программирования.
Простота, ясность, скорость компиляции — мечта разработчика.
Но вот одна вещь может довести до белого каления — это обработка ошибок.
В отличие от языков вроде Java или Python, где ошибки обрабатываются с помощью конструкции try-catch
, Go предпочитает явный подход: большинство функций возвращают ошибку в виде второго значения, и разработчик обязан проверять её после каждого вызова.
Это выглядит чисто и прозрачно, но на практике такие проверки приводят к громоздким и повторяющимся конструкциям. Вместо того чтобы писать код, который решает задачи, мы погружаемся в бесконечные проверки:
if err != nil {
return err
}
Как сократить размеры логов без потери функциональности
Разработчики периодически разрываются между желанием логировать как можно больше информации и необходимостью сделать объём логов разумно компактным.
Когда речь идёт о небольшом локальном сервисе с нагрузкой 10 запросов в день, можно позволить себе писать в логи всё: от полного текста запроса до полного текста ответа с кучей промежуточной информации (что пришло из базы, какой запрос послали во внешний сервис и что получили в ответ и т.д.). Когда же речь об относительно высоконагруженном сервисе, обрабатывающем порядка 1000 rps даже малая часть этой информации за пару дней запросто может вызвать переполнение современного жёсткого диска.
Возникает логичный вопрос: как логировать только нужную информацию?
Что делать, если выгорела половина команды, бизнес встал, а вам не хочется ничего делать?
Офисные работники засыпают, просыпается выгорание. Выгорание делает свой выбор среди неспящих, засидевшихся допоздна сотрудников. Выгорание сделало свой выбор. Все просыпаются офисными работниками. Все, кроме Олега. Олег просыпается уличным художником в Амстердаме.
Как говорится - в любой шутке есть доля шутки. Давайте поговорим про выгорание в команде. Про то, как стать максимально продуктивным, перестать выгорать и в целом избавиться от ощущения «опять эта работа».
Меня зовут Евгений Идзиковский. Я начинал аналитиком, продолжил IT-карьеру в Radmin’е, а затем кардинально сменил профессию. Сейчас я — психолог и «депрограммирую» людей от того, что им мешает жить. На досуге, отдыхая от депрограммирования, пишу нейросети на R и изучаю Python.
Партицирование таблиц в PostgreSQL: чек-лист для старта
Часто возникает проблема: одна из таблиц в базе данных сильно выросла и время выполнения запросов к этой таблице увеличилось. Одним из вариантов решения подобной проблемы в PostgreSQL является партицирование. В статье затронем не только техническую реализацию, но и опишем этапы подготовки к партицированию.
Представим, что у нас есть батон хлеба. Порежем его на части. Каждый отрезанный кусочек — часть целого батона, но не сам батон. То есть мы поделили целое на части — это и есть партицирование. Батон как целое соответствует таблице, а кусочки батона как части — партициям этой таблицы.
Как повысить эффективность разработки ПО. 5 крупных направлений
Если вы, как менеджер, ищете способы улучшить эффективность разработки, обратите внимание на эти важные пункты. Они показывает ключевые направления для оптимизации процессов и повышения продуктивности команд.
Smoke vs Sanity тестирование: в чём разница?
Тестирование, как неотъемлемый процесс жизненного цикла разработки программного обеспечения, обеспечивает функциональность, совместимость и производительность разрабатываемых приложений. Среди различных видов тестирования особое место занимают smoke-тесты и sanity-тесты, которые проверяют надёжность и стабильность приложений.
Smoke-тестирование обычно является первым этапом тестирования, проводимым после получения новой сборки. Если smoke-тесты успешно пройдены, что указывает на базовый уровень стабильности, то далее переходят к sanity-тестированию, чтобы более детально проверить конкретные изменения. Термины sanity-тестирование и smoke-тестирование часто используются как синонимы, но между ними есть существенные различия, о которых необходимо знать, чтобы выбрать правильную стратегию тестирования.
PostgreSQL Antipatterns: валим «слона» — highload на ровном месте
Сегодняшняя тема посвящена нелегким взаимоотношениям клиентского приложения и сервера PostgreSQL: как на ровном месте, неудачной архитектурой приложения, можно обеспечить себе хронические проблемы производительности.
Рассмотрим классические ситуации, когда разработчики начинают жаловаться на производительность БД - а виновата-то и не она!
Немного о подходе Architecture Decision Records
В процессе разработки проектного решения мы, как правило вносим множество изменений. Нет, конечно есть проекты, где все требования жестко «приколочены гвоздями» в ТЗ и внесение каких‑либо изменений практически невозможно. Но большинство проектов в той или иной степени используют знаменитую методологию Agile, позволяющую проявлять гибкость при реализации проектов.
При этом, мы не всегда можем четко определить, какие из принятых нами решений в процессе работы являются архитектурными, то есть требующими обязательного документирования, а какие таковыми не являются, хотя также очень важны для проекта. Когда архитектура программного обеспечения развивается в результате принятия командой ряда решений, командам разработчиков требуется способ отслеживать принятые ими архитектурные решения. И здесь им на помощь приходит отчет об архитектурных решениях Architecture Decision Records (ADR). По сути, ADR — это документы, которые описывают принятые архитектурные решения в проекте или системе. Они используются для сохранения и передачи информации о принятых решениях и обосновании их принятия.
Information
- Rating
- Does not participate
- Registered
- Activity