Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 203
Афигеть, еще и деньги за такое 0_0
WTF
WTF
А причём тут битрикс?
Начальник попросил продемонстрировать сертификаты?
Теперь и я стал нелюбить битрикс — за то что суют свой сертификат не в своё дело.
Начальник попросил продемонстрировать сертификаты?
Теперь и я стал нелюбить битрикс — за то что суют свой сертификат не в своё дело.
Я к тому, что это не топик про битрикс, а просто чередной баг NetCat. Пускай на неё и срут, с вашей стороны это выглядит «тупо пиар» битрекса.
Ну всё же, раз пошёл разговор о сертификатах. Берём теже сертификаты «Немесис» «Positive» датированые 2006 и 2007 годом. Берём, хмм… да хотябы журнал «Хакер» подшивкой за 2007 год.
Что мы видим? «Взлом CAPTCHA: надежный Битрикс» первое, что я нашёл.
Дак, что дают сертификаты от этих фирм вам? Почему люди плохо отзываютя о битриксе?
Подарите кегу пива админу с большущей кармой и вот вам плюсы.
Ну всё же, раз пошёл разговор о сертификатах. Берём теже сертификаты «Немесис» «Positive» датированые 2006 и 2007 годом. Берём, хмм… да хотябы журнал «Хакер» подшивкой за 2007 год.
Что мы видим? «Взлом CAPTCHA: надежный Битрикс» первое, что я нашёл.
Дак, что дают сертификаты от этих фирм вам? Почему люди плохо отзываютя о битриксе?
Подарите кегу пива админу с большущей кармой и вот вам плюсы.
Не знаю, как остальные 39, а я минусанул за огромные иллюстрации, совершенно не к месту, сделали бы лучше ссылками.
По минусу за каждый коммент? Хотите объективно расскажу? А, впрочем, не поймете.
Команда разработки БУС — молодцы, этого отрицать не будут, они сделали продукт, который продается, ага.
А вы — идиот. «кодируйте» дальше, пусть ваши проекты спасет БУС, а не ваш потенциал и талант. У него шансов больше.
Команда разработки БУС — молодцы, этого отрицать не будут, они сделали продукт, который продается, ага.
А вы — идиот. «кодируйте» дальше, пусть ваши проекты спасет БУС, а не ваш потенциал и талант. У него шансов больше.
На такие сертификаты водятся те, которые ничего не смыслят ни в системах утправления данными ни в программировании или безопасности продуктов. Такие сертификаты интересны простым пользователям, которые верят всему, что написано и показано. Все мы знаем как получают такие сертификаты и за что.
Привет аттестированный битрикс-программист как твои дела?
Нука быстренько взялся за разгребание фекалий! Это твоя работа!
Только сам, пожалуйста, много не наделай! А то потом все эти какашки разгребать не аттестированным :(
Нука быстренько взялся за разгребание фекалий! Это твоя работа!
Только сам, пожалуйста, много не наделай! А то потом все эти какашки разгребать не аттестированным :(
Не поверите, но лучше использовать самописные решения (возможно написанные на оупенсоурсном CMF, либо наработанным годами — собственным), уж если вы программистом себя называете.
Проверено — значительно хуже использовать самописные решения чем любые другие. Понимание приходит сразу после ухода программиста, после чего вдруг всё перестаёт работать.
собственные — не значит 1-го программиста. Слишком узко мыслите 8)
Это смотря какого и как ушедшего.
Если речь идет о проблемах с сопровождением — то это зависит от профессионализма как ушедшего, так и пришедшего программиста. Мне известны многие случаи улучшения качества кода после смены программеров.
Другое дело, если кто-то ушел и специально создал проблемы или ушел потому, что не смог поддерживать свой собственный спагетти-код. Или просто человек ушел и начальство решило — программист не нужен, и так все уже работает.
Если использовался распространенный фреймворк, использовался единый стиль кодирования и комментирования — поверьте, такой проект будет ощутимо проще поддерживать, чем закрытый универсальный коробочный движок.
Если речь идет о проблемах с сопровождением — то это зависит от профессионализма как ушедшего, так и пришедшего программиста. Мне известны многие случаи улучшения качества кода после смены программеров.
Другое дело, если кто-то ушел и специально создал проблемы или ушел потому, что не смог поддерживать свой собственный спагетти-код. Или просто человек ушел и начальство решило — программист не нужен, и так все уже работает.
Если использовался распространенный фреймворк, использовался единый стиль кодирования и комментирования — поверьте, такой проект будет ощутимо проще поддерживать, чем закрытый универсальный коробочный движок.
ах-ах
безопасность то одно, это ведро
но внутри то кал ;))) с опарышами
зы: сертификаты то всё такое, замыливание глаз и ПР — маркетинг
безопасность то одно, это ведро
но внутри то кал ;))) с опарышами
зы: сертификаты то всё такое, замыливание глаз и ПР — маркетинг
Помниться в битриксе можно было отгадав один раз капчу вручную, отдать её роботу, и он мог ей воспользоваться бесконечное количество раз.
Ох смешные формулировки в этих сертификатов… Так и представляю «неязвимость» к dos-атакам, направленным на веб-приложение поднятом на Бритиксе…
Но но, Друпал грязными лапами не трогать. Он во первых бесплатный.
А во вторых… в третьих, миллионых… битрикс с ним рядом не лежал, про Неткат ваше молчу.
А во вторых… в третьих, миллионых… битрикс с ним рядом не лежал, про Неткат ваше молчу.
Покупатель платит деньги не за красивый код, если вы не в курсе.
за баги платит непоправленные?
с точки зрения пользователя это выглядит даже большим ахтунгом, чем с программистской.
с точки зрения пользователя это выглядит даже большим ахтунгом, чем с программистской.
Во первых форум довольно редко нужная вещь. Я бы сказал экзотичная вещь в плане надобности и присутствия ее на неткатовских сайтах. Поэтому и баги по нему не приоритетны ни разу (на мой взгляд). Конечно то, что ее не исправили это плохо, плохо.
Но я думаю реально ни у одного из клиентов купившего неткат с форумом, не было проблем с левыми сообщениями на форуме. Это никогда и никому не было нужно.
Возможность замусоривать форумы и «гневно обращать внимание» на недостатки и «заставить ленивых засранцев шевелится» это чисто эстетическое удовольствие для хабраюзеров, которые недовольны тем, что такое(!) продают за деньги.
Но я думаю реально ни у одного из клиентов купившего неткат с форумом, не было проблем с левыми сообщениями на форуме. Это никогда и никому не было нужно.
Возможность замусоривать форумы и «гневно обращать внимание» на недостатки и «заставить ленивых засранцев шевелится» это чисто эстетическое удовольствие для хабраюзеров, которые недовольны тем, что такое(!) продают за деньги.
Вы уверены? Если он не нужен, то зачем продают?
Вышеприведенный баг это только верхушка айсберга. Некоторые баги позволяют и сайт взломать.
Лично мне не нравится совковая идеология компании — хороший маркетинг, красивая обертка — а внутри куча багов. За что мы должны любить эту компанию?
Вышеприведенный баг это только верхушка айсберга. Некоторые баги позволяют и сайт взломать.
Лично мне не нравится совковая идеология компании — хороший маркетинг, красивая обертка — а внутри куча багов. За что мы должны любить эту компанию?
так и темы можно создавать
Ну думаю сейчас они точно проснутся и быстро сварганят заплатки.
После вашей статьи там на форуме в данной ветке бардак полный.
Кончено баг — это зло. Но на живом сайте его не стоило показывать. :)
Кончено баг — это зло. Но на живом сайте его не стоило показывать. :)
а по-моему, как раз на живом и стоило, именно на их. что бы лень из них выбить
главное чтоб для автора потом это все без последствий закончилось.
ну… а какие могут быть последствия? законных — вроде никаких…
Если в квартиру дверь открыта — это не означает, что в нее можно всем входить.
А так на лицо чистое хулиганство.
А так на лицо чистое хулиганство.
Статья 213 УК РФ.
«Хулиганство, то есть грубое нарушение общественного порядка, выражающее явное неуважение к обществу, сопровождающиеся применением насилия к гражданам либо угрозой его применения, а равно уничтожением или повреждением чужого имущества»
Насилия к граданам применено не было (технически невозможно через интернет для здоровых граждан не подключенных к аппаратам искусственного дыхания и всему такому :), уничтожения или повреждения имущества не было. Посты явно не имущество, а кроме того они вряд ли принадлежат создателю сайта (скорее, автору поста).
«Хулиганство, то есть грубое нарушение общественного порядка, выражающее явное неуважение к обществу, сопровождающиеся применением насилия к гражданам либо угрозой его применения, а равно уничтожением или повреждением чужого имущества»
Насилия к граданам применено не было (технически невозможно через интернет для здоровых граждан не подключенных к аппаратам искусственного дыхания и всему такому :), уничтожения или повреждения имущества не было. Посты явно не имущество, а кроме того они вряд ли принадлежат создателю сайта (скорее, автору поста).
Человек просто опечатался.
Вы знаете, багрепорты скидывали им больше года назад! Но неткат такая компания, что без этой темы делать они ничего не будут
Ха, багрепорты. У меня на предыдущей работе (крупный рекламно-издательский холдинг) было полдесятка NetCat-ов купленых в «максимальной комплектации». О некоторых критических ошибках писали непосредственно их шефу — в ответ получали «большое спасибо», и никаких багфиксов. В итоге пришлось фиксить самостоятельно — из за этого самый крупный проект там до сих пор на 2.4, на 3.х перейти из за огромного количества переделок в коде практически нереально — если только всё заново написать.
Что там такого хорошего в этом неткате, что его действительно стоит использовать? Если все равно надо пилить руками, то почему бы не бахнуть какой-нибудь Liferay и пилить уже систему которая под пиление заточена.
Ну вообще система довольно таки удобна для небольших типовых сайтов — можно делать вообще не вдаваясь в программирование. Но шаг влево шаг вправо — начинаются танцы с бубнов. Почему мы использовали НетКет — не знаю, он был куплен до меня, возможно по [i]политическим мотивам[/i].
> почему бы не бахнуть какой-нибудь Liferay и пилить уже систему которая под пиление заточена.
Вы работали с Лайфреем? И как впечатления?
Вы работали с Лайфреем? И как впечатления?
Честно говоря — пока еще нет. Читаю сейчас книжку по его допиливанию, и написанное там очень радует.
Из негатива я пока нашел только «время запуска на современном компьютере — в пределах минуты», что намного меньше чем наша самопальная CMS, но и намного больше чем хотелось бы =) Но таки это Java, и эта проклятая минута старта наверняка потом намного снизит нагрузку на сервер.
Из негатива я пока нашел только «время запуска на современном компьютере — в пределах минуты», что намного меньше чем наша самопальная CMS, но и намного больше чем хотелось бы =) Но таки это Java, и эта проклятая минута старта наверняка потом намного снизит нагрузку на сервер.
>время запуска на современном компьютере — в пределах минуты», что намного меньше чем наша самопальная CMS
Ух ничего себе у вас «самопальная CMS»))
Ух ничего себе у вас «самопальная CMS»))
Чесно говоря, очень не советую вам использовать лайфрей. У вас будут 1) проблемы с приделыванием дизайна и 2) проблемы с наполнением CMS контентом (встроенная система xml-шаблон для схемы данных, xslt-шаблон для вывода данных просто чудовищна).
Чуть не забыл — CMS периодически дико виснет при отправлении данных с формы, но сами данные все-таки добавляются.
Было это года два назад, в версии 4.3, насколько я помню.
Было это года два назад, в версии 4.3, насколько я помню.
> «время запуска на современном компьютере — в пределах минуты»
Что же это вы явовцы там курите, как же это надо напистаь то чтобы она только минуту запускалась?
Что же это вы явовцы там курите, как же это надо напистаь то чтобы она только минуту запускалась?
Очень просто: например, кэширование структуры БД для последующей оптимизации запросов. Опцонально можно написать что угодно, включая плагины к веб-серверу :) А веб-сервер тоже не быстро запускается, да.
Наоборот, у меня сердце кровью обливается, когда я смотрю на PHP-скрипты, которые КАЖДЫЙ раз заново подключаются к базе данных при своем выполнении. Или которые КАЖДЫЙ раз заново разбирают файлы конфигурации. Я в свое время, когда писал сайт на PHP, отказался хранить конфигурацию в XML, т.к. каждый раз парсить его заново — очевидный филькин труд… а так бы удобно было с XML.
Или эту проблему в рамках PHP можно как-то удобно решить стандартным способом? Конкретно: повторные подключение к БД, повторный перепарсинг конфигов, повторное создание одних и тех же структур данных. Расскажите, как вы сами это делаете.
Наоборот, у меня сердце кровью обливается, когда я смотрю на PHP-скрипты, которые КАЖДЫЙ раз заново подключаются к базе данных при своем выполнении. Или которые КАЖДЫЙ раз заново разбирают файлы конфигурации. Я в свое время, когда писал сайт на PHP, отказался хранить конфигурацию в XML, т.к. каждый раз парсить его заново — очевидный филькин труд… а так бы удобно было с XML.
Или эту проблему в рамках PHP можно как-то удобно решить стандартным способом? Конкретно: повторные подключение к БД, повторный перепарсинг конфигов, повторное создание одних и тех же структур данных. Расскажите, как вы сами это делаете.
видимо вы насмотрелись на монстров вроде Zend framework :) Понимаю, у меня жедания что-то на нем писать тоже нету. сотни класов, с именами по 20 букв, любому вынесут мозг.
Насчет php-скриптов, с удовольствием расскажу. Во-первых, код интерпретатора php довольно-таки оптимизирован, и он может парсить скрипты килобайтами за довольно-таки маленькое время (это, конечно, еще не повод писать огромные системы с тысячами классов). Во-вторых, в php нормальные люди стараются не писать полотнища кода и представлять каждую букву отдельным объектом :) Часто удобнее вместо объекта использовать массив, а они в php реализованы грамотно.
Кстати, строки и массивы в php реализованы со счетчиком ссылок и используют механизм write-on-copy, то есть, если вы пишете $a = array(… тут начальные значения… ); $b = $a;, то операция присваивания очень дешевая :) Вот если вы захотите изменить $b, тогда будет сделана копия $a и изменения в ней, то же самое со строками.
В-третьих, не знаю как в Яве, в php файлы и классы можно подключать динамически, только когда они нужны. В-четвертых, с php можно использовать кеши, вроде memcached или apc (он круче memcached тем, что использует shared memory — а значит, нет издержек на установление соединения с демоном, обратная сторона — он недоступен извне, только на 1 сервере)
В общем, что касается парсинга, есть расширение APC, хранящее пропарсенные скрипты (в виде байткода) на диске, или в shared memory. Это убирает издержки на компиляцию скриптов в байткод, хотя особого выигрыша не дает, всего раза в 2.
Насчет издержек на подключение к БД — можно использовать persistent connections, то есть соединения, не закрывающиеся между запусками скрипта, но тут есть риск, вдруг предыдущий скрипт например забыл закрыть транзакцию? или ввел БД в какое-нибудь невменяемое состояние?
Файлы конфигурации — честно говоря, не понимаю, чем вам нравится XML (абсолютно нечитаем для человека имхо), но я бы сделал так: при первом обращении к конфигу — читал бы и парсил XML, сохраняя данные в виде например сериализованного массива php в файле (или в кеше), при повторных обращениях — смотрел время модификации исходного файла и если он не обновился, брал бы кешированную версию, думаю кода тут на 20 строк. Собственно такую штуку я и реализовывал для описания полей моделей, только с YaML а не XML.
Повторное создание структур данных — мне как-то не приходилось работать с системами, которые бы генерировали какие-то огромные структуры данных, но думаю решение опять же в аккуратном использовании кеша.
Если уж на то пошло, постоянный перезапуск скрипта при каждом запросе имеет свои преимущества: отсутсвие необходимости в тормозном сборщике мусора, отсутсвие накопления ошибок со временем.
Кстати, и в вашей ява-системе можно было бы сэкономить на времени запуска, если бы не все данные загружались при запуске, а генерировались при первом обращении к ним, например, структура таблицы могла бы запрашиваться из БД только когда она нужна, и кешировться в памяти, а не в начале. примерно так я и стараюсь делать в php.
Также, я слышал, что в ява-фреймворках тоже часто доходят до дури, например огромные конфиги, описание всех полей всех таблиц в огромном XML-файле, причем там куча дублирующей информации, вроде [field name=author db_name=author… ] и так далее. У меня бы руки отвалились столько писать :(
Насчет php-скриптов, с удовольствием расскажу. Во-первых, код интерпретатора php довольно-таки оптимизирован, и он может парсить скрипты килобайтами за довольно-таки маленькое время (это, конечно, еще не повод писать огромные системы с тысячами классов). Во-вторых, в php нормальные люди стараются не писать полотнища кода и представлять каждую букву отдельным объектом :) Часто удобнее вместо объекта использовать массив, а они в php реализованы грамотно.
Кстати, строки и массивы в php реализованы со счетчиком ссылок и используют механизм write-on-copy, то есть, если вы пишете $a = array(… тут начальные значения… ); $b = $a;, то операция присваивания очень дешевая :) Вот если вы захотите изменить $b, тогда будет сделана копия $a и изменения в ней, то же самое со строками.
В-третьих, не знаю как в Яве, в php файлы и классы можно подключать динамически, только когда они нужны. В-четвертых, с php можно использовать кеши, вроде memcached или apc (он круче memcached тем, что использует shared memory — а значит, нет издержек на установление соединения с демоном, обратная сторона — он недоступен извне, только на 1 сервере)
В общем, что касается парсинга, есть расширение APC, хранящее пропарсенные скрипты (в виде байткода) на диске, или в shared memory. Это убирает издержки на компиляцию скриптов в байткод, хотя особого выигрыша не дает, всего раза в 2.
Насчет издержек на подключение к БД — можно использовать persistent connections, то есть соединения, не закрывающиеся между запусками скрипта, но тут есть риск, вдруг предыдущий скрипт например забыл закрыть транзакцию? или ввел БД в какое-нибудь невменяемое состояние?
Файлы конфигурации — честно говоря, не понимаю, чем вам нравится XML (абсолютно нечитаем для человека имхо), но я бы сделал так: при первом обращении к конфигу — читал бы и парсил XML, сохраняя данные в виде например сериализованного массива php в файле (или в кеше), при повторных обращениях — смотрел время модификации исходного файла и если он не обновился, брал бы кешированную версию, думаю кода тут на 20 строк. Собственно такую штуку я и реализовывал для описания полей моделей, только с YaML а не XML.
Повторное создание структур данных — мне как-то не приходилось работать с системами, которые бы генерировали какие-то огромные структуры данных, но думаю решение опять же в аккуратном использовании кеша.
Если уж на то пошло, постоянный перезапуск скрипта при каждом запросе имеет свои преимущества: отсутсвие необходимости в тормозном сборщике мусора, отсутсвие накопления ошибок со временем.
Кстати, и в вашей ява-системе можно было бы сэкономить на времени запуска, если бы не все данные загружались при запуске, а генерировались при первом обращении к ним, например, структура таблицы могла бы запрашиваться из БД только когда она нужна, и кешировться в памяти, а не в начале. примерно так я и стараюсь делать в php.
Также, я слышал, что в ява-фреймворках тоже часто доходят до дури, например огромные конфиги, описание всех полей всех таблиц в огромном XML-файле, причем там куча дублирующей информации, вроде [field name=author db_name=author… ] и так далее. У меня бы руки отвалились столько писать :(
А можно пожалуйста копипаст писем с датами? «Их шеф» вроде как я, и я ничего подобного не помню за все время развития системы.
отвечу в л.с.
Ответил. Привел ссылки на все Ваши тикеты — проверьте сами, есть ли хоть один не закрытый или с нерешенной проблемой (за исключением того, где написано, что такого функционала в текущей версии нет, ждите 3.0). Также проверил всю личную почту (включая листы рассылки) на письма от указанного Вами человека. Не нашел ничего, связанного с указанными Вами проблемами. Если я не там искал — напишите, буду искать дальше.
Какая мы оказывается отстойная компания. А будьте добры — когда (день и время) и на какой ящик скидывали багрепорт? А то никто из сотрудников таких багрепортов не помнит.
в вашу систему поддержки
Изменения в ядро вносятся позитивные, но! Почему! Почему до сих пор повальная практика использования register_globals! Кучи переменных! Полное отсутсвие наследования и появление новых багов от версии к версии. Причем в самых разных местах. Если нужно больше подробностей — в ЛС
Изменения в ядро вносятся позитивные, но! Почему! Почему до сих пор повальная практика использования register_globals! Кучи переменных! Полное отсутсвие наследования и появление новых багов от версии к версии. Причем в самых разных местах. Если нужно больше подробностей — в ЛС
В поддержку онлайн (с какого логина) или на support@ (с какого адреса)? Когда именно — хотя бы дата? Будучи нашим партнером, Вы публично обвиняете нас в довольно нелицеприятных вещах, и не приводите никаких доказательств. Это не очень красиво. Если Вы действительно обращались к нам и мы пропустили это обращение — давайте найдем, я публично прямо здесь принесу Вам и топикстартеру свои извинения. Речь не идет о форумном баге — да, он есть, и это наш косяк. Речь о том, что мы якобы игнорируем сообщения о дырах и вообще обращения партнеров.
Регистер_глобалс — причин много, одна из которых — совместимость с предыдущими версиями и гибкость инструментов разработчика. Пока мы не можем от этого отказаться, мы минимизируем тот и без того небольшой риск, который вызывает их использование. Подробнее спрашивайте Вадима в Хелпдеске или почте, он все расскажет.
Какое такое полное отсутствие наследования? Это вообще даже рядом не лежит с реальностью! Приведите пример, хотя бы один.
А в ЛС от Вас ничего нет.
Регистер_глобалс — причин много, одна из которых — совместимость с предыдущими версиями и гибкость инструментов разработчика. Пока мы не можем от этого отказаться, мы минимизируем тот и без того небольшой риск, который вызывает их использование. Подробнее спрашивайте Вадима в Хелпдеске или почте, он все расскажет.
Какое такое полное отсутствие наследования? Это вообще даже рядом не лежит с реальностью! Приведите пример, хотя бы один.
А в ЛС от Вас ничего нет.
отпишусь завтра, сейчас нет доступа к хелпдеску
Регистер_глобалс — можете привести те причины, из-за которых нельзя от него отказаться? Не вижу никакой гибкости, когда он включен
Небольшая поправка к моему предыдущему посту. От регистер_глобалс нельзя БЫЛО отказаться в старых версиях, сейчас эта проблема уже решена, включать совершенно не обязательно. И даже проблем с совместимостью нет.
Скажите, а полный отказ от extract($_NETCAT_INPUT); когда ждать можно?
системные переменные фильтруются перед этой строкой:
$_NETCAT_INPUT = $nc_core->input->prepare_extract();
потом уже:
extract($_NETCAT_INPUT);
В чём смысл от этого отказываться?
$_NETCAT_INPUT = $nc_core->input->prepare_extract();
потом уже:
extract($_NETCAT_INPUT);
В чём смысл от этого отказываться?
Допустим я хочу добавить системную переменнную? Или указать параметр в vars.inc.php. После вызова $nc_core->input->prepare_extract(); мне надо заново определять параметры.
Это не удобно, потому что в куче переменных очень работать сложно.
Это не удобно, потому что в куче переменных очень работать сложно.
Для каждой задачи можно найти альтернативное решение. Файл vars.inc.php — конфигурационный файл системы, пихать туда свои переменные уже не очень хорошо. Зачем делать то, от чего хотите уйти?
В нем содержится основные параметры системы. Логично было бы добавлять туда константы, которые отвечают за аналогичные параметры компонентов сторонних разработчиков.
К примеру, у меня в зависимости от параметров, установленных в vars.inc.php подключался (через include) модуль в файле functions.inc.php (модуль интерфейс разработчика). Выносить конфигурацию туда — не логично.
К примеру, у меня в зависимости от параметров, установленных в vars.inc.php подключался (через include) модуль в файле functions.inc.php (модуль интерфейс разработчика). Выносить конфигурацию туда — не логично.
> подключался (через include) модуль в файле functions.inc.php (модуль интерфейс разработчика)
этот модуль и так всегда загружается, объясните задачу подробнее.
этот модуль и так всегда загружается, объясните задачу подробнее.
Сейчас точно не вспомню, скорее всего обходной путь найти можно было. (Я был не вкурсе, что параметры в vars.inc.php добавлять нельзя, логично было бы об этом указать в документации). Если в этом файле находятся все подключаемые пути и пароли, то совершенно логично если там будут находиться аналогичные конфиги других компонентов.
Вопрос снят
Вопрос снят
Для констант хорошо подходит окружение системного модуля default.
Лол, да это же те же глобальные переменные, только по другому называются!
Не, серьезно, 2009 год, вы хоть программистам купите книжку про ООП что-ли, пусть почитают.
Не, серьезно, 2009 год, вы хоть программистам купите книжку про ООП что-ли, пусть почитают.
> Лол, да это же те же глобальные переменные, только по другому называются!
Принудительная регистрация переменных из суперглобальных request массивов и выборочная регистрация переменных из явно указываемых массивов — не одно и то же! Ваше высказывание — глупость.
Вот я совсем не против если мне начальство ещё каких нить книжек прикупать будет, много книжек не бывает!
Принудительная регистрация переменных из суперглобальных request массивов и выборочная регистрация переменных из явно указываемых массивов — не одно и то же! Ваше высказывание — глупость.
Вот я совсем не против если мне начальство ещё каких нить книжек прикупать будет, много книжек не бывает!
> Ваше высказывание — глупость.
Вот еще. Вам же хорошие советы тут даю, а вы сразу — глупость. Extract извлекает элементы массива в локальные/глобальные (видимо у вас этот случай) переменные. Какая разница, что вы их там фильтруете, глобальные переменные — это зло. И не потому что так какой-то дядя пишет в умной книжке, а потому что блин они никому по сути не принадлежат (никакому объекту, никакому компоненту); могут быть доступны из любого файла, любой точки кода (и их может поменять кто угодно, а ты об этом не узнаешь); потому что неизвестно, установлены они к этому моменту или нет, если нет — получаем варнинг undefined variable; неизвестно где искать их определение и присваивание значений; неизвестно, кто их поменял. В общем, увеличивают меру беспорядка и связность.
Несмотря на это, во всяких джумлах, викиджвижках и, как выясняется вашей CMS, они повсеместно используются, что ж очень жаль за такой низкий уровень разработки.
Вот еще. Вам же хорошие советы тут даю, а вы сразу — глупость. Extract извлекает элементы массива в локальные/глобальные (видимо у вас этот случай) переменные. Какая разница, что вы их там фильтруете, глобальные переменные — это зло. И не потому что так какой-то дядя пишет в умной книжке, а потому что блин они никому по сути не принадлежат (никакому объекту, никакому компоненту); могут быть доступны из любого файла, любой точки кода (и их может поменять кто угодно, а ты об этом не узнаешь); потому что неизвестно, установлены они к этому моменту или нет, если нет — получаем варнинг undefined variable; неизвестно где искать их определение и присваивание значений; неизвестно, кто их поменял. В общем, увеличивают меру беспорядка и связность.
Несмотря на это, во всяких джумлах, викиджвижках и, как выясняется вашей CMS, они повсеместно используются, что ж очень жаль за такой низкий уровень разработки.
По поводу наследования:
1) Модуль интернет-магазин. Как на одной копии системы создать магазины с разной логикой? Авторизация пользователей. Как для разных сайтов сделать разную форму для авторизации? Как туда, к примеру, добавить еще одно поле и проверять его при входе? — Лезть в исходники системы и править там. А с очередным обновлением все переписывать.
2) Компоненты. Есть формы добавления, условия, действия после добавления — все хорошо. Если, к примеру, мне нужно автоматически добавлять данные? Приходится выводить все действия в сторонние функции или использовать curl. Почему нельзя сделать Message->add(array) и чтобы в нем обрабатывались все действия. Почему для работы с компонентами до сих пор приходится использовать запорсы к базе данных а не перевести их на ORM.
3) Было бы очень удобно, если код компонентов вынесли из бд в локальные файлы. Работы тут немного, а плюсов — куча.
1) Модуль интернет-магазин. Как на одной копии системы создать магазины с разной логикой? Авторизация пользователей. Как для разных сайтов сделать разную форму для авторизации? Как туда, к примеру, добавить еще одно поле и проверять его при входе? — Лезть в исходники системы и править там. А с очередным обновлением все переписывать.
2) Компоненты. Есть формы добавления, условия, действия после добавления — все хорошо. Если, к примеру, мне нужно автоматически добавлять данные? Приходится выводить все действия в сторонние функции или использовать curl. Почему нельзя сделать Message->add(array) и чтобы в нем обрабатывались все действия. Почему для работы с компонентами до сих пор приходится использовать запорсы к базе данных а не перевести их на ORM.
3) Было бы очень удобно, если код компонентов вынесли из бд в локальные файлы. Работы тут немного, а плюсов — куча.
Люди, какой нафиг register_globals в 2009 году, какая еще гибкость инструментов разработчика?
Оно deprecated в PHP 5.3, а в PHP6 вообще отсутствует!
Оно deprecated в PHP 5.3, а в PHP6 вообще отсутствует!
ога, типа такой флешмоб устроили с хабры) интерактивный хабраэффект)
Еще одна хрень — ввожу капчу, нажимаю предпросмотр, после чего появляется новая капча.
уже вроде исправили
там страницы добавляются с ужасающей скоростью=)
Думаю, через пару часов форум надо будет разгребать бульдозером.
Или откатываться на бэкап (если владельцы догадаются).
Хабраэффект, однако.
Или откатываться на бэкап (если владельцы догадаются).
Хабраэффект, однако.
а авторы сего чуда на хабре есть? а то чего то карму задели…
Решение проблемы от разработчиков просто гениальное.
Закрыли форум для гостей :)))
Закрыли форум для гостей :)))
Эх, только хотел 3-ее сообщение написать, тут доступ прикрыли — просят теперь авторизоваться :)
все, закрыли))
Закрыли форум =(
Редкая фирма понимает зачем ей форум и готова достойно выдержать поток обратной связи с форума. Поэтому это практически во всех CMS форум сильно остает в развитии.
Пользуясь случаем, принимаю заказы на интеграцию чего угодно доморощенного с vbulletin.
Пользуясь случаем, принимаю заказы на интеграцию чего угодно доморощенного с vbulletin.
Закрыли. Как бы сейчас не начался тотальный брут (А вдруг и в форме авторизации баги) =)
Зато открыта вакансия веб-разработчика!
Символично над полями входа на форум, смотрится «В компании АИСТ (разработчик NetCat) открыта вакансия веб-разработчика.»
Зато все кто хотел, успел понякать нахаляву (8
его наверное бегом уволили)))
Кого-то уже уволили :)
зато на сайте есть список их клиентов www.aist.ru/projects/clients/
можно поискать и там форумы от аиста :)
можно поискать и там форумы от аиста :)
Обычно кнопка «Ответ» для незареганных пользователей отключена или нет?
netcat.ru/search/?&action=index&text=%5C%5C%5C'%5C%5C%5C%22%60--%3E%EE&curPos=180&action=index
прикол в том, что пока вы гнобите здесь неткат — они зарабатывают деньги, причем не плохие
так что хватит разглагольствовать и умничать — все гоу работать и богатеть :)
так что хватит разглагольствовать и умничать — все гоу работать и богатеть :)
kammarket.ru нашел в примерах сайтов… лисичка жалуется, что этот сайт атакует компьютеры…
Не доверяю я цмскам где обязательное ртебование register_globala = On и в шаблонах идут инлайново запросы к бд и тд и тп
Вопрос автору. Вы пытались надавить на неткатовцев в том ключе, что мы, мол, деньги за систему заплатили, а тут такое. Грозились в суд подать за некачественный продукт?
Да. Но никаких исправлений нет. А каждй раз пробегаться по исходникоам после установки обновления надоедает.
В суд подавать не грозились.По лицензионному соглашению мы не имеем смотреть исходники и изменять их.
В суд подавать не грозились.По лицензионному соглашению мы не имеем смотреть исходники и изменять их.
вы вроде не автор…
Что касается лицензионного соглашения, то можно найти обходной путь — пожаловаться, что на форуме стали появляться левые сообщения, которые зарегистрированные пользователи точно не писали. И потребовать техподдержу решить проблему. Как такой вариант?
>>По лицензионному соглашению мы не имеем смотреть исходники и изменять их.
жесть
жесть
А кому-то из покупателей ПО это удавалось вообще?
NetCatПоддержкаФорум
Форум
* В компании АИСТ (разработчик NetCat) открыта вакансия веб-разработчика.
Форум
* В компании АИСТ (разработчик NetCat) открыта вакансия веб-разработчика.
Ну надо же. Статья была о баге в NetCat а стала о багах в Bitrix :D Мне как то кажется что это сделал сам NetCat, чтобы отвести разговоры на другую тему. Все тотчас забыли про NetCat и стали о Bitrix спорить :D
Пришлось как то работать в далеком 2006 году работать в компании, которая занималась продвижением сайтов на неткате, кхм, столько примитивных дыр я не видел нигде. Долго общался в итоге был ответ: «у нас все данные проверяются eval()» так что дыр быть не может. После этого желание чего то от них добится пропало.
А как можно данные проверять с помощью eval по секрету раскажите?
И мне тоже :) Заодно и про «столько примитивных дыр»
Это к разработчикам Netcat — их официальный ответ ;)
Мне кажется, Вы что-то напутали с формулировкой. У нас конечно было время, когда в отделе разработки работали один-два не очень сильных разработчика, но такое вряд ли могли сказать даже они.
Невероятно, но факт такое было сказано ;) Если я не ошибаюсь это даже в тикетах было.
А вспоминать у меня нет желания, так как воды утекло многовато. В текущих версиях может все интересней обстоит. Но на том момент было печально весьма.
Если вы или ваши сотрудники на тот момент не смогли найти эти ошибки, это не означает что их нет.
А вот ответ про eval() был помоему даже в тикетах, если память не изменяет.
А вспоминать у меня нет желания, так как воды утекло многовато. В текущих версиях может все интересней обстоит. Но на том момент было печально весьма.
Если вы или ваши сотрудники на тот момент не смогли найти эти ошибки, это не означает что их нет.
А вот ответ про eval() был помоему даже в тикетах, если память не изменяет.
> Если в ближайшее время появится патч, можно считать что я добился того, что хотел, публикуя эту статью.
А как связано то, чего Вы добивались, с выходом патча? Когда хотят добиться патча, обычно пишут не на Хабр, а разработчику — и получают и патч, и благодарности. А когда пишут на Хабр, а не разработчикам — добиваются поднятия кармы. Ну и, возможно, проблем разработчикам, пользователям и пр. Это я к тому, что ни в последний год, ни ранее нам ни о чем похожем не сообщали.
Господа, которые пишут про то, что кучу раз сообщали о куче багов и на них не реагировали — большая просьба примеры в студию — когда, на какой адрес писали, что вам ответили. У меня есть архив всех официальных ящиков NetCat, по каждому примеру отвечу. Иначе пишите уж, что предупреждали Белый Дом за год до 11 сентября. Повод высказаться покруче, а достоверность та же.
А как связано то, чего Вы добивались, с выходом патча? Когда хотят добиться патча, обычно пишут не на Хабр, а разработчику — и получают и патч, и благодарности. А когда пишут на Хабр, а не разработчикам — добиваются поднятия кармы. Ну и, возможно, проблем разработчикам, пользователям и пр. Это я к тому, что ни в последний год, ни ранее нам ни о чем похожем не сообщали.
Господа, которые пишут про то, что кучу раз сообщали о куче багов и на них не реагировали — большая просьба примеры в студию — когда, на какой адрес писали, что вам ответили. У меня есть архив всех официальных ящиков NetCat, по каждому примеру отвечу. Иначе пишите уж, что предупреждали Белый Дом за год до 11 сентября. Повод высказаться покруче, а достоверность та же.
А зачем им это?
Надо же показать что ты крут — взяли разработчикам «насрали».
Я не за Netcat — я против вот такого вандализма.
Надо же показать что ты крут — взяли разработчикам «насрали».
Я не за Netcat — я против вот такого вандализма.
если вы вы внимательно читали комменты, то автор топика не раз обращался к разработчикам. а им по…
поэтому такой «вандализм» я считаю приемлемым
поэтому такой «вандализм» я считаю приемлемым
habrahabr.ru/blogs/code_wtf/65121/#comment_1820869
Пускай автор в таком случае выложит тикет который посылал, во всех системах они пронумерованы.
Пускай автор в таком случае выложит тикет который посылал, во всех системах они пронумерованы.
Если Вы внимательно читали мой ответ, то автор топика НЕ ОБРАЩАЛСЯ к разработчикам по этому поводу. По другим — обращался и не раз, у нас к нему претензий нет, только благодарности. Вам сначала неплохо было бы разобраться в проблеме, выслушать как минимум две стороны, а уж потом что-то считать или не считать.
ребята! С последнего топика на хабре год прошел! никаких глобальных изменение в коде я за это время не заметил. Кое-что подправили, да. Много ужасных моментов повыкидывали. Но все равно продолжаете писать в том же стиле:
— куча переменных
— куча функций
— везде, где можно изобретаете свой велосипед
как результат каша в коде и множество ошибок
Я не против помогать вам в развитии проекта! но если развитие пойдет на устранение этих недостатков и превращение системы в хорошую удобную и масштабируемую cms.
Что лично от нетката хочу увидеть после этого топика я (что и послужило причиной его написания):
1) Быстрого исправления ошибок и выхода патчей
2) ГРАМОТНЫЙ КОД в котором легко разбираться. Сейчас это практически невозможно сделать
3) Нормальную архитектуру, наследование, выключение register_globals, ORM (компоненты, разделы)
4) UTF-8
Сейчас же для любого проекта, кроме сайтов-визиток, вашу систему использовать очень тяжело. Из-за того, что в ней достаточно много мест, которые меняют логику своей работы от версии к версии (это правильно, но желательно описывать это в Readme, что с данной версии вывод раздела с несколькими компонентами работает чуть-чуть по-другому) и невозможности модификации тех частей системы, которых нет в админке для сложных сайтов обноления недоступны.
По поводу модулей — из-за того, что у вас нет никакого подобия наследования ни один сайт, где они используется обновить нереально — перезаписывается весь код модулей, а правки каждый раз вносить достаточно неудобно
— куча переменных
— куча функций
— везде, где можно изобретаете свой велосипед
как результат каша в коде и множество ошибок
Я не против помогать вам в развитии проекта! но если развитие пойдет на устранение этих недостатков и превращение системы в хорошую удобную и масштабируемую cms.
Что лично от нетката хочу увидеть после этого топика я (что и послужило причиной его написания):
1) Быстрого исправления ошибок и выхода патчей
2) ГРАМОТНЫЙ КОД в котором легко разбираться. Сейчас это практически невозможно сделать
3) Нормальную архитектуру, наследование, выключение register_globals, ORM (компоненты, разделы)
4) UTF-8
Сейчас же для любого проекта, кроме сайтов-визиток, вашу систему использовать очень тяжело. Из-за того, что в ней достаточно много мест, которые меняют логику своей работы от версии к версии (это правильно, но желательно описывать это в Readme, что с данной версии вывод раздела с несколькими компонентами работает чуть-чуть по-другому) и невозможности модификации тех частей системы, которых нет в админке для сложных сайтов обноления недоступны.
По поводу модулей — из-за того, что у вас нет никакого подобия наследования ни один сайт, где они используется обновить нереально — перезаписывается весь код модулей, а правки каждый раз вносить достаточно неудобно
О. Вот это уже по делу, хотя не все ИМХО справедливо. Я сейчас в отпуске, у меня разряжается ноут, поэтому постараюсь развернуто ответить завтра. А вот вопрос относительно того, что нам якобы сообщалось о каких-либо багах, а мы игнорировали, остается открытым. Извините за занудство, но для меня этот вопрос принципиален.
Вот Вы считаете, что изменений глобальных нет, а нам кажется, что мы много сделали в области рефакторинга. По крайней мере, не сравнить с теми темпами, которые были раньше. По переменным, функциям и велосипедам — ну и как я могу ответить на это? Куча переменных и функций — это плохо? Велосипеды — например?
Исправление ошибок — происходит по мере их поступления и критичности. Критичные вещи исправляются тут же, непринципиальные дольше. По дыре в форуме я высказался ниже.
Грамотный код — см. выше, рефакторинг происходит, весь новый код и та часть старого, которая переписывается, имхо очень даже читабельна.
Архитектура, регистер_глобалс, объекты — ответил выше.
ЮТФ — в списке первых приоритетов, будет в 4.0.
Визитки — сейчас очень много нестандартных проектов, которые делаются нашими партнерами. Возможно, иногда кажется, что для решения нестандартных задач надо править код ядра/модулей, но в большинстве случаев это не так. Давайте попробуем вот как. По любой такой задаче пишите в саппорт и дублируйте мне в почту номер тикета. Вот как только получите ответ «надо править исходники» — так и поднимем эту проблему. Только условие — примеры должны быть реальные, а не выдуманные.
Исправление ошибок — происходит по мере их поступления и критичности. Критичные вещи исправляются тут же, непринципиальные дольше. По дыре в форуме я высказался ниже.
Грамотный код — см. выше, рефакторинг происходит, весь новый код и та часть старого, которая переписывается, имхо очень даже читабельна.
Архитектура, регистер_глобалс, объекты — ответил выше.
ЮТФ — в списке первых приоритетов, будет в 4.0.
Визитки — сейчас очень много нестандартных проектов, которые делаются нашими партнерами. Возможно, иногда кажется, что для решения нестандартных задач надо править код ядра/модулей, но в большинстве случаев это не так. Давайте попробуем вот как. По любой такой задаче пишите в саппорт и дублируйте мне в почту номер тикета. Вот как только получите ответ «надо править исходники» — так и поднимем эту проблему. Только условие — примеры должны быть реальные, а не выдуманные.
По вашему новому коду смотрю — он действительно намного читабельнее и лучше предыдущего (папка system). Вопрос снят.
А вот где пришлось править исходники:
1) Перенаправление запросов. Т.е. если входная строка соответствует некоторым параметрам (необходимость в запросах к базе есть, т.е. через mod_rewrite не получается) — выводим ту же самую страницу, что открывается по ссылке /news/news1.html (короткие ссылки на новости). Если нет — то 404 страница.
2) Хочу повесить некоторые действия на событие, когда пользователь заходит на сайт. Замечу, что код модуля достаточно часто обновляется. Но без правки исходников сделать этого я не могу.
А вот где пришлось править исходники:
1) Перенаправление запросов. Т.е. если входная строка соответствует некоторым параметрам (необходимость в запросах к базе есть, т.е. через mod_rewrite не получается) — выводим ту же самую страницу, что открывается по ссылке /news/news1.html (короткие ссылки на новости). Если нет — то 404 страница.
2) Хочу повесить некоторые действия на событие, когда пользователь заходит на сайт. Замечу, что код модуля достаточно часто обновляется. Но без правки исходников сделать этого я не могу.
1. Роутинг будет обязательно, новое API позволяет это реализовать в ближайшее время;
2. Система событий уже есть в системе, пока не документирована т.к. тестируется. Есть события на добавление, редактирование, удаление сообщений и прочих сущностей, в т.ч. и пользователя. Мы не топчемся на месте, стараемся развиваться, но на всё нужно время.
2. Система событий уже есть в системе, пока не документирована т.к. тестируется. Есть события на добавление, редактирование, удаление сообщений и прочих сущностей, в т.ч. и пользователя. Мы не топчемся на месте, стараемся развиваться, но на всё нужно время.
Спасибо. Вопросы сняты.
Прокомментируйте пожалуйста habrahabr.ru/blogs/code_wtf/65121/#comment_1821044 (2,3)
Прокомментируйте пожалуйста habrahabr.ru/blogs/code_wtf/65121/#comment_1821044 (2,3)
> 2)… Почему нельзя сделать Message->add(array) и чтобы в нем обрабатывались все действия. Почему для работы с компонентами до сих пор приходится использовать запорсы к базе данных а не перевести их на ORM.
То, что лежит в директории /netcat/system/ как раз для того и делалось. Для начала переписали базовый функционал получения данных, т.к. это даёт больше прироста производительности, в дальнейшем классы расширятся. В той же директории есть папка essences, в ней есть файл nc_message.class.php, функционал добавления сообщений появится в нём, по срокам ничего не буду говорить, т.к. это не ко мне. Выходит, что мы думаем об одном и том же)
> 3) Было бы очень удобно, если код компонентов вынесли из бд в локальные файлы. Работы тут немного, а плюсов — куча.
Тут спорный вопрос, файлы или БД — почти холивар. Уж точно не предмет первой необходимости.
То, что лежит в директории /netcat/system/ как раз для того и делалось. Для начала переписали базовый функционал получения данных, т.к. это даёт больше прироста производительности, в дальнейшем классы расширятся. В той же директории есть папка essences, в ней есть файл nc_message.class.php, функционал добавления сообщений появится в нём, по срокам ничего не буду говорить, т.к. это не ко мне. Выходит, что мы думаем об одном и том же)
> 3) Было бы очень удобно, если код компонентов вынесли из бд в локальные файлы. Работы тут немного, а плюсов — куча.
Тут спорный вопрос, файлы или БД — почти холивар. Уж точно не предмет первой необходимости.
Согласен. но тогда можно полностью отказаться от extract(). Ведь намного проще:
Тогда можно отказаться от eval, использовать нормальные редакторы
нельзя ли для extract
function process_template() {
extract(); // выводим переменные в область видимости функции!
include (Message.php) // Подключаем вывод компонента
}
Тогда можно отказаться от eval, использовать нормальные редакторы
нельзя ли для extract
нельзя ли extract заменить на
extract ( $var_array, EXTR_SKIP )?
extract ( $var_array, EXTR_SKIP )?
> Куча переменных и функций — это плохо?
Конечно, плохо. Часто (то есть в 95% случаев) данные и методы их обработки можно надежно убрать в объект. это имеет свои преимущества, например возможность безболезненного расширения функционала за счет наследования, возможность скрытия внутренненго устройства объекта.
Вот кто-то выше привел пример:
> $_NETCAT_INPUT = $nc_core->input->prepare_extract();
> extract($_NETCAT_INPUT);
Вы что, не можете сделать для входных перемнных класс вроде HttpRequest, как во всех приличных фреймворках и передать дальше? не загрязняя область глоб. переменных? Поверьте. так намного удобнее. Это же не код, а лапша какая-то, что тут написано. так уже лет 10 никто не пишет, да и не писал никогда ни один нормальный разработчик.
Это как джумла или друпал, люди толком не разобрались, как делаются большие системы, и пошли лепить как придется. Слава богу, мне под эти системы писать не приходится :))
Конечно, плохо. Часто (то есть в 95% случаев) данные и методы их обработки можно надежно убрать в объект. это имеет свои преимущества, например возможность безболезненного расширения функционала за счет наследования, возможность скрытия внутренненго устройства объекта.
Вот кто-то выше привел пример:
> $_NETCAT_INPUT = $nc_core->input->prepare_extract();
> extract($_NETCAT_INPUT);
Вы что, не можете сделать для входных перемнных класс вроде HttpRequest, как во всех приличных фреймворках и передать дальше? не загрязняя область глоб. переменных? Поверьте. так намного удобнее. Это же не код, а лапша какая-то, что тут написано. так уже лет 10 никто не пишет, да и не писал никогда ни один нормальный разработчик.
Это как джумла или друпал, люди толком не разобрались, как делаются большие системы, и пошли лепить как придется. Слава богу, мне под эти системы писать не приходится :))
> Часто (то есть в 95% случаев) данные и методы их обработки можно надежно убрать в объект.
Убираются, и весьма успешно. Вот только писать с нуля и переделывать систему которой 10 лет — не одно и то же. Совместимость должна остаться, попробуйте сначала решить такую задачу.
> Вы что, не можете сделать для входных перемнных класс вроде HttpRequest, как во всех приличных фреймворках и передать дальше? не загрязняя область глоб. переменных? Поверьте. так намного удобнее. Это же не код, а лапша какая-то, что тут написано. так уже лет 10 никто не пишет, да и не писал никогда ни один нормальный разработчик.
Как интересно, прочитав две строчки кода, уже советуете какие классы написать и как их использовать. Видимо впечатляющий опыт рефакторинга за плечами сказывается!
> Это как джумла или друпал, люди толком не разобрались, как делаются большие системы, и пошли лепить как придется.
Это всего лишь предположение.
Убираются, и весьма успешно. Вот только писать с нуля и переделывать систему которой 10 лет — не одно и то же. Совместимость должна остаться, попробуйте сначала решить такую задачу.
> Вы что, не можете сделать для входных перемнных класс вроде HttpRequest, как во всех приличных фреймворках и передать дальше? не загрязняя область глоб. переменных? Поверьте. так намного удобнее. Это же не код, а лапша какая-то, что тут написано. так уже лет 10 никто не пишет, да и не писал никогда ни один нормальный разработчик.
Как интересно, прочитав две строчки кода, уже советуете какие классы написать и как их использовать. Видимо впечатляющий опыт рефакторинга за плечами сказывается!
> Это как джумла или друпал, люди толком не разобрались, как делаются большие системы, и пошли лепить как придется.
Это всего лишь предположение.
> Вот только писать с нуля и переделывать систему которой 10 лет — не одно и то же. Совместимость должна остаться, попробуйте сначала решить такую задачу.
Согласен, переписывать кучу кода и модулей никому неохота. это в принципе вменяемое оправдание. Но я вас разочарую, все равно до бесконечности тянуть не получится. Если используется неправильная архитектура, по мере увеличения объема кода будет вылезать все больше багов.
Плюс есть человеческий фактор. С плохо написанным кодом постепенно полностью пропадает желание работать, полгода, максимум год — и программист сойдет с ума (горький опыт :) ).
> Как интересно, прочитав две строчки кода, уже советуете какие классы написать и как их использовать. Видимо впечатляющий опыт рефакторинга за плечами сказывается!
У меня относительно небольшой опыт работа с пхп, но на код я успел насмотреться всякий. Что касается 2 строчек, я же прекрасно себе представляю, зачем их написали (чтобы оставить глоб. переменные, только теперь их профильтровывают через функцию), и куда они дальше идут. Еще раз говорю, вам это плохой и бесперспективный код, все равно его придется рано или поздно выкинуть. И написать так, как я сказал :) Ну или свой велосипед изобретать и мучаться с проблемами разными.
Согласен, переписывать кучу кода и модулей никому неохота. это в принципе вменяемое оправдание. Но я вас разочарую, все равно до бесконечности тянуть не получится. Если используется неправильная архитектура, по мере увеличения объема кода будет вылезать все больше багов.
Плюс есть человеческий фактор. С плохо написанным кодом постепенно полностью пропадает желание работать, полгода, максимум год — и программист сойдет с ума (горький опыт :) ).
> Как интересно, прочитав две строчки кода, уже советуете какие классы написать и как их использовать. Видимо впечатляющий опыт рефакторинга за плечами сказывается!
У меня относительно небольшой опыт работа с пхп, но на код я успел насмотреться всякий. Что касается 2 строчек, я же прекрасно себе представляю, зачем их написали (чтобы оставить глоб. переменные, только теперь их профильтровывают через функцию), и куда они дальше идут. Еще раз говорю, вам это плохой и бесперспективный код, все равно его придется рано или поздно выкинуть. И написать так, как я сказал :) Ну или свой велосипед изобретать и мучаться с проблемами разными.
> Плюс есть человеческий фактор. С плохо написанным кодом постепенно полностью пропадает желание работать, полгода, максимум год — и программист сойдет с ума (горький опыт :) ).
Мне, как программисту, очень интересно решать задачи, которые не каждый решать возьмётся. Может это и IT-мазохизм, но для меня это интересно. Решать задачки по книжке конечно круто, радоваться потом какой умный ход и т.п., но в реальности задачи бывают намного жёстче.
Конечно, когда не можешь найти решение — проще всего всё бросить, плюнуть и говорить какой нехороший код, но когда можешь — хочется работать и улучшать.
> У меня относительно небольшой опыт работа с пхп, но на код я успел насмотреться всякий. Что касается 2 строчек, я же прекрасно себе представляю, зачем их написали (чтобы оставить глоб. переменные, только теперь их профильтровывают через функцию), и куда они дальше идут. Еще раз говорю, вам это плохой и бесперспективный код, все равно его придется рано или поздно выкинуть. И написать так, как я сказал :) Ну или свой велосипед изобретать и мучаться с проблемами разными.
ИМХО — недальновидный бред!
Мне, как программисту, очень интересно решать задачи, которые не каждый решать возьмётся. Может это и IT-мазохизм, но для меня это интересно. Решать задачки по книжке конечно круто, радоваться потом какой умный ход и т.п., но в реальности задачи бывают намного жёстче.
Конечно, когда не можешь найти решение — проще всего всё бросить, плюнуть и говорить какой нехороший код, но когда можешь — хочется работать и улучшать.
> У меня относительно небольшой опыт работа с пхп, но на код я успел насмотреться всякий. Что касается 2 строчек, я же прекрасно себе представляю, зачем их написали (чтобы оставить глоб. переменные, только теперь их профильтровывают через функцию), и куда они дальше идут. Еще раз говорю, вам это плохой и бесперспективный код, все равно его придется рано или поздно выкинуть. И написать так, как я сказал :) Ну или свой велосипед изобретать и мучаться с проблемами разными.
ИМХО — недальновидный бред!
Когда хотят добиться патча, обычно пишут не на Хабр, а разработчику — и получают и патч, и благодарности.Это необычный случай. Разработчикам пофиг.
Господа, которые пишут про то, что кучу раз сообщали о куче багов и на них не реагировали — большая просьба примеры в студию — когда, на какой адрес писали, что вам ответили.В тикеты системы поддержки партнерского аккаунта. Если у вас есть доступ в нее (уверен, что есть), то вот:
netcat.ru/forclients/helpdesk/helpdesk_12091.html
Сообщения от 2008-07. Все снабжены патчами! В конце было сказано:
Ваши багрепорты впечатляют, часть вопросов уже была решена ранее, кое-что вносим в список багов, ожидающих правки. в любом случае спасибо за Вашу активность. Свою активность мы проявим при следующих обновлениях ;)
После чего 2009-01-09 мы еще раз напомнили и был ответ:
В скором времени: январе-феврале выйдет совершенно новый модуль форума
Еще очень прошу вас, обратите внимание всех всих кодеров вот на этот тикет:
netcat.ru/forclients/helpdesk/helpdesk_18603.html
Собственно к написанию этого топика мы с коллегой пришли после того, как пришла пора ставить форум на очередной проект. Ковыряться в нем опять нет желания не у него не у меня, стали думать как вы вам напомнить об обещаниях.
Нам тоже очень не приятно, что приходится общаться так, другими доступными средствами у нас с вами как-то не получается.
1. Ждем ответа Дмитрия.
2. Вы могли бы точно таким же способом, но только без Хабра, напомнить о данном баге — эффект, я думаю, был бы тот же.
2. Вы могли бы точно таким же способом, но только без Хабра, напомнить о данном баге — эффект, я думаю, был бы тот же.
Я что-то решил даже выложить текст тикета netcat.ru/forclients/helpdesk/helpdesk_18603.html от 2009-03-19 сюда и спросить при свидетелях, аудит кода системы и стандартных компонентов будет?
Мы в очередной раз купили ваш замечательный продукт, который к счастью хоть и постепенно становиться лучше от версии к версии, но всеже далек от идеала. Количество говнокода зашкаливает. Я хочу чтобы вы прислушались к советам по написанию качественного кода, которые я хочу дать.
Рассмотрим для примера «Суффикс списка объектов» для поставляемого с системой компонента «Публикации: Новости компании»
".opt( !$nc_title,
opt($totRows>$f_RowNum && $cc_settings[ListingStyle]=='fixed', "<div class='nc_pagination'>Страницы: ".browse_messages($cc_env, 5)."</div>" ).
opt($totRows && $cc_settings[ListingStyle]=='day', "Архив по дням: ".listQuery("SELECT DATE_FORMAT(Date,'%Y') AS year, DATE_FORMAT(Date,'%m') AS month, DATE_FORMAT(Date,'%d') AS day FROM Message$classID WHERE Subdivision_ID=$sub AND Sub_Class_ID=$cc AND DATE_FORMAT(Date,'%Y%m')='$year$month' GROUP BY DATE_FORMAT(Date,'%d') ORDER BY Date", '".($i?" | ":NULL).($data[day]=='.$day.'?$data[day]:"<a href='.$SUB_FOLDER.$current_sub[Hidden_URL].'$data[year]/$data[month]/$data[day]/>$data[day]</a>")."' )).
opt($totRows && $cc_settings[ListingStyle]=='month', "Архив по месяцам: ".listQuery("SELECT DATE_FORMAT(Date,'%Y') AS year, DATE_FORMAT(Date,'%m') AS month FROM Message$classID WHERE Subdivision_ID=$sub AND Sub_Class_ID=$cc AND DATE_FORMAT(Date,'%Y')='$year' GROUP BY DATE_FORMAT(Date,'%m') ORDER BY Date", '".($i?" | ":NULL).($data[month]=='.$month.'?$data[month]:"<a href='.$SUB_FOLDER.$current_sub[Hidden_URL].'$data[year]/$data[month]/>$data[month]</a>")."' )).
opt($totRows && $cc_settings[ListingStyle]=='year', "Архив по годам: ".listQuery("SELECT DATE_FORMAT(Date,'%Y') AS year FROM Message$classID WHERE Subdivision_ID=$sub AND Sub_Class_ID=$cc GROUP BY DATE_FORMAT(Date,'%Y') ORDER BY Date", '".($i?" | ":NULL).($data[year]=='.$year.'?$data[year]:"<a href='.$SUB_FOLDER.$current_sub[Hidden_URL].'$data[year]/>$data[year]</a>")."' ))
)."
Первое и самое главное — вы используете чудо-юдо функцию opt вместо языковой конструкции (condition? "": ""). Чем это чревато? Дело в том, что opt, является определенной пользовательской функцией, а функции, как известно принимают параметры. Дело в том, что php не может на этапе вызова функции определить, какие параметры будут в ней использоваться, поэтому для вызова функции, вычисляются все указанные параметры. Т.е. когда вы пишете opt( $error, die() ), то перед тем как выполнится opt, будет выполнен второй аргумент и скрипт закончит свое выполнение вне зависимости значения $error. В приведенном примере это означает, что для вывода каждой страницы, где используется этот компонент будут выполнены 3 очень таких не хилых SQL запроса, с группировочкой там, с преобразованием дат, в то время как если определена переменная $nc_title, ни один из них вообще не пригодится. Это товарищи, просто <мат>.
Второе — Вы везде и всюду используете запись $current_sub[Hidden_URL] вместо $current_sub['Hidden_URL']. Дело в том, что такая запись медленнее обрабатывается, причем значительно. И это помимо того, что в принципе-то это совершенно разные записи. В чем же тут дело? А дело в том, что в PHP ключами массива могут быть только строки и числе. PHP считает Hidden_URL без кавычек константой, и при встрече такой конструкции проверяет глобальный пул констант на наличие там таковой. Если такая константа не найдена — он делает некое послабление и расценивает Hidden_URL как строку, благодаря чему, к сожалению, у вас все работает. На самом деле если определить Hidden_URL как константу через define (скажем 666), то запись $current_sub[Hidden_URL] будет равнозначна $current_sub[666] и будет не равнозначна $current_sub['Hidden_URL'].
Третье. Вы любите вставлять переменные в строки. Это не плохо. Но как вы это делаете — не могу смотреть без слез. Ну нельзя же не экранировать переменную. Пишите вот так: «бла бла {$f_Title}бла бла», не пишите так: «бла бла $f_Titleбла бла», когданибудь вы так нарветесь на неприятности, если не натыкались уже сотню раз. Апофеоз этого беспредела — "$f_Title" — переменная, заключенная в строку, где кроме нее ничего и нет больше.
«Мы в очередной раз купили ваш замечательный продукт» — извиняюсь, а зачем покупаете-то, если знаете что и как глючит и тем более как это исправить? Ну это так, риторический вопрос.
О_0 это полотно напрочь выносит мозг. Вероятность не заметить тут ошибку приближается к 100%. Как же я рад, как же я рад!!, что я не работаю с этой системой, вы не представляете!!!
> Второе — Вы везде и всюду используете запись $current_sub[Hidden_URL] вместо $current_sub['Hidden_URL'].
Более того, использование такой штуки дает нотис или варнинг, что загрязнает лог и мешает искать там полезные сообщения. Правда, внутри 2-ных кавычек это не вызывает проблем, и одобрено мануалом, так как там констант быть не может.
Ну и использлвание переменных прямо в SQL-запросе чревато потенциальной возможностью SQL-инъекции. А использование переменных прямо в выводимой строке (ну где там "....[a href=$variable...") — потенциальной возможностью XSS-уязвимости :))
Ох люди, пользуйтесь лучше чужими фреймворками если свой напистаь нормально не можете.
> Второе — Вы везде и всюду используете запись $current_sub[Hidden_URL] вместо $current_sub['Hidden_URL'].
Более того, использование такой штуки дает нотис или варнинг, что загрязнает лог и мешает искать там полезные сообщения. Правда, внутри 2-ных кавычек это не вызывает проблем, и одобрено мануалом, так как там констант быть не может.
Ну и использлвание переменных прямо в SQL-запросе чревато потенциальной возможностью SQL-инъекции. А использование переменных прямо в выводимой строке (ну где там "....[a href=$variable...") — потенциальной возможностью XSS-уязвимости :))
Ох люди, пользуйтесь лучше чужими фреймворками если свой напистаь нормально не можете.
Гм. Терпеть не могу такие моменты. Этот тикет я пропустил, потому что он начинался с другого вопроса. Да, вы действительно сообщали в саппорт о дыре и в начале года напоминали о ней. Прошу прощения у хабраюзеров Homm и Nex за выбранный мной тон в предыдущих ответах, я был не прав. И хотя я бы не стал напоминать о ней в таком формате (есть и другие способы, например, в партнерском разделе есть мои контакты; есть дилерский форум), но продолжать эту тему не буду. На будущее — если Вы видите косяк со стороны сотрудников поддержки, пишите пожалуйста мне. По крайней мере, не пострадают невиновные люди, то есть пользователи и партнеры.
Попробую пояснить для остальных читателей ситуацию. Этот тикет вел с нашей стороны человек, который сейчас у нас уже не работает. Вел не очень хорошо, судя как минимум по времени реакции и игнорированию этого бага. Спросить с него сейчас я уже не могу. С сотрудником, который Вам ответил про январь-февраль, я буду разговаривать в понедельник, когда вернусь из отпуска, по итогам я Вам напишу. Мы действительно планировали выпустить модуль в эти сроки, но кризис заставил нас поменять приоритеты. Почему он не сообщил руководителю разработки о проблеме сразу или после изменения планов по выпуску нового модуля — это очень серьезный вопрос к нему.
Второй топик принят.
Попробую пояснить для остальных читателей ситуацию. Этот тикет вел с нашей стороны человек, который сейчас у нас уже не работает. Вел не очень хорошо, судя как минимум по времени реакции и игнорированию этого бага. Спросить с него сейчас я уже не могу. С сотрудником, который Вам ответил про январь-февраль, я буду разговаривать в понедельник, когда вернусь из отпуска, по итогам я Вам напишу. Мы действительно планировали выпустить модуль в эти сроки, но кризис заставил нас поменять приоритеты. Почему он не сообщил руководителю разработки о проблеме сразу или после изменения планов по выпуску нового модуля — это очень серьезный вопрос к нему.
Второй топик принят.
Да проще код посмотреть: с первого взгляда видно, что писали ногами.
$NETCAT_FOLDER = join( strstr(__FILE__, "/")? "/": "\\", array_slice( preg_split("/[\/\\\]+/", __FILE__), 0, -1 ) ).( strstr(__FILE__, "/")? "/": "\\" );
$NETCAT_FOLDER = join( strstr(__FILE__, "/")? "/": "\\", array_slice( preg_split("/[\/\\\]+/", __FILE__), 0, -1 ) ).( strstr(__FILE__, "/")? "/": "\\" );
Баг достаточно серьезный в плане последствий, уже наверняка расползся по интернету, а вот на партнерском форуме информации о нем нет. Также нет информации на официальном форуме, не поступало по электронной почте информации о баге партнерам… Оповещать широкую публику дополнительно к этой публикации конечно не стоит, но все-таки партнеры должны это знать. Мы же отвечаем за сайты клиентов.
Автор этого сообщения довольно сильно подставил разработчиков сайтов на базе Net Cat, выложив step-by-step guide для юных «хакеров».
Вопрос: а зачем? чем виноваты люди, которые внедряют Net Cat? теперь им тоже придется принимать какие-то меры…
Уверен, что уже сейчас толпа троллей бороздит просторы Гугла в поисках сайтов на Net Cat…
Убытки понесут в первую очередь студии и фрилансеры, которые внедряли эту CMS на сайт заказчика, ведь именно к ним будут претензии.
Считаю, что таким сообщения место на каком-нибудь xakep.ru, а не здесь.
Если не нравится долгая реакция официального Net Cata на информацию о баге — смените CMS, выберите другую, их ведь полно.
А вы для решения проблем использовали «сталинский» метод, совсем не задумываясь о последствиях для рядовых пользователей и разработчиков.
P.S. Никакого отношения к данной системе (NetСat) не имею.
Вопрос: а зачем? чем виноваты люди, которые внедряют Net Cat? теперь им тоже придется принимать какие-то меры…
Уверен, что уже сейчас толпа троллей бороздит просторы Гугла в поисках сайтов на Net Cat…
Убытки понесут в первую очередь студии и фрилансеры, которые внедряли эту CMS на сайт заказчика, ведь именно к ним будут претензии.
Считаю, что таким сообщения место на каком-нибудь xakep.ru, а не здесь.
Если не нравится долгая реакция официального Net Cata на информацию о баге — смените CMS, выберите другую, их ведь полно.
А вы для решения проблем использовали «сталинский» метод, совсем не задумываясь о последствиях для рядовых пользователей и разработчиков.
P.S. Никакого отношения к данной системе (NetСat) не имею.
step-by-step guide для юных «хакеров».Вы его читали? Он просто для стеба разбит на пункты, на самом деле там все так просто, что любой юных «хакер» с большой долей вероятности сам мог наткнуться на него.
Убытки понесут в первую очередь студии и фрилансеры, которые внедряли эту CMS на сайт заказчика, ведь именно к ним будут претензии.Меры очень жестокие и очень к месту, разработчикам насрать уже год на своих клиентов, почему я должен заботиться об их безопасности.
для решения проблем использовали «сталинский» методТолько в самую последнюю очередь.
> Если не нравится долгая реакция официального Net Cata на информацию о баге — смените CMS, выберите другую, их ведь полно.
Если бы все рассуждали как Вы, мы бы до сих пор получали бажные процессора от Intel, сидели бы в дырявом-предырявом IE под Windows 2009, сделанной наспех на костях Windows 95 и сетовали бы мол «жизнь не удалась».
Если бы все рассуждали как Вы, мы бы до сих пор получали бажные процессора от Intel, сидели бы в дырявом-предырявом IE под Windows 2009, сделанной наспех на костях Windows 95 и сетовали бы мол «жизнь не удалась».
А не кажется ли вам, что кодобред платных монстров жанра CMS не что иное, как:
чрезвычайные требования по поддержке старых версий,
дедлайны к выходу суперновых версий о которых вовсю трубят маркетологи и директора,
требования к универсальности, когда разработчик средней руки не захочет править код компонентов до минимально необходимого минимума, вместо этого покрутит миллион настроек, а заказчик будет просить универсальной функциональности на все случаи жизни, все включено и никакой установки «расширений»,
просто коммерческий расчет, что рефакторинг сейчас — это потеря времени и отдача в руки конкурентам определенной доли рынка.
Как можно гордиться десятками тысяч файлов системы и нереальным количеством строк кода? Не понимаю.
чрезвычайные требования по поддержке старых версий,
дедлайны к выходу суперновых версий о которых вовсю трубят маркетологи и директора,
требования к универсальности, когда разработчик средней руки не захочет править код компонентов до минимально необходимого минимума, вместо этого покрутит миллион настроек, а заказчик будет просить универсальной функциональности на все случаи жизни, все включено и никакой установки «расширений»,
просто коммерческий расчет, что рефакторинг сейчас — это потеря времени и отдача в руки конкурентам определенной доли рынка.
Как можно гордиться десятками тысяч файлов системы и нереальным количеством строк кода? Не понимаю.
На странице форума: «В компании АИСТ (разработчик NetCat) открыта вакансия веб-разработчика».
Может у них штатного веб-разработчика и небыло? =)
Теперь ищат чтоб заплатку написал…
Может у них штатного веб-разработчика и небыло? =)
Теперь ищат чтоб заплатку написал…
это болезнь всех отечественных CMS
Работаю с UMI уже год. Один баг исправят, три новых появляется.
Не верьте рекламе. Крутите товар руцями
Работаю с UMI уже год. Один баг исправят, три новых появляется.
Не верьте рекламе. Крутите товар руцями
Ребята, это зачет!
cms-netcat.ru/support/tech/advice/functions_3.html
Прошу прощения за ссылку.
Цитировать это ну просто невозможно.
cms-netcat.ru/support/tech/advice/functions_3.html
Прошу прощения за ссылку.
Цитировать это ну просто невозможно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Дыры в форуме NetCat