Привет, Хабр! Вот уже 7 с половиной лет я веду учет своих личных финансов в одном из многочисленных приложений. Всё это время оно неплохо закрывало базовые потребности в моменте, но с годами захотелось глубже проанализировать свою накопленную микро-бигдату и просмотреть на картину в целом. Желательно, в буквальном смысле: воспринимать информацию в виде визуализаций, диаграмм и дашбордов мне проще.

Поэксперементировав, я за несколько вечеров собрал себе решение на довольно нестандартной для таких целей платформе – Kibana. Как по мне, получилось неплохо. По горячим следам я описал этот кейс в своем англоязычном Твиттере и поделился им же в одном русскоязычном сообществе. Угадайте, откуда какой первый комментарий:

– А [зачем], собственно?
– Интересное решение! Я евангелист из Эластик – не хочешь на митапе выступить?

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

Предисловие: этот пост представляет собой очень длинный перечень мыслей и проблем, возникавших у меня за годы работы; также в нём рассматриваются некоторые из аргументов, которые мне часто говорили. В посте выражено моё мнение, сформировавшееся у меня в процессе разработки игр на Rust в течение многих тысяч часов на протяжении многих лет и после множества завершённых игр. Это не хвастовство и не показатель успеха, я просто хочу сказать, что вложил достаточно много усилий в Rust; здесь не получится сказать «когда наберёшься опыта, тебе всё станет понятно».

Пост не будет ни научной оценкой, ни A/B-исследованием. Это моё личное мнение после разработки игр на Rust маленькой инди-командой (два человека) в попытках заработать достаточно денег, чтобы финансировать процесс. Мы не одни из тех разработчиков с бесконечными финансами от инвестора и многолетним запасом времени. Если вы находитесь в этой категории и получаете удовольствие от многолетней разработки систем, то всё написанное ниже к вам не относится. Я рассматриваю всё с такой точки зрения: «Мне хочется создать игру максимум за 3-12 месяцев, чтобы люди могли сыграть в неё, а я — немного заработать». Статья не написана с точки зрения «Я хочу изучить Rust, а разработка игр — это весело», хотя это и вполне нормальная цель; просто она никак не согласуется с тем, чего хотим мы — заниматься разработкой игр коммерчески успешным и самодостаточным образом.

Мы выпустили несколько игр на Rust, Godot, Unity и Unreal Engine, и многие люди сыграли в них в Steam. Мы создали с нуля собственный игровой 2D-движок с простым рендерером, а также в течение нескольких лет использовали Bevy и Macroquad во многих проектах, некоторые из которых были очень нетривиальными. Кроме того, я бэкенд-разработчик на полную ставку и пишу код на Rust. Этот пост — не какое-то поверхностное мнение после изучения нескольких туториалов или разработки небольшой игры для геймджема. За три с лишним года мы написали сильно больше ста тысяч строк кода на Rust.

Задача этого поста — развеять популярные и часто повторяемые аргументы. Но это всё-таки субъективное мнение; по большей части я написал пост, чтобы не объяснять снова и снова одно и то же. Пусть это будет справочный материал о том, почему мы, скорее всего, откажемся от Rust как от инструмента для разработки игр. Мы ни в коем случае не планируем прекращать создавать игры, просто не будем делать это на Rust.

Что если бы я вам сказал, что без понимания того, что такое backpropagation (обратное распространение ошибки), вы никогда не сможете использовать AI эффективно? Тогда я бы, конечно, соврал. Знать такие детали не требуется для использования AI в прикладных задачах, но, тем не менее, это базовый фундамент ML/AI, и понимать, как все устроено, полезно, ну или как минимум, интересно.

В данной статье речь пойдет о Wi-Fi мини видеокамере из семейства А9 от китайских производителей. Цель исследования этих камер – расширить возможность их применения, которая ограничена использованием только стандартных приложений для мобильных устройств на базе Android или iOS.

По итогу представлен некоторый анализ дампа сетевого трафика между камерой и мобильным приложением, а на его основе предложен работающий код на Python.

В приложении «Магнит: акции и доставка» можно оставлять отзывы на товары. Отзывы модерируются: мы публикуем те, которые считаем полезными для других покупателей, — они должны описывать потребительские свойства товара. Отклоняем все остальные: как правило, это жалобы на ценники, сервис в магазине, условия хранения либо просто нерелевантные тексты. Отзывы с жалобами обрабатывают службы поддержки и сервиса.

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

Одноклеточное РНК-секвенирование (scRNA-seq) – метод изучения экспрессионных профилей на уровне отдельных клеток, то есть определения, какие РНК присутствуют в каждой клетке и в каком количестве. Это позволяет ученым понимать, как функционирует каждая клетка и какие функции она выполняет.

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

Весь процесс достаточно сложный, но как GPT-4 помогает в его осуществлении? Об этом подробно и доступно я расскажу в этой статье!

Приятного прочтения! :)

Привет, Хабр!

Это исследователи из NSS Lab ИТМО и создатели сообщества ITMO.OpenSource. Мы считаем, что важно делать не просто науку, а открытую науку, результатами которой можно легко воспользоваться. Поэтому пишем об открытом коде, проводим митапы «Scientific Open Source» и разрабатываем научные решения с открытым кодом. Эта статья написана на материале исследования, которое мы презентовали на последнем митапе. В ней поговорим об открытом научном коде, посмотрим, как с ним обстоят дела в разных организациях, и поделимся подборкой репозиториев, которые могут решать различные научные задачи.

Или история о том, как научная статья "Вам нужно только внимание..." немного перевернула игру и индустрию ИИ. 

Трансформеры становятся сотами или попросту попадают в самые последние решения сферы NLP. Кстати, заслужили свою популярность они вообще недавно — только в 2017 году, когда курс доллара был 60 рублей, а для ТГ-каналов с новыми ИИ не исчислялись тысячами.

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

Я уже описывал идею создания прозрачного Open-Source мессенджера на основе этого алгоритма и хочу представить вам его самую простую реализацию с примерами кода.

Кода будет много...

Привет! Меня зовут Михаил Кажемский, я Lead DevOps в IT‑интеграторе Hilbert Team. В последнее время к нам часто обращаются заказчики, которым нужна помощь с организацией хранения долгосрочных метрик в российских облаках. Так как для многих эта задача сейчас актуальная, в данной статье мы с моим коллегой Денисом Бабичевым решили рассказать, как мы используем мощные возможности ClickHouse для эффективного долгосрочного хранения метрик Prometheus. В статье вы найдете рекомендации по использованию инструмента и описание альтернативных решений, таких как Thanos, Grafana Mimir и Victoria Metrics.

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

Если не читали первую часть, настоятельно рекомендую это сделать, чтобы оставаться в контексте.

Итак, продолжим.

Для лиги лени. Какая-то заумь про то, что не нужно, потому что все равно у нормальных людей все приложения давно в облаках на микросервисах, и прекрасно работают.

Часть 3. Что из этого следует, и как устроен планировщик нормального человека в Hyper-V. Тут не будет ничего нового для тех, кто открывал документацию про корневой раздел (root partition)

Кластеризация — это набор методов без учителя для группировки данных по определённым критериям в так называемые кластеры, что позволяет выявлять сходства и различия между объектами, а также упрощать их анализ и визуализацию. Из-за частичного сходства в постановке задач с классификацией кластеризацию ещё называют unsupervised classification.

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

Nvidia - одна из ключевых компаний мира прямо сейчас. Существует популярное мнение, что они просто везунчики, которые всегда оказываются с нужным продуктом в нужное время. Однако, если изучить историю развития этой компании, то станет отчетливо видно, что эти ребята умеют мастерски конкурировать, делают полезные выводы из провалов и отлично «ловят волны». Сегодня разберемся, как им это удается.

Рассказываю о своём опыте использования Xray (с протоколом VLESS-Reality) - одного из лучших решений для преодоления интернет-цензуры на сегодняшний день. Я потратил много времени на то, чтобы разобраться с ним - теперь вам достаточно одного вечера, чтобы поднять свой сервер на несколько десятков пользователей, c xray на борту!

• скрипт ex.sh для простой настройки и установки; есть поддержка Docker

• легко добавлять пользователей; клиентские конфиги в форме url-ссылок

• правильные конфиги: скрытность + удобство

• трафик популярных российских сайтов идёт напрямую, a не через сервер

• для xray есть приложения под все популярные ОС - делюсь инструкциями

• только https, нет udp; торренты через сервер блокируются по возможности

• мой проект на гитхабе: easy-xray

Предлагается пошаговое руководство по дообучению Whisper для любого многоязычного набора данных ASR с использованием Hugging Face 🤗 Transformers. Эта заметка содержит подробные объяснения модели Whisper, набора данных Common Voice и теории дообучения, а также код для выполнения шагов по подготовке данных и дообучению. Для более упрощенной версии с меньшим количеством объяснений, но со всем кодом, см. соответствующий Google Colab.

Для личных нужд я использую bare-metal сервер от Hetzner, порезанный на виртуалки и, с недавних времен, VPS на HostHatch для мониторинга и резервирования. Также есть маленькая ВМка у TietoKettu (для ВПН, экспериментов и прочее).

Так как IPv4-адресов мало, то хостинги обычно дают дополнительные айпишки за дополнительные деньги, а вот IPv6-сети выделяют щедро. Изначально, я объединил все виртуалки, у которых был публичный IPv4-адрес в Wireguard mesh сеть, но потом когда выяснилось, что надо бы присоединить ещё одну ВМку, пришлось переделать mesh на IPv6-адреса и тут понеслось...

Сначала выяснилось что у HostHatch нет связности с ElmoNet (TietoKettu использует их адреса), после недели-двух бодания с техподдержкой HostHatch-a связность появилась. Однако недели две назад от них приходит письмо, о техобслуживании нод, где живут мои ВМки. И что вы думаете? После обслуживания туннель до этих ВМок так и не восстановился. В итоге, оказалось что обе вмки исчезли их IPv6-интернета. На этот раз связность починили только через 3 дня, хотя я создал срочный тикет.

В итоге, я перевёл туннели обратно на IPv4 и переключился на DN42, но в один выходной мне на глаза попалась статья на Reddit и я решил воскресить идею о "своем" куске Интернета. Масла в огонь подбавил Vultr, который наглухо заблокировал доступ на свои ресурсы (даже IP calculator) с Hetzner.

В одном из комментов, к вышеупомянутой статье, была ссылка на IPv6-сообщество в Discord. Я присоединился и стал задавать много вопросов в канале #asn-newbies.

Думаю, что кому-нибудь мой опыт и набитые шишки будет полезен. Если это так, то прошу под кат.

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

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

Однако я пришёл к выводу, что единого способа обработки ошибок не существует. Вместо этого я считаю, что работу с ошибками в Go можно разделить на три основные стратегии.

Несколько месяцев назад у нас появилась необходимость разработать CSI-драйвер для Kubernetes, который в первую очередь использовался бы для хранения дисков виртуальных машин в Deckhouse Virtualization, но также мог бы использоваться и со стандартными контейнерами в Kubernetes. У оборудования наших заказчиков, как правило, есть определенная специфика — чаще всего это классическая SAN (Storage Area Network) с внешним хранилищем и общим shared LUN, который выделяется на несколько узлов. На одном LUN одновременно работает несколько виртуальных машин или контейнеров.

Помимо всего прочего, от драйвера нам требовалась поддержка различных CoW-фичей, таких как снапшоты, thin provisioning и возможность выполнять live-миграцию виртуальных машин в Kubernetes. Из существующих решений можно было бы отметить некоторые свободные проекты, однако ни один из них не реализует все желаемые фичи. Кроме того, у них есть явные проблемы с масштабированием.