0Bannon

Full-stack разработчик — это не тот, кто знает всё что угодно, что в принципе может быть на сервере. Технологий и продуктов слишком много, и просто учить всё это по списку не очень дальновидно.

Full-stack разработчик — это тот, кто разбирается во всем стеке технологий и используемых в проекте компонентов (как в части фронтенда, так и бэкенда), что позволяет ему в одно лицо затащить проект. Соответственно, перечень необходимых технологий, продуктов и инструментов зависит от того, что за проект стоит перед full-stack разработчиком. Исходя из этого я бы не стал приводить "10 things a Full Stack Developer should know".

Например, вы делаете первые шаги и решили открыть свой "Очередной блог веб-разработчика". И например, вам на фронтэнде до жути надоели фигурные скобочки, или вам друг посоветовал, или просто для разнообразия, но вы решили попробовать Python. Соответственно вы начнёте копать и получите такой стек: React|Vue.JS(раз вы фронтэндер) + Django&DRF|Flask + Virtualenv + uWSGI|Gunicorn + SQLite|PostgreSQL|MySQL + Memcached|Redis(возможно) + Ngix. Соответственно, хотите вы того или нет, но вам придётся всё это хозяйство разворачивать на сервере. А значит вам надо будет научиться работать в Bash и понимать, что вообще куда в *nix-системах (FHS, pipelines, environments, cron, systemd). Вам надо будет суметь организовать процесс разработки, чтобы изменения кода попадали на сервер и применялись. И лучше сразу начинать использовать тесты и системы контроля версий. Если что-то из этого вы не сможете и придётся привлекать кого-то ещё — вы не full-stack разработчик.

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

Enterprise разработка - это разработка, направленная на решение проблем бизнеса. В отличии от разработки для решения проблем конечных пользователей.

На самом деле нет каких-то зафиксированных принципиальных характеристик, которые присущи только EA. По-этому, в разговорной речи понятие "энтерпрайз" может значить весьма разные вещи. С одной стороны энтерпрайз - не про увлечение модой с переписыванием всего, как только появится новый тренд. Ибо это _дорого_, так как цена ошибки дорога. С другой стороны - совсем не обязательно, что это 20-летние технологии. Конкретный бизнес сам для себя выбирает модели развития и обновления стека технологий. С одной стороны - это сложность ПО, бизнес-логики. С другой - сложность понятие весьма относительное.

Но если все же пытаться выделить какие-то характерные черты, я бы назвал несколько:
* устойчивость к трендам (использование их, когда они пройдут стадию моды и перейдут к стадии заинтересованности крупными игроками, ибо никому не нужны технологии, которые через год умрут и их поддержка будет дорожать каждый день).
* сложная и непостоянная бизнес-логика, давление на нее из множества источников
* результат сложной переменчивой бизнес-логики в совокупности с длительным использованием продукта приводит к целям снижения стоимости поддержки за счет стоимости первоначальной разработки, производительности и потребляемых ресурсов. ООП, SOLID, Unit Test/TDD, DDD - все эти популярные буквы - последствия "энтерпрайза", когда мы готовы серьезно подходить к написанию кода для облегчения его последующего изменения.
* слабо заметный вклад конкретного программиста, проистекает из сложности ПО

Требования к программисту... ну я бы сказал, усидчивость, вдумчивость, исполнительность... хм, а что, в каких-то других областях другие требования к программистам? Хотя, конечно, в противоположность, можно назвать способ разработки "быстро-быстро и в продакшн". Но, к слову, такие ситуации могут и в энтерпрайзе возникнуть.

По-этому, стоит рассматривать не энтерпрайз/не энтерпрайз, а конкретные компании с конкретными требованиями и циклами разработки.

Там JS не нужен по большому счету. Минимум CSS, старый добрый HTML, и PHP, который составляет 95% функциональности подобной подсистемы.
Конфигурация отправляется из полей POST-запросами и сохраняется обычно в файлы, реже в БД. Почему реже? Потому, что системы настройки обычно настраивают так же и сам доступ к БД.
Так же из РНР обычно и генерируются input-поля с уже заполненными value.
Чтобы с непривычки не мучаться с импортами-экспортами-инклюдами конфигурационных файлов, рекомендую использовать JSON - это дёшево и сердито:

$config = json_decode(file_get_contents(__DIR__ . '/.config'), true); //читаем конфиги
//...
file_put_contents(json_encode($config), __DIR__ . '/.config'); //пишем конфиги

В данном примере .config - с точкой вначале, чтобы конфиги нельзя было открыть и прочитать из браузера - ведь это конфиденциальные данные. `__DIR__` - это магическая константа, путь к папке скрипта, в котором она использована.
Сохранять конфиги можно как угодно иначе, главное, чтобы они были недоступны из web.
Так же вам нужно предусмотреть элементарную безопасность: фильтрацию данных, полученных от пользователя.
Резюмируя, чтобы написать минимальный конфигуратор на РНР, нужно проштудировать информацию о:
json_encode / json_decode
file_get_contents / file_put_contents
htmlspecialchars / strip_tags / preg_match / filter_input

HTML и CSS, как я понимаю, вы уже и так успешно пользуетесь.

Делаете примерно такую сетку (в grid-template-columns)



Первый, второй, пятый и шестой элементы растягиваем на две колонки

.item:nth-child(6n + 1),
.item:nth-child(6n + 2),
.item:nth-child(6n + 5),
.item:nth-child(6n + 6) {
  grid-cloumn: span 2;
}

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

План действий может быть таким:
1. Берете/получаете макет
2. Внимательно рассматриваете его, мысленно разбивая на блоки. Думаете что куда может/должно растягиваться или уменьшаться при изменениях экрана и увеличении/уменьшении контента.
3. Если п.2. сразу не осилился, идете гулять или спать.
4. Возвращаетесь к п.2.
5. Верстаете понятные большие блоки, затем их заполняете. Разбивайте задачи более простые.

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

А совсем без проблем не выйдет, потому что экранов много, браузеров много, хотелок у заказчиков еще больше. Хорошо, когда эти хотелки интересные :)

Вообще, нужно взять бумажку и задать на высшем уровне абстракции все возможные в текущем представлении сущности. Если разговор о "змейке" - задаете вопрос, что у вас в игре есть как сущности. Скажем, есть змея, есть стены, есть жрачка, их пишете как сущности. Затеяли добавить "муху" - пишете тоже. Затем пишете, кто что умеет делать: змея умеет ползать, стукаться в стены или жрачку, расти и возможно что-нибудь ещё, стены просто стоят, жрачка умеет появляться, съедаться. И так далее, пока всю игру в примитивах не опишете. Дальше - каждая сущность это класс, каждое отношение это метод, каждый параметр, выясненный в процессе, это свойство класса. Но чем дальше в лес, тем больше грабли. На уровнях выше начинаются модули со своей инкапсуляцией, события, гонки всякие, а-ля "кто съел яблоко, вы или противник", асинхронное взаимодействие, подписки на что-либо, и так далее, интерфейсы становятся сложнее, какие-то объекты передаются как параметры и всё такое, но общий принцип остается - сначала большими кусками всё делится на куски поменьше, определяются интерфейсы (кто что может спросить или повлиять на кого), пытается реализовываться, потом, вполне возможно, находятся противоречия, которые приходится устранять рефакторингом, и по спирали.

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

IT - это супер интересная область. Тут огромные возможности , потому что компьютер даёт эти возможности. Потому что без компьютера невозможно уже сделать что-то конкурентное. Любое производство, любой текст, любая информация - это компьютер! IT - очень разнообразная сфера. Это не только "кодить в IDE" и "попивать кофе/смузи" и "сидеть за монитором по 18 часов" - это и оптоволокно и спутниковая связь, и работа автомобильных систем, и станки и тракторы и ракеты. Как и любая профессия, она может быть очень интересной и очень скучной.

Люди чаще недовольны, чем счастливы и это недовольство заставляет их двигаться вперёд - удовлетворять свои материальные и духовные потребности :) и это нормально :)

Любая профессия интересна по своему и это всё субъективно. IT - одна из немногих сфер которая позволяет жить и работать там где хочется и при этом зарабатывать те деньги на которые можно комфортно жить.

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

Счастье наступает когда человек может то что хочет и хочет то что может :)

Общий ответ только один, имхо:

Фронтенд разработчик должен решать фронтенд-задачи, которые перед ним ставят. Вёрстка в принципе относится к понятию "фронтенд". Если перед фронтендером ставят задачу сверстать что-то -- он должен уметь это делать..
А вот есть ли у фронтенда задачи по вёрстке -- это уже очень субъективно, на каждом проекте по-разному

Опять же, имхо:
Чем лучше фронтенд верстает -> Тем лучше он может решать задачи + шире круг задач, которые он может решать -> Тем он дороже на рынке

git init не нужен, если потом используется git clone.

Ошибка из-за того, что на сервере есть изменения, которых у Вас нет в локальном хранилище.
Нужно сделать git pull перед git push.

> информация укладывается неструктурировано, отрывками, а хотелось бы, чтобы в голове все было разложено "по полочкам"

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

(function( ) {
})();

Вот эта конструкция называется "анонимная самовызываемая функция".

То есть, тут два действия:
Объявление анонимной функции

function( ) {
}

и сразу ее вызов
()()
Первые скобки это синтаксический приём для вызова анонимной функции. Есть и другие методы. Например
+function(){}()
Вторые скобки - это собственно вызов функции и при необходимости передача параметра (обычный вызов же)

()(jQuery) — в параметре передается jQuery

function($){} — а тут этот параметр объявлен и используется

(function($){})(jQuery) — итого, объявили анонимную функцию, и вызвали ее, передав параметром объект jQuery

Например, доллар у вас используется другой библиотекой, пусть MooTools.
Тогда вы запускаете jQuery в безконфликтном режиме

jQuery.noConflict();

Это значит, что доллар использоваться не будет, и объект будет доступен только по ссылке jQuery.

Но для удобства вы можете использовать анонимную функцию и безопасно использовать внутри неё переменную доллара

(function($){
  $('.slider').slick();
})(jQuery);

Чтобы стало совсем понятно, конструкцию можно переписать без анонимной функции

var myFunc = function($){
 // some code
}

myFunc(jQuery);