Skip to content

Разбор кейса «смена емейла» со всеми ньюансами, от идеи до реализации, состояния и подводные камни (#general) 22.09.2017

Andrii edited this page Sep 23, 2017 · 1 revision

kirill.mokevnin [9:08 PM] @channel через полчаса слаконар про реальную разработку, разбор кейса «смена емейла» со всеми ньюансами, от идеи до реализации, состояния и подводные камни. Слаконар в стиле вопросов ответов, вы сами придумываете решение а я говорю почему оно не сработает.

mPut [9:09 PM] А если оно сработает? ))

alexander.vyatkin [9:09 PM] Сказали же - не сработает))

kirill.mokevnin [9:09 PM] Хаха, как бы не так

aenglisc [9:09 PM] оптимист штоле

ivana [9:09 PM] через полчаса пинг олл сделай плиз, Кирилл

kirill.mokevnin [9:09 PM] Все сложнее чем кажется на первый взгляд

ressonance [9:09 PM] а о чем он не совсем понятно..

kirill.mokevnin [9:10 PM] Это крутой кейс

ressonance [9:10 PM] язык, фрейворк ?

kirill.mokevnin [9:10 PM] Это не важно, сложность не в инструментария

ressonance [9:11 PM] значит что то общее, так понимаю..

kirill.mokevnin [9:11 PM] Очень конкретное

mPut [9:11 PM] Подскажите, пока слаконар не начался, нормальная ли практика - указывать как параметры по умолчанию инициализирующие переменные функции - итератора? Или лучше передавать в месте вызова?

ressonance [9:11 PM] а по рельсам будет когда нибудь что то?)

kirill.mokevnin [9:12 PM] Про код неинтересно

[9:13] Закодить это проще всего

[9:13] Когда понимаешь

alexander.vyatkin [9:13 PM] mPut, делай, как бизнес требует))

kirill.mokevnin [9:13 PM] А понимать это главное

sayobye [9:14 PM] Пока слаконар не начался, тоже вброшу небольшой вопрос. https://github.com/SayoBye/algorithms/blob/master/algorithms/binSearch/binSearch.js - насколько ужасен этот код алгоритма бинарного поиска? Не бейте пожалуйста :cry: (edited)

[9:17] блин, херня какая-то короче, хотел рекурсией написать, в итоге получилось что-то понятное только мне

amd [9:18 PM] Ждёмс

alexander.vyatkin [9:22 PM] Кек, сообщество ждунов))

andrii.marynets [9:24 PM] Было б хорошо сохранять слаконары в какую то статтю или просто сбор коментариев

kirill.mokevnin [9:26 PM] Пока такой вопрос. Как вы думаете, сколько времени займет у синьора помидора для проекта типа хекслет. В часах или днях

crew2finj [9:26 PM] @andrii.marynets https://github.com/Hexlet/hexlet-slack-archive/wiki вот тут хранится уже GitHub Hexlet/hexlet-slack-archive hexlet-slack-archive - Архивы хороших бесед из Слака Хекслета

(edited)

kirill.mokevnin [9:26 PM] Эта задача

greybutton [9:28 PM] 16 дней была инфа :hehe1:

puer [9:28 PM] месяц

mdnc [9:28 PM] Там последний коммиит год назад был

[9:28] Месяца 3

[9:29] Хотя нет, возможно больше, месяцев 6

dmitrykruglov [9:29 PM] Только сегодня читал про кложу из архива

aenglisc [9:29 PM] откуда в вики коммиты?

andrii.marynets [9:29 PM] 14 дней. Настроить воркеры, отправить на старый мейл линк подтверждение, а остальное что б синхронизировать всё. А то получитса что старий уже не действительный, а новый ище не действительный (edited)

kirill.mokevnin [9:30 PM] Звучит разумно но оно еще сложнее

alexander.vyatkin [9:30 PM] Вечность - всегда придется что-то допиливать

mdnc [9:30 PM] Блин, я задачу не правильно понял

dmitrykruglov [9:30 PM] Хотя теперь жалею об этом, пото му что желтел с жс к на кложу скрипт перейти

mPut [9:32 PM] Вопрос профана - это же стандартная задача, она должна быть уже решена?

alexander.vyatkin [9:34 PM] Если без перфекционизма - с планированием от нуля, где-то полгода-год, наверное?

kirill.mokevnin [9:34 PM] Ты троллишь да?

amd [9:34 PM] Собрал бы список адресов для которых надо провести замену. Далее сформировал бы скрипт на рассылку по данным адресам. Если кому то не удалось доставить то добавил бы для таких нотификацию при заходе в Хекслет

[9:34] Как то так

alexander.vyatkin [9:35 PM] Нет, я если даже троллю - то частично.. Я заблуждаюсь, причем совершенно искренне..

kirill.mokevnin [9:35 PM] Задача в том чтобы дать возможность менять емейл на сайте

alexander.vyatkin [9:35 PM] Ах, я не понял задачу

kirill.mokevnin [9:35 PM] У нас рахим задолбался руками это делать по запросу

amd [9:35 PM] Я не совсем понимаю что нужно нас

kirill.mokevnin [9:35 PM] И мы на днях вылили эту возможность

puer [9:35 PM] вопрос в том за какое время удастся добавить фичу смены емейл адреса юзерам на хекслете?

kirill.mokevnin [9:36 PM] Да

amd [9:36 PM] Кирил распиши подробней что от нас требуется)

kirill.mokevnin [9:36 PM] На хекслете нельзя было менять мыло

[9:36] Щас сожно

[9:36] Можно

alexander.vyatkin [9:36 PM] Если на жс все - сделал бы за два спринта, максимум)) но я не помидор..

kirill.mokevnin [9:36 PM] Сколько времени делается подобная фича на ваш взгляд

puer [9:36 PM] 30 минут

kirill.mokevnin [9:37 PM] Воот, пошли мои любимые звблуждения

amd [9:37 PM] Вот делал недавно на проекте. За 6 часов примерно, может меньше

[9:37] В районе 6 часов вообщем

kirill.mokevnin [9:38 PM] Чувствую что после слаконара куча людей побежит переписывать код

alexander.vyatkin [9:38 PM] Суть вопроса - на работающем проекте запилить фичу?

kirill.mokevnin [9:38 PM] Да

trofivan [9:38 PM] Я думаю в районе 3 дней потребуется.

[9:39] Биллинг привязан к мылу?

kirill.mokevnin [9:39 PM] Какой ты хитрый)

[9:39] Не только биллинг, но это потом

[9:39] Вход через соцсети не забывайте

alexander.vyatkin [9:40 PM] Саму фичу по смене мыла можно запилить за пять минут - просто потом все рухнет))

kirill.mokevnin [9:40 PM] И еще миграция на живую без простоя

alexander.vyatkin [9:40 PM] Жееесть

trofivan [9:41 PM] Партнёрка только к никнейму привязана? Почта не участвует?

kirill.mokevnin [9:42 PM] Нет 3 replies Last reply 18 hours ago View thread

puer [9:42 PM] возможно ли при разработке архитектуры предусмотреть такие моменты заранее, что бы в подобных ситуациях не возникало столько проблем?

alexander.vyatkin [9:43 PM] Зависит от архитектуры проекта, да..

kirill.mokevnin [9:43 PM] не думал что так глубок получится копнуть этой задачей

dmitrykruglov [9:43 PM] Так мы ещё с проблемами то не определились

kirill.mokevnin [9:43 PM] а мы ведь даже не начали еще

[9:44] вопросы отличные, зрите в корень

[9:44] кто знает кто такой фредерик брукс?

[9:44] начинаем кстати

[9:44] дети уснули

[9:44] забавно что одновременно

alexander.vyatkin [9:44 PM]

[9:44] Не знаю

kirill.mokevnin [9:44 PM] и так, эта задача просто прекрасна по своему составу

[9:44] там есть все о чем я говорю годами тут

[9:45] я сначала хотел большую статью написать, но подумал что сначала лучше в режиме реального времени, а потом на основе разговора я напишу ее

greybutton [9:46 PM] долгий разговор намечается

kirill.mokevnin [9:46 PM] не факт что мы дойдем до конца

trofivan [9:46 PM] Видимо развовор пойдёт в сторону неизменяемости.

kirill.mokevnin [9:46 PM] но будет интересно, сегдоня будет максиально практично все

alexander.vyatkin [9:46 PM] Не все дойдут, точно

kirill.mokevnin [9:46 PM] откровений будет предостаточно

[9:46] было два прекрасных вопроса выше

[9:46]

  1. типичная задача, почему ее надо программирвать

[9:47] 2. возможно ли при разработке архитектуры предусмотреть такие моменты заранее, что бы в подобных ситуациях не возникало столько проблем?

[9:47] что вы об этом думаете?

[9:47] а пока вы думаете, прочитайте плс все https://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D1%80%D0%B5%D0%B1%D1%80%D1%8F%D0%BD%D0%BE%D0%B9_%D0%BF%D1%83%D0%BB%D0%B8_%D0%BD%D0%B5%D1%82 Wikipedia Серебряной пули нет «Серебряной пули нет» (англ. «No Silver Bullet») — широко обсуждавшаяся статья Фредерика Брукса об инженерии программного обеспечения, написанная им в 1986 году. Брукс утверждает, что «ни в одной технологии или в управленческой технике не существует универсального метода, увеличивающего на порядок производительность, надёжность и простоту». Он также утверждает, что «мы не можем ожидать увеличения прибыли в два раза каждые два года» при разработке программного обеспечения, как это происходит с разработкой Show more… (167kB)

[9:47] без понимания этой штуки мы дальше не пойдем

alexander.vyatkin [9:47 PM] На второй вопрос - нельзя, мое мнение

redbrother [9:47 PM] угу, никак

alexander.vyatkin [9:47 PM] Вот я лошара.. Про Брукса забыл..

kirill.mokevnin [9:48 PM] я беру 5 минутный таймаут пока вы прочитаете

[9:48] и выскажете свои мнения

dmitrykruglov [9:48 PM] Тяжело с самого начала проектирования все кейсы учесть, а если ещё и опыта в этом нет...

kirill.mokevnin [9:49 PM] пошел болеть за тириона

amd [9:50 PM]

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

Думаю да. Если грамотно расписать все юзкейсы и сценарии для каждой роли пользователя

kirill.mokevnin [9:50 PM] под стартом имеется ввиду старт проекта

alexander.vyatkin [9:50 PM] Кек, если бы можно было учесть все кейсы сразу - ахулиард людей осталось бы без работы.. Так не работает, почему то.. Может из-за того, что энтропия растет? Я не знаю..

kirill.mokevnin [9:50 PM] вообще в принципе

andrii.marynets [9:51 PM] 1 если система не пишытса с нуля, то надо будет потратить врямя на докручивание готового решения, если новая то в будущем все равно надо будет что до докручивать 2 вот нельзя так просто взять и сделать всё идеально

alexander.vyatkin [9:51 PM] Это так, к слову.. Читайте Брукса, там интересно!!

kirill.mokevnin [9:53 PM] прочитали?

mPut [9:53 PM] Угу

amd [9:53 PM] я так быстро не умею читать

alexander.vyatkin [9:54 PM] Ну не надо "человеко-месяц" читать весь))

gugfug [9:54 PM] А можно поподробнее, Брукс???

redbrother [9:54 PM] Это же не научная статья, быстро читается (edited)

amd [9:54 PM] ну вот

[9:54] второй пункт как раз и относится к имманентным сложностям (edited)

puer [9:55 PM] и от них невозможно уйти

kirill.mokevnin [9:55 PM] невозможно это раз, второе не нужно

[9:55] и не нужно их проектировать заранее

amd [9:56 PM] разрабатывая админку на сайте каков процент того, что тебе не понадобится смена почтового адреса у пользователя если он есть в учетных данных? (edited)

kirill.mokevnin [9:56 PM] я не буду сейчас расписывать этот пункт подробно, потому что это огромная тема про бизнес и вот это все

trofivan [9:56 PM] Это как с преждевременной оптимизацией похоже.

kirill.mokevnin [9:56 PM] ключевая книга lean startup,прочитав ее вы переосмыслите многое

[9:57] да это она и есть

[9:57] спольки называет людей которые строят воздушные замки архитектурными астронавтами

[9:57] таких много кстати

[9:58] я называю таких людей игроки, им интересен процесс, новые ощущения, а про бизнес они скорее всего даже не знают

puer [9:58 PM] как же прочувствовать эту грань

kirill.mokevnin [9:58 PM] легко

andrii.marynets [9:58 PM] Мы от темы кажись уходим

amd [9:58 PM]

как же прочувствовать эту грань грань между чем и чем?

alexander.vyatkin [9:58 PM] Вот сегодня столкнулся с этой штукой - даже кайф какой-то почувствовал.. Когда возникла ВНЕЗАПНО потребность в новой фиче, которая не закладывалась в продукт изначально

kirill.mokevnin [9:58 PM] знаешь как? берешь в банке кредит 1 миллион рублей, нанимаешь разработчика и у тебя есть 6 месяцев до момента когд анадо возвращать

[9:59] потом тебе не то что будет нечего кушать, еще и кредит надо будет возвращат

[9:59] ьь

[9:59] тогда ты поймешь грань

[9:59] не думайте что я это придумал, у хекслета была ситуация когда мы дошли до дна

puer [9:59 PM] кажись дошло)

kirill.mokevnin [9:59 PM] у нас на счыету осталось 200$

[9:59] и дальше либо крах и долги, либо выкарабкаемся (edited)

alexander.vyatkin [10:00 PM] Эджайл грамотный поможет

amd [10:00 PM] ну тут другая тема немного, ребята правы

kirill.mokevnin [10:00 PM] ага, ну в общем читайте lean startup

[10:00] не пожалеете

[10:00] и так к нашей задаче

[10:00] отталкиваемся конкретно от хекслета

[10:00] вот значит фича как бы нужна, но рахим меняет емейлы раз в месяц руками

[10:01] и вроде норм, можно сосредоточиться на более важных вещах

[10:01] проходит год

[10:01] запросов становится больше, становится понятно что уже надо делать, мы тратим время рахима (edited)

[10:01] и вот представьте что вы девелопер

[10:01] Рахим такой говорит, запили плс смену емейла

[10:02] и тикет в трелло поставил

[10:02] больше там нет ничего

[10:02] ни тз, ни правил ничего

amd [10:02 PM] у меня с ходу вопрос. Почему эту фичу не заложили на начале проекта. Вроде такой функционал проходит как AS IS (просто интересно)

alexander.vyatkin [10:02 PM] Здесь не учат программировать - здесь учат бизнес-план мышлению.. Понемногу))

kirill.mokevnin [10:02 PM] это стартап, тут каждый в теме на 100% и каждый на 100% самодостаточен

[10:02] @amd я выше про деньги написал, знаешь сколько таких фич не закладывается с самого начала

[10:03] тебе надо понять разницу между бизнесом и стартапом

[10:04] @amd хекслет делал пивот более 3 раз, при которых было выкинуто до 80% кода

[10:04] в течении нескольких лет (edited)

[10:04] все давайте не прдолжать эту тему, читайте книгу)

amd [10:04 PM] лан, давайте дальше :slightly_smiling_face:

kirill.mokevnin [10:04 PM] ну вот рахим попросил вас

[10:04] ваши действия?

amd [10:05 PM] Иду к Рахиму и гговорю

[10:05] Рахим где постановка задачи???

kirill.mokevnin [10:05 PM] просьба быть особенно активными кто без опыта

rende11 [10:05 PM] А как это делалось руками?

kirill.mokevnin [10:05 PM] в админке

[10:05] мы просили написать письмо с нового емейла

aenglisc [10:05 PM] надо понять что вообще требуется для смены и что на это завязано

dmitrykruglov [10:05 PM] Рахим это делал руками постоянно, значит нужно спросить как он это делал и написать скрипт который делает то же самое)

trofivan [10:06 PM] Исследование и оценка рисков первым делом (edited)

amd [10:06 PM] авторахим))))

kirill.mokevnin [10:06 PM] а почему никто не говорит, я по быстрому сделал поле для изменения емйла в настройках пользователя и задеплоил? (edited)

amd [10:06 PM] вообщем. Первым делом я бы точно пошел выяснять детали и требовать описание задачи не в виде пары слов

kirill.mokevnin [10:07 PM] это все описание (edited)

amd [10:07 PM] это не описание)

trofivan [10:07 PM] Потому что так всё поломается. Критичная фича

redbrother [10:07 PM] Это же безобидное поле))

puer [10:07 PM] без опыта - добавляем кнопочку на соответсвующей странице, с помощью которой изменяем запись в БД для юзера. готово)

amd [10:07 PM] это похоже на Сделай всё хорошо

kirill.mokevnin [10:07 PM] именно так и рабтают стартапы

[10:07] никто не знает чтои как нужно

mPut [10:07 PM] Без опыта нужно сформировать и отправить запрос на старый емаил о смене, и создать ожидание клика по нужному адресу. После того как прийдет клик - отправить запрос на новый адрес, и снова ждать клика. После второго клика произвести смену.

kirill.mokevnin [10:07 PM] но у команды полное доверие

[10:08] и в такие проекты берут только автономных людей

greybutton [10:08 PM] я пошел бы смотреть как работает регистрация и с чем сейчас связан емайл

kirill.mokevnin [10:08 PM] сюда не берут таск ориентированных людей

[10:08] которые без аналитика не делают ничего

amd [10:08 PM] если автономный человек без вопросов все задачи берёт, я не уверен что он хороший специалист

sayobye [10:08 PM] Извините, я немного не понял. Рахим менял почты пользователей, которые просили сменить им почту в профиле? 1 reply 17 hours ago View thread

kirill.mokevnin [10:08 PM] а что тебя удивляет?

[10:09] когда люди пишут в саппорт с ними общаемся все мы

[10:09] у нас нет отдельного саппорта

[10:09] это денег стоит)

sayobye [10:09 PM] Казалось что таких заявок будет не много, ибо если нет возможности, то люди такие - "Ну ладно" и забивают

kirill.mokevnin [10:09 PM] так и было, но потом заявок стало больше

amd [10:09 PM] @kirill.mokevnin у меня нет опыта именно таких автономных стартапов, но всё же мне интересно. Какой уровень знаний о проекте каждого конкретного специалиста?

kirill.mokevnin [10:10 PM] @amd перестань пожалуйста тянуть одеяло в свою сторону

gugfug [10:10 PM] Так и почему нельзя просто добавить формачку в настройках пользователя?

kirill.mokevnin [10:10 PM] я уже сказал где можно почерпнуть знания довольно понятным языком

amd [10:10 PM] @kirill.mokevnin я пытаюсь понять просто

sayobye [10:10 PM] Вопрос. Почта как-то(*фикс) влияла на подписку и участвовала в её оформлении? (edited)

amd [10:10 PM] :slightly_smiling_face:

kirill.mokevnin [10:10 PM] в книге есть ответы это раз

[10:10] второе ты тут не один

amd [10:11 PM] да вроде никто больше и не спрашивает то особо)))

dmitrykruglov [10:11 PM] Блин, мне кажется пока в жизни с этой задачей не столкнёшься и не начнёшь Ее решать, не познаешь все проблемы

kirill.mokevnin [10:11 PM]

Так и почему нельзя просто добавить формачку в настройках пользователя?

[10:11] отличный вопрос

[10:11] и так поехали в задачу

[10:11] почему так делать нельзя?

trofivan [10:12 PM]

почему так делать нельзя? Изменение состояния, на котором завязаны другие процессы

sayobye [10:12 PM] Может собьются какие-то внутренние привязки, например привязка карты

amd [10:12 PM] незнаешь бизнес процессов всех, не знаешь что на чем завязано

kirill.mokevnin [10:12 PM] ну это очень абстрактный ответ

[10:12] эээ, ребят вы чего

[10:12] давать менять емейл по желанию это СЕКЬЮРИТИ ДЫРИЩА

[10:12] неважно какие бизнес процессы

[10:12] вы знаете что такое отправка почты?

alexander.vyatkin [10:13 PM] Я уехал на ДР, на меня не надейтесь))

kirill.mokevnin [10:13 PM] что такое спам и боунс рейты?

sayobye [10:13 PM] :face_with_rolling_eyes:

greybutton [10:13 PM] что такое боунс рейт?

mPut [10:13 PM] Нет, но формочка то не будет на прямую менят емэил в базе? Она будет запускать некий процесс. (edited)

kirill.mokevnin [10:13 PM] когда мы шлем письма, то система через которую мы это делаем, чекает нас

dmitrykruglov [10:13 PM] Бонус рейты?

kirill.mokevnin [10:13 PM] и если начинаются отлупы

[10:13] bounce rate

[10:13] это показатель отказов

[10:13] "почты не существует"

[10:13] "вас отклонили потому что вы лох"

[10:14] "почтовый ящик переполнен"

[10:14] любой сервис который шлет мыла не имеет права превышать определенный процент таких проблем (edited)

amd [10:14 PM] таймаут на смену почты не спасёт?

kirill.mokevnin [10:14 PM] bounce делится еще на soft и hard (edited)

puer [10:14 PM] значит нужно проверить валидность нового адреса

kirill.mokevnin [10:14 PM] смысл в том что если не подтверждать почту, а дать всем творить что угодно, то вероятность наличия кривых емейлов

[10:15] крайне высока, и очень легко перепрыгнуть планку

[10:15] в 5% примерно

[10:15] результатом будет бан, систма не сможет слать письма

[10:15] это страшная вещь (edited)

[10:15] а процент попаданий в спам вообще 0.7%

[10:15] если выше то тоже бан

[10:15] один раз нас забанили, по абузе

sayobye [10:15 PM] Т.е если превышать эти ложные запросы на сервис по отправке почты - то он блокирует вас?

[10:15] фига се

kirill.mokevnin [10:16 PM] какой то пльзователь накатал на нас письмо что мы типа его спамим (а вы знаете что мы маркетинговых писем шлем два в год)

puer [10:16 PM]

  • сделать лимит на количество попыток смены емейла

kirill.mokevnin [10:16 PM] каждый такой свервис это нехреновая интеграция

amd [10:16 PM] во во

gugfug [10:16 PM] Ну ок, пользователь отправляет запрос о смене мыла, отправляем письмо с подтверждением , если все ок вносим изменения на сервере иначе кидани ошибку

dmitrykruglov [10:16 PM] Конкуренты

kirill.mokevnin [10:16 PM] ну и еще, если я у вас уведу акк, то легко переведу его на чужую почту

[10:16] любую

gugfug [10:17 PM] Это да

kirill.mokevnin [10:17 PM] дальше всякое можно творить

eem [10:17 PM] а в чём сейчас проблема? я только присоеденился. Как правильно поменять почту подписчику без боли?

denis.stebunov [10:17 PM] пользователи, которые сами себе злобные буратины и поставили кривой емаил - это переоценненая угроза. У нас в системе 2 млн пользователей, и они просто так могут менять себе емаилы. Шлем 15 млн писем в месяц. Про софт- и хард- боунсы более чем наслышаны, попадали в баны N раз. И тем не менее, никаких массовых установок себе кривой почты не наблюдаем 3 replies Last reply 17 hours ago View thread

gugfug [10:17 PM] Может спасёт привязка к телефону

sayobye [10:17 PM] А если на мобилу регаться, то тоже такие проблемы?

amd [10:18 PM] @denis.stebunov поддерживаю. Точно такая же ситуация. Сотни тысяч левых емейлов

kirill.mokevnin [10:18 PM] вот, Денис будет полезные дополнения кидать

[10:18] у всех кто много шлет, много историй про письма (edited)

[10:18] Денис, но у вас вроде не публичная система для всех да?

dmitrykruglov [10:18 PM] Точно, мобила это ключ к спасению

kirill.mokevnin [10:18 PM] своя почта это ад если кто не знает

[10:18] нельзя это делать

denis.stebunov [10:18 PM] у нас очень публичная система для всех, и более того, там 50 сайтов различной направленности

kirill.mokevnin [10:18 PM] только всякие sparkpost

sayobye [10:18 PM] ну по сути у мобил должны быть такие же ограничения, возможно даже больше

amd [10:18 PM] почему ад?

kirill.mokevnin [10:19 PM] потому что у тебя только один ip

[10:19] потому что там миллиард настроек, всякие dkim, sprf и еще тыща штук

[10:19] потому что там всякие ретраи, потери данных и так далее

[10:19] это просто несерьезно

[10:19] а aws ses стоит копейки

[10:20] поехали дальше

[10:20]

Ну ок, пользователь отправляет запрос о смене мыла, отправляем письмо с подтверждением , если все ок вносим изменения на сервере иначе кидани ошибку

[10:20] это вроде как следующий шаг

[10:20] тут тоже секьюрити проблема

[10:21] любой кто подойдет к вашему компу может поменять мыло на свое

[10:21] или у кого будет доступ в ваш акк

gugfug [10:21 PM] И к телефону?

kirill.mokevnin [10:21 PM] кто нибудь помнит как всякие сайты типа фейсбука или гитхаба дают менять самые ключевые параметры? (edited)

sayobye [10:21 PM] ssh

trofivan [10:21 PM] 2FA

kirill.mokevnin [10:21 PM] это вход

sayobye [10:21 PM] а

kirill.mokevnin [10:21 PM] а когда вы заходите в раздел где все критично

krolik [10:21 PM] ну при смене мыла почти всегда везде нужно пароль ввести. Как и подтверждение нажать потом, это же какие-т очевидные вещи

kirill.mokevnin [10:21 PM] что гитхаб делает?

rende11 [10:21 PM] повтор пароля

kirill.mokevnin [10:22 PM] во!

[10:22] надо спрашивать пароль

[10:22] некоторые шлют два письма

[10:22] одно на старый акк, другие на новый (edited)

[10:22] и нужно два подтверждения

sayobye [10:22 PM] Ну допустим злоумышленник скилловый и как-то вытащил пароль из наших куков (возможно же?)

kirill.mokevnin [10:22 PM] в общем случае тебя ничего не спасет да

trofivan [10:22 PM] На старый слать фигово.

kirill.mokevnin [10:22 PM] но это уже более менее схема

[10:23] теперь мы подобрались к самому интересному

[10:23] а как сделать смену на уровне базы

[10:23] вот есть у нас таблица полььзоветелей с полем email

alexander.vyatkin [10:23 PM] Привязать аккаунт к гитхабу, пусть они разбираются со сменой имэйла))

sayobye [10:24 PM] Нужно наверное старую почту сохранять на случай если взломали и нужно вернуть контроль на старую почту.

dmitrykruglov [10:24 PM] Не удалять старую это точно

kirill.mokevnin [10:24 PM] можно сразу поменять?

[10:24] ага, видно что мутации ломают все

trofivan [10:24 PM] isDisabled делать и для новоый isEnabled

kirill.mokevnin [10:24 PM] а как сделать?

gugfug [10:24 PM] Очевидно нет?

redbrother [10:24 PM] 2ой акк

kirill.mokevnin [10:24 PM] 0_o

dmitrykruglov [10:24 PM] Пометить как удаленная

kirill.mokevnin [10:24 PM] второй акк это сильно (edited)

greybutton [10:24 PM] связь какую то старой и новой (edited)

kirill.mokevnin [10:24 PM] isDisabled делать и для новоый isEnabled

[10:24] не понял эту схему

[10:24] где пометить?

dmitrykruglov [10:25 PM] В базе

kirill.mokevnin [10:25 PM] вы прямо опишите кейс как оно произойдет

mPut [10:25 PM] Просто изменить после второго подтверждения (с нового адреса), зачем нам старая теперь?

kirill.mokevnin [10:25 PM] какая таблица, какие поля, как меняется (edited)

alek.grischenko [10:25 PM] не подтвержденную почту держать неподтвержденной пока не получим подтверждения с нового аккаунта(ну и со старых)

amd [10:25 PM] юзер может еще и с двух разных мест одновременно может пробовать поменять

kirill.mokevnin [10:25 PM] где держать неподтвержденую почту?

dmitrykruglov [10:25 PM] Блин хз

alek.grischenko [10:25 PM] в отдельном столбце бд

kirill.mokevnin [10:26 PM] ух

alexander.vyatkin [10:26 PM] В отдельной таблице

dmitrykruglov [10:26 PM] Надо подумать

kirill.mokevnin [10:26 PM] кто еще считает что отдельный столбец это норм идея?

amd [10:26 PM] храним на клиенте в локал сторадже

dmitrykruglov [10:26 PM] Вне норм

greybutton [10:26 PM] таблица с юзера две колонки настоящая почта, новая почта

dmitrykruglov [10:26 PM] Не

kirill.mokevnin [10:27 PM] многое вам сейчас откроется конечно

[10:27] кто скажет почему это идея хрень?)

sayobye [10:27 PM] обход бд будет какой-то стремный

kirill.mokevnin [10:27 PM] @alexander.vyatkin ты прав, но сначала про плохие кейсы

aenglisc [10:27 PM] так можно сдуру наплодить столбцов

kirill.mokevnin [10:27 PM] ну а реальная проблема?

trofivan [10:27 PM] Связать профиль пользователя с email-ами. Один (id профиля) ко многим (почтовым ящикам). У почтовых ящиков есть атрибут isEnabled = true | false

sayobye [10:28 PM] Я не знаю как бд работают, но нельзя ли там сделать так чтобы один столбец был чем-то вроде объекта?

kirill.mokevnin [10:28 PM] @trofivan погоди ты)

[10:28] ну вот сделали мы отдельный столбц

[10:28] newEmail

[10:28] так да?

greybutton [10:28 PM] да

kirill.mokevnin [10:28 PM] теперь смотрите кейс

[10:28] я запрашиваю смену емейла

mdnc [10:28 PM] Может несколько раз кинуть заявки на разные почти и принимать их в разной последовательности

kirill.mokevnin [10:28 PM] потом такой, блин не тот, и запрашиваю еще раз

[10:28] и что происходит?

amd [10:29 PM] много записей

dmitrykruglov [10:29 PM] На каждый новый емаил новый столбец нужен будет, это хрень

kirill.mokevnin [10:29 PM] не мнго

[10:29] а newEmail будет всгда содержать только последнее

amd [10:29 PM] много записей в варианте с отдельной таблицей я это имел ввиду)

kirill.mokevnin [10:29 PM] а ну это щас дойдем

[10:29] понятно почему нельзя столбец?

[10:30] у вас теряется инфа (edited)

gugfug [10:30 PM] Нет

greybutton [10:30 PM] не очень

amakartsev [10:30 PM] добавлять каждый раз новую запись в таблицу. Правда дублирование будет..

gugfug [10:30 PM] Ммм?

kirill.mokevnin [10:30 PM] каждый новый запрос емейла записывает новый newEmail

[10:30] сейчас я описываю кейс когда человек не подтверждает почту

sayobye [10:30 PM] Ну не давать записывать больше одного нового

kirill.mokevnin [10:30 PM] но делает несколько запросов подряд

dmitrykruglov [10:30 PM] Я походу поня нужно нового пользователя создать с новым мылом

mPut [10:30 PM] Менять предыдущий на новый

alexander.vyatkin [10:30 PM] Перезапись

amd [10:30 PM] а зачем нам хранить предыдущие варианты неподтвержденной почты, а не только последний не подтверждённый?

greybutton [10:30 PM] а почему не перезаписывать не подтвержденную почту?

kirill.mokevnin [10:30 PM] Ну не давать записывать больше одного нового а если челвек ошибся?)

[10:31] потому что ссылка должна связана быть именно с той почтой которую он вбил

[10:31] а не с тупо последней почтой

[10:31] это 1) как обычно секьюрити бага

[10:31] потому что можно вбить новый емейл

[10:31] чуваак кликнет по ссылке и подтвердит не ту почту

[10:31] он может ошибиться

[10:31] это не соответствует принципу наименьшего удивления

alexander.vyatkin [10:31 PM] Бизнес решает))

aenglisc [10:31 PM] особо смысла делать какие-то действия в базе до подтверждения нет, как я вижу (edited)

mPut [10:32 PM] Хранить почту и код подтверждения который будет передавться при клике

sayobye [10:32 PM] Ну типо одна ячейка для основной почты и ещё одна ячейка это тот на который он меняется. Если делается второй запрос (когда неправильно ввел) то эта вторая ячейка заменяется просто.

kirill.mokevnin [10:32 PM] и выше я описал почему это не правильно

[10:32] но есть еще кое что очень важное, о чем мало думают, это аналитика

[10:32] вы никогда не узнаете при таком раскладе как пользователи пользуются вашей фичей

[10:33] и если возникнут проблемы, вы никгда не сможете откатиться и восстановиться

trofivan [10:33 PM] Надо всю почту писать в отдельную таблицу. И связывать её с профилем. Добиваться максимальной имутабельности всего и вся?

kirill.mokevnin [10:33 PM] да, я во всех вебинарах кричу просто про иммутабельную базу данных

[10:33] нельзя в базе делать изменения для множственных связей

[10:33] она очевидно one to many

amd [10:33 PM] разве это не повлечет к распуханию базы данных в таком случае?

kirill.mokevnin [10:33 PM] но вы ее упорно пытаетесь засунуть в два стлбца

amakartsev [10:33 PM] т. е для кадого пользователя должна быть таблица с его емайлами?

kirill.mokevnin [10:34 PM] @amd база будет больше, но кого это волнует?

[10:35] у большинства проектов базы с жалкими размерами в сотни мегабайт или гигабайты

sayobye [10:35 PM] вдруг на целых 3мс будет медленнее работать

alexander.vyatkin [10:35 PM] Преждевременная оптимизация.. База больше? Зато работает всё!

kirill.mokevnin [10:35 PM] это даже не проблема

[10:36] вообще тут отдельная история должна быть про аналитику и логгирование

[10:36] вы даже не представляете себе сколько генерируется данных в проектах где много анализируют

dmitrykruglov [10:36 PM] Таблица many to many между юзерами и маилами с полем delited

kirill.mokevnin [10:36 PM] теперь перед тем как пойти дальше

trofivan [10:36 PM] Встанет проблема большой базы - можно будет продумывать варианты архивирования и дальнейшего удаления сильно старых данных. Но мне кажется такая проблема в 99% случаев в принципе не возникнет. Мы же не фильмы в базу пишем

kirill.mokevnin [10:36 PM] я хочу чтобы одна вещь засела у вас в голове

[10:37] да не будет такой проблемы, забудьте про это

[10:37] на хабре есть статья "вы не гугл"

[10:37] почитайте

[10:38] так вот, вы видите что все становится сложнее, появляются разные кейсы (а мы их далеко не все разобрали)

[10:38] почему все так сложно?

[10:38] если обобщить

[10:38] откуда берется сложность

[10:38] вы уже знаете что это необходимая сложность а не случайная

[10:38] но откуда она берется?

sayobye [10:38 PM] От пользователей?

kirill.mokevnin [10:38 PM] отличный ответ

[10:38] нет пользователей нет проблем

dmitrykruglov [10:38 PM] Изменение состояния

kirill.mokevnin [10:39 PM] ноу)

redbrother [10:39 PM] Чертов человеческий фактор)

alexander.vyatkin [10:39 PM] Мир это сложная штука, к которая нужно проще относиться))

trofivan [10:39 PM] Универсальность системы.

kirill.mokevnin [10:39 PM] мир сложная штука да

[10:39] а сложная она потому что много состояний

[10:39] именно количество состояний рождает эту комбинаторику

[10:39] и взрыв

gugfug [10:39 PM] Я так понял проблемы с безопасностью

kirill.mokevnin [10:39 PM] любое новое состояние как правило влияет почти на все

alexander.vyatkin [10:40 PM] Перманентный эффект бабочки

amd [10:40 PM] @kirill.mokevnin можно вопрос немного отстранённый но все же в общую тему?

kirill.mokevnin [10:40 PM] давай потом

[10:40] время много, хочется довести

amd [10:40 PM] ок

trofivan [10:40 PM] И тут мы вспоминаем конечные автоматы, которые помогают этот хаос состояний привести в порядок.

kirill.mokevnin [10:40 PM] они их не уменьшают

[10:40] мы и так сейчас ими уже оперируем

[10:40] и так, у нас новая таблица

[10:41] users и emails

[10:41] но!

[10:41] изначально емейл был в юзере

[10:41] как в новой схеме все будет работать?

[10:41] откуда система будет брать емейл

amd [10:41 PM] мигрировать данные в новую таблицу

trofivan [10:41 PM] Из новой таблицы. Нужно написать миграцию.

count [10:41 PM] миграция - изменение данных

greybutton [10:42 PM] откуда скажем оттуда и будет брать

trofivan [10:42 PM] Смигрировать в новую табличку, а на старые просто забить.

kirill.mokevnin [10:42 PM] откуда скажем оттуда и будет брать например валидация уникальности емейла в orm как правило зашита на ту таблицу по которой работает (в activerecord)

[10:42] поэтому если емейл будет вдругой таблице

[10:42] то привет куча проблем

[10:43] плюс постоянные join

[10:43] например если в админке есть поиск пользователей по мылу

[10:43] вам вообще много поправить придется

[10:43] даже если вы нормально абстракцию сделаете и доступ останется таким же

[10:43] user.email

[10:43] запросы в базу никто не отменял

alexander.vyatkin [10:44 PM] Полгода, я ж говорил)) минимум..

kirill.mokevnin [10:44 PM] :smile:

count [10:44 PM] ну тогда только дублированием. текущий мейл из таблицы пользователя. остальное - мыл

kirill.mokevnin [10:44 PM] о, это норм решение или нет?

amd [10:44 PM] лишние данные храним получается

trofivan [10:44 PM] Ещё одно состояние, не очень

alexander.vyatkin [10:45 PM] Бизнес!!

amd [10:45 PM] просто orm подкрутить чтоб таскал через join из новой таблицы

redbrother [10:45 PM] Вынужденное решение

kirill.mokevnin [10:45 PM] эх

[10:45] в общем рассказываю

trofivan [10:45 PM] Если эта оптимизация даст реальный результат для бизнеса, то можно использовать

kirill.mokevnin [10:45 PM] я щас расскажу про системные вещи

[10:45] вижу что понимания нет, но оно и понятно

[10:46] и так, есть такая штука как интерфейс и абстракция

[10:46] кто учится на хекслете знает не по наслышке

[10:46] пошли нервные смешки в зале да?)

al3xanderg [10:46 PM] Почему не хранить актуальный мейл в юзере, а историю его изменений в отдельной таблицы ?

amd [10:46 PM] мой мозг сейчас лопнет :smile: (edited)

kirill.mokevnin [10:46 PM] вот эта вся схема с емейлами, она как то касается остальной части сайта?

[10:47] всей остальной функциональности надо знать теперь про это усложнение?

[10:47] надо все остальное усложнять ради того, что никто не использует?

[10:47] если вы завяжетесь на email в новой таблице, вам придется пол проекта переписать

[10:47] грубо конечно, но много (edited)

[10:47] плюс куча кастома в стиле: "просто orm подкрутить чтоб таскал через join из новой таблицы"

[10:47] и вам постоянно надо будет это учитывать

[10:47] всегда

[10:48] любая задача теперь будет чуточку сложнее

[10:48] а теперь представьте что все именно так и делается

[10:48] суммарный эффект вам не понравится, но скорее всего рефлексии не получится

[10:48] за деревьями леса уже не увидеть будет

[10:48] обычно на этом этапе все все принимают как должное

amd [10:48 PM] разве если система строятся по уму не должна она стремится к low in coupling and high in cohesion ` (edited)

kirill.mokevnin [10:48 PM] типа "ну это у нас такая сложная система"

[10:49] для всей остальной системы есть юзер и у него емейл

[10:49] это разные bounded context с точки зрения ddd

[10:49] это первый аспект, теперь второй

[10:50] вероятно вы знаете что нормализция это хорошо и надо все нормализовать

[10:50] третья нормальная форма наше все

sayobye [10:50 PM] Для всей остальной системы же нужны абсолютны такие же данные, т.е тоже самое что и было раньше, дабы не переписывать всё, а как оно там под колпаком работает в одном месте уже фигня.

kirill.mokevnin [10:50 PM] да именно

al3xanderg [10:50 PM]

  1. Кнопка смена мыла
  2. Запрос пароля
  3. Отправка ссылки на старую почту
  4. Вход по ссылке - ввод пароля
  5. Задание нового мыла
  6. Ссылка на новое мыло + ввод пароля
  7. Ready.

Таблица юзерс - поля email Таблица users_email - id; id_user; email; dateChange

kirill.mokevnin [10:50 PM] не совсем)

amd [10:50 PM] я один с NoSQL работаю чтоли?)))))))

kirill.mokevnin [10:50 PM] все еще сложнее

[10:50] и вот тут будет откровение

[10:51] нужно стремиться денормализовывтаь данные

[10:51] делать их доступными

[10:51] какая проблема нас поджидает на этом пути?

[10:51] если поменялось в одном местве то надо менять и вдругом да?

[10:51] то есть та самая синхронизация изменяющихся данных

[10:52] но если ваша база растет имутабельно, то количество подобных синхронизаций сведено к минимуму

[10:52] а системы не знают про всю сложность

[10:52] у них данные вот прямо тут лежат

guliy [10:52 PM] Есть концепция целая - event sourcing, но это все не просто и надо с самого начала закладываться под это...

kirill.mokevnin [10:52 PM] эвент сорсинг это еще дальше, и это уже перебор для большинства

[10:53] достаточно просто делать имутабельно как с примером выше про таблицу писвем

[10:53] ничего не закладывается и получаются все преимущества

[10:53] и в отличие от эвентсорсинга не ломается орм и ничего не ломается

[10:53] все инструменты как помогали так и помогают

[10:54] то есть да, хранить емейл в таблице user по прежнему, это хорошая идея

al3xanderg [10:54 PM] актуальный мейл хранить в таблице юзер

guliy [10:54 PM] Орм -зло изначально, но это мое ИМХО)

al3xanderg [10:54 PM] а все смены в архивной таблице

kirill.mokevnin [10:54 PM] как я уже говорил, возьмите кредит в банке и сделайте проект успешный, тогда станет понятно зло они или нет)

al3xanderg [10:54 PM] Т.е. после отправки письма на новую почту и авторизации... новый мейл идет в юзер а старый в архив

kirill.mokevnin [10:55 PM] а вот это еще одна ошибка

[10:55] эта таблица не архивная

[10:55] это очень важно

[10:55] вы знаете что такое источник правды?

[10:55] я часто про семантику говорю, и вот тут самое оно

dmitrykruglov [10:55 PM] Нет

kirill.mokevnin [10:55 PM] single source of truth

[10:55] в системе всегда должен быть один источник правды для своих данных

[10:55] кто в данном случае источник правды?

redbrother [10:55 PM] users

kirill.mokevnin [10:56 PM] таблица emails или email в таблице юзеров?

[10:56] я именно про письма говорю

count [10:56 PM] по идее - таблица

greybutton [10:56 PM] а что правдой является?

kirill.mokevnin [10:56 PM] бинго, конечно таблица

[10:56] потому что email в юзере это денормализация

[10:56] он вторичен и восстанавливается по таблице emails (edited)

[10:57] архивные таблицы работают по другому, туда переносятся старые не актуальные записи

[10:57] но сами они не являются корнем агрегации в этих кейсах (edited)

[10:57] вижу что много новых понятий и вы загрузились

count [10:58 PM] ну пока все логично и не особо сложно

kirill.mokevnin [10:58 PM] давайте еще буквально пару моментов разберем и не будем дальше в дебри прыгать

[10:58] типа синхронизации с биллингом

[10:58] вот у нас есть таблица emails (edited)

[10:58] кто то выше говорил что должно быть булеан поле

[10:58] какое?

al3xanderg [10:58 PM] isActive

dmitrykruglov [10:59 PM] Delores

kirill.mokevnin [10:59 PM] отлично, почему это не правильно?)

dmitrykruglov [10:59 PM] Delited

kirill.mokevnin [10:59 PM] ну то есть оно сработает, но это не правильно

al3xanderg [10:59 PM] Потому что можно брать просто последнюю запись она будет актуальной

trofivan [10:59 PM] Потому что одно только может быть активным

[10:59] А в такой таблице может быть несколько

kirill.mokevnin [10:59 PM] ну это уже вопрос логики вашего кода isActive тут не причем (edited)

count [11:00 PM] подтверждено? (edited)

kirill.mokevnin [11:00 PM] активация емейла должна отключать старый и это будет через код делаться

[11:00] но тут еще бабка надвое сказала, есть разные варианты развития событий, нужно ли подтверждать подтвержденное? но это опустим

[11:00] я имею ввиду неправильно делать булеан поле isActive

[11:00] маркер активности конечно нужен

[11:00] но не так

trofivan [11:01 PM] Потому что может быть более 2 состояний у email

count [11:01 PM] активность можно через дату.

kirill.mokevnin [11:01 PM] потому что это конечный автомат да

[11:01] и конечный автомат должен быть выражен состояниями

trofivan [11:01 PM] Например, подтверждён/ожидает подтверждения/не подтверждён и прочие

kirill.mokevnin [11:01 PM] тут кое что нужно сказать

[11:01] вы должны понимать разницу между оверинжинирнг

[11:01] и "продуманная архитектура"

[11:02] всегда же ускользает это понимание да?

[11:02] оверинжинирнг это делать емейлы сразу отдельной таблицей когда только стартует проект

[11:02] если конечно это не является его основной фичей

amd [11:02 PM] меня терзает вопрос, но я спрошу в конце :slightly_smiling_face:

kirill.mokevnin [11:03 PM] а вот выбор поля isActive как булеан или state как строка

[11:03] это продуманная архитектура

[11:03] почему?

[11:03] начнем по по порядку, кто выбирает путь isActive, вообще скорее всего не знаком с автоматами

[11:03] а значит не будет использовать спец либы, а значит будет делать кучу рукопашки руками

[11:04] во вторых, у вас вообще то гораздо больше состояний, created, sending, sent, accepted, active, deactive

[11:04] потому что процесс отправки это тоже процесс

[11:04] я имею ввиду письма с подтверждением (edited)

[11:04] и переходные состояния такие как sending крайне важны6 чтобы ваши очереди по два раза не обрабатывали эту ситуацию (edited)

[11:05] если вы понимаете о чем я

[11:05] когда вы ставите флаг isActive, то вы потом его не поменяете

[11:05] начнут появляться новые флаги

[11:05] isSent

[11:05] isDeleted

[11:05] и так далее

al3xanderg [11:05 PM] да...

kirill.mokevnin [11:05 PM] у кого уже так, прошу читать "конечные автоматы шалыто"

[11:05] pdf легко гуглится

amd [11:06 PM] шалыто это автор?

guliy [11:06 PM] Битовая маска?)

kirill.mokevnin [11:06 PM] да, это профессор в питерском универе

[11:06] когда вы стейт делаете строчкой, то расширять его можете бесконечно

[11:06] прямо щас зайдите в гугл и наберите "github state machine <мой язык>"

count [11:06 PM] а потом могут появиться варианты +isActive +isDeleted

kirill.mokevnin [11:07 PM] и скиньте сюда что нибудь популярное

count [11:07 PM] противоречие

kirill.mokevnin [11:07 PM] да да

amd [11:07 PM] https://github.com/dotnet-state-machine/stateless GitHub dotnet-state-machine/stateless stateless - A simple library for creating state machines in C# code

antonshwab [11:07 PM] https://github.com/ztellman/automat GitHub ztellman/automat better automata through combinators

al3xanderg [11:07 PM] https://github.com/esampaio/state-machine GitHub esampaio/state-machine state-machine - Simple PHP package to create State Machines

kirill.mokevnin [11:08 PM] надеюсь теперь вы по другому взглянете на процессы и состояния

[11:08] про очереди еще поговорим отдельно

[11:08] это тоже история

[11:08] и автоматы в них

[11:08] я имею ввиду в следующий раз

dmitrykruglov [11:09 PM] Можно промежуточные состояния в базе не хранить

kirill.mokevnin [11:09 PM] там нужно хранить все

[11:09] ты пытаешься решать не ту проблему

[11:09] для базы нет проблемы хранить

[11:09] у программиста есть проблема "реагировать"

[11:09] и если данных нет, то придется изворачиваться

[11:10] sending крайне важно в случае если таска выполняется дольше положенного

[11:10] так как очередь вернет сообщение по визибилити таймауту

[11:10] и ее схватит следующий воркер

[11:10] он обязан проверить что таска сейчас sending и не выполнять отправку

[11:10] иначе привет дубли

[11:10] и тогда надо будет уже думать про локи (а автомат тоже лок)

guliy [11:11 PM] Если конечное число состояний, то строка не очень хороший вариант, как я уже писал -для этой задачи вполне бы подошло поле с битовой маской

kirill.mokevnin [11:11 PM] я уже не говорю про семантику передачи сообщний

[11:11] строка это прекрасный вариант, нет ничего страшнее битовой маски

[11:11] руками не распрасить

[11:11] ошибиться крайне просто

[11:11] геморой на пустом месте

[11:11] вы поизучайте решения на гитхабе

[11:11] в хекслете на вскидку 100 автоматов

count [11:11 PM] битовая маска не подойдет. ибо может содержать в себе противоречивые состояния (edited)

kirill.mokevnin [11:11 PM] при 400 таблицах

[11:12] окей, последний момент который разберем

[11:12] а то уже поздно

[11:12] это собственно сама ссылка

[11:12] вот мы ее получили

[11:12] и активируем

[11:12] а как этот механизм работает?

[11:12] подтверждение почты

amd [11:12 PM] переход по ссылке

kirill.mokevnin [11:12 PM] и?)

[11:13] прямо опиши

amd [11:13 PM] в ссылке уникальный токен зашит

kirill.mokevnin [11:13 PM] токен хранится в базе где?

guliy [11:13 PM] В ссылку зашивается токен, желательно jwt

count [11:13 PM] уффф… хорооший вопрос (edited)

amd [11:13 PM] в таблице там где не подтвержденный емейл

kirill.mokevnin [11:13 PM] ага кул

[11:13] я должен быть залогинен или нет?

[11:13] при активации

dmitrykruglov [11:14 PM] Нет

al3xanderg [11:14 PM] не важно

kirill.mokevnin [11:14 PM] так), ну чтож кто догадается почему это плхой вариант?

count [11:14 PM] у токена есть срок жизни. вопрос, нужно хранить только последний токен или все, непросроченные

kirill.mokevnin [11:14 PM] подсказка: секьюрити

al3xanderg [11:15 PM] при активации желательно заново логиниться

kirill.mokevnin [11:15 PM] представьте ситуацию, я случайно вбиваю чужой емейл у себя в акке, а чувак которому пришла ссылка взял и тыкнул ее

[11:15] и я потерял аккаунт

[11:15] еее

amd [11:15 PM] можно без логина, например проверять наличие куки секьюрной

kirill.mokevnin [11:15 PM] о каких куках речь? у людей тыщи устройств

amd [11:16 PM] а ну если в таком контексте

kirill.mokevnin [11:16 PM] ну а как еще?

dmitrykruglov [11:16 PM] Токен

kirill.mokevnin [11:16 PM] с мобилок и планшетов щас заходят больше

[11:16] чем с компов

[11:16] вам никакой токен не поможет

[11:16] нужна гарантия идентификации

[11:16] либо можно просто потерять акк

greybutton [11:16 PM] на старый майл тоже отправлять

count [11:17 PM] а если человек меняет мыл потому, что потерял доступ к старому?

guliy [11:17 PM] Гугл-аутинтификатор )

kirill.mokevnin [11:17 PM] кстати тут еще ведь проблема одна, вот я ошибься и вбил чужое мыло, а если оно было уже активно? А если не было активно, но другой потом захотел его тоже активировать?

amd [11:17 PM] по ссылке сразу на форму ввода логина пароля перекидывать, как подтвердит старые данные так сразу и менять

count [11:17 PM] логин-пароль то не поменялись

kirill.mokevnin [11:17 PM] вот в данном контексте набирается еще десяток кейсов

[11:18] теперь вы понимаете почему это не простая задача?

amd [11:18 PM] если делать с нуля да

al3xanderg [11:18 PM] если делать с головой)

redbrother [11:19 PM] :sob:.... В гробу я видел ваши состояния, куча проблем...

dmitrykruglov [11:19 PM] Легче не давать пользователям менять мыло

amd [11:19 PM] собственно, что хотел спросить. Зачем заново изобретать велосипед который кто то уже давно изобрел? Например в ASP.NET есть отдельный фреймворк который берёт на себя всю работу с учетными данными пользователей, вплоть до создание необходимых таблиц в БД. Крупные проекты (по моему опыту) опираются уже на готовый функционал подобного рода. И когда мне надо добавить возможность изменения пароля, мне достаточно обратится к уже именующийся API и докинуть поле для ввода на форму.

greencode [11:19 PM] в итоге вы за сколько эту фичу запилили?:)

dmitrykruglov [11:19 PM] Пусть новый акк создают

greybutton [11:19 PM] фейсбук вопросы задает по профилю, по друзьям и прошлой активности

kirill.mokevnin [11:19 PM]

Крупные проекты (по моему опыту) опираются уже на готовый функционал подобного рода. у вас в c# своя атмосфера, в остальном мире это не так

amd [11:20 PM] обидно звучит

[11:20] :disappointed:

kirill.mokevnin [11:20 PM] мы эту фичу запилили где-то за 4 полных дня и добавили 500 строк кода с тестами

[11:20] ну серьезно)

amd [11:20 PM] да я согласен)

guliy [11:20 PM] Ну и в итоге, что с мылкой то? )

amd [11:20 PM] просто делал это буквально недели две назад

[11:20] и часов за 6

[11:20] :slightly_smiling_face:

[11:20] ну как писал выше конечно, использовал готовый функционал

kirill.mokevnin [11:21 PM] но еще есть баги

[11:21] вот прямо щас упало

[11:21] [Hexlet] production - Reactivated Error: StateMachines::InvalidTransition: Cannot transition state via :activate from :created (Reason(s): Email уже существует)

guliy [11:21 PM] Тут же про фрейморки, а про инженерное мышление...

kirill.mokevnin [11:21 PM] активация емейла не прошла, где то пропустили кейс какой то

[11:21] возможно рейс кондишн

amd [11:22 PM] а вот вопрос, если имейл в черный список попадает это как то отслеживается системой?

kirill.mokevnin [11:22 PM] да, мы блочим

[11:22] и просим написать в саппорт

[11:22] для выяснения

amd [11:22 PM] и по отмоканию, обратно возвращаете?

kirill.mokevnin [11:22 PM] там чаще не чыерный список

[11:22] а нас в спам например добавляют

k1s [11:22 PM] у вас там в рубях акторов не завезли? рейс кондишн какой-то

amd [11:22 PM] ну то есть интеграции напрямую с сеервисами баз блэклистов нету?

kirill.mokevnin [11:22 PM] @k1s все на джобах же делается

[11:23] а так как очереди это at least once семантика, то сам понимаешь

[11:23] ты о другом

[11:23] мы используем sparkpost

[11:24] с нас хватило самостоятельно работы с почтой и мы давно с нее спрыгнули

amd [11:24 PM] Кирил, неужели нет аналогов уже готового фунционала (не дот нет)?

count [11:24 PM] кстати, а в какое состояние переходит старый мыл, до подтверждения нового?

kirill.mokevnin [11:24 PM] мы отслеживаем только прикладные проблемы

count [11:25 PM] и дается ли право пользователям иметь одинаковый мыл?

kirill.mokevnin [11:25 PM] есть посмотри devise

[11:26] @count да, это тоже вопрос (edited)

[11:26] в принципе все, надеюсь было полезно

[11:26] вот примерно так и происходит работа

[11:26] анализ сущностей, автоматов, секьюрити, логика (edited)

trofivan [11:26 PM] Спасибо, Кирилл

greybutton [11:26 PM] Спасибо

sayobye [11:27 PM] спасибо

amd [11:27 PM] вот действительно, живешь в контексте гос проектов и тут прям как другой новый мир)

[11:27] и локальные серверы почты никто не использует :slightly_smiling_face:

[11:27] и ФЗ по персональным данным особо не грозит

[11:29] Вот кстати да, Кирил вы же храните данные о пользователе как таковом не Хекслете, как у вас со стороны закона о персональных данных это дело обстоит. попадаете под действие?

kirill.mokevnin [11:30 PM] Начнем с того что хекслет не российская компания

amd [11:30 PM] но хранит же данные российских пользователей)

kirill.mokevnin [11:30 PM] А кто не хранит?

amd [11:30 PM] :slightly_smiling_face:

kirill.mokevnin [11:30 PM] Хоть один сервис назовешь?

sayobye [11:30 PM] Кстати хотел спросить почему не российская, ещё при регистрации адрес странный заметил

kirill.mokevnin [11:30 PM] Мы фины

amd [11:31 PM] да все хранят пока письмо счастья от роскомнадзора не прилетит

count [11:31 PM] и финки

amd [11:31 PM] они же по порядку должны на территории РФ хранится 2 replies Last reply 16 hours ago View thread

amd [11:31 PM] просто интересен вопрос был, можешь не заморачиваться с ответом :slightly_smiling_face:

[11:33] я и не знал что Хекслет в Финляндии, вот честно :smile:

kirill.mokevnin [11:34 PM] это не единственное чего ты не знал :wink:

amd [11:34 PM] Век живи век учись это да

kirill.mokevnin [11:34 PM] ребят, а по теме вопросы есть?

[11:34] что понятно/непонятно было

[11:35] про что потом подробнее рассказать

[11:36] кстати вот http://is.ifmo.ru/books/_book.pdf (edited)

amd [11:36 PM] Почему решили изначально что смена почты не нужна была. Design Flaw просто?

[11:37] Надо подумать и переосмыслить) вопросы наверное позже будут :)

greybutton [11:38 PM] про источник правды и еще не понял, связь между таблицей юзеры с полем майл и новой таблицей майлов. я в базах данных не много знаю

kirill.mokevnin [11:38 PM] на все такие вопросы я тебе отвечу одним, читай lean startup

k1s [11:38 PM] как уже спросили выше – почему просто не взять что-то готовое типа akka persistence fsm?

kirill.mokevnin [11:38 PM] когда у вас данные денормализованы, то должно быть место откуда они берутся

[11:39] @k1s ты точно читал о чем я писал?

[11:39] https://github.com/state-machines/state_machines вот это рельсовый автомат GitHub state-machines/state_machines state_machines - Adds support for creating state machines for attributes on any Ruby class

[11:40] и он очень глубоко проинтегрирован с ORM которую мы используем (edited)

trofivan [11:40 PM] У каждого email есть несколько состояний, считай это автомат. Сами состояния хранятся в таблице с адресами? Или в отдельной табличке?

kirill.mokevnin [11:40 PM] с адресами конечно, у тебя у каждого емейла один процесс подтверждения

[11:41] но автоматов на одну сущность может быть много, все же зависит от того в каких процессах она участвует

[11:41] например в хекслете у юзера автоматов штук 8 наверное

trofivan [11:41 PM] В таблице email есть столбец state.

[11:41] ?

kirill.mokevnin [11:41 PM] например так

trofivan [11:41 PM] А там уже строка?

kirill.mokevnin [11:41 PM] да просто строка

[11:42] ее обновляет либа для работы с автоматами

[11:42] я выше линк дал, посмотри примеры, там все понятно

amd [11:42 PM] Кирил ещё хотел спросить. Как думаешь в современных реалиях подобных проектов можно отказаться от электронной почты совсем? Например использовать боты в мессенджерах или sms сервис как в банках, не будут ли эти варианты проще

greencode [11:43 PM] только не sms. Забудьте это как способ авторизации

kirill.mokevnin [11:43 PM] я щас глянул

[11:43]

   state :created
   state :waiting_confirmation
   state :active do
     validates :email, email: { reject_one_level_domain: true }, uniqueness: { case_sensitive: false, scope: [:state] }
   end
   state :archived

   event :wait_confirm do
     transition :created => :waiting_confirmation
   end

   event :activate do
     transition all => :active
   end

   event :archive do
     transition all => :archived
   end
 end

[11:44] вот описание нашего автомата

[11:44] user:email

greencode [11:44 PM] удобно, но сукерности чуть больше нуля

amd [11:45 PM] Что reject_one_level_domain означает?

kirill.mokevnin [11:45 PM] попробуй переведи)

amd [11:46 PM] Она переводится) я не могу понять что за домены первого уровня отметаются)

trofivan [11:46 PM] Поэтому и reject

kirill.mokevnin [11:46 PM] а, я хрен его знает

[11:46] код не я писал

[11:47] но так логично вроде (edited)

[11:47] :smile:

trofivan [11:49 PM] У меня ещё вопрос. Денормализацию (хранение актуального мэйла в таблице users) лучшее делать когда совсем край и никак иначе? (edited)

[11:49] Денормализацию

[11:50] Автозамена блин

k1s [11:50 PM] это выглядит самым очевидным решением для начала (edited)

kirill.mokevnin [11:51 PM] денормализация это естественное состояние проектов где уже сложно

[11:51] но тут немного особый кейс

[11:51] обычно синхронизация это проблема прямо

[11:52] а тут так или иначе при активации нового емейла, в users проставлятся current_email_id (edited)

[11:52] и совершенно никакой сложности сразу туда и email вставлять

[11:52] в итоге все работало как работает

[11:53] но вот где синхронизация не требуется (из за имутабельной структуры), там мы сразу все связи денормализуем

[11:53] это и дешево и удобно

[11:53] поэтому мало джойнов

[11:53] запросы простые и тупые (edited)

naphaso [11:53 PM] что развели. кстате, запрашивать подтверждение старой почты при смене - имхо плохая практика. почта в половине случаев меняется потому, что доступ к старой почте потерян

kirill.mokevnin [11:53 PM] о, хорошее дополнение

[11:54] мы про это не подумали кстати, потому что не собирались так сделать

count [11:54 PM] я как раз говорил про это

[11:55] чот часто меняют почту потому что к старой утерян доступ

trofivan [11:55 PM] Я поэтому почту и менял. Старый домен закончился и не мог даже с него письмо отправить в саппорт

----- Today September 23rd, 2017 ----- naphaso [12:06 AM] не читая слаконар до конца (нет сейчас времени) попробую предложить свой вариант:

  1. запрос на смену почты поступает от аутентифицированного юзера (возможно с дополнительным подтверждением паролем)
  2. по запросу проверяется количество запросов в таблице email_change_request по данному user_id, если они не превышают N (равно 3, например), отправляется email на новый адрес и запрос помещается в таблицу email_change_request с полями (id, user_id, create_time, expire_time, prev_email, next_email, token), token=$random_token, expire_time=create_time+1h, с индексами по user_id, token и expire_time
  3. джоба каждый час чистит запросы с истекшим expire_time < now()
  4. в емейле есть ссылка которая включает в себя token
  5. при переходе по ссылке ищется запрос по токену, проверяется соответствие prev_email и user.email и у юзера меняется емейл.
  6. как истекшие, так и успешно отработавшие email_change_request сливаются в аналитику (я бы взял bigquery).

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

[12:08] автоматы тут выглядят оверинженерингом

kirill.mokevnin [12:08 AM] автомат в первую очередь заложен в сам процесс

[12:08] ты не можешь засунуть его туда где его нет по сути

[12:09] у тебя схема просто инвертная, ты делаешь первичным юзера и отдельно реквесты

[12:09] а аналитка вообще отдельно

naphaso [12:09 AM] всё во вселенной может быть представлено автоматом. необязательно конечным, не обязательно детерминированным - но может.

kirill.mokevnin [12:09 AM] у меня не реквесты а емейлы пользователя в принципе, и они первичны

[12:10] и емейл может быть либо в состоянии waiting_confirmation, либо active (на самом деле там еще стейты)

[12:10] ну и отправку емейла тебе надо чекать

naphaso [12:11 AM] т.е. у пользователя список емейлов, которые он может добавлять-удалять?

kirill.mokevnin [12:11 AM] джоба которая это делет может не доотправить

[12:11] по сути да

[12:11] потенциально это позволит использовать схему как в трелло (edited)

[12:11] с включением "активного" емейла

[12:11] плюс собираются письма и соц сетей

[12:11] и через них связь может идти (edited)

[12:12] ну и еще нам не нужны все эти сложности с вычисткой, из за имутабельности нашей базы, аналитика выгребается из нее

[12:12] не напрямую конечно, а через aws quick sight

[12:13] учитывая что наша база за 4 года существования доросла всего до 10 гигов, нам все эти ваши проблемы с бигдатой чужды)

naphaso [12:13 AM] везёт же

kirill.mokevnin [12:13 AM] внезапно так у большинства проектов

[12:13] поэтому я так топлю всегда за простые и тупые решения

[12:14] я это к тому что тут много неокрепших умов, и все хотят чувствовать себя героями

[12:14] глядя на тебя например

[12:14] что чревато

naphaso [12:15 AM] я сам говнокодю напропалую, с меня пример брать не надо

amd [12:16 AM] Кто не без этого)

naphaso [12:16 AM] если есть решение тупее и проще, и можно позволить себе риск решать проблемы когда они возникнут - я возьму его

kirill.mokevnin [12:17 AM] кстати, дополни про денормализацию

[12:17] как у вас с ней

naphaso [12:18 AM] не запаривались. когда пришла пора оптимизации, запихали денормализованные данные в кэш

count [12:18 AM] хмм.. “они почти гугл“?

kirill.mokevnin [12:18 AM] да)

[12:18] ну а например банальные айдишники для глубоких связей которые нужно доставать по цепочке и они никогда не меняются?

[12:18] мы храним в самых глубоких сущностях практически все до самого верха

[12:18] потому что очень много связанных выборок

[12:19] instance/run -> instance -> exercise/member -> lesson/member -> lesson -> course -> stack

[12:19] одна из цепочек

naphaso [12:20 AM] ну вот всю эту цепочку со всеми данными кэшировать по идентификатору в кластере редисов. или если она иммутабельна - то в groupcache

kirill.mokevnin [12:20 AM] плюс кучка ответвлений тип user

[12:20] но в таблицу вы не кладете да?

naphaso [12:21 AM] нет, накладненько выходит. и следить за инвалидацией тяжело

kirill.mokevnin [12:22 AM] так нет же инвалидации

[12:22] в этом ключ

[12:22] накладность в чем?

naphaso [12:23 AM] по объему данных и нагрузке на запись. читать сколько угодно цепочек - без проблем. надо будет - поднимем нужное количество слейвов бд для чтения. а вот писать лишний раз не стоит (edited)

kirill.mokevnin [12:23 AM] вот мне тут интересно, эта запись происходит один раз при создании

[12:24] разве это настолько критично получается в вашем случае +7 колонок int которые заполняются только при создании записи?

[12:24] если там ключи то я еще понимаю

dimonnwc3 [12:25 AM] все забыли, что смена емаила это U из CRUD, а то что стоит в задаче, это change request, вот с ними и надо работать, как отдельными сущностями, а не с emailами. На них и надо вешать стейт машину, тогда и денормализация не нужна будет. (edited) 1 reply Today at 12:28 AM View thread

kirill.mokevnin [12:25 AM] или в принципе чтение настолько просто, что нет смысла даже потенциальную нагрузку на запись делать?

[12:26] денормализация email в таблице user нужна по любому если хочется работать по старому

naphaso [12:26 AM] если один раз и ничего не меняется и точно меняться не будет - то зачем вообще множить сущности сверх необходимого? а если будет, то доставит проблемы. легко не увидеть лишние связи при рефакторинге

kirill.mokevnin [12:26 AM] речь про то что они уже есть и они нужны

naphaso [12:29 AM] а что мешает перестать использовать этот столбец? запрос юзера и всей информации по нему по емейлу вынестив кэш. инвалидировать его при модификации сущностей

kirill.mokevnin [12:30 AM] то что не имея кеша, за тебя все делает orm на 100%

[12:31] зачем вводить кеш, когда можно сделать столбец user_id

[12:31] который гарантированно не меняется

[12:31] и ходить к юзеру напрямую

[12:31] используя стандартные возможности orm

[12:31] instance.user

[12:31] например

[12:31] я понимаю что у вас нт никаких орм, но и тебе нужно понять что у нас нет никаких кешей

[12:32] и мы избегаем любую рукопашку

[12:32] потому что можем себе это позволить

naphaso [12:32 AM] ты говоришь про то что орм вам обеспечивает целостность денормализованных данных?

kirill.mokevnin [12:33 AM] я уже 5 раз говорю о том что мы денормализуем ключи которые не меняются гарантированно никогда

[12:33] если пользователь запустил нашу иде, то сущность которая за это отвечает, привязана только к этому пользователю

[12:33] и иначе никак (edited)

[12:33] и это не кеш

[12:34] кеш заканчивается, а юзер нет)

v.kolesnikov [12:34 AM] Как гарантия соблюдается? Мне вот кажется, что этот подход, с денормализацией в базе идёт именно из того пункта, что большинство ORM не умеет (делает неудобно, некрасиво) работать с глубокими связями. То есть денормализация в этом случае не является решением какой-то проблемы БД, а попыткой невелировать отсутствующие возможности ORМ, что как-то не очень. kirill.mokevnin который гарантированно не меняется Posted in #generalToday at 12:31 AM (edited)

kirill.mokevnin [12:35 AM] orm тут не причем, я про то что мы продолжаем пользоваться ее возможностями

[12:35] нам не нужны новые слои, проверки кешей

[12:35] я просто делаю entity.user

[12:35] и все

[12:35] потому что для этой моделки в таблице в базе есть user_id

[12:35] и мне не надо делать entity.entity.entity.user

[12:35] порождая 10 запросов в базу (edited)

[12:35] я уже не говорю про join

naphaso [12:35 AM] денормализация в бд по сути эквивалентна хранению кэша в бд. и проблемы те же. иммутабельный кэш без нужды в инвалидации - везде счастье

kirill.mokevnin [12:36 AM] ну так об этом и речь

[12:36] что когда можно себе это позволить, то это счастье

[12:36] и во многом оно за счет того что мы в принципе мало чего меняем

[12:36] обычно создаем новое

naphaso [12:39 AM] append-only подход прекрасно. ты говоришь у вас 10гб база, всё отлично справляется. рам на сервере бд сколько? гигабайт 16 поди. то есть ещё 6гб и начнутся проблемы с резкой деградацией производительности. и либо наращивать рам, либо составлять минимизировать обращения к редко используемым частям таблиц, чтобы они не вытесняли горячий кэш

kirill.mokevnin [12:39 AM] 4 гигабайта

naphaso [12:40 AM] ну значит горячих данных из них меньше 4гб и их ротация вписывается в производительность диска

kirill.mokevnin [12:41 AM] но это потому что пока мы не чистим буквально пару больших таблиц, в которых в районе нескольких миллионов, а может десятка миллионов записей

[12:41] в остальных дай бог тысяч по 800 наберется

[12:41] за 5 лет напомню

[12:41] и дай бог у нас начнется резкая деградация производительности когда мы дойдем до 20 гигов

[12:42] значит мы будем все еще живы (edited)

naphaso [12:45 AM] просто странно согласуется - ты с одной стороны говоришь, что можем себе позволить обходиться без кэша. с другой - что в базу заносим денормализованные данные (для оптимизации производительности?)

kirill.mokevnin [12:45 AM] нет, для удобства работы

[12:45] это тупо физически удобно

[12:45] когда я могу сделать join не 10 таблиц чтобы добраться до корня (edited)

[12:45] а сразу

[12:46] и я могу сделать сразу entity.user, а не entity.entity.entity.entity.user

naphaso [12:47 AM] каждая новая таблица в цепочке этих 10 таблиц экспоненциально уменьшает вероятность, что в связи с новыми требованиями когда-нибудь иммутабельность этой цепочки где-то не нарушится (edited)

kirill.mokevnin [12:47 AM] не нарушится

[12:47] можешь быть спокоен

[12:48] чаще бывает наоборот, что изменяемость приводит к проблемам

[12:48] давай пример

[12:48] а то ты не то себе фантазируешь

[12:48] вот есть exercise (edited)

[12:48] это практика

[12:49] ей соответствует репозиторий с заданием

[12:49] вот я меняю репозиторий

[12:49] что должно поменяться?

[12:51] ты ведь знаешь что нельзя менять практику

[12:51] или нет?)

[12:53] хм, я думаю чего ты тут активничаешь, а у тебя же день на дворе)

naphaso [12:53 AM] ну как я понял ты создаешь новую с новым заданием и меняешь её в курсе, а те что уже начали проходить, заканчивают старый вариант

kirill.mokevnin [12:54 AM] да, типичная схема как в любом ci

[12:54] есть project а есть build

[12:54] у нас exercise и exercise/build

[12:54] можно тут сделать мутабельно? нет конечно

[12:54] может ли один билд перепривязяться к другому exercise?

[12:54] нет конечно, даже в самых смелых мечтах

[12:54] соответственно все сущности связанные с exercise/build

[12:54] так же намертво связаны с exercise

[12:55] и если нам прямая связь с exercise упростит код, то мы денормализуем

[12:55] и в таблице будет exercise_build_id и exercise_id

[12:56] и еще, для той же аналитики часто очень важно запомнить те сущности которые были на тот момент, когда сущность создавалась

[12:56] поэтому эти id, сохраняются часто потому что мы запоминаем историчность

[12:56] но они не являются актуальными и по ним не строится логика

[12:57] ну и опять же, нет ничего проще чем подцепить к базе quicksight, который сам выкачивает нужные срезы

[12:57] и по ним уже строит аналитику

[12:57] все делается от и до любым человеком без навыком программирования (ну базы нужно знать немного) и без необходимости отвлекать девелопера (edited)

[12:57] и понятно что для вас такое никогда в жизни не сработает

[12:58]

ну как я понял ты создаешь новую с новым заданием и меняешь её в курсе,

[12:58] кстати нет

[12:59] в exercise есть понятие current_exercise_build

[12:59] мы только его меняем автоматом

[12:59] и старт любой практики завязывается на него

[12:59] и вот эта штука мутабельна да

[12:59] таких current много

naphaso [1:01 AM] про десять джойнов - а разве орм это не автоматизирует?

kirill.mokevnin [1:02 AM] да она это делает сама если ты связи опишешь, это выглядит так has_many :users, through: :members, таких цепочек можно строить бесконечное число (edited)

Max [1:02 AM] joined #general.

kirill.mokevnin [1:02 AM] и дальше будет выглядеть так как будто ты напрямую запрос делаешь entity.users (а она идет через мемберов) (edited)

[1:02] но если псмотришь в лог, то там все соберется в кучу джойнов

naphaso [1:04 AM] согласен, что денормализованные данные это удобно и полезно для производительности, но их удобнее держать в изолированном кэше. изолированный кэш за секунду можно грохнуть и не беспокоиться об этом - он соберётся заного. денормализованные данные в базе - куда тяжелее

kirill.mokevnin [1:04 AM] тут все просто, когда есть кеш и система в принципе с ним живет то да

naphaso [1:04 AM] обновить столбец у десятков миллионов записей на основе какой-то логики - это существенное время

kirill.mokevnin [1:04 AM] когда его нет, то это не просто усложнение, это адище

[1:05] потому что придется уже кучу штук делать руками

[1:05] и не то чтобы мы были против, мы еще н вышли на уровень "бизнес чувствует себя хорошо, можно нанять второго девелопера"

[1:05] к сожалению (edited)

[1:08] у нас знаешь какой приоритет, по максимум использовать все в дефолтном состоянии

naphaso [1:08 AM] ну почему руками, есть автоматизированные решения

kirill.mokevnin [1:08 AM] потому что это позволяет нам свитчится на новые версии всего и вся

[1:08] без проблем

[1:09] а они за собой привносят много плюшек и решают за нас все

[1:09] какие бы это не были автоматизированные решния, это не решения для наших бизнес задач

naphaso [1:09 AM] вон в спринге пишешь аннотацию @Cacheable над функцией и результат её выполнения в зависимости от параметров кэшируется

kirill.mokevnin [1:09 AM] мемоизацию и мы можем замутить чуть что)

[1:09] делов то

[1:09] только че они обманывают джавистов

[1:10] называя ее кешом (edited)

naphaso [1:11 AM] кэш, он через нужный cachemanager сохраняет его где угодно. ну и инвалидацию обеспечивает, если функция не совсем чистая. правда с инвалидацией уже не всё просто

[1:11] а чем это не кэш?

kirill.mokevnin [1:11 AM] у них есть фундаментальная разница, мемоизация не подразумевает понятия инвалидация, кеш подразумевает. Семантика разная, разное поведение кода

alexander.vyatkin [1:11 AM] Многое я пропустил..

kirill.mokevnin [1:12 AM] я под инвалидацией понимаю сейчас не только устаревание с точки зрения оптимизации самого хранилища

[1:12] а именно устаревание данных и замену новыми

[1:12] в мемоизации это не нужно по определению

naphaso [1:12 AM] иммутабельный кэш тоже кэш. да и спринговский кэш умеет в инвалидацию

kirill.mokevnin [1:12 AM] технически да

[1:12] семантически я все же считаю что это разные понятия

[1:13] кстати из вики

[1:13]

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

[1:14] кстати у нас есть одно место, где напрашивается материализованная вьюха

[1:14] мы пока не спешим, смотрим на него и думаем

[1:15] там нужно группировку по группировке делать

naphaso [1:15 AM] в англоязычной вики мемоизация определяется как кэширование результатов выполнения функции

alexander.vyatkin [1:15 AM] Ребята, вы пугаете.. Очень глубоко.. Разговор для вас двоих, получается..

kirill.mokevnin [1:15 AM] ох уж эта вики :kolobok:

[1:15] что ты думаешь про такие вьюхи?

[1:16] стоит ли оно того

naphaso [1:17 AM] я как-то всегда избегал их без видимых причин. разве что в аналитике использовал (bigquery, hadoop/spark) (edited)

kirill.mokevnin [1:17 AM] главное преимущество это опять же что мы сможем испльзовать все те же инструменты

[1:17] orm, выбрки, группировки, вывод (edited)

[1:17] иначе придется мало того что ручками, так еще синкать данные самим

[1:17] но вот эта материализация

[1:18] насколько она дорогая

[1:18] боюсь что дорогая

[1:18] потому что данные группируются

naphaso [1:18 AM] но в качестве замены денормализации материалайзд вью явно лучше

kirill.mokevnin [1:19 AM] тут не обойдешься денормализацией

naphaso [1:21 AM] ну если обновлять его надо нечасто

[1:22] каждое materialized view это полное исполнение запроса

kirill.mokevnin [1:22 AM] 0_o на каждое изменение?

naphaso [1:22 AM] обновляются вручную

kirill.mokevnin [1:22 AM] а

naphaso [1:22 AM] REFRESH MATERIALIZED VIEW

kirill.mokevnin [1:23 AM] черт, я думал оно само

[1:23] вот подстава

naphaso [1:24 AM] триггеры можно на обновление прикрутить, но тяжело и дорого. а аддитивное обновление при изменениях врядли кто реализует, не вписывается в реляционную модель

kirill.mokevnin [1:25 AM] угу(

naphaso [1:32 AM] хотя кстате вписывается в OLAP

[1:34] хотя я после эпопеи со своей дипломной работой как только слышу это слово начинаю отговаривать всех с этим связываться

[1:35] (я пытался несколько месяцев прикрутить гомоморфное шифрование к OLAP-модели)

[1:37] хорошо что олап похоже сгинул в истории, и пришла текущая бигдата, относительно простая и понятная

[1:41] хотя отдельные принципы нередко применяются, частенько даже изобретаются заного

kirill.mokevnin [2:12 AM] https://code.facebook.com/posts/300798627056246/relicensing-react-jest-flow-and-immutable-js/ Facebook Code Relicensing React, Jest, Flow, and Immutable.js React 16 will be licensed under the MIT Open Source license.

[2:12] @naphaso забирай)

naphaso [2:13 AM] вау

[2:14] они таки прислушались. моё мнение о них возросло

felix [8:27 AM] Народ, тут Кирилл недавно говорил, что напишет про react vs vue, плюсы и минусы обоих решений. Этого еще не произошло? Не охото прост пропустить (edited)

kirill.mokevnin [8:34 AM] Привет. Да там буквально один аспект о котором я сказать хотел

felix [9:09 AM] Привет, там выше чет просто эпическая история про емейлы) Я ток ща отлип, посмотреть не ответил ли кто) У нас в компании прост думают что лучше, vue или react. Говорят, что скорость разработки из-за jsx медленная, большие компоненты не напишешь и посматривают в сторону vue. А тут ты как раз написал, что тебе есть что сказать)

kirill.mokevnin [9:10 AM] В твоей компании серьезно считают что jsx их замедлит на 30%?)

felix [9:10 AM] ну да, вообще конечно там специфический кейс - лэндинг с анимациями. В этом случае реакт наверн не лучшее решение (edited)

sashashakun [9:12 AM] Ололо

kirill.mokevnin [9:14 AM] А вам точно jquery не подойдет?

[9:14] Лендинг это ж не про логику

felix [9:14 AM] Ну там прост заказчик хотел, чтобы все по модному, на реакте)

kirill.mokevnin [9:14 AM] Тут надо быстро говнякать

[9:14] Понятно

pandabear [9:19 AM] сделайте просто лендос и формочку на реакте запилите и всё

anatoliy.poloz [9:25 AM] почитал слаконавр

[9:25] зацепило

[9:27] но теперь кажется что aws, gce и прочие "облака" все же для стартапов, а не для удешевления большой нагрузки, как например думают в энтэрпрайзах

[9:29] в "бережливом стартапе" говорится что часть идея было взято от японской Toyota, а та в свою очередь взяла идеи у становления СССР и партизанских движений времен ВОВ.

greybutton [9:31 AM] а какие идеи тойота взяла у ссср? 3 replies Last reply today at 9:34 AM View thread

anatoliy.poloz [9:31 AM] и в общем основные постулаты бережливого стартапа сильно схожи с действиями партизанских 5рок, там в определенный момент поняли что нападать круппными группами не мобильно и стали устраивать много диверсий в разных местах малыми и очень мобильными группами

pandabear [9:34 AM] ну ты и сравнил, лол

alex_r [9:41 AM] партизанский стартап

mortex [11:48 AM] joined #general.

grigory14 [12:11 PM] Отличный слаконар! Сегодня ночью проснулся, думал, что бы такого почитать, чтобы быстро заснуть. Вспомнил про дискуссию в слаке, вот, думаю, то, что надо!)) начал читать и так стало интересно, сам себе задавал вопросы, которые у ребят возникали. Вобщем прекрасный пример проблемы, её подводных камней, разбора ошибочных путей решить задачу и наиболее приемлемый вариант ответа)

Clone this wiki locally
You can’t perform that action at this time.