Flat |
Отправлено: 8 июля 2018 — 11:18
|
Full Member
Покинул форум
Сообщений всего: 187
Дата рег-ции: Май 2018
Откуда: Красноярский край
Репутация: 14
|
Добавлю. Это я сделаю сам, тут делов на пол часа.
Сейчас курю тему "Перспективы дальнейшего развития". Там yura3d сказал такую фразу: "Перспективы файловой версии - раз и навсегда кануть в лету. Это случится рано или поздно, более того, это уже сейчас происходит. "
Он там усиленно продавливал тему изменения базы данных с файлов последовательного доступа к файлам прямого доступа, как в СУБД. И говорил, что это раз в 50 ускоряет работу форума.
Я согласен с ним, что ускоряет, тем более, что сам написал и тестировал функцию бинарного поиска по файловой базе прямого доступа, и скорость оказалась просто КОСМИЧЕСКОЙ)). А ведь можно сделать и прямую выборку.. Но всё это сильно усложнит двиг форума.
Но я не согласен, с yura3d в том, что исчерпан потенциал данного движка.
Не исчерпан. Просто не там искали..
Например: зачем качать всю тему целиком, если мы выводим всего например два десятка сообщений? Это имеет смысл делать если мы осуществляем поиск по теме. А в обычном случае этого не требуется. И если тема разрастётся, то скорость форума упадёт. Хотя, я тестил: 4 мегабайтная тема грузится у меня за 0,2 сек.
Например: мы можем делить тему на несколько отдельных файлов, тогда загрузка страниц будет линейной константой..
Можно упростить форум сделав его с постоянным числом сообщений на страницу, зато скорость будет приличной.
Конечно можно оставить и в этом случае выбор за пользователем, хотя логика работы форума несколько усложнится.
Малое количество сообщений на страницу тоже плохо, так как пользователь всё равно просматривает предыдущие страницы если тема имеет большой процент новых сообщений. Тогда можно сделать 50 сообщений на страницу либо константой либо оставить выбор пользователям. Или сделать например по 100 сообщений на файл, тогда, к тому же, нагрузка на сервер уменьшится и количество файлов будет приемлемым.
Как считаете? Для меня важно мнение простых и не простых пользователей.(Отредактировано автором: 8 июля 2018 — 11:38) |
|
|
Flat |
Отправлено: 10 июля 2018 — 09:01
|
Full Member
Покинул форум
Сообщений всего: 187
Дата рег-ции: Май 2018
Откуда: Красноярский край
Репутация: 14
|
"Все ушли на фронт" по своим делам, и вернутся не скоро.. Хорошо, буду писать свои соображения в этой теме на будущее.
-----------
Вчера реализовал и протестил две функции работы с файлами. Это для инфо по делам текущим.
------------
По мере знакомства с кодом возникают некоторые мысли и соображения, которыми хочется поделиться с заинтересованной публикой. Критика уместна в любом случае, ибо позволяет найти правильный путь и исправить ошибки, так что не принимайте близко к сердцу.Итак приступим.
1) В своё время форум был переведён на ООП рельсы. Извините, но ООП там и не пахнет. Всего один класс, в который напихали всего-всего, кучу-малу. Нет даже элементарных протектед, паблик.. Об остальном можно умолчать. ООП там - это одно название.
Да и вообще оно там не было нужно, ибо только замедляет работу скрипта. Никаких плюшек в данном конкретном коде нет и видимо не предвидится. Использование пространств имён, наоборот, имело бы определённый смысл, особенно при модульной организации кода.
2)Из рук вон плохо поддерживается модульность, коей, по большому счёту вообще не видно.
3)Папка members содержит файлы с некоторой информацией о пользователях. Другая информация о данных пользователях разбросана по другим папкам. Например те же аватарки и т.п. Имело бы смысл каждому пользователю дать отдельную папку и сбрасывать туда все файлы которые его касаются.
4)В скрипте используются сессии. Сессии полезны, например в том случае, если пользователь отключил куки. В этом случае при входе на сайт он будет залогинен пока есть сессия, то есть, пока не закрыт его браузер.
Теперь попробуйте заблокировать куки с данного форума, и вы увидите, что при попытке захода на форум не происходит авторизации. Это серьёзное упущение. Тогда зачем нужны сессии? Детство какое-то..
5)В куках сохраняется хэш пароля. Так лучше не делать. В куки надо сохранять рэндомный токен, который обновляется при каждом заходе на сайт.
Пока всё.(Отредактировано автором: 10 июля 2018 — 09:30) |
|
|
Flat |
Отправлено: 10 июля 2018 — 13:47
|
Full Member
Покинул форум
Сообщений всего: 187
Дата рег-ции: Май 2018
Откуда: Красноярский край
Репутация: 14
|
6) Шаблоны.
Свалены в одну папку. Чтобы понять код приходится постоянно лазить по разным папкам, что сильно утомляет. Может быть вообще отказаться от шаблонов. В FluxBB их нет, и код намного легче воспринимается на глаз и более понятен.
7)Языки.
Универсализация, в расчёте, что кто-то(а кто - один два чел.?) когда-то(в 22 веке)захочет сделать свой форум на суахили, приводит к тому, что код становится абсолютно не читаем. А чтобы понять что же здесь в данном конкретном месте выводится приходится лопатить не один десяток файлов. А там поди найди, ибо этих файлов целая куча. Если форум позиционируется как форум для русскоязычного сообщества, то нужно отказаться от языковых алиасов. У зарубежных товарищей существуют десятки форумов, которыми они и пользуются, а вот зачем ради мнимой универсализации усложнять жизнь админам, вообще не представляю. О вкусах не спорят..
Тут я высказываю то, что хотел бы видеть в своём собственном форуме.
Когда понимаешь что придётся переделывать почти всё, то это будет уже другой форум, хотя местами и с включением старого кода..
В общем, exbb является крайне не дружелюбен к простым админам, что необходимо срочно исправлять. К сожалению его эволюция почему-то двигается по пути усложнения кода. Код должен быть простой и ясный, только тогда он будет безопасен. Без выкрутасов, типа, "я и так ещё могу". Да я могу круче, но не буду из принципа.(Отредактировано автором: 10 июля 2018 — 13:52) |
|
|
|
Отправлено: 10 июля 2018 — 23:18
|
Покинул форум
Сообщений всего: 0
Дата рег-ции: N/A
Репутация: 0
|
1Bot пишет:нет описания интерфейсов взаимодействия ядра и модуля Я бы сказал что нет такой концепции. Многие дополнения позиционируются как модули но настолько жёстко вшиты в ядро, что по сути модулями не являются. Хотя справедливости ради стоит сказать, что Юра пытался это дело стандартизировать. В его модулях прослеживается структура.
(Добавление)
1Bot пишет: тогда в функции сохранения можно использовать любой из этих форматов данных Я слышал, что в последних версиях PHP грозились запретить использование сокращённой конструкции <? |
|
|
Flat |
Отправлено: 11 июля 2018 — 11:27
|
Full Member
Покинул форум
Сообщений всего: 187
Дата рег-ции: Май 2018
Откуда: Красноярский край
Репутация: 14
|
Yamaliya пишет:Надо бы предусмотреть конвертер туда и обратно.
Согласен. Просто прежде чем говорить о конвертере, необходимо сначала создать новый двиг.
Yamaliya пишет:двумя руками ЗА.
Всё, значит так и будет.
1Bot пишет:тогда в функции сохранения можно использовать любой из этих форматов данных.
Там ещё надо будет предусмотреть правильный разбор формата. Вот рабочие функции по новой базе, черновой вариант, но рабочий, кому интересно. Я не профессиональный программист, а программист-любитель, который любит копаться в чужом коде и старается писать по крайней мере не хуже приличий, так что не пеняйте, если что:
Пример кода (Отобразить)CODE:function read($filename)
{
if (!file_exists($filename))
{
return array();
}
$fp = @fopen($filename,'rb') or die('Could not read from the file <b>'.$filename.'</b>');
flock($fp, LOCK_SH);
$filesize = filesize($filename);
if($filesize<=8)return array();
$filesize =$filesize-8;
fseek($fp,8);
$str = fread($fp,$filesize);
flock($fp, LOCK_UN);
fclose($fp);
$str=eval($str);
if(isset($arr))return $arr;
return array();
}
function write($arr,$path)
{
$tmpName=randTmpName();//чтобы избежать конфликта процессов
$filename=dirname($path).'/'.$tmpName.'.dat';
$fp = fopen($filename,'wb') or die('Could not create the file <b>'.$filename.'</b>');
flock ($fp,LOCK_EX);
$buf='$arr=';
$buf.=var_export($arr, TRUE); $buf.=';';
$len=strlen($buf)+8;
if (fwrite($fp,'<?phpdie;?>'.$buf) === FALSE)
{
sleep(1);//подождём и попробуем ещё раз
if (fwrite($fp,'<?phpdie;?>'.$buf) === FALSE)
exit('Системный сбой при попытке записи во временный файл базы данных!');
}
fflush($fp);
if(filesize($filename)!=$len)exit('Системный сбой при попытке записи во временный файл базы данных!');
$name=basename($path);
unlink($path);
flock ($fp,LOCK_UN);
fclose($fp);
rename($filename, dirname($path).'/'.$name);
return;
}
function randTmpName()
{
$a = array('a','b','c','d','e','f','g','h','i','j','k','l','m','n','o','p','r','s','t','u','v','x','y','z','A','B','C','D','E','F','G','H','I','J','K','L','M','N','O','P','R','S','T','U','V','X','Y','Z','1','2','3','4','5','6','7','8','9','0');
$p= "";
for($i = 0; $i < 8; $i++)
{
$in = rand(0, count($a) - 1);
$p .= $a[$in];
}
return $p;
}
1Bot пишет:не забывайте, что основной код был написан еще для PHP4 и лишь немного видоизменен для работы с PHP5 на уровне "чтобы не возникало фатальных ошибок
Я прекрасно всё понимаю. Также прекрасно вижу откуда растут ноги многих функций. Первоначальный автор форума, Александр Субханкулов, использовал код IPB форума. И, кстати, правильно делал, ибо зачем городить велосипед если есть хорошие рабочие решения, жизнь-то одна.
Потом, уже после него, форум был изменён, хотя структура осталась практически прежней.
1Bot пишет:Сейчас же есть возможности как раз использовать средства ООП из новых версий PHP7 и по возможности убирать таким образом функциональные повторы в существующем коде.
Так что полный отказ от ООП будет скорее ошибкой.
Этим и занимается, насколько я понял, ув. WebMaster . Посмотрел код последней версии, там действительно ООП несколько улучшен. Вот эту ветку и следует продолжать делать в том же духе. Это, так сказать, старая песня о главном, и пусть она будет, кому нужно. Мне - нет.. Я хочу иного..
ООП ведь это всего лишь попытка эмулировать модульность, а её можно эмулировать и без ООП, хотя в PHP на это есть определённые ограничения.
1Bot пишет:Каждый модуль вполне себе может быть отдельным сколь угодно сложным объектом, который взаимодействует с классом ядра форума и реализует заданный интерфейс модуля, а также использует все возможности ядра.
Это самое сложное: понять как всё будет функционировать на всех уровнях; каким образом ДОЛЖНО быть устройство модульного движка. Чтобы и безопасность повысить и чтобы он был понятен и прост. Я постоянно об этом думаю. И уже сложилась определённая картина..
1) На самом верхнем уровне находится файл index.php. Это - головной модуль. Через него происходит вся работа. Его задача: инициализировать данные, авторизовать пользователя, провести валидацию имен существующих модулей в системе с именем того модуля, который приходит с запросом пользователя и подключать эти модули. Он ничего не выводит пользователю, а только выполняет эту черновую работу. Валидация имён позволяет легко обеспечить высокую безопасность движка, по принципу: свой - свой. Валидация ключей и значений возлагается на модули верхнего уровня, ибо только они сами знают "своих подопечных".
2) Модули верхнего уровня это: вывод главной страницы, регистрация и пр.
3)Модули нижнего уровня работают через подключение в модулях второго уровня.
Таким образом осуществляется строгая иерархическая система, которая легко понятна. Есть головной модуль, первого уровня, который знает о существовании модулей второго уровня, а модули второго уровня знают о существовании модулей своих подопечных.
В коде всё станет понятней что где и как. Так мне это представляется, и я начал уже потихоньку это осуществлять.(Отредактировано автором: 11 июля 2018 — 11:31) |
|
|
|