Вот потому и не люблю питон, питонистов уже пруд пруди и все начинают выдумывать свой велосипед с громкими заявлениями смотрите что я придумал.
Не учите питон, учите мат. часть.
Интерестна криптография, начинайте с азов, базовых алгоритмов и подходов и тогда не надо будет писать статьи на хабре и спрашивать: "Кто знает что это такое?"
Как использовать функции для работы с json на уровне postgesql вообще неописано, да я если честно не очень понимаю что на уровне orm можно из этого использовать и для чего?
Если уж пошла такая пьянка то postgresql может и из текстового поля сделать json или jsonb и может применить к ним свою проприепритарную магию работы со встроенными не реляционными типами.
Если уж ковырять дальше то основное применение этих типов это построение NoSql хранилищ, в этой парадигме orm с мапингом на типы наверное не самое лучшее решение.
Мы на своём проекте активно используем json и jsonb, но то совсем другая песня, у нас много рантайм генерации типов и мы мапим их из сложных json объектов.
Не сказано про особенность хранения json и jsonb.
А вряде случаев это существенно, помимо того что jsonb хранит бинарный вариант, а не текстовый он меняет порядок следования полей в объекте для более эффектмвного хранения и обработки. Эту особенность надо учитывать при чтении объектов.
Generic в TS присутствует, но в следствии номинальной типизации решение на них будет мало чем отличаться от перегрузки с кучей не обязательных параметров.
К примеру вариант Sum, но не для простых типов, а скажем для Point и Vector это превратится в такой же If с анализом типа, а если типов объектов будет больше то и код разрастётся.
В целом TS хорош, и против Js это огромный шаг вперёд. Но так как это всего лишь надстройка, многие вещи реализованны крайне не удобно
Большая часть проблем надумана и если подходить к ним с точки зрения что менять страшно и сломаеться, то наверное стоит вообще завязывать с разработкой и архитектурой, ну не всем это дано.
Практически не существует плохой архитектуры, есть только неумение её готовить или попытка натягивания её туда где она ну уж совсем не к месту.
И заголовок бы привели к какому одному поняитию.
Есть интеграция на уровне БД
Есть шаблон общая БД.
И есть интеграционная БД, про которую в статье нет вообще ничего.
Интеграционная БД это сущность схожая по функциональности с BFF, то-есть она предоставляет доступ внешним сервисам к данным не в том виде как они храняться, а в том виде как с ними удобно работать, как правило только на чтение, как правильно это вообще БД на движке отличном от основной БД, ориентированная на решение своей узко спкциализированной задачи.
Сколько холивара на пустом месте, посыл автора очень простой, не усложняйте то что можно оставить простым. Где тут было хоть слово про правильность приведённых примеров как истины последней инстанции? Это же просто примеры, они могут быть как хорошие так и плохие по коду или оформлению, но должны решать свою задачу, и тут они с задачей справились.
Реализаций может бесчисленно множество, вплоть до реализации своего мини крона. Но тут вопрос зачем это всё? Где тут усмотрели требования к точности? Или требования к незапуску второго процесса пока не закончился первый? Откуда вообще взялось столько домыслоф о которых автор нигде даже косвенно не упоминал?
Почему бы не выкинуть битрикс, развели зоопарк во главе с химерой в лице битрикса, и героически бьються с мельницами и франкештейном в лице битрикса. Время потраченное на ковырянее в плохой архитектуре можно было с лёгкостью потратить на написание хорошо спроектированного портала для которого ни жалкие 150 rps, а даже 1500 rps будут не проблемой. Вообще в нашем мире говорить о 150 rps говорить мягко говоря уже не прилично, лет 10-20 назад когда только начал активно набирать обороты e-commerc и когда негде было черпать ответы как же это делаеться, тогда ещё да.
Вообще не понятно о чём и для кого статья, выглядит как, мы не очень умеем готовить redis, поэтому нам понадобился эластик, но мы не понимаем зачем, поэтому теперь есть и то и другое, и ещё mySql. И какие мы молодцы, не понимая как выжать максимум из того что есть, размазали везде по чуть-чуть, и стало сильно лучше.
Эти отличия говорят только об одном. За PayPal стоит регулятор, и он же являеться гарантом легитимности проведённых транзакций. Если бы там были не живые деньги, а скажем тугрики или фантики, он так же был бы лешён этих отличий, так как ни одной стране мира не интерестно ничего кроме собственной валюты и конверсии её в валюты других стран. И не считая доллара валюты по большой части имеют обеспечение со стороны эмитента который и являеться её гарантом.
НО. В мире high-load и BigData о которых нам кричат на каждом углу и которые анонсирую в дата центрах сбера, мтс и прочих крупных игроков, жалкие 100к записей даже за данные не считают. Это семечки.
Зачем было такой огород городить, любая бд на более ли менее живом железе с мигрирует записи за несколько секунд.
Мы поднимали реплики между совершенно не совмесимыми БД, и они прокачивали гигабайтные базы данные в оба направления практически не имея нагрузок.
Что и зачем делали эти 15 человек? Почему было не взять готовое, проверенно решение? Или свой велосипед всегда лучше?
Хотя да, наверное у таких серьёзных продуктов есть и серьёзное финансирование, поэтому работа ради работы это в порядке вещей.
Автор прав что каждый язык по своему хорош, но я бы сказал что и каждый язык для своих задач. Нельзя точно сказать на каком языке кода больше, всё зависит от задачи. Например brain fuck, кода минимум, но что на нём можно решить?
И уже давно на вопрос как грузить данные ответили простым подходом, разделяй и влавствуй. Например разбить бд на кусочки, и не дрюгать всю бд целиком, а выполнить n+1 запрос к разным частям данных? Профит мне кажеться куда больше чем грузить из одного источника кусками.
Да query params были проблемой, но так как мы активно используем Reactive.Net написать обёртку делов на пол часа. Анимации, работа с графикой, всё прекрасно работает. Для WebGl есть билблиотека SkiaSharp. Мы тоже рендерим Xaml разметку в Canvas, отлично работает.
Когда завезут много поточность будет вообще сказка.
Собственно причина использования проста, мы не стремимся использовать Blazor как фреймворк веб разработки, напротив мы идём в сторону приближения его к Desktop подходам и MVVM.
Я бы посоветовал вообще больше времени уделять Research и меньше странным пабликам на хабре. Всё описанное в статье решаеться гораздо более простыми великами. Для компании которая имеет такой штат разработчиков не написать своё кастомное решение для доставки образов стыд и срам, работать с шифрованными секретами можно, для этого надо чуть чуть расширить кубик своими плагинами и всё. Опять же если компания позиционрует себя как опытного потребителя кубика то не иметь таких кастомных расширений она просто не может.
И да, я понимаю что поддержка любой кастомщины сложное дело, но мы ведь говорим не о команде из 2-х разрпботчиков, а о целом огромном подразделении которое отвечает за эксплуатацию всего этого хозяйства. Мы у себя закастомили очень многое, и мы не ВК, мы как раз скорее амбициозный стартап, и нам это оказалось по силам))))
Ну как бы сам проект что-то не то. До этого попадалась статья, как они перформили картинки и мультимедия тут же зашол в вк на компе музыку послушать и вижу что картинки тупо не грузяться, а я не жалуюсь на канал у меня чистые 100 мб, могу любую картинку затащить)))
Нельзя, если SetA равен null код упадёт. Его надо проверить на null, а вот второе сравнение опустить и сразу сравнить с обектом.
Хотя с точки зрения статьи это лишннее, статья не про оптимальную реализацию алгоритма, а про реализацию как таковую. Поэтому все что можно расписать расписано, хотя это и кажеться излишним.
Это очередная попытка как и uno platform. При чём попытка реально достойная, но к сожалению тоже далеко не идеальная. Если выбирать между maui и avalon я бы выбрал всё же первое. Для нас единственным возможным плюсом мог бы стать рендеринг web через canvas, но он оказался настолько кривым что оно того не стоило совсем.
Но в целом, с учётом того что avalon собран на голом энтузиазме, решение крайне достойное!!!!
Ждём когда домучают skiasharp и надо будет смотреть на всё это в одной связке.
Статья печалька, много умных слов мало умных мыслей.
Grpc как и rest работает поверх HTTP, как это ни странно)) Использует HTTP/2 да это хорошо, но он требует SSL, что наводит на мысль что при маленьких запросах затраты на согласование коннектов будут не соизмеримы с временем выполния самого запроса, это надо учитывать.
То что rest не умеет Contract first, бред полный.
Подход зависит от инструментов, хотите Contract first будет он, с генерацией не только контроллеров но клиенсткой стороны скажем на TS или каком другом языке.
openapi описывает контракты и они не обязательны, вы сами то себя слышите?
То-есть схема вам говорит я жду обект типа А с полями 1 и 2 такого-то типа, вы уверенно пихаете в метод болт и он у вас проходит так что-ли получаеться? Ну если у вас так продукт построен то мне жаль деньги потраченные на его развитие.
Senjor - это звучит конечно круто, но по сути изложения статьи я бы к себе на проект и джуном не взял.
Вот потому и не люблю питон, питонистов уже пруд пруди и все начинают выдумывать свой велосипед с громкими заявлениями смотрите что я придумал.
Не учите питон, учите мат. часть.
Интерестна криптография, начинайте с азов, базовых алгоритмов и подходов и тогда не надо будет писать статьи на хабре и спрашивать: "Кто знает что это такое?"
Отличная статья, один вопрос.
А зачем?
Столько манипуляций, столько сложностей.
Какую проблему или задачу хотели решить?
Как использовать функции для работы с json на уровне postgesql вообще неописано, да я если честно не очень понимаю что на уровне orm можно из этого использовать и для чего?
Если уж пошла такая пьянка то postgresql может и из текстового поля сделать json или jsonb и может применить к ним свою проприепритарную магию работы со встроенными не реляционными типами.
Если уж ковырять дальше то основное применение этих типов это построение NoSql хранилищ, в этой парадигме orm с мапингом на типы наверное не самое лучшее решение.
Мы на своём проекте активно используем json и jsonb, но то совсем другая песня, у нас много рантайм генерации типов и мы мапим их из сложных json объектов.
Не сказано про особенность хранения json и jsonb.
А вряде случаев это существенно, помимо того что jsonb хранит бинарный вариант, а не текстовый он меняет порядок следования полей в объекте для более эффектмвного хранения и обработки. Эту особенность надо учитывать при чтении объектов.
Generic в TS присутствует, но в следствии номинальной типизации решение на них будет мало чем отличаться от перегрузки с кучей не обязательных параметров.
К примеру вариант Sum, но не для простых типов, а скажем для Point и Vector это превратится в такой же If с анализом типа, а если типов объектов будет больше то и код разрастётся.
В целом TS хорош, и против Js это огромный шаг вперёд. Но так как это всего лишь надстройка, многие вещи реализованны крайне не удобно
Большая часть проблем надумана и если подходить к ним с точки зрения что менять страшно и сломаеться, то наверное стоит вообще завязывать с разработкой и архитектурой, ну не всем это дано.
Практически не существует плохой архитектуры, есть только неумение её готовить или попытка натягивания её туда где она ну уж совсем не к месту.
И заголовок бы привели к какому одному поняитию.
Есть интеграция на уровне БД
Есть шаблон общая БД.
И есть интеграционная БД, про которую в статье нет вообще ничего.
Интеграционная БД это сущность схожая по функциональности с BFF, то-есть она предоставляет доступ внешним сервисам к данным не в том виде как они храняться, а в том виде как с ними удобно работать, как правило только на чтение, как правильно это вообще БД на движке отличном от основной БД, ориентированная на решение своей узко спкциализированной задачи.
Статью писал человек совсем далёкий от Net.
Все примеры кривые, для коллекций например есть IReadOnlyCollection. Есть как верно подмечено инициаторы.
Да и всё уже давно придумано за нас.
То-есть написать класс с конструктором и приватными сеттерами это ой-ой-ой какая жуть, а наогородить кучу кода с рефлексией это респектос?
Подход конечно огонь!!!!
Если уж рефлексируете то хоть кешируйте результаты, по секрету скажу у одного и того же типа обьёктов полей в рантайме не прибавиться))))
Сколько холивара на пустом месте, посыл автора очень простой, не усложняйте то что можно оставить простым. Где тут было хоть слово про правильность приведённых примеров как истины последней инстанции? Это же просто примеры, они могут быть как хорошие так и плохие по коду или оформлению, но должны решать свою задачу, и тут они с задачей справились.
Реализаций может бесчисленно множество, вплоть до реализации своего мини крона. Но тут вопрос зачем это всё? Где тут усмотрели требования к точности? Или требования к незапуску второго процесса пока не закончился первый? Откуда вообще взялось столько домыслоф о которых автор нигде даже косвенно не упоминал?
Почему бы не выкинуть битрикс, развели зоопарк во главе с химерой в лице битрикса, и героически бьються с мельницами и франкештейном в лице битрикса. Время потраченное на ковырянее в плохой архитектуре можно было с лёгкостью потратить на написание хорошо спроектированного портала для которого ни жалкие 150 rps, а даже 1500 rps будут не проблемой. Вообще в нашем мире говорить о 150 rps говорить мягко говоря уже не прилично, лет 10-20 назад когда только начал активно набирать обороты e-commerc и когда негде было черпать ответы как же это делаеться, тогда ещё да.
Вообще не понятно о чём и для кого статья, выглядит как, мы не очень умеем готовить redis, поэтому нам понадобился эластик, но мы не понимаем зачем, поэтому теперь есть и то и другое, и ещё mySql. И какие мы молодцы, не понимая как выжать максимум из того что есть, размазали везде по чуть-чуть, и стало сильно лучше.
Эти отличия говорят только об одном. За PayPal стоит регулятор, и он же являеться гарантом легитимности проведённых транзакций. Если бы там были не живые деньги, а скажем тугрики или фантики, он так же был бы лешён этих отличий, так как ни одной стране мира не интерестно ничего кроме собственной валюты и конверсии её в валюты других стран. И не считая доллара валюты по большой части имеют обеспечение со стороны эмитента который и являеться её гарантом.
Да либа делает одну вещь и хорошо, сажает производительность.
Я конечно не великий специалист))))
НО. В мире high-load и BigData о которых нам кричат на каждом углу и которые анонсирую в дата центрах сбера, мтс и прочих крупных игроков, жалкие 100к записей даже за данные не считают. Это семечки.
Зачем было такой огород городить, любая бд на более ли менее живом железе с мигрирует записи за несколько секунд.
Мы поднимали реплики между совершенно не совмесимыми БД, и они прокачивали гигабайтные базы данные в оба направления практически не имея нагрузок.
Что и зачем делали эти 15 человек? Почему было не взять готовое, проверенно решение? Или свой велосипед всегда лучше?
Хотя да, наверное у таких серьёзных продуктов есть и серьёзное финансирование, поэтому работа ради работы это в порядке вещей.
Автор прав что каждый язык по своему хорош, но я бы сказал что и каждый язык для своих задач. Нельзя точно сказать на каком языке кода больше, всё зависит от задачи. Например brain fuck, кода минимум, но что на нём можно решить?
Решение не просто не ново, оно старо как мир.
И уже давно на вопрос как грузить данные ответили простым подходом, разделяй и влавствуй. Например разбить бд на кусочки, и не дрюгать всю бд целиком, а выполнить n+1 запрос к разным частям данных? Профит мне кажеться куда больше чем грузить из одного источника кусками.
У нас проект прекрасно живёт на Blazor.
Да query params были проблемой, но так как мы активно используем Reactive.Net написать обёртку делов на пол часа. Анимации, работа с графикой, всё прекрасно работает. Для WebGl есть билблиотека SkiaSharp. Мы тоже рендерим Xaml разметку в Canvas, отлично работает.
Когда завезут много поточность будет вообще сказка.
Собственно причина использования проста, мы не стремимся использовать Blazor как фреймворк веб разработки, напротив мы идём в сторону приближения его к Desktop подходам и MVVM.
Я бы посоветовал вообще больше времени уделять Research и меньше странным пабликам на хабре. Всё описанное в статье решаеться гораздо более простыми великами. Для компании которая имеет такой штат разработчиков не написать своё кастомное решение для доставки образов стыд и срам, работать с шифрованными секретами можно, для этого надо чуть чуть расширить кубик своими плагинами и всё. Опять же если компания позиционрует себя как опытного потребителя кубика то не иметь таких кастомных расширений она просто не может.
И да, я понимаю что поддержка любой кастомщины сложное дело, но мы ведь говорим не о команде из 2-х разрпботчиков, а о целом огромном подразделении которое отвечает за эксплуатацию всего этого хозяйства. Мы у себя закастомили очень многое, и мы не ВК, мы как раз скорее амбициозный стартап, и нам это оказалось по силам))))
Ну как бы сам проект что-то не то. До этого попадалась статья, как они перформили картинки и мультимедия тут же зашол в вк на компе музыку послушать и вижу что картинки тупо не грузяться, а я не жалуюсь на канал у меня чистые 100 мб, могу любую картинку затащить)))
Блин, есть же компилируемые деревья, они для этого созданы, ускорить стандартный Linq
Да, их я упустил. Тогда вы правы, условие лишнее
Нельзя, если SetA равен null код упадёт. Его надо проверить на null, а вот второе сравнение опустить и сразу сравнить с обектом.
Хотя с точки зрения статьи это лишннее, статья не про оптимальную реализацию алгоритма, а про реализацию как таковую. Поэтому все что можно расписать расписано, хотя это и кажеться излишним.
На самом деле авлония не лучше и не хуже.
Это очередная попытка как и uno platform. При чём попытка реально достойная, но к сожалению тоже далеко не идеальная. Если выбирать между maui и avalon я бы выбрал всё же первое. Для нас единственным возможным плюсом мог бы стать рендеринг web через canvas, но он оказался настолько кривым что оно того не стоило совсем.
Но в целом, с учётом того что avalon собран на голом энтузиазме, решение крайне достойное!!!!
Ждём когда домучают skiasharp и надо будет смотреть на всё это в одной связке.
Статья печалька, много умных слов мало умных мыслей.
Grpc как и rest работает поверх HTTP, как это ни странно)) Использует HTTP/2 да это хорошо, но он требует SSL, что наводит на мысль что при маленьких запросах затраты на согласование коннектов будут не соизмеримы с временем выполния самого запроса, это надо учитывать.
То что rest не умеет Contract first, бред полный.
Подход зависит от инструментов, хотите Contract first будет он, с генерацией не только контроллеров но клиенсткой стороны скажем на TS или каком другом языке.
openapi описывает контракты и они не обязательны, вы сами то себя слышите?
То-есть схема вам говорит я жду обект типа А с полями 1 и 2 такого-то типа, вы уверенно пихаете в метод болт и он у вас проходит так что-ли получаеться? Ну если у вас так продукт построен то мне жаль деньги потраченные на его развитие.
Senjor - это звучит конечно круто, но по сути изложения статьи я бы к себе на проект и джуном не взял.