• MVC php на пальцах?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Ох...

    Model View Controller. Да ну его, ему уже 45 лет (придумали в 79-ом году). Давайте лучше про Model View Adapter погокорим. это то что все используют в популярных фреймворках последние лет так 10 так точно.

    mvc-mvp-mvvm-6-638.jpg?cb=1375170002

    Вообще в этом всем важно не только то, что каждая буква обозначает, а как они друг с дружкой связаны.

    View - это не только HTML, но и вообще представление в целом, а так же логика его формирования. Шаблонизаторы, фильтры, различные функции/объекты помогаютщие нам сформировать view (например форматирование дат, сериализаторы и т.д.) В подавляющем большинстве случаев "представление" наших данных - это HTTP запросы и HTTP ответы. HTML - э то лишь часть HTTP ответа.

    Model - Это целый слой, который может быть представлен в виде кучи отдельных объектиков, структур и т.д. Его задача - делать дела и хранить/менять состояние системы. Тут легко запутаться потому что термин "модель" много чего значит. Воспринимайте его как "слой логики" а не конкретные объекты. И да - база данных и прочая чушь - это детали реализации этого слоя. "не важные штуки" словом. Туда же и ActiveRecord, ORM-ки всякие. Это деталь реализации и все остальные чуваки (view и controller) о них знать ничего не должны (хотя иногда могут в целях упрощения).

    Controller или адаптер. Это опять же не обязательно один объект. это может быть цепочка адаптеров (еще называют фронт-контроллером, middlewares и т.д.). Его задача весьма простая. Получаем представление данных на входе (HTTP запрос), определяем что надо делать, и просим модель что-то сделать (ни в коем случае не меняем ничего самостоятельно в контроллере, он только просит). Потом мы можем попросить модель вернуть нужный нам кусок состояния, и попросить View сформировать представление (HTTP ответ).

    Как-то так. В целом же это я сейчас описал "идеальный мир". Вся суть этого подхода - разделение логики презентационной и логики приложения. Зачем это надо? что бы было проще жить! Обычно UI приложения или способы взаимодействия с ним меняются почаще логики или как минимум в разные моменты времени. Адаптеры в этом случае служат промежуточным слоем, они ничего сами не делают, это "переводчики". Они просто переводят то, что сказано в запросе в язык понятный приложению и обратно.

    Но на начальной стадии можно слегка нарушать эти правила, делать толстые контроллеры и т.д. В этом случае бизнес логика будет потихоньку "вытекать" из модели. Это не хорошо, и на хоть сколько нибудь больших проектах может привести к проблемам. Потому важно находить баланс.
    Ответ написан
  • В чем преимущества *nix, linux перед windows (для веб разработчика)?

    @spotifi
    Нету никаких проблем.
    Если только ваше конкретное используемое для ваших задач ПО нормально работает с Windows.

    Например, в моем случае используется Ansible и Docker, который не поддерживается на Windows. Приходится использовать Vagrant. Это достаточно удобно. Но ресурсы все же кушает.

    А так - даже Vim хорошо себя чуствует на Windows. Нативный. Не cygwin.

    Microsoft это тоже понимает.
    И вот уже они встроили подсистему Linux Ubuntu в Windows 10. Это не виртуализация, а именно полноценная подсистема.

    И многие вещи, например, те же шрифты - в Windows работают лучше, чем под Linux.

    Могут сказать - что лучше использовать для разработки ту же среду что и для production.

    Но дело в том, что даже если вы сидите на Ubuntu Desktop, то ваша среда серьезно отличается от среды сервера FreeBSD, CentOS, Debian, Ubutntu Server. И для полноценного CI все равно умные дядьки категорически рекомендуют и на Linux даже использовать Docker для полноценной эмуляции.

    Но ведь Docker-то можно использовать и на Windows. Правда, запускается он там подольше.

    Где именно вести разработку, где вам удобнее - это ваше личное дело. Вопрос ваших предпочтений. Никаких объективных причин в наше время, когда существуют Docker, Vagrant и виртуальные машины, когда куча приложений изначально сделанных для *nix запускаются в native под Windows - нет никаких причин себя строить. Кроме любопытства - а как оно там на других системах живется.

    У тех кто вас троллит есть еще одна причина: им приятно показать себя более умными. Как же - ведь Linux можно сконфигурить руками.

    Ага, конечно.

    Или используют готовые десктопные дистрибутивы. Не зря Ubuntu так популярна.
    Или если освоили ArchLinux - то построили себе совершенно убогое окружение по готовым мануалам.

    Чтобы действительно набрать скиллы ручной настройки Linux - нужно огромное количество упроства и времени, чем ваши друзья, которые вас троллят, вряд ли обладают.

    На деле 99% твердящих о гибкости Linux - далее чем ставить Apache и MySQL из пакетов - ничего сами и не умеют. Фактически работая в то же настроенной другими людьми десктопной среде. Но разве вы не умеете делать то же самое под Windows?

    Другое дело, что разворачивать и тестировать нужно под аутентичным операционным окружением.
    Неважно под Ubuntu ты сидишь или под Windows.

    Лучшие практики советуют использовать полностью изолированный и независимый от рабочего места разработчика инструментарий - виртуальные машины, Vagrant, Docker, отдельные физические сервера.

    В этом случае под твоей любимой ОС работает только текстовый да графический редактор. А все развертывание для тестирования и для продакшн проводится в совсем другой среде.

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

    CityCat4
    @CityCat4
    Если я чешу в затылке - не беда!
    OMG, как только народ с ума ни сходит...

    Рабочая обстановка должна быть рабочей обстановкой. Все это лежание, стояние, висение за одну ногу - не скажу ничего, может кому и удобно так работать...Но как говорится, как человек, проводящий за монитором по 12 часов кряду, вставлю свои пять центов :)

    Все нижеизложенное - сугубо IMHO

    Стол - большой, широкий, способный выдержать мониторы и все прочее, что нужно для работы, так чтобы не тесниться. Высота стола должна быть такой, чтобы руки находились на удобной высоте для работы - для меня это чуть ниже 3-й сверху пуговицы рубашки. Места под столом должно быть достаточно, чтобы вытянуть ноги.
    Стул - мягкий, вращающийся, с широкой прочной крестовиной. Очень люблю сидеть, закинув ноги за лучи крестовины крест-накрест и слегка вращаться при этом. (Привычка аж с 1990 года, когда работал оператором ЭВМ и верхом на кресле мог ездить по машинному залу). Спинка - полужесткая, высокая, анатомической формы. Для работы должна поддерживать спину, поэтому брать "кресла руководителей", в которых спинка полуоткидная - не стоит - полулежа работать не сможете, эта поза больше для того, чтобы киношку посмотреть. Спинка кресла должна быть настолько жесткой, чтобы откинулся на нее всем весом, а она только слегка пружинила. Подлокотники должны предоставлять опору на локти, а не быть декоративным элементом. Предпочитаю кресла CHAIRMAN.
    Клавиатура - полноразмерная, с цифровым блоком, со стрелками, без всех этих новомодных тенденций к суживанию, обязательно с широкой подставкой под запястья - без нее при установке на стол запястье выгибается вверх и просидеть так долго не сможет и мазохист. Функциональные клавиши полной ширины - иначе попасть проблематично. Наилиучшие клавы, как ни странно у Microsoft.
    Мыш - универсальная (не под правую руку), утяжеленная (весом не менее двух батареек AA). Лучшие мыши были у Logitech, можно Microsoft.
    Ответ написан
  • 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

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

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

    akarin
    @akarin
    Сидят 3 хиспстера в свитерах и пьют кофе. Менеджер ищет на гитхабе что то похожее на свой будущий проект.
    Ответ написан
  • Какие дисциплины изучать программисту чтобы меньше зависеть от языков и технологий?

    @endemic
    Как писали выше - боле абстракнтные понятия:
    Алгоритмы, Паттерны, Какие-то межъязыковые вещи типа многопоточности, рефлексии, метапрограммирования (generic в C#/Java, template в C++).

    Некоторые люди рекомендуют джентельменский набор:
    1. Компилируемый язык (пока C++ без вариантов, но скоро будет Rust, надеюсь)
    2. VM язык (Java или C#)
    3. Скриптовый язык (Perl, Python)
    4. SQL
    5. Веб: HTML/CSS и JavaScript на базовом уровне

    Средние знания всего вышеперечисленного позволяют быть более менее в курсе дел и даже если вылезет что-то новое - подстроиться. Нужно только правильно расставить акценты.
    Ответ написан