MiksIr

А css - это не элемент интерфейса? Дизайн - это дизайн. А разработка - это разработка. Все, что превращает дизайн в конечный интерфейс - это разработка. Каша у вас. "Фронт-енд", "Фронт-енд разработчик", "Фронт-енд архитектор" - все в одну кучу? Совершенно разные понятия. Просто фронт-енд - это набор сущностей, когда говорим о разработчике - говорим о том, что он делает и что должен знать. А архитектор решает как именно делать то или иное.. и дает указания разработчику =)

А для меня вот фронт-енд - это сервера принимающие соединения, занимающиеся кешом и статикой, а бек-енд - это пул серверов, занимающийся выполнением ПО =)) У нас есть HTTP. Вот все, что со стороны клиента - это фронт-енд разработка, что со стороны сервера - это бек-енд. Фронт-енд разработка - это все, что потом анализируется, парсится и исполняется клиентским софтом. Например, HTML/CSS - это все же программа, указывающая браузеру что делать. Так что всегда считал это разработкой. Хотя, другое мнение тоже понимаю. Скорее всего оно идет от сильных JS разаботчиков - называя себя фронт-енд разработчиками им, полагаю, не очень приятно, что их занятие смешивают с версткой. > а ничего, что нынче уже на каждом втором проекте предусматривается бэкэнд на фронтэнде? C бек-офисом не перепутали? =)

Для меня основная проблема Битрикса, которая мешает воспринимать его на серьезные проекты - это архитектура ключевого модуля инфоблоков, которая провоцирует огромные джойны, а некоторые типы полей вообще неудобны в использовании. Я очень и очень сомневаюсь, что вы сможете поменять архитектуру не трогая API. Не получится. А админку раскрасить - так это сколько угодно. Да, и кстати, обратная совместимость никогда не бывает обязательным требованием сама по себе. Если ведется разработка рющечек, то да - важна, если, фактически, рождается новый продукт, то поддержка обратной совместимости (особо учитывая кривость предыдущей архитектуры) в 99.9999999% случаев оказывается значительно дороже, чем одновременная поддержка двух проектов - нового и старого.

Новый битрикс со старым API? Поржал =)

Нет, значительно проще. Битрикс — чуть ли не единственная документированная CMS. api позволяет решать любую задачу, не затрагивая код ядра. Красивая стройная архитектура. Логика от представления чётко отделена. Можно масштабировать, комбинировать и вообще творить что угодно, почти полная свобода действий. Есть возможность управление любым нестандартным функционалом вынести в админку, создавать элементы управления в публичной части и т.п. Всё это требует всего лишь чтения документации, но никак не перелопачивания тонн быдлокода и ломания мозгов, как в джумле. Но если чукча не читатель, а писатель, то лучше даже не смотреть в сторону битрикса. Сложно будет. А тому, кому результат работы чукчи-не-читателя-а-писателя достанется на поддержку, будет ещё сложнее. К сожалению, быдлокодить битрикс позволяет безгранично, никак этому не препятствует. Отвратительная архитектура. Во всем. Часто настолько запутанная, что непонятно - специально путали что ли. Возьмите любой приличный фреймворк и вы поймете что такое "красивая стройная архитектура" и отделение логики. Причем, качество кода очень разное - где-то более-менее, где-то, особо в компонентах, такой говнокод... А уж про количество файлов - это да... очень приятные ощущения для работы с любыми IDE и VCS. Документация хороша для стандартного набора действий, типа дергания api инфоблоков. Что-то выходящее за рамки этого натыкается на черную дыру. Ну и сам api как правило убог и нелогичен. Самое главное - отсутствие стиля и рекомендаций по разработке приводит порой к таким жутким решениям, что поддержка написанного кем-то еще превращается в большую головную боль. Т.е. присвоить Бириксу гордое CMF не могу тоже, все же хороший фреймворк ведет программиста за ручку в какой-то мере, помогая писать легко поддерживаемый код. Во многом в говнокоде виновата и квалификация программистов, тут все очевидно - хороший программист не пойдет писать решения на битриксе - его и так неплохо кормят. Так что хороший программист на битриксе - это редкость. Например, у меня стойкая уверенность, что 95% битрикс-разработчиков, которые лезут ловить всякие события и тому подобное, не знают, что такое autoload. Да, Битрикс позволяет быстро создать простой сайт. Простой - это с функционалом готовых компонент, причем как в ядре, так и в выводе. Стоит захотеть даже не сложный функционал, а просто серьезно изменить вывод начинается куча подпорок, часть из которых битрикс уже гордо ввел в понятие "функционал". Хотя понять это, опять же, можно лишь поработав с хорошими ООП фреймворками. В общем много можно говорить, но лучше от этого не станет. Приходится разрабатывать на битриксе и самому и своим программистам... воспринимаем это как некую кару, испытание которое нужно преодолеть, что бы достичь просветления и заняться вещами действительно приятными для разработки. Не спорю, для кого-то и Битрикс - верх совершенства.

Я не вижу на рынке ни одной качественной CMS =( Понимаете, суть в том, что качественные студии не будут работать и с вашим продуктом. И "бесплатность" тут мало роли играет. Хотя первый шаг вы правильно сделали. Качественные студии никогда не будут уговаривать клиента делать что-то на не TOP-овой CMS (а по факту битрикс и остается), и уж тем более - на своей собственной CMS написанной с нуля. Хотя если вы раскрутите свою CMS хотя бы в десятку - что-то может сдвинуться, но усилий нужно много, т.е. просто выложить "протестировать" недостаточно - нужно вкладывать серьезные деньги в продвижение.

EMS SQL Manager попробуйте.

Ну форк всегда была дорогой операцией не смотря на все copy-on-write. А какое отношение времени скрипт/jpegtran? Если больше всего jpegtran занимает, то нужна немного другая архитектура и параллелизм.

> почему такое использование sprintf влияет на производительность Дело не в производительности. Подстановка переменных в шаблон printf плохо, ибо если внутри переменной будет % символ - будет ошибка. Раз уж printf дает возможность подставлять переменные через плейсхолдеры, так и нада. >зачем в данном случае unset Привычка когда цикл с передачей по ссылке foreach($arr as $key=>&$val) ....; .... $val = 100500; И внезапно наш $arr испорчен ибо $val после цикла все еще ссылка на элемент массива. Очень распространенная ошибка. >и в функцию triesn идет лишь 2 параметра - (int)limit и (array)modes Ах, да. Ну так тоже намана, даже правильно. Другое решение - можно внутри функции с func_get_args() поиграться. Но в общем, наверно, не нужно. >./jpegtran" - программа, а остальные аргументы - аргументы идущие в программу, но почему написаны таким образом? -| это в PHP вроде как аналог popen А про аргументы... вроде так $var = "some argument"; - с пробелом тут open("-|./program $var"); - будет передано шелу на выполнение, у него пробел - разделитель аргументов, т.е. program получит 2(!) аргумента - some и второй - argument. Если пишем open("-|","./program", $var) - это передает в program один аргумент как строку с пробелом. Аналог этого - open("-|./program '$var'");

Могу сказать, что перловый скрипт тоже написан криво. Хотя бы по тому, как человек юзает sprintf function try_splits($str, $c) { $arr = array_flip(array( 2,5,8,12,18 )); foreach ($arr as $key=>&$value) { $value = sprintf('%d: 1 %d %s; %d: %d 63 %s;', $c, $key, $str, $c, $key+1, $str); } unset($value); $mode = triesn(2, "$c: 1 63 $str;", array_intersect_key($arr, array_flip(array(2,8,5)))); if ($mode != $arr[8]) return $mode; return triesn(1, $mode, array_intersect_key($arr, array_flip(array(12, 18)))); } Порядок ключей в массиве вроде как совершенно не нужен - он используется только по прямому индексу

А имеет значение порядок? Лучше вообще не думать о порядке ключей, или их задавать самому. Ориентироваться на дефолтный порядок может быть проблемой http://search.cpan.org/~jhi/perl-5.8.1/pod/perldelta.pod#Hash_Randomisation

Это особенность хеша. В общем именно по-этому это называется хешом, а не массивом. Способ хранения хеша не сохраняет порядок ключей при переборе.

> непонимание начинается со второй строки Да ладно? Это простые тенарные операторы $var = $a ? $b : c, просто вложенные друг в друга. А если ты про $ret - то мы туда присваиваем вызов функции, и если он true - это значение и возвращаем. Можно записать так if ($ret = self::cmp(!$matches[3], !$matches[1])) { return $ret; } else { if ($ret = self::cmp($matches[4], $matches[2])) { return $ret; } else { return strcmp($b, $a); } } > здесь выполняется preg_match (судя по обращению к найденному в следующей строчке) и preg_replace одновременно Да, в perl-е при replace операции скобки все-равно попадают в $1 ... В PHP видимо это нужно в 2 операции делать, сначала preg_match, что бы получить $matches, а потом preg_replace > и вообще, как определить, что =~ выполняет? Так я это писал в первом сообщении. Буква перед патерном. s - замена, m или пусто - поиск s/// - замена, m// или просто // - поиск. Разделителями, как и в пхп, может быть что угодно, т.е. s### и m## тоже работает (но m тут уже обязательно)

Дело не в том, что булево нужно конвертнуть в int. В каждой итерации сорта должно быть 1 или 0 или -1. return -1 || 0 || 0 даст в перле -1, а в php - true или (int)true = 1 Нужно переписывать как-то так: return ($ret = self::cmp(!$matches[3], !$matches[1])) ? $ret : ( ($ret = self::cmp($matches[4], $matches[2])) ? $ret : strcmp($b, $a) );

Щас убегаю, проверять некогда, но мне кажется, проблема в логических операциях. В перле они возвращают значение, а PHP - булевое. Т.е. в перле -1 || 1 вернет -1 (первый операнд - правда, его и возвращаем, второй вообще не трогаем), 0 || -1 вернет -1 (первый - false, возвращаем второй). На этом, кстати, там очень удобные назначения дефолтных значений основаны, типа $var = $var || 'default var'; В PHP же это дает булевы true (т.е. 1). Из-за этого сортировка путается.

usort($txt, function($a, $ { - вот здесь заглавная почему? В PHP используются те две переменные, которые как параметры функции указаны. Т.е. $a и $B. А дальше при сравнении используется $b маленькая "$a\n$b"

Скажи, а ты там не напутал с регистром $b переменной? В PHP переменные регистрозависимые и $B и $b - разные переменные.

В перле for и foreach синонимы и работают в зависимости от параметров. В данном случае аналог PHP-ного foreach. Перл "выдумывает" только $_ (ну и @_), больше переменных никаких он не выдумывает (т.е. $i неоткуда взяться).

Да вроде верно. В PHP http://en.wikipedia.org/wiki/Quicksort (по данным www.php.net/sort) В Perl

shift возвращает первый элемент массива и удаляет его (сдвигает массив). Так как параметр не указан, массив берется @_, т.е. параметры функции (той функции, внутри которой был вызов) sub test2 { my $second_param_of_test_function = shift; } sub test { my $first_param = shift; test2(shift); # равно my $second_param = shift; test2($second_param); } test($first, $second);

sprintf должен быть такой же, у них корни одни - из Сишного sprintf $| = 1 - это отключение буферизации вывода, насколько я помню

Регулярки фактически должны 1 в 1 работать в preg_match/preg_replace // или m// - это match, возвращает в скалярном контексте число совпадений s/a/b/ - это preg_replace('/a/', 'b') результат не возвращает, а меняет переменную, Модификатор g - это "заменять все" т.е. нативное поведеление preg_replace т.е. $txt =~ s/a/b/g; - это $txt = preg_replace('/a/', 'b', $txt); К переменным регулярки применяется через =~ Т.е. $txt =~ /\s/ - ищет регулярку по $txt, а вот $txt = /\s/ - ищет регулярку по дефолтной переменной и возвращает результат в $txt - можно записать иначе как $txt = ($_ =~ /\s/); Ну и $1 $2 $3 и т.д. - это скобочки в последней выполненной регулярке, т.е. аналог параметра $matches sort работает аналогично php sort - внутри {} callback функция где $a и $b - пара В перле есть такая штука - дефолтная переменная $_ (и дефолтный массив @_), если что-то типа цикла по массиву не указывает куда класть каждый элемент - кладем в $_ т.е. for(@modes) проходит по элементам массива и каждый из них в $_ Внутри функции @_ - это массив параметров Например, my ($limit, @modes) = @_; - в $limit первый параметр, в @modes - все остальное, ибо массив Ну соответственно sub tries { triesn(99, @_); } - это вывзов triesn куда передаются параметры вызова tries Например, $var = shift; - shift это аналог array_shift, но так как параметра нет - используем дефольный @_, а так как мы внутри функции - это параметры функции, т.е. в $var - первый параметр функции Про эту строчку my %n = map {$_ => sprintf "$c: 1 %d $str; $c: %d 63 $str;", $_, $_+1} 2,5,8,12,18; map - это аналог array_map, возвращает новый массив в данном случае делает это в виде ассоциативного массива (в перле называется "хеш"), о чем так же говорит %n Т.е. в %n будет хеш вида 2 => строка 5 => строка и т.д. Да, в перле, в отличии от пхп, все переменные глобальные если не сказано, что они локальные (my). Т.е. там ниже есть цикл с определениием $c и вызовом функции, где это $c используется напрямую. К слову, локальность переменных можно определять не только внутри функции, но внутри любого блока (циклы, например) Вроде все... будут вопросы - спрашивай =)

Какой скучный тролль

Сейчас держу такое устройство - Huawei Mediapad. Куплен ибо лучше по характеристикам чем все остальное и при этом на 20-30% дешевле чем худший по параметрам самсунг. Вполне добротный дизайн, который сложно назвать "ворованным".

Это все тяжелое наследие PHP, забейте. Писать нужно явно public, abstract и т.д. только если вы вдруг не решили поддерживать PHP4. Приватный конструктор нужен для паттерна Синглтон. > когда метод объявлен без префикса это тоже самое, что и public или есть какие-то различия? Нет различий. Сначало был PHP4 и не было никаких public/protected и т.д. - все методы были публичные. Написание без указания доступа оставлено для совместимости.