Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 97
С одной стороны все верно…
вот только что вздумал блог сделать — поставил себе вордпресс. ушло минут 10 на все и про все… самому писать долго что-то подобное, а тут уже готово…
И со многими вещами так…
Но все же… велосипеды я изобретать не перестану… так появляется какой-то азарт, стремление, интерес… отсюда и появляется в некоторой части опыт…
Одно дело когда спешишь, работа не ждет — можно и склепать все на давно изобретенных велосипедах, на которых прекрасно «кататься»
А вот посидеть, и поиздеваться над своей головой, когда есть лишнее время, иногда это доставляет кучу положительных эмоций)
вот только что вздумал блог сделать — поставил себе вордпресс. ушло минут 10 на все и про все… самому писать долго что-то подобное, а тут уже готово…
И со многими вещами так…
Но все же… велосипеды я изобретать не перестану… так появляется какой-то азарт, стремление, интерес… отсюда и появляется в некоторой части опыт…
Одно дело когда спешишь, работа не ждет — можно и склепать все на давно изобретенных велосипедах, на которых прекрасно «кататься»
А вот посидеть, и поиздеваться над своей головой, когда есть лишнее время, иногда это доставляет кучу положительных эмоций)
Конечно, для саморазвития — сколько угодно!
Но я просто намекаю на то, что для общества в целом будет полезно два варианта развития событий:
1. У вас появляется революционная идея, вы реализовываете её и становитесь чертовски популярны, девушки бросаются на вас на улице и требуют оставить автограф на груди и т.д…
2. У вас нет времени/фантазии придумывать что-то новое, так что вы присоединяетесь к существующему проекту, который сами используете, и помогаете развивать его — тем самым реализовывая свои творческие потребности.
А сейчас у многих получается так: времени/фантазии придумывать что-то новое нет, поэтому я напишу свой шаблонизатор/DAO/ORM…
Но я просто намекаю на то, что для общества в целом будет полезно два варианта развития событий:
1. У вас появляется революционная идея, вы реализовываете её и становитесь чертовски популярны, девушки бросаются на вас на улице и требуют оставить автограф на груди и т.д…
2. У вас нет времени/фантазии придумывать что-то новое, так что вы присоединяетесь к существующему проекту, который сами используете, и помогаете развивать его — тем самым реализовывая свои творческие потребности.
А сейчас у многих получается так: времени/фантазии придумывать что-то новое нет, поэтому я напишу свой шаблонизатор/DAO/ORM…
1.
— вы реализовываете чтото революционное, схорошим качестовом исполнения и… ничего. вы выкладываете проект sf/gc и снова ничего. вы пишите документацию, перводите код на свободную лицензию и снова пусто.
— вы делаете чтото, низкого качества, с кучей ошибок и начинаете пиариться (привет доктрина) и у вас появляется все о чем пишется в пункте 1
2.
если у вас нет фантазии — то какой же вы программист, идите на завод, тут нужно думать и придумывать.
а если уж вектор вашей фантазии совпал еще с чьим то вектором, то это просто замечательно ;)
люди учатся и это нормально, вы сами сказали что поступали так же… проявите снисхождение к начинающим.
— вы реализовываете чтото революционное, схорошим качестовом исполнения и… ничего. вы выкладываете проект sf/gc и снова ничего. вы пишите документацию, перводите код на свободную лицензию и снова пусто.
— вы делаете чтото, низкого качества, с кучей ошибок и начинаете пиариться (привет доктрина) и у вас появляется все о чем пишется в пункте 1
2.
если у вас нет фантазии — то какой же вы программист, идите на завод, тут нужно думать и придумывать.
а если уж вектор вашей фантазии совпал еще с чьим то вектором, то это просто замечательно ;)
люди учатся и это нормально, вы сами сказали что поступали так же… проявите снисхождение к начинающим.
У меня такое впечатление, что мы говорим об одном и том же, только разными словами :)
Только вопросы маркетинга я не обсуждал. Я исхожу из того, что если проект хороший, сообщество поддержет его автоматически. На практике — это не так, любой проект нуждается в раскрутке. Просто это отдельная тема.
Только вопросы маркетинга я не обсуждал. Я исхожу из того, что если проект хороший, сообщество поддержет его автоматически. На практике — это не так, любой проект нуждается в раскрутке. Просто это отдельная тема.
к сожалению нет, в ваших словах содержиться только часть истины, для полной картины не стоит принебрегать реальными условиями, например тем что сообщество сначало нужно создать.
Хм, мне казалось, что сообщество уже есть.
Как минимум два его кусочка сейчас сидят и «сотрясают электроны» на этих страницах :)
Я не пытаюсь смоделировать развитие сферического общества PHP-девелоперов в вакууме.
Я просто озвучиваю свои личные соображения по поводу того, какая ситуация уже сложилась на данный момент и в каком направлении нам следует двигаться дальше, как обществу в целом.
Как минимум два его кусочка сейчас сидят и «сотрясают электроны» на этих страницах :)
Я не пытаюсь смоделировать развитие сферического общества PHP-девелоперов в вакууме.
Я просто озвучиваю свои личные соображения по поводу того, какая ситуация уже сложилась на данный момент и в каком направлении нам следует двигаться дальше, как обществу в целом.
Согласен с автором, но не во всем.
За всё время существования, действительно ничего серьезного не вышло и не улучшилось.
И согласен с автором, действительно зачем изобретать велик, когда лучше взять готовый инстумент от «производителя».
Но не согласен с чем.
Гомнокодеры, просто сбили цену на инженеров. Они клепают подделки БЕЗ изменений в архитектуре.
Посмотрите куда либо вокруг. Возьмем, к примеру, cms, все одинаковые — отличия чисто косметические, архитектура как была реляционная денормализованная, так и осталась. Нового ничего нет, итог — нет в принципе нормальной cms. И также в других областях.
Я не против zfw, даже «за», но он опять же заставляет идти по старой дорожке. Т.е. если надо старая архитектура, то он, как инструмент, очень сильно поможет. Если у вас новая АРХИТЕКТУРА, он тоже поможет, если вы «выдерете» из него то что вам надо.
Я согласен с автором насчет zfw. Лучше поддерживать fw от «производителя», возможно и отстающего на начальном этапе.
За всё время существования, действительно ничего серьезного не вышло и не улучшилось.
И согласен с автором, действительно зачем изобретать велик, когда лучше взять готовый инстумент от «производителя».
Но не согласен с чем.
Гомнокодеры, просто сбили цену на инженеров. Они клепают подделки БЕЗ изменений в архитектуре.
Посмотрите куда либо вокруг. Возьмем, к примеру, cms, все одинаковые — отличия чисто косметические, архитектура как была реляционная денормализованная, так и осталась. Нового ничего нет, итог — нет в принципе нормальной cms. И также в других областях.
Я не против zfw, даже «за», но он опять же заставляет идти по старой дорожке. Т.е. если надо старая архитектура, то он, как инструмент, очень сильно поможет. Если у вас новая АРХИТЕКТУРА, он тоже поможет, если вы «выдерете» из него то что вам надо.
Я согласен с автором насчет zfw. Лучше поддерживать fw от «производителя», возможно и отстающего на начальном этапе.
Говнокодеры есть везде — и на Джаве, и в ДотНете. Просто у этих порог вхождения повыше, чем у PHP, так что говнокодеры не так бросаются в глаза. Но их я в рассчет не беру, статью писал совсем не для них :)
А что значит «старая архитектура» в контексте ZF?
Хотя нет, меня даже больше интересует, что такое «новая архитектура» в вашем понимании?
А что значит «старая архитектура» в контексте ZF?
Хотя нет, меня даже больше интересует, что такое «новая архитектура» в вашем понимании?
Очень правильный крик души :) Поддерживаю!
Вобщем, согласен с автором. Конечно, лучше улучшать существующие фрейморки (коих уже сейчас для PHP накопилась уйма). Проблема в документации. Я посмотрел все популяные фрейморки (CodeIgniter, CakePhp, Symfony, Zend, Kohana) и много CMS систем (Drupal, Joomla, SilverStripe) но проблема в большинсте одна — рабочая документация.
Как и в натуральном PHP много примеров дается как смесь HTML с кодом — начинающие программисты привыкают к этому. И много от этого проблем. В последнее время больше стало описаний API и CookBooks, но тут тоже есть проблемы:
Решил попробывать Symfony — один из мощных PHP-фрейморков — взял за основу книжку по созданию приложения askeet. После пары уроков начались ошибки — из серии «QuestionForm not found» — это отбивает вякую охоту разбираться — тем более с наскоку так не въехать «что да почему».
Я к тому — чтобы подвигнуть себя и других разработчиков — надо создание большей документации, примеров использования, скринкастов и готовых плагинов — а без этого сложно все…
Как и в натуральном PHP много примеров дается как смесь HTML с кодом — начинающие программисты привыкают к этому. И много от этого проблем. В последнее время больше стало описаний API и CookBooks, но тут тоже есть проблемы:
Решил попробывать Symfony — один из мощных PHP-фрейморков — взял за основу книжку по созданию приложения askeet. После пары уроков начались ошибки — из серии «QuestionForm not found» — это отбивает вякую охоту разбираться — тем более с наскоку так не въехать «что да почему».
Я к тому — чтобы подвигнуть себя и других разработчиков — надо создание большей документации, примеров использования, скринкастов и готовых плагинов — а без этого сложно все…
За всех отвечать не буду, скажу только за Zend Framework.
На данный момент с документацией у него всё отлично.
Есть полное руководство (и даже частично на русском, хотя лично я настоятельно рекоммендую читать документацию исключительно на английском).
Есть краткий обзор компонентов.
Есть QuickStart в Wiki.
И, наконец, есть отдельный раздел Multimedia со всякими скринкастами и т.д.
На данный момент с документацией у него всё отлично.
Есть полное руководство (и даже частично на русском, хотя лично я настоятельно рекоммендую читать документацию исключительно на английском).
Есть краткий обзор компонентов.
Есть QuickStart в Wiki.
И, наконец, есть отдельный раздел Multimedia со всякими скринкастами и т.д.
А если у вашего любимого фреймворка по каким-то причинам с документацией плохо — это как раз замечательный повод помочь развитию проекта. Если вы разобрались сами — помогите разобраться остальным и напишите документацию. Именно такие «маленькие подвиги» приносят в тысячи раз больше пользы, чем очередные велоразработки.
Незнаю, имхо проблема восприятия PHP как языка кухарок — реальная проблема, но она существует уже давно, и я верю что когда-нибудь она сойдет на нет, а вот проблема придумывания велосипедов — проблема надуманная, и на том-же хабре (хотя в меньшей степени) или на каком-нибудь специализированном форуме по PHP — конечно хреновы миллионы непризнанных гениев, хвастающихся своими велосипедами (как в матрице, огромное поле, а там кабачками PHP-девелоперы: P), но это-же все новички, тот кто занимается программированием на PHP давно — давно уже все для себя решил, и имеет собственные готовые програмные решения на любой случай жизни. Мне лично наоборот не нравится тенденция «ухты, а тут все готовенькое, сейчас я это себе в код впихну», если уж и используешь чужой код — то его хотя-бы для начала нужно досконально изучить и понять, и быть в состоянии написать с нуля если не лучше, то хотя-бы также, иначе это не программирование, а собирание конструктора лего. Хотя в чем-то конечно соглашусь, Zend Framework далеко не самое худшее, что есть на PHP, и его хорошо-бы по-больше разрекламировать, чтобы кабачков-велосипедистов впоследствии стало меньше :)
Полностью согласен. Прежде чем использовать сторонние библиотеки, нужно понимать, как они работают. Но не всегда. Например, лично мне глубоко фиолетово, как работает Zend_Pdf и у меня нет никакого желания вникать в это дело — уж простите :)
Фреймворк — не панацея. Он не сделает из новичка гуру. Но фреймворк приучит новичка к хорошему стилю программирования и общепринятым архитектурным приёмам разработки. Если новичок обладает потенциалом, набравшись опыта он сам копнёт глубже в код самого фреймворка из любопытства и узнает, как же там всё устроено внутри :)
Фреймворк — не панацея. Он не сделает из новичка гуру. Но фреймворк приучит новичка к хорошему стилю программирования и общепринятым архитектурным приёмам разработки. Если новичок обладает потенциалом, набравшись опыта он сам копнёт глубже в код самого фреймворка из любопытства и узнает, как же там всё устроено внутри :)
Не всем хватает усидчивости, чтобы внимательно изучить фреймворк. Гораздо проще нашлёпать своих скриптов и получить результат через полчаса, чем потратить день на изучение фреймворка и получить тот же результат за пять минут.
Утрирую, конечно, но смысл понятен. :)
Утрирую, конечно, но смысл понятен. :)
Всё верно, именно так и поступает большинство девелоперов на данный момент.
Но это не потому, что все они ленивые или глупые.
Это потому, что раньше небыло мейнстримного фреймворка, который бы все знали «с детства» и который бы предоставлял полный набор типичных решений для веб-разработчика.
Есть ли такой фреймворк сейчас? Ну, как вы уже поняли из этой статьи, я вижу Zend Framework как зародышь этого мейнстримного фреймворка. Именно поэтому я стараюсь популяризировать его, привлечь к нему больше девелоперов. Ведь чем больше девелоперов будет использовать его, тем больше девелоперов захотят принять участие в его разработке, тем качественнее и продуманнее будет его архитектура и т.д.
Если вам не нравится ZF по каким-то причинам — это ваше право, выберите фреймворк по вкусу и поддерживайте его: пишите багрепорты, присылайте патчи, записывайте скринкасты и т.д.
Только умоляю — больше не изобретайте велосипедов!
PS. Это не к вам лично, разумеется :)
Но это не потому, что все они ленивые или глупые.
Это потому, что раньше небыло мейнстримного фреймворка, который бы все знали «с детства» и который бы предоставлял полный набор типичных решений для веб-разработчика.
Есть ли такой фреймворк сейчас? Ну, как вы уже поняли из этой статьи, я вижу Zend Framework как зародышь этого мейнстримного фреймворка. Именно поэтому я стараюсь популяризировать его, привлечь к нему больше девелоперов. Ведь чем больше девелоперов будет использовать его, тем больше девелоперов захотят принять участие в его разработке, тем качественнее и продуманнее будет его архитектура и т.д.
Если вам не нравится ZF по каким-то причинам — это ваше право, выберите фреймворк по вкусу и поддерживайте его: пишите багрепорты, присылайте патчи, записывайте скринкасты и т.д.
Только умоляю — больше не изобретайте велосипедов!
PS. Это не к вам лично, разумеется :)
Я к ZF отношусь вполне хорошо. Слежу за ним, если память не изменяет, с апреля 2006 года. :)
Проблема маленько в другом как мне видится. Когда человек ставит ту же Java и пытается начать на ней что-то писать посерьёзнее System.out.println(«Hello, world!»); так или иначе придётся обращаться к документации. Просто так сделать то же окошко с кнопками и минимальной обработкой событий не получится. А уж в документации все классы, объекты, структуры подробно расписаны с красивыми примерами. И невольно начинаешь следовать стилю, увиденному в документации. :)
В случае с PHP всё гораздо проще: нарисовал страничку, воткнул в неё код и вот она, радость на экране. Конечно, потом если человек пойдёт дальше, он дойдёт до шаблонизаторов, паттернов и прочих необходимых инструментов. Но путь этот может быть очень долгим. :)
Ваша мысль про велосипеды понятна и в ней есть большая доля истины. Но как говорится, со своего огорода яблочки вкуснее, а велосипед свой, но с сиденьем лучше общедворового без сиденья, но зато с катафотами и брызговиками. ;)
P.S. с ZF да, запоздали ребята. Но ничего, ниша ещё не занята. :)
Проблема маленько в другом как мне видится. Когда человек ставит ту же Java и пытается начать на ней что-то писать посерьёзнее System.out.println(«Hello, world!»); так или иначе придётся обращаться к документации. Просто так сделать то же окошко с кнопками и минимальной обработкой событий не получится. А уж в документации все классы, объекты, структуры подробно расписаны с красивыми примерами. И невольно начинаешь следовать стилю, увиденному в документации. :)
В случае с PHP всё гораздо проще: нарисовал страничку, воткнул в неё код и вот она, радость на экране. Конечно, потом если человек пойдёт дальше, он дойдёт до шаблонизаторов, паттернов и прочих необходимых инструментов. Но путь этот может быть очень долгим. :)
Ваша мысль про велосипеды понятна и в ней есть большая доля истины. Но как говорится, со своего огорода яблочки вкуснее, а велосипед свой, но с сиденьем лучше общедворового без сиденья, но зато с катафотами и брызговиками. ;)
P.S. с ZF да, запоздали ребята. Но ничего, ниша ещё не занята. :)
Лично мне вот не верится, что проблема эта сойдет на нет. Точнее, проблемы, как таковой нет. PHP занимает вакантную нишу «простого языка веб-программирования». Ни Java, ни .NET, ни Python, ни Perl, ни Ruby, ни {your_favourite_language} на нишу эту не претендуют (причем, по совершенно разным причинам).
На это главная ставка создателей языка — сделать его максимально доступным. И я не вижу в этом ничего плохого: сейчас легче найти и поддерживать проект на PHP, чем на чем-либо другом, хотя по деньгам выйдет примерно так же.
Если PHP станет (а, имхо, уже стал) де-факто основным языком программирования в вебе — я буду только за. Ибо нужен какой-то базис, какая-то общепризнанная платформа. До PHP ее не было.
На это главная ставка создателей языка — сделать его максимально доступным. И я не вижу в этом ничего плохого: сейчас легче найти и поддерживать проект на PHP, чем на чем-либо другом, хотя по деньгам выйдет примерно так же.
Если PHP станет (а, имхо, уже стал) де-факто основным языком программирования в вебе — я буду только за. Ибо нужен какой-то базис, какая-то общепризнанная платформа. До PHP ее не было.
Проблемой я считаю неэффективное использование умственных ресурсов. Вместо того, чтобы сделать что-то общественно полезное, мы тратим время не изобретение велосипедов, которые никому (и в первую очередь — нам самим, просто мы этого ещё не понимаем) не нужны. Можно посмотреть на это так: лучше потратить год на вынашивание и реализацию уникальной идеи, которую до вас никто не реализовывал, чем раз в месяц «выхлопывать» очередной конструктор форм.
Если вам нужен конструктор форм — выберите наиболее подходящий для вас из существующих. С вероятностью 99% он не будет вас устраивать полностью. Но вместо того, чтобы сесть и написать свой (что, конечно, намного проще), лучше помогите авторам максимально подходящего готового решения довести его до ума. Почитайте документацию или в конце концов просто спросите у авторов, почему они не реализовали той функциональности, которой вам нехватает? Есть большая вероятность, что либо вы просто не до конца разобрались, либо вы вообще пошли не той дорогой и хотите того, чего не следует хотеть :) Это я всё говорю из личного опыта.
В любом случае, авторы библиотеки наверняка с удовольствием направят вас в нужном направлении.
Если вам нужен конструктор форм — выберите наиболее подходящий для вас из существующих. С вероятностью 99% он не будет вас устраивать полностью. Но вместо того, чтобы сесть и написать свой (что, конечно, намного проще), лучше помогите авторам максимально подходящего готового решения довести его до ума. Почитайте документацию или в конце концов просто спросите у авторов, почему они не реализовали той функциональности, которой вам нехватает? Есть большая вероятность, что либо вы просто не до конца разобрались, либо вы вообще пошли не той дорогой и хотите того, чего не следует хотеть :) Это я всё говорю из личного опыта.
В любом случае, авторы библиотеки наверняка с удовольствием направят вас в нужном направлении.
Вот тут возникает простой вопрос — вы как отделяете полезные идеи от неполезных? Я понимаю. что Зенд зажег вам факел и теперь ничего вокруг не имеет смысла кроме огня в конце туннеля, но КАК вы определяете что то или иное решение велосипед, а не истинный перл?
Субъективно. Если решение основано на какой-то новой идее, ранее никем не реализованной, то это интересно. А если же решение ничем не отличается от конкурентов кроме названий методов (образно выражаясь), то для меня ценность такого решения очень сомнительна.
Только оставьте этот сарказм. Я нисколько не скрываю своей приверженности ZF'у, но я потрудился и аргументировал свою точку зрения. Zend (а точнее два его основателя) курировали разработку PHP начиная с PHP/FI 2. Вы можете назвать компанию, которая бы разбиралась в архитектуре PHP лучше, чем Zend? Если нет, то я не вижу причин не доверять Zend'у разработку мейнстримного фреймворка для их родного языка.
Обратите внимание — в первую очередь я призываю людей не велосипедить. А уже после этого, если кто-то захочет примкнуть к сообществу ZF-девелоперов — я буду только рад.
Только оставьте этот сарказм. Я нисколько не скрываю своей приверженности ZF'у, но я потрудился и аргументировал свою точку зрения. Zend (а точнее два его основателя) курировали разработку PHP начиная с PHP/FI 2. Вы можете назвать компанию, которая бы разбиралась в архитектуре PHP лучше, чем Zend? Если нет, то я не вижу причин не доверять Zend'у разработку мейнстримного фреймворка для их родного языка.
Обратите внимание — в первую очередь я призываю людей не велосипедить. А уже после этого, если кто-то захочет примкнуть к сообществу ZF-девелоперов — я буду только рад.
Идея правильная; разве что, наверное, под многократно упомянутым обществом всё же подразумевалось сообщество. ;-)
2 года назад просил писать свой «фреймворк» ;) поигрался и хватит.
проще писать екстенды к существующим :) на работе Зенд, дома Кейк :)
проще писать екстенды к существующим :) на работе Зенд, дома Кейк :)
Разделяю взгляды автора. Даже пример приведу:
Достался мне в наследство один проект, который до меня делали года два на Java и никак доделать не смогли. Заказчику кто-то сказал, что проекты на Java или .NET это круто и профессионально. Тем не менее я убедил его переписать всё на PHP и наконец вдохнуть в проект жизнь после двух лет застоя. И не смотря на сжатые сроки я рад, тем более что разработка отлично продвигается благодаря Zend Framework.
Достался мне в наследство один проект, который до меня делали года два на Java и никак доделать не смогли. Заказчику кто-то сказал, что проекты на Java или .NET это круто и профессионально. Тем не менее я убедил его переписать всё на PHP и наконец вдохнуть в проект жизнь после двух лет застоя. И не смотря на сжатые сроки я рад, тем более что разработка отлично продвигается благодаря Zend Framework.
Без обид, но я совершенно не об этом писал :)
Переписать проект с нуля на другой ЯП — это далеко не всегда самая удачная идея.
Но всё зависит от конкретного проекта, конечно же.
В любом случае, рад что у вас всё получается ;)
Переписать проект с нуля на другой ЯП — это далеко не всегда самая удачная идея.
Но всё зависит от конкретного проекта, конечно же.
В любом случае, рад что у вас всё получается ;)
Конечно не об этом. Видимо, я не точно выразился.
Я ни в коем случае не против Java или других, но я PHP разработчик в первую очередь :). Но переписывать взялся не от нечего делать, а от того, что я (или кто-то другой) потратили бы столько-же, а скорее всего даже больше времени на исправление и доработку старой версии.
А сказать я хотел о том, что Zend Framework мне помогает сделать проект, таким, каким он должен быть.
P.S. недавно нашёл баг в Zend Framework. может вы подскажете (например в качестве дополнения к посту) куда и что написать с целью устранения бага
Я ни в коем случае не против Java или других, но я PHP разработчик в первую очередь :). Но переписывать взялся не от нечего делать, а от того, что я (или кто-то другой) потратили бы столько-же, а скорее всего даже больше времени на исправление и доработку старой версии.
А сказать я хотел о том, что Zend Framework мне помогает сделать проект, таким, каким он должен быть.
P.S. недавно нашёл баг в Zend Framework. может вы подскажете (например в качестве дополнения к посту) куда и что написать с целью устранения бага
Легко!
Идёте на Зендовский Issue Tracker и регистрируетесь.
Входите в систему под вашей учетной записью и в верхнем меню клацаете на «Create New Issue».
Дальше, думаю, всё будет понятно.
Если будут вопросы — пишите в личку, подскажу.
Идёте на Зендовский Issue Tracker и регистрируетесь.
Входите в систему под вашей учетной записью и в верхнем меню клацаете на «Create New Issue».
Дальше, думаю, всё будет понятно.
Если будут вопросы — пишите в личку, подскажу.
Единственный толковый топик про PHP за последний год.
В свое время на выбор мной именно ZF повлияла цитата с одного из php форумов:
думаю, что в ней есть доля истины :) Автору за топик плюс :)
ZendFramework это некое подобие PEAR, только в разработке компании Zend и специально под PHP 5. Скорее всего, это будущее PHP
думаю, что в ней есть доля истины :) Автору за топик плюс :)
С одной стороны, абсолютно не согласен с критикой. Пусть пишут, если хотят.
С другой, вложение в общее дело мне кажется отличной альтернативой этому.
С другой, вложение в общее дело мне кажется отличной альтернативой этому.
Разработчик может саморазвиваться, изобретая велосипеды.
Такой подход принесёт довольно ограниченную пользу, причем лишь ему одному.
А если немного поднапрячься и включить соображалку, можно найти более достойное применение собственным мозгам и не просто улучшать свои навыки кодерства, но и учиться работать в команде, критически оценивать свой код и код других, внося свой вклад в развитие сообщества разработчиков в целом.
Конечно же, какой дорогой стоит идти — каждый решает сам для себя.
Такой подход принесёт довольно ограниченную пользу, причем лишь ему одному.
А если немного поднапрячься и включить соображалку, можно найти более достойное применение собственным мозгам и не просто улучшать свои навыки кодерства, но и учиться работать в команде, критически оценивать свой код и код других, внося свой вклад в развитие сообщества разработчиков в целом.
Конечно же, какой дорогой стоит идти — каждый решает сам для себя.
Пост — набор клише, имхо. И непонятно к кому это всё обращено? Опытные девелоперы уже научились пользоваться чужими наработками, а новички — не думаю, что на них это подействует. Да и одно дело изобретать велосипед, другое — писать что-то для получения разностороннего опыта.
В моём окружении достаточно много людей, которых я считаю профессиональными разработчиками, но которые по разнообразным личным убеждениям любят изобретать велосипедыт. Оправданий они придумывают огромное количество (ещё бы, соображалка ведь у них хорошо работает :)), но ИМХО всё сводится к обыкновенному эго: «я же сам девелопер матёрый, зачем мне брать чужую библиотеку, когда я могу собственную написать?».
Я не могу никого заставить изобретать велосипеды.
Я лишь взываю к здравому смыслу и намекаю, что есть куда более интересные и полезные вещи, которым стоит уделить своё время.
Я прекрасно понимаю, что новый разработчик не может просто прочитать мою статью, проникнуться, три года не писать ни строчки кода (ведь всё уже написано за него!), а потом выдать какой-то шедевр, от которого у сообщества челюсти попадают.
Велосипедостроение — это часть нормального процесса развития разработчика.
Художники, к примеру, в первую очередь учатся создавать репродукции известных мастеров, чтобы освоить технику, а уже потом начинают реализовывать собственные идеи.
Просто, по-моему, разработчик к своим велосипедам должен относиться очень критично. Сравнивать его с готовыми решениями, оценивать все плюсы и минусы, задумываться над архитектурными ограничениями и пытаться понять, почему разработчики общедоступной библиотеки решили эту задачу именно таким образом? Возможно, они изначально выбрали неверную архитектуру и теперь уже не могут исправить её без нарушения обратной совместимости? А может это вы не до конца поняли хитрый замысел автора, который своим нестандартным решением обошел целую кучу проблем, которые могли потенциально возникнуть в дальнейшем развитии библиотеки?
ИМХО, именно задавая себе подобные вопросы, разработчик начинает по-настоящему развиваться.
Я не могу никого заставить изобретать велосипеды.
Я лишь взываю к здравому смыслу и намекаю, что есть куда более интересные и полезные вещи, которым стоит уделить своё время.
Я прекрасно понимаю, что новый разработчик не может просто прочитать мою статью, проникнуться, три года не писать ни строчки кода (ведь всё уже написано за него!), а потом выдать какой-то шедевр, от которого у сообщества челюсти попадают.
Велосипедостроение — это часть нормального процесса развития разработчика.
Художники, к примеру, в первую очередь учатся создавать репродукции известных мастеров, чтобы освоить технику, а уже потом начинают реализовывать собственные идеи.
Просто, по-моему, разработчик к своим велосипедам должен относиться очень критично. Сравнивать его с готовыми решениями, оценивать все плюсы и минусы, задумываться над архитектурными ограничениями и пытаться понять, почему разработчики общедоступной библиотеки решили эту задачу именно таким образом? Возможно, они изначально выбрали неверную архитектуру и теперь уже не могут исправить её без нарушения обратной совместимости? А может это вы не до конца поняли хитрый замысел автора, который своим нестандартным решением обошел целую кучу проблем, которые могли потенциально возникнуть в дальнейшем развитии библиотеки?
ИМХО, именно задавая себе подобные вопросы, разработчик начинает по-настоящему развиваться.
Я не могу никого заставить изобретать велосипеды.Тут должно было бы «Я не могу никого заставить перестать изобретать велосипеды».
Развиваться, решая проблемы, которые ещё не решены, не решив при этом проблем, которые решены другими — сомнительная ветвь эволюции. На пальцах это значит, что чтобы понять как передаются переменные по ссылке — надо написать какой-нибудь велосипед. Чтобы понять как работает ob_handler — тоже. Чтобы понять что такое паттерны программирования — тоже следует что-нить велосипедоподобное написать. Если не писать велосипеды, то в голове разраба будет сквозить мысль «у какая интересная технология, где бы её применить? хм, а вот сюда воткну, пофиг, что ещё её не пробовал нигде и задачу не решал ни разу, походу разберёмся».
То есть в любом случае, чтобы создать ХОРОШИЙ и НОВЫЙ код, то лучше сначала создать хороший и старый код, плохой и новый код, имхо, хуже — лучше постоянно писать хороший код, чем новый. А то будет так, что кто первый написал и выложил какую-то либу — того и тапки. Пофиг, что код плохой — он ведь быстрее всех написал НОВЫЙ код:)
Нет, я не против новых подходов и развития библиотек — я против огульного «бега вперёд». Хотя ещё больше против сидения на месте, но из Junior'а за 3 месяца ОЧЕНЬ сложно сделать Senior'а без прописывания человеком велосипедных задач — он просто не успеет перестроить мозги и понять на практике чем хороши комментарии в коде, как нужно оптимизировать, как использовать ООП и паттерны программирования и так далее.
То есть в любом случае, чтобы создать ХОРОШИЙ и НОВЫЙ код, то лучше сначала создать хороший и старый код, плохой и новый код, имхо, хуже — лучше постоянно писать хороший код, чем новый. А то будет так, что кто первый написал и выложил какую-то либу — того и тапки. Пофиг, что код плохой — он ведь быстрее всех написал НОВЫЙ код:)
Нет, я не против новых подходов и развития библиотек — я против огульного «бега вперёд». Хотя ещё больше против сидения на месте, но из Junior'а за 3 месяца ОЧЕНЬ сложно сделать Senior'а без прописывания человеком велосипедных задач — он просто не успеет перестроить мозги и понять на практике чем хороши комментарии в коде, как нужно оптимизировать, как использовать ООП и паттерны программирования и так далее.
Тогда давайте сойдемся на том, что в крайности вдаваться не надо.
Плохо сидеть на месте и только тем и заниматься, что писать велосипеды.
Но и написать качественный новый код, не изучив и не отработав на практике старые приёмы тоже не получится.
Во всём нужно знать меру.
Кстати…
Ничего плохого в этом на самом деле не вижу :)
Лучше плохой код, который «gets the job done», чем хороший код, которого нет :)
Или чем абстрактный код кристальной чистоты, который на практике применить невозможно.
Так что можно (а иногда даже нужно) начинать с «плохого» кода, который работает, а затем уже рефакторить его и доводить до ума. То, что рефакторингом на практике мало кто занимается и «на это нет времени» — это уже другая тема…
Плохо сидеть на месте и только тем и заниматься, что писать велосипеды.
Но и написать качественный новый код, не изучив и не отработав на практике старые приёмы тоже не получится.
Во всём нужно знать меру.
Кстати…
А то будет так, что кто первый написал и выложил какую-то либу — того и тапки. Пофиг, что код плохой — он ведь быстрее всех написал НОВЫЙ код:)
Ничего плохого в этом на самом деле не вижу :)
Лучше плохой код, который «gets the job done», чем хороший код, которого нет :)
Или чем абстрактный код кристальной чистоты, который на практике применить невозможно.
Так что можно (а иногда даже нужно) начинать с «плохого» кода, который работает, а затем уже рефакторить его и доводить до ума. То, что рефакторингом на практике мало кто занимается и «на это нет времени» — это уже другая тема…
Спасибо, практически со 100% точностью вы передали и мои мысли (:
Я частично согласен, частично нет.
Советую прочесть один рассказ Азика Азимова — «Профессия»
Советую прочесть один рассказ Азика Азимова — «Профессия»
Эх, вдохновился, и в очередной раз пошел разбирать Zend Framework…
Если бы все думали так же. Вообще, каждый программист неизбежно проходит через стадию «напиши свою ОС/фреймворк/еще-что-нибудь». Это нормально, это дает понимание того, что велосипеды изобретать в большинстве случаев нет смысла (или не дает, но тут уж ничего не поделаешь), это дает толчок идти вперед, развиваться.
Круто делать самому такие штуки как зенд, а не использовать готовое :)
Хотя кому что по силам :)
Хотя кому что по силам :)
А по-моему по-настоящему круто — уметь делать самому такие штуки, как ZF, но не создавать «второй ZF», а присоединится к разработке существующего, чтобы вычищать баги и оптимизировать только одну базу кода.
Вы представьте себе, что было бы с Линуксом, если бы каждый продвинутый девелопер форкал (или ещё хуже — писал бы с нуля!) кернел?
Совместная работа над одним проектом — это синергетическая штука. Ведь лучше десяти разработчикам объединиться и написать один фреймворк, а потом совместно поддерживать его, чем каждый из них напишет по фреймворку для себя.
Вы представьте себе, что было бы с Линуксом, если бы каждый продвинутый девелопер форкал (или ещё хуже — писал бы с нуля!) кернел?
Совместная работа над одним проектом — это синергетическая штука. Ведь лучше десяти разработчикам объединиться и написать один фреймворк, а потом совместно поддерживать его, чем каждый из них напишет по фреймворку для себя.
Угу. Абсолютно согласен. Только почему-то после недели осваивания пайтона с джанго в сторону РНР смотреть вообще не хочется.
Я так тоже раньше думал. В реальности же, обычный проект дешевле и проще делать на PHP (используя фреймворк, разумеется), чем на Django. А крупный проект выгоднее делать на RoR. Там нормальная система обновления схем БД, в отличие от Djangoвского ORM, к которому хоть и приделали костыльки на эту тему, да плоховатенько. Смысла же ставить на Django SQLAlchemy (или другой ORM) особого нет, теряются абсолютно все вкусности Django (админка в первую очередь). И брюки превращаются в элегантные шорты, а Django в обычный фреймворк.
З.Ы. Но Python жжот :)
З.Ы. Но Python жжот :)
Простой однозначно быстрее получится на python-e.
А что касается миграций — да, такого в джанго пока нет. Как вариант — написать свое. Там кода не много — просто парсинг каталога с файлами вида 1.sql, 2.sql итд — писал такое для PHP.
Кстати жанго не только орм/админка. А еще отличнейшая система шаблонов.
А вот с РоРом не работал, к сожалению.
А что касается миграций — да, такого в джанго пока нет. Как вариант — написать свое. Там кода не много — просто парсинг каталога с файлами вида 1.sql, 2.sql итд — писал такое для PHP.
Кстати жанго не только орм/админка. А еще отличнейшая система шаблонов.
А вот с РоРом не работал, к сожалению.
Если бы все было так просто с миграциями ))))) Имеется ввиду миграция вида: «изменил класс модели — вызвал команду — база изменилась». А шаблоны есть в любом фреймворке.
code.djangoproject.com/wiki/SchemaEvolution
Тут это в принципе описано подробно ) Но будет ли это реализовываться — фиг знает )
Пока приходится ручками делать дифы )
Тут это в принципе описано подробно ) Но будет ли это реализовываться — фиг знает )
Пока приходится ручками делать дифы )
Ну что за нравы — влезли со своим Питоном в закрытый хабратопик про PHP :)
Шучу, шучу, питон — классная штука, сам его щупаю понемногу.
Шучу, шучу, питон — классная штука, сам его щупаю понемногу.
Вот-вот. На самом деле есть сторонняя утилита. Говорят работает. Я не стал пробовать :)
Я, когда писал шаблонизатор, очень тесно познакомился с регулярными выражениями. По-моему хороший опыт. Ну как-то понятнее мне всё своё, не знаю почему.
Не знаю я сам когдат пробовал изобретать велосипеды, но потом не нашел в этом смысла ведь есть Zend FrameWork, Symfony FrameWork, Doctrine(ИМХО) мне с ними удобнее работать и всё изобретено до нас))
Уважаемый автор, а не желаете ли вы на самых распростецких, но в тоже время увлекательных примерах показать какие пряники несёт в себе ZF? Я давно работаю на связке pear+smarty + свой заезженый (но гибкий при этом) архитектурный велосипед. Меня в общем почти всё устраивает. Я знаю как и что сделать. Где что погнуть чтоб поехать прямо. НО. меня не устраивает время разработки. Это не потому что я чудовищно ленивый и тормозной, это потому что гнуть действительно приходится часто и довольно много. Я думаю общественность будет только «за» пару постов в ключе «ZF это вкусно и полезно!!».
з.ы. нет мне не лень читать мануал, просто меня он не впечатляет :)
з.ы. нет мне не лень читать мануал, просто меня он не впечатляет :)
На официальном сайте есть скринкасты и QuickStart — рекоммендую ознакомиться, т.к. что бы я сейчас ни начал писать — это будет копипейстинг официального мануала.
Если будет настроение, попозже подготовлю хабрастатью с примерами мелких полезностей, которые предоставляет ZF.
Но тут как бы на словах тяжело передать все прелести.
Просто прежде чем использовать ZF (как и любой другой фреймворк), надо сначала почистить свой мозг от «мусора» предыдущего опыта и принять, хотя бы на время, архитектурные взгляды разработчиков фреймворка.
И уже потом, когда вникните во всё, оценивать, лучше он или хуже, чем ваши собственные наработки.
Очень распространенной ошибкой является попытка заточить фреймворк под собственную архитектуру. В особенно запущенных случаях вреда от фреймворка становится больше, чем пользы, потому что разработчик кучу времени тратит на написание разнообразных адаптеров (в лучшем случае) или на переписывание большей половины классов с нуля (в худшем).
ИМХО, когда начинаешь знакомиться с фреймворком, надо полностью следовать его идеологии.
В итоге, либо она устраивает тебя и ты принимаешь её, либо продолжаешь поиски своего идеального сферического фреймворка в вакууме :)
Хочешь всех плюшек коллективного разума — будь добр принять общую идеологию. К сожалению, этот фактор тоже много кого отпугивает, хотя лично я ничего страшного в этом не вижу.
Если будет настроение, попозже подготовлю хабрастатью с примерами мелких полезностей, которые предоставляет ZF.
Но тут как бы на словах тяжело передать все прелести.
Просто прежде чем использовать ZF (как и любой другой фреймворк), надо сначала почистить свой мозг от «мусора» предыдущего опыта и принять, хотя бы на время, архитектурные взгляды разработчиков фреймворка.
И уже потом, когда вникните во всё, оценивать, лучше он или хуже, чем ваши собственные наработки.
Очень распространенной ошибкой является попытка заточить фреймворк под собственную архитектуру. В особенно запущенных случаях вреда от фреймворка становится больше, чем пользы, потому что разработчик кучу времени тратит на написание разнообразных адаптеров (в лучшем случае) или на переписывание большей половины классов с нуля (в худшем).
ИМХО, когда начинаешь знакомиться с фреймворком, надо полностью следовать его идеологии.
В итоге, либо она устраивает тебя и ты принимаешь её, либо продолжаешь поиски своего идеального сферического фреймворка в вакууме :)
Хочешь всех плюшек коллективного разума — будь добр принять общую идеологию. К сожалению, этот фактор тоже много кого отпугивает, хотя лично я ничего страшного в этом не вижу.
Поддержку миграций написать для нормального фреймворка не проблема.
Полный аналог для RoR миграций был написан в компании работающей с CakePHP за неделю.
Полный аналог для RoR миграций был написан в компании работающей с CakePHP за неделю.
Согласен со всем за исключением последнего предложения. Пускай непосредственно PHP занимается Zend, а за основной фреймворк например та же Sensio со своим Symfony. Хотя основная мысль автора абсолютно верна. Не стоит писать то чем уже занимаются тысячи программеров по всему миру. Потому как для того чтобы сделать что-то более интересное нежели то что пишут они ты должен быть в тысячи раз умней и производительней среднестатистического PHP-программиста.
Проблема всех движков и CMS в том, что они рассчитаны на решение типичных задач. То есть они средне оптимизированы для всего. В этом и скрывается корень некоторых проблем, которые почему-то автор в упор не видит. наверное не писал особо сложных проектов:
1) вы не рулите библиотекой и не определяете ее развитие, это порождает основную проблему, которая не так уж редко встречается: скачиваете новую версию, заменяете старую и проект умирает, и вы не можете его оживить.
2) суппорт тысяч людей конечно дело крутое, но у семи нянек как водится дидя без глаза: с серьезных фрейморках добиться чтобы нужную вам багу пофиксили очень трудно, проходит сотня стадий, решений, потом может кто и доберется жо этого бага и пофиксит. Что делать пока его не пофиксили? Тут возникает проблема 3.
3) Вы начинаете делать заплатки (конечно де временные) и обнаруживаете, что свежие официальные патчи на ваши не становятся. Более того, новый патч фикси важную багу но не фиксит то, что пофиксили вы. Начинается геморная ручная работа с матом.
4) поскольку готовые фреймоврки предлагают типичные решения, то часто они годятся для написания проектов одного типа, ну иногда двух, все остальное начинает требовать от вас либо вмешательства в код либ (что нам не подходит по пункту 3), либо отказываться от кусков фреймворка и дописывать свои. Конечно сладкие слова автора о том, что вы де тупой, если пишите свой код, а не используете чужой, однако реалии таковы, что тот же ADODB, названный автором в качестве примера просто уложит вам намертво проект с серьезной посещаемостью. Да, там все красиво, да, там все умно — но проект будет лежать. Я очень хорошо знаком с ADODB и являюсь автором русского перевода его доки, так что знаю о чем говорю.
Поэтому статья автора однобока и в большой степени безосновательна. Если бы он перестал употреблять столь любимое им слово шаблонизатор и привел бы более существенные примеры, я думаю он бы понял что смысла в его посте нет. Хотя да, толпе он нравится и плюсуется, но взгляд этот поверхностный. Хоум пейджи клепать да, можно, но серьезный проект просто вынудит вас делать «велосипеды».
1) вы не рулите библиотекой и не определяете ее развитие, это порождает основную проблему, которая не так уж редко встречается: скачиваете новую версию, заменяете старую и проект умирает, и вы не можете его оживить.
2) суппорт тысяч людей конечно дело крутое, но у семи нянек как водится дидя без глаза: с серьезных фрейморках добиться чтобы нужную вам багу пофиксили очень трудно, проходит сотня стадий, решений, потом может кто и доберется жо этого бага и пофиксит. Что делать пока его не пофиксили? Тут возникает проблема 3.
3) Вы начинаете делать заплатки (конечно де временные) и обнаруживаете, что свежие официальные патчи на ваши не становятся. Более того, новый патч фикси важную багу но не фиксит то, что пофиксили вы. Начинается геморная ручная работа с матом.
4) поскольку готовые фреймоврки предлагают типичные решения, то часто они годятся для написания проектов одного типа, ну иногда двух, все остальное начинает требовать от вас либо вмешательства в код либ (что нам не подходит по пункту 3), либо отказываться от кусков фреймворка и дописывать свои. Конечно сладкие слова автора о том, что вы де тупой, если пишите свой код, а не используете чужой, однако реалии таковы, что тот же ADODB, названный автором в качестве примера просто уложит вам намертво проект с серьезной посещаемостью. Да, там все красиво, да, там все умно — но проект будет лежать. Я очень хорошо знаком с ADODB и являюсь автором русского перевода его доки, так что знаю о чем говорю.
Поэтому статья автора однобока и в большой степени безосновательна. Если бы он перестал употреблять столь любимое им слово шаблонизатор и привел бы более существенные примеры, я думаю он бы понял что смысла в его посте нет. Хотя да, толпе он нравится и плюсуется, но взгляд этот поверхностный. Хоум пейджи клепать да, можно, но серьезный проект просто вынудит вас делать «велосипеды».
Спасибо, именно такой комментарий я с нетерпением ждал :)
1. Верно, библиотекой «рулит» мейнтейнер библиотеки. Но то, что вы не определяете направление её развития — это заблуждение. Те же Зендовцы с удовольствием принимают предложения, причём самый разнообразные: от добавления новых компонентов до изменения архитектуры всего фреймворка (только без нарушения обратной совместимости, пожалуйста).
Если в новой версии фреймворка обратная совместимость нарушена, то это повод усомниться в компетентности мейнтейнеров.
Ни один серьёзный мейнтейнер не позволит себе ломать обратную совместимость между минорными версиями, так что для серьёзных фреймворков этот аргумент неактуален. Если же такое вдруг происходит — не стойте в стороне! Создайте багрепорт и поднимите шум по этому поводу, а лучше — разберитесь в чём дело и пришлите мейнтейнерам патч. Примите участие в разработке фреймворка, который сами же используете, чтобы не допустить такой ситуации в будущем. Или чтобы как минимум быть морально готовым к этому :)
2. Некоторое количество бюрократии в исправлениях ошибок есть, согласен. Тут уже каждый должен смотреть по ситуации. Например, когда я обнаружил небольшую ошибку в view-хелпере formLabel, я просто временно отнаследовал его и переопределил нужный метод, забыв об ошибке и продолжив разработку. Когда вышла версия с исправлением, я просто удалил более не нужный код из своего класса-наследника. К слову, ошибку Зендовцы исправили сами за три дня. Я тогда поленился патч писать, слишком мелкая ошибка была :)
3. А не нужно патчить самому чужой фреймворк, это моветон. При необходимости — наследуйте его классы и добавляйте исправления в них, как я описал выше.
4. Я не понимаю, что такое «проект одного типа». Веб-проект — это проект одного типа? Или вы хотите сказать, что на фреймворке X можно написать интернет-магазин, но нельза написать форум? Будьте любезны объясниться :)
Что касается ADODB, то его действительно тяжело назвать образцом высокопроизводительной библиотеки. Но поверьте, если в процессе разработки окажется, что в вашем проекте самое тормозное место — это ADODB (не обработка запроса БД, а именно библиотека ADODB), то вы — просто гений оптимизации. Будьте добры, поделитесь с сообществом своими наработками в проектировании высоконагрузочных систем — я уверен, что многие будут вам очень благодарны, включая вашего покорного слугу.
Кроме того, «более существенные» примеры чего вы хотите получить? Велосипедных решений, которыми веб просто переполнен? Или более существенные примеры того, почему лучше использовать (а в идеале — принимать участие в разработке) мейнстримный фреймворк вместо самописного?
1. Верно, библиотекой «рулит» мейнтейнер библиотеки. Но то, что вы не определяете направление её развития — это заблуждение. Те же Зендовцы с удовольствием принимают предложения, причём самый разнообразные: от добавления новых компонентов до изменения архитектуры всего фреймворка (только без нарушения обратной совместимости, пожалуйста).
Если в новой версии фреймворка обратная совместимость нарушена, то это повод усомниться в компетентности мейнтейнеров.
Ни один серьёзный мейнтейнер не позволит себе ломать обратную совместимость между минорными версиями, так что для серьёзных фреймворков этот аргумент неактуален. Если же такое вдруг происходит — не стойте в стороне! Создайте багрепорт и поднимите шум по этому поводу, а лучше — разберитесь в чём дело и пришлите мейнтейнерам патч. Примите участие в разработке фреймворка, который сами же используете, чтобы не допустить такой ситуации в будущем. Или чтобы как минимум быть морально готовым к этому :)
2. Некоторое количество бюрократии в исправлениях ошибок есть, согласен. Тут уже каждый должен смотреть по ситуации. Например, когда я обнаружил небольшую ошибку в view-хелпере formLabel, я просто временно отнаследовал его и переопределил нужный метод, забыв об ошибке и продолжив разработку. Когда вышла версия с исправлением, я просто удалил более не нужный код из своего класса-наследника. К слову, ошибку Зендовцы исправили сами за три дня. Я тогда поленился патч писать, слишком мелкая ошибка была :)
3. А не нужно патчить самому чужой фреймворк, это моветон. При необходимости — наследуйте его классы и добавляйте исправления в них, как я описал выше.
4. Я не понимаю, что такое «проект одного типа». Веб-проект — это проект одного типа? Или вы хотите сказать, что на фреймворке X можно написать интернет-магазин, но нельза написать форум? Будьте любезны объясниться :)
Что касается ADODB, то его действительно тяжело назвать образцом высокопроизводительной библиотеки. Но поверьте, если в процессе разработки окажется, что в вашем проекте самое тормозное место — это ADODB (не обработка запроса БД, а именно библиотека ADODB), то вы — просто гений оптимизации. Будьте добры, поделитесь с сообществом своими наработками в проектировании высоконагрузочных систем — я уверен, что многие будут вам очень благодарны, включая вашего покорного слугу.
Кроме того, «более существенные» примеры чего вы хотите получить? Велосипедных решений, которыми веб просто переполнен? Или более существенные примеры того, почему лучше использовать (а в идеале — принимать участие в разработке) мейнстримный фреймворк вместо самописного?
>Создайте багрепорт и поднимите шум по этому поводу, а лучше — разберитесь в чём дело и пришлите мейнтейнерам патч.
«Полдня ты будешь за ним по лесу гоняться, чтобы из своего фоторужья выстрелить, а потом еще полдня — чтобы фотографию отдать!»
сначала долго доказываешь что это баг, потом долго доказываешь что патч стоит принять…
«Полдня ты будешь за ним по лесу гоняться, чтобы из своего фоторужья выстрелить, а потом еще полдня — чтобы фотографию отдать!»
сначала долго доказываешь что это баг, потом долго доказываешь что патч стоит принять…
Всякое бывает, но в большинстве случаев это зависит от адекватности мейнтейнеров того или иного проекта.
Но если в случаях типа Pidgin'а обычные пользователи могут рассчитывать только на форк, с веб-фреймворками дела обстоят проще. Мы ещё надёжнее застрахованы от таких ситуаций, ведь у нас каждый пользователь — это одновременно и девелопер. Он может в любой момент сделать собственный «маленький форк», отнаследовав базовый класс фреймворка и в нём исправив ошибку.
О чём я и написал выше, но вы почему-то мой аргумент проигнорировали.
Но если в случаях типа Pidgin'а обычные пользователи могут рассчитывать только на форк, с веб-фреймворками дела обстоят проще. Мы ещё надёжнее застрахованы от таких ситуаций, ведь у нас каждый пользователь — это одновременно и девелопер. Он может в любой момент сделать собственный «маленький форк», отнаследовав базовый класс фреймворка и в нём исправив ошибку.
О чём я и написал выше, но вы почему-то мой аргумент проигнорировали.
Он может в любой момент сделать собственный «маленький форк», отнаследовав базовый класс фреймворка и в нём исправив ошибку.
Вы не учитываете что есть ключевое слово final и модификатор private (с константами не уверен, поэтому не буду утверждать) которые могут свести на нет попытку наследовать базовый класс.
Вы не учитываете что есть ключевое слово final и модификатор private (с константами не уверен, поэтому не буду утверждать) которые могут свести на нет попытку наследовать базовый класс.
Ни final, ни private без крайней необходимости никто не использует.
Если ваш фреймворк злоупотребляет этим — опять же, есть повод задуматься.
Но сам ваш подход мне кажется забавным.
Вы же доверяете Zend, используя PHP в своих проектах.
Так почему же вы не хотите доверять Zend в разработке фреймворка на самом PHP?
Есть у меня один приятель-параноик, который боялся использовать любые сторонние библиотеки в PHP и всё писал сам.
И получалось же у человека. Да, медленно и печально, с кучей косяков и ошибок, набивая сотни шишек он двигался вперёд.
Я по-дружески подкалывал его и намекал, что ему не стоит доверять PHP и он должен срочно начать писать собственный язык программирования. А потом собственный веб-сервер, собственную СУБД, собственную ОСь и собственное железо, на котором это хозяйство будет работать. Ведь кто знает, чего они все там внутри понаделывали. Да и пойди попробуй потом форк процессору Intel сделать…
Если ваш фреймворк злоупотребляет этим — опять же, есть повод задуматься.
Но сам ваш подход мне кажется забавным.
Вы же доверяете Zend, используя PHP в своих проектах.
Так почему же вы не хотите доверять Zend в разработке фреймворка на самом PHP?
Есть у меня один приятель-параноик, который боялся использовать любые сторонние библиотеки в PHP и всё писал сам.
И получалось же у человека. Да, медленно и печально, с кучей косяков и ошибок, набивая сотни шишек он двигался вперёд.
Я по-дружески подкалывал его и намекал, что ему не стоит доверять PHP и он должен срочно начать писать собственный язык программирования. А потом собственный веб-сервер, собственную СУБД, собственную ОСь и собственное железо, на котором это хозяйство будет работать. Ведь кто знает, чего они все там внутри понаделывали. Да и пойди попробуй потом форк процессору Intel сделать…
>Но сам ваш подход мне кажется забавным.
тогда посторайтесь мне обьяснить мой подход
>Вы же доверяете Zend, используя PHP в своих проектах.
не все их этих людей работают в zend, я доверяю свободному по
>Так почему же вы не хотите доверять Zend в разработке фреймворка на самом PHP?
а почему именно zf? почему не symfony? limb? solarphp? mzz наконец? а возможно мой или ваш собственный?
понимаете что получается, вы предлагаете продвинуть только один «правильный» фреймворк
тогда посторайтесь мне обьяснить мой подход
>Вы же доверяете Zend, используя PHP в своих проектах.
не все их этих людей работают в zend, я доверяю свободному по
>Так почему же вы не хотите доверять Zend в разработке фреймворка на самом PHP?
а почему именно zf? почему не symfony? limb? solarphp? mzz наконец? а возможно мой или ваш собственный?
понимаете что получается, вы предлагаете продвинуть только один «правильный» фреймворк
>>Но сам ваш подход мне кажется забавным.
>тогда посторайтесь мне обьяснить мой подход
Объяснять вам ваш же подход? Вы сами-то поняли, что попросили? :)
Я лучше объясню свои слова: мне кажется забавным, что вы в принципе приводите аргументы про final и private.
Но я не буду вас переубеждать, если у вас нет более весомых аргументов против использования сторонних открытых разработок.
>не все их этих людей работают в zend, я доверяю свободному по
Вот и отлично! Я тоже доверяю свободному ПО! ZF — это как раз самое настоящее свободное ПО, разве нет?
>а почему именно zf? почему не symfony? limb? solarphp? mzz наконец? а возможно мой или ваш собственный?
Я в статье написал про аналогию с Java-Sun и DotNet-Microsoft.
Я глубоко убежден, что лучше создателей самого языка PHP фреймворк на PHP никто не напишет.
И не потому, что в Zend работают божественные создания, которые порождают божественный код, величие которого простые смертные типа вас с нами не могут оценить :)
В Zend работают обыкновенные люди, не лучше и не хуже нас с вами. Просто у них есть такая штука, как база пользователей. Их работа заключается в том, чтобы эту базу пользователей поддерживать. А пользователи эти — существа капризные, каждый из них тянет одеяло на себя. И Zend'у в этой ситуации приходится быть модератором, который будет принимать взвешенные и объективные решения, которые бы удовлетворили если не всех, то большинство разработчиков. А тем, кого не удовлетворили, чтобы они не обижались сильно — надо предложить альтернативное решение их проблемы.
Вот именно поэтому я и считаю, что ZF — это самый надежный вариант для сообщества разработчиков, чтобы инвестировать в него свои силы и время для совместной выгоды под контролем такого модератора, как Zend.
Но вы снова отвлекли меня от сути статьи :)
Идея не в том, чтобы все поголовно пересели на ZF.
Идея в том, чтобы разработчики начали использовать и помогали развиваться существующим готовым решениям, а не плодить «велосипеды».
>тогда посторайтесь мне обьяснить мой подход
Объяснять вам ваш же подход? Вы сами-то поняли, что попросили? :)
Я лучше объясню свои слова: мне кажется забавным, что вы в принципе приводите аргументы про final и private.
Но я не буду вас переубеждать, если у вас нет более весомых аргументов против использования сторонних открытых разработок.
>не все их этих людей работают в zend, я доверяю свободному по
Вот и отлично! Я тоже доверяю свободному ПО! ZF — это как раз самое настоящее свободное ПО, разве нет?
>а почему именно zf? почему не symfony? limb? solarphp? mzz наконец? а возможно мой или ваш собственный?
Я в статье написал про аналогию с Java-Sun и DotNet-Microsoft.
Я глубоко убежден, что лучше создателей самого языка PHP фреймворк на PHP никто не напишет.
И не потому, что в Zend работают божественные создания, которые порождают божественный код, величие которого простые смертные типа вас с нами не могут оценить :)
В Zend работают обыкновенные люди, не лучше и не хуже нас с вами. Просто у них есть такая штука, как база пользователей. Их работа заключается в том, чтобы эту базу пользователей поддерживать. А пользователи эти — существа капризные, каждый из них тянет одеяло на себя. И Zend'у в этой ситуации приходится быть модератором, который будет принимать взвешенные и объективные решения, которые бы удовлетворили если не всех, то большинство разработчиков. А тем, кого не удовлетворили, чтобы они не обижались сильно — надо предложить альтернативное решение их проблемы.
Вот именно поэтому я и считаю, что ZF — это самый надежный вариант для сообщества разработчиков, чтобы инвестировать в него свои силы и время для совместной выгоды под контролем такого модератора, как Zend.
Но вы снова отвлекли меня от сути статьи :)
Идея не в том, чтобы все поголовно пересели на ZF.
Идея в том, чтобы разработчики начали использовать и помогали развиваться существующим готовым решениям, а не плодить «велосипеды».
>Объяснять вам ваш же подход? Вы сами-то поняли, что попросили? :)
что вы придумали и назвали моим подходом
>Я лучше объясню свои слова: мне кажется забавным, что вы в принципе приводите аргументы про final и private.
я привожу аргументы к тому что не все в этом мире можно наследовать и переопределить и с этим приходиться считаться.
>Но я не буду вас переубеждать, если у вас нет более весомых аргументов против использования сторонних открытых разработок.
тут только два аргумента:
— лицензия проекта
— api проекта/его фукциональная состовляющая
>Я глубоко убежден, что лучше создателей самого языка PHP фреймворк на PHP никто не напишет.
>В Zend работают обыкновенные люди, не лучше и не хуже нас с вами.
если вспомнить пишевую пирамиду и перенести ее на программистов, то получиться что лучше есть куда ;)
>который будет принимать взвешенные и объективные решения, которые бы удовлетворили если не всех, то большинство разработчиков
не думаю что большинство разработчиков обрадовалось включению dojo в zf 1.6
>Идея не в том, чтобы все поголовно пересели на ZF.
>Идея в том, чтобы разработчики начали использовать и помогали развиваться существующим готовым решениям, а не плодить «велосипеды».
вы уже писали свои велосипеды? дайте другим, возможно ктото напишет свой мотоцикл, а если нет, то придет в стан готовых решений.
что вы придумали и назвали моим подходом
>Я лучше объясню свои слова: мне кажется забавным, что вы в принципе приводите аргументы про final и private.
я привожу аргументы к тому что не все в этом мире можно наследовать и переопределить и с этим приходиться считаться.
>Но я не буду вас переубеждать, если у вас нет более весомых аргументов против использования сторонних открытых разработок.
тут только два аргумента:
— лицензия проекта
— api проекта/его фукциональная состовляющая
>Я глубоко убежден, что лучше создателей самого языка PHP фреймворк на PHP никто не напишет.
>В Zend работают обыкновенные люди, не лучше и не хуже нас с вами.
если вспомнить пишевую пирамиду и перенести ее на программистов, то получиться что лучше есть куда ;)
>который будет принимать взвешенные и объективные решения, которые бы удовлетворили если не всех, то большинство разработчиков
не думаю что большинство разработчиков обрадовалось включению dojo в zf 1.6
>Идея не в том, чтобы все поголовно пересели на ZF.
>Идея в том, чтобы разработчики начали использовать и помогали развиваться существующим готовым решениям, а не плодить «велосипеды».
вы уже писали свои велосипеды? дайте другим, возможно ктото напишет свой мотоцикл, а если нет, то придет в стан готовых решений.
тут только два аргумента:
— лицензия проекта
— api проекта/его фукциональная состовляющая
Я просил назвать аргументы против использования открытых фреймворков.
Вы же назвали просто список факторов, которые надо учитывать при выборе подходящего фреймворка, без всякого анализа.
Аргументами эти факторы могут стать, если, например, лицензия проекта несовместима с вашим закрытым коммерческим приложением. В случае с тем же ZF, это не так.
Про API я вас вообще не понял, честно говоря.
Вам некомфортно изучать API сторонних библиотек?
Или вы не можете реализовать внутренний API собственного проекта, когда он основан на сторонней библиотеке?
если вспомнить пишевую пирамиду и перенести ее на программистов, то получиться что лучше есть куда ;)
Не обижайтесь, но по-моему эта аналогия притянута за все три с половиной уха.
Предположим, вы написали собственный фреймворк для разработки веб-приложений.
Теперь перед вами стоит задача разработать само веб-приложение на этом фреймворке.
Как вы считаете, у кого это получится сделать лучше — у вас (автора этого фреймворка) или у дяди Боба (который сам на PHP вообще не пишет, зато делает шикарные сайты на готовых CMS'ках)?
не думаю что большинство разработчиков обрадовалось включению dojo в zf 1.6
Вот тут полностью с вами соглашусь. Большинство разработчиков не обрадовалось включению Dojo в ZF. Потому что большинству разработчиков глубоко пофиг на это самое включение :)
Ничего не мешает продолжать использовать ZF с любой другой библиотекой, которая вам больше нравится.
вы уже писали свои велосипеды? дайте другим, возможно ктото напишет свой мотоцикл, а если нет, то придет в стан готовых решений.
Такое впечатление, что многие здесь буквально поняли заголовок статьи.
Якобы, я призываю всех взять и полностью перестать писать уже написанную функциональность. Да на здоровье, в целях самообразования — сколько угодно.
Я лишь прошу критически относиться к собственным творениям.
Если ты написал велосипед, то ты не принёс в этот мир ничего нового, но зато сам набрался опыта. Просто многие путаю цель и средства. Цель — писать такой код, который будет качественно лучше чем весь код, написанный ранее. А учиться писать такой код при помощи велосипедов — это лишь средство достижения цели.
аргументы я назвал в общем случае, я не держу вас за глупого человека и как я вижу вы понимаете лицензионную составляющую программирования.
с апи все просто, либо оно часто меняется, либо оно человеконепонятно (например методы аргумента принимают mixed, либо как с simpleXML приходиться использовать жесткую типизацию)
>Как вы считаете, у кого это получится сделать лучше — у вас (автора этого фреймворка) или у дяди Боба (который сам на PHP вообще не пишет, зато делает шикарные сайты на готовых CMS'ках)?
все зависит от компонетов которые будут в фреймворке, обьема кода фреймворка, до 50кб возможно автор и выполнит задачу более эфективно, но при больших обьемах даже автор полезет в документацию/phpDOC/Тесты
>Вот тут полностью с вами соглашусь.
я вам всего лишь показал что действия «модераторов» обсуждаемы
я думаю стоило именно так и написать с самого начала. спасибо за дискуссию.
с апи все просто, либо оно часто меняется, либо оно человеконепонятно (например методы аргумента принимают mixed, либо как с simpleXML приходиться использовать жесткую типизацию)
>Как вы считаете, у кого это получится сделать лучше — у вас (автора этого фреймворка) или у дяди Боба (который сам на PHP вообще не пишет, зато делает шикарные сайты на готовых CMS'ках)?
все зависит от компонетов которые будут в фреймворке, обьема кода фреймворка, до 50кб возможно автор и выполнит задачу более эфективно, но при больших обьемах даже автор полезет в документацию/phpDOC/Тесты
>Вот тут полностью с вами соглашусь.
я вам всего лишь показал что действия «модераторов» обсуждаемы
Такое впечатление, что многие здесь буквально поняли заголовок статьи.
Якобы, я призываю всех взять и полностью перестать писать уже написанную функциональность. Да на здоровье, в целях самообразования — сколько угодно.
Я лишь прошу критически относиться к собственным творениям.
Если ты написал велосипед, то ты не принёс в этот мир ничего нового, но зато сам набрался опыта. Просто многие путаю цель и средства. Цель — писать такой код, который будет качественно лучше чем весь код, написанный ранее. А учиться писать такой код при помощи велосипедов — это лишь средство достижения цели.
я думаю стоило именно так и написать с самого начала. спасибо за дискуссию.
По поводу API — тут уже всё очень индивидуально. Качество API сложно оценить объективно, это скорее из области «нравится/не нравится».
И вам спасибо за дискуссию!
И вам спасибо за дискуссию!
Еще мне крайне интересно — насколько вы изучили все библиотеки Зенда и знаете как они работают внутри? Или вы всеже программируете просто под API, начитавшись примеров кода? И просто подражаете? Насколько быстро вы отлавливаете баги, которые связаны не с вашим кодом а с фреймворком? Круто «быстро» писать программы, но когда в них что-то ломается, причем не в вашем коде, вам придется изучить и отдебажить большое количество чужого незнакомого вам кода. Хорошо если он качественный.
Когда я начинал использовать ZF, первым делом я пошел RTFM'ить :)
Начал с изучения примеров по контроллеру (и бутстрапу), т.к. на нём завязано всё остальное в MVC.
Ну а дальше всё начало получаться само собой, главное было начать вникать.
Когда же натыкался на какие-то грабли (ну а как же без этого) — лез в код самого ZF и смотрел, как там всё внутри устроено.
До сих пор не столкнулся ни с одним ограничением, которое бы заставило меня отказаться от использования ZF.
Для меня плюсы перевешивают минусы, хоть и незначительно. Это я и пытаюсь исправить за счёт улучшения самого ZF. И я убеждён, что овчинка стоит выделки. Но опять же, это моё личное мнение.
Начал с изучения примеров по контроллеру (и бутстрапу), т.к. на нём завязано всё остальное в MVC.
Ну а дальше всё начало получаться само собой, главное было начать вникать.
Когда же натыкался на какие-то грабли (ну а как же без этого) — лез в код самого ZF и смотрел, как там всё внутри устроено.
До сих пор не столкнулся ни с одним ограничением, которое бы заставило меня отказаться от использования ZF.
Для меня плюсы перевешивают минусы, хоть и незначительно. Это я и пытаюсь исправить за счёт улучшения самого ZF. И я убеждён, что овчинка стоит выделки. Но опять же, это моё личное мнение.
Ну ладно, щас опять конечно заминусуют, но я отвечу. Вы видимо никогда не менеджерили солидный проект. Наличие в нем большого количества сторонних библиотек делает проект нестабильным, попросту расшатывает его. Приятно видеть тут народ, занимающийся созданием хоумпейджей и стандартных порталов, там действительно какие-то 1000-5000 хостов прекрасно уложатся в вашу колбасень из левых библиотек, которые вы почему-то посчитали эталонными, но что вы будете делать с 10000 хостами? а если ваш проект окажется еще популярнее? Правильно, начнете постепенно выкидывать весь этот шлак и пытаться написать велосипед, который будет работать быстро, качественно и именно так, как вам нужно. Что до Зенд фреймворк и быстроты исправлений, то это исключение, ане правило, да и то это ПОКА, погодите немного и вы увидите, что с каждым месяцем все сложнее и сложнее будет двигать в него изменения. и знаете почему? Потому что слишком много разных людей и слишком разные у них потребности. Вот тут начинается самое интересное:
1) производитель старается угодить всем и мы получаем говнокод и супер монстра, который по сути убивает сам себя
2) производитель разумен и он выбирает определенную линию и перестает слушать всех
3) из пункта 2 следует, что определенное часть пользователей пойдет лесом и останется один на один с кучей1 чужого кода, который надо фиксить и поддерживать.
Все эти правильные рассуждения о мейнстримовых библиотеках хороши, пока вы молоды и ваши проекты рассчитаны на небольшую аудиторию. Я же в своем опыте наблюдаю, как начинают избавляться от всего этого мусора и начинают делать велосипеды, потому что так оно работает и легко поддерживается. Вы видимо имеете огромное количество времени, чтобы лазить по интернету и искать сотни либ, уже написанных до вас, тестировать их, экспериментировать. Я конечно не буду даже упоминать, что все эти либы написаны как правило разными людьми, разные интерфейсы, разный способ именования классов, методов, и так далее. Все это надо интегрировать а один проект. Если Зенд фреймворк удовлетворяет всем вашим требованиям — я только рад — моим он не удовлетворяет.
Все тут говорят правильно, потому что это мейнстрим топика, и никто не хочет почему-то включить голову и подумать, что не все создают велосипеды только потому что хотят самоутвердиться. Я видел достаточное количество серьезных нагруженных проектов изнутри, так вот смею вас заверить, сторонние библиотеки там стремятся к нулю и постоянно выкидываются, потому что это именно та нестабильность в проекте, что тормозит его развитие, да и просто тормозит.
1) производитель старается угодить всем и мы получаем говнокод и супер монстра, который по сути убивает сам себя
2) производитель разумен и он выбирает определенную линию и перестает слушать всех
3) из пункта 2 следует, что определенное часть пользователей пойдет лесом и останется один на один с кучей1 чужого кода, который надо фиксить и поддерживать.
Все эти правильные рассуждения о мейнстримовых библиотеках хороши, пока вы молоды и ваши проекты рассчитаны на небольшую аудиторию. Я же в своем опыте наблюдаю, как начинают избавляться от всего этого мусора и начинают делать велосипеды, потому что так оно работает и легко поддерживается. Вы видимо имеете огромное количество времени, чтобы лазить по интернету и искать сотни либ, уже написанных до вас, тестировать их, экспериментировать. Я конечно не буду даже упоминать, что все эти либы написаны как правило разными людьми, разные интерфейсы, разный способ именования классов, методов, и так далее. Все это надо интегрировать а один проект. Если Зенд фреймворк удовлетворяет всем вашим требованиям — я только рад — моим он не удовлетворяет.
Все тут говорят правильно, потому что это мейнстрим топика, и никто не хочет почему-то включить голову и подумать, что не все создают велосипеды только потому что хотят самоутвердиться. Я видел достаточное количество серьезных нагруженных проектов изнутри, так вот смею вас заверить, сторонние библиотеки там стремятся к нулю и постоянно выкидываются, потому что это именно та нестабильность в проекте, что тормозит его развитие, да и просто тормозит.
Давайте пиписьками меряться не будем, ладно?
Кроме того, столь опытный человек, как вы, должен бы знать, что уровень нагрузки меряется хитами, а не хостами.
Да, ни один из знакомых мне фреймворков нельзя просто так взять и построить на нём высоконагрузочную систему, просто почитав разные туториалы и квикстарты.
Но опытный человек оценит все плюсы архитектуры use-at-will и сможет использовать только те компоненты, которые его устраивают.
Если же этот человек ещё и сознательный, он может предложить свои идеи по улучшению фреймворка для поддержки высоких нагрузок, адаптировать свои наработки и опубликовать их в Сети.
Вот вам и замечательный пример новой, ещё неразведанной отрасли, в которую имеет смысл инвестировать силы и время — создание высоконагрузочных фреймворков. Или, что ИМХО ещё лучше, оптимизация существующих фреймворков для поддержки высоких нагрузок.
По поводу внесения изменений и риска того, что фреймворк уйдет «не туда» — по-моему риски эти слишком надуманные.
Любой желающий может давать свой фидбек мейнтейнерам и влиять на ход развития проекта.
Если же мейнтейнеры вдруг стали неадекватны (что весьма маловероятно само по себе), любой желающий сможет сделать форк и стать мейнтейнером.
В самом, самом крайнем случае на фреймворк все забьют и у вас останется несколько уже готовых проектов, написанных на нём.
Ну и что? Конец света наступил? Вам придётся «мейнтейнить» чужую базу кода? Да не смешите! Этот код вылизывала такая толпа разработчиков, что вероятность поймать в нём баг несравненно меньше вероятности поймать баг в самописной библиотеке.
Чем больше база пользователей какой-то библиотеки, тем меньше в ней неизвестных багов — это же аксиома!
Я не призываю никого использовать «колбасень из левых библиотек».
Используйте те библиотеки, которым доверяете.
Таким образом, «недостойные» отомрут сами собой — это ведь естественный отбор.
Но не доверять никому и считать, что все эти открытые библиотеки только и мечтают, как бы прокрасться в ваш проект, а потом завалить его изнутри — это просто смешно.
Но я должен с вами согласится в том, что хайлоад-проекты сейчас очень редко используют сторонние библиотеки.
Отчасти из-за своей паранойи, отчасти из-за низкого качества библиотек в контексте высоких нагрузок.
Но и первый, и второй факторы — поправимы ;)
Кроме того, столь опытный человек, как вы, должен бы знать, что уровень нагрузки меряется хитами, а не хостами.
Да, ни один из знакомых мне фреймворков нельзя просто так взять и построить на нём высоконагрузочную систему, просто почитав разные туториалы и квикстарты.
Но опытный человек оценит все плюсы архитектуры use-at-will и сможет использовать только те компоненты, которые его устраивают.
Если же этот человек ещё и сознательный, он может предложить свои идеи по улучшению фреймворка для поддержки высоких нагрузок, адаптировать свои наработки и опубликовать их в Сети.
Вот вам и замечательный пример новой, ещё неразведанной отрасли, в которую имеет смысл инвестировать силы и время — создание высоконагрузочных фреймворков. Или, что ИМХО ещё лучше, оптимизация существующих фреймворков для поддержки высоких нагрузок.
По поводу внесения изменений и риска того, что фреймворк уйдет «не туда» — по-моему риски эти слишком надуманные.
Любой желающий может давать свой фидбек мейнтейнерам и влиять на ход развития проекта.
Если же мейнтейнеры вдруг стали неадекватны (что весьма маловероятно само по себе), любой желающий сможет сделать форк и стать мейнтейнером.
В самом, самом крайнем случае на фреймворк все забьют и у вас останется несколько уже готовых проектов, написанных на нём.
Ну и что? Конец света наступил? Вам придётся «мейнтейнить» чужую базу кода? Да не смешите! Этот код вылизывала такая толпа разработчиков, что вероятность поймать в нём баг несравненно меньше вероятности поймать баг в самописной библиотеке.
Чем больше база пользователей какой-то библиотеки, тем меньше в ней неизвестных багов — это же аксиома!
Я не призываю никого использовать «колбасень из левых библиотек».
Используйте те библиотеки, которым доверяете.
Таким образом, «недостойные» отомрут сами собой — это ведь естественный отбор.
Но не доверять никому и считать, что все эти открытые библиотеки только и мечтают, как бы прокрасться в ваш проект, а потом завалить его изнутри — это просто смешно.
Но я должен с вами согласится в том, что хайлоад-проекты сейчас очень редко используют сторонние библиотеки.
Отчасти из-за своей паранойи, отчасти из-за низкого качества библиотек в контексте высоких нагрузок.
Но и первый, и второй факторы — поправимы ;)
Почему вы считаете наличие у меня большого опыта и публичное его обнародование мерением пиписек? Я вот вам резонно укажу, что вы, призывая делиться опытом, почему-то судорожно вздрагиваете когда им начинают делиться и плачете о том, что де пиписьками мерятся. Так как же этим опытом делиться? Вы определитесь, нужен вам опыт мой, в частности, или нет. Я помоему очень аргументировано отвечаю на ваши вопросы, тогда как вы постоянно льете воду и вообще никакой конкретики не высказываете.
Опытный человек легко умеет переводить хосты в хиты, и опытный человек оперирует хостами, потому что хиты величина переменная, а хосты как правило величина более-менее постоянная. Так что замечание не в кассу.
Никакой фреймворк нельзя адекватно оптимизировать под высокие нагрузки, это понимает любой, кто делал достаточно разнообразные а не однотипные продукты. Потому что любой фреймворк узкоспециализированная вещь слишком общая, чтобы ее оптимизировать под максимальные нагрузки.
Если вы поинтересуетесь Зендом в частности, который вы так пропагандируете, то заметите, что даже используя его небольшую только нужную часть вы тянете с собой его инфраструктуру, кучу всякого побочного кода.
Почему вы считаете, что мой «велосипед» который я таковым не считаю не является прекрасным инвестированием средств.
В общем, ХВАТИТ ЛИТЬ ВОДУ, вы постоянно повторяете себя, не высказывая ничего нового и интересного. Совершенно очевидно, что вы никогда не пробовали делать форка чужого проекта и совершенно очевидно, что вы никогда не выпускали опенсорсную библиотеку, которая становилась до определенной степени популярной. Потому что большинство ваших замечаний это восторженный писк о том, как хорошо было бы жить в мире, где нету войн и все счастливы. И дело тут даже не в высоко нагруженных проектах. Вы просто не пробовали. А вот возьмите, попробуйте и вам тут же станет ясно, что если маинтейнер либы уйдет ни туда — вам будет очень больно и неприятно.
Опытный человек легко умеет переводить хосты в хиты, и опытный человек оперирует хостами, потому что хиты величина переменная, а хосты как правило величина более-менее постоянная. Так что замечание не в кассу.
Никакой фреймворк нельзя адекватно оптимизировать под высокие нагрузки, это понимает любой, кто делал достаточно разнообразные а не однотипные продукты. Потому что любой фреймворк узкоспециализированная вещь слишком общая, чтобы ее оптимизировать под максимальные нагрузки.
Если вы поинтересуетесь Зендом в частности, который вы так пропагандируете, то заметите, что даже используя его небольшую только нужную часть вы тянете с собой его инфраструктуру, кучу всякого побочного кода.
Почему вы считаете, что мой «велосипед» который я таковым не считаю не является прекрасным инвестированием средств.
В общем, ХВАТИТ ЛИТЬ ВОДУ, вы постоянно повторяете себя, не высказывая ничего нового и интересного. Совершенно очевидно, что вы никогда не пробовали делать форка чужого проекта и совершенно очевидно, что вы никогда не выпускали опенсорсную библиотеку, которая становилась до определенной степени популярной. Потому что большинство ваших замечаний это восторженный писк о том, как хорошо было бы жить в мире, где нету войн и все счастливы. И дело тут даже не в высоко нагруженных проектах. Вы просто не пробовали. А вот возьмите, попробуйте и вам тут же станет ясно, что если маинтейнер либы уйдет ни туда — вам будет очень больно и неприятно.
После слов «судорожно вздрагиваете», «плачете» и «вообще никакой конкретики» (это — мой любимый аргумент, его можно применять всегда и везде, независимо от наличия конкретики в словах оппонента) у меня окончательно пропало желание продолжать бесполезный спор с троллем.
Судя по оценкам, моя целевая аудитория смысл статьи поняла.
Если вы считаете мой подход неверным — напишите свою статью и мы вмесе посмотрим, как сообщество поддержит её.
Я вам даже карму плюсанул, чтобы возможность такая была.
За сим — откланиваюсь.
PS: Про хосты и хиты повеселили. Аффтар, пешы исчо!
Судя по оценкам, моя целевая аудитория смысл статьи поняла.
Если вы считаете мой подход неверным — напишите свою статью и мы вмесе посмотрим, как сообщество поддержит её.
Я вам даже карму плюсанул, чтобы возможность такая была.
За сим — откланиваюсь.
PS: Про хосты и хиты повеселили. Аффтар, пешы исчо!
Золотые слова
Почему я «изобретаю велосипед» (да-да я делаю свой фреймворк)
1. Мне не нужно 90% функций имеющихся в наличии фреймворков.
2. Я хочу понимать код. Код должен быть под моим контролем. Когда я использую чужое решение — это либо чёрный ящик (потому что там чёрт ногу сломит), либо (если код хороший) нужно понять чужой код, а это уже требует слишком много времени в силу п.1.
Тем не менее я весьма уважаю простые и эффективные решения, «рецепты» и приёмы. Меня интересует скорее подход, чем сам код. За это например я уважаю форум PunBB.
Сейчас я для себя написал очень простой MVC-фреймфорк без лишнего ООП и с нативными PHP-шаблонами, с доступом к БД через PDO. Осталось сделать простое кеширование (PHP-массива и/или буффера вывода) и надёжную авторизацию (CSRF tokens и пр.). Всё остальное — отвлекает от сути и снижает производительность.
Сам фреймворк — это набор функций в одном файле. Плюс структура файлов в корне сайта. Всё.
Спасибо за тему и успехов.
1. Мне не нужно 90% функций имеющихся в наличии фреймворков.
2. Я хочу понимать код. Код должен быть под моим контролем. Когда я использую чужое решение — это либо чёрный ящик (потому что там чёрт ногу сломит), либо (если код хороший) нужно понять чужой код, а это уже требует слишком много времени в силу п.1.
Тем не менее я весьма уважаю простые и эффективные решения, «рецепты» и приёмы. Меня интересует скорее подход, чем сам код. За это например я уважаю форум PunBB.
Сейчас я для себя написал очень простой MVC-фреймфорк без лишнего ООП и с нативными PHP-шаблонами, с доступом к БД через PDO. Осталось сделать простое кеширование (PHP-массива и/или буффера вывода) и надёжную авторизацию (CSRF tokens и пр.). Всё остальное — отвлекает от сути и снижает производительность.
Сам фреймворк — это набор функций в одном файле. Плюс структура файлов в корне сайта. Всё.
Спасибо за тему и успехов.
1. Мне не нужно 90% функций имеющихся в наличии фреймворков.
Архитектура use-at-will позволяет вам использовать только те компоненты фреймворка, которые вам необходимы.
Все остальные будут лежать «мёртвым грузом», никому не мешая и ожидая момента, когда они наконец понадобятся.
Насколько мне известно, такой подход практикует большинство современных фреймворков.
2. Я хочу понимать код. Код должен быть под моим контролем. Когда я использую чужое решение — это либо чёрный ящик (потому что там чёрт ногу сломит), либо (если код хороший) нужно понять чужой код, а это уже требует слишком много времени в силу п.1.
Если вы работаете не один, а в команде, то вам каждый день приходится колупать чужой код, причём не всегда хорошего качества :)
Кроме того, в идеале код самого фреймворка копать не нужно — нужно копать его документацию.
Но тут уже каждый сам решает, что ему удобнее копать — в самом коде комментариев тоже хватает.
Спасибо за тему и успехов.
И вам того же!
хм… я тим лидер команды проекта incomeproject.com (это большая площадка для создания партнерских программ), могу сказать, что использование сторонних библиотек осложнено как минимум по таким причинам:
чтобы использовать такую библиотеку в серьезном проекте ей нужно полностью доверять, чтобы ей доверять ее надо изучить и обкатать на каком-либо «не важном» проекте, таких обычно нет.
нужно полностью понимать область применения, условия работы Фреймворка, методологию решения проблем, которую он предлагает. если этого нет, то вы рано или поздно встанете в ситуацию когда Фреймворк не удовлетворяет ваших требований и нужно писать «костыль» тут то вы и попадете в ловушку когда нужно ставить еще и еще костыли. поставить костыль корректно (под нужным углом) и не нарушить логической целостности работы приложения основанной на FW вы все равно можете только в случае если понимаете идеологию решения задачи, которая заложена в Фреймворк.
Таким образом что б начать пользовать Фреймворк вам нужно:
вот, только теперь можно использовать данный Фреймворк в своих проектах…
все что я тут написал — это мое мнение, моя позиция, но она основана на опыте человека, который написал системы на PHP (ну и не только php), работающие на свыше 5-ти машинах как с функциональным распределением вычислений, так и с распределением вычислений по данным и прекрасно масштабируемы.
доверие к С++, С и Java обусловлено вовсе не одним фактом бренда, который за ними стоит, хотя и им тоже, но еще и старостью технологии Java`е тока не давно сан сделал полную среду свою, а до этого так же были склады решений и все рылись в них, достаточно вспомнить эпопею с аспектным программированием.
почему я использую свои разработки и предпочитаю изучать патерны, а не Фреймворки?
это только общие замечания, есть частные, например, вы знаете, что в вашем случае контекст задачи подразумевает упрощение какого — либо механизма, в рамках фрайм ворка это упрощение (логики, абстракций, производительности) обычно сложно сделать, но на вашей кухне вы можете себе позволить это.
я выделяю такие плюсы/минусы:
свои велосипеды
минусы:
Плюсы:
в итоге вы рискуете, но вы гарантированы от того чтоб зайти в тупик, а с Фреймворком (особенно большим вы не гарантированны)
чтобы использовать такую библиотеку в серьезном проекте ей нужно полностью доверять, чтобы ей доверять ее надо изучить и обкатать на каком-либо «не важном» проекте, таких обычно нет.
нужно полностью понимать область применения, условия работы Фреймворка, методологию решения проблем, которую он предлагает. если этого нет, то вы рано или поздно встанете в ситуацию когда Фреймворк не удовлетворяет ваших требований и нужно писать «костыль» тут то вы и попадете в ловушку когда нужно ставить еще и еще костыли. поставить костыль корректно (под нужным углом) и не нарушить логической целостности работы приложения основанной на FW вы все равно можете только в случае если понимаете идеологию решения задачи, которая заложена в Фреймворк.
Таким образом что б начать пользовать Фреймворк вам нужно:
- попробовать его где либо в слабо значительном месте.
- изучить всю доку и знать типичные примеры, желательно потусовать в сообществах и узнать типичные проблемы
- понять идеалогию решения (большой Фреймворк, много авторов, а значит много разношерстных решений)
- осознать ВСЕ уровни абстракций используемых в Фреймворке.
- написать где-то долго играющий, но опять же критичный проект на этом Фреймворке.
вот, только теперь можно использовать данный Фреймворк в своих проектах…
все что я тут написал — это мое мнение, моя позиция, но она основана на опыте человека, который написал системы на PHP (ну и не только php), работающие на свыше 5-ти машинах как с функциональным распределением вычислений, так и с распределением вычислений по данным и прекрасно масштабируемы.
доверие к С++, С и Java обусловлено вовсе не одним фактом бренда, который за ними стоит, хотя и им тоже, но еще и старостью технологии Java`е тока не давно сан сделал полную среду свою, а до этого так же были склады решений и все рылись в них, достаточно вспомнить эпопею с аспектным программированием.
почему я использую свои разработки и предпочитаю изучать патерны, а не Фреймворки?
- знание паттернов программирования дает вам не само блюдо, а рецепт как приготовить блюдо, вы вольны использовать любые поваренные приборы: PHP JAVA С++.
- вы сможете добавить специи по своему выбору, если вы работаете в команде, то у вас больше шанцев изменить рецепт до приготовления, так чтоб ни у кого из членов команды не было аллергии на отдельные его части.
- вы можете использовать сезонные и свежие овощи! например, если только что появилась возможность использовать наймспайсы, вы их любите, то вы уже можете включить их в состав своих блюд! я очень сомневаюсь, что шеф повар вашего любимого Фреймворка обладает достаточной гибкостью чтоб сделать это.
- худеем — нужно меньше калорий… я думаю, что вам не зачем тащить с собой всю инфраструктуру Фреймворков просто, чтоб оно работало «как всегда» или на «всякий случай», вы же готовите!, а значит, на столе не должно быть ничего лишнего.
- «используйте только соевый соус» — подумайте должны ли вы так строго соблюдать рецепт?? а что если вам хочется кетчуп? отказаться от таматов? ограничения вызванные использованием готового фраймворка иногда оказываются очень серьезными и вам не нужными.
это только общие замечания, есть частные, например, вы знаете, что в вашем случае контекст задачи подразумевает упрощение какого — либо механизма, в рамках фрайм ворка это упрощение (логики, абстракций, производительности) обычно сложно сделать, но на вашей кухне вы можете себе позволить это.
я выделяю такие плюсы/минусы:
свои велосипеды
минусы:
- нет сообщества, которое обсудит ВАШУ проблемму
- велика вероятность «глупых» ошибок
- вы варитесь в собственном соку — не знаете новых методов если всегда все делаете сами
- Сложно предать проект другим людям
Плюсы:
- вы имеете полную свободу выбора, все что вы делаете вы можете сделать как вам угодно
- в любом месте вы можете вставить новое решение и будете знать как это изменит вашу систему
- вы можете решить любую проблему! вы автор системы, вам подвластны решения
- все органичения вам подвластны
в итоге вы рискуете, но вы гарантированы от того чтоб зайти в тупик, а с Фреймворком (особенно большим вы не гарантированны)
в общем скопипастил ответ в отдельный топик ИМХО это отдельная тема developer.habrahabr.ru/blog/39729/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Хватит изобретать велосипеды!