Комментарии

Я не поняла на счет «черного и белого». На счет догм было же уже написано в начале моего коммента.

Про начальников — что я имела ввиду — разработчик не может самостоятельно определять цели и средства потому как он находится внутри разработки. Поэтому есть специальные люди, специально в стороне от разработчиков у которых должен быть бОльший опыт(специальный опыт) и они «не в команде»(не в банде). А то что все люди и все ошибаются — ну да, но если есть нормальный подход к построению команд разработчиков то человеческий фактор снижается.
На счет лишь разница в ЗП, уровне ответственности — да верно. Но это же не главное!!! Начальник в стороне со своими задачами и он видит когда его подчиненные полезным делом занимаются, а когда начинают изобретать велосипед или их потянуло не туда.

Алгоритм Mobile First влияет на поисковую выдачу не только во время мобильного серфинга, но и при использовании десктопных устройств. Основная и мобильная версии сайта ранжируются по одному индексу, поэтому если ресурс не адаптивен к мобильным устройствам, позиции сайта могут просесть. Если пользователь переходит на сайт, не находит полезную информацию и возвращается к поисковой выдаче, Google воспринимает это как отрицательный сигнал и снижает позиции сайта при ранжировании.

Есть и еще один совет. Обязательно оставляйте на странице «воздух». Должна быть очевидная, естественная навигация без отвлекающих факторов (таких как всплывающие окна). Хорошая целевая страница содержит всю необходимую информацию, необходимую для поощрения посетителей, но ничего лишнего. Слишком много информации может ошеломить посетителей, поэтому будьте проще и предоставьте только необходимую информацию, которая будет направлять посетителей вниз по воронке. Информация, которую вы помещаете спереди и по центру, должна легко просматриваться – желательно использовать маркеры, чтобы объяснить детали, когда это необходимо.

Хорошо обдумайте, какую ключевую информацию нужно показывать на первом экране сайта, в пределах прямой видимости посетителей, а что можно поместить под прокруткой. Большинство посетителей, естественно, знают, что могут прокрутить вниз для получения дополнительной информации, поэтому не бойтесь добавлять более подробные описания там, где они будут незаметно скрыты. Хороший дизайн целевой страницы обеспечивает чистое и привлекательное визуальное впечатление, в то же время, позволяя посетителям получать информацию, которую они могут пожелать, не навязчивым способом. Используйте преимущества в расположении информации ниже по странице. Еще один способ добавить больше информации, не перегружая посетителей текстом, — это целевые страницы с видео. Подумайте о выделении ключевых моментов вашего предложения с помощью текста и используйте необязательное кликабельное видео для объяснения деталей.

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

Хорошая статья! Стоит не забывать что пользователю проще покинуть ресурс, чем разбираться и «попадать» пальцем на маленькие кнопки «купить». Важно не только сделать сайт адаптивным, но и продумать путь пользователя. Интерфейс сайта должен плавно вести пользователя от главного экрана сайта до достижения цели. Если все элементы сайта расположены на своих местах, конверсия сайта вырастет.

Тут все просто: Эффективная целевая страница (landing page) является краеугольным камнем успешного интернет-маркетинга. Ваше предложение может быть звездным, а ваши объявления PPC — оптимизированными, но без хорошей целевой страницы ваш бизнес неизбежно пострадает. Макет вашей целевой страницы должен быть безупречным.

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

Стало быть виноваты не девопсы-любители, а нужно было сказать, что виноват был их начальник. А автор похоже не захотел так выражаться по какой-то причине.

В общем чета осадочек остался от статьи. Извините.

Один из признаков энтерпрайз-стиля — разделение приложения на слабосвязанные слои. Дефолтная для Laravel ORM предлагает свою реализацию паттерна ActiveRecord, который по определению сильно связывает уровень бизнес-логики с уровнем хранения данных. Возможно, при должной дисциплине и(или) абстракциями поверх ORM можно отделить бизнес-логику от уровня хранения данных, вроде бы относительно легко прикрутить Doctrine для замены дефолтной, но в документации, постах и т. п. я не встречал такого подхода, а ровно наоборот подается как преимущество тесная свзяанность. Типа всего нужно написать $order = new Order(); $order.save(); и новая запись сохранена. В Doctrine это займёт минимум на строку больше.

Использую Laravel несколько лет. Не фанат, не евангелист. Нравится, устраивает. Регулярно в подобных статьях вижу одного-двух людей, ругающихся на фасады и на невозможность писать в энтерпрайз-стиле.

1. Если я правильно понял, на фасады ругань из-за «магии». Вопрос: какое вам дело до «магии», если вы все равно точно знаете, какой будет результат при их использовании? Ну или объясните, в чем проблема, если я неправильно понял.

2. Объясните про энтерпрайз-стиль. Что это такое, конкретно? Что он дает (какие плюсы)? И почему на Ларе нельзя писать в этом стиле?

А никто не говорит, что Yii не выполняет свою задачу. Выполняет. Только почти что каждую задачу можно решить проще и элегантнее с перспективами на вырост. В случае Yii этого не получится. Зато то, что умеет Yii — делает быстрее всех. Ну, примерно как JQuery среди React, Angular, Vue и прочих.

Если учитывать это, то утверждение «не надо переносить подходы Yii на другие фреймы» становится чуть менее радикальным, верно?

Почему привязываетесь к неким статическим параметрам? (возраст, качество внешних ссылок и пр.)
У нас тут как бы «эра поведенческих факторов»))
Собственно, в данном случае я говорю о ПФ не как дань о пресловутой моде.

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

Дальше, должна быть явная структура (архитектура, называйте как хотите, смысл один) сайта. Анализируя ссылочную структуру, гугл определяет «метки», благодаря которым пользователь экономит время поиска информации на сайте. Это вполне себе может быть связано с ПФ.

И в заключение, соответствие ссылок и текста по этим ссылкам, авторитетность сайта, бэклинки и все такое прочее.
В чем-то, кстати, схоже с Яндексом — полистайте его факи по этому поводу.

Было два проекта больших на Yii, вот как раз там было всё очень удобно и прозрачно. Будь Yii плохим фреймворком — не снискал бы столько лучей обожания ото многих людей. И вообще, понятие «нормальный фрейм» — очень субъективное. Для яичников — это yii, для симфонистов — симфони, очевидно. Было бы лучше, если бы люди не делали радикальных заявлений относительно того, что богу подобно, а что плохо, да ещё и менторским тоном и безапелляционно.

Тем более, что особо разницы я не почувствовал, на вкатывание после yii мне понадобилась одна неделя сразу после устройства на новую работу.

Учи лучше TS и юзай его.
Жопоболи будет в разы меньше.

Даже если «порог входа довольно простой» — то такой порог уже в абсолютно всех языках. Нужно только знать «кнопочки и визуальный эффект» от первых этапов программирования.
Но для меня JavaScript стал слишком тошнотворным.
Если раньше все кто умел и не умел прикручивал библиотеки и готовые простые решения для сайтов типа JQuery, то написание теперь собственного решения требует множество знаний, которые не описываются в учебниках «выше операторов и работы с prototype». А читабельность такого кода на JS — вообще отвратительна… она называется «мы задумали, а вы как хотите — разгрёбывайте».

Чего только стоит самостоятельная попытка изучения, так чтобы проще и доходчивей:
НУ как вообще нормальному человеку изучить разделы 6,7 и 9 из списка этого сайта: learn.javascript.ru, так чтобы и глазом не моргнув суметь рассказать, что сам то понял, если понял…

Поэтому спрос на JS будет! и 1 подходящий к 10-ти неподходящих представителей, и даже потом 1 к 100..., но чтобы его одолеть в том виде какой он сейчас — я не гений.
Я кое-как выучил скрытую функцию, и кое как применял на протяжении 2х лет,… постоянно путаюсь в чтении передачи в функцию и из неё, превращение функции в классы с методами, из-за отличаемого синтаксиса от всех «разумных классических» языков. Меня «типает от JQuery.Deferred… Promise», из-за слабого преподавания на сайтах… Т.е. я постоянно забываю применение….этот весь идиотизм в JS.

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

Как только ПС автоматически проставит дополнительные ссылки, в панели Google Webmaster появиться возможность управлять внешними ссылками.

Это проблема всех Yii'шников, которые переходят на любой другой нормальный фрейм. И это не было бы проблемой (например, используя Laravel можно использовать подходы Symfony, Zend или какой-нибудь Spring смело, и наоборот), если бы в Yii было бы сделано что-то грамотно, но увы.

Ларавель — хороший фреймворк, удобный и передовой, соглашусь. Но мне больше нравится Yii, наверное, потому что в нём я каждую дырку знаю, и мне он ближе по духу. Щас, правда, проект на ларавеле. Хорошо, но то и дело не хватает Yii. Каждый раз я сначала мыслю, как бы я это сделала «там», а потом придумываю, как это перевести на лару.

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

Как только ПС автоматически проставит дополнительные ссылки, в панели Google Webmaster появиться возможность управлять внешними ссылками.

Все зависит от релевантной «ценности» страниц. Хотя например, косвенно можно повлиять указав перекрестные ссылки на другие выделенные разделы.

Вроде и хорош Laravel на первый взгляд, но, по факту, для более-менее серьезного использования он годится только после доработки стандартного сетапа и нарушения всего, что говорит документация и предлагают авторы.

В ларавеле можно использовать инъекцию зависимостей по интерфейсу, заменить ущербный Eloquent на Doctrine (или вообще обойтись без готовой ORM), можно запилить структуру проекта согласно принципам «гексагональной архитектуры» или DDD, да и вообще много чего можно сделать.

Но, по факту, официальная документация и туториалы предлагает вместо этого использовать статические фасады для доступа к чему угодно (начиная с 5 версии — так и вообще просто глобальные функции типа app(), dispatch() и т.д. Забавно, что сам Тейлор аргументирует тем, что, мол, «под капотом» фасадов и функций на самом-то деле DI-контейнер инстанцирует объекты, как будто это что-то меняет)

Макаки, разумеется, в восторге — можно говнокодить безо всяких ограничений не включая мозг. Напрямую обратиться к БД в темплейте? Легко! Вызвать какой-либо сервис прямо из модели? Запросто! И именно поэтому ларавел так популярен! На западе уже, фактически, это «новый вордпресс». Да, казалось бы, дело в макаках, а не в ларавеле, но почему тогда документация учит «плохим» практикам, даже толком не упоминая о «хороших»?

А про «экосистему» и говорить не хочется — с каких пор привязка к вендорским инструментам стала благом?