Вы выше уже ответили что локальные модели можно подключить (хоть и там через конфиги а не из ui, но оно и у contine через жопу, все по Эскобару), так что моя претензия что проект Скам полностью снимается))
Просто если бы оно действительно было "взять opensource проект, вырезать из него возможность пользоваться своими моделями, вставить проприетарные модели и продавать доступ" - это прямо плохо)
Один из лучших примеров - автомобильные дороги. Чем больше становится полос и магистралей - тем больше людей покупают машины, а как результат - вся остальная инфраструктура начинает страдать и все стоят в пробках.
Но этот же пример показывает - что реально - проблема в том, что выбран неправильный путь масштабирования и что даже важнее - неправильные метрики (измеряем и оптимизирует количество проехавших машин, а нужно - людей).
Аналогично пример с паровым котлом - изменять потребление угля странно, а вот количество работы совершенной двигателями - вполне интересно (хотя конечно все зависит от цели).
Про llm - как будто все просто и сложно одновременно. Просто, потому что понятно, что нужно измерять эффективность решения задач сотрудниками с llm и без, с учётом качества результата. Сложно - потому что эти показатели (в сферах типо разработки ПО) и до llm было нетривиально измерить (от чего по поводу методик оценки задач уже не первый десяток лет ходят споры).
Но в любом случае считаю - что выгорание тут притянуто за уши. Выгорание - это практически всегда про плохие процессы.
Всегда старался не обновляются как можно дольше - пока проект собирается и новые фичи не требуются. Можно и дальше придерживаться этого подхода.
А то начинается - обновил студию, обнови градл плагин, обновил градл плагин, обнови зависимости, зависимости не обратно совместимы, а некоторых вообще больше нет - ищи замену, переписывай код, код переписал - теперь баги исправляй и тесты. А ещё и интерфейс поменялся, что нибудь ещё сломалось.
Особенно печально - когда лежит у тебя проект "для себя", которому 7ой год жизни идёт - и вот хотя тебе буквально никаких исправлений за 7 лет в нём не потребовалось - если нужно билд собрать - возможно даже не один день придется потратить, чтобы под новое окружение все обновить. Хоть студию нужной в гит рядом с проектом клади (для ios и legsy проектов помню кстати так и делали)
Только пожалуйста - проверяйте результат. Почти весь инструментарий для работы с llm как будто этими llm и написан. Тот же continue кладет intelij idea, постоянно глючит (на уровне интерфейса) и выглядит коряво. Десктопные клиенты зачастую не умеют в копи-паст - вообще бред.
А возможность подключить свои локальные модели будет?
А можно нажать кнопку перехода к следующей песне на наушниках или в крайнем случае смарт часах - без всего этого геморроя.
Вы реально думаете, что те, кто слушают с телефона спотифай так страдают?
А по поводу проблем с рекламой и прочими странными претензиями по поику любимой песни - нормальных плееров в сторе завались, где всего этого нет и интерфейс будет, каким захотите.
Эм... вы телефон с собой не берете? Как будто просто сейчас очень мало людей, которые выходят из дома не беря с собой телефон - чтобы его размер был хоть каким то аргументом в пользу МП3 плеера
Короче я понял, статья нужна как правильно оценивать Гиты кандидатов. Потому что ваш подход тоже вызывает сомнения - кандидат который знает sql в совершенстве может хранить в пет проекте файлы в базе и не делать индексы - главный вопрос осознанно он это делает или нет.
Потому что в домашнем проекте - где предельная нагрузка 3.5 папуаса, а данных 10 записей, хранить файлы в базе и забить на индексы - может оказать 0.00000000000000001% влияния производительность, но сэкономить пару часов.
Вот как раз хотел написать статью о том, как правильно оценивать гитхаб кандидата. И вы все сделали неправильно 😄
Гит - надо смотреть с целью задать вопросы, а не с целью проверить код и ведение гита. В домашних проектах совсем другие цели и задачи и совсем другие пути их решения.
Если проект буду поддерживать я и только я - возможно забью на правильный гитигнор. И в комментах могу писать хоть про огород бабушки, если не планирую их читать никогда.
Если это код, который никогда не планируется читать - то в нём не нужна декомпозиция или внятный стиль.
Если это проект для эксперементов - в нём может быть невероятная чушь вида поднятия всего opengl стека ради простой анимации или парсинга json руками с использованием регулярок.
Но посмотрев на это вы можете на собеседовании спросить почему сделано так, и как бы человек сделал будь это рабочий код - и вот если он скажет, что норм и так-же - это один вывод, а если он распишет минусы своего решения, причины почему так сделано, и как он бы сделал у вас - вы получите ценную информацию и скорее всего в итоге хорошего сотрудника.
Фраза "если человек делает хорошо, то будет делать хорошо везде", которую я слышал от коллег которые тоже оценивают гит кандидата как продуктовый - верна, но трактуется неправильно. Потому что хорошо решенная задача это далеко не всегда хорошо написанный код - зачастую в идеале это вообще код не написанный, или код написанный как угодно но срок, или код работающий только в нужных сценариях, или даже не работающий, но позволивший сделать необходимые выводы.
Это лучше, чем жариться у сана с раскалённым маслом в макдаке, а контингент туда идёт близкий - люди которым требуется подработка здесь и сейчас и у которых не очень много профессиональных навыков
Я с одной стороны с вами согласен. А с другой есть исключения - когда нужен утилитарный класс, тулза или кусок ui (не требуется контекст) - llm способны решить проблему очень быстро и круто. Например на днях мне нужно была утилита для быстрого преобразования объекта в json но с некоторой спецификой (из за чего библиотечные решения не подходили) - и llm написала этот код за минуту, хотя мне бы потребовалось минут 40. В микроскопическом pet проекте, для себя - наверное часа 2 работы решилось за 10 минут - когда надо было нагенерить любой прилично выглядевший ui под задачу.
В принципе сейчас считаю, навык отличить что быстрее нагенерить, а что написать - полезным (и наверное об этом статья, хоть и как-то очень размыто)
На новом функционале - реально наверное получить прирост в скорости и в 50%. Правда создание нового функционала без контента - это прям капля в океане работы программиста))
Возможно кстати - по итогу мы получим новый подход к разработке - когда качество кода не важно, весь код пишется чтобы быть выброшен, а все фичи очень сильно декомпозированы, чтобы контекст был минимальным и их было можно быстро перегенерить.
Не. Проблема состоит в том, что автор статьи сначала описывает проблему (высокую сложность модификации кода из за большой иерархичности данных при использовании ооп), а потом предлагает подход, который никак эту проблему как будто не решает.
Ну то есть даже безотносительно того, хороший ли подход к хранению всего игрового состояния в глобальной таблице или плохой - непонятно, как это влияет на то, что чтобы рассчитать урон меча с учётом перчаток и разных типов - все равно придется пройтись по таблице всех itemов, взять для каждого item подтаблицу параметров и по формуле где-то это свети с itemами оппонента, чтобы рассчитать урон.
Исправляюсь, получается вся продукция razer кроме клавиатур))
А про кресла, тоже сижу на dxracer но честно говоря и половины своих денег это говнецо не стоит (хоть и жалко признавать себе, что выкинул 50к). Купил в другой город себе визуально похожее кресло за четверть цены - и практически не заметил разницы. А удобнее всего было на офисном самуре который у меня был до того. Но он очень быстро отправился на тот свет ввиду некачественной пайки подлокотников.
Тоже прикидывал какое бы я нынче взял себе кресло, если бы моё двинуло кони, и это было бы что-то типо ergolife sit 8, но точно не очередной игровой кофш)
Вот если человек начинает противостоять и идти на конфликт - у меня сразу возникают сомнения в его оценке действий руководителя в том числе.
Обычно высококлассный специалист ограничивается предупреждением руководства о последствиях - и дальше либо принимает правила игры (и саркастично смотрит как всё разваливается, имея у себя за пазухой припасённое сообщение, где он предупреждал что всё так и будет), либо меняет работу. Но "с кулаками" никуда не лезет.
А если линейный сотрудник (независимо от крутости) - лезет в работу управленца и пытается навязать свою позицию (иначе конфликта бы не было). То даже если позиция правильная, я все равно такие случаи не считаю т.к. правильность позиции зависит от точки зрения и объема данных.
Вот вроде бы быстрого получения ответа по документации здорово - а с другой стороны - периодически даёт неправильные трактовки методам или параметрам. Короче вроде и удобно, а вроде и если ссылку на собственно документацию не попросить - есть вероятность налететь на проблемы
Из текста получается - главная проблема в том, что вы решали не ту задачу, которая нужна заказчикам.
Так - конечно получится провал.
Раз конкуренты смогли условно по цене 20% реализовать весь необходимый заказчику функционал, то значит 80% ушли у вас на задачи, которые заказчику не нужны.
Грустно, но закономерный исход. Именно из за этого в инвестициях сейчас правит подход - сначала продай, потом разрабатывай.
Вы выше уже ответили что локальные модели можно подключить (хоть и там через конфиги а не из ui, но оно и у contine через жопу, все по Эскобару), так что моя претензия что проект Скам полностью снимается))
Просто если бы оно действительно было "взять opensource проект, вырезать из него возможность пользоваться своими моделями, вставить проприетарные модели и продавать доступ" - это прямо плохо)
Один из лучших примеров - автомобильные дороги. Чем больше становится полос и магистралей - тем больше людей покупают машины, а как результат - вся остальная инфраструктура начинает страдать и все стоят в пробках.
Но этот же пример показывает - что реально - проблема в том, что выбран неправильный путь масштабирования и что даже важнее - неправильные метрики (измеряем и оптимизирует количество проехавших машин, а нужно - людей).
Аналогично пример с паровым котлом - изменять потребление угля странно, а вот количество работы совершенной двигателями - вполне интересно (хотя конечно все зависит от цели).
Про llm - как будто все просто и сложно одновременно. Просто, потому что понятно, что нужно измерять эффективность решения задач сотрудниками с llm и без, с учётом качества результата. Сложно - потому что эти показатели (в сферах типо разработки ПО) и до llm было нетривиально измерить (от чего по поводу методик оценки задач уже не первый десяток лет ходят споры).
Но в любом случае считаю - что выгорание тут притянуто за уши. Выгорание - это практически всегда про плохие процессы.
Всегда старался не обновляются как можно дольше - пока проект собирается и новые фичи не требуются. Можно и дальше придерживаться этого подхода.
А то начинается - обновил студию, обнови градл плагин, обновил градл плагин, обнови зависимости, зависимости не обратно совместимы, а некоторых вообще больше нет - ищи замену, переписывай код, код переписал - теперь баги исправляй и тесты. А ещё и интерфейс поменялся, что нибудь ещё сломалось.
Особенно печально - когда лежит у тебя проект "для себя", которому 7ой год жизни идёт - и вот хотя тебе буквально никаких исправлений за 7 лет в нём не потребовалось - если нужно билд собрать - возможно даже не один день придется потратить, чтобы под новое окружение все обновить. Хоть студию нужной в гит рядом с проектом клади (для ios и legsy проектов помню кстати так и делали)
Скам получается какой-то)
Хотя и continue настолько кривой (для intelij idea), что сам - Скам)
Только пожалуйста - проверяйте результат. Почти весь инструментарий для работы с llm как будто этими llm и написан. Тот же continue кладет intelij idea, постоянно глючит (на уровне интерфейса) и выглядит коряво. Десктопные клиенты зачастую не умеют в копи-паст - вообще бред.
А возможность подключить свои локальные модели будет?
А можно нажать кнопку перехода к следующей песне на наушниках или в крайнем случае смарт часах - без всего этого геморроя.
Вы реально думаете, что те, кто слушают с телефона спотифай так страдают?
А по поводу проблем с рекламой и прочими странными претензиями по поику любимой песни - нормальных плееров в сторе завались, где всего этого нет и интерфейс будет, каким захотите.
Эм... вы телефон с собой не берете? Как будто просто сейчас очень мало людей, которые выходят из дома не беря с собой телефон - чтобы его размер был хоть каким то аргументом в пользу МП3 плеера
Короче я понял, статья нужна как правильно оценивать Гиты кандидатов. Потому что ваш подход тоже вызывает сомнения - кандидат который знает sql в совершенстве может хранить в пет проекте файлы в базе и не делать индексы - главный вопрос осознанно он это делает или нет.
Потому что в домашнем проекте - где предельная нагрузка 3.5 папуаса, а данных 10 записей, хранить файлы в базе и забить на индексы - может оказать 0.00000000000000001% влияния производительность, но сэкономить пару часов.
Вот как раз хотел написать статью о том, как правильно оценивать гитхаб кандидата. И вы все сделали неправильно 😄
Гит - надо смотреть с целью задать вопросы, а не с целью проверить код и ведение гита. В домашних проектах совсем другие цели и задачи и совсем другие пути их решения.
Если проект буду поддерживать я и только я - возможно забью на правильный гитигнор. И в комментах могу писать хоть про огород бабушки, если не планирую их читать никогда.
Если это код, который никогда не планируется читать - то в нём не нужна декомпозиция или внятный стиль.
Если это проект для эксперементов - в нём может быть невероятная чушь вида поднятия всего opengl стека ради простой анимации или парсинга json руками с использованием регулярок.
Но посмотрев на это вы можете на собеседовании спросить почему сделано так, и как бы человек сделал будь это рабочий код - и вот если он скажет, что норм и так-же - это один вывод, а если он распишет минусы своего решения, причины почему так сделано, и как он бы сделал у вас - вы получите ценную информацию и скорее всего в итоге хорошего сотрудника.
Фраза "если человек делает хорошо, то будет делать хорошо везде", которую я слышал от коллег которые тоже оценивают гит кандидата как продуктовый - верна, но трактуется неправильно. Потому что хорошо решенная задача это далеко не всегда хорошо написанный код - зачастую в идеале это вообще код не написанный, или код написанный как угодно но срок, или код работающий только в нужных сценариях, или даже не работающий, но позволивший сделать необходимые выводы.
Это лучше, чем жариться у сана с раскалённым маслом в макдаке, а контингент туда идёт близкий - люди которым требуется подработка здесь и сейчас и у которых не очень много профессиональных навыков
Я с одной стороны с вами согласен. А с другой есть исключения - когда нужен утилитарный класс, тулза или кусок ui (не требуется контекст) - llm способны решить проблему очень быстро и круто. Например на днях мне нужно была утилита для быстрого преобразования объекта в json но с некоторой спецификой (из за чего библиотечные решения не подходили) - и llm написала этот код за минуту, хотя мне бы потребовалось минут 40. В микроскопическом pet проекте, для себя - наверное часа 2 работы решилось за 10 минут - когда надо было нагенерить любой прилично выглядевший ui под задачу.
В принципе сейчас считаю, навык отличить что быстрее нагенерить, а что написать - полезным (и наверное об этом статья, хоть и как-то очень размыто)
На новом функционале - реально наверное получить прирост в скорости и в 50%. Правда создание нового функционала без контента - это прям капля в океане работы программиста))
Возможно кстати - по итогу мы получим новый подход к разработке - когда качество кода не важно, весь код пишется чтобы быть выброшен, а все фичи очень сильно декомпозированы, чтобы контекст был минимальным и их было можно быстро перегенерить.
Не. Проблема состоит в том, что автор статьи сначала описывает проблему (высокую сложность модификации кода из за большой иерархичности данных при использовании ооп), а потом предлагает подход, который никак эту проблему как будто не решает.
Ну то есть даже безотносительно того, хороший ли подход к хранению всего игрового состояния в глобальной таблице или плохой - непонятно, как это влияет на то, что чтобы рассчитать урон меча с учётом перчаток и разных типов - все равно придется пройтись по таблице всех itemов, взять для каждого item подтаблицу параметров и по формуле где-то это свети с itemами оппонента, чтобы рассчитать урон.
Исправляюсь, получается вся продукция razer кроме клавиатур))
А про кресла, тоже сижу на dxracer но честно говоря и половины своих денег это говнецо не стоит (хоть и жалко признавать себе, что выкинул 50к). Купил в другой город себе визуально похожее кресло за четверть цены - и практически не заметил разницы. А удобнее всего было на офисном самуре который у меня был до того. Но он очень быстро отправился на тот свет ввиду некачественной пайки подлокотников.
Тоже прикидывал какое бы я нынче взял себе кресло, если бы моё двинуло кони, и это было бы что-то типо ergolife sit 8, но точно не очередной игровой кофш)
Вот если человек начинает противостоять и идти на конфликт - у меня сразу возникают сомнения в его оценке действий руководителя в том числе.
Обычно высококлассный специалист ограничивается предупреждением руководства о последствиях - и дальше либо принимает правила игры (и саркастично смотрит как всё разваливается, имея у себя за пазухой припасённое сообщение, где он предупреждал что всё так и будет), либо меняет работу. Но "с кулаками" никуда не лезет.
А если линейный сотрудник (независимо от крутости) - лезет в работу управленца и пытается навязать свою позицию (иначе конфликта бы не было). То даже если позиция правильная, я все равно такие случаи не считаю т.к. правильность позиции зависит от точки зрения и объема данных.
??? Не понял о чем вы
Интересно - а есть конторы готовые за тебя пройти этот квест, и дорого ли стоят их услуги
Всё жду, когда что-то такое появится в виде библиотеки, чтобы легко интегрировать llm в свое приложение и оно работало локально на устройстве
Вот вроде бы быстрого получения ответа по документации здорово - а с другой стороны - периодически даёт неправильные трактовки методам или параметрам. Короче вроде и удобно, а вроде и если ссылку на собственно документацию не попросить - есть вероятность налететь на проблемы
А чем он лучше 7zip-а?
Из текста получается - главная проблема в том, что вы решали не ту задачу, которая нужна заказчикам.
Так - конечно получится провал.
Раз конкуренты смогли условно по цене 20% реализовать весь необходимый заказчику функционал, то значит 80% ушли у вас на задачи, которые заказчику не нужны.
Грустно, но закономерный исход. Именно из за этого в инвестициях сейчас правит подход - сначала продай, потом разрабатывай.