How to become an author
Search
Write a publication
Pull to refresh

Comments 46

А почему бы не генерить 1 раз из less файлов обычные css-ки? И подгружать, соответственно их.
Total votes 5: ↑5 and ↓0+5
В случаи разработки less файлы я постоянно правлю — по этому постоянно перегенерировать их неудобно. Да и для продакшена — зачем усложнять себе выкладку дополнительным шагом сборки, которого легко можно избеждать.
Total votes 3: ↑1 and ↓2-1
Ну так и разрабатывайте с динамической компиляцией в браузере, а на продакшене компилируйте при сборке приложения.
Total votes 5: ↑5 and ↓0+5
>Ну так и разрабатывайте с динамической компиляцией в браузере, а на продакшене компилируйте при сборке приложения.

Это значит что нужно в продакшене и в девелопменте эти части страницы будут различаться. К чему такие сложности если можно без этого обойтись?
Total votes 4: ↑2 and ↓20
А на кой черт на продакшене использовать не скомпилированный код? Может вы еще и на продакшене в режиме онлайн минифицируете и обфусцируете JS код? Мне почему-то больше кажется, что сложности написаны именно у вас.
Total votes 7: ↑6 and ↓1+5
Да, я так и делаю. В cms, которую пользую на работе, есть фунционал который за меня минифицирует js/css. Я об этом даже не задумываюсь и не вспоминаю при правках. В чем сложность для меня-то?
Total votes 3: ↑1 and ↓2-1
Я конечно, могу процитировать весь топик, но мы же взрослые люди и умеем скролить.
У меня такое впечатление, что вы просто не знакомы с понятием сборки приложения (например maven, ant), и у вас возникает какие-то трудности в понимании, того что для решения проблемы достаточно добавить в сборку для продакшена этап компиляции css (в данном случае сборщик у вас наверное тот самый функционал). А уж простите править файлы на продакшене — это либо форс мажор, либо отсутствие мозга.
Total votes 4: ↑2 and ↓20
лол, они почти всегда будут различаться и для этих случаев очень неплохо подходят штуки вроде fabric, куда полезнее будет ман по управлению ноды из fab, свежо и удобно.
Total votes 1: ↑1 and ↓0+1
… видел программу, которая автоматически перегенерирует LESS файлы при их изменении, но она оказалась платной и только под МакОСь.

LESS.app, winless, less,...?
This comment wasn’t rated yet0
Но да, не уверен про автоматическую компиляцию при изменении.
This comment wasn’t rated yet0
Ага, они. Мне подход с трансформацией на лету больше нравится — получается, как будто less поддерживается самим браузером, мне не надо думать о том у куда и во что генерируются эти самые .less файлы.
Total votes 1: ↑1 and ↓0+1
Хм, у меня это 10 строчек кода маленького демона делают, а люди за это деньги берут ?!
Total votes 1: ↑1 and ↓0+1
Люди берут за удобный интерфейс. Вообще идея УГ. Могу посоветовать почитать про мавен или ант:)
This comment wasn’t rated yet0
while true; do inotifywait -e modify css.less; lessc css.less > css.css; done;
Total votes 1: ↑1 and ↓0+1
Что если хранить в начале less файла строку хеша от файла (всех остальных строк), и если файл изменился, то только тогда заново генерировать?
This comment wasn’t rated yet0
Зачем? Изменение даты последнего имезенения файла в большинстве случаев должно хватать.
This comment wasn’t rated yet0
Недавно на хабре были статьи про Less, приводилась прога SimpLESS.
Бесплатна, работает на всех платформах, на лету отслеживает изменения и компилит их в css причем еще и минимизирует его.
Сейчас использую данную прогу на нескольких проектах, очень удобно, а на продакшн выкладываю чистый css
Total votes 1: ↑1 and ↓0+1
>Бесплатна, работает на всех платформах, на лету отслеживает изменения и компилит их в css причем еще и минимизирует его.

На счет минимизации — так это LESS штатно умеет, и мой сервер тоже. Но с моим подходом вообще не надо задумываться на чем пишешь — на less или css.
Total votes 1: ↑0 and ↓1-1
incron + препроцессор less, и не придётся «запускать ручками» :) много проще чем сервер + прокси
This comment wasn’t rated yet0
>сервер + прокси

Так nginx я в любом случаи использую (и многие используют). Добавить пару строчек в нгинкс и запстуить одной командой сервер не сложнее чем добавить задачу в крон, а крон выполять надо будет очень часто — я быстро правлю+ переключась в браузер :)
This comment wasn’t rated yet0
incron — это cron который срабатывает не по времени, а по событию, например, после модификации файла :)
This comment wasn’t rated yet0
Спасибо, не знал про его существование.
This comment wasn’t rated yet0
я сделал (не)множко по-другому:

etc/nginx/nginx.conf
perl_modules etc/nginx/perl;
perl_require lesscss.pm;


etc/nginx/perl/lesscss.pm
package lesscss;
use File::stat;
use nginx;

sub handler
{
	my $r = shift;
	
	$r->send_http_header("text/css");
	return OK if $r->header_only;
	
	if(-f $r->filename)
	{
		$less = $r->filename;
		$less =~ s/\"//g;
		$css = $less;
		$css =~ s/\.less$/.css/gi;
		
		if(!stat($css) || stat($less)->mtime > stat($css)->mtime)
		{
			system("PATH=/opt/local/bin lessc \"".$r->filename."\" > \"".$css."\"");
		}
		if(-e $css)
		{
			$r->sendfile($css);
			$r->rflush;
		}
	}
	
	return OK;
}

1;
__END__


etc/nginx/vhost/???
location ~* ^.+\.less$ { perl lesscss::handler; }


в итоге nginx сам смотрит за изменениями в .less-файле, и незаметно обновляет .css, лежащий тут же рядом.
решение не идеально, но для домашнего сервера пойдёт.
Total votes 4: ↑3 and ↓1+2
Спасибо. Ваше решение самое то!
Total votes 1: ↑0 and ↓1-1
Не делайте так. В nginx Perl не для этого. На тестовом сервере, куда никто кроме Вас не ходит, еще покатит. Но очумелые ручки же это «самое то» решение непременно на боевой выкатят.
Total votes 4: ↑4 and ↓0+4
Расскажите, в чём подвох с Перлом?
This comment wasn’t rated yet0
Во время выполнения perl внутри nginx, скриптом напрочь блокируется весь worker. Perl, встроенный в nginx — это совсем не то же самое, что mod_perl в Apache. Он не предназначен для генерации страниц, лазания в SQL, форкания процессов (как в вышеприведенном примере с вызовом system() и less) и т.п.

Встроен для удобства написания сложной логики обработки location или написания хитровывернутых rewrite теми, кому это действительно нужно. Чтобы не сковывать их ограничениями синтаксиса nginx.conf.

Ну максимум — что-то собрать из SSI.
This comment wasn’t rated yet0
Спасибо :)

P.S. Хотя мне недавно попадалась статья на тему прикручивания libdrizzle к Nginx.
This comment wasn’t rated yet0
Олег в рассылке (и, кстати, документации тоже) явным образом и черным по белому НЕ рекомендует сетевые обращения из встроенного Perl. Настойчиво предлагается «ограничиться операциями, время исполнения которых короткое и предсказуемое, например, обращение к локальной файловой системе».
This comment wasn’t rated yet0
У нас ограничивается обращением по сокету к локальному MySQL с таблицей в памяти. Но думаю над тем, когда же это станет узким местом.
This comment wasn’t rated yet0
Если человек знает, что делает и понимает, чем это грозит, то ничего страшного.
Total votes 1: ↑1 and ↓0+1
Тьфу, блин. Игорь, конечно. Вредно в два окна сразу писать.
This comment wasn’t rated yet0
Я себе hook сделал в Mercurial, и ничего лишнего)
Total votes 3: ↑3 and ↓0+3
Эээ. Это немного другое — не будете же во время разработки при изменении свойства «напосмотреть» коммититься.
Total votes 1: ↑0 and ↓1-1
На посмотреть и js скрипт сойдет
Total votes 1: ↑1 and ↓0+1
я в php проектах использую leafo.net/lessphp/
rewrite правила к css проверяют, есть ли less файл с аналогичным именем и если есть и дата модификации его позже, чем у css, то компилирую less в css
дальше вне зависимости от первого условия отдается содержимое css или ошибка 404, если его нету.

для низко нагруженных проектов более, чем достаточно и довольно быстро.
This comment wasn’t rated yet0
Как мне кажется, гораздо разумней использовать для данных целей assetic – он позволяет налету компилировать LESS, SASS, Compas, сжимать css, javascript и многое другое.
Позволяет генерировать скрипты, как на лету, так и делать дамп на диск.

github.com/kriswallsmith/assetic
This comment wasn’t rated yet0
Поскольку результаты кешируються то можно было бы просто в кроне запускать компилятор less, а на сайте уже дергать нагенеренный CSS.
This comment wasn’t rated yet0
Такое решение из серии вредных советов. На боевом сервере нужно собирать css в момент деплоя. Деплой же всё равно должен быть автоматизирован так или иначе, какая разница что будет на одну операцию дольше.
А для отладки, локально, используйте все что угодно.
Total votes 1: ↑1 and ↓0+1
>Такое решение из серии вредных советов. На боевом сервере нужно собирать css в момент деплоя.

Так вы напишите, чем плохо то. Зачем вообще собирать, а не на лету обрабатывать, с учтом того что кеширование все равно решает проблему производительности? Тот же python/php за то и любят, что его файлы собирать не надо. Nginx gzip-ает тоже налету. Почему же именно в этом случае должна быть сборка?
This comment wasn’t rated yet0
«Nginx gzip-ает тоже налету»
Расходуя процессорные ресурсы на каждый запрос, увеличивая latency. Кстати, nginx.org собирается make-файлом, генерация и сжатие всех страниц выполняется на этапе сборки.

Зачем расходовать ресурсы впустую?

«Тот же python/php за то и любят, что его файлы собирать не надо»
Не за это python любят. В сущности это, как раз, пустяк.
This comment wasn’t rated yet0
Вообще для боевого деплоя есть make, а для тестового сервера — можно делать как угодно, да. Но тогда и less на клиенте не должен раздражать, он даже удобнее.
Total votes 1: ↑1 and ↓0+1
Действительно, не проще будет написать Makefile, который будет делать все сам?
Я не только про конвертацию less в css, можете туда еще например проверку на ошибки в языке (для перла я юзаю Perl::Critic например, для ноды jslint), тесты в конце концов прикрутить.
Подготовку минифицированных js, гзип, объединение чего надо в 1 файл и так далее.

Например потом можно в .deb все упаковать и положить в репозиторий.
В бою-же просто apt-get update && apt-get install package.
This comment wasn’t rated yet0
Sign up to leave a comment.

Articles

Show the best of all time

Your account

Sections

Information

Services

Support
© 2006–2024, Habr