Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Прочитал дискуссию, стало грустно.
Какой все-таки ужасный спор: то ли знать что-то одно, но хорошо - то ли всего по чуть-чуть. Лично я только по одной этой дискуссии смог бы понять, почему падают "Прогрессы", если б не прочувствовал этого ранее.
Оба ответа ужасны.
Ну вот как-то так можешь вставить запись в Clients и в переменную $id получить ид вставленной записи
$conn=DB::connection('mysql');
$id = $conn->table('Clients ')->insertGetId(
[
'name'=>$name
,'age'=>$age
...
]);tmanager пишет:Но когда осуществляешь эту настройку сам - видишь, сколько нужно "свистелок и перделок", чтоб это всё работало.
Так с любой технологией, особенно когда используется стэк технологий, на то и в моду пошли docker/vagrant.
Но есть какой-то предел, за которым я начинаю переживать за судьбу проекта. Ну например. Сервер (компьютер) стал умирать. Нужно все переставить на новый. И кто-то решает - а не поставить ли новые версии всякого софта - раз уж пошла такая пьянка.
Когда с моим проектом такое произошло - как я благодарил себя, что минимально зависел от сервака!
Про надёжность - у вас были какие-то кейсы когда фреймворк "ломался" сам по себе?
Нет, никогда.
Если понимать надежность в значении "не ломается на должным образом настроенном сервере" - то Ларавел и проекты на нем вполне надежны. Но когда осуществляешь эту настройку сам - видишь, сколько нужно "свистелок и перделок", чтоб это всё работало.
Потому что руководству всё равно как пишется код, это не его компетенция. Поэтому вразумительно ответить оно не может. Я уже привёл наглядные примеры, когда ваш стиль вызывает проблемы.
Это его компетенция. Иначе это не руководитель - а какой-то дурачок.
Но ему нужны доводы, а не пробелы.
Другой сценарий:
1. Для генерации ID сессий используются настройки PHP по умолчанию.
2. Эти настройки (ГПСЧ) используют предсказуемые источники энтропии (время).
3. Особо не трудясь их можно предугадать, синхронизировавшись с сервером, который отправляет время с точностью до секунды в Date в каждом запросе.
4. И дальше увести сессию.
А нефиг использовать авторизацию на сессиях в ответственных случаях!
Вам стоило бы почитать что-то хорошее по безопасности. Не хабрахабр и вообще не то, что Вы читаете. Что-то хорошее.
Сценарий:
1. Сайт соцсети.
2. Пользователи загружают личные фотографии.
3. Для файлов генерируются предсказуемые имена.
4. Кто угодно с малейшим знанием bash/wget скачивает картинки в обход настроек приватности.
Если стоит задача приватности фото - которая в этой теме не ставилась! - то она совершенно иначе решается!
Вовсе не путем придумывания хитрых имен - это дебилизм полнейший! Если так работают соцсети - это довод не хранить в них ничего приватного.
Я надеюсь, вы понимаете, что это говорит не в пользу этого времени, потому что проблемы предсказуемых идентификаторов очевидны.
Вам на каждом шагу мерещатся хакеры, которые, как только узнают нехитрый принцип формирования имен закачанных файлов - сразу сломают сайт к чертовой матери. Поэтому Вы будете делать это за них
Чтоб юзеры затирали друг другу файлы. Да здравствует непредсказуемость!
но общепринятой практикой в известных мне языках считается располагать скобки на том же уровне, что и блок.
Это действительно общепринятая практика - или мы присутствуем при сочинении нового мифа?
Работающий код <> безопасный код и даже <> хороший код.
Если проект работает 6 лет без сбоев - смело заменяйте Ваши неравенства равенствами: это означает, что код легко читаем и обновляем.
Плохой год после шесть лет превращается в ср-е г-но и его приходится переписывать.
То, что у вас таких проблем не было может обозначать как качественно написанный код (в чём ваши фрагменты кода заставляют усомниться)
Из-за пробелов после ифов?
, так и отсутствие заинтересованных лиц в его, так сказать, разоблачении.
Да полно таких лиц, только руководству требуется что-то более существенное, чем пробелы и уровни скобок.
Я даже знаю, что они Вам ответят на это. Ничего.
Ну то есть поблагодарят за внимание к качеству - и дадут понять, что разговор окончен.
WordPress?
Нет. Времена, когда для уникальности внось создаваемого именир не использовали текущее время или генератор случайных чисел - как в примерах выше. Они у Вас когнитивного диссонанса не вызвали
У меня скобки на том же уровне, что и вложенный блок, вызывают когнитивный диссонанс.
Сочувствую.
В коде мешанина из пробелов и табов
Это не ко мне. Это к форуму, с которым я боролся, возможно, неумело. В моем редакторе все красиво.
После запятых и if и switch нужны пробелы, между равно тоже. Иначе код write-only.
Тут можете глумиться - это я перфокарты экономлю
По привычке.
Это Ваше замечания готов принять.
Страшно подумать, как выглядит ваш проект.
Но он работает - приятно удивляя быстродействием и надежностью. Уже шесть лет - в трех офисах. ERP большой фирмы.
Уменьшил отступы - и сделал более понятный комментарий про таблицу:
//fieldName - имя input type="file"
if(isset($_FILES['fieldName'])) //Пришли данные из формы
if($_FILES['fieldName']['size'] > 0) //Файл закачался
{
//Изучим, что это нам закачали (getimagesize() - в ядре)
$info=getimagesize($_FILES['fieldName']['tmp_name']);
if($info === false) //Закачали НЕ изображение
{
//Обрабатываем ошибку
}
else
{
$ext = 'jpg'; //расширение файла
switch($info[2])
{
case IMG_GIF:
$ext = 'gif';
break;
case IMG_PNG:
$ext = 'png';
break;
case IMG_JPEG :
break;
default:
//Как-то реагируйте на то, что не веб-формат
break;
}
//$conn - это подключение к базе данных. Внутри метода надо будет написать
//global $conn;
//Нужно создать таблицув базе для того, чтоб делать уникальные имена файлам
//Вот её структура
//create table pictures(id int primary key auto_increment);
$query='insert into pictures() values()';
mysqli_query($conn,$query);
$id=mysqli_insert_id($conn);
//формируете по своей логике путь к файлу. Например:
$filename=__DIR__.'/../../images/users/image'.$id.'.'.$ext;
//Закачиваем файл
move_uploaded_file($_FILES['fieldName']['tmp_name'], $filename);
if(!file_exists($filename))
{
//Обрабатывайте ошибку - скорее всего, права доступа на папку
}
else
{
//формируете по своей логике URL файла. Например:
$url = '/images/users/image'.$id.'.'.$ext;
//Ну теперь и записываем его... куда его надо записать? Ну например:
$query="insert into userfiles(url,width,height) values('$url',".$info[0].",".$info[1].")";
mysqli_query($conn,$query);
}
}
}Об такой пример кода глаза сломаешь, неужели нельзя нормально его отформатировать?
дело вкуса. Мне так нравится. Кому иначе нравится - недолго и отформатировать
создание таблицы в момент загрузки (что значит лишние привилегии пользователю БД)
Нет там создания таблицы в момент загрузки.
Есть комментарий, отражающий структуру таблицы.
Аж почувствовал дыхание из рубежа 90-00.
Дыхание просвещенных времен.
//fieldName - имя input type="file"
if(isset($_FILES['fieldName'])) //Пришли данные из формы
if($_FILES['fieldName']['size'] > 0) //Файл закачался
{
//Изучим, что это нам закачали (getimagesize() - в ядре)
$info=getimagesize($_FILES['fieldName']['tmp_name']);
if($info === false) //Закачали НЕ изображение
{
//Обрабатываем ошибку
}
else
{
$ext = 'jpg'; //расширение файла
switch($info[2])
{
case IMG_GIF:
$ext = 'gif';
break;
case IMG_PNG:
$ext = 'png';
break;
case IMG_JPEG :
break;
default:
//Как-то реагируйте на то, что не веб-формат
break;
}
//$conn - это подключение к базе данных. Внутри метода надо будет написать
//global $conn;
//Создадим таблицу для того, чтоб делать уникальные имена файлам
//create table pictures(id int primary key auto_increment);
$query='insert into pictures() values()';
mysqli_query($conn,$query);
$id=mysqli_insert_id($conn);
//формируете по своей логике путь к файлу. Например:
$filename=__DIR__.'/../../images/users/image'.$id.'.'.$ext;
//Закачиваем файл
move_uploaded_file($_FILES['fieldName']['tmp_name'], $filename);
if(!file_exists($filename))
{
//Обрабатывайте ошибку - скорее всего, права доступа на папку
}
else
{
//формируете по своей логике URL файла. Например:
$url = '/images/users/image'.$id.'.'.$ext;
//Ну теперь и записываем его... куда его надо записать? Ну например:
$query="insert into userfiles(url,width,height) values('$url',".$info[0].",".$info[1].")";
mysqli_query($conn,$query);
}
}
}tmanager пишет:Ребят, а почему не написать это на чистом php? И кода меньше, и универсальности больше.
Одна ведь функция всего: move_uploaded_file().В общем, кому пример на чистом php?
Мне, пожалуйста.
Пришлю, только сегодня вечером или завтра утром. Я в пути ![]()
Не скажу про данный проект, но поделюсь опытом.
Вот живет себе на свете бизнесмен. Учинивший свой бизнес: оптом купить - в розницу продать. Что, конечно же, в условиях нашей бюрократии и искусство, и подвиг. Но есть какая-то тоска: учился-учился, фазовые портреты рисовал, в пространстве их вертел - а зарабатываешь как банальный торговец с 8-ю классами школы. Хочется почувствовать себя элитой: рассказать что-то умное слушателям - особенно дамам. Но и тут облом: все норовят от этих лекций улизнуть. Особенно дамы. Даже собственные сотрудницы начинают тупить, что им-де работать надо (ха-ха-ха).
И тут, как и положено, лёжа в ванне, бизнесмен кричит "Эврика!". Проект.
Находим больных и отбившихся от стада программистов, и платим им... нет-нет, не зарплату! Некое пособие, чтоб (плохо) дожить до светлого будущего. И в помощь им - девчонок, которые явно недогружены. Собрал "митинг" в кафе - и читай лекции, куда они теперь денутся. Будут слушать.
И в душе мир: я ж инноватор, проекты делаю. Для всяких отсталых стран типа США.
* * *
Мой совет такому бизнесмену: прекрати х-й заниматься, эти девки все равно не дадут. Это не так делается.
Мой совет программистам: самая ср-я работа лучше участия в таком проЁкте. Хотя бы слушать эту муйню не надо.
Извините.
Но надо всё-таки понимать, что среди кучи таких "вбросов" есть действительно достойные решения.
Разумеется. Но такие решения должны обладать некоторым очевидным преимуществом. А не просто "моложе - значит лучше".
...Сорри. Поехал я с 4-го Laravel-а на пятый. Буду сильно занят.
Вот читаю я Вас - и вспоминаю целый пласт кинематографа, когда два главных героя: один - опытный ветеран, второй - новичок, но обученный по последнему слову. Второй - конечно, молодец, и именно благодаря его смелым решениям все получается. Но ничего б не получилось, если б первый постоянно не вытаскивал второго из ...ма.
Потому что новое - не только не всегда лучшее. Это даже и не всегда новое.
}%> По мне - и Laravel не беда, не будь Mongo в проекте. Бьюсь.
Не обижайтесь, но вы как будто проспали 20 лет и выйдя из спячки внезапно обнаружили кучу новых вещей - MVC, ORM, NoSQL-БД и теперь все эти новшества вам кажутся странными и неразумными. Зачем вас понесло в веб-разработку?
Все наоборот. Я удивляюсь: сплю я, что ли??? Было ж все это 20 лет назад - и было отвергнуто. Совершенно справедливо, на мою думку. Появились нормальные, адекватные технологии. И вдруг все это отвергнутое и отсталое полезло вновь - но это теперь инновации.
Мне это напоминает эстраду: стали перепевать древние-древние песни. Они теперь - новые. Так и здесь.
* * *
Вот Вы мне может объяснить: чем Монго лучше того же MySQL? Только просьба - без пропагандисткого гундежа. А вот так, чтоб я понял - да, нужно изучать, потому что есть очевидное преимущество?
Ну все по сути уже сказано, даже Конфуция вспомнили (весьма к месту!).
Я только хочу добавить: вот в такой тяге к знаниям есть что-то нездоровое. Топикстартер рискует стать книжником. Вроде тех, о которых народ слагает что-то вроде "ученые - в ... мочёные".
Чтоб этого не произошло - немедленно сделайте проект! Придумайте и сделайте! И только после этого возвращайтесь в обсуждения.
P.S. Это добрый совет и ничего более.
В проекте действительно L4?
Да, консоль так сказала, да и по всему видно.
По мне - и Laravel не беда, не будь Mongo в проекте. Бьюсь.
Уже знаю, про что будет моя следующая статья
Ничего нет толкового про Монго, особенно под Ларой. Дают ссылку, ссылка ведет на другую ссылку, а там в итоге фигня какая-то.
Снимаю вопрос. В первом случае - что угодно, только не данные.
Извините.
Вот так массив значений заполняется:
$result = DB::connection('mongodb')->collection('products')
->where('category_id','=',(int)$category_id);А вот так не заполняется (ошибки не выдает, просто пустой массив):
$result = DB::connection('mongodb')->collection('products')
->where('category_id','=',(int)$category_id)
->get();Винда может так подгадить?
Основная проблема - это безопасность. Я аж в ступор впал, когда прочитал "...за незначительное усиление надежности". SQLi были бичом сети вплоть до последнего времени.
Все известные мне (не по прессе, а от верных людей) взломы были делом рук людей, законно получивших все необходимые доступы для своего злодейства. Им не нужно было унижаться до SQL-инжекции.
и привет - у топового интернет-аукциона находят SQLi //на главной странице//. И утекли миллионы данных пользователей, потому что их разработчик считал "незначительные улучшения надёжности" выше своего достоинства.
Не поэтому. А потому, что он вообще ничего не считал. Это такая примета времени сегодня - "эффективный менеджер". Он - руководил.
Дал команду.
Каждый сырой запрос - это потенциальная дыра. Сколько запросов - столько дыр. По статистике вероятности после ...цатого запроса помноженное на число доработок проекта и членов команды вероятность ошибки стремиться к единице. Оно вам надо?
Мне - не надо. Я просто взял за правило экранировать все, что пихаю в запрос.
Читаемость кода, стоимость разработки и поддержки проекта. Ты пробовал читать чей-то сложный запрос в БД? Сколько у тебя времени уходит на то, чтобы понять как это работает?
Запрос SQL - это предложение на английском языке. И если он тяжело читается - значит, плохо спроектирована база и/или автор запроса неправильно строит работу с базой. На мои сложные запросы никто не жалуется.
Вот ты оставил время и энергию (т.е. деньги заказчика), разобрался, добавил фичу/пофиксил баг и забыл. Через три месяца лезешь в этот запрос и опять приходится разбираться полностью с нуля.
Если я "разобрался и пофиксил" - значит, запрос переписан и читается как "я помню чудное мгновенье".
Еще ситуация. Ты изменил в одном месте код запроса и у тебя рухнуло отображение данных в нескольких местах.
Если мне за это объявят неполное служебное соответствие - я скажу, что счастливо отделался.
Ты можешь взять чужой проект и с ходу работать с данными, потому что всегда знаешь какой там будет формат данных.
Вот взял. Бьюсь, как рыба об лёд.
Кстати, уже могу назвать проблему, к которой привел ORM. Человек писал код, совершенно не заморачиваясь быстродействием. Индексы, партишины, view? Нет, не слышали. Все записи в массив, массив обойдем построчно, собирая чего-то там. Потом и о пагинации подумаем, если процесс еще не гавкнулся...
Если честно, я вообще не понимаю как в 2016ом можно до сих пор писать сырые запросы при наличии прекрасных проверенных годами ORM.
Ну хотя бы затем, чтобы легче понять, в чем проблема выполнения запроса. Вот не работает правильно код ORM - что ему, скоту, надо???
А выводишь текст запроса, который тщится выполнить скрипт - и "вот и он, больной зуб"
Вообще, чтобы понять разницу между ООП и процедурным кодом, ORM и сырым SQL нужно сделать хотя бы один действительно сложный проект с множеством связей.
Этого у меня не отнять.
"мне так удобнее, потому что я это знаю, а учиться не хочу".
Так вопрос не стоит.
Я начинаю изучать ОРМ - и думаю, мои аргументы не заставят себя ждать. Понадобится какой-нибудь SELECT ... INTO или что-то другое, чего не выразить ОРМ-ом.
А пока умолкаю за отсутствием аргументов.
Ну какие там значительные ограничения? :-)
Не знаю.
Я понимаю, что ignorantia non est argument. Просто чует сердце-вещун: должны быть серьезные ограничения.
Вот изучу (куда деваться) этот ОРМ - и, может, продолжу эту тему.