grigorie1990

Что выбрать Python(Django) или PHP(Laravel/Yii)?

Когда люди спрашивали "какой линукс лучше?", один умный человек сказал - лучше тот линукс, который знает Ваш знакомый сисадмин.

Тут ситуация - совершенно аналогичная, учить (для начала) лучше то, что готов Вам преподавать Ваш ментор (на счёт наставника в институте - я лично сомневаюсь, но знать как оно там у Вас лично - не могу).

Второй момент - смотря для чего учить? Что Вы хотите делать в итоге? Блоги? Для этого однозначно Django/Python лучше подойдут. Хотите работать? В какой стране? Например, в США будет по определению популярен C# во всех его формах и проявлениях, т.к. вендор .NET-платформы - сам находится в той же стране, со всеми вытекающими... Как только определяетесь со страной, с/в которой хотите работать, идёте на местный фриланс и смотрите кол-во работы. Понятное дело, что и исполнителей будет больше, и т.д., и что в среднем +/- на одну каждую единицу технологий будет приблизительно равное кол-во исполнителей, но популярность технологии N привлекает не только исполнителей, а ещё спонсоров и тех кто в итоге продвигает проект пополняя сообщество конечных разработчиков.

Единственное, с чего бы я начинать не советовал - это с Yii, так как вектор его развития непонятен, он уже больше 3-х лет висит в версии 2.0 и когда будет 2.1 или 3.0 (и будет ли вообще) - не ясно пока. Лично я от него в своё время ушел и рад тому вполне. Но, это личный опыт и сейчас найдётся миллион человек, которые будут с полной уверенность доказывать, что я не прав.

Я лично рекомендовал бы изучать сразу либо Laravel, либо Symfony (а лучше и то и другое, и в целом эти фреймворки имеют много общего по части внутренностей), если соберетесь в "клуб PHP-шников".

Как уже озвучил предыдущий оратор - у PHP есть одно преимущество и недостаток в одном флаконе. Он с самых первых версий разрабатывался для создания веб-проектов (аки "сайтов"), в то время - для сайтов которые были актуальны тогда, в наше время - для сайтов (серверной части веб-проектов) которые актуальны сейчас. И это его направление очень ярко проявляется на практике... на PHP, за историю его существования вышло просто неимоверное кол-во веб-фреймворков, "плохие" умирали, те что "получше" живут до сих пор и т.д. Наверное, кол-во PHP-фреймворков (веб-направления) можно сравнить с кол-вом программ в которые Python встроен как скриптовый язык...

Python в этом плане изначально разрабатывался как язык общего назначения и делают на нем далеко не только веб/сайты, он часто используется буквально "везде", для примера - на нем написана часть 3D-редактора "Blender3d", он не редко выступает скриптовым языком в больших и сложных программах, на нем не редко пишут прототипы больших программ и так далее. Соответственно, универсальность языка - та же "палка о двух концах", что и с PHP, только "в другую сторону".

При вызове из jquey атрибут data-d не читается, но если его перенести в главный div, то читается

по тому что this в данном контексте это <div class="model-selector" data-model="Solaris" > и никак не кнопка внутри него?

$('.model-selector').click(function () {
        $("[name='modelName']").val($(this).data('model'));
        $("[name='dName']").val($(this).find('button').data('d'));
});

Я расскажу Вам про личный опыт, без претензий на истину в последней инстанции...

Для чего идеальна MongoDb? Примеры приложений, где монга будет лучше mysql?

Для человека который привык работать с реляционными БД, смириться с логикой и вообще с подобными БД - довольно сложно. Для тех, кто работает с реляционными БД профессионально - сделать это ещё сложнее...

Если сравнивать с реляционными БД и с оглядкой на конкретно MySQL - монга идеально вписывается там, где структура данных заранее неизвестна. Тут я хотел привести пример, но не смог придумать ни одного дельного примера, после того как начал плотно работать с PostgreSQL... Давайте попробую из практики. Мы один раз применяли монгу в проекте где есть десятки и сотни тысяч товарных позиций и у каждой из них свой уникальный набор различных свойств. На основе уже имеющихся свойств, "соседних" товаров, контентщику предлагался наиболее вероятный набор параметров, которые нужно заполнить, но в любой момент он мог удалить или добавить любое поле и/или множество значений одного из них, например, "Цвет: черный, серый, фиолетовый". Всё это дело попадало под разные динамические фильтры и далее по цепочке... В то время, насколько я помню ещё не было поддержки JSONB-формата у PostgreSQL, по этому мы остановились на MongoDB. Ну и конечно же, желание "воткнуть ультра новую и модную БД в проект" сыграло свою роль...

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

Безусловно, не редко можно встретить проекты в которых даже в реляционных БД не прописаны, например, внешние ключи и контроля целостности данных как такового нет, но обычно это происходит по следующим причинам:
1. Очень низкая квалификация администратора БД проекта
2. В попытке выжать из базы больше производительности, не найдя других методов оптимизации
3. Данных настолько много, что БД/ключи - начинают "сыпаться", не редко это связано с п.1

Так же, последние тесты показывают, что PostgreSQL почти не уступает MongoDB даже в её родной среде (на уровне данных в формате JSON). А в некоторых аспектах даже превосходит её... Подробности Вы можете увидеть на некоторых конференциях по Postgres (да, на конференциях по MongoDB, Вы вряд ли увидите, как кто-то будет рассказывать, что [их любимая] монга "хуже" некоторых других движков...). Кстати, поддержку формата JSON стандартизировали (наконец-то) на уровне SQL-стандарта (если я не ошибаюсь) и в самом ближайшем будущем, думаю стоит ожидать полноценную поддержку оного в SQL-базах, в т.ч. поддержку в бинарном виде с возможностью индексации данных (кстати, некоторые SQL-базы уже такое умеют).

Моё понимание, ответа на вопрос, "когда действительно стоит использовать MogoDB?" звучит примерно так: Исключительно в тех случаях, когда Вы понимаете, что она станет действительно хорошим решением для поставленной задачи и сейчас и в будущем. В моей практике, таких проектов можно было бы насчитать ничтожно мало, а точнее около нуля, особенно с учётом развития некоторых современных SQL-БД и вообще направления "JSON в SQL" в целом. Но, безусловно такие проекты могут быть и есть (в данном случае, не у меня). Но, тут стоит обратить внимание на крайне важный факт - когда всплывает такой проект, что бы адекватно оценить наиболее оптимальную БД под него - нужно знать как минимум пару-тройку SQL-БД, со всеми их особенностями, достоинствами и недостатками... причем не просто "знать", а хорошо знать, "изнутри". А так же знать все характерные черты монги, а так же её особенности, достоинства и т.д. То есть, если Вы задаётесь вопросом, "а хорошо ли впишется монга в проект N?" и не можете найти на него однозначного ответа, вероятнее всего, что в долгосрочной перспективе, в "проект N" она впишется плохо.

P.S. В заключение, хочу ещё раз напомнить, что "JSON в SQL" - активно развивается... Со всеми вытекающими.

<?= $form->field($model,'word')->textInput(['onchange'=>'loadDoc(this.value)'])?>

Говорит что нет файла composer json в папке domains.

Как вариант, Вы можете создать пустой Yii-проект, через composer, как это сделать написано, например тут, для примера:

composer create-project yiisoft/yii2-app-basic basic 2.0.12

и скопировать готовый composer.json файл оттуда.

И еще одна проблема почему-то не получается ввести токен, он его запрашивает "Token (hidden):"

Он даёт Вам ввести, просто не показывает ввод, точно так же дела обстоят, например, при вводе пароля в консоли.

RewriteCond %(REQUEST_FILENAME) !-f
RewriteCond %(REQUEST_FILENAME) !-d

Эти директивы говорят, что если поступил запрос к реально существующему файлу (-f) или каталогу (-d), то правила к нему применятся не будут. Соответственно, index2.php в вашем случае должен обрабатываться нормально (так как он является реальным файлом, правила к нему применяться не будут).
По поводу картинок, попробуйте путь указать относительно корня. То есть, чтоб путь начинался с "/". Посмотрите в отладчике браузера, по какому пути он запрашивает картинки

Добавьте в корень файл .htaccess с содержимиым

RewriteEngine On
RewriteCond $1 !\.(css|js|png|ico|jpe?g|gif|woff|eot|svg|ttf|txt)$ [NC]
RewriteRule ^(.*)$ index.php [L,QSA]

Что могу порекомендовать из литературы (коль скоро вопрос именно о ней) чем пользовался лично:

1. Во-первых, однозначно Доусон. Интересно, быстро, практично.

2. После - на выбор: если очень сжато - то ЭТО, если основательно - ЭТО.

Для начала все.

С версиями сейчас не заморачивайся, отдавая приоритет 3-ке. По поводу ближайшего будущего Python, связанного с его версиями, если интересно, почитай небольшое интервью с Андреем Светловым ТУТ.