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

    +56

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    19. 19
    20. 20
    21. 21
    22. 22
    23. 23
    if(isset($_POST['btnsubmitup']))
    		{
    			for ($i = "0"; Arr::get($_POST, 'id'.$i, ''); $i++) {
    			if (Arr::get($_POST, 'up'.$i, '') == '1') {
    				$p1=-1;
    	//			$uploaddir = '/img/brands/';
    				$a = Arr::get($_POST, 'id'.$i, '');
    	//			$p1 = Upload::save($_FILES['photo'.$i], $uploaddir.$a.'.jpg', './', 0777);
    
    					$rand=rand(1000000,9999999);
    				$uploaddir = '/img_carpets/collection/';
    				$uploaddir2 = 'img_carpets/collection/';
    				$p1 = Upload::save($_FILES['file1'.$i], $uploaddir.'ID-'.$rand.'-1.jpg', './', 0777);
    				$p2 = Upload::save($_FILES['file2'.$i], $uploaddir.'ID-'.$rand.'-2.jpg', './', 0777);
    				$p3 = Upload::save($_FILES['file3'.$i], $uploaddir.'ID-'.$rand.'-3.jpg', './', 0777);
    				$p4 = Upload::save($_FILES['file4'.$i], $uploaddir.'ID-'.$rand.'-4.jpg', './', 0777);
    	//			if ($p1!="0") { $p1=$rand; }
    	//			if ($p2!="0") { $p2=$rand; }
    	//			if ($p3!="0") { $p3=$rand; }
    	//			if ($p4!="0") { $p4=$rand; }
    					$im2=Image::factory($uploaddir2.'back.png');
    
    // -> и так далее

    Начал разбирать библиотеку (фреймворк скорее - kohanaframework) одного сайта, дабы сделать нормальную админку
    Дошел до процедуры сохранения картинок. Я посмотрел, по какому же алгоритму сохраняются картинки (формирование имени файла)
    И опупел!
    ** $rand=rand(1000000,9999999); **
    В базе поле для сохранения имени картинки - не уникально.
    Т.е., разраб решил поиграть в рулетку, анука генератор чисел выберет еще раз одно и то же число, и перезапишет картинку у товара. ))))
    А оператор админки будет чесать репу - тут же работало а тут и нет )

    Запостил: topilnik, 01 Августа 2012

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

    • 23 строки ради одной. :)
      А способ классный.
      Ответить
    • Пздс какой то, тупо time() . "_" . md5(filename);
      Ну и для большей эффективности можно рандом от 1 до макс. числа одновременно загружаемых картинок.
      Ответить
    • md5_file($filename), md5(uniqid(rand(),1)) и т.д.
      Ответить
    • Там же получается 9 миллионов значений.
      9999999-1000000=8999999
      т.е. вероятность перезаписи = 1/8999999
      или я чего-то не понимаю?
      Ответить
      • а должна быть 0
        Ответить
        • вообще про одну десятимиллионную не всё так просто
          мне тервер преподавали давно и на пальцах, поэтому пускай люди со специальностью "математик" в дипломе меня поправят, может я несу пургу

          вероятность, что мы ткнём пальцем в число и попадём уже использующееся = k/M, где k - количество уже использующихся, а M - размер множества
          т.е. при 1000 фотографий из 10 млн один тык пальцем - всего то 1/10000 (0.01%, копейки ага?)
          но дело принимает другой оборот, когда нам надо удостовериться, что каждое 1001 тыканье не приведет к фейлу (иначе какой в этом смысл)

          считаю, что вероятность, что 1001 последовательное тыканье сфейлится будет равна
          1 - (1 - p[0])*(1 - p[1])*..*(1 - p[k]), где p[i] = i/M (т.е. начинаем эксперимент с пустой папки)

          для 1001 тыканья у меня получилось уже 4.88%
          а для 10000 фотографий (из 10 миллионов то, свободных нумеров полно ведь) - 99.327%
          Ответить
          • Тут смысл в том, что после создания фотографии вероятность того, что следующая "повторится" увеличивается на 1. 1/8999999, 1/8999998, 1/8999997....
            Ответить
            • по моему всё же
              1/8999999, 2/8999999, .... k/8999999
              Ответить
            • Этот наивный подход неверен. Как заметил @defecate-plusplus, математически удобнее считать вероятность того, что следующая не повторится.
              Ответить
          • Да, вы правы, всё зависит от того, что принимать за "эксперимент". Если речь идёт об единовременной выборке одной фотографии, которая сравнивается с какой-то другой фиксированной фотографией, то вероятность низка. Если речь идёт о некотором количестве последовательных выборок и нас интересует возможность совпадения двух любых фотографий (как раз наш случай), это совсем другой эксперимент (другое вероятностное пространство), вероятность повтора в котором растёт довольно быстро.

            Парадокс дней рождений.
            Ответить
          • prooflink
            http://liveworkspace.org/code/e189f3f6a0e5c6e4f5981b3f3c2d5dbc
            Ответить
          • > люди со специальностью "математик"
            Тараса забанили.
            Ответить
            • у него зелёный диплом
              а подразумевал я как раз того, кто прорецензировал мой пост
              Ответить
        • > а должна быть 0
          Ну не надо так категорично ;) В git'е тоже должна быть нулевая вероятность коллизии, но все смирились с 1/2^128 (с учетом парадокса ДР)...

          P.S. Но 10^7 согласен, мало, да еще и rand() может оказаться хреново реализованным.
          Ответить
          • оффтопа ради
            надо мигрировать на удобную vcs в конторе, немного разработчиков, никакой удалённой работы - svn или таки git?
            всё что нужно (интеграция с ide - работа мышкой, консольный режим) есть в обеих, потому хочется дополнительных критериев
            Ответить
            • я больше люблю git
              Быстрый, не нужно никакого специального сервера, хотя центральный репозиторий организовать не проблема
              Можно редактировать историю (желательно только локальную, разумеется) через git rebase -i
              В svn уж больно много раздражающих мелких косяков

              Интеграция с MS VC есть у обоих
              http://ankhsvn.open.collab.net/
              http://code.google.com/p/gitextensions/
              svn плагин для VC мне не понравился, гитовский не видел

              Можно ещё mercurial посмотреть, но IMHO git удобнее (хотя у hg интеграция с ОС более нативная)
              Ответить
              • Тоже проголосую за git.

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

                Удобно работать с ветвями - создал ветвь, потестировал что-нибудь, не понравилось - откатил, никто ничего и не заметил. В svn же работа с ветвями это полная ж...
                Ответить
            • ну и продолжая вечер по заявкам
              мы как то привыкшыя лаптями то

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

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

              уважаемые знатоки, колхозница Даздраперма Ильинишна из села Глубокие Позывы интересуется, сложно ли при каждом коммите проверять диффы и можно ли как то автоматизировать процесс?
              Ответить
              • > сложно ли при каждом коммите проверять диффы
                Если "разумное разделение ответственности", и каждый старается пилить свой независимый кусок - то можно даже не курить диффы. Если локальные и удаленные изменения коснулись друг друга - и git и svn предупредят, и заставят решить возникший конфликт.
                Ответить
                • вот что значит локальные и удаленные - версия на сервере выросла по сравнению с локальным репозиторием?

                  ну и чтобы два раза не вставать
                  в рекламных буклетах TFS в красках расписывают о фиче "code review"
                  типа я могу выделить кусок кода и подсказать молодому сотруднику, куда ему надо сходить что ему надо исправить
                  в сабже есть что то подобное?
                  Ответить
                  • > что значит локальные и удаленные
                    Это значит, что у каждого разработчика на самом деле локально есть полная копия репозитория, которая работает даже без доступа к сети. Когда он наковыряется со своей таской, наплодив кучу коммитов, он может слить изменения в "центральный" репозиторий (центральный только потому, что мы так решили, центром может быть любой репозиторий, они практически не зависимы). Это позволяет делать частые локальные коммиты без опасности кому-нибудь поднасрать.

                    > в сабже есть что то подобное
                    Есть, только для этого нужно установить соответсвующий интсрумент.
                    Для гита есть гугловский gerrit, есть ещё универсальный reviewboard. К сожалению, установка требует некоторых навыков.
                    Ответить
                    • > локально есть полная копия репозитория
                      репозиторий здесь имеется в виду то, что нужно только тебе для проекта, или всё, что армия говнокодеров успела насрать разработать за 15 лет существования конторы
                      или под каждый проект надо создавать некий обособленный репозиторий?
                      Ответить
                      • git: Всё, что армия говнокодеров успела насрать за 15 лет существования конкретного проекта. (Если, конечно, под каждый проект заводится отдельный репозиторий).

                        svn: ЕМНИП "чистая копия" версии, на которой основана локальная + сама локальная версия. Труды армии говнокодеров за 15 лет хранятся на сервере.
                        Ответить
                      • Это уж как душе угодно
                        Общепринятый путь - хранить каждый проект в своём git-репозитории (например, каждая подсистема ядра linux лежит в своём репозитории). Это гораздо удобнее, чем хранить всё в одной большой куче. Для иерархических проектов есть фича submodules.
                        Ответить
                        • просто в понятии source safe (дада, у нас используется именно это говно мамонта, стыд) каждая папка - это и есть проект
                          поэтому я как бы могу посмотреть клиентом огромную иерархию от корня $/...., но фактически в солюшене из 10 проектов внутри каждый проект просто привязан к своей конкретной папке в иерархии и при get этого проекта он сливает ровно то, что нужно, начиная с своей папки
                          весь старый мир никто разрушать до основанья не будет, вот я и пытаюсь уложить в своей голове, надо ли мне будет сливать ненужный код
                          видать вот эти вот submodules и выручат
                          Ответить
                  • У svn - если локально что-то поправили, а за это время версия на сервере выросла из-за коммита коллеги.

                    У git'а - если последний коммит на сервере не является непосредственным предком коммита на локальной машине. (У него номеров версий как таковых нет).

                    "code review" - насчет этого не видел, скорее всего нет... Разве что внешние тулзы.
                    Ответить
                • Кстати, и svn (всегда) и git (если не принуждать его), не дают залить изменения на центральный сервер, если на него кто-то что-то уже отправил.
                  Ответить
              • что значит "проверять диффы"? системы контроля версий отслеживают изменения в одних и тех же строках одних и тех же файлов, выдавая ошибку при попытке коммита несмёрженной версии. Кроме того, у svn и git есть так называемые хуки - скрипты, выполняемые при попытке коммита или после коммита. Можно, например, таким образом запретить коммиты, если месседж не содержит ссылку на таску в таск-трекере или если код не компиляется, а также запускать билд\деплой на билд-сервере с автоматическим прогоном тестов после каждого коммита.
                Ответить
                • > не содержит ссылку на таску в таск-трекере
                  > если код не компиляется
                  страх какой
                  это же ведь отключается?
                  Ответить
                  • Это можно специально настроить, если хочется
                    По дефолту все хуки пустые
                    Ответить
                • Можно автоматически понижать премию, за push кода, который не компилируется.
                  Ответить
                  • я, бывает, начинаю серьезные вещи, которые в течение дня могут например не мочь компилироваться (пока не должны)
                    естесственно эти вещи не интерферируют с основной веткой кода
                    ну а куда нибудь в .../sandbox проект уже положить охота
                    всё таки сервер бекапится регулярно, а моя машина - нет

                    потому и было бы невесело, если бы мне еще vcs лечила мозги, если код не компиляется (кстати, с++ это же джава ведь, чтобы за полсекунды проверить компиляеца или нет, хехе)
                    Ответить
                    • Вот для такого случая как-раз можно запилить веточку и засылать ее на сервер, не мешая тем, кто пилит основную.
                      Ответить
                  • Говорят, где-то за сломанный билд сотрудник становился ответственным и занимался проверкой до тех пор, пока билд не сломал кто-нибудь другой.
                    Ответить
          • Сорри, сморозил глупость. C 1/2 после 2^128 файлов...
            Ответить
      • Вероятность перезаписи другая, загугли birthday problem.

        EDIT: А, выше уже об этом уже сказали, ну, и пусть говорят!
        Ответить

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