Ну тут то хоть какая то бумага была от гос. органов… Выбешивает поведение западных контор при абузах от спамхауса. Там вообще, домен паркуют при жалобе от спамхауса без раздумья и писка, хотя эта компания к исполнительной власти вообще никакого отношения не имеющая и зарегистрирована вообще непонятно где. Сам сталкивался со случаем, когда при одной абузе на фарму был мало того что закрыт домен, на который была жалоба (хотя фармы там не было никогда) так и еще припарковали ВСЕ домены, которые были зарегистрированы на те же NS сервера, что и домен в абузе. Было очень весело, когда отвалилось более 100 доменов и даже непонятно кому жаловаться. Регистратор кивает на спамхаус а те просто не отвечают. И это цивилизованный запад!
Спонсор переписи — Налоговая служба России :)
Из всех фрилансеров зарегистрированы как предприниматели всего 9%, то есть все остальных можно брать за уклонение от налогов и незаконную предпринимательскую деятельность? Или 9% — это что то другое?
А кто сказал о всем тексте? Цитат тоже беспредельно вставлять нельзя, есть порог, после которого чрезмерное цитирование законодательно признается плагиатом. Но что очень много сайтов содержит полные версии или куски статей и книг — это даже сомнению не подлежит. Зайдите в форум на searchengines.ru, там для сканерщиков целые топики есть. И рерайтеры там тусят по полной. И сто пудов — на Западе уже давно и биржи и вообще, как направление бизнеса, это существует. Если учесть тот факт, что Гугл во всех странах кроме России и Китая — самая популярная поисковая система — линкоторговцы под нее явно не бедствуют и спрос рождает весьма неплохое предложение. Так что помощь в сохранении шедевров книгопечатания, помогающая убить кучу линкоферм, основанных на ворованном контенте — это весьма и весьма успешный выстрел по двум зайцам. А «депломы» — да, надо писать самому. 5% цитирования — это на самом деле очень даже немало… И если товарищ студент соизволит прочитать 10-20 книг по теме — думаю гугл будет не против.
Как вариант, для определения уникальности текстов на сайтах. Все сателлиты и говносайты, основанные на отсканированном варианте они смогут отбросить в один момент. Апдейт — 90% сателлитов в бане :)
Про пример понятно, это была шутка. Просто речь шла об очевидности. То что вы написали — да, вполне очевидно. Но как вы сами указали — на Хаскель (не знаю этого языка, хотя написанная вами конструкция вполне понятна, что и вызвало у меня аллюзию на псевдокод, сорри если оскорбил хаскелистов :) ). Мой спич был несколько о другом: обсуждается PHP и не факт, что рекурсия написанная на нем будет очевидней аналогичного кода на циклах. В случае рекурсии:
function fact($n)
{
return ($n==0)? 1: $n*fact($n-1);
}
и цикла
function fact($n)
{
for ($i=2,$fact=1;$i<=$n;$i++) $fact*=$i;
return $fact;
}
да, первый вариант может и очевидней. Но это в случае расчета факториала. Но в вебе то факториалы ни к чему. Если взять что то более сложное с несколькими условиями выхода — можно получить куда более нечитаемый и сложный для поддержки вариант. И именно поэтому я поднял вопрос про реализацию… Может хаскель вообще заточен исключительно под рекурсии, что они на нем так красиво и просто смотрятся :)
хм… у вас в примере псевдокод. Если уж сравнивать решения — то уж и пишите тогда честно — на PHP (вроде о нем же речь). И тогда когда получите ответный код на том же PHP без рекурсии — будем смотреть, что проще :)
> Умные люди не пишут кластеры на Visual Basic'e, GUI-приложения на Фортране, а сложные веб-приложения на PHP
Это вы зря… Когда дело доходит до бизнеса, а в 99.9% всех случаев когда что то программируется — это — бизнес, бизнесмен решает — на что вложить деньги. И выбирает не то, что мегаправильно и красиво, а то, что позволит получить продукт быстро. Куча стартапов пишется на чем? На PHP! Потому что стоимость разработки — маленькая по сравнению с теми же Java или C#, Ruby и т.д, и есть масса специалистов, наработаны решения по устранению узких мест в виде кеширования и кластеризации. И все это почти даром. Да, когда идет речь о программировании Just for Fun — то да, там народ все делает от души и красиво. И не на PHP. Но рассматривать язык только как дизайн — это подход разработчика, но не бизнесмена.
Электромотор то явно не деревянный, значит искажения в ходе времени будут только в искривлении стрелок + люфт шестеренок, то есть общее направление стрелки будет всегда правильным, отставания на 5-10 минут не может быть в принципе.
На каком основании вы делаете вывод о "что порог вхождения не сильно отличается от смарти" ? Если провести опрос на хабре - как вы думаете какое будет соотношение людей, которые знают Смарти, но не знают XSLT, знают только XSLT, и знают и то и другое ? Вот когда первых и вторых примерно будет одинаковое количество - тогда можно будет говорить, о том, что уровень входа - одинаковый, потому как люди изначально не парились что изучать и изучить XSLT для них было ничуть не сложнее чем Smarty. С другой стороны, наличие форумов, наподобие вот этого: http://xpoint.ru/forums/internet/XML/for… показывает, что XSLT - это не семечки, и если все что вы в нем используете - это foreach с if и var и имеет аналогичные вещи в Smarty - то это не факт, что все остальное в нем так же тривиально.
Я не понял, вы свой пример чему противопоставляете ? Надо понимать, что вы разгильдяй без гибкости ума, который за 4 часа прочитал книжку по XSLT и все освоил ? Или тогда о чем этот спич ? То что неглупые люди занимаются написанием сайтов - это факт. Но из него абсолютно не следует факт, что этим не могут заниматься не столь же одаренные личности. Что касается порога вхождения - он есть. И само количество программистов на PHP - тому свидетельство. Что то я не видел на форумах по Pyton, Ruby и Java тупейших по форме и по содержанию вопросов, которыми почему то изобилуют форумы на PHP. Народ начинает с попсы. Она может плохой или хорошей, но это не суть. А суть в том, что многие сделав старт, считают что они Lead Developer-ы, и задрав нос, кладут на все остальное, останавливаясь в развитии. Поэтому ваш личный пример - не доказывает ничего. В попсе могут тоже быть таланты, ибо не человек для инструмента, а инструмент для человека. Многие этого не понимают, и именно это приводит к холиварам.
Чую мысль не закончена, но это уже настолько напоминает борьбу с ветряными мельницами, что продолжать уже не хочется.
>то что он сделает на xslt даже страшно подумать
зря :) если такой "разработчик" смог осилить Смарти только на уровне {php}, то в XSLT он погрязнет на первом же . Уровень вхождения в Смарти и в XSLT все таки разный и разгильдяям второй просто не осилить. Все таки чтобы с процедурного языка перейти на декларативный - нужна некая гибкость ума, а некоторые "девелоперы", ей не обладают. А вообще, если речь ведем о очень крупном проекте (в моей классификации его нет) - то там вообще все заморочено и подходить к ним с обычными мерками на уровне выбора шаблонизатора вообще смысла нет... Если нагрузки планируются такие, что время компиляции шаблона играет роль - то Apache Benchmark вам в зубы и в перед, к тестированию и экспериментам :)
{xslt xml=$xml xsl=$xsl}
есть у меня проект, построенный на подобной технологии... :) Хотя если честно, кеширование Smarty - меня разочаровало. Если реализовывать схему с ведомым контроллером, подход, предложенный разработчиками Smarty идет лесом, он просто не работает.
Вопрос даже не совсем в производительности... Хотя нормальные БД умеют результаты выборки выдавать в XML, что позволяет обойтись без прокладок, да и если расчитывается сильнонагруженный сервис - то там кеширование результатов (причем на нескольких уровнях) предусматривается изначально, и расчитывать, что "мы возьмем этот шаблонизатор, и все станет шоколадно" - наивно, и никто этим заниматься не будет. А вот то, что серьезный развивающийся проект надо делать максимально удобным для работы с ним команды разработчиков, чтобы потом не приходилось разгребать говнокод - это необходимо. Понятно, что наплодить нечитабельных перлов можно везде, но XSLT на мой взгляд более дуракоустойчивей. По крайней мере, в шаблоне XSLT шансы встретить {php}нереальный гвонокод на PHP{/php} равны нулю :) С другой стороны, один из плюсов XSLT - это кроссплатформенность. Если мне в какой то период времени придется перенести проект или его часть с PHP на JAVA(Pyton, С#,Си и т.д.), то можно быть уверенным, что хотя бы шаблоны переделывать не придется.
Эм... вы хотите сказать, что модуль, написанный на Си, отконвертит кусок XML-я в HTML медленнее чем интрепретируемый PHP произведет необходимое количество конкантенаций строк ? Сомневаюсь. Если, конечно, для вывода одной страницы с 50-тью комментариями выдавать XML в полмегабайта - то да, он захлебнется. Но во всех других случаях - он уж явно не медленнее любой другой шаблонизатор. А если вы планируете пихать в XSLT логику - то это уже мы не о MVC говорим. Тем более если проблемы производительности возникают из-за шаблонизатора - то значит вы что то не то кешируете :)
А какой процент из времени генерации содержимого страницы (выборки из БД, обработка данных PHP и т.д.) занимает именно работа шаблонизатора ? На моих проектах 90% всего времени - это выборки из БД. И оптимизация БД или включение кеширования дает гораздо больший прирост производительности, чем 7%, которые я выйграю начав использовать нативный PHP.
Из всех фрилансеров зарегистрированы как предприниматели всего 9%, то есть все остальных можно брать за уклонение от налогов и незаконную предпринимательскую деятельность? Или 9% — это что то другое?
function fact($n)
{
return ($n==0)? 1: $n*fact($n-1);
}
и цикла
function fact($n)
{
for ($i=2,$fact=1;$i<=$n;$i++) $fact*=$i;
return $fact;
}
да, первый вариант может и очевидней. Но это в случае расчета факториала. Но в вебе то факториалы ни к чему. Если взять что то более сложное с несколькими условиями выхода — можно получить куда более нечитаемый и сложный для поддержки вариант. И именно поэтому я поднял вопрос про реализацию… Может хаскель вообще заточен исключительно под рекурсии, что они на нем так красиво и просто смотрятся :)
Это вы зря… Когда дело доходит до бизнеса, а в 99.9% всех случаев когда что то программируется — это — бизнес, бизнесмен решает — на что вложить деньги. И выбирает не то, что мегаправильно и красиво, а то, что позволит получить продукт быстро. Куча стартапов пишется на чем? На PHP! Потому что стоимость разработки — маленькая по сравнению с теми же Java или C#, Ruby и т.д, и есть масса специалистов, наработаны решения по устранению узких мест в виде кеширования и кластеризации. И все это почти даром. Да, когда идет речь о программировании Just for Fun — то да, там народ все делает от души и красиво. И не на PHP. Но рассматривать язык только как дизайн — это подход разработчика, но не бизнесмена.
Чую мысль не закончена, но это уже настолько напоминает борьбу с ветряными мельницами, что продолжать уже не хочется.
>м же .
м же <xls:template ...>.
зря :) если такой "разработчик" смог осилить Смарти только на уровне {php}, то в XSLT он погрязнет на первом же . Уровень вхождения в Смарти и в XSLT все таки разный и разгильдяям второй просто не осилить. Все таки чтобы с процедурного языка перейти на декларативный - нужна некая гибкость ума, а некоторые "девелоперы", ей не обладают. А вообще, если речь ведем о очень крупном проекте (в моей классификации его нет) - то там вообще все заморочено и подходить к ним с обычными мерками на уровне выбора шаблонизатора вообще смысла нет... Если нагрузки планируются такие, что время компиляции шаблона играет роль - то Apache Benchmark вам в зубы и в перед, к тестированию и экспериментам :)
есть у меня проект, построенный на подобной технологии... :) Хотя если честно, кеширование Smarty - меня разочаровало. Если реализовывать схему с ведомым контроллером, подход, предложенный разработчиками Smarty идет лесом, он просто не работает.