ВС
Но закидывать такое железом - не вариант. Идеологически неверно и дорого
Size: a a a
2020 November 21
РА
Но закидывать такое железом - не вариант. Идеологически неверно и дорого
ну один раз большой объем только спарсить, а дальше можно и в один поток уже.
T🐜
Может быть, кто знает) 178.214.249.24 - глянь, нет ли с этого адреса запросов)))
Ха ха, есть 11 запросов. Не парсил значит, просто смотрел :D
ВС
ну один раз большой объем только спарсить, а дальше можно и в один поток уже.
А если в другой раз понадобится снова парсить, только объём будет уже раза в 2-3 больше, а сроки ещё меньше? Чё делать будешь?
ВС
Вполне такое допускаю, когда речь идёт про исходные данные и их перегонку.
T🐜
Вон че )
РА
А если в другой раз понадобится снова парсить, только объём будет уже раза в 2-3 больше, а сроки ещё меньше? Чё делать будешь?
Ну я согласен. Буду искать решение. Селениум - вариант для ленивых,
ДЩ
Правильно делать так, чтобы модуль / компонент был весь в одной директории. Чтобы можно было взять директорию и переместить в другое место, не опасаясь, что где-то ещё остались классы / файлы этого модуля / компонента.
ну дак это само собой, каждый в своей папке, перенести в другое место не опасаясь это все по умолчанию
вопрос именно в наименовании классов, просто у каждого модуля есть
Config.php
Validator.php
OneRecord.php
и т.д.
в варианте 1 (он сейчас) имеет место толпа подсказок при вводе
вопрос именно в наименовании классов, просто у каждого модуля есть
Config.php
Validator.php
OneRecord.php
и т.д.
в варианте 1 (он сейчас) имеет место толпа подсказок при вводе
Validator отличающихся по вышестоящему каталогу имени модуля... что наверно не есть хорошо... или пофиг?ВС
ну дак это само собой, каждый в своей папке, перенести в другое место не опасаясь это все по умолчанию
вопрос именно в наименовании классов, просто у каждого модуля есть
Config.php
Validator.php
OneRecord.php
и т.д.
в варианте 1 (он сейчас) имеет место толпа подсказок при вводе
вопрос именно в наименовании классов, просто у каждого модуля есть
Config.php
Validator.php
OneRecord.php
и т.д.
в варианте 1 (он сейчас) имеет место толпа подсказок при вводе
Validator отличающихся по вышестоящему каталогу имени модуля... что наверно не есть хорошо... или пофиг?Я так понял, при вводе отображаются подсказки модулей и из соседних неймспейсов?
ДЩ
Я так понял, при вводе отображаются подсказки модулей и из соседних неймспейсов?
да
ВС
В любом случае, вариант 2 мне не кажется привлекательным. Больше проблем с ним в угоду решения некорректному резолву IDE. Я бы попробовал понять причину такого поведения, возможно, кинул бы issue в посонов.
ДЩ
В любом случае, вариант 2 мне не кажется привлекательным. Больше проблем с ним в угоду решения некорректному резолву IDE. Я бы попробовал понять причину такого поведения, возможно, кинул бы issue в посонов.
ВС
А если начинать выражение не с названия метода, а с вызова конкретного инстанца? Такого уже не будет?
ДЩ
В любом случае, вариант 2 мне не кажется привлекательным. Больше проблем с ним в угоду решения некорректному резолву IDE. Я бы попробовал понять причину такого поведения, возможно, кинул бы issue в посонов.
да нее IDE тут ни при чем, если бы я начинал писать класс с его начала то кучи вариантов и не было бы
ВС
Ну тогда вообще не вижу проблемы
ВС
Тут нужно оценить, удобно ли будет вам поддерживать все эти неймспейсы во всех наименованиях классов и вызовах. Как мне кажется, нет.
ДЩ
не ну понятно если начинать от корня то проблемы не будет, но как-то непривычно что ли
https://i114.fastpic.ru/big/2020/1121/99/fffd39a8e5e513441ebd03063930ab99.jpg
https://i114.fastpic.ru/big/2020/1121/99/fffd39a8e5e513441ebd03063930ab99.jpg
S
Тут нужно оценить, удобно ли будет вам поддерживать все эти неймспейсы во всех наименованиях классов и вызовах. Как мне кажется, нет.
psr4