Да, радиус мы по определению считаем постоянной величиной, заданной в условиях задачи (про корку арбуза).
Вспоминается смежная задача, если зайти с другой стороны, что диагональ N-мерного куба всё время увеличивается, при увеличении размерности N, при фиксированной длине стороны куба. Используется обобщение формулы Пифагора для высоких размерностей. Просто, информация к размышлению.
Ну да, если жену выбирать по одному параметру, то вообще проблем нет :) А чем больше требований начинаешь предъявлять к потенциальной жене, то больше шансов, что не найти тебе идеал. Надо быть проще, выбрать 2, 3 основных параметра, а с остальными мириться. Да и вообще, если про личную жизнь, не в параметрах дело, а в готовности двух людей вкладываться в совместные проекты (проекты в широком смысле). А отличие параметров — даже полезно, позволяет более многогранно совместно смотреть на мир, о чём и сделан один из выводов в статье.
Тухлая/свежая ягода — это всего один параметр, пространство одномерное.
Если мы введём ещё множество параметров отбора ягод, то получим бОльшую размерность и условные 50% ягод, которые не будут удовлетворять всем параметрам. Например параметры:
— треснута корочка на ягоде или нет;
— размер ягоды большой/маленький;
— овальность/округлость ягоды;
— подсохший хвостик ягоды или нет;
— косточек больше 2 (для не киш-миша);
и т.д.
Ну да, говорить, что «все люди этого не понимают» ошибочно, конечно кто-то понимает этот результат, кто-то интуитивно чувствует. Просто я в своей практике сталкивался с непониманием этого, что чем больше в системе звеньев, тем она менее надёжна, я бы так это выразил своими словами.
Да, и итоговый вывод тоже очень жизненный: «Так что нет резона вести нескончаемые споры, в поисках истины, вместо этого, стоит прислушаться и постараться услышать иное мнение, увидеть взгляд из другого, сопряжённого, пространства, обогащая тем самым своё восприятие мира.»
Спасибо автору за статью.
Мне нечего добавить к статье, к сожалению.
Мне понравился вывод: «Достаточно дюжины шагов, чтобы 5% вероятности ошибки на каждом из них, выросли до 50% вероятности провала всего дела!»
На практике люди этого не понимают, пытаются внедрять в бизнес процессы новомодные приложения, которые, фактически, становятся дополнительной точкой отказа и приводят только к проблемам, а не пользе.
Ну вообще-то в статье шла речь о конкретном bcrypt, насколько я понимаю, не симметричном алгоритме, поэтому прошу признать актуальность «Проблема инвалидации». По остальным контраргументам проблем «перца» ваши доводы заслуживают внимания.
Видимо имеется ввиду перехэширование в момент авторизации пользователей, как сказано habr.com/post/194972, функция password_needs_rehash. Но это не решение, или не самое лучшее решение, которое приведёт к тому, что в БД постоянно будут храниться хэши двух и более типов, которые к тому же надо поддерживать в коде, как итог путаница.
Ой, а можно пример кода по пункту: «то Вам нужно просто перешифровать все хэши (и соли) новым ключем.»? Я, например, не знаю, как решить эту задачу.
Дано: БД с хэшами паролей, корректно зашифрованных солью+перцем1.
Найти: БД с хэшами тех же самых пролей, корректно зашифрованных солью+перцем2.
:) Нет, не подходит. Они становятся горизонтальными прямоугольниками, а нужны вертикальные прямоугольники, с полным перечнем всех полей. В перечне полей (=колонок) вся соль, как без них между таблицами связи рисовать? Связки между таблицами происходят по полям и важны названия полей, по которым идёт связка, только в этом случае ER модель приобретает мощное прикладное значение, когда глядя на схему за 5 минут можно сложный запрос составить, в незнакомой базе данных. Колонки нужны.
У меня почему-то при переключении Layout ничего не меняется в отображении, странно.
Добрый вечер.
Хорошая программа DataGrip, правда ещё не совсем привык к логике работы с проектами, в смысле обычно в других программах просто подключаешься к базе данных и работаешь, сохраняешь отдельные sql файлы, но не связанные между собой в проекты. Основное преимущество программы в том, что можно работать с разными типами баз данных: MySQL, MSSQL, PostgreSQL и прочее.
Для быстрого изучения структуры чужой базы данных очень удобно использовать ER модели. В DataGrip есть возможность отобразить визуализацию таблиц: Diagrams -> Show Visualisation… При этом отображаются таблицы со всеми своими полями (даже со связями, если связи прописаны на уровне базы данных), практически то, что нужно, однако у отображения есть один большой недостаток, что квадраты (именно квадраты!!! а не прямоугольники) отображающие таблицы излишне большие по ширине, съедают слишком много места, в то время как внутри этих квадратов пустота. В итоге эти квадраты не помещаются на страницу, приходится печатать их очень мелкими и ничего не видно. Т.е. от такой визуализации на выходе ноль! к сожалению.
1. Нельзя ли визуализацию сделать более компактной?
Пытаюсь обойти эту проблему тем, что хочу экспортировать структуру базы данных и скормить полученный *.sql файл другой программе для ER моделирования. Такой возможности в DataGrip не нахожу. Есть экстрактор для экспорта данных, но для экспорта структуры всей базы данных (или отдельной схемы) нет.
2. Нельзя ли сделать экстрактор для извлечения пустой структуры базы данных? Кое-что нагуглил на эту тему (http://www.varuste.net/show_create_table.html), но не знаю куда этот скрипт нужно «засунуть» :)
Скорее всего расчёт сделан на то, что крупные операторы смогут реализовать этот функционал, чтобы человек мог переходить от одного оператора к другому, а вот мелкие, начинающие операторы этого сделать не смогут, не по зубам. Таким образом, полагаю, что этот законопроект протолкнули сами крупные сотовые операторы, чтобы избавиться от мелких конкурентов, что «не есть гуд».
Программа OpenSCAD, о которой уже говорил в статье, очень хорошая, трёхмерные изображения рисуются на счёт раз, надо только освоиться немного. Вот, например, вчера нарисовал торы за 20 минут.
А вот 4-мерные картинки, точнее картинки, где изображены четырёхмерные многогранники, как уже сказал, скачал из википедии.
Да, я тоже в своё время пытался изобразить 4-мерное пространство на компьютере с помощью вращения. Хотел сначала 3-мерный куб повращать, а потом аналитически обобщить это вращение на 4-мерие и посмотреть, что получится визуально, но, честно говоря, до конца эту идею не довёл и, да, в то время ещё компьютеры послабее были.
Очень приятно, что нас так много единомышленников, во всяком случае тех, кто интересуется одними и теми же вопросами.
Смысл статьи — дать и объяснить понятие-определение «Символ Шлефли», только не лексическое, а образно-логическое определение. Этот термин нужно понимать, чтобы понять вывод многогранников в размерностях 4 и выше.
Вспоминается смежная задача, если зайти с другой стороны, что диагональ N-мерного куба всё время увеличивается, при увеличении размерности N, при фиксированной длине стороны куба. Используется обобщение формулы Пифагора для высоких размерностей. Просто, информация к размышлению.
Если мы введём ещё множество параметров отбора ягод, то получим бОльшую размерность и условные 50% ягод, которые не будут удовлетворять всем параметрам. Например параметры:
— треснута корочка на ягоде или нет;
— размер ягоды большой/маленький;
— овальность/округлость ягоды;
— подсохший хвостик ягоды или нет;
— косточек больше 2 (для не киш-миша);
и т.д.
Между прочим в статье делаются серьёзные, жизненные выводы, которые, для меня лично, являются руководством к действию.
Спасибо автору за статью.
Мне нечего добавить к статье, к сожалению.
На практике люди этого не понимают, пытаются внедрять в бизнес процессы новомодные приложения, которые, фактически, становятся дополнительной точкой отказа и приводят только к проблемам, а не пользе.
Дано: БД с хэшами паролей, корректно зашифрованных солью+перцем1.
Найти: БД с хэшами тех же самых пролей, корректно зашифрованных солью+перцем2.
У меня почему-то при переключении Layout ничего не меняется в отображении, странно.
Хорошая программа DataGrip, правда ещё не совсем привык к логике работы с проектами, в смысле обычно в других программах просто подключаешься к базе данных и работаешь, сохраняешь отдельные sql файлы, но не связанные между собой в проекты. Основное преимущество программы в том, что можно работать с разными типами баз данных: MySQL, MSSQL, PostgreSQL и прочее.
Для быстрого изучения структуры чужой базы данных очень удобно использовать ER модели. В DataGrip есть возможность отобразить визуализацию таблиц: Diagrams -> Show Visualisation… При этом отображаются таблицы со всеми своими полями (даже со связями, если связи прописаны на уровне базы данных), практически то, что нужно, однако у отображения есть один большой недостаток, что квадраты (именно квадраты!!! а не прямоугольники) отображающие таблицы излишне большие по ширине, съедают слишком много места, в то время как внутри этих квадратов пустота. В итоге эти квадраты не помещаются на страницу, приходится печатать их очень мелкими и ничего не видно. Т.е. от такой визуализации на выходе ноль! к сожалению.
1. Нельзя ли визуализацию сделать более компактной?
Пытаюсь обойти эту проблему тем, что хочу экспортировать структуру базы данных и скормить полученный *.sql файл другой программе для ER моделирования. Такой возможности в DataGrip не нахожу. Есть экстрактор для экспорта данных, но для экспорта структуры всей базы данных (или отдельной схемы) нет.
2. Нельзя ли сделать экстрактор для извлечения пустой структуры базы данных? Кое-что нагуглил на эту тему (http://www.varuste.net/show_create_table.html), но не знаю куда этот скрипт нужно «засунуть» :)
А вот 4-мерные картинки, точнее картинки, где изображены четырёхмерные многогранники, как уже сказал, скачал из википедии.
Очень приятно, что нас так много единомышленников, во всяком случае тех, кто интересуется одними и теми же вопросами.