Для автора, который запускает на replicate может и без разницы. А в условиях, когда доступ к зарубежным ресурсам в любой момент может закончится разница есть. Говоря о локальных моделей -- для задачи постобработки текста достаточно квена и прямых рук. На кой фиг там gpt5?
Гм. А чем модель, крутящаяся не на контролируемом мной железе (Mistral OCR) лучше? Особенно для чувствительных данных. Но революции тут не вижу, да. P.S. Там китайцы уже HunyuanOCR выпустили -- новая SOTA в OCR. Выглядит очень неплохо.
Командировки разные бывают. Когда едешь на конференцию -- там особо ноут не нужен. Или сбор части команды для обсуждения дальнейшей стратегии развития (большинство на удалёнке) -- большинству тоже не нужны. Я в прошлом году брал -- только протаскал зазря. А на связи таки быть нужно.
То есть логика "мне не нужен -- значит никому не нужен"? А переть с собой ноут, который 100% не понадобится в командировке, ради рабочего чата -- ну такое себе.
Нужна. Как правило какой-нибудь срочный вопрос возникает в тот момент, когда отошёл в магазин / отъехал за ребёнком в детский садик / etc. И в командировку я с собой ноут не попру (+3 кг с собой таскать -- ну такое), а на связи быть надо.
Дополню свой предыдущий комментарий. Как уже некоторые комментаторы писали, этот «тест» не показывает реальный опыт. Промолчу про задачку с условиями (за такой код надо бить). Но возьмём то же множественное наследование: это как нужно было накосячить с архитектурой, что пришлось к нему прибегать? Соответственно, разработчик никогда с ним мог и не сталкиваться. Даже за 8 лет. Comprehension — часто работаю с генераторами и сетами, поэтому сходу могу ответить. Потому что сталкивался. Однако же я понимаю, что даже гораздо более опытный человек мог их не встретить на вполне реальных проектах. Так что эти вопросы не показывают накрутку опыта. Знание некоторых тонкостей — да. Но не опыт. P. S. Comprehension я бы спросил. Но ответ был бы плюсиком кандидату, а не «индикатором накрутки». И при прочих равных отдал бы предпочтение кандидату с более широким «кругозором» в плане технологий и ЯП, чем того, который кроме питона и его спецификации не видел ничего.
Скорее, это вопрос уровня "какой тепловой зазор ГРМ у mitsubishi outlander 2010 года выпуска", на который любой инженер покрутит у виска. Ибо такие вещи нужно читать в справочнике, а не вспоминать. Ну и с текущим темпом развития LLM нужда знать нюансы языка будет снижаться, особенно для таких популярных ЯП, как python. Так что лично я проверю общее умение программировать на уровне задачки 4-5kyu с CodeWars.
Там с нативными компонентами работа, так что должно уметь. Есть вариант с кастомной рисовалкой, и с кастомной рисовалкой + openGL. Но танцы с бубном и свои костыли нужны: комьюнити пока маленькое, проекты развиваются не очень быстро.
Lazarus в помощь. Вот без шуток: нужно было быстро сделать утилитку для мониторинга CAN-шины, выбор стоял -- qt или лазарус. Выбрал лазарус и не пожалел: по времени ушло примерно столько же, сколько ушло бы на qt при том, что с паскалем лет 10 не сталкивался. И с либами на C достаточно легко интегрировать, и по производительности не потерял, и возможности отстрелить себе ноги поменьше. Разработка под мобилки (андроид, про яблоки не в курсе) тоже, кстати, есть, но с небольшими танцами с бубном. Ну и полностью бесплатно.
Я помню их радостные статьи о переходе на React Native. Это было началом конца производительности. По-моему, react native -- это зло ещё хуже, чем электрон.
Для автора, который запускает на replicate может и без разницы. А в условиях, когда доступ к зарубежным ресурсам в любой момент может закончится разница есть.
Говоря о локальных моделей -- для задачи постобработки текста достаточно квена и прямых рук. На кой фиг там gpt5?
Гм. А чем модель, крутящаяся не на контролируемом мной железе (Mistral OCR) лучше? Особенно для чувствительных данных. Но революции тут не вижу, да.
P.S. Там китайцы уже HunyuanOCR выпустили -- новая SOTA в OCR. Выглядит очень неплохо.
Командировки разные бывают. Когда едешь на конференцию -- там особо ноут не нужен. Или сбор части команды для обсуждения дальнейшей стратегии развития (большинство на удалёнке) -- большинству тоже не нужны. Я в прошлом году брал -- только протаскал зазря. А на связи таки быть нужно.
То есть логика "мне не нужен -- значит никому не нужен"? А переть с собой ноут, который 100% не понадобится в командировке, ради рабочего чата -- ну такое себе.
Мне видяха для работы нужна
Нужна. Как правило какой-нибудь срочный вопрос возникает в тот момент, когда отошёл в магазин / отъехал за ребёнком в детский садик / etc. И в командировку я с собой ноут не попру (+3 кг с собой таскать -- ну такое), а на связи быть надо.
Дополню свой предыдущий комментарий. Как уже некоторые комментаторы писали, этот «тест» не показывает реальный опыт. Промолчу про задачку с условиями (за такой код надо бить). Но возьмём то же множественное наследование: это как нужно было накосячить с архитектурой, что пришлось к нему прибегать? Соответственно, разработчик никогда с ним мог и не сталкиваться. Даже за 8 лет. Comprehension — часто работаю с генераторами и сетами, поэтому сходу могу ответить. Потому что сталкивался. Однако же я понимаю, что даже гораздо более опытный человек мог их не встретить на вполне реальных проектах. Так что эти вопросы не показывают накрутку опыта. Знание некоторых тонкостей — да. Но не опыт.
P. S. Comprehension я бы спросил. Но ответ был бы плюсиком кандидату, а не «индикатором накрутки». И при прочих равных отдал бы предпочтение кандидату с более широким «кругозором» в плане технологий и ЯП, чем того, который кроме питона и его спецификации не видел ничего.
Скорее, это вопрос уровня "какой тепловой зазор ГРМ у mitsubishi outlander 2010 года выпуска", на который любой инженер покрутит у виска. Ибо такие вещи нужно читать в справочнике, а не вспоминать. Ну и с текущим темпом развития LLM нужда знать нюансы языка будет снижаться, особенно для таких популярных ЯП, как python. Так что лично я проверю общее умение программировать на уровне задачки 4-5kyu с CodeWars.
Подальше от Земли такие сделки совершайте, пожалуйста
Для этого есть enumarate(arr).
Там с нативными компонентами работа, так что должно уметь. Есть вариант с кастомной рисовалкой, и с кастомной рисовалкой + openGL. Но танцы с бубном и свои костыли нужны: комьюнити пока маленькое, проекты развиваются не очень быстро.
Lazarus в помощь. Вот без шуток: нужно было быстро сделать утилитку для мониторинга CAN-шины, выбор стоял -- qt или лазарус. Выбрал лазарус и не пожалел: по времени ушло примерно столько же, сколько ушло бы на qt при том, что с паскалем лет 10 не сталкивался. И с либами на C достаточно легко интегрировать, и по производительности не потерял, и возможности отстрелить себе ноги поменьше. Разработка под мобилки (андроид, про яблоки не в курсе) тоже, кстати, есть, но с небольшими танцами с бубном. Ну и полностью бесплатно.
Я помню их радостные статьи о переходе на React Native. Это было началом конца производительности. По-моему, react native -- это зло ещё хуже, чем электрон.