Astrohas

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

Если ещё не читали, то прочтите статью Линейная алгебра для разработчиков игр, ещё могу посоветовать этот доклад с GDC. Для лучшего понимания трёхмерной графики очень полезно научиться моделить примитивные вещи в трёхмерном редакторе, а ещё лучше попробовать процедурно сгенерировать какую-нибудь сферу или кубик.

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

Используйте SoftEther - там поддерживается куча VPN протоколов, в том числе и свой встроенный.
Этот самый встроенный протокол базируется на SSL и неотличим от https для всяких анализаторов трафика, работает очень шустро.

piclie - это очень быстро.
dot - это для визуализации/отладки.

SELECT `t2`.* 
  FROM (
    SELECT `id`
      FROM `table`
      WHERE `parent_id` = 0
      ORDER BY `id` DESC
      LIMIT 5
  ) AS `t1`
  JOIN `table` AS `t2` 
    ON `t2`.`id` = `t1`.`id` OR `t2`.`parent_id` = `t1`.`id`

Используй
a.lower() in ['vk', 'вк']

Welcome to Yota, они уже очень давно с помощью DPI режут скорости у ненравящихся им протоколов.
Можете попробовать SoftEther VPN, их фирменный протокол DPI-непригоден.

Я расскажу Вам про личный опыт, без претензий на истину в последней инстанции...

Для чего идеальна MongoDb? Примеры приложений, где монга будет лучше mysql?

Для человека который привык работать с реляционными БД, смириться с логикой и вообще с подобными БД - довольно сложно. Для тех, кто работает с реляционными БД профессионально - сделать это ещё сложнее...

Если сравнивать с реляционными БД и с оглядкой на конкретно MySQL - монга идеально вписывается там, где структура данных заранее неизвестна. Тут я хотел привести пример, но не смог придумать ни одного дельного примера, после того как начал плотно работать с PostgreSQL... Давайте попробую из практики. Мы один раз применяли монгу в проекте где есть десятки и сотни тысяч товарных позиций и у каждой из них свой уникальный набор различных свойств. На основе уже имеющихся свойств, "соседних" товаров, контентщику предлагался наиболее вероятный набор параметров, которые нужно заполнить, но в любой момент он мог удалить или добавить любое поле и/или множество значений одного из них, например, "Цвет: черный, серый, фиолетовый". Всё это дело попадало под разные динамические фильтры и далее по цепочке... В то время, насколько я помню ещё не было поддержки JSONB-формата у PostgreSQL, по этому мы остановились на MongoDB. Ну и конечно же, желание "воткнуть ультра новую и модную БД в проект" сыграло свою роль...

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

Безусловно, не редко можно встретить проекты в которых даже в реляционных БД не прописаны, например, внешние ключи и контроля целостности данных как такового нет, но обычно это происходит по следующим причинам:
1. Очень низкая квалификация администратора БД проекта
2. В попытке выжать из базы больше производительности, не найдя других методов оптимизации
3. Данных настолько много, что БД/ключи - начинают "сыпаться", не редко это связано с п.1

Так же, последние тесты показывают, что PostgreSQL почти не уступает MongoDB даже в её родной среде (на уровне данных в формате JSON). А в некоторых аспектах даже превосходит её... Подробности Вы можете увидеть на некоторых конференциях по Postgres (да, на конференциях по MongoDB, Вы вряд ли увидите, как кто-то будет рассказывать, что [их любимая] монга "хуже" некоторых других движков...). Кстати, поддержку формата JSON стандартизировали (наконец-то) на уровне SQL-стандарта (если я не ошибаюсь) и в самом ближайшем будущем, думаю стоит ожидать полноценную поддержку оного в SQL-базах, в т.ч. поддержку в бинарном виде с возможностью индексации данных (кстати, некоторые SQL-базы уже такое умеют).

Моё понимание, ответа на вопрос, "когда действительно стоит использовать MogoDB?" звучит примерно так: Исключительно в тех случаях, когда Вы понимаете, что она станет действительно хорошим решением для поставленной задачи и сейчас и в будущем. В моей практике, таких проектов можно было бы насчитать ничтожно мало, а точнее около нуля, особенно с учётом развития некоторых современных SQL-БД и вообще направления "JSON в SQL" в целом. Но, безусловно такие проекты могут быть и есть (в данном случае, не у меня). Но, тут стоит обратить внимание на крайне важный факт - когда всплывает такой проект, что бы адекватно оценить наиболее оптимальную БД под него - нужно знать как минимум пару-тройку SQL-БД, со всеми их особенностями, достоинствами и недостатками... причем не просто "знать", а хорошо знать, "изнутри". А так же знать все характерные черты монги, а так же её особенности, достоинства и т.д. То есть, если Вы задаётесь вопросом, "а хорошо ли впишется монга в проект N?" и не можете найти на него однозначного ответа, вероятнее всего, что в долгосрочной перспективе, в "проект N" она впишется плохо.

P.S. В заключение, хочу ещё раз напомнить, что "JSON в SQL" - активно развивается... Со всеми вытекающими.

Устанавливаете все принтеры на отдельном компьютере. На нем эти принтеры расшариваете, и подключаете пользователям принтеры не напрямую, а эти расшаренные.

При этом можете расшаривать даже не отдельные принтеры, а если некоторые стоят рядом, их можно (нужно) объединить в пулы, и шарить как один принтер, тогда сервер печати будет сам выбирать свободный принтер. При этом, если какой-то принтер будет занят (например картридж меняется), то сервер печати автоматом не будет на него давать задания.

Собственно это и есть основная роль службы сервера печати в Windows.