Отчет про коленный стул.
Прошло чуть больше двух недель. Итоги:
1. Самое главное. У меня перестала болеть поясница! Это ура!
2. Когда я хочу долго сидеть, не вставая (например, когда играю во что-то), то я использую обычный стул. Пока не могу дольше часа просидеть на коленном.
3. Через час сидения спина устает. Очень хочется расслабиться, сменить положение. Я могу походить, полежать на диванчике. В общем, стимулирует к переключению.
4. Мое тело нашло лайфак, чтобы избегать пункта 3 и совместить с любимой привычкой - задирать ноги. Теперь я иногда просто подбираю под себя коленки, ставя лапки на перекладину, сижу как на жердочке (как в курятнике) только с упором под жопку)

О покупке не пожалела, стулом пользуюсь, надеюсь все же привыкнуть сидеть на нем постоянно. #Tools

Пост про выгорание в первую очередь с точки зрения менеджерского опыта.

Друг меня попросил книжек на этот счет, но я не могу вспомнить конкретной литературы, я написала просто набор идей, собранных за свой опыт и попыток решить эту проблему для себя.

Поделитесь тоже, кто как справляется с выгоранием. Интересно почитать.

https://telegra.ph/Vygoraniya-post-05-14 #Работа

На этой неделе прошла вступительные тесты в Школу 21 https://21-school.ru/
Давно мечтала снова побыть студенткой. У них интересный формат обучения, все бесплатно, при этом крутой кампус.
Теперь, чтобы поступить в школу, нужно пройти "бассейн". Из того, что я знаю, на бассейне дают задания на C, время на выполнение ограничено. Бассейн длится 4 недели без выходных.
Я записалась на 7 июня в Москве.
По возможности буду писать сюда о впечатлениях.
Надеюсь, что мне будет не очень сложно, так как все ж немного трогала С, когда проходила курсы cs50, ну, и в программировании уже ненулевая.
Знала бы раньше про эту школу, вписалась бы еще в прошлом году. Хех. #Учеба

Школа 21.
День 1. Температура после прививки. Я порывалась поехать, но не осилила. Провалялась весь день в постели.
День 2. Утром меня отпустило, поехала. Накосячила с системой везде, где только можно было. Случайно сдала пустую работу, не зарегистрировалась вовремя на следующую работу. Начинается все с shell и git. Инфра не нравится. Документация вся в видео. Хочу текст(
Завтра по ходу буду пересдавать первую работу, проверять чьи-то?) #Учеба

Давно сюда не писала. Но хочу поделиться ботом, которого перенесла на свой бекенд сегодня, @s_channel_bot.
Это бот, который позволяет отслеживать наиболее популярные посты в каналах.
Изначально он был собран другим человеком через простенький скрипт. Я перенесла этот функционал на свой бекенд проекта Noctua.
Пришлось много поплакать над библиотекой telethon, чтобы добиться адекватного сохранения данных о просмотрах и репостах постов. Нет, на самом деле это не великая проблема, но когда поток сообщений высокий, аккаунтов больше, чем 1, начинаются пляски с бубном.
Жаль, что тележка не предоставляет возможность работать с чужими каналами через бота, и приходится так выворачиваться.
К слову, кто не в курсе, бота нельзя добавить в канал обычным смертным, только админом. Поэтому, чтобы получать сообщения из каналов, приходится заводить пользователей и добавляться в канал как пользователь через кастомный клиент тележки как раз с помощью библиотеки telethon.

Недавно осознала, что перестала бояться незнакомого для меня функционала, новых библиотек и так далее. Вообще перестала так бояться и стрессовать при выкатах и разработке. Все можно порешать, со всем можно разобраться. Если раньше конкретно нервничала, когда что-то шло не так или я не знала как это делать, то сейчас... Ахаха, могу просто залипнуть над решением и орать, если меня отвлекают. Орать. Потому что не трогайте меня, когда я сосредоточена. Нет, большую часть времени я расслабленно что-то делаю, но если я погрузиласть в поток, то не трогайте меня, я не хочу есть/чай/ничего, дайте дописать код спокойно)

На счет нового и интересного функционала, с которым столкнулась. Надо ж поделиться полезным:
1. https://docs.python.org/3/library/textwrap.html встроенная библиотека для того, чтобы разделять текст на нужные по размеру куски. Та же тележка имеет ограничение на объем сообщения. Раньше я ручками писала функции, чтобы резать тексты до нужного объема, но оказывается есть вот такая штука. Удобно.
2. https://docs.python.org/3/library/difflib.html. Мне периодически нужен нечеткий поиск. Недавно я вообще столкнулась с задачей, где в таблице есть список людей, у который в фамилиях есть спецсимволы (ну там немцы, чехи, кто-то там еще со своими умлаутами или как их там). А нужен простенький скрипт, который будет искать нужных людей по фамилии. И вот как быть с этими умлаутами? Короче, эта библиотека - мое спасение. Она сравнивает строки и оценивает их "похожесть", что дает возможность найти нужную фамилию. Работает примерно так:
запрос - caceres
1. A. Cáceres | Совпадение = 0.7058823529411765
2. A. Calver | Совпадение = 0.5
3. L. Cacace | Совпадение = 0.5
4. J. Cabrera | Совпадение = 0.47058823529411764
5. C. Armiento | Совпадение = 0.4444444444444444

matcher = SequenceMatcher(lambda x: x in " .", name.lower(), query.lower())
matcher.ratio() #Совпадение

Если интересно, то алгоритм описан https://en.wikipedia.org/wiki/Gestalt_Pattern_Matching

Всем удачи и спасибо, что вы со мной! ^_^ #Python, #Tools, #Работа

Про REST.

https://ru.wikipedia.org/wiki/REST
https://medium.com/@andr.ivas12/rest-%D0%BF%D1%80%D0%BE%D1%81%D1%82%D1%8B%D0%BC-%D1%8F%D0%B7%D1%8B%D0%BA%D0%BE%D0%BC-90a0bca0bc78

Как-то даже не гуглила про REST, так как была уверена, что знаю о чем это. Но когда загуглила, поняла, что надо разобраться. Кстати, некоторые моменты было проще понять в англоязычной википедии. На русском языке какие-то странные формулировки...

- Клиент-сервер. Разделяем разработку и работу приложений на фронтенд и бекенд. Когда у тебя бекенд не парится на счет клиента, а занимается только данными (принимает, отдает, изменяет, обрабатывает). А фронтенд (клиент) отвечает за все взаимодействие с пользователем (интерактив и тд и тп).
- Отсутствие состояния. Бекенд не следит о предыдущих шагах пользователя, ему все равно. Ответ бекенда не зависит от истории взаимодействия с клиентом. Все отслеживание состояния (весь интерактив, скажем так) на стороне клиента (фронтенда). Например, выбор фильтров на страничке, переходы по страницам и тд и тп.
- Кешируемость. При больших нагрузках, чтобы снизить количество запросов к серверу, результаты по популярным запросам кешируют. В этом требовании смысл в том, что ответ можно закешировать, а также нужно помечать закешированный он или нет. Читаем также про http-кеширование. Еще можно посмотреть статью aws https://aws.amazon.com/ru/caching/
- Слои. На бекенде за данными можно сходить еще куда-то, но клиент об этом ничего не узнает и не должен знать. Он стучит в одно место и получает ответ. В вике приведен другой пример, что клиент постучал по пути и ему отдали закешированный результат на слое обработки запросов, не дойдя до сервера. В данном случае просто верхнем слоем взаимодействия является тот, кто либо отдает кеш, либо идет на сервер за данными. При любом раскладе клиент (фронтенд) стучит в одно место и получает ответ, его не редиректит, никто ему не мешает, он пришел и получил, не зная, что там произошло под капотом.
- Код по запросу (опционально). Сервер может передать код для расширения функционала клиента. Такого вроде никогда не видела на практике. Даже пример не могу привести, для меня это диковинка.

- Единообразие интерфейса.

Это вот как раз про структуру web-сервисов - /name get - список, /name post/put - создание, /name/id get - итем, /name/id post/put/patch изменяет итем, /name/id delete - удаляет. Плюс еще стандарты для задания пагинации, фильтрации, передачи параметров и тп.

Требования:
-- Идентификация ресурсов. Web-сервисы по url дают доступ фактически к ресурсам в бд, но в самой бд эти данные (ресурсы) могут иметь иное представление (хранится в другом формате). Это не только про id на самом деле, но и в том числе про названия ресурсов. Как раз структура /name/id, где name - название ресурса, id - его идентификатор.
-- Манипуляция ресурсами через представление. Клиенту (фронту) через сервисы дается достаточно информации и возможностей, чтобы изменить или удалить данные (ресурс) в бд через те же веб-сервисы (тот самый crud).
-- «Самоописываемые» сообщения. Как раз мета-данные типа общего количества объектов, количество объектов на странице, количество страниц, ссылка на следующую страницу.
-- Гипермедиа как средство изменения состояния приложения (HATEOAS). На сколько я понимаю, что если сервер возвращает ссылку на какие-либо данные, то он должен вернуть такую ссылку, чтобы клиенту не надо было ее обрабатывать, чтобы по ней получить какой-либо контент. Например, возвращая картинку или видео, на эти файлы должна быть полная ссылка, а не id, чтобы клиент не хранил у себя правила формирования ссылок на этот ресурс.
Короче, клиент должен строить пути только для тех структур, которые он сам же и формирует. Пути до ресурсов бекенда, формирует сам бекенд. Таким образом логика бекенда и фронтенда должны быть независимы и полностью разделены, не должны быть задублированы. #Учеба, #Конспекты

По факту стандарт REST просто про способ разделения и взаимодействия между фронтендом и бекендом.
И еще, на самом деле нет требования к формату передачи данных. Просто чаще всего используется JSON, но по идее это также может быть и XML. #Учеба, #Конспекты

Друг позвал поучаствовать в хакатоне https://leaders2021.innoagency.ru/
Иронично, что задачи связаны с mos.ru, а я работала над задачами mos.ru 3.5 года. Этот проект меня не отпускает.
Сейчас мы сдали свое решение и ждем технической проверки, поэтому я решила написать о впечатлениях и историю нашего участия.

Лично я пошла на этот хакатон по фану. Ничего не жду от него, кроме приятных впечатлений от работы с ребятами. И то, что я хотела, я получила. Команда у нас классная.
Наш состав - я, 2 не очень опытных бекендера (Python) с увлечением в ml и такой же не очень опытный data scientist. Меня определили в капитана/тимлида, что совсем меня расслабило, вспомнила менеджерский опыт, когда ты ничего не делаешь, а только руководишь)

Расскажу наш порядок работы. Возможно, кому-то будет полезно, так как в таких творческих командах порой сложно упорядочить хаос. Я считаю, что хоть не идеально, но все же мы довольно неплохо справились.

1. Выбор задачи. На хакатоне 10 задач, у каждого свой интерес, довольно сложно выбрать одну. Поэтому для выбора задачи у нас была следующая стратегия:
- Выкинули все задачи, которые мы точно не хотим или не можем сделать.
- Сформулировали набор критериев для оценки задачи.
- Разобрали между собой оставшиеся задачи для анализа.
- Каждый проанализировал свой набор задач по указанным критериям и представил свои задачи на общем обсуждении
- Обсудили задачки и проголосовали за ту, что нравится больше.
https://docs.google.com/document/d/1SKgg1eqJ4SN0tIOAFdtLSktvhYlOHBHb0wCV0LIq2qo/ наш файлик, если будет интересно глянуть наш анализ.
Мы в итоге выбрали 10 задачу - рекомендательная система новостей для mos.ru
2. Распределение работы. Довольно сложная штука, особенно учитывая то, что всем хочется интересных задач, я мало что знала о возможностях участников, плюс вы все же не на работе. В целом, я постаралась максимально равноценно разделить задачи по тем возможностям, которые я знала о ребятах. В целом задача была разделена на такие части: рекомендации, ядро, авторазметка. Откуда авторазметка? А мы ее по фану взяли, так как в исходном описании задачи она упомянута, я знаю, что она заказчику нужна, но ее слили в основном ТЗ. Нам было интересно попробовать, поэтому мы решили ее не выкидывать. Что думаете, что тимлид забрал себе самую интересную задачу? Не, нифига, я вообще себе взяла подготовку презентации и помощь остальным. Я считаю, что настоящий тимлид должен быть свободен, чтобы при необходимости помочь!
3. Нельзя назвать наш формат работы скрамом, но мы каждый день в 10 вечера созванивались и обсуждали статус задач. Если честно, то за первую неделю, на мой взгляд, мы ничего толком не сделали. Мы обсуждали, пробовали технологии, искали решение. Я бы этот период назвала ленивой раскачкой. Но созвоны помогают держать всех в тонусе и не разбегаться в разные стороны, держать направление, убирать лишнюю нервозность, вовремя находить проблемы. Это время пришлось потратить на то, чтобы притереться и задать определенную рабочую среду в команде.
4. Чем ближе дедлайн, тем активнее разворачивалась работа. Фактически основное решение мы собрали за последнюю неделю. Последний день почти полностью провели за компами постоянно на связи. Нам удалось все сделать четко и закончить за счет распределения задач, ответственного отношения каждого из участников и постоянной синхронизации.

Я не скажу, что у нас вышло идеальное решение. У нас не дримтим, а можно сказать, что группа джунов. Но я думаю, что объективно, мы справились достойно для отведенного времени и того датасета, что мы получили на входе (просмотры для 239 пользователей за август по новостям, опубликованным с 2011 года - 26к просмотров).
Репозиторий нашего решения https://github.com/mandrianova/mos-news #Хакатон, #ML

Хочу сказать спасибо участникам моей команды, интересно было обсуждать задачки, смотреть чужие решения, разбираться вместе с проблемами и даже созваниваться по ночам)
И что самое главное, чего я боялась, если честно, ребята довели свои задачи до конца, никто не слился, никто не сбросил свой груз на остальных. Все трудились до конца и полноценно. Конечно, не без шероховатостей, я уверена, что у каждого могли остаться какие-то недовольства, но это мелочи. Для такого типа команды, я считаю, мы сработались прекрасно.

По использованным технологиям, наверное, напишу отдельный пост. Хотя в плане технологий я в основном только наблюдала и коснулась поверхностно. #Хакатон

Технологии на хакатоне. В продолжение предыдущего поста.

ML
Больше всего эмоций у меня лично было на счет ML. Я, конечно, прошла курс по ml и даже многое для себя осознала, но на практике не применяла. Когда у нашего датасаентиста начались проблемы с обучением модели и оценкой результата, я подумала, что это финиш. Не знаю, возможно, другие ребята также могли бы ему помочь разобраться, но они были заняты своими задачами, поэтому я решила попробовать помочь. И да, я кайфанула от того, что я смогла разобраться в проблеме и помочь. При чем не на уровне синтаксиса языка, а на уровне понимания сути подготовки данных для обучения, смысла обучения, как корректно разделить на train и test и тд. В итоге сопроводительную документацию по модели писала я уже сама, так как полностью понимала все, что мы сделали для рекомендаций.
Мы не использовали чего-то очень сложного, мы взяли библиотеку implicit, модель ItemItemRecommender, подробности можете посмотреть в сопроводительной документации https://github.com/mandrianova/mos-news/blob/master/develop/Documentation.ipynb
В чем собственно была загвоздка? В подготовке матрицы для модели. У нас даже шутейка появилась при оценке результатов, когда падала ошибка - "может, просто транспонировать?". И да, результат у нас получился не идеальный, не было времени экспериментировать дальше. Но теперь можно поставить галочку в опыте работы с ML)

Разметка текста
Давно смотрю на https://deeppavlov.ai/ и https://github.com/natasha/natasha, очень хотелось попробовать на задачах, но никак не доводилось. В этот раз тоже не довелось самой этим позаниматься, но они были использованы для авторазметки. Хотя основной алгоритм основан на TF-IDF https://ru.wikipedia.org/wiki/TF-IDF. Если честно, я не сильно погружалась в код. Но, мне хватило того, что диппавлова мы никак не могли развернуть. Он оказался каким-то неповоротливым в плане зависимостей. И в итоге мы не стали разбираться с проблемами Павлова и использовали Наташу. Хотя думаю, что при большом желании можно порешать эти проблемы.
В итоге функция разметки работает очень медленно. Мы не успели ее оптимизировать. Кажется, что основная проблема в скорости нормализации слов в тексте. Возможно, есть какое-то простое и быстро решение, но мы не искали. Лично мне вспомнился пример из cs50, где в похожей задаче (проверка орфографии в тексте по словарю) скорость работы функции си значительно превышала скорость на питоне. Вот для таких задач, наверное, идеально писать или использовать библиотечку на компилируемом языке программирования с оптимальным кодом, чтобы быстро отрабатывала.

Быстро-мелко-сервисы
Ребята выбрали fastapi для того, чтобы сделать endpoint по задаче. Даже настроили асинхронные таски для переобучения модели. Мало, что могу сказать, так как в код я почти не лезла, но захотелось эту библиотеку попробовать еще где-нибудь. Легковесна как flask, но при этом с довольно интересными возможностями и в плане построения api, и в плане асинхронной работы. В принципе я и раньше знала о преимуществах fastapi, но теперь еще больше думаю попробовать применить ее где-нибудь. Вопрос только где)...

Облако.
В рамках хакатона дали промокод на Яндекс Облако. По сути можно было бы воспользоваться другими вариантами, но решили почему бы и не попробовать яндекс. Мне было интересна разница с aws, так как я кроме aws пробовала только хероку. Документация по яндекс облаку на русском языке. Это дико непривычно. Забавно видеть preview некоторых функций, которые в aws уже давно существуют. Понятно, что яндекс облако молодо по сравнению с aws. Прикольно, что они вообще в это полезли. В целом с разворачиванием инстанса особых проблем не возникло. Не могу нормально даже сравнить интерфейс, так как было просто непривычно. Были какие-то мелочи, типа очень не хватало ссылки на сам инстанс, немного заплутали в настройках. Но основные проблемы с разворачиванием у нас были скорее из-за наших косяков, а не из-за яндекса.

Наверное, все. Если будут вопросы - пишите. Постараюсь ответить или позвать ребят, чтобы рассказали что и как было сделано. #Хакатон, #ML

Наша команда прошла в финал на хакатоне, хехей! На входе по нашей задаче была 21 команда, вышли в финал 5 команд. #Хакатон

Сижу, думаю о том, что рассказывать на питче хакатона... и внезапно вспомнила как я писала "трудноговорку" в 2018 году для театральной студии (текст, который сложно будет выговаривать). В общем, я тогда написала текст на тему рекомендательной системы, почти не понимая половину слов. Прикладываю то творение ниже:


"Для разработки коллаборативной высоконагруженной рекомендательной системы заработавшийся менеджер выбрал триста тридцать три переквалифицированных кастомизированных фреймворка. Он развернуто и тщательно сформулировал и задокументировал все функциональные и нефункциональные требования и передал информацию освободившемуся техническому директору на согласование. В усовершенствованном решении приняли использование документоориентированной нереляционной базы в специализированном хранилище из-за возможностей масштабируемости, атомарности и согласованности.
Объектно-ориентированные программисты запрограммировали коллаборативную фильтрацию для индивидуального прогнозирования самых изощренных персонализированных предпочтений пользователей.
Функциональные тестировщики и асессоры, авторизованные на тестирование разработанного билда, обнаружили, что вышеуказанная коллаборативная рекомендательная фильтрация предпочтительнее, чем контентно-основанные ранее используемые предложения.
После реализации перечисленного функционала отдел маркетинговых исследований проанализировал, измеряя параметры статистических моделей для оценок пользователей, построенных с помощью байесовских сетей, кластеризации, латентной семантической модели, такие как сингулярное разложение, вероятностный латентный семантический анализ, скрытое распределение Дирихле и марковской процесс принятия решений на основе моделей. Они предпочли обучаемые модели, разработанные с использованием специализированных интеллектуальных аналитических компонентов и алгоритмов машинного обучения, чтобы найти закономерности на основе первичных выборочных данных.
Через централизованную систему контроля версий с автоматизированным выкатом на продовое окружение опубликовали обновленную рекомендательную фильтрацию на жестко выверенную ограниченную пользовательскую выборку, чтобы продемонстрировать и перепроверить все в реалистичных условиях. Ключевые показатели на мониторинге отобразили всплеск конверсии.
По показаниям статистических счетчиков аналитический и маркетинговый отделы одобрили реализованный функционал."

Чуть причесать и речь готова ХД #Хакатон, #ML

Наша команда на хакатоне вошла в тройку лидеров! Мы вошли в финал!
Если честно, я немного устала и рада, что вся работа завершена. Я на днях вставала среди ночи, чтобы исправить ошибку разделения в тестовой выборке, которая давала нам неверные результаты. Хорошо, что за плечами есть курс по ml и понимание как вообще это работает.
Конкуренты показали довольно "потные" презентации по ds. Чувствуется опыт в ml. Но мы достигли довольно неплохих результатов на банальной логике и понимании темы, как мне кажется.
Блин, больше всего хочется кричать о том, что сколько же понтов и магии вокруг ml. Когда я пробовала в модель добавить веса на основе сфер и тегов, перевела данные о них в матрично-цифровой формат, наш ds сказал, что я сделала эмбеддинг. Ахах, я слышала это слово, но я не знала, что оно значило) Я просто подумала, что было бы неплохо попробовать сделать вот так. Зато словечко стильно-трендовое) Но, на том тестовом датасете это ничего не дало, да. Даже стало чуть хуже. Поэтому мы остались на чистой обратной зависимости от количества дней с даты публикации.
Интересно, я не проверяла, но если бы мы тупо взяли чисто последние опубликованных свежих 20 новостей, какую бы мы получили точность?)
Надо попробовать ради фана... Нет, только бы я не была права, это тогда полный фейл...

Ну что же, ждем объявления победителей 12 ноября. #Хакатон, #ML

Решила поделиться своими незаконченными конспектами по смежным темам.
ML - конспект основан на курсе по ML от МФТИ и Яндекса, из которого я прошла 1 и частично 2 этап https://www.coursera.org/specializations/machine-learning-data-analysis
AWS - конспект основан на плейлисте https://www.youtube.com/playlist?list=PLg5SS_4L6LYsxrZ_4xE_U95AtGsIB96k9
infra - конспект основан на лекциях "Введение в архитектуру ЭВМ о элементы ОС" https://www.youtube.com/playlist?list=PLlb7e2G7aSpRZ9wDzXI-VYpk59acLFOIr

Все три темы прохожу наплывами, поэтому возможно когда-нибудь доделаю и выложу полные конспекты.
Но вообще это скорее способ расширения общего кругозора. На самом деле последнее время учусь больше точечно по необходимости. #Конспекты, #AWS, #ML