SQLite *

В жизни каждого инженера-фронтендера наступает момент, когда осознаёшь: далее не обойтись без кэширования данных из API. Всё может начаться с самых невинных вещей: сохраняем предыдущую страницу с данными, чтобы кнопка «Назад» срабатывала мгновенно; реализуем простенькую логику отмены действия или обеспечиваем слияние нескольких состояний от различных запросов к API. Но все мы знаем, чем такое кончается. Один за другим возникают запросы на новые фичи, и вскоре мы уже не покладая рук реализуем кэши данных, индексы для работы вручную, оптимистические мутации и рекурсивную инвалидацию кэша.

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

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

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

Выполняется обучение модели на множестве данных, сохранение весов (параметров) модели и использование сохранённых параметров для быстрого принятия решений. Обучение может длиться долго и требовать больших вычислительных мощностей и множества данных; обученная модель работает быстро и на слабых компьютерах. С помощью такого подхода выявляются закономерности в данных, качество результатов напрямую зависит от объёма данных для обучения.

В данной статье я хочу раскрыть суть машинного обучения на примере создания искусственного интеллекта для математической игры Баше (названа в честь французского поэта и математика Баше де Мезириака).

Я новичок в работе с базами данных и для их изучения (а заодно для изучения Питона) начал небольшой пет-проект. В процессе оказалось, что в моей многопользовательской системе запросы к БД всегда касаются только одного пользователя. «Отлично!» подумал я, «раздам каждому пользователю по табличке и сэкономлю ресурсы сервера на индексации!». Конечно сначала я почитал литературу и подобных решений в ней не нашел. Потом сходил на один из популярных ресурсов и там мне объяснили, что так делать нельзя. Но почему – никто объяснить не смог (или возможно не захотел). Поэтому я решил сделать небольшой тест на самых популярных БД – проверить что будет на самом деле.

В этой статье вы найдёте ответ на вопрос, как экспортировать БД из Access в SQLite без использования дополнительных утилит.

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

Добро пожаловать в этот подробный туториал, который научит вас работать с базой данных SQLite в языке программирования Python. В этом руководстве мы покроем все основные аспекты использования SQLite, начиная с установки и создания базы данных, и заканчивая выполнением сложных запросов и управлением транзакциями.

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

Для каких целей? На момент возникновения идеи было еще не совсем понятно. Но предпосылки развития идеи были.

В процессе своего обучения профессии ML engineer, пришло время и мне окунуться в мир баз данных. На курсе нам предложили два инструмента для работы с базами данных - это DataGrip и DBeaver (если же, по вашему мнению, существует более интересные продукты, то я буду только рад, если вы в комментария об этом расскажете). Я в своей статье задаюсь целью сравнить эти два инструмента - возможно это поможет кому-то с выбором.

Итак, приступим.

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

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

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

Всем доброго дня!

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

Возможно вам тоже покажется, что развитие Qt как минимум в части Sql остановилось этак лет 12 назад.

А ведь фреймворк заслуживает развития ибо базовые классы уровня QSqlTabelModel и QTableView предоставляют богатый функционал для реализации ваших запросов.

История создания регулярных выражений берет свое начало с 1942 года. В то время Уолтер Питтс — американский логик, работавший, в основном, в области когнитивной психологии, работал  с известным физиологом Уорреном МакКаллоком. Основой их работы были труды связанные с теоретическим построением нейронных сетей. Немного позже, американский математик Стивен Клини изучал события в сетях МакКаллока-Питтса и предложил способ описания таких событий при помощи языка регулярных выражений.

Работа Клини вышла в середине 50-х годов двадцатого века. Научные труды были бы забыты, но американский программист Кен Томпсон в конце 60-х годов обнаружил, что регулярные выражения можно использовать для задания шаблонов поиска строк в длинных текстах. Смысл поиска заключается в том, что регулярное выражения преобразуется в конечный автомат, который производит поиск строк, которые должны соответствовать определенным шаблонам. Для построения конечного автомата Томпсон придумал специальный алгоритм, который сейчас носит название «построение Томпсона». Таким образом Кен Томпсон смог принести в мир стандарт для задания поисковых шаблонов.

Сами по себе, регулярные выражения есть ни что иное, как текстовый шаблон, который соответствует какому-то тексту. В трудах Джеффри Фридла пишется, что: «Регулярные выражения— это мощнейший инструмент, хорошо известный программистам. Однако он может быть полезен не только программистам, но и всем людям, работающим с кодом или простым текстом». При использовании регулярных выражений человеку придется работать с литералами и метасимволами. Это два существенно различающихся по своей сущности понятия. Литералы – это обычные символы, т.е. при записи в строках регулярного выражения они интерпретируются так, как они записаны. Примером литералов в регулярных выражениях может быть любая буквенная последовательность. В свою очередь, метасимволы интерпретируются при поиске особым образом. Примером может служить символ «*», который задает последовательность любого количества литералов.

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

Автор Уилл Ларсон*, технический директор компании Calm, в своей статье признается, что никогда не был особенно хорош в «оценке». Поэтому он решил потратить несколько часов на развитие этого навыка, что со временем вылилось в текстовые заметки на эту тему. Под катом автор делится полезными правилами для оценки требуемого дискового пространства, а затем собирает фрагмент кода на SQLite3, чтобы продемонстрировать, как можно проверить результаты вашей «оценки».

*Обращаем ваше внимание, что позиция автора не всегда может совпадать с мнением МойОфис.

TLDR; Использование Sqlite в Laravel (или любых других PHP приложениях) для Unit-тестирования может привести к false positive результатам тестов. Тот код который пройдет тесты, не заработает после переезда в production и использования других БД, например, MySQL. Вместо этого разверните тестовую БД с использованием той же технологии и движка, которые будут использоваться вашим приложением в production.

Во-первых, позвольте мне начать с того, что я очень рад видеть, что вы проводите Unit-тестирование — вы на верном пути! Laravel познакомил многих разработчиков с миром Unit-тестирования, сделав утилиты для тестирования первоклассной частью фреймворка. Это круто! Но нам нужно убедиться, что наше чувство безопасности, которое мы получаем от наших Unit-тестов, верно.

Один из механизмов, которые Laravel предлагает для Unit-тестов, основан на использовании базы данных SQLite . Для ускорения выполнения тестов, база данных запускается непосредственно в оперативной памяти. Такое решение работает в 95% случаев. Но, дьявол кроется в деталях, в этих 5%.

Поговорим о причинах, почему это не лучший выбор.

SQL — концептуально странный язык. Вы пишете ваше приложение на одном языке, скажем, на JavaScript, а затем направляете базе данных команды, написанные на совершенно другом языке — SQL. После этого база данных компилирует и оптимизирует эту команду на SQL, выполняет её и возвращает вам данные. Такой метод кажется ужасно неэффективным, но, всё-таки, ваше приложение может проделывать сотни таких операций в секунду. Просто безумие!

Но на самом деле всё ещё страннее.

По белой книге Адаптация Алексеев Денис делается последнее поколение приставок RyBox. С Романом Душкиным мы работаем над тем, что мы обретём Сильное Бессмертие благодаря внедрению Метода тотального контроля (МТК -8) отличающийся от МТК 6 и 7 наличием показателя УЦД(уникальность цифрового двойника).
Метод тотального контроля (МТК6):

I. Наблюдение как система выполняет операции

II. Тестирование и постоянное обновление

III.Определение тенденций развития

IV.Детальный анализ данных на выходе

V. Написание отчёта о результатах

VI.Завершающий диалог с системой

VII. Тестирование

(МТК ЭиО)

Анализ теста Сотрудника

Обновление ИОТ/(база знаний)

Определение тенденций развития Руководителем

Детальный анализ Ментором работы Сотрудника

Написание отчёта о результатах

Завершающий диалог с Сотрудником

Тестирование подготовки Сотрудника Отделом Качества

Э- эксперт
О- обучающийся
ИОТ - индивидуальная образовательная траектория

И так резюмируем какие МТК кого контролируют
Метод Тотального Контроля 6 - Роботы
Метод Тотального Контроля 7 - Люди
Метод Тотального Контроля 8 - Цифровые Двойники
Метод Тотального Контроля 9 - Клоны
Благодаря Клонам мы приближаемся к Сильному бессмертию

МТК Х - волшебники.

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

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

Исходный код на GitHub

Вы когда-нибудь задумывались над тем что ваши Dao это сплошной повторяющийся код и выглядит это все как ночной кошмар? Тогда я знаю решение вашей проблемы.

Меня зовут Бен Джонсон, и я написал встраиваемую базу данных, которая служит бэкендом систем вроде etcd, — это BoltDB. Сегодня я работаю над Open Source проектом Litestream в компании Fly.io. Благодаря репликации Litestream делает SQLite приемлемым для фулстек‐приложений. Если вы можете установить SQLite, то Litestream заставите работать за 10 минут.