Мотивація
Сучасний розвиток технологій рухається в бік передбачення поведінки людини на підставі відстеження всього масиву її активностей у віртуальній і фізичній реальності (big data). У цьому є позитивний момент, оскільки якщо ви бачите, куди людина йде, то можна їй показати найбільш короткий і ефективний шлях. Але, за законом єдності і боротьби протилежностей, тут виникає наступна загроза (для маркетологів навпаки перспектива), як я її бачу - це можливість не передбачати поведінку, а формувати передбачувану поведінку.
Якщо цікаво, що з цим може вдіяти окрема людина - ласкаво просимо під кат.
Безумовно, якщо дивитися ще ширше, то саме суспільство, за допомогою культури та інших соціальних інструментів формує передбачувану поведінку особистості, але це занадто широко, тому що культура дає незрівнянно більший рівень свободи суджень на відміну від фокусованої інформаційної стрічки, тому звужуюся назад.
Отже, що може зробити окремий customer, щоб ускладнити завдання з формування власної передбачуваної поведінки? Для мене відповідь полягає в наступній фразі - щоб навчитися чимось керувати, необхідно навчитися це вимірювати.
Але що може вимірювати людина сама у себе і як це аналізувати? Рішення придумано досить давно - це ведення особистого щоденника (своя/моя little data) і подальший аналіз зафіксованих подій.
Але при веденні щоденника виникає наступна складність, принаймні для мене, це майже неможливість ефективної категоризації подій\об'єктів (я порочений об'єктно-орієнтованим мисленням). Наприклад, хотілося б окремо розглядати завдання, думки, питання, помилки, і т. д., бачити зв'язки між ними, отримувати аналітику. Треба відзначити, що частково приклади ефективного вирішення даної проблеми можна знайти в численних книгах з тайм-менеджменту. Але я спробував зробити свій велосипед.
Отже, які властивості може мати ідеальний щоденник:
- Заклад даних та їх швидка (у межі, автоматична) класифікація, за різними видами об'єктів, таких як, думки, завдання, нагадування, контакти, сон, нотатки тощо. Ведення зв'язків між об'єктами;
- Завантаження даних із зовнішніх джерел (соцмереж, банківських рахунків, трекерів фіз.активності);
- Автоматична побудова аналітики, за різними зрізами інформації;
- Видача підказок щодо поточних дій (завдання з високим пріоритетом, дні народження тощо);
- Можливість налаштування алгоритмів, за індивідуальною обробкою об'єктів;
- Система повинна надавати вибір, яка інформація доступна для публікація в зовнішню мережу, а яка залишається персональною (реалізація повинна забезпечувати чесність у цьому відношенні), дані в зовнішній мережі також класифікуються і розкладаються на складові;
- У межі будь-яка інформація, з якою стикається людина, і будь-яка інформація, яка генерується даною людиною повинна класифікуватися і вкладатися в такий щоденник.
А тепер, закінчивши з мріями, повертаємося з платонівського ідеального в наше грішне і, пропустивши через безліч кривих дзеркал, і не тільки дзеркал, отримуємо реалізацію концепту:
Завдання
Спочатку я ставив перед собою такі цілі:
- Створення будь-яких видів об'єктів без розробки;
- Виведення однакових об'єктів на окремій сторінці з відображенням у табличному вигляді, а також з можливістю переходу до окремого об'єкта та відображення\відання у вигляді картки;
- Можливість встановлення зв'язків між об'єктами;
- Налаштування статусів і категорій для об'єктів;
- Ведення аналітики\нагадувань\прогнозування.
Результати
Вийшло:
- Створення нових об'єктів;
- Створення статусних схем, прив'язуваних до будь-яких видів об'єктів;
- Є можливість створювати посилання між об'єктами, посилання відображаються в окремій вкладці. По суті посилання вирішують завдання спадкування і є зв'язками між будь-якими об'єктами;
- Гіперпосилання на об'єкти - можливо задавати пряме посилання на об'єкт;
- Для завдань є можливість створення окремих тек для зручності обробки.
Проблеми:
- Немає аналітики;
- Немає каскадного видалення дочірніх об'єктів;
- Немає можливості пошуку об'єктів;
- Немає можливості на одній сторінці обробляти кілька об'єктів;
- Складність створення нових видів об'єктів (опис об'єкта займає близько півгодини, навіть у мене як автора)
- Більш менш зрозуміла архітектура перетворилася на набір хаків
Рішення
Disclaimer! Автор не є професійним програмістом і фахівцем в області розробки на python\js, а всього лише аматором, тому ідеї щодо правильної організації архітектури і використовуваних технологій вітаються і я буду дуже вдячний за дані поради.
Код github
Використовуваний інструментар
Backend:
- Python 3.2.5 - Серверна частина
- SQLite 3.5.1 - База даних
Frontend:
- Bootstrap 3.3.6 - Відображення даних
- JQuery 2.2.0 - Логіка
- TinyMCE 4.3.2 - Редактор тексту. Додатково використовувався плагін syntaxhighlighter, для форматування коду.
- Datatables 1.10.10 - Відображення даних у табличній формі.
Архітектура розв "язання
Загальний опис архітектури
- На Python написаний сервіс, який крутиться на localhost і виконує обробку запитів від html-сторінок.
- Об'єкти представляють собою html-сторінки з певною розміткою, в якій вказуються назви полів, відповідають полям в базі даних (не використовується ніяких ORM рішень, обробка здійснюється своїм велосипедом)
- Спілкування з сервером відбувається через json-повідомлення.
- Всі об'єкти з сервера завантажуються при початковому завантаженні сторінки, в подальшому відбувається обмін тільки дельтою.
- Є вбудовані об'єкти, це статуси і відносини, інші об'єкти описуються окремо (див. нижче)
На жаль, у міру наростання функціоналу і бажання скоріше отримати закінчене рішення, архітектура почала розповзатися і не вдалося повною мірою інкапсулювати об'єкти, тому на практиці наявні різні хакі і моменти пробиття інкупсуляції, але в цілому схема актуальна.
Frontend:
- js - Точка входу для обробки подій frontend. Здійснюється ініціалізація початкових даних, обробка подій з html-сторінки, виклик інших об'єктів для роботи.
- js - Внутрішнє перетворення даних на необхідний формат для обробки залежно від сценарію.
- js - Обробка картки об'єкта, відображення даних картки для редагування, перегляду, зв'язків, збереження даних.
- js - Керування показом картки\таблиці на сторінці
- js - Обгортка для ajax-запиту
- js - Обгортка для роботи з datatables.net.
- js - Обгортка для роботи з TinyMCE
- % ObjectName% - Параметри, по кожному виду об "єкта.
- js - Всі можливі види об'єктів, доступних при відображенні відносин.
- js - Клас для обробки вигляду об "єкта
- js - Обробка відносин між об'єктами.
- js - Перетворення даних на формат для передачі на сервер.
- js - Константи.
Backend:
- py - Обробка запитів.
- py - Перетворення json-запиту з frontend на sql-запит для БД
- py - Виконання sql-запиту.
- py - Параметри.
- py - Параметри видів об "єкта на сервері.
- py - Створення директорій для завдань.
Схема бази даних:
- % object _ name% - Окрема таблиця для кожного створюваного об "єкта.
- sys_status - Можливі статуси, згруповані за статусними схемами.
- Sys_rel2obj_items - Дані зв «язків між об» єктами
- Sys_rel_object2object - налаштування стосунків між об "єктами
- object_type - Опис типів
- Sys_rel - Опис стосунків
Приклади JSON-повідомлень:
- Отримати статуси по об'єкту - {«object»: “status”, “action”:”select”, “items”:[{“id”:1,”msg”:{“fields”: [{“column”:”id”, “op”:”>=”, “value”:”0″}]}}]}
- Отримати відносини по об'єкту - {«object»: “rel_items”, “action”:”select”, “items”:[{“id”:1,”msg”:{“fields”: [{“column”:”obj1_type”, “op”:”=”, “value”:”project”},{“column”:”id1″, “op”:”=”, “value”:”22″}]}}]}
- Отримати можливі відносини об'єктів - {«object»: “sys_rel_object2object”, “action”:”select”, “items”:[{“id”:1,”msg”:{“fields”: [{“column”:”id”, “op”:”>=”, “value”:”0″}]}}]}
- Отримати всі об'єкти - {«object»: “project”, “action”:”select”, “items”:[{“id”:1,”msg”:{“fields”: [{“column”:”id”, “op”:”>=”, “value”:”0″}]}}]}
- Створити об'єкт - {«object»:”project”, “action”:”insert”, “items”:[{“id”:0,”msg”:{“fields”:{ “title”:”123″,”note”:”123” }}}]}
- Змінити об'єкт - {«object»:”project”,”action”:”update”,”items”:[{“id”:0, “msg”:{“fields_set”:{“title”:”1234″,”note”:”123”}, “fields_where”:{“id”:”22″}}}]}
Де:
- Object - тип об'єкта (наприклад, проект, завдання тощо)
- Action - тип дії (створення, видалення, вилучення, вилучення, отримати)
- Items - в рамках одного повідомлення, можна запитувати кілька елементів, наприклад, робити кілька insert.
- Msg - повідомлення в рамках одного пакета
- Поля Fields за цим об'єктом
Деякі з створених об'єктів:
- Project- ведення проектів.
- Task- ведення завдань
- Question- ведення питань
- Think- ведення думок, ідей тощо.
- Timing- контроль часу ()
- Розпізнавання контактів
- Diary- ведення особистого щоденника
- Snippet– snippet
Алгоритм створення нового об'єкта
- Створити таблицю в БД
- Створити файл% object _ name% .html
- Створити файл% object _ name% .js
- Описати об'єкт у файлі object2db.py
- За необхідності додавання статусу заповнити дані в таблицях (sys_status)
- При необхідності створення нових відносин заповнити дані в таблицях (sys_rel_object2object)
Більш детально не описував створення (і не записував відео, хоча спочатку ідея була), тому що вийшов досить довгий і нудний процес. Не став робити конструктор, оскільки для концепту він виявився надлишковим, але це перше з чого почну при розробці версії 2.0 см. нижче.
Плани на майбутнє для версії 2.0
Ідеал - робота з будь-якими об'єктами в рамках одного вікна, мінімум дій за допомогою мишки. Максимум перекласти на опис у командному рядку.
Ідеї:
- Редактор об "єктів. - Створення об'єктів, без необхідності ручного створення html-сторінок, наявності окремого js-файлу для об'єкта та окремого налаштування на python.
- Створення статусів.
- Створення\налаштування стосунків.
- Відображення на одній сторінці безлічі об'єктів. - Зараз архітектура побудована таким чином, що на одній сторінці можливе відображення тільки одного виду об'єкта (не рахуючи посилань на інші об'єкти).
- Командний рядок - Командний рядок для скорочення кол-ва дій для виконання операцій.
- Наприклад, на об'єкті «Проект» в командному рядку набирається «Завдання» і відбувається автоматичне створення об'єкта «Завдання» з посиланням на даний проект. Оскільки зараз потрібно перейти на вкладку
- Шифрування. - Додати шифрування БД.
- Аналітика - Можливість базової аналітики по об'єктах, з відображенням кол-ва за статусами, важливістю тощо.
- Додавання об'єкта (дати) - Окремий об'єкт, який можна додавати до будь-якого об'єкта з можливістю додавання стоків
- Активності - Можливість відпрацювання певних дій
- Перевірка на дублювання - При створенні інстанції об'єкта перевірка на дублювання
- Обов'язковість полів - Визначення полів, обов'язкових для заповнення.
Ув'язнення
Намагався написати статтю максимально короткою, щоб швидко можна було зрозуміти основну ідею та опис реалізації, не потонувши у великій кількості зайвої інформації.
Цією системою користуюся, близько 3 місяців, попутно виправляючи помилки, політ рівний.
Дякую за час.
