Меня, как и автора, больше всего беспокоит отсутствие в JS какой либо спецификации у сущностей — модулей, классов, объектов. Т.е. не до конца понятно какие у них свойства и методы и как с ними работать. И да, это в конечном счете упирается в проблему сопровождения проекта. Т.е. по сути что TS что Dart дает нам такую спецификацию на уровне классов и интерфейсов.
Но в динамический языках существует другая практика TDD — spec файлы, т.е. файлы спецификации модулей и классов, которые являются чистыми юнит-тестами. Эти тесты должны быть максимально просты и очевидны. Такие файлы сразу дают явную рабочую спецификацию модуля или класса и примеры работы. Так что это проблема вполне решаема административными мерами — просто каждый модуль должен иметь спецификацию.
А все остальные проблемы вполне решаемы стандартными методами: gulp + requirejs(browsify) + strict mod + jshit(lint).
Ну и код ревъю для крупного проекта никто не отменял, независимо от того на чем вы пишете хоть на Dart хоть на C++
Очень интересно.
Хорошо бы ваш такой богатый опыт оформить это в виде статьи «Как правильно готовить ZMQ», а то в zguide не так много таких нюансов описано.
На счет идентии не знал, спасибо. Наверно по правилам надо перегенерить идентити при перезапуске. Тогда не должно быть проблем, и не нужно тормозить кластер(я правда не уверен. что тогда ликов конекшенов не будет)
Хеартбит и уведобления о доставки — это да, нужно обязательно. тут разработчики не скрывают.
На счет диагностики тоже согласен, это ужасно раздражает и напрягает. Я уже думаю — а не написать, ли пач zmq (или форк сделать) в котором была-бы прикручена диагностика. В принципе это не сложно реализовать.
И если не секрет — а в проде клиенты и сервисы на чем бекенд написан?
Это просто хардкор какой-то. Все гораздо проще — купите нормальные вентиляторы
Если денег нет — то китайские типа deepcool.
Если есть то Noctua, Scythe ну и зальманы с термолтейками тоже есть. Короче выбор нормальный тихих вентиляторов достаточно большой.
Не инъекции — а библиотеки и «костыли» которые надо устанавливать и поддерживать. Лучше просто примеры. Строгая динамическая, моя ошибка. Имел ввиду статическая.
Fake — класс-фальшивка, так обычно пишут в примерах. Никак не связан.
Короче в пайтоне проблем с инъекцией нет — вам нужно, делайте хоть к классу, хоть к инстансу. И многие так делают, когда это надо — это python way и в этом нет никаких проблем или сложностей.
И да, было бы наверно более интересно обсудить эти методы и рецепты.
Я не против DI. Я к тому что для этого особых фреймворков в питоне не нужно и все реализуется достаточно тривиально. По поводу глобальной инъекции уже указали на конфиги как самое простое и очевидное решение.
Типизация как раз и приводит к высокой связанности. На пайтоне можно писать вообще без типов и внешних связей и делать инекцию атрибутов по мере выполнение(пример выше с юзером) — это уже само по себе DI.
По моему тут просто нужно показать простые и тривиальные методы реализации DI и решения. Тогда было бы более понятно что и для чего.
Я к тому, что на питоне эта задача достаточна тривиальна (если она действительно нужна) и решается одним методом в 5 строк:
class Container:
def __init__(self, system_data):
for component_name, component_class, component_args in system_data:
if type(component_class) == types.ClassType:
args = [self.__dict__[arg] for arg in component_args]
self.__dict__[component_name] = component_class(*args)
else:
self.__dict__[component_name] = component_class
В статье не хватает примеров и не показана использование инъекции внутренних объектов в локальной области (иначе задача вообще тривиальная, и сводиться к использованию глобального конфига) из за этого и возникло непонимание. Т.е. если нужен глобальный инжекшн то конфигов вполне достаточно.
Так же не показан в общем метод реализации автора, в чем его смысл.
Потому что все DI библиотеки пытаются решить проблему инъекции внутри класса. У питона такой проблемы не существует.
class User(object):
db = Fake() # db connection
def do_some():
do.save(True)
.....
User.db = RedisDb('localhost:1234') # explicit injection or 'setattr' can be used for text based config files
user = User()
user.do_some() # the redis db is used
Поэтому используя парадигмы других языков вы пытаетесь решить несуществующую проблему в питоне. Нравиться DI — используй ее на здоровье.
Вы должны проникнуться духом пайтона, почувствовать его рантаймовскую природу. Она отличается от природы декларативных языков.
А если серьезно — в питоне это не нужно, потому как ту отсутствует строгая типизация, и бороться с ней с помощью инъекций бессмысленно. Это только порождает дополнительную сложность, а это не python way, на мой взгляд.
Как уже указали выше — простые конфигурационные файлы вполне достаточны. По примеру джанги, где в сетингах указываешь различные классы и никаких зависимостей.
Кроме этого можно пачить классы в рантайме, по примеру гевентов, без проблем!
Очень похоже на мой случай но мне хватило понять все с первого раза, потратил пол года, если не больше, не жалею. С выводом согласен на 100% — для успешного выхода в паблик должен быть очень тщательно проработан геймдизайн, оформление и уникальность. Без этого все уйдет шлаком.
А вообще геймдев это фан, прежде всего для разработчика и вы сами должны испытывать удовольствие от процесса создания игры. А финансовый вопрос — это как повезет.
Удачи вам! :)
Но в динамический языках существует другая практика TDD — spec файлы, т.е. файлы спецификации модулей и классов, которые являются чистыми юнит-тестами. Эти тесты должны быть максимально просты и очевидны. Такие файлы сразу дают явную рабочую спецификацию модуля или класса и примеры работы. Так что это проблема вполне решаема административными мерами — просто каждый модуль должен иметь спецификацию.
А все остальные проблемы вполне решаемы стандартными методами: gulp + requirejs(browsify) + strict mod + jshit(lint).
Ну и код ревъю для крупного проекта никто не отменял, независимо от того на чем вы пишете хоть на Dart хоть на C++
Хорошо бы ваш такой богатый опыт оформить это в виде статьи «Как правильно готовить ZMQ», а то в zguide не так много таких нюансов описано.
На счет идентии не знал, спасибо. Наверно по правилам надо перегенерить идентити при перезапуске. Тогда не должно быть проблем, и не нужно тормозить кластер(я правда не уверен. что тогда ликов конекшенов не будет)
Хеартбит и уведобления о доставки — это да, нужно обязательно. тут разработчики не скрывают.
На счет диагностики тоже согласен, это ужасно раздражает и напрягает. Я уже думаю — а не написать, ли пач zmq (или форк сделать) в котором была-бы прикручена диагностика. В принципе это не сложно реализовать.
И если не секрет — а в проде клиенты и сервисы на чем бекенд написан?
Если денег нет — то китайские типа deepcool.
Если есть то Noctua, Scythe ну и зальманы с термолтейками тоже есть. Короче выбор нормальный тихих вентиляторов достаточно большой.
И установите программу регулятор оборотов по типу:
www.almico.com/speedfan.php
И будет вам счастье без перегрева!
1. Берешь сайт-конкурента
2. Нагоняешь трафика 3000 ботов
3. Пишешь в раскомнадзор кляузу
4. Сайт конкурента штрафуют-закрывают
5. ПРОФИТ!
Короче в пайтоне проблем с инъекцией нет — вам нужно, делайте хоть к классу, хоть к инстансу. И многие так делают, когда это надо — это python way и в этом нет никаких проблем или сложностей.
И да, было бы наверно более интересно обсудить эти методы и рецепты.
В примере с контейнером как раз показана DI
Типизация как раз и приводит к высокой связанности. На пайтоне можно писать вообще без типов и внешних связей и делать инекцию атрибутов по мере выполнение(пример выше с юзером) — это уже само по себе DI.
По моему тут просто нужно показать простые и тривиальные методы реализации DI и решения. Тогда было бы более понятно что и для чего.
Оригинал: Inversion of Control
В статье не хватает примеров и не показана использование инъекции внутренних объектов в локальной области (иначе задача вообще тривиальная, и сводиться к использованию глобального конфига) из за этого и возникло непонимание. Т.е. если нужен глобальный инжекшн то конфигов вполне достаточно.
Так же не показан в общем метод реализации автора, в чем его смысл.
Поэтому используя парадигмы других языков вы пытаетесь решить несуществующую проблему в питоне. Нравиться DI — используй ее на здоровье.
Вы должны проникнуться духом пайтона, почувствовать его рантаймовскую природу. Она отличается от природы декларативных языков.
А вообще хороший ответ по теме на стековерфлове: Why is IoC / DI not common in Python
А если серьезно — в питоне это не нужно, потому как ту отсутствует строгая типизация, и бороться с ней с помощью инъекций бессмысленно. Это только порождает дополнительную сложность, а это не python way, на мой взгляд.
Как уже указали выше — простые конфигурационные файлы вполне достаточны. По примеру джанги, где в сетингах указываешь различные классы и никаких зависимостей.
Кроме этого можно пачить классы в рантайме, по примеру гевентов, без проблем!
А вообще геймдев это фан, прежде всего для разработчика и вы сами должны испытывать удовольствие от процесса создания игры. А финансовый вопрос — это как повезет.
Удачи вам! :)
— А что там у вас с Дубной?
— Она утонула.
— !!?
На сколько я знаю, раньше использовали трансформаторное масло.