Про 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, чтобы клиент не хранил у себя правила формирования ссылок на этот ресурс.
Короче, клиент должен строить пути только для тех структур, которые он сам же и формирует. Пути до ресурсов бекенда, формирует сам бекенд. Таким образом логика бекенда и фронтенда должны быть независимы и полностью разделены, не должны быть задублированы. #Учеба, #Конспекты
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. #Учеба, #Конспекты
И еще, на самом деле нет требования к формату передачи данных. Просто чаще всего используется 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
Иронично, что задачи связаны с 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
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
👍2
Наша команда прошла в финал на хакатоне, хехей! На входе по нашей задаче была 21 команда, вышли в финал 5 команд. #Хакатон
👍1
Сижу, думаю о том, что рассказывать на питче хакатона... и внезапно вспомнила как я писала "трудноговорку" в 2018 году для театральной студии (текст, который сложно будет выговаривать). В общем, я тогда написала текст на тему рекомендательной системы, почти не понимая половину слов. Прикладываю то творение ниже:
"Для разработки коллаборативной высоконагруженной рекомендательной системы заработавшийся менеджер выбрал триста тридцать три переквалифицированных кастомизированных фреймворка. Он развернуто и тщательно сформулировал и задокументировал все функциональные и нефункциональные требования и передал информацию освободившемуся техническому директору на согласование. В усовершенствованном решении приняли использование документоориентированной нереляционной базы в специализированном хранилище из-за возможностей масштабируемости, атомарности и согласованности.
Объектно-ориентированные программисты запрограммировали коллаборативную фильтрацию для индивидуального прогнозирования самых изощренных персонализированных предпочтений пользователей.
Функциональные тестировщики и асессоры, авторизованные на тестирование разработанного билда, обнаружили, что вышеуказанная коллаборативная рекомендательная фильтрация предпочтительнее, чем контентно-основанные ранее используемые предложения.
После реализации перечисленного функционала отдел маркетинговых исследований проанализировал, измеряя параметры статистических моделей для оценок пользователей, построенных с помощью байесовских сетей, кластеризации, латентной семантической модели, такие как сингулярное разложение, вероятностный латентный семантический анализ, скрытое распределение Дирихле и марковской процесс принятия решений на основе моделей. Они предпочли обучаемые модели, разработанные с использованием специализированных интеллектуальных аналитических компонентов и алгоритмов машинного обучения, чтобы найти закономерности на основе первичных выборочных данных.
Через централизованную систему контроля версий с автоматизированным выкатом на продовое окружение опубликовали обновленную рекомендательную фильтрацию на жестко выверенную ограниченную пользовательскую выборку, чтобы продемонстрировать и перепроверить все в реалистичных условиях. Ключевые показатели на мониторинге отобразили всплеск конверсии.
По показаниям статистических счетчиков аналитический и маркетинговый отделы одобрили реализованный функционал."
Чуть причесать и речь готова ХД #Хакатон, #ML
"Для разработки коллаборативной высоконагруженной рекомендательной системы заработавшийся менеджер выбрал триста тридцать три переквалифицированных кастомизированных фреймворка. Он развернуто и тщательно сформулировал и задокументировал все функциональные и нефункциональные требования и передал информацию освободившемуся техническому директору на согласование. В усовершенствованном решении приняли использование документоориентированной нереляционной базы в специализированном хранилище из-за возможностей масштабируемости, атомарности и согласованности.
Объектно-ориентированные программисты запрограммировали коллаборативную фильтрацию для индивидуального прогнозирования самых изощренных персонализированных предпочтений пользователей.
Функциональные тестировщики и асессоры, авторизованные на тестирование разработанного билда, обнаружили, что вышеуказанная коллаборативная рекомендательная фильтрация предпочтительнее, чем контентно-основанные ранее используемые предложения.
После реализации перечисленного функционала отдел маркетинговых исследований проанализировал, измеряя параметры статистических моделей для оценок пользователей, построенных с помощью байесовских сетей, кластеризации, латентной семантической модели, такие как сингулярное разложение, вероятностный латентный семантический анализ, скрытое распределение Дирихле и марковской процесс принятия решений на основе моделей. Они предпочли обучаемые модели, разработанные с использованием специализированных интеллектуальных аналитических компонентов и алгоритмов машинного обучения, чтобы найти закономерности на основе первичных выборочных данных.
Через централизованную систему контроля версий с автоматизированным выкатом на продовое окружение опубликовали обновленную рекомендательную фильтрацию на жестко выверенную ограниченную пользовательскую выборку, чтобы продемонстрировать и перепроверить все в реалистичных условиях. Ключевые показатели на мониторинге отобразили всплеск конверсии.
По показаниям статистических счетчиков аналитический и маркетинговый отделы одобрили реализованный функционал."
Чуть причесать и речь готова ХД #Хакатон, #ML
Наша команда на хакатоне вошла в тройку лидеров! Мы вошли в финал!
Если честно, я немного устала и рада, что вся работа завершена. Я на днях вставала среди ночи, чтобы исправить ошибку разделения в тестовой выборке, которая давала нам неверные результаты. Хорошо, что за плечами есть курс по ml и понимание как вообще это работает.
Конкуренты показали довольно "потные" презентации по ds. Чувствуется опыт в ml. Но мы достигли довольно неплохих результатов на банальной логике и понимании темы, как мне кажется.
Блин, больше всего хочется кричать о том, что сколько же понтов и магии вокруг ml. Когда я пробовала в модель добавить веса на основе сфер и тегов, перевела данные о них в матрично-цифровой формат, наш ds сказал, что я сделала эмбеддинг. Ахах, я слышала это слово, но я не знала, что оно значило) Я просто подумала, что было бы неплохо попробовать сделать вот так. Зато словечко стильно-трендовое) Но, на том тестовом датасете это ничего не дало, да. Даже стало чуть хуже. Поэтому мы остались на чистой обратной зависимости от количества дней с даты публикации.
Интересно, я не проверяла, но если бы мы тупо взяли чисто последние опубликованных свежих 20 новостей, какую бы мы получили точность?)
Надо попробовать ради фана... Нет, только бы я не была права, это тогда полный фейл...
Ну что же, ждем объявления победителей 12 ноября. #Хакатон, #ML
Если честно, я немного устала и рада, что вся работа завершена. Я на днях вставала среди ночи, чтобы исправить ошибку разделения в тестовой выборке, которая давала нам неверные результаты. Хорошо, что за плечами есть курс по ml и понимание как вообще это работает.
Конкуренты показали довольно "потные" презентации по ds. Чувствуется опыт в ml. Но мы достигли довольно неплохих результатов на банальной логике и понимании темы, как мне кажется.
Блин, больше всего хочется кричать о том, что сколько же понтов и магии вокруг ml. Когда я пробовала в модель добавить веса на основе сфер и тегов, перевела данные о них в матрично-цифровой формат, наш ds сказал, что я сделала эмбеддинг. Ахах, я слышала это слово, но я не знала, что оно значило) Я просто подумала, что было бы неплохо попробовать сделать вот так. Зато словечко стильно-трендовое) Но, на том тестовом датасете это ничего не дало, да. Даже стало чуть хуже. Поэтому мы остались на чистой обратной зависимости от количества дней с даты публикации.
Интересно, я не проверяла, но если бы мы тупо взяли чисто последние опубликованных свежих 20 новостей, какую бы мы получили точность?)
Надо попробовать ради фана... Нет, только бы я не была права, это тогда полный фейл...
Ну что же, ждем объявления победителей 12 ноября. #Хакатон, #ML
👍1
Решила поделиться своими незаконченными конспектами по смежным темам.
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
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
Про градации - от джуна до CTO.
Много-много размышлений есть как измерить уровень специалиста, споров и тп. Этот показатель все равно остается субъективным.
В группе Боль тимлида заметила очередную жалобу на этот счет и задумалась.
В каждой компании своя градация и это нормально, у каждой компании свои требования к специалистам, свой стек технологий, свои нюансы. Вот на своем стартапе я фактически СТО с самого начала. Хотя смешно об этом говорить, так как у меня нет подчиненных и сравнивать не с кем. Но я делаю всю реализацию - архитектуру, инфраструктуру, пишу код, записываю себе задачки в техдолг, сама решаю что мне еще надо прокачать, отвечаю за расходы, сроки, качество.
На хакатоне в команде я была тимлидом. Нас уже было 4 человека. Я занималась декомпозицией, приоритетами, организацией, решением проблем. Задача тут уже была другая, другой подход, была команда.
А теперь представим маленькую компанию, у которой простые задачи. Там нужно знать небольшой набор технологий. И человек, который хорошо в них разобрался может быть в этой маленькой компании сеньором, техдиром. А вот он увольняется и идет на собеседование в крупный проект, где используются более сложные технологии и там его уже оценивают как джуна.
И это нормально. Нормально в одной компании быть всем, а в другой быть песчинкой. В стартапе - СТО, в гугле - стажером.
Важно какую ценность ты приносишь компании. Поэтому ранг зависит от ценности специалиста в рамках конкретной компании.
Но некоторые технари любят писькомерство)
- фу, да какой он сеньор, когда он не знает даже популярные сортировки!
Ребята, не обязательно знать все, чтобы приносить ценность бизнесу.
- Фууууу, да этот криворукий джун не умеет писать скрипты на баше!
Ребята, это не мешает ему решать задачи.
- Фууу, да он не может писать качественный код, пишет лапшу, это дорого поддерживать и тп!
Заказчика это устраивает? Не будет устраивать - наймет другого.
Про оплату. Кто как себя смог продать, у кого какие приоритеты. Кто-то хочет зарабатывать бабки, кто-то интересные проекты, кто-то развития, у каждого свои приоритеты. Наверное, не стоит завидовать и злиться, что слабому спецу платят больше, чем сильному. Возможно, на то есть свои причины. Лучше подумать о своих приоритетах и если это нужно, то как поднять цену себе.
Про себя.
Иногда я смотрю на свой код и мне стыдно. Иногда мне стыдно, что я много чего не знаю. Иногда мне стыдно, что я лажаю и ошибаюсь. Особенно, когда кто-то из коллег ловит меня на моем не знании каких-то базовых вещей. Но в такие моменты я стараюсь выдохнуть и подумать. Так, задача сделана, она работает. Код можно поправить и отрефакторить позже, когда будет вдохновение. Да, бывают такие моменты, когда сегодня решаешь в лоб, пишешь лапшу кода. А послезавтра накатывает идея и переписываешь своей код, делаешь его более читабельным, оптимизированным. А иногда не делаешь, так как то, что было использовано сегодня, завтра уже можно выкинуть. А все, что не знаю, понемногу сижу и изучаю, развиваюсь. Нельзя же по мановению волшебной палочки узнать сразу все. Просто иногда думаю, ага, надо бы подтянуть вот эту тему, так как она мне полезна и даст профит в перспективе.
Не буду в этот раз писать на счет собесов по этой теме. Отдельно как-нибудь. Когда созрею и без эмоций постараюсь отрефлексировать опыт своих собесов и собесов знакомых.
Кстати, пишите свои отзывы по собесам. Кто что спрашивает и почему. Какие впечатления. Интересно узнать обе стороны. #Работа
Много-много размышлений есть как измерить уровень специалиста, споров и тп. Этот показатель все равно остается субъективным.
В группе Боль тимлида заметила очередную жалобу на этот счет и задумалась.
В каждой компании своя градация и это нормально, у каждой компании свои требования к специалистам, свой стек технологий, свои нюансы. Вот на своем стартапе я фактически СТО с самого начала. Хотя смешно об этом говорить, так как у меня нет подчиненных и сравнивать не с кем. Но я делаю всю реализацию - архитектуру, инфраструктуру, пишу код, записываю себе задачки в техдолг, сама решаю что мне еще надо прокачать, отвечаю за расходы, сроки, качество.
На хакатоне в команде я была тимлидом. Нас уже было 4 человека. Я занималась декомпозицией, приоритетами, организацией, решением проблем. Задача тут уже была другая, другой подход, была команда.
А теперь представим маленькую компанию, у которой простые задачи. Там нужно знать небольшой набор технологий. И человек, который хорошо в них разобрался может быть в этой маленькой компании сеньором, техдиром. А вот он увольняется и идет на собеседование в крупный проект, где используются более сложные технологии и там его уже оценивают как джуна.
И это нормально. Нормально в одной компании быть всем, а в другой быть песчинкой. В стартапе - СТО, в гугле - стажером.
Важно какую ценность ты приносишь компании. Поэтому ранг зависит от ценности специалиста в рамках конкретной компании.
Но некоторые технари любят писькомерство)
- фу, да какой он сеньор, когда он не знает даже популярные сортировки!
Ребята, не обязательно знать все, чтобы приносить ценность бизнесу.
- Фууууу, да этот криворукий джун не умеет писать скрипты на баше!
Ребята, это не мешает ему решать задачи.
- Фууу, да он не может писать качественный код, пишет лапшу, это дорого поддерживать и тп!
Заказчика это устраивает? Не будет устраивать - наймет другого.
Про оплату. Кто как себя смог продать, у кого какие приоритеты. Кто-то хочет зарабатывать бабки, кто-то интересные проекты, кто-то развития, у каждого свои приоритеты. Наверное, не стоит завидовать и злиться, что слабому спецу платят больше, чем сильному. Возможно, на то есть свои причины. Лучше подумать о своих приоритетах и если это нужно, то как поднять цену себе.
Про себя.
Иногда я смотрю на свой код и мне стыдно. Иногда мне стыдно, что я много чего не знаю. Иногда мне стыдно, что я лажаю и ошибаюсь. Особенно, когда кто-то из коллег ловит меня на моем не знании каких-то базовых вещей. Но в такие моменты я стараюсь выдохнуть и подумать. Так, задача сделана, она работает. Код можно поправить и отрефакторить позже, когда будет вдохновение. Да, бывают такие моменты, когда сегодня решаешь в лоб, пишешь лапшу кода. А послезавтра накатывает идея и переписываешь своей код, делаешь его более читабельным, оптимизированным. А иногда не делаешь, так как то, что было использовано сегодня, завтра уже можно выкинуть. А все, что не знаю, понемногу сижу и изучаю, развиваюсь. Нельзя же по мановению волшебной палочки узнать сразу все. Просто иногда думаю, ага, надо бы подтянуть вот эту тему, так как она мне полезна и даст профит в перспективе.
Не буду в этот раз писать на счет собесов по этой теме. Отдельно как-нибудь. Когда созрею и без эмоций постараюсь отрефлексировать опыт своих собесов и собесов знакомых.
Кстати, пишите свои отзывы по собесам. Кто что спрашивает и почему. Какие впечатления. Интересно узнать обе стороны. #Работа
Последние 2 недели сплошная возня с конфигами и перевыкатами.
Каждый, кто выходит на новое место работы, знает какого это разобраться с чужой инфрой, настроить у себя проект, разобраться что к чему.
Я этот этап прошла на текущем проекте в одиночку. И мне пришлось не просто поднять у себя на компе, но развернуть все на инфре aws. При этом пришлось использовать сервис ECS, который раньше не использовала. Интересная штука. Надо будет перетащить на него свои проекты, когда разберусь до конца.
Вообще, мне интересно строить инфру проекту, считай с нуля. Я прикидывала калькулятор на aws по стоимости сервисов, поднимала свеженькие инстансы для бд, для кеширования, настраивала доступы, ключи, реджистри. Заставила себя нормально настроить подключение по ssh и aws cli. Навела порядок в своей wsl.
Испытала много попа-боли при настройке nginx. Хах, кто знал, что конфиг digital ocean будет с подвохом:
А директорию для конфигов назовем sites-available. Хм, кстати, может поэтому была ошибка при автоматической генерации сертификата. Надо будет перепроверить скрипт)
Другой не менее сложный момент был в том, чтобы получить доступ из контейнера с nginx в контейнеры с бекендом и фронтендом. У меня запущена network типа bridge, которая обеспечивает связь по имени контейнера. Но имя генерится при каждом новом запуске задачи, не менять же каждый раз конфиг nginx после этого? В итоге я методом тыка нащупала, что можно стучать по хосту 172.17.0.1, но не факт, что он не поменяется. Также пишут, что можно использовать host.docker.internal, но у меня не сработало. Надо искать нормально решение. Но пока не могу придумать какое.
Зато я начала писать примитивные bash-скрипты. Каждый репозиторий проекта снабдила скриптом для сборки контейнера и пуша в реджистри. Потому что надоело одно и то же набирать каждый раз)
Для настройки и запуска nginx написала пару питонячьих скриптов, которые запускаются из bash-скрипта и их результат является условием в bash-скрипте. Почувствовала себя админом, умеющим в питон. Хах!
Отдельно доставило доброжелательностью сообщество @docker_ru. Давно там состою, но всегда стесняюсь спрашивать, так как иногда даже сформулировать сложно то, чего я хочу или в чем у меня проблема. А вот сегодня решилась написать и мне даже попытались помочь! Приятно.
Поправила, собрала, выкатила, проверила, поправила, собрала, выкатила, проверила... Надоело уже возиться с инфрой, хочется покодить)
Впрочем, я еще не закончила. Надо добить разворачивания инфры и наконец перейти к коду. Хотя посматриваю я на чужой код и мне немного страшно. Там столько всего накручено... Особенно на фронте. React во всех его прекрасных проявлениях. Сегодня фронт при сборке на меня ругнулся, что ему не хватает памяти на сборку и следом "вылетело" несколько программ. Я аж офигела от такого поворота событий.
И еще. Так забавно, когда я на проекте сама себе менеджер, сама техлид, сама админ, сама бекенд, сама фронтенд, сама тестер) Многоликая!
Несвязный набор слов. Не выспалась вчера. Простите. Всем интересных задач, проектов, лучших коллег! #Docker, #AWS, #Работа
Каждый, кто выходит на новое место работы, знает какого это разобраться с чужой инфрой, настроить у себя проект, разобраться что к чему.
Я этот этап прошла на текущем проекте в одиночку. И мне пришлось не просто поднять у себя на компе, но развернуть все на инфре aws. При этом пришлось использовать сервис ECS, который раньше не использовала. Интересная штука. Надо будет перетащить на него свои проекты, когда разберусь до конца.
Вообще, мне интересно строить инфру проекту, считай с нуля. Я прикидывала калькулятор на aws по стоимости сервисов, поднимала свеженькие инстансы для бд, для кеширования, настраивала доступы, ключи, реджистри. Заставила себя нормально настроить подключение по ssh и aws cli. Навела порядок в своей wsl.
Испытала много попа-боли при настройке nginx. Хах, кто знал, что конфиг digital ocean будет с подвохом:
include /etc/nginx/sites-enabled/*;
А директорию для конфигов назовем sites-available. Хм, кстати, может поэтому была ошибка при автоматической генерации сертификата. Надо будет перепроверить скрипт)
Другой не менее сложный момент был в том, чтобы получить доступ из контейнера с nginx в контейнеры с бекендом и фронтендом. У меня запущена network типа bridge, которая обеспечивает связь по имени контейнера. Но имя генерится при каждом новом запуске задачи, не менять же каждый раз конфиг nginx после этого? В итоге я методом тыка нащупала, что можно стучать по хосту 172.17.0.1, но не факт, что он не поменяется. Также пишут, что можно использовать host.docker.internal, но у меня не сработало. Надо искать нормально решение. Но пока не могу придумать какое.
Зато я начала писать примитивные bash-скрипты. Каждый репозиторий проекта снабдила скриптом для сборки контейнера и пуша в реджистри. Потому что надоело одно и то же набирать каждый раз)
Для настройки и запуска nginx написала пару питонячьих скриптов, которые запускаются из bash-скрипта и их результат является условием в bash-скрипте. Почувствовала себя админом, умеющим в питон. Хах!
Отдельно доставило доброжелательностью сообщество @docker_ru. Давно там состою, но всегда стесняюсь спрашивать, так как иногда даже сформулировать сложно то, чего я хочу или в чем у меня проблема. А вот сегодня решилась написать и мне даже попытались помочь! Приятно.
Поправила, собрала, выкатила, проверила, поправила, собрала, выкатила, проверила... Надоело уже возиться с инфрой, хочется покодить)
Впрочем, я еще не закончила. Надо добить разворачивания инфры и наконец перейти к коду. Хотя посматриваю я на чужой код и мне немного страшно. Там столько всего накручено... Особенно на фронте. React во всех его прекрасных проявлениях. Сегодня фронт при сборке на меня ругнулся, что ему не хватает памяти на сборку и следом "вылетело" несколько программ. Я аж офигела от такого поворота событий.
И еще. Так забавно, когда я на проекте сама себе менеджер, сама техлид, сама админ, сама бекенд, сама фронтенд, сама тестер) Многоликая!
Несвязный набор слов. Не выспалась вчера. Простите. Всем интересных задач, проектов, лучших коллег! #Docker, #AWS, #Работа
Рубрика проблемы и их решения.
CORS и S3. Самая странная проблема. Файлики прекрасно грузились с другого домена и не было проблем. Пока я не добралась до воспроизведения аудио. Казалось бы, вот этот же аудио-файл был спокойно загружен страницей, но react буквально тут же этот же файл пытается загрузить снова и получает ошибку с CORS. Я иду проверять настройки в S3. Все ок. Ладно, добавляю еще настройку:
Чтобы S3 прокидывал нужные заголовки. Все равно ошибка. Страдаю, гуглю, кручу-верчу. В общем, помогает в итоге очистка кэша браузера. После этого у меня все ок, аудио загружается и работает.
Прошу посмотреть на другом компе, где еще ни разу не загружался этот сайт. И там та же ошибка с CORS. И снова очистка кэша браузера лечит проблему. Как Карл? Нет. Серьезно. Как? Почему?
Воспроизводила несколько раз. Где я не догоняю?
Ладно, там разница в количестве возвращенных заголовков между запросом с ошибкой и без нее. Но почему оно разное до очистки кэша на сайте, который был загружен впервые и после нее?
Вторая история тоже про s3. Я наивно надеялась, что я раз и переключу хранение файлов на S3. Но нет. На проекте идет много обработки аудио и видео с помощью ffmpeg. И все скрипты, конечно, были реализованы через хранение файлов на сервере. В начале мне было страшно влезать в чужой непонятный код и я хотела вовсе отказаться от идеи перехода на S3. Реально становилось страшно от количества чужих непонятных функций для обработки файлов, которые между собой связаны. Когда я начала распутывать этот клубок, переходя и переписывая от одной функции к другой, мне казалось, что я так все переломаю, что потом не смогу собрать. В середине пути мне снова хотелось бросить и откатить все назад. Много раз я сомневалась в правильности принятого решения. Несколько раз приходилось возвращаться к тому, что уже было переписано и править, так как в процессе я узнавала что-то новое и важное обо всей логике. Когда я переписала все до конца, паззл сложился. Теперь я знаю как работает загрузка и обработка файлов на проекте) Заодно переписала логирование)
В процессе изучения проблем приходилось заглядывать и во фронтовую часть. Хоть я и писала свою приложеньку на React, это все же не тоже самое, что смотреть в чужой проект, где компоненты на 300+ строк кода. Первый взгляд на код вызывает панику и 1001 вопрос "что здесь происходит?". И также приходится садиться и разбирать этот клубок на ниточки, чтобы понять как он работает.
Правда, есть определенный кайф в возможности переделать все так, как считаешь нужным. Не смотря на проблемы, мне нравится то, что я сама решаю как поднять этот домик.
Последний сервис успешно развернула на сервере. Но меня пугает его медлительность и прожорливость. Я его подняла на 2cpu и 8gb ram, но сервис все равно не успевает ответить за 5 секунд по одному из запросов. Код в сервисе не вдохновляет. Когда я увидела функцию для обработки endpoint на flask на 300+ строк кода, большая часть из которых начинается с условия if request.method == 'POST', хотя метод итак указан в параметре для route, мне взгрустнулось. И это ведь не весь код, там идет вызов функций из скриптов логики.
"Скоро рассвет. Выхода нет. Ключ поверни и полетели. Надо писать в чью-то тетрадь кровью, как в метрополитене. Выхода нет" (С)
Ладно, выход есть, как и свет в конце тоннеля. 3 недели и я развернула! Нагенерила себе уже 12 задачек в беклог) Буду завтра ковырять то, что оставила на потом. #Работа, #AWS
CORS и S3. Самая странная проблема. Файлики прекрасно грузились с другого домена и не было проблем. Пока я не добралась до воспроизведения аудио. Казалось бы, вот этот же аудио-файл был спокойно загружен страницей, но react буквально тут же этот же файл пытается загрузить снова и получает ошибку с CORS. Я иду проверять настройки в S3. Все ок. Ладно, добавляю еще настройку:
"AllowedHeaders": ["Authorization"]
Чтобы S3 прокидывал нужные заголовки. Все равно ошибка. Страдаю, гуглю, кручу-верчу. В общем, помогает в итоге очистка кэша браузера. После этого у меня все ок, аудио загружается и работает.
Прошу посмотреть на другом компе, где еще ни разу не загружался этот сайт. И там та же ошибка с CORS. И снова очистка кэша браузера лечит проблему. Как Карл? Нет. Серьезно. Как? Почему?
Воспроизводила несколько раз. Где я не догоняю?
Ладно, там разница в количестве возвращенных заголовков между запросом с ошибкой и без нее. Но почему оно разное до очистки кэша на сайте, который был загружен впервые и после нее?
Вторая история тоже про s3. Я наивно надеялась, что я раз и переключу хранение файлов на S3. Но нет. На проекте идет много обработки аудио и видео с помощью ffmpeg. И все скрипты, конечно, были реализованы через хранение файлов на сервере. В начале мне было страшно влезать в чужой непонятный код и я хотела вовсе отказаться от идеи перехода на S3. Реально становилось страшно от количества чужих непонятных функций для обработки файлов, которые между собой связаны. Когда я начала распутывать этот клубок, переходя и переписывая от одной функции к другой, мне казалось, что я так все переломаю, что потом не смогу собрать. В середине пути мне снова хотелось бросить и откатить все назад. Много раз я сомневалась в правильности принятого решения. Несколько раз приходилось возвращаться к тому, что уже было переписано и править, так как в процессе я узнавала что-то новое и важное обо всей логике. Когда я переписала все до конца, паззл сложился. Теперь я знаю как работает загрузка и обработка файлов на проекте) Заодно переписала логирование)
В процессе изучения проблем приходилось заглядывать и во фронтовую часть. Хоть я и писала свою приложеньку на React, это все же не тоже самое, что смотреть в чужой проект, где компоненты на 300+ строк кода. Первый взгляд на код вызывает панику и 1001 вопрос "что здесь происходит?". И также приходится садиться и разбирать этот клубок на ниточки, чтобы понять как он работает.
Правда, есть определенный кайф в возможности переделать все так, как считаешь нужным. Не смотря на проблемы, мне нравится то, что я сама решаю как поднять этот домик.
Последний сервис успешно развернула на сервере. Но меня пугает его медлительность и прожорливость. Я его подняла на 2cpu и 8gb ram, но сервис все равно не успевает ответить за 5 секунд по одному из запросов. Код в сервисе не вдохновляет. Когда я увидела функцию для обработки endpoint на flask на 300+ строк кода, большая часть из которых начинается с условия if request.method == 'POST', хотя метод итак указан в параметре для route, мне взгрустнулось. И это ведь не весь код, там идет вызов функций из скриптов логики.
"Скоро рассвет. Выхода нет. Ключ поверни и полетели. Надо писать в чью-то тетрадь кровью, как в метрополитене. Выхода нет" (С)
Ладно, выход есть, как и свет в конце тоннеля. 3 недели и я развернула! Нагенерила себе уже 12 задачек в беклог) Буду завтра ковырять то, что оставила на потом. #Работа, #AWS
Просто пара слов про рефакторинг, потому что захотелось.
Рефакторинг должен решать определенную задачу, иметь цель и эта цель не должна быть - "просто сделать красиво". Бл***! Не надо писать или переписывать код, чтобы просто было красиво. Серьезно( Я понимаю, что будущее, поддержка и вот это все, но серьезно, не надо делать красоту ради красоты, дизайн ради дизайна, страдать перфекционизмом.
Надо включать голову. Каждый раз я думаю, а зачем я это делаю. Действительно ли это важно? Можно ли этим пренебречь? Что будет, если я это не сделаю?
Самый важный и классный вопрос - а что будет, если этого не сделать? Мне всегда нравились решения задач от противного. Они были необычные и этим вдохновляли. Так и этот вопрос заставляет взглянуть на проблему с другой стороны. Всем удачи)
PS. Просто вот этот вечный страх говнокода, что так нельзя, это фу-фу-фу. Да нет, нормально все. Завтра будет лучше. Исправим, допилим, все будет. Но, к сожалению это стандарт, шаблон мышления в среде. Коллеги будут тыкать, тоскичить на тему, что ты все делаешь не так, только потому что так не принято, так нельзя и вообще твой код - говно.
Извините, пригорело. #Работа
Рефакторинг должен решать определенную задачу, иметь цель и эта цель не должна быть - "просто сделать красиво". Бл***! Не надо писать или переписывать код, чтобы просто было красиво. Серьезно( Я понимаю, что будущее, поддержка и вот это все, но серьезно, не надо делать красоту ради красоты, дизайн ради дизайна, страдать перфекционизмом.
Надо включать голову. Каждый раз я думаю, а зачем я это делаю. Действительно ли это важно? Можно ли этим пренебречь? Что будет, если я это не сделаю?
Самый важный и классный вопрос - а что будет, если этого не сделать? Мне всегда нравились решения задач от противного. Они были необычные и этим вдохновляли. Так и этот вопрос заставляет взглянуть на проблему с другой стороны. Всем удачи)
PS. Просто вот этот вечный страх говнокода, что так нельзя, это фу-фу-фу. Да нет, нормально все. Завтра будет лучше. Исправим, допилим, все будет. Но, к сожалению это стандарт, шаблон мышления в среде. Коллеги будут тыкать, тоскичить на тему, что ты все делаешь не так, только потому что так не принято, так нельзя и вообще твой код - говно.
Извините, пригорело. #Работа
Столько всего хочется рассказать. Но многое пока еще не доделано.
Напишу тру-стори, которая меня прям порадовала.
Один из сервисов, который мне достался был тяжелым. С кучей зависимостей. Только для того, чтобы он поднялся требовалось ~5Gb RAM. Неповоротливый, медленный. В requirements 78 строчек. Tenserflow, natasha, nltk, pymystem3 и много другое. Подключение к бд на сыром sql, много неструктурированного кода, недокументированного, плохо читаемого. Он работал медленно, часто отвечал на запрос дольше 5 секунд. Надо было его оптимизировать, ускорять.
Закармливать этого монстра ресурсами не хотелось. Каким прожорой он будет, когда еще и нагрузка пойдет? Лезть в код было жутко, потому что слишком много всего. Я бы в нем разбиралась очень долго.
И я посмотрела на то, что вообще этот сервис делает и подумала, что вроде функционал нужен простой и в теории можно обойтись google api и встроенной библиотекой difflib. Сразу скажу, что я неправильно оценила необходимый функционал сервиса изначально. Но базовые требования к нему были поняты мной верно. Просто я не учла некоторых подводных камней, которые раскрылись в процессе.
В общем, я решилась на авантюру - переписать все с нуля. Как тот самый программист, который приходит и говорит - фу, надо все переделать)
Когда я начала переписывать, я нашла много неучтенных мной моментов. Что-то я также переписала в новом сервисе, чем-то пришлось пренебречь. Но за день я собрала новый сервис, который по сути выполняет 80% функционала старого. Работает сейчас на 200Mb оперативки. Чисто в теории его можно запустить на банальной lambda функции в AWS. Что я подумываю сделать, но меня смущает скорость ответа от google. Сейчас наблюдаю за тем, сколько в среднем требуется времени на отработку запроса. Но средняя скорость ответа сервиса - 1.1 секунда, из нее на google api приходится почти 100% :-P
Продакт качеством сервиса доволен. Говорит, что в целом отрабатывает не хуже, а в некоторых случаях даже лучше старого. Без nlp и вот этого всего. И бд, кстати, мне тоже не понадобилась.
Люблю я простые решения. Меня прям прет от этого.
На очереди вынесение части функционала из ядра, который медленно работает и тоже жрет много ресурсов. Руки чешутся его пересобрать.
Иии… Я на финишной прямой построения нормального горизонтального масштабирования. Осталось переделать немного Load Balancer и перезапустить и тадам. Когда доделаю инфру, постараюсь написать что я сделала и как.
На самом деле находила много годных статей на эту тему. Но все равно, у каждого свои боли, и не все можно найти в статьях. Я вроде уже ориентируюсь в AWS, но все же еще часто приходится повозиться, чтобы понять как сделать ту или иную штуку.
Вообще меня прет от того, что я не ощущаю собственных границ в плане возможностей. Могу и фронт, и бекенд, и инфру… Да, пусть, я не все знаю на супер-уровне, но любая проблема решаема: документация, stackoverflow, google, сообщества. И пофиг, что я раньше чего-то не делала или не знала, но я сажусь и пытаюсь разобраться, пытаюсь решить задачу. И все получается. Пусть не сразу, но все получается. Это кайфово.
Чудесный мир программирования, я люблю тебя ❤️ #Работа
Напишу тру-стори, которая меня прям порадовала.
Один из сервисов, который мне достался был тяжелым. С кучей зависимостей. Только для того, чтобы он поднялся требовалось ~5Gb RAM. Неповоротливый, медленный. В requirements 78 строчек. Tenserflow, natasha, nltk, pymystem3 и много другое. Подключение к бд на сыром sql, много неструктурированного кода, недокументированного, плохо читаемого. Он работал медленно, часто отвечал на запрос дольше 5 секунд. Надо было его оптимизировать, ускорять.
Закармливать этого монстра ресурсами не хотелось. Каким прожорой он будет, когда еще и нагрузка пойдет? Лезть в код было жутко, потому что слишком много всего. Я бы в нем разбиралась очень долго.
И я посмотрела на то, что вообще этот сервис делает и подумала, что вроде функционал нужен простой и в теории можно обойтись google api и встроенной библиотекой difflib. Сразу скажу, что я неправильно оценила необходимый функционал сервиса изначально. Но базовые требования к нему были поняты мной верно. Просто я не учла некоторых подводных камней, которые раскрылись в процессе.
В общем, я решилась на авантюру - переписать все с нуля. Как тот самый программист, который приходит и говорит - фу, надо все переделать)
Когда я начала переписывать, я нашла много неучтенных мной моментов. Что-то я также переписала в новом сервисе, чем-то пришлось пренебречь. Но за день я собрала новый сервис, который по сути выполняет 80% функционала старого. Работает сейчас на 200Mb оперативки. Чисто в теории его можно запустить на банальной lambda функции в AWS. Что я подумываю сделать, но меня смущает скорость ответа от google. Сейчас наблюдаю за тем, сколько в среднем требуется времени на отработку запроса. Но средняя скорость ответа сервиса - 1.1 секунда, из нее на google api приходится почти 100% :-P
Продакт качеством сервиса доволен. Говорит, что в целом отрабатывает не хуже, а в некоторых случаях даже лучше старого. Без nlp и вот этого всего. И бд, кстати, мне тоже не понадобилась.
Люблю я простые решения. Меня прям прет от этого.
На очереди вынесение части функционала из ядра, который медленно работает и тоже жрет много ресурсов. Руки чешутся его пересобрать.
Иии… Я на финишной прямой построения нормального горизонтального масштабирования. Осталось переделать немного Load Balancer и перезапустить и тадам. Когда доделаю инфру, постараюсь написать что я сделала и как.
На самом деле находила много годных статей на эту тему. Но все равно, у каждого свои боли, и не все можно найти в статьях. Я вроде уже ориентируюсь в AWS, но все же еще часто приходится повозиться, чтобы понять как сделать ту или иную штуку.
Вообще меня прет от того, что я не ощущаю собственных границ в плане возможностей. Могу и фронт, и бекенд, и инфру… Да, пусть, я не все знаю на супер-уровне, но любая проблема решаема: документация, stackoverflow, google, сообщества. И пофиг, что я раньше чего-то не делала или не знала, но я сажусь и пытаюсь разобраться, пытаюсь решить задачу. И все получается. Пусть не сразу, но все получается. Это кайфово.
Чудесный мир программирования, я люблю тебя ❤️ #Работа
Я поставила промежуточную точку в создании инфры для своего проекта.
Не скажу, что я сделала идеально, я не супер-специалист в этом, но хочу поделиться тем, что в итоге получилось.
Все развернуто на AWS. И далее будут сокращенные названия aws-сервисов. Если что, я очень многое подсмотрела на канале adv-it https://www.youtube.com/playlist?list=PLg5SS_4L6LYsxrZ_4xE_U95AtGsIB96k9.
Итак.
1. База данных postgres на RDS. Первый год использования 1 инстанс db.t2.micro бесплатный. Доступ к базе данных только внутри сети VPC. Извне нет возможности подключения.
2. Redis. Тоже вроде только первый год использования бесплатно 1 инстанс cache.t3.micro. Аналогично как и бд имеет доступ только внутри сети VPC.
3. Файловое хранилище S3. Для Django есть библиотека https://django-storages.readthedocs.io/en/latest/backends/amazon-S3.html. Для всего остального можно использовать boto3. В расходах у меня за ноябрь вышло 24 цента за s3. Там есть бесплатный уровень использования, но я его превысила. Посмотрю как дальше пойдет.
4. Реджестри для хранения докер-образов - ECR. У меня получилось 4 образа. За ноябрь вышло 1 доллар. Стоимость идет - 10 центов за GB-месяц. Надо понять как там автоматически удалять старые образы.
5. Дальше самое интересное - ECS - сервис управления контейнерами. Он задевает сразу несколько сервисов. Распишу примерный путь)
- в ECS создала пустой кластер.
- там же в Task Definitions завела на каждый контейнер отдельный конфиг задачи. К задаче привязывается контейнер и порт, на котором будет жить этот контейнер. (будем строить кораблик, который доставит контейнер в порт ^_^)
- Также в S3 в закрытый бакет положила файл .env, который прописан в настройках задач как файл для получения переменных среды.
- дальше в EC2 консольке завела Launch template для моего кластера. Для экономии взяла спотовые инстансы, которые продают со скидкой (непостоянные инстансы, которые могут отобрать в любой момент). Позже по необходимости сделаю базовый инстанс постоянный, а на масштабирование - споты. Важно, в Advanced details в user data прописать привязку инстансов к кластеру и для ecs настройку, что это спотовые инстансы:
Если не прописать настройку кластера, то инстанс не будет добавлен в кластер. Я на этом словила много недоумения.
Плюс обязательно указать нужную AMI. Я прям специально искала, что ecs использует ami-04e6179c63d17513d (это образ системы, которая будет развернута на инстансе).
Тут еще как оказалось не все типы инстансов поддерживают эту систему, поэтому надо выбирать внимательно.
- После иду создавать Auto Scaling group (ASG), где выбираю нужный шаблон. Load Balancer на данном шаге не привязывала.
- Для https и масштабирования я создала 2 application load balancer - internal (ходит внутри сети) и internet-facing (с выходом в интернет). Первый сделан для того, чтобы закрыть все сервисы из интернета. Доступ к ним будет только по локальной сети. Но при этом, при увеличении нагрузки балансер будет распределять ее между разными запущенными контейнерами по одному пути к сервису. Второй я прикрутила к nginx, в котором прописаны нужные пути до открытых сервисов. Плюс ко второму можно привязать бесплатный https сертификат от aws (создается через certificate manager).
- Дальше в кластере привязала ASG как capacity provider. Вот тут как раз можно будет отдельно сделать провайдера для одного постоянного инстанса, я думаю.
- Обновила кластер и сделала новый провайдер дефолтным.
- И последним пунктом в кластер завела сервисы, связанные в конфигами тасков на каждый сервис. Там в процессе заодно создала Target Group на каждый сервис.
6. Мой любимый CloudWatch для логов. Там несложно. Просто распихать все по нужным папкам.
7. Совсем забыла, еще sqs конечно же как брокер очередей. #AWS, #Работа
Не скажу, что я сделала идеально, я не супер-специалист в этом, но хочу поделиться тем, что в итоге получилось.
Все развернуто на AWS. И далее будут сокращенные названия aws-сервисов. Если что, я очень многое подсмотрела на канале adv-it https://www.youtube.com/playlist?list=PLg5SS_4L6LYsxrZ_4xE_U95AtGsIB96k9.
Итак.
1. База данных postgres на RDS. Первый год использования 1 инстанс db.t2.micro бесплатный. Доступ к базе данных только внутри сети VPC. Извне нет возможности подключения.
2. Redis. Тоже вроде только первый год использования бесплатно 1 инстанс cache.t3.micro. Аналогично как и бд имеет доступ только внутри сети VPC.
3. Файловое хранилище S3. Для Django есть библиотека https://django-storages.readthedocs.io/en/latest/backends/amazon-S3.html. Для всего остального можно использовать boto3. В расходах у меня за ноябрь вышло 24 цента за s3. Там есть бесплатный уровень использования, но я его превысила. Посмотрю как дальше пойдет.
4. Реджестри для хранения докер-образов - ECR. У меня получилось 4 образа. За ноябрь вышло 1 доллар. Стоимость идет - 10 центов за GB-месяц. Надо понять как там автоматически удалять старые образы.
5. Дальше самое интересное - ECS - сервис управления контейнерами. Он задевает сразу несколько сервисов. Распишу примерный путь)
- в ECS создала пустой кластер.
- там же в Task Definitions завела на каждый контейнер отдельный конфиг задачи. К задаче привязывается контейнер и порт, на котором будет жить этот контейнер. (будем строить кораблик, который доставит контейнер в порт ^_^)
- Также в S3 в закрытый бакет положила файл .env, который прописан в настройках задач как файл для получения переменных среды.
- дальше в EC2 консольке завела Launch template для моего кластера. Для экономии взяла спотовые инстансы, которые продают со скидкой (непостоянные инстансы, которые могут отобрать в любой момент). Позже по необходимости сделаю базовый инстанс постоянный, а на масштабирование - споты. Важно, в Advanced details в user data прописать привязку инстансов к кластеру и для ecs настройку, что это спотовые инстансы:
#!/bin/bash
echo ECS_CLUSTER=cluster-name >> /etc/ecs/ecs.config
echo ECS_ENABLE_SPOT_INSTANCE_DRAINING=true >> /etc/ecs/ecs.config
Если не прописать настройку кластера, то инстанс не будет добавлен в кластер. Я на этом словила много недоумения.
Плюс обязательно указать нужную AMI. Я прям специально искала, что ecs использует ami-04e6179c63d17513d (это образ системы, которая будет развернута на инстансе).
Тут еще как оказалось не все типы инстансов поддерживают эту систему, поэтому надо выбирать внимательно.
- После иду создавать Auto Scaling group (ASG), где выбираю нужный шаблон. Load Balancer на данном шаге не привязывала.
- Для https и масштабирования я создала 2 application load balancer - internal (ходит внутри сети) и internet-facing (с выходом в интернет). Первый сделан для того, чтобы закрыть все сервисы из интернета. Доступ к ним будет только по локальной сети. Но при этом, при увеличении нагрузки балансер будет распределять ее между разными запущенными контейнерами по одному пути к сервису. Второй я прикрутила к nginx, в котором прописаны нужные пути до открытых сервисов. Плюс ко второму можно привязать бесплатный https сертификат от aws (создается через certificate manager).
- Дальше в кластере привязала ASG как capacity provider. Вот тут как раз можно будет отдельно сделать провайдера для одного постоянного инстанса, я думаю.
- Обновила кластер и сделала новый провайдер дефолтным.
- И последним пунктом в кластер завела сервисы, связанные в конфигами тасков на каждый сервис. Там в процессе заодно создала Target Group на каждый сервис.
6. Мой любимый CloudWatch для логов. Там несложно. Просто распихать все по нужным папкам.
7. Совсем забыла, еще sqs конечно же как брокер очередей. #AWS, #Работа