Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 56
По-моему, стоит различать писание сайтов «для себя» и реальные коммерческие разработки.
Свой «самопал» никто не должен видеть.
Иначе все будут видеть «SUPER ULTRA CMS v1.0 by CoolCoder».
Иначе все будут видеть «SUPER ULTRA CMS v1.0 by CoolCoder».
Я бы не был таким категоричным, чтобы прямо никто не видел.
Если «самопал» устраивает того, кто им пользуется, и не имеет явных дыр безопасности — то почему его никто не должен видеть?
Если «самопал» устраивает того, кто им пользуется, и не имеет явных дыр безопасности — то почему его никто не должен видеть?
А кто может гарантировать, что их нет?
Никто не может, но вы не самый плохой программист, и вы таких дыр не видите- это уже хорошо. А если ко всему этому ваш сайт не имеет огромной посещаемости и конкурентов, которые могут заказать взлом вашего сайта — так пользуйтесь на здоровье.
Не всем нужен огромный и мощный движок. Некоторых вполне устраивает минималистический самописный сайтик с понятной автору админкой.
Не всем нужен огромный и мощный движок. Некоторых вполне устраивает минималистический самописный сайтик с понятной автору админкой.
Я не видел элементарный sql-inj. Может в запарке был, когда писал данный кусок, может еще что. Нашел примерно через год. Вы все-еще считаете, что когда код видите только вы, можно с уверенностью говорить о какой-то там безопасности?
в принципе даже если делает сообщество — баги тоже бывают и всеравно выкатываются обновления, закрывающие иногда очень даже чудовищные баги.
так что тут гарантий никогда не может быть в отсутствии багов. Разница только в порядке их количества.
так что тут гарантий никогда не может быть в отсутствии багов. Разница только в порядке их количества.
Есть еще один момент. К чужому коду относишься с подозрением, а значит и проверяешь его лучше чем свой ;)
имхо, дело не в подозрительности, а просто в том, что глаз не «замылен».
— Что же из этого следует?
— Следует жить! Шить сарафаны и легкие платья из ситца…
— Вы полагаете, все это будет носиться?
— Я полагаю, что все это следует шить
Конечно же нужно писать свои CMS/Frameworks, и не одну — только так можно чему-либо научиться. И только написав их и наступив на десятки граблей, можно прочувствовать, чем же существующие инструменты лучше.
Но чтобы к этому прийти, их следует написать.
— Следует жить! Шить сарафаны и легкие платья из ситца…
— Вы полагаете, все это будет носиться?
— Я полагаю, что все это следует шить
Конечно же нужно писать свои CMS/Frameworks, и не одну — только так можно чему-либо научиться. И только написав их и наступив на десятки граблей, можно прочувствовать, чем же существующие инструменты лучше.
Но чтобы к этому прийти, их следует написать.
Отказался от использования чужих CMS, когда матушка попросила написать маленький сайт для ТСЖ (она председатель). Возможности платить за хостинг не было, а посему пришлось найти что-то ущербное, но бесплатное. Учитывая жёсткую потребность в экономии трафика, места на диске и процессорного времени и пришлось отказаться от всех чужих CMS-ок и творить самому.
Хотя нет, вру: я использовал ещё Twig в качестве шаблонизатора. Однако и его я постарался максимально уменьшить вырезав то, что не использовалось.
Ну взяли бы F3 какой-нибудь или что-то легковесное с минимумом функциональности. Зачем сразу за Zend хвататься. Плюс его если кастомно собрать — то тоже не так и много кода получается.
Ну, я как-то не особо знаком с существующими CMS, знаю в основном крупные и тяжёлые, поэтому и начал писать с нуля. Да и работа, признаться, была элементарная. Всего получилось два php файла, сам Twig и xml файлы, содержащие контент для вывода. А все шаблоны, изображения и прочую статику вынес на narod :)
Как насчёт GetSimple cms? Не требуется БД, использование ресурсов по минимуму. Добротная простая маленькая cms.
Или cmsimple как крайний экстремальный вариант (дистрибутив меньше 50 килобайт).
Это просто к тому что «всё ужеукраде... написано до нас».
Или cmsimple как крайний экстремальный вариант (дистрибутив меньше 50 килобайт).
Это просто к тому что «всё уже
Коммерческие CMS создаются целыми группами людей, командами из высококлассных (хотелось бы верить) специалистов разных областей. Современные лидеры коммерческих CMS — это как камни обточенные водой. Они обтачивались годами, и ещё будут обтачиваться годами, так как с новыми технологиями и новыми трендами нужны и новые разработки, которые опять таки один человек не сможет внедрять, поэтому продолжает работать команда.
Я к чему это все — самопальный движ архиполезная штука в плане получения опыта, такими вещами закаляются программисты зачастую до очень хороших специалистов, но такой CMS коммерческой не быть. Таково моё мнение.
Я к чему это все — самопальный движ архиполезная штука в плане получения опыта, такими вещами закаляются программисты зачастую до очень хороших специалистов, но такой CMS коммерческой не быть. Таково моё мнение.
Зато такая CMS не будет массово взломана скрипткиддсами. Для них самый эффективный взлом — поиск по интернету не обновлённых версий CMS с найденными уязвимостями. От целенаправленного взлома, опять же, известная CMS спасёт не сильно лучше, чем сколько-нибудь грамотно сделанная своя.
Так что имхо — в не массовых масштабах — вполне могут быть и коммерческими. Т.е. продажа под конкретного заказчика.
Так что имхо — в не массовых масштабах — вполне могут быть и коммерческими. Т.е. продажа под конкретного заказчика.
Глядя на исходники Битрикса иногда хочется верить, что ее писал не школьник лет 10 назад. Проблема большинства CMS-сок — проблема совместимости. Именно эта проблема не позволяет разработчикам отказаться от архитектуры системы в пользу чего-то более нового.
К сожалению на хабре отсутствует возможность ответить сразу двум людям. Ну или к счастью, не форум же.
В общем отвечаю вам и webkumo — вы правы, я под влиянием мыслей о своих проектах просто по ошибке посчитал что разработка CMS инициируется исключительно для широкого использования и продвижения в массы, аки drupal, wordpress, и т.д.
По индивидуальным проектам моё мнение такое — свою CMS необходимо разрабатывать только для тех нетривиальных случаев, в которых ресурсами существующих не обойтись.
На примере велосипеда (боже, какой популярный персонаж среди разработчиков) — если требуется велосипед, — все что надо сделать это сесть и поехать. Но если нужна ракета, то конечно её нужно разрабатывать, а не перепаивать злополучного педального коня.
В общем отвечаю вам и webkumo — вы правы, я под влиянием мыслей о своих проектах просто по ошибке посчитал что разработка CMS инициируется исключительно для широкого использования и продвижения в массы, аки drupal, wordpress, и т.д.
По индивидуальным проектам моё мнение такое — свою CMS необходимо разрабатывать только для тех нетривиальных случаев, в которых ресурсами существующих не обойтись.
На примере велосипеда (боже, какой популярный персонаж среди разработчиков) — если требуется велосипед, — все что надо сделать это сесть и поехать. Но если нужна ракета, то конечно её нужно разрабатывать, а не перепаивать злополучного педального коня.
В академических интересах нужно и то, и другое попытаться написать. Для конкретной работы уже исходить из поставленной задачи лучше. Если можно использовать готовую CMS, то почему нет? Ну а если вы решили уже написать что-то такое, что выходит за рамки той или иной CMS (не имеется ввиду, что они этого не умеют, или плагинов нету), или элементарно нужна свобода для разработки, то лучше взять фреймворк. В таком случае и свобода есть, и необходимых ряд задач уже решен. А вот насчет написания своего фреймворка могу только повториться — только в академических интересах.
Свой самопал категорически не советую писать. Даже совсем новичку, даже в учебно-познавательных целях.
То время, которое вы потратите на написание очередного велосипеда, вы бы могли провести за сессией изучения популярного фреймворка или чтения полезной литературы. Учитесь ценить своё время, оно очень дорогое :)
Если задачка написать «2 странички для мамы» — всегда можно посмотреть в сторону micro framework — Silex, F3, к примеру.
P.S.
ZF — хороший фреймворк, но автор явно либо лукавит, либо отстал от трендов. Сейчас Symfony нет равных, вообще. Без преувеличений.
Более того, благодаря тому что отличные спецы из Zend периодически страдают NIH синдромом, они скоро встанут перед веселым выбором либо использовать компоненты Symfony, либо вылететь с этой ниши.
То время, которое вы потратите на написание очередного велосипеда, вы бы могли провести за сессией изучения популярного фреймворка или чтения полезной литературы. Учитесь ценить своё время, оно очень дорогое :)
Если задачка написать «2 странички для мамы» — всегда можно посмотреть в сторону micro framework — Silex, F3, к примеру.
P.S.
Наверное многие согласятся что на первом месте стоит Zend, а дальше пошли все остальные. Zend с каждым годом «мужает» оптимизируется код, улучшается безопасность, появляются новые модули, возможности расширения и т.д. и это все благодаря тем отличным спецам что его поддерживают.
ZF — хороший фреймворк, но автор явно либо лукавит, либо отстал от трендов. Сейчас Symfony нет равных, вообще. Без преувеличений.
Более того, благодаря тому что отличные спецы из Zend периодически страдают NIH синдромом, они скоро встанут перед веселым выбором либо использовать компоненты Symfony, либо вылететь с этой ниши.
… И если вы все же возьметесь писать свой самопал — очень прошу, не используйте его в коммерческих целях. Не подкладывайте свинью своему клиенту и возможному коллеге, которому придется этот говнокод поддерживать.
Я уверен, что это будет говнокод просто потому что в наше время один человек в своё свободное время и с ограниченным опытом никогда не напишет что-то лучше, чем большая группа мотивированных и талантливых разработчиков.
Я уверен, что это будет говнокод просто потому что в наше время один человек в своё свободное время и с ограниченным опытом никогда не напишет что-то лучше, чем большая группа мотивированных и талантливых разработчиков.
Не соглашусь с Вами.
Изучать мануалы и коды это одно, практика совсем другое, иногда практика от теории сильно отличаются. Получить хорошую практику сидя с самого начала на одном фреймворке не выйдет.
Выбор Zend, Symfony или F3 это зависит от поставленных задач.
Изучать мануалы и коды это одно, практика совсем другое, иногда практика от теории сильно отличаются. Получить хорошую практику сидя с самого начала на одном фреймворке не выйдет.
Выбор Zend, Symfony или F3 это зависит от поставленных задач.
Been there, done that.
Если бы меня 2 года назад кто-нибудь заставил вместо написания полнейшего, неюзабельного говнокода, детально разбирать популярный фреймворк (именно делательно, через дебаггер и с пониманием зачем что делается на каждом этапе), сейчас я был бы гораздо сильнее, как специалист. Вместо этого приходится нагонять упущенное.
Если бы меня 2 года назад кто-нибудь заставил вместо написания полнейшего, неюзабельного говнокода, детально разбирать популярный фреймворк (именно делательно, через дебаггер и с пониманием зачем что делается на каждом этапе), сейчас я был бы гораздо сильнее, как специалист. Вместо этого приходится нагонять упущенное.
Если абстрагироваться от языка, то сейчас Ruby on Rails нет равных, вообще. Без преувеличений
Тонко, но насчет Symfony, что касается мира PHP, я действительно не преувеличивал.
Просто долго расписывать все значимые проекты и людей, которые поддерживают Symfony (весь фреймворк или его компоненты), не хотелось захламлять комментарии этим. Навскидку — Drupal, Joomla, phpbb, ezPublish, Laravel, Zikula, BBC News.
Просто долго расписывать все значимые проекты и людей, которые поддерживают Symfony (весь фреймворк или его компоненты), не хотелось захламлять комментарии этим. Навскидку — Drupal, Joomla, phpbb, ezPublish, Laravel, Zikula, BBC News.
Ну так Единственный способ освоить новый язык программирования — писать на нем программы..
Если цель — изучить все тот же самый php, то безусловно надо понимать, как именно с его помощью решать возникающие проблемы. Фреймворки — они для тех кто уже понимает зачем они нужны :)
Если цель — изучить все тот же самый php, то безусловно надо понимать, как именно с его помощью решать возникающие проблемы. Фреймворки — они для тех кто уже понимает зачем они нужны :)
Это пять!
P.S. Сам люблю, знаете, на досуге велосипед мастерить github.com/AntonShevchuk/Bluz
Фреймворки — они для тех кто уже понимает зачем они нужны :)
P.S. Сам люблю, знаете, на досуге велосипед мастерить github.com/AntonShevchuk/Bluz
Очень нравятся слова, если не ошибаюсь, Алекса Маккау — «Обязательно напишите свой MVC-фреймворк на JavaScript, а потом спрячьте его куда подальше и пользуйтесь дальше только тем, что написали другие».
Впрочем, даже в учебных целях свой фреймворк, пожалуй, следует писать, как минимум дотошно разборавшись вначале в языке, его возможностях и аналогичных чужих решениях. Иначе можно лишь напрасно потратить время.
Впрочем, даже в учебных целях свой фреймворк, пожалуй, следует писать, как минимум дотошно разборавшись вначале в языке, его возможностях и аналогичных чужих решениях. Иначе можно лишь напрасно потратить время.
Пишите, что уж там, хуже не будет.
PHP сообщество и так много лет топталось на одном месте, извергая отрыжки в виде новых супер-модных фреймворков написаных на коленке, мотивация к появлению которых была одна — «Пфф, бред какой использовать xxx, понаписали непойми чего, монструозного. Я сейчас быстренько сам напишу».
Я просто не понимаю как можно из года в год, изо дня в день, из проекта в проет решать основополагающие проблемы веб приложений: каким роутинг сделать, как хранить сессию и прочие второстепенные вещи которые должны быть решены раз и навсегда. Да даже вторая симфония, от которой все более-мение нормальные разработчики няшечные слюньки пускают является лишь жалкой копией спринга.
Ну не верю я в то, что в 2012-м году работать с формами нужно именно так, как и написано в их мануале ( symfony.com/doc/current/book/forms.html ). А работа с формами это наверное половина из всего того когда что пишут разработчики на PHP.
С кого брать пример? JavaScript. Всего лишь за несколько лет язык вырос из «да что вы бредите в js классов нет, только функции», одним словом — второго языка для веб-разработчика, в мощнейший язык на котором можно без особых усилий, приятно и красиво писать высоконагруженые игровые приложения как на фроненде, так и на бэкенде. А с чего там начиналось все? Ах да:
Поэтому даже не думайте — пишите. И еще лет через пять, когда все языки уйдут далеко вперед, кто-то из комманды разрабочкиков php в компании zend подумает, что в следующей версии неплохо было бы сделать jit-компилятор и добавить аннотации (а не перепиливать комментарии), в zf откажуются от (уже ставшей, после появления неймспейсов) идиотской системы именования классов, а в симфонии все таки сделают нормальную обработку пользовательских форм.
PHP сообщество и так много лет топталось на одном месте, извергая отрыжки в виде новых супер-модных фреймворков написаных на коленке, мотивация к появлению которых была одна — «Пфф, бред какой использовать xxx, понаписали непойми чего, монструозного. Я сейчас быстренько сам напишу».
Я просто не понимаю как можно из года в год, изо дня в день, из проекта в проет решать основополагающие проблемы веб приложений: каким роутинг сделать, как хранить сессию и прочие второстепенные вещи которые должны быть решены раз и навсегда. Да даже вторая симфония, от которой все более-мение нормальные разработчики няшечные слюньки пускают является лишь жалкой копией спринга.
Ну не верю я в то, что в 2012-м году работать с формами нужно именно так, как и написано в их мануале ( symfony.com/doc/current/book/forms.html ). А работа с формами это наверное половина из всего того когда что пишут разработчики на PHP.
С кого брать пример? JavaScript. Всего лишь за несколько лет язык вырос из «да что вы бредите в js классов нет, только функции», одним словом — второго языка для веб-разработчика, в мощнейший язык на котором можно без особых усилий, приятно и красиво писать высоконагруженые игровые приложения как на фроненде, так и на бэкенде. А с чего там начиналось все? Ах да:
<a href="javascript:onclick()">кликли меня</a>Поэтому даже не думайте — пишите. И еще лет через пять, когда все языки уйдут далеко вперед, кто-то из комманды разрабочкиков php в компании zend подумает, что в следующей версии неплохо было бы сделать jit-компилятор и добавить аннотации (а не перепиливать комментарии), в zf откажуются от (уже ставшей, после появления неймспейсов) идиотской системы именования классов, а в симфонии все таки сделают нормальную обработку пользовательских форм.
Не всё так плохо в PHP — как по мне уже сейчас язык опять начал развиваться, и создание PSR радует, и адекватный пакет менеджер появился на смену PEAR, и ZF уже в бете с уже давно нормальным именованием классов, возможно и аннотации скоро появятся — ведь уже сейчас многие фреймворки страдают обработкой комментов посредством рефлексий
Но только не стоит в него тянуть так активно что-то из Java/Ruby/Python — местами конечно клёво, но не более…
Но только не стоит в него тянуть так активно что-то из Java/Ruby/Python — местами конечно клёво, но не более…
Вот сейчас на гитхабе зашел в первый попавшийся модуль, и увидел это: github.com/zendframework/zf2/blob/master/library/Zend/Authentication/Adapter/Exception/ExceptionInterface.php и это github.com/zendframework/zf2/blob/master/library/Zend/Authentication/Adapter/Http.php
Если первое это что-то очень фееричное, выходящее за рамки чего-либо разумного (как и вся работа с исключениями в этом фреймворке), то во втором случае что поменялось то? В любом нормальном языке такой адаптер будет именоваться — HttpAdapter, а не Http в пакете adapter. Потому что название http навевает тоску. И при этом, святой ты код, этот Http (который видимо нормальными людьмю будет юзатся вместе c use Http as HttpAdapter) имплементит AdapterInterface. Супер система наименования.
Если первое это что-то очень фееричное, выходящее за рамки чего-либо разумного (как и вся работа с исключениями в этом фреймворке), то во втором случае что поменялось то? В любом нормальном языке такой адаптер будет именоваться — HttpAdapter, а не Http в пакете adapter. Потому что название http навевает тоску. И при этом, святой ты код, этот Http (который видимо нормальными людьмю будет юзатся вместе c use Http as HttpAdapter) имплементит AdapterInterface. Супер система наименования.
Косательно форм в симфони, вроде как с версии 2.1 все стало чуть лучше.
Если я могу написать что-то вроде:
То да, стало лучше. Если нет — увы.
И да, DI должен работать так:
И либо зеркальцем, либо через get\set методы запиливать зависимость.
/**
* @FomValdatorAnnotation(valid=true)
*/
publuc function onSumbitForm(MyForm $form) {
return "ololo, this is valid form";
}
/**
* @FomValdatorAnnotation(valid=false)
*/
publuc function onSumbitInvalidForm(MyForm $form) {
return "ololo, this is shit form";
}
То да, стало лучше. Если нет — увы.
И да, DI должен работать так:
SomeController extends Controller {
/**
* @Autowired(SomeService)
* @var SomeService
*/
private $someService;
public function doSomeShitWithSomeService()
{
$someService->doSomeShit();
}
}
И либо зеркальцем, либо через get\set методы запиливать зависимость.
Помниться в попытках изучить ООП, паттерны проектирования и прочее, я начал писать свой фреймворк. За тот месяц я поднял уровень намного выше, нежели за год. Так что определенно да, свои фреймворки/CMS-ки писать стоит. Но только в качестве самообучения. Для коммерческих проектов стоит серьезно подумать, перед тем как писать что-то свое. Хотя опять же для серьезных проектов как по мне и CMS-ки готовые не годятся.
Стоит писать ровно при одном из двух условий:
1. Самообучение, результаты буду выкинуты
2. Ты точно знаешь, что тебе не хватает в аналогах и ты точно знаешь, что ты хочешь сделать
1. Самообучение, результаты буду выкинуты
2. Ты точно знаешь, что тебе не хватает в аналогах и ты точно знаешь, что ты хочешь сделать
почему за ваше желание,
учиться на своих ошибках
должен платить заказчик?
учиться на своих ошибках
должен платить заказчик?
# Paul Lomax: «1. Используй то, что есть.»
# Paul Lomax: «2. Осознай, что это полный отстой.»
# Paul Lomax: «3. Напиши свое.»
# Paul Lomax: «4. Подожди, пока кто-то выпустит меньший отстой.»
# Paul Lomax: «5. Забрось свое. Используй чужое»
# Paul Lomax: «2. Осознай, что это полный отстой.»
# Paul Lomax: «3. Напиши свое.»
# Paul Lomax: «4. Подожди, пока кто-то выпустит меньший отстой.»
# Paul Lomax: «5. Забрось свое. Используй чужое»
Так стоить писать или нет? )
Для малобюджетных проектов, мелочей типо визиток и каталогов, для быстрого развертывания взять за базу цмс/фреймворк абсолютно логично (если есть опыт работы с ним) если нет своих готовых наработок.
Для больших коммерческих разработок лучшим решением будет разработка бизнес-логики и реализация без дополнительных инструментов, как практика показывает, обвешивать фреймворки своими модулями или пилянием готовых решений под свои нужды — через полгода очень трудоёмкий процесс при поддержке и развитии. Свои решения более лаконичны и легковесны, если опыт конечно есть :)
Для малобюджетных проектов, мелочей типо визиток и каталогов, для быстрого развертывания взять за базу цмс/фреймворк абсолютно логично (если есть опыт работы с ним) если нет своих готовых наработок.
Для больших коммерческих разработок лучшим решением будет разработка бизнес-логики и реализация без дополнительных инструментов, как практика показывает, обвешивать фреймворки своими модулями или пилянием готовых решений под свои нужды — через полгода очень трудоёмкий процесс при поддержке и развитии. Свои решения более лаконичны и легковесны, если опыт конечно есть :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Стоит ли писать свой Framework/CMS если есть уже готовые?