В одной из предыдущих статей я описывал проблемы, которые возникают при работе с временными таблицами. Тогда я вкратце описывал, почему нам приходится их так часто использовать. В частности, одной из причин была неправильная работа планировщика запросов в PostgreSQL. Многие из проблем планировщика запросов (и не только PostgreSQL) были также описаны в статье Почему не SQL. В этой статье я покажу достаточно простой и часто используемый случай, когда планировщик ошибается, что может приводить к значительному росту потребления ресурсов. 

Проблема воспроизводится на последней стабильной на данный момент версии PostgreSQL - 16.2. При этом используются стандартные настройки PostgreSQL. Я пробовал менять разные настройки, но мне не удалось добиться правильного плана в общем случае, поскольку в данном случае проблема скорее логическая, а не в определении стоимости вычислений. Однако, каждый может легко воспроизвести эту ситуацию локально и попробовать поиграться с настройками. 

Рассмотрим простую доменную логику, в которой есть документы и их строки. Для каждой строки вводится сумма. Строки лежат в отдельной таблице и ссылаются на документ :

О том, как сделать прозрачную синхронизацию заметок Obsidian между устройствами (Desktop, Android, iOS) через GitHub:

1. Без сторонних приложений (вроде iCloud, SyncThing, Termux и пр)
2. Бесплатно
3. Бонусом — резервная копия: как самих заметок, так и истории изменений.

В результате получается полноценная замена Notion: структурированные заметки с автоматической синхронизацией между устройствами.

Если вы не знаете, что такое префикс-функция строки, не знаете, как она вычисляется, или, что самое главное, не до конца понимаете, почему алгоритм вычисления префикс-функции работает за линейное время, то эта статья для вас.

Я прошел через череду осознаний и озарений, прежде чем достичь просветления, и теперь предлагаю вам пройти этот путь вместе со мной.

Хабр, в связи с уходом Notion выросла потребность в аналогичном решении, которое бы было сопоставимо удобной Wiki, Task Manager — платформе. 

Я испробовал десять self-hosted решений и нашел несколько почти идеальных! Вы можете развернуть их у себя на сервере, при работе над совместными проектами с командой или для ведения личных записей.

Задумывались ли вы когда-нибудь о том, что делает вас живым? Что делает живым хоть что-то?

В 2012 году на заседании Американского химического общества, посвящённом происхождению жизни, Эндрю Эллингтон предложил радикальную теорию: «Жизни не существует». Энди — профессор химии из Техасского университета в Остине, и это был первый слайд его презентации о химии РНК и происхождении жизни. Его идея оставила меня в невероятном недоумении.

Я была озадачена, потому что, наверное, должна была бы согласиться с Энди. Но я не согласилась. Когда я присутствовала на лекции Энди, я была абсолютно уверена, что жива, как уверена и сейчас. Вы, вероятно, тоже уверены, что живы. Разве вы не прожили всю свою жизнь, живя? Быть живым — это важно. Это очень отличается от того, чтобы не быть живым.

В этом тексте хочется подробнее рассмотреть хранение данных в PostgreSQL на физическом уровне.

Для начала определимся с общеизвестными вещами. Данные хранятся в таблицах, таблицы находятся в схемах, схемы, в свою очередь, в базах данных. Под данными я тут подразумеваю одну или несколько строк. В качестве примера будем рассматривать эталон критики, по моему личному мнению, цитаты Линуса Торвальдса.

Решил вспомнить счастливое детство и полазить по сайтам демосценеров — с удивлением обнаружил, что многие выкладывают релизы под.. FreeBSD.

FreeBSD — мягко говоря не самая подходящая система для занятия оптимизированной графикой, поэтому наличие такого количества демо создаваемых под эту систему озадачило.

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

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

Тут я хочу подытожить все опробованные подходы и выбрать лучший по моему мнению.

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

В этой части разберем устройство, виды и повадки современных телевизоров.

Основные характеристики — всякие яркости, HDRы, контрасты и цветовые охваты, что они значат и зачем нужно 120Гц, мы разобрали в предыдущей части.

Всем привет!

Flux.1 D — это мощная модель для генерации изображений по текстовому описанию. Меня зовут Вандер, я куратор клуба по нейросети Fooocus и нейро-энтузиаст, и сегодня мы разберемся, почему вам точно стоит обратить внимание на свежеиспеченную Flux.

Разработчики Flux - бывшие создатели Stable Diffusion и Stable Diffusion XL - Робин Ромбах и Андреас Блаттман. Оба выступали за идею, но компания преследовала только коммерческие интересы Как итог - произошел конфликт и ключевые фигуры покинули Stability AI. Недавно ими была создана новая компания The Black Forest Team, которая и представила нам Flux.

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

Модель очень хорошо следует промпту и распознает текст.

В статье мы посмотрим, как запустить Flux онлайн и локально, а так же на ее возможности.

Всем привет! Это команда Amnezia. 

Мы читаем комментарии под нашими постами и знаем, что один из самых частых вопросов – когда будет XRay? Так вот, мы добавили XRay в приложение AmneziaVPN, а точнее протокол Reality от XRay для всех платформ -  IOS, Android, Windows, Linux и MacOS. Если у вас еще нет последнего релиза, скорее скачивайте и создавайте VPN на собственном сервере в пару кликов с одним из самых защищенных и быстрых протоколов в мире, ниже мы немного о нем расскажем, а в конце статьи будет пошаговая  инструкция как это сделать.

Почему XRay Reality так популярен ?

Все дело в том, что Reality подходит для стран с самым высоким уровнем интернет-цензуры, сейчас его используют в Китае и Иране, он защищен от детектирования методами active probing. 

Распознать цензоров REALITY может еще на этапе TLS-хендшейка. Если REALITY видит, что к нему приходит его клиент, то сервер запускает для него VPN туннель, а если приходит любой другой запрос на 443 порт, то TLS-подключение передается на какой-нибудь другой реальный сайт, например, google.com, где цензор получит настоящий TLS-сертификат от google.com и вообще все настоящие данные с этого сайта.

Со стороны систем анализа трафика это выглядит как подключение к настоящему сайту, сервер отдает настоящий TLS-сертификат этого сайта, и вообще все (включая TLS fingerprint сервера) выглядит очень по-настоящему и не вызывает подозрений. 

Особенно приятно, что при этом производительность REALITY и скорость подключения у протокола действительно хороши, в сравнении, например, со связкой OpenVPN over Cloak.

Однажды один мудрый DevOps сказал мне: «DevOps’ы — это люди, способные сделать всё, лишь бы не делать ничего». Привет, Хабр, я Алексей Подольский, лидер направления инструментов безопасной разработки в Cloud.ru. Сегодня я расскажу, как сделать жизнь чуть легче, если кластеров кубера в проектах развелось столько, что за всеми не уследить. Будем объединять кластеры в один, да так, чтобы падали затраты, а не прод. Будет полезно админам, DevOps’ам, прикладным архитекторам, и всем, кто работает с Kubernetes. Поехали!

Я думаю, что вы не раз уже гуглили, заглядывали в статьи, манифесты IT-гигантов о лучших практиках проектирования API. Я тоже.

Но в большинстве из них всё ограничивается описанием URL ресурса, мотивацией использовать пагинацию, сложными словами про кэширование и SSL. Это, безусловно, необходимо для общего понимания технологий, но практически не помогает, когда ты сидишь перед пустой страницей и надо начать “проектировать контракт”.

Я работаю тимлидом направления системного анализа в X5Tech и за все время развития карьеры сталкивалась с большим количеством кейсов проектирования Web систем. IT продукты в большинстве очень динамичны: постоянно изменяются требования, появляются новые, итеративно улучшается пользовательский опыт (по принципу 20% усилий на 80% результата, а остальное доделаем потом).

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

В этой статье предлагаю спроектировать контракт по шагам, и на каждом из них я расскажу про общие рекомендации из копилочки “Полезное”, а также про личные правила и практики, полученные долгим опытом работы над постоянно меняющимися ИТ-продуктами, которые помогут для “дальновидного” проектирования GET REST API.

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

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

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

Продолжаю публикацию расширенных транскриптов лекционного курса "PostgreSQL для начинающих", подготовленного мной в рамках "Школы backend-разработчика" в "Тензоре".

Сегодня поговорим о самых простых, но важных, возможностях команды SELECT, наиболее часто используемой при работе с базами данных - формировании выборок (VALUES), их ограничении (LIMIT/OFFSET/FETCH), фильтрации (WHERE/HAVING), сортировке (ORDER BY), уникализации (DISTINCT) и группировке (GROUP BY).

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