Станислав Б

При чём тут какая-то связка с php? Как php вообще относится к вёрстке? Если вы там адаптивности боитесь, то, лично моё мнение, вам ещё нужно подтянуть знания и вы себя в оценке переоценили))

Что насчёт самого макета, то я бы сказал, слишком лёгкий. Чё тут делать то? Карту вставить? Подвигать стрелочки при наведении через css? Сделать кнопку с раскрытием меню?

P.S. Я никак не хочу обидеть или оскорбить вас, но я не понимаю, сути вашего вопроса. У вас навыки 70% х 30%, а вы вместо того, что бы начать верстать, пришли сюда с глупым вопросом, а не слишком ли сложно!

Предполагается, что "сервер" это не боевой сервер, где крутится приложение, а сервер сборки, например агент teamcity/jenkins/hudson.

Если же у вас на "боевом" сервере что-то пойдет не так, то это что? интернет пропадет, чтобы подкачать зависимости? Так а как юзеры будут тогда на нем работать?

Предполагается, что разработчиков много.

Предполагается наличие pull request-ов, которые требуют успешного билда для merge

Если ты работаешь сам, то делай как тебе удобно. Если работаешь не сам - есть best practice

Программу никому неизвестного ВУЗа нужно узнавать в этом вузе.
Но в любом случае современное веб-программирование там не изучают.

ИТ область - это область с высоким порогом входа.
Высокий порог входа не пустые слова. Это сложно. Это очень сложно.
Это даже для того, чтобы понять чем прикладная информатика отличается от программной инженерии, вам бы поучиться годик, ибо в двух словах пояснить так, чтобы все стало понятно - не получится.

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

А главное - вуз, в отличие от школы, обычно прививает навыки самостоятельного изучения и решения проблем. В школе практически неважно, как вы учитесь - все равно перетянут в другой класс, разве что ты совсем даун.

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

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

На мой взгляд, в резюме не должно быть указано з/п, вообще.
В плане уровня з/п... Любая, за которую сможете себя продать. А о наглости и самоуверенности тут вообще не стоит думать.

Patreon

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

Это та самая PDF-ка, которая еще в 2012 была странноватой и местами устаревшей?

__call() - это не функция а магический метод, который вызывается при попытке вызвать несуществующий метод у объекта. Теоретически, можно в нем прописать обращение к методам из других объектов, но кому в здравом уме это может понадобится - не представляю.
Тем более, что все в том-же 2012 появились trait'ы.

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

Сам по себе перевод без разрешения автора оригинального текста не является незаконным, а вот использование его уже незаконно без разрешения автора оригинального текста.

А уж спрашивать разрешения у автора или нет это ваше личное дело. Ну и по ситуации надо смотреть.
Просто надо понимать что в таком случае возможны проблемы, и надо грамотно оценить риски.

и достаточно ли будет указывать неактивную ссылку на источник

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

Никак.
Команда "Архаровцы" из Нижнего Кукуева имеет коэффициент прошлых побед 10.
Команда "Атлетико" из Мадрида имеет коэффициент прошлых побед 8.
Каковы шансы победы архаровцев?

Прежде всего проверьте версию СУБД. json_array_elements_text была добавлена в релизе 9.4.

Все 5 чисел делаете равными 89. Далее берете 2 любых числа из этих пяти. Одно увеличиваете на n, другое уменьшаете. Важно подобрать n случайным образом, но так чтобы при увеличении/уменьшении числа не вышли за диапазоны (что в целом тоже просто). Повторяете все вот это столько раз сколько хотите.

Потому что SI 16-разрядный, а AL 8-разрядный. Сравнивайте SI с AX.

Принцип KISS не означает что надо использовать самые примитивные инструменты.
Он означает, что не надо переусложнять систему без нужды.
Если так рассуждать, так и высшее образование не нужно: "Дед отличные бани строил, хотя вовсе был неграмотный. Я и без сопромата небоскреб построю!"
Если вы пока ещё не понимаете назначение всех этих "лееров, провайдеров и репозиториев", это не значит, что они вообще никому не нужны.

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

И кстати. Код, в котором "всё друг на друге завязано" - это очень плохой код. Собственно, предназначение всех этих "лееров, провайдеров и репозиториев" как раз в том, чтобы компоненты были как можно более независимы друг от друга.