Смотрим, как вездесущий PostgreSQL справляется с нестандартными для реляционной системы управления базами данных (СУБД) ролями: хранением и поиском временных рядов, пар «ключ — значение», эмбеддингов для больших языковых моделей и многомерных кубов. Отвечаем на вопрос: действительно ли так нужно строить сложные архитектуры со множеством разнородных систем хранения данных — MongoDB, Redis, InfluxDB, Pinecone, ClickHouse, Apache Cassandra — или можно обойтись одним PostgreSQL?

Привет, Хабр! Меня зовут Александр Брейман, я доцент департамента программной инженерии факультета компьютерных наук НИУ ВШЭ и по совместительству эксперт Учебного центра IBS по управлению данными и архитектуре ПО. В прошлой статье я рассказывал о миграции с Oracle на PostgreSQL, а сегодня разберу, как последний работает с нетипичными видами данных.

Нейросети, которые вроде как должны были отобрать у всех нас работу, на поверку оказались не совсем такими, как мы себе представляли. Даже эталонный ChatGPT-4o запинается, неверно понимает задачи и допускает ошибки, какие не допустил бы даже ребенок. Тем не менее, даже его можно приспособить под выполнение некоторых бытовых задач, облегчив тем самым свои рутинные задачи. Например, у меня нейросеть проверяет за ребенком домашнее задание, считает расходы, проводит факт-чекинг моих собственных текстов и делает много чего еще. Но, конечно, для того чтобы ИИ был "в адеквате" и не косячил, нужно учесть несколько важных нюансов. Именно об этом и поговорим сегодня, причем в режиме "для новичков".

Я не знаю как правильно назвать обзор/гайд про эту плату. Самая китайская плата? Самая загадочная? Самая неоднозначная? В любом случае - одна из самых интересных!

Поговорим про OrangePi AIpro, плату от запрещённой в половине мира Huawei.

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

Когда спрашиваю у людей на собесах, или когда в команде решаем, как клепать очередной проект, такое порой слышу, что становится страшновато. Мне кажется, лет через 5 все компании будут обитать в мультивселенной безумия из “микросервисов”, которую они себе радостно построили, уходя от этих ваших страшных “монолитов”.

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

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

В этой статье будут рассмотрены основные подходы к проектированию архитектуры хранилищ данных (DWH), эволюция архитектур, взаимосвязь Data Lake, Data Factory, Data Lakehouse, Data Mesh c DWH, преимущества и недостатки подходов к моделированию данных. Материал будет полезен тем, кто работает с корпоративными данными: аналитики, инженеры и архитекторы данных.

Мем айсберг SQL: погружение в глубины изучения баз данных

Мем айсберг SQL — это вирусное интернет-изображение, изображающее айсберг с несколькими слоями. Вершина айсберга содержит общеизвестные концепции и инструменты SQL, такие как операторы SELECT и JOIN. Однако по мере погружения под воду становятся видны более абсурдные и малоизвестные аспекты SQL.

Довольно часто возникает необходимость визуально представлять результаты работы устройства в том или ином человеко-понятном виде (текст, картинка, видео). Если это устройство не является абсолютно автономным, то задача решается проще, мы не сильно зависим от источника питания. На просторах Хабра есть ряд публикаций, посвященных различным метеостанциям и другим устройствам с экранами, подключенных к постоянному питанию.

А вот если нам нужно собрать полностью мобильное устройство, работающее от аккумуляторов, то здесь проблема потребления питания может стать достаточно острой. Так, при сборке собственного планшета на базе Raspberry Pi 3 мне пришлось выделить под тачскрин отдельный аккумулятор, так как при использовании общего источника (Li-Po, 6000 мАмпер-часов) питания устройство могло проработать более часа, но при запуске какого-либо ресурсоемкого приложения резко возрастал ток потребления и устройство тупо отрубалось, так как аккумулятор просто не мог выдать такой ток.

Разрабатывая различные приложения, я часто сталкиваюсь с тем, как после очередного коммита, в репозитории я вижу один из важнейших файлов, когда я работаю с переменными окружениями, оказалась на странице репозитория на Github. Речь идет о файле .env, чья общедоступность может быть очень опасным. И для того, чтобы обезопасить хранение конфигурационных переменных и настроек моего приложения, используется данный текстовый файл.

Я работаю на VS Code, и я, to be honest, так и не понял, с какой стати .gitignore "не игнорирует" .env. Причем спокойно "игнорирует" другие файлы, директории.

Всё же, нужно действовать, исходя из конкретного кейса, но если вы не хотите, чтобы какой-нибудь John Doe воспользовался данными из вашего .env, то вы перешли по верной ссылке. Вы же не отдаете ключи грабителю с фразой "Грабьте мой дом", верно?

Десять лет назад я писал пару статей - Как загрузить последний Office с сайта Microsoft без всякого App-V / Хабр (habr.com) и Как загрузить Microsoft Office 16 с сайта Microsoft / Хабр (habr.com), при помощи на тот момент еще мало кому известным Office Deployment Tool.

Время бежит стремительно, за Office 2016 выходит Office 2019, Office 2021, и вот сейчас подошло время для Office 2024. Что ж, посмотрим, что поменялось в плане загрузки, установки и активации продукта за десять лет.

Для начала о версиях и изданиях Microsoft Office. Чтобы не быть слишком дотошным в описании, скажу коротко самое главное, - с годами линейка Office развивается, существуют разные подписки и планы обновления, - новые функции появляются в новых версиях, для старых версий выходят исправления ошибок и заплатки к найденным уязвимостям.

Microsoft давно перешел на систему распространения продуктов семейства Office по разным, так называемым, "каналам" (channels), в зависимости от того как часто вы хотите получать нововведения и обновления.

Ключевым отличием в текущей загрузке и установке Office от того, что было актуально во времена Office 2016, является то, что вы должны определить, каким каналом распространения вы собираетесь пользоваться, - то есть с какого канала собираетесь устанвливать сам продукт. Тем, кто хотел бы подробно изучить разные каналы распространения я предложу почитать первоисточник - Обновления Office - Office release notes | Microsoft Learn. Остальным кратко резюмирую - Microsoft сейчас предпочитает всем продать подписку на Microsoft 365 (то, что ранее называлось Office 365), с регулярно обновляемыми возможностями в течении так называемой Современной политики жизненного цикла. По этой же современной политике распространяется пользовательские (коробочные, ретейл) версии Office 2021. Office 2021, например, поддерживается лишь до 13 октября 2026. А более старые версии следуют, так называемой политике фиксированного жизненного цикла, в рамках которой Office 2016 и Office 2019 поддерживаются лишь до 14 октября 2025. В целом, они не перестанут работать после, однако, перестанут обновляться. И у тех из вас, кто пользуется почтовыми сервисами на базе Microsoft Outlook.com или Office365, а возможно и пользователям Microsoft Exchange, с обновлениями выпущенными после 14 октября 2025 уже пора призадуматься об обновлении.

А что если окажется, что простые знания на самом деле более нюансированные, а старые знакомые, такие как Double-checked locking, являются неоднозначными? Именно на такие мысли наталкивает изучение кода реальных проектов. Результаты этого исследования мы и рассмотрим в этой статье.

GraphQL — невероятная технология, привлёкшая много внимания с тех пор, когда я начал в 2018 году использовать её в продакшене. Вам не придётся долго листать мой блог, чтобы увидеть, как я раньше продвигал её. После создания множества React SPA поверх путаницы нетипизированных JSON REST API технология GraphQL показалась мне глотком свежего воздуха. Я искренне поддерживал хайп вокруг GraphQL.

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

В статье для примеров я буду использовать код на Ruby с превосходной библиотекой graphql-ruby, но я уверен, что многие из перечисленных проблем не зависят от выбора языка/библиотеки GraphQL.

Если вы знаете более качественные решения или способы, напишите мне комментарий.

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

Привет, Хабр! Меня зовут Максим Приходский, я архитектор R-Style Softlab и сегодня хочу рассказать вам о проекте создания архитектурного репозитория в git на базе PlantUML.

Привет всем! Меня зовут Юля, я фронтенд-разработчик, наставник на курсах по JS и React и организатор профессионального сообщества Tbilisi JS. В Практикуме я помогаю студентам на курсе «React-разработчик».

За время работы в разных компаниях и над разными проектами я поняла, что Git — это не только (и не столько!) знание самой технологии и конкретных команд, но и определённая культура взаимодействия, практики, подходы, договорённости. Всё это помогает участникам команды лучше понимать друг друга и работать быстрее и чётче.

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

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

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

Привет! Меня зовут Александр Каленюк, и я крепко подсел на C++. Пишу на C++ 18 лет кряду, и все эти годы отчаянно пытаюсь избавиться от этой разрушительной зависимости.

Всё началось в конце 2005 года, когда мне довелось писать движок для симуляции 3D-пространства. В этом движке было буквально всё, чем язык C++ мог похвастаться в 2005 году. Трёхзвёздочные указатели, восьмиуровневые зависимости, C-подобные макросы повсюду. Кое-где – вкрапления ассемблера. Итераторы в стиле Степанова и мета-код в стиле Александреску. В общем, всё. Кроме ответа на самый важный вопрос: зачем?

Юбилейная - 10-я - конференция PGConf.Russia опередила юбилей компании (Postgres Professional исполнилось 9 лет). А самая первая - PGConf.Russia 2015 - даже опередила саму компанию: конференция прошла в феврале, а официальный день рождения Postgres Professional 1 апреля 2015.

Меня зовут Дима Синявский, я SRE-инженер в Vi.Tech — это IT-дочка ВсеИнструменты.ру. В этой статье расскажу я вам о том как мы развивались и с нами развивалась наша система логирования. Почему вам нужен Vector.dev + Clickhouse для хранения и когда это выгодно.

Когда компания была маленькой нам хватало и блокнота, чего сейчас уже не скажешь.
У нас 931 000 пайплайнов в месяц, 4 кластера Kubernetes: от 170 до 190 нод в каждом, и 200 ГБ логов ежедневно.