Вы знаете, я прочитал простыню автора, его ответы, которые он как нейронкой пишет, и не знаю что тут сказать хорошего. В Бразилии много хороших программистов, и реалии своей страны они знают лучше. А автор хочется сделать примитивнейшую хреновину по функционалу.
Но в чем-то вы правы - у автора все получится. Поскольку цель просто набить портфолио.
> Лет через 5 30-50 процентов вынуждены будут курьерами и уборщиками стать
Тут я с вами согласен: после того, как станет ясно, что прогнозисты тотальной замены программистов нейронками жидко обгадились, уборщики точно потребуются.
Да, и перловики во всю с него смеялись. Писать какие-то серьезные вещи на нем считалось моветоном года до 2010. А там уже и питон стали пихать в каждую дырку. В общем да - пхп хоронили всю историю его создания. Хотя он пережил и перл, и питон, и руби, и ноду. Сейчас вот идет эпопея с го...
Это вы так говорите, потому что знаете хорошо экосистему. Для меня тоже помню было не очевидно очень как прикрутить сбор инфы без экспортера. Что характерно это можно было сделать, но сперва нужно продраться через понимание модели работы прометея(а это часто не нужно, потому что не твой основной профиль), потом через его адептов, которые будут учить как правильно, и потом только нагуглишь "неправильный" метод, который тебе нужен здесь и сейчас.
Так тонко, что аж толсто. Байтовый заголовок, противоречащий посылу статьи. А из самой статьи я понял, что мне нужно конкурировать с 5 000 000 людей, которые пользуются ИИ, и только у них есть в несколько раз больше шанс получить повышение. Уговорили, куплю жене сапоги^W^W подписку на Bothub!
Для ясности: у вас обычный пет-проект ради портфолио без какого-либо смысла. Просто скаффолднутое апи на ворохе технологий, которые хорошо выглядят в глазах рекрутера, который не будет разбираться детально.
Если это будет смотреть разработчик, то вам эта хайпорепа пойдет скорее в минус, ибо навайбкожено и оверкильно. А кейз оптимизации вообще смотрится забавно. Из него торчат уши того, что у вас есть fx-8320 и есть только HDD. Хотя сегодня еще придется поискать систему не на SSD, если вам захочется похостить свой API.
И чтобы вы уперлись не в базу, не в питон, не в неоптимизированную асинхронщину, а в алгоритмы шифрования соединений и полезли оптимизировать там - это конечно сильно. Наверное потому что прочитали пару статей про настоящий хайлоад, где упирались уже именно в это. И плевать, что в таком хайлоаде вам хрен разрешат вырезать шифры под процессор, потому что сразу куча клиентов старых отвалится. И плевать что тот же самый хайлоад будет на ssd и новых процах, где уже могут аппаратные алгоритмы шифрования, которые нужны.
По-моему это просто волчарская статья из расчета, что никто в цифрах разбираться не будет. Посмотрите в профиле автора "О себе" - чистая реклама насколько он что там увеличил.
Ну хорошо, NPU за копейки у нас есть. А память? Насколько я понимаю все эти embedded сети, они достаточно слабые. Т.е. все так и ограничится распознаванием краев на фотках в быстром редакторе, да поиском лиц в камере. То же нормальное распознавание голоса уже потребует нескольких гигов памяти. Тот же локальный whisper у меня 1070 работает всего лишь в 4 раза быстрее скорости голоса и жрет при этом то ли 4, то ли 6 гб памяти. Меньшие по размеру модели справляются печально. Ну и как только NPU начнет лезть в общую память - прощай низкое энергопотребление. Так что, вангую, что нас ждет куча маркетингового псевдо-ИИ в каждом утюге.
Очень хочется даже не p2p, но со своим сервером. И чтобы без диктовки пароля по телефону. Есть такие штуки, чтобы зашил адрес сервераключ/пароль в бинарник и отправил каждому из родственников на случай чинения чего-то там? И чтобы сервер влезал на самый копеечный vps, потому что у rustdesk системные требования немаленькие.
Скажите, а в какую сторону копать, если у меня есть записи одного голоса, и я хочу этим голосом перепеть другую песню? Это вообще делается локально на данный момент?
Никогда не встречал такого на практике, чтобы это было не костыльно. В каком-то ява-подобном языке, это выглядело бы как:
модуль A
модуль B
интерфейс реализуемый модулем А, который дергает модуль B
интерфейс реализуемый модулем B, который дергает модуль A
Такое решение может иметь место, но в очень специфическом случае - когда абстракция протекает, и мы с этим смирились. Например в 95% случаев мы из бизнес логики дергаем драйвер базы данных для персиста. Но в каких-то редких случаях, для оптимизации, драйверу будет полезно знать состояние системы выше уровнем, чтобы знать - персистить сейчас или пододождать еще пару вызовов персиста и потом сразу записать бОльший объем данных.
А в 95% случаев во всех системах что я видел - один интерфейс, который реализуем модуль B для дерганья из модуля А. Это если мы говорим об "уровнях" в архитектуре, которая действительно иерархически построена, как то: база > ентити > репозиторий > контроллер.
Но уровни как таковые не всегда есть. Например, при попытке причесать сложный монолит, часто можно столкнуться с взаимными зависимостями вроде бы равноправных кусков бизнес логики. Например корзина хочет знать наличие остатка на складе, а склад хочет знать количество корзин и товаров, зарезервированных в каждой в данный момент.
Поэтому очень важно разделять рассматриваемые сценарии реализации инверсии зависимоти по типу архитектуры. Для равноправных взаимозависимых модулей нужно 2 интерфейса, для иерархически зависимых нужен 1 интерфейс.
Вы знаете, я прочитал простыню автора, его ответы, которые он как нейронкой пишет, и не знаю что тут сказать хорошего. В Бразилии много хороших программистов, и реалии своей страны они знают лучше. А автор хочется сделать примитивнейшую хреновину по функционалу.
Но в чем-то вы правы - у автора все получится. Поскольку цель просто набить портфолио.
> Лет через 5 30-50 процентов вынуждены будут курьерами и уборщиками стать
Тут я с вами согласен: после того, как станет ясно, что прогнозисты тотальной замены программистов нейронками жидко обгадились, уборщики точно потребуются.
Да, и перловики во всю с него смеялись. Писать какие-то серьезные вещи на нем считалось моветоном года до 2010. А там уже и питон стали пихать в каждую дырку. В общем да - пхп хоронили всю историю его создания. Хотя он пережил и перл, и питон, и руби, и ноду. Сейчас вот идет эпопея с го...
По моему опыту быстрее поставить zabbix с нуля, по туториалам с интернета, чем разобраться как донастроить имеющийся прометей.
Это вы так говорите, потому что знаете хорошо экосистему. Для меня тоже помню было не очевидно очень как прикрутить сбор инфы без экспортера. Что характерно это можно было сделать, но сперва нужно продраться через понимание модели работы прометея(а это часто не нужно, потому что не твой основной профиль), потом через его адептов, которые будут учить как правильно, и потом только нагуглишь "неправильный" метод, который тебе нужен здесь и сейчас.
Так тонко, что аж толсто. Байтовый заголовок, противоречащий посылу статьи. А из самой статьи я понял, что мне нужно конкурировать с 5 000 000 людей, которые пользуются ИИ, и только у них есть в несколько раз больше шанс получить повышение. Уговорили, куплю жене сапоги^W^W подписку на Bothub!
Ну если просто - то ладно. А то я уж было подумал, что очередной рекламный ботокомент о пользе нейронок. А тут как от сердца отлегло.
>Но справедливости ради - адекватный работодатель встречается нечасто
Тут вы сильно ошибаетесь: крайне редкий работодатель признает себя неадекватным.
Нейронки спишут всё.
Проблемы в компании, но не хочется терять лицо перед клиентами? Сократи сотрудников под предлогом, что используешь нейронки.
Пригрози остальным сотрудникам, что заменишь их нейронкой.
Рецессия в экономике? Очевидно виноваты нейронки!
У тебя отключают свет из-за плохих сетей? Нейронки выпили весь свет из розетки!
Не можешь обновить кудахтер? Это из-за нейронок взлетели цены на видяхи и память(справедливости ради, это так)
Компромат на крупного чиновника? Это нейронками сгенерировано.
В общем, если бы нейронок не было, их следовало бы придумать.
Для ясности: у вас обычный пет-проект ради портфолио без какого-либо смысла. Просто скаффолднутое апи на ворохе технологий, которые хорошо выглядят в глазах рекрутера, который не будет разбираться детально.
Если это будет смотреть разработчик, то вам эта хайпорепа пойдет скорее в минус, ибо навайбкожено и оверкильно. А кейз оптимизации вообще смотрится забавно. Из него торчат уши того, что у вас есть fx-8320 и есть только HDD. Хотя сегодня еще придется поискать систему не на SSD, если вам захочется похостить свой API.
И чтобы вы уперлись не в базу, не в питон, не в неоптимизированную асинхронщину, а в алгоритмы шифрования соединений и полезли оптимизировать там - это конечно сильно. Наверное потому что прочитали пару статей про настоящий хайлоад, где упирались уже именно в это. И плевать, что в таком хайлоаде вам хрен разрешат вырезать шифры под процессор, потому что сразу куча клиентов старых отвалится. И плевать что тот же самый хайлоад будет на ssd и новых процах, где уже могут аппаратные алгоритмы шифрования, которые нужны.
Удачи в трудоустройстве.
По-моему это просто волчарская статья из расчета, что никто в цифрах разбираться не будет. Посмотрите в профиле автора "О себе" - чистая реклама насколько он что там увеличил.
У вашего котенка дверца не на месте.
>Для Uber приоритетом является надежное озеро данных
В этом озере весело плескались гуртовщики мыши.
Ну хорошо, NPU за копейки у нас есть. А память? Насколько я понимаю все эти embedded сети, они достаточно слабые. Т.е. все так и ограничится распознаванием краев на фотках в быстром редакторе, да поиском лиц в камере. То же нормальное распознавание голоса уже потребует нескольких гигов памяти. Тот же локальный whisper у меня 1070 работает всего лишь в 4 раза быстрее скорости голоса и жрет при этом то ли 4, то ли 6 гб памяти. Меньшие по размеру модели справляются печально. Ну и как только NPU начнет лезть в общую память - прощай низкое энергопотребление. Так что, вангую, что нас ждет куча маркетингового псевдо-ИИ в каждом утюге.
Очень хочется даже не p2p, но со своим сервером. И чтобы без диктовки пароля по телефону. Есть такие штуки, чтобы зашил адрес сервераключ/пароль в бинарник и отправил каждому из родственников на случай чинения чего-то там? И чтобы сервер влезал на самый копеечный vps, потому что у rustdesk системные требования немаленькие.
Скажите, а в какую сторону копать, если у меня есть записи одного голоса, и я хочу этим голосом перепеть другую песню? Это вообще делается локально на данный момент?
Если появляются такие вопросы, то наличие-отсутствие удаленки в этом месте работы - это вообще последняя проблема в вашем списке.
Никогда не встречал такого на практике, чтобы это было не костыльно. В каком-то ява-подобном языке, это выглядело бы как:
модуль A
модуль B
интерфейс реализуемый модулем А, который дергает модуль B
интерфейс реализуемый модулем B, который дергает модуль A
Такое решение может иметь место, но в очень специфическом случае - когда абстракция протекает, и мы с этим смирились. Например в 95% случаев мы из бизнес логики дергаем драйвер базы данных для персиста. Но в каких-то редких случаях, для оптимизации, драйверу будет полезно знать состояние системы выше уровнем, чтобы знать - персистить сейчас или пододождать еще пару вызовов персиста и потом сразу записать бОльший объем данных.
А в 95% случаев во всех системах что я видел - один интерфейс, который реализуем модуль B для дерганья из модуля А. Это если мы говорим об "уровнях" в архитектуре, которая действительно иерархически построена, как то: база > ентити > репозиторий > контроллер.
Но уровни как таковые не всегда есть. Например, при попытке причесать сложный монолит, часто можно столкнуться с взаимными зависимостями вроде бы равноправных кусков бизнес логики. Например корзина хочет знать наличие остатка на складе, а склад хочет знать количество корзин и товаров, зарезервированных в каждой в данный момент.
Поэтому очень важно разделять рассматриваемые сценарии реализации инверсии зависимоти по типу архитектуры. Для равноправных взаимозависимых модулей нужно 2 интерфейса, для иерархически зависимых нужен 1 интерфейс.