Pavel Karinin

Вопрос был решен вот каким образом:
1) DHCP раздает IP-адреса вида 10.10.10.*, а также в качестве DNS адрес самого роутера.
2) Для каждого домена создается запись в DNS Static, где каждый домен (типа делегирован) на адрес вида 10.*.10.10
3) Для каждого адреса вида 10.*.10.10 создается запись NAT (chain=dstnat), и в качестве конечного адреса (ToAddress) указываем 10.10.10.10 и нужный порт (ToPort)
... и всё

Примерно так:

setInterval(() => {
        var user;
        for (const id in users) {
            user = users[id];
            if (parseInt(user.ping) == 1) user.ping = 0
        }
    }, 60000);

В общем-то да, является плохой практикой. <figcaption> должен оставаться связанным с изображением, которое вы размещаете в <fugure>, т.к. (согласно спецификации) <figcaption> представляет собой заголовок или описание для всего содержимого , в котором он находится, при этом в самом элементе может быть размещено несколько разных медиа-объектов (в том числе изображений). Автора можно не указывать, но хоть какое-то минимальное описание приветствуется. В противном случае просто не используйте элемент <figcaption>.

Потому что document.getElementsByClassName('video_item') возвращает массив (коллекцию) элементов, а эта коллекция (будучи своего рода объектом) не имеет такой функции как getElementsByTagName

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

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

Если разместить картинку как img на задний план, то очень просто:

img {
  filter: gray; /* IE6-9 */
  -webkit-filter: grayscale(1); /* Google Chrome, Safari 6+ & Opera 15+ */
  filter: grayscale(1); /* Microsoft Edge and Firefox 35+ */
}

Речь идет о "шагах" при процедурах аутентификации/авторизации.
Если вы не против английского, тут можно подробно об этом прочитать, чтоб не дублировать:
1-legged
2-legged
3-legged

Рекомендую прочитать всю страницу, там для разных версий

Конечно div создается вы его сами добавляете туда, в этом месте:

var containerScriptToHead = document.createElement('div');
containerScriptToHead.id = 'containerScriptToHead';					
head.appendChild(containerScriptToHead);

удалите эти три строки из скрипта и все будет нормально

Будет также относиться к article.
Хотя с точки зрения правильности его лучше отправить в тег header

var item_unitaz = [
{'item_id':1, 'article':'DE23421312', 'name':'Привет','type':2},
{'item_id':2, 'article':'DE12421442', 'name':'Пока','type':32},
{'item_id':3, 'article':'DE78677833', 'name':'Воробей','type':68},
{'item_id':4, 'article':'DE23442235', 'name':'Петух','type':45}];

function compareUnitaz(a, b) {
  if (a.type > b.type) return 1;
  if (a.type < b.type) return -1;
  return 0;
}

item_unitaz.sort(compareUnitaz);

На этот вопрос есть подписчики, не ожидал, что столько, но это говорит о том, что вопрос интересен и это хорошо. Поэтому хоть и я его автор, но отвечу тоже. Я, как человек, который пережил эпохи Mosaic, Netscape и IE (старички меня поймут), отвечу ещё и по той причине, что часто, нет … очень часто сталкиваюсь с тем, что действительно "талантливые" начинающие Front-End тратят попусту свое время, из-за незнания такого, казалось бы, вопроса ни о чем (как выразился Froggyweb) об организации своего workflow и начинают не с того, с чего стоило бы начинать в результате это приводит к тому, что некоторая работа просто дублируется, переделывается и т.д. лишь потому, что изначально об этом не подумал.

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

Я работаю на трёх мониторах: центральный - вёрстка, левый - результат, правый - дизайнерский макет + чего ещё что надо по ходу пьесы, типа киношки, статейки и т.д.;

Среда:
в Visual Studio - для сложных и крупных проектов, плотно подсевших на Back-End;
в Visual Studio Code - для проектов попроще;
хе-хе в Блокноте - для совсем простых))

Музыка – это святое, тем более я её тоже иногда пишу, но слушаю всегда чужую на SoundCloud))

Создаю папку решения

Создаю в ней подпапку всегда с одним и тем же имеем: _native_design, в которую (в зависимости от формата портирую дизайн)

Выбираю явственно общие компоненты страниц (шапка, контент, меню, боковые меню, подвал и д.р.) и для каждого создаю простой пустой файл scss с названием, соответствующим компоненту.

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

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

Исходя из сетки, и из минимально необходимой версии браузеров (речь конечно же об IE), создаю файл _base.scss который наполняю сбросом стиля, и объявлениями для grid (ну все это не вручную, а сниппетами, импортами, инклудами, которые у меня подготовлены почти на все случаи жизни).

Стараюсь придерживаться отлично зарекомендовавшего себя принципа "one base", который подразумевает единую основу для всего макета, т.е. есть одни базовый каркас (основа), и эта основа является местом для навешивания на неё всего необходимого. Часто вижу ошибки в этом плане, когда доходит до того, что ради одно "нестандартного" компонента страницы, встречающегося НЕ на каждой странице, используется отдельный (и не один) базовый стиль (по сути, файл), в котором 90% каскада продублировано с другим и т.п.

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

Шрифты, тоже достойны внимания, т.к. не все дизайнеры знают, что это такое с точки зрения Web, и используют их не по назначению (такое бывает), что требует согласования.

Потом начинается работа с адаптивностью. Я всегда сворачиваю контент, т.е. начинаю с широкого формата, потом desktop, tablet, mobile. Тут ничего сложного нет, особенно когда есть сетка, исходя из того насколько много компонентов плотно зависят от размеров, выбираю как прописывать медиа-запросы, т.е. либо запрос внутри селекторов блоков, либо селекторы внутри запроса. Как правило, используется 4-6 точек + по две на каждую основную точку, т.е. на 1px больше и на 1px меньше, но не всегда, зависит от макета. Не забываем про DPI.

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

Потом начинается JS, т.е. наполнение интерактивом уже не средствами CSS, а именно скриптовым.

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

Короче, как-то так… ради ответа, открыл Word и накатал этот текст. Уверен, что что-то пропустил, о чем-то не сказал, но не судите строго))

UPD:
Забыл сказать: про измерения скорости загрузки и скорости отрисовки. Этому стоит уделять внимание особенно в макетах со сложной композицией! Следует помнить о том, что перед отрисовкой браузеры проводят серьезный анализ DOM и каскада стилей, есть способы оптимизировать эти моменты, это важно для мобильных устройств, если у сайта нет для них отдельной версии. Это же касается и JS в части вашего ручного кода.

UPD2:
Ребят, я Skype указывал не для того, что вы присылали мне на него вопросы. Есть уточнения, пишем сюда или создаем новый вопрос на Тостере. Спасибо за понимание.

Тут недавно "игрались" в такую задачку, и Владимир Проскурин решал ее, посмотрите тут, и адаптируйте под свои нужды.

Если вы не просите нас выложить вам готовый код, то здесь много рассказано про циклы в JS, а здесь про перебор массивов.

Конечно бывало, и бывает постоянно ни с одним языком, так с другим, иногда от собственной "мудрости", иногда по запарке, иногда от небольшого опыта пользования тем или иным языком. Это нормальное явление. Со временем, разумеется, все меньше и меньше, но все равно бывает. Как лечить? - писать, писать и еще раз писать, а главное не просто писать, а понимать что пишешь, как пишешь... нечего писать: придумайте для себя задачу, придумайте сайт - сверстайте его, наполните интерактивом, пока будете это делать опыт и приходит.

Буквально два дня назад делал такую же назвал так: subscriptions
UPD: название должно отражать или как минимум намекать на содержание

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

Буквально перед публикацией проекта, отвечаю себе (а может и другим, в том числе dimonchik2013) на собственный вопрос. Когда я задавался этим вопросом, у меня физически не было возможности проверить свои предположения, поскольку на тот момент только продумывались разные нюансы. Сложность вопроса заключалась по большей части в том, что браузеры по-разному ведут себя со сторонними куки + личные настройки пользователей. И по сей день нет единого рецепта для 100% простановки куки при кросс-доменных запросах, хотя некоторые подвижки есть (но это отдельная тема).

Вопрос был решён комбинированием уже имеющихся практик решения данной проблемы, а именно так: на странице first.com размещаем пустой и невидимый iframe, в него загружаем страницу с домена second.com, которая исполняет сценарий, создавая форму, с методом POST и action-адресом, по которому в ответ сервер выставит куки (разумеется, для second.com, как в моем случае и было необходимо). После этого iframe средствами postMessage может "информировать" родительское окно, что все прошло гладко или что-то случилось в свою очередь родительское окно удалить этот iframe. Все браузеры с включёнными куки, но с разными установками на предмет принятия сторонних куки прекрасно справились с этим сценарием.



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

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

Как-то так (если совсем дословно и не упрощать):

function validateForm() {
    var x = $('#myForm #log').val();
    var y = $('#myForm #pass').val();
    if (x == "" || y == "") {
        $('#demo').html('Hello Dolly.');
        return false;
    }
}