На Go писатель, серверов пинатель.
В эпоху быстрорастущих приложений важно иметь возможность контролировать состояние системы в любой момент времени. Одними из требований для достижения этого являются логи и метрики, которые помогают нам следить за многими параметрами, такими как количество запросов в секунду (RPS), потребление памяти, cache git и т.д. Однако, есть ещё один полезный инструмент - трейсинг. В этой статье мы ознакомимся со стандартом OpenTelemetry в языке Go и инструментом Jaeger
Привет, я Майк.
Недавно я начал работать в компании Manticore на должности Developer Advocate. Я не совсем далёк от ИТ, но сейчас активно осваиваю современные технологии. В этом блоге я буду делиться своим опытом и тем, что узнаю о Manticore. Я планирую вести дневник, где буду рассказывать, что такое Manticore и как с ним работать. Давайте вместе разбираться, как все устроено, выявлять проблемы и взаимодействовать с разработчиками.
Если вам интересно изучать Manticore вместе со мной, я буду держать вас в курсе в:
Краткое содержание
Мы рады представить две новые важные функции в Manticore Search: нечёткий поиск и автокорректировка запросов (или "автодополнение"). Эти функции улучшают возможности поиска, предлагая более удобный для пользователя опыт.
Не знаю как вам, но для меня нет лучшего начала дня, чем потрепаться о программировании. Кровь кипит при виде удачной критики одного из "жирных" языков, которым пользуются плебеи, мучаясь с ним на протяжении рабочего дня между стыдливыми посещениями StackOverflow.
(Тем временем, вы и я используем только самый просветленный язык и отточенные инструменты, разработанные для ловких рук таких мастеров, как мы).
Конечно, как автор проповеди, я иду на риск. Вам может нравиться язык, который я высмеиваю! Безрассудный памфлет мог бы неосторожно привлечь в мой блог яростную толпу черни с вилами и факелами наперевес.
Чтобы защититься от праведного огня и не оскорбить ваши (вероятно деликатные) чувства, я буду рассказывать о языке...
Меня зовут Максим Горозий. Я тимлид в Т-Банке, работаю над нашей образовательной платформой, которая служит для разных направлений бизнеса. В ИТ больше 10 лет и успел поработать в двух GameDev-компаниях, где управление памятью занимало весомое время в оптимизации производительности кода. Люблю строить системы и взаимосвязи между ними, а также EdTech и преподавание, а еще больше — работать над инструментами обучения. Хотя начинал с C, я идеологический фанат Go, DDD и Agile.
«Оно тормозит» — классическая цитата разработчиков. Расскажу, как разобраться в причинах и научиться управлять памятью, медитируя над профайлингом, чтобы все работало быстро.
Периодически общаюсь с разработчиками о микросервисах, монолитах и прочих мифических существах. Удивляет, какая эзотерика живёт в головах у людей, иногда слышишь такое, что ёжики в тумане нервно курят в сторонке.
Когда спрашиваю у людей на собесах, или когда в команде решаем, как клепать очередной проект, такое порой слышу, что становится страшновато. Мне кажется, лет через 5 все компании будут обитать в мультивселенной безумия из “микросервисов”, которую они себе радостно построили, уходя от этих ваших страшных “монолитов”.
Дай думаю поделюсь инфой, чтобы наше с вами будущее не было наполнено болью, страданием и борьбой с последствиями тех дурацких решений, которые можно напринимать прямо сейчас с той кашей в голове, которую я вижу у людей по этой теме.
Вы не используете очередь? Вы просто не умеете её готовить. Но прежде чем этому научиться, нужно разобраться, что это вообще такое и где это применяется. Потому что большинству достаточно 10 000 запросов в секунду, а это дает любой брокер. Но если вам нужно больше, придется погрузиться в очереди достаточно глубоко.
Расскажу, что такое очереди, зачем они нужны и как работают. На примере нескольких сценариев объясню, как устроены очереди и какие есть решения. Какие у очередей самые распространенные проблемы и как их избежать. В чем отличия брокеров, их плюсы и минусы, и как все это использовать в своих целях.
«Сделай работающим, сделай правильным, сделай быстрым». Это мантра, которую вы, вероятно, слышали раньше. Это хорошая мантра, которая помогает вам сосредоточиться на том, чтобы не переусложнять решение. Я пришел к выводу, что обычно достаточно сделать это правильно, обычно это достаточно быстро, если сделать это правильно.
Когда мы начали реализацию подписок GraphQL в Cosmo Router, мы сосредоточились на том, чтобы сделать это работающим. Это было несколько месяцев назад. Это было достаточно хорошо для первой итерации и позволило нам получить отзывы от наших пользователей и лучше понять проблемное пространство.
В процессе того, как мы делали это правильно, мы сократили количество горутин на 99% и потребление памяти на 90% без жертвования производительностью. В этой статье я объясню, как мы достигли этого. Использование Epoll/Kqueue сыграло большую роль в этом, но также переосмысление архитектуры, чтобы она была более событийно‑ориентированной.
Префиксы помогают разработчикам быстро понять предназначение переменных и функций, что особенно полезно в больших проектах или когда код должен быть понятен новым участникам команды
Привет, Хабр! Меня зовут Ильяс. Мы с командой делаем собственный Service Mesh в Ozon Tech, и в этой статье я расскажу, как можно за вечер реализовать свое супер кастомное межсервисное взаимодействие. К концу статьи мы с вами напишем современные алгоритмы балансировки, настроим канареечные деплои, а также узнаем, как реализовать кучу других супернеобычных механизмов межсервисного взаимодействия на основе, не поверите, библиотеки gRPC :D И да, мы с моей командой уже раскатили это на весь Ozon Tech, состоящий из более чем 4500 сервисов. Пристегнитесь — мы начинаем… :-)
Основная прелесть использования ПЛИС, на мой взгляд, состоит в том, что разработка аппаратуры превращается в программирование со всеми его свойствами: написание и отладка кода как текста на специализированных языках описания аппаратуры (HDL); код распространяется в виде параметризованных модулей (IP-блоков), что позволяет его легко переиспользовать в других проектах; распределенная разработка обширным коллективом разработчиков с системой контроля версий, такой же, как у программистов (Git); и, как и в программировании, ничтожно низкая стоимость ошибки.
Последнее очень важно, так как если при разработке устройства классическим методом разработчик несет вполне существенные затраты на сборку и производство изделия, и любая схемотехническая ошибка или ошибка трассировки печатной платы — это всегда выход на очередную итерацию и попадание на деньги, то при работе с ПЛИС ошибки ничтожны по своей стоимости и легко устранимы. И даже если в серийном изделии обнаруживается ошибка, то её во многих случаях можно устранить очередным апгрейдом прошивки «в поле» без замены изделия. Короче, с приходом ПЛИС разработка цифровой аппаратуры все больше и больше выглядит как программирование, а это, помимо всего прочего, существенно понижает порог вхождения в тему, и все больше программистов становятся разработчиками «железа». А новые люди, в свою очередь, приносят с собой в индустрию новые подходы и принципы.
В этой статье я хочу поделиться своим небольшим опытом «программирования» микросхем ПЛИС и тем, как я постепенно погружался в тему ПЛИСоводства. Изначально я собирался написать небольшую заметку про открытый тулчейн для синтеза Yosys. Потом — про язык SpinalHDL и синтезируемое микропроцессорное ядро VexRiscv, на нём написанное. Потом — про замену микроконтроллеров микросхемами ПЛИС на примере моей отладочной платы «Карно». Но в процессе я погрузился в историю появления Hardware Description Languages (HDL), и когда я начал писать, Остапа, как это часто бывает, понесло... В общем, получилось то, что получилось.
А еще эту статью можно рассматривать как глубокое погружение в то, что происходит вот на этом новогоднем видео.
Приветствую, Хабр!
Иногда на меня находит меланхолия. Копаюсь в архивных фотографиях, вспоминаю старые проекты. Недавно из большой коробки с барахлом достал несколько макетов, где исправлялись различные (в основном, конечно, глупые) ошибки. Это будет пост о том «как не нужно было делать» или «учимся на своих ошибках».
Одной из проблем первых сезонов Школы цифрового синтеза является малое число поддерживаемых плат, на которых можно легко и быстро повторить упражнение.
Чтобы справиться с данной проблемой, группа энтузиастов, под руководством Юрия Панчула, добавила поддержку множества плат и нескольких toolchain’ов от различных производителей FPGA.
В данном туториале, посвященном работе с FPGA от компании Gowin, я расскажу про то, как установить GOWIN EDA, о доступных платах и перефирии к ним и про работу со скриптами сборки примеров.
Про restic я уже рассказывал в статье Бэкап-хранилище для тысяч виртуальных машин свободными инструментами, с тех пор он остаётся моим любимым инструментом для бэкапа.
Сегодня я опишу вам готовый рецепт того как настроить эффективное бэкапирование чего угодно прямо из stdin, с дедупликацией и автоматической очисткой репозитория от старых копий.
Несмотря на то, что restic отлично подходит для сохранения целых каталогов с данными в этой статье мне хотелось бы сделать упор на сохранении резервных копий на лету прямо из Stdin.
Как правило это бывает актуально для сохранения бэкапов виртуальных машин, баз данных и других, представленных одним большим файлом, данных, которые можно последовательно вычитывать и сразу отправлять в систему бэкапирования.
Идея упростить или абстрагировать код с помощью ORM, возможно, имеет очень ограниченный контекст применимости. По сути ORM хорош для приложений уровня простого CRUD, а дальше начинает только мешать. А CRUD-приложений в реальной жизни очень мало.
Итак, судьба снова свела вас с C++, и вы поражены его возможностями с точки зрения производительности, удобства и выразительности кода. Но вот незадача: вы теряетесь в этом многообразии замечательных новых фич и, как следствие, затрудняетесь сходу определить, что из этого всего вам действительно стоило бы взять на вооружение в своей повседневной работе по написанию кода. Не стоит расстраиваться, в этой статье вашему вниманию будут представлены 21 новая фича современного C++, которые помогут сделать ваш проект лучше, а работу над ним легче.
Сообщество C++ дополняет стандарт чаще, чем Apple выпускает новые iPhone. Благодаря этому C++ теперь больше похож на большого слона, а съесть целого слона за один присест невозможно. Вот почему я решил написать эту статью, чтобы дать вашему путешествию по современному C++ своего рода отправную точку. Моя целевая аудитория здесь — люди, которые переходят со старого (т.е. 98/03) С++ на современный (т.е. 2011 и далее) С++.
Я отобрал ряд фич современного C++ и постарался объяснить их на лаконичных примерах, чтобы вы научились определять места, где их можно использовать.