Слегка оживлю тему... в прищепке пример оптимизации небольшой функции класса "по Касьянову". Примерно также изменяется и весь остальной код портала... кодировка utf-8, может кому и сгодится в порядке обучения...

Почему так? Да как раз потому что код большой и даже очень большой и уследить за всем и вся - нереально. Поэтому, маленький секретик, как вывод из старого, доброго Дейкстры "стурктурное программирование" (или как оно там называлось) - когда пишется конструкция языка, типа if then elsif else, или switch/case, она СРАЗУ(!) пишется целиком, даже если мне надо только then. И если нечего написать в else или switch default, то вот такие тексты туда и втыкаются... "на будущее". При первом же прогоне на тестировании, большинство таких текстов заменяется "правильным" кодом реакции на ошибку в данных... это так, упрощенно и в порядке ликбеза читающим... тут, конечно не мешает правильное понимание чего и когда надо проверять... но это уже из другой оперы...

Дейкстра крут, да.
У этого метода есть развитие, описанное в книге Бейбера "Программное обеспечение без ошибок".
Сейчас трудно внедрять этот метод на производстве, т.к. не всем объяснишь, скажем, как инвариант цикла находится, но Вам, думаю, может пригодиться.

Подскажи тру прогеры. Сегодня наткнулся на вакансию от нгс - требуется php junior прогер(кроме знаний англ. более ничего не описано, мол научитесь в ходе работы), хотелось бы узнать, что подразумевается под junior (необязательно эта вакансию, сейчас очень часто встречаю такое слово), с какими мин. знаниями стоит пробоваться на эту вакансию и чего ожидать после трудоустройства, в плане работы?

Дык! И я про то же пытаюсь донести. Можно и нужно писать СРАЗУ без ошибок. Тогда "сопровождать" не придется (в современном понимании этого термина)..., впрочем и "скромничать" тоже не придется...

... а ещё можно и нужно сразу писать модульно и с логичным делением на классы и методы... но это ещё сложнее объяснить, чем выделение инвариантов.

P.S. Кстати, книжка действительно хорошая, тоже подпишусь к рекомендации.

/ **

* Fanya mahesabu ya upeo iwezekanavyo ukubwa wa sura mpya katika saizi:

*

* @ Return Zend_Exception | array ('0 '=> (int) upana, '1' => (int) urefu)

* /

Вы правда любите такие комментарии?

УПД: мда... НГС не допускает старнных языков в лоно контента... пришлось таки поменять Хинди на Суахили

УПД: мда... НГС не допускает старнных языков в лоно контента... пришлось таки поменять Хинди на Суахили

Ну комментарии еще ладно, но эзепшен тоже на русском вылетает.

Это всё? А по делу сказать нечего, верно?

Для тех "кто в таньке": недалеко здесь (ранее) есть чего и для кого пишется... можно перечитать.

А ежели без стеба, то всё хорошо в меру. В том числе и идолопоклонство перед иноязычными комментами... Потому как правильный (англоязычный) коммент - никак не улучшает содержание кода в части "так было".

Ну и ещё: коммент на русском, потому как здесь далеко не все читают по иноземному. Это раз. Эксепшн тоже на русском, потому как пользуются порталом - русские люди, а не иноземцы. Я не пишу сферического коня для попало кого... ежели вчё.

сгодится в порядке обучения...
Да упаси боже!

Замечания:
1. Описание не соответствует тому, что функция делает. Входные параметры вообще не описаны, да и имена какие-то странные: вместо по смыслу width, height - какие-то x, y.
2. size_normalize как-то не по-английски звучит.
3. Проверка входных параметров не структурирована и не отделена от бизнес-логики. Делать, например, надо как-то так.
4. Отрицательные значения размеров рисунка - все ок, едим так?
5. "Сжимать" умеем не больше чем в 1000 раз, а увеличивать до бесконечности? В чем смысл ограничения? Чтобы рисунок не сжался до 1x1 пикселя? Так может просто новые размеры проверить на разумность?
6. Почему-то MAX_RATIO (или MIN_RATIO, например) называется EQUAL_ZERO.
7. Если вылетел эксепшн, будем выяснять с помощью отладчика, какой параметр стал тому виной? По ссылке выше все примеры показывают как можно проверять параметры и не гадать, что именно случилось.
8. Возвращать массивы вместо структур (class Size { var $width, $height }) или просто output-параметров - это так счас модно?

В общем, код требует рефакторинга.

Ну давайте по делу, чо:

1) комментарий-описание функции в свободной форме, то есть про автогенерацию документации к модулям и классам можно забыть - зачем?
2) входные параметры не проверяются, причем вообще (уже написали, да)
3) жуткий стиль оформления Ричи субъективно как по мне неудобен - замучаешься искать открывающую блок скобку. Лучше использовать Алмена имхо
4) переносить условие в if - моветон, купите себе уже нормальный широкий монитор. ну либо как-то по другому запишите. И разрядите операции в условии пробелами - воднустрокунаписанноеусловие реально режет глаз.
5) в эксепшне отстуствует что-либо кроме невнятного сообщения на русском - как вызывали, откуда, что получилось (это уже сказали). Хотя может быть это делается "уровнем выше", логичней ошибки выполнения метода логгировать в самом методе, где есть и входные параметры, и рассчитанные, и стек вызова, и много всего остального, передавая наверх не локализованный эксепшн.
6) если вы пишите в своем коде что-то понятное не всем (а только русским людям, это же для русских пишется), вы видимо вполне не против встретить далее в вашем коде и логах каменты и эксепшны на суахили. Вообще за локализацию сообщения об ошибках на уровне логики нужно на кол сажать. Как и впринципе за какую-попало локализацию. Подсказываю - вариантов русского может быть несколько, потому что один умный придумал русскую кодировку а трое других идиотов koi8-r и cp1251/cp866. Вы удивитесь, читая ваши информативные логи, если вдруг ваш код начнет работать на системе, где понятной вам русской локали нет вообще и быть не может, соответственно сделать тот же grep логов будет извращенным сексом. Поэтому отмазки "я же пишу для русских" не катят, увы. Да, когда пишите логи/возвращаете эксепшн - пишите название модуля и название функции которая этот эксепшн вызвала + ключевое слово - чтобы вызывающая сторона могла обработать этот эксепшн правильно, поняв что случилось, где, и насколько это критично для продолжения своей работы.
7) если вы не запускаете тестов на вашем коде, это не значит что их не нужно писать хотя бы в комментариях к коду в качестве примера, так же как и пример вызова вашего метода - времени много не занимает, а вспомнить потом помогает

Тогда "сопровождать" не придется (в современном понимании этого термина)

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

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

Постепенно пришло понимание, что "программиста со стажем" я больше в соучастники проекта не возьму ни под каким соусом...

Почему?

1. Нормально соответствует. А Вы разобрались, с тем "что она делает"?
2. Как было названо так и оставлено...
3. Проверка ровно та, которая требуется... если бы разобрались, то стало бы понятно, что это внутренняя функция получения максимально возможных размеров картинки при заданном прямоугольнике с сохранением исходного соотношения сторон... она просто сильно внутренняя...
4. Я посмотрю как Вы отрицательные значения вытащите из Мускуля из поля типа "unsigned int", покажите?
5. А Вы пгобовали сжать нормальный сайтовый рисунок (ну типа даже 800х600) в тысячу раз? И как? Смысл ограничения, в том, что заданный прямогульник не должен оказаться нулевым... а вытащить пустой прямоугольник из БД - легко.
6. Поэтому это не MAX_RATIO, а то как оно названо... предел сравнения с нулем. Вот если бы смотрели чуть внимательнее - таких вопросов бы не возникло...
7. В Эксепшн попадаем, если не прошли проверку параметров. Их всего 4. Или нет размера картинки, или прямоугольник пуст. О чем и написано. Прога - корпоративная, и метод юзается для конкретных частей проги...
а, ну ещё: Вылетает Zend_Exception, ежели вчё... он умеет и стек показать и много чего другого сделать...
8. Чего возвращалось, то и возвращается...

P.S. "Смотрим в книгу - видим нечто"... написал же СПЕЦИАЛЬНО: применение оптимизационных методов... И ТОЛЬКО. То есть как из такого кода остается ровно то, что необходимо.

P.P.S. ... а вот то, что исходный вариант просто НЕВЕРЕН... так ни до кого и недоперло... это два. Вот так Вы все и пишете...

... и почему я ничего другого в комментах и не ожидал?!?

1) ?!? Чего Вам не хватило для "генерации"? Случаем не @param? Так они в реальном коде есть... этож таки "пример оптимизации", а не "оформления"...

2) Ну Вы даете! "Что курим/пьем"? Тожа хачу!

3) Да нет там НИКАКОГО стиля оформления! "так получилось" в процессе оптимизации и устранении копро-кода... впрочем его Вы тоже не заметили... или он оказался привычнее?!?

4) Это с непривычки... при постепенном нарабатывании опыта, как правило проходит.

5) Это действительно делается "уровнем выше"... ZF все-таки...

6) Если в нашей команде появятся толковые прогеры на Суахили, меня это устроит. Вообще, с локализацией всё нормально... если, слегка снизойдете до разбора того что было показано, Вам это станет понятно... потому как этот код "вдруг" не станет... а вот если Вам понадобится, то локализуете хоть под форточки, хоть под Спектрум... или чего у Вас там...

7) Примеры вызова ЭТОГО кода могут потребоваться разве что первокурснику...

P.S. Итого: За разбор изменений между "так було" и "так стало" я Вам выше кола не ставлю...

P.P.S. Допускаю, что ZF Вы не знаете. Он далеко не всем нужен. Но не разобравшись в сути вопроса, делать замечания - давно так не веселился. Отдельное спасибо!

Я поэтому и оттенил - " в современном...". Развитие - оно и есть развитие... это НЕ сопровождение. Это ДОБАВЛЕНИЕ нового - т.е. того, чего раньше не было. Совсем не было.

Да ЕСТЬ ТАМ ПРОВЕРКА!!! Ровно та, которая нужна!

Итого:

1. Метод получает 4 параметра: размеры исходной картинки и размер прямоугольника, куды её вписать надобно...

Самое первое - ПРОВЕРЯЕМ исходную ширину на еённое наличие (не нуль, не фальш и т.д.), потому как для получения коэффициента на неё банально делить надобно. Затем считаем этот самый аспект по стороне и ПРОВЕРЯЕМ его на близость к нулю. Когда одно число делится на другое в результате получается ВЕЩЕСТВЕННОЕ число, которое НЕЛЬЗЯ сравнивать с нулем... а можно только отследить его близость к последнему... чего и делается. Здесь же, далее АНАЛОГИЧНО проверяем второй исходный размер и ТОЧНО ТАКЖЕ считаем и ПРОВЕРЯЕМ второй коэффициент на близость к нулю.

Всё это делается в ОДНОМ предложении if(), точнее в его условной части... И если только ВСЕ ПРОВЕРКИ пройдены успешно ( и только в этом случае!) попадаем на единственный оператор (правда тернарный), который возвращает результат МЕНЬШЕГО коэффициента. ВСЁ.

Любая НЕВЫПОЛНЕННАЯ проверка - приведет к генерации исключения.
Это так стало. Итого имеем общее количество операций (причем как для разбора интерпретатору, так и при выполнении) - СТРОГО НЕОБХОДИМОЕ для решения задачи. Можете упростить?

А теперь "как было":

1. Получаем избыточный параметр, который выделяет первое действие... вот никто даже не заинтересовался - куды же оно делось? А как показал греп по вызовам - ОНО НЕ ИСПОЛЬЗУЕТСЯ НИГДЕ. Удалено как бесполезно выполняемый код.

2. Условия в части if и elseif взаимно дополняют друг друга, а стало быть исполняется либо одно либо другое - одна из проверок ГАРАНТИРОВАННО излишня - т.е. "копрокод" по определению...

3. результат функции округления "давится" на вывод ошибок... ну да, как же без этого, если на ноль делить это "наше всё"! Только при этом, чего-чего присваивается, ась?

4. При внимательном рассмотрении, находим, что результат выполнения блоков от первого условия практически НЕ ЗАВИСИТ... потому как , что "горизонтальная" картинка (высота больше ширины), что наиборот, НО делается внутренняя проверка, что ЕСЛИ НЕ ПОЛУЧИЛОСЬ, ТО ДЕЛАЕМ НАОБОРОТ. То есть, в худшем случае, СЧИТАЕМ ДВАЖДЫ КАЖДУЮ ВЕЛИЧИНУ... Ну просто песня а не код!!! Интересно, раз ни у кого вопросов НЕ ВОЗНИКЛО - Вы все так пишете???

5. Ну и как тут совершенно никто НЕ ЗАМЕТИЛ - нет ни одной проверки параметров... только вот ошибки давим, потому как явно в отладке они лезли...

Прочитайте три предыдущих поста вдумчиво.

Это и есть ответ на Ваше "почему": потому что незнание банальных и прописных истин, не компенсируется опытом "копрописания", хоть десятилетиями. И нет в показанном преобразовании никакого "таланту", ежели вчё. Банальное применение типовых методов поиска и замены инвариантов. Только так как "так стало" - надо писать СРАЗУ. И это нормальные технологии, а никакой не талант "семи пядей во лбу"... их просто надо знать.

Вы разобрались, с тем "что она делает"?
Странный вопрос для афтара кода. Вы не уверены, что ваш код понятен другим? Тогда он тем более требует рефакторинга.Но несмотря на то, как выглядит ваш код, тем не менее, я понял, что ваша функция вписывает рисунок в размеры $new_x * $new_y, сохраняя пропорции.

Как было названо так и оставлено...
А нафига тогда рефакторинг делается, если ГК остается ГК?

Нормально соответствует.
Cравните описание в коде:
Вычисляем максимально возможный размер новой картинки в пикселах:
и ваше же объяснение:
внутренняя функция получения максимально возможных размеров картинки при заданном прямоугольнике с сохранением исходного соотношения сторон
Ну ведь можете, когда захотите! Просто скопируйте объяснение в код, и все будет понятно из одного описания.

она просто сильно внутренняя...
Тем не менее, от деления на 0 вы страхуетесьИ из кода никак не видно, что функция внутренняя.

как Вы отрицательные значения вытащите из Мускуля из поля типа "unsigned int", покажите?
У вас могут быть рисунки со сторонами более 2M пикселей???

800х600) в тысячу раз?
800K * 600K - легко. А вы такие уже сжимать не умеете! Хотя заложились аж на UINT

Смысл ограничения, в том, что заданный прямогульник не должен оказаться нулевым...
Так и проверяйте, что новые (или итоговые) размеры не нулевые! И всем будет понятно сразу, что имеется в виду.

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

Их всего 4
Но вариантов их значений дофига и больше!

Вылетает Zend_Exception, ежели вчё... он умеет и стек показать и много чего другого
Но не указывает на причину. Ее придется искать в отладчике.

написал же СПЕЦИАЛЬНО: применение оптимизационных методов...
ГК трансформировался в ГК. Где здесь оптимизации? Тем более, что функционал метода сильно изменился.

исходный вариант просто НЕВЕРЕН... так ни до кого и недоперло...
На исходный вариант меня уже не хватило, так как слишком многа букаф, и оба кода даже на первый взгляд вызывают отторжение. Но я себя заставил прочитать хотя бы итоговый вариант!

Вот так Вы все и пишете...
Пока мы видим как пишите вы

отстутствие проверки входных параметров придирка, но при условии, что используется только внутри компании. Кто в здравом уме туда будет передавать мусор.
В здравом не будет. Но от случайных ошибок страховаться все равно надо. Assert'ы в том же C++ не просто так придуманы.

только кодестайл и не как не дело вкуса
Кодстайл - дело вкуса того, кто его определяет. Слава Богу, мне попадались только команды, придерживающиеся Олмана, с чем я внутренне абсолютно согласен.

так как "так стало" - надо писать СРАЗУ.
Так вообще никогда писать не надо.

Я поэтому и оттенил - " в современном...". Развитие - оно и есть развитие... это НЕ сопровождение. Это ДОБАВЛЕНИЕ нового - т.е. того, чего раньше не было. Совсем не было.
...

не факт, изменение требований всяко не всегда добавление нового, также и изменения старого.Про странность вписывания только по одной стороне уже упоминал, от этого дизайны едут. Остальное и так понятно, включая выкидывание неиспользуемого параметра, но речь эе о придирка..т.е. критике

О! А как надо? ПредлОжите свой вариант, или "времени многа нада"?

Кстати, уже предлагал "упростить"... как-то умолчали об этом... может заодно и...

на остальное:

"Пока мы видим как пишите вы" -- это нормально. Продолжайте скромничать... причина уже давно понятна.

"На исходный вариант меня уже не хватило" и "Тем более, что функционал метода сильно изменился." -- не изменился. Но обе цитаты наглядно показывают что Вас и на итоговый не хватило, пока не расписал...

"Но не указывает на причину. Ее придется искать в отладчике." -- ой. А что он "указывает"?!? Как-то пользуемся - удобна.

"Но вариантов их значений дофига и больше!" -- и?!? данные проверки не позволяют предотвратить типовое ошибочное писание вызвавшего кода?

"Так и проверяйте, что новые (или итоговые) размеры не нулевые!" -- ?!? метод делает проверки ровно те, и ровно в том порядке, в котором они востребованы... нафига я должен вставлять ДОПОЛНИТЕЛЬНЫЙ код?!?

"Тем не менее, от деления на 0 вы страхуетесь" -- ну да. Раз в исходном коде стоит @round(), стало быть где-то вполне возможно деление на ноль... или Вы предлагаете мне прошерстить все мегабайты исходников?!?

Ну и вот это всё:
------
Как было названо так и оставлено...
А нафига тогда рефакторинг делается, если ГК остается ГК?
------

Также наглядно показывает, что у нас с Вами разное понимание "ГК". Для меня ГК - это всё что работает неэффективно, делает лишнюю работу без нужды на то, писано "как попало"... мне как-то не сложно разбираться пусть и плохо структруированном, но эффективно работающем коде... но "глаз режет" липовое писание кода...

Для Вас - это явно нечто другое... что с полезностью выполняемой кодом работы явно связано опосредованно. Собственно об этом и завел речь в части деградации ИТ отрасли. Копроэкономика, аданака. Увы.

P.S. Здесь опять оформление улетело?!? Ладно нельзя смайлики добавлять по человечески было... теперь ни цветом выделить ни курсивом...

В здравом не будет. Но от случайных ошибок страховаться все равно надо. Assert'ы в том же C++ не просто так придуманы.

от всех случайных ошибок все равно не застрахуешься. Ко всему прочему проверки загромождают код и делают его малочитаемым. Проверки во всех уровнях только лишняя трата времени и сил. В безопасном, в защищенном от usererror-ов, коде она не нужна. Если она есть - затычка от своих же кривых рук. Написанный код нужно проверять самому, при первом же тестовом прогоне случайные ошибки будут отловленны в дебагере.
зы. у нас во время релиза бывает падает связь с удаленными серваками, хоть за проверяйся, все равно зараза упадет.

Кодстайл - дело вкуса того, кто его определяет. Слава Богу, мне попадались только команды, придерживающиеся Олмана, с чем я внутренне абсолютно согласен.

только способ сделать одинакого читаемый код в проекте где разрабов > 1, и только вкуса, посмотрите например на стандартный кодестайл жабыПоскольку на чем только не писал, то давно уже побарабану, лишь бы какой-то да был.

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

проверки загромождают код и делают его малочитаемым.
А по-моему, проверки делают код самодокументируемым и при правильном оформлении (а ля design by contracts) нисколько не ухудшают читабельность. Кроме того, еще помогают тестировщику (да и самому разработчику спустя какое-то время) понять, где баг, а где фича.

способ сделать одинакого читаемый код в проекте где разрабов > 1...
Я имел в виду, что кодстайл обычно принимается маленькой группой опытных товарищей на ИХ ЛИЧНЫЙ вкус, а пользоваться приходится всем, ессно. Здесь ничего не имею против.

ПредлОжите свой вариант, или "времени многа нада"?
На php - да, время надо, чтобы все аккуратно сделать, так как на нем не пишу. А на C# могу быстро сделать код, который делает то же самое, что у вас.

Продолжайте скромничать...
Ну я же не могу рабочий код выкладывать, NDA все-таки.

не изменился
А как же 3*4?

А что он "указывает"?!
Ни-че-го. Остается только брать отладчик в руки и вперед.

метод делает проверки ровно те, и ровно в том порядке, в котором они востребованы... нафига я должен вставлять ДОПОЛНИТЕЛЬНЫЙ код?!?
Я передам $old_y == 0. И у вас выполнится лишняя работа: && abs($rx=(double)$new_x/(double)$old_x) > self::EQUAL_ZERO. Ну и где ваши оптимизации, чтобы лишний код не выполнялся?

Раз в исходном коде стоит @round(), стало быть где-то вполне возможно деление на ноль...
Э-э-э, гм а если @round($x*$y), то $x, $y тоже будете проверять? Всегда думал, что деление на 0 там, где деление!

Вы предлагаете мне прошерстить все мегабайты исходников?!?
У вас такая связность кода???

у нас с Вами разное понимание "ГК"
Очевидно.

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

об этом и завел речь в части деградации ИТ отрасли
ИТ-отрасль на подъеме, какая деградация? Не надо судить по своим коллегам, тем более, что вы же их и нанимали. И сами подумайте, пойдет к вам профи работать? Ваш удел - самоделкины да студенты. Поднимайте уровень культуры разработки в своей команде хотя бы по тесту Джоэля до 10 из 12, тогда и студенты толковые к вам будут идти, а не всякий шлак. Ну и Касьянов с Дейкстрой, конечно, авторитеты, "но слишком хрустальные". (c)

Но если не делать проверок вообще, то тоже ничего хорошего. Уж лучше пусть будут лишние проверки, чем не будет необходимых.
А по-моему, проверки делают код самодокументируемым и при правильном оформлении (а ля design by contracts) нисколько не ухудшают читабельность. Кроме того, еще помогают тестировщику (да и самому разработчику спустя какое-то время) понять, где баг, а где фича.
для этого есть отладчик, если разработчик ленится проверить код в отладчике, если надеется на тестера - это плохой разработчик. И если это постоянно, то смахивает на саботаж.
В примере приведенном Толступузом, в его кодестайле, если сделать все проверки, то код проверки будет больше кода функции. Жесть. По мне так и проверки Толстопуза только показатель кривости системы допускающей мусор в базе. По хорошему все должно отсекаться раньше.

если разработчик ленится проверить код в отладчике, если надеется на тестера - это плохой разработчик.
Код и не должен проверяться в отладчике, есть модульное тестирование. А для остального должны быть внятные диагностические сообщения. И проверять входные параметры - это не надежда на тестировщика, а помощь ему.

смахивает на саботаж
На саботаж смахивает написание ГК.

если сделать все проверки, то код проверки будет больше кода функции
И что здесь плохого? Если код четко структурирован, то это не будет мешать. А если пользоваться code contracts, то аргументы еще и на этапе компиляции смогут проверяться!

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

Такие длинные условные операторы в краткой форме не способствуют пониманию кода, ИМХО. Приходится 2-5 минут вчитываться и вдумываться, вряд ли это такое ультра важное место где от пары дополнительных переменных вся производительность полетит к чертям. Сведение к инвариантам до предела не всегда способствует читаемости. Да, проверок и присваиваний может и получится минимальное количество, но просматривать код тяжеловато потом.

Только не пишите, что раз он идеален, то никогда потом на него смотреть не понадобится, пожалуйста.

Как всё это мило
Помню, когда-то давно и мне приходилось решать эту задачку. И я радовался, как ребёнок, когда придумал это же элегантное решение. Хорошее было время, лёгкое и наивное. Всё было простым и понятным, как в Кнутовских алгоритмах.
А потом в мою жизнь пришёл махровый ентерпрайз, и я продал ему за баксы то, что у программиста должно быть на месте души.
Ну что вы накинулись на человека, ей богу? Порадуйтесь за него - ведь он самый счастливый из нас, и до сих пор может заниматься такими изящными и простыми вещами. Ну молодец ведь, красиво же сделал. Чё вы брюзжите, как лысое пузатое старьё?
А я знаю, чё вы брюзжите... Вам завидно. Завидно так же, как и мне. Вы в глубине души тоже хотите вернуться в то время, когда могли себе позволить заниматься такими вот штуками, и получать от них удовольствие. Хотите, и в то же время понимаете, что это уже невозможно, это ушло навсегда. Потому что у вас жёны, машины, ипотеки, и сопливые детишки, и за всё это нужно платить. Платить баксами, вырученными с продажи ваших программистских душ.
Удачи тебе, толстопуз, счастливый ты наш.

Выложите на C#, мне как-то все равно.

"Ну я же не могу рабочий код выкладывать, NDA все-таки." -- так и я о том же...
"А как же 3*4? ... Я передам $old_y == 0. И у вас выполнится лишняя работа: ... @round($x*$y)"
Вы таки невнимательны. И достаточно сильно. Там було уже выше 3*4 - НЕ ИСПОЛЬЗУЕТСЯ де факто. Оба параметра - размеры ОДНОЙ (исходной) картинки... а, передайте! Можно в личку... я попробую залить на портал ТАКУЮ картинку... заодно и посмотрю как она выглядит...
Поскольку не пишите на ПХП, то там проблема не в самом делении, а в операторе "@" перед именем... он затыкает вывод ошибок "напрочь". То есть это означает "ИСПОЛНИТЬ МОЛЧА невзирая на ошибки"...
что и озадачило в том "что было"... т.е. уже кто-то на деление на ноль в этом месте кода нарывался явно...

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

На каком "подъеме"??? То что всё больше плохого кода пишется, всё большим количеством участников этого копропроцесса??? Гы. Там, ежели вчё IBM-овцы потихоньку пилят свои автописательские проги... вот когда уровень ручного ГК станет сопоставим или ниже с автоматическим ГК... куда-куда "все пойдут"?А впрочем, может оно так и надо.

Нормальные мужики. Оба. И много других не хуже. Просто это не "просматривать" надо, а в пальцах иметь...

Пасибки, только я не придумывал элегантного решения... потому и выложил. Это результат тупого применения инвариатных преобразований... я даже не особо разбирался чего оно делает... уже потом, после того как выложил наступило прозрение, что по сути решение действительно красивое - тянем картинку к минимально возможному аспекту... но оно не моё... увы.

Я про то и пытаюсь донести, что правильное применение правильных методов позволяет "не задумываясь" писать такие вещи "левой задней ногой".

Выложите на C#
Например так:

так и я о том же...
Нет, мы о разном. Рабочий код я не могу выкладывать не потому, что он ГК, а потому что NDA.

Можно в личку...
Да зачем в личку? Просто вызовите size_normalize(800000, 600000, 80, 60).

проблема не в самом делении, а в операторе "@" перед именем... он затыкает вывод ошибок "напрочь"
Ну хоть что-то полезное узнал
приходится править то, что есть. Увы.
Не понимаю этих вздохов! Вы - начальник, код - вашей команды. Так с кого спрашивать за ГК? Настраивайте процессы: код-ревью, тестирование, автобилды, обучение сотрудников и пишите нормальный код.

На каком "подъеме"?
С 10-15 лет назад не сравнить - из проганья на коленке ИТ в России превратился в настоящую индустрию. Только у нашей компании обороты исчисляются сотнями миллионов $$, а 15 лет назад компании вообще не было.

Нормальные мужики. Оба. И много других не хуже.
Непонятно только, откуда ГК-то берется?

Пасибки, что уделили внимание. Посмотрел код. Если не учитывать общую многословность, то оно "практически" тоже самое, но чуть дольше. А упростить?

... нет об одном.

Прикрываться можно чем угодно, хоть фиговым листком. В бытность, даже имея 1-ю форму допуска и работая в отдельно взятой комнате под тройной охраной, ... и позже, работая на Рона Гордона... свободно обсуждал отдельные куски кода. Потому что также как и выложенный здесь кусок ранее, сам по себе это всего лишь кусок кода "ни о чем". Даже хорошо документированный. Просто не надо выкладывать "лишнее" и только.
... а прикрываться можно чем угодно.

... не понимаю...
Вы делаете стандартное предположение, которое в корне неверно. Если бы то, что сейчас развивает и попутно(!) правит моя команда, писалось под моим руководством - наверное бы повесился с горю. Этот код равномерно г..нокодился около десятка программистов начиная с 200... какого-то году... даже и не знаю с какого. Между прочим, некоторые из них тут появлялись, пару знаю - точно ...

... 10-15лет...
вот, вот... не развился... а встроился полноценно в копроиндустрию.

... как это откуда? Как раз из "индустрии".

оно "практически" тоже самое, но чуть дольше. А упростить?
Оно не многословно, там нет ничего лишнего. А упростить - переписать в одну строку что ли, выкинув проверки и диагностику? А зачем? Этот код еще будет читать N человек, зачем тратить их время на то, чтобы они оценили "гений" афтара кода? Лично я предпочту слегка косячный, но понятно написанный код, который легко оттестировать и пофиксить, чем работающий, но абсолютно нечитабельный и не модифицируемый код.

Прикрываться можно чем угодно, хоть фиговым листком.
Мда, как все плохо с пониманием, что такое NDA...

имея 1-ю форму допуска свободно обсуждал отдельные куски кода
Я должен похвалить? Понятно, что фрагмент для разработчиков почти ничего не значит, но для юристов это не так. Если вы застряли в подростковом развитии, то это не значит, что в международных компаниях то же самое.

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

Если бы то писалось под моим руководством - наверное бы повесился с горю.
Да и сейчас пока еще не видно кардинальных улучшений...

не развился... а встроился полноценно в копроиндустрию.
Именно развился, откровенное Г. никто покупать не будет. Или вы MS, IBM, Oracle и т.д. тоже считаете представителями этой "индустрии"?

К сожалению не знаю С#, поэтому промолчу... но сдается мне, что оно медленне. Дело не в том, что кусок маленький "ни о чем"... это же просто как пример подхода. На больших кусках кода, всё становится значительно грустнее. То что было показано - это не "гениальность афтара", а переход между было и стало...

То что "было" - это как раз и есть "слегка косячный, но понятно написанный код", который Вы готовы предпочесть... и смотреть надо не на разницу между повтором того что стало на другом языке вовсе...
... вот из того что было, как раз и получается нечитаемый, немодифицируемый код... просто от одного объема.

С пониманием NDA всё нормально. Код - он и есть код. Это набор инструкций и имен. Замените имена в куске кода - и всё станет нормально даже для юристов. Или Вы на профессиональных форумах вопросов не задаете, примеров для получения внятных ответов не приводите? Вот не верю я в такие сказки, почему-то...

Опять же как пример:
SELECT my_current_cash FROM webmoney.cashes WHERE my_login = "tolstopuz" AND password = "123";
явно может нарываться на юристов... а пример:
SELECT field1 FROM table1 WHERE search_field1 = 'text_string' AND search_field2 = 'string_hash';
один из многих тысяч вариантов кода "ни о чем". Ваши юристы, вместе с NDA спокойно спят... а стиль писания - виден тем не менее...

Так что прикрываться можно чем угодно. Истинная причина - всё та же.

... насчет медали - согласен на все 200%. Процесс ещё очень далек, хотя кое-какие результаты уже видны, о чем уже писал.

из "улучшений", на глазок:
1. Добавление прайсов на портал. Пользователям предоставлен простой, наглядный интерфейс, который больше не заливает чего попало и куда попало, не создает липовых описаний товаров, улучшено попадание товара в раздел портала примерно в трое, снято ограничение на 500 товарных строк, сняты ограничения на формат файлов и картинок, разрешено множественное добавление картинок к строке, напрямую из файла, примерно в 10 раз ускорен процесс ручного редактирования нераспознанных товарных строк, ускорен сам разбор прайсового файла... тоже около 10 раз, разборщик теперь имеет несколько (настраивается и расширяется произвольно) стратегий разбора строки, способен использоваться для разбора любых текстов (хоть PHP, хоть этого форума)... и при этом из кода удалено около 5000 строк из около 30 файлов.

Потрачено времени с 15 декабря по 24 января. Оригинал писался около полугода и имел двухступенчатую работу... это со стороны программирования. Со стороны клиентов и продаж - уже писал, что благодарность клиента, привозящего подарки, помимо оплаты размещения на портале - это уже становится нормой. Я так понимаю, что не за красивые глазки...

2. Доработан редактор видов товаров. Он теперь просто работает. Опять же быстро, наглядно и непринужденно. Только за один вчерашний день модератор исправил около 1000 видов товарных позиций на портале. Ранее, это было ваще невозможно... для этого было добавлено около 300 строк кода и удалена ещё пара тысяч.

Как факт, наконец-то отключен интерфейс, который использовался для этих целей с 1998года... совсем. То, что некоторые из присутствующих тут (и не в одиночку!) в течении нескольких лет (2004-2006 если не ошибаюсь) пытались сотворить на Interbase и Delphi - сделано за пару месяцев...

3. Управление изображениями. Устранено двойное копирование файлов с места на место в процессе двухступенчатости работы, собственно с самой двухступенчатостью вместе. То есть места на дисках надо теперь почти в три раза меньше (временные копии)... стало быть "загнуться" они в три раза позже... или можно хранить в три раза больше...

4. Управление БД. устранено тройное хранение данных в связи с устранением двухступенчатого процесса. Опять же время доступа, скорость работы, жизненный цикл свободных объемов дисков... индексы и прочая лабуда как следствие...

5. Добавлен новый функционал... ну просто совсем новый. Собственно это и было работой... остальное так, "между делом".

Хотя, Вы правы, я очень хорошо осознаю, что реально - это капля в море того софта, который здесь крутится и пишется на протяжении уже 16 лет...

И опять же, написал это вовсе не для того чтобы показать "какой я весь в белом" (во-первых не один работаю)... а для того, чтобы показать РЕАЛЬНЫЙ, ПОЛЕЗНЫЙ КПД современного типового прогера "от копроиндустрии". Фактически, то что можно делать за месяц - делается за год. То что может работать на железе - теперь требует раз 10 больших затрат на тоже самое. То что пишется - требует постоянного внимания разработчика, хотя ничего нового реально не создается - т.н. "сопровождение".

Вот это и называю деградацией ИТ-индустрии. Это теперь норма. И как Вы тут кстати упомянули - они и есть главные застрельщики.

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

сдается мне, что оно медленне
Привыкли утверждать голословно? Во-первых, во время исполнения (или даже на этапе установки ПО на конкретной машине!) MSIL транслируется в native, так что работает достаточно шустро, а во-вторых, только замер производительности ответит на вопрос, что быстрее.
С пониманием NDA всё нормально
Вы это серьезно или просто притворяетесь клоуном?

Замените имена в куске кода - и всё станет нормально даже для юристов
Аж 2 раза. Теперь кто-то зарегистрирует этот фрагмент код и может предъявлять претензии на авторство моей компании, так как код будет иметь ту же структуру и в скомпилированном виде выглядеть аналогично! К сведению, разработчикам Mono (альтернативного .NET фреймворка) запрещено дизассемлировать и читать код .NET, чтобы не писать похожий код.

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

стиль писания - виден тем не менее
Я же вам заслал пример кода, не поленился. Или вам надо 10 KLoC кода, чтобы оценить? Даю слово, что продакшн код у нас в конторе написан еще лучше, так как на него выполняется многократное ревью. ГК тупо не пройдет, да и людям в глаза смотреть стыдно будет за плохой код, так что все стараются.

из "улучшений", на глазок:
Надеюсь, вы копировали это из квартальных отчетов или писали на основе закрытых задач и багов в багтрэкере, а не по памяти?
это и называю деградацией ИТ-индустрии
Это деградация конкретно вашей конторы, которая на уровень лидера индустрии никогда и не подымалась. Более того, застряла на этапе наколенного девелопмента.

они и есть главные застрельщики
MS, IBM, Oracle - говнокодеры??? Компании, в которых работают лучшие из лучших разработчиков, до которых вам как до Луны пешком??? У которых процесс разработки поставлен от и до?

не нравится Вам терминология копрокода
Отчего же? Давайте называть вещи своими именами - у вас именно тот самый копрокод, и вы его типичный воспроизводитель, если на сделанное вам ревью кода вы лепите глупые отмазки на уровне джуниора. И по себе людей не судят - старая народная мудрость, не надо говорить от имени всей индустрии, находясь на ее задворках.

Считаете Вы что количественный рост копрокода - это прогресс... и ладушки.
Не считаю. Более того, осуждаю всех, кто его пишет, так как сейчас есть все инструменты и методики для написания хорошего кода. А 10-15 лет назад все было совсем по-другому, тогда про тестирование и рефакторинг еще не многие слышали, не говоря уже о применении...

Cпасибо за код.
Мне понравился код tolstopuz'а. По духу, так сказать, ближе. Ничего лишнего (только запутал с переменными, всё же x/y - это координаты, и в исключении желательно кидать "плохие" параметры). Если писать нужно за деньги, то можно разводить бадью с ручными проверками пред и пост условий. Кстати, а как Вы, Well, проверяете вручную инварианты? В программировании по контракту ведь и это есть.
Вопрос всем: скажите, парни, почему вы используете арифметику с плавающей точкой для картинок, где она по сути не нужна? Я не силён в PHP. Но попробовал избавиться в коде tolstopuz'а от double. На моём стареньком ноутбуке выигрыш по производительности на этой маленькой функе составила 25-30% (PHP 5.3.3-1ubuntu9.7 with Suhosin-Patch (cli) (built: Dec 13 2011 17:53:04)). Погрешность ведь получается 1 пиксел. Зачем все эти round?
Вот код:
http://pastebin.com/2a9WGjz7

Вот код
Те же проблемы, что и у афтара топа: упадет на вызове size_normalize(800000, 600000, 80, 60), хотя я не вижу объективных причин не выполнить такого преобразования размеров. И умножение перед делением (RR * $to_sx / $sx) создает ошибку переполнения в целочисленной арифметике, если передать $to_sx > 2^29 (хотя на php, возможно, это и пройдет, если он автоматом подбирает типы данных).

как Вы, Well, проверяете вручную инварианты? В программировании по контракту ведь и это есть.
Вызовы ValidateImageSize можно было заменить на Contract.Requires(size.Width > 0 && size.Height > 0, "Invalid bla-bla-bla") для входных аргументов и Contract.Ensures() для результата. Мои проверки аналогичны этому, но работают и без CC.

скажите, парни, почему вы используете арифметику с плавающей точкой для картинок, где она по сути не нужна?
В принципе - да, не особенно нужна. Только тогда надо корректно написать целочисленное умножение-деление, чтобы не возникали ошибки переполнения. Это только кажется, что все так просто, даже сложить/перемножить 2 числа - нетривиальная задача.

Во-от... старею... меня уже улучшить смогли. Пасибки.

Дальнейшая идея по ускорению и улучшению: если некруглую константу заменить с 1000 на правильную - 1024, то можно обойтись битовыми сдвигами вместо умножения... это ишо быстрее. Хотя на интерпретароре - думаю совершенно непринципиально.

Вот об том и речь, что аккуратное писание кода "в мелочах" - в конечном результате дает общий выигрыш по всем параметрам ОДНОВРЕМЕННО: скорости работы, требуемых объемах, причем как оперативных так и долговременных, масштабируемости и расширяемости в дальнейшем - сроке жизни кода...

Вы это серьезно или просто притворяетесь клоуном?

Думаю, те кто читают, легко понимают, что переписав чужое решение на другом языке, Вы никакого СВОЕГО кода не предоставили, а ссылки на NDA в силу предложения предоставить СВОЙ стиль на ЛЮБОМ своем куске кода - всего лишь "оправдашки". Потому что показать НЕЧЕГО.

Это так же как типовой соискатель: "Хорошо, чего принесли, дабы посмотреть?" "... ой. а это, у мене дома комп сгорел..."
По Тем же проблемам Похоже, что наличие краевых эффектов в любом коде - Вам не знакомо. Вопрос не в том "поплывет оно или не поплывет" на данных, которых НЕ бывает в природе, а в том чтобы оно РАБОТАЛО в нормальных условиях и реагировало на ненормальные, но встречающиеся.

Всегда можно придумать исскуственный набор условий, в которых никакой код не работает. Но это не аргумент в споре - это оправдашки того, кого "поймали"...
P.S. К вопросу у флагманах индустрии: Я таки был не совсем прав, потому как Вы собрали в одну кучу сильно РАЗНЫЕ фирмы.

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

IBM - в прошлом это наверное самая крутая контора, сделавшая для индустрии очень много чего полезного. На сегодня - она очень разная... там есть отделы, работающие НА копроиндустрию, а есть те, кто пишет то, чего в будущем сделает всех копропрогеров безработными в единочасье.

Мелкософт - как раз и есть флагман копроиндустрии. Те самые мои сверстники, уехавшие туда, достаточно быстро ими стали по их же мнению.

Вот код
Те же проблемы, что и у афтара топа: упадет на вызове size_normalize(800000, 600000, 80, 60), хотя я не вижу объективных причин не выполнить такого преобразования размеров. И умножение перед делением (RR * $to_sx / $sx) создает ошибку переполнения в целочисленной арифметике, если передать $to_sx > 2^29 (хотя на php, возможно, это и пройдет, если он автоматом подбирает типы данных).

Для того, чтобы утверждать, что что-то упадёт, нужно знать предметную область. Вы спросили tolstopuz'а, бывают ли у него картинки по 800000 пикселей (или $to_sx == 2^29)? Каков контракт? Мне, например, не понравилось в Вашем коде то, что фактически запрограммирован тот самый сферический конь в вакууме. Во-первых проигнорировано утверждение, что картинки на входе гарантированно не имеют отрицательные размеры и зачем-то наколбашена проверка самого себя под мифом проверки предусловий. Типа "программирование по контракту". Только эти "контракты" у Вас будут сидеть в продакшине и за эти строки будет платить заказчик. Если в с++ ассерты можно убрать из релиза, то эти художества намертво сидят в коде и впустую греют процессор. Их основное предназначение - выявить ошибки вашей же команды, но не выполнение целевой задачи. Этот случай отлично описан в Pragmatic Programmer. Во-вторых, почему-то не замечена изначальная константа EQUAL_ZERO и забит общий ОкадЭмический алгоритм. То есть Вы, не глядя на предмет, нарушили правила игры и забабахали сразу броненосец. Вот поэтому я и написал, что если платят за процесс написания (число строк кода), а не за результат, то я пишу точно так же как Вы - по-максимуму. В-третьих, длинные названия переменных, но раз пишут так делать в умных книжках (писать как рассказ), то ладно уж. По коду видно, что его писал типичный enterprise программист, солидный, начитанный, намертво уверенный в своей правоте и неторопливый. Лоск на 10 из 10
В моём примере я только показал ось улучшения производительности. Но на чистовике бы только добавил внятное название контанты RR и выкидывание исключения с параметрами. Только не стал разбираться, как в PHP клеить параметры в строку. И никаких ненужных проверок псевдо-предусловий
Вижу зря я наезжал на tolstopuz'а. У этого дяТьки некоторым есть чему поучиться. Только по коду можно понять, кто о чём говорит

Вот код
Те же проблемы, что и у афтара топа: упадет на вызове size_normalize(800000, 600000, 80, 60), хотя я не вижу объективных причин не выполнить такого преобразования размеров.

Ничего не упадёт. Вылетит исключение, которое можно перехватить/залогировать, и оно убережёт пользователя от вида замаштабированной явно не-картинки. Ваш же код начнёт масштабировать явно не то и может любезно вывалит это на экран пользователю. Потом вернётся багом от саппорта. И процесс и бабло будет идти

Вы никакого СВОЕГО кода не предоставили
Не понял, а чей я вам код прислал? Ваш?

переписав чужое решение на другом языке
Так и вы же рефакторили чужой код?

ссылки на NDA в силу предложения предоставить СВОЙ стиль на ЛЮБОМ своем куске кода - всего лишь "оправдашки". Потому что показать НЕЧЕГО.
Допустим. И ваш код от этого автоматически становится идеальным?

наличие краевых эффектов в любом коде - Вам не знакомо
Напротив, похоже, что оно незнакомо именно вам. Так как мой код работает корректно на любых данных, а ваш - только на некотором подмножестве, причем достаточно странном.

Всегда можно придумать исскуственный набор условий, в которых никакой код не работает
Да ладно вам. Сломаете мой код (подобрав среду и комбинацию входных параметров) - сниму шляпу.

сильно РАЗНЫЕ фирмы
Все конторы объединяет то, что их продукты достаточно качественные, процессы в них поставлены, а работают лучшие разработчики. И не вам их судить.

мои сверстники, уехавшие туда, достаточно быстро ими стали по их же мнению
А мои знакомые, которые работают в MS, так не считают.

нужно знать предметную область
Постановки задачи не было. О том, что в >1000 раз сжимать нельзя (а увеличивать почему-то можно) сказано тоже не было. Да и по коду все варианты некорректных ситуаций сводятся почему-то к одной ошибке.

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

Типа "программирование по контракту"
Не типа, а можно и CC использовать, и assert'ы в C#. И ничего греться не будет. Ну и надо определиться, в какой окружении функция работает - в стерильном или нет. Судя по проверкам на 0 - у афтара точно не стерильное, данные летят сразу из БД без проверки.

если платят за процесс написания (число строк кода), а не за результат
Получить быстрый результат, наплевав на качество (сюда я отношу не только корректность работы, но и поддерживаемость кода) - это и есть признак того, чем афтар так недоволен!

типичный enterprise программист
Ну да, так оно и есть. Привык думать на 10 шагов вперед и уважать труд коллег, а не по-быстрому на коленке и хоть трава не расти.

Ничего не упадёт. Вылетит исключение
Для пользователя это одно и то же.

явно не-картинки.
С чего бы это? Панорамы бывают очень даже большого горизонтального размера и вполне корректно масштабируются. И проверять тогда уж надо не степень сжатия, а разумность исходных и требуемых размеров, и желательно где-то за пределами функции, так как времена меняются быстро, сегодня фотки размером 10Мп, а через пару лет - 100Мп.

явно не-картинки.
С чего бы это? Панорамы бывают очень даже большого горизонтального размера и вполне корректно масштабируются. И проверять тогда уж надо не степень сжатия, а разумность исходных и требуемых размеров, и желательно где-то за пределами функции, так как времена меняются быстро, сегодня фотки размером 10Мп, а через пару лет - 100Мп.

Какие панорамы?! Даже тут Вы думаете не предметно о прайс-листах.
Дальше спорить смысла не вижу, потому что прекрасно понимаю Ваш стиль и могу его имитировать.
Но не выношу, когда из задачи клиента раздуваются сферические кони и решается не сама задача, а с помпой реализуются интересующие самого программиста незначительные для клиента вещи (из 10 строк толстопуза раздута ПРОГРАММА). Дедлайн вам судья и дальнейшее сопровождение. А у нас и без коней всё хорошо

Пасибки. Я просто не видел C#, поэтому мне сложно было оценить ТАКОЕ г...о на предмет "дополнительных" улучшений... собственно их и выкидываю уже третий месяц тоннами.

НПП
Мне уже, просто, интересно - вам меряться не надоело, а?

Завидуйте молча:). Пусть порезвяться, а то тут с программисткими темами слабовато :).

Олег - я уже, читая эту ветку, тихо радуюсь, что 1С - не программирование.
Этакий пикник на обочине индустрии по производству порносайтов, тупо описывающий средней величины заводик.
Я бы свой код выложил, но жалко местечковых гуру - на валерьянке разорятся (кто успеет дотянуться).