Storing secrets in git repository

Sometime you may want to store secrets in git repository and keep track of changes history. For example you may want to store a production configuration or any other sensitive information.

You may already know that git-crypt may be your friend in this case. But what you can do in case if you developing software using Windows platform like I'm doing this? That's may be a problem to use this nice tool on Windows OS.

You may find binaries for git-crypt somewhere on the internet, but would you trust to such binaries? I believe not.

What can we do in this case? We can build our own binary and test it on our repository.

In this article we will build such binary and will do few experiments to check that it will work for us.

Python: improving time required to load 1.5G CSV file

In previous post we discussed how we can search for specific item in 1.5G CSV file with 132M records. And we improved search from 73625.309 ms (more than a minute) to just ~0.005 ms - almost 15 million times faster. Which is pretty impressive improvement as per my understanding.

But there is still one bottle neck that can be improved - time required for first initial scan of the file. Let's try to improve this in this article.

All source files can be found in JFF-Bohdan/item_lookup

Python: playing with big lists (132M records), checking if item in list

Let's imagine situation when we need to check if item is in list and our list is pretty big. For example, we may have file with hundreds of millions records and we need to develop solution which should be able quickly say if we have specific item in that list or not.

Let's start with naive implementation and then try to improve it iteratively.

This post was inspired by post https://habr.com/ru/post/538358/

Охотничий кот

 Стандарты безопасности 60-х.

Итак, мой рассказ о дресированном охотничьем коте.

Simple package for duplicate files removal

Just created simple Python package that will use for duplicate images removal. Also may be used for identical files removal with any type of content.

Fast autocomplete using Python and Redis

Fast autocomplete using Python and Redis

General information

Problem

Imagine situation when you need provide autocomplete for some data list. In case when you using SQL probably you will do something like this:

select * from table_name where table_field like 'search%'

Probably you know, that when you database contains significant amount of data you will get essential decreasing of data processing.

N-Queens problem solving program

N-Queens problem solving program

N-Queen problem - you need N chess queens on a chess board with dimensions NxN in a way that they do not threat each other (according to chess rules).

Program can find all possible solutions for N-dimensional board. Also, program able to print available solutions to console or to the file.

Here is my solution in Python language: https://github.com/JFF-Bohdan/nqueens (MIT license)

Yet Another Tiny Backup

Yet Another Tiny Backup

General information

Backup tool for one of my production instances. It implements very simple logic for my special requirements.

Algorithm: yatbackup can compress whole folder using specified archiver. In case, when another backup with same hash available in destination folder, new archive will be deleted.

Yes, it's all.

Why do I need it? I need create backup of some folder using cron, but I don't need duplicate archives.

Also, I need to understand that utility successfully finished, even no new archives was created.

Source code and documentation available here: https://github.com/JFF-Bohdan/yatbackup

pynvr - Python NVR (Network Video Recorder) based on OpenCV.

pynvr - Python NVR (Network Video Recorder) based on OpenCV.

Source can be found here: https://github.com/JFF-Bohdan/pynvr

General information

pynvr can interract with cameras using OpenCV (supports many types of connection including connection to USB cameras and network cameras using RTSP, for example)

Captured video stream must be analysed for motion and then saved to files according to specific rules.

When motion detected (or rule triggered) not only video after start must be saved but some frames before (pre-alarm/pre-event frames) must be saved to output file.

О проекте TapVisor

О проекте TapVisor 

Предназначение системы

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

Система ориентирована на B2B и представляет из себя SaaS. Клиент создаёт в системе организацию к которой подключаются источники данных, собирающие информацию на торговых точках или точках автоматизации.

Система спроектирована максимально абстратно, таким образом можно собирать самую разнообразную информацию и автоматизировать такие задачи как:

1. контроль температурного диапазона;
2. контроль влажности;
3. сбор информации о торговле товаром;
4. контроль налива жидкого товара;
5. контроль наличия объекта на базе - например для проката.

В данный момент система собирает такую информацию:

1. события о продажах вина и пива;
2. прокат туристического оборудования на точках проката;
3. температуру на большом количестве пивных кранов в пабе.

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

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

Для сбора информации могут быть использованы как специализированные контроллеры так и решение с необслуживаемыми компьютерами - Raspberry Pi, Orange Pi, etc. Такое решение позволяет максимально быстро выполнить автоматизацию объекта, а в дальнейшем, при необходимости произвести специализированный контроллер.

Система изначально проектировалась для работы с клиентами из разных часовых зон, события в центральной БД имеют несколько атрибутов дата/время, с учётом временных зон. При проектировании контроллеров и кеширующих узлов на базе RPi максимальное внимание было уделено работе в среде с задержками и сбоями при передаче данных. Для обеспечения безопасности, передача данных осуществляется с использованием RSA + PKCS1_v1_5 + AES (для мощных кеширующих узлов) либо с использованием алгоритма Speck для слабых контроллеров.

Где и как это можно увидеть

В системе предусмотрен демо-режим, позволяющий ознакомиться с интерфейсом, для полученя доступа к демо-режиму можно войти в систему http://tapvisor.com с таким данными:

Login    : "demo" (без кавычек)

Password : "demo" (без кавычек)

В этом режиме можно увидеть часть функциональности, доступной владельцу организации подключённой к сервису TapVisor. Эта демо-организация состоит из трёх торговых точек по продаже пива:

1. Cork / Пробка
2. Roger's Place / У Роджера
3. The Pub / Пивбар

и торгуёт такими товарами:

1. Ginger Beer / Имбирное
2. Lager Beer / Светлое
3. Light Ale / Эль
4. Porter / Тёмное 

Среди виджетов можно отметить такие:

• Sales - выручка по магистралям за сегодня и вчера;
• Dashboard - аналитика по продажам, более подробно вы можете прочитать тут http://tapvisor-help-ru.aminis.com.ua/dashboard
• Charts - здесь можно построить графики о продажах по часам, по дням;
• Reports/Sales-products - информация о продажах товара с возможностью наложения фильтров по точкам, дням;
• Director of the world - карта с отметками всех точек. Цветом и текстом можно визуализировать самую важную информацию: выручку за день, состояние остатков, то насколько был выполнен план на день и т.д.;
• Stock/Parameters - контроль остатков на точке, предоставляется информацию о том сколько товара того или иного типа осталось на магистралях точки;
• Reports/All events - список все событий, происходящих на точке

Особенности режима:

1. в этом режиме нет доступа к изменению настроек;
2. предоставляется доступ к данным с 2017-02-20;
3. предоставлен доступ не ко всем виджетам;
4. возможности системы и распределение возможностей по тарифам можно посмотреть тут: http://tapvisor.com/tariffs

Как это устроено внутри

 Back-end

Система написана на Python, используя Flask и SQLAlchemy. В качестве СУБД используется PostgreSQL, для LRU кеша использован Redis. Используется связка nginx и uwsgi.

Для оптимизации скорости выполнения запросов используется:

1. roll-up's (свертки) для  событий, используемых для построения Dashboard;
2. sharding - на базе Citus single-machine cluster с некоторым количеством worker'ов, обрабатывающих шарды. Шардинг используется в режиме multi-tenant application c table co-location, что обеспечивает обработку SQL запросов в пределах одного шарда;
3. фоновое вычисление данных которые могут в будущем понадобиться пользователю;
4. кеширование результатов запросов и тех данных, что могут понадобиться пользователю в Redis;
5. концепция "горячего архива" - архив за последние несколько дней для "горячих клиентов" (активных пользователей). Более старые события хранятся в "обычном/холодном архиве";

Используемая OS - Debian.

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

Front-end

Используется TypeScript и Bootstrap, позволяющий корректно отображать сайт на старых версиях iOS и обеспечивающий совместимость с максимальным количеством браузеров.

Используемые библиотеки: Nodejs + webpack + typescript + jQuery + bootstrap 

 

Для визуализации графиков используются  Highcharts

Визуализация таблиц (с поддержкой тонких настроек рендеринга, pagination и динамической подгрузки данных) -  DataTables.

Как это было сделано

Для управления проектом использовалась такие инструменты как:

1. Redmine - управление проектом;
2. git - контроль версий;
3. Google Drive/Google Docs - хранение протоколов, документации на узлы системы, описание протоколов взаимодействия узлов системы.

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

После того как в системе были накоплены  данные мы приступили к оптимизации, проходившей по следующему алгоритму:

1. мы выявляли медленно работающие виджеты и сопоставляли фактически обнаруженное с нашими предсказаниями о том, что и как будет замедляться;
2. выполняли профилирование;
3. искали методики, позволяющие выполнить оптимизацию;
4. тестировали и внедряли решение по оптимизации.

Что самое важное в оптимизации? Можно отметить такие моменты как:

1. накопление данных в БД, при этом параллельно необходимо выдвигать предположения о том какие  ожидаются результаты по работе того или иного виджета;
2. тщательное профилирование и поиск того что на самом деле медленно работает, а только затем оптимизация.

Надеюсь вам нравится результат.

Приятного использования.