Через 9 минут выступаю здесь
Присоединяйтесь к нашему голосовому чату. В 19:00 начнём обсуждать ситуацию на рынке труда. Приглашённые гости — наши выпускники и специалисты IT-компаний — ответят на ваши вопросы и поделятся своим опытом работы за рубежом: https://t.me/karpovcourseschat
Присоединяйтесь к нашему голосовому чату. В 19:00 начнём обсуждать ситуацию на рынке труда. Приглашённые гости — наши выпускники и специалисты IT-компаний — ответят на ваши вопросы и поделятся своим опытом работы за рубежом: https://t.me/karpovcourseschat
Telegram
karpov.courses: чат
Телеграм-канал: https://t.me/KarpovCourses
Навигация по полезным постам: https://telegra.ph/Navigaciya-05-19
Навигация по полезным постам: https://telegra.ph/Navigaciya-05-19
👍31❤7
Продолжаем разговор и сегодня поговорим про еще один архетип Стафф Инженера - Решала
Решала это уважаемый и надежный агент больших начальников, который глубоко закапывается в сложную проблему и, как бы удивительно это не звучало, решает ее. Решалу направляют на критические участки или те участки, где велик риск неудачи
В то время как большинство Архетипов Стафф Инженера завязано на организационную активность, Решала занимается уже существующими и понятными проблемами, соответственно он не занимаются административщиной.
Зачастую Решала перестает работать над проблемой, как только критическая стадия миновала, что может создать некое ощущение ветрености и непостоянства, так как команда остается поддерживать "решенную" проблему
Решала чаще всего трудится в компаниях где единицей планирования является человек, а не команда, его редко можно встретить в компании, где все вращается вокруг спринтов. Хотя если такая компания разрастается или живет достаточно долго чтобы нажить разнообразный технический долг, то там может завестись решала
#BigTechLevels
Решала это уважаемый и надежный агент больших начальников, который глубоко закапывается в сложную проблему и, как бы удивительно это не звучало, решает ее. Решалу направляют на критические участки или те участки, где велик риск неудачи
В то время как большинство Архетипов Стафф Инженера завязано на организационную активность, Решала занимается уже существующими и понятными проблемами, соответственно он не занимаются административщиной.
Зачастую Решала перестает работать над проблемой, как только критическая стадия миновала, что может создать некое ощущение ветрености и непостоянства, так как команда остается поддерживать "решенную" проблему
Решала чаще всего трудится в компаниях где единицей планирования является человек, а не команда, его редко можно встретить в компании, где все вращается вокруг спринтов. Хотя если такая компания разрастается или живет достаточно долго чтобы нажить разнообразный технический долг, то там может завестись решала
#BigTechLevels
👍68❤5😁1
Сделаю репост своей записи на linkedin
Why precision is a dangerous metric
I had a recent conversation with a friend of mine regarding the evaluation of fraud models.
Of course, no metric is ideal, and it always depends on what is the final goal. However, we usually want to maintain a specific fraud-to-legit transactions ratio when we speak about fraud models. If we would have ten times more transactions, it is probably ok to have ten times more fraud, but not twenty of thirty. In other words, we want to have a probabilistic model.
Another thing is that fraud usually belongs to the class imbalance problem, and this imbalance is not constant. One day it can be 1:100 (outburst of fraudulent transactions), next day, 1:1000 (an ordinary day) and next day, 1:10000 (fraudsters took a vacation)
The problem with precision is that its calculations take both classes into account, precision = TP/(TP + FP)
Imagine we have a model which has a probability of 95% to predict that fraud is a fraud and 5% to predict that non-fraud is fraud.
Review two scenarios
P = number of positive samples, N = number of negative samples
P = 10000, N = 10000, Precision = 0.95*10000/(0.95*10000 + 0.05* 10000) = 0.95
P = 1000, N = 10000, Precision = 0.95*1000/(0.95*1000 + 0.05* 10000) = 0.65
It is easy to prove that TPR and FPR would not change because those are rates independent of class imbalance. AUC, which can be shown to be an averaged Recall (TPR) of class 1 and 0, is also class balance insensitive and, thus, probabilistic.
Initially, my friend created a notebook to prove me wrong ( I slightly adjusted it to show the opposite). He said, quote:
Model A is better according to both ROC AUC & PR AUC Metrics. However, model B (bad model) still gets a very good FPR (0.00092) even though if it was put into production, the predictions would be rubbish (920 out of 1000 fraud predictions would be incorrect). Precision allows us to see this. It's just 0.08 for Model B, so we'd never even think about putting it close to production :D
Now, what is the fallacy here?
First of all, model B has an FPR of 0.0092, which is 46 times higher than model A, with an FPR of 0.0002. There is no good or bad FPR. It depends on your volume, and even a slight difference might be huge. 0.99 is ten times higher than 0.999, 1:100 vs 1:1000.
But, even here, while precision is only ten times worse, the FPR of model B is 46 times worse, hard to call this to be very good.
As you can see in the notebook above - precision shows a very different number with the shift in class balance, even with the same model performance. At the same time, both TPR and FPR remain the same. Note that the total volume of transactions almost didn't change.
I strongly recommend using the following metric to assess your fraud models.
Fix specificity on the desired level (specificity = TNR = 1 - FPR), for example, in one company, where we had a goal to catch a fraudulent behaviour and more than 100 000 000 000 events per day; we were fixing specificity to be at least 0.999999 (in other words, we were ok to have one false positive per one million events) and maximising recall (true positive rate)
In the next post, I will provide another reason why precision is dangerous.
Why precision is a dangerous metric
I had a recent conversation with a friend of mine regarding the evaluation of fraud models.
Of course, no metric is ideal, and it always depends on what is the final goal. However, we usually want to maintain a specific fraud-to-legit transactions ratio when we speak about fraud models. If we would have ten times more transactions, it is probably ok to have ten times more fraud, but not twenty of thirty. In other words, we want to have a probabilistic model.
Another thing is that fraud usually belongs to the class imbalance problem, and this imbalance is not constant. One day it can be 1:100 (outburst of fraudulent transactions), next day, 1:1000 (an ordinary day) and next day, 1:10000 (fraudsters took a vacation)
The problem with precision is that its calculations take both classes into account, precision = TP/(TP + FP)
Imagine we have a model which has a probability of 95% to predict that fraud is a fraud and 5% to predict that non-fraud is fraud.
Review two scenarios
P = number of positive samples, N = number of negative samples
P = 10000, N = 10000, Precision = 0.95*10000/(0.95*10000 + 0.05* 10000) = 0.95
P = 1000, N = 10000, Precision = 0.95*1000/(0.95*1000 + 0.05* 10000) = 0.65
It is easy to prove that TPR and FPR would not change because those are rates independent of class imbalance. AUC, which can be shown to be an averaged Recall (TPR) of class 1 and 0, is also class balance insensitive and, thus, probabilistic.
Initially, my friend created a notebook to prove me wrong ( I slightly adjusted it to show the opposite). He said, quote:
Model A is better according to both ROC AUC & PR AUC Metrics. However, model B (bad model) still gets a very good FPR (0.00092) even though if it was put into production, the predictions would be rubbish (920 out of 1000 fraud predictions would be incorrect). Precision allows us to see this. It's just 0.08 for Model B, so we'd never even think about putting it close to production :D
Now, what is the fallacy here?
First of all, model B has an FPR of 0.0092, which is 46 times higher than model A, with an FPR of 0.0002. There is no good or bad FPR. It depends on your volume, and even a slight difference might be huge. 0.99 is ten times higher than 0.999, 1:100 vs 1:1000.
But, even here, while precision is only ten times worse, the FPR of model B is 46 times worse, hard to call this to be very good.
As you can see in the notebook above - precision shows a very different number with the shift in class balance, even with the same model performance. At the same time, both TPR and FPR remain the same. Note that the total volume of transactions almost didn't change.
I strongly recommend using the following metric to assess your fraud models.
Fix specificity on the desired level (specificity = TNR = 1 - FPR), for example, in one company, where we had a goal to catch a fraudulent behaviour and more than 100 000 000 000 events per day; we were fixing specificity to be at least 0.999999 (in other words, we were ok to have one false positive per one million events) and maximising recall (true positive rate)
In the next post, I will provide another reason why precision is dangerous.
👍53🔥15❤1
24 марта в 18:00 в МТС проводят онлайн-митап для дата саентистов, дата инженеров и других дата людей
Ребята из МТС и ivi.ru расскажут про PU Learning и разберут принципы сортировки блоков с фильмами на главной странице IVI. После этого мы с Виктором Кантором и Пашей Мягких устроим панельную дискуссию про использование Data Science в разных сферах бизнеса.
Участие, бесплатное, регистрируйтесь по ссылке:
https://mts-digital.timepad.ru/event/1962458/
Ребята из МТС и ivi.ru расскажут про PU Learning и разберут принципы сортировки блоков с фильмами на главной странице IVI. После этого мы с Виктором Кантором и Пашей Мягких устроим панельную дискуссию про использование Data Science в разных сферах бизнеса.
Участие, бесплатное, регистрируйтесь по ссылке:
https://mts-digital.timepad.ru/event/1962458/
mts-digital.timepad.ru
ML MEETUP МТС Big Data #2 / События на TimePad.ru
МТС проведет онлайн-митап для дата-саентистов, дата-инженеров и специалистов, интересующихся машинным обучением
Все, кто так или иначе вовлечен в ML-проекты, неважно, в контексте обучения моделей, их деплоя, или построения ETL пайплайнов, найдут для себя…
Все, кто так или иначе вовлечен в ML-проекты, неважно, в контексте обучения моделей, их деплоя, или построения ETL пайплайнов, найдут для себя…
❤35👍13🔥7🤩3
Slack ODS (open data science) переводят на Free Plan.
Окончательно заявлять что это приведет к остановке существования нельзя, но чат на 60к с человек, где хранятся лишь последние 10к сообщений и нет мудрости прошлых веков, это совсем другой чат
С другой стороны, люди уже довольно успешно ругаются друг с другом в чате этого канала.
Импортозамещение
Upd. Слак не банит ОДС, до этого мы были на бесплатном режиме, теперь надо платить, сумма измеряется миллионами долларов в год
Окончательно заявлять что это приведет к остановке существования нельзя, но чат на 60к с человек, где хранятся лишь последние 10к сообщений и нет мудрости прошлых веков, это совсем другой чат
С другой стороны, люди уже довольно успешно ругаются друг с другом в чате этого канала.
Импортозамещение
Upd. Слак не банит ОДС, до этого мы были на бесплатном режиме, теперь надо платить, сумма измеряется миллионами долларов в год
😢233🤯27🤬15👍6😁5😱2❤1🔥1
Отправили вместе с @arsenyinfo из @partially_unsupervised оглавление книги Machine Learning System Design на ревью в издательство, ревью проводит N человек по M пунктам, один из ревьюеров удивил
Is the Table of Contents appropriate for the readers described in the proposal? What should be added or deleted to reflect this reader more accurately?
Yes, the TOC is quite versatile and covers a huge range of topics all important for data science projects. However, ML is normally considered much narrower: ML normaly refers to the learning algorithm alone, so a data science project could use ML (but has not to) but data science is usually considered a much broader field than ML. Now it confuses me a little that a book about ML systems covers things like data gathering and reporting as this is exactly what separates classical ML from data science.
Does this description match the reader you would expect to be interested in this topic? Why or why not?
Not really, as data scientists and software engineers are not the same roles and it is not clear to me who would profit the most. From the TOC and the title it is clear that the book mainly addresses software engineers, but data scientists (more than ML people) are the ones who really have to come up with ML systems, so I would expect data scientists to be the main target audience.
Is the title of the book appropriate to the subject?
I feel that the book is more about data science systems than ML systems as ML for me means mainly learning algorithms, so a book about ML is normally considered to deal with learning algorithms like supervised and unsupervised algorithms, and not about pipelines and data collection, model monitoring etc. An exception is MLOps, which deals exactly with how to operate ML solutions, but I feel that the title could be broader and should not necessarily contain ML at its core.
Много думал
Is the Table of Contents appropriate for the readers described in the proposal? What should be added or deleted to reflect this reader more accurately?
Yes, the TOC is quite versatile and covers a huge range of topics all important for data science projects. However, ML is normally considered much narrower: ML normaly refers to the learning algorithm alone, so a data science project could use ML (but has not to) but data science is usually considered a much broader field than ML. Now it confuses me a little that a book about ML systems covers things like data gathering and reporting as this is exactly what separates classical ML from data science.
Does this description match the reader you would expect to be interested in this topic? Why or why not?
Not really, as data scientists and software engineers are not the same roles and it is not clear to me who would profit the most. From the TOC and the title it is clear that the book mainly addresses software engineers, but data scientists (more than ML people) are the ones who really have to come up with ML systems, so I would expect data scientists to be the main target audience.
Is the title of the book appropriate to the subject?
I feel that the book is more about data science systems than ML systems as ML for me means mainly learning algorithms, so a book about ML is normally considered to deal with learning algorithms like supervised and unsupervised algorithms, and not about pipelines and data collection, model monitoring etc. An exception is MLOps, which deals exactly with how to operate ML solutions, but I feel that the title could be broader and should not necessarily contain ML at its core.
Много думал
👍31🤔26😁18🤬2❤1
Вышло видео с выступления, во время котрого меня пугали, поили энергетическими напитками, а затем пытались раслабить
И все это для того, чтобы замерить пульс
https://youtu.be/Ux81IqLuxco
И все это для того, чтобы замерить пульс
https://youtu.be/Ux81IqLuxco
YouTube
Валерий Бабушкин — Опыт компаний-гигантов в оценке разработчиков
Валерий работал в Facebook и расскажет про инженерные уровни в FAANG. Ты узнаешь как использовать системы оценок разработчиков в крупных, и что делать, если в твоей компании таких нет.
https://it-nights.ru/
https://it-nights.ru/
👍32😁5❤4👏2🔥1
Пришла пора послушать единственного человека @nizhib, успешно прошедшего собеседование
https://www.youtube.com/watch?v=iqbsHiSnZQE
https://www.youtube.com/watch?v=iqbsHiSnZQE
YouTube
System Design с Валерием Бабушкиным | Выпуск 3 | Собеседование | karpov.courses
Курс Hard ML https://karpov.courses/ml-hard
На каждое новое собеседование по System Design мы зовём всё более опытных специалистов.
В этот раз нашим гостем стал Евгений, тимлид команды ML в AliExpress Россия. Ему досталась одна из самых сложных, по словам…
На каждое новое собеседование по System Design мы зовём всё более опытных специалистов.
В этот раз нашим гостем стал Евгений, тимлид команды ML в AliExpress Россия. Ему досталась одна из самых сложных, по словам…
👍71🔥26👏2❤1
В среду ездил в University of Manchester - читал лекцию про Блокчейн как технологию и почему это компьютер и про Блокчейн как компанию и машинное обучение. Немного рассказал про машинное обучение в Блокчейне как компании
Прикладываю ссылку на запись, но предупреждаю, что это была зум запись с моего ноутбука
https://youtu.be/pqO7zapN5jY
На фото группа студентов организаторов
Прикладываю ссылку на запись, но предупреждаю, что это была зум запись с моего ноутбука
https://youtu.be/pqO7zapN5jY
На фото группа студентов организаторов
👍133🔥25❤7😁1
Продолжаем пост из серии как готовиться к интервью, совместно с @nizhib
Как готовиться к интервью по систем дизайну
Это довольно непривычная секция для людей, которые впервые сталкиваются с интервью в зарубежные компании уровня FAANG. Здесь не будут задавать много вопросов, чтобы разузнать что вы можете , а что не можете. Ограничатся всего одним открытым вопросом на проектирование конкретной системы (вроде ”спроектируйте Твиттер”) и будут ожидать от вас сольное выступление на 40 минут.
В самом начале стоит посмотреть видео по теме, выложенные на канале Karpov Courses (на сегодняшний день их пока только три, будут еще) и затем с другими видео по запросу “System Design Mock Interview”, чтобы иметь представление о том, что это вообще за жанр.
Затем узнайте, каким инструментом вы будете пользоваться при прохождении интервью или выберете любой, доступный онлайн, например тот же Фейсбук использует excalidraw.
Далее рекомендуем проходить курс Grokking the System Design Interview, при этом параллельно перенося краткую выжимку и схему в выбранный whiteboard.
После прохождения курса можно дополнительно ознакомиться с видео на канале codeKarle, где разбираются похожие примеры, при этом автор канала прибегает к более модульнуму и масштабируемому подходу, а также разбирает важный вопрос про выбор БД и интеграцию с аналитикой, ML и прочим — это все достаточно полезные детали и дополнения для выхода на уровень вплоть до E6.
Также материалы по систем дизайну можно найти и на гитхабе .
Для закрепления после пройденных уроков курса рекомендуется попробовать самим реализовать несколько дизайнов по отработанной схеме для других продуктов. Можете потом сравнить полученные прикидки и схему с теми, что получаются на схожих видео.
UPD. В комментариях говорят
Вот этот курс куда лучше чем грокинг https://courses.systeminterview.com/
#InterviewPreparation
Как готовиться к интервью по систем дизайну
Это довольно непривычная секция для людей, которые впервые сталкиваются с интервью в зарубежные компании уровня FAANG. Здесь не будут задавать много вопросов, чтобы разузнать что вы можете , а что не можете. Ограничатся всего одним открытым вопросом на проектирование конкретной системы (вроде ”спроектируйте Твиттер”) и будут ожидать от вас сольное выступление на 40 минут.
В самом начале стоит посмотреть видео по теме, выложенные на канале Karpov Courses (на сегодняшний день их пока только три, будут еще) и затем с другими видео по запросу “System Design Mock Interview”, чтобы иметь представление о том, что это вообще за жанр.
Затем узнайте, каким инструментом вы будете пользоваться при прохождении интервью или выберете любой, доступный онлайн, например тот же Фейсбук использует excalidraw.
Далее рекомендуем проходить курс Grokking the System Design Interview, при этом параллельно перенося краткую выжимку и схему в выбранный whiteboard.
После прохождения курса можно дополнительно ознакомиться с видео на канале codeKarle, где разбираются похожие примеры, при этом автор канала прибегает к более модульнуму и масштабируемому подходу, а также разбирает важный вопрос про выбор БД и интеграцию с аналитикой, ML и прочим — это все достаточно полезные детали и дополнения для выхода на уровень вплоть до E6.
Также материалы по систем дизайну можно найти и на гитхабе .
Для закрепления после пройденных уроков курса рекомендуется попробовать самим реализовать несколько дизайнов по отработанной схеме для других продуктов. Можете потом сравнить полученные прикидки и схему с теми, что получаются на схожих видео.
UPD. В комментариях говорят
Вот этот курс куда лучше чем грокинг https://courses.systeminterview.com/
#InterviewPreparation
www.educative.io
Grokking System Design Interview: Patterns & Mock Interviews
A modern approach to System Design Interviews. One course to master distributed systems and scalable architecture patterns. Practice with mock interviews. Built by FAANG engineers.
👍87🔥18❤1😁1
Недавно искал фотку для конференции
Вбил в поиск Валерий Бабушкин и перешел на картинки
Сделал так в двух поисковиках. Результаты показались весьма разными
Два мира - два Шапиро
Вбил в поиск Валерий Бабушкин и перешел на картинки
Сделал так в двух поисковиках. Результаты показались весьма разными
Два мира - два Шапиро
😁109👍5🔥4🤩2🎉1
Подъехало видео с одного из уроков Хард МЛ
Снижение дисперсии через стратификацию и Сuped
Обратите еще внимание на подробный разбор Cuped здесь
Кроме того ноутбук в видео не совсем корректный. Он корректно демонстрирует принцип, но применять такое в реальности нельзя - будет переобучение. Корректный ноутбук для прикладных задач - по ссылке к видео или здесь
Снижение дисперсии через стратификацию и Сuped
Обратите еще внимание на подробный разбор Cuped здесь
Кроме того ноутбук в видео не совсем корректный. Он корректно демонстрирует принцип, но применять такое в реальности нельзя - будет переобучение. Корректный ноутбук для прикладных задач - по ссылке к видео или здесь
YouTube
Снижение дисперсии через стратификацию Сuped | Валерий Бабушкин | Вводный урок | karpov.courses
Курс Hard ML: https://bit.ly/3JO9d9l
Если вы уже изучили весь доступный в наших соцсетях контент по курсу Hard ML, то советуем убедиться, что вы не забыли о вводном уроке от Валерия Бабушкина ;)
В нём разбирается снижение дисперсии через стратификацию CUPED…
Если вы уже изучили весь доступный в наших соцсетях контент по курсу Hard ML, то советуем убедиться, что вы не забыли о вводном уроке от Валерия Бабушкина ;)
В нём разбирается снижение дисперсии через стратификацию CUPED…
👍68🔥7❤3
No code/ low code платформы, в моих глазах, являются крупным надувательством и имеют очень специфичную область применения
Либо это очень ограниченный функционал. Либо это какой-то мутный язык программирования, который нужно выучить, чтобы говорить машине, что ты хочешь чтобы она сделала. Именно эту задачу решает язык программирования, библиотеки и фреймворки, и тогда здесь вообще практически нет отличий от нормального программирования.
Кроме вендор лока, бонусом
И отсутствием код ревью
И, зачастую, отсутствием нормального CI/CD
Либо это очень ограниченный функционал. Либо это какой-то мутный язык программирования, который нужно выучить, чтобы говорить машине, что ты хочешь чтобы она сделала. Именно эту задачу решает язык программирования, библиотеки и фреймворки, и тогда здесь вообще практически нет отличий от нормального программирования.
Кроме вендор лока, бонусом
И отсутствием код ревью
И, зачастую, отсутствием нормального CI/CD
👍99😁18👏7🤔4👎3
Компания где я работаю подняла немного денег
https://www.bloomberg.com/news/articles/2022-03-30/blockchain-com-in-talks-for-new-funding-at-14-billion-valuation
https://www.bloomberg.com/news/articles/2022-03-30/blockchain-com-in-talks-for-new-funding-at-14-billion-valuation
Bloomberg.com
Blockchain.com Raises New Funding at $14 Billion Valuation
Startup Blockchain.com said it raised new funding that values the company at about $14 billion, more than doubling its worth in a sign that cryptocurrency firms still enjoy the favor of investors in turbulent venture capital markets.
🔥124🤯19👍15👏4❤1😁1
Я много помогал ребятам из Алиэкспресса делать разные штуки.
Поиск, ценообразование, рекомендательные системы, антифрод, А/Б тесты, МММ, косвенно матчинг
Теперь они проводят Первый митап команды AliTech
Расскажут о том, как готовить данные и обучать алгоритмы, чтобы находить совпадения среди миллионов товаров (а на AliExpress их больше 2 млрд), разберут не только истории успеха, но и попытки, которые ни к чему не привели — на митапе команды AliTech 7 апреля, в 18:00.
В программе
— Как сделали матчер: тайтлы, берты и две сестры, Андрей Русланцев, AliExpress Россия
— Как не сделали матчер: тайтлы, чехлы и близнецы, Денис Ивашков, AliExpress Россия
— Prod2vec: три в одном! Объединяем всю информацию о товаре в один вектор, Александр Голубев, Ozon
— Прикладные задачи матчинга и способы оценки качества, Макар Красноперов, Яндекс.Маркет
— Q&A сессия о матчинге и не только!
Митап будет в 18:00 в четверг, 7 апреля, в новом офисе AliExpress в башне «Империя» в Сити — и в трансляции на YouTube. Регистрироваться тут (это обязательно)
Поиск, ценообразование, рекомендательные системы, антифрод, А/Б тесты, МММ, косвенно матчинг
Теперь они проводят Первый митап команды AliTech
Расскажут о том, как готовить данные и обучать алгоритмы, чтобы находить совпадения среди миллионов товаров (а на AliExpress их больше 2 млрд), разберут не только истории успеха, но и попытки, которые ни к чему не привели — на митапе команды AliTech 7 апреля, в 18:00.
В программе
— Как сделали матчер: тайтлы, берты и две сестры, Андрей Русланцев, AliExpress Россия
— Как не сделали матчер: тайтлы, чехлы и близнецы, Денис Ивашков, AliExpress Россия
— Prod2vec: три в одном! Объединяем всю информацию о товаре в один вектор, Александр Голубев, Ozon
— Прикладные задачи матчинга и способы оценки качества, Макар Красноперов, Яндекс.Маркет
— Q&A сессия о матчинге и не только!
Митап будет в 18:00 в четверг, 7 апреля, в новом офисе AliExpress в башне «Империя» в Сити — и в трансляции на YouTube. Регистрироваться тут (это обязательно)
alitech.timepad.ru
Встречаемся в «Империи»: ML митап AliTech / События на TimePad.ru
Поговорим о том, как готовить данные и обучать алгоритмы, чтобы находить совпадения среди миллионов товаров (а на AliExpress их более 2 млрд), причем разберем не только истории успешного успеха, но и попытки, которые ни к чему не привели — на первом митапе…
👍76🔥13❤1🤔1🤮1