Задать вопрос
  • На сколько директива должна быть независимой?

    ГЛЕБ ГЛЕБОВ: контроллер содержит в себе логику работы директивы, он ничего не знает о DOM, link это такой вот промежуточный слой который склеивает все вместе. Вы хотите что бы по клику директива что-то делала - в link вешаете обработчик click (например) и в обработчике вызываете метод контроллера. Вам надо что бы директива в зависимости от данных что-то отображала - в link пишем ватчер и ватчим там значение из контроллера, по изменению обновляем DOM). Собственно это все логично только из названия метода - link (связывать).
  • Должен ли знать php-разработчик популярные CMS?

    Александр А: если я не работаю с популярными CMS (и с CMS вообще), зачем я это должен знать?
  • Как задать шаблон для чисел в Angular?

    А комбинацию этого дела обернуть в директиву.
  • Не могу отправить кроссдоменный запрос Apache 2.4?

    KuzmenkoArtem: перечитайте мой ответ, ваш этот Lumen знать ничего не знает о OPTIONS запросах и падает, так как у него по урлу по которому вы шлете запрос только GET/POST разрешены например. Вывод - добавить в Lumen мидлвэр который бы на все OPTIONS запросы с CRORS заголовками возвращал 200 ok
  • Есть ли жинь за пределами CMS?

    Mikhail: ну и да, у VK используется только очень ограниченное подмножество языка, которое они могут спокойно транслировать в Си и уже компилировать. Причем добавляются опеределенные вставки из-за динамической природы языка и тут он у HHVM может выигрывать только за счет того, что просто не поддерживает 70% языка. Это эдакий обрубок. HHVM же ничего никуда не компилирует, оно транслирует PHP (или Hack, на котором они все пишут теперь) в опкоды и из них генерят машинный код через JIT. Динамическая же генерация машинного кода поволяет учитывать оптимизации и т.д. При наличии ресурсов гугла можно добить до производительности V8, который возможно работает быстрее KPHP. Ну и да, писать на KPHP код для продакшена стоит только вконтактам.
  • Есть ли жинь за пределами CMS?

    Mikhail: я не знаю о какой такой статистике вы говорите. Без пруфов это просто выкрики в пустоту.

    Короче TL;DR - меряться производительностью при выборе стэка технологий - это конечно прикольно но бессмысленно. Сервера стоят дешевле.

    1) Symfony + Doctrine - один из самых жирных тандемов PHP мира. Собственно думаю Drango + SQLAlchemy тоже нифига не легкие. Но зато можно упарываться по DDD и ООП и компенсировать медлительность высокой скоростью разработки. При совмещении этого фреймворка (а в ближайшем будущем и вообще всех фреймворков имеющих бридж с PSR-7) и php-pm (менеджер процессов-воркеров для PHP, эдакий fastcgi интерфейс, позволяющий не тратить время на инициализацию бойлерплейта) да еще и с PHP7 можно уже говорить о высоких нагрузках и при этом не жертвовать горизонтальным масштабированием (согласитесь, с PHP, так как он state less по своей природе, это дико просто)

    2) Не спроста VK и FB имеют целые датацентры. У вас есть хоть один проект для которого надо класстер серверов держать? Для вас 10% прирост производительности позволяет сократить расходы настолько, что можно добавить разработчиков? Сильно сомневаюсь (хотя всякое бывает, но это меньше одного процента всех проектов).

    3) Нода, а именно Google-вский V8, является по сути самым быстрым интерпритатором, если сравнивать с динамическими языками. У него крайне эффективный JIT компилятор и он в принципе на вычислениях приближается к Си (правда -O3 всеравно быстрее за счет векторизации и прочего, но это если чиселки считать). Так что V8 уж точно быстрее будет выполнять код чем всякие там CPython или PyPy (пруф). Что до асинхронности - рассматривать event loop только как плюшку ноды это тупо. Насколько я помню Twisted пайтоновский тоже на нем работает, и ReactPHP по-ха-пэшный внутри даже те же библиотеки юзает (ну или может юзать), а именно libev.

    4) Повторюсь, скорость работы языка важна только тогда, когда мы имеем дело с узкими местами. Говорить же что Python быстрый - это смешно. Вот Go - он да, и быстрый, и инфраструктура интересная, и компилируется... А еще Rust неплох для узких мест, тот же яндекс его потиху внедряет насколько я вкурсе.
  • Есть ли жинь за пределами CMS?

    Mikhail: о да, еще и с монгой... ну да ну да. На самом деле все верно, мускуль это весело и прикольно, но после постгреса она кажется немного детской местами. Меня лично все эти плюшки постгреса аля jsonb или postgis не так подкупают как качественная реализация механизма транзакций, которая с тем что есть в innodb даже сравнивать не стоит, ну и православные последовательности вместо богомерзских автоинкрементов.

    Mikhail: Python дает максимальную производительность? Не смешите. Даже пых быстрее, если рассматривать варианты с честным fastcgi в виде php-pm и т.п. демонов. А уж говорить что питоны быстрее ноды - это надо знатно упороться. У Python плюсы в другом - Python это Python, он нежный, намного более нежный чем все эти PHP, Ruby, JS. И кодить на нем приятно... С другой стороны есть люди которым настолько непривычно и странно без интерфейсов, что лучше уж на PHP.

    Что до MySQL делает всех - враньше и провокация. MongoDB рвет всех только тогда, когда вы храните аграгации данных и собственно выборка любая сводится к тупому селекту. А один шаг в лево, один кривой индекс и все летит в ад.

    Вообще выбирать стэк технологий только с колокольни производительность ... ну скажем так, в этом есть смысл если вы ориентируетесь только на очень высокие нагрузки. В целом же в 95% случаев все это спички в костре тормозов из-за не правильной архитектуры, локов, отсутствия индексов и т.д.
  • Каким образом обеспечить деплой проекта?

    Попробуйте Ansible, он от авторов Fabric и в целом можно его считать работой над ошибками + свои нюансы.
  • Что делать с FlexBox в Internet Explorer 8, 9?

    Blyyya: ну да, именно так. Флексбоксы это круто и они решают кучу проблем, но медиаквери всеравно приходится писать, всеравно приходится перестраивать сетку и т.д.
  • Есть ли библиотека для определения даты оплаты домена?

    ShamblerR: последнее предложение вашего вопроса явно не тянет на отслеживание доменов ваших клиентов, с учетом того что вы собираетесь отслеживать "эксклюзив". Обычно у продавцов доменов для клиентов есть API или хотя бы нотификашки на email, которые за пару недель до начинают заваливать письмами с просьбой обновить это дело.
  • Что делать с FlexBox в Internet Explorer 8, 9?

    Blyyya: освежить память? Вы уже работали с флексбоксами но не помните ничего? Или вы не работали с флексбоксами и тогда встает вопрос что именно вы собираетесь освежать.

    По флексбоксам же рекомендую видео Вадима Макеева: https://vimeo.com/67011034
  • Стоит ли писать REST API вручную?

    Влад Developer: ну а так использую web sockets в контексте angular приложений.
  • Стоит ли писать REST API вручную?

    Влад Developer: вы надеюсь понимаете разницу между перечисленными вещами?
  • Стоит ли писать REST API вручную?

    Влад Developer: REST Api это только интерфейс к вашему приложению. Это лишь маленький кусочек приложения если рассматривать вопрос стрктуры. У меня скажем API это контроллеры, методы которых содержат одну или две строчки кода - взять данные из реквеста, сформировать DTO, вызвать application level сервис и собственно на этом все. Такой код вполне себе можно генерировать.

    А вот как это все будет храниться в базе, как будет что взаимодействовать я лучше опишу сам. Ну и да, я не использую express.js или node.js, апишки пишу на php. node.js использую исключительно как шину данных в случае если надо организовать реалтайм работу.
  • Стоит ли изучать Symfony?

    Вячеслав Плиско: как вы по одному абзацу можете определить уровень знаний человека? Научите, пригодится такой навык. Я вот не особо вижу что бы у человека было достаточно опыта что бы он мог хоть что-то знать нормально, учитывая характер вопроса в принципе.

    Что до вашего примера, зависит от того какова планка "не хуже". У меня тоже такие примеры были, когда стажеры которые второй раз в жизни видели симфони писали код не хуже людей которые на ней работают уже 3-4 года. Но в этом нет заслуги симфони, только пинание и код ревью, парное программирование и т.д.