Комментарии 18
И узнать, какими инструментами пользуется сообщество, для решения задач по повышению личной эффективности, также, возможно, получить советы, в каком направлении (технологии\framework\фичи) двигаться, если возникнет желание сделать что-то, после чего возникнут дополнительные вопросы кроме базового.
всё_очень_плохо.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(изначально ориентировался на django с вомзожностью создания своих объектов) и bromzh действительно грамотно расписал технические моменты и посоветовал технологии, которые необходимо использовать.
Тем больше жаль, что перешло все в практическую реализацию в виде еще_одного_todo_менеджера, коих десятки и сотни. Может быть не тратить время на изучение-разработку того, что уже давно написано, а уделить внимание проработке концепции и основным алгоритмам реализации того, что попало в раздел «мечты»? С удовольствием почитал бы в продолжении о развитии предложенной идеи.
На самом деле я сознательно ограничил себя в описании идеи, т.к. продолжение действительно можно описать захватывающее, т.е. в идеале человек ставит свою жизнь под личный контроль, а не отдает себя на откуп мегакорпорациям, позволяя бессознательно манипулировать собой.
Но я посчитал, что голая идея без прототипа мало чего стоит, в итоге попытался сделать прототип, но согласен, что получился еще один todo-менеджер, однако мне нужно было приземлиться, чтобы понимать границы своих фантазий и попытаться что-то сделать руками.
Т.к. данный материал вызвал небольшой, но все-таки интерес, то, возможно, я соберусь и систематизирую, свое видение по данной теме и опубликую уже без технических ограничений :)
Примеры:
— по п.1.
— ГОСТы на АСУ и НИОКР + РВшки;
— другие категории: СУБД, клиент/сервер, ИО, МО, ПО (ОПО/ОСПО/СПО);
— под интерфейсами понимают протоколы и менюшки.
— по п.2
— Qt старых версий (3, 4).
И в таком виде, мне — ленивой жопе, его достаточно, чтоб не потерять нить жизненного повествования и применять хоть какой-то системный подход в своих мыслях и делах.
Разработка личной системы управления