И сейчас то покупать тяжело (зачастую чтобы понять подходит техника или нет например, приходится искать инструкцию на сайте производителя и читать её), а в будущем видимо вообще будет нереально.
Из описанного - реально полезным выглядит ответ на запрос как альтернатива простому поиску - типо "нужна штука чтобы ...". И автоподборки. Но учитывая что пихать они будут из расчёта продать, а не подобрать нуженое - пользоваться все равно не выйдет.
Все остальное - выглядит как усложнение и без того безумно сложных карточек - типо подстраивающегося интерфейса (который ты только выучил, а он подстроился), и не дай бог видео отзывов. Но вероятно так оно и будет(
Ну т.е. аналог того, что мы влзващали бы ошибку или результат как варианты sealed класса, только теперь меньше кода надо писать, если ошибки одинаковые в разных методах. В целом неплохо, но и не то, чтобы прямо интересно. У exception уникальная механика пробрасывания ошибки вверх по цепочке вызовов и finaly гарантирующий выполнение, а тут по сути просто синтаскический сахар.
Приходит пациент к врачу и говорит - доктор, у меня заноза в пальце ноги, помогите. А доктор отвечает - да у вас диабет второго типа, вон пальцы опухли, нафиг вам эту занозу выдирать, от диабета всё равно не поможет.
В штатах уже давно всё знают о проблеме продажи оружия, уже кучу раз обсуждалось это, но есть лобби производителей оружия, есть законодательная база которую тяжело победить (там право на приобретение черт побери в конституции), есть масса людей, которые считают что им лучше с оружием - это все очень сложно переломить. Но это не повод игнорировать - даже если это гипотетическикая проблема - возможность на 3д принтере напечатать неотслеживаемое никем оружие скачав stl за 5 секунд с доступного всем ресурса. (Так получается даже порно посмотреть сложнее, чем пушку себе скачать)
Да, любое решение можно обойти - как и любую систему безопасности, но чем выше цена такого обхода, тем меньше вероятность, что школьник напечатает пистолет и пристрелит человека, который его в фортнайт обыграл.
Очень грустно от таких промтов становится на самом деле. И вот от этого "написал капсом, теперь точно не проигнорирует". Человек вероятно абсолютно не понимает с каким инструментом работает, и таких ведь будет большинство. Ещё грустнее, что зачастую даже разработчики платформ подобных - не понимают этого (те, которые берут готовую llm, хостят её у себя, и обертку вокруг накручивают). Напоминает ситуацию, когда человек из лучших побуждений покупает картридж для фильтра "ультра", когда ему надо на деле "жесткость", и т.к. у ультры в жесткой воде ещё и срок жизни меньше - получает воду худшего качества за большие деньги.
И вот - весьма любопытный инструмент, позволяющий легко решать типовые задачи, и неплохо справляется например с ответами на вопросы по документации - пытаются использовать как панацею, складывается спорная репутация и безумие вокруг.
Вот парадокс - с одной стороны люди выдвигвют такие идеи (генерить, читать, аппрувить), а с другой - вроде как читать код с полным пониманием и вдумчивым анализом - сложнее чем его писать. Особенно если учесть, что нейросеть может очень тонко скрывать подставу - давая легетимные названия переменным, а потом делая с ними не то, что заявлено (это моё любимое от gpt-4o когда он тебе полностью правильный алгоритм решения задачи пишет, а потом абсолютно неправильное решение и подогнанный ответ)))
У них я думаю и так денег нету, а тут ещё надо море работы проделать рискованной. Разве что сбор могли бы на такое прорабатывать организовать, и если соберётся денег - сделать. Но это ведь ещё и оценить надо как-то перед сбром... короче сложно, дорого, не понятно кому нужно.
У меня инверторных холодильник в кухне-гостинной, и он весьма ощутимо шумел на первой заморозке когда выдавал полную мощность, но как только заморозится - его больше никогда не услышать, хоть ухо к самому девайсу прикладывай.
А start-stop - это час шума на два часа тишины, или если слишком чувствительная схема хуже - 5 минут шума на 10 тишины. На съемной квартире был такой - чудовищно, его в спальне из кухни слышно, так еще и с хлопком но включение.
Если бы мне такой ремонт мастер без предварительного согласования сделал, пришлось бы потом этого мастера искать чтобы забрал свою плату с компрессором и нахер дорогу ему показывать.
У меня есть несколько знакомых - которые такие и без ии. У них "я должен жить в этом месте потому что в пошлых жизнях я жил здесь", "я отвечаю за грехи своих предков но испытания вот вот закончатся", "весь мир подаёт мне знаки" и ещё куча такой бредятины, изотерики и гаданий. Причём - все как один - ведут с этим каналы в телеге))) правда они не особо успешны и их безумие можно понять попыткой сбежать от тяжелой жизни или себя.
Надо будет предупредить, чтобы не пользовались llm.
Если бы в походе был человек, который имеет представление о лавине - то он был бы пойман и допрошен, даже если сам бы трясся и плакал где нибудь в палатке и ничего делать не планировал. А если бы такого человека не было - был бы найдет наиболее подходящий или собран комитет. (точно так-же как был найден человек который знал как правильно разжечь костры под проливным ливнем).
Вы упорно путаете тимлидов и пм-ов, и не хотите сдаваться. Ваше дело. Но управляющими футбольных команд (топ-менеджерами спортивных клубов) становятся чаще всего не бывшие футболисты, а люди с опытом в менеджмете, финансах и юриспруденции, а бывшие футболисты становятся тренерами. Более того, Да и топ менеджеров компаний - легко берут из одной предметной области в другую (например из тяжелой металургии в ритейл, почему бы и нет) - и поверьте, ни в металургии ни в продажах в магазине - эти люди никогда в серьез не работали.
Еще раз - ПМ туда не работать ехал, он был обычным отдыхающим. Он не был отвественен за организацию - он мог понимать хоть во всем в мире, но события бы это не изменило. (Более того, я уверен, что если бы он был отвественным за организацию, то ничего такого бы не случилось, т.к. он бы и прогноз выяснил и перестраховался на все риски, и с опытными туристами бы проконсультировался)
По вашему ПМ - должен быть одновременно опытным дизайнером, опытным разработчиком, опытным тестировщиком, опытным аналитиком, опытным безопасником, опытным девопсом? Т.е. он должен в каждую роль в команде уметь, так еще и руководить? А если на проекте еще пару стеков технологических - он еще и в них обоих должен быть экспертом?
Нет - ну здорово если так, пойдите найдите такого на рынке, желательно чтобы он не стоил пол миллиона долларов в месяц.
Когда проблема - "дождь пошел непонятно откуда" - пм идет к меторологу, и говорит - "откуда пошел дождь?", он не должен сам становиться метеорологом. Если ему нужно при этом стать метеорологом значит только одно - он плохой пм и не умеет делегировать непрофильную часть.
Вот вообще не согласен. ПМ и разработчик не пересекающиеся должности. Ведущий инжинер и прораб - это скорее тимлид - человек который принимает корневые технические решения и определяет направление развития технической части проекта. Пм - это про работу с людьми, планирование и рискменеджмент, согласования и жонглирование мощностями.
Очень показателен был в моей практике был пример - когда на большой конференции (в поле, палаточный лагерь) - ночью пошел штормовой дождь, часть палаток залило, часть смыло, часть людей были в дрова, по всюду начали возникать проблемы - и пм (исключительно крутой), быстро оценив обстановку и не теряя головы - собрал группу, распределил задачи и отвественности, перераспределил ресурсы и в процессе мониторил и корректировал работы - и через 30 минут кризис был устранен - затопленные расселены, пьяные перенесны в сухость и безопасность, палатки пересобраны, костры разведены и т.д. (он кстати под утро жаловался, что приезхал отдыхать а тут опять работа)
При этом сам он - в походы не ходил и палатка ему далась в построении с большим трудом, да и разжечь костер под дождем не факт что он смог бы.
Пм-у не нужно владеть всеми компетенциями на проекте - для этого он может попросить оценить специалиста (а на проекте это программисты, дизайнеры, аналитики, безопасники, девопсеры, qa и проч.). Его дело знать что оценить, и что потом с этими данными сделать, чтобы при имеющихся ресурсах эффективно получить результат.
В принципе делегирование ответственности - годится для самых крутых спецов, которые могут и готовы поработать задачу на всех уровнях.
Ну с натяжкой, но джуны и студенты имеют свойство думать бесконечное количество времени, и могут не начать делать, а все думать и думать. Им лучше сразу предложить действовать а корректировать в процессе.
Есть такие сотрудники, которые без контроля могут неделями сидеть без задач или в заблокированном состоянии. Которые не способны давать обратную связь без запроса - таких придётся пинговать)
Сбалансированная рабочая команда - это вообще штука очень интересная ("человек который изменил все" - хоть и про бейсбол - но хорошо показывает, что хороший баланс позволяет солянкой быть почти на уровне команды сборных звёзд)
Если бы при собеседовании в компанию мне hr сказала - сейчас проведём тест - какой вы смешарик - я бы однозначно записал это в плюс компании. Креативные решения - последствия креативных проблем - а значит просто может и не быть, но и скучно не будет)
"можно ли доверить жизнь пациента решению системы, логику которой никто не понимает и не может гарантировать" - человечество уже много раз легко отвечало "да" на этот вопрос.
Даже сейчас мы лечим метформином диабет, литием биполярку не понимая почему это работает (но доказав клиническую эффективность). Даже полных принципов работы аспирина не понимаем. А уж что было до того с пиявками и кровопусканиями я даже вспоминать не хочу.
Так что если на достаточной для клинических исследований выборке (со всем нюансами случайности и разнообразия, и контрольными группами) - робот показывает себя лучше человека (особенно в 10 раз) - то в чем этическая дилемма?) Особенно если у конкретного человека будет выбор - оригинальный человек или generic робот, но в 10 раз лучше)
Да, согласен - в андроид до смешного доходит - фоновые процессы за 5 лет раза 4 переделывали, в итоге бывает приходишь пощупать новую технологию о которой "недавно услышал" - а она уже deprecated))
Вроде вот недавно relativeLayout завезли, потом всякие livedata, и уже от view в compose уходят.
И на swift не лучше - apple решила вкатиться в реактивность, а адаптеры к существующей своей же реактивности не завезла - в итоге новый и старый код не стыкуются так ещё на уровне наследования, где нельзя сразу всех уснаследовать)
Неправильно выразился. Я имел ввиду, скорее что падение качества с дистилятами не линейное, и есть ощущение, что "достаточное качество" наступает уже где-то на уровне 48b моделей. И не обязательно сразу упарываться в полную модель, можно постепенно докупая железо остановиться на устраивающем уровне.
Как с принципом паретто - если 20% модели дают 80% результата, то может те оставшиеся 20% результата и нафиг не нужны)
И сейчас то покупать тяжело (зачастую чтобы понять подходит техника или нет например, приходится искать инструкцию на сайте производителя и читать её), а в будущем видимо вообще будет нереально.
Из описанного - реально полезным выглядит ответ на запрос как альтернатива простому поиску - типо "нужна штука чтобы ...". И автоподборки. Но учитывая что пихать они будут из расчёта продать, а не подобрать нуженое - пользоваться все равно не выйдет.
Все остальное - выглядит как усложнение и без того безумно сложных карточек - типо подстраивающегося интерфейса (который ты только выучил, а он подстроился), и не дай бог видео отзывов. Но вероятно так оно и будет(
Ну т.е. аналог того, что мы влзващали бы ошибку или результат как варианты sealed класса, только теперь меньше кода надо писать, если ошибки одинаковые в разных методах. В целом неплохо, но и не то, чтобы прямо интересно. У exception уникальная механика пробрасывания ошибки вверх по цепочке вызовов и finaly гарантирующий выполнение, а тут по сути просто синтаскический сахар.
Приходит пациент к врачу и говорит - доктор, у меня заноза в пальце ноги, помогите. А доктор отвечает - да у вас диабет второго типа, вон пальцы опухли, нафиг вам эту занозу выдирать, от диабета всё равно не поможет.
В штатах уже давно всё знают о проблеме продажи оружия, уже кучу раз обсуждалось это, но есть лобби производителей оружия, есть законодательная база которую тяжело победить (там право на приобретение черт побери в конституции), есть масса людей, которые считают что им лучше с оружием - это все очень сложно переломить. Но это не повод игнорировать - даже если это гипотетическикая проблема - возможность на 3д принтере напечатать неотслеживаемое никем оружие скачав stl за 5 секунд с доступного всем ресурса. (Так получается даже порно посмотреть сложнее, чем пушку себе скачать)
Да, любое решение можно обойти - как и любую систему безопасности, но чем выше цена такого обхода, тем меньше вероятность, что школьник напечатает пистолет и пристрелит человека, который его в фортнайт обыграл.
Очень грустно от таких промтов становится на самом деле. И вот от этого "написал капсом, теперь точно не проигнорирует". Человек вероятно абсолютно не понимает с каким инструментом работает, и таких ведь будет большинство. Ещё грустнее, что зачастую даже разработчики платформ подобных - не понимают этого (те, которые берут готовую llm, хостят её у себя, и обертку вокруг накручивают). Напоминает ситуацию, когда человек из лучших побуждений покупает картридж для фильтра "ультра", когда ему надо на деле "жесткость", и т.к. у ультры в жесткой воде ещё и срок жизни меньше - получает воду худшего качества за большие деньги.
И вот - весьма любопытный инструмент, позволяющий легко решать типовые задачи, и неплохо справляется например с ответами на вопросы по документации - пытаются использовать как панацею, складывается спорная репутация и безумие вокруг.
Тогда 2/3 вайбкодинга теряется, т.к. то, что llm сгенерила за 10 минут, надо потом ещё час читать и осозновать)
Вот парадокс - с одной стороны люди выдвигвют такие идеи (генерить, читать, аппрувить), а с другой - вроде как читать код с полным пониманием и вдумчивым анализом - сложнее чем его писать. Особенно если учесть, что нейросеть может очень тонко скрывать подставу - давая легетимные названия переменным, а потом делая с ними не то, что заявлено (это моё любимое от gpt-4o когда он тебе полностью правильный алгоритм решения задачи пишет, а потом абсолютно неправильное решение и подогнанный ответ)))
У них я думаю и так денег нету, а тут ещё надо море работы проделать рискованной. Разве что сбор могли бы на такое прорабатывать организовать, и если соберётся денег - сделать. Но это ведь ещё и оценить надо как-то перед сбром... короче сложно, дорого, не понятно кому нужно.
Хер с ний с электроэнергией - шум.
У меня инверторных холодильник в кухне-гостинной, и он весьма ощутимо шумел на первой заморозке когда выдавал полную мощность, но как только заморозится - его больше никогда не услышать, хоть ухо к самому девайсу прикладывай.
А start-stop - это час шума на два часа тишины, или если слишком чувствительная схема хуже - 5 минут шума на 10 тишины. На съемной квартире был такой - чудовищно, его в спальне из кухни слышно, так еще и с хлопком но включение.
Если бы мне такой ремонт мастер без предварительного согласования сделал, пришлось бы потом этого мастера искать чтобы забрал свою плату с компрессором и нахер дорогу ему показывать.
А про автопилот не слышали?)
Звучит сложно)
Oled + быстрый контроллер - и можно никакой сетки дополнительной, и обвязки вокруг подсветки не делать)
У меня есть несколько знакомых - которые такие и без ии. У них "я должен жить в этом месте потому что в пошлых жизнях я жил здесь", "я отвечаю за грехи своих предков но испытания вот вот закончатся", "весь мир подаёт мне знаки" и ещё куча такой бредятины, изотерики и гаданий. Причём - все как один - ведут с этим каналы в телеге))) правда они не особо успешны и их безумие можно понять попыткой сбежать от тяжелой жизни или себя.
Надо будет предупредить, чтобы не пользовались llm.
Если бы в походе был человек, который имеет представление о лавине - то он был бы пойман и допрошен, даже если сам бы трясся и плакал где нибудь в палатке и ничего делать не планировал. А если бы такого человека не было - был бы найдет наиболее подходящий или собран комитет. (точно так-же как был найден человек который знал как правильно разжечь костры под проливным ливнем).
Вы упорно путаете тимлидов и пм-ов, и не хотите сдаваться. Ваше дело.
Но управляющими футбольных команд (топ-менеджерами спортивных клубов) становятся чаще всего не бывшие футболисты, а люди с опытом в менеджмете, финансах и юриспруденции, а бывшие футболисты становятся тренерами. Более того, Да и топ менеджеров компаний - легко берут из одной предметной области в другую (например из тяжелой металургии в ритейл, почему бы и нет) - и поверьте, ни в металургии ни в продажах в магазине - эти люди никогда в серьез не работали.
Конечно произошло бы.
Еще раз - ПМ туда не работать ехал, он был обычным отдыхающим. Он не был отвественен за организацию - он мог понимать хоть во всем в мире, но события бы это не изменило. (Более того, я уверен, что если бы он был отвественным за организацию, то ничего такого бы не случилось, т.к. он бы и прогноз выяснил и перестраховался на все риски, и с опытными туристами бы проконсультировался)
По вашему ПМ - должен быть одновременно опытным дизайнером, опытным разработчиком, опытным тестировщиком, опытным аналитиком, опытным безопасником, опытным девопсом? Т.е. он должен в каждую роль в команде уметь, так еще и руководить? А если на проекте еще пару стеков технологических - он еще и в них обоих должен быть экспертом?
Нет - ну здорово если так, пойдите найдите такого на рынке, желательно чтобы он не стоил пол миллиона долларов в месяц.
Когда проблема - "дождь пошел непонятно откуда" - пм идет к меторологу, и говорит - "откуда пошел дождь?", он не должен сам становиться метеорологом. Если ему нужно при этом стать метеорологом значит только одно - он плохой пм и не умеет делегировать непрофильную часть.
Вот вообще не согласен. ПМ и разработчик не пересекающиеся должности. Ведущий инжинер и прораб - это скорее тимлид - человек который принимает корневые технические решения и определяет направление развития технической части проекта. Пм - это про работу с людьми, планирование и рискменеджмент, согласования и жонглирование мощностями.
Очень показателен был в моей практике был пример - когда на большой конференции (в поле, палаточный лагерь) - ночью пошел штормовой дождь, часть палаток залило, часть смыло, часть людей были в дрова, по всюду начали возникать проблемы - и пм (исключительно крутой), быстро оценив обстановку и не теряя головы - собрал группу, распределил задачи и отвественности, перераспределил ресурсы и в процессе мониторил и корректировал работы - и через 30 минут кризис был устранен - затопленные расселены, пьяные перенесны в сухость и безопасность, палатки пересобраны, костры разведены и т.д. (он кстати под утро жаловался, что приезхал отдыхать а тут опять работа)
При этом сам он - в походы не ходил и палатка ему далась в построении с большим трудом, да и разжечь костер под дождем не факт что он смог бы.
Пм-у не нужно владеть всеми компетенциями на проекте - для этого он может попросить оценить специалиста (а на проекте это программисты, дизайнеры, аналитики, безопасники, девопсеры, qa и проч.). Его дело знать что оценить, и что потом с этими данными сделать, чтобы при имеющихся ресурсах эффективно получить результат.
"Потому, что только смелых уважает высота, потому что в самолёте все зависи ат винта..."
В принципе делегирование ответственности - годится для самых крутых спецов, которые могут и готовы поработать задачу на всех уровнях.
Ну с натяжкой, но джуны и студенты имеют свойство думать бесконечное количество времени, и могут не начать делать, а все думать и думать. Им лучше сразу предложить действовать а корректировать в процессе.
Есть такие сотрудники, которые без контроля могут неделями сидеть без задач или в заблокированном состоянии. Которые не способны давать обратную связь без запроса - таких придётся пинговать)
Сбалансированная рабочая команда - это вообще штука очень интересная ("человек который изменил все" - хоть и про бейсбол - но хорошо показывает, что хороший баланс позволяет солянкой быть почти на уровне команды сборных звёзд)
Если бы при собеседовании в компанию мне hr сказала - сейчас проведём тест - какой вы смешарик - я бы однозначно записал это в плюс компании. Креативные решения - последствия креативных проблем - а значит просто может и не быть, но и скучно не будет)
"можно ли доверить жизнь пациента решению системы, логику которой никто не понимает и не может гарантировать" - человечество уже много раз легко отвечало "да" на этот вопрос.
Даже сейчас мы лечим метформином диабет, литием биполярку не понимая почему это работает (но доказав клиническую эффективность). Даже полных принципов работы аспирина не понимаем. А уж что было до того с пиявками и кровопусканиями я даже вспоминать не хочу.
Так что если на достаточной для клинических исследований выборке (со всем нюансами случайности и разнообразия, и контрольными группами) - робот показывает себя лучше человека (особенно в 10 раз) - то в чем этическая дилемма?) Особенно если у конкретного человека будет выбор - оригинальный человек или generic робот, но в 10 раз лучше)
Да, согласен - в андроид до смешного доходит - фоновые процессы за 5 лет раза 4 переделывали, в итоге бывает приходишь пощупать новую технологию о которой "недавно услышал" - а она уже deprecated))
Вроде вот недавно relativeLayout завезли, потом всякие livedata, и уже от view в compose уходят.
И на swift не лучше - apple решила вкатиться в реактивность, а адаптеры к существующей своей же реактивности не завезла - в итоге новый и старый код не стыкуются так ещё на уровне наследования, где нельзя сразу всех уснаследовать)
Зато не скучно)
Неправильно выразился. Я имел ввиду, скорее что падение качества с дистилятами не линейное, и есть ощущение, что "достаточное качество" наступает уже где-то на уровне 48b моделей. И не обязательно сразу упарываться в полную модель, можно постепенно докупая железо остановиться на устраивающем уровне.
Как с принципом паретто - если 20% модели дают 80% результата, то может те оставшиеся 20% результата и нафиг не нужны)