Так пересядь, в чем проблема? Религия не позволяет? Новости врут - голодные до сенсаций журналюги раздувают любую мелочь до масштабов вселенских проблем. В реальности же с таким столкнуться очень сложно. На нвидиа все абсолютно тоже самое - там от драйверов вообще карточки сгорают, и что? Желающих меньше покупать не видно.
Тут проблема не в обычном ПО, а в драйверах, когда их шатают с двух сторон сразу. Не удивительно что это иногда вызывает проблемы.
Что касается безопасного обновления - это только на Linux. Там можно что угодно обновлять, и до перезагрузки система будет работать. Да и после перезагрузки, даже если подчистую снёс загрузочный раздел, не проблема загрузиться с любой флешки с линуксом - главное чтобы кто-то загрузил ядро в память, остальное поправимо. У меня какое-то время вообще загрузчик жил одновременно и на флешке и на диске, когда на старом железе nvme железу было неизвестно, а флешки известны.
На винде максимум что можно получить в этом плане - точки сохранения. Если будет проблема в процессе обновления, система упадет, а загрузиться в полуобновленном состоянии уже не выйдет, и исправить это на винде очень нетривиальная задача, хотя иногда и получается.
Верно, тесты ускоряют разработку. Просто не все их умеют готовить - для многих это как религия, они себе лоб расшибают, послушно обкладывая тестами вообще все-все-все из каких-то своих представлений о том как нужно писать тесты, или же наоборот, упорно из игнорируют, полагаясь на ручное тестирование или мысленное моделирование. Ручное тестирование жрет много времени, причем иногда его нужно выполнять повторно несколько раз, пока не исчерпается поток доработок. В мысленном моделировании ничего плохого нет, если есть опыт, это быстро и достаточно надежно, но тут играет чисто человеческий фактор: с удивлением узнал, что некоторые в этом настольные преисполнились, что сдают код, который из-за грубых опечаток даже запуститься не в состоянии, т.е. код даже ни разу не запускался автором, все из головы накидано, а в результате получается очень некрасиво, воспринимается это скорее как не накидано, а наложено. Ну а автотесты приходится межу делом подключать даже там, где их никогда не было, чисто для себя: они хорошо экономят силы и время, позволяют не вникать повторно в код, не тестировать его повторно, тем более вручную, позволяют сразу выкинуть из головы и сам код, и все сомнения относительно его надежности, а также, в случае проблем, позволяют не перебирать код, а сразу перейти к проблемному фрагменту. Также они снимают такую проблему, как скрытые ошибки: иногда ошибки в общем коде остаются незамеченными годами, автотесты такое вскрывают сразу, если написаны не через одно место.
А что касается прицела на будущее - для себя взял за правило так не делать. Это не окупается, никому не нужно, и никому не интересно. Минимально соломы набросать конечно нужно, но минимально, только из эгоистичных побуждений, для облегчения себе жизни, для облегчения отладки и тестирования, не больше. Это вполне хорошо бьёт код на тестируемые фрагменты, и вполне логично и обоснованно их раскладывает по структуре, просто потому что следует не абстрактной цели, а вполне конкретной. Это также автоматически отрезает весь тот ад абстракций, который любят порождать особо дальновидные товарищи, закладывая то, что вообще никогда не будет использовано, но всегда будет требовать внимания и поддержки.
И по мне такой подход неплохо окупается: забот гораздо меньше, только выполнить требования задачи и немножко облегчить себе жизнь, и ничего более. Меньше думаешь, меньше кода, он проще, лучше и легче читается, меньше времени тратишь на его написание и отладку. Как итог сил прикладываешь меньше. А если и когда требования изменятся - будет потребность, будут ресурсы, и самое главное, будут известны конкретные требования, что позволит провести целевой рефакторинг.
Особенно ярко это контрастирует, когда натыкаешься на код дальновидного товарища, в котором даже разобраться та ещё задача, десяток классов для какого-нибудь десятистрочного одноразового фильтра, и ты такой на вот эту гору запутанного абстрактного и абсолютно бесполезного кода взираешь и только один вопрос: "Зачем ты это сотворил? Кто и как теперь это будет поддерживать?". Как итог у такого товарища код бесполезен и переусложнен без какой-либо потребности в этом.
Тут переплетается такой эффект как владение кодовой базой. Если его нет - ни о какой надёжности и скорости речи быть не может, будет сплошной баго глюкодром на радость пользователю.
Если код пилит одна небольшая команда - команда полностью владеет кодом, все эффективно. Высокая оперативность принятия решений и реализации, все просто, быстро, согласованно.
Если в команде большая текучка - команда уже только частично владеет кодом: вновьприбывшие не способны полностью овладеть кодовой базой, и начинают творческое велосипедостроение из костылей, когда в кодовой базе все необходимое для работы уже давно написано и оттестировано, но чтобы использовать готовое, нужно знать что оно есть, а знания кодовой базы у вновьприбывших отсутствуют. А вместе с покидающими команду уходят знания и экспертиза команды, которые очень сложно восполнить, а быстро это вообще не сделать. В проекте начинаются проблемки.
Ну а если команда проекта - сборная солянка из нескольких команд, или даже фирм, значит кодом не владеет никто: творческое велосипедостроение из костылей во все поля. Тут уже не до эффективности, хорошо если проблемы вообще хоть как-то решаются и процесс куда-то в целом движется. Это классический тяни-толкай: такой уровень бюрократии, палок и подножек, что ни о какой согласованности разработки в принципе можно не говорить. Каждый работает как умеет, и многое пишет для себя сам, даже не затрудняясь что-то изучать в коде, позитивные инициативы из-за бюрократии не оплачиваются, не поощряются, зато наказываются, и хотя на словах и может заявляться обратное, только слова к делу не пришьешь. Выходит так, что в таких процессах никто особо не заинтересован в результате, процесс важнее. Получается мутное болото, а не разработка. Иногда в таких процессах даже могут всплыть герои, с попытками что-то организовать и оптимизировать, улучшить результат, но их энтузиазм ничем не подкрепляется и быстро сгорает - один активный человек в огромной инертной, активно сопротивляющейся любым изменениям, системе в принципе ничего сдвинуть не в состоянии.
Скорее всего, потому что в 11 тот ещё треш: устанавливается на старое железо, и при первом же запуске ядро бсодит по страшному. Если при этом ещё и всех принудительно обновит до 11, бсоды пойдут массово - это будет тот ещё номер. На новом железе просто tpm выключил - сразу перестало подходить для обновления, по мнению 10, тем лучше.
Поддерживать вручную, на большее в ближайшем будущем явно не стоит рассчитывать. Как с нейросетями для художников: можно получить простенькую заготовку по описанию, но допиливать и поддерживать ее придется самому.
В крайнем случае можно попробовать скормить фрагмент кода сетке для анализа - сомнительно что это поможет, но вдруг? В любом случае с большими фрагментами кода такое не получится - их нужно уже осмысливать, сверять с требованиями к коду и здравым смыслом.
Получается просто генератор заготовок - какие-то простенькие алгоритмы можно накидать по-быстрому с помощью нейронки, но без ручной проверки результата все равно не обойтись: выдать оно может что угодно, в том числе явную глупость и мусор. Прям как за джунами бдить. Но джуны быстро эволюционируют, учатся, и результат выдают на несравнимо более сложных задачах и намного более связный - с ними в теории намного проще и стабильнее, чем с сеткой, должно выходить.
Вот да. Огромный проект с миллионами строк кода. Структура сложная, много говнокода, лютое легаси. Документации, кроме самого кода, нет, как оно работает никто не скажет. Задача поправить там что-то сама по себе простая: берешь и правишь, делов то. Но прежде чем править что-то, сперва нужно во всей этой структуре отыскать место для правки - нужно проанализировать много кода, понять что он делает, в десяток мест залезть с отладчиком, убедиться что происходит именно то, что предполагается. А потом нужно понять что и как в этой структуре можно и нужно изменить, чтобы и требования выполнить, и ничего не поломать, имея ввиду что код может выполнять какие-то неизвестные и неописанные в требованиях на правки функции, да еще и постараться сделать это красиво и надёжно, чтобы не плодить говнокод и упростить поддержку. Что-то в ходе этих изысканий неизбежно вызовет фейспалмы и подвергнется рефакторингу, или даже будут найдены скрытые ошибки в какой-то логике. Вот это вот все превращает простые правки в сложный квест с невероятным сюжетом и неожиданной концовкой.
Вот как в легаси что-то нейронка будет править - даже не представляю. Тут и человеку разобраться сложно. Процедура сродни операции: каждый шаг выверяется и согласовывается с окружающей логикой, постоянный контроль, нужно отдавать себе отчёт что происходит в окружающем коде и как на это повлияют новые правки, не делаешь ли хуже. Потому что цена ошибки высока: одно неверное движение или решение - и целый ворох скрытых багов весело разбегается по огромной кодовой базе.
У машины тут только одно преимущество: она в теории может запомнить весь код, а когда в голове держишь весь код, правки хорошо согласованы. Основная проблема человека: слишком малая ёмкость памяти, если для правки нужно держать в голове слишком много кода, часть его тут же вытесняется и забывается, получается частично что-то делаешь вслепую. Отсюда и все ООП пошло: чтобы абстрагироваться от кода и оперировать как можно меньшим количеством частей в один момент времени, не теряя ничего из виду. Но конкретно у нейронки ресурсов намного меньше, чем у машины: даже если бы она понимала что делает, ей доступно намного меньше ресурсов, чем есть на ее хосте, так что большие кодовые базы тут даже рассматривать не стоит.
А вот что-то небольшое вполне поместится, что в оп-посте и видно: пару маленьких блоков кода, с трудом, постоянно теряя что-то, кое-как осилила. Вот под такие задачи ее и можно использовать: сгенерить один маленький конкретный метод по описанию, проверить код и убедиться что результат устраивает, если нужно поправить, или выкинуть и написать вручную, если выдало какую-то откровенную глупость.
Ну хз. Родственник - пенсионер примерно также использует машину: на единственный ssd установил одну игру, и годами шпилит. А что, пенсия, делать нефиг, убивает время, интересов нет.
Мне же под работу не хватает 500 гиг: половина ежедневные бекапы, треть данные и инструменты, остальное всякие вспомогательное и немного для отдыха. На домашнем компе же терабайт забит игрушками и ещё терабайт 5 всякими личными данными, бекапами, семейными архивами, музыкой, фильмами, и т.п.
Вот ленточник мне под архивы вполне зашёл бы, если бы не цена. Харды дорогие слишком для этого, тем более если делать по науке, с резервированием и отдельным хранилищем. Ну а всякие игры, софт, и часто используемые данные - тут идеален ssd
Вообще имеет смысл: связь - самый дорогой компонент, особенно когда объемы данных растут. Пока это не особо заметно, но очевидно что объемы данных будут только расти, а вот возможности связи наращивать куда как сложнее, особенно в будущем, когда потребуется более дальнобойная связь, и провод не протянешь.
Это стараются компенсировать всевозможным сжатием. Нейросети по сути то же сжатие, только более эффективное.
Но идея сама по себе сложная и проблемная - нейронки плохо поддаются контролю, сложно получить именно то, что хочешь получить. Впрочем в будущем так или иначе найдут какое-то решение - сейчас толком и инструментов под них нормальных особо нет, и железо только-только начало появляться, нейронки только в начале своего развития.
Аналогично. В первую очередь нужно смотреть на деньги и зарплатную политику. Есть ли деньги у фирмы вообще на высокие технологии? Если нет - что вы там надеетесь найти? Платить не будут. Если таки есть - хорошо ли она оплачивает труд специалистов, щедро ли делится доходами, которые этими специалистами и добываются? Если плохо, если пытается нагреть на оплате труда - с чего вы взяли, что вам будут платить хорошо? Не стоит тратить свое время.
Согласен, тоже такое впечатление сложилось. И тут есть негативный фактор: лиду легко свалить свои косяки на джуна и выпнуть его, тем самым "закопав" проблему, но это мерзко и низко, хороший лид такого никогда не сделает, напротив будет боятся такого расклада как огня, потому что задача лида не в диверсиях внутри команды, а в поддержке и направлении.
А теперь сделай все тоже самое, но где-то в глубине огромного фреймворка, с которым глубже скудной документации не общался. Задача уже стала сложнее, не так ли? Особенно для джуна. Мы не видели проблемный код и оригинальные требования, чтобы что-то судить. Да и о самой проблеме только с одной стороны слышно, вторая же заочно лишена права голоса - не очень оригинальная попытка набросить на вентилятор.
А почему все завязано на одного программиста? Если один не может - это нормально, всегда должны быть другие, кому можно дать посмотреть, и кто-нибудь в конце концов да сможет. Или же проблема перейдет на уровень нерешаемой в принципе, и потребует пересмотра стратегии. Но на одном человеке чтобы все было завязано - как минимум это очень странно. Неужели только один программист на всю контору?
Чет бред какой-то. Обычный программист задачи такого уровня решать в принципе не должен. Так что стоит сперва определиться, какой результат хотим получить. Одно дело любой ценой срочно убрать лаги - тут не до разбирательств, просто вкидываешь гору бабла и арендует дополнительные мощности, чтобы не пошли потери, а все разбирательства уже потом, когда проблема уже не стоит так остро. Другое дело если не срочно но любой ценой требуется найти источник лагов - это профилирование и оптимизация, это долгое исследование логов, тесткейсов, перебор вариантов, и т.п. исследовательско-аналитическая деятельность, поиск причин и путей оптимизации. А вот чтобы так срочно беги исследуй логи и сделай хоть что-нибудь - это уже дурка какая-то: исследования и разбирательства, фиксы и тесты это дело не быстрое, а без понимания источника проблемы ничего сделать впринципе нельзя на уровне программиста, но можно на уровне администратора и управленцев, выделить дополнительные бюджеты, добавить аппаратных мощностей, но зачем тогда ответственность вешать на программиста? Зачем требовать от него "сделай хоть что-нибудь"? Что он может сделать, если ему не дают ни времени, ни возможностей, ни полномочий, ни ресурсов? Только послать такого руководителя подальше.
На счет эффектов правда, всякие EAX не прижились, как собственно и другие проприетарные/уникальные штуки, типа physx, как раз из-за ограниченной аппаратной поддержки: технологии, которые работают не у всех, никто всерьёз даже не рассматривает, прикручивают только для галочки, с расчетом на то что они использоваться все равно не будут.
У каждой игры нынче свой движок эффектов. Это с одной стороны здорово, что ни привязки к железу, нет ограничений, например та же Арма симулирует скорость звука, чтобы далёкие взрывы слышались с задержкой, симулирует распространение звука с учётом холмов, чтобы технику за препятствиями было хуже слышно. Но с другой стороны это плохо: у каждой игры звук свой, нет какого-то стабильного качества, все зависит от профессионализма всей команды, от менеджмента до рядовых поограммеров, так что хороший звук в целом редкость, если о нем специально не позаботились при разработке. И на многоканальном звуке программная эмуляция даёт большую нагрузку на железо - на старых процессорах один звук может целое ядро сожрать, так что все лагать начинает: ядер там всего два обычно.
Но даже сегодня программная эмуляция решает далеко не весь спектр задач. Ситуация тут как с игровыми мышками или мониторами: да, часто на игровое железо вешают всякую подсветку для подростков, но все таки там есть и аппаратные плюшки, которые его отличают от обычного железа. У тех же игровых мышек например много дополнительных кнопок, высокая чувствительность, причем регулируемая, возможность переключать разрешение налёту, возможность полной настройки матрицы разрешений, высоты отрыва, множество всяких профилей, переключаемых налёту, со всякими двойными кликами, эмуляцией клавиатуры, и все это работает без софта, но понятно что настраивается только через софт. Удобно? Безусловно. У игровых мониторов тоже железо, отзывчивость и цвета лучше, больше настроек, и есть всякие дополнительные плюшки, которых нет у обычных мониторов, типа отображения перекрестия прицела, высветление темных участков чтобы иметь преимущество в темных играх/помещениях/пещерах/ночами, и т.п. Не удивительно что современные игровые аппаратные звуковые карточки тоже предлагают такие же плюшки: в первую очередь это работа с микрофоном/гарнитурой, четырехпиновый штекер, усиление/очистка/корректировка голоса, и даже подмена голоса, современные игры сильно завязаны на социальное взаимодействие, дискорды и чатик, к слову все это хорошо работает и для рабочих конференций, реально другое качество голоса, также всякие дополнительные тонкие настройки звука, причем все настройки хранятся аппаратно и не зависят от софта, специально для игроков есть всякие технологии специально для игр, например усиление слабых звуков и ослабление сильных, чтобы лучше слышать далёкие шаги, увеличенная пространственная детализация, чтобы чётче локализовать источник этих звуков и стрелять вслепую, на звук, работает все это замечательно, и нигде больше такого получить нельзя, ну и бонусом идут технологии программной виртуализации, которые позволяют снять с игры честный восьмиканальный звук, и преобразовать его для наушников так, что создаётся полное ощущение что ты используешь домашний кинотеатр, и очень четко различаешь откуда идёт звук, спереди или сзади, конкретный азимут, это прямо как прозреть внезапно, после коррекции зрения, столько новых деталей и настолько прозрачный звук получается, словами не передать.
Так что у креативов ниша до сих пор существует, она сегодня менее востребована, дорогое игровое железо нужно не всем, когда базовые вещи звуковым движком игры реализуются, но всякие дополнительные плюшки и комфорт можно получить только так, за дополнительные деньги, и спрос на это до сих пор живой, карточки креатива в магазинах разлетаются и пользуются спросом даже на вторичном рынке.
Это по которым на два месяца вперёд приема нет, а у тебя срочное, и ты не понимаешь что делать?
Или по тем самым, по которым приходишь к своим 11:15 по талону, и с температурой ждёшь до 16:00, потому что врач один и принимает в порядке живой очереди, а талоном можно только подтереться?
Задумка неплохая, но вот реализация никакая. На той же почте эти талоны проработали две недели, потом мониторы сняли, одни провода висят. Только в банках ещё оно живо и работает. Но в банках 20 окон принимают, а на почте и в поликлинике считай одно: когда работать некому, эти талоны абсолютно бесполезны.
Нужно на несколько порядков больше устройств - современному обществу крайне важна возможность выбора: платформа, бренд, модель, серия, цвет, разные объемы памяти/дисков/процессор/видеокарта/экран - вот это вот все. Очевидно что на закрытом рынке такое изобилие невозможно, и отказываться от выбора тоже никто не будет - спрос на технику с международного рынка никуда не денется, как ни ограничивай и не взвинчивай цены. Это просто данность, современные реалии.
Так пересядь, в чем проблема? Религия не позволяет? Новости врут - голодные до сенсаций журналюги раздувают любую мелочь до масштабов вселенских проблем. В реальности же с таким столкнуться очень сложно. На нвидиа все абсолютно тоже самое - там от драйверов вообще карточки сгорают, и что? Желающих меньше покупать не видно.
Тут проблема не в обычном ПО, а в драйверах, когда их шатают с двух сторон сразу. Не удивительно что это иногда вызывает проблемы.
Что касается безопасного обновления - это только на Linux. Там можно что угодно обновлять, и до перезагрузки система будет работать. Да и после перезагрузки, даже если подчистую снёс загрузочный раздел, не проблема загрузиться с любой флешки с линуксом - главное чтобы кто-то загрузил ядро в память, остальное поправимо. У меня какое-то время вообще загрузчик жил одновременно и на флешке и на диске, когда на старом железе nvme железу было неизвестно, а флешки известны.
На винде максимум что можно получить в этом плане - точки сохранения. Если будет проблема в процессе обновления, система упадет, а загрузиться в полуобновленном состоянии уже не выйдет, и исправить это на винде очень нетривиальная задача, хотя иногда и получается.
Верно, тесты ускоряют разработку. Просто не все их умеют готовить - для многих это как религия, они себе лоб расшибают, послушно обкладывая тестами вообще все-все-все из каких-то своих представлений о том как нужно писать тесты, или же наоборот, упорно из игнорируют, полагаясь на ручное тестирование или мысленное моделирование. Ручное тестирование жрет много времени, причем иногда его нужно выполнять повторно несколько раз, пока не исчерпается поток доработок. В мысленном моделировании ничего плохого нет, если есть опыт, это быстро и достаточно надежно, но тут играет чисто человеческий фактор: с удивлением узнал, что некоторые в этом настольные преисполнились, что сдают код, который из-за грубых опечаток даже запуститься не в состоянии, т.е. код даже ни разу не запускался автором, все из головы накидано, а в результате получается очень некрасиво, воспринимается это скорее как не накидано, а наложено. Ну а автотесты приходится межу делом подключать даже там, где их никогда не было, чисто для себя: они хорошо экономят силы и время, позволяют не вникать повторно в код, не тестировать его повторно, тем более вручную, позволяют сразу выкинуть из головы и сам код, и все сомнения относительно его надежности, а также, в случае проблем, позволяют не перебирать код, а сразу перейти к проблемному фрагменту. Также они снимают такую проблему, как скрытые ошибки: иногда ошибки в общем коде остаются незамеченными годами, автотесты такое вскрывают сразу, если написаны не через одно место.
А что касается прицела на будущее - для себя взял за правило так не делать. Это не окупается, никому не нужно, и никому не интересно. Минимально соломы набросать конечно нужно, но минимально, только из эгоистичных побуждений, для облегчения себе жизни, для облегчения отладки и тестирования, не больше. Это вполне хорошо бьёт код на тестируемые фрагменты, и вполне логично и обоснованно их раскладывает по структуре, просто потому что следует не абстрактной цели, а вполне конкретной. Это также автоматически отрезает весь тот ад абстракций, который любят порождать особо дальновидные товарищи, закладывая то, что вообще никогда не будет использовано, но всегда будет требовать внимания и поддержки.
И по мне такой подход неплохо окупается: забот гораздо меньше, только выполнить требования задачи и немножко облегчить себе жизнь, и ничего более. Меньше думаешь, меньше кода, он проще, лучше и легче читается, меньше времени тратишь на его написание и отладку. Как итог сил прикладываешь меньше. А если и когда требования изменятся - будет потребность, будут ресурсы, и самое главное, будут известны конкретные требования, что позволит провести целевой рефакторинг.
Особенно ярко это контрастирует, когда натыкаешься на код дальновидного товарища, в котором даже разобраться та ещё задача, десяток классов для какого-нибудь десятистрочного одноразового фильтра, и ты такой на вот эту гору запутанного абстрактного и абсолютно бесполезного кода взираешь и только один вопрос: "Зачем ты это сотворил? Кто и как теперь это будет поддерживать?". Как итог у такого товарища код бесполезен и переусложнен без какой-либо потребности в этом.
Тут переплетается такой эффект как владение кодовой базой. Если его нет - ни о какой надёжности и скорости речи быть не может, будет сплошной баго глюкодром на радость пользователю.
Если код пилит одна небольшая команда - команда полностью владеет кодом, все эффективно. Высокая оперативность принятия решений и реализации, все просто, быстро, согласованно.
Если в команде большая текучка - команда уже только частично владеет кодом: вновьприбывшие не способны полностью овладеть кодовой базой, и начинают творческое велосипедостроение из костылей, когда в кодовой базе все необходимое для работы уже давно написано и оттестировано, но чтобы использовать готовое, нужно знать что оно есть, а знания кодовой базы у вновьприбывших отсутствуют. А вместе с покидающими команду уходят знания и экспертиза команды, которые очень сложно восполнить, а быстро это вообще не сделать. В проекте начинаются проблемки.
Ну а если команда проекта - сборная солянка из нескольких команд, или даже фирм, значит кодом не владеет никто: творческое велосипедостроение из костылей во все поля. Тут уже не до эффективности, хорошо если проблемы вообще хоть как-то решаются и процесс куда-то в целом движется. Это классический тяни-толкай: такой уровень бюрократии, палок и подножек, что ни о какой согласованности разработки в принципе можно не говорить. Каждый работает как умеет, и многое пишет для себя сам, даже не затрудняясь что-то изучать в коде, позитивные инициативы из-за бюрократии не оплачиваются, не поощряются, зато наказываются, и хотя на словах и может заявляться обратное, только слова к делу не пришьешь. Выходит так, что в таких процессах никто особо не заинтересован в результате, процесс важнее. Получается мутное болото, а не разработка. Иногда в таких процессах даже могут всплыть герои, с попытками что-то организовать и оптимизировать, улучшить результат, но их энтузиазм ничем не подкрепляется и быстро сгорает - один активный человек в огромной инертной, активно сопротивляющейся любым изменениям, системе в принципе ничего сдвинуть не в состоянии.
Скорее всего, потому что в 11 тот ещё треш: устанавливается на старое железо, и при первом же запуске ядро бсодит по страшному. Если при этом ещё и всех принудительно обновит до 11, бсоды пойдут массово - это будет тот ещё номер. На новом железе просто tpm выключил - сразу перестало подходить для обновления, по мнению 10, тем лучше.
Нейронке такое можно доверить только при условии ее непогрешимости
А если потребуется что-то изменить в ее коде, который ты не понимаешь?
Поддерживать вручную, на большее в ближайшем будущем явно не стоит рассчитывать. Как с нейросетями для художников: можно получить простенькую заготовку по описанию, но допиливать и поддерживать ее придется самому.
В крайнем случае можно попробовать скормить фрагмент кода сетке для анализа - сомнительно что это поможет, но вдруг? В любом случае с большими фрагментами кода такое не получится - их нужно уже осмысливать, сверять с требованиями к коду и здравым смыслом.
Получается просто генератор заготовок - какие-то простенькие алгоритмы можно накидать по-быстрому с помощью нейронки, но без ручной проверки результата все равно не обойтись: выдать оно может что угодно, в том числе явную глупость и мусор. Прям как за джунами бдить. Но джуны быстро эволюционируют, учатся, и результат выдают на несравнимо более сложных задачах и намного более связный - с ними в теории намного проще и стабильнее, чем с сеткой, должно выходить.
Вот да. Огромный проект с миллионами строк кода. Структура сложная, много говнокода, лютое легаси. Документации, кроме самого кода, нет, как оно работает никто не скажет. Задача поправить там что-то сама по себе простая: берешь и правишь, делов то. Но прежде чем править что-то, сперва нужно во всей этой структуре отыскать место для правки - нужно проанализировать много кода, понять что он делает, в десяток мест залезть с отладчиком, убедиться что происходит именно то, что предполагается. А потом нужно понять что и как в этой структуре можно и нужно изменить, чтобы и требования выполнить, и ничего не поломать, имея ввиду что код может выполнять какие-то неизвестные и неописанные в требованиях на правки функции, да еще и постараться сделать это красиво и надёжно, чтобы не плодить говнокод и упростить поддержку. Что-то в ходе этих изысканий неизбежно вызовет фейспалмы и подвергнется рефакторингу, или даже будут найдены скрытые ошибки в какой-то логике. Вот это вот все превращает простые правки в сложный квест с невероятным сюжетом и неожиданной концовкой.
Вот как в легаси что-то нейронка будет править - даже не представляю. Тут и человеку разобраться сложно. Процедура сродни операции: каждый шаг выверяется и согласовывается с окружающей логикой, постоянный контроль, нужно отдавать себе отчёт что происходит в окружающем коде и как на это повлияют новые правки, не делаешь ли хуже. Потому что цена ошибки высока: одно неверное движение или решение - и целый ворох скрытых багов весело разбегается по огромной кодовой базе.
У машины тут только одно преимущество: она в теории может запомнить весь код, а когда в голове держишь весь код, правки хорошо согласованы. Основная проблема человека: слишком малая ёмкость памяти, если для правки нужно держать в голове слишком много кода, часть его тут же вытесняется и забывается, получается частично что-то делаешь вслепую. Отсюда и все ООП пошло: чтобы абстрагироваться от кода и оперировать как можно меньшим количеством частей в один момент времени, не теряя ничего из виду. Но конкретно у нейронки ресурсов намного меньше, чем у машины: даже если бы она понимала что делает, ей доступно намного меньше ресурсов, чем есть на ее хосте, так что большие кодовые базы тут даже рассматривать не стоит.
А вот что-то небольшое вполне поместится, что в оп-посте и видно: пару маленьких блоков кода, с трудом, постоянно теряя что-то, кое-как осилила. Вот под такие задачи ее и можно использовать: сгенерить один маленький конкретный метод по описанию, проверить код и убедиться что результат устраивает, если нужно поправить, или выкинуть и написать вручную, если выдало какую-то откровенную глупость.
Ну хз. Родственник - пенсионер примерно также использует машину: на единственный ssd установил одну игру, и годами шпилит. А что, пенсия, делать нефиг, убивает время, интересов нет.
Мне же под работу не хватает 500 гиг: половина ежедневные бекапы, треть данные и инструменты, остальное всякие вспомогательное и немного для отдыха. На домашнем компе же терабайт забит игрушками и ещё терабайт 5 всякими личными данными, бекапами, семейными архивами, музыкой, фильмами, и т.п.
Вот ленточник мне под архивы вполне зашёл бы, если бы не цена. Харды дорогие слишком для этого, тем более если делать по науке, с резервированием и отдельным хранилищем. Ну а всякие игры, софт, и часто используемые данные - тут идеален ssd
Вообще имеет смысл: связь - самый дорогой компонент, особенно когда объемы данных растут. Пока это не особо заметно, но очевидно что объемы данных будут только расти, а вот возможности связи наращивать куда как сложнее, особенно в будущем, когда потребуется более дальнобойная связь, и провод не протянешь.
Это стараются компенсировать всевозможным сжатием. Нейросети по сути то же сжатие, только более эффективное.
Но идея сама по себе сложная и проблемная - нейронки плохо поддаются контролю, сложно получить именно то, что хочешь получить. Впрочем в будущем так или иначе найдут какое-то решение - сейчас толком и инструментов под них нормальных особо нет, и железо только-только начало появляться, нейронки только в начале своего развития.
Аналогично. В первую очередь нужно смотреть на деньги и зарплатную политику. Есть ли деньги у фирмы вообще на высокие технологии? Если нет - что вы там надеетесь найти? Платить не будут. Если таки есть - хорошо ли она оплачивает труд специалистов, щедро ли делится доходами, которые этими специалистами и добываются? Если плохо, если пытается нагреть на оплате труда - с чего вы взяли, что вам будут платить хорошо? Не стоит тратить свое время.
Согласен, тоже такое впечатление сложилось. И тут есть негативный фактор: лиду легко свалить свои косяки на джуна и выпнуть его, тем самым "закопав" проблему, но это мерзко и низко, хороший лид такого никогда не сделает, напротив будет боятся такого расклада как огня, потому что задача лида не в диверсиях внутри команды, а в поддержке и направлении.
А теперь сделай все тоже самое, но где-то в глубине огромного фреймворка, с которым глубже скудной документации не общался. Задача уже стала сложнее, не так ли? Особенно для джуна. Мы не видели проблемный код и оригинальные требования, чтобы что-то судить. Да и о самой проблеме только с одной стороны слышно, вторая же заочно лишена права голоса - не очень оригинальная попытка набросить на вентилятор.
А почему все завязано на одного программиста? Если один не может - это нормально, всегда должны быть другие, кому можно дать посмотреть, и кто-нибудь в конце концов да сможет. Или же проблема перейдет на уровень нерешаемой в принципе, и потребует пересмотра стратегии. Но на одном человеке чтобы все было завязано - как минимум это очень странно. Неужели только один программист на всю контору?
Чет бред какой-то. Обычный программист задачи такого уровня решать в принципе не должен. Так что стоит сперва определиться, какой результат хотим получить. Одно дело любой ценой срочно убрать лаги - тут не до разбирательств, просто вкидываешь гору бабла и арендует дополнительные мощности, чтобы не пошли потери, а все разбирательства уже потом, когда проблема уже не стоит так остро. Другое дело если не срочно но любой ценой требуется найти источник лагов - это профилирование и оптимизация, это долгое исследование логов, тесткейсов, перебор вариантов, и т.п. исследовательско-аналитическая деятельность, поиск причин и путей оптимизации. А вот чтобы так срочно беги исследуй логи и сделай хоть что-нибудь - это уже дурка какая-то: исследования и разбирательства, фиксы и тесты это дело не быстрое, а без понимания источника проблемы ничего сделать впринципе нельзя на уровне программиста, но можно на уровне администратора и управленцев, выделить дополнительные бюджеты, добавить аппаратных мощностей, но зачем тогда ответственность вешать на программиста? Зачем требовать от него "сделай хоть что-нибудь"? Что он может сделать, если ему не дают ни времени, ни возможностей, ни полномочий, ни ресурсов? Только послать такого руководителя подальше.
На счет эффектов правда, всякие EAX не прижились, как собственно и другие проприетарные/уникальные штуки, типа physx, как раз из-за ограниченной аппаратной поддержки: технологии, которые работают не у всех, никто всерьёз даже не рассматривает, прикручивают только для галочки, с расчетом на то что они использоваться все равно не будут.
У каждой игры нынче свой движок эффектов. Это с одной стороны здорово, что ни привязки к железу, нет ограничений, например та же Арма симулирует скорость звука, чтобы далёкие взрывы слышались с задержкой, симулирует распространение звука с учётом холмов, чтобы технику за препятствиями было хуже слышно. Но с другой стороны это плохо: у каждой игры звук свой, нет какого-то стабильного качества, все зависит от профессионализма всей команды, от менеджмента до рядовых поограммеров, так что хороший звук в целом редкость, если о нем специально не позаботились при разработке. И на многоканальном звуке программная эмуляция даёт большую нагрузку на железо - на старых процессорах один звук может целое ядро сожрать, так что все лагать начинает: ядер там всего два обычно.
Но даже сегодня программная эмуляция решает далеко не весь спектр задач. Ситуация тут как с игровыми мышками или мониторами: да, часто на игровое железо вешают всякую подсветку для подростков, но все таки там есть и аппаратные плюшки, которые его отличают от обычного железа. У тех же игровых мышек например много дополнительных кнопок, высокая чувствительность, причем регулируемая, возможность переключать разрешение налёту, возможность полной настройки матрицы разрешений, высоты отрыва, множество всяких профилей, переключаемых налёту, со всякими двойными кликами, эмуляцией клавиатуры, и все это работает без софта, но понятно что настраивается только через софт. Удобно? Безусловно. У игровых мониторов тоже железо, отзывчивость и цвета лучше, больше настроек, и есть всякие дополнительные плюшки, которых нет у обычных мониторов, типа отображения перекрестия прицела, высветление темных участков чтобы иметь преимущество в темных играх/помещениях/пещерах/ночами, и т.п. Не удивительно что современные игровые аппаратные звуковые карточки тоже предлагают такие же плюшки: в первую очередь это работа с микрофоном/гарнитурой, четырехпиновый штекер, усиление/очистка/корректировка голоса, и даже подмена голоса, современные игры сильно завязаны на социальное взаимодействие, дискорды и чатик, к слову все это хорошо работает и для рабочих конференций, реально другое качество голоса, также всякие дополнительные тонкие настройки звука, причем все настройки хранятся аппаратно и не зависят от софта, специально для игроков есть всякие технологии специально для игр, например усиление слабых звуков и ослабление сильных, чтобы лучше слышать далёкие шаги, увеличенная пространственная детализация, чтобы чётче локализовать источник этих звуков и стрелять вслепую, на звук, работает все это замечательно, и нигде больше такого получить нельзя, ну и бонусом идут технологии программной виртуализации, которые позволяют снять с игры честный восьмиканальный звук, и преобразовать его для наушников так, что создаётся полное ощущение что ты используешь домашний кинотеатр, и очень четко различаешь откуда идёт звук, спереди или сзади, конкретный азимут, это прямо как прозреть внезапно, после коррекции зрения, столько новых деталей и настолько прозрачный звук получается, словами не передать.
Так что у креативов ниша до сих пор существует, она сегодня менее востребована, дорогое игровое железо нужно не всем, когда базовые вещи звуковым движком игры реализуются, но всякие дополнительные плюшки и комфорт можно получить только так, за дополнительные деньги, и спрос на это до сих пор живой, карточки креатива в магазинах разлетаются и пользуются спросом даже на вторичном рынке.
Даже индусы сначала сами переезжают, потом родню подтягивают. Тысячелетняя мудрость.
Это по которым на два месяца вперёд приема нет, а у тебя срочное, и ты не понимаешь что делать?
Или по тем самым, по которым приходишь к своим 11:15 по талону, и с температурой ждёшь до 16:00, потому что врач один и принимает в порядке живой очереди, а талоном можно только подтереться?
Задумка неплохая, но вот реализация никакая. На той же почте эти талоны проработали две недели, потом мониторы сняли, одни провода висят. Только в банках ещё оно живо и работает. Но в банках 20 окон принимают, а на почте и в поликлинике считай одно: когда работать некому, эти талоны абсолютно бесполезны.
Нужно на несколько порядков больше устройств - современному обществу крайне важна возможность выбора: платформа, бренд, модель, серия, цвет, разные объемы памяти/дисков/процессор/видеокарта/экран - вот это вот все. Очевидно что на закрытом рынке такое изобилие невозможно, и отказываться от выбора тоже никто не будет - спрос на технику с международного рынка никуда не денется, как ни ограничивай и не взвинчивай цены. Это просто данность, современные реалии.