Почему вы указываете питон в тегах? При этом вы не упоминаете Python вообще, даже в разрезе того, что GDScript может быть близок тем, кто знаком с питоном.
GDScript, вообще говоря, из общего с питоном имеет только то, что программные блоки там разделяются отступами. В остальном это не такие уж одинаковые языки. И взаимодействия GDScript с питоном, подключения питоновских модулей и т.п. тоже нет.
Да и сам движок к питону имеет отношение весьма косвенное. Написан на C++, разве что SCons, которым он собирается, на питоне написан.
Да, можно через GDNative плагин с какого-то момента подключать игровую логику на питоне, но об этом тоже не сказано.
P.S. Движок сам по себе весьма крут. Не захламлён кучей всякого, как unity/unreal, при этом даёт возможность относительно удобно писать на C++, в отличие от unreal это адекватный C++, а не ue-макросы. Вместе с тем довольно удобный для прототипирования и быстрого старта, в отличие от прочих open-source движков.
Жаль, что не делают больших проектов на нём. Весьма добротная вещь.
Пух выглядит весьма неэлектробезопасно. Особенно учитывая то, что плата никак не герметизирована, как и светодиоды.
Что будет в случае нагрева или КЗ вследствие неплотного контакта?
Всё правильно. Потому что надо не учить язык, а учиться программировать. Развивать абстрактное мышление, доводить до автоматизма процесс декомпозиции задач, проводить параллели со структурами данных в реальном мире и пр.
Учить любой язык программирования, неважно насколько он актуален сейчас или будет потом, совершенно бесполезно в любом возрасте. Потому что программирование — это способ выражения своих мыслей, а не языковые конструкции.
Правда, зачастую эту мысль, в сущности довольно очевидную, мало где озвучивают и зачастую из "уметь писать на языке X" делают вывод "выучиться программировать", что в целом не совсем правда. Хотя, написав множество программ в процессе освоения некоторого языка, можно выработать привычки и в конце концов научиться программировать.
И в этом ключе достаточно просто понимать, что не важно, что использовать для обучения. Будь то питон, паскаль или ещё какой-нибудь 1С. Да, это в некоторой степени влияет на скорость обучение и т.д., но концепции почти везде более-менее одинаковые.
Да и питон постарше сегодняшних выпускников вузов будет, которые могли его впитывать с молоком матери. Так что рано хоронить его пока.
Спорное утверждение. GC — это не серебряная пуля выделения памяти. Повисшие горутины и всякие приколы вроде объектов в слайсах утечки создают только в путь.
В этом плане C++/Rust с умными указателями и RAII позволяют добиться более предсказуемого поведения, так что это вообще не аргумент.
Для серверной части зачастую выбирают инструментарий который банально позволяет проще развертывать приложения.
Почему в стандартных библиотеках для константных ошибок используется переменная, создаваемая через errors.New() а не, например, переопределение типа строки?
В таком случае переопределить значение будет невозможно даже случайно.
package errors
type Error string
func (e Error) Error() string {
return string(e)
}
//
const ErrFileNotFound errors.Error = "file not found"
Допустим, в стандартных библиотеках этого нельзя сделать из-за того, что это может сломать обратную совместимость для некоторого кода.
Но в примерах и многих библиотеках такой подход тоже не используется по каким-то причинам.
Я конечно так, погулять вышел, но из опыта работы с омегой точно не могу посоветовать.
Она дешёвая, на этом достоинства закончились.
2мм пины — самая большая боль. Либо покупаете их доки, которые стоят в два раза больше самой омеги, либо сами разводите переходники.
Они тоже используют чип от медиатека, но в своей сборке LEDE используют самопальный проприетарный драйвер WiFi.
Раньше открытый был намного хуже, но сейчас ситуация чуть лучше, если собирать LEDE из git.
Если собирать LEDE — можно пользоваться. В плане объема RAM/ROM лучше плат на базе тплинковских роутеров. Но с I/O работать всё равно не слишком удобно.
Для валидации ведь есть, как минимум, JSON Schema.
Если этого требует какая-то частная задача — можно попотеть и написать/поискать валидатор.
От того, что вы добавите строгую схему данных в условном JSON 2.0 и запретите опциональные свойства, конечные потребители не станут следовать этим правилам ввиду того, что уже есть тонны реализаций каноничного JSON, и ни в одночасье, ни в обозримой перспективе они не перейдут на новый стандарт, потому что "работает — не трожь".
Тем более, что немало реализаций поддерживают де-/сериализацию JSON с учётом требований, о которых вы говорите, правда, не на уровне спецификаций JSON, а на стороне библиотеки.
1.Я имею в виду схемы. постгрес во время работы создает много схем с названиями pg_temp_1, pg_temp_2, ..., pg_temp_100500 и pg_toast_temp_1, ...
Да, схемы можно выбрать. Но когда у вас десятки серверов в data sources, в каждом из которых по несколько баз с десятками-сотнями пользовательских схем, выбирать схемы для показа мягко скажем, неудобно.
Если же оставить галочку 'All schemas', в дереве будут сотни служебных схем, которые там только для того, чтобы мешать просмотру.
При этом пункт селектора 'Load sources for: All excl. system schemas' не влияет ни на что.
И паттерн в фильтре схем не может быть эксклюзивным, только инклюзивный.
2.Какое-то время назад в фильтре схем была возможность через Ctrl+ЛКМ выделить схемы, потом нажать пробел и у них всех бы поменялся чекбокс.
У datagrip большая беда с фильтрами схем. По крайней мере, для postgresql.
Он зачем-то выводит кучу служебных таблиц pg_toast_%/pg_temp_%, которых на production-серверах может быть ощутимое количество.
Плюсом к этому сам фильтр жутко неудобный. Если хочется выбрать вручную схемы для синхронизации — нужно кликать по каждой вручную. Пользуясь в течение полугода и EAP и стабильными ревизиями можно было наблюдать эволюцию этого фильтра. Сначала сделали хорошо и добавили возможность выделить схемы, затем включив нажатием пробела, а потом вернули как было.
Не скажу за всех, но свободного места, которое остаётся от оригинальной прошивки, мне не хватило на установку минимально урезанного питона.
Плюс, для более-менее готового устройства (опять же, за себя говорю) все эти приблуды от омеги не особо нужны (вроде встроенной web ide и всяких модулей к ней).
Если вам достаточно поиграться и что-то просто погонять — то можете смело брать. Но если возникает инженерное вдохновение — на каждом шагу начинают появляться какие-то навязчивые проблемы, которые и на форуме onion никто не сможет помочь разрешить. Можете его почитать, если интересно.
На омегу даже не смотрите, серьёзно. Столько красноречивого хочется про неё сказать.
Она красивая на картинках и в брошюрах, когда на ней детишки уже готового робота гоняют по полу через веб-IDE.
Когда дело доходит до закономерной сборки OpenWRT с минимально необходимым обвесом и нормальных применений — оказывается что это неюзабельная хрень, у которой даже режимов энергосбережения нет нормальных.
Плюс, ESP — Это совершенно другого класса устройство.
Возможно, стоит иметь небольшой хост, который не будет энергонезависимым и постоянно подключен к розетке и небольшой контроллер с BLE, который подключается к хосту.
Можете посмотреть платы у particle.io (не реклама).
Вы же в курсе, что для синхронной памяти тайминги указываются не в абсолютных величинах, а относительно базовой частоты, правда?
Не такой большой разрыв там.
К сожалению, некоторые сети просматривают трафик при помощи DPI и даже openvpn до версии 2.4, который не завернут в tls, обрубается в таких сетях. Не говоря о pptp
Перешёл на The Old Reader с Feedly как раз, удобно.
И на телефоне FeedMe. Не самое прорывное решение в плане дизайна и юзабилити, но довольно минималистично.
Стоит отметить, что certbot хоть и официальный, но непомерно раздутый и на лоукост корыте с 256МБ RAM может просто не запуститься, например.
acme.sh довольно функциональный и попроще для аудита, чтобы понять, что та версия, что у вас никуда не будет отправлять ключи. И к ресурсом не столь требовательный.
<sceptic mode="on">
opencv и numpy — это, строго говоря, не "только Python"
</sceptic>
Да и зачем вам numpy, если он нигде не используется в коде? Но работать с большими массивами точек используя стандартные list питона — это весьма неэффективно.
А в целом, плюс API блендера разве что в более удобной работе с STL и др. файлами моделей.
Почему вы указываете питон в тегах? При этом вы не упоминаете Python вообще, даже в разрезе того, что GDScript может быть близок тем, кто знаком с питоном.
GDScript, вообще говоря, из общего с питоном имеет только то, что программные блоки там разделяются отступами. В остальном это не такие уж одинаковые языки. И взаимодействия GDScript с питоном, подключения питоновских модулей и т.п. тоже нет.
Да и сам движок к питону имеет отношение весьма косвенное. Написан на C++, разве что SCons, которым он собирается, на питоне написан.
Да, можно через GDNative плагин с какого-то момента подключать игровую логику на питоне, но об этом тоже не сказано.
P.S. Движок сам по себе весьма крут. Не захламлён кучей всякого, как unity/unreal, при этом даёт возможность относительно удобно писать на C++, в отличие от unreal это адекватный C++, а не ue-макросы. Вместе с тем довольно удобный для прототипирования и быстрого старта, в отличие от прочих open-source движков.
Жаль, что не делают больших проектов на нём. Весьма добротная вещь.
Пух выглядит весьма неэлектробезопасно. Особенно учитывая то, что плата никак не герметизирована, как и светодиоды.
Что будет в случае нагрева или КЗ вследствие неплотного контакта?
Всё правильно. Потому что надо не учить язык, а учиться программировать. Развивать абстрактное мышление, доводить до автоматизма процесс декомпозиции задач, проводить параллели со структурами данных в реальном мире и пр.
Учить любой язык программирования, неважно насколько он актуален сейчас или будет потом, совершенно бесполезно в любом возрасте. Потому что программирование — это способ выражения своих мыслей, а не языковые конструкции.
Правда, зачастую эту мысль, в сущности довольно очевидную, мало где озвучивают и зачастую из "уметь писать на языке X" делают вывод "выучиться программировать", что в целом не совсем правда. Хотя, написав множество программ в процессе освоения некоторого языка, можно выработать привычки и в конце концов научиться программировать.
И в этом ключе достаточно просто понимать, что не важно, что использовать для обучения. Будь то питон, паскаль или ещё какой-нибудь 1С. Да, это в некоторой степени влияет на скорость обучение и т.д., но концепции почти везде более-менее одинаковые.
Да и питон постарше сегодняшних выпускников вузов будет, которые могли его впитывать с молоком матери. Так что рано хоронить его пока.
В этом месяце ещё не было инструкций по созданию ботов в телеграме, люди уже начали забывать, как получить токен.
Спорное утверждение. GC — это не серебряная пуля выделения памяти. Повисшие горутины и всякие приколы вроде объектов в слайсах утечки создают только в путь.
В этом плане C++/Rust с умными указателями и RAII позволяют добиться более предсказуемого поведения, так что это вообще не аргумент.
Для серверной части зачастую выбирают инструментарий который банально позволяет проще развертывать приложения.
Почему в стандартных библиотеках для константных ошибок используется переменная, создаваемая через
errors.New()а не, например, переопределение типа строки?В таком случае переопределить значение будет невозможно даже случайно.
Допустим, в стандартных библиотеках этого нельзя сделать из-за того, что это может сломать обратную совместимость для некоторого кода.
Но в примерах и многих библиотеках такой подход тоже не используется по каким-то причинам.
Я конечно так, погулять вышел, но из опыта работы с омегой точно не могу посоветовать.
Она дешёвая, на этом достоинства закончились.
2мм пины — самая большая боль. Либо покупаете их доки, которые стоят в два раза больше самой омеги, либо сами разводите переходники.
Они тоже используют чип от медиатека, но в своей сборке LEDE используют самопальный проприетарный драйвер WiFi.
Раньше открытый был намного хуже, но сейчас ситуация чуть лучше, если собирать LEDE из git.
Если собирать LEDE — можно пользоваться. В плане объема RAM/ROM лучше плат на базе тплинковских роутеров. Но с I/O работать всё равно не слишком удобно.
Для валидации ведь есть, как минимум, JSON Schema.
Если этого требует какая-то частная задача — можно попотеть и написать/поискать валидатор.
От того, что вы добавите строгую схему данных в условном JSON 2.0 и запретите опциональные свойства, конечные потребители не станут следовать этим правилам ввиду того, что уже есть тонны реализаций каноничного JSON, и ни в одночасье, ни в обозримой перспективе они не перейдут на новый стандарт, потому что "работает — не трожь".
Тем более, что немало реализаций поддерживают де-/сериализацию JSON с учётом требований, о которых вы говорите, правда, не на уровне спецификаций JSON, а на стороне библиотеки.
1.Я имею в виду схемы. постгрес во время работы создает много схем с названиями
pg_temp_1,pg_temp_2, ...,pg_temp_100500иpg_toast_temp_1, ...Да, схемы можно выбрать. Но когда у вас десятки серверов в data sources, в каждом из которых по несколько баз с десятками-сотнями пользовательских схем, выбирать схемы для показа мягко скажем, неудобно.
Если же оставить галочку 'All schemas', в дереве будут сотни служебных схем, которые там только для того, чтобы мешать просмотру.
При этом пункт селектора 'Load sources for: All excl. system schemas' не влияет ни на что.
И паттерн в фильтре схем не может быть эксклюзивным, только инклюзивный.
2.Какое-то время назад в фильтре схем была возможность через Ctrl+ЛКМ выделить схемы, потом нажать пробел и у них всех бы поменялся чекбокс.
В трекере есть как минимум три задачи, связанные с этим.
У datagrip большая беда с фильтрами схем. По крайней мере, для postgresql.
Он зачем-то выводит кучу служебных таблиц
pg_toast_%/pg_temp_%, которых на production-серверах может быть ощутимое количество.Плюсом к этому сам фильтр жутко неудобный. Если хочется выбрать вручную схемы для синхронизации — нужно кликать по каждой вручную. Пользуясь в течение полугода и EAP и стабильными ревизиями можно было наблюдать эволюцию этого фильтра. Сначала сделали хорошо и добавили возможность выделить схемы, затем включив нажатием пробела, а потом вернули как было.
Не скажу за всех, но свободного места, которое остаётся от оригинальной прошивки, мне не хватило на установку минимально урезанного питона.
Плюс, для более-менее готового устройства (опять же, за себя говорю) все эти приблуды от омеги не особо нужны (вроде встроенной web ide и всяких модулей к ней).
Если вам достаточно поиграться и что-то просто погонять — то можете смело брать. Но если возникает инженерное вдохновение — на каждом шагу начинают появляться какие-то навязчивые проблемы, которые и на форуме onion никто не сможет помочь разрешить. Можете его почитать, если интересно.
На омегу даже не смотрите, серьёзно. Столько красноречивого хочется про неё сказать.
Она красивая на картинках и в брошюрах, когда на ней детишки уже готового робота гоняют по полу через веб-IDE.
Когда дело доходит до закономерной сборки OpenWRT с минимально необходимым обвесом и нормальных применений — оказывается что это неюзабельная хрень, у которой даже режимов энергосбережения нет нормальных.
Плюс, ESP — Это совершенно другого класса устройство.
Возможно, стоит иметь небольшой хост, который не будет энергонезависимым и постоянно подключен к розетке и небольшой контроллер с BLE, который подключается к хосту.
Можете посмотреть платы у particle.io (не реклама).
Не такой большой разрыв там.
К сожалению, некоторые сети просматривают трафик при помощи DPI и даже openvpn до версии 2.4, который не завернут в tls, обрубается в таких сетях. Не говоря о pptp
Кроме shadowsocks. Это обёртка, которая туннелирует внутри себя, и локально запускает socks сервер. и пароль зашифрованным передается.
И на телефоне FeedMe. Не самое прорывное решение в плане дизайна и юзабилити, но довольно минималистично.
Мир не ограничен хецнером, линоде и ДО.
На LowEndBox такого навалом, например.
Стоит отметить, что certbot хоть и официальный, но непомерно раздутый и на лоукост корыте с 256МБ RAM может просто не запуститься, например.
acme.sh довольно функциональный и попроще для аудита, чтобы понять, что та версия, что у вас никуда не будет отправлять ключи. И к ресурсом не столь требовательный.
<sceptic mode="on">
opencv и numpy — это, строго говоря, не "только Python"
</sceptic>
Да и зачем вам
numpy, если он нигде не используется в коде? Но работать с большими массивами точек используя стандартныеlistпитона — это весьма неэффективно.А в целом, плюс API блендера разве что в более удобной работе с STL и др. файлами моделей.
У автора оригинала на страничке есть почта — можете попробовать написать.