Михаил

Эти подходы не только для крупных проектов, они вообще для любых проектов.

1. БД обновляется через миграции. То есть, вы пишете SQL-скрипты, которые нужно выполнить в БД (создание новых таблиц, новых колонок, добавление записей в справочные таблицы, удаление ненужных более колонок и т.д.), а система миграции (вот не в курсе есть ли такая у WP, но совершенно точно есть у более продвинутых Laravel/Doctrine) контролирует что скрипты миграций были выполнены (и выполнены в правильном порядке). Можно скрипты прокатывать и руками, но в таком случае всегда есть вероятность ошибки.
   
2. Разделение исходного кода и собранного кода. У вас есть исходный код и работает разработчик с исходным кодом проекта. Тут путаница возникает в том числе потому, что у PHP исходный код и исполняемый код - суть одно и тоже. Но концептуально разделять это стоит. После того как исходный код написан, выполняется сборка (в частности на этом этапе отрабатывают SCSS/gulp/webpack и т.п. инструменты) и получается код для загрузки на сервер. Поэтому задача "поменять цвет кнопки" решается изменением одной строчки в исходном коде, затем пересборкой и перезаливкой собранного кода на сервер
   
3. Пересборку и перезаливку можно делать вручную. Но лучше если этим будет заниматься CI-сервер. Бесплатно CI предоставляет, например, гитлаб. Насчет гитхаба/битбакета не в курсе, не интересовался. Суть в том, что при изменении исходного кода в репозитории, автоматически (или вручную) запускается некоторый процесс (pipeline), выполняющий сборку-тестирование-деплой новой версии. Разумеется, чтобы это все работало сначала придется потрудиться, разобраться, написать нужные скрипты и конфиги. Но для большого проекта это незаменимый инструмент.
   

Это зависит от того как организована система хранения. Может получиться так, что искать по хэшу она будет быстрее чем по обычному числу т.к., например, может использоваться quad tree или octree. Если использовать число, то старшие биты будут плюс-минус одинаковы, что приведет к тому что данные скопятся в одной из веток дерева, а другие будут пустыми. А если дерево еще и распределенное - это будет означать что данные неравномерно распределены по нодам. Хэш такую проблему решает сразу. Для гита вероятность коллизий хэша пренебрежимо мала, практически нулевая.

В случае гитхаба, вероятно, данные хранятся в гит-репозитории. Поэтому хэш коммита в ссылке - естественное и логичное решение. Насчет фиддла сказать не могу - но в принципе тоже, скорее всего, что-то аналогичное, только закодировано не в 16-ричную систему, а в 32-ричную (5 * 8 = 40 бит)

Плюс хэш можно генерировать независимо от хранилища (по содержимому + времени, например). А для генерации последовательных идентификаторов нужно обращаться в систему хранения, которая должна следить за их уникальностью и, таким образом, может стать "узким местом".

Как вариант:
у вас в первом случае: 2560х1440х8бит - 240 Гц
во втором случае: 2560х1440х10бит - 144 Гц

У меня такое предположение что глубину цвета в 10 бит либо видеокарта, либо монитор на 240 Гц не тянет. И, как результат, делает "шаг назад" на предыдущую поддерживаемую частоту 144 Гц.

Сессии работают следующим образом: при создании сессии сервер отсылает заголовок Set-Cookie браузеру в котором сохраняет значение идентификатора сессии (JSESSIONID). При последующих запросах браузер посылает "печеньку" обратно серверу и тот, получив идентификатор, может восстановить сессию из своего хранилища. Если "печеньки" заблокированы, то возможно передать jsessionid как query param запроса. Но это уже требует дополнительных телодвижений на стороне клиента.

Так как вы упоминаете REST, то предположу использование XmlHttpRequest в браузере (напрямую или опосредованно через какую-то библиотеку), который не посылает заголовок Cookie по умолчанию.

Поэтому вариантом решения может быть отправка идентификатора сессии явным образом как query param с именем jsessionid.

Однако, использование сессии в REST запросах - в целом не очень хорошая практика, так как REST предполагается быть stateless. А в случае сессии у вас появляется состояние на стороне сервера. Если сессия нужна только для аутентификации клиента, то посмотрите на использование токенов, таких как JWT, которые позволяют решить эту проблему без наличия сессии на стороне сервера.

Давайте по порядку.

Что такое аннотация? Аннотация - это некоторые произвольные метаданные, которые программист может присоединить к некоторому объекту. И только. Данные, ничего кроме. Никакого поведения сама по себе аннотация не добавляет.

То есть аннотация ничего не делает? Да, именно так. Сама по себе аннотация ничего не делает.

Тогда зачем она вообще нужна? Для того чтобы аннотация оказала какое-то влияние на программу нужен процессор аннотаций. Процессор аннотаций бывает двух видов: первый работает во время компиляции программы. И аннотации оказывают влияние именно на процесс компиляции. Это может повлиять на итоговой код программы, либо изменить логику работы компилятора, например, добавить какие-то дополнительные проверки.

Второй вид процессоров аннотаций работает во время выполнения программы. Через механизм рефлексии он анализирует аннотации, которые добавил программист, и выполняет логику в соответствии с аннотации и содержащимися в них даннми. Так, например, работает Spring, который в соответствии с аннотациями @Service, @Scope, @Autowired, @Controller и т.п. инициализирует компоненты приложения и запускает его в нужной конфигурации.

У Эккеля написано неточно (либо это неточный перевод, такое тоже часто бывает). Переменные никакого значения не получают, получает значение поле в аннотации (аннотация в Java - это тоже объект и тоже имеет поля). А затем уже процессор аннотаций значение этого поля как-то использует (в приведенном примере - устанавливает соответствие с колонкой в таблице базы данных соответствующего типа и, при необходимости, создает её).

У Шилдта написано корректнее - сами по себе аннотации никак семантику программы не затрагивают, для того чтобы они заработали требуется дополнительный код.

Открываете документацию собственно Unity - чем она вам не для gamedev-а?
Открываете документацию Unreal Engine, CryEngine, да в общем-то любого игрового движка - и вперед, более чем достаточно примеров.

Вариантов тут несколько, например:

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

Собственно вы, если не вскрывать корпус, можете только убедиться что питание к компьютеру поступает надежно. Я бы посоветовал подключить, если есть возможность, в розетку без всяких удлинителей. Либо, если невозможно - заменить удлинитель на один и хороший, качественный.
Остальное может диагностировать только специалист, так что компьютер нужно будет отдавать в гарантийную мастерскую.

Мощность блока питания - это максимальная мощность, которую он может выдать. Если подключить к вашему БП (85 Вт) потребителя, который требует 100 Вт - блок питания не справится с такой нагрузкой (как конкретно это проявится - зависит от схемотехники БП)

Если же к нему подключить 60 Вт (да хоть 5 Вт) - это будет означать только то что БП работает "вполсилы", у него остается запас мощности т.к. не БП определяет сколько он "впихнет" в потребителя, а, наоборот, потребитель определяет сколько он "заберет" у источника питания. Поэтому резерв мощности никогда не может навредить потребителю. Из этого же, кстати, следует что заряжаться макбук быстрее не станет.

Потому что вы пытаетесь запустить файл homework.lesson8.HelloWorld находясь в каталоге с файлом. java логично пытается найти файл ./homework/lesson8/HelloWorld.class и обламывается о чем вам и сообщает.

java HelloWorld тоже не работает т.к. java находит файл HelloWorld.class внутри которого написано что он принадлежит пакету homework.lesson8, то есть это не тот файл который хочет запустить пользователь.

Сделайте cd ../.. (перейдите в каталог src) и запускайте java homework.lesson8.HelloWorld - будет работать

Но вообще перемешивать исходный код (*.java) и скомпилированные файлы (*.class) в одних и тех же директориях - очень плохая идея. Обратите внимание, что IDEA, когда компилирует файлы складывает их в папку out. Можете перейти туда и запускать свою программу из той папки (тогда вызывать javac отдельно вам не нужно). Либо указать в опциях javac куда нужно складывать скомпилированные файлы.

А зачем вам гит на vps? Должен быть какой-то один "источник правды".

Мне кажется что история должна быть такой: git server (github/gitlab/etc) -> local repository -> rsync to vps -> volume to docker

Соответственно, когда вы меняете ветку в локальном репозитории - rsync видит изменения файлов и синхронизирует их с vps, который ничего про гит не знает - для него это просто набор файлов.

Как вариант - выдать каждому воркеру свой докер-контейнер. А общий для них node_modules смонтировать как volume (я так подозреваю можно даже смонтировать как read-only).