Laravel по-русски

Я до сих пор использую PHPlot, отличная библиотека с кучей функционала. Без биндингов к Laravel, но, с другой стороны, зачем они нужны?

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

sqlite3 - это для функций типа sqlite_open(). pdo_sqlite - это драйвер для функций PDO, а PDO работает сразу со многими БД. Laravel использует PDO, как и все современные проекты.

Смотри логи сервера и логи Laravel.

Сделай скрипт вида <?php phpinfo(); открой его в браузере, посмотри, есть ли там среди опций pdo_sqlite. Если его нет, то, значит, в php.ini он не включен (или сервер не был перезапущен после включения). Включается просто - добавь такую строку (путь не нужен):

extension=pdo_sqlite

Она уже там где-то есть, только закомментированная (с ; в начале).

Если pdo_sqlite нет в системе, то PHP при запуске должен ругаться. Но ты говоришь, что из консоли работает - значит, он есть. Учти еще, что обычно в системе несколько php.ini - один для CLI, другой для Apache, третий для php-fpm и т.д. Если ты включаешь расширение в /etc/php/*/cli/php.ini, то в Apache оно не включится - меняй соответствующий конфиг.

Надо понимать две вещи:

• "обычное приложение/лендинг/подставить_нужное" с шансом 146% окажется "необычным" (с точки зрения фрилансера)

• даже если есть ТЗ, почти наверняка в процессе выяснится, что оно не полное, что "ой, ну тут надо мелочь еще сделать"

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

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

• для начала нужно получить ТЗ, максимально подробное (а не полстранички в Word типа "агитброшюра" без списка экранов, кнопок, функций и прочих требований)

• по ТЗ оценить адекватность заказчика - насколько много дыр в функционале (ибо в процессе работы заказчик будет "раскручивать" тебя на функционал за каждую такую дыру, а ты - спорить с ним, что "под это описание можно весь Фейсбук подогнать")

• если ТЗ адекватное и у тебя есть достаточный опыт (5-10-... штук) разработки именного такого типа сайтов - то прикидываешь, во сколько (по часам) тебе раньше обходилась разработка, какие были косяки и трудности

• умножаешь полученное число часов на свою ставку и еще на 3

Если хоть один из пунктов не выполняется (ТЗ "с водой", нет опыта, не умножил на 2-3) - лучше такой проект не брать, т.к. почти наверняка в итоге будут споры, нервы, минусы в карму, плохие отзывы и прочее.

Как вариант, ТЗ можно составить самому (или помочь заказчику сделать это) - но, надо понимать, что это тоже не бесплатно (грамотное ТЗ это может быть вообще половиной проекта, условно). Обычно это может случаться с крупными заказчиками (300к+), которые тебе дают, допустим, 10% от грубой стоимости, ты с ними выясняешь ТЗ и в нем фиксируете вместе весь функционал. В итоге ты уверен, что "дыр" в ТЗ нет, а у заказчика появляется точный бюджет.

Когда жмешь на "Сообщение" - ты отправляешь письмо на почту. Обратный адрес письма (Reply-To) выставляется в твой, так что ответ на письмо приходит к тебе. robot@laravel.ru - это отправитель, но ему ответ не отправляется.

Да что вы говорите?

% php -r "echo gettype((0.1+0.7)*10);"
double

Если что, это была цитата из официальной документации PHP.

Значит что-то держит память, ссылки не дохлые.

Видимо, здесь и утекает. В Laravel ногу сломишь, пока поймешь, где, что и кто не очистил (я еще в L3 находил утечки, даже Тейлору писал, а L3 был на порядок проще того, что сейчас), поэтому попробуй переписать этот кусок в виде сырого запроса, благо он у тебя простой. Если это не поможет - тогда попробуй и вовсе его закомментировать и заменить на чтение данных из файла (просто для тестов) через json_decode(file_get_contents()) или require() (если данные в виде PHP-кода - var_export()). Если действительно утечка здесь, то после замены память будет в норме, сколько бы итераций не прошло.

Много файлов за 0 лет работы скопилось?

А чего ты хотел, Laravel оптимизированным по памяти никак не назовешь, с его кучей прокладок и фасадов. Он хорош в отдельно взятой области - обработке запросов от клиента. В этом плане никакие утечки не страшны, потому что в типичном запросе GC может вообще не вызываться, запрос быстро отработал и всю память собрали принудительно. А у тебя, видимо, тысячи объектов, и ты при этом хочешь плюшки Laravel в виде коллекций и ORM... Не, так не бывает.

В MySQL тоже есть временные таблицы (как явно создаваемые через CREATE TEMPORARY TABLE, так и не явно создаваемые для сложных/больших запросов). Другое дело, что временная таблица это все равно таблица со всеми вытекающими (сравнительно медленная; DDL, поэтому нельзя внутри транзакции; требует права доступа помимо базовых SELECT/INSERT/UPDATE/DELETE; и т.д.) и обычно намекает на проблемы в проектировании. К тому же если вы сами создаете временную таблицу, вам придется руками поддерживать ее актуальность, когда изменяется таблица, на основе которой она создана.

Кстати, посмотрите в сторону CREATE VIEW. Возможно, в вашем случае как раз требуется именно это.

У вас смешалось все в кучу.

Во-первых, вы пишете данные в формате .csv (comma-separated values), а не .xls или .xlsx (это именно родные Excel-форматы, не CSV). Поэтому давайте имени файла расширение .csv.

Во-вторых, Excel (по крайней мере старые версии точно, старее 2015 или около того) читает CSV только в кодировке ОС, т.е. на русской Windows это CP1251 (как вы правильно заметили). Но! У CP1251 не может быть префикса BOM (EF BB BF) - это признак файла в кодировке UTF-8. Нельзя один файл кодировать одновременно как UTF-8 и CP1251. BOM в вашем случае нужно убрать, оставить только mb_convert_encoding().

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

Все правильно, пишут как раз про .xls/.xlsx, которые закрытые бинарные форматы от MS.

$text = '';
foreach ($arrayData as $key => $value) {
    $text .= "\"$value\";\"$key\"\r\n";   // <<<
}
$files = fopen($_SERVER['DOCUMENT_ROOT']."/file_text.csv","w+b");   // <<<
//fwrite($files, "\xEF\xBB\xBF");  // <<<
$text = mb_convert_encoding($text,"windows-1251");
fwrite($files, $text);
fclose ($files);

Я на Laravel не писал уже много лет, так что о нем конкретно говорить не могу, но вообще, когда читаю статьи про фреймворки, ощущение, что народ 90% рабочего времени пишет модели, формы и классы (или печатает со скоростью 10 знаков в минуту), и поэтому кодогенераторы и магические dependency injection (и другие injection, вроде свойств в Eloquent) приносят такое невероятное облегчение и хайп. Особенно меня вымораживают кодо-комментарии (@dataSource и пр.) — ладно там в юнит-тестах, но в основном коде, это ж маразм, основывать логику на комментариях!

В моей работе как-то все наоборот. Да, есть модели (сильное название — класс со свойствами), но вообще не вижу никаких проблем от руки написать такой класс на каждую таблицу (даже если их 20-30 штук). Это делается даже «не приходя в сознание». И не ломаешь голову, откуда пришло то или иное свойство. Явное лучше скрытого. С методами аналогично — руки не отсохнут написать, что первый аргумент это User $user. На такие рутинные операции тратится может 5% времени. Остальные 95% — никакой фреймворк не облегчит, потому что это собственно и есть бизнес-логика, где требуется продумывание и планирование и только потом код.

А вот шаблонизаторы, если они легкие и прозрачные, сильно облегчают жизнь — писать HTML на голом PHP не продуктивно. ORM — если очень-очень легкая, то имеет место быть для всяких User::find(123), однако обязательно должен быть и прямой доступ к SQL (в виде подготовленных запросов), иначе придется переписывать пятиэтажные (JOIN) запросы с WHERE, HAVING, ORDER BY и LIMIT из человекочитаемого SQL в человеконечитаемые вызовы методов. ORM такие запросы эффективно сгенерировать вряд ли сможет, да и будешь уверен, что после очередного обновления и изменения внутренней логики ORM твой запрос не стал в 10 раз медленнее, потому что она его поняла как-то не так. Отлаживать удобнее, опять же.

Нужно смириться, что код писать придется так или иначе, и что «удобства» добавляют огромное число неконтролируемого тобой кода, который ни отладить (из-за объема и из-за магии), ни понять.

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

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

С формальной точки зрения делать логин первичным ключом верно, но это настолько против всех устоявшихся практик, что действительно, разве что в дипломе такой подход и увидишь. Причем причин-то менять практики нет - мало ли, логин будет перемещен в другую таблицу, да и вообще, с числовым ключом работать намного проще и быстрее (часто строка требует преобразования в число для использования в индексе). А если логин будет изменен (некоторые форумы, к примеру, это позволяют) - это повлечет за собой изменение его во всех связанных таблицах. И это только то что сразу приходит на ум.

Делать ПК на "обычных" данных хорошо разве что в pivot-таблицах, где поле с автоинкрементом совершенно излишне.