Как правило pet проекты смотрятся не на собеседовании(иначе оно сильно растянется). Я смотрю до собеседования, верхнеуровнево смотрю логику и кодстайл, прикидываю будет ли такой проект понятен другим программистам из команды. Могу на самом собеседовании задать доп вопрос по пет проекту если что то заинтересовало или что то было непонятно
т к определение junior у всех разное, то специально описал минимальные требования к junior позиции
по росту до middle: сотрудник на этой позиции должен уметь самостоятельно вести проекты(только по архитектурным вопросам обращаясь к сеньёрам и техлиду), иметь опыт выполненных с нуля проектов. При расписывании задач middle не должен требовать слишком мелкие детали - их он проработает самостоятельно, и при необходимости на код ревью защитит перед старшими товарищами. Оттачивание этих навыков начинается на четвёртом этапе, в конце испытательного - когда сотруднику дадут новый проект либо скажут значительно модифицировать текущий. Эту задачу он будет так же выполнять вместе с наставником, но цель - делать это максимально самостоятельно, обращаясь только по ключевым или архитектурным вопросам.
так же middle должен хорошо знать свой текущий проект и уметь его лить в прод - эти навыки сотрудник получает на третьем этапе
Согласен возможно выбранный пример слишком простоват, и надо в первой итерации усложнить пунктами выше, а после этого уже переписать на react и оценить полученный опыт
с помощью библиотеки aioamqp: https://aioamqp.readthedocs.io/en/latest/api.html?highlight=publish#publishing-messages в рамках проекта с boilerplate используется в функции consume_handler, когда нужно перекинуть сообщение с ошибкой в очередь с авторазбором пример кода(канал уже поднят): await channel.publish(payload=body, exchange_name='exchange', routing_key='routing_key')
данный кусочек на отдельную статью не тянет, может мимоходом упомяну в какой нибудь будущей публикации
Спасибо за подробное разъяснение.
Были идеи по удалению коннекта из функций модели. Но на aiopg это не очень удобно реализовывать. В новых проектах попробую реализовать эту логику через библиотеку databases.
Возможно у Вас есть примеры кода, в котором описанная выше логика реализована?
Данная обёртка и полноценная ORM — разные вещи
В данном случае используется SQLAlchemy Core, он хорошо оттестирован, и обёртка нужна для уменьшения кол-ва кода и большей читаемости запросов
спасибо за подробный ответ!
В планах — попробовать асинхронную алхимию на одном из новых некритичных сервисов, и если она себя хорошо покажет — можно тиражировать этот опыт.
Но я думаю что ORM не подойдёт для сложных нагруженных сервисов, т к для разработчика не всегда понятна как она построит тот или иной запрос и не «положит ли бд» в каких то граничных случаях. Запросы без ORM гораздо проще прогнозировать и проверять через explain
Я указал этот момент в разделе «Сравнение с остальными ОРМ».
Сейчас в документации описано что это beta версия. Нужно какое то время подождать исправления всех проблем, на данный момент использовать эту версию с привязкой к asyncio рискованно
Как правило pet проекты смотрятся не на собеседовании(иначе оно сильно растянется). Я смотрю до собеседования, верхнеуровнево смотрю логику и кодстайл, прикидываю будет ли такой проект понятен другим программистам из команды. Могу на самом собеседовании задать доп вопрос по пет проекту если что то заинтересовало или что то было непонятно
т к определение junior у всех разное, то специально описал минимальные требования к junior позиции
по росту до middle:
сотрудник на этой позиции должен уметь самостоятельно вести проекты(только по архитектурным вопросам обращаясь к сеньёрам и техлиду), иметь опыт выполненных с нуля проектов. При расписывании задач middle не должен требовать слишком мелкие детали - их он проработает самостоятельно, и при необходимости на код ревью защитит перед старшими товарищами. Оттачивание этих навыков начинается на четвёртом этапе, в конце испытательного - когда сотруднику дадут новый проект либо скажут значительно модифицировать текущий. Эту задачу он будет так же выполнять вместе с наставником, но цель - делать это максимально самостоятельно, обращаясь только по ключевым или архитектурным вопросам.
так же middle должен хорошо знать свой текущий проект и уметь его лить в прод - эти навыки сотрудник получает на третьем этапе
полностью согласен с вами
описал это в четвёртом пункте(этапе), чтобы не загромождать каждый пункт "необходимостью получения ОС"
про незамыленный взгляд - действительно помогает понять куски системы, сделанные слишком сложно, и планировать рефакторинг
в черновиках так статья и называлась, видимо я неправильно перенёс на хабр название
поправил, спасибо :)
Согласен
возможно выбранный пример слишком простоват, и надо в первой итерации усложнить пунктами выше, а после этого уже переписать на react и оценить полученный опыт
интересный подход к оценке, спасибо)
спасибо за ссылку на интересную статью :)
спасибо что отписали, такой метод тоже часто используем, он хорошо ложится в статью
спасибо за подробное описание!
с помощью библиотеки aioamqp: https://aioamqp.readthedocs.io/en/latest/api.html?highlight=publish#publishing-messages
в рамках проекта с boilerplate используется в функции consume_handler, когда нужно перекинуть сообщение с ошибкой в очередь с авторазбором
пример кода(канал уже поднят):
await channel.publish(payload=body, exchange_name='exchange', routing_key='routing_key')
данный кусочек на отдельную статью не тянет, может мимоходом упомяну в какой нибудь будущей публикации
А что подразумевается под producer? Отправка сообщений в очередь(consumer/producer)? Или вопрос про продолжение?
Были идеи по удалению коннекта из функций модели. Но на aiopg это не очень удобно реализовывать. В новых проектах попробую реализовать эту логику через библиотеку databases.
Возможно у Вас есть примеры кода, в котором описанная выше логика реализована?
В данном случае используется SQLAlchemy Core, он хорошо оттестирован, и обёртка нужна для уменьшения кол-ва кода и большей читаемости запросов
В планах — попробовать асинхронную алхимию на одном из новых некритичных сервисов, и если она себя хорошо покажет — можно тиражировать этот опыт.
Но я думаю что ORM не подойдёт для сложных нагруженных сервисов, т к для разработчика не всегда понятна как она построит тот или иной запрос и не «положит ли бд» в каких то граничных случаях. Запросы без ORM гораздо проще прогнозировать и проверять через explain
Сейчас в документации описано что это beta версия. Нужно какое то время подождать исправления всех проблем, на данный момент использовать эту версию с привязкой к asyncio рискованно