1. PHP / Говнокод #7574

    +163

    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    6. 6
    7. 7
    8. 8
    9. 9
    $username = $vbulletin->userinfo['username'];
    .
    .
    .
    .
    .
    .
    $nickname = $username;
    $nickname = mysql_real_escape_string($nickname);

    PHP, булка, Эстонский код.

    Запостил: swat54, 17 Августа 2011

    Комментарии (36) RSS

    • ничего удивительного это же vbulletin
      Ответить
    • vBullShitIn...
      Ответить
    • ну не такое уж и говно... хотя, конечно, и не все гладко
      Ответить
      • более тупой архитектуры я в жизни не видел. еще и платное. ещё эти мудаки абсолютно все файлы в бд складывают, даже аватары. если приглядеться, то там костыль на костыле и стулом подперто
        Ответить
        • > эти мудаки абсолютно все файлы в бд
          А что плохого в том, чтобы складывать всё в БД? В java-мире это скорее норма, нежели исключение:
          1. Легче контролировать доступ, не нужно возиться с хранением в базе путей.
          2. Легче делать бэкап всех данных.
          3. Легче этот бэкап потом разворачивать.
          В контексте наличия вещей наподобие Apache Cassandra проблемы производительности постепенно уходят в прошлое.
          Ответить
          • ну точно. всем по класстеру в этом чати, я угощаю
            Ответить
          • Плохо это делать на дырявом php, но если все предусмотреть то может что и получится
            Ответить
          • такое г-но надо под реверс прокси подсовывать
            и нанять кого-нибудь, кто разбирается в HTTP,
            чтобы код, отдающий юзерпики написал
            Ответить
        • Вроде как можно выгрузить на диск, только потом самому с правами и доступом половым сношением сношаться.
          Хотя, да, на маленьком форуме таблица с картинками ВНЕЗАПНО разрослась до трёх гигабайт, делать ей backup было весьма занятно. А если накернилось что, при попытке вылечить таблицу можно было провести немало увеселительных минут.
          Ответить
        • Напиши свой форум способный выдержать нагрузки в 300к человек в день и вплоть до 10к одновременно на одном сильном сервере. Я куплю за $100. Честно!
          Ответить
          • Я тоже, но только за 50.
            Ответить
          • мне жаль тебя огорчать, но одно дело сделать выборку простых текстовых данных и совсем другое если туда ещё и блоб, а ещё и пыхом потом этот файл отдать. Тока не говори, что пых отдаст картинку быстрее nginx. Это почти тоже самое как гланды через жопу удалять)
            Ответить
            • При чем тут это? Хранить картинки в базе - это всего-лишь дефолтное поведение vBulletin'а. Можешь выбрать хранение статики в FS и отдавать как захочется - хоть сервер свой напиши, который будет буллетиновскую статику раздавать.

              Я говорю о том, что сам движок буллетина оптимизирован достаточно, чтобы держать сильные нагрузки, - за это можно платить. Именно из-за хорошей оптимизации движка буллетина, на нем сидят http://forums.digitalpoint.com/, наш http://forum.searchengines.ru/ и еще много высоконагруженных форумов.
              Ответить
              • > движок буллетина оптимизирован
                щито щито? см. говнокод
                Ответить
                • Дооо! Жуткий говнокод. Автор кода должен кукурузу собирать.
                  А еще этот код самое прямое доказательство неоптимизированности движка. Из-за этого кода производительность упала в 10 раз - не иначе.
                  Ответить
                  • гавняшка тут, гавняшка там. И в результате весь двиг скатился в говно. И к стати пярмой вызов mysql_real_escape_string уже есть говно.
                    Ответить
                    • "пярмой вызов mysql_real_escape_string уже есть говно"

                      Хочу объяснений, если не затруднительно, конечно.
                      Ответить
                      • Предположительно тут должен быть комментарий про prepared statements
                        Ответить
                      • Да какие тут еще комментарии, двиг форума это не гостевая, тут думать надо а если mysql c не нужен будет ? почему бы не использовать PDO?.
                        Ответить
                        • PDO не везде стоит, чтобы его пихать на популярный двиг.
                          Ответить
                        • Да я не против PDO и prepared statements (надеюсь, в 5 версии буллетина появится), - даже как бы наоборот, ибо сам пользуюсь. Просто не согласен, что использование mysql_real_escape_string напрямую есть говно.
                          Думать надо не о том, будет ли нужен MySQL (нет сомнений, что он еще очень долго будет жить невзирая на развитие NoSQL/NewSQL), а о том, чтобы дать свободу выбора (предложить альтернативу выбора сервера БД), но это уже совсем другая история.
                          Ответить
          • В каком страшном сне серверные сценарии стали узким местом нагруженного приложения типа "форум"? И тем более как это PHP сценарий начал "оптимизировать"?

            Вопросы, как нетрудно догадаться, риторические.
            Ответить
            • Риторические. А еще они не ко мне.
              Ответить
              • Как не жаль, но именно к вам.
                "PHP сценарий, оптимизированный под высокую нагрузку" -- это АДСКАЯ РЖАКА :))))
                Пора бы уже вырасти и понять, что в высокой нагрузке важны инженерные решения окружения, а не гейтвей сценариев, будь это Perl, C++ или PHP. Сценарий будет влиять на нагрузках относительно небольших, но тогда и нет смысла его оптимизировать, нагрузка же невелика. А когда нагрузка большая, то сценарий будет проводить до 80% времени в ожидании ответов иных компонент: сервер, база данных, операционная система. И нет смысла оптимизировать то, где поток проводит 20% времени.

                По этой причине, какое бы, извините, говно не было бы написано в PHP, при правильном инженерном проектировании системы её можно растянуть на Jaguar и в секунду обслуживать всех жителей Земли.
                Ответить
                • Убытки нанесенные человеческой глупостью трудно рассчитать, или предвидеть, поэтому очень самонадеянно рассчитывать на то, что хороший дизайн спасет плохое исполнение. В программе все должно быть прекрасно... :)
                  Ответить
                • Еще раз - это не ко мне. Я сам работаю с высокими нагрузками и знаю, как с ними справляться. То что вы тут распыляетесь, на мое сознание никак не влияет ;-) А PHP сценарии можно оптимизировать и оптимизация дает многое. Если вы хоть раз работали с большими массивами данных, вы поймете о чем я говорю. Порой нужны нестандартные инженерные решения.

                  Можно поинтересоваться, с какими нагрузками работала спроектированная вами система (или поддерживаемая вами на крайний случай)?

                  "при правильном инженерном проектировании системы её можно растянуть на Jaguar и в секунду обслуживать всех жителей Земли"

                  Никто никогда ни в коем случае не проектирует систему "правильно" - она всегда "дотачивается" под нагрузки. Twitter и Facebook - самые яркие примеры.

                  К стати, я рад, что вы знаете название самого мощного ЭВМ в мире :-)
                  Ответить
                  • Внатуре не моден. Он не самый мощный =\
                    Ответить
                    • Ну ладно - один из самых мощных :-) Вроде там японцы тоже че-то жуткое собрали.
                      Ответить
    • Все комменты с плюсиками, значит все правы
      Ответить
    • - Чего случилось, та? Поругались, что ль, с Пашкой?
      Ответить
    • - Не пущу, Лёка, ты мой. Я хочу тебя ужасно, я еле дотерпел до утра, пока твои предки уйдут. Ты мне снился всю ночь.
      Ответить

    Добавить комментарий