Недавно мой знакомый 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-приложения, включая доступные в официальных магазинах, однако не наблюдает обилия русскоязычных публикаций, призванных, как минимум, предостеречь читателей от ошибок, сделанных разработчиком таких проектов. Написанное же здесь преследует цель помочь тем, кто сейчас выбирает СУБД для своего творения, либо уже остановился на каком-то варианте, но желает убедиться в правильности своего решения.

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

Приветствую, уважаемое сообщество!
Забегая вперед прошу прощения у тех, кто ожидает новизны или революционных идей. Их тут нет. Но есть вполне хорошая прикладная система.

Системы поддержки принятия решений сейчас набирают обороты. Причем я не буду особо останавливаться на перечислении способов реализации. Оговорюсь только об основных свойствах. Я бы очень упрощенно и обобщенно назвал эти системы вероятностными. То есть они выдают рекомендации с известной долей вероятности используя накопленную и проанализированную статистику. Не скажу что это плохо. Тема BigData и Machine learning нынче в тренде. Так же эти системы работают по принципу черного ящика. Поэтому проверить достоверность работы заложенной модели не всегда можно выявить.

Казалось бы, каждый, кто осваивает ардуино, первым делом конструирует или повторяет прибор для измерения температуры и(или) прочих параметров окружающей среды. Только большинство подобных конструкций, к сожалению, мало применимы в домашнем хозяйстве — в качестве тренировки сгодится, а пользы нет. Попробуем исправить эту недоработку. В статье расскажу о создании комплекса для измерения и хранения любых данных на примере сбора показаний датчиков температуры, влажности воздуха и атмосферного давления. Начну с требований к прибору и описания протокола обмена, закончу web-службой для получения данных из БД. Подробных выкладок и пошаговых руководств не будет, но будет немного теории и много кода.

Сразу же предупрежу о велосипедности выдаемого здесь на обозрение. Если прочтение заголовка вызывает лишь с трудом подавляемый возглас «Твою мать, только не новый таксон ORM!», то лучше наверное воздержаться от дальнейшего чтения, дабы не повышать уровень агрессии в космологическом бульоне, в котором мы плаваем. Виной появлению данной статьи явилось то, что в кои-то веки выдался у меня отпуск, в течение которого решил я попробовать себя на поприще написания блогопостов по околохабровской тематике, и предлагаемая тема мне показалась вполне для этого подходящей. Кроме того, здесь я надесь получить конструктивную критику, и возможно понять чего же еще с этим можно сделать этакого интересного. В конце будет ссылка на github-репозиторий, в котором можно посмотреть код.

Популярная в Android-среде СУБД SQLite позволяет организовывать удобные хранилища данных, её возможностей достаточно для многих приложений, но не для тех, что работают с информацией, которую надо защищать.

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

Столкнувшись с задачей подключить SQLLite к своему мобильному приложению iOS через FMDB, я не нашел ни одного актуального гайда на русском языке. И тем более для Swift. В этой статье я постараюсь этого исправить.

В этом гайде будут использоваться файлы с objective-c, поэтому не надо ждать порта FMDB на Swift.

Скачать FMDB можно тут.

В FMDB три main class:

FMDatabase — представляет данных SQLite. Используется для выполнения SQL-операторов.
FMResultSet — представляет результаты выполнения запроса по FMDatabase.
FMDatabaseQueue — если вы хотите, чтобы выполнялись запросы и обновления на несколько потоков, можно использовать этот класс. Пример в 8 пункте.

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

if (![db open]) {
    [db release];
    return;
}

Шаги:

Имеется типична ситуация:

• кем-то написанное приложение на Qt;
• пользователи жалуются, что программа во время работы жрем много CPU;
• профилировщик и strace указывают на то, что происходит насилование базы.

В такой ситуации хочется посмотреть что за запросы, их количество, время выполнения. Если в PostgreSQL есть pg_stat_statements и pgBadger, то для SQLite пришлось написать свой самокат. Самокат представляет из себя вызов sqlite3_profile для каждого соединения, запись полученной информации в журнал.

На сегодняшний день две мои самые любимые темы — SQLite и key-value базы данных. И в этот раз я пишу сразу про обе: этот пост посвящён Python-обёртке для используемого в SQLite 4 key-value хранилища на основе LSM.

Я не слишком внимательно отслеживаю релизы SQLite, но версия 3.8.11 привлекла моё внимание, поскольку в её описании заявлено серьёзное увеличение производительности по сравнению с 3.8.0. В сопроводительной информации я наткнулся на упоминание о новом экспериментальном расширении для полнотекстового поиска (о котором писал когда-то), и потому мне стало интересно, какая складывается ситуация с SQLite 4.

Изучив доступную информацию, я обратил внимание, что одной из задач разработчиков было обеспечить в новых версиях интерфейс для подключаемых движков баз данных. На момент написания этого поста в SQLite 4 уже было два встроенных бэкенда, один из которых — key-value хранилище на основе LSM. В последние пару месяцев мне доводилось поиграться с Cython, пока я писал Python-обёртку для встроенных k-v хранилищ UnQLite и Vedis. И я подумал, что было бы неплохо применить Cython для создания интерфейса движка БД на основе LSM, используемого в SQLite 4.

Разобравшись с исходным кодом SQLite 4 и крохотным заголовочным файлом LSM, я написал python-lsm-db (документация).