Я пока только поглядываю в сторону реакта и после прочтения возник вопрос насчёт того, что в редьюсер передаётся состояние, которое нельзя изменять. Если изменять, могут быть нежелательные последствия. Не лучше было ли тогда, если бы редьюсер вызывался с копией состояния, которую можно и даже нужно изменять, впрочем если создать новое тоже ничего плохого не произойдёт?
Есть какая-то логика именно в том как сейчас?
По дороге люблю слушать подкасты на английском, кроме попсовых типа English as a Second Language Podcast, могу посоветовать Luke’s ENGLISH Podcast. Это учитель английского, подкаст не формальный и веселый, больше для развития лексики, он там мометы разные поясняет, иногда разбирает, но в основном только в начале, дальше больше просто разговоры на разные темы.
Ну и не по теме, с удивлением понял, что я на хабре, а не на гиктаймсе.
Допустим поместят к вам обычные сайты визитки фотографов, небольших фирм и прочее. Никто из них и вместе они взятые не будут выедать 100% времени процессора, памяти и т.д. С другой стороны сервера работают, потребление у них хоть и не такое как при полной нагрузке, но есть. В итоге клиенты почти не платят, расходы у вас есть.
Скажите, пожалуйста, где ошибка в рассуждениях? Вижу пока только вариант, что если они не выедают, то можно к ним еще в 10 раз больше сайтов добавить, но они могут занять у вас все место, а процессор так и не загрузить с ОЗУ. Клиентов ограниченное количество, только их часть к вам прийдет, если почти все будут аморфные и мало активные, непонятно что делать.
Или вы сами в другом облаке и за неиспользованные ресурсы вам платить не надо?
Не убедили. Да npm может запускать задачи, да через консоль многие нужные вещи можно запустить, а если нет, то запустить свой скрипт, а в нем запустить то, что нужно. Есть даже переменные, громоздкие, конечно, $npm_package_config_*, но все же. С другой стороны, с тем же успехом можно просто свой скрипт на ноде, но к чему все эти велосипеды.
Про сложность. Для продакшена тот же css надо собрать из исходников, прогнать через автопрефиксер, возможно, объединить с какими-то другими стилевыми файлами не из исходников, сжать; если селекторов более 4096, разрезать для старых ие; пройти cache buster'ом, обновив пути в шаблонах. Если берем емейл рассылку, то заинлаинить в style атрибут, а все media queries в head. Не то, чтобы есть какая-то сложность когда есть просто ряд задач, но сложнее чем ваш пример. В статье предлагается написать гигантские строки, по типу
1. Зачастую файл стилей не один, а несколько, например, ие специфичный, общий, мобильный. Сейчас у нас собираются файлы все из папки, которые не начинаются на нижнее подчеркивание. Мы просто добавляем файл в папку исходников стилей нужный и он собирается. В вашем примере легко понять как собрать конкретный файл, как собрать все файлы, а дальше стандартными средствами npm я не знаю как отфлильтровать файлы подходящие под одни условия и не походящие под другие. По мне есть два варианта, я через апи работы с файловой системой сам их найду и скормлю тулзе, либо уже надо, например, на баше сначала файлы это отфильтровать, а потом уже скармливать, можно, как вариант упомянутый в вашей статье, использовать nodejs альтернативы в командной строке (rimraf для rm, таже проблема с cp и другими). Все это не то, чтобы упрощает работу по сравнению с настройкой гранта, например.
2. Без внешних файлов, с переменными какая-то боль, мне удобнее в гранте написать
'<%= path.production %> чем громоздкое $npm_package_config_path_production, либо выносим конфигурацию во внешний скрипт, и запуск задач, чтобы они настройки брали оттуда тоже (справедливости ради некоторые могут брать настройки из json файла переданного как аргументв командной строке, но другие то не могут). Сейчас, например, у нас около 10-15 конфигурационных пременных, это по сути единственное, что мы иногда меняем заводя новый проект.
3. У сборки стилей, например, да и других ресурсов у нас обычно три таска: сборка во время разработки, для продакшена и компромисный, когда идет сборка в папку для продакшена не минифицированных версий (нужно при передаче на поддержку сторонним организациям, которые работают по-старинке). Похожая ситуация с js. Сейчас у нас около 15 плагинов-тасков, для части из них сформулированы несколько тасков-задач, из них формируется 3-5 сценариев. Хранить все это громадье в package.json и править не удобно, особенно когда команда и все её параметры записаны в виде одной длинной строки. Опять выходом будет вынести все в отдельные файлы, но в отличие от гранта с плагинов автозагрузки, например, задачи уже автоматом не подхватятся просто на основе используемых плагинов, а придется их прописать. Хотя можно, написать, свой автозагрузчик…
4. Приходим к набору файлов, который да можно таскать из проекта в проект, но это велосипед, который надо будет осваивать новому разработчику, с другой стороны Grunt/Gulp в любом случае известней и он может быть с ним знаком.
5. Как сделать стандартными средствами так, чтобы запустить несколько задач в параллель, а потом результат их выполнения передать в третью, притом кроссплатформенно? Может это просто, конечно, но опять же зачем мне решать эту задачу, если её решение идет в виде плагина, который нужно только настроить.
Таск-раннеры вам дают готовую архитектуру, если она вам не нужна, как и куча плагинов, то это нормально, с другой стороны не вижу смысла агитировать переезжать на npm scripts (что не далеко от написания своего велосипеда, когда требуется что-то по-сложнее), если таск-раннер справляется со своей задачей.
Ну и, конечно, я до сих пор не могу отойти и понять, как такое можно всерьез предлагать
Не поводу топика, а в целом про то, что таск-раннеры не нужны.
Мне, кажется, есть некоторое лукавство во всем этом «Grunt/Gulp/etc на помойку, я все задачи могу написать в package.json». Оверхед на простейших сценариях очевиден, но в сложных сценариях не все так просто.
Да этот код не сложнее, но передавать параметры в виде аргументов командной строки то еще удовольствие, хотя можно завести по отдельному файлу на задачу и запускать их, а потом можно даже некоторые настройки общие, например, основные пути вынести в другой файл, чтобы править было удобно, а потом… получим свой таск-раннер.
Да, есть оверхед в сценарии когда вам надо запустить пару тройку задач в параллель, но если у вас с десяток задач, которые надо организовывать в сценарии, да желательно так, чтобы это таскать из проекта в проект, то не вижу смысла не использовать готовую архитектуру для этого.
Согласен с вами. С пробелами, надо дополнительно решать сколько именно их ставить, зачем это надо непонятно. Размер приятного отступа индивидуален, зависит от шрифта, как IDE их показывает, от размера экрана и вообще вкусовщина, где разумных доводов уже не найти. Кроме того, при клике мышкой четко в отступ не факт, что попадешь.
Не могу понять в чем проблема, представим есть населенные пункты:
A – B – Москва – D – E
На табло A – E. Вы имеете ввиду, что если я очутился в B, мне надо в Москву, и я не знаю, где B, то у меня три варианта, исходный
A – B – Москва – D – E
и два о том, что B между Москвой и E
A – Москва – B – D – E
A – Москва – D – B – E
и, если выберу два последних, то я подумаю, что электричка уже Москву прошла и поеду в направлении от неё?
В таком случае беда, конечно, но ведь, если мне нужно не в Москву, то, если не писать текущую станцию и все до самого конца, я без знаний тоже не буду знать куда ехать, поэтому логично предположить, что я что-то да знаю или могу уточнить.
Если я знаю где я нахожусь приблизительно, т.е. что B до Москвы (между A и Москвой), то проблемы нет.
Всегда считал, что интуитивно понятно, что электричка Царицыно-Москва идет в Москву, Москва-Царицыно наоборот. Соответсвенно, надо указывать обе конечные станции в нужном порядке, а не одну и направление
Для подмены статики с боевой, пути к которой прописаны в шаблоне, на результаты динамической генерации доступные на локалхосте удобно использовать proxy модули www.npmjs.com/package/grunt-proxy github.com/drewzboto/grunt-connect-proxy
Раньше использовали Charles для этого. Если у человека настроен локальный сервер, например, nginx, то можно и в нем настроить, например, example.dev у меня, как раз всю статику будет забирает с сервера поднятого грантом, а example.test уже отдает сайт без подмены статики, выдывая сгенерированную продакшен версию ресурсов, но использование модуля дает большую переносимость все же.
Для деплоя, раньше использовали capistrano, git-хуки, после статьи для простых сценариев перешли на grunt-shipit
В простых случаях используем grunt-rigger для конкатенации js, в отличие от других модулей, хотелось прописывать все в самом файле
//= partials/some.partial.js
Видимо сказывался опыт работы с rails, и не хотелось лезть каждый раз в файл настроек сборщика или в хтмл пихать кучу тегов скрипт, которые будет парсить сборщик и заменять потом одним. В статье gulp-версию плагина используют не тольк для js, но у нас такой надобности не было, обычно у шаблонизаторов свои методы для вставки партиалов, у css-препроцессоров тоже.
Есть шапка с аватаркой залогиненного пользователя и фоном, который из спрайта со всеми остальными картинками интерфейса, две картинки в статье и две в комментариях. В обычном случае, это все грузится параллельно в шесть потоков, в вашем из-за блокировок разделяется на три группы в два потока.
Ваше решение, это заранее узнать, что за картинки и подгрузить в невидимости. Такой подход может быть оправдан только в каком-то специальном случае, но тогда понятно почему советы универсального инструмента от гугл вам не подходят.
В отличие от вопроса простого позиционирования скриптов, где суммарное время загрузки одно и тоже и разница чисто визуальная, здесь время загрузки увеличиться в общем случае.
Скрипты блокируют вообще все на время своего исполнения, в итоге, те же самые картинки, которые могли бы группироваться для паралелльной загрузки, обычно это 2-6 потоков, смогут объединяться только по секциям, в итоге очередей будет больше, а значит и время загрузки.
Для примера, у вас по две картинки в трех секциях, хром мог бы загрузить их все параллельно, вместо этого, они будут грузиться последовательно тремя группами по две штуки.
Чуть подробнее есть у тут, статья хоть и старая, но проблема в ней описана.
Хотя, сам я лично использую SASS, на котором ваш миксин еще лакончинее
Есть какая-то логика именно в том как сейчас?
English as a Second Language Podcast должна вести на http://www.eslpod.com/
Ну и не по теме, с удивлением понял, что я на хабре, а не на гиктаймсе.
Скажите, пожалуйста, где ошибка в рассуждениях? Вижу пока только вариант, что если они не выедают, то можно к ним еще в 10 раз больше сайтов добавить, но они могут занять у вас все место, а процессор так и не загрузить с ОЗУ. Клиентов ограниченное количество, только их часть к вам прийдет, если почти все будут аморфные и мало активные, непонятно что делать.
Или вы сами в другом облаке и за неиспользованные ресурсы вам платить не надо?
Про сложность. Для продакшена тот же css надо собрать из исходников, прогнать через автопрефиксер, возможно, объединить с какими-то другими стилевыми файлами не из исходников, сжать; если селекторов более 4096, разрезать для старых ие; пройти cache buster'ом, обновив пути в шаблонах. Если берем емейл рассылку, то заинлаинить в style атрибут, а все media queries в head. Не то, чтобы есть какая-то сложность когда есть просто ряд задач, но сложнее чем ваш пример. В статье предлагается написать гигантские строки, по типу которые конечно можно разделить на строки по-меньше, но авторы предпочли не разделять, например, такое свое творение
1. Зачастую файл стилей не один, а несколько, например, ие специфичный, общий, мобильный. Сейчас у нас собираются файлы все из папки, которые не начинаются на нижнее подчеркивание. Мы просто добавляем файл в папку исходников стилей нужный и он собирается. В вашем примере легко понять как собрать конкретный файл, как собрать все файлы, а дальше стандартными средствами npm я не знаю как отфлильтровать файлы подходящие под одни условия и не походящие под другие. По мне есть два варианта, я через апи работы с файловой системой сам их найду и скормлю тулзе, либо уже надо, например, на баше сначала файлы это отфильтровать, а потом уже скармливать, можно, как вариант упомянутый в вашей статье, использовать nodejs альтернативы в командной строке (rimraf для rm, таже проблема с cp и другими). Все это не то, чтобы упрощает работу по сравнению с настройкой гранта, например.
2. Без внешних файлов, с переменными какая-то боль, мне удобнее в гранте написать
'<%= path.production %> чем громоздкое $npm_package_config_path_production, либо выносим конфигурацию во внешний скрипт, и запуск задач, чтобы они настройки брали оттуда тоже (справедливости ради некоторые могут брать настройки из json файла переданного как аргументв командной строке, но другие то не могут). Сейчас, например, у нас около 10-15 конфигурационных пременных, это по сути единственное, что мы иногда меняем заводя новый проект.
3. У сборки стилей, например, да и других ресурсов у нас обычно три таска: сборка во время разработки, для продакшена и компромисный, когда идет сборка в папку для продакшена не минифицированных версий (нужно при передаче на поддержку сторонним организациям, которые работают по-старинке). Похожая ситуация с js. Сейчас у нас около 15 плагинов-тасков, для части из них сформулированы несколько тасков-задач, из них формируется 3-5 сценариев. Хранить все это громадье в package.json и править не удобно, особенно когда команда и все её параметры записаны в виде одной длинной строки. Опять выходом будет вынести все в отдельные файлы, но в отличие от гранта с плагинов автозагрузки, например, задачи уже автоматом не подхватятся просто на основе используемых плагинов, а придется их прописать. Хотя можно, написать, свой автозагрузчик…
4. Приходим к набору файлов, который да можно таскать из проекта в проект, но это велосипед, который надо будет осваивать новому разработчику, с другой стороны Grunt/Gulp в любом случае известней и он может быть с ним знаком.
5. Как сделать стандартными средствами так, чтобы запустить несколько задач в параллель, а потом результат их выполнения передать в третью, притом кроссплатформенно? Может это просто, конечно, но опять же зачем мне решать эту задачу, если её решение идет в виде плагина, который нужно только настроить.
Таск-раннеры вам дают готовую архитектуру, если она вам не нужна, как и куча плагинов, то это нормально, с другой стороны не вижу смысла агитировать переезжать на npm scripts (что не далеко от написания своего велосипеда, когда требуется что-то по-сложнее), если таск-раннер справляется со своей задачей.
Ну и, конечно, я до сих пор не могу отойти и понять, как такое можно всерьез предлагать
Мне, кажется, есть некоторое лукавство во всем этом «Grunt/Gulp/etc на помойку, я все задачи могу написать в package.json». Оверхед на простейших сценариях очевиден, но в сложных сценариях не все так просто.
Да этот код не сложнее, но передавать параметры в виде аргументов командной строки то еще удовольствие, хотя можно завести по отдельному файлу на задачу и запускать их, а потом можно даже некоторые настройки общие, например, основные пути вынести в другой файл, чтобы править было удобно, а потом… получим свой таск-раннер.
Да, есть оверхед в сценарии когда вам надо запустить пару тройку задач в параллель, но если у вас с десяток задач, которые надо организовывать в сценарии, да желательно так, чтобы это таскать из проекта в проект, то не вижу смысла не использовать готовую архитектуру для этого.
A – B – Москва – D – E
На табло A – E. Вы имеете ввиду, что если я очутился в B, мне надо в Москву, и я не знаю, где B, то у меня три варианта, исходный
A – B – Москва – D – E
и два о том, что B между Москвой и E
A – Москва – B – D – E
A – Москва – D – B – E
и, если выберу два последних, то я подумаю, что электричка уже Москву прошла и поеду в направлении от неё?
В таком случае беда, конечно, но ведь, если мне нужно не в Москву, то, если не писать текущую станцию и все до самого конца, я без знаний тоже не буду знать куда ехать, поэтому логично предположить, что я что-то да знаю или могу уточнить.
Если я знаю где я нахожусь приблизительно, т.е. что B до Москвы (между A и Москвой), то проблемы нет.
www.npmjs.com/package/grunt-proxy
github.com/drewzboto/grunt-connect-proxy
Раньше использовали Charles для этого. Если у человека настроен локальный сервер, например, nginx, то можно и в нем настроить, например, example.dev у меня, как раз всю статику будет забирает с сервера поднятого грантом, а example.test уже отдает сайт без подмены статики, выдывая сгенерированную продакшен версию ресурсов, но использование модуля дает большую переносимость все же.
Для деплоя, раньше использовали capistrano, git-хуки, после статьи для простых сценариев перешли на grunt-shipit
В простых случаях используем grunt-rigger для конкатенации js, в отличие от других модулей, хотелось прописывать все в самом файле
//= partials/some.partial.js
Видимо сказывался опыт работы с rails, и не хотелось лезть каждый раз в файл настроек сборщика или в хтмл пихать кучу тегов скрипт, которые будет парсить сборщик и заменять потом одним. В статье gulp-версию плагина используют не тольк для js, но у нас такой надобности не было, обычно у шаблонизаторов свои методы для вставки партиалов, у css-препроцессоров тоже.
Ваше решение, это заранее узнать, что за картинки и подгрузить в невидимости. Такой подход может быть оправдан только в каком-то специальном случае, но тогда понятно почему советы универсального инструмента от гугл вам не подходят.
Скрипты блокируют вообще все на время своего исполнения, в итоге, те же самые картинки, которые могли бы группироваться для паралелльной загрузки, обычно это 2-6 потоков, смогут объединяться только по секциям, в итоге очередей будет больше, а значит и время загрузки.
Для примера, у вас по две картинки в трех секциях, хром мог бы загрузить их все параллельно, вместо этого, они будут грузиться последовательно тремя группами по две штуки.
Чуть подробнее есть у тут, статья хоть и старая, но проблема в ней описана.