не увидел основной части любого ремоута, это захват и обработка видеопотока с его передачей. Как захватывает? Что дальше в пайплайне? Кодек небось тупо h264 или vp8. Вы в итоге что написали то, гуи обертку скопированную? Обычный клон, который не будет нормально работать в полевых условиях. Попробуйте продумать и сделать rdp систему на замену anydesk, тогда поймете разницу.
какую бы модель бизнеса не рассматривали, ваши айти гонки никому не нужны, если они финансово не обоснованы. Качество кода вообще никому не важно кроме вас, это все затраты на поддержание, которые будут именно потом, а не сейчас.
Ух, половина постов "ии круто", вторая "ии говно". Это просто инструмент и им надо уметь пользоваться, а мы только начали это делать и инструмент кривой плюс постоянно меняется. Не надо гвозди забивать микроскопом и все нормально будет. Даже в крупных проектах можно использовать, просто понимать надо возможности инструмента и не скармливать ему весь проекта хрома в надежде "вдруг запомнит" =)
В правильном направлении идете. Все то что мы сейчас применяем на людях в крупных проектах необходимо и приходится применять на ИИ на проектах всех размеров. Это как сказать джуну "сделай сайт" или показать ему детальную спецификацию. У меня при проработке подобной схемы возник только один вопрос, в каком виде сейчас описывать и отдавать требования ИИ, чтоб он их лучше всего понимал. Чего бы хотелось от подобной системы в будущем: минимизация первых двух этапов - сбор/анализ/описание требований и построение архитектуры. ИИ должен максимально эффективно помогать в этом, да это сложная задача, особенно учитывая что требования постоянно меняются (и это тоже надо учитывать), но человек допускает много ошибок (пропускает именно на этих этапах), а зачастую просто игнорирует это все и программирует как есть. Так же считаю для подобных систем, да и для ИИ в принципе, необходимо использовать доступные системы верификации кода. Например, boogie + z3 можно прикрутить к некоторым местам, но это уже расширение.
Жаль не ставятся комменты к минусам, чего минусят не понятно.. Да тяжелый, это же очевидно из протокола, rest с json избыточен, хоть как его сжимай бротли/зипом/дефлейтом. Т.е. по-простому: куча сжатого хоть и повторяющегося текста всегда будет хуже заранее предопределенного бинарного пакета. Измерял уже дотнетовский грпс и не я один. Если можете сервер в с++, то задержки еще меньше будут. Да размер клиента будет побольше, но не 20мбайт никак, 667 кб весит протобаф и грпс для wpf, например. Да где-то не работает хттп 2, но доступен хттп 1.1 и это все равно лучше чем рест получается, quick (хттп 3) в вин11 есть и можно в никсах подключить через бубен (не тестировал, но по судя по изменениям протокола еще быстрее работать будет). Конечно для каждого проекта нужно тестировать отдельно все, но сделать клиент и сервер на шарпе для пары унарных методов проще простого. У всех свои причины перейти на грпс, я это делал для уменьшения трафика и задержек в мобильном и впф клиенте. Если кто тестил грпс в хттп3 киньте результаты сравнения с хттп 2, интересно.
grpc может работать через любой хттп, ничто не мешает использовать его в веб клиенте. Вообще учитывая скорость передачи и задержки везде бы использовал его, а не тяжелый рест с жсоном
Далек от темы космоса, по данным вики до запуска первых тестовых 60 спутников старлинк прошло минимум 4 года. У нас запустили первый через такой же промежуток времени. Далее сравните бюджет выделенный на старлинк и сферу, он в 50 раз больше. Не понятно сколько и там, и там ушло на R&D, но все же делить на кол-во спутников не совсем корректно, т.к. не мы как минимум еще не все вывели. Все нормально, имхо, понятно что отстаем, но системы разные, назначение отличается и т.д.
Поясните, пожалуйста, зачем сис/биз аналитику знать разницу между субд? Это проблемы архитектора, разве нет? Про бизнес аналитиков знаю, кто такие системные не особо. Они могут предлагать варианты реализации? От бизнес аналитика мы получаем результат "бизнесс процессы должны быть вот такие", что выдает системный? По статье хотел сказать: экономику знать надо ещё и предметную область, это самое важное имхо, после опыта конечно. В книжках все это хорошо и красиво, на практике все в стиле "впихнуть невпихиваемое".
Вспомните еще циклы с i, j, k и прочее. Можно, потому что при обучении упрощают нагрузку на обучаемого ограничиваясь областью изложения. Наименование классов/методов/переменных и т.п. это отдельная тема по который разработчик должен отдельно и обязательно быть обучен.
Используйте другие технологии, изобретайте новые, хватит ныть и и пить. У нас в любой области непаханый край работы в любой точке мира. Запретили arm? Придумайте новый. Заблокировали дот нет? Сделайте свой. Кончился виндус? Привет никсы.Жизнь течет, все меняется, мне например всегда будет чем заняться, даже если текущий стек канет в лету по какой-то причине. Никто не отнимет у меня программирование, это невозможно в принципе. Можно забрать у композитора пианино, но он останется композитором.
Кнут отталкивает сложностью, он интересный да, полезный - безусловно, но Дональд прежде всего математик и ее там хватает с лихвой на очень не слабом уровне. Новички не могут его читать.
не увидел основной части любого ремоута, это захват и обработка видеопотока с его передачей. Как захватывает? Что дальше в пайплайне? Кодек небось тупо h264 или vp8. Вы в итоге что написали то, гуи обертку скопированную? Обычный клон, который не будет нормально работать в полевых условиях. Попробуйте продумать и сделать rdp систему на замену anydesk, тогда поймете разницу.
какую бы модель бизнеса не рассматривали, ваши айти гонки никому не нужны, если они финансово не обоснованы. Качество кода вообще никому не важно кроме вас, это все затраты на поддержание, которые будут именно потом, а не сейчас.
потому что в большинстве случаев прибыль здесь и сейчас лучше чем потом, даже если больше.
Ух, половина постов "ии круто", вторая "ии говно". Это просто инструмент и им надо уметь пользоваться, а мы только начали это делать и инструмент кривой плюс постоянно меняется. Не надо гвозди забивать микроскопом и все нормально будет. Даже в крупных проектах можно использовать, просто понимать надо возможности инструмента и не скармливать ему весь проекта хрома в надежде "вдруг запомнит" =)
В правильном направлении идете. Все то что мы сейчас применяем на людях в крупных проектах необходимо и приходится применять на ИИ на проектах всех размеров. Это как сказать джуну "сделай сайт" или показать ему детальную спецификацию. У меня при проработке подобной схемы возник только один вопрос, в каком виде сейчас описывать и отдавать требования ИИ, чтоб он их лучше всего понимал. Чего бы хотелось от подобной системы в будущем: минимизация первых двух этапов - сбор/анализ/описание требований и построение архитектуры. ИИ должен максимально эффективно помогать в этом, да это сложная задача, особенно учитывая что требования постоянно меняются (и это тоже надо учитывать), но человек допускает много ошибок (пропускает именно на этих этапах), а зачастую просто игнорирует это все и программирует как есть. Так же считаю для подобных систем, да и для ИИ в принципе, необходимо использовать доступные системы верификации кода. Например, boogie + z3 можно прикрутить к некоторым местам, но это уже расширение.
Жаль не ставятся комменты к минусам, чего минусят не понятно.. Да тяжелый, это же очевидно из протокола, rest с json избыточен, хоть как его сжимай бротли/зипом/дефлейтом. Т.е. по-простому: куча сжатого хоть и повторяющегося текста всегда будет хуже заранее предопределенного бинарного пакета. Измерял уже дотнетовский грпс и не я один. Если можете сервер в с++, то задержки еще меньше будут. Да размер клиента будет побольше, но не 20мбайт никак, 667 кб весит протобаф и грпс для wpf, например. Да где-то не работает хттп 2, но доступен хттп 1.1 и это все равно лучше чем рест получается, quick (хттп 3) в вин11 есть и можно в никсах подключить через бубен (не тестировал, но по судя по изменениям протокола еще быстрее работать будет). Конечно для каждого проекта нужно тестировать отдельно все, но сделать клиент и сервер на шарпе для пары унарных методов проще простого. У всех свои причины перейти на грпс, я это делал для уменьшения трафика и задержек в мобильном и впф клиенте. Если кто тестил грпс в хттп3 киньте результаты сравнения с хттп 2, интересно.
grpc может работать через любой хттп, ничто не мешает использовать его в веб клиенте. Вообще учитывая скорость передачи и задержки везде бы использовал его, а не тяжелый рест с жсоном
Далек от темы космоса, по данным вики до запуска первых тестовых 60 спутников старлинк прошло минимум 4 года. У нас запустили первый через такой же промежуток времени. Далее сравните бюджет выделенный на старлинк и сферу, он в 50 раз больше. Не понятно сколько и там, и там ушло на R&D, но все же делить на кол-во спутников не совсем корректно, т.к. не мы как минимум еще не все вывели. Все нормально, имхо, понятно что отстаем, но системы разные, назначение отличается и т.д.
Поясните, пожалуйста, зачем сис/биз аналитику знать разницу между субд? Это проблемы архитектора, разве нет? Про бизнес аналитиков знаю, кто такие системные не особо. Они могут предлагать варианты реализации? От бизнес аналитика мы получаем результат "бизнесс процессы должны быть вот такие", что выдает системный? По статье хотел сказать: экономику знать надо ещё и предметную область, это самое важное имхо, после опыта конечно. В книжках все это хорошо и красиво, на практике все в стиле "впихнуть невпихиваемое".
Вспомните еще циклы с i, j, k и прочее. Можно, потому что при обучении упрощают нагрузку на обучаемого ограничиваясь областью изложения. Наименование классов/методов/переменных и т.п. это отдельная тема по который разработчик должен отдельно и обязательно быть обучен.
Используйте другие технологии, изобретайте новые, хватит ныть и и пить. У нас в любой области непаханый край работы в любой точке мира. Запретили arm? Придумайте новый. Заблокировали дот нет? Сделайте свой. Кончился виндус? Привет никсы.Жизнь течет, все меняется, мне например всегда будет чем заняться, даже если текущий стек канет в лету по какой-то причине. Никто не отнимет у меня программирование, это невозможно в принципе. Можно забрать у композитора пианино, но он останется композитором.
Кнут отталкивает сложностью, он интересный да, полезный - безусловно, но Дональд прежде всего математик и ее там хватает с лихвой на очень не слабом уровне. Новички не могут его читать.