Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 87
хабракат бы
Хабракат забыли
Двумя руками за велосипеды! Во-первых это опыт, во-вторых личная свобода. К тому же когда на берётся достаточное количество своих решений то писать что-либо придётся всё меньше и меньше, толкь поддреживать рание написанный код и всё (:
Немножко несогласен, что когда набирается достаточное количество решений то приходится писать все меньше и меньше. У меня, да и еще парочки знакомых девелоперов, которые использовали свои велосипеды в десятках различных веб-приложений появляется одна проблема — внутренний рефакторинг этого самого велосипеда (хотя если быть точнее то переписывание некоторых компонентов практически с нуля). Потому как сложно использовать старый код, написаный полтора года назад, но полностью рабочий, решающий свои задачи, проверенный временем; когда за это время ты узнал еще о десятке способов решения данной проблемы, и тебя решение, которое у тебя есть на данный момент не устраивает полностью.
минусы:
Ну а где упоминание кучи затраченного времени на написание и отладку своих велосипедов?
Ну а где упоминание кучи затраченного времени на написание и отладку своих велосипедов?
велика вероятность «глупых» ошибок
я посчитал что эта вещь включает ту, о которой вы сказали.
я посчитал что эта вещь включает ту, о которой вы сказали.
Иногда легче написать, чем изучать чежой фреймверк с кучей ненужного функционала.
Я о том, что на полное изучение тоже требуется время.
Я о том, что на полное изучение тоже требуется время.
Совершенно верно.
Плюс, считаю, надо разделить еще на две параллели:
— Ребята из технологического звена — разработчики и архитекторы — для них это, возможно, и больший контроль над структурами и личный опыт в написании вещей.
— Однако, для людей из бизнеса — владельцев и управленцев — это совсем по-другому — для них это означает финансовые инвестиции в поддержку еще одной технологической разработки. И нужно очень точное обоснование принимаемых технологических решений.
Плюс, считаю, надо разделить еще на две параллели:
— Ребята из технологического звена — разработчики и архитекторы — для них это, возможно, и больший контроль над структурами и личный опыт в написании вещей.
— Однако, для людей из бизнеса — владельцев и управленцев — это совсем по-другому — для них это означает финансовые инвестиции в поддержку еще одной технологической разработки. И нужно очень точное обоснование принимаемых технологических решений.
Это время с лихвой окупается при решении нестандартный/стандартных задач в будущем.
Имел опыт работы с Або, Битрикс, Друпал, МодХ — отличнные системы, но для решения задачи в лоб, право-лево тут не дано.
На самом деле выбор за программером, либо изучить досканально FW и писать под него, либо писать свое и опять же работать :) Каждый выбирает сам.
Имел опыт работы с Або, Битрикс, Друпал, МодХ — отличнные системы, но для решения задачи в лоб, право-лево тут не дано.
На самом деле выбор за программером, либо изучить досканально FW и писать под него, либо писать свое и опять же работать :) Каждый выбирает сам.
Странно, коммент попал не в ту ветку…
странно я пишу вовсе не о том, что нельзя использовать FW, а о том что нужно писать свои велосипеды тоже, но меня не понимают.
Вы точно о фреймворках говорите? Погуглите CakePHP, Symfony.
cms кстати тоже относятся к готовым решениям и к ним все в тойже мере применимо
Выясняется. Так вы решите, чего вы хотите.
Для меня такие вопросы просто давно не стоят. Есть задача, есть ресурсы на её реализацию. А говорить, что мы, мол, свой фремворк наколбасим быстрее, чем выучим что-нибудь из имеющегося (да еще и сделаем мега-абстрактным, или предлагается *каждый раз* переписывать модули типа acl?) — это как-то не по тимлидерски, зато по пехепешному (:
Хватит изобретать велосипеды там, где они не нужны! Решайте поставленные задачи имеющимися средствами. Или вы профессионализм оцениваете по количеству кода, который дублирует уже разработанную кем-то функциональность?
Для меня такие вопросы просто давно не стоят. Есть задача, есть ресурсы на её реализацию. А говорить, что мы, мол, свой фремворк наколбасим быстрее, чем выучим что-нибудь из имеющегося (да еще и сделаем мега-абстрактным, или предлагается *каждый раз* переписывать модули типа acl?) — это как-то не по тимлидерски, зато по пехепешному (:
Хватит изобретать велосипеды там, где они не нужны! Решайте поставленные задачи имеющимися средствами. Или вы профессионализм оцениваете по количеству кода, который дублирует уже разработанную кем-то функциональность?
Все таки Або, Битрикс, Друпал, МодХ — это готовые CMS.
А фреймворки это — ZF, Symfony, Prado, CodeIgniter, Solar, CakePHP.
А фреймворки это — ZF, Symfony, Prado, CodeIgniter, Solar, CakePHP.
Одной рукой за готовые решения, другой — за велосипеды. Потому как готовые решения как правило — добро, они могут сэкономить нам очень много времени, нервов и дать некоторых недостающих знаний. А вся чепуха то, что мы вот сами напишем лучше — едва ли действует и в двадцати случаях, в которых нужно действительно что-то адаптировать именно под конкретные условия конкретного проекта, а не стандартные условия, для которых и писалось это решение.
А вот свои велосипеды частенько приходится использовать уже вместе с готовыми решениями — да, получается иногда такой суповой набор, с немножко разными стандартами кодирования, немного подпиленный и забитый по сути в адаптеры, которые и не дают ему полностью развалится и позволяют всему общатся между собой, без особых проблем.
Сейчас вот к примеру активно пользуюсь Zend Framework, изучая его, черпая что-то новое и внося в свой небольшой фреймворк (если раньше создавался как решение от всех моих проблем, то сейчас — скорее это некий sandbox позволяющий эксперементировать и получать новые знания), который уже наверное по сути является клоном самого зенда. Наверное это хорошо когда твоя идеология и видения фреймворка совпадает с видением довольно неглупых людей, у которых еще и можно подсмотреть как это лучше сделать.
А вот свои велосипеды частенько приходится использовать уже вместе с готовыми решениями — да, получается иногда такой суповой набор, с немножко разными стандартами кодирования, немного подпиленный и забитый по сути в адаптеры, которые и не дают ему полностью развалится и позволяют всему общатся между собой, без особых проблем.
Сейчас вот к примеру активно пользуюсь Zend Framework, изучая его, черпая что-то новое и внося в свой небольшой фреймворк (если раньше создавался как решение от всех моих проблем, то сейчас — скорее это некий sandbox позволяющий эксперементировать и получать новые знания), который уже наверное по сути является клоном самого зенда. Наверное это хорошо когда твоя идеология и видения фреймворка совпадает с видением довольно неглупых людей, у которых еще и можно подсмотреть как это лучше сделать.
согласен, в целом изучение фраймворка — это удивительно полезная деятельность. половина моего поста имено и посвящена вопросу что фраймворк нада изучить. Как правило так и получается что нарвится почти все, и поэтому идеи и патрены понравившегося фраймворка переплывают в свою разработку. Но опять же если вы ищите решение, то нада использовать либу, ее, например, и из фраймворка можно выдрать.
Так вот мне в последнее время приходят мысли о том, что програмера новому языку следуюет учить по схеме:
Погонять по мануалу, показать что вообще есть в языке, дать почитать «Совершенный код», и после посадить на изучение кода какого-нибудь фреймворка, что пограмотнее написан, что бы посмотрел сразу как надо правильно использовать возможности языка. Осилит все это — готовых решений от него ждать надо будет недолго, неосилит — да и не нужен такой.
Насчет нравится почти все — мне нравилось почти все (кроме скорости работы наверное) только в одним из четырех (ZF, Symfony, CI, Prado) фремвоков — zf. У которого еще, по каким-то странным стечением обстоятельств и слабая связанность компонентов, поэтому в отличие от какого-нибудь Prado, у которого можно выдрать только монтировкой что-нибудь, зенд вливается в другие проекты ну просто на ура, и многими разработчиками считается как вообще какой-то нативный компонент своего языка.
Погонять по мануалу, показать что вообще есть в языке, дать почитать «Совершенный код», и после посадить на изучение кода какого-нибудь фреймворка, что пограмотнее написан, что бы посмотрел сразу как надо правильно использовать возможности языка. Осилит все это — готовых решений от него ждать надо будет недолго, неосилит — да и не нужен такой.
Насчет нравится почти все — мне нравилось почти все (кроме скорости работы наверное) только в одним из четырех (ZF, Symfony, CI, Prado) фремвоков — zf. У которого еще, по каким-то странным стечением обстоятельств и слабая связанность компонентов, поэтому в отличие от какого-нибудь Prado, у которого можно выдрать только монтировкой что-нибудь, зенд вливается в другие проекты ну просто на ура, и многими разработчиками считается как вообще какой-то нативный компонент своего языка.
как ни крути, а свой «велосипед» тоже станет фреймверком
ну тогда вы можете совершить очередной раз извечную ошибку разработчиков:
решать нада конкретную задачу а не абстрактную и потому нада иметь набор интсрументов, а не мотнстра который умеет все за вас.
решать нада конкретную задачу а не абстрактную и потому нада иметь набор интсрументов, а не мотнстра который умеет все за вас.
Так как этот топик — ответ на мой, не могу не прокомментировать :)
Спасибо за ваши мысли, ведь в дискуссии рождается истина.
По вашему мнению, прежде чем использовать фреймворк, нужно проверить его «в слабо значительном месте», изучить всю доку (это всегда полезно, кстати), потусоваться в его сообществе, понять идеологию решений, архитектуру и т.д.
На практике же, это как раз тот вариант, когда выгоднее стать частью толпы: посмотреть, какой фреймворк используют остальные для решения задач, похожих на ваши? Какие у них возникают проблемы и насколько просто они преодолеваются.
Ведь, когда мы выбирали язык PHP, мы не лезли в его исходные коды, не изучали его архитектуру (на си — ну, не так глубоко, во всяком случае) и всё такое.
Мы просто посмотрели, что окружающие используют именно него и проблем с ним не возникает — и сами начали пробовать. Таким образом можно сказать, что мы мы учимся на чужих ошибках.
Дальше про «кухню» :)
Не надо противопоставлять две эти замечательные штуки :)
Не понравилось вам какое-то ограничение компонента — вы можете либо отнаследовать его и дописать / переписать часть необходимых методов, чтобы обеспечить нужную функциональность, либо если вам совсем нечего делать — написать собственный компонент-замену, «с блекджеком и шлюхами» (с) Бендер, Футурама.
Спасибо за ваши мысли, ведь в дискуссии рождается истина.
По вашему мнению, прежде чем использовать фреймворк, нужно проверить его «в слабо значительном месте», изучить всю доку (это всегда полезно, кстати), потусоваться в его сообществе, понять идеологию решений, архитектуру и т.д.
На практике же, это как раз тот вариант, когда выгоднее стать частью толпы: посмотреть, какой фреймворк используют остальные для решения задач, похожих на ваши? Какие у них возникают проблемы и насколько просто они преодолеваются.
Ведь, когда мы выбирали язык PHP, мы не лезли в его исходные коды, не изучали его архитектуру (на си — ну, не так глубоко, во всяком случае) и всё такое.
Мы просто посмотрели, что окружающие используют именно него и проблем с ним не возникает — и сами начали пробовать. Таким образом можно сказать, что мы мы учимся на чужих ошибках.
Дальше про «кухню» :)
знание паттернов программирования дает вам не само блюдо, а рецепт как приготовить блюдо, вы вольны использовать любые поваренные приборы: PHP JAVA С++.Использование свободного фреймворка не мешает вам использовать паттерны проектирования, и наоборот.
Не надо противопоставлять две эти замечательные штуки :)
вы сможете добавить специи по своему выбору, если вы работаете в команде, то у вас больше шанцев изменить рецепт до приготовления, так чтоб ни у кого из членов команды не было аллергии на отдельные его части.Если я правильно понял вашу аналогию, то у меня в этом вопросе взгляды монархические. Тимлид сам выбирает, какие технологии будет использовать команда. В идеале — предварительно посовещавшись с разработчиками, но это не всегда обязательно и может легко перерасти в целую корзину холиворов.
вы можете использовать сезонные и свежие овощи! например, если только что появилась возможность использовать наймспайсы, вы их любите, то вы уже можете включить их в состав своих блюд! я очень сомневаюсь, что шеф повар вашего любимого Фреймворка обладает достаточной гибкостью чтоб сделать это.Ничего не мешает вам использовать «свежие овощи» в своём коде — за пределами фреймворка. Конечно же, если фреймворк не написан с использованием «овощей» типа неймспейсов, использовать его в проекте с неймспейсами будет не совсем удобно. С другой стороны, тот же сокращенный тернарный оператор можно использовать без всяких проблем.
худеем — нужно меньше калорий… я думаю, что вам не зачем тащить с собой всю инфраструктуру Фреймворков просто, чтоб оно работало «как всегда» или на «всякий случай», вы же готовите!, а значит, на столе не должно быть ничего лишнего.Этот аргумент я вообще никогда не понимал, честно говоря. В чём смысл этого «худения»? Освободить драгоценный мегабайт места на сервере? Если вам (в данный момент) не нужно генерить PDF, то просто не используйте соответствующий класс. Чем вам мешает то, что он у вас есть?
«используйте только соевый соус» — подумайте должны ли вы так строго соблюдать рецепт?? а что если вам хочется кетчуп? отказаться от таматов? ограничения вызванные использованием готового фраймворка иногда оказываются очень серьезными и вам не нужными.Во фреймворках с правильной модульной архитектурой компоненты можно использовать как все вместе, так и по отдельности.
Не понравилось вам какое-то ограничение компонента — вы можете либо отнаследовать его и дописать / переписать часть необходимых методов, чтобы обеспечить нужную функциональность, либо если вам совсем нечего делать — написать собственный компонент-замену, «с блекджеком и шлюхами» (с) Бендер, Футурама.
затраты на введение фраймворка сопоставимы с затратами на работу без него — это основная проблемма.
язык PHP мы выбирали именно основываясь на анализе и потребности.
в целом попробуйте посмотреть по другому:
вам нужен компонент вашей системы, он нужен для чего-то.
у вас 2 равноварианта: поиск решения (поиск готового кода) и поиск решения (написание кода), как видите они часто равнозначны.
Если человек не может написать шаблонизатор который будет удовлетворять его потребности в 70% случаев, то он не сможет и смарти толково использовать.
Начинать нужно Всегда с анализа того, что есть, именно поэтому изучение фраймворка полезная работа, что-то да останется, если вы ничего не подчерпнули, не взяли, не оставили себе — то вы не изучили фраймворк. Но говорить, что фраймворк должен доминировать над собственными разработками в продакшене — это ИМХО не верно. Я считаю, что свои разработки очень полезны, как с точки зрения развития так и с точки зрения бизнеса. Своя разработка предсказуема и управляема, всегда есть ответственное лицо которое может внести изменения. Если вы добиваетесь такойже управляемости с фраймворком, то используйте его! в моих командах я ниразу не пропускал использование фрайма, который бы был досконально изучен и считаю, что делал верно.
пример:
В Zend_Acl роль может наследоваться от одной или от нескольких ролей. Это реализовано для поддержки наследования правил между ролями.
в принципе очень клевая штуковина, давайте попробуем ее использовать.
Допустим роль определяется в результате какой либо инициализации при старте системы. определили что наш пользователь есть «moderator» унаследованный от «user» который в свою очередь унаследован от «guest».
все сделать просто, все работает, но система дорабатывается… допустим что в результате дальнейшей инициализации системы было обнаружено что наш пользователь заблокирован (класс «block»), тоесть ему запрещен доступ к каким-то ресурсам. пробуем реализовать это на Zend_Acl и… тупик — это как раз пример когда мы вышли за контекст использования Zend_Acl. эту задачу решить в рамках Acl можно, но не нужно ибо решение будет некрасивым и будет нарушен слой абстракций (нам придется выносить логику управления ресурсами за приделы Acl)
прошу прощения у тех, кто не работал с Zend_Acl прочитать кратко можно framework.zend.com/manual/ru/zend.acl.html, проблема кроется в том, что
Конфликт произошел по причине наследования от нескольких ролей.
Zend_Acl решает эту неоднозначность, завершая запрос, как только находит первое правило, которое может быть применено к запросу.
пример несколько грамоздкий, но наглядный.
Автор фреймворка работает обычно в другом контексте чем вы, поэтому то какую решает проблему он и которую решаете вы часто различны.
Вы правильно написали, что «Во фреймворках с правильной модульной архитектурой компоненты можно использовать как все вместе, так и по отдельности.» если из фреймворка можно вырвать интересующий вас кусок, то вам повезло =), делайте это!
про худение это особый момент. Дело в том, что часто часть написанная на фреймворке занимает 70%-95% работы скрипта и как оптимизировать ее не ясно, хотя задача не кажется иногда такой большой, поэтому приходится думать о том как «худеть».
а в целом за ответ спасибо, я не тотальный противник фреймворков, я противник их неосознаного выбора.
язык PHP мы выбирали именно основываясь на анализе и потребности.
в целом попробуйте посмотреть по другому:
вам нужен компонент вашей системы, он нужен для чего-то.
у вас 2 равноварианта: поиск решения (поиск готового кода) и поиск решения (написание кода), как видите они часто равнозначны.
Если человек не может написать шаблонизатор который будет удовлетворять его потребности в 70% случаев, то он не сможет и смарти толково использовать.
Начинать нужно Всегда с анализа того, что есть, именно поэтому изучение фраймворка полезная работа, что-то да останется, если вы ничего не подчерпнули, не взяли, не оставили себе — то вы не изучили фраймворк. Но говорить, что фраймворк должен доминировать над собственными разработками в продакшене — это ИМХО не верно. Я считаю, что свои разработки очень полезны, как с точки зрения развития так и с точки зрения бизнеса. Своя разработка предсказуема и управляема, всегда есть ответственное лицо которое может внести изменения. Если вы добиваетесь такойже управляемости с фраймворком, то используйте его! в моих командах я ниразу не пропускал использование фрайма, который бы был досконально изучен и считаю, что делал верно.
пример:
В Zend_Acl роль может наследоваться от одной или от нескольких ролей. Это реализовано для поддержки наследования правил между ролями.
в принципе очень клевая штуковина, давайте попробуем ее использовать.
Допустим роль определяется в результате какой либо инициализации при старте системы. определили что наш пользователь есть «moderator» унаследованный от «user» который в свою очередь унаследован от «guest».
все сделать просто, все работает, но система дорабатывается… допустим что в результате дальнейшей инициализации системы было обнаружено что наш пользователь заблокирован (класс «block»), тоесть ему запрещен доступ к каким-то ресурсам. пробуем реализовать это на Zend_Acl и… тупик — это как раз пример когда мы вышли за контекст использования Zend_Acl. эту задачу решить в рамках Acl можно, но не нужно ибо решение будет некрасивым и будет нарушен слой абстракций (нам придется выносить логику управления ресурсами за приделы Acl)
прошу прощения у тех, кто не работал с Zend_Acl прочитать кратко можно framework.zend.com/manual/ru/zend.acl.html, проблема кроется в том, что
Конфликт произошел по причине наследования от нескольких ролей.
Zend_Acl решает эту неоднозначность, завершая запрос, как только находит первое правило, которое может быть применено к запросу.
пример несколько грамоздкий, но наглядный.
Автор фреймворка работает обычно в другом контексте чем вы, поэтому то какую решает проблему он и которую решаете вы часто различны.
Вы правильно написали, что «Во фреймворках с правильной модульной архитектурой компоненты можно использовать как все вместе, так и по отдельности.» если из фреймворка можно вырвать интересующий вас кусок, то вам повезло =), делайте это!
про худение это особый момент. Дело в том, что часто часть написанная на фреймворке занимает 70%-95% работы скрипта и как оптимизировать ее не ясно, хотя задача не кажется иногда такой большой, поэтому приходится думать о том как «худеть».
а в целом за ответ спасибо, я не тотальный противник фреймворков, я противник их неосознаного выбора.
Про Zend_Acl — вы столкнулись с такими проблемами, потому что пытаетесь натянуть свою идеологию на готовое решение, вместо того, чтобы понять, как можно решить вашу задачу в рамках идеологии Zend_Acl.
Навскидку могу назвать два решения:
1. При блокировке перевести пользователя в группу заблокированных. Дальше всё должно быть очевидно, как мне кажется.
2. Не менять группу пользователя, а пометить его как «заблокированного». Насколько я понял, именно по такому пути вы и пошли. Но в таком случае нужно понимать, что данная задача автоматически выходит за рамки ACL'а. Вы должны добавить отдельную проверку типа if ($user->isBlocked) и действовать соответственно.
По аналогии, вы хотите запретить пользователям редактировать чужие статьи, но при этом разрешить редактировать собственные. Эта задача на уровне обыкновенного ACL'а не решается, потому что ACL предназначен для работы с другими понятиями: группами, ресурсами и действиями. Всё, что выходит за эти рамки — нужно реализовывать за рамками ACL'а.
И это не потому, что ACL плохой или неудобный, а потому что он решает четко определенный набор задач и не нужно хотеть от него того, для чего он изначально не предназначен.
Навскидку могу назвать два решения:
1. При блокировке перевести пользователя в группу заблокированных. Дальше всё должно быть очевидно, как мне кажется.
2. Не менять группу пользователя, а пометить его как «заблокированного». Насколько я понял, именно по такому пути вы и пошли. Но в таком случае нужно понимать, что данная задача автоматически выходит за рамки ACL'а. Вы должны добавить отдельную проверку типа if ($user->isBlocked) и действовать соответственно.
По аналогии, вы хотите запретить пользователям редактировать чужие статьи, но при этом разрешить редактировать собственные. Эта задача на уровне обыкновенного ACL'а не решается, потому что ACL предназначен для работы с другими понятиями: группами, ресурсами и действиями. Всё, что выходит за эти рамки — нужно реализовывать за рамками ACL'а.
И это не потому, что ACL плохой или неудобный, а потому что он решает четко определенный набор задач и не нужно хотеть от него того, для чего он изначально не предназначен.
замечательно! вот вы и повторяете уже мою мысль сами!
штука какраз в том что когда делается что-то новое, то не всегда есть решение, и без велосипедов чуть чуть отличных никак!
Автор фреймворка работает обычно в другом контексте чем вы, поэтому то какую решает проблему он и которую решаете вы часто различны.
штука какраз в том что когда делается что-то новое, то не всегда есть решение, и без велосипедов чуть чуть отличных никак!
Вы путаете два понятия:
1. Готового решения нет.
2. Готовое решение есть, но вы его не нашли/не поняли/оно вам не понравилось.
И если вы начнете делать собственное решение, то в первом случае, вы — молодец, особенно если поделитесь результатом с сообществом. А во-втором, вы — велосипедист, потому что не разобрались в существующих решениях или забили на них, вместо того, чтобы разобраться или помочь авторам решения сделать его лучше.
Написав самописный фреймворк, вы поможете только себе.
Улучшая свободный фреймворк, вы помогаете всем её пользователям.
А они, улучшая его со своей стороны, помогают вам.
Это же так просто…
P.S. Если вы достаточно амбициозны, чтобы из своего велосипеда сделать по-настоящему свободный фреймворк (стать мейнтейнером, написать документацию, принимать патчи, поднять публичный репозиторий, набрать команду разработчиков и т.д.) — мой глубокий респект вам.
Если же амбиций/времени/сил/денег у вас не достаточно, выберите проект по душе и поддерживайте его, как я поддерживаю ZF.
А просто велосипед написать — много ума и сил не надо…
Это я не лично вам писал, это скорее для %username% :)
1. Готового решения нет.
2. Готовое решение есть, но вы его не нашли/не поняли/оно вам не понравилось.
И если вы начнете делать собственное решение, то в первом случае, вы — молодец, особенно если поделитесь результатом с сообществом. А во-втором, вы — велосипедист, потому что не разобрались в существующих решениях или забили на них, вместо того, чтобы разобраться или помочь авторам решения сделать его лучше.
Написав самописный фреймворк, вы поможете только себе.
Улучшая свободный фреймворк, вы помогаете всем её пользователям.
А они, улучшая его со своей стороны, помогают вам.
Это же так просто…
P.S. Если вы достаточно амбициозны, чтобы из своего велосипеда сделать по-настоящему свободный фреймворк (стать мейнтейнером, написать документацию, принимать патчи, поднять публичный репозиторий, набрать команду разработчиков и т.д.) — мой глубокий респект вам.
Если же амбиций/времени/сил/денег у вас не достаточно, выберите проект по душе и поддерживайте его, как я поддерживаю ZF.
А просто велосипед написать — много ума и сил не надо…
Это я не лично вам писал, это скорее для %username% :)
повторюсь и я… затраты на поиск/изучение готового решения часто сопоставимы с написанием своего, и еще я не против фрейморков как таковых, я против того, чтоб отказываться от велосипедов.
В ближайшее время я напишу (седня завтра) статейку про очередной велосипед, поэтому попрошу вас зайти ко мне в други чтоб я мог вам дать почитать до публикации.
В ближайшее время я напишу (седня завтра) статейку про очередной велосипед, поэтому попрошу вас зайти ко мне в други чтоб я мог вам дать почитать до публикации.
замечательно! вот вы и повторяете уже мою мысль сами!
штука какраз в том что когда делается что-то новое, то не всегда есть решение, и без велосипедов чуть чуть отличных никак!
Автор фреймворка работает обычно в другом контексте чем вы, поэтому то какую решает проблему он и которую решаете вы часто различны.
штука какраз в том что когда делается что-то новое, то не всегда есть решение, и без велосипедов чуть чуть отличных никак!
Про ACL написал, а про остальное — забыл :)
Я не спорю, есть умельцы, которые способны на это, но таких скорее единицы.
Как я уже написал выше, я сам иду по другому пути — наследую компоненты фреймворка и добавляю в них ту функциональность, которой лично мне нехватает.
К автомобилям наследование не применимо (к сожалению), так что ближайшая аналогия — это взять стандартную модель автомобиля, а потом прикручивать/менять детали по мере необходимости, например установить ксенон и спойлер, разукрасить кузов аэрографией, поставить турбину или чип-тюнинг, если турбина уже есть и т.д.
А по поводу «худения» — если выполнение кода фреймворка занимает 70-95% времени выполнения скрипта, то либо у вас просто офигительно простая бизнес-логика (приложение «Hello World»), либо вы сами где-то серьёзно накосячили. Интересно было бы услышать реальный пример, откуда взялись такие цифры. Не забыв предварительно включить кэш опкода типа Zend Optimizer или APC, конечно же.
если из фреймворка можно вырвать интересующий вас кусок, то вам повезло =), делайте это!Ещё раз, я абсолютно не согласен с этим подходом! Весь смысл в использовании фреймворка заключается в том, что его компоменты проектируются для простого и удобного совместного использования. Тут присутствует синергетический эффект — фреймворк в целом использовать намного эффективнее, чем сумму всех его компонентов по-отдельности. Это всё равно что взять готовый автомобиль, разобрать его на детали, взять понравившиеся (колёса, двигатель и коробку передач), а всё остальное (кузов, подвеску, фары...) сделать самостоятельно и рассчитывать на то, что результат получится лучше, чем изначальный вариант автомобиля.
Я не спорю, есть умельцы, которые способны на это, но таких скорее единицы.
Как я уже написал выше, я сам иду по другому пути — наследую компоненты фреймворка и добавляю в них ту функциональность, которой лично мне нехватает.
К автомобилям наследование не применимо (к сожалению), так что ближайшая аналогия — это взять стандартную модель автомобиля, а потом прикручивать/менять детали по мере необходимости, например установить ксенон и спойлер, разукрасить кузов аэрографией, поставить турбину или чип-тюнинг, если турбина уже есть и т.д.
А по поводу «худения» — если выполнение кода фреймворка занимает 70-95% времени выполнения скрипта, то либо у вас просто офигительно простая бизнес-логика (приложение «Hello World»), либо вы сами где-то серьёзно накосячили. Интересно было бы услышать реальный пример, откуда взялись такие цифры. Не забыв предварительно включить кэш опкода типа Zend Optimizer или APC, конечно же.
Как я уже написал выше, я сам иду по другому пути — наследую компоненты фреймворка и добавляю в них ту функциональность, которой лично мне нехватает
впринципе я не против такой позиции, просто у меня другая. Ну не находил я фраймов которые имеют привлекательные мне слои абстракции, а ведь с этого все начинается.
Я понял вас, понял ваши аргументы, но они мне кажутся недостаточно значительны чтобы избрать фреймворк и присоединиться к таким людям, да я изучаю фреймворки, но не сажаю на них свои большие проекты.
я предпочитаю библиотеки: инструменты которые отлажено решают узкий класс задач, которые избавлены от необходимости жить в особой среде фреймворка — это мой выбор, а то ваш, у нас нет точек конфронтации.
скажите а как цитатки вставлять? а то я тут новенький =)
Такого неграмотного текста в захабренном топике я еще не видел.
Я сам использую в некоторых проектах фреймворки и никогда не был против них, но автор на мой взгляд либо не очень понимает, о чем пишет, либо не очень понимает, как об этом писать.
Если я ничего не путаю, всегда были паттерны проектирования, а не программирования. Что такое паттерны программирования?
Я сам использую в некоторых проектах фреймворки и никогда не был против них, но автор на мой взгляд либо не очень понимает, о чем пишет, либо не очень понимает, как об этом писать.
Если я ничего не путаю, всегда были паттерны проектирования, а не программирования. Что такое паттерны программирования?
Хотелось бы узнать, какими фреймворками (на «PHP JAVA C++») и как долго пользовался автор, оценить опыт так сказать.
в контексте PHP, сейчас я работаю в проекте с ZF, также приходилось использовать CakePHP, про java — NetBeens предлагает огромнейший выбьор всего, за приделы редко вылетал.
А какие книги читал автор как-то связанные с программированием? :)
Хотелось бы узнать что надо прочитать, чтобы выдать подобный перл «с функциональным распределением вычислений, так и с распределением вычислений по данным»
Хотелось бы узнать что надо прочитать, чтобы выдать подобный перл «с функциональным распределением вычислений, так и с распределением вычислений по данным»
ндя… проблема понимания конечно лежит на говорящем, но это не работает в нашем случае… гуглите — все написано.
Вот что выдал гугл.
Нет результатов для «»функциональное распределение вычислений«»
Нет результатов для «»распределение вычислений по данным«»
Нет результатов для «»функциональное распределение вычислений«»
Нет результатов для «»распределение вычислений по данным«»
Проблема в том что вы читали в умных статьях словосочетание «распределённые вычисления», а когда писали свою статью надо было сделать из себя некоего авторитета в этом вопросе, и рассказывая о своём опыте, начали добавлять непонятные термины. Но людям, которые варятся в этом, подобные слова вызвали обратный эффект.
Далее перед публикацией стоило пройти по статье ещё один раз и смело удалять подобные абзацы
«доверие к С++, С и Java обусловлено вовсе не одним фактом бренда, который за ними стоит, хотя и им тоже, но еще и старостью технологии Java`е тока не давно сан сделал полную среду свою, а до этого так же были склады решений и все рылись в них, достаточно вспомнить эпопею с аспектным программированием.»
у которых смысл — сделать многа букав.
И рассуждая о таких вещах, было бы логичнее заставлять людей задаваться вопросом, а не вбивать свою точку зрения.
p.s. хорошие программисты пишут велосипеды, и они понимают когда это оправдано, а когда нет :) Возможно у начинающих ещё возникают по этому поводу какие-то вопросы, а опытные просто решают задачу, и если существующие решения не подходят, то они делают велосипед.
иии… зачем срать в карму ?! :)
Далее перед публикацией стоило пройти по статье ещё один раз и смело удалять подобные абзацы
«доверие к С++, С и Java обусловлено вовсе не одним фактом бренда, который за ними стоит, хотя и им тоже, но еще и старостью технологии Java`е тока не давно сан сделал полную среду свою, а до этого так же были склады решений и все рылись в них, достаточно вспомнить эпопею с аспектным программированием.»
у которых смысл — сделать многа букав.
И рассуждая о таких вещах, было бы логичнее заставлять людей задаваться вопросом, а не вбивать свою точку зрения.
p.s. хорошие программисты пишут велосипеды, и они понимают когда это оправдано, а когда нет :) Возможно у начинающих ещё возникают по этому поводу какие-то вопросы, а опытные просто решают задачу, и если существующие решения не подходят, то они делают велосипед.
иии… зачем срать в карму ?! :)
доверие к С++, С и Java обусловлено вовсе не одним фактом бренда, который за ними стоит, хотя и им тоже, но еще и старостью технологии Java`е тока не давно сан сделал полную среду свою, а до этого так же были склады решений и все рылись в них, достаточно вспомнить эпопею с аспектным программированием.
Сразу понятно, что человек о Java знает только по наслышке и пишет наугад, по тем обрывкам, которые достались. Доверие ко всему остальному тексту, соответственно, резко падает.
никогда не использовал, и надеюсь никогда не буду. а времени жалко только на нудную монотонную работу.
зависла на фразе «еще и старостью технологии Java`е тока не давно сан сделал полную среду свою»
Только изобретя своих 2-3 велосипеда, понимаешь, что они все изобретены до тебя и начинаешь пользоваться уже изобретенными.
В свое время был согласен с автором этого топика — лучше писать свое, все свое. Но сейчас — строго противоположного мнения — потратил целую кучу денег на ненужные разработки — люди, пишущие фреймворки, очень сильно углубляются в свою конкретную проблематику и решают задачу «с головы до ног». Чтобы сделать свое, так же глубоко затрагивающее все используемые в разработке аспекты создания ИТ-проектов, нужны немыслимые инвестиции.
Плюс, фреймворки часто написаны очень качественно, их авторы часто очень заботятся и о качестве кода и о качестве самих фреймворков.
Мы, например, используя в качестве платформы .NET, используем от 15 разных фреймворков для решения самых разных задач. Как такое можно написать, поддерживать и развивать своими силами, не будучи огромной компанией — вообще не представляется.
Плюс, фреймворки часто написаны очень качественно, их авторы часто очень заботятся и о качестве кода и о качестве самих фреймворков.
Мы, например, используя в качестве платформы .NET, используем от 15 разных фреймворков для решения самых разных задач. Как такое можно написать, поддерживать и развивать своими силами, не будучи огромной компанией — вообще не представляется.
За грамотность Вам — двойка.
Поддерживаю автора. Поставил «+».
повторное использование готового кода — краеугольный камень программирования еще со времен Грейс Моррей Хоппер. когда у вас станет поменьше свободного времени, то вам придется сделать выбор, результат которого вполне очевиден.
умение решать типичные задачи так же краеугольный камень времен Аристотеля, идея поста направлена не против фреймов, а за велики
очень много типичных и нетипичных задач приходится решать даже при использовании готовых библиотек. и много элементарных алгоритмов нужно знать и уметь применять даже используя готовые библиотеки. я не хочу, чтобы начинающие программисты прочитали этот пост и воодушевились тем, что для них нет необходимости в изучении накопленного годами опыта. просто для примера: с подходом, который провозглашает автор, никогда не было бы Google Chrome.
хорошо или плохо использовать фреймворки? искать универсальный ответ на этот вопрос бесполезно. в каждом случае нужно думать. иметь готовое «да» или «нет» очень заманчиво, но это слишком простое решение, которое не всегда работает.
хорошо или плохо использовать фреймворки? искать универсальный ответ на этот вопрос бесполезно. в каждом случае нужно думать. иметь готовое «да» или «нет» очень заманчиво, но это слишком простое решение, которое не всегда работает.
вот такие шибко грамотные понапишут своего, а потом разбирайся что они там навертели.
помните, что ваши велосипеды потом придётся поддерживать другим.
стандартные фреймворки — это книги, документация, сообщество, faq, примеры и т.п.
а сколько страниц документации пишется на ваш очередной велосипед?
я думаю среднее значение — около 0. хорошо ещё если комменты в коде есть.
ну и, конечно, рассуждения написанные настолько безграмотным русским языком даже и читать неприятно. с трудом дочитал до конца.
помните, что ваши велосипеды потом придётся поддерживать другим.
стандартные фреймворки — это книги, документация, сообщество, faq, примеры и т.п.
а сколько страниц документации пишется на ваш очередной велосипед?
я думаю среднее значение — около 0. хорошо ещё если комменты в коде есть.
ну и, конечно, рассуждения написанные настолько безграмотным русским языком даже и читать неприятно. с трудом дочитал до конца.
подскажите пожалуйста новичку, захотел изучить веб-программирование, но с чего начать? столько всего… django, ruby, php, zf, grails, python, и т.д.
я так понимаю надо начать с PHP как с текущего стандарта, а потом приниматься за какой-нибудь фреймворк?
P.S. Подскажите плизз хороший ресурс по PHP (аналог Camelbook для Perl, или Djangobook для Django).
Заранее огромное спасибо.
я так понимаю надо начать с PHP как с текущего стандарта, а потом приниматься за какой-нибудь фреймворк?
P.S. Подскажите плизз хороший ресурс по PHP (аналог Camelbook для Perl, или Djangobook для Django).
Заранее огромное спасибо.
если вопрос ко мне, то считаю, что нужно начать с задачи. поставить простенькую задачку и решить ее, конечно вначале я считаю не нужно использовать никаких фреймов, потому что нужно понять какие бывают проблемы, какие встают трудности, только когда вы узнаете какие бывают проблемы вы сможете начать искать решения. Но это моя позиция, есть другие.
Процитирую себя же:
1. Первым делом пишем в гугле установка apache и php. Узнаем что такое apache, php и mysql.
2. Настраиваем все это, пытаемся понять, что по сути вместо apache и mysql, могут быть различные компоненты, nginx, iss, postresql, oracle и т.д.
3. Лезем на php.net/manual/ru и узнаем как вообще пишется на этом языке
4. Покупаем книжку «Совершенный код», начинаем читать.
4.х Если новичек в програминге вообще — то покупаем кучу книг по программингу, желательно больше теоретические, всякий мусор типа PHP в поддлиннике для супер-профи — лучше не брать, хоть все будет гораздо легче, но потеряете много времени, потому как будете считать что именно вот так вот надо писать код, как написано в них. А в них по большей части написан бред для полоумных.
5. Пишем простенькие приложения, смотрим что куда, как и что, вникаем в тонкости языка. Радуемся первому собственноручно написаному блог-движку, форуму и левой цмс-ки которая вообщем то ничего и не умееет.
6. Качаем ZF, Symfony, Prado, CodeIgniter, Solar, CakePHP и изучаем код и возможности, пытаясь понять как вообще используется язык на котором будем писать.
7. Понимаем что вообщем-то стали уже довольно сильными девелоперами и выбираем путь сами…
Так вот мне в последнее время приходят мысли о том, что програмера новому языку следуюет учить по схеме:
Погонять по мануалу, показать что вообще есть в языке, дать почитать «Совершенный код», и после посадить на изучение кода какого-нибудь фреймворка, что пограмотнее написан, что бы посмотрел сразу как надо правильно использовать возможности языка. Осилит все это — готовых решений от него ждать надо будет недолго, неосилит — да и не нужен такой.
1. Первым делом пишем в гугле установка apache и php. Узнаем что такое apache, php и mysql.
2. Настраиваем все это, пытаемся понять, что по сути вместо apache и mysql, могут быть различные компоненты, nginx, iss, postresql, oracle и т.д.
3. Лезем на php.net/manual/ru и узнаем как вообще пишется на этом языке
4. Покупаем книжку «Совершенный код», начинаем читать.
4.х Если новичек в програминге вообще — то покупаем кучу книг по программингу, желательно больше теоретические, всякий мусор типа PHP в поддлиннике для супер-профи — лучше не брать, хоть все будет гораздо легче, но потеряете много времени, потому как будете считать что именно вот так вот надо писать код, как написано в них. А в них по большей части написан бред для полоумных.
5. Пишем простенькие приложения, смотрим что куда, как и что, вникаем в тонкости языка. Радуемся первому собственноручно написаному блог-движку, форуму и левой цмс-ки которая вообщем то ничего и не умееет.
6. Качаем ZF, Symfony, Prado, CodeIgniter, Solar, CakePHP и изучаем код и возможности, пытаясь понять как вообще используется язык на котором будем писать.
7. Понимаем что вообщем-то стали уже довольно сильными девелоперами и выбираем путь сами…
ответы на основные обвинения чтоб не писать каждому а то много написали.
ключевые слова в англ яз. литературе: data parallel и message passing
возможно мой перевод не корректный, но ваши посты впринципе направлены против меня, в таких сообщениях видно отсутствие попыток понять собеседника, карму понижаю ибо не конструктивные ответы… мне не нужно вообше делать авторитета или что либо в таком духе, я удивлен что сообщению уделено такое внимание.
ведь топик-то не о вреде фраймворков, а о полезности великов.
а что вам тут не нравится?
не нравится мой русский язык — конструктивно товарищи! прoтивно читать — не читайте! большенство тех, кто тут резко высказались ни написали вообще ничего.
не нравится моя позиция — это понятно (но я ж не говорю чтоб вы отказались от своей, а вы меня как носителя позиции отличной от вашей обвиняете именно). Да, я считаю что велосипеды нужно уметь писать, нужно чувствовать в себе силы написать либо кусок фрейма либо его целиком если это вам нужно.
ключевые слова в англ яз. литературе: data parallel и message passing
возможно мой перевод не корректный, но ваши посты впринципе направлены против меня, в таких сообщениях видно отсутствие попыток понять собеседника, карму понижаю ибо не конструктивные ответы… мне не нужно вообше делать авторитета или что либо в таком духе, я удивлен что сообщению уделено такое внимание.
ведь топик-то не о вреде фраймворков, а о полезности великов.
а что вам тут не нравится?
не нравится мой русский язык — конструктивно товарищи! прoтивно читать — не читайте! большенство тех, кто тут резко высказались ни написали вообще ничего.
не нравится моя позиция — это понятно (но я ж не говорю чтоб вы отказались от своей, а вы меня как носителя позиции отличной от вашей обвиняете именно). Да, я считаю что велосипеды нужно уметь писать, нужно чувствовать в себе силы написать либо кусок фрейма либо его целиком если это вам нужно.
>ключевые слова в англ яз. литературе: data parallel и message passing
начнём вступительный курс с википедии :) en.wikipedia.org/wiki/Concurrent_computing
кстати, интересно взглянуть на кусок пхп кода, в котором у вас реализован «message passing» :)
начнём вступительный курс с википедии :) en.wikipedia.org/wiki/Concurrent_computing
кстати, интересно взглянуть на кусок пхп кода, в котором у вас реализован «message passing» :)
> не нравится мой русский язык — конструктивно товарищи! прoтивно читать — не читайте!
конструктивно — это «виноват, обещаю исправиться». а так получается какая-то воинствующая безграмотность.
> ведь топик-то не о вреде фраймворков, а о полезности великов.
каждый программист в своей карьере должен изобрести определённое число велосипедов — чисто для тренировки.
это и обсуждать смысла нет — просто этапы развития. просто заниматься надо этим надо в своей собственной песочнице и не выносить за её пределы.
в общем, есть мнение, что автор ещё слишком молод и неопытен. это пройдёт.
конструктивно — это «виноват, обещаю исправиться». а так получается какая-то воинствующая безграмотность.
> ведь топик-то не о вреде фраймворков, а о полезности великов.
каждый программист в своей карьере должен изобрести определённое число велосипедов — чисто для тренировки.
это и обсуждать смысла нет — просто этапы развития. просто заниматься надо этим надо в своей собственной песочнице и не выносить за её пределы.
в общем, есть мнение, что автор ещё слишком молод и неопытен. это пройдёт.
человек, продвигающий идею великов О_О — жесть. Стандарты http, xml, работа с db, сокетами, RMC, RMI, security, звук, графика — притаились в ожидании, когда вы перепишите их своей реализацией. )))))))
Считаю, что использовать фреймворки нужно осторожно(как и писать свои), чтобы не было нагромождений ненужной фигни. В принципе, делая несколько проектов подряд, пытаешься организацию их работы делать похожей, это и есть зачатки фреймворка, и если развить их, то скорость разработки и эффективность возрастает.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Фреймворк или свои велосипеды?