Часто вижу, что требования в вакансиях - это либо копипаст из других описаний, либо довольно общие и не всегда отражают реальность
Как кандидат, я бы хотел понимать, чем конкретно предстоит заниматься, а не угадывать это по ключевым словам. Если у компании есть нормальное, живое описание задач - его можно использовать для анализа (например, через мою тулзу) и получить реально полезный результат с точки зрения найма.
А если такого описания нет то его стоит написать хотя бы в общих чертах. В итоге выигрывают обе стороны: кандидат лучше понимает, куда идет, а компания -кого ищет.
Мне кажется что у либы требует нетипичного подхода, который может развиться только после написания на ней проектов 2-3 на ней + ее больно дебажить
По ней бы пригодился хороший гайд по струтуре сложных приложений, с кучей вьюх и лейаутов (типа project layout), но из вариантов только смотреть их examples и чужие репы с большими приложениями.
Но мне очень понравилась ее гибкость и то как она заставляет голову думать об организации кода, эдакий мини челенж))
это стандартный подход достаточно, он удобен и я не пытаюсь с ним бороться, но все проблемы которые я перечислил - применимы к нему, я сам таким всегда пользовался
можно пример API ? не очень понял, как должно выглядеть добавление новыого поля или просто как будет выглядеть конфиг с несколькими опциями конфигурации, по тексту не очень понимаю чем это от koanf отличается
можно добавить и etcd, но не в динамическом режиме, пакет проектирован так что ключи выставляются один раз вызовом метода Parse и больше его вызывать нельзя
я буду рад более конструктивной критике)
FAANG и так использует подобные инструменты - интегрированные в их hr flow, но спасибо за совет
неа, в будущем если популярность его будет и запрос - то добавлю конечно
но пока только текст
Часто вижу, что требования в вакансиях - это либо копипаст из других описаний, либо довольно общие и не всегда отражают реальность
Как кандидат, я бы хотел понимать, чем конкретно предстоит заниматься, а не угадывать это по ключевым словам. Если у компании есть нормальное, живое описание задач - его можно использовать для анализа (например, через мою тулзу) и получить реально полезный результат с точки зрения найма.
А если такого описания нет то его стоит написать хотя бы в общих чертах. В итоге выигрывают обе стороны: кандидат лучше понимает, куда идет, а компания -кого ищет.
насколько я видел в сторонних либах (они в репе баблти указаны) есть overlay view, возможно это то что нужно:)
не очень люблю cli на пайтоне, накатываешь кли приложение, а с ним зависимостями python 3.10 какойнибудь выкачивается)
Мне кажется что у либы требует нетипичного подхода, который может развиться только после написания на ней проектов 2-3 на ней + ее больно дебажить
По ней бы пригодился хороший гайд по струтуре сложных приложений, с кучей вьюх и лейаутов (типа project layout), но из вариантов только смотреть их examples и чужие репы с большими приложениями.
Но мне очень понравилась ее гибкость и то как она заставляет голову думать об организации кода, эдакий мини челенж))
как то так будет выглядеть подобная логика на зероконф
только в зероконф нужно обявлять опции конфигурации в пакете где она применяться, а не в одном файле
тут с точки зрения использования
- кобра - для кли - юзер взаимодействует с --help
- zerocfg - конфигурация приложения, юзер взаимодействует с кодом
мне кажется что для депрекейта достаточно коммента в коде
это стандартный подход достаточно, он удобен и я не пытаюсь с ним бороться, но все проблемы которые я перечислил - применимы к нему, я сам таким всегда пользовался
можно пример API ? не очень понял, как должно выглядеть добавление новыого поля или просто как будет выглядеть конфиг с несколькими опциями конфигурации, по тексту не очень понимаю чем это от koanf отличается
он в апи похож на viper, мне такое апи кажется бойлерплейтным, однако вплане количества источников у него нет равных и либа koanf хороша в этом плане
можно иметь yaml \ env + os.SetEnv и использовать встроенные парсеры env и yaml
можно имплементировать mockSource конфигурации и его использовать, либа в этом плане достаточно гибкая
но как мне кажется нужно decoupling делать конфига и тестируемого кода
деприкейта нет, не очень понимаю как и для чего его стоит реализовавыть?
\\ Depricated на опцией в коде ведь можно указать, или это про рендер конфигурации чтобы там был варн?
префикс для энвов сейчас нельзя, но это вопрос 3 строчек кода, просто руки еще не дошли, поскольку дополировываю код основного пакета
несуществующие знания триггерят ошибку UnknownFields.. (для энв парсера она не триггерится только)
в статье про это есть, можно найти по ключ слову
IsUnknown
Спасибо за вопрос,
я не проектировал пакет под live-reload, он привносит немало болейрплейта как по мне при подходе моем подходе к определению конфигурации.
думаю хорошим вариантом будет какраз viper для вас
можно добавить и etcd, но не в динамическом режиме, пакет проектирован так что ключи выставляются один раз вызовом метода Parse и больше его вызывать нельзя
Спасибо, дополнил)
я в статье старался пройтись по истокам возникновения идеи сделать и не вдаваться в детали, обойтись простыми примерами, чтобы читать было проще:)
спасибо за фидбек:)
я изначально хотел zeroconf, но изза совпадения названия с технологией сделал zerocfg
а в целом название референсит zerolog
спасибо, поправил