Pull to refresh

Comments 56

По-моему, стоит различать писание сайтов «для себя» и реальные коммерческие разработки.
UFO just landed and posted this here
Свой «самопал» никто не должен видеть.
Иначе все будут видеть «SUPER ULTRA CMS v1.0 by CoolCoder».
Я бы не был таким категоричным, чтобы прямо никто не видел.
Если «самопал» устраивает того, кто им пользуется, и не имеет явных дыр безопасности — то почему его никто не должен видеть?
А кто может гарантировать, что их нет?
Никто не может, но вы не самый плохой программист, и вы таких дыр не видите- это уже хорошо. А если ко всему этому ваш сайт не имеет огромной посещаемости и конкурентов, которые могут заказать взлом вашего сайта — так пользуйтесь на здоровье.
Не всем нужен огромный и мощный движок. Некоторых вполне устраивает минималистический самописный сайтик с понятной автору админкой.
Я не видел элементарный sql-inj. Может в запарке был, когда писал данный кусок, может еще что. Нашел примерно через год. Вы все-еще считаете, что когда код видите только вы, можно с уверенностью говорить о какой-то там безопасности?
в принципе даже если делает сообщество — баги тоже бывают и всеравно выкатываются обновления, закрывающие иногда очень даже чудовищные баги.

так что тут гарантий никогда не может быть в отсутствии багов. Разница только в порядке их количества.
Есть еще один момент. К чужому коду относишься с подозрением, а значит и проверяешь его лучше чем свой ;)
имхо, дело не в подозрительности, а просто в том, что глаз не «замылен».
дело не столько в «замыленности», а в том, что сложно оценить, какими еще хитрыми способами можно заставить работать тот или иной код, если ты сам его написал. а когда ты анализируешь чужой код, то в голове нет логических цепочек автора, поэтому беспристрастно взглянуть куда легче.
это и есть «не замыленность».
— Что же из этого следует?
— Следует жить! Шить сарафаны и легкие платья из ситца…
— Вы полагаете, все это будет носиться?
— Я полагаю, что все это следует шить

Конечно же нужно писать свои CMS/Frameworks, и не одну — только так можно чему-либо научиться. И только написав их и наступив на десятки граблей, можно прочувствовать, чем же существующие инструменты лучше.

Но чтобы к этому прийти, их следует написать.
а потом, попользовав чужую CMS, поняв ее минусы и места, где она не подходит вам, где мешает, где просто не покрывает простых потребностей, набив шишек и пропатчив с сотню багов надо сесть и написать свою, легковесную CMS, точно под свои задачи, грамотно, правильно, как вы это видите.
Вот поэтому года два назад я полностью перешел на фреймворки и к CMS работаю только если уж очень надо по работе.
Отказался от использования чужих CMS, когда матушка попросила написать маленький сайт для ТСЖ (она председатель). Возможности платить за хостинг не было, а посему пришлось найти что-то ущербное, но бесплатное. Учитывая жёсткую потребность в экономии трафика, места на диске и процессорного времени и пришлось отказаться от всех чужих CMS-ок и творить самому.
Хотя нет, вру: я использовал ещё Twig в качестве шаблонизатора. Однако и его я постарался максимально уменьшить вырезав то, что не использовалось.
Ну взяли бы F3 какой-нибудь или что-то легковесное с минимумом функциональности. Зачем сразу за Zend хвататься. Плюс его если кастомно собрать — то тоже не так и много кода получается.
Ну, я как-то не особо знаком с существующими CMS, знаю в основном крупные и тяжёлые, поэтому и начал писать с нуля. Да и работа, признаться, была элементарная. Всего получилось два php файла, сам Twig и xml файлы, содержащие контент для вывода. А все шаблоны, изображения и прочую статику вынес на narod :)
Ну так надо было «изучить рынок» перед написанием, не так ли? ;)

Когда 2 файла — это не случай, рассматриваемый в статье.
Как насчёт GetSimple cms? Не требуется БД, использование ресурсов по минимуму. Добротная простая маленькая cms.

Или cmsimple как крайний экстремальный вариант (дистрибутив меньше 50 килобайт).

Это просто к тому что «всё уже украде... написано до нас».
Но не обо всём же я знать могу.
Коммерческие CMS создаются целыми группами людей, командами из высококлассных (хотелось бы верить) специалистов разных областей. Современные лидеры коммерческих CMS — это как камни обточенные водой. Они обтачивались годами, и ещё будут обтачиваться годами, так как с новыми технологиями и новыми трендами нужны и новые разработки, которые опять таки один человек не сможет внедрять, поэтому продолжает работать команда.

Я к чему это все — самопальный движ архиполезная штука в плане получения опыта, такими вещами закаляются программисты зачастую до очень хороших специалистов, но такой CMS коммерческой не быть. Таково моё мнение.
Зато такая CMS не будет массово взломана скрипткиддсами. Для них самый эффективный взлом — поиск по интернету не обновлённых версий CMS с найденными уязвимостями. От целенаправленного взлома, опять же, известная CMS спасёт не сильно лучше, чем сколько-нибудь грамотно сделанная своя.
Так что имхо — в не массовых масштабах — вполне могут быть и коммерческими. Т.е. продажа под конкретного заказчика.
Глядя на исходники Битрикса иногда хочется верить, что ее писал не школьник лет 10 назад. Проблема большинства CMS-сок — проблема совместимости. Именно эта проблема не позволяет разработчикам отказаться от архитектуры системы в пользу чего-то более нового.
> но такой CMS коммерческой не быть

Согласен, не быть. Но зачем? Первостепенная задача сам проект, под который пишется фреймворк, а не он сам.
К сожалению на хабре отсутствует возможность ответить сразу двум людям. Ну или к счастью, не форум же.

В общем отвечаю вам и webkumo — вы правы, я под влиянием мыслей о своих проектах просто по ошибке посчитал что разработка CMS инициируется исключительно для широкого использования и продвижения в массы, аки drupal, wordpress, и т.д.

По индивидуальным проектам моё мнение такое — свою CMS необходимо разрабатывать только для тех нетривиальных случаев, в которых ресурсами существующих не обойтись.

На примере велосипеда (боже, какой популярный персонаж среди разработчиков) — если требуется велосипед, — все что надо сделать это сесть и поехать. Но если нужна ракета, то конечно её нужно разрабатывать, а не перепаивать злополучного педального коня.
В академических интересах нужно и то, и другое попытаться написать. Для конкретной работы уже исходить из поставленной задачи лучше. Если можно использовать готовую CMS, то почему нет? Ну а если вы решили уже написать что-то такое, что выходит за рамки той или иной CMS (не имеется ввиду, что они этого не умеют, или плагинов нету), или элементарно нужна свобода для разработки, то лучше взять фреймворк. В таком случае и свобода есть, и необходимых ряд задач уже решен. А вот насчет написания своего фреймворка могу только повториться — только в академических интересах.
Свой самопал категорически не советую писать. Даже совсем новичку, даже в учебно-познавательных целях.
То время, которое вы потратите на написание очередного велосипеда, вы бы могли провести за сессией изучения популярного фреймворка или чтения полезной литературы. Учитесь ценить своё время, оно очень дорогое :)

Если задачка написать «2 странички для мамы» — всегда можно посмотреть в сторону micro framework — Silex, F3, к примеру.

P.S.
Наверное многие согласятся что на первом месте стоит Zend, а дальше пошли все остальные. Zend с каждым годом «мужает» оптимизируется код, улучшается безопасность, появляются новые модули, возможности расширения и т.д. и это все благодаря тем отличным спецам что его поддерживают.

ZF — хороший фреймворк, но автор явно либо лукавит, либо отстал от трендов. Сейчас Symfony нет равных, вообще. Без преувеличений.

Более того, благодаря тому что отличные спецы из Zend периодически страдают NIH синдромом, они скоро встанут перед веселым выбором либо использовать компоненты Symfony, либо вылететь с этой ниши.
… И если вы все же возьметесь писать свой самопал — очень прошу, не используйте его в коммерческих целях. Не подкладывайте свинью своему клиенту и возможному коллеге, которому придется этот говнокод поддерживать.

Я уверен, что это будет говнокод просто потому что в наше время один человек в своё свободное время и с ограниченным опытом никогда не напишет что-то лучше, чем большая группа мотивированных и талантливых разработчиков.
Не соглашусь с Вами.
Изучать мануалы и коды это одно, практика совсем другое, иногда практика от теории сильно отличаются. Получить хорошую практику сидя с самого начала на одном фреймворке не выйдет.
Выбор Zend, Symfony или F3 это зависит от поставленных задач.
Been there, done that.

Если бы меня 2 года назад кто-нибудь заставил вместо написания полнейшего, неюзабельного говнокода, детально разбирать популярный фреймворк (именно делательно, через дебаггер и с пониманием зачем что делается на каждом этапе), сейчас я был бы гораздо сильнее, как специалист. Вместо этого приходится нагонять упущенное.
Я думаю, что если бы вы, даже раньше чем 2 года назад выбрали любой другой мейнстрим язык… то были бы еще сильнее как специалист.

Тонко, но насчет Symfony, что касается мира PHP, я действительно не преувеличивал.

Просто долго расписывать все значимые проекты и людей, которые поддерживают Symfony (весь фреймворк или его компоненты), не хотелось захламлять комментарии этим. Навскидку — Drupal, Joomla, phpbb, ezPublish, Laravel, Zikula, BBC News.
Не. Негодный выйдет холивар, расово неверный, воздержимя?
Ну так Единственный способ освоить новый язык программирования — писать на нем программы..

Если цель — изучить все тот же самый php, то безусловно надо понимать, как именно с его помощью решать возникающие проблемы. Фреймворки — они для тех кто уже понимает зачем они нужны :)
Это пять!
Фреймворки — они для тех кто уже понимает зачем они нужны :)


P.S. Сам люблю, знаете, на досуге велосипед мастерить github.com/AntonShevchuk/Bluz
только написав пару костылей приходит понимание того, а зачем же все эти фреймворки и почему так, а не иначе.
UFO just landed and posted this here
Очень нравятся слова, если не ошибаюсь, Алекса Маккау — «Обязательно напишите свой MVC-фреймворк на JavaScript, а потом спрячьте его куда подальше и пользуйтесь дальше только тем, что написали другие».
Впрочем, даже в учебных целях свой фреймворк, пожалуй, следует писать, как минимум дотошно разборавшись вначале в языке, его возможностях и аналогичных чужих решениях. Иначе можно лишь напрасно потратить время.
Пишите, что уж там, хуже не будет.

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 — местами конечно клёво, но не более…
Вот сейчас на гитхабе зашел в первый попавшийся модуль, и увидел это: 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. Супер система наименования.
Косательно форм в симфони, вроде как с версии 2.1 все стало чуть лучше.
Если я могу написать что-то вроде:
/**
 * @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. Получив опыт, осознает убогость своих поделок изучает что-то готовое. Становится стандартным кодером.
3. Поработав с готовым осознает некоторые проблемы существующих решений. А проблемы есть всегда. Например tradeoff между универсальностью и эффективностью — он есть всегда.
4. Приходит к своему пониманию решения каких-то проблем, создает свои фреймворки. Что касается того, что за фреймворками стоят какие-то организации и много ресурсов: фреймворк не обязательно должен быть все объемлющий, может быть какой-то специализированный, вроде Tornado — такие штуки как раз одиночки и пишут.

Фишка в том, что до 4 пункта доходят только единицы.
Согласен, к примеру тот же LiveStreet. Правда это CMS, а не framework. Но все же.
почему за ваше желание,
учиться на своих ошибках

должен платить заказчик?
Возможно потому что он хочет сэкономить?
UFO just landed and posted this here
Почему сразу наказание? Вполне очевидно, что низкобюджетный специалист получает навыки в процессе работы.
# Paul Lomax: «1. Используй то, что есть.»
# Paul Lomax: «2. Осознай, что это полный отстой.»
# Paul Lomax: «3. Напиши свое.»
# Paul Lomax: «4. Подожди, пока кто-то выпустит меньший отстой.»
# Paul Lomax: «5. Забрось свое. Используй чужое»
Так стоить писать или нет? )

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

Для больших коммерческих разработок лучшим решением будет разработка бизнес-логики и реализация без дополнительных инструментов, как практика показывает, обвешивать фреймворки своими модулями или пилянием готовых решений под свои нужды — через полгода очень трудоёмкий процесс при поддержке и развитии. Свои решения более лаконичны и легковесны, если опыт конечно есть :)

Sign up to leave a comment.

Articles