Денис Бондарь

Зачем нужна таблица маршрутизации?

Для того чтобы указывать маршрут, как бы удивительно это не звучало.
Маршрут это путь следование, указание куда идти.
Вот например подходите вы к человеку на улице и спрашиваете его как дойти до института изящных искуссты.. Человек не в курсе где расположен этот институт, поэтому он достает из своей таблицы маршрутизации маршрут по умолчанию и озвучивает его вам - Идите на х...

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

Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.100 20

Всем участвующим в беседе доброго времени суток!
Зарегистрировался исключительно из-за данного поста.
Небольшое лирическое отступление: работаю в support регионального isp, в связи с чем приходится постоянно общаться с подобными всезнающими геймерами.
Поскольку предварительно я почитал ответы автора сабжа на некоторые комментарии аудитории, то отвечать постараюсь максимально доступным языком.

morfianes
Согласно предоставленной тобой лично трассировке winmtr (по хопам):
1. твой роутер;
2. какой-то неизвестный провайдерский хост, предположительно, закрытый по icmp;
3. очередной хост на сети твоего провайдера (возможно, промежуточный коммутатор или иное, предположительно, активное сетевое оборудование);
4. gateway твоего провайдера, с которого тебе непосредственно предоставляется доступ во-вне (в интернет) - на этом ЗО (зона ответственности) твоего провайдера ВСЕ!!!
Вот, лять, прямо вообще ВСЕ, от слова СОВСЕМ!!!
5. ЗО вышестоящего оператора!!!
и т.д.

Ты молодец!! Красава!! Ресспектую!!
Нагуглил, а может и в Яндексе поискал и нашел, 2ip.ru на котором "пробил" принадлежность проблемного, по твоему мнению, ipшника, а именно 94.25.8.129, и, казалось бы, вот ОНО!!!
Ipшник находится в адресном пространстве, принадлежащем твоему провайдеру, но...
Правильно - ничего!!!
Вот, лять, прямо вообще НИЧЕГО!!! От слова СОВСЕМ!!!

Тот, факт, что, согласно нарытым тобой данным, ipшник принадлежит Ростелекому, ну, т.е. твоему провайдеру, вообще ни о чем не свидетельствует.
Как правильно заметил support Ростелекома, о чем и тебе сообщил, ты даже скриншот с перепиской скинул, но головой подумать дальше видимо чего-то не хватило.

Согласно данным whois, ресурс с этим ipшником находится в сети Prestig_Internet.
Ничего не смущает, не?!

А теперь так же банально, как ты 2ip.ru разыскивал, берем и гуглим, ну Яндексом пользуемся, (тебе что удобнее??) Prestig_Internet и первой ссылкой, по каким-то причинам, enforta.ru.
Немного странно, конечно, но и к этому вскоре подойдем.

Чуть ниже в результатах поиска, хотя... не утруждайся - прикладываю ссылку: https://www.list-org.com/company/704092
Сам же ты все равно не найдешь.
Переходим по ссылке, читаем и, о Боже!!, выясняем для себя следующее:
- Организация ООО "ПРЕСТИЖ-ИНТЕРНЕТ"... наверное имеет прямое отношение к сети Prestig_Internet, по крайней мере это вполне логично предположить.

По всей видимости у ООО "ПРЕСТИЖ-ИНТЕРНЕТ" в свое время не хватило адресной емкости, в связи с чем у Ростелеком, да-да, именно у твоего провайдера, просто напросто был куплен ipшник.
Вот так просто!!! Взяли и купили у Ростелеком ipшник, прикинь, ля!!!
Однако, полагаю, что данный ipшник Ростелеком просто взял и "зажал", т.е. данный адрес не является PI, т.е. провайдеро-независимым, но это ты потом загуглишь, ну или в Яндексе найдешь.
По факту расторжения договорных отношений между ООО "ПРЕСТИЖ-ИНТЕРНЕТ" и Ростелеком его (ipшник), скорее всего, придется вернуть.

Читаем далее:
- Статус: ПРЕКРАЩЕНИЕ ДЕЯТЕЛЬНОСТИ ЮРИДИЧЕСКОГО ЛИЦА ПУТЕМ РЕОРГАНИЗАЦИИ В ФОРМЕ ПРИСОЕДИНЕНИЯ с 01 ноября 2017 года.

И тут, казалось бы, все мои доводы рухнули, разлетелись в пух и прах, но... х... ты угадал!!
Листаем ниже!!
- Правопреемники: АО "ЭР-Телеком Холдинг" (брэнды Дом.ру и Энфорта, если, вдруг, ты не в курсе).
Теперь более понятно, при чем тут Энфорта. Если все еще не понятно - читай далее.

Таким образом получаем следующее:
- ipшник принадлежит Ростелеком, ибо он не является PI (предположительно);
- железо, которое работает на этом ipшнике, принадлежит АО "ЭР-Телеком Холдинг" - на основании данных list-org.com;
- какие отношения в разрезе данного ip адреса между Ростелеком и АО "ЭР-Телеком Холдинг" мне вот прям до звезды фиолетово.

Могу осмелиться предположить, что маршрутизация от тебя, а по факту от твоего роутера 192.168.0.1 (D-Link, наверное), до конечного ресурса, а именно 162.249.73.10, который, как бы, тоже нихрена не у тебя под боком находится, строится по принципу OSPF... а может BGP... а может... (да, простят и поправят, в случае ошибки, коллеги по цеху).
Что такое OSPF/BGP потом загуглишь, ну или в Яндексе найдешь.
Если не найдешь, привлекай Rambler к содействию.
Конечно, мои предположения к фактически используемой маршрутизации на сети твоего провайдера, а так же точкам обмена трафика с другими операторами связи, остаются только предположениями, но... если... вдруг...

Итого:
- 212.48.195.0 - граница ЗО твоего провайдера (Вот, лять, прямо вообще КОНЕЦ!!! От слова СОВСЕМ!!!), с этого момента Ростелеком тебе должен/обязан (читай, как больше нравится) чуть меньше, чем ни...чего;
- ресурс 94.25.8.129 фактически принадлежит АО "ЭР-Телеком Холдинг", несмотря на то, что ipшник находится в адресном пространстве Ростелеком, контакты ЭР-Телеком найдешь, тут уже совсем все изи;
- менять маршрут ради тебя одного такого пи...дельного никто не станет - хлопотно;
- почитай/ознакомься: https://habr.com/ru/post/134892/ - доступным для понимания языком написано;

P.S. уж слишком дохрена вас таких... "интересных", платят 500рэ за 100М, а голову выделывают...

Можно для каждого значения сделать вес, можете сделать так, чтобы сумма все х весов была 100,
но не обязательно — это могут быть произвольные значения. Главное, что доля веса от суммы всех весов — будет вероятностью данного элемента.

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

Обновление от 13.06.2020:
Так вышло, что мой тимлид математик и нашел интересное и эффективное решение этой задачи

<?php

$values = [
    ['value' => 'One', 'weight' => 20],
    ['value' => 'Two', 'weight' => 30],
    ['value' => 'Three', 'weight' => 50]
];

function randByWeight(array $arr) {
    $max = 0;
    $result = [];
    foreach($arr as $value) {
        $rand = pow((mt_rand() / (mt_getrandmax() + 1)), 1/$value['weight']);
        if ($rand > $max) {
            $max = $rand;
            $result = $value;
        }
    } 

    return $result;
}

// Например: 'Three' выпадет в 50% случаев, тк его вес -- половина от суммы всех весов
// Например: 'Two' выпадет в 30% случаев, тк его вес -- 30% от суммы всех весов
var_dump(randByWeight($values));

sandbox.onlinephpfunctions.com/code/39de2d54a298de...

Чем хорошо это решение — его можно использовать прямо в SQL запросе!

SELECT * FROM table ORDER BY POWER(random(), 1/weight) DESC LIMIT 1

Классическое решение:

<?php

$values = [
    ['value' => 'One', 'weight' => 20],
    ['value' => 'Two', 'weight' => 30],
    ['value' => 'Three', 'weight' => 50]
];

function randByWeight(array $items) {
    $sum = array_reduce($items, function(int $acc, array $item): int {
        return $acc += $item['weight'];
    }, 0);
    
    $rand = (mt_rand() / (mt_getrandmax() + 1)) * $sum;

    foreach($items as $item) {
        if($rand < $item['weight']) {
            return $item;
        }
        
        $rand -= $item['weight'];
    }
}

// Например: 'Three' выпадет в 50% случаев, тк его вес -- половина от суммы всех весов
// Например: 'Two' выпадет в 30% случаев, тк его вес -- 30% от суммы всех весов
var_dump(randByWeight($values));

sandbox.onlinephpfunctions.com/code/aee9dca651213e...

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

Хотя ответ очень простой и первый вопрос автора даёт очень простую подсказку.

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

То есть к самому приложению, если подумать, отношения не имеет.

И из понимания этого простого факта становится ясно, зачем нужен контроллер - в нем и происходит это самое соединение. Веб запросы транслируются в обращения к модели. А ответ модели - в красивые веб странички, в чем помогает Вью

При этом модель - это не убогий интерфейс к таблице в бд, как думают все попугаи. А собственно все приложение и есть. Это ещё называется бизнес-логикой.

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

Ответ с картинками и видео с ютюбе https://qna.habr.com/answer?answer_id=1475989#answ...

Как обычно
код = число1+База*(число2+База*число3)
База в твоем случае 30-1+1=30
расшифровка
Число3 = код mod База^2
Число2 = (код - Число3 * База^2) mod База
Число1 = код - Число3 * База^2 - Число2 * База

Смотря зачем)). Я когда делаю Code Review критерии следующие:

* Безопасность:
- Каждый аргумент метода простого типа должен проверяться на тип в случае его проксирования и на граничные значения в случае обработки. Чуть что не так - бросается исключение. Если метод с кучкой аргументов на 80% состоит из поверки из аргументов - это вполне норм))
- Никаких trigger_error, только исключения.
- Исключения ДОЛЖНЫ быть человеко-понятны, всякие "Something went wrong" можно отдавать пользователю, но в лог должно попасть исключение со стектрейсом и человеко-понятным описанием, что же там пошло не так.
- Каждый аргумент (объект) метода должен быть с тайпхинтингом на этот его класс, или интерфейс.
- За eval как правило шлю на **й.
- @ допускается только в безвыходных ситуациях, например проверка json_last_error.
- Перед работой с БД - обязательная проверка данных.
- Никаких == и !=. Со swtich - единственное исключение, по ситуации.
- Если метод возвращает не только bool, а еще что-то - жесткая проверка с ===, или !== обязательна.
- Никаких условий с присваиваниями внутри. while($row = ...) - тоже идет лесом.
- Магические геттеры/сеттеры разрешаются только в безвыходных ситуациях, в остальном - запрещены.
- Конкатенации в sql - только в безвыходных ситуациях.
- Параметры в sql - ТОЛЬКО через плейсхолдеры.
- Никаких глобальных переменных.
- Даты в виде строки разрешаются только в шаблонах и в БД, в пхп коде сразу преобразуется в \DateTimeImmutable (в безвыходных ситуациях разрешено \DateTime)
- Конечно зависит от проекта, но как приавло должно быть всего две точки входа: index.php для web и console(или как-то по другому назваться) - для консоли.

* Кодстайл PSR-2 + PSR-5 как минимум, + еще куча более жестких требований (для начала все то что в PSR помечено как SHOULD - становится MUST)
- В PhpStorm ни одна строчка не должна подсвечиваться (исключением является typo ошибки, например словарик не знает какой-то из аббревиатур, принятых в вашем проекте). При этом разрешается использовать /** @noinspection *** */ для безвыходных ситуаций.
- Если кто-то говорит, что пишет в другом редакторе и у него не подсвечивается, на эти отговорки кладется ВОТ ТАКЕЕЕНЫЙ мужской половой **й и отправляется на доработку)).

* Организация кода:
- Никаких глобальных функций.
- Классы без неймспейса разрешаются только в исключительно безвыходных ситуациях.

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

* Принципы MVC:
- Никаких обработок пользовательского ввода в моделях, от слова совсем.
- Никаких ***ть запросов в БД из шаблонов.
- Никаких верстки/js/css/sql-ин в контроллерах.
- В моделях НИКАКОЙ МАГИИ, только приватные свойства + геттеры с сеттерами.
- В моделях разрешено использовать метод save(при наличии такого разумеется) только в исключительных ситуациях. Во всех остальных - либо insert, либо update.

* Принципы SOLD:
- Никаких божественных объектов умеющих во все.
- Если метод для внутреннего пользования - private, никаких public.
- Статические методы разрешаются только в случае безвыходности.

* Принцип DRY разрешено нарушать в случаях:
- Явного разделения обязанностей
- В тестах (каждый тест должен быть независимым, на сколько это возможно)

* Работа с БД:
- Запрос в цикле должен быть РЕАЛЬНО обоснован.
- За ORDER BY RAND() - шлю на***й.
- Поиск не по ключам (конечно если таблица НЕ на 5 строк) запрещен.
- Поиск без LIMIT (опять же если таблица НЕ на 5 строк) запрещен.
- SELECT * - запрещен.
- Денормализация БД должна быть обоснована.
- MyISAM не используется (так уж)) )
- Множественные операции обязательно в транзакции, с откатом если чо пошло не так.
- БД не должна содержать бизнес логики, только данные в целостном виде.
- Не должно быть нецелесообразного дерганья БД там, где без этого можно обойтись.

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

* О людях:
- "Я привык писать так и буду дальше" - не вопрос, ревью пройдешь только когда поменяешь свое мнение.
- "Я пишу в vim-е и мне так удобно" - здорово, код консолью я тоже в нем пишу)) но есть требования к коду, если в них не сможешь - не пройдешь ревью.
- "Я скопировал этот страшный метод и поменял 2 строчки" - это конечно замечательно, но по блейму автор всего этого метода ты, так что давай без говняшек, хорошо?
- "Оно же работает!" - вот эта фраза переводится примерно так: "да, я понимаю, что пишу полную хрень, но не могу писать нормально потому, что руки из жо", я правильно тебя понял?))
- "У меня все работает!" - рад за тебя, а как на счет продакшна?
- "Там все просто" - не используй слово "просто", от слова "совсем". Вот тебе кусок кода (первого попавшегося с сложной бизнес логикой), где там ошибка (не важно есть она, или нет)? Ты смотришь его уже 2 минуты, в чем проблема, там же все "просто"))

* Всякое:
ActiveRecord (это я вам как в прошлом фанат Yii говорю) - полное говно, примите за исходную. По факту у вас бесконтрольно по проекту гуляют модельки с подключением к БД. Не раз натыкался на то, что в тех же шаблонах вызывают save, или update (за такое надо сжигать).
То, что используется Laravel - это печально((. Что бы выполнить требования приведенные выше, приходится "воевать" с фреймворком.

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

UPD

Формализировал данные критерии по ссылочке: https://github.com/index0h/php-conventions

vagrant

Во-первых: начните изучать архитектурную часть программирования, изучите паттерны проектирования, изучите SOLID, DRY, KISS и остальные модные словечки, постарайтесь всё это осознать, или, на крайняк - зазубрить. Всё придет с опытом, изначально все не понимали зачем всё так сложно, но эта сложность обусловлена неисчислимыми литрами слёз и потраченных нервов, всё не просто так.

Судя по всему это тестовое или учебное задание. От вас требовалось отоверинжинирить простую задачу. Давайте попробуем:

Суть задачи - есть файл с определенной структурой хранения данных, структура строковая. Требуется этот файл преобразовать в другую структуру данных и вывести эту структуру в json формате. Задача ясна.

Разобъем задачу на отдельные независимые этапы:
1) Преобразование одной структуры данных (текстового файла) в другую (объект, понятный PHP, к примеру)
2) Преобразование этой структуры данных в Json формат.
Первый вопрос, который может возникнуть - почему сразу не преобразовать в json? Ответ - при расширении системы в будущем - нам понадобится вывести данные в виде массива, или в виде XML, или даже в виде готового файла Excel. Нам будет сложно дополнять логику изначального класса, ничего при этом не сломав и не затронув уже существующий функционал. Также ответом на этот вопрос может являться каждая буква из SOLID принципов, подробнее отвечу дальше, когда буду пояснять за реализацию, см. ниже

Теперь рассмотрим эту задачу с точки зрения ООП, начнем думать не от конкретной реализации, а от интерфейса и абстракции (мы не парсим конкретный файл, мы парсим просто файл, мы не переводим его в конкретное представление json, мы переводим его просто в представление):
Нам понадобится 2 класса - непосредственно класс, читающий файл и преобразующий его в простейший тип данных (например PHP array). Второй класс - преобразователь простейшего типа данных парсера в какой-то определенный тип:

1. LogFileReaded implements/extends FileReaderContract(интерфейс, возможно абстрактный класс, если понадобится предустановленная логика)
   
   Непосредственно наш преобразователь (не забываем, что передавать путь к файлу и все настройки нужно из вне, к примеру, в конструктор. Нельзя, как вы - хардкодить всё внутрь файла, на крайний случай - можно использовать конфигурацию), на ввод получает файл определенного типа с определенной известной структурой, на выходе выдает информацию из файла, преобразованную в базовый тип (массив, в нашем случае). Если нам когда-то понадобится парсить другой тип данных или структура данных будет изменена - мы сможем написать отдельный класс для этой логики, а не рушить целостность уже работающего кода, добавляя туда новую логику. Запомните - нужно стремиться не менять, а дополнять.
   
   
2. JsonPresenter implements/extends DataTypePresenterContract
   
   Абстракция содержит контракт на метод output(), а в конструкторе принимются исходные данные. В конкретной реализации JsonPresenter в output() будет банальный json_encode() (да, это нормально, нет, класс не лишний и нет, json_encode() нельзя пихать в сам парсер) А теперь к вопросу - почему не следует просто запихать это всё в парсер и вместо массива отдать json: в будущем, когда система будет расширяться - нам понадобится представить данные в виде XML - что тогда будем делать - переписывать весь код парсера ради добавления switch case "json" и т.д.? А если что-то сломается во всей системе? А если вариантов представления станет настолько много, что файл будет просто не читаем? А при данном подходе достаточно будет просто написать новый класс XMLPresenter, или даже ExcelPresenter, который на выводе не строку будет выдавать, а целый файл (опустим типизацию output пока)). Также этот класс можно реализовать в виде декоратора (паттерн), да и много еще как.
   
   

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

К примеру: в итоге, если вас уже повысили, и вы вместо парсинга стали заниматься более высшими материями - новому программисту, чтобы дописать логику преобразования данных в Excel не нужно знать как конкретно вы преобразовывали когда-то эти данные в json, ему не нужно дебажить ваш код, ему достаточно посмотреть на интерфейс - отнаследоваться от него и написать свой собственный метод преобразования и дальше использовать его в нужном месте.

P.S. В данной реализации опускаются и упрощаются некоторые моменты для понятности

https://habr.com/post/326880/

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

Если они не могут привести никаких внятных доводов, кроме "мне так нравится" и "в крутой компании Х это используют" - то забейте на их мнение.

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

См. NATS.
Куда как меньше админовского/девопского геморра.

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

1) Если очередь будет создана сервером, то auto-delete не будет работать, если клиент не подпишется на неё.
2) Не забывайте, что если два клиента (например, две вкладки или две сессии одного пользователя) подключатся к одной очереди, то сообщение получит только один из них. В своих решениях я использовал подход, что очередь создавалась клиентом, а обменник сервером, но необходимо убедиться, что до RabbitMQ доходят только легитимные запросы (от авторизованных клиентов) и пользователь ограничен в правах создавать только нужные очереди и подписывать их на нужные обменники.
3) Рекомендовал бы не выставлять порт web-stomp плагина без доп.защиты (например, HAProxy), которая позволит защитить RabbitMQ от перегрузки подключениями.

P.S. Писал статью на Хабр год назад о подобной системе, может быть что-то будет интересное в ней ещё - https://habr.com/post/341068/

Создавать очереди должен только бэкенд (PHP). Он же выдает уникальные ID (например, session_id или md5) клиенту. Далее клиент подключается к ранее созданной очереди с этим ID.

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

P.S. Логин/пароль на клиенте нет смысла использовать, ибо он все легко равно перехватывается.

Вы сконцентрировались на попытке сделать ваше решение БД-ориентированным, в то время как вас не просили этого делать. Из за БД-ориентированности в вашем коде происходят странные вещи, можно сказать "магия". Некоторые вещи вообще странные, вроде списка статей внутри статьи.
Вас просили сделать описания классов, методов и свойств класса в формате PhpDoc, а вы этого не сделали.

Попробуйте ещё раз, но со следующими ограничениями:

• В классе User оставьте только свойство $name и свойство $articlesList = [] - который будет уже списком статей, которые написал автор. Пусть список храниться внутри объекта пользователя, в ORM типа Doctrine так и происходит. Уберите оттуда $id.
  
• Не забудьте добавить методы getName() и setName($newName) для работы со свойством name. Это является правильным для ООП - не позволять клиентам класса работать со свойствами напрямую, а лишь вызывая методы, которые вы предоставляете. Причина проста - в методе вы можете указать какое-нибудь дополнительное поведение, которое требуется при изменении свойства.
  
• Также придумайте методы, необходимые для работы со списком статей. Ну вот два уже напрашивается из задания: "возможность для автора создать новую статью" и "возможность получить все статьи конкретного пользователя". Но по хорошему статью ещё и удалить можно...
  
• Для статьи вам понадобятся 2 поля - это ссылка на автора (то есть сам объект класса User, а не магический id). То есть $author, и ещё, раз это статья, то ей неплохо бы добавить свойство $text.
  
• А теперь главное - не пишите вообще текста методов. Только открыли фигурные скобки и сразу закройте на следующей строке. От вас этого не просили. И даже явно указали этого не делать!
  

Если всё ещё сомневаетесь, то советую почитать обучалку по Doctrine. Там они постепенно создают совершенно коректные с точки зрения ООП классы User и Bug. (они это делают последовательно, так что не поленитесь докрутить до самого конца обучалки)

Вообще мимо.

Для начала надо сделать код рабочим. Некоторые вещи вроде class Article() { ... } и function find_by_user($user_id == nuul) написаны с ошибками.

Потом читаем про конструкторы, про private/protected/public, забываем про var.