Александр

Кроме того, что он позволяет питону интерпретировать директория как пакет, в __init__.py может быть включен различный код инициализации, например:

• переменная __all__
  
• проверка ограничений при использовании пакета
  
• сообщение о deprecated
  

1. Питон может искать модули в нескольких папких в порядке очередности (в том числе по путям в PYTHON_PATH).
2. Представьте что по одному из путей у вас вот так:

а по другому вот так:

3. Вы импортируете модуль string, но первой по приоритету обрабатывается директория с папкой string. А у вас там например вообще не питоновский код, а документация какая-нибудь. Вы на самом деле хотите заимпортить string.py из второй папки, но интерпретатор будет думать что нужно взять директорию, и выдаст ошибку (скажет что мол не является это валидным пакетом или что-то в таком духе).
4. Чтобы такого не было, разработчики решили что вы должны явно помечать, что хотите чтобы папка считалась пакетом. Это тоже самое что помечать файлы с кодом на питоне расширением .py - вы же не ждёте что интерпретатор будет воспринимать .txt-шники как модули на питоне? То же самое и с папкой.

Ну и да, как уже упомянул Вячеслав , __init__.py вовсе не обязательно должен быть пустым, например там могут быть реэкспорты.

В мире программирования - это синонимы.

В жизни Request подразумевает формализованный запрос, например официальный запрос информации о каком-то предмете, который подразумевает заполнение некоторой формы (формуляра).

Query - это просто вопрос.

Например, вы приходите в банк, вам нужно открыть кредит. Когда вы спрашиваете, в какое окошко вам обратиться, это query, когда заполняете форму это fill in application, когда отправляете форму на рассмотрение - это и есть request.

+ и все что дальше него до @ — просто игнорируется. Это очень удобно, потому что позволяет иметь при одном ящике бесчисленное количество адресов.

Я например часто использую эту фичу когда регистрируюсь на каких-то сайтах, например для facebook e-mail myemail+fb@domain.net, для yandex — myemail+ya@domain.net, для какого — нибудь сомнительного сайта — myemail+hrenkakayato@domain.net и т.д.

Письма по всем этим адресам будут доставлены в myemail@domain.net

И если потом например в мой ящик начинает приходить спам на имя myemail+hrenkakayato, то сразу видно, где утечка. И легко сделать фильтр, чтобы просто банить такие письма…

Согласен с коллегами - ноутбук проектировщику нужен в следующих случаях:
- проживание в комнате коммуналки с семьей (ставить физически некуда, а работать приходится - на подоконнике и на тумбочке);
- командировки - ваше второе я: геодезист, специалист авторского надзора и прочие геологи.

Во всех остальных случаях нужен стационарный комп, потому что:
1) Проектировщику нужен нормальный монитор 24", а часто даже пара одинаковых (документация на одном, чертеж на втором). К ноутбуку конечно можно подключить второй большой монитор и нормальную клавиатуру - поставить ее перед большим монитором, но какой тогда смысл в ноутбуке?
2) Автокад одноядерный. Это его родовой дефект. И все "течения" в автокаде - на его "шасси" - тоже (Civil, Plant3D и пр). Основной процесс "упирается рогом" в производительность одного ядра, а все вспомогательные процессы - потребляют еще 0,5 ядра максимум. Т.е. работает он только в режиме "полтора землекопа". Поэтому нам нужен процессор упоротый по частоте в режиме нагрузки 2-х ядер. А это например линейка Интел с индексом К. А значит с ноутбуками - опять мимо.
2) Память - тут все сложно. Да, надо признать, что чистый Автокад прекрасно работает и на i5 второго поколения выпуска 2012 года с 8-ю оперативки, но второй родовой дефект Автокада - работа с кучей временных файлов. В результате при наличии в системе "свободной" памяти она используется как дисковый кэш и некоторые тяжелые кадовские операции могут ускоряться в десятки (!) раз при наличии запаса именно незанятой памяти. Плюс есть любители - кроме Автокада держать открытыми еще несколько пожирателей памяти: 30 вкладок в Хроме, Скайп, Вайбер, Word, Acrobat - тут смотрите по своим вредным привычкам и особенностям работы. Но 16 гигабайт обычно решает проблему.
Опять же ноутбуки с 16 - это топ и дорого.
3) Быстрый диск. Как я уже написал - автокад любит диск. Поэтому сегодня есть смысл собирать под него комп с NVMe диском, со скоростями ближе к 3000 мб/сек на чтение и запись. А ноутбук - как правило кот в мешке - не вы его собирали, и что там сунуто - обычно "сюрприз". Хотя уже пошли модели, где в этом плане все ОК, но опять же - информации ноль. Только опытным путем...
4) Видеокарта - встроенная. Дело в том, что у Красных, что у Зеленых - дискретные видеокарты разделены на игровой и профессиональный сегменты. И что у AMD, что у Nvidia - кадовские функции ускорения в игровых картах отключены. В то же время уже с 2012 года встроенная графика Intel этим не страдает, всё кадовское ускорение там разрешено и дискретным решениям - как минимум не проигрывает.
А теперь найдите хоть один ноутбук с вышеуказанными характеристиками и без дискретной видеокарты!
5) Дешевле. Комп с нужными характеристиками выйдет примерно в 2 раза дешевле аналогичного ноутбука :).

Ну вот - теперь признайте правду - игровых ноутбуков не бывает, ноутбуков под авткоад - тоже. Автокад работает на современном - чем угодно, но иногда скорость НЕКОТОРЫХ может операций может отличаться критично.

P.S. а если всё же для игр - то в стационарный поставить видеокарту намного проще.

Есть разные понятия джиттера, основное это резкое изменение фазы сигнала (например при последовательном воспроизведении двух музыкальных треков). Однако в сетях джиттером обычно называют просто "прыгающий пинг", т.е. разброс во времени прохождения сетевых пакетов. Т.е. если у вас все пакеты идут по 2 миллисекунды, то джиттера нет. Если все пакеты по 200 миллисекунд то джиттера тоже нет. Но если часть пакетов идет по 2 и часть по 200 - то это джиттер. Джиттер есть практически в любых броадкастных сетях, в т.ч. и в Ethernet, при высоких загрузках среды передачи. В WiFi выраженность джиттера будет зависеть от нескольких факторов, основной это загруженность используемого частного канала. В многоквартирном доме или офисном здании с кучей небольших компаний это может быть достаточно серьезной проблемой. Джиттер плох в основном для игр и реалтаймовых протоколов (голоса, видео).

Если вы не наблюдаете рандомных задержек пинга даже при существенной нагрузке на сеть, то проблемы джиттера у вас нет.

Это всё вкусовщина, я миллион вариантов видел и все они свою задачу выполняли. Просто возьмите пустую сцену и поэкспериментируйте, сделайте, чтобы ui можно было просто так без ничего запустить и снаружи подёргать из тестового класса. Ну и с бизнес-логикой точно так же, сделайте, чтобы она в "консольном режиме" работала без лишнего обвеса.

Из общих советов могу порекомендовать избегать циклических связей, когда, например, вы в ui что-то отправляете и в сценарии ожидаете, что оттуда вас дёрнут в ответ, а если не дёрнут, то всё сломается. Для того, чтобы это не случалось, очень удобно использовать такую конструкцию:
public event Action OnSomething = () => {};
Так вы всегда сможете вызывать OnSomething и не беспокоиться о том, есть ли какие-либо подписчики у этого события, оно никогда не будет null и снаружи его никто вызвать не сможет. Когда вы начинаете думать в таком формате, то проектировать архитектуру становится проще.

В остальном, в принципе, можете делать что угодно. Я бы не советовал подписываться на юнитёвые интерфейсные события через инспектор, потому что так код становится сложнее отлаживать, но в разных организациях свои привычки, иногда над префабами работает отдельный человек, и в код он не лазает.

Всё зависит от цели, задачи и пути исполнения. Для обучения программированию, выстраиванию архитектуры и основам gamedev libgdx отлично подходит, но он по сути только для 2D игр(и он ну очень хорош в этом) + мало инструментов разработки( editor, animator и т.д).
C# и Java конечно похожи, но не настолько что б сразу "перескочить". Но и C# в Unity это не совсем C#. Короче, если идет только обучение или желание создать небольшую 2D игру на мобилку, то libgdx. Если есть немного знаний + 3D или мало мальская серьезная 2D, то Unity. А если ПК + 3D или Пк + Мега 2D, то Unreal Engine 4.