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

    −23

    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
    /**
    * Конвертация формата времени в удобочитаемый вид
    * @param mixed $data
    * @param mixed $year
    * @param mixed $time
    * @param mixed $second
    */
    public static function data_convert($data, $year, $time, $second){
        $res = "";
        $part = explode(" " , $data);
        $ymd = explode ("-", $part[0]);
        if(count($ymd)==1){
        $ymd = explode (".", $part[0]);
        $ymd[2]="20".$ymd[2];
        $ymd = array_reverse($ymd);
        }
        $hms = explode (":", $part[1]);
        if ($year == 1) {$res .= $ymd[2]; $res .= '.'.$ymd[1]; $res .= '.'.$ymd[0];}
        if ($time == 1) {$res .= ' '.$hms[0]; $res .= ':'.$hms[1]; if ($second == 1) $res .= ':'.$hms[2];}
        return $res;
      }

    На вход из БД могут заходить два вида дат: (mysql)
    - TIMESTAMP "2016-11-13 05:29:38"
    - VARCHAR "13.11.16 05:29"
    На выходе получаем единый формат "16.11.2016 05:29"

    Хранить дату в varchar ? Это модно ))

    Гурманов прошу обратить внимание на строку 19. Как там органично не указаны {} в секундах

    Запостил: AndryG, 20 Ноября 2016

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

    • Получилась вот такая замена. После переделывания поля с varchar на DATETIME сразу подхватится и здесь
      public static function data_convert($data){
        try{
          return (new DateTime($data))->format('d.m.Y H:i');
        }catch(\Exception $e){
          return $data;
        }
      }
      Ответить
      • Всё проще, долбоёб:

        date("d.m.Y H:i", strtotime($date));
        Ответить
        • strtotime выполняет неочевидные преобразования:
          echo date("jS F, Y", strtotime("11.12.10")); // подразумевает y.m.d
          // outputs 10th December, 2011 
          
          echo date("jS F, Y", strtotime("11/12/10")); // подразумевает m/d/y
          // outputs 12th November, 2010 
          
          echo date("jS F, Y", strtotime("11-12-10")); // подразумевает d-m-y
          // outputs 11th December, 2010


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

          Кстати, методы класса DateTime можно использовать и «в процедурном стиле»:
          date_format(date_create_from_format('Y-m-d H:i:s', $data), 'd.m.Y H:i');


          P.S. Всё-таки "Y-m-d H:i:s" strtotime проглатывает (распознаёт год, когда он четырёхзначный), но на втором формате глючит.
          Ответить
          • P.P.S. Проверил. У меня strtotime вообще не распознаёт формат с точками: если написать только дату без времени, то выводит сегодняшнее число; если написать дату со временем, то выводит 1 января 1970.

            <?php
            
            echo date("jS F, Y", strtotime("10.11.12")) . PHP_EOL;			// 20th November, 2016 = сегодня
            echo date("jS F, Y", strtotime("2010.11.12")) . PHP_EOL;		// 1st January, 1970 = 0 by unix time
            echo date("jS F, Y", strtotime("10.11.2012")) . PHP_EOL;		// 10th November, 2012
            echo date("jS F, Y", strtotime("10.11.12 10:11:12")) . PHP_EOL;		// 1st January, 1970 = 0 by unix time
            
            echo date("jS F, Y", strtotime("10/11/12")) . PHP_EOL;			// 11th October, 2012
            echo date("jS F, Y", strtotime("2010/11/12")) . PHP_EOL;		// 12th November, 2010
            echo date("jS F, Y", strtotime("10/11/2012")) . PHP_EOL;		// 11th October, 2012
            echo date("jS F, Y", strtotime("10/11/12 10:11:12")) . PHP_EOL;		// 11th October, 2012
            
            echo date("jS F, Y", strtotime("10-11-12")) . PHP_EOL;			// 12th November, 2010
            echo date("jS F, Y", strtotime("2010-11-12")) . PHP_EOL;		// 12th November, 2010
            echo date("jS F, Y", strtotime("10-11-2012")) . PHP_EOL;		// 10th November, 2012
            echo date("jS F, Y", strtotime("10-11-12 10:11:12")) . PHP_EOL;		// 12th November, 2010


            http://ideone.com/QxTavL

            В общем, никогда не используйте strtotime. Лучше сразу date_create_from_format.
            Ответить
            • Когда заметил, что протупил с обрезанием даты в методе, то время редактирования поста уже вышло.
              Спасибо за подсказку date_create_from_format(). Пытался ночью найти эту функцию, да был очень сонный ))
              Вот новый вариант функции. Можно отдельным постом вешать - знатный изврат вышел. Будет такой костыль, пока не приведу в порядок поле в БД
              public static function data_convert($data){
                try{
                  try{
                    $dt = new DateTime($data);
                  }catch(\Exception $e){
                    $dt = DateTime::createFromFormat('d.m.y H:i', $data);
                  }
                  return $dt->format('d.m.Y H:i');
                }catch(\Exception $e){
                  return $data;
                }
              }
              Ответить
    • давно доказано что любители пхп и мускуль не моугт в программироване
      Ответить
      • че не так с мускуль?
        Ответить
        • мускуль не умеет примерно ничего: ни констреинтов, но нормального анализатора запросов, ни экзекьюшен плана to name some

          та же постгря в миллиард раз лучше
          Ответить
          • Так может она лучше, потому что ты сам ничего кроме хомпаг не делаешь?
            https://eng.uber.com/mysql-migration/
            Ответить
            • Вот сразу видно что ты нихуя не умеешь, потому даже не смог ответить по существу. Высер убера давно уже обосран, ибо там много ламерской чуши, начиная от высера про многопоточность.
              Ответить
              • обоснуй
                Ответить
                • Что именно? Что на линуксе поток не дороже процесса? Ну так почитай как потоки на линуксе работают.
                  Ответить
                  • Поток везде не дороже процесса. Лучше ты иди высер убера почитай, прежде чем обсуждать.
                    Ответить
                    • Не дороже, и не дешевле. Ты такой же ламер, как уберовцы?
                      Ответить
                      • Ой все. Я не собираюсь твои выперды в лужу расшифровывать.

                        > не дешевле
                        И опять ты в лужу перднул. Рано тебе еще в интернете спорить, иди домашку делать.
                        Ответить
                        • >>ой все

                          слив защитан)

                          Вот тебе более развернутый ответ, где я ппкс

                          Funny article by Uber. The only real issue they found is Write Amplification. That is probably can be an issue for huge sites.
                          >>Replication
                          Postgres supports statement-based replication by third party tools like http://www.pgpool.net/ which is de-facto standard.
                          That is shame not to have such a good functionality built in, but MySQL lacks so many tools so there is even a company named Percona which produces tools to manage mysql
                          replication and backup.
                          >>Data Corruption
                          Wow, they found a bug in Postgres. I am sure MySQL is bug-free
                          >>Replica MVCC, Postgres Upgrades
                          Again: statement updates are available to solve this issue.
                          >>The Buffer Pool
                          Following sentence is lie: "Postgres allocates some memory for internal caches, but these caches are typically small compared to the total amount of memory on a machine."
                          From postgres manual on shared_buffers (postgres analogue of mysql buffer pool):
                          "shared_buffers: If you have a dedicated database server with 1GB or more of RAM, a reasonable starting value for shared_buffers is 25% of the memory in your system"
                          >>Connection Handling
                          This is not true, at least for Linux: "Postgres, however, use a process-per-connection design. This is significantly more expensive than a thread-per-connection design for a number of reasons."
                          Process is not "significantly more expensive" than thread on Linux. But they probably use Windows, I am not sure.
                          There are a lot of features Postgres has and MySQL/InnoDB does not (smart query optimizer, true constraints, cached views, calculated columns, etc), but they are probably not used by Uber.
                          Ответить
                          • > That is probably can be an issue for huge sites.
                            Чтд. С твоими хомпагами действительно разницы нет.
                            Ответить
                            • лол, ты не осилил прочитать все остальное чтоли?

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

                                  Это похвально. сразу бы так)
                                  Ответить
                  • Поток дешевле процесса, или на прыщах все наоборот?
                    Ответить
                    • на прыщах это одинаково

                      http://stackoverflow.com/questions/807506/threads-vs-processes-in-linux
                      Ответить
                      • В общем случае неверно. Даже если закрыть глаза на то, что процессы влекут оверхед по памяти (надо где-то хранить дескрипторы и прочие метаданные), процессы в отличии от потоков живут в разных адресных пространствах, значит при переключении процессов нужно сбросить все кеши и TLB, например. В железе есть некие оптимизации супротив этого, но железо не резиновое.

                        Ну и между процессами нужно IPC какое-то, по умолчанию они друг-другу в память гадить не могут, значит любое взаимодействие между ними = оверхед.
                        Ответить
                        • > В железе есть некие оптимизации супротив этого
                          Ну вот как раз, когда 10к что-то делающих процессов, от этих оптимизаций мало пользы. Пока процесс опять попадет на выполнение (да на то же ядро), весь тлб вымоет.
                          Ответить
                        • > по умолчанию они друг-другу в память гадить не могут
                          шаред мемори же
                          Ответить
                          • Нахуй это говно, я вам скажу. Хотя у нас используется.
                            Ответить
                            • Ну постгря вряд ли без этого обошлась. Иначе там все очень плохо.
                              Ответить
                              • всё говно кроме мочи
                                постгря не эталон
                                у нас уже в портфолио прилично нагруженных проектов на ней
                                вакуум это самый атас, постгря плохо дружит с тем, чтобы очень часто и очень много апдейтить тыщи строк
                                Ответить
                                • Пальпировал твою простату, проверь.
                                  Ответить
                                • Часто и много - это сколько? Расскажи про опыт.
                                  Ответить
                                  • был такой проект, когда мы пиздили снапшотами состояния flightradar24 и marinetraffic (ну и до кучи прочие системы, куда фантазия заказчика достигала)

                                    по сути, раз в N минут (N около 5 для самолётиков) поллили все объекты из внешней системы, сохраняли все отрезки пути, куда кто сместился (ну и плюс вытаскивали все описания, картинки и т.д.)

                                    за один снапшот около 10к объектов приходило, ну и 10к * k отрезков пути

                                    схему я сделал ещё не зная о адовом подарке от создателей постгреса, в котором любой апдейт строки создает в хвосте таблицы новую копию этой строки, не важно, нужна ли была старая строка кому-то или нет (вместо того, чтобы где-то в отдельных блоках хранить и потом по старому месту после коммита присунуть новое состояние), а таковых объектов было немало, т.к. если объект уже тречился в системе, то ему обновляли last_path_segment_id, ну и для path_segment тоже в целях ускорений (уточка говорит зря зряя) сделали двунаправленный список (next/prev path segment id), ну и понятное дело, когда объект пропадал, мы его тоже архивировали и в итоге тёрли вместе с сегментами

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

                                    притом, что в ресурсах там не было лимитов, железо топовое

                                    пока игрались с ручными настройками вакуума бд, база росла за сутки на десятки гигов, из которых "живых" строк было ну вот те же самые 10к объектов + сколько то там им сегментов пути (ну допустим x100) - всё потому, что постгрес продолжает писать в хвост таблицы, пока не сделается вакуум

                                    в итоге сейчас оно ночью чистится вилкой и работает стабильно ну уже года полтора
                                    но осадочек от автовакуума остался
                                    Ответить
                                • да, у постгри создаются новые rows и потом делается gc

                                  так устроен там mvcc. потому аргумент про засирание это ЕДИНСТВЕННЫЙ правдивый аргумент в уберовом высере.

                                  Все остальное там чушь.

                                  Зато в постгре есть охулиард фич которые есть в нормальных субд и которых нет в mysql. Тебе-то не надо перечислять,ты же вкурсе наверняка что в mysql даже констреинтов нет.
                                  Ответить
                                  • Я не пойму, тут срач про мускул вс постгрес?
                                    Ответить
                                    • Тут бароп говорит, что мускул говно, потому что ему туда перделок не завесли.
                                      Ответить
                                      • >>перделок

                                        это query optimizer перделка?;)

                                        лол, хуесто, сразу видно что ты ничего кроме лабы с субд не делал
                                        Ответить
                                        • самый охуенный оптимизатор в оракле, постгресовскому до него еще пилить и пилить, sad but true

                                          буквально вчера видел тупейший фейл постгреса - построил btree индекс на таблице по колонке baz, которая FK, ну с целью быстро и охуенно считать select count(*) from foo.bar where baz = :1

                                          оракл бы сделал range scan по индексу, count на след шаге и все, кост был бы примерно 2

                                          постгрес какого то хера сделал bitmap scan по индексу (почему битмап, подумал я, там ведь разнообразие этих значений больше тыщи, ну да хуй с тобой, может, это у тебя ренж такой) и... и... полез в материнскую таблицу через nested loop, а уж потом count

                                          причем, select(baz) или select(1) естесно никак ему не помогли, как и аналайзы

                                          с другой стороны за $0 очень годно, каких то фич оракловых нет, есть зато сотни своих
                                          Ответить
                                      • Из тем что я столкнулся лично - сортировка за O(n**2) с myisam. Тебе хватит?
                                        Ответить
                                        • справедливости ради надо сказать что myisam не нужен
                                          давно уже innodb по дефолту

                                          да и query "optimizer" в мускулях не всегда зависит от движка

                                          но postgresql geqo конечно дает посасать мускулю очень сильно.

                                          Да и не только он . WITH дает, Window functions дает, вычисляемые поля, тысячи их!

                                          Сравнивать mysql с postgres это как notepad с wordом
                                          Ответить
                        • А я слышал что проц не видит разницы между процессами и потоками.
                          Ответить
                          • Наверное потому что проц всегда выполняет потоки.
                            Ответить
                          • > не видит разницы между процессами и потоками
                            Потоки проц вообще не видит, для него это просто сохранение и загрузка регистров. А от процессов он видит только таблицу страниц (а на некоторых архитектурах - и её не видит).
                            Ответить
                            • А потоки это типа не часть процесса?
                              Ответить
                              • Пидар, ты не темни. Говори прямо, к чему клонишь.
                                Ответить
                                • >А от процессов он видит только таблицу страниц
                                  Проц не видит относятся потоки к одному и тому же процессу или нет. Ему похуй.
                                  Ответить
                                  • Видит. При переключениями между потоками разных процессов адресное пространство меняется, меняется таблица страниц, процессор либо сразу сбрасывает кэш этой таблицы, либо начинает это делать постепенно. При переключении между потоками одного процесса этого не происходит.
                                    Ответить
                                    • Особенно круто меняются страницы с кодом, да:) И про copy-on-write ты тоже не слышал.
                                      Ответить
                                      • Бароп, ты не темни. Говори прямо, каким боком ты тут со своим копи он врайт и что сказать хотел.
                                        Ответить
                                        • при создании нового процесса через fork() (а так же clone() итд)будут использоваться же самые страницы в памяти что и для старого процесса, пока он не начнет в них что-то писать.

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

                                              еще раз: в ядре линукса _НЕТ_ разницы между потоком и процессом.

                                              Тебе на русский перевести http://stackoverflow.com/questions/807506/threads-vs-processes-in-linux?answertab=votes#tab-top ?
                                              Ответить
                                              • Зачем ты споришь о неизвестных тебе вещах? Я уже понял, что ты не знаешь, что такое виртуальная память. Иди читать. Еще раз слова для поиска: виртуальная память, mmu, tlb.
                                                Ответить
                                                • Я прекрасно знаю как работает mmu, но tlb тут не при чем!

                                                  еще раз: у процессора нет понятия "поток" и "процесс": у него есть понятие "task". Понятие "поток" и "процесс" может быть у операционки. У линуксового ядра разницы между этими понятиями практически нет. Пока ты не прочитаешь приведенную мною ссылку, я не буду тебе ничего говорить. Всё.
                                                  Ответить
                                                  • Я прекрасно знаю, как устроены потоки в линуксе, и что форк реализован через клон. Не надо повторять это, как попугай. То что потоки и процессы одно и то же - это пиздешь. Потоки с разными адресными пространствами одним - это не одно и то же.
                                                    Ответить
                            • внезапно в другом потоке другой стек и тред локал хранилище, а значит у него тоже могут быть другие страницы, правда?

                              Борманд, ну ты же умный парень, объясни уже хуесте что НЕТ разницы по перформансу между потоком и процессом на линуксе (на винде -- есть)
                              Ответить
                              • Вот ты дурак. Стеки и тредлокал переменные всех потоков одного процесса находятся в одном адресном пространстве по разным адресам. Завались уже.
                                Ответить
                                • лол, ты читать умеешь: http://stackoverflow.com/questions/807506/threads-vs-processes-in-linux?answertab=votes#tab-top ?
                                  Ответить
                          • мой п(р)оц не видит разницы между твоим ртом и очком твоей мамаши, проверь
                            Ответить
                        • еще один знаток нарисовался.

                          1) страницы кода у тебя ОДИНАКОВЫЕ, правда?

                          2) Стеки у тебя ВСЕГДА разные что для потока в том же процессе, что в другом

                          3) В потоке может быть своя куча, а в треде свой тред локал

                          4) "static" может быть свой у процесса но создается только при новой записи (copy on write).
                          Ответить
                          • Ты сейчас рассказал о том, что кеши могут протухать. В этом никто не сомневался и так, вопрос в том, сбрасывается ли TLB полностью или нет. Сейчас добилдится doxygen для прыщей, и мы всё (надеюсь) узнаем.
                            Ответить
                            • ладно, посыпаю голову пеплом: TLB перегрузится если process block другой. Ну с таким же успехом оно перегрузится когда шедулер запустит на этом ядре другое приложение (у тебя же не только постргря на машине) и когда ты в kernel space пойдешь тоже может поменяться. И по-прежнему не доказано что это хоть как-то серьезно влияет на перформанс. TLB полезен чтобы не ебаться с таблицами страниц в рамках одного кванта, а квант это же вечность по компьютерным меркам. У тебя есть какие-то бенчмарки?
                              за щеку, проверь
                              Ответить
                            • Вот говнокод познавательный, толкает к открытиям.

                              Во-первых, ещё вовсе не ясно, что хуже: зафлашить весь TLB разом несколькими инструкциями и потом огрести thrashing, замедляя приложения, или же инвалидировать его точечно, но выполняя сложный обход с кучей инструкций, замедляя context switch.

                              Во-вторых, необходимость полной инвалидации кешей дико меняется с новыми архитектрурами.

                              В-третьих, с не выставленным CPU affinity ядро само успешно инвалидирует все кеши путём перекидывания процесса между ядрами, но TLB бывает многоуровневым, поэтому оценить масштаб бедствия очень сложно.

                              Короче, да, в первом приближении на современных архитектурах вне лабораторных условий разница в производительности не должна быть слишком заметной.
                              Ответить
                              • >>В-третьих, с не выставленным CPU affinity

                                Представим себе что у нас квадратный конь в вакууме, и есть два процесса и два ядра cpu.
                                Разве шедулер начнет менять их местами просто так, от нечего делать?

                                Я думаю что нет, он оставит каждый процесс при своем cpu.

                                Теперь представим что у нас 158 процессов и 2 CPU.

                                Пусть процесс привязан к ядру 1.
                                Значит-ли это что никакой процесс не сможет больше выполняться на ядре 1? Если да, то это адский проеб ресурсов.
                                Если нет (то-есть это просто значит что он всегда будет выполняться только на этом ядре), то как только первый процесс уснет (или просто кончится его время) туда сразу же придет другое приложение и пизда придет TLB.

                                Вопрос: как ту поможет affinity?
                                Ответить
                                • Иди на хуй.
                                  Ответить
                                  • Сам иди на хуй


                                    В общем собака порыта в CLONE_VM.

                                    Позиксовые понятия "процесс" (fork()) и "поток" (pthread_create()) один хуй мапятся в clone()

                                    Просто один с CLONE_VM (и создает новый процесс блок -> флашит TLB) а другой без.

                                    Но на перформанс все равно почти не влияет
                                    Ответить
                                    • > Но на перформанс все равно почти не влияет

                                      context switch почти не влияет, прошу заметить. (Хотя если навыделять много страничек, то всё будет плохо всё равно, что-то мне говорит)

                                      За IPC всё равно придётся в ядро лезть, если не заморачиваться с shared memory. А это плохо.
                                      Ответить
                    • На прыщах тоже дешевле. Бароп - дурачек, не слушай его.
                      Ответить
    • Ходят слухи среди пыхов, что чем больше в коде $, тем больше зарплата.
      Ответить
      • слышал, чем больше хуев в твоем рту, тем больше твоя зарплата, проверь
        Ответить
    • Вижу, что сайт говнокода обзавелся говноюзерами. Печально.
      Ответить

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