gulpfile в 10 строк? Легко! — упрощаем создание типовых задач

1) Да почему он плохо читаем-то? Что из, скажем, строки со сборкой stylus'а неочевидно при просмотре? Какие тут баги могут быть, если работа скрипта основана исключительно на работе модуля, без какого-либо дополнительного кода? Какая проблема перенести scripts из package.json? У меня подобных проблем до сих пор не возникало.
2) Watch процессы не умирают, а просто выводят ошибку, возникшую при сборке, в консоль. По крайней мере у меня так с вышеуказанными скриптами.
3) Что же есть настолько сложное (или несовместимое) в сборке фронтенда, что это не съест cmd? Вышеописанный (и немного более сложный, этот я немного упростил) набор скриптов вполне себе нормально отрабатывает в и виндовом cmd, и в bash

gulpfile в 10 строк? Легко! — упрощаем создание типовых задач

Про простейшие сценарии в принципе и речь, хотя и сложные вполне реально сделать даже без отдельных js файлов. Но если ограничиваться сборкой ресурсов фронтенда, то каких-то реально сложных вещей и не должно быть, так ведь? А чаще всего только это и требуется. Да и не вижу никаких проблем таскать scripts из проекта в проект точно так же, как и gulp/gruntfile.
Вообще, вот есть статья на тему, может там все это лучше объяснено (важно еще хотя бы пробежать глазами следующую статью, продолжение этой). Лично меня она убедила.

Почему-то не проставились ссылки, вот статьи:
http://blog.keithcirkel.co.uk/why-we-should-stop-using-grunt/
http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/

gulpfile в 10 строк? Легко! — упрощаем создание типовых задач

Флаги доступно и понятно описаны в доках соответствующих модулей, а многие из них повторяются и легко запоминаются (например, -w — watch, -o — output). Тем более в gulp/grunt так или иначе все равно нужно эти флаги задавать, просто по-другому и гораздо более многословно. С большим количеством файлов, действительно, неудобно, но зачем вообще нужно много файлов? Для этого и есть main.js/styl/less/и т.д., где и прописаны всякие require, include, import и т.п. Максимум, что тут можно добавить — это генерация отдельного файла с зависимостями (скажем, генерируем отдельный css со скомпиленным bootstrap'ом, а в main инклюдим только variables, при желании переопределенный), но 2 файла — это не много. К тому же большинство модулей позволяют следить за целыми папками.

gulpfile в 10 строк? Легко! — упрощаем создание типовых задач

А зачем это все, когда можно так?

{
// package.json
// ...
"scripts": {
    "styles:watch": "stylus assets/styles/main.styl -w -r -u kouto-swiss -o public/assets/main.css",
    "js:watch": "watchify -d -t debowerify assets/js/main.js -o public/assets/main.js",
    "server": "node app.js",
    "livereload": "node livereload.js",
    "start": "parallelshell \"npm run styles:watch\" \"npm run js:watch\" \"npm run server\" \"npm run livereload\""
}
// ...
}

Ну, только livereload-сервер нужно дописать, еще строка:

require('livereload').createServer({ port: 1234 }).watch('public/assets');

Неужели это сложнее?

Используем возможности CSS4 уже сегодня с cssnext

И это не есть хорошо. Так что я действительно расстроен)

Используем возможности CSS4 уже сегодня с cssnext

Да, лично я считаю, что это неверный шаг, так как он по-прежнему является именно «сахаром», даже на уровне языка в случае с ES6. Прототипы-то все равно никуда не делись, в итоге они и получаются! И это нужно понимать при программировании на JS, и как раз это то, в чем не все с ходу разбираются (и себя я тоже подразумеваю, я долго доходил до философии JS после Java и C#, да и не совсем уверен, до конца ли я дошел), а ключевое слово class в JS только ставит палки в колеса при понимании этого.
Нет, я не могу спорить с очевидным — код с сахаром может (но может и нет) выглядеть более читаемым, но это не должно достигаться путем подмены понятий, так как ведет к фундаментальному непониманию.
Да и, кстати, с выходом ES6 отпадет необходимость использовать «трансшпилеры», если, конечно, те не придумают какую-то убер-фичу.

Используем возможности CSS4 уже сегодня с cssnext

Да, и по поводу JavaScript: «трансшпилеры» (если имеются в виду всякие TypeScript и CoffeeScript) — это редкая кака, вызванная неспособностью людей после классических ООП языков понять концепцию прототипов. Ну нету в JS классов, смиритесь с этим, люди! Так нет, в JS зачем-то добавляют классы, хотя их там быть не должно… Нет, там, безусловно, есть удобные штуки вроде скобочной нотации анонимных функций, но зачем мне все это, если у меня есть IDE с автодополнением, а на выходе один хрен мы получаем JavaScript? Тоже, в общем, непонятно мне это.

Используем возможности CSS4 уже сегодня с cssnext

Если рассматривать с точки зрения фронтенд разработчика, то вообще без разницы, использовать ли less/sass/stylus или postcss с плагинами. Но тут такая беда: css сам по себе — это не более, чем просто таблица стилей, что ярко показывает расшифровка аббревиатуры. Тут не нужны какие-то супер-пупер плагины, а достаточно того, что уже есть в препроцессорах, а именно переменных, автопрефиксов, в редких случая циклов, вложенности и замены некоторых свойств на их более совместимые со старичками конструкции (необходимость которых падает с каждым днем со скоростью, сравнимой со скоростью развития postcss).

Итого лично я стал бы использовать postcss в том случае, если он ИЗ КОРОБКИ и БЕЗ ДОПОЛНИТЕЛЬНОЙ НАСТРОЙКИ ПЛАГИНОВ давал бы мне больше, чем stylus. Но stylus (с 1 модулем kouto-swiss) уже дает мне все, что нужно. Если углубляться, то stylus, к тому же, дает объективно больше, чем остальные препроцессоры.
А зачем мне «язык программирования» для css? Я считаю, что оно того не стоит и роль postcss в будущем написания стилей сильно преувеличена.

Все это, конечно, только мое мнение, но сложено оно исходя из опыта реальной работы и прочтения кучи статей на тему.

Используем возможности CSS4 уже сегодня с cssnext

По мне так это все высосано из пальца. Практически все из этого или есть в существующих препроцессорах, или достигается миксинами, или просто поддерживается большинством браузеров (тот же rem). По сути из всего списка действительно полезная и новая вещь — это пользовательские селекторы (не уверен, но вроде в less, sass, stylus такого нет). Хотя только из-за этого я вряд ли пересяду со stylus'а.

Что нужно знать о Битриксе некоторым потенциальным покупателям

С выводом согласен — очень навороченная система для интернет-магазинов, учтено все, что можно учесть. Для других проектов с большой вероятностью найдутся решения получше.
Ну а насчет инфоблоков — это плата за универсальность. Посмотрите на тот же друпал или вордпресс (с каким-нибудь acf) — там все так же, кастомные поля хранятся отдельно от постов/нодов/элементов инфоблока. Хотите свою структуру — используйте фреймворки.

Не совсем крутой Ruby

Недавно начал изучать Python, но очень быстро был вынужден закончить. У меня полилась кровь из глаз, когда я увидел, что в метод первым параметром передается this, и я не смог продолжить.

Программист == творчество || программист != творчество

Словоблудие. Творчество — это не более чем слово. Важно не то, как ты обзовешь свое дело, а то как ты его воспринимаешь. Ярлыки не имеют никакого значения. Хочешь быть творческим? Будь! Не хочешь? Ну не будь тогда! Все ж просто :)

Приятная сборка frontend проекта

Насчет Bower согласен. Стоит его добавить. Но жалко, конечно, что нельзя только нужный файл тянуть… Точнее, я читал, что как-то можно, но это будет не универсально, так как структура файлов проектов не у всех одинаковая.

Jade — да, я его тоже пробовал на этом же boilerplate. Очень удобно, но его можно легко поставить вместо HB добавлением зависимости в package и небольшой правкой кода в engine.js (собственно, для этого я и вынес код для шаблонизатора в отдельный файл). Нужно будет поправить документацию с учетом возможности ставить свой шаблонизатор.

Приятная сборка frontend проекта

Недавно делал нечто подобное, но без bower (мне не нравится, что bower тянет за собой содержимое всего репозитория вместо одного js-файла) и с шаблонизатором Handlebars (ведь даже на фронте часто проще заполнять пространство в цикле, например, а не писать голый html). Так же livereload работает веселее — он не перегружает всю страницу, если изменены стили, а только перегружает сами стили. Ну и я использовал grunt, хотя можно попробовать и на gulp перейти.
Ну и вообще у меня как-то попроще получилось, хотя вроде все примерно то же самое)
Вот, если кому интересно — github.com/mrTimofey/boilerplate

Описание одной интеграции 1С и Битрикс, и почему я не рекомендую своим клиентам использовать такую интеграцию

Работает то, что было необходимо для клиента. То есть то, что я перечислил выше.
Оплата задается на уровне заказов. Выгрузка заказов осталась стандартная коробочная. Она не завязана на структуре данных сайта, поэтому не имело смысла ее делать.
Да, как я и сказал, колонок цен несколько.
Нет, этим вопросом я не занимался, но подозреваю, что это достаточно легко исправить. Просто не было необходимости.
Нет, складов нет. Но, если подумать, что такое склад, то тут должно быть все очень просто — есть идентификаторы складов, по каждому из которых к товару привязывается его остатки. Легко доработать (30 минут чистого времени, если все действительно так просто).
Актуализация остатков тоже есть, я это упоминал. Если вы об изменении остатков в момент заказа на сайте, то этим скрипт выгрузки уже не занимается.
Честно говоря, не знаю, как в CML выглядит резерв. Но не думаю, что случай более сложный, чем склады.

Готов доработать и оформить как битриксовый модуль. Вопрос вашего желания, возможностей и готовности подождать.

Описание одной интеграции 1С и Битрикс, и почему я не рекомендую своим клиентам использовать такую интеграцию

Для самостоятельного написания нужно всего лишь изучить формат CommerceML, что не так уж и сложно, а так же хорошо владеть API битрикса. В 1С разбираться совершенно не обязательно. Я лично уже 3 сайта сделал на собственном скрипте для выгрузки, причем один из них был вынужден применить на сайте, где работала коробочная выгрузка, так как в один прекрасный момент она перестала работать (1С просто зависал на 10-15 минут, дальше ничего не происходило). По опыту могу сказать так: да, на первом сайте я потратил около 2-х дней (с учетом возникших багов и доработок) в общей сложности на создание выгрузки с разными колонками цен, розницей/оптом, наличием товара и SKU. Для второго сайта мне понадобилось около часа на его адаптацию. В третьем, в котором как раз требовалось выпилить стандартную выгрузку, я провозился около часа-двух, и то в основном время было потрачено на разбор существующей структуры сайта.

Из минусов решения — отсутствие настройки из админки. Но кто будет настраивать выгрузку? Скорее всего программист, который сможет заглянуть в код и поправить настройки. Я старался все подробно комментировать и выносил настраиваемые моменты в переменные в начале файла.
Из плюсов — полная кастомизируемость под структуру сайта. В отличие от стандартной, в которой все наоборот — структура сайта должна быть подогнана под выгрузку. Так же мой вариант работает значительно быстрее.
Единственное, что действительно требует доработки — это разделение выгрузки на несколько подходов, так как она может не отработать на хостингах из-за ограничений по времени выполнения.

Описание одной интеграции 1С и Битрикс, и почему я не рекомендую своим клиентам использовать такую интеграцию

Согласен, проще обмен на стороне битрикса сделать самостоятельно — меньше проблем в будущем. У битрикса API остается совместимым со старыми версиями, так что самописную выгрузку обновлениями не сломаешь. А со стороны 1С в любом случае все приходит в формате CommerceML, который тоже вряд ли сильно меняется. А если и меняется, то проще свой код поправить, чем ковыряться со стандартной выгрузкой. Да даже чужой код проще, что уж там)

Opera 12.17 пытается обновиться до 25

Я вас понимаю, я сам когда на опере старой еще сидел — верстал изначально под нее и тоже проблем не было с другими браузерами. А вы спросите тех разработчиков, которые писали под хром — они вам скажут другое.
Я немного не прав был в том плане, что опера была менее распространенной среди разработчиков, что и явилось причиной проблем с ней. 2 место потому, что на ней реально не все вещи работают так же, как в том же хроме или фф (обратное не верно), а люди, которые не тестируют верстку в опере изначально, соответственно, могут столкнуться с проблемами. Но это не осел, конечно. Количество проблем с ослом в разы больше, естественно.
И не надо в меня стрелять, я сам «болею» за оперу)

Opera 12.17 пытается обновиться до 25

Все равно новая опера мне нравится больше, чем хром. И из фишек, которых лично мне не хватало, сейчас нет как раз только группировки вкладок. И, что очень важно, веб избавился от еще одного движка, который занимал 2 место по количеству проблем в верстке. Не подумайте, мне очень нравился их движок, во многом он работал лучше аналогов и не был таким прожорливым как фф на тот момент и хром. Но это еще один движок, и, как следствие, еще один браузер для отладки, что с точки зрения разработчика не есть хорошо.

Opera 12.17 пытается обновиться до 25

Если я не ошибаюсь, опера обещала не обновлять старую ветку до тех пор, пока в новой не будут реализованы все фичи старой.
Хотя они как минимум не реализовали группировку вкладок (из того, чем я пользовался в старой).