Сейчас у вас в тихих классах размеров и тем, куча копипасты про шрифт, танзишен и т.д., если понадобиться менять, вы предлагаете менять те же настройки транзишена в пяти местах, а если цветов еще больше, то в еще большем количестве. Зачем код так жестоко дублировать то?
Если он везде пристуствует его можно вынести в отдельный тихий класс %btn-default и extend делать либо в нужных классах кнопок, либо в сами тихие классы им расширить. Хотя, конечно, стоило просто завести класс btn c свойствами по-умолчанию, не стоит слишком увлекаться extend'ами.
Ваше решение должно состоять из единственного файла на JS.
Нельзя загружать никаких модулей, даже тех, что входят в стандартный комплект Node.js.
Так то, если вставить код нужных модулей и библиотек в свой файл, кроме нативных естественно, условия формально выполнятся. Уж, чтобы уж совсем было не подкопаться, то лицензии по использованию это разрешают допустим. Можете как-то более развенуто свою позицию описать, пожалуйста.
2. Можете все-таки как-то определить ограничение по памяти. В погоне за быстродействием понятно, что будет увеличиваться расход памяти, так что коль скоро она ограничена, её количество достаточно важно, особенно в рамках разговоров, что «писем будет много».
Допустим 8/16/etc Гб, чтобы можно было протестировать как-то самим, а то ограничений по памяти нет в теории, а на практике у вас будет какое-то вполне конкретное.
By default, --max_old_space_size (which controls the upper limit of the V8 heap) is ~1.5GB.
Вы будете этот лимит менять? В предыдущих версиях ноды, притом, он менялся не до бесконечности, в новой вроде починили.
3. В связи с предыдущим вопросом опять же, не могли бы вы как-то очертить, хотя бы порядок количества сообщений и фильтров. Например, 10K или даже 100K фильтров одно, 10M уже совсем другое, а если больше, то, вообще, надо думать. Память будет как-то ограничена, надо как-то представлять сколько вообще места у нас, может там места на эти самые письма и фильтры только и есть=).
4. Просто на всякий случай, точно ли ваши тесты на корректность будут проверять, что actions у сообщений перечислены «в порядке перечисления правил в массиве rules»? У вас это упоминается, но просто, может они все-таки коммутативны=)
На олимпиадах по программированию типа ACM тесты тоже не дают.
Да, но результат проверки на этих самых тестах виден сразу, хоть сами тесты и не известны, а не в самом конце, когда уже ничего не исправишь. Так то скрывать тесты и проверку провести в самом конце все же не самая лучшая затея по отношению к участникам. Ждать часа X и обнаружить, что в погоне за быстродействием, ты в скрипте не учел какой-то странный случай, не очень хочется.
P.S.
Конкурс отличный, жалею что предыдущие ваши пропустил, отличная разрядка.
Я пока только поглядываю в сторону реакта и после прочтения возник вопрос насчёт того, что в редьюсер передаётся состояние, которое нельзя изменять. Если изменять, могут быть нежелательные последствия. Не лучше было ли тогда, если бы редьюсер вызывался с копией состояния, которую можно и даже нужно изменять, впрочем если создать новое тоже ничего плохого не произойдёт?
Есть какая-то логика именно в том как сейчас?
По дороге люблю слушать подкасты на английском, кроме попсовых типа 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-препроцессоров тоже.
Если он везде пристуствует его можно вынести в отдельный тихий класс %btn-default и extend делать либо в нужных классах кнопок, либо в сами тихие классы им расширить. Хотя, конечно, стоило просто завести класс btn c свойствами по-умолчанию, не стоит слишком увлекаться extend'ами.
1. Использование стороннего кода
Так то, если вставить код нужных модулей и библиотек в свой файл, кроме нативных естественно, условия формально выполнятся. Уж, чтобы уж совсем было не подкопаться, то лицензии по использованию это разрешают допустим. Можете как-то более развенуто свою позицию описать, пожалуйста.
2. Можете все-таки как-то определить ограничение по памяти. В погоне за быстродействием понятно, что будет увеличиваться расход памяти, так что коль скоро она ограничена, её количество достаточно важно, особенно в рамках разговоров, что «писем будет много».
Допустим 8/16/etc Гб, чтобы можно было протестировать как-то самим, а то ограничений по памяти нет в теории, а на практике у вас будет какое-то вполне конкретное.
Кроме того у самой ноды, если верить github.com/nodejs/node/wiki/Frequently-Asked-Questions на процесс оно есть
Вы будете этот лимит менять? В предыдущих версиях ноды, притом, он менялся не до бесконечности, в новой вроде починили.
3. В связи с предыдущим вопросом опять же, не могли бы вы как-то очертить, хотя бы порядок количества сообщений и фильтров. Например, 10K или даже 100K фильтров одно, 10M уже совсем другое, а если больше, то, вообще, надо думать. Память будет как-то ограничена, надо как-то представлять сколько вообще места у нас, может там места на эти самые письма и фильтры только и есть=).
4. Просто на всякий случай, точно ли ваши тесты на корректность будут проверять, что actions у сообщений перечислены «в порядке перечисления правил в массиве rules»? У вас это упоминается, но просто, может они все-таки коммутативны=)
Да, но результат проверки на этих самых тестах виден сразу, хоть сами тесты и не известны, а не в самом конце, когда уже ничего не исправишь. Так то скрывать тесты и проверку провести в самом конце все же не самая лучшая затея по отношению к участникам. Ждать часа X и обнаружить, что в погоне за быстродействием, ты в скрипте не учел какой-то странный случай, не очень хочется.
P.S.
Конкурс отличный, жалею что предыдущие ваши пропустил, отличная разрядка.
Хотя, сам я лично использую 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-препроцессоров тоже.