Думаю проблема подхода еще и от фреймворка зависит. В хроме вопросы со сборкой и минификацией сейчас решаются тупо подключением source map, что дает возможность прямо в «инспекторе» редактировать прямо исходники (sass, например). Кейс с внешним редактором так же работает — хром следит за изменениями в исходниках и обновляет окна когда нужно. Но я вовсе не утверждаю, что этот способ универсален — бывает ведь и такое github.com/LearnBoost/stylus/pull/886 :)
Кстати, Chrome 29 версии уже почти подобрался к возможностям плагина (см. habrahabr.ru/post/182036/), а в Chrome 30 это уже практически из коробки (см. Live editing).
Если коротко:
1. Открыть chrome://flags/#enable-devtools-experiments, включить галку, перезапустить.
2. Devtools / Settings / Expriments чекнуть галку «FileSystem inspection»
3. Devtools / Settings / Workspace добавить директорию с ресурсами сайта, и прописать маппинг адреса на сервере и пути относительно выбранной директории ( http://localhost:8080/ -> / или что-то типа этого).
теперь все изменения, сделанные в Chrome, автоматически сохраняются в файловой системе, а изменения в текстовом редакторе отражаются в браузере (возможно, для этого надо открыть исходник файла в редакторе Chrome).
офф: для bem-tools (если вдруг) можно подключать на страницу index.css, вместо _index.css, тогда магия с путями работает правильно.
В среднем Google приходится удалять по 15 миллионов «пиратских» ссылок в месяц…
С тех пор количество DMCA-запросов от правообладателей выросло очень быстро, можно сказать, лавинообразно. Само собой, вручную миллионы запросов никто обработать не в состоянии, пускай даже привлечь к работе целую армию людей.
5,8 RPS. любопытно, какую нагрузку может держать один человек? :)
тема безусловно интересная и похоже, что автор обладает поистине энциклопедическими знаниями в этой области. однако читать такой поток сознания с картинками совсем не просто. :)
допустим, голосуют двое:
5, 4, 3, 2, 1 — первый
1, 2, 3, 4, 5 — второй
хотя у каждого проголосовавшего в отдельности порядок предпочтений определен, в сумме получается, что все претенденты набрали по 6 баллов, и определить объективного победителя невозможно. как я понял, в этом и состоит «парадокс Кондорсе».
ага, и так необходимая всем минеральная вода отсеялась уже бы в первом туре. (
«много туров» адекватно работает, например, в спорте, где участники состязаются между собой в решении какой-то объективной задачи, результат решения которой можно измерить (например, кинуть что-нибудь дальше всех, или проплыть быстрее) — т.е. дать ему формальную оценку. но это принципиально отличается от случая с демократической политой, где у участников нет объективной задачи, а сама оценка одновременно является и результатом, за который идет «борьба». отсюда все заморочки. систем голосования, различной степени сложности, придумана масса, но приемлемого результата нет (в статье есть ссылка на теорему Эрроу). возможно сама постановка порочна.
на интуитивном уровне, от систем голосования хочется формализации некоего чувства справедливости. если она может давать иные результаты, это неправильная система. в системе с простым большинством голосов результат может не отражать основные предпочтения избирателей. это показывает пример.
второй тур может еще сильнее исказить картину. допустим, втором туре победит «квас», как оппозиция тех кто против «водки». но будет-ли этот результат справедлив — ведь истинных любителей кваса, как показал первый тур, только двое (20%)? данная система на этот вопрос ответ не дает. единственный плюс таких систем — результат есть всегда.
Кондорсе, решая эту проблему предложил, систему, где голосующие должны не просто выбирать одного из кандидатов, а ранжировать претендентов согласно своим предпочтениям. в ней результат может сильно отличаться от «абсолютного» (скажем, может победить «минеральная вода», если она окажется у всех на втором месте как самая востребованная — алкоголики лечат печень, трезвенники уталяют жажду, кто-то бадяжит квас и т.п.) но сам же нашел парадокс в возможности ситуации, если голоса оказываются симметричны, то сделать выбор становится не возможным.
кажется, пример с напитками, скорее, иллюстрирует одну из ключевых проблем мажоритарной системы голосования, нежели сам парадокс (возможность ситуации когда голоса, в сумме, получаются противоречивы). поэтому хочется продолжения. спасибо за то, что подняли интересную тему.
Подписываем наши функции на рассылки:
>>> subscribe('insertors', fun)
>>> subscribe('insertors', bar)
ммда, такие примеры можно называть паттернами, в каком-то узком смысле, просто потому, что они достаточно типичны. но на роль хороших архитектурных приемов, они, по-моему, не годятся уже лет как тридцать.)
как выше заметил bolk, в статье перепутаны ФП и процедурное программирование — практически во всех примерах видны все стандартные грабли этого подхода, связанных с плохо инкапсулированным состоянием. как раз ООП с этим и борется, за счет «развесистых схем классов», а в ФП состояния не должно быть как такового (во всяком случае в таком совсем уж явном виде).
абстракция является одной из основных концепций программирования. поэтому что угодно можно написать на чем угодно. в С тоже можно программировать в ООП стиле, думая про классы, наследование и т.п. и в JavaScript ни кто не мешает эмулировать классы через прототипы и клонирование.
в остатке остается лишь чисто инженерный вопрос — вычислительная стоимость подобных развлечений. оптимизация на уровне мета-модели стоит дорого, а зачастую и вовсе не реализуема — поэтому получается хоть и похоже, но на порядок медленнее. вот и вся разница. :)
расскажите, что вы называете термином «Остров»? обычный сниппет выдаче это остров? или остров это некоторая группа сниппетов? а может быть остров это представление сайта в поисковой выдаче где есть интерактивная форма? а врезка это остров?
Если коротко:
1. Открыть chrome://flags/#enable-devtools-experiments, включить галку, перезапустить.
2. Devtools / Settings / Expriments чекнуть галку «FileSystem inspection»
3. Devtools / Settings / Workspace добавить директорию с ресурсами сайта, и прописать маппинг адреса на сервере и пути относительно выбранной директории (
http://localhost:8080/->/или что-то типа этого).теперь все изменения, сделанные в Chrome, автоматически сохраняются в файловой системе, а изменения в текстовом редакторе отражаются в браузере (возможно, для этого надо открыть исходник файла в редакторе Chrome).
офф: для bem-tools (если вдруг) можно подключать на страницу index.css, вместо _index.css, тогда магия с путями работает правильно.
где-то тут же есть поддержка Source Map
еще они пишут про устройства с двенадцати-дисковыми картриджами из дисков и raid.
5,8 RPS. любопытно, какую нагрузку может держать один человек? :)
5, 4, 3, 2, 1 — первый
1, 2, 3, 4, 5 — второй
хотя у каждого проголосовавшего в отдельности порядок предпочтений определен, в сумме получается, что все претенденты набрали по 6 баллов, и определить объективного победителя невозможно. как я понял, в этом и состоит «парадокс Кондорсе».
«много туров» адекватно работает, например, в спорте, где участники состязаются между собой в решении какой-то объективной задачи, результат решения которой можно измерить (например, кинуть что-нибудь дальше всех, или проплыть быстрее) — т.е. дать ему формальную оценку. но это принципиально отличается от случая с демократической политой, где у участников нет объективной задачи, а сама оценка одновременно является и результатом, за который идет «борьба». отсюда все заморочки. систем голосования, различной степени сложности, придумана масса, но приемлемого результата нет (в статье есть ссылка на теорему Эрроу). возможно сама постановка порочна.
второй тур может еще сильнее исказить картину. допустим, втором туре победит «квас», как оппозиция тех кто против «водки». но будет-ли этот результат справедлив — ведь истинных любителей кваса, как показал первый тур, только двое (20%)? данная система на этот вопрос ответ не дает. единственный плюс таких систем — результат есть всегда.
Кондорсе, решая эту проблему предложил, систему, где голосующие должны не просто выбирать одного из кандидатов, а ранжировать претендентов согласно своим предпочтениям. в ней результат может сильно отличаться от «абсолютного» (скажем, может победить «минеральная вода», если она окажется у всех на втором месте как самая востребованная — алкоголики лечат печень, трезвенники уталяют жажду, кто-то бадяжит квас и т.п.) но сам же нашел парадокс в возможности ситуации, если голоса оказываются симметричны, то сделать выбор становится не возможным.
ммда, такие примеры можно называть паттернами, в каком-то узком смысле, просто потому, что они достаточно типичны. но на роль хороших архитектурных приемов, они, по-моему, не годятся уже лет как тридцать.)
как выше заметил bolk, в статье перепутаны ФП и процедурное программирование — практически во всех примерах видны все стандартные грабли этого подхода, связанных с плохо инкапсулированным состоянием. как раз ООП с этим и борется, за счет «развесистых схем классов», а в ФП состояния не должно быть как такового (во всяком случае в таком совсем уж явном виде).
в остатке остается лишь чисто инженерный вопрос — вычислительная стоимость подобных развлечений. оптимизация на уровне мета-модели стоит дорого, а зачастую и вовсе не реализуема — поэтому получается хоть и похоже, но на порядок медленнее. вот и вся разница. :)
если все равно нужно что-то вызывать, в чем преимущество по сравнению с тупо «bower install»?