Помнится, в университете проходили универсальный метод «математического бильярда», при помощи которого можно решать подобные задачи для любых размерностей сосудов и искомого количества оставшейся воды.
По-моему, это действительно сложно считать уязвимостью. Но вот у некоторых сервисов присутствует возможность разлогинить юзера без его непосредственного участия, что грустно — вот эти ребята так делают (ОСТОРОЖНО! Вы можете быть разлогинены в некоторых сервисах после перехода по ссылке): http://superlogout.com. Правда, работает мало где — толи уже прикрыли дырки, толи никогда и не работало, но в gmail на текущий момент меня выкидывает.
Забавно, но, когда я пытаюсь похвалиться своей жене и показать, какую штуку запилил сегодня, наиболее частый ответ, который я слышу — «и чо?». А если отвечу «ты не поймешь», обидится. Я в тупике :(
А еще вы однажды можете столкнуться с проблемами со стандартным gulp'овским вотчером (не будет следить за вновь созданными файлами, удаленными, например) — тогда обратите внимание на chokidar.
Gulp — это система сборки проекта, на продакшне обычно его задача — просто собрать конечные файлы и остановиться, а вотчеры используются для разработки. Если нужно следить за репозиторием, то можно написать bash-скрипт, который при изменениях будет запускать gulp для пересборки. Можно, например, вот это допилить под себя.
1. Проверку переданных аргументов удобно делать так же при помощи плагина gulp-util, помимо этого там есть еще набор приятных вкусняшек.
2. Livereload'ов на свете много развелось, мне очень нравится browser-sync. Про использование в разных окружениях, в т.ч. с gulp, можно почитать тут. Там тоже много хороших возможностей, например, синхронизация действий в разных браузерах, возможность открывать сайт на разных машинах в пределах локальной сети и еще много разного.
3. Про перехват ошибок уже выше написали — gulp-plumber для этого хорош.
И еще — постарайтесь не держать все таски в одном файле, а для каждого создавать отдельный, а в основном gulpfile.js реквайрить директорию с тасками — так будет проще переносить их из проекта в проект, оставляя только нужные в каждом конкретном случае.
Недавно занимался настройкой окружения под себя и в итоге оформил это как npm-модуль с возможностью развернуть новый проект: fmp.
Разница с описанными вами процессами небольшая, только прикрутил возможность при создании нового поректа указать используемый css-препроцессор, мне приходится работать с разными, ну и еще по-мелочи. В ближайших планах — добавить вменяемый HTML-шаблонизатор с возможностью определять переменные на любом уровне и устанавливать их значение в подключающих файлах (смотрю в сторону Handlebars и Jade), минификацию файлов и еще мелочевок.
Вообще, из технических специалистов часто получаются действительно хорошие менеджеры, ведь они, в отличии от обычных менеджеров — не технарей, могут гораздо точнее декомпозировать и оценивать задачи, видеть глубинные проблемы, которые могут возникнуть на проекте в перспективе и т.п. Поэтому часто руководство посматривает на своих лучших программистов и продумывает перспективу перевода их в менеджерский состав.
Да, этот пункт есть в чеклисте ([ ] Зависимые поля обновляются синхронно) и мы постоянно за этим следим.
Есть, правда, тонкости. Допустим, когда границы цен можно задавать самому — то у пользователя все равно будет возможность получить нулевую выборку (например, есть два товара, один 10 рублей, второй — 1000, а ползунки цен сдвинули на 100-200). Ну и само обновление фильтра в таком случае оборачивается большим количеством запросов.
Но в любом случае, если скорость работы приемлемая, то этот пункт очень даже желательно выполнять.
Уже не первый год для стилей использую классы вида «class-name», а для javascript — вида «jsClassName». При первом же взгляде на разметку можно понять, какие классы для чего созданы.
Если есть возможность сделать что-то более удобное, чем существующие аналоги, то ответ однозначен — делайте!
Есть еще мысль. Перед тем, как начинать детально кастомизировать каждый элемент/блок, давать выбрать общий цветовой тон (хотя-бы светлый/темный, либо несколько пресетов по умолчанию на выбор), а еще для автоматической генерации цветовых схем можно было бы попробовать прикрутить генератор на подобии colorscheme.ru, правда в последнем не уверен.
Начинаю знакомиться с вашей библиотекой. Дошел до анимаций, сразу возник вопрос: для одновременной смены нескольких свойств обязательно необходимо вызывать метод .animate() несколько раз подряд или можно в одном вызове указать весь набор изменяемых параметров? Как я понял, сейчас можно делать так:
2. Livereload'ов на свете много развелось, мне очень нравится browser-sync. Про использование в разных окружениях, в т.ч. с gulp, можно почитать тут. Там тоже много хороших возможностей, например, синхронизация действий в разных браузерах, возможность открывать сайт на разных машинах в пределах локальной сети и еще много разного.
3. Про перехват ошибок уже выше написали — gulp-plumber для этого хорош.
И еще — постарайтесь не держать все таски в одном файле, а для каждого создавать отдельный, а в основном gulpfile.js реквайрить директорию с тасками — так будет проще переносить их из проекта в проект, оставляя только нужные в каждом конкретном случае.
Разница с описанными вами процессами небольшая, только прикрутил возможность при создании нового поректа указать используемый css-препроцессор, мне приходится работать с разными, ну и еще по-мелочи. В ближайших планах — добавить вменяемый HTML-шаблонизатор с возможностью определять переменные на любом уровне и устанавливать их значение в подключающих файлах (смотрю в сторону Handlebars и Jade), минификацию файлов и еще мелочевок.
Вообще, из технических специалистов часто получаются действительно хорошие менеджеры, ведь они, в отличии от обычных менеджеров — не технарей, могут гораздо точнее декомпозировать и оценивать задачи, видеть глубинные проблемы, которые могут возникнуть на проекте в перспективе и т.п. Поэтому часто руководство посматривает на своих лучших программистов и продумывает перспективу перевода их в менеджерский состав.
Есть, правда, тонкости. Допустим, когда границы цен можно задавать самому — то у пользователя все равно будет возможность получить нулевую выборку (например, есть два товара, один 10 рублей, второй — 1000, а ползунки цен сдвинули на 100-200). Ну и само обновление фильтра в таком случае оборачивается большим количеством запросов.
Но в любом случае, если скорость работы приемлемая, то этот пункт очень даже желательно выполнять.
Есть еще мысль. Перед тем, как начинать детально кастомизировать каждый элемент/блок, давать выбрать общий цветовой тон (хотя-бы светлый/темный, либо несколько пресетов по умолчанию на выбор), а еще для автоматической генерации цветовых схем можно было бы попробовать прикрутить генератор на подобии colorscheme.ru, правда в последнем не уверен.
А хочется чего-то такого: