только что вот считать оригинальным описанием?
то что написано в rfc? RFC 2313, RFC 2437, RFC 3447 в каком именно?
или первая его оригинальная публикация в научных журналах ?
только вот в этих документах нет ничего конкретного по реализации (кроме математических формул) потому что парадигм программирования очень много:
Императивное программирование
1.1. ООП
1.2. Процедурное и тд
Декларативное программироваине
2.1. Функциональное и тд
Вы будете искать rfc описывающее rsa в рамках ООП или ФП? таких нет, потому что rfc это описание и оно не привязано к реализации (парадигме или языку программирования), а как вы будете делать реализацию и в рамках какой парадигмы, зависит от вас и возможно от языка программирования что будете использовать (глупо например используя java писать в фп парадигме или использовать haskell и писать в ооп)
Даже если вы выберете ООП то тут есть еще куча вопрос:
mutable или immutable ?
stateless или statefull ?
То о чем вы говорите (о разрыве знакомого многим и лишними абстракциями) называется "связанность", что код должен отражать предметную область с которой он работает.
Только вот проблема в том что на вики выложен пример реализации в виде псевдо кода или какой нибудь наиболее наглядный пример на популярном языке, например в ФП не принято использовать циклы и вместо циклов бы тут использовали array map и реализация была бы совсем другой (в вики нет примера алгоритма флойда в рамках ФП).
Поэтому я согласен с тем что код должен быть сильно связан с предметной областью с которой он работает, но я не согласен с тем что есть одна и только одна каноническая реализация алгоритма, как минимум один и тот же алгоритм может выглядеть по разному в разных парадигмах программирования, также могут применяться разные оптимизации для повышения производительности и тд,
так вопрос разделения действий очень относительный.
вот например взять тот же алгоритм флойда и пхп, там есть операция +, если я выйду за пределы int во время этой операции?
Для работы с большими числами есть bc math или gmp, но это же алгоритм флойда надо ли их использовать, мне кажется да (если можно за пределы int уйти) но вы говорите что алгоритм флойда это то неделимое и надо смотреть на всю картину в целом, давайте тогда и работу с большими числами реализуем внутри циклов, как тогда будет выглядеть алгоритм без вспомогательных функций (методов) для работы с большими числами ?
по поводу изображений пример не корректен, если было так как вы говорите то в редакторах не было бы zoom (ведь удобней смотреть на все изображение без приближений вы так написали), поэтому пример с изображениями как раз и говорит что иногда один элемент (изображение) состоит из множества разных элементов (пикселей и векторов, ведь внезапно бывает еще и векторная графика), но мы не задумываемся о этих деталях когда смотрим на изображение пока нет в этом необходимости.
а как по вашему должен выглядеть алгоритм rsa со всеми основными вещами (decrypt, encrypt, sign, verify, createkey причем не разбивая на отдельные функции)
а также работу с BigInt тоже не выносить отдельно это же цельное, там ниже задал вопрос, но не вам к сожалению, поэтому и тут продублировал, а и еще постарайтесь сделать поменьше строк, "это очень важно".
вот сразу как открываешь подобный файл и видишь родные $i, $j, $n прям сразу ясно становиться что за алгоритм
прям каждый день сниться когда все это в одной функции будет не разделено на вспомогательные вещи, прям сразу ясно что это RSA, а не DSA
теперь запишите его как вы говорили все в одну функцию, да да да decrypt, encrypt, sign, verify, createkey пусть там на входе массив будет и сказан тип операции что надо сделать и разные ключи с параметрами
я вам даже начну
<?php function rsa(array $params) { return ;/* тут надо его просто расчитать в зависимости от параметров и да я специально все в одну строку пишу, чтобы строки сэкономить это же так важно */}
и теперь ответьте честно будет выглядеть проще?
есть GodObject, но похоже можно еще создавать GodFunction или GodMethod, не знал о последних двух, спасибо что помогли их понять еще раз.
исходный вариант 4 строки которые в примере это на самом деле, + 1 строка на функцию + 2 строки на скобки этой функции(в psr открывающая с новой строки) + 1 строка закрывающая скобка для каждого цикла (итого 3) + 1 строка на return
итого получаем 4 полезных строки размазанные по еще 7 строкам получаем 11 входных строк.
но даже учитывая 11 строк можно считать что он выглядит не сложно, но это не значит что так как я написал делать нельзя.
Но работа программиста это не писать максимально короткие программы, а писать софт который потом можно поддерживать потому что имея 11 строк я могу довольно много чего придумать так чтобы потом это было читать и понимать тяжело, поэтому мы не строками меримся, а пишем софт который потом поддерживать и большая часть времени читать.
Для примера цитата про "алгоритм установки gentoo" http://bash.im/quote/394695 если вам нравиться подобное в коде, то у всех свои вкусы и каждый вправе иметь свои взгляды.
по поводу разбивать на части то что цельное, вы когда запрос к бд посылаете вы ручками создаете сокет, подключаетесь к бд и посылаете запрос или все таки разделяете на уровень по работе с бд и потому что генерирует запросы?
ото алгоритм работы с бд можно назвать и это:
Создать подключение
Аутедентификация + авторизация
выбрать бд
цикл по запросам для бд
как бы тоже 4 строки, не надо все под одну гребенку нести.
а то что я разбил исходный текст на 3 метода это потому что у алгоритма 3 уровня отступов
так как php используется в вебе то такое решение вполне сойдет
<?php
class Floid
{
private $w;
public function __construct(array $w, int $n)
{
// если нужно проверяем данные
$this->w = $w;
$this->n = $n;
}
public function getResult()
{
for ($k = 1; $k <= $this->n; $k++) {
$this->forByI($k);
}
return $this->w;
}
private function forByI($k)
{
for ($i = 1; $i <= $this->n; $i++) {
$this->calc($k, $i);
}
}
private function calc($k, $i)
{
for ($j = 1; $j <= $this->n; $j++) {
$this->w[$i][$j] = min(
$this->w[$i][$j],
$this->w[$i][$k] + $this->w[$k][$j]
);
}
}
}
если мы будем говорить об оптимизации производительности, потребление памяти, скорости и тд первое что стоит начать делать это взять компилируемый язык чтобы не терять время интерпретации, причем я ничего против пхп не имею в свое нише он дает достаточную производительность.
ах да по поводу отсутуов внутри min забыл упомянуть что такое в функциях можно делать но в меру, могу убрать но не вижу смысла зачем от этого избавляться
а вот если ко второй задаче добавить еще и между скобками текст и причем еще добавить escape charter чтобы можно было писать (\{) и это было сбалансированно, то задачку мы усложним и тут уже можно ее решение к автоматам сводить, но только зачем это в пхп ?
и еще почему во второй задаче цикл написан будто бы задачи решали программисты С
пришел к подобному подходу довольно давно есть пару замечаний по таблице sign_in_requests:
Колонку email заменить на users_id (связь по primarykey как то более привычно).
Вместо колонки expiredAt, мне кажется более логично created_at (тем самым время жизни токена можно вынести в конфиг).
Вместо колонки isUsed более логично использовать activated_at где писать дату входа по токену
Колонка requestIp в реальности бесполезна (если только не супер строгая система, но там такой подход вообще не подойдет).
Добавляю колонку deleted_at где можно деактировать любую запись
Также в некоторых случаях если не охото jwt юзать или сессии, можно добавить колонку secret(Uniq) и сообщать ее пользователю и там хранить уже в куках или localstorage и отправлять этот секрет с каждым запросом, у этого подхода есть и минусы но в некоторых случаях он прекрасно подходит
Получается колонка secret это как бы session_id который не чистится и человек авторизован пока не выйдет (logout)
та модель что на видео отличается от той что на видео на ютубе, а зная как могут извращаться некоторые производители я бы не рискнул сказать что это одно и тоже.
Не обратил внимание на SSD.
За свои деньги это хороший выбор если покупать в России.
тоже интересовался данной моделькой но судя по отзывам эту модель сложно разбирать и там почти все распаяно может быть, поэтому ремонто пригодность довольно низка, ну и плюс добавить сюда цену ssd
но на российском рынке одна из интересных моделек за свои деньги.
к сожалению не могу сказать еще не заказал, самого интересуют подобные вопросы перед приобретением но независимые обзоры именно этой модели не видел(по картинкам уже нашел некоторые моменты что не нравятся, над клавишей enter расположена клавиша delete внезапно), меня интересует еще время автономной работы чтобы было хотя бы 4ч в режиме серфинга.
Для меня это такой же кот в мешке, но судя по техническим характеристикам за свои деньги может получится довольно выгодной моделью и в случае поломок наверно можно будет найти детали на али без проблем
Еще я рассматриваю ноуты отсюда(но тут чуть другая цена примерно равны рознице в россии но это совсем уже другие ноуты), тут с корпусом судя по всему полный порядок system76.com/laptops/galago но мне по размерам хочется 14 дюймовый system76.com/laptops/lemur но он уже не металический и порт usb type c без thunderbolt вроде.
Ну и еще из инсересного нашел вот такой производитель ноутов slimbook.es (там разные модельки) они из Испании вроде, делают ноут для kde вроде, но имхо по железной начинке они проигрывают system76
надеюсь не сочтут рекламой не к одной из ссылок не имею никакого отношения, просто старался найти лучшие варианты за свои деньги.
я отлижил себе вот эту модельку ru.aliexpress.com/item/14-inch-4gb-8gb-16gb-ram-128gb-256gb-ssd-wifi-bluetooth-gaming-netbook-ips-screen/32831531868.html
но если сделать поиск по laptop ips fhd и отфильтровать по 14 дюмовым (15.6 многовато, 13.3 маловато это по моим субьективным ощущениям) можно посмотреть хорошие модельки, но там процецы или n* (хороши с точки зрения автономности но слабые) или i7 45* или искать по современней i7 6500 (идеален в плане что поддерживается windows 7 отлично, в отличие от 7 покаления intel где надо делать небольшие танцы чтобы не переходить на w10)
мне самому пробуки понравились, но дисплей там так себе судя по обзорам и да я смотрю ноуты только с fhd
если честно ноутбук очень больная тема, после 2014 года цены просто космос, искал себе для работы но в россии нормальные модели около 100к стоят
из нормальных нашел довольно выгодный вариант на али Core i7 6500U 16 ГБ Оперативная память + 128 ГБ SSD + матрица ips и он дюймовый и это добро за 36 535 (с доставкой), ну или если нужно хороший то присмотрел себе от system76 несколько моделек, но тут с доставкой все сложно.
Нормальные варианты только от 100к рублей в России
действительно категоричность моего комментария возможно и не правильна(с этой точки зрения я не подумал), но как мне кажется это очевидное замечание, что с точки зрения безопасности это(когда несколько сервисов и симетричное шифрование и все они знают один и тот же ключ) может быть не лучшим выбором, причем я ничего против безопасности jwt не имею и использую их уже несколько лет.
только что вот считать оригинальным описанием?
то что написано в rfc? RFC 2313, RFC 2437, RFC 3447 в каком именно?
или первая его оригинальная публикация в научных журналах ?
только вот в этих документах нет ничего конкретного по реализации (кроме математических формул) потому что парадигм программирования очень много:
1.1. ООП
1.2. Процедурное и тд
2.1. Функциональное и тд
Вы будете искать rfc описывающее rsa в рамках ООП или ФП? таких нет, потому что rfc это описание и оно не привязано к реализации (парадигме или языку программирования), а как вы будете делать реализацию и в рамках какой парадигмы, зависит от вас и возможно от языка программирования что будете использовать (глупо например используя java писать в фп парадигме или использовать haskell и писать в ооп)
Даже если вы выберете ООП то тут есть еще куча вопрос:
То о чем вы говорите (о разрыве знакомого многим и лишними абстракциями) называется "связанность", что код должен отражать предметную область с которой он работает.
Только вот проблема в том что на вики выложен пример реализации в виде псевдо кода или какой нибудь наиболее наглядный пример на популярном языке, например в ФП не принято использовать циклы и вместо циклов бы тут использовали array map и реализация была бы совсем другой (в вики нет примера алгоритма флойда в рамках ФП).
Поэтому я согласен с тем что код должен быть сильно связан с предметной областью с которой он работает, но я не согласен с тем что есть одна и только одна каноническая реализация алгоритма, как минимум один и тот же алгоритм может выглядеть по разному в разных парадигмах программирования, также могут применяться разные оптимизации для повышения производительности и тд,
так вопрос разделения действий очень относительный.
вот например взять тот же алгоритм флойда и пхп, там есть операция +, если я выйду за пределы int во время этой операции?
Для работы с большими числами есть bc math или gmp, но это же алгоритм флойда надо ли их использовать, мне кажется да (если можно за пределы int уйти) но вы говорите что алгоритм флойда это то неделимое и надо смотреть на всю картину в целом, давайте тогда и работу с большими числами реализуем внутри циклов, как тогда будет выглядеть алгоритм без вспомогательных функций (методов) для работы с большими числами ?
по поводу изображений пример не корректен, если было так как вы говорите то в редакторах не было бы zoom (ведь удобней смотреть на все изображение без приближений вы так написали), поэтому пример с изображениями как раз и говорит что иногда один элемент (изображение) состоит из множества разных элементов (пикселей и векторов, ведь внезапно бывает еще и векторная графика), но мы не задумываемся о этих деталях когда смотрим на изображение пока нет в этом необходимости.
к сожалению я так и не вижу реализацию rsa от вас
а как по вашему должен выглядеть алгоритм rsa со всеми основными вещами (decrypt, encrypt, sign, verify, createkey причем не разбивая на отдельные функции)
а также работу с BigInt тоже не выносить отдельно это же цельное, там ниже задал вопрос, но не вам к сожалению, поэтому и тут продублировал, а и еще постарайтесь сделать поменьше строк, "это очень важно".
простите не вам про одну строку.
давайте я возьму очень популярный алгоритм которым большинство присутствующих пользуется и не задумывается (реализацию специально на пыхе найду) https://github.com/phpseclib/phpseclib/blob/master/phpseclib/Crypt/RSA.php
вот сразу как открываешь подобный файл и видишь родные $i, $j, $n прям сразу ясно становиться что за алгоритм
прям каждый день сниться когда все это в одной функции будет не разделено на вспомогательные вещи, прям сразу ясно что это RSA, а не DSA
теперь запишите его как вы говорили все в одну функцию, да да да decrypt, encrypt, sign, verify, createkey пусть там на входе массив будет и сказан тип операции что надо сделать и разные ключи с параметрами
я вам даже начну
и теперь ответьте честно будет выглядеть проще?
есть GodObject, но похоже можно еще создавать GodFunction или GodMethod, не знал о последних двух, спасибо что помогли их понять еще раз.
исходный вариант 4 строки которые в примере это на самом деле, + 1 строка на функцию + 2 строки на скобки этой функции(в psr открывающая с новой строки) + 1 строка закрывающая скобка для каждого цикла (итого 3) + 1 строка на return
итого получаем 4 полезных строки размазанные по еще 7 строкам получаем 11 входных строк.
но даже учитывая 11 строк можно считать что он выглядит не сложно, но это не значит что так как я написал делать нельзя.
Но работа программиста это не писать максимально короткие программы, а писать софт который потом можно поддерживать потому что имея 11 строк я могу довольно много чего придумать так чтобы потом это было читать и понимать тяжело, поэтому мы не строками меримся, а пишем софт который потом поддерживать и большая часть времени читать.
Для примера цитата про "алгоритм установки gentoo" http://bash.im/quote/394695 если вам нравиться подобное в коде, то у всех свои вкусы и каждый вправе иметь свои взгляды.
по поводу разбивать на части то что цельное, вы когда запрос к бд посылаете вы ручками создаете сокет, подключаетесь к бд и посылаете запрос или все таки разделяете на уровень по работе с бд и потому что генерирует запросы?
ото алгоритм работы с бд можно назвать и это:
как бы тоже 4 строки, не надо все под одну гребенку нести.
а то что я разбил исходный текст на 3 метода это потому что у алгоритма 3 уровня отступов
"умом Россию не понять ..."
так как php используется в вебе то такое решение вполне сойдет
если мы будем говорить об оптимизации производительности, потребление памяти, скорости и тд первое что стоит начать делать это взять компилируемый язык чтобы не терять время интерпретации, причем я ничего против пхп не имею в свое нише он дает достаточную производительность.
ах да по поводу отсутуов внутри min забыл упомянуть что такое в функциях можно делать но в меру, могу убрать но не вижу смысла зачем от этого избавляться
если честно подобный подход считаю очевидным, пришел к следующему правилам для себя:
все остальное это следствие из этих правил.
да вы верно дополнили то что я написал во втором пункте сразу не сработает и тогда они правильней строки перебирали, чем конвертить строку в массив
а вот если ко второй задаче добавить еще и между скобками текст и причем еще добавить escape charter чтобы можно было писать (\{) и это было сбалансированно, то задачку мы усложним и тут уже можно ее решение к автоматам сводить, но только зачем это в пхп ?
и еще почему во второй задаче цикл написан будто бы задачи решали программисты С
Может быть заменено на
Meltdown и Spectre это уязвимость в процессорах а не ОС, поэтому смена ОС тут не поможет.
он наверно имеет ввиду сервисы которые генерируют временные ящики на 10 минут и тем самым он юзает их для регистрации не светя свой настоящий email.
и второй раз получить к тому же временному email очень мало вероятно
пришел к подобному подходу довольно давно есть пару замечаний по таблице sign_in_requests:
Также в некоторых случаях если не охото jwt юзать или сессии, можно добавить колонку secret(Uniq) и сообщать ее пользователю и там хранить уже в куках или localstorage и отправлять этот секрет с каждым запросом, у этого подхода есть и минусы но в некоторых случаях он прекрасно подходит
Получается колонка secret это как бы session_id который не чистится и человек авторизован пока не выйдет (logout)
Не обратил внимание на SSD.
За свои деньги это хороший выбор если покупать в России.
но на российском рынке одна из интересных моделек за свои деньги.
Для меня это такой же кот в мешке, но судя по техническим характеристикам за свои деньги может получится довольно выгодной моделью и в случае поломок наверно можно будет найти детали на али без проблем
Еще я рассматриваю ноуты отсюда(но тут чуть другая цена примерно равны рознице в россии но это совсем уже другие ноуты), тут с корпусом судя по всему полный порядок system76.com/laptops/galago но мне по размерам хочется 14 дюймовый system76.com/laptops/lemur но он уже не металический и порт usb type c без thunderbolt вроде.
Ну и еще из инсересного нашел вот такой производитель ноутов slimbook.es (там разные модельки) они из Испании вроде, делают ноут для kde вроде, но имхо по железной начинке они проигрывают system76
надеюсь не сочтут рекламой не к одной из ссылок не имею никакого отношения, просто старался найти лучшие варианты за свои деньги.
но если сделать поиск по laptop ips fhd и отфильтровать по 14 дюмовым (15.6 многовато, 13.3 маловато это по моим субьективным ощущениям) можно посмотреть хорошие модельки, но там процецы или n* (хороши с точки зрения автономности но слабые) или i7 45* или искать по современней i7 6500 (идеален в плане что поддерживается windows 7 отлично, в отличие от 7 покаления intel где надо делать небольшие танцы чтобы не переходить на w10)
мне самому пробуки понравились, но дисплей там так себе судя по обзорам и да я смотрю ноуты только с fhd
из нормальных нашел довольно выгодный вариант на али Core i7 6500U 16 ГБ Оперативная память + 128 ГБ SSD + матрица ips и он дюймовый и это добро за 36 535 (с доставкой), ну или если нужно хороший то присмотрел себе от system76 несколько моделек, но тут с доставкой все сложно.
Нормальные варианты только от 100к рублей в России
действительно категоричность моего комментария возможно и не правильна(с этой точки зрения я не подумал), но как мне кажется это очевидное замечание, что с точки зрения безопасности это(когда несколько сервисов и симетричное шифрование и все они знают один и тот же ключ) может быть не лучшим выбором, причем я ничего против безопасности jwt не имею и использую их уже несколько лет.