На самом деле смысл во всём этом есть. Например, лет через 10-15 мощные компьютеры смогут подобрать приватные ключи к этим кошелькам и станет возможно их вывести. А этот мутный банк тут как тут - "а это уже наше, хехе".
Кроме W2K, позднее вышел W2K3 (Windows 2003). Несмотря на то, что он тоже позиционировался как Server - прекрасно и стабильно работал на десктопах. Вот он, пожалуй, и был лучшим в то время.
Надо бы три раза подчеркнуть что конфигурацию в таком виде кроме как для одноразовых тестов использовать нельзя. Храни вас святой Нортон если вы решите использовать это на продакшене.
Непонятно что за версии вы советуете использовать. Kafka последних версий не нуждается в Zookeeper.
Круто! Респект вам за правильное применение ваших знаний математики.
Не способен задать вопрос по сути статьи, поэтому задам по тому, за что зацепился взгляд:
В контексте ядра работы алгоритма я не принес ничего нового, даже наоборот, больше копипастил у других. Перед тем как приступить к реализации своего, я посмотрел реализации в нескольких СУБД, в частности, YDB, MySQL и DuckDB.
Как вы решили вопрос с конечной лицензией? Я вижу, что у вас MIT. У MySQL - GPL, у YDB и DuckDB - Apache 2.0. Если были заимствования - то тут возможна коллизия?
Ну так-то отвалиться может что угодно. Они могут вообще распечатывать ваш xml и прогонять через OCR, а потом диктовать слепому наборщику текстов по телефону со стадиона - и вы ничего с этим не сделаете.
А про SOAP - ну так-то там много стандартов наверчено вокруг. Я года 4 назад честно пытался начать работать с сервисом, который в SOAP использует ws-addressing и кучу подписей в документе и в транспорте. В итоге оказалось, что ни в одной Python библиотеке просто не поддерживается одна из особенностей - что-то там не подписывалось правильно и все мои попытки самому починить ни к чему не привели. В итоге, после трёх месяцев я нагуглил у собратьев по несчастью что в php это как-то работает и всё закончилось костылём где я из python вызываю php для отправки файла.
А этот SOAP-сервис, который сначала был стройно разбит на несколько wsdl и xsd файликов уже через пару лет превратился в сборище разных версий этих xsd, которые ссылаются друг на друга в хаотичном порядке.
Неправильное. RFC (не вспомню какой, правда) запрещает преобразование email адреса где-либо, кроме сервера-владельца. Если вы хотите следовать RFC - вы должны принять адрес как его вам дали.
А как же регистр? Юзер зарегистрировался как "vasya@gmail.com" и пытается зайти с "Vasya@gmail.com" - тоже не надо преобразовывать?
Рано. У вас теперь два поля для PII masking в логах, анонимизации для стейджа, интеграций с партнёрами. Это набор источников для интереснейших багов.
Нормализуйте email, добавьте соль и возьмите от этого хэш - тот же sha256 - получите заодно уникальный ключ для юзера. Можете передавать его партнёрам или писать на стене. Однако, возможна ситуация когда вы немного исправили процедуру нормализации и хэширование для уже существующих email в базе будет выдавать другой ключ. Впрочем, и без хэширования нормализованный email в базе может измениться.
По теме проверки email - как обычно, на древнем StackOverflow сохранились сокровища с примерами вроде этого. Все понимают, что надо где-то знать меру, но не все знают про эти дополнительные фичи вроде той же субадресации (RFC5233).
Однако, это уже дополнительная фича, которая может не поддерживаться почтовым сервером. Даже автор статьи в примере приводит только gmail. Однако, плюс (и минус, а также может быть и решетка #) для этого используют почти все крупные почтовые сервисы. Фича с точками - только у gmail AFAIK, но ещё могут быть корпоративные домены, которые хостятся на gmail, а так же более мелкие сервисы. Просто так нормализация - довольно непростой процесс.
Хирург командует во время операции: - Так, приступаем к ампутации левой ноги пациента Ивано... Ассистент с пилой: <вжжжжж> Хирург: Ноги!! Ассистент с пилой: <вжжжжж> Хирург: Левой!!! - <вжжжжж>
Ну что вы к человеку пристали.. Погуглите по слову "релиденс" - найдёте 198-страничный (на данный момент) pdf-документ с названием "Физика Иного Разума".
Человек пишет свою физику. Серьёзные учёные на такое даже смотреть не будут, поэтому обычно такие теории распространяются через все подряд сайты, где, если повезёт, обрастают каким-то количеством поклонников разных теорий заговоров.
Ну правда, кто-то хочет тратить своё время и пытаться что-то доказать? Давайте наставим минусов и человек уйдёт дальше на пикабу.
Ну вот здесь уже возможны варианты. Контейнеров может быть разное количество и имена у них могут автоматически назначаться, однако кто-то может захотеть жёстко гвоздями прибить конфигурацию на именах контейнеров. Может и я захочу потом.
Лично мне нужны будут имена сервисов (как в compose или Swarm), либо, может быть, hostname - но с ними могут возникнуть сложности (особенно с разными сетями). Сервис может иметь несколько инстансов контейнеров.
Очевидно что у вас нет цели поддерживать все фичи докера, спасибо даже на тех что уже есть. В принципе, мои задачи для Swarm может решить даже обыный docker-резолвер, который в последних версиях nginx доделали.
Не совсем понял, что имеется в виду, можно чуть подробнее с примером?
Ну вот вся функциональность из labels, но только описаная в конфиге. И отключать конфигурацию из labels. Сервисы группировать либо по именам, либо по тем же labels (просто имена).
Пример конфига красивый придумать не смогу, но, вероятно, тоже что-то типа блока docker_service.
Да, будет более статическая конфигурация, но иногда это и надо. Например, никакие новые неизвестные сервисы не добавятся, конфигурация хранится и управляется в одном месте.
Есть или нет - то нам пока неведомо. Но за 100 баксов попробовать стоит, видимо.
На самом деле смысл во всём этом есть. Например, лет через 10-15 мощные компьютеры смогут подобрать приватные ключи к этим кошелькам и станет возможно их вывести. А этот мутный банк тут как тут - "а это уже наше, хехе".
Кроме W2K, позднее вышел W2K3 (Windows 2003). Несмотря на то, что он тоже позиционировался как Server - прекрасно и стабильно работал на десктопах. Вот он, пожалуй, и был лучшим в то время.
Надо бы три раза подчеркнуть что конфигурацию в таком виде кроме как для одноразовых тестов использовать нельзя. Храни вас святой Нортон если вы решите использовать это на продакшене.
Непонятно что за версии вы советуете использовать. Kafka последних версий не нуждается в Zookeeper.
А почему имиджи из репозитории Confluent?
А зачем нужен Docker Desktop?
Круто! Респект вам за правильное применение ваших знаний математики.
Не способен задать вопрос по сути статьи, поэтому задам по тому, за что зацепился взгляд:
Как вы решили вопрос с конечной лицензией? Я вижу, что у вас MIT. У MySQL - GPL, у YDB и DuckDB - Apache 2.0. Если были заимствования - то тут возможна коллизия?
А вот это уже более отвязно - я бы сказал, что это лучший вариант, несмотря на Алису.
Неплохо, но это тоже не панк, это что-то на мотивы Арии.
Это не панк, это попса. Кровь-кишки, тимлид опять порезал гендира на митинге, но созвон продолжается, мы семья, а-а-а (соло на бас-гитаре)...
"Решил попробовать поработать в гетеросексуальном коллективе".
Ну так-то отвалиться может что угодно. Они могут вообще распечатывать ваш xml и прогонять через OCR, а потом диктовать слепому наборщику текстов по телефону со стадиона - и вы ничего с этим не сделаете.
А про SOAP - ну так-то там много стандартов наверчено вокруг. Я года 4 назад честно пытался начать работать с сервисом, который в SOAP использует ws-addressing и кучу подписей в документе и в транспорте. В итоге оказалось, что ни в одной Python библиотеке просто не поддерживается одна из особенностей - что-то там не подписывалось правильно и все мои попытки самому починить ни к чему не привели. В итоге, после трёх месяцев я нагуглил у собратьев по несчастью что в php это как-то работает и всё закончилось костылём где я из python вызываю php для отправки файла.
А этот SOAP-сервис, который сначала был стройно разбит на несколько wsdl и xsd файликов уже через пару лет превратился в сборище разных версий этих xsd, которые ссылаются друг на друга в хаотичном порядке.
Простите, наболело.
И тут эти ребята с блокнотами внезапно напряглись после такой новости...
Скрытый текст
Ну тогда мы снова вступаем на скользкую дорожку - разные ли пользователи "Vasya" и "vasya"? Тут проблема с плюсом уже - частный случай.
Но я ни разу не встречал сервиса где такое разрешалось. Наверное и правильно.
Так а пользователя-то как находить в базе при логине? Это же один аккаунт. Пароль тут совсем не при чём. Вопрос в том - как хранить email в базе.
А как же регистр? Юзер зарегистрировался как "vasya@gmail.com" и пытается зайти с "Vasya@gmail.com" - тоже не надо преобразовывать?
Нормализуйте email, добавьте соль и возьмите от этого хэш - тот же sha256 - получите заодно уникальный ключ для юзера. Можете передавать его партнёрам или писать на стене. Однако, возможна ситуация когда вы немного исправили процедуру нормализации и хэширование для уже существующих email в базе будет выдавать другой ключ. Впрочем, и без хэширования нормализованный email в базе может измениться.
По теме проверки email - как обычно, на древнем StackOverflow сохранились сокровища с примерами вроде этого. Все понимают, что надо где-то знать меру, но не все знают про эти дополнительные фичи вроде той же субадресации (RFC5233).
Однако, это уже дополнительная фича, которая может не поддерживаться почтовым сервером. Даже автор статьи в примере приводит только gmail. Однако, плюс (и минус, а также может быть и решетка #) для этого используют почти все крупные почтовые сервисы. Фича с точками - только у gmail AFAIK, но ещё могут быть корпоративные домены, которые хостятся на gmail, а так же более мелкие сервисы. Просто так нормализация - довольно непростой процесс.
Хирург командует во время операции:
- Так, приступаем к ампутации левой ноги пациента Ивано...
Ассистент с пилой: <вжжжжж>
Хирург: Ноги!!
Ассистент с пилой: <вжжжжж>
Хирург: Левой!!!
- <вжжжжж>
and my friend's name is Semen.
Ну что вы к человеку пристали.. Погуглите по слову "релиденс" - найдёте 198-страничный (на данный момент) pdf-документ с названием "Физика Иного Разума".
Человек пишет свою физику. Серьёзные учёные на такое даже смотреть не будут, поэтому обычно такие теории распространяются через все подряд сайты, где, если повезёт, обрастают каким-то количеством поклонников разных теорий заговоров.
Ну правда, кто-то хочет тратить своё время и пытаться что-то доказать? Давайте наставим минусов и человек уйдёт дальше на пикабу.
Ну вот здесь уже возможны варианты. Контейнеров может быть разное количество и имена у них могут автоматически назначаться, однако кто-то может захотеть жёстко гвоздями прибить конфигурацию на именах контейнеров. Может и я захочу потом.
Лично мне нужны будут имена сервисов (как в compose или Swarm), либо, может быть, hostname - но с ними могут возникнуть сложности (особенно с разными сетями). Сервис может иметь несколько инстансов контейнеров.
Очевидно что у вас нет цели поддерживать все фичи докера, спасибо даже на тех что уже есть. В принципе, мои задачи для Swarm может решить даже обыный docker-резолвер, который в последних версиях nginx доделали.
Ну вот вся функциональность из labels, но только описаная в конфиге. И отключать конфигурацию из labels. Сервисы группировать либо по именам, либо по тем же labels (просто имена).
Пример конфига красивый придумать не смогу, но, вероятно, тоже что-то типа блока
docker_service.Да, будет более статическая конфигурация, но иногда это и надо. Например, никакие новые неизвестные сервисы не добавятся, конфигурация хранится и управляется в одном месте.