Комментарии 36
Эх, понеслась! Вторая статья за два часа.
На данный момент наверное Рунет опережает англоязычную блогосферу по наличию статей о Kohana v3…
На данный момент наверное Рунет опережает англоязычную блогосферу по наличию статей о Kohana v3…
И у меня есть идея для третьей, совершенно срывающей башню статьи :)
Но боюсь готова будет не раньше следующих выходных.
Но боюсь готова будет не раньше следующих выходных.
Неужто руководство для новичков по Kohana 3? :)
У меня есть идея попробовать сделать модуль для этого: code.google.com/p/phpdaemon/
И тем самым сделать кохану первым фреймворком, работающим по true-fastCGI.
По правде сказать, там такой говнокодище внутри :)
И тем самым сделать кохану первым фреймворком, работающим по true-fastCGI.
По правде сказать, там такой говнокодище внутри :)
НЛО прилетело и опубликовало эту надпись здесь
Кого показывать, идею? Я показал :)
А говнокодище вот на этой странице.
А говнокодище вот на этой странице.
А какие преимущества дает Doctrine по сравнению с кохановской ORM? Или просто, кто к чему привык?
С этим можно ознакомится на страницах документации. Вкратце — создания миграций, генерация моделей, задание моделей в yaml. Kohana ORM хорош, но его иногда мало.
кохановский орм (по крайней мере 2ой версии) был крайне топорным, с необходимостью выстраивания ряда костылей на костыли при отступлении хотя бы на шаг влево-вправо от того, что придумали девелоперы.
ps: вот этот код был найден в орм кохана v2: phpclub.ru/talk/showthread.php?s=&threadid=116145&rand=40
ps: вот этот код был найден в орм кохана v2: phpclub.ru/talk/showthread.php?s=&threadid=116145&rand=40
Неужели мифические наносекунды оправдывают этот говнокод?А почему такая уверенность, что секунды мифические? В критических участках кода в нативных языках иногда даже разворачивание циклов оправдывается.
я там дальше провел измерения на реальном проекте, написанным с kohana2.
phpclub.ru/talk/showthread.php?postid=870862#post870862
phpclub.ru/talk/showthread.php?postid=870862#post870862
Не так давно переписывался с человеком, у которого был цикл с созданием более тысячи объектов ORM. Не буду говорить, что это оправдано, но, согласитесь, тут уже миллисекунды решают ;)
А вообще, я не понимаю — где там быдлокод? Да, вместо одной строки развернули блок на 10. Да, возможно не всегда это действительно будет сказываться. Но чем оно мешает? Вы часто расширяете методы ORM, чтобы ругаться на данный участок?
А вообще, я не понимаю — где там быдлокод? Да, вместо одной строки развернули блок на 10. Да, возможно не всегда это действительно будет сказываться. Но чем оно мешает? Вы часто расширяете методы ORM, чтобы ругаться на данный участок?
чтобы ругаться на данный участок достаточно наличия самого этого участка. он неоправдан.
для меня 0.00001 в вызове длительностью 0.05-0.07 (реальные цифры реального проекта) это ничто. переубедите?
«Не так давно переписывался с человеком, у которого был цикл с созданием более тысячи объектов ORM. Не буду говорить, что это оправдано, но, согласитесь, тут уже миллисекунды решают ;)»
поверьте, в создании 1000 сущностей средствами ОРМ всё процессорное время будет сожрано совершенно другими методами. и мы снова получим 0.01с в вызове порядка 10-20 секунд (к примеру). и опять эта оптимизация будет высосанной из пальца.
для меня 0.00001 в вызове длительностью 0.05-0.07 (реальные цифры реального проекта) это ничто. переубедите?
«Не так давно переписывался с человеком, у которого был цикл с созданием более тысячи объектов ORM. Не буду говорить, что это оправдано, но, согласитесь, тут уже миллисекунды решают ;)»
поверьте, в создании 1000 сущностей средствами ОРМ всё процессорное время будет сожрано совершенно другими методами. и мы снова получим 0.01с в вызове порядка 10-20 секунд (к примеру). и опять эта оптимизация будет высосанной из пальца.
Еще раз. Чем именно не устраивает данный участок? даже если попытка оптимизации не совсем удалась, хуже-то не будет… Вы ведь так и не обосновали свои претензии к данному участку, что именно в нем такого «говнокодистого». Только не надо говорить о читабельности, ибо во внутренностях ORM Вы не будете ковыряться каждый день.
у меня претензии следующие: зачем оптимизировать то, что не тормозит?
вы ведь знаете, что стройный код оптимизировать проще, чем корявый.
и в будущем, если не дай бог (но поверьте, такого не случится, объяснял почему уже миллион раз) это место будет самым медленным в проекте — то в контексте, опять же, конкретного проекта оптимизация может быть другой, и очень даже вероятно более удачной.
вы ведь знаете, что стройный код оптимизировать проще, чем корявый.
и в будущем, если не дай бог (но поверьте, такого не случится, объяснял почему уже миллион раз) это место будет самым медленным в проекте — то в контексте, опять же, конкретного проекта оптимизация может быть другой, и очень даже вероятно более удачной.
>> у меня претензии следующие: зачем оптимизировать то, что не тормозит?
вы ведь знаете, что стройный код оптимизировать проще, чем корявый.
Не вижу там ничего корявого.
Более того, что там тогда еще оптимизировать, если, как Вы говорите, в данном участке оптимизация не нужна?
вы ведь знаете, что стройный код оптимизировать проще, чем корявый.
Не вижу там ничего корявого.
Более того, что там тогда еще оптимизировать, если, как Вы говорите, в данном участке оптимизация не нужна?
вот именно. зачем такая огромная конструкция, если она не тормозит? почему она записана для 4х аргументов, а не для 5 или 3?
чем 2 строки с call_user_func_array() были хуже, чтобы городить вместо этих 2х строк — 30?
чем 2 строки с call_user_func_array() были хуже, чтобы городить вместо этих 2х строк — 30?
для меня 0.00001 в вызове длительностью 0.05-0.07 (реальные цифры реального проекта) это ничто. переубедите?Но ведь это для вас в вашем проекте. У кого-то другого вызовов было не 6, а 600 и ему этот участок был критичен. Решительно не понимаю, чего кричать «мне это не нужно, уберите пожалуйста». Вам не нужно, другим нужно.
если будет 600 вызовов, тогда 0.00001 превратится в 0.006, а общее время будет стремится к 30секундам. и оптимизация снова будет ничтожная.
собственно у вас та же самая позиция, что и у девелоперов коханы.
собственно у вас та же самая позиция, что и у девелоперов коханы.
напишите приложение, в котором этот кусок будет критичен и приведите цифры, сколько вообще выполняется ваше приложение и сколько вы выйграли конкретно этим методом.
вы хоть что-то, кроме своих догадок, можете противопоставить моим цифрам?
вы хоть что-то, кроме своих догадок, можете противопоставить моим цифрам?
Если производительность любого участка кода тестировать на реальном проекте, разница все время будет 0 :)
Нужно тестировать, на сколько конкретный участок быстрее. Если хотя бы раза в 2, это уже повод.
Нужно тестировать, на сколько конкретный участок быстрее. Если хотя бы раза в 2, это уже повод.
в том то и дело, что в реальных проектах, нас интересует в итоге не относительная разница: да, код там в 2-3 раза быстрее отрабатывал, а абсолютная.
конкретно этот участок кода работал на 0.00001с быстрее, чем более простая реализация в 2 строки.
извините конечно, но для меня писать подобный говнокод, который сэкономит 0.00001с из вызова в 0.05с — это извращение.
конкретно этот участок кода работал на 0.00001с быстрее, чем более простая реализация в 2 строки.
извините конечно, но для меня писать подобный говнокод, который сэкономит 0.00001с из вызова в 0.05с — это извращение.
ps: повод оптимизации — это медленный участок.
как только появится человек, который сможет в реальном проекте всю бизнес-логику оттюнить настолько, что этот участок кода будет самым медленным (а, не поверите, лучшие кандидаты на оптимизацию — самые медленные участки, а не те участки, которые проще всего оптимизировать), вот тогда и поговорим. и, вероятно даже, этому человеку все начнут поклоняться.
как только появится человек, который сможет в реальном проекте всю бизнес-логику оттюнить настолько, что этот участок кода будет самым медленным (а, не поверите, лучшие кандидаты на оптимизацию — самые медленные участки, а не те участки, которые проще всего оптимизировать), вот тогда и поговорим. и, вероятно даже, этому человеку все начнут поклоняться.
Отлично. Приятно видеть, как после выхода КО3 к ней проснулся интерес.
моя версия модуля, где основными функциями Doctrine Command Line Interface можно пользоваться с окна браузера
Очень интересно.
Я как раз занимался написания CLI контроллера для kohana, который бы заменял Doctrine CLI і генерил модели внутри каждого модуля отдельно. Это позволяет делать отличные вещи, с которыми у kohana orm проблемы. Так же удобно делать модули, где изначально только yaml схема, а все остальное генерируется динамично.
Я как раз занимался написания CLI контроллера для kohana, который бы заменял Doctrine CLI і генерил модели внутри каждого модуля отдельно. Это позволяет делать отличные вещи, с которыми у kohana orm проблемы. Так же удобно делать модули, где изначально только yaml схема, а все остальное генерируется динамично.
Подскажите, пожалуйста, какой пароль, а то интересно взглянуть на ваше творение ;)
Кстати, есть еще модуль Sprig (http://github.com/shadowhand/sprig) от Shadowhand'а, который я все не могу скачать и потестировать…
А как Doctrine интегрировать с пагинацией Коханы?
Решил проблему используя компоненты Zend Framework
Описал решение тут
http://seyferseed.ru/php/zend-framework-2-paginator-bez-zend-mvc.html
Вот почему я не использую Kohana для новых проектов…
Описал решение тут
http://seyferseed.ru/php/zend-framework-2-paginator-bez-zend-mvc.html
Вот почему я не использую Kohana для новых проектов…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Интеграция Doctrine в kohana 3