если у вас ИИ плохо пишет - значит вы дали мало контекста и плохо поставили задачу.
Правильно и детально расписать контекст и поставить задачу - это 90% работы программиста, а код писать это дай бог 10%. С таким же успехом можно посадть джуна и хэндхолдить его 90% времени — можно, но зачем? Где тогда экономия на использвании ИИ? И если квалифицированные разработчики многое могут понять тупо из своего опыта и обрывчатых данных, включив режим бабы-ванги, то ИИ здесь в пролёте.
Там парадоксальная ситуация, оно может дать результат, если:
а) нужна тривиальщина, в плане тривиальных технологий и тривиальных задач (что логично, на чём обучили то оно и умеет);
б) в задачу закопали кучу времени и усилий, например на объяснение и разжевывание всех деталей задачи/фичи, всего контекста системы и т.д.;
Правда во втором случае получается зачастую столько работы, что проще в итоге сделать самому лол. Ну это если уметь, да. А если не уметь, то я правда даже хз с этим справиться, ибо оно теряет контекст, галюцинирует и т.д.
Хотел я поковоряться в ретро-разработке для которого нет 100500 примеров и реальных опенсорс проектов, которые можно было бы засунуть в модель на её обучение, и сразу выходит пшик - вроде понимает что-то про синтаксис и т.д., но полное непонимание того что реально доступно в API и девтулзах конкретных версий, путает это с более современныи версиями схожих технологий и т.д. В итоге никакого продуктивного прогресса, даже при понимании разработки как таковой.
iPhone не был никогда однозадачным, это заблуждение казуалов от непонимания реальности.
Там система с первого дня была полноценным многозадачным юниксом, вагон и тележка процессов работали в бэкграунде и отдувались за свои части функциональности, вроде лаунчера, проигрывания музыки, работы сети, синхронизации, проверки почты и прочего-прочего-прочего.
А то о чём вы говорите это просто зажатые настройки системы по ограничению работы пользовательских приложений в бэкграунде, т.е. если пользователь выходит из одного приложения, то система его выгружала к чертям собачим, ибо простите но у трубки было всего 128 Мб оперативной памяти и ~400 Мгц процессора.
Просто плавность и прогнозируемость работы в ограниченых условиях были для них важнее, чем говорить для галочки "да, можно иметь несколько запущеных приложений", забывая добавить что правда либо девайс раком ставиться, либо приложения убиваются системой рандомно, как тогда было на альтернативных платформах лол.
Кто пересел в 2007-2008 году на айфон после предыдущих платформ знает о чём я говорю.
Какой-то чёрно-белый идеализм. Сети плохие, производители хорошие.
Концептуально это скорее так, по всему миру примеров довольно много, вроде тех случаев когда в США Walmart пользуясь своим положением требовал у производителя сделать их условные газонокосилки хуже и дешевле, чтобы наростить объём продаж и т.д.
но, в результате, многократно разжёвывает одни и те же вещи.
А хотелось бы иметь, сначала, некоторое общее введение в верстку как таковую, а уже потом технические детали. И, главное, чтобы никакой "воды", никаких повторов.
А это дополнительная проблема любых учебников или материалов. Это вам удобнее чтобы без воды и повторов, например потому что у вас база лучше, или в целом вам проще воспринимать так, а это к сожалению далеко не у всех так. Зачастую попытки научить кого-то чему-то только через многократные повторения и работают. Поэтому в идеале книги нужны не только хорошо написанные, разумно подающие материал и без всех этих ошибок, но и под разные аудитории и разные базы.
На самом деле зависит от того насколько конкретный человек застал эти игры раньше, например многим более молодым геймерам сам факт пикселизации жестко глаза режет, прямо мешает воспринимать картинку нормально. А если брать более конкретные вещи, то некоторые элементы управления и UI очень так себе:
инвентарь в одну колонку всего с парочкой предметов на экране;
тоже самое для интерфейса торговли и т.д.;
сколлинг в инвентаре кнопками без поддержки колеса мыши;
очень специфичная работа контекстного меню через удерживание нажатой кнопки и т.д.;
Вы это сейчас серьёзно? Симки всю жизнь чуть ли не в оптовых количествах сразу у всех операторов покупали на условных бомжей, на ворованные паспорта и т.д. Почему это должно изменить?
Там базово камера состоит из двух основных компонентов: камера-сенсора и микроконтроллера, который управляет ею и реализует её как USB устройство. Камера-сенсор подключен к микроконтроллеру несколькими пинами (приём и передача данных, сброс, включение и т.д.), среди которых один из важных для всей ситуации это пин, который управляет режимом Standby. Базово, если на пин Standby подаётся питание, то это держит камеру в выключенном (Standby) режиме, когда оно не может захватывать видео сигнал, ну и заодно имеено к пину Standby подцеплен драйвер светодиода индикации работы камеры.
Всё как бы логично и проще некуда: если микроконтроллер включает камеру, то он перестаёт подавать питание на её по пину Standby, тем самым автоматически включается светодиодный индикатор, т.е. либо сигнал на Standby есть и тогда сенсор отключен, а светодиод не горит, либо сигнала нет и тогда сенсор включается и заодно загарается светодиод.
Но вот тут загвоздка:
прошивка для всей этой требухи не зашита в девайс, а грузиться в рантайме по тому самому USB интерфейсу которым оно подключено, а значит если постараться и найти уязвимости, то легко подложить хакнутую прошивку для камеры;
хакнутой прошивкой можно заставить устройства вести себя иначе, чем предусмотрел поставщик компонентов в своей документации и производитель итоговый (который это реализовал), в частности можно перепилить логику взаимодействия микроконтроллера с сенсором таким образом чтобы оно вообще не трогало этот Standby пин, но при это работало;
Типичная проблема от слишком умных девайсов (программируемый микроконтроллер ради веб-камеры, чтобы оно могло быть USB девайсом) и фич для удобста (прошивка не зашита в девайс, а грузится в рантайме - удобно же), которые создают блюди из дополнительных уязвимостей.
Там двойной бэкдор от поставщика камеры скорее, во-первых недокументированный производителем сенсора режим работы, во-вторых сам факт, что "прошивку" даже не надо перепрошивать, т.к. она грузиться в рантайме (зато удобно баги править, да) и её легко подменить: собственно в подменнёной прошивке они считай там перепрограммируют камеру чтобы она иначе пины свои использовала и не использовала пин с питанием, к которому Apple подцепились для индикации работы.
Проблема в том, что даже это не панацея. Если мне не изменяет память, то у макбуков давным-давно светодиод висит на питании камеры, однако как минимум у одной старой модели смогли сделать эксплоит который позволял хитро активировать камеру без того чтобы человек увидел светодиод.
Они там сделали что-то типа хитрой прошивки, которая позволяла активировать камера-сенсор в специальном недокументированном производителем режиме, манипулируя регистрами толи в самом сенсоре, толи в микроконтроллере, который им рулил.
И хотя в следующих моделях такое провернуть уже было нельзя Apple не просто так добавила в ОС индикторы доступа к камере и микрофону, так сказать на всякий случай пусть будет и такое.
Тоже проиграл с этой формулировки. Человек может и не ищет, но он точн сравнивает по этим характеристикам. Зачастую кстати выбирая более плохой товар, когда ну бумаге выглядит лучше. Например будет пять примерно равных рюкзаков, и в сравнении у одного будет 23 литра объём, у парочки — по 25, а какого-то — вообще 27. И человек зачастую примет решение, что больше больше литров в примерно таких же габаритах это лучше т.к. практичнее. А то что форма внутреняя может быть такой, что эти литры сугубо теоретические это пофиг. В табличке характеристик написано больше — значит лучше. Именно поэтому китайцы заваливают услоный Али товараами с фейковыми характеристиками. Потому что цифры продают вполне себе.
По моему опыту желание посмотреть на гитхаб действительно существует, в том числе у зарубежных работодателей и заказчиков, но каждый раз хочется спросить мол ребята, а что вы там ожидаете увидеть? Работа делается над проектами клиентов, это в личном гитхабе публично лежать не может лол.
Лень мешает. Многократно ловил источники слива почты через этот трюк с плюсом. Никто даже не парится нрмализацию делать т.к. источники почты по-умолчанию считаются уже нормализованными.
Потому, что как продукт Gmail (именно как сервис почты, не приложение) сознательно отходит от стандартов и делает так чтобы любое использование его вне официального приложения создавало дополнительный «фрикшн» для пользователей. Начиная от концепций тегов vs папок и заканчивая регулярными палками в колёса по авторизации: авторизация по паролю? не, не слышали, либо Oauth2 со своими заскоками, либо пароль приложения, который по цепочке требует двухфакторку... или вообще потребует вводить капчу лол.
X и Y хромосомы передают привет.
Это нормально когда у людей «неправильное» (по вашему взгляду) мнение.
Чтобы 10+ камер не имели одну точку отказа в виде общего роутера
Иметь взгляды это плохо?
Ставить в пример Google в 2025 году как что-то хорошее это прямо мда.
Правильно и детально расписать контекст и поставить задачу - это 90% работы программиста, а код писать это дай бог 10%. С таким же успехом можно посадть джуна и хэндхолдить его 90% времени — можно, но зачем? Где тогда экономия на использвании ИИ? И если квалифицированные разработчики многое могут понять тупо из своего опыта и обрывчатых данных, включив режим бабы-ванги, то ИИ здесь в пролёте.
Там парадоксальная ситуация, оно может дать результат, если:
а) нужна тривиальщина, в плане тривиальных технологий и тривиальных задач (что логично, на чём обучили то оно и умеет);
б) в задачу закопали кучу времени и усилий, например на объяснение и разжевывание всех деталей задачи/фичи, всего контекста системы и т.д.;
Правда во втором случае получается зачастую столько работы, что проще в итоге сделать самому лол. Ну это если уметь, да. А если не уметь, то я правда даже хз с этим справиться, ибо оно теряет контекст, галюцинирует и т.д.
Хотел я поковоряться в ретро-разработке для которого нет 100500 примеров и реальных опенсорс проектов, которые можно было бы засунуть в модель на её обучение, и сразу выходит пшик - вроде понимает что-то про синтаксис и т.д., но полное непонимание того что реально доступно в API и девтулзах конкретных версий, путает это с более современныи версиями схожих технологий и т.д. В итоге никакого продуктивного прогресса, даже при понимании разработки как таковой.
Вы, наверное, шутите или ностальгия у вас. Оно было жутко-тормозным. Особенно впечатляа разница между их рекламой и реальным поведением.
iPhone не был никогда однозадачным, это заблуждение казуалов от непонимания реальности.
Там система с первого дня была полноценным многозадачным юниксом, вагон и тележка процессов работали в бэкграунде и отдувались за свои части функциональности, вроде лаунчера, проигрывания музыки, работы сети, синхронизации, проверки почты и прочего-прочего-прочего.
А то о чём вы говорите это просто зажатые настройки системы по ограничению работы пользовательских приложений в бэкграунде, т.е. если пользователь выходит из одного приложения, то система его выгружала к чертям собачим, ибо простите но у трубки было всего 128 Мб оперативной памяти и ~400 Мгц процессора.
Просто плавность и прогнозируемость работы в ограниченых условиях были для них важнее, чем говорить для галочки "да, можно иметь несколько запущеных приложений", забывая добавить что правда либо девайс раком ставиться, либо приложения убиваются системой рандомно, как тогда было на альтернативных платформах лол.
Кто пересел в 2007-2008 году на айфон после предыдущих платформ знает о чём я говорю.
Потому что примерно в этом возрасте он попадает в школу и его естественному любопытству отбивают почки системой образования.
Концептуально это скорее так, по всему миру примеров довольно много, вроде тех случаев когда в США Walmart пользуясь своим положением требовал у производителя сделать их условные газонокосилки хуже и дешевле, чтобы наростить объём продаж и т.д.
А это дополнительная проблема любых учебников или материалов. Это вам удобнее чтобы без воды и повторов, например потому что у вас база лучше, или в целом вам проще воспринимать так, а это к сожалению далеко не у всех так. Зачастую попытки научить кого-то чему-то только через многократные повторения и работают. Поэтому в идеале книги нужны не только хорошо написанные, разумно подающие материал и без всех этих ошибок, но и под разные аудитории и разные базы.
На самом деле зависит от того насколько конкретный человек застал эти игры раньше, например многим более молодым геймерам сам факт пикселизации жестко глаза режет, прямо мешает воспринимать картинку нормально. А если брать более конкретные вещи, то некоторые элементы управления и UI очень так себе:
инвентарь в одну колонку всего с парочкой предметов на экране;
тоже самое для интерфейса торговли и т.д.;
сколлинг в инвентаре кнопками без поддержки колеса мыши;
очень специфичная работа контекстного меню через удерживание нажатой кнопки и т.д.;
Вы это сейчас серьёзно? Симки всю жизнь чуть ли не в оптовых количествах сразу у всех операторов покупали на условных бомжей, на ворованные паспорта и т.д. Почему это должно изменить?
Там базово камера состоит из двух основных компонентов: камера-сенсора и микроконтроллера, который управляет ею и реализует её как USB устройство. Камера-сенсор подключен к микроконтроллеру несколькими пинами (приём и передача данных, сброс, включение и т.д.), среди которых один из важных для всей ситуации это пин, который управляет режимом Standby. Базово, если на пин Standby подаётся питание, то это держит камеру в выключенном (Standby) режиме, когда оно не может захватывать видео сигнал, ну и заодно имеено к пину Standby подцеплен драйвер светодиода индикации работы камеры.
Всё как бы логично и проще некуда: если микроконтроллер включает камеру, то он перестаёт подавать питание на её по пину Standby, тем самым автоматически включается светодиодный индикатор, т.е. либо сигнал на Standby есть и тогда сенсор отключен, а светодиод не горит, либо сигнала нет и тогда сенсор включается и заодно загарается светодиод.
Но вот тут загвоздка:
прошивка для всей этой требухи не зашита в девайс, а грузиться в рантайме по тому самому USB интерфейсу которым оно подключено, а значит если постараться и найти уязвимости, то легко подложить хакнутую прошивку для камеры;
хакнутой прошивкой можно заставить устройства вести себя иначе, чем предусмотрел поставщик компонентов в своей документации и производитель итоговый (который это реализовал), в частности можно перепилить логику взаимодействия микроконтроллера с сенсором таким образом чтобы оно вообще не трогало этот Standby пин, но при это работало;
Типичная проблема от слишком умных девайсов (программируемый микроконтроллер ради веб-камеры, чтобы оно могло быть USB девайсом) и фич для удобста (прошивка не зашита в девайс, а грузится в рантайме - удобно же), которые создают блюди из дополнительных уязвимостей.
Там двойной бэкдор от поставщика камеры скорее, во-первых недокументированный производителем сенсора режим работы, во-вторых сам факт, что "прошивку" даже не надо перепрошивать, т.к. она грузиться в рантайме (зато удобно баги править, да) и её легко подменить: собственно в подменнёной прошивке они считай там перепрограммируют камеру чтобы она иначе пины свои использовала и не использовала пин с питанием, к которому Apple подцепились для индикации работы.
Проблема в том, что даже это не панацея. Если мне не изменяет память, то у макбуков давным-давно светодиод висит на питании камеры, однако как минимум у одной старой модели смогли сделать эксплоит который позволял хитро активировать камеру без того чтобы человек увидел светодиод.
Они там сделали что-то типа хитрой прошивки, которая позволяла активировать камера-сенсор в специальном недокументированном производителем режиме, манипулируя регистрами толи в самом сенсоре, толи в микроконтроллере, который им рулил.
И хотя в следующих моделях такое провернуть уже было нельзя Apple не просто так добавила в ОС индикторы доступа к камере и микрофону, так сказать на всякий случай пусть будет и такое.
Тоже проиграл с этой формулировки. Человек может и не ищет, но он точн сравнивает по этим характеристикам. Зачастую кстати выбирая более плохой товар, когда ну бумаге выглядит лучше. Например будет пять примерно равных рюкзаков, и в сравнении у одного будет 23 литра объём, у парочки — по 25, а какого-то — вообще 27. И человек зачастую примет решение, что больше больше литров в примерно таких же габаритах это лучше т.к. практичнее. А то что форма внутреняя может быть такой, что эти литры сугубо теоретические это пофиг. В табличке характеристик написано больше — значит лучше. Именно поэтому китайцы заваливают услоный Али товараами с фейковыми характеристиками. Потому что цифры продают вполне себе.
По моему опыту желание посмотреть на гитхаб действительно существует, в том числе у зарубежных работодателей и заказчиков, но каждый раз хочется спросить мол ребята, а что вы там ожидаете увидеть? Работа делается над проектами клиентов, это в личном гитхабе публично лежать не может лол.
Лень мешает. Многократно ловил источники слива почты через этот трюк с плюсом. Никто даже не парится нрмализацию делать т.к. источники почты по-умолчанию считаются уже нормализованными.
Потому, что как продукт Gmail (именно как сервис почты, не приложение) сознательно отходит от стандартов и делает так чтобы любое использование его вне официального приложения создавало дополнительный «фрикшн» для пользователей. Начиная от концепций тегов vs папок и заканчивая регулярными палками в колёса по авторизации: авторизация по паролю? не, не слышали, либо Oauth2 со своими заскоками, либо пароль приложения, который по цепочке требует двухфакторку... или вообще потребует вводить капчу лол.