Доброго времени суток, Хабровчане! В этой статье я хочу рассказать о своем опыте упрощения взаимодействия с базами данных SQL при разработке десктопного приложения с помощью класса QSqlRelationalTableModel кроссплатформенной библиотеки Qt.

Пролог

С Qt я познакомился еще будучи студентом 1 курса, только начиная программировать на C++, тогда же и серьезно заинтересовался библиотекой и, с тех пор слежу за ее апдейтами. Несколько месяцев назад на работе мне дали ТЗ, в котором требовалось разработать приложение, взаимодействующее с БД SQLite. Структура базы фиксирована и заранее известна мне из ТЗ.

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

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

Привет, Хабр и его обитатели! Захотелось изваять нечто на HTML и JS, чтобы было десктопное и удобное. Что для этого нужно? Правильно. Node.js и NW.js или Electron. Поглядев на слабые попытки холивара NW vs Electron и почитав документацию и того и другого было принято решение для начала пощупать NW.js.

Но вот ведь засада. Выполнение npm i sqlite3 устанавливает только те библиотеки, которые могут исполняться при непосредственном запуске через node. А если попытаться подключить скрипт в html и запустить этот html в NW.js, то ничего у нас не выйдет. Гугл сотоварищи выдает только один рецепт включения sqlite в проект на nw.js, да и тот приходится вытаскивать из кэша. Да и устарел он уже. Посему было потрачено пару дней на изучение проблематики и поиск рабочего решения. Прошу под кат.

Привет! Сегодня я выпустил новую версию ThinkingHome.Migrator — инструмента для версионной миграции схемы базы данных под платформу .NET Core.

Пакеты опубликованы в NuGet, написана подробная документация. Вы уже можете пользоваться новеньким мигратором, а я расскажу, как он появился, почему у него номер версии 3.0.0 (хотя это первый релиз) и зачем он нужен, когда есть EF Migrations и FluentMigrator.

В одном из комментариев, присланным участником garex, в ответ на заявление:

Но сегодня в стандартной версии openssl отсутствует поддержка как ГОСТ Р 34.11-2012, так и ГОСТ Р 34.10-2012. Более того в версии 1.1 поддержка криптографии ГОСТ исключена из стандартной поставки («The GOST engine was out of date and therefore it has been removed.»)

было сказано:

Чем не устраивает вот эта, которую «убрали?» github.com/gost-engine/engine
Пример билда: github.com/rnixik/docker-openssl-gost/blob/master/Dockerfile

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

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

Ссылка на GitHub для нетерпеливых

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

Данная статья расскажет про библиотеку на Kotlin, которая позволяет писать SQL запросы в синтаксисе Kotlin. Также, мы немного посмотрим на внутренности библиотеки, чтобы понять как это работает.

Если одним из главных объектов инфраструктуры открытых ключей (ИОК) являются сертификаты X509, то центральным субъектом ИОК являются Удостоверяющие Центры (УЦ). Именно УЦ выпускают сертификаты, прекращают их действие (отзыв сертификата), подтверждают их валидность. На страницах Хабрахабр можно найти различные публикации на тему выпуска цифровых сертификатов с использованием OpenSSL.

Конечно, вы постоянно что-то редактируете и прекрасно умеете это делать. А что насчёт данных в мобильном приложении, когда на экране нужно разместить большое количество элементов? Не забудьте, что сделать это нужно максимально аккуратно для пользователя, эффективность которого напрямую зависит от удобства ввода. Задача перестаёт быть тривиальной.

Прочитав статью, вы узнаете, как:

• организовать структуру данных, чтобы их было удобно редактировать
• обеспечить «динамизм» вашему UI
• определять, изменилось ли что-то
• сохранять историю изменений
• сделать многопользовательский режим за 5 минут

В конце вас ждет готовый прототип с исходным кодом, демонстрирующим описанный подход.

Недавно мой знакомый Karl (имя изменено) проходил собеседование на должность DevOps и обратился ко мне с просьбой проверить его решение. Я почитал условие задачи и решил, что из нее бы вышел неплохой тест, поэтому немного расширил задачу и написал свою реализацию, а заодно попросил коллегу Alex подумать о своей реализации. Когда все три варианта были готовы, я сделал еще две сравнительные версии на C# и сел писать эту статью. Задача довольно проста, а соискатели находятся на неких ступенях эволюции из админов в программисты, которые я и хотел оценить.

Кому интересны грязные детали, необъективные тесты и субъективные оценки — прошу под кат.

Содержание

• 1. Введение
  
  • 1.1. Правки
• 2. Несколько причин, почему SQLite не использует Git
  
  • 2.1. Git затрудняет поиск потомков после коммита
  • 2.2. Ментальная модель Git излишне сложна
  • 2.3. Git не отслеживает исторические названия ветвей
  • 2.4. Git требует дополнительной административной поддержки
  • 2.5. Git неудобен в использовании
• 3. Руководство пользователя Git по доступу к исходному коду SQLite
  
  • 3.1. Зеркала на GitHub
  • 3.2. Доступ через веб
  • 3.3. Доступ через Fossil
• 4. Дополнительно

1. Введение

SQLite не использует Git. Вместо этого у нас работает система управления версиями Fossil, специально разработанная и написанная для поддержки SQLite.

Люди иногда спрашивают, почему SQLite не использует Git, как все остальные. В статье мы попробуем ответить на этот вопрос. Кроме того, в третьем разделе приводятся советы для пользователей Git, как легко получить доступ к исходному коду SQLite.

«В чем же заключается преимущество?» — спросите вы, ну все дело в том, что в нем можно построить логику примерно из следующих выражений:

– Пользователь на шаге N?
– Сообщение содержит изображение и смайлик?
– Текст подходит под регулярное выражению «I am [a-zA-Z]+»?
– Время получения раньше/позже заданного?
– Это было нажатие на клавиатуре/обычное сообщение/inline-кнопка?

Большинство из этих правил могут быть в зависимости друг от друга, но об этом чуть позже.

Для начала, о чем я хочу рассказать:

1. Об идее проекта – зачем я это сделал, какие есть аналоги, но почему мне они не нравятся.
2. Архитектурных решениях, какие возникли трудности, как были решены.
3. Что получилось в итоге и стоило ли оно того, дальнейшее развитие.

Вступление

Как только на территории РФ вступил в силу запрет на анонимность в мессенджерах, у меня дошли руки написать пост про telegram-бота. По ходу создания бота столкнулся с большим количеством проблем, которые пришлось решать по отдельности, и буквально выцеживать крупинки информации со всего интернета. И вот после нескольких месяцев страданий и мучений (кодинг – не основное моё занятие) я наконец-то закончил с ботом, разобрался со всеми проблемами и готов поведать свою историю Вам.

Доброго времени суток, Хабровчане!

Проблема поиска по русским символам в SQLite давно уже стала притчей во языцех, причины ее появления довольно подробно описаны здесь. Впрочем, есть довольно распространенные решения данной проблемы, самым популярным из которых является подключение ICU, библиотеки, с помощью которой можно реализовать полноценный поиск по Unicode. Но мне хотелось более короткого в плане кода решения чтобы в результате поиск был:

• регистронезависимым;
• по русским и английским символам;
• игнорирование символа ё/Ё при поиске;
• быстрым;
• использовал встроенный NOCASE collation.

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

Да и после заявлений типа:

Что касается популярности этих сервисов, то центры госуслуг «Мои документы» привлекли чуть больше половины всех проголосовавших, незначительно уступив порталу «Активный гражданин»

как-то возникают лёгкие сомнения. Так что — приступим к сбору информации! А потом будем её анализировать. Для этого нам понадобится какой-нибудь язык (скажем, питон), какая-нибудь бд (скажем, sqlite) и какой-нибудь веб-скраппер, благо для питона их множество. Сразу говорю, в конце дам ссылку на получившуюся базу данных, можно сделать с ней что угодно.

Всем привет! Меня зовут Олег и я программист-любитель под Android. Любитель потому что в данный момент я зарабатываю деньги программированием в совсем другом направлении. А это хобби, которому я посвящаю свое свободное время. К сожалению у меня нет знакомых программистов под Android и все свои базовые знания я черпаю либо из книг, либо из интернета. Во всех тех книжках и статьях в интернете, которые я читал, созданию базы данных для приложения отводится крайне мало места и по сути все описание сводится к созданию класса являющегося наследником SQLiteOpenHelper и последующему внедрению SQL кода в Java код. Если не считать, что мы получаем плохо читаемый код (а если в нашем приложении появляется больше 10 таблиц, то вспоминать все эти взаимосвязи между таблицами тот еще ад), то в принципе жить можно конечно, но как-то совершенно не хочется.
Забыл сказать самое главное, можно сказать что это моя проба пера тут. И так поехали.

Интро

Каждая таблица в SQLite по умолчанию содержит приватный ключ на основе автоматически генерируемого 64-битного целого. Это эффективно и удобно в большинстве ситуаций. Неудобства начинаются, пожалуй, только в двух случаях:

• когда диапазона 64 бит не хватает (тогда стоит задуматься о целесообразности SQLite задаче)
• когда хранилище становится "распределенным"

Может показаться, что и второй задачи в комбинации с SQLite не должно возникать, но распределенность не всегда означает что-нибудь вроде BigData. Типичный пример (из-за чего лично мне и понадобилось исследование на эту тему) это приложение с возможностью синхронизации данных между устройствами. Это может быть как что-то небольшое, как записная книжка, так и более нагруженное, как история браузера. Проблемой тут становится не столько объем данных, сколько слияние нескольких баз. Очевидно, что целочисленные счетчики записей, начинающие отсчет с 1, неизбежно будут выдавать конфликтующие последовательности, а значит использовать их в качестве уникального идентификатора записи на нескольких устройствах уже нельзя. Можно заморочиться с разделением на поддиапазоны или "сдвиганием" айдишников записей перед их передачей, но это все кривые и хрупкие костыли. Никто так не делает, конечно же. Вместо этого каждое устройство присваивает своим записям что-нибудь вроде GUID-а – просто и надежно.

На первый взгляд нижеприведённый материал может показаться ещё одним банальным «хэллоууорлдом», «туториалом от Капитана Очевидность», коих уже предостаточно на просторах Сети, но это впечатление обманчиво. На деле чтобы добиться того же результата с нуля у WinForms-программиста, не работавшего ранее с Entity Framework Core (не путать с классической Entity Framework) и вооружённого только уже валяющимися в изобилии на просторах Сети туториалами по EF Core и документацией может уйти куда больше времени, чем он наивно ожидал до того, как взялся за дело. Так случилось и со мной. Посему хочу поделиться опытом.

Python DB-API – это не конкретная библиотека, а набор правил, которым подчиняются отдельные модули, реализующие работу с конкретными базами данных. Отдельные нюансы реализации для разных баз могут отличаться, но общие принципы позволяют использовать один и тот же подход при работе с разными базами данных.

В статье рассмотрены основные методы DB-API, позволяющие полноценно работать с базой данных. Полный список можете найти по ссылкам в конец статьи.

Требуемый уровень подготовки: базовое понимание синтаксиса SQL и Python.

Всем привет. Пишу на Хабре впервые, не судите строго. Хочу поделиться своим опытом поиска универсальной SQLite ORM библиотеки на С++ и моей новой разработкой собственной библиотеки для работы с SQLite на C++ sqlite_orm.

Когда я искал ORM'ку я отталкивался от нескольких ключевых пунктов:

• библиотека должна иметь как CRUD, так и не CRUD
• должны быть гибкие условия WHERE, а не тупо WHERE id = ?
• должен быть функционал миграций (синхронизации схемы) на случай обновлений приложения
• фичи вроде ORDER BY и LIMIT тоже должны быть
• сериализация классов не должна быть написана в своих классах. Это очень важный пункт для меня с тех пор, как я познакомился с Java и с Android-разработкой в частности. Android-разработчики стараются придерживаться принципа единственной ответственной (single responsibility principle), что очень важно если приложение собрано из разной кучи библиотек и модулей, которые могут меняться с течением времени. И поэтому самая популярная на github SQLite ORM'ка на С++ hiberlite меня не устроила способом сериализации — класс модели должен иметь статичную функцию serialize с кодом непосредственной сериализации. Я искал такой модуль, от которого бы не зависел код моей модели данных. Ведь у меня может быть несколько сериализаторов (JSON, XML, SQLite), и по-хорошему каждый должен прилагаться к модели данных, но никак ее не менять, а иначе получится каша в коде модели.
  

Ранее мы уже публиковали статью о том, как генерировать фиктивные данные при помощи Mimesis — библиотеки для языка программирования Python. Статья, которую вы читаете является продолжением предыдущей, потому мы не будем приводить основ работы с библиотекой. Если вы пропустили статью, поленились прочитать или просто не захотели, то, вероятно, захотите сейчас, ибо эта статья предполагает, что читатель уже знаком с основами библиотеки. В этой части статьи мы будем говорить о best practice, расскажем о нескольких, на наш взгляд, полезных особенностях библиотеки.

Данная статья написана по мотивам – мотивам разработки мобильного приложения, недавно вышедшего на платформах iOS и Android. Это событие можно было бы назвать заурядным и мало кому интересным, если бы не одно большое и несколько незначительных «но»: вся разработка (включая сервер) велась на Delphi, а в качестве СУБД, как ни странно, задействована совсем не SQLite. Автор, безусловно, понимает, что на текущий момент уже существуют мобильные Delphi-приложения, включая доступные в официальных магазинах, однако не наблюдает обилия русскоязычных публикаций, призванных, как минимум, предостеречь читателей от ошибок, сделанных разработчиком таких проектов. Написанное же здесь преследует цель помочь тем, кто сейчас выбирает СУБД для своего творения, либо уже остановился на каком-то варианте, но желает убедиться в правильности своего решения.

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