Всегда старался не обновляются как можно дольше - пока проект собирается и новые фичи не требуются. Можно и дальше придерживаться этого подхода.
А то начинается - обновил студию, обнови градл плагин, обновил градл плагин, обнови зависимости, зависимости не обратно совместимы, а некоторых вообще больше нет - ищи замену, переписывай код, код переписал - теперь баги исправляй и тесты. А ещё и интерфейс поменялся, что нибудь ещё сломалось.
Особенно печально - когда лежит у тебя проект "для себя", которому 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% ушли у вас на задачи, которые заказчику не нужны.
Грустно, но закономерный исход. Именно из за этого в инвестициях сейчас правит подход - сначала продай, потом разрабатывай.
Пока какой нибудь telegram или watsapp не интегрируют в себя такую штуку (а в телегу вполне могли бы), которая автоматически включалась бы при отсутствии интернета - нужной массовости чтобы обеспечить связность сети хотя бы одном доме - не наберётся. И все это звучит как очень нишевые штуки, которыми никто никогда не воспользуется
Как будто подобные статьи отлично опровергают даже своим существованием целесообразность человекоподобных роботов.
Его тут через симуляции с огромным трудом учат выполнять задачу, в которой минимум неопределенности (барабаны всегда на одних и тех же позициях, одни и те-же, движения все одинаковые). И все равно результат весьма слабый даже в самой симуляции.
В защитники антропоморфных роботов рассказывают, как они сэкономят за счёт того, что один робот будет решать все задачи пользуясь оборудованием для человека.
Да при таком плохом и сложном обучении на статичных задачах - каких бесконечных денег и проблем будет стоить обучение и эксплуатация в динамичном - где каждый нож/вилка/сковорода разных размеров, весов и добротности.
Всегда старался не обновляются как можно дольше - пока проект собирается и новые фичи не требуются. Можно и дальше придерживаться этого подхода.
А то начинается - обновил студию, обнови градл плагин, обновил градл плагин, обнови зависимости, зависимости не обратно совместимы, а некоторых вообще больше нет - ищи замену, переписывай код, код переписал - теперь баги исправляй и тесты. А ещё и интерфейс поменялся, что нибудь ещё сломалось.
Особенно печально - когда лежит у тебя проект "для себя", которому 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% ушли у вас на задачи, которые заказчику не нужны.
Грустно, но закономерный исход. Именно из за этого в инвестициях сейчас правит подход - сначала продай, потом разрабатывай.
Пока какой нибудь telegram или watsapp не интегрируют в себя такую штуку (а в телегу вполне могли бы), которая автоматически включалась бы при отсутствии интернета - нужной массовости чтобы обеспечить связность сети хотя бы одном доме - не наберётся. И все это звучит как очень нишевые штуки, которыми никто никогда не воспользуется
Как будто подобные статьи отлично опровергают даже своим существованием целесообразность человекоподобных роботов.
Его тут через симуляции с огромным трудом учат выполнять задачу, в которой минимум неопределенности (барабаны всегда на одних и тех же позициях, одни и те-же, движения все одинаковые). И все равно результат весьма слабый даже в самой симуляции.
В защитники антропоморфных роботов рассказывают, как они сэкономят за счёт того, что один робот будет решать все задачи пользуясь оборудованием для человека.
Да при таком плохом и сложном обучении на статичных задачах - каких бесконечных денег и проблем будет стоить обучение и эксплуатация в динамичном - где каждый нож/вилка/сковорода разных размеров, весов и добротности.