Как реагировать на критические события
Хотел я вчера прервать сорокодневное молчание постом про 6 недель Стамбула, но решил перенести этот пост. Сегодня хочу подумать о том как человек реагирует на важные события, которые напрямую его касаются. Что делать и чего делать не стоит.
За последние полтора года таких событий было три. И все они происходили в начале двадцатых чисел месяца (может в нумерологи податься). Таймлайн развития всегда одинаковый: просыпаешься, новости о происходящем сами тебя находят, сначала смятение, потом шок/стресс/паника.
Вот ровно в тот момент, когда первый шок закончился, надо убирать всю панику в сторону и начинать соображать что же тебе делать, как реагировать на происходящее.
Реакция не должна строиться на фундаменте общего инфополя и всеобщей паники ! Действия должны строиться на основе твоих убеждений и стремлений. Эти штуки обычно не меняются в критические моменты.
После того как ты в слух проговорил что же для тебя в этой жизни важно, можно переходить к следующему шагу. Оценить какие риски в происходящем есть для тебя (risk analysis привет). Если ты можешь их оценить, значит можешь понять как их обойти или что делать при реализации риска.
В конечном итоге у тебя появится общий вектор твоего движения и набор возможных препятствий, с которыми ты знаешь что делать. А это - все что тебе нужно чтобы составить план действий. Не тот который ты прочитал в телеграм канале или услышал от знакомого, а свой собственный, продуманный, персональный.
Техническая рекомендация - при оценке рисков, всегда искать первоисточник любой информации. Нет первоисточника/не можешь найти, верифицируй информацию в нескольких местах, которым можешь доверять (быстрый старт в OSINT).
В общем как то так и прошел вчерашний день😕 Начавшись с нумерологии, через анализ рисков и закончен был немудреными osint практиками.
Have plan, stay informed, stay safe✌️ 🌏
P.S.: Пост про 6 недель Стамбула уже пишу !
#insight
Хотел я вчера прервать сорокодневное молчание постом про 6 недель Стамбула, но решил перенести этот пост. Сегодня хочу подумать о том как человек реагирует на важные события, которые напрямую его касаются. Что делать и чего делать не стоит.
За последние полтора года таких событий было три. И все они происходили в начале двадцатых чисел месяца (может в нумерологи податься). Таймлайн развития всегда одинаковый: просыпаешься, новости о происходящем сами тебя находят, сначала смятение, потом шок/стресс/паника.
Вот ровно в тот момент, когда первый шок закончился, надо убирать всю панику в сторону и начинать соображать что же тебе делать, как реагировать на происходящее.
Реакция не должна строиться на фундаменте общего инфополя и всеобщей паники ! Действия должны строиться на основе твоих убеждений и стремлений. Эти штуки обычно не меняются в критические моменты.
После того как ты в слух проговорил что же для тебя в этой жизни важно, можно переходить к следующему шагу. Оценить какие риски в происходящем есть для тебя (risk analysis привет). Если ты можешь их оценить, значит можешь понять как их обойти или что делать при реализации риска.
В конечном итоге у тебя появится общий вектор твоего движения и набор возможных препятствий, с которыми ты знаешь что делать. А это - все что тебе нужно чтобы составить план действий. Не тот который ты прочитал в телеграм канале или услышал от знакомого, а свой собственный, продуманный, персональный.
Техническая рекомендация - при оценке рисков, всегда искать первоисточник любой информации. Нет первоисточника/не можешь найти, верифицируй информацию в нескольких местах, которым можешь доверять (быстрый старт в OSINT).
В общем как то так и прошел вчерашний день
Have plan, stay informed, stay safe
P.S.: Пост про 6 недель Стамбула уже пишу !
#insight
Please open Telegram to view this post
VIEW IN TELEGRAM
⚡3
6 недель Стамбула
После четырех месяцев в Бишкеке я прилетел в Стамбул. Первая мысль была такая, я наконец то в мегаполисе ! То, чего очень не хватало - биг сити лайф, много людей, все куда-то бегут, до тебя нет никакого дела, а в воздухе висит атмосфера легкой спешки. Которая с грохотом рушится если посмотреть на ближайшее кафе, где локалы пью чай литрам и много курят.
Я жил в европейской части города, визуальна она похожа на что-то среднее между Прагой и черногорским Котором. Плотная застройка, невысокие разноцветные дома. В такой архитектре приятно гулять, чувствуешь себя соразмерным постройкам вокруг. Через каждые сто метров есть корнершоп, пекарня или висит флаг Турции. Приятное ощущение нейборхуда, которого не было в Бишкеке и которое очень редко попадается в Москве.
В этом городе хочется много ходить, потому что тебя везде окружает живая история. Начиная с дворца султанов 19 века, через усыпальницу величайшего османского пирата 16 века и заканчивая перестроенным православным храмом 5 века, который соседствует с одним из самых больших базаров в мире. И все это за одну воскресную прогулку. Единственный минус в том, что все прогулки либо вверх, либо вниз, по ровному можно ходить только на набережных.
Здесь у меня были самые длинные пробежки ! Вайб на пробежке такой, бежишь рядом с Босфором, смотришь на яхты и чаек, солнце, погода идеальная. Пробегаешь булочные и кофешопы, уютные парки и паромные порты. Потом питстоп на чай и бублик с нутеллой. Смотришь на часы и вот уже второй десяток километров подходит к концу, это значит пора заканчивать, идти за донером, опять пить чай и ехать домой. Сказка не иначе !
Уровень жизни тут достижим как и в любом другом мегаполисе. Можно найти все что понадобится и ещё немножко. Общественный транспорт работает идеально. Все привычные сервисы типа доставки или такси работают. Прайс на продукты, аренду и услуги московский. Удивлением были цены на алкоголь, они процентов на 30 выше чем я привык, что вино в супермаркете, что гинесс в баре.
Мысли последних дней были такие. Стамбул это очень интересный город с какой-то бесконечной историей, чтобы понять который нужно гораздо больше времени, чем потратил я. Город, в котором европейские лайфстайл смешивается с восточным пониманием жизни, а сверху присыпан легкой атмосферой киношности или сказочности. Много думал про историю российской эмиграции. И про то, что иметь всякие бытовые радости (+15 зимой, возможность купить новую модель беговых кроссовок или наличие икеи/декатлона) это приятно.
✈️
#travel
После четырех месяцев в Бишкеке я прилетел в Стамбул. Первая мысль была такая, я наконец то в мегаполисе ! То, чего очень не хватало - биг сити лайф, много людей, все куда-то бегут, до тебя нет никакого дела, а в воздухе висит атмосфера легкой спешки. Которая с грохотом рушится если посмотреть на ближайшее кафе, где локалы пью чай литрам и много курят.
Я жил в европейской части города, визуальна она похожа на что-то среднее между Прагой и черногорским Котором. Плотная застройка, невысокие разноцветные дома. В такой архитектре приятно гулять, чувствуешь себя соразмерным постройкам вокруг. Через каждые сто метров есть корнершоп, пекарня или висит флаг Турции. Приятное ощущение нейборхуда, которого не было в Бишкеке и которое очень редко попадается в Москве.
В этом городе хочется много ходить, потому что тебя везде окружает живая история. Начиная с дворца султанов 19 века, через усыпальницу величайшего османского пирата 16 века и заканчивая перестроенным православным храмом 5 века, который соседствует с одним из самых больших базаров в мире. И все это за одну воскресную прогулку. Единственный минус в том, что все прогулки либо вверх, либо вниз, по ровному можно ходить только на набережных.
Здесь у меня были самые длинные пробежки ! Вайб на пробежке такой, бежишь рядом с Босфором, смотришь на яхты и чаек, солнце, погода идеальная. Пробегаешь булочные и кофешопы, уютные парки и паромные порты. Потом питстоп на чай и бублик с нутеллой. Смотришь на часы и вот уже второй десяток километров подходит к концу, это значит пора заканчивать, идти за донером, опять пить чай и ехать домой. Сказка не иначе !
Уровень жизни тут достижим как и в любом другом мегаполисе. Можно найти все что понадобится и ещё немножко. Общественный транспорт работает идеально. Все привычные сервисы типа доставки или такси работают. Прайс на продукты, аренду и услуги московский. Удивлением были цены на алкоголь, они процентов на 30 выше чем я привык, что вино в супермаркете, что гинесс в баре.
Мысли последних дней были такие. Стамбул это очень интересный город с какой-то бесконечной историей, чтобы понять который нужно гораздо больше времени, чем потратил я. Город, в котором европейские лайфстайл смешивается с восточным пониманием жизни, а сверху присыпан легкой атмосферой киношности или сказочности. Много думал про историю российской эмиграции. И про то, что иметь всякие бытовые радости (+15 зимой, возможность купить новую модель беговых кроссовок или наличие икеи/декатлона) это приятно.
#travel
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6⚡2❤🔥1🔥1💯1
Безопасность докер контейнеров №2 🐳
Продолжают появляться знания про безопасность докера. В прошлой заметке писал про CVE уязвимости, которые находятся в базовых пайтон образах. Сегодня пишу про безопасность самого запускаемого контейнера.
Если сильно упрощать, то докер контейнер это своего рода виртуальная операционная система, изолированная от системы в которой контейнер запускается. Как и у любой ОС, в докер контейнере тоже есть пользователи, группы пользователей и разные права доступа к системе.
По умолчанию, контейнер запускается с root правами. Эти права позволяют контролировать все процессы запущенные в контейнере и иметь полный доступ ко всем файлам системы. С одной стороны это удобно, не надо думать над тем, как создавать файлы. Но с другой стороны это не очень безопасно, и вот почему.
Представим такой сценарий: злоумышленник получает доступ к контейнеру. Здесь конечно стоит оговориться, что контейнеры не запускают на голом сервере, скорее всего там будет какой-то оркестратор и другие уровни управления. Но все эти уровни, чаще всего, находятся не в ведении ML инженера или разработчика. Если же контейнер с рут правами, то в нем можно будет убить процесс, который запустил сервер или открыть порты или совершить ещё какую-нибудь пакость. Если же запустить корневой процесс контейнера от пользователь без прав администратора, то так сделать не получится.
Для того что бы запускать основной процесс юзером без прав надо добавить следующую инструкцию. Она добавит нового пользователя без рут прав:
Ещё хорошо бы убрать у системных исполняемых файлов возможность исполнения от имени владельца. Декодинг такой - находим все файлы с нужными разрешениями и убираем возможности установки битов доступа:
#dev
Продолжают появляться знания про безопасность докера. В прошлой заметке писал про CVE уязвимости, которые находятся в базовых пайтон образах. Сегодня пишу про безопасность самого запускаемого контейнера.
Если сильно упрощать, то докер контейнер это своего рода виртуальная операционная система, изолированная от системы в которой контейнер запускается. Как и у любой ОС, в докер контейнере тоже есть пользователи, группы пользователей и разные права доступа к системе.
По умолчанию, контейнер запускается с root правами. Эти права позволяют контролировать все процессы запущенные в контейнере и иметь полный доступ ко всем файлам системы. С одной стороны это удобно, не надо думать над тем, как создавать файлы. Но с другой стороны это не очень безопасно, и вот почему.
Представим такой сценарий: злоумышленник получает доступ к контейнеру. Здесь конечно стоит оговориться, что контейнеры не запускают на голом сервере, скорее всего там будет какой-то оркестратор и другие уровни управления. Но все эти уровни, чаще всего, находятся не в ведении ML инженера или разработчика. Если же контейнер с рут правами, то в нем можно будет убить процесс, который запустил сервер или открыть порты или совершить ещё какую-нибудь пакость. Если же запустить корневой процесс контейнера от пользователь без прав администратора, то так сделать не получится.
Для того что бы запускать основной процесс юзером без прав надо добавить следующую инструкцию. Она добавит нового пользователя без рут прав:
RUN addgroup --gid $GROUP_ID user && \В аргументы
adduser --disabled-password --gecos '' --uid $USER_ID --gid $GROUP_ID user
USER user
GROUP_ID и USER_ID надо передать номера группы и пользователя.Ещё хорошо бы убрать у системных исполняемых файлов возможность исполнения от имени владельца. Декодинг такой - находим все файлы с нужными разрешениями и убираем возможности установки битов доступа:
RUN find / -perm /6000 -type f -exec chmod a-s {} \; || true
Это все конечно выглядит не очень просто и понятно для человека, который не использует линукс. Но заботать базовые навыки сисадмина очень полезно, даже если ты занимаешься ML, а тем более разработкой. Эти навыки позволят писать более безопасные и тонко настраиваемые решения ✌🏻👨💻#dev
👍4⚡1
Персональные данные и личная безопасность 🥷🏻
Все, что касается персональных данных и, как следствие, личной безопасности кажется темой, которую можно обсуждать бесконечно. В прошлой заметке я писал про то, как юзают пользовательские данные правоохранители в штатах. Сегодня, пишу о том, как личные данные могут использовать силовики в РФ.
Причиной для написания поста стала статья в NY Times о том, как компании, аффилированные с российским гос сектором, научились анализировать зашифрованный трафик месенджеров. Нет, у них пока нет прямого доступа к чату, но понимать что именно (текст, картинки, голосовые сообщения или видоски) и кому ты отправляешь они уже могут. Очевидно, что если эти технологии есть у гос сектора, то ими могут пользоваться все правоохранительные структуры.
Казалось бы, новость конечно плохая, но не ужасная. Давай разовьем идею и подумаем, что же именно государство может о тебе понять, исходя из твоих данных. Начать надо с того, что в РФ есть СОРМ - система оперативно-розыскных мероприятий. Это комплекс софта и железок, которые собирают весь телефонный и интернет трафик. На хабре был хороший пост про то, как это работает.
Если есть доступ к веб трафику, можно его проанализировать и понять с кем ты общаешься и через какие каналы. Ещё из данных оператора можно вытащить где примерно ты находился и в какое время - частично понятны твои передвижения.
Вспомним новости про раздачу повесток в метро. И понимаем, что можно узнать где ты вошел и где вышел, а ещё связать твое лицо с личным делом в военкомате. Понятно, что система работает не очень хорошо, иначе таких повесток было бы очень много. Но идентификация лица и связь с гос базами (не только военкомат) уже есть. На этом этапе получаем карту твоих передвижений по городу.
Прочитаем ещё немного новостей и поймем что у ФСБ скоро будет доступ к базам данных аггрегаторов такси. А это опять же твои передвижения и способы их оплаты. Косвенно можно понять как часто и в каких барах ты тусуешься, куда ездишь на массаж и когда возвращаешься домой после ужина с родителями.
Я думаю логика тут понятна, любой цифровой след, который ты оставляешь может быть найден, сопоставлен с твоей личностью и проанализирован.
Единственный момент, который меня как то успокаивает так это то, что для государства очень сложно и дорого собирать всю эту информацию.
Из поста на хабре понятно, что весь софт пишется с багами, а качество данных, которые хранит оператор ужасное. Насколько я понимаю, сейчас нет сквозных интеграций по всем государственным базам данных. И весь сбор/анализ этого огромного количества информации производится почти что в ручную. Именно это позволяет иметь некоторый временной лаг, от начала слежки, до каких-то физических воздействий на человека.
Однако очевидно, что работы по автоматизации этого процесса ведутся, а нам остается только ждать когда они будут закончены. До глубины души надеюсь что это будет реализовано не скоро, если будет вообще !
Несмотря на всю мерзость и гадость сложившихся условий с ними можно и нужно бороться. Делать все, что бы твои данные принадлежали именно тебе, а не всем гос структурам страны. Тогда ты, как единица гражданского общества, будешь менее уязвим и более свободен. Расскажу как это можно сделать в следующих постах ✌🏻🌎
Stay anonymous, stay free, stay safe !
#security
Все, что касается персональных данных и, как следствие, личной безопасности кажется темой, которую можно обсуждать бесконечно. В прошлой заметке я писал про то, как юзают пользовательские данные правоохранители в штатах. Сегодня, пишу о том, как личные данные могут использовать силовики в РФ.
Причиной для написания поста стала статья в NY Times о том, как компании, аффилированные с российским гос сектором, научились анализировать зашифрованный трафик месенджеров. Нет, у них пока нет прямого доступа к чату, но понимать что именно (текст, картинки, голосовые сообщения или видоски) и кому ты отправляешь они уже могут. Очевидно, что если эти технологии есть у гос сектора, то ими могут пользоваться все правоохранительные структуры.
Казалось бы, новость конечно плохая, но не ужасная. Давай разовьем идею и подумаем, что же именно государство может о тебе понять, исходя из твоих данных. Начать надо с того, что в РФ есть СОРМ - система оперативно-розыскных мероприятий. Это комплекс софта и железок, которые собирают весь телефонный и интернет трафик. На хабре был хороший пост про то, как это работает.
Если есть доступ к веб трафику, можно его проанализировать и понять с кем ты общаешься и через какие каналы. Ещё из данных оператора можно вытащить где примерно ты находился и в какое время - частично понятны твои передвижения.
Вспомним новости про раздачу повесток в метро. И понимаем, что можно узнать где ты вошел и где вышел, а ещё связать твое лицо с личным делом в военкомате. Понятно, что система работает не очень хорошо, иначе таких повесток было бы очень много. Но идентификация лица и связь с гос базами (не только военкомат) уже есть. На этом этапе получаем карту твоих передвижений по городу.
Прочитаем ещё немного новостей и поймем что у ФСБ скоро будет доступ к базам данных аггрегаторов такси. А это опять же твои передвижения и способы их оплаты. Косвенно можно понять как часто и в каких барах ты тусуешься, куда ездишь на массаж и когда возвращаешься домой после ужина с родителями.
Я думаю логика тут понятна, любой цифровой след, который ты оставляешь может быть найден, сопоставлен с твоей личностью и проанализирован.
Единственный момент, который меня как то успокаивает так это то, что для государства очень сложно и дорого собирать всю эту информацию.
Из поста на хабре понятно, что весь софт пишется с багами, а качество данных, которые хранит оператор ужасное. Насколько я понимаю, сейчас нет сквозных интеграций по всем государственным базам данных. И весь сбор/анализ этого огромного количества информации производится почти что в ручную. Именно это позволяет иметь некоторый временной лаг, от начала слежки, до каких-то физических воздействий на человека.
Однако очевидно, что работы по автоматизации этого процесса ведутся, а нам остается только ждать когда они будут закончены. До глубины души надеюсь что это будет реализовано не скоро, если будет вообще !
Несмотря на всю мерзость и гадость сложившихся условий с ними можно и нужно бороться. Делать все, что бы твои данные принадлежали именно тебе, а не всем гос структурам страны. Тогда ты, как единица гражданского общества, будешь менее уязвим и более свободен. Расскажу как это можно сделать в следующих постах ✌🏻🌎
Stay anonymous, stay free, stay safe !
#security
👍5👏1🤔1🐳1🍾1
Масштабирование продукта 📈
Недавно разговаривал с инженером, который обеспечивает отказоустойчивость инфраструктуры для процессинга платежей. В конце диалога пришел к довольно интересному инсайту.
Диалог у нас строился вокруг того, как можно понять, что продукт или прототип успешен на ранней стадии. Идея в следующем, если твое решение может окупить начальные вложения, в виде покупки железок, а после выйти на ежемесячную окупаемость потребляемых ресурсов, то это хороший знак (хороший, но не достаточный для успеха). После этого, уже можно думать над тем, как расти дальше. Если решение не выходит на полную окупаемость, то ты что-то делаешь не так и бизнеса из этого не выйдет.
Меня немного удивила история с покупкой железок. Я был уверен, что сейчас никто ничего не покупает, за исключением больших игроков и компаний специализирующихся на облачных вычислениях. Хотя, я думаю, что тут можно просто прикинуть нагрузки и посчитать сколько выйдет покупка + месячное содержание своего железа и аренда подходящих ресурсов. И выбрать более дешевый вариант.
Теперь про инсайт. Инфраструктурное масштабирование продукта это супер важный скилл. Потому что качество продукта определяется, в том числе, удовлетворенностью пользователей. Если при резком увеличении нагрузки будет увеличено время ответа, появится нестабильная работа или невозможность использования фичей, это все приведет к недовольству пользователей. Недовольные пользователи увеличивают отток. Большой отток, сложнее зарабатывать деньги. Невозможность быть прибыльным ведет продукт сначала к стагнации, а потом к смерти.
Думаю, что на этапе тестирования гипотезы продукта или обкатки прототипа этот навык может и не пригодиться. Но вот когда все гипотезы подтверждены и начинается приток пользователей, вот тут тебе точно надо понимать как ты будешь масштабировать свое решение !
P.S.: И если с сервисами типа AWS, GCP, Azure примерно понятно что делать при росте нагрузок. То как быть со своими железками - не очень. Покупка своих ресурсов требует точного и долгосрочного планирования, которое кажется редко достижимым в стартап среде
#startup #dev
Недавно разговаривал с инженером, который обеспечивает отказоустойчивость инфраструктуры для процессинга платежей. В конце диалога пришел к довольно интересному инсайту.
Диалог у нас строился вокруг того, как можно понять, что продукт или прототип успешен на ранней стадии. Идея в следующем, если твое решение может окупить начальные вложения, в виде покупки железок, а после выйти на ежемесячную окупаемость потребляемых ресурсов, то это хороший знак (хороший, но не достаточный для успеха). После этого, уже можно думать над тем, как расти дальше. Если решение не выходит на полную окупаемость, то ты что-то делаешь не так и бизнеса из этого не выйдет.
Меня немного удивила история с покупкой железок. Я был уверен, что сейчас никто ничего не покупает, за исключением больших игроков и компаний специализирующихся на облачных вычислениях. Хотя, я думаю, что тут можно просто прикинуть нагрузки и посчитать сколько выйдет покупка + месячное содержание своего железа и аренда подходящих ресурсов. И выбрать более дешевый вариант.
Теперь про инсайт. Инфраструктурное масштабирование продукта это супер важный скилл. Потому что качество продукта определяется, в том числе, удовлетворенностью пользователей. Если при резком увеличении нагрузки будет увеличено время ответа, появится нестабильная работа или невозможность использования фичей, это все приведет к недовольству пользователей. Недовольные пользователи увеличивают отток. Большой отток, сложнее зарабатывать деньги. Невозможность быть прибыльным ведет продукт сначала к стагнации, а потом к смерти.
Думаю, что на этапе тестирования гипотезы продукта или обкатки прототипа этот навык может и не пригодиться. Но вот когда все гипотезы подтверждены и начинается приток пользователей, вот тут тебе точно надо понимать как ты будешь масштабировать свое решение !
P.S.: И если с сервисами типа AWS, GCP, Azure примерно понятно что делать при росте нагрузок. То как быть со своими железками - не очень. Покупка своих ресурсов требует точного и долгосрочного планирования, которое кажется редко достижимым в стартап среде
#startup #dev
👍3🔥1
Как создавать продукт ?
Вообще я думаю что создание продуктов это самая интересная часть айти. Когда ты можешь придумать и разработать что-то, что будет нести ценность для пользователей и решать их задачи.
Строго говоря, сам процесс понимания потребностей пользователя и создания нужного продукта кажется мне более интересным и важным чем, например, обучение и файнтюн новой сеточки, чтобы прибавить пару процентов точности к бейзлайну.
К сожалению, у меня нет профессиональных навыков в этой области. Поэтому, я стараюсь брать знания во всех подходящих источниках, например startupschool.org, gopractice.ru, блог Вани Замесина и релевантные каналы в ТГ. Про классику типа Lean Startup, From zero to one, The Startup: owners manual я молчу.
Один из таких каналов, про стартапы и управление продуктом - Надежда и опора продуктового подхода. Он довольно камерный, с интересными постами, кароче говоря он мне нравится. Его ведет Надежда и в эту субботу, 12 августа, она будет читать лекцию "Как создавать продукты". В адженде заявлены классные темы, в которые мне хочется погрузиться глубже. Бонусом она будет разбирать некоторые кейсы !
Мне интересна тема митапа и важно, чтобы мою идею разобрал человек, который работает с продуктами. А ещё мне кажется важным делиться полезными вещами в своем канале, так что это win-win-win для нас всех.
Ниже сам анонс мероприятия:
Лекция «Как создавать продукты»
💡 С чего начать, когда есть много разных идей?
🔍 Как проводить исследования и тестировать гипотезы?
🚀 Как создавать продукт без страха провала?
🕓 12 августа, в 16:00 (мск), онлайн.
Инвайт ссылка:
https://t.iss.one/+u5Db6Yrnzw8yMDky
P.S.: Как можно заметить, я пока ищу ответ на вопрос из заголовка🤭
Вообще я думаю что создание продуктов это самая интересная часть айти. Когда ты можешь придумать и разработать что-то, что будет нести ценность для пользователей и решать их задачи.
Строго говоря, сам процесс понимания потребностей пользователя и создания нужного продукта кажется мне более интересным и важным чем, например, обучение и файнтюн новой сеточки, чтобы прибавить пару процентов точности к бейзлайну.
К сожалению, у меня нет профессиональных навыков в этой области. Поэтому, я стараюсь брать знания во всех подходящих источниках, например startupschool.org, gopractice.ru, блог Вани Замесина и релевантные каналы в ТГ. Про классику типа Lean Startup, From zero to one, The Startup: owners manual я молчу.
Один из таких каналов, про стартапы и управление продуктом - Надежда и опора продуктового подхода. Он довольно камерный, с интересными постами, кароче говоря он мне нравится. Его ведет Надежда и в эту субботу, 12 августа, она будет читать лекцию "Как создавать продукты". В адженде заявлены классные темы, в которые мне хочется погрузиться глубже. Бонусом она будет разбирать некоторые кейсы !
Мне интересна тема митапа и важно, чтобы мою идею разобрал человек, который работает с продуктами. А ещё мне кажется важным делиться полезными вещами в своем канале, так что это win-win-win для нас всех.
Ниже сам анонс мероприятия:
Лекция «Как создавать продукты»
💡 С чего начать, когда есть много разных идей?
🔍 Как проводить исследования и тестировать гипотезы?
🚀 Как создавать продукт без страха провала?
🕓 12 августа, в 16:00 (мск), онлайн.
Инвайт ссылка:
https://t.iss.one/+u5Db6Yrnzw8yMDky
P.S.: Как можно заметить, я пока ищу ответ на вопрос из заголовка
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4🤔2❤🔥1🔥1
Спроси маму
Дочитал книгу Роба Фитцпатрика - Спроси маму. Небольшая и очень интересная книга о том, как проверять свои бизнес идеи. Мне её рекомендовали знакомые продакты. А ещё, когда то давно, ее рекомендовали менторы из ФРИИ в своем стартап-акселераторе.
Книга маленькая, всего 150 страниц. Текст несложный и главы небольшие по объему. Пару раз встречался с такой историей - большая часть главы описывает одну тему, а в конце, парочка абзацев совсем про другое. И это другое гораздо интереснее чем основная часть. Общую канву это никак не нарушает, даже становится интереснее читать. Очень много живых примеров, благодаря которым можно понять, что имел ввиду автор, когда описывал теоретическую часть.
Книга объясняет как именно задавать вопросы так, чтобы понять, имеет ли твоя идея шанс на жизнь или нет. Объясняет как уходить от предвзятости собеседника, как отделять важные вопросы от неважных, почему формализм в общении это плохо и даже как технически выделять сегменты в целевой аудитории своего продукта. Упрощая, книга про то, как проверить актуальность бизнес идеи на этапе, когда кроме идеи у тебя ничего ещё нет.
Я подозреваю, что это нельзя назвать фундаментальным трудом, да и книгой, в полном понимании, я бы тоже это не назвал. Это больше похоже на методичку, в которой хранится набор правил и подходов для тестирования идей. Методичку крепко сдобренную примерами и объяснениями на любой вкус.
Мне, как человеку, не работающему в области продуктологии, материал понравилась. Огромное количество полезной и новой информации, формата бери и применяй прямо сейчас. Причем изложенные концепции можно испольовать не только в продуктовой работе, но и в своей каждодневной жизни. Кароче говоря, книгу могу рекомендовать всем, кто хочет делать свой стартап или кто уже сейчас работает с продуктом.
#book
Дочитал книгу Роба Фитцпатрика - Спроси маму. Небольшая и очень интересная книга о том, как проверять свои бизнес идеи. Мне её рекомендовали знакомые продакты. А ещё, когда то давно, ее рекомендовали менторы из ФРИИ в своем стартап-акселераторе.
Книга маленькая, всего 150 страниц. Текст несложный и главы небольшие по объему. Пару раз встречался с такой историей - большая часть главы описывает одну тему, а в конце, парочка абзацев совсем про другое. И это другое гораздо интереснее чем основная часть. Общую канву это никак не нарушает, даже становится интереснее читать. Очень много живых примеров, благодаря которым можно понять, что имел ввиду автор, когда описывал теоретическую часть.
Книга объясняет как именно задавать вопросы так, чтобы понять, имеет ли твоя идея шанс на жизнь или нет. Объясняет как уходить от предвзятости собеседника, как отделять важные вопросы от неважных, почему формализм в общении это плохо и даже как технически выделять сегменты в целевой аудитории своего продукта. Упрощая, книга про то, как проверить актуальность бизнес идеи на этапе, когда кроме идеи у тебя ничего ещё нет.
Я подозреваю, что это нельзя назвать фундаментальным трудом, да и книгой, в полном понимании, я бы тоже это не назвал. Это больше похоже на методичку, в которой хранится набор правил и подходов для тестирования идей. Методичку крепко сдобренную примерами и объяснениями на любой вкус.
Мне, как человеку, не работающему в области продуктологии, материал понравилась. Огромное количество полезной и новой информации, формата бери и применяй прямо сейчас. Причем изложенные концепции можно испольовать не только в продуктовой работе, но и в своей каждодневной жизни. Кароче говоря, книгу могу рекомендовать всем, кто хочет делать свой стартап или кто уже сейчас работает с продуктом.
#book
👍4🤔1
10 перелетов за 12 месяцев
За последний год у меня было 10 перелетов. Это гораздо больше чем в прошлые года. И как то само собой вышло, что под конец, у меня появились некоторые правила, которые помогли мне экономить время и летать с большим комфортом.
Начну с багажа. Нет ничего более удобного чем пластиковый чемодан на колесиках с ручкой. Да, я имею ввиду такие яркие твердые чемоданы, которые удобно возить за собой. Они отлично подходят почти для всех типов поездок. Их не надо тащить на себе, в них удобно упаковывать одежду и в случае необходимости можно быстро найти, потерянную в недрах, вещь.
Количество багажа. Если вещей совсем мало, а поездка короткая, достаточно будет обычно рюкзака. Если же поездка чуть длиннее, то я беру маленький чемодан и рюкзак. А если надо срочно релоцироваться в другую страну, то возьму большой чемодан вместе с маленьким и не забуду рюкзак. За этот год ни одна авиакомпания не просила доплатить за второе место ручной клади.
В рюкзаке удобно носить почти всю электронику, которая у тебя есть, а ещё документы и зарядки. С рюкзаком у меня связано одно правило - перед прохождением предполетного досмотра я убираю все железно-электрические вещи в рюкзак. Тогда, перед рамкой металлоискателя, мне надо просто положить рюкзак на ленту и пройти. Это быстро, удобно и редко вызывает вопросы у службы безопасности.
Если я лечу с чемоданом в ручной клади, то скорее всего в нем будут лежать кроксы ! Кроксы надеваются после сдачи багажа и снимаются, зачастую, уже в отеле. Я не буду говорить что это самая удобная обувь в мире. Просто скажу, что полеты в кроксах на порядок удобнее полетов в любой другой обуви.
Ну и напоследок остается напомнить следующее. Люди с детьми все делают дольше обычного. На паспортном контроле паспорт отдавайте без обложки. Место у прохода самое комфортное. Выходить на посадку лучше раньше, а не позже - не придется искать место для ручной клади. Две воды лучше одного сока. Да, бортпроводник может принести ещё попить. А наушники с шумоподавлением и худи это минимальный набор для комфортного сна на борту.
✈️
#travel
За последний год у меня было 10 перелетов. Это гораздо больше чем в прошлые года. И как то само собой вышло, что под конец, у меня появились некоторые правила, которые помогли мне экономить время и летать с большим комфортом.
Начну с багажа. Нет ничего более удобного чем пластиковый чемодан на колесиках с ручкой. Да, я имею ввиду такие яркие твердые чемоданы, которые удобно возить за собой. Они отлично подходят почти для всех типов поездок. Их не надо тащить на себе, в них удобно упаковывать одежду и в случае необходимости можно быстро найти, потерянную в недрах, вещь.
Количество багажа. Если вещей совсем мало, а поездка короткая, достаточно будет обычно рюкзака. Если же поездка чуть длиннее, то я беру маленький чемодан и рюкзак. А если надо срочно релоцироваться в другую страну, то возьму большой чемодан вместе с маленьким и не забуду рюкзак. За этот год ни одна авиакомпания не просила доплатить за второе место ручной клади.
В рюкзаке удобно носить почти всю электронику, которая у тебя есть, а ещё документы и зарядки. С рюкзаком у меня связано одно правило - перед прохождением предполетного досмотра я убираю все железно-электрические вещи в рюкзак. Тогда, перед рамкой металлоискателя, мне надо просто положить рюкзак на ленту и пройти. Это быстро, удобно и редко вызывает вопросы у службы безопасности.
Если я лечу с чемоданом в ручной клади, то скорее всего в нем будут лежать кроксы ! Кроксы надеваются после сдачи багажа и снимаются, зачастую, уже в отеле. Я не буду говорить что это самая удобная обувь в мире. Просто скажу, что полеты в кроксах на порядок удобнее полетов в любой другой обуви.
Ну и напоследок остается напомнить следующее. Люди с детьми все делают дольше обычного. На паспортном контроле паспорт отдавайте без обложки. Место у прохода самое комфортное. Выходить на посадку лучше раньше, а не позже - не придется искать место для ручной клади. Две воды лучше одного сока. Да, бортпроводник может принести ещё попить. А наушники с шумоподавлением и худи это минимальный набор для комфортного сна на борту.
#travel
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥4🔥2👍1🐳1
Логи сервиса 👩💻
Один раз я потратил 4 часа времени, чтобы понять почему сервис с моей моделью падал при некоторых запросах. В самом начале все казалось просто - взять запрос, обрушивший сервис, отправить в сервис запущенный локально и в дебагере посмотреть где проблема. Но я бы не стал писать этот пост, если бы все было так просто))
Оказалось, что мой сервис не логировал входящие запросы. Строчка о том, что запрос пришел была. Но строки с полным текстом запроса не было ! В сервисе, который отправлял запросы, было всего 4 лог лайна на весь код🤯 Так что из него достать тоже ничего не получалось.
Это я все к тому, что самый дешевый и простой шаг в сторону наличия нормальной наблюдаемости твоего сервиса это логи ! У тебя может не быть сервисных метрик, может не быть красивого трейсинга. Но если твой сервис запускается не у тебя на ноутбуке и им пользуется кто-то кроме тебя, то логи в нем быть просто обязаны !
К добавлению логирования не стоит относиться как к единоразовой задаче. Лог это часть сервиса и он будет развиваться вместе с его функциональностью. Количество эндпоинтов и интеграций будет увеличиваться, а размер запросов расти. Поскольку лог должен отражать все, что происходит с сервисом, его придется дорабатывать. Строго говоря, если лог продуман хорошо, то по нему можно понять состояние сервиса в любой момент времени.
В стандартной библиотеке питона есть модуль
Все очень просто, чтобы добавить логер с нужным форматом, нужно удалить уже существующий, и добавить новый, с подходящими настройками. Из интересного - можно сразу сделать структурированные логи (каждая строчка это json со всеми необходимыми параметрами):
P.S.: А если хочешь больше узнать про наблюдаемость сервисов, вот подходящая заметка
#dev
Один раз я потратил 4 часа времени, чтобы понять почему сервис с моей моделью падал при некоторых запросах. В самом начале все казалось просто - взять запрос, обрушивший сервис, отправить в сервис запущенный локально и в дебагере посмотреть где проблема. Но я бы не стал писать этот пост, если бы все было так просто))
Оказалось, что мой сервис не логировал входящие запросы. Строчка о том, что запрос пришел была. Но строки с полным текстом запроса не было ! В сервисе, который отправлял запросы, было всего 4 лог лайна на весь код
Это я все к тому, что самый дешевый и простой шаг в сторону наличия нормальной наблюдаемости твоего сервиса это логи ! У тебя может не быть сервисных метрик, может не быть красивого трейсинга. Но если твой сервис запускается не у тебя на ноутбуке и им пользуется кто-то кроме тебя, то логи в нем быть просто обязаны !
К добавлению логирования не стоит относиться как к единоразовой задаче. Лог это часть сервиса и он будет развиваться вместе с его функциональностью. Количество эндпоинтов и интеграций будет увеличиваться, а размер запросов расти. Поскольку лог должен отражать все, что происходит с сервисом, его придется дорабатывать. Строго говоря, если лог продуман хорошо, то по нему можно понять состояние сервиса в любой момент времени.
В стандартной библиотеке питона есть модуль
logging, но честно говоря, он мне не очень нравится. Очень нравится мне пакет loguru, который позволяет в 3 строки сделать удобный логер с нужным форматом, несколькими уровнями серьезности и разноцветными (!!!) сообщениями.Все очень просто, чтобы добавить логер с нужным форматом, нужно удалить уже существующий, и добавить новый, с подходящими настройками. Из интересного - можно сразу сделать структурированные логи (каждая строчка это json со всеми необходимыми параметрами):
from loguru import logger
logger.remove()
logger.add(sys.stdout, serialize=False, format=LOG_FORMAT)
Если по какой-то причине вам надо сохранять логи локально, то можно очень просто настроить компрессию и ротацию логов в файле, для этого:logger.add("local.log", rotation="1 week", compression="tar.gz")
Вывод тут только один - не забивай на логи, добавить логлайн это быстро, просто и совсем не больно. Потом сохранишь кучу времени !P.S.: А если хочешь больше узнать про наблюдаемость сервисов, вот подходящая заметка
#dev
Please open Telegram to view this post
VIEW IN TELEGRAM
⚡2🔥1🤔1🐳1
Build Public 🛠
Предыстория. Месяц назад начал проходить курс по ML System Design. Основная цель курса, это научиться строить сложные системы, которые решают проблемы пользователей с помощью машинного обучения. Вишенка курса - проект, который надо делать в командах, а в конце будет защита перед лекторами и другими командами.
Вместе с этим, прикоснулся к движухе indie hacking. В ней очень популярна идея build public. Это когда ты делаешь свой проект и параллельно рассказываешь про свои удачи/проблемы/достижения. Кто-то делает лайв кодинг на стриме, кто-то пишет апдейты в твитере. Форма тут не важна, важно что ты погружаешь аудиторию в текущее состояние проекта. Эта идея кажется мне очень крутой. Крутой, потому, что ты делишься опытом, потому что можешь получить фидбек от более экспертных людей по своим решениям или проблемам. А еще потому, что это мотивирует тебя не забивать на свое детище, даже если все идет не по плану.
Основная часть. Так вот, на этом курсе я лидирую проект. Мы в команде решили, что будем делать приложение, которое позволяет оценивать эмоциональную окраску новостей фондового рынка. Про то, почему выбрали именно такую тему, расскажу потом. Сейчас хочу рассказать про организацию работы в команде.
Мы стараемся работать асинхронно и в аджайл стиле. По классике, каждый рабочий отрезок команды строится по схеме PDCA. Именно в следствии этой схемы существует: планирование + работа с бэклогом, дейли митинги для уточнение состояния, ретро + демо в конце спринта и четкие итоги встреч/экшен планы.
Это все круто и хорошо работает в компаниях где есть много менеджеров. Но как быть, когда ты делаешь сайд проект в свободное время и просто ставить задачи нельзя ? Надо становиться гибче и делать больший упор на мотивацию команды.
В нашем случае эта схема мутировала в следующее: мы работаем по недельным спринтам, у нас нет дейли, но есть демо. Демо совмещено с планированием и проводится раз в спринт. Планирование крупными мазками, на уровне фичей или эпиков. Более детальное формирование требований происходит асинхронно в гугл доках. Очень помогают коментарии. Если кому-то, что-то не понятно разговариваем тет-а-тет и делаем так, чтобы стало понятно.
Какие технологии мы используем ? База это чат в тележке. Таск трекер - trello, удобно смотреть кто чем занят. Архитектуру обсуждаем в miro, в ней же брейнштормим. Собираем требования и описываем фичи в гугл доках (помним про комменты). Созвоны в гуглмит. Код, понятное дело, держим в гите, где каждый ковыряет свои фичи в отдельных ветках.
Мне очень интересно работать над этим проектом ! Хочется писать про это часто, потому что нахожу очень (!!!) много нового для себя. Нового, в построении процессов, менеджменте, разработке, архитектуре и технологиях. Следуя идеи buld public всю эту кучу новой информации буду делить на связные блоки и постить сюда.
Stay tuned✌️ Build public, build open 🌎
P.S.: Fast forward ⏩ сейчас состояние такое - выкатили пре-альфа версию в паблик. Смотрим как работает, собираем баги и набиваем шишки
#buildpublic #dev
Предыстория. Месяц назад начал проходить курс по ML System Design. Основная цель курса, это научиться строить сложные системы, которые решают проблемы пользователей с помощью машинного обучения. Вишенка курса - проект, который надо делать в командах, а в конце будет защита перед лекторами и другими командами.
Вместе с этим, прикоснулся к движухе indie hacking. В ней очень популярна идея build public. Это когда ты делаешь свой проект и параллельно рассказываешь про свои удачи/проблемы/достижения. Кто-то делает лайв кодинг на стриме, кто-то пишет апдейты в твитере. Форма тут не важна, важно что ты погружаешь аудиторию в текущее состояние проекта. Эта идея кажется мне очень крутой. Крутой, потому, что ты делишься опытом, потому что можешь получить фидбек от более экспертных людей по своим решениям или проблемам. А еще потому, что это мотивирует тебя не забивать на свое детище, даже если все идет не по плану.
Основная часть. Так вот, на этом курсе я лидирую проект. Мы в команде решили, что будем делать приложение, которое позволяет оценивать эмоциональную окраску новостей фондового рынка. Про то, почему выбрали именно такую тему, расскажу потом. Сейчас хочу рассказать про организацию работы в команде.
Мы стараемся работать асинхронно и в аджайл стиле. По классике, каждый рабочий отрезок команды строится по схеме PDCA. Именно в следствии этой схемы существует: планирование + работа с бэклогом, дейли митинги для уточнение состояния, ретро + демо в конце спринта и четкие итоги встреч/экшен планы.
Это все круто и хорошо работает в компаниях где есть много менеджеров. Но как быть, когда ты делаешь сайд проект в свободное время и просто ставить задачи нельзя ? Надо становиться гибче и делать больший упор на мотивацию команды.
В нашем случае эта схема мутировала в следующее: мы работаем по недельным спринтам, у нас нет дейли, но есть демо. Демо совмещено с планированием и проводится раз в спринт. Планирование крупными мазками, на уровне фичей или эпиков. Более детальное формирование требований происходит асинхронно в гугл доках. Очень помогают коментарии. Если кому-то, что-то не понятно разговариваем тет-а-тет и делаем так, чтобы стало понятно.
Какие технологии мы используем ? База это чат в тележке. Таск трекер - trello, удобно смотреть кто чем занят. Архитектуру обсуждаем в miro, в ней же брейнштормим. Собираем требования и описываем фичи в гугл доках (помним про комменты). Созвоны в гуглмит. Код, понятное дело, держим в гите, где каждый ковыряет свои фичи в отдельных ветках.
Мне очень интересно работать над этим проектом ! Хочется писать про это часто, потому что нахожу очень (!!!) много нового для себя. Нового, в построении процессов, менеджменте, разработке, архитектуре и технологиях. Следуя идеи buld public всю эту кучу новой информации буду делить на связные блоки и постить сюда.
Stay tuned
P.S.: Fast forward ⏩ сейчас состояние такое - выкатили пре-альфа версию в паблик. Смотрим как работает, собираем баги и набиваем шишки
#buildpublic #dev
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🐳6
NewsBuddy E01
Прошло два спринта с предыдущего поста про build public. Наш проект продвинулся вперед, а наша команда немного уменьшилась. И, конечно же, появилась куча интересных выводов в разных областях! Начну с более высокоуровневых.
Процессы. Процессы бесконечно важны. В самом начале, со стороны это было совсем не очевидно. Но если их не настроить, то управление командой превратится в сущий ад на земле ! Сейчас для меня самым сложным является декомпозиция глобального видения продукта на фичи, а фичи на таски, там где это необходимо.
Работа над архитектурой проекта. На это прям уходит время, когда я сажусь и думаю как реализовать какую-то функциональность. Например, какие фичи и в какие компоненты надо добавить, чтобы на фронте появилось две новые строчки. Забивать и делать как пришло в голову нельзя. Потому что архитектура, в каком то смысле определяет целевое состояние проекта.
Взаимодействие компонентов. Как следствие добавления новых фичей - меняются контракты сервисов. А хотелось бы их менять не очень часто, потому что это лишние траты времени и мотивации команды. Поэтому надо скрупулезнее подходить к проектированию межсервисного взаимодействия. И, опять же, это отнимает часть времени.
Я не случайно написал выше про мотивацию команды. В групповых пет-проектах это очень важный аспект (который не настолько значим в рамках обычных рабочих проектов, кмк) ! Надо понимать, когда речь заходит о таких проектах, мало кто хочет разбираться в устройстве сетевого взаимодействия docker контейнеров или же как настроить nginx в качестве reversed proxy. Чаще всего, все хотят писать прикольный пайтон код, который делает все за две строчки))
Итогом этих двух недель стал следующий вывод. Тимлид это не тот, кто пишет больше всех продакшен кода и даже не тот, кто лучше всех понимает какую-то технологию. Тимлид это тот, кто может в системный анализ проекта. Тот, кто понимает, как должна выглядеть целевая архитектура проекта. И наконец тот, кто может настроить процессы в команде. Кароче говоря, это такой jack of all trades, master of none в рамках проекта. Что меня, честно говоря, и устраивает.
P.S.: Кстати полная фраза такая - A jack of all trades is a master of none, but often times better than a master of one. В таком виде мне нравится даже больше !
P.P.S.: NewsBuddy это название нашего проекта, E01 типа первый эпизод, как в сериалах
#buildpublic #insight #dev
Прошло два спринта с предыдущего поста про build public. Наш проект продвинулся вперед, а наша команда немного уменьшилась. И, конечно же, появилась куча интересных выводов в разных областях! Начну с более высокоуровневых.
Процессы. Процессы бесконечно важны. В самом начале, со стороны это было совсем не очевидно. Но если их не настроить, то управление командой превратится в сущий ад на земле ! Сейчас для меня самым сложным является декомпозиция глобального видения продукта на фичи, а фичи на таски, там где это необходимо.
Работа над архитектурой проекта. На это прям уходит время, когда я сажусь и думаю как реализовать какую-то функциональность. Например, какие фичи и в какие компоненты надо добавить, чтобы на фронте появилось две новые строчки. Забивать и делать как пришло в голову нельзя. Потому что архитектура, в каком то смысле определяет целевое состояние проекта.
Взаимодействие компонентов. Как следствие добавления новых фичей - меняются контракты сервисов. А хотелось бы их менять не очень часто, потому что это лишние траты времени и мотивации команды. Поэтому надо скрупулезнее подходить к проектированию межсервисного взаимодействия. И, опять же, это отнимает часть времени.
Я не случайно написал выше про мотивацию команды. В групповых пет-проектах это очень важный аспект (который не настолько значим в рамках обычных рабочих проектов, кмк) ! Надо понимать, когда речь заходит о таких проектах, мало кто хочет разбираться в устройстве сетевого взаимодействия docker контейнеров или же как настроить nginx в качестве reversed proxy. Чаще всего, все хотят писать прикольный пайтон код, который делает все за две строчки))
Итогом этих двух недель стал следующий вывод. Тимлид это не тот, кто пишет больше всех продакшен кода и даже не тот, кто лучше всех понимает какую-то технологию. Тимлид это тот, кто может в системный анализ проекта. Тот, кто понимает, как должна выглядеть целевая архитектура проекта. И наконец тот, кто может настроить процессы в команде. Кароче говоря, это такой jack of all trades, master of none в рамках проекта. Что меня, честно говоря, и устраивает.
P.S.: Кстати полная фраза такая - A jack of all trades is a master of none, but often times better than a master of one. В таком виде мне нравится даже больше !
P.P.S.: NewsBuddy это название нашего проекта, E01 типа первый эпизод, как в сериалах
#buildpublic #insight #dev
👍3
NewsBuddy E02
В прошлой заметке делился своими выводами про выстраивание процессов в проекте. Сегодня хочу рассказать про архитектуру и технологии.
В самом первом эпизоде я писал что основная наша фича это уметь определять эмоцию новости по её заголовку. Задача в целом понятная и уже решенная. Так что проект у нас скорее про создание системы вокруг этой задачи. Хочется, конечно, назвать это продуктивизацией, но язык не поворачивается так сказать (базовое понимание управления продуктом и понимание стартапа не дает).
С учетом того, что проект этот в рамках курса по ML System Design, мы решили сфокусироваться на интересной нам функциональности и технологиях, а не на продуктовом подходе.
Итак, что мы сейчас умеем. Определять эмоцию введенного юзером текста и собирать новости по критериям пользователя + делать эмоциональный скоринг. По сути это две фичи но суть у них одна.
Новости мы не парсим, а берем из готового api - AlphaVantage. Есть отдельный сервис, который дергает этот апи. Ответы от api сохраняет или в базу или отправляет на скоринг в модель. Сейчас добавляем оркестратор, чтобы регулярно собирать новости, скорить их и хранить новость + скор в БД.
Модель используем готовую с HuggingFace. Для сервинга тоже сервис с одной ручкой predict, который по сути проксирует запрос на HuggingFace. Из интересного это обработка ответов от HF. Например иногда HF может отдавать сообщение о том, что модель пока не готова к запросам. Фиксится это или теплым стартом сервиса с моделью (при старте, отправить прогревочный запрос на HF, чтобы модель загрузилась) или научиться локально хранить модель в рамказ процесса сервиса (работаем над этим).
Новости храним в БДшке. По канону микросервисной архитектуры есть DB manager, по сути, точка вход в БД. Реализует CRUD операции. Больше ничего интересного он не делает.
Пользовательский интерфейс - очень простой. Всего 3 странички - интро сервиса, окно для пользовательского ввода текста и набор настроек для сбора пользовательского пула новостей.
Что по стеку, спросишь ты ? А я тебе отвечу, что все стандартно:
- Сервисы на FastApi, все обернуто в docker
- База данных Postgres
- Оркестрация Prefect (вот это наверное не очень стандартно)
- UI написан на Streamlit
- Деплой на стенд через общий docker-compose + Nginx reversed_proxy
- API построено по REST, валидация запросов pydantic
Ниже картинка с наглядной архитектурой. Единственное но, это брокер сообщений между менеджером API и сервисом модели. Пока не реализован и я не уверен что он там нужен. Идея в том, что бы скорить новости не on-request от пользователя, а в фоне и класть в БД.
#buildpublic #dev
В прошлой заметке делился своими выводами про выстраивание процессов в проекте. Сегодня хочу рассказать про архитектуру и технологии.
В самом первом эпизоде я писал что основная наша фича это уметь определять эмоцию новости по её заголовку. Задача в целом понятная и уже решенная. Так что проект у нас скорее про создание системы вокруг этой задачи. Хочется, конечно, назвать это продуктивизацией, но язык не поворачивается так сказать (базовое понимание управления продуктом и понимание стартапа не дает).
С учетом того, что проект этот в рамках курса по ML System Design, мы решили сфокусироваться на интересной нам функциональности и технологиях, а не на продуктовом подходе.
Итак, что мы сейчас умеем. Определять эмоцию введенного юзером текста и собирать новости по критериям пользователя + делать эмоциональный скоринг. По сути это две фичи но суть у них одна.
Новости мы не парсим, а берем из готового api - AlphaVantage. Есть отдельный сервис, который дергает этот апи. Ответы от api сохраняет или в базу или отправляет на скоринг в модель. Сейчас добавляем оркестратор, чтобы регулярно собирать новости, скорить их и хранить новость + скор в БД.
Модель используем готовую с HuggingFace. Для сервинга тоже сервис с одной ручкой predict, который по сути проксирует запрос на HuggingFace. Из интересного это обработка ответов от HF. Например иногда HF может отдавать сообщение о том, что модель пока не готова к запросам. Фиксится это или теплым стартом сервиса с моделью (при старте, отправить прогревочный запрос на HF, чтобы модель загрузилась) или научиться локально хранить модель в рамказ процесса сервиса (работаем над этим).
Новости храним в БДшке. По канону микросервисной архитектуры есть DB manager, по сути, точка вход в БД. Реализует CRUD операции. Больше ничего интересного он не делает.
Пользовательский интерфейс - очень простой. Всего 3 странички - интро сервиса, окно для пользовательского ввода текста и набор настроек для сбора пользовательского пула новостей.
Что по стеку, спросишь ты ? А я тебе отвечу, что все стандартно:
- Сервисы на FastApi, все обернуто в docker
- База данных Postgres
- Оркестрация Prefect (вот это наверное не очень стандартно)
- UI написан на Streamlit
- Деплой на стенд через общий docker-compose + Nginx reversed_proxy
- API построено по REST, валидация запросов pydantic
Ниже картинка с наглядной архитектурой. Единственное но, это брокер сообщений между менеджером API и сервисом модели. Пока не реализован и я не уверен что он там нужен. Идея в том, что бы скорить новости не on-request от пользователя, а в фоне и класть в БД.
#buildpublic #dev
👍3🐳1
Плейлист v4
Давно не было обновления плейлиста. В этот раз собрал пачку треков под которые работаю в последнее время. Там не только электроника, есть акустические треки и даже немного эмбиента.
Из интересного могу отметить:
😇 Weightless by Marconi Union. Есть исследование, которое показывает что прослушивание этого трека снижает тревожность на 65%
🦍 Antonio Montana by Gorilla Zippo. Диджей трека никто иной как Василий Вакуленко, он же Баста, он же Ноггано
🇳🇴 Osuga by Djuma Soundsystem. Клевое норвежское аптемпо, в которм угадывается мелодия из песни Ева, группы Винтаж
Приятного прослушивания !
Как всегда, неизменная ссылка: https://music.yandex.ru/users/o.maverick/playlists/1003
P.S.: За 3 генерации этого плейлиста на нем собралось целых 5 лайков. Цифра не большая, но приятная, не думал что там кто-то будет жать на ❤️ !
#sounds
Давно не было обновления плейлиста. В этот раз собрал пачку треков под которые работаю в последнее время. Там не только электроника, есть акустические треки и даже немного эмбиента.
Из интересного могу отметить:
Приятного прослушивания !
Как всегда, неизменная ссылка: https://music.yandex.ru/users/o.maverick/playlists/1003
P.S.: За 3 генерации этого плейлиста на нем собралось целых 5 лайков. Цифра не большая, но приятная, не думал что там кто-то будет жать на ❤️ !
#sounds
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥4
Селф-хост паранойя 🥵
В одном из первых постов я объяснял, почему селф хост решение это хорошая идея. Но селф хост бывает разным: когда ты физически обладаешь своим hardware и когда не обладаешь.
В случае аренды железа примерно понятны какие есть риски. Например, тебя могут заблокировать или засаспендить. До недавнего времени, мне казалось это самым большим риском, пока я не прочитал вот этот отчет.
Что произошло ? Есть один из самых первых российских jabber серверов - jabber.ru, он же xmpp.ru. Его админы арендуют инстансы у Hetzner и Linode, это старые и уважаемые (по крайней мере были, до этого события) провайдеры инфраструктуры.
При регулярном чекапе сервера, админ jabber.ru замечает что просрочен TLS сертификат. Кажется обычное дело, но после поверхностной проверки, все сертификаты сервера оказываются свежие. Кароче не буду затягивать, и пересказывать пост (прочитай, там реально инетесно !), вот что произошло.
Предположительно владелец инфраструктуры подменил TLS сертификаты в инстансе и добавил прокси между jabber сервером и выходом в сеть. Причем все подмены были сделаны за 17 секунд, когда сеть одного из инстансов мигнула, судя по логам.
Это значит, что весь зашифрованный трафик, генерируемый сервером jabber.ru был скомпрометирован. Потому, что доступ к трафику обеспечивается наличием прокси по схеме man-in-the-middle. Вместе с этим, у злоумышленника есть сертификат для шифрования пакетов, значит он может их расшифровать. Иначе говоря у владельца атаки есть доступ ко всему контенту jabber.ru с момента начала атаки и до ее деактивации.
Тут хочется придумать какое-то простое решение, формата делай вот так и все будет ок. Но, это не очень просто, потому, что атаковали сервис владельцы инфраструктуры. Это примерно так же, как если бы ты покупал яблоки на рынке, ел их, болел не зная причины, а потом узнал, что они были отравлены продавцом.
Решение покупать нужное железо под каждый проект, продукт, бизнес, конечно хорошее, но работать не будет. Не у всех есть кэш на такие штуки, не говоря уже про ресурсы для эксплуатации.
Думаю что лучшее глобальное решение - меньше доверять большим корпоративным структурам (государствам/правительствам в том числе, кстати). А локальное - стараться понимать как функционирует твой проект/продукт/бизнес на, как можно более низком, уровне.
P.S.: Реально советую прочитать отчет об этой атаке. Там довольно интересные подробности: какой был вектор атаки и как удалось понять в чем проблема. Ссылка: https://notes.valdikss.org.ru/jabber.ru-mitm
#security
В одном из первых постов я объяснял, почему селф хост решение это хорошая идея. Но селф хост бывает разным: когда ты физически обладаешь своим hardware и когда не обладаешь.
В случае аренды железа примерно понятны какие есть риски. Например, тебя могут заблокировать или засаспендить. До недавнего времени, мне казалось это самым большим риском, пока я не прочитал вот этот отчет.
Что произошло ? Есть один из самых первых российских jabber серверов - jabber.ru, он же xmpp.ru. Его админы арендуют инстансы у Hetzner и Linode, это старые и уважаемые (по крайней мере были, до этого события) провайдеры инфраструктуры.
При регулярном чекапе сервера, админ jabber.ru замечает что просрочен TLS сертификат. Кажется обычное дело, но после поверхностной проверки, все сертификаты сервера оказываются свежие. Кароче не буду затягивать, и пересказывать пост (прочитай, там реально инетесно !), вот что произошло.
Предположительно владелец инфраструктуры подменил TLS сертификаты в инстансе и добавил прокси между jabber сервером и выходом в сеть. Причем все подмены были сделаны за 17 секунд, когда сеть одного из инстансов мигнула, судя по логам.
Это значит, что весь зашифрованный трафик, генерируемый сервером jabber.ru был скомпрометирован. Потому, что доступ к трафику обеспечивается наличием прокси по схеме man-in-the-middle. Вместе с этим, у злоумышленника есть сертификат для шифрования пакетов, значит он может их расшифровать. Иначе говоря у владельца атаки есть доступ ко всему контенту jabber.ru с момента начала атаки и до ее деактивации.
Тут хочется придумать какое-то простое решение, формата делай вот так и все будет ок. Но, это не очень просто, потому, что атаковали сервис владельцы инфраструктуры. Это примерно так же, как если бы ты покупал яблоки на рынке, ел их, болел не зная причины, а потом узнал, что они были отравлены продавцом.
Решение покупать нужное железо под каждый проект, продукт, бизнес, конечно хорошее, но работать не будет. Не у всех есть кэш на такие штуки, не говоря уже про ресурсы для эксплуатации.
Думаю что лучшее глобальное решение - меньше доверять большим корпоративным структурам (государствам/правительствам в том числе, кстати). А локальное - стараться понимать как функционирует твой проект/продукт/бизнес на, как можно более низком, уровне.
P.S.: Реально советую прочитать отчет об этой атаке. Там довольно интересные подробности: какой был вектор атаки и как удалось понять в чем проблема. Ссылка: https://notes.valdikss.org.ru/jabber.ru-mitm
#security
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4🐳1💯1
Бизнес без MBA
Довольно давно услышал про эту книгу от самого автора, Олега Тинькова. Он говорил, что в этой книге есть все, чтобы ты понял как начать свой дело.
В целом он прав, эта книга не про радужную мотивацию, и не про то, что у тебя точно все получится. Это скорее методичка, в которой описаны основные механика и инструменты традиционного бизнеса.
Рассказывается про то, что такое юнит экономика, зачем нужен платежный календарь, есть немного про переговоры, маркетинг и продажи. Даже есть юридический минимум: ИП или ООО, как выводить деньги, почему надо платить налоги. А в конце, набор интересных механик, как и где брать деньги, как работать с партнером, когда ликвидировать бизнес и как можно из него выйти.
Как и в любой методичке, тут чувствуется очень много ссылок на более полные и глубокие материалы. Например глава про переговоры, это выжимка из книги Джима Кэмпа - "Сначала скажите нет" (считается классической книгой про искусство ведения переговоров). В части про клиентов и продукт, я заметил частичку "Спроси маму" из недавнего поста. Блок про маркетинг, это скорее всего дистилляция Филипа Котлера или Игоря Манна.
Сама книга небольшая, всего 200 страниц. Главы хорошо структурированы, все очень четко и понятно. В момент чтения, появляется ощущение, что ты сидишь со старшим товарищем, у которого много опыта, и он отвечает на твои новичковые вопросы. Развернуто, но не вводя ненужных деталей. А заканчивает он свой спитч, напоминанием, что такие знания должны быть практическими, а не книжными.
Резюмируя, могу сказать, что это хорошая прикладная книга. Если у тебя есть точно сформулированные вопросы про бизнес, то ты найдешь здесь ответы. Вместе с этим, это обзорный материал, а не глубокое погружение. Так что после нее придется много пробовать и читать более узкую литературу.
#book
Довольно давно услышал про эту книгу от самого автора, Олега Тинькова. Он говорил, что в этой книге есть все, чтобы ты понял как начать свой дело.
В целом он прав, эта книга не про радужную мотивацию, и не про то, что у тебя точно все получится. Это скорее методичка, в которой описаны основные механика и инструменты традиционного бизнеса.
Рассказывается про то, что такое юнит экономика, зачем нужен платежный календарь, есть немного про переговоры, маркетинг и продажи. Даже есть юридический минимум: ИП или ООО, как выводить деньги, почему надо платить налоги. А в конце, набор интересных механик, как и где брать деньги, как работать с партнером, когда ликвидировать бизнес и как можно из него выйти.
Как и в любой методичке, тут чувствуется очень много ссылок на более полные и глубокие материалы. Например глава про переговоры, это выжимка из книги Джима Кэмпа - "Сначала скажите нет" (считается классической книгой про искусство ведения переговоров). В части про клиентов и продукт, я заметил частичку "Спроси маму" из недавнего поста. Блок про маркетинг, это скорее всего дистилляция Филипа Котлера или Игоря Манна.
Сама книга небольшая, всего 200 страниц. Главы хорошо структурированы, все очень четко и понятно. В момент чтения, появляется ощущение, что ты сидишь со старшим товарищем, у которого много опыта, и он отвечает на твои новичковые вопросы. Развернуто, но не вводя ненужных деталей. А заканчивает он свой спитч, напоминанием, что такие знания должны быть практическими, а не книжными.
Резюмируя, могу сказать, что это хорошая прикладная книга. Если у тебя есть точно сформулированные вопросы про бизнес, то ты найдешь здесь ответы. Вместе с этим, это обзорный материал, а не глубокое погружение. Так что после нее придется много пробовать и читать более узкую литературу.
#book
❤🔥3👍1💯1
Как стать тимлидом 🧐
Недавно писал про тимлидство и про то, что это не такая уж и тривиальная позиция. За прошедший месяц успел пройти курс на тему, как стать тимлидом. Сегодня хочу поделиться выводами и полезными материалыми.
Думаю, что все управление командой состоит из двух частей. Это софтскильная часть и хардскильная. Первая, как это не странно, гораздо сложнее и более объемна. Под софтскиллами понимаю - ведение переговоров, выстраивание процессов и коммуникации в команде, в некотором смысле, управление продуктом, так же найм сотрудников. Хардскиллы это архитектура, управление кодом проекта и детали некоторых софтскиллов (например, как проводить глубинное интервью или что такое LTV и как его посчитать).
Начнем с переговоров. Это бесконечно важная и, пожалуй, самая сложная часть. Не стоит сужать переговоры до встреч с business people. Переговоры это про любые межличностные взаимодействия как внутри команды, так и за её предлеами. Основные инструменты, которые помогут стать крутым переговорщиком это книга "Сначала скажите нет" - Джима Кэмпа (про нее, кстати, говорилось в книге "Бизнес без МВА"). И психотерапия, как это не странно, потому что очень важно понимать мотивацию как свою так и своего оппонента.
Выстраивание процессов. Это более формализованная область и есть готовые фреймворки. Например цикл PDCA (Plan-Do-Check-Act). Идея такая, надо уметь планировать задачи и декомпозировать их, контролировать выполнение и подводить итоги. Стоит понимать, что чем с более взрослыми, в профессиональном смысле, людьми ты работаешь, тем меньше контролирующих процессов необходимо. Второй пункт - прозрачность это лучший контроль. Основной материал - стратегия ФФФ от бюро Горбунова и любой материал по типовым процессам в команде.
Управление продуктом. Строго говоря, обычно есть отдельный человек, который занимается только принятием продуктовых решений, это PM. Но он есть не всегда, а даже когда он есть, хорошо бы понимать почему он принимает определенные решения. Это довольно большой блок знаний, который можно разделить так. Надо уметь понимать потребности пользователей, надо уметь считать экономику продукта, надо понимать механику метрик продукта и точно надо уметь говорить с людьми от бизнеса. Материалы здесь следующие: книга "Спроси маму" - Роберт Фитцпатрик, лекции Startup School от YC, материалы от GoPractice.
Архитектура и управление кодом. Эти две штуки в одном абзаце, потому что с ними проще всего. Архитектура твоего проекта строится на основе собранных требований и продуктового видения. Под управлением кодом стоит понимать менеджмент техдолга и поддержание приятного developer experience.
Вывод такой - курс крутой, помогает расставить реперные точки на роадмапе своего развития. Готовых знаний не дает, скорее говорит в какую сторону надо смотреть.
P.S.: Уже начал читать "Сначала скажите нет", как никак в двух местах ее рекомендуют, значит стоит того
#dev #insight
Недавно писал про тимлидство и про то, что это не такая уж и тривиальная позиция. За прошедший месяц успел пройти курс на тему, как стать тимлидом. Сегодня хочу поделиться выводами и полезными материалыми.
Думаю, что все управление командой состоит из двух частей. Это софтскильная часть и хардскильная. Первая, как это не странно, гораздо сложнее и более объемна. Под софтскиллами понимаю - ведение переговоров, выстраивание процессов и коммуникации в команде, в некотором смысле, управление продуктом, так же найм сотрудников. Хардскиллы это архитектура, управление кодом проекта и детали некоторых софтскиллов (например, как проводить глубинное интервью или что такое LTV и как его посчитать).
Начнем с переговоров. Это бесконечно важная и, пожалуй, самая сложная часть. Не стоит сужать переговоры до встреч с business people. Переговоры это про любые межличностные взаимодействия как внутри команды, так и за её предлеами. Основные инструменты, которые помогут стать крутым переговорщиком это книга "Сначала скажите нет" - Джима Кэмпа (про нее, кстати, говорилось в книге "Бизнес без МВА"). И психотерапия, как это не странно, потому что очень важно понимать мотивацию как свою так и своего оппонента.
Выстраивание процессов. Это более формализованная область и есть готовые фреймворки. Например цикл PDCA (Plan-Do-Check-Act). Идея такая, надо уметь планировать задачи и декомпозировать их, контролировать выполнение и подводить итоги. Стоит понимать, что чем с более взрослыми, в профессиональном смысле, людьми ты работаешь, тем меньше контролирующих процессов необходимо. Второй пункт - прозрачность это лучший контроль. Основной материал - стратегия ФФФ от бюро Горбунова и любой материал по типовым процессам в команде.
Управление продуктом. Строго говоря, обычно есть отдельный человек, который занимается только принятием продуктовых решений, это PM. Но он есть не всегда, а даже когда он есть, хорошо бы понимать почему он принимает определенные решения. Это довольно большой блок знаний, который можно разделить так. Надо уметь понимать потребности пользователей, надо уметь считать экономику продукта, надо понимать механику метрик продукта и точно надо уметь говорить с людьми от бизнеса. Материалы здесь следующие: книга "Спроси маму" - Роберт Фитцпатрик, лекции Startup School от YC, материалы от GoPractice.
Архитектура и управление кодом. Эти две штуки в одном абзаце, потому что с ними проще всего. Архитектура твоего проекта строится на основе собранных требований и продуктового видения. Под управлением кодом стоит понимать менеджмент техдолга и поддержание приятного developer experience.
Вывод такой - курс крутой, помогает расставить реперные точки на роадмапе своего развития. Готовых знаний не дает, скорее говорит в какую сторону надо смотреть.
P.S.: Уже начал читать "Сначала скажите нет", как никак в двух местах ее рекомендуют, значит стоит того
#dev #insight
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3🐳1💯1
Качественный код == личная эффективность
Вчера на работе рассказывал про качество кода и наблюдаемость пайтон проектов. Было интересно выступать не в рамках своей DS команды, а в рамках всей компании. Были люди из других отделов и в конце получилась довольно интересная дискуссия.
Преза была не технической, а скорее филосовско-разговорной. Ценность видел в том, чтобы ребята начали смотреть на качество проекта как на то, от чего зависит их личная эффективность. Собственно все технические детали невозможно уложить в один часовой рассказ, по этому про технику говорил мало.
Почему я считаю, что чем качественнее проект, тем эффективнее команда ? Все просто, чем выше качество проекта, тем больше внимания люди тратят на разработку нужной функциональности. Грязный, плохо структурированный, неэффективный и нестандартизированный код сложно поддерживать, расширять и дебажить. Любая простая задача становится тяжелой и неприятной, потому что приходится заново разбираться и вспоминать что же происходит в таком коде.
С другой стороны, если твой код написан по правилам, есть документация, понятно разложена функциональность, есть тесты, качественные логи и, не дай бог, трейсинг, то с ним довольно просто работать. Онбординг в такой проект происходит быстро и безболезненно со всех сторон. Любая таска по расширению функционала не вызывает проблем, а дебаг занимает считанные минуты !
Уверен, что хорошая наблюдаемость в проекте только умножает его качество. Потому, что становится доступна понятная визуализация работы кода (трейсинг), фиксируются ключевые состояния сервиса (логи) и собирается информация о эффективности решения (метрики).
Вообще все такие доклады это про развитие инженерной культуры. Мне кажется, что это супер важная вещь, за которую нужно прямо бороться. Без культуры разработки далеко не уедешь. А стать 10x engineer вообще не получится !
P.S.: про важность логов писал вот тут ещё
#dev
👁🫦👁
Вчера на работе рассказывал про качество кода и наблюдаемость пайтон проектов. Было интересно выступать не в рамках своей DS команды, а в рамках всей компании. Были люди из других отделов и в конце получилась довольно интересная дискуссия.
Преза была не технической, а скорее филосовско-разговорной. Ценность видел в том, чтобы ребята начали смотреть на качество проекта как на то, от чего зависит их личная эффективность. Собственно все технические детали невозможно уложить в один часовой рассказ, по этому про технику говорил мало.
Почему я считаю, что чем качественнее проект, тем эффективнее команда ? Все просто, чем выше качество проекта, тем больше внимания люди тратят на разработку нужной функциональности. Грязный, плохо структурированный, неэффективный и нестандартизированный код сложно поддерживать, расширять и дебажить. Любая простая задача становится тяжелой и неприятной, потому что приходится заново разбираться и вспоминать что же происходит в таком коде.
С другой стороны, если твой код написан по правилам, есть документация, понятно разложена функциональность, есть тесты, качественные логи и, не дай бог, трейсинг, то с ним довольно просто работать. Онбординг в такой проект происходит быстро и безболезненно со всех сторон. Любая таска по расширению функционала не вызывает проблем, а дебаг занимает считанные минуты !
Уверен, что хорошая наблюдаемость в проекте только умножает его качество. Потому, что становится доступна понятная визуализация работы кода (трейсинг), фиксируются ключевые состояния сервиса (логи) и собирается информация о эффективности решения (метрики).
Вообще все такие доклады это про развитие инженерной культуры. Мне кажется, что это супер важная вещь, за которую нужно прямо бороться. Без культуры разработки далеко не уедешь. А стать 10x engineer вообще не получится !
P.S.: про важность логов писал вот тут ещё
#dev
👁🫦👁
❤🔥5👍1🐳1