Артём, Честно, никогда не задумывался о доказательстве параллельности (возможно я не прав).
По моему это логично, получаем список файлов и запускаем для каждого обработчик...
Быстрым гуглингом не нашел пруфа о асинхронности.
Но, нашел вопрос об этом - https://github.com/gulpjs/gulp/issues/879
Может натолкнет вас на правильные мысли.
По коду проблем не вижу... Единственное minifi() может долго выполняться и это создает эффект последовательности.
Adamos, вот поэтому еще год-полтора назад перевели остатки проектов с битрикс на laravel, и помельче на wordpress. Избыточность и не поворотливость битрикса впечатляет. =) Не знаю как сейчас, но раньше и от кода в некоторых модулях битрикса.... не просто подташнивало, а...
Хотя на вкус и цвет... Для мелких проектов и небольшим трафом битрикс отлично *почти сарказм* подходит.
Senseich
По моему опыту, бутстрап из коробки (css) не самый лучший вариант для верстки чего-то кроме админок и быстрой верстки интерфейсов с простым дизайном. Ну, и еще проекты отрисованные дизайнером изначально под бутстрап по тз. По мне бутстрап избыточен в своих возможностях для обыденной верстки.
В других варианта верстка сложных превращается в "муки" и ваш файл с версткой вырастает до размеров 2000-5000 строк.
Лично я последние 10-15 проектов верстал уже своей сборкой, миксинов для препроцессоров. Использую те же grid миксины что и бутстрап, прям из исходников бутстрапа брал, и кучу еще всего мелкого с разных проектов и фреймворков...
Советую изучить CSS препроцессоры: SASS, LESS, сам использую Stylus. Системы сборки: gulp, grunt, webpack... Сильно облегчит вам жизнь и ускорит разработку.
Естественно для CSS знать и использовать БЭМ, хотя мне БЭМ не по душе, я использую альтернативу для него: rscss.
Можете глянуть мой старый вариант сборщика (Заливал для себя на память) https://github.com/allardcool/gulpbuild
Врятли сразу поймете что там и как, не зная основ. Но, возможно будет полезно.
Антон Уланов, Кстати да Zero Handoff. Я про него забыл.
Просто когда мы собирали сеть тогда поддержки ZH еще не было, вроде версия контроллера 2.3 еще была. С тех пор так и не перенастраивали. Тогда руководителя смутило (спорить не стали), что все точки на один канал надо переводить, и так работало, так и осталось =)
Здесь контроллер создается в ручную, не через фреймворк. new \App\WidgetController($view, $logger, $table)
Скорее всего для удобства сделано, сразу в контроллере уже будет, и вьюшка, и логгер, и объект для таблицы из бд.
Это решение для какой-то конкретной задачи.
В шахте лифта, на 18 этажей, не будет нормально работать точка доступа wifi, даже направленная. Отражения в шахте, плюс пересечение с другими точками wifi в доме, вам дадут сигнал на 3-5 этажей.
Нужно будет ставить 4-5 точек, на стандартах 802.11r или 802.11k (на обычных точках (g, n) у вас будет видео только спустя несколько секунд после остановки лифта), естественно камера должна поддерживать эти стандарты. Плюс еще стоимость подключение этих точек.
В результате цена за одну камеру по wifi будет раз в 20-30 (точно не скажу) дороже, чем кабелем.
Не думаю, что есть смысл запариваться с wifi.
По первым 3 вопросам вам, примерно, верно ответили выше.
4. Да, вы правы 99% NAT используют из-за нехватки ip адресов. Если у вас есть белый ip, вам повезло с провайдером. Хотя ipv6 уже на подходе (еще лет 5-10 будет подходить =) ), он решит эти проблемы.
5. Скорее всего проблема именно в днс. Попробуйте верните днс гугла и посмотрите трасировку до сервера мидллваре провайдера. Возможно, провайдер просто не передает эти днс выше и гугл днс не знает, что там за сервер для iptv. Думаю провайдер (техпод провайдера) вам не правду сказал, NAS тут ни причем (как вообще с dhcp могут выдаваться одинаковые ip, такое в принципе не возможно при сегментации сети), и скорее сего от отсутствия знаний в этом вопросе, а не из-за того, что хотели соврать =)
Посмотрите в браузере отладчиком, есть ли в ответе в хедере куки...
И проверьте у вас в браузере в куках сессию, может в браузере отключены куки...
В общем смотрите на ответ вашего сервера.
Там будет понятно, выполняется у вас установка куков или нет.
Mikhail Osher: Нет смысла спорить... Весь бэм построен по такой схеме, есть четкие правила. Если вы решите обернуть дочерние элементы в еще 1 див, вы нарушите структуру, у вас появляется между блоком и элементом еще 1 блок. Только в чистом виде bem, в отличие от rscss, вам это простит, но вы всю методологию бэм сломаете, и это уже не бэм, а просто не удобное/длинное именование классов.
Решение простое в rscss (да и в bem), просто меняете структуру слоя и переносите классы на другой блок, меняете стили. Сделайте 2 варианта c rscss и bem, и добавьте див, если не отходить от правил, то вам придется одинаковое кол-во действий произвести.
Уже пол года работаю с rscss (более 20 проектов, 5 из них гигантские просто) и не разу не было таких проблем.
Mikhail Osher: Опять же, вы не поняли сути блоков и слоев. В ">" и есть вся прелесть. Про bem могу тогда сказать тоже самое, он обязывает использовать "__" для дочерних блоков, плюс гигантские имена классов не дают такую гибкость использования слоев =) Хотя спорить тут не о чем, "на вкус и цвет все фломастеры разные".
По моему это логично, получаем список файлов и запускаем для каждого обработчик...
Быстрым гуглингом не нашел пруфа о асинхронности.
Но, нашел вопрос об этом - https://github.com/gulpjs/gulp/issues/879
Может натолкнет вас на правильные мысли.
По коду проблем не вижу... Единственное minifi() может долго выполняться и это создает эффект последовательности.