Да, по поводу папочек нелья не отметить алтернативный подход, когда у нас есть папка user и там уже в ней все про это - и инфраструктура, и персистентносиь и сервисы, и апи. А вообще в идеале у каждого файла кода могли бы быть теги. Тогда можно будет и по слоям группировать, и по сущности. В этом плане редакторы кода пока плохо развиваются. Жаль идея Билла Гейтса загнать всю файловую систему в бд не взлетела.
Не подумайте, что я спорю, я всего-лишь ищу истину или новые горизонты. Но вот в языке C# есть механизмы для конструирования классов. Правда не знаю насколько это остается в русле статической типизации. Мне кажется, свободна интерпретируемого языка в том чтобы в процессе выполнения создавать и исполнять код больше относится к метапрограммированию и вроде этот подход не особо распространен.
Для повышения производительности мы чаще используем денормализацию базы или другой вид кэширования, хотя делаем это максимально осторожно, потому что увеличивается количество кода, ответственного за поддержание консистентности.
Я разрабатываю финтех-платформу с командой уже 6 лет. Изначально было около 7 главных микросервисов, потом мы штамповали не глядя еще и дошли до 30, но теперь постепенно схлопываем. Не в рамках отдельного процесса, а между делом. И да, понятно, что парсинг json может занимать 50% нагрузки, но у нас нет миллионов пользователей, у нас их несколько десятков тысяч, и мы умещаемся на десятке серверов в хецнере по 40-50 долларов. И даже если их станет на треть меньше - это не будет существенным фактором для проекта. Возможно даже будет в минус, потому что при отказе железа больше компонентов будет отключено и меньше будет запас под скачки трафика.
Не хватает фактологии в части того, сколько эксплуатационных расходов они могли бы сэкономить, перейдя с json на ProtoBuf, или хотя бы на http 3. Также непонятно какой вклад в рачходы вносит докеризация и виртуализация. Также сомнительно про 90%, потому что тогда сколько нагрузки на серваках субд, которые так просто не сократишь. Допустим, у них было условно 90 серверов бэка и 10 базы, тогда сокращения на 90% достичь практически невозможно.
Для операторов связи симки стоят критически мало. Десятки миллардов на самом деле и не нужно чтобы завалить все спамом, для этого хватает и сотен или тысяч аккаунтов в сутки
Это никак не уменьшает количество левых аккаунтов - в номере телефона 10 цифр, соответственно опсосы могут наделать десятки миллардов аккаунтов. Это даже наоборот увеличивает количество левых аккаунтов, эти опсосы могут даже сознательно сами делать левые аккаунты, продавать левые симки и так далее - делают все, чтобы взять с сервисов деньги. Об этом и была статья - это больше выглядит как дыра в безопасности.
Маркетплейс у них уже есть, даже с функциями доставки, и хитрыми стикерами для оформления заказов прямо в стримах. На самом деле одна их только подсистема стикеров тянет на мегапроект, не говоря уже о более неочевидных вещах. Например, я еще знаю что у людей бывают десятки категорий для любимых сохраненок. Так что инстаграм уже давно суперапп, в котором некоторые проводят 99% смартфонного времени. Так что смех тут немного припоздал.
Зависит от специализации. Но в целом обычно есть всякие бесплатные обучающие видеоуроки по основному фреймворку, с которым нужно работать. Выбираешь что-то максимально популярное и востребованное - реакт или го. По ним можно пару-тройку месяцев позаниматься и поделать уебные проекты. После этого можно учить типовые вопросы и ответы к собеседованию для этих фреймворков. Далее уже пробуешь собеседования, смотришь где отстаешь - там и подтягиваешь.
Я говорил про разложения Дирака и Майораны - если они приводят к разным результатам, то чисто логически их нельзя назвать эквивалентными.
Не звучит как эквивалентность.
Да, по поводу папочек нелья не отметить алтернативный подход, когда у нас есть папка user и там уже в ней все про это - и инфраструктура, и персистентносиь и сервисы, и апи. А вообще в идеале у каждого файла кода могли бы быть теги. Тогда можно будет и по слоям группировать, и по сущности. В этом плане редакторы кода пока плохо развиваются. Жаль идея Билла Гейтса загнать всю файловую систему в бд не взлетела.
Есть годное объяснение о сути этих плагинов?
Не подумайте, что я спорю, я всего-лишь ищу истину или новые горизонты. Но вот в языке C# есть механизмы для конструирования классов. Правда не знаю насколько это остается в русле статической типизации. Мне кажется, свободна интерпретируемого языка в том чтобы в процессе выполнения создавать и исполнять код больше относится к метапрограммированию и вроде этот подход не особо распространен.
А в чем преимущества динамической модели языка программирования?
Для языка C# такая "деструктуризация" переводится обычно как"деконструкция".
Для повышения производительности мы чаще используем денормализацию базы или другой вид кэширования, хотя делаем это максимально осторожно, потому что увеличивается количество кода, ответственного за поддержание консистентности.
Из 10 серверов у нас 4 под два кластера базы, три для бэка, и три специфических для других нужд. По сути даже и сокращать некуда.
Я разрабатываю финтех-платформу с командой уже 6 лет. Изначально было около 7 главных микросервисов, потом мы штамповали не глядя еще и дошли до 30, но теперь постепенно схлопываем. Не в рамках отдельного процесса, а между делом. И да, понятно, что парсинг json может занимать 50% нагрузки, но у нас нет миллионов пользователей, у нас их несколько десятков тысяч, и мы умещаемся на десятке серверов в хецнере по 40-50 долларов. И даже если их станет на треть меньше - это не будет существенным фактором для проекта. Возможно даже будет в минус, потому что при отказе железа больше компонентов будет отключено и меньше будет запас под скачки трафика.
Не хватает фактологии в части того, сколько эксплуатационных расходов они могли бы сэкономить, перейдя с json на ProtoBuf, или хотя бы на http 3. Также непонятно какой вклад в рачходы вносит докеризация и виртуализация. Также сомнительно про 90%, потому что тогда сколько нагрузки на серваках субд, которые так просто не сократишь. Допустим, у них было условно 90 серверов бэка и 10 базы, тогда сокращения на 90% достичь практически невозможно.
Наглядные манипуляции объектами выглядят очень зрелищно.
Я слышал слухи, что EF как-то не особо дружит с паттерном UnitOfWork. Например вот тут:
https://gunnarpeipman.com/ef-core-repository-unit-of-work/
Для операторов связи симки стоят критически мало. Десятки миллардов на самом деле и не нужно чтобы завалить все спамом, для этого хватает и сотен или тысяч аккаунтов в сутки
Это никак не уменьшает количество левых аккаунтов - в номере телефона 10 цифр, соответственно опсосы могут наделать десятки миллардов аккаунтов. Это даже наоборот увеличивает количество левых аккаунтов, эти опсосы могут даже сознательно сами делать левые аккаунты, продавать левые симки и так далее - делают все, чтобы взять с сервисов деньги. Об этом и была статья - это больше выглядит как дыра в безопасности.
А из другой страны симку легко восстановить?
Подтверждения через СМС - это зло, особенно хорошо хто понимаешь, когда лишился доступа к старой симке на которую все оформлено.
Маркетплейс у них уже есть, даже с функциями доставки, и хитрыми стикерами для оформления заказов прямо в стримах. На самом деле одна их только подсистема стикеров тянет на мегапроект, не говоря уже о более неочевидных вещах. Например, я еще знаю что у людей бывают десятки категорий для любимых сохраненок. Так что инстаграм уже давно суперапп, в котором некоторые проводят 99% смартфонного времени. Так что смех тут немного припоздал.
Зависит от специализации. Но в целом обычно есть всякие бесплатные обучающие видеоуроки по основному фреймворку, с которым нужно работать. Выбираешь что-то максимально популярное и востребованное - реакт или го. По ним можно пару-тройку месяцев позаниматься и поделать уебные проекты. После этого можно учить типовые вопросы и ответы к собеседованию для этих фреймворков. Далее уже пробуешь собеседования, смотришь где отстаешь - там и подтягиваешь.
Это лучше вы за меня еще что-нибудь скажите - у вас хорошо получается!