Учеба

В целом все не так уж и страшно как казалось. Мой порыв прохождения вводных курсов оказался таки полезным. Кажется, большая часть первых двух модулей во многом совпадает в тем, что я уже прошла. Поэтому за три дня, я прогнала уже 4 недели математики и 5 недель программирования. Недели - это кусочки, на которые разбиты курсы на курсере. Модули универа также разбиты на недели с дедлайнами.

Решила продолжить и закончить еще курс гугла для инженера техподдержи, пока есть время. Наткнулась в нем на годноту в блоке про системное администрирование https://www.coursera.org/learn/system-administration-it-infrastructure-services . Одна из тем была управление изменениями. Чисто с точки зрения менеджера для меня ничего особенно нового, но вот реально, хотелось бы, чтобы в это умели и инженеры. Скопировала весь текст статьи на английском https://docs.google.com/document/d/1CNtrfJDAKzi24TlxZQx007wFUwrxf6YMEtXss43uJHk/edit?usp=sharing, если кому будет интересно.

Еще из интересного, не знала про команду script. Кажется, что она может реально пригодиться, полезная штука https://manpages.ubuntu.com/manpages/bionic/man1/script.1.html

Блин, так прикольно учиться 🙂 Обожаю онлайн формат! #Учеба, #Курсы

О бытовом
Поиск жилья оказывается очень долгим и тяжелым процессом, когда у тебя очень большой выбор. Мы посмотрели 27 квартир в 10 разных зданиях.
Сейчас прошла неделя с нашего переезда, интернет провели только в понедельник. До полноценного удобства еще далеко, но уже лучше, чем временное жилье.
Я стала как-то проще относится к тому, что мы снова здесь будем брать столы и мониторы для работы, так как это лучше, чем экономить и год страдать за маленьким экраном на неудобном столе.
Хочу поделиться немного условиями, в которых мы теперь живем. Это похоже на отель. На первом этаже огромный холл, где стоит кофемашина от Старбакса с очень приличным кофе, еще там же mailroom - комната для почты, плюс на входе сидит охрана и ресепшен отеля, который находится в этом же здании вроде бы. На 6 этаже большой бассейн, спортивный зал с кучей новых тренажеров, библиотека, барбекю зона, караоке, кафе и еще куча всяких ништяков. Еще один бассейн находится на самом верхнем 58 этаже. В доме все классно, только за доставками приходится спускаться вниз, так как без специальной карточки подняться на этаж не получится.
До школы примерно 1,5 километра. Мы идем к школе через 3 торговых центра. Это очень забавный путь, только из-за его наличия мы сняли жилье на таком расстоянии от школы. За 2-3 минуты можно дойти до первого тц и спуститься на -2 этаж, в котором есть проход к метро и от метро к другому тц (который по факту находится через дорогу, подземный переход такой получается). Во втором тц, не поднимаясь наверх проходишь мимо еще закрытых утром магазинов, но уже открытых киосков с кофе и завтраками, дальше к туннелю, который соединяет этот тц с океанариумом. Минут 10 идти по туннелю, не спеша. Потом выныриваешь на мгновение на улицу и поднимаешься на пешеходный мост, который ведет к третьему тц. Еще минут 10-15 и выходишь из третьего тц на улицу, где буквально через 100 метров находится школа.
Почему не ходить по улице? Когда на улице перманентные 30+ - это дико тяжело. Когда я ходила эту же дорогу по улице, я потом еще часа два приходила в себя.

О работе и учебе пока нечем особо поделиться. На выходных планирую засесть, наконец, за учебу.
Разве что хочу рассказать про инструмент, который коллега посоветовал мне ранее и я им прям прониклась - draw.io. Хорош для отрисовки схемы архитектуры. Тут тебе и направляющие и удобный ui, идеально! Удобно, что исходник диаграмм можно прям в репозитории хранить, плюс есть все нужные фигуры, иконки и тп. На днях рисовала схему работы на сервисах AWS, круто что все нужные сервисы нашла в поиске, не пришлось нигде еще бегать искать нужные картинки. #Жизнь, #Tools

Внимание задачка с подвохом.
Я сегодня узнала, что наше фронтенд приложение может быть вызвано post запросом с полезными для нас данными в теле запроса. Наше фронтенд приложение написано на React и мы используем react-router-dom. Само приложение находится в s3 bucket и работает через CloudFront. Сначала я узнала, что у нас стоит ограничение на post запросы, но это легко поправить. Потом я посидела и подумала, что это все же не имеет смысла. Как думаете почему? (Следующим постом постараюсь разъяснить)

Есть идеи как в этом случае поступить?
У меня уже есть мысли, но пока очень костыльные. Когда реализую в итоге что-нибудь, напишу что получилось.

UPD. Если что суть проблемы не сильно связана с сервисами AWS, скорее с тем как работает фронтенд (для тех, кто далек от AWS) #Работа, #JS

К предыдущему посту:

Когда думала про post запрос, в первую очередь захотелось порыться в документации роутинга на тему, а как же получать параметры запроса помимо тех, что в url. До меня правда не сразу дошло, что тело запроса недосягаемо для фронтового приложения.
Для тех, кто как и я, в танке:
⁃ Запрос приходит на сервер, который отдает просто html-страничку.
⁃ Браузер на основе html загружает js-скрипты и начинает их исполнять.
В итоге у js-приложения есть доступ только к тому, что в браузере (url, куки, локальные данные и тп).
Был бы у меня nginx для обработки статики, то можно было бы внутри его конфигов прям прописать обработку сценария для post запроса, чтобы данные из тела перенести в url.
Но у меня CloudFront, поэтому пришлось делать aws lambda function как прокси и внутри делать редирект. Впервые, кстати, прям осознанно писала ответ для редиректа. Узнала, что для этого просто необходимо указать корректный статус код и в заголовок добавить ключ Location с указанием нужного url, куда редиректим. Минус еще одно небольшое белое пятно в понимании.
Если немного точнее, то я только часть параметров из тела перенесла в url. Только те, что могут понадобиться самому фронтенду. А все, что для бекенда решила сохранить в DynamoDB.

Очевидно?!
Очевидно, что все вы… вот что очевидно!

Учеба

Блин, как же кайфово учиться онлайн! Каждый момент можно отследить свой прогресс и что еще предстоит изучить. Можно учиться как удобно, в том темпе, который нравится.
Математика идет со скрипом. Не потому что она сложная, а потому что не помню ничерта, базовые квадраты, кубы, синусы, косинусы, даже банальную таблицу умножения вспоминаю со скрипом. Пора распечатывать базовые таблицы и развешивать их как шпоры перед глазами, чтобы заново выучить.

Нет настроения графоманить. >_< #Работа, #JS, #Учеба

А вы знали, что чтобы получить научный калькулятор на айфоне, его надо повернуть? А чтобы получить функцию арксинуса и другие полезные функции, надо нажать кнопку 2nd? А на айпаде в принципе калькулятора нет?! #Tools

На днях обнаружила как логировать запросы в API GateWay (почитать можно тут https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-logging.html#set-up-access-logging-using-console). В общем, включила логирование для продакшн стейджа. А началось все с того, что я включила уведомления об ошибках на продовых стейджах для наших апишек, потому что не все наши функции и не все ошибки нам присылают в уведомления. Как-то от уведомлений я перешла к логам, а теперь и залезла в log insights, где сделала запрос с группировкой по пути запроса и статус-коду на количество запросов, среднем времени ответа, максимальном времени ответа и минимальном. Теперь у нас есть статистика запросов и ошибок. Офигеть! Проекту 4 года.
Продолжаю ковырять aws powertools https://awslabs.github.io/aws-lambda-powertools-python/2.16.2/
В текущей задаче решила задействовать их логику для роутинга, прописала модельки на основе пайдентик, сижу, наслаждаюсь прям. Где мы раньше были, когда писали свои велосипеды.
Еще узнала про утилиту aws sam для деплоя lambda functions, в текуших реалиях непонятно как ее применить на наших функциях, но копнуть точно стоит. Надо бы научиться ею пользоваться, потому что кажется, это довольно удобный инструмент деплоя.
Еще обнаружила, что логи в формате json хорошо парсятся с помощью log insights, надо перейти в логировании на логер powertools, который по умолчанию как раз логирует в нужном формате, плюс еще имеет кучу плюшек.
С каждой задачей оглядываюсь на предыдущий код и понимаю, что в этот раз получилось лучше, чем в прошлый. Еще лучше, еще лучше. И каждый раз немного стыдно за прошлый код.

Учеба.
Божечки-кошечки, практика программирования в универе - угар. Собери игрушку на JS. Для новичков, думаю, это конечно забавно, но малопонятно и, на мой взгляд, не слишком практично, так как даже не близко к реальным задачам.
Купила калькулятор для экзамена по математике, casio fx-991ex из списка допустимых (не все калькуляторы разрешено использовать на экзамене). Нашла плейлист с гайдами на него на 100+ видео. На калькулятор, Карл! Вообще кальк реально зверь, и в матрицы умеет, и в функции, и в таблицы и многое-многое другое.

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

Еще внезапный момент. Узнала, что у Luxoft есть офис в KL и они нанимают с оформлением местной рабочей визы. Хочу в Luxoft 🙂 Правда, не нашла у них вакансий на свой стек. Это не цель, конечно, но так было бы гораздо проще остаться здесь надолго, а мне тут и правда очень нравится. Хех. #UOL, #Учеба, #AWS, #Работа

#UOL, #Учеба

Мое новое рабоче-учебное пространство готово 🙂 Хоть у меня и не супер задротский стол, но, черт, у меня фетиш на красивые рабочие столы. Я прям тащусь от видео с сетами для организации своего места. Когда мне комфортно в своем кабинетике, я готова из него не вылезать вообще 🙂 #Жизнь

Начала писать midterm по математике, он является вроде курсовой работой. По требованиям надо сдать pdf с решениями задач (не только ответы). Это накладывает необходимость найти годный инструмент, где можно использовать латекс и потом экспортировать в pdf. Пока в поисках лучшего. Пробовала OneNotes, знаю, что можно использовать md, в том числе в colab или просто в юпитер ноутбуках. Сейчас пытаюсь ковырять в notion, у которого немного свой латекс. Пока ни один из этих инструментов не кажется достаточно удобным.
Еще нашла прикольный инструмент https://mathsolver.microsoft.com/. Он не просто решает задачки, но и отрисовывает графики, объясняя что куда и как.
Также в сообществе наткнулась на рекомендацию по изучению академического английского тут https://www.phrasebank.manchester.ac.uk/. Кажется, это весьма годно не только для студентов.
Божечки-кошечки, как же прикольно учиться сейчас.
Не нравится лектор? Пошла нагуглила все, что нужно в ютубе, нашла кучу статей по теме.
Но вот в плане расчетов все равно нет ничего удобнее старой доброй тетрадки. Считать, именно считать и решать уравнения все равно проще на бумаге, чем электронно, если не использовать автоматические решения. #Tools, #Учеба, #UOL

Воу-воу! Xmind замутил инструмент xmind copilot. Работает пока так себе, если честно, с точки зрения контента, это не сравнится с нормальными конспектами, но начало положено! https://xmind.ai/editor/
Если честно, то я уже привыкла к github copilot так, что даже не замечаю, что он есть. Это лучший уровень инструмента, когда кажется, что он уже стал частью тебя и ты его перестаешь замечать. Идеально.
И я очень рада, что xmind развивается, только где моя оч удобная их справка по латексу, хнык. Они переделали сайт и теперь я получаю 500 ошибку на этой страничке 🙁 #Tools

Постмортем упавшего прода. #Аниме

Ткнула совсем чутка в Google Cloud Functions и заметила, что у них версии языков посвежее, чем у AWS и можно настроить не только память, но и CPU, да и вообще настройки инстанса на входе кажутся более гибкими. Но, не проверяла все это в работе. Еще испытала приятные ощущения от осознания разницы моего начала работы с AWS и первого знакомства с интерфейсом Google Cloud (на самом деле не совсем первого, потому что я уже использовала Google Cloud API для распознавания речи и генерации речи из текста, но все же). Если тогда я ничего не понимала, что делают все эти настройки, как они работают и тп, то сейчас уже с легкостью ориентируюсь даже в другом интерфейсе. Хочется поглубже порыться в Google Cloud, но пока нет времени и проекта под это. На самом деле понимаю, что лучше бы сконцентрироваться пока дальше на AWS, но по сторонам ведь тоже неплохо смотреть?

Медленно, но верно продолжаю midterm по математике. Использовала по рекомендации тут https://www.overleaf.com, реально удобный инструмент. Заметила, кстати, что некоторые студенты тупо пишут на бумаге от руки, а потом фоткают и собирают из этого pdf. Но это же - ну такое… Над одной задачей просидела довольно долго из-за того, что напрочь забыла все варианты путей всяких разложений и упрощений выражений. На самом деле сложно назвать упрощением то, когда ты выражение вида a-b превращаешь в (a-b)*(a+b)/(a+b), чтобы можно было посчитать предел Оо и выяснить сходимость для ряда, заданного первым выражением. Зато, пока я гуглила все варианты проверок сходимости, разбиралась с тем, что мне предлагает чатгпт (неверные решения), я по истине начала понимать некоторую логику всего этого. Если честно, то пришлось купить WolframAlpha на месяц. Но считаю, что все это прям полезно, так как реально мозг начинает включаться и вспоминать все эти математические операции. Так, когда дойду до ML, глядишь и математику вспомню нормально.

Кстати, впервые воспользовалась студенческой скидкой при покупке вольфрама. Ыыы, я студентка, я реально студентка ХД. При чем для подтверждения статуса вроде просто ввела название вуза и все (?), не запомнила точно шаги, но никаких подтверждающих доков с меня не спросили.

На работе играюсь с потоками. Долго лочилась на одной просто фигне с этим. Написала код, залогировала время выполнения каждого блока, даже профилирование включила. Никак не могла понять почему запросы выполняются так медленно. Типа handshake по несколько секунд и тп. Даже получение данных из DynamoDB, которая должна отрабатывать моментально, происходило за секунды. Моему негодованию и недоумению не было предела. На очередном мите пожаловалась коллеге и он ответил - “ну да, потоки же прожорливы по ресурсам”! И тут меня прям осенило, память же, точняк. У нас все инстансы по умолчанию на 128 MB! Как только я докинула памяти, поигралась с ограничением количества воркеров для потоков все полетело как надо! Хы

С фронтом тоже забавно вышло, никак не могла понять почему у меня строка не разблокируется после обновления значения, влияющего на блокировку. Проверила все зависимости, пошла перечитать документацию про стейты в реакте, прошерстила весь код вдоль и поперек. Уже ни на что не надеясь, закинула код в чатгпт, задав вопрос про проблему. Поставь условие else для смены статуса блокировки - было мне ответом! Ха! Какая ж срань! Со школы страдаю такой фигней, когда глобально все сделаю ок, а вот какую-нить мелочь просто пропущу.

Отпуск. Я отработала год и гуляла всего 10 рабочих дней из 24 возможных. Но мне кажется, что я уже второй год живу в вечном отпуске, поэтому немного странно брать отпуск в отпуске? Но с другой стороны, копить отпуск - плохая затея. Поэтому придется отдохнуть хотя бы от работы.

И еще начинаю чет делать с LinkedIn на будущее, поэтому если есть желание - добавляйтесь в мою сеть, будем друг другу полезны https://www.linkedin.com/in/mandrianova/

PS. Сколько ж крутых тайтлов выходит в этом году - уиии! Жду-не дождусь новый сезон волейбола! #AWS, #Работа, #Учеба, #UOL

Еще в догонку, я вернулась на светлую тему. Неделю или две сидела на темной, но так и не смогла привыкнуть. Вроде не так уж и плохо, но все равно неудобно. Зато поняла, кажется, в чем реальная проблема глаз. Я последние несколько лет много читала с телефона. Это были не соцсети, а прям художественные книжки, которые я залпом глотала, читая каждую свободную минутку. И кажется, что именно это дало проблему с глазами. Вот уже несколько дней ничего не читаю. Вроде бы глазам стало полегче. #Жизнь

9 веток, 50 коммитов. Я завершаю работу над одной из очередных рабочих задач. И это еще не конец, потому что в самом конце я еще хочу поудалять старый код, который уже не востребован по этой задаче.
Хочу отрефлексировать этот опыт. У нас нет строгих процессов разработки, поэтому нет нужды декомпозировать задачи, хотя по-хорошему надо было это сделать. Но давайте сначала.
Исходная задача была буквально в несколько строк, к ней еще было привязано несколько, которые по факту являлись дополнительными фичами. По сути ядро бизнес-логики было сделано коллегами до меня, мне надо было взять это ядро, вынести в отдельный сервис и доработать его по условиям новых фичей. Кое-какая документация к ядру сохранилась в прошлых задачах, но описания к коду, как и его авторов, увы, не было. Но мне не привыкать разбираться в чужом коде, хотя в этой ситуации задача была со звездочкой, правда.
Так вот, что было.

Суть сервиса довольно простая - собрать данные из одного сервиса, обработать по определенным требованиям, показать пользователю и по запросу пользователя отправить в другой сервис. Осложняется это тем, что сбор данных происходит из нескольких источников, на каждую строку в таблице приходится делать несколько запросов. Маппинг некоторых данных задан не жестко, то есть это вручную созданные поля в системе-источнике. #Работа

Шаг 1. Вытащить логику сбора. У коллег маппинг данных был сделан очень хитрым способом с несколькими уровнями в виде словарей. Когда данные из источника сначала прогоняют по одному словарю, потом эти данные уже с новыми ключами прогоняют по другому словарю и все это было очень неочевидно. Много раз у меня возникало желание бросить все это, но это ж работа и ее надо делать. Этот шаг невозможно оценить, этот клубок мотаешь-мотаешь, а он никак не распутывается. Кое-какая документация, конечно, помогала, но не сильно.
Шаг 2. Прямо в процессе распутывания клубка я осознавала какие источники мне нужны и какие данные надо будет собрать. Это давало понимание, что мне надо будет доработать наш новый скелет работы с сервисом-источником. Мне надо было доработать модели и фабрики к ним. Тут я последовательно создавала отдельные ветки для обновления нашей базовой либы для работы с сервисом-источником. Если бы я этим занялась после того как полностью закончила шаг 1, то я могла бы точно прикинуть полный скоуп работ, но у меня не было целей составить строгий план. Я могла двигаться в свободном плавании, поэтому я работала в своем темпе. Я знаю, что хорошо было бы под каждую ветку создавать отдельную задачу, это бы оставило больше артефактов, но в данном случае я посчитала, что это необязательно, я просто оставляю readme с примером использования кода для новых функций. Кажется, что это полезнее, так как находится прям в репозитории.
Шаг 3. Помимо бекенда есть еще фронтовая часть, которая раньше жила прямо вместе с бекендом в виде html/js контента, зашитого прям в питонячьи скрипты. Кое-что, конечно, вынесено, но разбираться в файлах на тысячи строк не хотелось совсем. Фронт я собирала с нуля, заглядывая на то как это было у коллег в текущем интерфейсе.
Шаг 4. После того как я собрала базовую логику началась стадия проверки, где я уперлась в скорость работы. Дальше шла оптимизация, где я фактически полностью пересобрала всю бизнес-логику, потому что надо было максимально сэкономить, закешировать то, что можно закешировать.
Шаг 5. Еще в процессе проверки обнаружились некоторые особенности взаимодействия (мой пост про пост-запрос за фронтендом), из-за которых пришлось еще мутить дополнительный сервис (прокся). Тоже было бы логично вытащить это в отдельную задачку.
Шаг 6. Фичи! Да, в самом конце на всю эту базу, я как на новогоднюю елку уже с большим удовольствием навешивала те самые фичи, ради которых по сути все и затевалось. Это мой самый любимый шаг. Реально доставляет кайф, когда видишь как быстро и изящно можно добавить функционал на базовый скелет.
Шаг 7. Ради одной из фичей пришлось еще отрефакторить еще один существующий сервис, но его писала я, поэтому прошло все довольно быстро. Я просто оптимизировала его, переделала под новый вариант нашей архитектуры и добавила фичу для частичной обработки, вместо полной.

Можно ли было разделить эту задачу? На самом деле 7 из 9 веток уже в основной ветке. Я их делала, сразу отправляла на ревью и мержила, чтобы не держать в себе. Это все ветки, кроме последнего шага, в которых были доработки, не касающиеся основного разрабатываемого сервиса. Можно было и 7 шаг засунуть в отдельную ветку и выпустить ее раньше, но так как я уже понимала, что подхожу к финалу, плюс это не так критично, поэтому оставила его внутри основной ветки задачи.

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

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

Как же меня заманала эта задача! Ура, наконец-то финал. Я люблю свою работу очень сильно! 🙂 #Работа

Импорты в python. Много раз от знакомых видела вопросы про проблемы с импортами в python. Чаще всего они не возникают, если не менять уровень директории для запуска скрипта. То есть если у вас проект от корня, то с импортами будет все в порядке. Однако, сейчас я работаю на проекте, где все сервисы лежат в одном репозитории. Получается, что на сервере запуск идет от корня сервиса, а на локальной машине от корня репозитория (на уровень выше).

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

Самое интересное, что в тестах к этому сервису был хук импортов, который добавлял директорию сервиса к python путям, а внутри сервиса все импорты были прописаны как абсолютные. Когда я открывала этот сервис в pycharm, у меня были кровавые слезы при взгляде на эти импорты, потому что интерпретатор грустил. Можно было бы, конечно, в настройках проекта также указать эту папку как пакет, но это костыль.

Как же я давно мечтала исправить этот сервис. Как же у меня свербило от него. И вот вчера я добралась до него!
Убрала этот конфиг, прописала в settings файл все условия в зависимости от стейджа. Основные доступы и прочие защищенные данные я уже давно перетащила в SecretManager, поэтому с этим проблем не было. Попутно поправила кое-что для других сервисов, которые использовались в этом (обновила код в репозитории, потому что расходился прод-код и код в репе, обновила название одного из сервисов под наш стандарт и тп). И вот добралась до импортов. Быстренько подменила абсолютные пути на относительные и раскатала скриптом новую версию на тестовом стейдже. И… ничего не заработало. Получила ошибку импортов, что вылезаю на слишком высокий уровень с помощью относительных импортов. Сначала я решила перебрать структуру проекта, потому что там было много такого from module import *. Плюс система вложенности отчасти нелогичная, плюс связность между модулями высокая. Но все мои попытки соптимизировать все равно выдавали одну и ту же ошибку с импортами. Что же…

Я не хотела откатываться назад. Я не хотела сдаваться. Стаковерфлоу, документация, ничего не помогало. Но я отчаянно хотела найти решение для нашей задачи, так как реально часто хочется сделать нормальную структуру сервиса, а не получается из-за разного уровня запуска на локальной машине и сервере.

Моей палочкой-выручалочкой стал ответ чатгпт. Вот по истине приятно обсудить проблему с машиной. Ее можно применять как продвинутую уточку, так сказать. Ничего сильного нового она мне не посоветовала, но в конце написала мысль:
“To fix this issue, you should refactor your code to either use absolute imports where appropriate, or restructure your package so that relative imports do not need to go beyond the top level package.”

И тут меня осенило! Я базовый входной файл (у меня это lambda_function.py с обработчиком для событий) вынесла в корень сервиса, а остальное завернула в общую директорию, таким образом убрав все скрипты с относительными импортами с верхнего для сервиса уровня. В корневом скрипте же вполне ок работают абсолютные пути.

Божечки-кошечки, все завелось!

Ня! А коллег ждет кошмарный пул-реквест… Но это лучше, чем предыдущее состояние этой функции.

А еще я сдала midterm вчера, ура! 19 страниц, 686 строк latex кода! Вжух! #Python, #Работа

Словила тут очень интересный баг в чужом коде. Рассказываю схемку.

class Parent:
 def func():
  pass

@converter(scheme: Dict[str, callable])
class Children(Parent):
 def func():
  pass

Не буду выкладывать код конвертера, но суть его логики была в том, что он брал все методы родителя и оборачивал их в соответствии со scheme, где в ключе указывалось название метода, а в значении функция, которая обработает результат в нужном формате. А потом он эти методы присваивал в соответствии с названием дочернему классу.

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

И что самое забавное, место, где возникала ошибка никак не логировалось. Там было нечто вроде:

try:
 children.func()
except Exception as err:
 return f“Все пошло к херам {err}”
    )

Классно, да?
Используйте logger.exception(“все пошло к херам”), так вы хотя бы получите трейс исключения.
Изначально ошибку нашла путем поиска по коду текста ошибки. Добавила логов, потом увидела то, что пишут логи и очень удивилась, что вместо дочерней функции, почему-то отрабатывала функция родителя. Вот это поворот! Потом нашла этот чертов декоратор и долго тупила над его кодом, потому что - “что блин прости ты делаешь, серьезно?”. На самом деле хочется выпилить этот декоратор, но пока лишь пофиксила его логику, чтобы он использовал дочерний метод (если он существует) для обертки вместо родительского. Что за дичь, а?

И нет, я тоже допускаю ошибки в коде, иногда очень глупые. Я тоже иногда пишу диковатый код. Но такие хаки у меня вызывают крайнее недоумение. Типа вместо использования ООП сделать декоратор, который сломает логику ООП, это надо исключительно постараться. #Работа, #Python

Я сегодня испробовала AWS SAM для работы со своим привычным стеком технологий. Сделала пока только базовый каркас из API Gateway, lambda function и основной обвязки. Планирую еще докрутить к этому sqs, DynamoDB и прочие ништяки.

Суть в чем. Это так прекрасно, что несмотря на сложности сбора корректного конфига, я с самого начала верещала от восторга от этой утилиты.
0. Установила sam cli
1. Открыла в pycharm новый проект, сразу на базе шаблона под aws sam, который базово создал мне структуру и конфиги.
2. Потом была очень долгая отладка конфига под мои нужды. Я никогда раньше не работала с aws cloudformation толком, если не считать там-сям небольшие конфиги. А тут пришлось прям погрузиться и разобраться.
3. Локальный запуск. Команда sam local start-api запускает докер-контейнер на базе конфигурации, который полностью локально имитирует окружение для функций и их эндпоинты на api gateway. Это позволяет развернуть все эти облачные ништяки на локальной машине и полноценно проверить работоспособность. Как же это хорошо. Как я соскучилась по нормальному локальному запуску, потому что привыкла уже проверять на тестовом окружении. Мне не хватит слов, чтобы передать весь кайф от такой банальной штуки как нормальное локальное окружение и полноценная автоматизация.
Теперь меня внутренне съедает мысль, что повторить такое для рабочего проекта будет крайне трудно из-за некоторых ограничений в доступах.
После всех костылей и возни с настройками деплоя я в таком астрале от этого инструмента, что я заново влюбилась в serverless архитектуру и aws сервисы. Мне все это и так нравилось, но скорее часто вопреки всем проблемам, с которыми я сталкивалась, но тут прям лавина радости и кайфа. Логи как в cloudwatch из lambda function, запущенной на локальной машине, вызвали у меня сегодня бабочки в животе, правда:

REPORT RequestId: 8bc17eab-90a0-4454-ad04-bba6a959e530 Duration: 2.86 ms Billed Duration: 3 ms Memory Size: 128 MB Max Memory Used: 128 MB

(Эта запись генерится автоматически при завершении работы функции без фактического логирования в коде, это часть обертки aws, поэтому к коду функции оно совсем не имеет отношения и нужен специальный контейнер, который имитирует обертку aws для lambda function, чтобы получить такой лог на локальной машине. Как раз всей этой оберткой занимается aws sam).

Как же я обожаю такие вещи. Тонна удовольствия.

Уйти в программирование - было лучшим решением в моей жизни. Хоть ведение технически сложных проектов будучи менеджером мне тоже очень нравилось, но тут это все гораздо глубже и гораздо интереснее. Придумывать архитектуру, искать оптимальное системное решение, разбираться в очередной технологии/инструменте - это восторг.
Лучи добра всем и удачи в своих проектах. #AWS

Эстетика учебы в универе, современность.
Меня так прут современные инструменты! Открыла pdf на ipad учебник, захотела вставить фрагмент в конспект, выделила, скопировала и на маке вставила. Уруру. Закладки, выделения, красивые книжки с цветными графиками. Сама себе завидую :) #Математика, #Учеба, #UOL

На экзамене по математике можно использовать только одну страничку для черновиков. Оо 1 страничку на 4 часа экзамена по математике… Блин, они реально стебутся что ли?
UPD. Плохо не знать английский на хорошем уровне и учиться на нем. Как мне подсказали речь о шпаргалке, а не о черновике. А это значит, что все очень даже неплохо! Спасибо! Обожаю вас! #Математика, #Учеба, #UOL