>>35068
>>1134788

Ты можешь посмотреть в сторону компонента Symfony ExpressionLanguage: https://symfony.com/doc/current/components/expression_language.html - там уже есть парсер выражений. Но если тебе интересно, как вообще это делается, читай пасту:

Разбор выражений делается с помощью синтаксического анализа. Он же применяется, например, при разборе компьютерных программ. Мы определяем "грамматику" (набор правил) и по ней делаем разбор.

Для записи грамматики есть разные стандартные способы:

- BNF https://en.wikipedia.org/wiki/Backus–Naur_form
- EBNF https://en.wikipedia.org/wiki/Extended_Backus–Naur_form
- ABNF https://en.wikipedia.org/wiki/Augmented_Backus–Naur_form (спецификация на рус: https://rfc2.ru/5234.rfc )
- и даже можно использовать регулярки https://habrahabr.ru/post/171667/

Все эти грамматики определяют правила составления конструкций из минимальных неделимых кусочков языка (терминалы) и других составных конструкций. Например, для математического выражения терминалами могут быть числа и знаки арифметических операций, а составной конструкцией - "сумма", определенная как последовательность конструкций ЧИСЛО "+" ЧИСЛО.

Традиционно разбор выражения делают в 2 этапа:

1) В рамках лексического анализа лексер (токенайзер) разбивает выражение на массив токенов (лексем): "-(22 + 2) ^ 3 ^ 4" -> ['-', '(', '22', '+', '2', ')', '^', '3', '^', '4']. На этом этапе числа группируются в токен, удаляются незначащие символы. Токен может быть представлен строкой, массивом, объектом, в зависимости от задачи. Последовательность токенов можно представить в виде массива или объекта.

2) В рамках синтаксического анализа парсер получает на вход поток токенов и строит дерево выражения их узлов. Тут есть разные алгоритмы: https://ru.wikipedia.org/wiki/Синтаксический_анализ

Дерево выражения удобно представлять в виде дерева из объектов-узлов разного типа (AST). Ну например, математическое выражение 10 + 2 + 3 ^ 4 можно представить в виде дерева объектов:

SumNode(
NumberNode(10),
NumberNode(2),
PowerNode(
NumberNode(3),
NumberNode(4)
)
)

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

Для твоей задачи самым простым будет метод "рекурсивного спуска". На вход алгоритм получает "поток токенов", на выходе выдает объект-корень дерева выражения (AST). С деревом потом можно делать что угодно.

Мы представляем поток токенов в виде некоей сущности tokens (это может быть объект, итератор, и тд), которая поддерживает по сути 2 операции: "подглядеть" текущий токен (peek) и "поглотить" (consume) текущий токен с переходом к следующему. Таким образом, парсер читает последовательность токенов за один проход и никогда не "отступает" назад. Это позволяет нам подсоединить выход лексера так, что мы не накапливаем массив токенов, а сразу же разбираем их по мере получения. Вот пример потока токенов, представленного в виде класса:

class TokenStream
{
// Возвращает текущий токен либо null, если они закончились
public function peek(): ?Token { ... }

// Берет токен, проверяет, что он указанного типа, возвращает его
// и переходит к следующему токену
public function consume($type = null): Token { ... }
}

Для начала, мы записываем "грамматику", то есть полный набор правил, по которым разбираются выражения, начиная с верхнего уровня. Я использую синтаксис ABNF ( https://en.wikipedia.org/wiki/Augmented_Backus–Naur_form , советую почитать также про BNF и EBNF):

-------

; Правила записываются в виде "конструкция = определение"
; Например, ниже "операнд" может быть одной из перечисленных ниже конструкций
; Знак / обозначает "или"
; ЧИСЛО - это один токен, который далее не делится на части (терминал)
; строки в кавычках вроде "(" обозначают соответствующие символы (скобку)
операнд = ЧИСЛО / "(" выражение ")" / унарный-минус / унарный-плюс

унарный-минус = "-" операнд
унарный-плюс = "+" операнд

; ＊ значит, что выражение в скобках повторяется сколько угодно раз, включая ноль,
; то есть конструкция "степень" может содержать много операндов и знаков ^,
; а может состоять из одного операнда без знака ^
степень-или-операнд = операнд ＊( "^" операнд )

; произведение - это набор конструкций "степень", разделенный
; знаками деления и умножения
произведение = степень-или-операнд ＊( ( "＊" / "/" ) степень-или-операнд )
сумма = произведение ＊( ( "+" / "-" ) произведение )

выражение = сумма

-------

Читать правила удобнее снизу вверх (а писать - наоборот).

Эти правила по сути задают алгоритм разбора той или иной конструкции. Ну например, правило 'операнд = ЧИСЛО / "(" выражение ")" / унарный-минус / унарный-плюс' значит следующее:

Когда мы хотим разобрать конструкцию "операнд", мы должны:

- проверить, является ли токен ЧИСЛОм ? Если да - создаем из него узел и разбор закончен
- является ли первый токен скобкой? Если да, поглощаем его, затем вызываем правило разбора "выражение", затем поглощаем закрывающую скобку
- является ли первый токен минусом? Если да, разбираем конструкцию "унарный-минус"
- является ли первый токен плюсом? Если да, разбираем конструкцию "унарный-плюс"
- иначе, выдаем синтаксическую ошибку

Правило 'сумма = произведение ＊( ( "+" / "-" ) произведение )' надо читать так:

Конструкция "сумма" состоит из конструкции "произведение", за которой может идти любое число последоватльностей из знака плюс или минус и конструкции "произведение".

Эти правила можно записать и по-другому. Например, "степень-или-операнд" можно сформулировать так:

; правоассоциативное выражение
степень-или-операнд = операнд "^" степень-или-операнд / операнд

; левоассоциативное
произведение = степень-или-операнд ( "＊" / "/" ) произведение / степень-или-операнд

Возвращаясь к методу "рекурсивного спуска". В нем мы для каждого правила грамматики пишем соответствующую функцию, которая его реализует. Она выглядит так:

function parseSomething(tokens): [Node, tokens]

Она получает на вход поток токенов, поглощает часть из них, возвращает соответствующий им узел дерева и измененный поток токенов. Возвращать на самом деле tokens не обязательно, можно договориться, что функция изменяет состояние переданного ей аргумента.

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

Если взять правила выше, то у нас будут функции:

parseOperand
parseUnaryMinus
parseUnaryPlus
parsePower
parseMultiplication
parseSum = parseExpression

Опишу для примера алгоритм функции parseOperand(tokens):

- если текущий токен == ЧИСЛО, то создаем узел типа NumberNode и возвращаем его
- иначе, если текущий токен = "(", то поглощаем его, вызываем parseExpression и поглощам идущий далее токен ")". И возвращаем получившийся узел.
- если текущий токен - знак минус, то, вызываем parseUnaryMinus и возвращаем результат
- если текущий токен - знак плюс, то вызвыаем parseUnaryPlus и возвращаем результат
- сигнализируем об ошибке

Пример:

class Parser
{
...
function parseOperand(TokenStream $tokens)
{
$token = $tokens->peek();

if ($token->type == Token::TYPE_NUMBER) {
$tokens->consume();
return [new NumberNode($token), $tokens];
}

if ($token->value == "(") {
$tokens->consume("(");
list($node, $tokens) = $this->parseExpression($tokens);
$tokens->consume(")");
return [$node, $tokens];
}

if ($token->value == "-") {
return $this->parseUnaryExpression($tokens);
}

if ($this->value == "+") {
return $this->parseUnaryExpression($tokens);
}

$this->throwExpectedError("expected NUMBER, (, +, or -");
}

Мои правила предполагают, что узел может содержать не 2, а более детей. То есть для выражения "2 + 4 - 3" я создаю один узел SumNode с 3 детьми: 2, 4 и 3. Но это можно поменять и на узлы с 2 детьми, это не принципиально.

Я советую попробовать реализовать метод "рекурсивного спуска".

Если хочешь усложнить задачу, попробуй добавить в выражение: дроби (1/3), функции (sin(x)). Также, можешь попробовать сделать парсер какого-нибудь языка программирования, например, урезанной версии PHP, поддерживающей переменные, функции, конструкции if и for. Начать можешь с описания грамматики.

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

Потому для таких случаев придуманы генераторы парсеров. Довольно известный - ANTLR ( https://github.com/antlr/antlr4 ), он написан на Яве, но умеет генерировать парсеры на разных языках программирования. Для него, например, есть куча грамматик разных языков: https://github.com/antlr/grammars-v4.

Также, есть написанный на PHP PEG: https://github.com/hafriedlander/php-peg

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

>>35053 (OP)
Великовозрастный долбоёб и php с pdo;

Вопросы такие: Как правильно добавлять данные с формы в таблицу? Допустим форма регистрации. Не забивать же каждое поле в переменную? В массив, а потом этот массив запихивать в бд?

Как правильно упаковать запись в таблицу с помощью pdo? Есть два файла: index.php, pdo.php. В индексе, в шапке, инклуд файла pdo.php, и сама форма с кнопкой. В файле pdo.php - простой коннект к бд. Пишу корявый prepare вместе с bindParam (допустим без массива, а данные с поля - попадают в переменную) - нихуя не происходит. В то время как форма по загрузке файла, с добавлением в бд инфы по нему - рабочие. Что за магия?

try {
$dbh = new PDO('mysql:host = localhost;dbname = $dbname', $user, $pass, array(PDO::ATTR_PERSISTENT => false));
// само подключение

$addUsr = $dbh->prepare("INSERT INTO user (group, name, pass, salt, email) VALUES (:group, :name, :passwd, :salt, :email)");
$addUsr->bindParam(':group', $group);
$addUsr->bindParam(':name', $usrName);
$addUsr->bindParam(':passwd', $salted);
$addUsr->bindParam(':salt', $salt);
$addUsr->bindParam(':email', $email);
// подготовленное выражение

} catch (PDOException $e) {
print "Error!: " . $e->getMessage() . "<br/>";
die();
}
// закрываем трай

Допустим на подобном ублюдском примере с "значение поля = переменная". После условия формы, в индексе, стоит $addUsr->execute();

Ну и вариант "красивой" передачи, пожалуйста. Пробовал, кстати, $dbh->exec в начале скрипта, с болванистыми данными, которые должны забиваться при отработке скрипта, но ему похуй. В бд ничего не появляется. Как так, ёбаный в рот? Вопрошал в факе, но там всем настолько похуй, что нихуя вообще не написали.

Ребятки, есть вопрос по Доктрине!

Дано две таблицы mysql, их условная структура:

orders(
id,
created,
... // всякие обычные неинтересные поля
)

orders_properties(
id,
order_id,
param enum('height', 'weight', 'length', 'color'),
value varchar(100)
)

Получается между таблицами связь один-ко-многим: у каждого заказа может быть ни одного, одно или несколько свойств, которые указаны в поле param таблицы orders_properties. На мой взгляд, решение странное, но такая таблица уже есть, с ней ничего не сделать.

Как из этого сделать сущность Доктрины?

Типа такой:
class Order
{
private $id;
private $created;
private $height;
private $weight;
private $length;
private $color;
...
}

Чтобы оно обновлялось само и значения брались из orders_properties либо были пустыми, если там нужных нет.

Те способы, которые я нашел (например, http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/cookbook/mysql-enums.html) мою проблему, увы, не решают.

>>36317

Производительность при такой схеме с монтированием файлов не очень высокая может быть.

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

Вдобавок, если у тебя несколько проектов, то они могут требовать разные версии программ, а в линуксе (в отличие от виндоуз) поставить параллельно разные версии программ сложно - попробуй поставь без компилятора несколько версий PHP или mysql. (линуксоиды делают пакетный менеджер nix/guix, который должен решить эти и другие проблемы и вообще хорош, но им никто не пользуется).

В принципе, ничего плохого в этом нет. Мы ведь используем менеджер пакетов composer для указания зависимостей. Логично, что серверный софт вроде mysql или nginx это тоже зависимости приложения и их стоит описывать. Но почему для этого нужна целая виртуальная машина?

В моем понимании, хватило бы просто строчки в ридми apt-get install php mysql nginx. Не знаю, почему другие так не могут. Для моих проектов обычно этого хватает.

Мне все это не нравится, так как оно скорее всего тормозное, особенно на виндоуз. Требует много места на диске. Но может у тебя этих проблем не будет, а места предостаточно, кто знает.

Вагрант - позволяет настраивать виртуальную машину (virtual box) с помощью конфига на Руби. Обычно используется для описания среды для разработчика. При этом в конфиг можно включить установку в ВМ нужных программ. Про плюсы надо наверно читать документацию. Ну например, плюс то, что новый разработчик не должен мучаться с поиском и установкой программ, а просто выполняет одну команду и получает работающее окружение.

Как я понимаю, идея в том, что разработчик кладет в проект конфиг с описанием ВМ, а ты скачиваешь проект, запускаешь вагрант, он гудит пару часов и ты (если все хорошо и использованные пакеты не удалили из репозитория ОС) получаешь настроенную ОС в виртуалке, в которой проект 100% (а может и не 100) работает. Из минусов, как я понимаю, то, что там например может быть не тот дистрибутив, который тебе нравится, там может быть vi вместо нормального редактора, то есть все настроено не под тебя (как разработчик захотел, так и настроил). Плюс, виртуалка может работать медленно, занимать много места на диске. Ну например, вместо маленького дебиана кто-нибудь засунет туда многогигабайтный центос или десктопную убунту. Также, у тебя может быть например 3 Гб памяти, а кто-нибудь пропишет для виртуалки 2 Гб и она съест всю память.

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

Также докер упрощает взаимодействие контейнера с хостом - тебе не надо руками пробрасывать папки, TCP-соединения, он все это делает сам.

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

Из плюсов - там есть хранилище готовых образов (Docker Hub).

Минусы те же, что и у вагранта. Образ могут настроить не так, как тебе нравится (и скорее всего так и будет). Плюс, не знаю, как сейчас, а раньше демон докера работал из-под рута.

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

Докеру есть альтернатива - lxc. Это свободный инструмент для запуска линукс-контейнеров. Плюсы в том, что его пишут не хипстеры на Го, а серьезные дядьки из Интел и они не навязывают какие-то паттерны использования, минусы в том, что когда я его последний раз пробовал, там многие вещи не работали вообще. Ну и фич меньше чем у докера.

Ансибл - позволяет на основе конфига (они называются плейбуки) настраивать по SSH сервер или группу серверов, можно использовать для деплоя (когда серверов много), для настройки серверов. Ну например, админ может сделать плейбук "поставить nginx, php, postgres" и в одну команду сконфигурировать чистый сервер или несколько серверов вместо того, чтобы заходить на каждый и что-то там править руками.

Хотя мне он не нравится тем, что ему нужен inventory файл и нельзя просто IP сервера в командной строке указать. Плюс, не работает под виндой нормально и под cygwin. Я хотел сделать на его основе playbook, который разворачивает VPN на произвольной чистой машине, но из-за inventory это не удобно и я вернулся к bash скриптам, у которых конечно корявый синтаксис, но нет такой проблемы.

> Встречал в интернете упоминания о том, что на докере/вагранте разворачивают себе рабочее окружение и мне стало интересно насколько это будет удобнее (и будет ли)

Ну проверь.

>>36321

Я не очень понимаю, как что у тебя сделано, но конечно, тут надо использовать параметры роутов, чтобы был роут вроде /articles/{topic}/, то есть где раздел задан параметром. Контроллер смотрит на параметр и находит статьи из нужного раздела.

Если у тебя 2 уровня категорий, разделы и секции, то нужен еще роут /articles/{topic}/{section}/

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

Также, если я верно понял, у тебя несколько таблиц со статьями, это все дурь, и хватит одной таблицы статей. Плюс, таблица разделов и таблица секций. Но тут еще стоит подумать об объединении их в одну таблицу с деревом категорий. Так как интуиция мне подсказывает что это просто категории.

Ты, к сожалению, так описал вопрос, что я ничего не могу понять:

- Чем раздел отличается от секции.

> Например, при переходе к статьям articles_IT

Что такое "статьи articles_IT"? Название роута? Название категории статей?

>>36373

Твой вопрос какой-то странный. Давай лучше рассмотрим товары. Правильно было написать "Есть таблица товаров, товары разной категории, у них бывают разные свойства. В чем плюсы/минусы EAV в сравнении с просто добавлением полей в таблицу с товарами (single table)". И как разные варианты реализовать с помощью ORM.

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

Это называется "наследование таблиц", и там есть разные паттерны:

- http://design-pattern.ru/patterns/single-table-inheritance.html
- http://design-pattern.ru/patterns/concrete-table-inheritance.html
- http://design-pattern.ru/patterns/class-table-inheritance.html

То, что ты предлагаешь, добавлять колонки в одну таблицу - это как раз паттерн Single Table Inheritance.

Два других паттерна плохо работают для товаров, так как потребуют много таблиц, по числу категорий товаров. Тут-то на помощь и приходит EAV.

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

Сравниваем:

Плюсы EAV:

- в EAV новые свойства можно добавлять не меняя схему базы данных (не делая ALTER TABLE). Менеджер может делать это через админку, не привлекая программиста. В случае ORM, надо еще переделывать код при добавлении новых свойств.
- в схеме с single table (когда у нас есть одна таблица товара с кучей колонок), если свойств много, то колонок тоже будет очень много - сотни, и мы упремся в разные ограничения БД и потери производительности. В случае ORM, у нас еще будет гигантский класс с сотней полей, с которым неудобно работать.
- в single table, если свойств много, то большинство колонок будут хранить null и просто зря расходовать место
- в single table никак не определено, какие свойства могут быть у той или иной категории товара. В EAV это можно определить через связи.
- в single table для эффективного поиска надо создавать огромное число (десятки и сотни) индексов, что негативно скажется на производительности и требует кучу места

Минусы EAV:

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

Если появляются проблемы с поиском, то проще всего подключить поисковый демон вроде сфинкса, который будет держать внутри данные в денормализованном и удобном для поиска виде.

Если ты знаешь еще минусы, напиши. Но я смотрю на список плюсов/минусов и не понимаю, где выигрыш в использовании Single Table Inheritance.

> если у нас есть доп.таблица user_attributes(age, sex)

То не очень понятно, зачем она нужна и что мешает эти колонки сразу поместить в таблицу users. Не понятно, зачем вы городите EAV для таблицы пользователей, которые явно отличаются от товаров. Ради производительности?

> то мы сущности User (которая лежит в таблице users) можем задать поле $sex, которое по связи OneToOne будет ссылать на столбец sex из таблицы с аттрибутами.

Не можем. Мы не можем в одном классе замапить поле на колонку из другой таблицы. Мы можем только связать поле с другой сущностью (user_attributes).

> а если у таблицы структура users_attributes(param enum('age','sex'), value), то мы так сделать уже не можем.

Доктрина так не работает. Она мапит таблицы на классы так, что одна таблица обычно соответствует одному классу, а колонки в таблице - полям класса. Нельзя в один класс замапить колонки из разных таблиц.

Но это и не нужно. Ты в сущности User можешь получить атрибуты и найти в них то, что тебе нужно.

> можно было бы сказать, что так мы можем добавлять любое количество параметров без изменения таблицы, но это не так - все равно придется менять столбец param - добавлять в него разрешенные значения.

Это у вас не EAV. В EAV для разрешенных значений обычно делают таблицу.

> короче я не понимаю, в чем плюсы.

Скорее всего там у пользователя много атрибутов, большинство их не заполняет и им не хочется хранить NULL. Но вообще, почему так сделано, надо спрашивать у тех, кто это делал.

>>36406

> Допустим, я подобрал для сотен тысяч форму слова, отбросив по три цифры с концов, а на деле число оказалось миллиардом. Остальные шесть цифр не переведутся же.

Если тебе нужно число тысяч (от 0 до 999) то ты сначала берешь 6 последних цифр числа, потом отбрасываешь 3 последние цифры. И остается ровно 3 цифры, больше 1000 там никогда не получится.

Если тебе нужно число единиц, ты опять же, берешь только 3 последние цифры и больше 999 там не получится.

Плюс, в условии задачи вроде стоит ограничение, что число меньше миллиарда. То есть оно разбивается на 3 группы по 3 цифры каждая. Миллионы, тысячи и единицы. Можешь для надежности сделать 4 группы - добавить миллиарды.

>>36720

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

Иначе тебе придется делать полноценный планировщик запросов, который должен формировать SQL запросы, запросы к API и объединять их результаты. Попробуй написать выражение посложнее чем A AND B и ты увидишь, как там все запутанно.

Тебе надо формировать условие из того, что предлагает Query Builder, все эти $expr->equals(...).

>>36874

Какие именно символы? Вот, например, регулярка, которая ищет восклицательные и вопросительные знаки:

/[?!]/u

Это символьные классы: http://php.net/manual/ru/regexp.reference.character-classes.php

Или тебе надо искать "все символы из всех алфавитов мира"? для этого есть юникодные свойства: http://php.net/manual/ru/regexp.reference.unicode.php

Как пользоваться функцией str_getcsv(...)?

https://secure.php.net/manual/ru/function.str-getcsv.php

>enclosure

>Устанавливает символ ограничителя поля (только один символ).

Что такое ограничитель поля?

>escape

>Устанавливает экранирующий символ (только один символ). По умолчанию равен обратному слешу (\).

И от чего и что будет экранироваться?

Данные примерно в таком варианте

NAME
SOME_STRING = SOMEDATA
COLUMNS = something,another,somethinganother,...
1,135.02,135.09,133.25,133.47,33226223
2,135.51,136.27,134.62,135.52,35623100
3,135.345,135.9,134.8398,135.67,22584555

Нужно получить что-то вроде

[
"NAME",
"SOME_STRING" => "SOMEDATA",
"COLUMNS" => ["something", "another", "somethinganother", ...],

"DATA" => [[1, 135.02, 135.09, 133.25, 133.47, 33226223 ], [2, 135.51, 136.27, 134.62, 135.52, 35623100], [3, 135.345, 135.9, 134.8398, 135.67, 22584555]]
]

Текущих знаний мне хватает чтобы спарсить каждую строчку с помощью str_getcsv($s, "\n"), и затем вручную преобразовать массив с помощью регулярных выражений
Это лучший способ и данная функция не предусматривает лучших решений?

>>38863

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

Вот тут немного описано это: https://github.com/codedokode/pasta/blob/master/student-list.md#Выносим-код-за-корень-сервера

>>38698

Какие-то простые вещи сверстать или поправить существующую верстку - конечно. Кстати, в ОП посте есть набор задач по HTML/CSS, после прохождения которого как раз будет нужный уровень.

>>38215

Тебе нужен preg_replace_callback либо preg_replace с массивом слов и замен. Посмотри мануал по этим функциям.

>>38456

Давай посмотрим на код. Вот у меня ощущение, что ты там некоторые вещи писал не осознанно, а просто наугад, в надежде что заработает. Так не надо делать, сейчас ты учишься и у тебя главная цель не решить задачу как можно быстрее, а разобраться в материале.

Для начала можно попробовать написать алгоритм словами (используя только простые команды, не допускающие двойного толкования). Команд у нас в распоряжении всего несколько:

$x = ... - создает переменную или меняет значение существующей
echo ... - выводит строки и числа, в том числе переменные
if (условие) { действия } - выполняет действия, если выполняется условие
for (...) { ... } - выполняет одни и те же действия много раз в цикле
break - немедленно выходит из цикла

Если ты забыл эти команды, перечитай предыдущие уроки или мануал PHP.

Если мы посмотрим на твой код, то мы увидим там куски, которые не имеют никакого смысла, например:

($rubley < 1000000);

Эта строчка проверяет, меньше ли $rubley чем указанная сумма, но с результатом проверки ничего не делает - она не сохраняет результат в переменную и не использует его в конструкции if. То есть она бесполезна.

Далее, если мы посмотрим сюда, то увидим другую ошибку:

$rubley = ($seychas * $procent) + $rubley;

Здесь справа использована переменная $seychas, но на момент выполнения команды такой переменной еще не существует. Строчка, которая ее создает, расположена ниже.

Ну и непонятно вообще, зачем тут для обозначения суммы на счете используется 2 разных переменных.

То есть выглядит, увы, не как осознанно написанный код.

Вернемся к алгоритму. Как бы его записать, используя только перечисленные выше команды? Ну например, так:

------

пусть суммаНаСчету равна 10000;
пусть процент равен 1.1;

меняем возраст вкладчика от 16 до 108 лет с шагом 1 год, выполняя каждый год {

увеличить суммуНаСчету на процент;

если (на счету миллион или больше) {
выйти из цикла;
}

увеличить возраст вкладчика;
}

вывести ответ к задаче;

------

Ну а дальше надо переписать это с помощью команд выше.

Вообще, тут ключевое место алгоритма еще можно записать по-другому, более красиво:

пока (на счету меньше миллиона) {
увеличить сумму на счету;
увеличить возраст на 1;
}

Но как эту конструкцию "пока" перевести в код? Тут есть такой вариант:

for (; $sum < 1000000 ;) {
...
}

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

while ($sum < 1000000) {
тело цикла выполняется до тех пор, пока условие вверху выполняется;
}

Подробнее: http://php.net/manual/ru/control-structures.while.php

Также, перечитай внимательно условие задачи и убедись, что твоя программа выводит все, что требуется.

Если что-то непонятно, задавай вопросы.

>>41356

Для начала, а ты смотрел мою статью по тестированию? https://gist.github.com/codedokode/a455bde7d0748c0a351a

Дальше, ты должен решить, что и как ты будешь тестировать. Для этого мы берем каждый класс (или группу классов, работающих вместе) и определяем требования к ним. Что они должны уметь делать? Каждое требование будет проверяться тестом. Затем придумываем, как это требование проверить (тут может потребоваться смекалка) и пишем код тестов.

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

Но обычно сценарии тестов строятся по схеме "Дано - Если - То". Ну например, "ЕСТЬ пустая база данных, ЕСЛИ вызвать метод подсчета числа записей в ней, ТО он вернет ноль".

Сценарии бывают позитивные и негативные, позитивные проверяют, что при правильных входных данных функция работает, а негативные проверяют ее поведение при неправильных входных данных.

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

Рассмотрим пример составления сценария тестирования.

Например, у тебя есть класс для сохранения и получения объектов из БД. Какие к нему есть требования? Ну очевидно, первое что в голову приходит:

- маппер должен уметь сохранять объект в БД
- маппер должен уметь загружать объект из БД

дальше там могут быть дополнительные требования вроде "маппер должен присваивать id создаваемым объектам", "маппер должен уметь считать число объектов в БД", это ты должен наверно знать, из описания не ясно.

Как проверить требования выше? Тут могут быть разные идеи. Например:

- загрузить в базу данных дамп с известными сущностями
- попробовать загрузить одну из них
- проверить, что данные загруженные данные соответствуют ожидаемым

А можно чуть схитрить и проверить обе функции сразу:

- сделать пустую БД
- вызвать функцию вставки сущности в БД
- вызвать функцию загрузки сущности из БД
- проверить, что данные вернулись корректные

Как-то так.

Помни еще, что тесты должны быть независимы и не полагаться на очередность вызова, или на то, что другой тест вообще будет вызван.