Т.е. вы здесь заявляете, что какой-то хреновины, от которой вы рано или поздно все равно умрёте, не существует? Ну, не всем дано родиться Маклаудами :)
Ок. Итого, в AWS миллион транзакций обойдется мне в 1-2 доллара, а в блокчейне - 1500-2500 долларов. Вот и вся демонстрация почему народ особо в блокчейн и не мигрирует.
Переработки отрицательно влияют на производительность. Каких результатов можно ждать от уставшего и невыспавшегося человека? А сколько убытков принесут ошибки, допущенные от переутомления? А сколько потом придется потратить ВВП на лечение выгорания?
Воочию видел как вместо оптимизации производства тупо заставляют перерабатывать. Я не согласен с тем, что корреляции между переработка и ВВП нет. Уверен, что есть, но обратная. Другой вопрос в том, что выявить эту корреляцию вряд ли получится из-за тех самых аргументов, которые коллеги высказали выше.
НИКОГДА и ни при каких обстоятельствах не используйте rabbit и kafka при работе с мультимедиа! Не пройдете по производительности, а если и пройдете, то на ресурсах разоритесь и задержки будут чрезмерные, причем, нарастающие со временем.
Материалов, описывающих работу с потоковым видео полно, если знать ключевые слова. И ключевые слова здесь ffmpeg, gstreamer и opencv. Это три фреймворка, которые тесно между собой переплетены. Все написаны на C, все работают с протоколами и кодеками различных медиа-потоков, поддерживают все, что необходимо.
Я хренею: до 5 утра в игрушки играть - это терапия такая? Терапия - это нормальный режим и полноценный сон. А игры до 5 - это как алкоголь. Дают лишь сиюминутное наслаждение и добивают в долгосроке.
Все старички сдают. Только в php неожиданный выброс в данных. Самое интересное как раз в 11-20. Именно эти языки выдавливают старичков - Go, Kotlin, Rust.
1. Изначально сделали ставку на десктоп, когда уже лет 10 на рынке известно, что большинство пользователей приходит именно с мобил. Даже если элементарный здравый смысл страдает, то аналитики-то для чего у вас в команде?
В эпоху мультиплатформенных решений типа Flutter, Compose, Xamarin, выбрали нативные решения и (о, как удивительно!) не влезли в сроки.
Даже вместо штатных JS-решений на базе Cordova и др. (им тоже уже лет 10-15) сделали какие-то костыли на WebView. А дальше что? Будете двойной ресурс тратить на полную переделку всего фронта или будете тянуть дальше этот костыль?
Это только фронт. На бэке и в инфраструктуре таких косяков тоже полный мешок. Уже то, что весь Сбер сделал ставку на Виндос и Мак, а Линукс на рабочее место невозможно было выпросить... Неужели еще в 2014-15 годах было не ясно чем все это закончится? Или в 2022-23 годах на государственную платформу устанавливаете OpenShift, принадлежащий RedHat-IBM... Или я не понимаю гениальности плана архитекторов Сбера, или пора вводить за такие вещи уголовную ответственность.
В общем, Сбер в своем репертуаре. Если бы такие косяки допускала небольшая компания, она давно бы уже разорилась. Сбер способен на таких косяках получать еще прибыль исключительно из-за своего монопольного положения на рынке.
Он вполне обоснованно уступает рынок Kotlin-у. Такой консервативности как у Java я не вижу ни у одного другого современного языка. Корутины уже практически все современные языки реализовали, а Java так до сих пор впаривает разрабам CompletableFuture да сторонние реактивные библиотеки. Из Андроида и Вэб-а Java уже почти полностью выгнали. Как я понимаю, только на бэкенде он еще остается усилиями ну уж очень консервативных команд. Это те, кто мне отвечал, что Java лучше Kotlin и что они еще 20 лет будут на Java 8 сидеть.
Вот меня удивляет в российском АйТи то, что все сидят на каком-то устаревшем стеке и гордятся им как последними достижениями человеческой мысли. KMM изначально был временным решением, неким MVP. И после переименования в KMP, он принципиально не поменялся. А вы его тут расхваливает как замену Flutter.
Ничем подобным он никогда не являлся.
Реальной заменой Flutter является Jetbrains Compose Multiplatform, который делается на базе Google Jetpack Compose. И это реальная и мощная замена Flutter-у, а не костыль KMM. И для этого продукта не нужно придумывать надуманные аргументы типа Dart выучить тяжело. Да ничего сложного в нем нет. Не в этом проблема Flutter-а. А в том, что у него канва своя и он плохо учитывает особенности платформ. Да ещё и Dart не стал популярным и экосистема не такая богатая как в других языках.
А если смотреть ещё дальше, то в ближайшие годы развернется серьезная битва между Kotlin и Rust. Но в России об этом узнают лет через 10-15, как всегда.
Т.е. вы не ослили настройку бизнес-процессов разработки и вместо нее разработки очередной язык? Уже то, что вы вдесятером проектирует АПИ, уже изумляет. Считаете новый язык разработать проще? А кто сейчас его поддерживать будет?
OpenAPI довольно развит. К нему есть претензии, но вы когда свой язык до того же уровня доведете? У вас даже толкового описания элементов АПИ не наблюдается. Title, description где у вас? А ограничения формата комментариями?
Вообще-то OpenAPI неплохо кастомизируется. Можно писать собственные шаблоны и генераторы. Можно даже подключать собственные шаблонизаторы. Я так понял, вы эту тему тоже не осилили.
Я так и не увидел у вас как гененится документация. То, что вы показываете, к доке не имеет отношения, а является спекой. Не вижу как вашу спеку можно превратить в табличное описание, которое попадет в руководство по интеграции.
В новой версии OpenAPI поддерживаются асинхронные протоколы. Не только REST. Вы в своем синтаксисе задумывались вообще о других технологиях типа gRPC, Kafka, etc?
Я ничего против разработки АПИ не имею. Я говорю только, что ей не может заниматься сис.аналитик. Тем более б.аналиьик. Ей занимается архитектор или разраб.
Согласование и разработка - это разные процедуры, требующие разных навыков.
Design Specification - это specification, а не design. Если будете причислять к разрабатывающим всех сопричастных, то вам придется причислить и дворников, курьеров и поваров.
Я соглашусь, что на рынке бардак. Вон автор не понимает разницы между сис. и б. аналитиками. Много где аналитики принимают архитектурные решения. Ну так потом и имеем кошмар на проектах.
Заканчивать надо с монолитами. Тогда и обновление версии языка в системе будет подешевле, чем полет на Луну, обходиться.
Т.е. вы здесь заявляете, что какой-то хреновины, от которой вы рано или поздно все равно умрёте, не существует? Ну, не всем дано родиться Маклаудами :)
А загуглить слово "serverless" религия не позволяет :)))))))
Смотря с чем сравнивать. Полно человеческих переводов, которые вообще ни в зуб ногой.
Логика в статье: "Мне уже 50 лет предсказывают, что я умру. Я за эти 50 лет не умер, значит они все враки и я не умру никогда."
Ок. Итого, в AWS миллион транзакций обойдется мне в 1-2 доллара, а в блокчейне - 1500-2500 долларов. Вот и вся демонстрация почему народ особо в блокчейн и не мигрирует.
И сколько все это стоит?
Одна транзакция в смарт контракте по моим оценкам где-то в 10-100 тыс раз дороже, чем такая же, но в облаке.
Переработки отрицательно влияют на производительность. Каких результатов можно ждать от уставшего и невыспавшегося человека? А сколько убытков принесут ошибки, допущенные от переутомления? А сколько потом придется потратить ВВП на лечение выгорания?
Воочию видел как вместо оптимизации производства тупо заставляют перерабатывать. Я не согласен с тем, что корреляции между переработка и ВВП нет. Уверен, что есть, но обратная. Другой вопрос в том, что выявить эту корреляцию вряд ли получится из-за тех самых аргументов, которые коллеги высказали выше.
Любую обработку надо делать на указанных фреймворках. Rmq вообще для видео не подходит. Это как молотком в зубах ковыряться.
НИКОГДА и ни при каких обстоятельствах не используйте rabbit и kafka при работе с мультимедиа! Не пройдете по производительности, а если и пройдете, то на ресурсах разоритесь и задержки будут чрезмерные, причем, нарастающие со временем.
Материалов, описывающих работу с потоковым видео полно, если знать ключевые слова. И ключевые слова здесь ffmpeg, gstreamer и opencv. Это три фреймворка, которые тесно между собой переплетены. Все написаны на C, все работают с протоколами и кодеками различных медиа-потоков, поддерживают все, что необходимо.
Иероглифическая письменность, если вы не заметили, тоже является отдельным языком со своей грамматикой, хоть и не обладает произношением.
Я хренею: до 5 утра в игрушки играть - это терапия такая? Терапия - это нормальный режим и полноценный сон. А игры до 5 - это как алкоголь. Дают лишь сиюминутное наслаждение и добивают в долгосроке.
Все старички сдают. Только в php неожиданный выброс в данных. Самое интересное как раз в 11-20. Именно эти языки выдавливают старичков - Go, Kotlin, Rust.
Не знаю, чем тут в статье гордиться?
1. Изначально сделали ставку на десктоп, когда уже лет 10 на рынке известно, что большинство пользователей приходит именно с мобил. Даже если элементарный здравый смысл страдает, то аналитики-то для чего у вас в команде?
В эпоху мультиплатформенных решений типа Flutter, Compose, Xamarin, выбрали нативные решения и (о, как удивительно!) не влезли в сроки.
Даже вместо штатных JS-решений на базе Cordova и др. (им тоже уже лет 10-15) сделали какие-то костыли на WebView. А дальше что? Будете двойной ресурс тратить на полную переделку всего фронта или будете тянуть дальше этот костыль?
Это только фронт. На бэке и в инфраструктуре таких косяков тоже полный мешок. Уже то, что весь Сбер сделал ставку на Виндос и Мак, а Линукс на рабочее место невозможно было выпросить... Неужели еще в 2014-15 годах было не ясно чем все это закончится? Или в 2022-23 годах на государственную платформу устанавливаете OpenShift, принадлежащий RedHat-IBM... Или я не понимаю гениальности плана архитекторов Сбера, или пора вводить за такие вещи уголовную ответственность.
В общем, Сбер в своем репертуаре. Если бы такие косяки допускала небольшая компания, она давно бы уже разорилась. Сбер способен на таких косяках получать еще прибыль исключительно из-за своего монопольного положения на рынке.
Он вполне обоснованно уступает рынок Kotlin-у. Такой консервативности как у Java я не вижу ни у одного другого современного языка. Корутины уже практически все современные языки реализовали, а Java так до сих пор впаривает разрабам CompletableFuture да сторонние реактивные библиотеки.
Из Андроида и Вэб-а Java уже почти полностью выгнали. Как я понимаю, только на бэкенде он еще остается усилиями ну уж очень консервативных команд. Это те, кто мне отвечал, что Java лучше Kotlin и что они еще 20 лет будут на Java 8 сидеть.
Вот меня удивляет в российском АйТи то, что все сидят на каком-то устаревшем стеке и гордятся им как последними достижениями человеческой мысли. KMM изначально был временным решением, неким MVP. И после переименования в KMP, он принципиально не поменялся. А вы его тут расхваливает как замену Flutter.
Ничем подобным он никогда не являлся.
Реальной заменой Flutter является Jetbrains Compose Multiplatform, который делается на базе Google Jetpack Compose. И это реальная и мощная замена Flutter-у, а не костыль KMM. И для этого продукта не нужно придумывать надуманные аргументы типа Dart выучить тяжело. Да ничего сложного в нем нет. Не в этом проблема Flutter-а. А в том, что у него канва своя и он плохо учитывает особенности платформ. Да ещё и Dart не стал популярным и экосистема не такая богатая как в других языках.
А если смотреть ещё дальше, то в ближайшие годы развернется серьезная битва между Kotlin и Rust. Но в России об этом узнают лет через 10-15, как всегда.
На Али два девайса продают. Две буквы отличия, а разница существенна. Флэшь у одного 2, у другого 16 Мб.
Интернет кишит конвертерами "примерчик на json"->OpenAPI.
Т.е. вы не ослили настройку бизнес-процессов разработки и вместо нее разработки очередной язык? Уже то, что вы вдесятером проектирует АПИ, уже изумляет. Считаете новый язык разработать проще? А кто сейчас его поддерживать будет?
OpenAPI довольно развит. К нему есть претензии, но вы когда свой язык до того же уровня доведете? У вас даже толкового описания элементов АПИ не наблюдается. Title, description где у вас? А ограничения формата комментариями?
Вообще-то OpenAPI неплохо кастомизируется. Можно писать собственные шаблоны и генераторы. Можно даже подключать собственные шаблонизаторы. Я так понял, вы эту тему тоже не осилили.
Я так и не увидел у вас как гененится документация. То, что вы показываете, к доке не имеет отношения, а является спекой. Не вижу как вашу спеку можно превратить в табличное описание, которое попадет в руководство по интеграции.
В новой версии OpenAPI поддерживаются асинхронные протоколы. Не только REST. Вы в своем синтаксисе задумывались вообще о других технологиях типа gRPC, Kafka, etc?
Я ничего против разработки АПИ не имею. Я говорю только, что ей не может заниматься сис.аналитик. Тем более б.аналиьик. Ей занимается архитектор или разраб.
Согласование и разработка - это разные процедуры, требующие разных навыков.
Design Specification - это specification, а не design. Если будете причислять к разрабатывающим всех сопричастных, то вам придется причислить и дворников, курьеров и поваров.
Я соглашусь, что на рынке бардак. Вон автор не понимает разницы между сис. и б. аналитиками. Много где аналитики принимают архитектурные решения. Ну так потом и имеем кошмар на проектах.