Хм. Не знаю, где вы усмотрели такую суть. Ни в коем случае не пытался относить свои суждения к объективным научным знаниям, или сделать математические формулы свойствами физических фотонов. Просто увидел в статье похожий принцип и предположил, как это может быть реализовано на низком уровне, без привлечения магии типа «оно само». Примерно как раньше люди возможное строение атома обсуждали. Хотел для интереса узнать примеры, подтверждающие или опровергающие эту гипотезу. Ну да ладно.
Я и предположил, как может быть реализован этот математический процесс на физическом уровне. Не «оно само случайно выбирается», а некоторый равномерный колебательный процесс, случайность в измерениях которого появляется благодаря наблюдению в произвольный момент времени.
Эту статью я читал, там только общие слова без подробностей. И противоречий с такими предположениями я не нашел.
Если развить мысль дальше, то возможно, потенциальная мощность квантовых вычислений как-то связана с этими высокочастотными процессами. То есть, их можно рассматривать как аналог перебора на высокой скорости всех возможных вариантов в обычных вычислениях. Если я где-то не прав, буду признателен за конкретные примеры.
Ну так, насколько я понимаю, в этом и есть особенность квантовой спутанности — измерение состояния одной частицы влияет на результат измерения состояния второй, даже если они разнесены за пределы известных взаимодействий.
Вы, похоже, знакомы с предметом, можете поподробнее рассказать? Из того, что я знаю о теореме Белла, не вижу каких-то противоречий. Я же не утверждаю, что спин заранее задан, я предполагаю, что есть некоторый процесс, при остановке которого спин фиксируется. То есть, случайность есть, теория вероятности работает, но источник случайности — действия наблюдателя.
При нажатии на кнопку, на индикаторе высвечивается случайное число. В чем же тут случайность, откуда она берется? Сразу раскрою секрет. Цифры генерируются по порядку: 0, потом 1, 2, и так далее. Хитрость вот в чем: очень высокая частота импульсов. Они выдаются так быстро, что цифры сливаются в одну на индикаторе. И совершенно невозможно угадать цифру!
Немного не в тему, но при чтении статей про квантовую неопределенность у меня возникали похожие мысли. То есть вот имеется фотон с неизвестным спином, и этот спин не то чтобы неопределен и появляется в момент наблюдения, а просто меняется очень быстро, или может не он сам, а какие-то связанные с ним параметры, то есть присутствуют какие-то высокочастотные колебания. И в момент наблюдения просто фиксируется текущее значение спина, колебания прекращаются, и повторное измерение дает то же значение. Так вроде и случайность присутствует, и магии особой нет. Но я не настолько разбираюсь в физике, чтобы понять, насколько эти мысли правильные.
Играю в игры в основном из-за сюжета. Если случайно узнал, что у какой-то игры неинтересная концовка, то и желание играть в нее пропадает. Есть игры, в которых важнее процесс, NFS например. Но какой смысл придумывать мир, атмосферу и сюжет, чтобы все закончилось просто и уныло, чтобы после прохождения возник вопрос — ну и зачем все это было надо?
Решили рассказать историю, так надо чтобы история была интересной. А иначе зачем в ней участвовать?
Тоже извиняюсь за задержку.
Вижу, вы уже сами сделали алгоритм и в БД и в приложении. Так как тут нас интересует скорость отдачи контента, а не читаемость, то пожалуй тогда не буду переписывать код на ORM. Просто покажу, как можно ускорить показ результатов — добавить внешнюю систему кэширования Memcached. Понятно, что в базе тоже можно настроить кэширование, но кэшироваться будут результаты отдельных запросов, а в случае с get_client_price() можно запоминать готовый результат всех расчетов.
Итак, вначале на моей машине были такие показатели:
Per page: 500
Номер документа: 20515
Список из app: 0.96 — 1.02
Список из DB: 0.34 — 0.36
После добавления кэширования:
Список из app: 1.16 — 1.20 (первый вызов)
Список из app: 0.04 — 0.08 (последующие вызовы)
Это потребовало добавления нескольких строчек без особого изменения остального кода (коммит на github). Там кеширование на 10 секунд, в зависимости от характера изменений в таблицах можно сделать на большее время, или постоянно с инвалидацией кеша при внесении изменений.
Размещение логики в коде дает больше возможностей, как по описанию этой логики, так и по управлению данными.
Похоже изобретатель ларавел написал исполняемый файл (для каждой ОС отдельный)
Строка запуска «php /path/to/artisan schedule:run» намекает на то, что это PHP скрипт, а не бинарный файл. Соответвенно, он один для всех ОС. И он есть в исходниках фреймворка на github.
а две Closore
Closure это один из способов. In addition to scheduling Closure calls, you may also schedule Artisan commands and operating system commands.
Крон раз в минуту запускает исполн. файл (условно artisan.exe), который запустил крон-файл пользователя, создал реестр запусков и потом в отдельном потоке запуcкает наши Closure-крон-задачи пользователя (или примерно так). Все довольно сложно
Не знаю, почему вы так решили. Я с этим фреймворком не работал, но насколько я понял из документации, крон запускает скрипт планировщика, в планировщике запускается функция Kernel::schedule(), где написано расписание задач, нужные задачи запускаются. Closure выполняются в том же процессе, команды запускаются в отдельных процессах (не потоках). Все просто и логично.
Вся эта сложность и надежность artisan
проверена тысячами пользователей фреймворка в разных проектах.
Вы так и не поняли, похоже. В указанном планировщике есть возможность сделать несколько задач. Одна строчка в кроне запускает не задачу, а планировщик. Чтобы падение одной задачи не влияло на другие, они выделяются в отдельные команды. Каждая команда запускается в отдельном процессе. Форкать вручную ничего не надо, планировщик запускает процессы сам. Пользователю нужно указать только одну строчку на каждую команду. 2 команды значит 2 строчки. Pthreads и его ограничения здесь ни при чем, вам просто указали, что количество способов запустить в PHP 2 задачи одновременно больше 0.
Еще бывает, когда есть сразу 2 файла ABC и abc. Висит один измененный файл, через stash не убирается, ни merge ни rebase не сделать. Исправить можно, если отключить в реестре флаг obcaseinsensitive, примонтировать диск в cygwin с опцией posix=1, и сделать git reset --hard в git, установленном из репозиториев cygwin.
Скачал. Регистрации нет. Через админку пользователя добавить нельзя. Пароли хранятся в открытом виде. После логина ссылка «ROOT» в меню не работает, выводятся 2 ошибки, «Controller `c_user::` or method `default_c::c_user()` not exist» и «View file `view/_sample.php` not exist». Проверка доступа находится в представлениях. CMS часть не работает, как фреймворк систему использовать сложно, по причинам, уже описанным в других комментариях.
Код шаблона админки:
<?php defined('START') or die;
# For Licence and Disclaimer of this code, see http://coresky.net/license
$err = $out = $refresh = '';
$sky->head();
$top_html = '<!doctype html><html><head>' . ob_get_clean();
$top_html .= css(".active {background: #91d0c0 !important}") . '</head><body style="margin-top:0">';
define('zebra', 'return @$i++ % 2 ? \'bgcolor="#eee"\' : "";');
define('button', '<a href="?%2$s" class="admin-btn%3$s">%1$s</a>');
if (!$user->adm_allowed): echo 'Not permited';
elseif (2 == $user->auth):
...
Для сравнения, фреймворк Yii2.
Шаблон проекта ставится одной командой, многофункциональный компонент для работы с пользователями еще одной. После установки все работает. Из коробки есть UI в стиле Bootstrap и механизм управления любыми скриптами и стилями, меню, пагинация, многоязычность и многосайтовость. Проверка доступа находится в контроллерах. Шаблонов страницы можно иметь несколько для разных разделов и менять в рантайме.
Код основного шаблона страницы:
<?php
/* @var $this \yii\web\View */
/* @var $content string */
use yii\helpers\Html;
use yii\bootstrap\Nav;
use yii\bootstrap\NavBar;
use yii\widgets\Breadcrumbs;
use frontend\assets\AppAsset;
use common\widgets\Alert;
AppAsset::register($this);
?>
<?php $this->beginPage() ?>
<!DOCTYPE html>
<html lang="<?= Yii::$app->language ?>">
<head>
<meta charset="<?= Yii::$app->charset ?>">
<meta name="viewport" content="width=device-width, initial-scale=1">
<?= Html::csrfMetaTags() ?>
<title><?= Html::encode($this->title) ?></title>
<?php $this->head() ?>
</head>
<body>
...
Имхо, многие проблемы происходят от того, что представление данных используется как модель. Календарная система или часовой пояс это параметры представления некоторого момента во времени. При работе с разными представлениями нужно приводить их к какому-то общему виду. Unixtime это хорошая идея, но високосные секунды немного ломают картину.
Мне кажется, было бы неплохо сделать более глобальную систему отсчета, например SST (Solar System Time), в которой значение будет увеличиваться на 1 каждую атомную секунду независимо от вращения Земли. Начальное значение установить в примерный возраст Солнечной системы. Все электронные системы могли бы вести отсчет именно в ней. Для всех событий прошлого или будущего можно задать точный момент на этой шкале. Для конвертации в земное время и обратно необходима таблица високосных секунд и часовой пояс, ну и григорианский календарь по умолчанию. Таким образом, будет универсальная однозначная неубывающая система отсчета времени.
Нет никакого кода для автоэкранирования в коде фреймворка, данные не склеиваются с запросом в одну строку. Запрос передается отдельно, данные отдельно. Смотрите примеры использования PDO::prepare.
Даже если вы не будете использовать PDO, а добавите автоэкранирование всех параметров запроса, на выполнение этих «лишних» вызовов уйдет гораздо меньше времени, чем на прием-передачу данных из БД через сетевое соединение. Вы пытаетесь экономить на спичках.
И претензии к вашему фреймворку связаны не только с экранированием, так что на чаше весов здесь гораздо больше критериев.
Помнится, в универе через HIEW писал в бинарном файле загрузчик на asm и делал разметку первичных разделов, через dd заливал его на флешку, и все работало. Еще как-то научил FreeDOS грузиться со 2 раздела на 40-гигабайтном диске, стандартный загрузчик не воспринимал большие номера секторов, поменял номер прерывания для чтения сектора и связанный с ним код загрузки параметров. Сейчас правда уже забыл, как все это работает, да оно и не нужно.
FreeDOS + AUTOEXEC.BAT + grub4dos. Остановился на таком варианте. Не надо форматировать флешку и конвертировать образы, свободное место используется по прямому назначению для хранения любых файлов. Ubuntu грузится из ISO образа, установщик Windows можно скопировать поверх существующих файлов, варианты загрузки редактируются через menu.lst или в интерактивном режиме во время запуска.
Ну вот есть ваш фреймворк, в котором надо писать экранирование, циклы, и следить за количеством полей, и есть другой фреймворк, где ничего этого делать не надо. В соответствии с принципом KISS нужно выбрать другой фреймворк. Поэтому люди вас и критикуют, а вернее, пытаются объяснить, в чем вы не правы, а не потому что они не вникли в суть и не захотели понять ваши высокие цели.
Это вы, видимо, с разработкой больших приложений не сталкивались. Там и под 50 бывает, и с наследованием таблиц, причем одновременно редактируется как минимум половина. Информация к размышлению: как вы думаете, сколько параметров может быть у обычной городской квартиры?
В коде у меня, как ни странно, нет ни циклов, ни escape(). Проще не придумаешь.
нет никакой кучи потенциальных SQL инъекций, зачем врать? Приведите хоть 1 пример реальный…
«Потенциальная SQL инъекция» означает, что сейчас инъекции нет, но при некоторых условиях она может появиться. Пример я вам привел: меняем регулярное выражение для соответствия RFC — появляется инъекция в запросе.
Да, экранировать надо вручную, это принцип KISS
В запрос передаются 10 значений. Можно 10 раз вызывать escape(), можно 10 раз не вызывать escape(). Минус 80 символов, как минимум. Мне непонятно, почему более громоздкий вариант это по-вашему проще.
Если у вас сложности с экранированием вручную, вы не будете способны написать нормальное веб-приложение, даже если фреймворк даст вам функции-методы, где авто-экранирование.
Почему это? Кстати, раз уж зашел разговор, написанные вами веб-приложения можно где-то посмотреть?
У меня сложная архитектура?
Не сложная, а запутанная и, соответственно, сложная для понимания. Архитектура у вас как раз простая, и это тоже показатель — то, что вы простую архитектуру записали сложным и малопонятным кодом.
настолько сложно, что вы не можете понять работу функции?
Смысл не в том, что ее нельзя понять, а в том, что для понимания ее работы надо залезть в реализацию. А для понимания работы системы в целом надо залезть в реализацию всех функций, потому что а вдруг там тоже магические константы.
Прочитайте книжку Макконнелла, если еще не читали. А если читали, то задумайтесь, почему программисты считают ее хорошей.
Вы предлагаете не использовать PDO и именованные параметры, а экранировать данные вручную.
У вас в коде куча потенциальных SQL-инъекций.
if (sql("+select count(1) from users where email='$data[email]'$or")) return 3;
Email перед этим проверяется регуляркой. Вы в курсе, что одиночная кавычка в email это разрешенный символ? Кто-нибудь решит привести вашу регулярку в соответствие с RFC, и в запросе появится уязвимость.
Вы предлагаете писать в полупроцедурном стиле с eval() и глобальными объектами. При этом некоторые процедуры с какими-то скрытыми хаками.
Вы предлагаете другим разбираться, поддерживать и развивать ваш код с кучей сокращений и запутанной архитектурой. Все вот эти global $UA, $PVAL, $s_crypt, $p_mem; $this->idc; $this->gpc; $this->qn;. А что означают $sky->s_c_manda и $sky->s_j_manda я даже думать не хочу.
Я считаю, что информация объективно существует, так как у нее есть свои законы, и ее могут обрабатывать компьютеры, то есть устройства, не обладающие сознанием.
У меня сложилось такое мнение, что информация показывает взаимосвязь между чем-либо — связь между одной палочкой и одной овечкой в стаде, между 10 палочками и 10 камнями, между объектом и словом, его обозначающим. 1 бит информации при подбрасывании монетки — это связь между фактом совершения события и его результатом (одним из 2 возможных).
Понятие наблюдателя связано с датчиками, которыми производится наблюдение. Понятие объекта появляется при повторяющейся корелляции (т.е. взаимосвязи) сигналов с датчиков (например, рецепторов сетчатки). Для определения наличия взаимосвязи нужно состояние отсутствия взаимосвязи, т.е. некоторая двоичная система.
Определение смысла информации — определение контекста и установление взаимосвязи между входными данными и знакомым понятием в этом контексте. В более глобальном смысле, думаю, можно сказать, что восприятие информации — это моделирование внешних событий с помощью внутренних понятий. Обучение — это создание новых понятий и установка связей с существующими.
Эту статью я читал, там только общие слова без подробностей. И противоречий с такими предположениями я не нашел.
Если развить мысль дальше, то возможно, потенциальная мощность квантовых вычислений как-то связана с этими высокочастотными процессами. То есть, их можно рассматривать как аналог перебора на высокой скорости всех возможных вариантов в обычных вычислениях. Если я где-то не прав, буду признателен за конкретные примеры.
Немного не в тему, но при чтении статей про квантовую неопределенность у меня возникали похожие мысли. То есть вот имеется фотон с неизвестным спином, и этот спин не то чтобы неопределен и появляется в момент наблюдения, а просто меняется очень быстро, или может не он сам, а какие-то связанные с ним параметры, то есть присутствуют какие-то высокочастотные колебания. И в момент наблюдения просто фиксируется текущее значение спина, колебания прекращаются, и повторное измерение дает то же значение. Так вроде и случайность присутствует, и магии особой нет. Но я не настолько разбираюсь в физике, чтобы понять, насколько эти мысли правильные.
Решили рассказать историю, так надо чтобы история была интересной. А иначе зачем в ней участвовать?
Вижу, вы уже сами сделали алгоритм и в БД и в приложении. Так как тут нас интересует скорость отдачи контента, а не читаемость, то пожалуй тогда не буду переписывать код на ORM. Просто покажу, как можно ускорить показ результатов — добавить внешнюю систему кэширования Memcached. Понятно, что в базе тоже можно настроить кэширование, но кэшироваться будут результаты отдельных запросов, а в случае с get_client_price() можно запоминать готовый результат всех расчетов.
Итак, вначале на моей машине были такие показатели:
Per page: 500
Номер документа: 20515
Список из app: 0.96 — 1.02
Список из DB: 0.34 — 0.36
После добавления кэширования:
Список из app: 1.16 — 1.20 (первый вызов)
Список из app: 0.04 — 0.08 (последующие вызовы)
Это потребовало добавления нескольких строчек без особого изменения остального кода (коммит на github). Там кеширование на 10 секунд, в зависимости от характера изменений в таблицах можно сделать на большее время, или постоянно с инвалидацией кеша при внесении изменений.
Размещение логики в коде дает больше возможностей, как по описанию этой логики, так и по управлению данными.
Строка запуска «php /path/to/artisan schedule:run» намекает на то, что это PHP скрипт, а не бинарный файл. Соответвенно, он один для всех ОС. И он есть в исходниках фреймворка на github.
Closure это один из способов. In addition to scheduling Closure calls, you may also schedule Artisan commands and operating system commands.
Не знаю, почему вы так решили. Я с этим фреймворком не работал, но насколько я понял из документации, крон запускает скрипт планировщика, в планировщике запускается функция Kernel::schedule(), где написано расписание задач, нужные задачи запускаются. Closure выполняются в том же процессе, команды запускаются в отдельных процессах (не потоках). Все просто и логично.
проверена тысячами пользователей фреймворка в разных проектах.
Код шаблона админки:
Для сравнения, фреймворк Yii2.
Шаблон проекта ставится одной командой, многофункциональный компонент для работы с пользователями еще одной. После установки все работает. Из коробки есть UI в стиле Bootstrap и механизм управления любыми скриптами и стилями, меню, пагинация, многоязычность и многосайтовость. Проверка доступа находится в контроллерах. Шаблонов страницы можно иметь несколько для разных разделов и менять в рантайме.
Код основного шаблона страницы:
Мне кажется, было бы неплохо сделать более глобальную систему отсчета, например SST (Solar System Time), в которой значение будет увеличиваться на 1 каждую атомную секунду независимо от вращения Земли. Начальное значение установить в примерный возраст Солнечной системы. Все электронные системы могли бы вести отсчет именно в ней. Для всех событий прошлого или будущего можно задать точный момент на этой шкале. Для конвертации в земное время и обратно необходима таблица високосных секунд и часовой пояс, ну и григорианский календарь по умолчанию. Таким образом, будет универсальная однозначная неубывающая система отсчета времени.
Даже если вы не будете использовать PDO, а добавите автоэкранирование всех параметров запроса, на выполнение этих «лишних» вызовов уйдет гораздо меньше времени, чем на прием-передачу данных из БД через сетевое соединение. Вы пытаетесь экономить на спичках.
И претензии к вашему фреймворку связаны не только с экранированием, так что на чаше весов здесь гораздо больше критериев.
В коде у меня, как ни странно, нет ни циклов, ни escape(). Проще не придумаешь.
«Потенциальная SQL инъекция» означает, что сейчас инъекции нет, но при некоторых условиях она может появиться. Пример я вам привел: меняем регулярное выражение для соответствия RFC — появляется инъекция в запросе.
В запрос передаются 10 значений. Можно 10 раз вызывать escape(), можно 10 раз не вызывать escape(). Минус 80 символов, как минимум. Мне непонятно, почему более громоздкий вариант это по-вашему проще.
Почему это? Кстати, раз уж зашел разговор, написанные вами веб-приложения можно где-то посмотреть?
Не сложная, а запутанная и, соответственно, сложная для понимания. Архитектура у вас как раз простая, и это тоже показатель — то, что вы простую архитектуру записали сложным и малопонятным кодом.
Смысл не в том, что ее нельзя понять, а в том, что для понимания ее работы надо залезть в реализацию. А для понимания работы системы в целом надо залезть в реализацию всех функций, потому что а вдруг там тоже магические константы.
Прочитайте книжку Макконнелла, если еще не читали. А если читали, то задумайтесь, почему программисты считают ее хорошей.
Вы предлагаете не использовать PDO и именованные параметры, а экранировать данные вручную.
У вас в коде куча потенциальных SQL-инъекций.
Email перед этим проверяется регуляркой. Вы в курсе, что одиночная кавычка в email это разрешенный символ? Кто-нибудь решит привести вашу регулярку в соответствие с RFC, и в запросе появится уязвимость.
Вы предлагаете писать в полупроцедурном стиле с eval() и глобальными объектами. При этом некоторые процедуры с какими-то скрытыми хаками.
Вы предлагаете другим разбираться, поддерживать и развивать ваш код с кучей сокращений и запутанной архитектурой. Все вот эти
global $UA, $PVAL, $s_crypt, $p_mem; $this->idc; $this->gpc; $this->qn;. А что означают$sky->s_c_mandaи$sky->s_j_mandaя даже думать не хочу.Это правильный путь? Нет уж, спасибо.
У меня сложилось такое мнение, что информация показывает взаимосвязь между чем-либо — связь между одной палочкой и одной овечкой в стаде, между 10 палочками и 10 камнями, между объектом и словом, его обозначающим. 1 бит информации при подбрасывании монетки — это связь между фактом совершения события и его результатом (одним из 2 возможных).
Понятие наблюдателя связано с датчиками, которыми производится наблюдение. Понятие объекта появляется при повторяющейся корелляции (т.е. взаимосвязи) сигналов с датчиков (например, рецепторов сетчатки). Для определения наличия взаимосвязи нужно состояние отсутствия взаимосвязи, т.е. некоторая двоичная система.
Определение смысла информации — определение контекста и установление взаимосвязи между входными данными и знакомым понятием в этом контексте. В более глобальном смысле, думаю, можно сказать, что восприятие информации — это моделирование внешних событий с помощью внутренних понятий. Обучение — это создание новых понятий и установка связей с существующими.