Пользователь пока ничего не рассказал о себе

Достижения

Все достижения (50)

Наибольший вклад в теги

Все теги (246)

Лучшие ответы пользователя

Все ответы (587)
  • CMS своими руками

    @egorinsk
    Автор, а что гуглить. Есть минимум 3 способа: расковырять простую Open-Source CMS (проблема: найти CMS с хорошей архитектурой и аккуратным кодом), устроиться в компанию, у которой есть своя CMS (а она есть почти у каждой студии), и наконец, написать самому правильно.

    Маны нужны не по написанию CMS, а по используемым продуктам и технологиям.

    Сначала надо определиться с задачей. Установите и попользуйтесь несколькими CMS, просто чтобы увидеть особенности их работы. (если вы не можете это сделать — вам надо изучать основы установки и настройки apache/mysql/whatever, а не CMS писать. Уходите практиковать эти навыки). Также, есть хороший сайт, где установлены демки десятков CMS и можно их посмотреть, не устанавливая.

    Запишите, что вы хотите получить, сделайте наброски страниц. Определитесь с требованиями к вашей CMS. Какие в ней будут модули, как ими можно управлять.

    CMS обычно состоит из 2 частей — т.н. «админки» (запароленный раздел, где меняется конфигурация сайта, добавляются материалы) и публичной части сайта, которую видят пользователи.

    Если вы еще не бросили эту затею, перейдем к следующему пункту. Проектирование архитектуры и написание CMS. Чтобы хорошо писать сложную CMS, нужен опыт и понимание того, как вообще писать сложные программы. Нужно глубокое знание HTTP/HTML/CSS/JS/SQL. А именно:

    — система должна быть модульной, чтобы, написав основу, можно было, не переписывая ее, не спеша добавлять модули и расширять функционал
    — система должна писаться с использованием грамотной архитектуры и аккуратного кода, так как поддержка и переписывание плохого кода будет отнимать у вас слишком много сил. А потом в нем вообще никто не сможет разобраться.

    Что еще надо знать. Во-первых, надо иметь представление что значит MVC или 3-звенная архитектура.

    M в MVC — это Model. CMS скорее всего будет хранить данные в БД — надо знать, что такое и как пишется DBAL (гуглите: PDO), плейсхолдеры в запросах, возможно, Table Gateway, ознакомиться с тем, что такое ORM, и почему PHP-ные ORM так тормозят. Если будете делать модельки, не храните значения полей в публичных свойствах — это неудобно и нарушает инкапсуляцию. Храните их в приватном массиве $attributes.

    V is for View. Надо знать, что такое шаблонизаторы (прочтите мануал по Smarty, Django Templates, HAML и XSLT, чтобы иметь общее представление, какие они бывают). Для PHP хорошие варианты — использовать чистый PHP или XSLT, если осилите. Smarty — устаревший тормозной хлам, Twig тоже имеет недостатки. И не стоит ставить шаблонизатор, только, чтобы писать {$a} вместо [?= $a =].

    Не смешивайте логику (сложные вычисления, обращение к БД) и шаблонизацию. Лучше сделайте 2 файла: один с кодом, другой с шаблоном. В идеале, шаблонизатор получает от контроллера значения переменных и, кроме хелперов, никакого другого кода не вызывает.

    C — контроллеры. Но это самая простая часть, контроллер — это просто класс с методами типа viewAction(), editAction() и роутер, который смотрит на УРЛ и вызывает нужный контроллер. Посмотрите, как устроен Zend_Controller и Zend_Front_Contriller, и сделайте так же, но попроще. выкинув 90% функционала — он вам не понадобится.

    Нужно как-то сделать систему компонентной без сильных связей: чтобы ядро могло работать и без модулей, а добавление модуля не требовало дописывания кода в ядро. Почитайте про Dependency Injection, а также Observer (observer — это когда мы делаем функцию addEventListener()).

    Не используйте хуки, как в Друпал. Это дурной и порочный путь, взятый видимо из древных времен и программирования на Си.

    Что еще. Освоив все эти понятия, у вас в принципе не будет сложностей написать CMS, но почитайте еще мои советы по тому, как писать правильный код с исп. ООП: habrahabr.ru/qa/17158/#answer_70869

    Написание своих велосипедов, в общем, полезно и способствует расширению кругозора разработчика, заставляет его изучать разные подходы к написанию кода.

    Ну что еще. Если (в чем я сильно сомневаюсь) благодаря моему скромного совету вы все же сможете пройти этот нелегкий путь и станете успешным разработчиком, можете заплатить мне денег. Я не против.
    Ответ написан
    Комментировать
  • Что такое оверхэд (overhead)?

    @egorinsk
    Неизбежные накладные расходы.

    Например, программа, которую вы написали, делает полезную работу в течение 10 мс, но на запуск и завершение виртуальный машины Ява уйдет дополнительно 5 секунд, и эти 5 секунд будут оверхедом.
    Ответ написан
    2 комментария
  • Что плохого в вёрстке таблицами?

    @egorinsk
    Начнем с того, что все, что делается таблицами, делается и CSS (просто надо не лениться и прочитать соответствующие руководства). У таблиц есть недостатки:

    — нельзя перегруппировать блоки для узких страниц или в версии для печати только с помощью CSS
    — если мы выводим список картинок таблицей, каждая картинка в ячейке, то при добавлении или удалении картинки оставшиеся не сдвигаются, а остается пустое место
    — у ячеек width работает как min-width, при этом алгоритмы ратяжения ячеек не документированы и ведут себя непредсказуемо, из-за этого они могут непредсказуемо растягиваться, и хуже того, при динамической замене контента они не всегда сжимаются обратно и остаются дыры. Одно длинное слово или картинка может растянуть всю страницу.
    — фиксированное, абсолютное и относительное позиционирование неюзабельно в таблицах
    — ячейки не получится перетаскивать drag-n-drop
    — трудно манипулировать DOM (надо хитро вставлять и убирать дополнительные элменеты)
    — верстка получается замусоренная кучей лишних тегов, которые тяжело читать и в которых тяжело разобраться. Это не HTML, а лапша. Особенно тяжело, когда таблицы вложены друг в друга и раскиданы по куче шаблонов.
    — нельзя поместить контент в коде первым, а меню в шапке — вторым (некоторые сеошники считают, что это улучшает индексацию)
    — верстка таблицами всегда была костылем (и это несемантично), с поддержкой CSS2 (появилась более 10 лет назад) таблицы стали не нужны. 10 лет назад они уже стали ненужными.

    Давайте, расскажите хоть одну причину использовать устаревшую много лет назад технологию. Поддержка IE4? Верстальщик-пенсионер?
    Ответ написан
    4 комментария
  • Как эффективно переучиться на веб-разработчика?

    @egorinsk
    Вообще, не увлекайтесь спецификациями. Марк Цукерберг как-то без них обошелся. Google тоже не следует строгим стандартам.

    Если вы хотите «эффективно» изучить матеиал, тогда вы должны читать статьи «для чайников» (которые вы с вашим опытом, наверняка освоите за кратчайшее время). HTML/CSS так устроены, что даже если вы сделаете 100 ошибок на странице, он все равно как-нибудь да отобразится. Ну если вы хотите более солидные знания, то параллельно смотрите непонятные моменты в спецификациях, это в общем-то полезно. А сэкономленное время посвятите практике. Она тут очень важна.

    Вот, что стоит изучить (в любом порядке):

    1) Начните с основ HTTP (только ради бога, не читайте спецификацию целиком, хватит общего представления о методах запросов, заголовках и теле запроса, кодах ответа 403/404/500/200/300)
    2) Изучите основы HTML (есть раздел на сайте htmlbook). SGML вам хватит в том объеме, в котором он упоминается в спецификации HTML. PCDATA не упоминается в ней и потому знать про отличия от CDATA вам не нужно (ну если так хотите узнать, найдите спецификацию SGML и почитайте).

    Обратите внимание, в некоторых (некачественных) статьях вы можете увидеть штуки вроде [br /] — самозакрывающиеся теги. Это ошибочный синтаксис, который употребляют авторы, путающие HTML и XHTML. В HTML такого синтаксиса нет (хотя в силу своей толерантности к ошибкам в HTML такой код как-то работает).

    3) Изучите CSS и позиционирование элементов. Вот хороший учебник, разъясняющий тонкости всяких флоатов: softwaremaniacs.org/blog/category/primer/ А спецификацию CSS2.1, думаю, вы нагуглите сами, она довольно понятно написана.

    4) Изучите яваскрипт (да, включая замыкания и прототипы) и DOM. Обратите внимание, jQuery — лишь обертка над DOM и не зная DOM, вы не сможете нормально пользоваться jQuery, вы лишь научитесь копипастить скрипты из интернета, не понимая, как они работают. После этого можете изучать jQuery, заодно советую заглянуть в исходный код, а не только читать документацию.

    5) Изучите один из серверных языков, хотя бы основы

    6) Изучите основы SQL

    7) Начинайте что-нибудь делать, так как в этот момент у вас будет очень много теоретических знаний и очень мало практических. Можете сделать простое веб-приложение, можете улучшить какое-нибудь существующее.

    8) Изучите ООП

    9) Изучите какой-нибудь серверный MVC-фреймворк

    В общем, я думаю, стоит изучить базовые технологии, и приобретать практические навыки, а дальше неизвестно, понадобится ли вам HAML или что-то еще. Большинство упомянутых вами технологий изучать необязательно. Изучать надо то, что вам нужно для решения задачи, а не все подряд (иначе на это могут уйти года).

    > А есть ещё и XHTML, который тоже имеет свои отличия…

    Его уже нет, его никто не будет развивать и использовать, более того, и раньше многие использовали не XHTML, а лишь похожий на XHTML синтаксис (в частности самозакрывающиеся теги), а на деле писали HTML. Вы можете изучить его, но только ради любопытства, а не ради практической пользы.

    > Клиентская разработка нынче редко обходится без всяких шаблонизаторов типа HAML/SASS

    Вы еще Coffescript забыли упомянуть. Это очень спорные вещи, есть мнения как за, так и против. Но в любом случае, согласитесь, как-то странно изучать SASS, не изучив вначале CSS, верно? Начинающему это не нужно.

    > а для эффективной серверной разработки всё и того сложнее: фреймворки, ORM, continuous integration, очереди задач и прочая-прочая.

    Для приложения из 3 страниц все это не нужно. Сложные технологии нужны в больших и огромных проектах, начинать можно и без них. И более того, не имея определенного опыта работы с кодом, вы вряд ли поймете, зачем это нужно. А когда понадобятся, тогда и изучите.

    По вопросу, где брать информацию: авторитетные источники (для поиска ответа во всех подробностях) — это спецификации W3C, официальная документация фреймворков, неофициальные источники вроде htmlbook, stackoverflow или Хабра — для того, чтобы быстро получить представление о тех или иных возможностях HTML. Еще можете какую-нибудь книгу почитать, только не старую.
    Ответ написан
    5 комментариев
  • Как и где найти php программиста на работу «за идею»?

    @egorinsk
    В Стране Чудес.
    Ответ написан
    Комментировать