Упрощённо - никакими "своими" ключами - ничего подписать будет нельзя - только ключами, которые выдал гугл. Приложение подписанное своим ключём не установится на устройство, отвечать за проверку ключа будут гугл сервисы.
Это как с картриджами на приставках - вы конечно можете выпустить свой картридж со своим ключём, только ни одна приставка - проверяющая подлинность, ваш картридж не запустит
Вот тут может даже пригодиться плашка про дефектное устройство - которая у нас по закону для девайсов, куда рустор не поставить. Сертификацию ему могут и не дать, и тогда так можно будет отличить бестолковые "сертифицированные" устройства, от нормальных, куда можно ставить любые приложения.
Одна "беда" - в коммерческой разработке я практически не видел "плоских" проектов т.к. это очень дорого из за минимального переиспользования компонентов.
Везде используется свой инструментарий который базируется на другом своем инструментарии и так в 10 слоев. А с этим llm уже не справляются.
Моя (пока очень небольшая) практика показывает - что строить "плоские" приложения с помощью llm можно. И можно делать это быстро и удобно и даже качественно. Нужно поддерживать очень сильную декомпозированность кода, минимальную связанность, и всё, что только можно - выносить в утилиты. Утилиты llm пишут отлично (их конечно приходится править руками, но не много). Классы работающие с простым api - тоже (имеется в виду - что разрабатываемый код опирается на api, который уже оперирует примитивами).
Когда у тебя каждая задача очень маленькая, хорошо описана, и особенно опирается на стандартные вещи (например цвета берутся из темы приложения, данные из репозитория который атомарно отдаёт их примитивами, интерфейс построен из стандартных компонентов) - то это работает круто.
Минусом всего этого - поддерживать такой уровень качества кода и описания задач - не сильно-то проще и быстрее, чем написать все самому. А ещё отпадает возможность писать сложный функциональный инструментарий (какие нибудь свои хитрые ui компоненты например - их llm не поймет тупо)
Плюсом - код декомпозирован, независим, готов к выбрасыванию - любой компонент при необходимости можно даже не исправлять, а перегенерить целиком.
В процессе прочтения возникло ощущение, что я быстрее напишу проект руками, чем договорюсь по всем указанным пунктам с нейросетью. Особенно для задачи из примера - которую если исключить настройку докера - я как будто за пару часов решал.
Вот это имхо первый шаг в бесконечно длинном пути, который может сделать антропоморфных работы полезными. Но что-то слабо верится, что этот путь кто-то пройдет и это вообще имеет смысл.
Чтобы роботам двигающимся с использованием нейромоделей можно было доверять - их либо придется дополнительно не нейро-алгортимом ограничивать, либо делать слабыми и мягкими (бэймакс). А так - если это будет железка способная пожать пару тонн, как верить, что в один момент он не перепутает твою ногу с шлангом пылесоса, и не протаскивает тебя лицом по всему дому
Вариант для инференса уже реален дома. Да круто было бы запускать бОльшие модели, очень жду. А вот обучение пока даже не близко - все равно удел больших серверных ферм
Бактерии остаются на hepa, и дальше уже никуда не летят, а во многих очистителях ещё и добавляют пропитку фильтра, чтобы пировать им там было веселее. Впрочем, им обычно и так там не особо хорошо живётся, если в помещении нормальная влажность.
Вирусы (которые тоже пируют, правда вне носителя - не живые даже) - либо прилипают (а там высокая вероятность), либо нет. Но если это респираторка - там вирус в аэрозоли - а она точно осядет на фильтре.
От части есть такое(( В надежде немного "переломить" ситуацию была написана статья (основной посыл как раз - ссылка на гит не может считаться в минус). По факту - ссылка на гит если он у кандидата есть - может привести к куда более конструктивному собеседованию, по результатам которого будет выстроено более точное мнение о кандидате (зачастую еще люди считают - что мнение о кандидате бывает только хорошее или плохое, но на деле - оно скорее совпадаем/не совпадаем. И кандидат который например показал более низкий технический уровень, но лучшие софт скилы или мотивацию или умение работать с монотонными задачами будет интереснее, чем более хардовый специалист). А правильное менение о кандидате - залог того, что ни с одной стороны после трудоустройства не будет неоправданных ожиданий. Короче для всех хорошо)))
А что вас интересует? Имен и проектов я очевидно раскрыть не могу (да и не помню уже честно говоря).
Пришел человек у которого на гитхабе была openSource библиотека, позволяющая если правильно помню - производить обработку изображений в декларативном стиле (вырезать круг, сделать блюр, сделать tint, масштабировать и прочее). Мы ей не пользовались, но репа была достаточно звёздна, и востребованная.
На интервью показал себя великолепно.
А дальше все просто - мы выкатили оффер, но какой-то банк просто выкатили оффер жирнее, которой мы не могли перебить, и кандидат ушел.
Я совершенно согласен с тем, что требовать гит у кандитата в качестве подтверждение опыта - совершенно абсурдно. Действительно есть миллион ситуаций - когда на свои проекты нет времени или сил. Но то, что прямо категорически - те у кого есть гит, ноулайферы - не согалсен. У меня примерно у половины товарищей разработчиков - есть какой нибудь проект домашний. У кого-то это приложение для пылесоса, у кого-то - собственная прокся до конкретного ресурса в сети, у кого-то недоделанная игра, один парень пытается сейчас в ai-агентов. Есть и большие проекты и маленькие.
А про 10 этажный дом... самое забавное что пришлось уточнять про 10 этажный - иначе аналогия не работает)) ведь строители которые строят сначала дома проектна и дома для себя тоже строят потом сами (я прямо сейчас в таком нахожусь в гостях, и видит бог - архитектурный перокт ему бы не помешал)
История про человека, которого наняли чтобы улучшить ведение гита - это огонь))
Я тоже кстати думал что позиция - не оценивать пет проекты метриками коммерческих - очевидна, а оказалось что не всем. Так что "ваше мнение очень важно для нас" :D
То, что в результате внедрения ии работник стал решать больше задач и больше из-за этого стрессует (было в статье), это пример неправильных процессов - где они построены таким образом, что задачи вызвают стресс у работника (а значит вероятно его бьют палками за просрочки или невыполнение нормы там, где это не требуется).
Если всё сделать правильно - задачи не будут вызывать стресс у сотрудника, сколько бы их не было.
Единственное что - я бы добавил рядом с дублированием ещё один пункт - не бойтесь писать одноразовый код, и выбрасывать его при изменении логики.
Часто видел в проектах - где есть уже хорошая, устойчивая к изменениям, декомпозированы архитектура, ситуации - когда ради например экрана ошибки (цель которого вывести одну строку) - вместо "скинуть все в кучу в одном классе за 5 минут" - выстраиваются все слои абстракции, слабой связности и прочего (на что тратился целый день). А потом все это ржавело, а в худшем случае ещё и требовало поддержки, при том, что продуктовая логика никогда не менялась.
Я бы вообще добавил это как паттерн - пишешь класс, который не должен эволюционировать. Прямо быстро, прямо спагетти кодом с прямыми вызовами (задуман на выброс) - отмечаешь его аннотацией trash, и в регламенте запрещаешь вносить в этот код любые усложнения.
Зачастую написанный "говнокодом" класс может просуществовать весь цикл жизни приложения и так и не потребовать его прочитать.
В принципе это сходится с пунктом статьи про непредугадывание, но все же немного про другое.
Про автообновления образа это вы конечно сильно. Два раза обновлял immich (раз в пол года) - оба раза надо было последовательно перечитать все патчноты на предмет breaking update и в ручную чего нибудь переконфигурировать. Иначе даже при накатывании обновлений последовательно один за другим - сервер кирпичился (обратимо, но всё-же).
И обратная проблема - заморозил версию сервера - клиент на мобиле тоже обновлять нельзя. Если ГП его обновит - все шансы что просто не заведётся.
Вот сейчас надо бы опять обновить, но руки не доходят
Вы неверно прочитали описание фичи.
Упрощённо - никакими "своими" ключами - ничего подписать будет нельзя - только ключами, которые выдал гугл. Приложение подписанное своим ключём не установится на устройство, отвечать за проверку ключа будут гугл сервисы.
Это как с картриджами на приставках - вы конечно можете выпустить свой картридж со своим ключём, только ни одна приставка - проверяющая подлинность, ваш картридж не запустит
Вот тут может даже пригодиться плашка про дефектное устройство - которая у нас по закону для девайсов, куда рустор не поставить. Сертификацию ему могут и не дать, и тогда так можно будет отличить бестолковые "сертифицированные" устройства, от нормальных, куда можно ставить любые приложения.
А в какой ide интегрированный gemini может выполнять код?
Одна "беда" - в коммерческой разработке я практически не видел "плоских" проектов т.к. это очень дорого из за минимального переиспользования компонентов.
Везде используется свой инструментарий который базируется на другом своем инструментарии и так в 10 слоев. А с этим llm уже не справляются.
Моя (пока очень небольшая) практика показывает - что строить "плоские" приложения с помощью llm можно. И можно делать это быстро и удобно и даже качественно. Нужно поддерживать очень сильную декомпозированность кода, минимальную связанность, и всё, что только можно - выносить в утилиты. Утилиты llm пишут отлично (их конечно приходится править руками, но не много). Классы работающие с простым api - тоже (имеется в виду - что разрабатываемый код опирается на api, который уже оперирует примитивами).
Когда у тебя каждая задача очень маленькая, хорошо описана, и особенно опирается на стандартные вещи (например цвета берутся из темы приложения, данные из репозитория который атомарно отдаёт их примитивами, интерфейс построен из стандартных компонентов) - то это работает круто.
Минусом всего этого - поддерживать такой уровень качества кода и описания задач - не сильно-то проще и быстрее, чем написать все самому. А ещё отпадает возможность писать сложный функциональный инструментарий (какие нибудь свои хитрые ui компоненты например - их llm не поймет тупо)
Плюсом - код декомпозирован, независим, готов к выбрасыванию - любой компонент при необходимости можно даже не исправлять, а перегенерить целиком.
В процессе прочтения возникло ощущение, что я быстрее напишу проект руками, чем договорюсь по всем указанным пунктам с нейросетью. Особенно для задачи из примера - которую если исключить настройку докера - я как будто за пару часов решал.
Так, что там, у harmony os нормальный сдк? Что-то резко захотелось перейти на другую ос
Вот это имхо первый шаг в бесконечно длинном пути, который может сделать антропоморфных работы полезными. Но что-то слабо верится, что этот путь кто-то пройдет и это вообще имеет смысл.
Чтобы роботам двигающимся с использованием нейромоделей можно было доверять - их либо придется дополнительно не нейро-алгортимом ограничивать, либо делать слабыми и мягкими (бэймакс). А так - если это будет железка способная пожать пару тонн, как верить, что в один момент он не перепутает твою ногу с шлангом пылесоса, и не протаскивает тебя лицом по всему дому
Вариант для инференса уже реален дома. Да круто было бы запускать бОльшие модели, очень жду. А вот обучение пока даже не близко - все равно удел больших серверных ферм
Бактерии остаются на hepa, и дальше уже никуда не летят, а во многих очистителях ещё и добавляют пропитку фильтра, чтобы пировать им там было веселее. Впрочем, им обычно и так там не особо хорошо живётся, если в помещении нормальная влажность.
Вирусы (которые тоже пируют, правда вне носителя - не живые даже) - либо прилипают (а там высокая вероятность), либо нет. Но если это респираторка - там вирус в аэрозоли - а она точно осядет на фильтре.
Я думаю git - можно считать общепонятным сокращением для git репозиторий. А провайдер тут не важен - хоть bitbucket
Согласен - тут плюс "заморочился" вполную перекрывается минусом "попытался обмануть", выявленным по результатам беседы)
От части есть такое((
В надежде немного "переломить" ситуацию была написана статья (основной посыл как раз - ссылка на гит не может считаться в минус).
По факту - ссылка на гит если он у кандидата есть - может привести к куда более конструктивному собеседованию, по результатам которого будет выстроено более точное мнение о кандидате (зачастую еще люди считают - что мнение о кандидате бывает только хорошее или плохое, но на деле - оно скорее совпадаем/не совпадаем. И кандидат который например показал более низкий технический уровень, но лучшие софт скилы или мотивацию или умение работать с монотонными задачами будет интереснее, чем более хардовый специалист).
А правильное менение о кандидате - залог того, что ни с одной стороны после трудоустройства не будет неоправданных ожиданий. Короче для всех хорошо)))
Да вы думаете у меня осталась что-ли) это было ~4 года назад) я уже и компанию сменить успел)
А что вас интересует? Имен и проектов я очевидно раскрыть не могу (да и не помню уже честно говоря).
Пришел человек у которого на гитхабе была openSource библиотека, позволяющая если правильно помню - производить обработку изображений в декларативном стиле (вырезать круг, сделать блюр, сделать tint, масштабировать и прочее). Мы ей не пользовались, но репа была достаточно звёздна, и востребованная.
На интервью показал себя великолепно.
А дальше все просто - мы выкатили оффер, но какой-то банк просто выкатили оффер жирнее, которой мы не могли перебить, и кандидат ушел.
Я совершенно согласен с тем, что требовать гит у кандитата в качестве подтверждение опыта - совершенно абсурдно. Действительно есть миллион ситуаций - когда на свои проекты нет времени или сил.
Но то, что прямо категорически - те у кого есть гит, ноулайферы - не согалсен. У меня примерно у половины товарищей разработчиков - есть какой нибудь проект домашний. У кого-то это приложение для пылесоса, у кого-то - собственная прокся до конкретного ресурса в сети, у кого-то недоделанная игра, один парень пытается сейчас в ai-агентов. Есть и большие проекты и маленькие.
А про 10 этажный дом... самое забавное что пришлось уточнять про 10 этажный - иначе аналогия не работает)) ведь строители которые строят сначала дома проектна и дома для себя тоже строят потом сами (я прямо сейчас в таком нахожусь в гостях, и видит бог - архитектурный перокт ему бы не помешал)
История про человека, которого наняли чтобы улучшить ведение гита - это огонь))
Я тоже кстати думал что позиция - не оценивать пет проекты метриками коммерческих - очевидна, а оказалось что не всем. Так что "ваше мнение очень важно для нас" :D
Приведите пример.
То, что в результате внедрения ии работник стал решать больше задач и больше из-за этого стрессует (было в статье), это пример неправильных процессов - где они построены таким образом, что задачи вызвают стресс у работника (а значит вероятно его бьют палками за просрочки или невыполнение нормы там, где это не требуется).
Если всё сделать правильно - задачи не будут вызывать стресс у сотрудника, сколько бы их не было.
В статье все по делу.
Единственное что - я бы добавил рядом с дублированием ещё один пункт - не бойтесь писать одноразовый код, и выбрасывать его при изменении логики.
Часто видел в проектах - где есть уже хорошая, устойчивая к изменениям, декомпозированы архитектура, ситуации - когда ради например экрана ошибки (цель которого вывести одну строку) - вместо "скинуть все в кучу в одном классе за 5 минут" - выстраиваются все слои абстракции, слабой связности и прочего (на что тратился целый день). А потом все это ржавело, а в худшем случае ещё и требовало поддержки, при том, что продуктовая логика никогда не менялась.
Я бы вообще добавил это как паттерн - пишешь класс, который не должен эволюционировать. Прямо быстро, прямо спагетти кодом с прямыми вызовами (задуман на выброс) - отмечаешь его аннотацией trash, и в регламенте запрещаешь вносить в этот код любые усложнения.
Зачастую написанный "говнокодом" класс может просуществовать весь цикл жизни приложения и так и не потребовать его прочитать.
В принципе это сходится с пунктом статьи про непредугадывание, но все же немного про другое.
Про автообновления образа это вы конечно сильно. Два раза обновлял immich (раз в пол года) - оба раза надо было последовательно перечитать все патчноты на предмет breaking update и в ручную чего нибудь переконфигурировать. Иначе даже при накатывании обновлений последовательно один за другим - сервер кирпичился (обратимо, но всё-же).
И обратная проблема - заморозил версию сервера - клиент на мобиле тоже обновлять нельзя. Если ГП его обновит - все шансы что просто не заведётся.
Вот сейчас надо бы опять обновить, но руки не доходят