Основная прелесть использования ПЛИС, на мой взгляд, состоит в том, что разработка аппаратуры превращается в программирование со всеми его свойствами: написание и отладка кода как текста на специализированных языках описания аппаратуры (HDL); код распространяется в виде параметризованных модулей (IP-блоков), что позволяет его легко переиспользовать в других проектах; распределенная разработка обширным коллективом разработчиков с системой контроля версий, такой же, как у программистов (Git); и, как и в программировании, ничтожно низкая стоимость ошибки.

Последнее очень важно, так как если при разработке устройства классическим методом разработчик несет вполне существенные затраты на сборку и производство изделия, и любая схемотехническая ошибка или ошибка трассировки печатной платы — это всегда выход на очередную итерацию и попадание на деньги, то при работе с ПЛИС ошибки ничтожны по своей стоимости и легко устранимы. И даже если в серийном изделии обнаруживается ошибка, то её во многих случаях можно устранить очередным апгрейдом прошивки «в поле» без замены изделия. Короче, с приходом ПЛИС разработка цифровой аппаратуры все больше и больше выглядит как программирование, а это, помимо всего прочего, существенно понижает порог вхождения в тему, и все больше программистов становятся разработчиками «железа». А новые люди, в свою очередь, приносят с собой в индустрию новые подходы и принципы.

В этой статье я хочу поделиться своим небольшим опытом «программирования» микросхем ПЛИС и тем, как я постепенно погружался в тему ПЛИСоводства. Изначально я собирался написать небольшую заметку про открытый тулчейн для синтеза Yosys. Потом — про язык SpinalHDL и синтезируемое микропроцессорное ядро VexRiscv, на нём написанное. Потом — про замену микроконтроллеров микросхемами ПЛИС на примере моей отладочной платы «Карно». Но в процессе я погрузился в историю появления Hardware Description Languages (HDL), и когда я начал писать, Остапа, как это часто бывает, понесло... В общем, получилось то, что получилось.

А еще эту статью можно рассматривать как глубокое погружение в то, что происходит вот на этом новогоднем видео.

Эта статья рассчитана в большинстве своём на новичков. Тут мы поговорим о том, как не упереться в лимиты подключений к базе, и чтобы приложение в продакшн не упало.

В августе 2023 года под руководством группы TAG Observability в экосистеме CNCF была выпущена версия 1.0 документа по наблюдаемости (observability). CNCF — флагман развития и продвижения облачных технологий. Организация объединяет в себе множество компаний, разработчиков и специалистов с огромным опытом и экспертизой, которые упаковали в этот документ. Наш материал является его переводом.

В своей предыдущей статье я исследовал структуру PyObject и её роль в качестве заголовка для всех объектов среды исполнения CPython. Эта структура играет важнейшую роль в обеспечении наследования и полиморфизма в системе объектов CPython. Но это лишь вершина айсберга.

В этой статье мы опустимся на один уровень ниже и посмотрим, что же происходит внутри среды исполнения Python для выполнения простого действия a + b. Иными словами, мы узнаем о подробностях реализации типов, операторов и динамической диспетчеризации в CPython.

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

Двадцать лет назад Джоэл Спольски написал: «Не существует такой штуки, как «обычный текст». Если имеется строка, но неизвестно, какую кодировку символов она использует — смысла в этой строке нет. Больше нельзя спрятать голову в песок и притвориться, что «обычный» текст имеет кодировку ASCII.»

Многое изменилось за 20 лет. В 2003 году главный вопрос звучал так: «Что это за кодировка?». В 2023 году такой вопрос больше не стоит: с вероятностью в 98% это — UTF-8. Наконец то! Можно снова спрятать голову в песок!

Представим следующую ситуацию. Ваш python веб-сервер собирает какие-то метрики prometheus_client-ом: счётчики, гистограммы и т. д, например, количество входящих запросов. Вы также настроили приложение, чтобы /metrics возвращал все ваши метрики. Если режим работы prometheus_client-a оставить по умолчанию, при запуске приложения gunicorn-ом с более чем одним воркером вы сталкиваетесь с проблемой консистентности метрик.

Вносить изменения в код приложения и тут же автоматически получать задеплоенные изменения, чтобы быстро тестировать его, — мечта разработчика. В этой статье мы посмотрим, как реализовать такой подход для небольшого приложения с фронтендом и бэкендом: организуем два варианта локального стенда на базе minikube или Docker с автоматическим развертыванием всех изменений или только закоммиченых в Git.

Бэкенд приложения напишем на Go, а фронтенд — на Vue.js. Все это позволит быстро запускать проект для тестирования прямо во время разработки, что, несомненно, повысит удобство работы с приложением.

Декорирование функций - это, наверное, самая сложная среди базовых и самая простая среди продвинутых фич языка Python. С декораторами, наверное, знакомы все джуны (хотя бы в рамках подготовки к собеседованиям). Однако, крайне мало разработчиков пишут их правильно. Особенно принимая во внимания тенденции последних нескольких лет к аннотированию всего и вся. Даже популярные open-source проекты (если основная часть их кода была написана до 2018 года) вряд ли дадут вам примеры декораторов, отвечающих всем современным требованиям к коду.

Так давайте разбираться!

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

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

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

Google хочет убить свои стандартные 10 синих ссылок (заменив их выдачей данных из чатбота Bard). Твиттер умирает под давлением ботов и синих галочек. Amazon захламляется ИИ-книгами, которые сейчас доминируют в списке бестселлеров, а также фальшивыми отзывами и прочим мусором. Большие проблемы с контентом и рекламодателями испытывает TikTok.

Массовые увольнения захватывают интернет-СМИ. В вакансии от «ИИ-редактора» ожидается «выпуск от 200 до 250 статей в неделю». ChatGPT используется для создания целых сотен спам-сайтов, на которых, ничего не подозревая, через Google Ads рекламируются бренды. Etsy наводнен «мусором, созданным искусственным интеллектом».

Чатботы цитируют друг друга в каком-то дезинформационном уроборосе. LinkedIn использует искусственный интеллект для симуляции сообщений рекрутеров (чтобы создать персонализированное сообщение теперь не нужно тратить ни секунды времени — привет, официально одобренный спам!). Но и это ещё не предел. Snapchat и Instagram рассчитывают, что боты скоро будут разговаривать с вами, когда этого не делают ваши друзья. Реддиторы устраивают забастовки. Бастуют моды Stack Overflow. Интернет-архив борется со считывателями данных, выдающих десятки тысяч запросов в секунду. А еще «ИИ разрывает Википедию на части».

В общем, старая сеть умирает, а новая сеть изо всех сил пытается родиться. И мы уже видим её общие очертания.

Обычно мы подключаем сбор метрик в prometheus к нашим web‑приложениям с помощью каких‑то клиентских библиотек, которые отдают метрики на /metrics. В этой статье я хочу рассказать как визуализировать Latency с помощью Histogram метрики.

Будет полезно тем, кто еще не строил метрики из Prometheus, а так же тем, кто хочет понять как их интерпретировать.

Несколько лет назад я с удовольствием прочитал фанфик «Гарри Потер и методы рационального мышления»  Элиезера Юдковского. Несмотря на подростковую направленность книжки, она получилась интересной. И умопомрачительно смешной – особенно на контрасте с оригинальным произведением.

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

Мне очень понравился формат книги Элиезера – в которой он объяснял серьезные научные концепции на примере знакомых с детства персонажей. Читая, я задавал себе вопрос: Какими бы получились «Гарри Потер и Методы», если бы Элиезер жил в России? Какую книгу он выбрал бы для основы? Приключения Буратино заняты покойным Константином Крыловым, так что остается только Незнайка и дядя Фёдор.  При этом дядя выглядит тут предпочтительнее – Незнайка слишком оторван от окружающей нас реальности, которая требует осмысления.

Взявшись писать, я решил немного осовременить исходную книгу. Мне не нравится, что современные писатели-фантасты, вместо того чтоб отвечать на заданные социумом вопросы, попрятались в виртуальные миры и носа не кажут наружу. Поэтому моему Дяде будет четырнадцать. Это интеллигентный московский подросток из хорошей семьи, который бежит в деревню – где погружается в лютую русскую хтонь…

Привет! Сегодня я хочу познакомить вас с ПО, которое мы разрабатываем в нашей компанией — кластерной СУБД и сервером приложений на языке Rust. Мы профессионально занимаемся созданием и эксплуатацией решений на основе Tarantool и с некоторых пор начали разработку своего ПО, о котором и пойдёт речь.

Picodata — это дальнейшее развитие истории Tarantool, в которой учтен опыт эксплуатации этой СУБД и предложены решения как архитектурных, так и функциональных недостатков открытой версии Tarantool. Также, наше ПО проще запускать, настраивать и поддерживать в рабочем состоянии благодаря единой точке входа и интеграции всего инструментария в одном исполняемом файле. Мы создавали Picodata как изначально кластерную СУБД, которой удобно пользоваться. Если не верите, что российская СУБД может быть удобной, попробуйте — в конце этой статьи есть раздел Практикум, где можно сразу же попробовать собрать кластер самому на паре-тройке виртуальных машин или на вашем локальном компьютере. Сейчас же будет немного теории о том, как вообще работает распределенный кластер, что именно не так в “ванильном” Tarantool и что нам пришлось сделать чтобы это исправить.

Системный аналитик всегда и везде сталкивается с бесконечным количеством диаграмм разного вида, с нотациями (правилами), чтобы нарисовать данные диаграммы и с бесконечным количеством инструментов для их описания. Но мало кто говорит о таком инструменте, как PlantUML. 

Лично мне завесу тайны приоткрыл Альфа-Банк, здесь документация ведется рядом с кодом, и схемы логичнее описывать тоже кодом. Но это не так страшно и не так сложно (почти) как кажется. Давайте я приоткрою ящик Пандоры и сниму кармическое проклятье с  этого инструмента. 

GPT-4 позволяет достаточно просто писать boilerplate код с использованием различных языков, технологий и библиотек. Но, есть небольшая проблема, данные GPT-4 не совсем актуальные и ограничены серединой 2021 года.

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

Как мы боролись с документированием API на наших проектах, и как мы немного сошли с ума

У вас на проекте порядок с документацией на API? Скорее всего нет. И в нашей компании порядка не было.

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

В предыдущей статье я рассказывал, как можно доучить GPT на собственных взглядах и вкусах. Сегодня попробуем дать GPT возможность поработать программистом по‑настоящему — с запуском кода и отладкой без участия человека. Весь код опубликован в репозитарии.

Как многие уже убедились, ChatGPT хорош, но есть некоторые типы задач, с которыми у него возникают трудности:

1. Он не может получать новые актуальные знания из сети.
2. Он не может выполнить какие‑либо действия.
3. У него сложности с алгоритмическими задачами (перевернуть строку, решить уравнение, произвести вычисления с применением численных методов).

И если задача 1 решается с помощью BingChat, то 2 и 3 мы сегодня будем решать в рамках данного туториала.

Основная идея такая: пусть ChatGPT сам решает, может ли он справиться с задачей «в уме» или же это лучше сделать с помощью написания кода на python, а наш сервер сразу же выполняет этот код и снова отдает результат работы ChatGPT, чтобы он мог его интерпретировать и или выдать пользователю окончательный ответ или исправить ошибку в своей программе и попытаться ещё раз.