Я сам далеко не специалист в Rx, просто попалась на глаза статья с интересным названием — вот решил перевести для себя и для других. Комментарии об этом подходе, плюсах и минусах — это приятный бонус и для меня в том числе :) Если ж тема интересна, думаю найдутся те, кому есть что рассказать и от себя. И я буду иметь в виду, если ещё что-то попадётся (специально искать и отсеивать пока времени нет). А вообще Rx на вид довольно просты, если есть опыт работы с LINQ.
Тема по замене событий на Rx (или обёртки событий в Rx) второй раз мне уже попадается — вот и заинтересовался и решил опубликовать для сообщества.
Планируется ли делать грид вариативным под размер, как в бутстрап 3? Т.е. когда есть разные классы для разных экранов (col-xs-12 col-md-6 col-lg-3) — очень удобная штука.
У нас используется grunt-usemin + grunt-filerev и, когда я впервые читал про gulp, для них ещё не было аналогов, сейчас вот нашёл gulp-usemin, на первый взгляд полный аналог, но не уверен. И есть ещё пара кастомных тасков, которые опираются именно на список файлов. Т.е. смысл в том, что это можно перенести на Gulp, но там всё равно будет необходимость читать список файлов либо как-то по другому сам процесс организовывать.
Сейчас время полной сборки занимает пару минут, что вполне устраивает для разворачивания на сервере, а локально сборка запускается только по конкретным задачам, которые проходят очень быстро (типа собрать JST файл из набора шаблонов). А редактируем мы gruntfile крайне редко. Так что смысла переходить на gulp никакого нет у нас, только пустая трата ресурсов будет. Да и, честно говоря, в нашем проекте конфигурационный стиль файла сборки больше подходит, чем кодостиль gulp-а.
А про виртуальную файловую систему — не совсем справедливо про gulp, всё таки там потоки и их явное использование. А виртуальная ФС — это когда пишешь file.write( '*/dir1/dir2/file' ); file.read( '*/dir1/dir2/file' ); — а grunt понимает, что надо не к реальной ФС обращаться, а взять указатель на буфер из некоего словаря в ОП. Но смысл — хранение данных в ОП — да, один.
Из своего опыта:
1) Подгрузка всех плагинов у нас выглядит так: require( 'matchdep' ).filterDev( 'grunt-*' ).forEach( grunt.loadNpmTasks );
2) У нас были проблемы с grunt-concurrent — он переиначивал параметры командной строки (проблема оказалась даже не в плагине, а в самом grunt, проблема с булевыми параметрами)
3) Были и проблемы со скоростью — сборка занимала до 40 минут, решилось обновлением версий плагинов и заменой некоторых на более продуктивные аналоги
4) Gulp нам не подходит именно из-за потоков, есть несколько специфичных тасков, которые можно организовать только при работе с файлами
И есть у меня такая мысль, что можно сделать grunt таким же шустрым, как и Gulp, реализовав в нём «виртуальную» файловую систему — когда файлы читаются с диска и сохраняются их промежуточные версии по специальному пути в оперативной памяти, а по окончании всех операций записываются на диск уже по реальным путям. Но я посмотрел исходники grunt мельком и понял, что быстро и просто это не реализовать… Но если есть евангилисты grunt — дарю идею.
Я посмотрел видео, и вот прям захотелось поиграть в такого Марио, без обилия смертей и нервов.
Может реализуете, если уже есть почти готовый вариант? Можно пару новых инструментов дать Марио: фонарик, осветительная ракета и т.п. Из пейзажев просится наверху ночной (с луной и звёздами — посветлее), а в подземелье и так темно, там можно какие-нибудь катокомбы нарисовать.
Вот не надо кидаться терминами, даже не поинтересовавшись происхождением слова и возможными формами употребления. У слова «интегрировать» есть специальное значение, которое как раз применяется к людям. А про функционал правильно написали, надо говорить функциональность, другое дело, что язык действительно живой и, думаю, что скоро слово функционал по отношению к ПО совсем приживётся, и троллить будут только, разве что, пожилые преподаватели в вузах.
— вот это вещь, вот это я понимаю. Сидишь в авто, делаешь дела свои находу, а тебе ещё оттуда голос с эхом такой: «через сто метров поверните направо». (Заяптая решает многое, где поставишь, то и получишь, а без неё ещё лучше.)
Хорошего именно простота логики, не надо заботиться о что откуда почему пришло и как это себя поведёт если… Не стоит усложнять там, где это не требуется, и стоит упрощать там, где это возможно.
Я не спорю, что бывают задачи разные и разные подходы к их решению, и каждому унструменту свою задачу. Я высказал своё мнение, что я лучше разобью логику на более простые составляющие, чем буду применять «множественное наследование», и да, я считаю, что если это самое множественное наследование применяется повсеместно, то стоит пересмотреть подходы к проектированию/программированию.
Серебряной пули не существует, на этом давайте и закончим, и без того затянувшийся и слишком абстрактный разговор.
Множественное примешивание — это простая операция, которая не сохраняет информацию о перегрузках методов, она их просто перекрывает и всё. После примешивания вы не можете обратиться к источнику примеси (т.к. это не требуется), и не можете знать какой источник предпоследний и т.д. В общих словах, вы ориентируетесь на результат без истории его возникновения.
Не холивара ради, но множественное наследование говорит лишь о проблемах в обсерватории. Мне много где приходилось применять обычное наследование (одиночное, хоть на прототипах, хоть классическое), и много делал полезных примесей, которые придают объекту определённые «способности» (удачно подобранное выражени в статье). Но множественное наследование — это перебор. IMHO.
Вот спасибо, а то у меня а Aspell почему-то multilang не завёлся (показывает пустой список и всё тут), а с Huspell всё отлично и портабельно, и устанавливать ничего лишнего не надо.
Спасибо. Теперь я знаю какой костюм у капитана очевидность
Вот это предложение имел в виду, промахнулся с тем, куда кат указывает.
Первое предложение после ката переведено с противоположным смыслом (оригиналу и заголовку)
Тема по замене событий на Rx (или обёртки событий в Rx) второй раз мне уже попадается — вот и заинтересовался и решил опубликовать для сообщества.
Сейчас время полной сборки занимает пару минут, что вполне устраивает для разворачивания на сервере, а локально сборка запускается только по конкретным задачам, которые проходят очень быстро (типа собрать JST файл из набора шаблонов). А редактируем мы gruntfile крайне редко. Так что смысла переходить на gulp никакого нет у нас, только пустая трата ресурсов будет. Да и, честно говоря, в нашем проекте конфигурационный стиль файла сборки больше подходит, чем кодостиль gulp-а.
А про виртуальную файловую систему — не совсем справедливо про gulp, всё таки там потоки и их явное использование. А виртуальная ФС — это когда пишешь file.write( '*/dir1/dir2/file' ); file.read( '*/dir1/dir2/file' ); — а grunt понимает, что надо не к реальной ФС обращаться, а взять указатель на буфер из некоего словаря в ОП. Но смысл — хранение данных в ОП — да, один.
1) Подгрузка всех плагинов у нас выглядит так: require( 'matchdep' ).filterDev( 'grunt-*' ).forEach( grunt.loadNpmTasks );
2) У нас были проблемы с grunt-concurrent — он переиначивал параметры командной строки (проблема оказалась даже не в плагине, а в самом grunt, проблема с булевыми параметрами)
3) Были и проблемы со скоростью — сборка занимала до 40 минут, решилось обновлением версий плагинов и заменой некоторых на более продуктивные аналоги
4) Gulp нам не подходит именно из-за потоков, есть несколько специфичных тасков, которые можно организовать только при работе с файлами
И есть у меня такая мысль, что можно сделать grunt таким же шустрым, как и Gulp, реализовав в нём «виртуальную» файловую систему — когда файлы читаются с диска и сохраняются их промежуточные версии по специальному пути в оперативной памяти, а по окончании всех операций записываются на диск уже по реальным путям. Но я посмотрел исходники grunt мельком и понял, что быстро и просто это не реализовать… Но если есть евангилисты grunt — дарю идею.
Может реализуете, если уже есть почти готовый вариант? Можно пару новых инструментов дать Марио: фонарик, осветительная ракета и т.п. Из пейзажев просится наверху ночной (с луной и звёздами — посветлее), а в подземелье и так темно, там можно какие-нибудь катокомбы нарисовать.
Я не спорю, что бывают задачи разные и разные подходы к их решению, и каждому унструменту свою задачу. Я высказал своё мнение, что я лучше разобью логику на более простые составляющие, чем буду применять «множественное наследование», и да, я считаю, что если это самое множественное наследование применяется повсеместно, то стоит пересмотреть подходы к проектированию/программированию.
Серебряной пули не существует, на этом давайте и закончим, и без того затянувшийся и слишком абстрактный разговор.