Обновить
Комментарии 18
Добро пожаловать на Хабру, конечно, но лично у меня после всего прочитанного в голове нет ни одного вопроса кроме: «И чё?». Может я устал, конечно, но вот хоть убей никакой ценности не вижу.
Ценность, видимо, в идее.
Cкорее всего ценность вижу только я, как автор, потративший n-ое кол-во времени на реализацию. Основная идея в том, чтобы показать, как можно довольно просто сделать свой личный todo-менеджер, с возможностью расширения.

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

Просто не получилось. Но есть куда еще упрощать.

всё_очень_плохо.jpg


Архитектуры в проекте нет, всё выглядит как набор файлов, в которых всё сильно захардкожено и которые как-то работают.


Бэкенд


  • Нет никакой обработки исключений. Любой невалидный json сломает сервер. Любой json, в котором не окажется нужного ключа, сломает сервер. Любая ошибка от БД сломает сервер.
  • Непосредственно сам сервер очень странный. Почему BaseHTTPRequestHandler? Можно было либо сделать WSGI-приложение (чтобы можно было запускать на весьма продуктивных wsgi-серверах), либо взять питон посвежее (>3.4) и задействовать asyncio (чтобы было асинхронно). Первый вариант для данной задачи предпочтительнее. Плюс, довольно странная концепция посылать на сервер запросы только на 1 endpoint на манер некого QueryLanguage, причём, без всякой валидации оного. Есть же JsonSchema. Да и REST в данном случае подошёл бы лучше.
  • Работа с БД. Есть прекрасный проект sqlalchemy, состоящая из 2-х частей. Core-часть представляет некий обобщённый интерфейс для работы с БД. Позволяет абстрагироваться от конкретной БД и писать запросы на неком DSL, которые потом трансформируются в SQL. Ещё есть ORM-часть, если вдруг понадобится. Так же для неё есть дополнительные инструменты: миграции, сериализация моделей, полнотекстовый поиск, и т.д. А что у вас? Всё завязано только на sqlite, все имена таблиц жёстко прописаны и изменить их не сломав приложение будет очень трудно. Миграций нет, так что изменить схемы будет не просто. Генерация SQL из JSON выглядит очень подозрительно и хрупко. Особенно удручает, что тестов нет. Плюс, как я понял, модели строятся только на фронте, а связанные объекты запрашиваются отдельным запросом (а транзакций нет). Если так, то консистентность данных никак не гарантируется, что очень печально.
  • Очень странно, что бэкенд совсем не знает о данных, с которыми работает. Из-за этого нет ни валидации данных на стороне сервера, ни возможности хоть как-то кастомизировать (де)сериализацию данных.
  • Если заглянуть в код сервера, то можно увидеть, что при каждом запросе создаётся новый экземпляр класса для работы с БД, хотя достаточно было создать его только 1 раз.
  • В самом классе для работы с БД новое соединение с базой создаётся при каждом новом запросе, хотя его тоже достаточно создать 1 раз.
  • Сам код тоже плох: очень много elif, повсюду небезопасное получение ключа у словарей (надо через .get()), кодстайл тоже очень хромает.

Фронтенд


  • Всё в глобальной области видимости.
  • Нет проверки, все ли необходимые js-файлы загрузились и все ли объекты доступны.
  • Нет никакой структуры приложения. Бизнес-логика вперемешку с логикой отображения. Где-то в селекторы передаётся строка из настроек, где-то просто так.
  • JSON генерируется вручную, путём конкатенации строк… Ну есть же штатный JSON.stringify!
  • Зачем столько NaN совсем не по делу? Нужно либо инициализировать null-ами (или пустыми объектами), либо оставлять undefined.
  • Повсюду функции-конструкторы без аргументов. Попытка сделать всё в ООП-стиле? Но при этом, прототипы не используются нигде. Зачем так? Нужен просто объект — создавай через синтаксис со скобками ({ foo: function (a, b) {...} }). this будет работать и так.
  • Непонятные обёртки для ajax, console, etc.
  • Трэш в codestyle
  • Куча html-страниц с кучей copy-paste. Если потребуется поменять шапку, придётся лезть в каждый html-файл. Есть же шаблонизаторы/препроцессоры.

Как же всё это улучшить?
Всё приложение по-сути просто интерфейс к БД со стандарным набором CRUD-методов. Незачем придумывать велосипеды, намного быстрее взять что-то готовое. REST API в данном случае подойдёт очень хорошо.
Лично я сделал бы так:


Вариант №1. Описать схему данных в swagger'е. Сваггер умеет по схеме генерировать много чего полезного. Например, html-формы и даже контроллеры для методов REST. Вполне подойдёт, для быстрого старта тем более. Потом уже можно будет допиливать бэк и фронт.
Вариант №2. Написать всё самому, используя готовые фреймворки.


Вместо непонятного json-query-language использовать REST-подход. На клиент отправлять не просто данные из БД, а сериализованные модели с учётом связей.
На Никаких имён таблиц и столбцов на клиенте! Доставать данные из БД, строить из них модели, учитывая отношения и серилизовать их должен не клиент, а сервер. Фронт должен уметь лишь отображать полученные данные и, используя формы, отправлять данные на сервер.


Бэкенд
Взять Flask в качестве микро web-framework. Для работы с БД использовать SQLAlchemy. Добавить Flask-migration для удобных миграций. Для REST API взять Flask-Restless. Всё это прекрасно умеет работать совместно. Добавить на серверную сторону валидацию данных, грамотную обработку ошибок, и гибкий конфиг.


Фронтенд
Вместо кучи html-файлов и хрупким js-кодом, написать SPA. Взять какой-нибудь фреймворк (angular/angular2/backbone/ember), добавить к нему расширения для работы с REST, нормальный wysiwyg-редактор и Grid для отображения таблиц.
Само приложение структурировать по-человечески: отдельно написать сервисный слой, где будет происходить общение с сервером через ajax, отдельно реализовать view-слой, где полученные от сервисов данные будут отображаться в нужном виде.


Добавить в проект таск-раннер или сборщик (gulp/webpack).
В идеале, стоит использовать ES6 и Babel (или TypeScript), чтобы писать нормальный современный JS-код. Добавить загрузчик модулей (requirejs, system.js, webpack) и явно импортировать в js-файлы нужные зависимости, чтобы быть уверенным, что все зависимости загрузились.


В общем, почитайте про MVC, про REST, про популярные фреймворки для бэка и фронта. Велосипеды городить тоже иногда полезно, но без знания основ будет больше вреда: и код хороший не получится, и нужных знаний не прибавится.

Большое спасибо подробный технический комментарий! Буду изучать.

Можно сперва посмотреть в сторону свагера. Вот тут есть демка его редактора, там сверху есть 2 пункта меню: "сгенерировать сервер" и "сгенерировать клиент". Можно посмотреть, что он нагенерирует и взять что-то за основу. Ещё больше инструментов тут.
Ещё для REST API на питоне есть, например, Eve (кстати, оно тоже умеет со сваггером работать).

Простите, не совсем «в тему» ответ, но я вам хочу аплодировать за то, что вы вот так изучили что-то внезапно-новое и чужое, и подробно расписали-разложили всё по полочкам. Очень впечатлило. Такие комментарии к подобным статьям — оооочень большая редкость.
Очень основательный комментарий, спасибо!
Скажите, как изменилась бы предложенная вами схема с использованием MVC в ASP.NET?
Идея мне нравится.
ведение личного дневника и последующий анализ зафиксированных событий

Анализ событий можно развить в систему рекомендаций. Например, в течение определённого периода времени вы интересовались какой-то темой. Потом забыли про это. Система напоминает вам про это.
Второй коммент вижу в котором фигурирует слово «идея». Кто объяснит мне в чем новизна идеи и чем она может понравится — мгновенно получит от меня плюс в карму. Я пока не увидел ничего интересного. Я бы даже сказал, что даже с точки зрения функционала это еще пока не сопоставимо с какой-нибудь CMS. Просто жонглирование понятиями и вместо «страница» и «категория» автор использовал другие слова, лол
Под главной идеей я имел ввиду — сбор информации по всем действиям конкретного человека (данные трекеров\задачи\дневник\контакты\мысли и т.д. и т.п.) в одном месте, без доступа из вне, для возможности дальнейшего анализа, прогнозирования, сообразно с целями конкретного индивида.

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

По реализации я согласен, что в итоге получилась ухудшенная версия какой-нить CMS(изначально ориентировался на django с вомзожностью создания своих объектов) и bromzh действительно грамотно расписал технические моменты и посоветовал технологии, которые необходимо использовать.
Очень многообещающее начало с потрясающей идеей — личная big data. По сути как развитие идеи не просто еще один дневник, но максимально возможно автоматическая система хранящая любую информацию с которой сталкивается и которую генерирует конкретный индивидуум. И в перспективе автоматический анализ данной информации с выдачей рекомендаций в зависимости от поставленных целей. Сфера применения практически безгранична. Дальнейшее масштабирование для многих пользователей и групп с решением чисто технических/архитектурных вопросов и вопросов конфиденциальности хранимых данных видится вполне решаемым. Главное сохранить фокус на ключевой идее.

Тем больше жаль, что перешло все в практическую реализацию в виде еще_одного_todo_менеджера, коих десятки и сотни. Может быть не тратить время на изучение-разработку того, что уже давно написано, а уделить внимание проработке концепции и основным алгоритмам реализации того, что попало в раздел «мечты»? С удовольствием почитал бы в продолжении о развитии предложенной идеи.
Я бы все-таки называл личная little data, т.к. применительно к одному человеку не может быть столько big-данных :) (но это сугубо как забавный антипод big data, не настаиваю)

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

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

Т.к. данный материал вызвал небольшой, но все-таки интерес, то, возможно, я соберусь и систематизирую, свое видение по данной теме и опубликую уже без технических ограничений :)
Сам занимаюсь подобной идеей (PBD — Private Big Data). Уклон в сторону личного RUP. Т.е. ставишь себе проекты, измеряешь своё состояние, планируешь сроки и уровень нового состояния. Плюс автору статьи — в постановке вопроса. Два плюса комментатору, расписавшему среды для фронтенда и т.п. А если реализуешь гостовский =водопад=, да еще в ФОИВ, то 1) фронтенды/бекэнды не используют 2) другие RAD и ЯВУ.

Примеры:
— по п.1.
— ГОСТы на АСУ и НИОКР + РВшки;
— другие категории: СУБД, клиент/сервер, ИО, МО, ПО (ОПО/ОСПО/СПО);
— под интерфейсами понимают протоколы и менюшки.
— по п.2
— Qt старых версий (3, 4).
Да, в целом это то, что я имел ввиду. А есть программы\статьи по PBD в открытом доступе, которые можно смотреть\потестировать?
На стенах у меня расклеены листочки. Пока только в башке.
Я в результате долгих мучений к TODO.txt пришёл, там всё: идеи, задачи, снабжение, долги, контакты, основные расходы/доходы, покупки, рацион, распорядок и т.п. Доступен в любой момент по хоткею (выезжает, загруженный в текстовый редактор, как квейковская консоль, поверх всего). Стараюсь вести его так, чтоб, при необходимости, можно было распарсить на сущности/проанализировать.

И в таком виде, мне — ленивой жопе, его достаточно, чтоб не потерять нить жизненного повествования и применять хоть какой-то системный подход в своих мыслях и делах.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.