archelon

На хабре еженедельный(?) обзор новостей по фронтенду и вроде такой же по мобильной разработке, и вроде по бэку тоже что-то такое есть.

Конечно рисуются отдельные спрайты. Ну или делается 3d-модель, которая потом стилизуется под 2d.

Нужен огромный и продолжительный труд, чтобы написать приличную книжку.
Чтобы в ней было не 10 страниц, а много хорошего материала, с примерами, с задачами, с изложением. Оформить, вычитать, отредактировать, договориться с издателем, выпустить, получить какую-то отдачу.
Хорошую книгу ты читаешь долго. Месяц, два, год. Перечитываешь.

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

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

Также видео делать сложнее, чем писать текст. Гораздо дольше. Гораздо дороже.
Редактирование видео вещь в разы более муторная, поэтому чаще просто переснимают короткие блоки, а это опять таки непросто.
То есть сделать видео с таким же качеством материала и с такой же плотностью материала - в десятки раз дороже по всем ресурсам - деньги, время, оборудование.
И при этом никто не будет смотреть месяц видео (160 часов, например). Никто не будет делать поиск внутри видео, закладки на нужные отрывки и использовать видео как справочник.

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

Видео - это разок посмотреть на чей-то практический материал, разок посмотреть как это делает кто-то другой.

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

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

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

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

P.S. Одним из самых важных минусов видео я считаю то, что ты не можешь получать информацию в комфортном для себя темпе, с возможностью быстро перечитать слово/фразу и обдумать ее. Сам читаю множество лекций, и эта проблема, когда скажешь 2-3 предложения быстрее, чем обычно и половина учеников отваливается с бессмысленным взгядом. Так на живом курсе ты можешь обратить на это внимание и перефразировать, а записанное видео уже не изменишь.

Автор, как советует куратор, разберись в себе. Тогда и без нас будешь знать, куда идти.

А ближе к теме...
Записывай слова для гугления:
АСУ ТП, SCADA, ПЛК, автоматизация производства, учёт электроэнергии, телеметрия, промышленная автоматизация.

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

Используй базу, которая у тебя есть, с умом.
Моё мнение, "уеб-программисты" в большинстве случаев - это путь для тех, кто никакой базы не имеет. Не ведитесь на рекламу курсов и предметные статьи/ролики блогеров и ютуберов.

И учти главное: у работодателей голод на хороших технарей в автоматизации производств последние лет 30. А джунов веб-мастеров переизбыток уже 15 лет минимум.

<a href="путь/к/html-файлу">Ссылка</a> плюс CSS стилизация под кнопку

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

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

Смотрите как здесь применяют https://ahrefs.com/blog/ru/audit-obratnyh-ssylok/

В статье эти теги почти в каждом абзаце. Такое форматирование в контенте должно помочь оптимизации. Не надо выделять ключевики более 1-2 раз.

Здесь написано когда и как надо применять https://webref.ru/layout/advanced-html-css/semanti...

"Выстрелить себе в ногу" - это идиома англоязычного мира, означающая причинение себе вреда необдуманными действиями. Языки C и C++ достаточно низкоуровневые языки, чтобы на них можно было делать опасные вещи. При этом первый вообще никак не контролирует действия программиста и позволяет написать любую ересь, а у второго такое количество тёмных уголков, в которых можно ересь сделать случайно, что не все знают даже спецы с десятилетиями опыта. Эти два совокупных фактора превращают программирование на Сях и Плюсах в изготовление приспособлений для стрельбы по собственным ногам.

Это специфичное для blockquote определение, которое Eric Meyer (автор reset.css) позаимствовал у Paul Chaplin. Первая строка content: "" делает так, чтобы у blockquote исчезли кавычки — на случай, если вторая строка content: none не поддерживается браузером, потому что первая строка — это CSS 2, а вторая — это CSS 2.1. В одну строку их записать нельзя, потому что по стандарту для свойства «content» нельзя комбинировать ключевые слова «normal» и «none» с другими значениями.

Вообще, когда встречается перечисление одного и того же свойства с разными значениями, это делается для того, чтобы обеспечить совместимость с разными браузерами. То есть, если, например, браузер не поддерживает «content: none», он применит «content: ""», а другую запись проигнорирует.

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

.some-class {
    background: #e66465;
    background: linear-gradient(#e66465, #9198e5);
}

В этом коде, если браузер поддерживает градиентный фон, он сначала прочитает, что нужно использовать цвет «#e66465», а потом это перезапишется записью «linear-gradient», и итоговое значение будет «linear-gradient(#e66465, #9198e5);». Если же браузер не поддерживает градиент, он сначала прочитает, что нужно использовать «#e66465», а потом увидит неподдерживаемое определение «linear-gradient», проигнорирует его, и итоговое значение будет «#e66465».

оригиналы почтой,
сканы,
ЭЦП

последние две может в эпоху ковид еще сменятся , а то и первую потеснят - но небыстро

Задайте .elipse { margin: 0 auto }, и будет вам счастье

Такие файлы добавляются в .gitignore так же, как и любой другой файл.
Но, подозреваю, что вопрос в другом. Хочется чтобы файлы исчезли из проекта?
Ты видишь, что файл никуда не исчез и сделал вывод, что файл не добавлен в игнор. Но это не так.
По сути .gitignore тебе совершенно не нужен, потому что добавление файла в игнор не удалит его автоматически из репозитория, если он ранее уже был добавлен в отслеживаемые. Этот файл нужен только чтобы случайно не добавить в репозиторий лишнее. Но даже он не помешает нам добавить любой файл в репо командой git add файл

Когда не хочешь видеть файл в репо, просто удали его физически и сделай коммит.

Если же файл нужен в рабочем каталоге, но ты не хочешь его светить в репозитории, то удали файл только из индекса командой git rm --cached имя_файла и закоммить это.