Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Надо понимать две вещи:
"обычное приложение/лендинг/подставить_нужное" с шансом 146% окажется "необычным" (с точки зрения фрилансера)
даже если есть ТЗ, почти наверняка в процессе выяснится, что оно не полное, что "ой, ну тут надо мелочь еще сделать"
Из этого следует, что лучше работать по часам - так гораздо, невероятнее спокойнее обеим сторонам, ибо заказчик видит, во что (материально) его хотелки выливаются, а фрилансер продолжает работать, а не бузить о том, что "в ТЗ этого не было".
Тем не менее, если совсем никак по часам (бывают принципиальные заказчики или у которых бюджет, выше которого не прыгнешь):
для начала нужно получить ТЗ, максимально подробное (а не полстранички в Word типа "агитброшюра" без списка экранов, кнопок, функций и прочих требований)
по ТЗ оценить адекватность заказчика - насколько много дыр в функционале (ибо в процессе работы заказчик будет "раскручивать" тебя на функционал за каждую такую дыру, а ты - спорить с ним, что "под это описание можно весь Фейсбук подогнать")
если ТЗ адекватное и у тебя есть достаточный опыт (5-10-... штук) разработки именного такого типа сайтов - то прикидываешь, во сколько (по часам) тебе раньше обходилась разработка, какие были косяки и трудности
умножаешь полученное число часов на свою ставку и еще на 3
Если хоть один из пунктов не выполняется (ТЗ "с водой", нет опыта, не умножил на 2-3) - лучше такой проект не брать, т.к. почти наверняка в итоге будут споры, нервы, минусы в карму, плохие отзывы и прочее.
Как вариант, ТЗ можно составить самому (или помочь заказчику сделать это) - но, надо понимать, что это тоже не бесплатно (грамотное ТЗ это может быть вообще половиной проекта, условно). Обычно это может случаться с крупными заказчиками (300к+), которые тебе дают, допустим, 10% от грубой стоимости, ты с ними выясняешь ТЗ и в нем фиксируете вместе весь функционал. В итоге ты уверен, что "дыр" в ТЗ нет, а у заказчика появляется точный бюджет.
Почему я не могу свою же тему не отредактировать не удалить?
Потому что народ этим злоупотребляет. Решил проблему - напиши, как, а не удаляй вопрос.
Если запостил что-то личное - нажми "Пожаловаться", я удалю.
Я так и не понял где тут на форуме ПМ личные сообщения падают мне в почтовый ящик с обратным адресом robot@laravel.ru и на этом всё
Когда жмешь на "Сообщение" - ты отправляешь письмо на почту. Обратный адрес письма (Reply-To) выставляется в твой, так что ответ на письмо приходит к тебе. robot@laravel.ru - это отправитель, но ему ответ не отправляется.
Теперь возник другой вопрос , а что использовать лучше , мой метод с views или Ваш метод. Имеется конечно ввиду с точки безопасности и скорости выполнения.
VIEW это механизм, встроенный в СУБД. Соответственно, он более безопасный и быстрый (в общем случае, т.к. MySQL не может оптимизировать сложные запросы к VIEW). Но из этого следует и то, что если хочется переносимости между разными СУБД - VIEW лучше не использовать. С простым WHERE куда больше шансов, что он заработает в PostgresSQL или в SQLite.
Вообще, в среднем проекте нет причин использовать VIEW. Обычно "проще" значит "лучше".
а вы ему суете int
Да что вы говорите?
% php -r "echo gettype((0.1+0.7)*10);"
doubleТак что кто не знает php - идут лесом.
Если что, это была цитата из официальной документации PHP.
Крайняк, если не решу проблему, то на питоне все сделаю
На PHP вполне нормально реализуются долгоживущие парсеры. У самого PHP утечек нет, у меня бывали и бывают процессы, которые стартуют с ОС и работают, пока не перезагрузишь. Это именно проблема (или "нецелевое использование" - как угодно) Laravel. В твоем случае достаточно переписать пару мест на "более голый" PHP (степень "голости" зависит от тебя). Python - это слишком радикальное решение, ИМХО.
В конце концов, "whereIn()->pluck()" это тот же PDO + array_column(), 2-3 строчки максимум.
Ниже второй код с его использованием. разницы нет.
Значит что-то держит память, ссылки не дохлые.
Ну тут обычный запрос в бд, что бы выбрать уже имеющиеся ссылки, а затем сравнить их со всеми найденными ссылками что бы в итоге получить новые уникальные ссылки которых нет в базе.
Видимо, здесь и утекает. В Laravel ногу сломишь, пока поймешь, где, что и кто не очистил (я еще в L3 находил утечки, даже Тейлору писал, а L3 был на порядок проще того, что сейчас), поэтому попробуй переписать этот кусок в виде сырого запроса, благо он у тебя простой. Если это не поможет - тогда попробуй и вовсе его закомментировать и заменить на чтение данных из файла (просто для тестов) через json_decode(file_get_contents()) или require() (если данные в виде PHP-кода - var_export()). Если действительно утечка здесь, то после замены память будет в норме, сколько бы итераций не прошло.
Эти все файлы за 0 лет работы скопились.
Много файлов за 0 лет работы скопилось? 
Но теперь блин придется по ходу следить, или использовать шедулер что бы заного процесс запускать когда память сядит…
А чего ты хотел, Laravel оптимизированным по памяти никак не назовешь, с его кучей прокладок и фасадов. Он хорош в отдельно взятой области - обработке запросов от клиента. В этом плане никакие утечки не страшны, потому что в типичном запросе GC может вообще не вызываться, запрос быстро отработал и всю память собрали принудительно. А у тебя, видимо, тысячи объектов, и ты при этом хочешь плюшки Laravel в виде коллекций и ORM... Не, так не бывает.
Не могу понять почему чистильщик не очищает память?
А какой лимит по памяти у процесса (memory_limit)? Может ему и не нужно, т.к. памяти еще хватает.
Попробуй gc_collect_cycles(); - это вызовет GC принудительно.
Точнее сказать нельзя, потому что не известно, что там в getMissed().
$this->convert(memory_get_usage(true)));
Учти, что:
real_usage
Set this to TRUE to get total memory allocated from system, including unused pages. If not set or FALSE only the used memory is reported.
Так что статистика может быть нерепрезентативна. Сравни с memory_get_usage(false).
На MSSQL есть специальные временные таблицы.
В MySQL тоже есть временные таблицы (как явно создаваемые через CREATE TEMPORARY TABLE, так и не явно создаваемые для сложных/больших запросов). Другое дело, что временная таблица это все равно таблица со всеми вытекающими (сравнительно медленная; DDL, поэтому нельзя внутри транзакции; требует права доступа помимо базовых SELECT/INSERT/UPDATE/DELETE; и т.д.) и обычно намекает на проблемы в проектировании. К тому же если вы сами создаете временную таблицу, вам придется руками поддерживать ее актуальность, когда изменяется таблица, на основе которой она создана.
Кстати, посмотрите в сторону CREATE VIEW. Возможно, в вашем случае как раз требуется именно это.
1) Скорость загрузки не более 0,1 сек
4) Ежедневные отчёты . в день минимум 3 Pusha
Сайт должен быть полностью самописным , разработан безупречно
У всех свой стиль ведения дел, но я просто хочу обратить внимание на слишком сильный акцент на внешней стороне дела, что может вызвать у исполнителя симметричный ответ в виде формального подхода - "0.1 сек есть, 3 пуша есть, ну а что функции не работают так про это ничего и не писали"
Скорость загрузки, действительно, не всегда зависит от разработчика. Может это интеграция с сервисом в далеком забугорье, может очень хитрый фильтр на миллионе записей. Без четкого описания среды ("фильтров 2, такого-то типа, записей не более 100, до БД пинг 1 мс") такие требования выглядят, как микроменеджмент.
Push'ы - тут еще интереснее, это из разряда "требовалось не менее 100 000 строк кода, мы добили разницу цитатами из Пушкина". Редко бывает задача, которую разбить на несколько коммитов ну никак нельзя. Иногда бывает, что целый день (а то и несколько) копаешь-копаешь в поисках непонятного бага, а кода - нет. Потом один коммит с исправлением на одной строчке, за которым десятки часов поисков. И за это вы будете штрафовать? Или будете требовать отчетов?
А "самописный" - это даже не технический термин, формально я написал вызов Eloquent - и это уже мой, "самописный", код, так что вовсе не ясно, что подразумевается под этим словом.
В общем, я посоветовал бы найти отличного спеца и оставить всю техническую часть на его совести, тем более вы, видимо, не видите разницы между push и commit, то есть у вас нет хорошего технического background'а, и если будете пытаться таким спецом рулить (всякие там "митапы" и "созвоны") - он или уйдет, или будет "сидеть на з/п", в итоге у вас в любом случае проект не выгодит.
У вас смешалось все в кучу.
Во-первых, вы пишете данные в формате .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);Anatolii
Просьба не создавать дубликаты тем, а поднимать существующие.
Я на 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. Ирония в том, что пакеты как раз стараются писать без привязки к фреймворкам…
Как решить эту ошибку используя php 7.1 ?
Разобраться, почему в переменной не тот формат данных, который нужен. Скорее всего там, как и написано, не число, а временное представление типа "2019-06-01T...". Можно попробовать их посмотреть через отладчик, а не через dd(), или через var_dump(). Еще можно отключить error_reporting() для E_WARNING и/или E_NOTICE, но это очень плохой путь - разве что для отладки.
Но делаю диплом и в комиссии сказали если у тебя логины уникальные то пусть он используеца как идентификатор.
Не троллинга ради, но если у нас готовят ИТ вот с таким подходом - это просто тушите свет... Надо понимать, что члены комиссии никогда не участвовали в реальной разработке. У меня даже нет слов это прокомментировать, одни эмоции.
С формальной точки зрения делать логин первичным ключом верно, но это настолько против всех устоявшихся практик, что действительно, разве что в дипломе такой подход и увидишь. Причем причин-то менять практики нет - мало ли, логин будет перемещен в другую таблицу, да и вообще, с числовым ключом работать намного проще и быстрее (часто строка требует преобразования в число для использования в индексе). А если логин будет изменен (некоторые форумы, к примеру, это позволяют) - это повлечет за собой изменение его во всех связанных таблицах. И это только то что сразу приходит на ум.
Делать ПК на "обычных" данных хорошо разве что в pivot-таблицах, где поле с автоинкрементом совершенно излишне.
Первое: перечисление типа 5,6,7,10,15,16,17,21,29 преобразовать в 5-7,10,15-17,21,29
<?php
$s = '5,6,7,10,15,16,17,21,29';
$a = [];
$prev = $start = null;
foreach (json_decode("[$s,0]") as $n) {
if ($n - 1 !== $prev) {
$start === null or $a[] = $start === $prev ? $start : "$start-$prev";
$start = $n;
}
$prev = $n;
}
echo join(',', $a);Второе: перечисление типа 5-7,10,15-17,21,29 преобразовать в 5,6,7,10,15,16,17,21,29
<?php
$s = '5-7,10,15-17,21,29';
$a = [];
foreach (explode(',', $s) as $pair) {
list($start, $end) = explode('-', $pair) + ['', ''];
$end === '' and $end = $start;
while ($start <= $end) { $a[] = $start++; }
}
echo join(',', $a);А как установить swap постоянно ?
Дописать в /etc/fstab:
/swapfile none swap defaults 0 0Но как только пытаюсь уточнить поле даты, оно сразу меняется.
Что понимается под "уточнить"?
Внешние ключи именно для того и придуманы, чтобы их нельзя было просто обойти - они нужны для сохранения целостности базы. Если задача такая, что внешний ключ мешает - то что-то не то в самой задаче.
Например, если у тебя ключ на каком-то id (в другой таблице), то перед изменением записи надо создать запись в той второй таблице, чтобы такой id действительно существовал, тогда внешний ключ не будет "мешать".
Информации слишком мало, чтобы дать более точный ответ.
Затем , если страницу не трогать несколько минут и сделать Refresh опять тормоза .
Если это не какое-то внутреннее кэширование Laravel, то похоже на встроенный opcache в PHP, который кэширует (предкомпилирует) скрипты в памяти вместо загрузки каждый раз с диска, что очень сильно ускоряет работу проектов с кучей скриптов (как то Laravel, форумы, вики-движки и т.д.).
По умолчанию opcache не "протухает", но, возможно, на вашем сервере настройки нестандартные или памяти слишком мало - см. php.ini, группу [opcache]. Там много полезных переменных - максимальное число файлов, используемая память, время обновления и т.д.
garrip91
Тема закрыта. Я вам писал, почему. За повторный пост такого же характера будет бан - первый на этом форуме за все 7 лет его истории.
[pool www] child 9221 exited on signal 11 (SIGSEGV - core dumped) after 1506.246210 seconds from start
А точно та ошибка? "after 1506.246210 seconds" говорит, что скрипт висел 25 минут, прежде чем упал, а вы писали: "При этом, если обновить страницу, то страница корректно отображается." - 25 минут точно ждали?
Есть сведения, что сегфолт можно вызвать зациклившейся регуляркой, например.
Это надо очень-очень постараться. Возможно, в системе несовместимые библиотеки, PHP был собран не на тех, которые есть сейчас. Лучше попробовать все удалить (со всеми зависимостями), обновить apt/yum/что там у вас, и поставить заново из пакетов.
На одном проекте хорошо разобрался и реализовал FullText (мускл 5.7 InnoDB) и в итоге при размере БД в 6КК строк в основном в трех таблицах (1гиг с индексами), ищет почти мгновенно.
У меня в одном проекте с ~5 млн строк (в одной таблице) поначалу тоже был FULLTEXT-индекс от MySQL, но, видимо, у нас разная структура данных и/или поиска. У меня каждый документ это где-то 50 индексируемых слов, а каждый запрос может содержать десяток слов в разной конфигурации (т.е. с операторами). На MySQL в какой-то момент времени поиск стал занимать секунды, перешел на Sphinx - поиск сократился до долей секунды (на 2 порядка).
Еще большой плюс Sphinx (либо отдельной системы хранения вроде Redis только для поиска) в том, что добавлять/обновлять данные в огромной таблице с FULLTEXT под нагрузкой нереально. У меня импорт 100к записей, если не отключать сайт, занимал часы, при этом хоть сайт и был скорее жив, чем мертв (для пользователей), но все жутко тормозило из-за параллельного обновления индекса. А Sphinx - это отдельная надстройка, он может легко обновляться частично и/или на лету без особых проблем с производительностью.
Минус только в том, что изначально связку Sphinx и MySQL нужно настроить, но зато дальше полет нормальный.
хочу спросить кто какие плагины использовал для Laravel 5
Насчет плагинов ничего не могу сказать (проект не на Laravel), но зачем они нужны, если у Sphinx такой же интерфейс, что и у MySQL?
<?php
$persons = [
'name'=>[
0=> 'Vasya',
1=>'Petya',
2=>'Kolya'
],
'street' =>[
0=>'Lenina',
1=>'Marksa',
2=>'Engelsa'
]
];
// ----
$elegant = array_map(function ($name, $street) {
return compact('name', 'street');
}, $persons['name'], $persons['street']);
// ----
var_dump($elegant);Так на https://laracasts.com нет субтитров. Или они появляются, когда покупаешь подписку?
Честно говоря уже не помню, возможно ты прав. Но если там нет английских субтитров - значит нигде нет.
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)