[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: PHP программист, г. Москва, 55 т.р.
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
Santehnick
CHtml это набор статичных методов, соответственно объект не создается и не занимает место в памяти. Отработает только CHtml::encode() остальные 1980 строк из этого файла будут полностью проигнорированы интерпретатором. Да и команда может разрабатывать какой-нибудь RESTful сервис, где вообще не нужны классы для работы с фронтендом.

Цитата

Про AR вообще не стоит даже говорить. Для чего он в конкретном приложении? В фреймворке понятно, должна быть универсальность, должен быть выбор. А в конкретном рабочем проекте? Кому в голову придет менять СУБД на рабочем проекте?


AR это не для того, чтобы субд менять. Это паттерн для объектно-реляционного отображения (ORM). Вместо написания длинных sql запросов, мы работаем с объектами моделей, с помощью которых можно легко создавать/обновлять/удалять данные из базы данных


// создать нового пользователя
$user = new User;
$user->setAttributes($_POST);
$user->save();
// обновить существующего пользователя
$user = User::findById($id);
$user->login = 'NewLogin';
$user->save();
//удалить пользователя
$user = User::findById($id);
$user->delete();


Цитата

Где брать сформированный текст запроса?

В Yii 2 есть модуль debug там есть вся информация по запросу в том числе и все тексты запросов которые были выполнены к субд. В Yii 1 тоже есть.

Цитата

А чтобы решить специфичную, нужно либо воротить свой "велосипед", либо править существующий.

Не нужно, фреймворк это низкоуровневый код, в нем нет высокоуровневого кода, который как-то бы мешал, вам в разработке.
Цитата

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

Нет, потому что фреймворк это низкоуровневый код, а платежи и организация смс это высокоуровневый код. Ерунды типа регистрации, там тоже нет.

Цитата

Что он даст кроме структуры и межсобойного синтаксиса?

Как минимум обработку ошибок, логгирование, mvc, роутинг, генерацию url, события, поведения, dao, ar, миграции, скафолдинг, дебаг, кеширование, restful, тестирование, фильтры, di container, service of locator, rbac, валидацию данных, авторизацию, аутентификацию. И это без всяких фич для фронтенда.

ZF не лучший пример.
OleKh
Цитата (Ron @ 26.09.2015 - 19:17)
Как критиковать без подсказок?

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

Цитата (Ron @ 26.09.2015 - 19:17)
Имеется ввиду изучить исходники и все-все алгоритмны под капотом?

Нет, хотя бы научиться толково использовать без постоянного гугления.

Цитата (Ron @ 26.09.2015 - 19:17)
о фрилансерах такое мнение, то дело действительно плохо. Потому что у нормального фрилансера есть и верстальщик прикормленный и дизайнер и т.д. Если проект несложный - делаешь сам.

Обобщенно в основной массе думаю так и есть, естественно что на фрилансе могут быть и очень продвинутые разработчики. Нормальный фрилансер чтобы побольше заработать скорее сам сделает верстку и фронт-энд как умеет, чем будет нанимать специалиста на Bootstrap, Angular и т.п.. В таком случае можна нанять спецов и на бэк-энд и по базам данных, тогда это уже что-то типа проект менеджера выйдет, а не фрилансера. Дизайнер свой - это круто, согласен.
OleKh
Цитата (twin @ 26.09.2015 - 19:21)
Цитата (Ron @ 26.09.2015 - 17:17)
Это которые для перехода с одной СуБД на другую что ли?

Нет. Скорее всего имелись ввиду штатные миграции Yii. Это что-то типа SVN для СУБД. Чтобы можно было откатить модификации таблиц.

зачем гадать, когда есть гугл ) мне довелось всего лишь применять уже созданные ранее в проекте миграции используя команду yiic migrate

http://www.yiiframework.com/doc/guide/1.1/...abase.migration
chee
Обсуждали кучу раз. Нормальный программист, будет выдерживать баланс, будет знать довольно хорошо базовые технологии, как и пару фреймворков.

Нельзя изучать фреймворк ради цели найти работу, нужно изучать php, а потом уже конкретный фреймворк и то уже по факту, и компании должны этому способствовать.

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

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

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
l@pteff
имхо, норм з\п на первое время, если конечно работодатель не собирается выжать из тебя все соки.
Во многих конторах больше 40 тыр платить вообще не хотят, каким бы крутым спецом ты не был
Invis1ble
в очередной раз убеждаюсь, что большинство тех, кто хает фреймворки, не понимают, о чем говорят
для них фреймворк - это виджеты и регистрация, которую надо перепиливать, а миграции - это переезд на другую СУБД. А, еще пагинация. И если в нем нет встроенной в ядро отправки СМС, то это плохой, негодный фреймворк. Ну и тому подобные глупости.

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

Ron
Invis1ble, если всё перечисленное не использовать в виде плагинов (или как там называется этот голимый универсальный хлам об сообщества), что ж тогда в нем останется, извините? Валидатор + MVC + query билдер, преимущества которого весьма спорны?

Это первое. Второе: Slim VS Zend. И то и другое фреймворки! Вопрос. Дайте определение что такое фреймворк? Кто больше из них фреймворк Slim или Zend? )) Кто фреймворкастее?

Invis1ble
Цитата (Ron @ 27.09.2015 - 04:23)
Валидатор + MVC + query билдер, преимущества которого весьма спорны?

еще одно доказательство smile.gif
открою секрет, валидатор и билдер - это, по сути, не фреймворк. Да, в некоторые фреймворки их может и встраивают в стандартную поставку, но это не характеристики фреймворка.
А ответ прост: фреймворк - это в первую очередь архитектура и совокупность интерфейсов, опираясь на которые и навешиваются все нужные вам компоненты.

Цитата (Ron @ 27.09.2015 - 04:23)
если всё перечисленное не использовать в виде плагинов

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

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

twin
Цитата (OleKh @ 26.09.2015 - 18:06)
Кого куда тянет, например для e-learning на Wordpress есть классный плагин, недавно мне пришлось немного на него глянуть. Сразу скажу 2-3 дня на изучение, установку, кастомизацию будет маловато, может недели две, если хотя бы есть представление о Wordpress.

Я говорю про основы. А это уже частности. И еще, Wordpress, это кагбэ и не фреймворк вовсе. а CMS. Ну да и Бог с ним, другое важно. Изучение фреймворка предполагает изучение всех плагинов? Как часто он тебе потребуется в дальнейшей жизни? Ну вот ты столкнулся с задачей, а мне он может и вообще никогда не потребоваться, а значит 2 недели, потраченные на его изучение, коту под хвост. А через пару месяцев и ты это все забудешь, и без мануала не сможешь повторить. И в чем разница между тобой, лезущим в мануал, и мной, делающим тоже самое. Вот об этом речь.
Цитата (Santehnick @ 26.09.2015 - 18:21)
CHtml это набор статичных методов, соответственно объект не создается и не занимает место в памяти. Отработает только CHtml::encode() остальные 1980 строк из этого файла будут полностью проигнорированы интерпретатором.

А я про интерпретатор не говрил. Я про память говорил. Прежде чем дело дойдет до интерпретатора, в оперативку будет забобахано 100 Kb только ради одной функции. Не много вроде, но оно в процессе набегает мама не горюй. Преславутый ZEND на каждый чих отжирает не менее 8 мегабайт.
Цитата (Santehnick @ 26.09.2015 - 18:21)
AR это не для того, чтобы субд менять. Это паттерн для объектно-реляционного отображения (ORM).
Так а для чего ORM? Active Record, ты правильно заметил, всего лишь частный случай ORM. А последний как раз и придуман для унификации. Осуществляя работу с СУБД через "посредника", где нет привязки к самой СУБД, а все запросы выполнены объектами, решается задача универсального управления любым хранилищем данных. Вот отсюда и вопрос - на кой ляд мне на рабочем проекте, где уже гигабайты данных, менять СУБД?
Цитата
Вместо написания длинных sql запросов, мы работаем с объектами моделей
Всё верно. Если это касается простеньких запросов, кои ты и привел в пример. Давай ка попробуй поработать через AR с этим запросом Обещаю незабываемые впечатления. smile.gif
Цитата (Santehnick @ 26.09.2015 - 18:21)
В Yii 2 есть модуль debug там есть вся информация по запросу в том числе и все тексты запросов которые были выполнены к субд. В Yii 1 тоже есть.

Ну хорошо, коли так.
Цитата (Santehnick @ 26.09.2015 - 18:21)
Не нужно, фреймворк это низкоуровневый код, в нем нет высокоуровневого кода, который как-то бы мешал, вам в разработке.
До него еще не добрались, до высокоуровневого. Я сейчас про возможности самого фреймворка говорю. Если мне чего-либо не хватит, что делать? Способ только один - расширять возможности. А значит наследник, лишний файл, пошло поехало. Вот пример того, о чем я говорю. Там правда исходник фиксили, но это же не по правилам.
Цитата (Santehnick @ 26.09.2015 - 18:21)

Цитата

Что он даст кроме структуры и межсобойного синтаксиса?

Как минимум обработку ошибок, логгирование, mvc, роутинг, генерацию url, события, поведения, dao, ar, миграции, скафолдинг, дебаг, кеширование, restful, тестирование, фильтры, di container, service of locator, rbac, валидацию данных, авторизацию, аутентификацию. И это без всяких фич для фронтенда.
Так в том и дело, что половина из этого списка мне допустим не нужна. Тот же AR я в страшном сне никогда использовать не буду. Или тот же di container. Мне вообще не нравится философия DI. Не вижу я в ней смысла. Это просто ООП для ООП, дабы четко следовать канонам. А то, что за это приходится платить неудобством трассировки, пофиг. Главное, чтобы всё было объектным. Если мне эта философия не подходит, какая мне польза от фреймворка в этой части?

А вторая половина может меня не устраивает. Да и есть все что нужно в своих разработках. Многие вещи честно спёрты из тех же фреймворков и адаптированы под текущие задачи. К примеру мой дебаггер гораздо симпотичнее того, что в Yii. Или тот же RBAC мне больше кохановский нравится.

Не, что не говори, а фреймворк сужает возможности программиста, загоняет его в клетку. Приводит к стагнации, а часто и к деградации biggrin.gif
Не зря форум Yii забит такими вот инсенуациями:
Цитата
Крон только начал осиливать, cronfile мне не о чем не говорит, хотя наводит на мысли.
Документация называется "install.cron", но по всей видимости к крону непосредственно эта статья не имеет отношения.Там показывается как создать консольную команду. Это вводит в заблуждение, становится непонятно, предлагает Yii какие-то инструменты для создания crontab или нет? В этой статье не описывается создание задачи, там дается намек как это можно сделать. Видимо сейчас мне нужно забыть на время о Yii и поизучать сам крон и как с ним работать через php, создать необходимый инструментарий, которого нет в yii и по этому он не описан в том рецепте, а затем дополнить свой класс консольной команды и жить счастливо.


Про синтаксис отдельная тема. Кто во что горазд. Вот с jQuеry допустим другой коленкор. Там если его не знаешь, в фронт-энд программисты путь заказан. Потому что 99% сайтов используют этот фреймворк. А изучать досконально Yii для устройства на работу - бред. А для себя - бред втройне.

Выгода только работодателю. Программисту одни минусы.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.