Польза от Welltory и шаг вперёд в написании движка
Проспал на удивление долго. Днём долго ничего не хотелось делать. Вместо этого пошёл в Instagram. Там DarLik прислала ссылку на аккаунт Tinkoff Journal, где задали провокационный вопрос «чем бы вы занимались, если бы была возможность не работать». Отписал штук шесть комментариев тем, кто считал, что без работы жить нельзя, и нужно не мечтать, а делом заниматься. А ещё в рассылке ЖЖ наткнулся на сообщение, где затрагивалась сходная тема, и тоже отметился. Правда, ответил только один упёртый дельтийский дедок.
Потом запустил Welltory, сделал очередной замер состояния. Результаты были так себе: 60-44-54%. Решил, что заставлять себя в таком состоянии смысла нет, и сел играть в Transport Tycoon. Где-то через час или полтора замерил своё состояние ещё раз, и на этот раз показатели были гораздо лучше: 80-58-46%. В общем, впервые от Welltory проявилась практически видимая польза!
После этого вновь занялся движком нового сообщества, и, надо сказать, весьма продуктивно. Почти доделал регистрацию и авторизацию пользователей. По сути, теперь осталось сделать только создание/редактирование статей, а также поиск, и будет готова основа для тестирования (то, что называют MVP — minimal viable product). Правда, пока что без дизайна от слова вообще.
Вообще, удивляюсь, насколько легко идёт написание кода! Такого даже в 2004 году не было, когда я Intellect Board 2.x писал. Там дело шло хоть и быстро, но с некоторым насилием над собой. А тут всё само собой получается. Видимо, то, что я делаю, правильно и угодно высшим силам!
Впрочем, один затык всё же был. Полтора часа провозился с тем, чтобы понять, почему не работает оператор $ne при выборке из MongoDB для проверки уникальности Email. Оказывается, я писал в условии ['login'=>['$ne',$login]], а нужно — ['login'=>['$ne'=>$login]]. А потом ещё вычитал, что в PHP 5.5 и выше для паролей нужно использовать не привычный SHA-256, а медленные хеши и специальные функции password_hash и password_verify. И какое-то время ушло на переделку.
И пока никак не могу определиться, как быть с управлением областью видимости для каждой заметки. Есть два решения. Первый способ — это хранить только обычные теги и признаки режима показа сообщения: в публичном пространстве (при выборке по тегу), на стене и в ленте событий, показываемой подписчикам. Тогда для выборок придётся делать довольно сложные запросы.
Второе — в список тегов кроме обычного #тег1, #тег2 добавлять скрытые теги вида @автор и #тег1@автор, #тег2@автор. Это создаёт избыточность (все теги дублируются дважды, а также дублируется автор, логин которого хранится в отдельном поле) и некоторое неудобство при редактировании (нужно отфильтровывать скрытые теги при выводе). Зато позволяет очень легко реализовать выборку по спискам подписки/игнора, где могут быть указаны как теги, так и пользователи и сочетания тег@пользователь. И ещё управлять легко областью видимости: если пользователь выберет показывать сообщение только в публичном пространстве, то скрытые теги просто не добавлять, если наоборот, только у себя в ленте, то оставить только скрытые теги.
Потом запустил Welltory, сделал очередной замер состояния. Результаты были так себе: 60-44-54%. Решил, что заставлять себя в таком состоянии смысла нет, и сел играть в Transport Tycoon. Где-то через час или полтора замерил своё состояние ещё раз, и на этот раз показатели были гораздо лучше: 80-58-46%. В общем, впервые от Welltory проявилась практически видимая польза!
После этого вновь занялся движком нового сообщества, и, надо сказать, весьма продуктивно. Почти доделал регистрацию и авторизацию пользователей. По сути, теперь осталось сделать только создание/редактирование статей, а также поиск, и будет готова основа для тестирования (то, что называют MVP — minimal viable product). Правда, пока что без дизайна от слова вообще.
Вообще, удивляюсь, насколько легко идёт написание кода! Такого даже в 2004 году не было, когда я Intellect Board 2.x писал. Там дело шло хоть и быстро, но с некоторым насилием над собой. А тут всё само собой получается. Видимо, то, что я делаю, правильно и угодно высшим силам!
Впрочем, один затык всё же был. Полтора часа провозился с тем, чтобы понять, почему не работает оператор $ne при выборке из MongoDB для проверки уникальности Email. Оказывается, я писал в условии ['login'=>['$ne',$login]], а нужно — ['login'=>['$ne'=>$login]]. А потом ещё вычитал, что в PHP 5.5 и выше для паролей нужно использовать не привычный SHA-256, а медленные хеши и специальные функции password_hash и password_verify. И какое-то время ушло на переделку.
И пока никак не могу определиться, как быть с управлением областью видимости для каждой заметки. Есть два решения. Первый способ — это хранить только обычные теги и признаки режима показа сообщения: в публичном пространстве (при выборке по тегу), на стене и в ленте событий, показываемой подписчикам. Тогда для выборок придётся делать довольно сложные запросы.
Второе — в список тегов кроме обычного #тег1, #тег2 добавлять скрытые теги вида @автор и #тег1@автор, #тег2@автор. Это создаёт избыточность (все теги дублируются дважды, а также дублируется автор, логин которого хранится в отдельном поле) и некоторое неудобство при редактировании (нужно отфильтровывать скрытые теги при выводе). Зато позволяет очень легко реализовать выборку по спискам подписки/игнора, где могут быть указаны как теги, так и пользователи и сочетания тег@пользователь. И ещё управлять легко областью видимости: если пользователь выберет показывать сообщение только в публичном пространстве, то скрытые теги просто не добавлять, если наоборот, только у себя в ленте, то оставить только скрытые теги.