Денис Белевцов

Нашел решение.

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

Есть такая «секретная» ссылка: www.youtube.com/get_video_info?video_id=XXXXXX
Вместо XXXXXX подставьте хэш видео, который в ссылке на ролик, типа youtu.be/BWCiWZtrWXU после слеша.

По этой (первой) ссылке вернутся URL-encoded данные. Распакуйте их и возьмите параметр url_encoded_fmt_stream_map. Его значение опять надо распаковать как URL-параметры. И из результата вытащить параметр url – это ссылка на единый скачивабельный видеофайл.

Например, в консоли браузера:

function getUrlParams(search) {
    let hashes = search.slice(search.indexOf('?') + 1).split('&')
    let params = {}
    hashes.map(hash => {
        let [key, val] = hash.split('=')
        params[key] = decodeURIComponent(val)
    })

    return params
}
var s = '------'; // здесь длиннющая строка из ответа /get_video_info
var a = getUrlParams(s);
var b = getUrlParams(a.url_encoded_fmt_stream_map);
console.log(b.url); // эту ссылку открываем в браузере - это скачиваемый видеофайл

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

VanillaJS, очень хороший фреймворк. Перешел на него с jQuery и всем советую.

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

Поделюсь с вами вот такой ссылкой:
https://www.youtube.com/playlist?list=PLswdBLT9llb...

Общего между ними то что они работают одинаково. Разницы между ними технически никакой. А вот идеологические различия есть.

Я расскажу о них в контексте PHP. Прошу заметить что протокол HTTP к PHP имеет косвенное отношение потому что он создавался для обмена html страницами а PHP просто расширяет возможности и того и другого.

GET запрос используется чтобы получить данные а POST чтобы отправить. (Напоминаю что технически они работают одинаково).

Поэтому в контексте PHP опираясь на эту идеологию сделали следующим образом:
1. При каждом запуске PHP по умолчанию создаются суперглобальные массивы ($_GET, $_POST).
2. Если в строке запроса есть вопросительный знак(?). То все что после него считается параметрами GET запроса они представлены в формате 'ключ'='значение' и в качестве разделителя используется знак амперсанда (&)
Пример:
GET /index.php?name=Андрей&surname=Галкин
это строка запроса, тут 2 параметра. эти параметры попадут в массив $_GET.
3. $_POST заполняется другим способом. содержимое этого массива заполняется из "заголовков запроса". То есть из места, скрытого от глаз в явном виде. Всю рутину по созданию таких заголовков берет на себя браузер. Хотя иногда и что-то редактируется в заголовках в ручную.

Чаще всего пост запрос используется в формах (для отправки данных).

Например у нас есть форма для входа 2 поля логин и пароль.

Представим что мы используем GET метод. Тогда при отправке формы мы перейдем на следующий адрес /login.php?login=Андрей&password=123 согласитесь что так передавать такую информацию совсем не безопасно. Любой может открыть ваш браузер и начиная вводить адрес сайта он из истории может увидеть ваши пароли и логины.

А вот если бы мы указали методом POST то мы бы получили следующий запрос:
POST /login.php (login=Андрей&password=123) то что в скобочках было бы скрыто и никак не сохранено в браузере.

Теперь другая ситуация например форма поиска. Мы вводим текст и получаем страницу с результатами. Вот тут уместнее GET форма. потому что нам было бы удобно сразу иметь ссылку на результат поиска, то есть добавить в строку запроса можно выразится "Публичные параметры", которыми можно поделиться. И как результат в строке браузера будет конкретная ссылка на текущую страницу. Мы можем ее скопировать, и разместить где-нибудь, или например скинуть другу. И получить при переходе одну и ту же страницу. А не просить других людей зайти на сайт и в поиск вбить определенную фразу чтобы получить необходимую страницу.

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

И еще одна хорошая новость их можно комбинировать, например
POST /index.php?page=login (login=Андрей&password=123) Думаю я уже достаточно объяснил что из этого получится и какие параметры в какой массив попадут.

поставить минимальную стоимость как за полчаса работы.
объяснять, что вы сейчас заняты и поправите через 1-23 часа.
Брать деньги за все время от прихода первого сообщения до сдачи последней правки.
так как вы в режиме оперативного сопровождения.

Совершенно нормальный подход. Пишу так же, пример:

.footer {
    position: relative;
    background-color: @dark-grey-blue;
    color: @white;
    font-size: 12px;
    padding: 20px;
    box-sizing: border-box;

    @media @desktop {
        height: 200px;
        padding: 0;
    }

    &__text {
        display: block;
        text-align: center;

        @media @desktop {
            position: absolute;
            top: 75px;
            left: 15px;
            width: 250px;
            text-align: left;
        }
    }
}

Всё зависит от того, будут ли во флекс-ячейках элементы (используемые только в этом контексте) или блоки (могут быть переиспользованы где-то ещё).

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

<div class="container">
	<div class="container__header"> ... </div>
	<div class="container__body"> ... </div>
	<div class="container__footer"> ... </div>
</div

.container {
	display: flex;
	...
}
.container__header {
	flex: 1 1 auto;
}
.container__body {
	flex: 1 1 auto;
}
.container__footer {
	flex: 1 1 auto;
}

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

<div class="container">
	<div class="container__header">
		<div class="some-header-block"> ... </div>
	</div>
	<div class="container__body">
		<div class="some-body-block"> ... </div>
	</div>
	<div class="container__footer">
		<div class="some-footer-block"> ... </div>
	</div>
</div

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