Не зарабатываю на жизнь майкой, могу иметь ошибочное представление. Но не знаю, в каком ещё пакете кроме гудини флюиды лучше, чем в майке. Они и раньше были более менее, но после интеграции бифроста можно забыть про realflow. Разве нет!?
P.S. Realflow и Phoenix FD я не рассматриваю, так как это не пакеты общего назначения.
Что-то вы в один ряд поставили продукты с разными задачами. Гуди используется для процедурной анимации и генерации. Персонажей в нём не лепят. Сильная сторона Maya — анимация, риггинг, флюиды. Если речь о моделлинге, то тут макс, модо, блендер. Если моушн графика, то раньше синема4д, сейчас процедурные ништяки и в майку подвезли. Если речь об архивизе, то тут только Макс. Скульптинг — блендер, зебра, 3д коат, мад бокс. То есть, практически у каждого продукта своя ниша.
Но если говорить про лайтвэйв… Можете назвать студии, которые используют lightwave? Под него даже vray нет (хотя это один из основных рендеров в студиях).
Вы точно только на половину в режиме троля написали?
Знания — однозначно сила. А вот в какой цвет вы эту силу окрасите, зависит от вас.
Завтра попробую пул реквесты поотправлять с предложениями об улучшении кода.
Думаю, мне удастся показать, как избавиться от globals и сделать код стройным и понятным не только интерпретатору.
зачем вам методы setXXX и viewXXX? Почему не обращаться к полю непосредственно? В питоне же всё открыто, подобное сокрытие не имеет смысла.
И ещё, попробуйте отделить данные от представления. Пусть данные хранятся в массиве (списке) как целые числа. Откажитесь от класса Pole. Вам не нужно у каждой клетки иметь список соседних (это легко подсчитать и так). Как вариант — вообще отказаться от массива всех ячеек. Можно иметь лишь список с координатами бомб.
Да, и ещё. Всё-таки классы нужно называть с большой буквы.
Globals совсем не вариант.
Вы написали свою первую версию программы. Теперь её перепишите так, чтобы она работала так же, но без globals.
И циклы for j in range(len(buttons[i])) нужно менять на просто for button in buttons.
Ваш код — хороший пример того, как написать можно, но не нужно. Его нужно эволюционировать до чего-то более совершенного. В комментариях исправлять не получится, нужно видеть историю изменений.
Лучше залейте его на гитхаб, чтобы можно было его улучшать итеративно.
Советую почитать книгу "Чистый код" Роберта Мартина. Там, правда, не питон, но основные советы годятся.
Статью писать смысла особо нет, так как в официальной документации сказано обо всём том же.
А код… залил на Bitbucket. Но код очень далёк от совершенства (заранее предупреждаю):
https://bitbucket.org/mmalanuck/qmaterial
Так же пытался описать свои компоненты в виде документации, может тоже будет интересно пробежаться глазами:
https://mmalanuck.bitbucket.io/material_ui/
У стороннего наблюдателя, глядя на все эти зелёные прямоугольники с синим контуром и закруглёнными краями, может возникнуть ассоциация с рисованными на flash интерфейсами. И может показаться, что это что-то несерьёзное.
Но на самом деле, на qml очень хорошо получается сделать компоненты в том же стиле Material Design. Так что, на мой взгляд, если знаешь питон и нужно писать GUI приложение, стоит обратить внимание на эту технологию.
Если это поле нигде не учитывается в коде, то ничего нигде и не сломается. Новое поле просто будет игнорироваться.
А, к примеру, если в де/сериализаторе учитывалась контрольная сумма по полученным полям, и с новым полем у вас получаются другие суммы, то, скорее всего, неверен код сериализатора. Или же он ожидал конкретную структуру, значит, вы должны строго придерживаться её, значит, должна быть валидация получаемых данных. Приложение ругнётся, но вылетать ему необязательно.
Думаю, что распаковка аргументов в конструкторе — это здорово и питонично. Но мы тут её не видим, потому, что всякие концепции (чистого кода, DDD и прочее) описывались Робертом Мартиным, Эриком Эвансом, Мартиным Фаулером и прочими для статически типизированных языков как Java или C#. Просто опыт работы с данными методологиями ещё не обтесался и не питонизировался. Надеюсь, всё ещё впереди.
мне казалось, что тдд хорошо для модульных тестов, а тут какие то интеграционных тесты получаются. действительно ли необходимы такие тесты, не являются ли они хрупкими?
Идею закапывания флеш я тоже не поддерживаю. Я за флеш. Но на мой дилетантский взгляд, разница между as3 и haxe всё же существенна. Haxe подхватил as3, который был выпущен в 2006 году и остановился, в то время, как haxe развивается до сих пор и вскоре ожидается версия 3.3.
А так, если ваша платформа только Flash (player или Air), то да, можно на as3 писать… но на хаксе будет слаще и вкуснее )))
P.S. забыл добавить ещё одно из преимуществ haxe — менеджер библиотек. Как бы тоже немалая вещь.
может речь о том, что вирей и для блендера есть?
https://www.chaosgroup.com/vray/blender
Не зарабатываю на жизнь майкой, могу иметь ошибочное представление. Но не знаю, в каком ещё пакете кроме гудини флюиды лучше, чем в майке. Они и раньше были более менее, но после интеграции бифроста можно забыть про realflow. Разве нет!?
P.S. Realflow и Phoenix FD я не рассматриваю, так как это не пакеты общего назначения.
Что-то вы в один ряд поставили продукты с разными задачами. Гуди используется для процедурной анимации и генерации. Персонажей в нём не лепят. Сильная сторона Maya — анимация, риггинг, флюиды. Если речь о моделлинге, то тут макс, модо, блендер. Если моушн графика, то раньше синема4д, сейчас процедурные ништяки и в майку подвезли. Если речь об архивизе, то тут только Макс. Скульптинг — блендер, зебра, 3д коат, мад бокс. То есть, практически у каждого продукта своя ниша.
Но если говорить про лайтвэйв… Можете назвать студии, которые используют lightwave? Под него даже vray нет (хотя это один из основных рендеров в студиях).
Вы точно только на половину в режиме троля написали?
Знания — однозначно сила. А вот в какой цвет вы эту силу окрасите, зависит от вас.
Завтра попробую пул реквесты поотправлять с предложениями об улучшении кода.
Думаю, мне удастся показать, как избавиться от globals и сделать код стройным и понятным не только интерпретатору.
Почему не лучшая мысль?! Нормальная мысль.
Вы хотите узнать, как сделать этот код лучше?! Если да, то создавайте.
Да, посмотрел. Только вы в гист сохранили, а это, как я понял, сервис снипетов. Я же советую в сам github залить, чтобы разные версии коммитить.
зачем вам методы setXXX и viewXXX? Почему не обращаться к полю непосредственно? В питоне же всё открыто, подобное сокрытие не имеет смысла.
И ещё, попробуйте отделить данные от представления. Пусть данные хранятся в массиве (списке) как целые числа. Откажитесь от класса Pole. Вам не нужно у каждой клетки иметь список соседних (это легко подсчитать и так). Как вариант — вообще отказаться от массива всех ячеек. Можно иметь лишь список с координатами бомб.
Да, и ещё. Всё-таки классы нужно называть с большой буквы.
Globals совсем не вариант.
Вы написали свою первую версию программы. Теперь её перепишите так, чтобы она работала так же, но без globals.
И циклы
for j in range(len(buttons[i]))нужно менять на простоfor button in buttons.Ваш код — хороший пример того, как написать можно, но не нужно. Его нужно эволюционировать до чего-то более совершенного. В комментариях исправлять не получится, нужно видеть историю изменений.
Лучше залейте его на гитхаб, чтобы можно было его улучшать итеративно.
Советую почитать книгу "Чистый код" Роберта Мартина. Там, правда, не питон, но основные советы годятся.
А почему вы объект
QQuickView()присвоили переменнойappLabel? Почему это appLabel? Label — это же подпись. Может лучше было быview = QQuickView()?А код… залил на Bitbucket. Но код очень далёк от совершенства (заранее предупреждаю):
https://bitbucket.org/mmalanuck/qmaterial
Так же пытался описать свои компоненты в виде документации, может тоже будет интересно пробежаться глазами:
https://mmalanuck.bitbucket.io/material_ui/
Но на самом деле, на qml очень хорошо получается сделать компоненты в том же стиле Material Design. Так что, на мой взгляд, если знаешь питон и нужно писать GUI приложение, стоит обратить внимание на эту технологию.
А, к примеру, если в де/сериализаторе учитывалась контрольная сумма по полученным полям, и с новым полем у вас получаются другие суммы, то, скорее всего, неверен код сериализатора. Или же он ожидал конкретную структуру, значит, вы должны строго придерживаться её, значит, должна быть валидация получаемых данных. Приложение ругнётся, но вылетать ему необязательно.
А так, если ваша платформа только Flash (player или Air), то да, можно на as3 писать… но на хаксе будет слаще и вкуснее )))
P.S. забыл добавить ещё одно из преимуществ haxe — менеджер библиотек. Как бы тоже немалая вещь.