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

Существующие приложения, как правило, не могут предоставить готовое решение для работы в таком контексте. Приходится придумывать или создавать что-то свое. Самое простое — это начать с каких-то стандартных заметочников, например Evernote или OneNote, и приспособить их под себя. Однако с появлением Roam-подобных программ пришло понимание, что можно создать очень гибкую систему, которую легко настроить под ведение любого вида задач, проектов и хранение различного типа связанной с ними информации. В этой статье познакомимся с примером настройки и практического использования маркдаун-заметочника Obsidian совместно с методологией Getting Things Done (GTD) Дэвида Аллена.

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

Привет! Меня зовут Сергей, я более 11 лет в тестировании, и успел за это время перепробовать множество разных подходов в QA — начинал простым тестировщиком, затем строил и развивал всевозможные отделы тестирования и автоматизации, а сейчас работаю в QIWI.

В этой серии постов я хочу поговорить с вами про тестирование трех популярных так называемых не-REST-бэкендов. Самое главное для начала — определиться с терминами, договоримся, что везде в тексте, где я упоминаю REST — речь идет именно о REST HTTP-бэкенде. Наверняка многие из вас с ним работали и вообще неплохо знакомы.

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

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

Привет! Меня зовут Артём Гордиенко, я работаю Java/Kotlin-разработчиком в Росбанке и занимаюсь разработкой микросервисов, необходимых для внешнеэкономической деятельности интернет-клиент-банка юридических лиц. Реализация этого доклада стала возможной благодаря одному-единственному сообщению, обнаруженному в логах одного нового микросервиса. Как оказалось, причина сообщения серьезно влияет на производительность приложения. Мне это показалось довольно интересным, и захотелось поделиться информацией с другими разработчиками. 

Многие сталкиваются с реализацией вывода списочных данных с пагинацией из БД. В Spring Data и в самом Hibernate есть стандартные решения, которые позволяют достаточно просто решить эту задачу. Но у предлагаемых решений есть подводные камни, и со временем или даже сразу они могут серьезно повлиять на производительность. В худшем случае — и вовсе привести к падению приложения.

В этом посте, основанном на моем докладе с JPoint 2023, я расскажу, при использовании каких стандартных решений вы столкнетесь с падением производительности и какие есть эффективные варианты реализации запросов с пагинацией. Также обсудим баги в Hibernate 6, которые я обнаружил.

В данной статье будет описано, как создать простой kafka producer и kafka consumer, а затем протестировать их.

Привет, Хабр, меня зовут Дима. В последние пару лет занимаюсь аналитикой, отвечаю за данные в Почте Mail.ru. Развиваю аналитическое хранилище данных и инструменты для работы с ними. Мы плотно работаем со стеком Hadoop, Hive, Spark, Clickhouse и Kafka. Я хочу остановиться на некоторых аспектах работы с данными в Spark: как мы храним петабайты информации и как выполняем запросы к ним?

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

Привет, Хабр! В прошлой статье я  писал о том, как реализовать end-to-end тестирование telegram-бота. А сегодня расскажу о том, как реализовать полнотекстовый поиск в Postgres посредством SQLAlchemy и как его проиндексировать. 

Меня зовут Михаил Выборный, я python-разработчик, backend-developer в облачном провайдере beeline cloud. Вы узнаете, как подготовить файл миграции для alembic. В конце статьи я приведу ссылку на небольшой репозиторий, где реализовал сервис-класс для удобной интеграции поиска в свой проект. 

Планшет Blackview Tab 12 Pro является типичным представителем мультимедийных планшетов, которые созданы для приятного времяпрепровождения. Большой экран, стерео динамики, внушительный объем памяти — все это способствует просмотру различного рода контента и интернет серфингу. Причем благодаря поддержке 4G вы можете использовать его не только дома, но и на работе, в отпуске или в дороге. Стоит отметить, что планшет получил алюминиевый корпус и здорово выглядит, а в стандартную комплектацию включены чехол-книжка и защитное стекло на экран. При всех озвученных преимуществах, Blackview Tab 12 Pro является весьма доступным девайсом и не разорит семейный бюджет.

Статья объясняет внутреннюю архитектуру виртуальной машины Java (JVM). Диаграмма отображает ключевые внутренние компоненты типичной JVM, которая соответствует спецификации The Java Virtual Machine Specification Java SE 7 Edition

Оглавление: Уроки компьютерного зрения. Оглавление / Хабр (habr.com)

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

Напомню, какие шаги были сделаны на прошлом уроке:

• Применить медианную фильтрацию к изображению.

• Провести бинаризацию.

Сегодня мы пойдем чуть дальше: выделим контур и найдем на нем прямоугольник номерного знака. Для начала напишем класс, который производит выделение контура:

Всем привет! Это моя первая статья на Хабр (поэтому не судите строго).

Дело было так: смотрел я как-то в окно и увидел, как человек сидит в машине на парковке и ждет, когда освободится парковочное место. Бывает, что и я сижу в машине и жду, когда же можно будет припарковать своего верного коня. И тут я подумал, а почему бы не подключить Компьютерное Зрение для этого? Зачем я учился разработке нейросетей, если не могу заставить компьютер работать вместо меня?

Изначально идея заключалась в следующем: Модель на базе компьютерного зрения должна через веб-камеру, установленную дома, отслеживать освободившиеся места на парковке и информировать через telegram-бота если такое место появится. Работать будем на Python.

Итак, ТЗ для меня от меня сформулировано, теперь за дело!

Первое с чем необходимо было определиться, это решить, какую модель детектирования объектов использовать. Сначала мой выбор пал на Fast R-СNN. Модель показывала хорошее качество детектирования. Однако после нескольких дней прокрастинации обдумывания реализации я решил воспользоваться более современными и интересными методами и подключить детектор от YOLO (взял не самую новую 4 версию).

Хабр, привет! Меня зовут Артем Терзьян, я Java-разработчик в IBS. Именно на мои плечи пала нелегкая задача выбора идеального BPMN-движка для реализации с его помощью бизнес-процессов в рамках нашей собственной платформы. Надеюсь, приведенный обзор поможет кому-то сэкономить время при столкновении с аналогичной задачей.

В 2017 году я начал изучать Java. И, чтобы как-то визуализировать результат трудов, я решил сделать десктопное приложение (функционал продублирован в Telegram боте).

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

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

Здравствуй, дорогой читатель. Каждый разработчик, независимо от его специальности, сталкивался (или столкнётся во время своей профессиональной карьеры) с задачей, в которой необходимо разработать проект, имеющий базу данных, серверную часть и конечный продукт, взаимодействующий с пользователем. Данная статья поможет новичку разобраться с данной задачей.

В статье будут затронуты такие важные темы, как теория баз данных, реляционная база данных PostgreSQL, Spring Framework и Android разработка. Также будет рассмотрен базовый, не очень сложный пример, который поможет разобраться во всех этих темах и "потрогать" их руками.

Статья предназначена для начинающего разработчика, но имеющего базовые знания о разработке программного обеспечения и языках программирования Java и Kotlin.

Все материалы и исходный код можно найти здесь.

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

Сейчас же у нас есть супер-мощные инструменты для управления сервисами. Они позволяют иметь несколько разных версий сервиса одновременно. Бизнес-пользователи могут управлять тем, какую версию видит та или иная группа пользователей. Обновление и откат версии сервиса могут происходить без прерывания работы пользователей. И когда появился такой мощный и красивый молоток, все начали хотеть забивать гвозди только им. Даже те, кому это, на самом-то деле, вообще не нужно. И тут есть проблема - наличие инструмента не означает автоматической готовности сервисов для того, чтобы этот инструмент с ними можно было использовать. И если обновлять сервисы старым способом было сложно, то новым это делать еще сложнее. Давайте посмотрим, почему это так, и как вообще получить этот ваш Zero Downtime.

Я написал книгу и назвал ее "Электрообереги". Она рассказывает про те замечательные устройства в электрощитке, что спасают нас от погибели. Начиная от предохранителей, которые существуют более века, заканчивая новейшими устройствами защиты от дугового пробоя. (Включая АВ, АВДТ, ВДТ, УЗО, РН, УЗИП, СГД и т.д.) Рассказ построен так, чтобы даже блондинке стало ясно как эти устройства устроены и зачем они нужны. Кто давно на меня подписан подобные посты уже видел - книжка представляет собой собранные воедино и причесанные публикации за последние два года. Еще я перерисовал все сторонние иллюстрации и теперь книжка лицензионно чиста - ни один мерзкий копираст не подкопается.

А еще сегодня у меня день рождения. И это хороший повод сделать подарок миру - книжка публикуется под открытой лицензией CC BY-NC-SA, тоесть ее можно распространять совершенно свободно.

Самодельная автоматически обновляющаяся газета на E-Ink с использованием Rust и ChatGPT — как вам такой DIY?

CRaC (Coordinated Restore at Checkpoint) — это проект OpenJDK, разработанный Azul для решения проблемы «медленного» запуска виртуальной машины Java в микросервисной среде.

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

В механизме восстановления контрольной точки (checkpoint-restore) нет ничего нового, и большинство из вас уже знают и используют его ежедневно. 

Если вы работаете на ноутбуке и закрываете крышку, операционная система обнаруживает это и сохраняет текущее состояние на диск. Как только вы снова открываете крышку, операционная система восстанавливает сохраненное состояние с диска.
CRaC предоставляет тот же механизм, но для JVM и вашего запущенного приложения.

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

После этого вы сможете восстанавливать состояние JVM, включая состояние вашего приложения, из этой сохраненной контрольной точки так часто, как вам захочется.

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

Подробный рассказ о том, как я свой дом и сад сделал умными. С фото, техническими деталями, стоимостями и выводами на будущее.