ну попадётся там символ из 1 байта или 3-х

Откуда ты вообще получил такую строку

Строка "\xAB" это строка из одного байта

это из сертификата cer

Через OpenSSL вытащил с помощью регулярки

А преоразовать че то туплю

А строка "\\xAB" состоит из 5 байтов

Потому что \x это это преобразуется только для вывод на консоль

Теперь понятно, почему \\xAB.bytes из 5) Просто я никак не мог отделить личшний \. Щас кажется придумал

Потому что \x это это преобразуется только для вывод на консоль

Я вообще думал, что \x указывает, что это шестнадцетеричное значение, а второй слэш для эскейпинга

Строка "\xAB" это строка из одного байта

Значит я верно говорил, что из 2х байт состоит моя буква. Пробелы блин в знаниях больште, только на готовые методы привык

В руби \x это эскейпинг для Хексов в строке

Только фишка в том что если там в тексте цифра, знак припинания или английская буква, то это символ состоит из одного байта

Поэтому если ты будешь делить просто по два - поломается нафиг

Ага тут я знаю, но их там нет, т.к. там хранится ФИО

просто делал автоматизацию по перевыпуску сертификатов

И шаблоны html автоматом, а так ручками долбанешься

90 доков готовить

надо вырезать все \\x и оставить только эти штуки регуляркой

а потом юзануть любую либу для hex

Народ, как в ruby правильно преобразовать строку вида \\xD0\\xA6\\xD1\\x8B\\xD1\\x80\\xD0\\xB5\\xD0\\xBD\\xD0\\xB4\\xD0\\xB0\\xD1\\x88\\xD0\\xB8\\xD0\\xB5\\xD0\\xB2\\xD0\\xB0 \\xD0\\x94\\xD0\\xB0\\xD1\\x88\\xD0\\xB8\\xD0\\xBC\\xD0\\xB0 \\xD0\\x9C\\xD1\\x83\\xD0\\xBD\\xD0\\xBA\\xD1\\x83\\xD0\\xB5\\xD0\\xB2\\xD0\\xBD\\xD0\\xB0 в читаемые русские символы? Я знаю, что каждые 2 байта, это русская буква, но это при условии что если в консоле я напишу их через один слэш \xD0\xA6. Я уже всяко pack/unpack переюзал врубится никак не могу. Сори, что не в руби чате

присвоить строке: s = "\\xD0 ... и сделать s.gsub(/\\x(\w\w)/) { $1.to_i(16).chr }.force_encoding('utf-8')

"Цырендашиева Дашима Мункуевна"

Блин, мне не давало покоя какое же ФИО там хранится, теперь я спокоен

Хотел даже бросить работу и самому сделать, хаха

Дамы и господа. Меня опять пригласили выступать на OpenStack конфу :)

Слава, женщины, бухло :)

СПС) я че то пробовал gsub но видимо криворукий)

по идее там заэвалить можно

но у меня что-то не получилось с первого раза

эвалить в грепах смертно

eval "\"#{s}\""

блин кавычки перепутал когда пытался в первый раз

эвалить в грепах смертно

там не про греп идёт разговор

Пацаны

Поясните кто нибудь за микросервисы

Я когда то видел

Что советовали чуть ли не авторизацию отделять в микросервис

Какой смысл деления есть?

Нет, делай монолит, а когда взлетит, тогда и поемешь как поделить. Если надо будет.

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

+1 главное мониторинг прикрути и смотри где запросов больше то и отделяй на отдельную тачку как сервис

С базой тоже самое делаешь шардирование логическое а потом разносишь, "ecto_instashard" в помошь.

Единственное с чем пришлось помучаться перед продом, это с нормальным заворачиванием в докер.

@spscream круто выручил в этом плане

Парни подскажите как грамотно мониторить генстейдж

И прикручивать все это дело к каналам

В фениксе , никто не сталкивался ?

а мониторинг чего конкретно в генстейдже тебя интересует?

в чем проблема собственно

Ну у меня пайплайн стартанул

и я хочу чтобы когда умерла одна из стейджей ее переподнять супервизором

и кильнуть пайплайн в том числе когда чанал закончил стримить

Что советовали чуть ли не авторизацию отделять в микросервис

Это имеет смысл, только если у тебя больше чем один сервис будет пользоваться аутентификацией/авторизацией. Я щас как раз пилю AA-микросервис на Erlang, и пилю отдельно, чтобы а) сделать его единой АА-точкой для 1+ сервисов б) обеспечить отказоустойчивость.

А если сервис один, то делай монолитно - код проще будет, да и запилить получится быстрее.

https://blog.docker.com/2017/04/introducing-the-moby-project/ Это что, "А теперь с новым вкусомЪ"?

Заменили ченж эт в феникс 1.3?

Контексты это явно то чего не хватало

С точки зрения композиции кода

Да вроде норм было. Хранил все в модели и не запаривался

Ща тоже норм, только по другому

Ну модель жирная это не оч

И зачастую методы используют две

Модели

В такой момент становится непонятно

Какую из моделей в какую испортить

ERROR: S client not available

И работать

Жирная модель норм как по мне. Просто в экто модель - не модель

Из-за этого вся фигня с контекстами

Так конечно лучше

Понятнее станет

Ну две Таблицы когда есть

Это уже и в других языках две модели будет

MSA имеет важный смысл объединения в один технологический процесс реализаций функциональности различных технологических стеков, например держать connections, distribution на Erlang, работу с БД на какой нибудь Java, Ruby, Python, бизнес логику на них же. С точки зрения архитектуры это выгодно тем что проще осуществлять архитектурный контроль и делегировать разработку различных сервисов различным командам так как от каждого сервиса необходима только поддержка протокола. Сервисы могут взаимодействовать либо через Kafka, MQ, либо иные решения и все это удобно мониторить и находить узкие места

Слышал я где-то, что в эрланге можно делать все это и без mq. Не знаю, правда или нет...

Правда, но не нужно

Правда, но не нужно

почему?

Гетерогенные системы сложны в обслуживании.

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

Один ответ на два вопроса: после года жизни production поддержка и развитие функционала системы превратится в очень требовательное к скиллам занятие, станет проблемой потеря ключевых сотрудников, если на этапе проектирования сразу заложить риски то альтернатив не много, если они вообще есть.

После года прода любая система очень требовательна к скилам

Ибо читать чужой код за неделю и за год - разные вещи

Один ответ на два вопроса: после года жизни production поддержка и развитие функционала системы превратится в очень требовательное к скиллам занятие, станет проблемой потеря ключевых сотрудников, если на этапе проектирования сразу заложить риски то альтернатив не много, если они вообще есть.

слегка передергиваешь. Риски, какие например? Если вопрос в спецах, то за год "выращиваются" 1-2 чела и вводятся в курс ))) В последствии, они легко подхватят, если что. Второе, если растет емкость проекта, то она растет не изолированно от самих разрабов! Следовательно и разрабы растут (скилы), не?

Прожект на продакшене не есть сферический конь в вакууме, да еще и изолированный от персонала. Так, что развитие идет норм. )))

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

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

Может и так (сомневаюсь, но не настаиваю), НО! Гетерогенностью такие вопросы вряд-ли решишь, ИМХО.

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

Как то, что микросервисы написаны на разных языках а не на одном улучшает эту ситуацию?

Так у тебя 10 эрланг разработчиков пилят 10 микросервисов. А так один питон разраб пилит один питон микросервис

И ещё один го разраб пилит один микросервис

Гетерогенность даёт возможность забирать лучшее что предоставляет данный стек и объединять все это в один продукт

10 эрлангистов стоят дорого

Гетерогенность даёт возможность забирать лучшее что предоставляет данный стек и объединять все это в один продукт

Короче точка зрения кардинально поменялась. Ну по крайней мере я с ней согласен теперь

Гетерогенность даёт возможность забирать лучшее что предоставляет данный стек и объединять все это в один продукт

Не согласен. Но, в пикеровку вступать не буду, ибо холивар какой-то )))

10 эрлангистов стоят дорого

Да неужели ))) Прям сделал мой вечерЪ )))

10 эрлангистов стоят дорого

Из 10 эрлангистов можно набрать пару толковых, несколько жунов, мидлов там - и нигде не провиснуть

А из одного питониста надо сразу брать звезду

Из 10 эрлангистов можно набрать пару толковых, несколько жунов, мидлов там - и нигде не провиснуть

???