A12Z анонсирован в марте для iPad Pro 2020.
Некоторые издания считают его расширенной версией A12X (установленный на прошлогодние iPad Pro): здесь (сравнение) и здесь (« but with an extra GPU core enabled» — «с доступным дополнительными ядрами графического ускорителя»)
Можно найти на Али «plastic bird repeller» — пластиковые, «не приносят вреда птицам».
В Амстердаме под мостами есть небольшие ниши с кольцами или металлическими прутами — видимо для привязывания лодок. В этих нишах часто сидят голуби, но не в тех, где к таким прутам пристегнуты пластиковые стяжки (шириной ~5-8 мм) с торчащими во все стороны концами.
Изображения для асферических линз же удаётся сделать. Думаю часть расчетов нужно возлагать на стороне контроллера дисплея — по растягиванию на площади дисплея размытые пиксели, сгенерированные на рендере с учетом такого подхода. Конечно это нетривиальный расчёт — я бы не взялся такую связку на коленке сделать. Печально, что приходится зависеть от производительности рендеринга и канала передачи для данных (с видеокарты на контроллер дисплея), в большинстве своём почти невидимых.
Полагаю для уменьшения количества рендеринга и передачи данных на дисплеи/проекторы можно было бы попробовать эксплуатировать небольшой угол острого зрения (используя трекинг направления взгляда) — в областях нечеткого зрения можно генерировать меньше деталей (своего рода плавающее пятно с четкой детализацией)?
Все верно, некоторые дни время, потраченное непосредственно на разработку действительно удручающе небольшое, но все эти этапы цикла разработки важны для продукта (исключая бестолковые митинги и более, чем короткие «перекуры»).
Мне думается, что автор имеет ввиду процентные части именно времени разработки (если я правильно понял) — а не рабочего дня в целом (того самый «мифического человека-месяца).
Следуя этой метафоре — если это не инди-разработчик, или фрилансер — приходится выбирать удава по критериям — проект интересный/перспективный/комфортный/денежный. Как и в большинстве профессий — конвертация профессиональных навыков и потраченных усилий в средства существования — не прямолинейна и часто имеет эффективность (или соотношение) значительно меньше единицы. Приходится быть разборчивее в выборе удава и вовремя менять его.
Просто есть категория разработчиков (не редкая, нужно заметить), считающих юнит-тесты отдельной разновидностью разработки, считающих отладку — альтернативой юнит-тестам (буквально: «зачем мне юнит-тесты, если я могу отладкой пользоваться»).
Вероятно имелась ввиду непосредственно работа программиста над определенной функциональности, иначе нужно учесть и остальные составляющие цикла разработки — QA, DevOps, последующие рефакторинг и багфигсинг и т.д. Они все важны, если мы говорим о продукте, а не просто о программе или одной конкретной функциональности (к последней я и отношу юнит-тесты).
Чтобы выглядеть авторитетной, вероятно. Только вот выглядеть (да и быть) авторитетным среди людей ценящих такой необоснованный практикой «статус» по меньшей мере бессмысленно.
У меня также сомнения по поводу этого утверждения. Думаю, что в процессе освоения нужно регулярно переоценивать соотеошение усилий, результата и перспективности, чтобы небыло печально, когда достиг уровня мастера в чем-то, что уде можно сделать проще и дешевле другим способом (а то и вовсе уже не актуально).
Переехав в начале 2000х в Питер, получил тестовое задание с алгоритмической направленностью. С интернетом (и деньгами) плохо было — купил третий том Кнута (и ещё какую-то книгу) и успешно сделал задание (и получил работу). Всего Кнута конечно не читал. И выбор книг сейчас больше конечно — есть из чего выбрать.
Не претендую на истину — просто наблюдения из жизни программиста:
В начале 2000-х были мысли: приходится постоянно писать велосипеды, что-то с программированием «не так». И тут «повезло» — прочитал «Мифический человеко-месяц» и «Программист-прогматик» (эти книги перевернули мое понимание о программировании). Затем — присоединился на месяц к команде, работающей по XP (eXtream Programming) — работа парами, гибкая разработка (которая сейчас известна как “agile/scrum/kanban/...”), TDD, standup-ы, Smalltalk/Java/C#, узнал о рефакторинге, шаблонах дизайна (design-patterns). Тогда я понял, что это не с «программированием что-то «не так»», а со моим отношением к нему. И недостаточно просто «увлекаться» программированием (к тому времени профессионально работая программистом уже 7 лет) и читая книги про Linux/C++/JavaScript/TCP/IP/SQL/“Невесту программиста» и т.д. Нужно профессионально расти, в том числе регулярно признавая (себе и коллегам), что «я дурак и был не прав» (а значит — «узнал что-то новое, и стал немного умнее или профессионально лучше»). Выше по тексту — я поставил слово «повезло» в кавычках, поскольку убедился, что везение — происходит значительно более часто, чем мы его замечаем, поскольку к нему нужно быть готовым (точнее — нужно себя к нему подготовить) — чтобы в нужный момент увидеть удачную возможность и быть в состоянии воспользоваться ей. Например — нужно достаточно хорошо освоить какой-то фреймворк, что бы суметь получить оффер на «работу-мечту» (для которого этот фреймворк требуется), а для этого хотя-бы быть в состоянии (и хотеть) рассматривать такие позиции на рынке труда. В общем «лучше день потерять, чтобы затем за пять минут долететь» (С). Оцениваю удачу как 90% успеха, но часто только несколько процентов удач многие в состоянии использовать (или даже просто — заметить).
Также приходится смотреть не только «в-глубь» (прокачивая один определенный скил или фреймворк или технологию), но и «в-ширь» — регулярно оглядываясь по сторонам, оценивая тренды и их возможную перспективу на 2-5-10 лет, изучая другие направления (метафора: не фокусироваться только на конной тяге, когда уже мимо начали ездить автомобили и трамваи). И это больше всего мне нравится в современном программировании — не только необходимость постоянно учиться, но и широкие возможности для этого (и да, знание английского минимум upper-intermediate — это «must have»).
Интересный подход. Хоть и работает только для поверхностей, обращенных с пользователю — касание сверху, сбоку, с обратной стороны — не контролируется.
Возможно что-то типа экзоскелета на плече-руку-кисть-пальцы (только не с моторами, а «блокираторами»/тормозами на суставах) могло бы остальные поверхности покрыть. А шероховатость — вибромоторами или пьезо-«жужжалками» на концах пальцев иммитировать.
Некоторые издания считают его расширенной версией A12X (установленный на прошлогодние iPad Pro): здесь (сравнение) и здесь (« but with an extra GPU core enabled» — «с доступным дополнительными ядрами графического ускорителя»)
В Амстердаме под мостами есть небольшие ниши с кольцами или металлическими прутами — видимо для привязывания лодок. В этих нишах часто сидят голуби, но не в тех, где к таким прутам пристегнуты пластиковые стяжки (шириной ~5-8 мм) с торчащими во все стороны концами.
Я полагал у Epson также есть прогресс (несколько моделей)
https://epson.com/moverio-augmented-reality#
Полагаю для уменьшения количества рендеринга и передачи данных на дисплеи/проекторы можно было бы попробовать эксплуатировать небольшой угол острого зрения (используя трекинг направления взгляда) — в областях нечеткого зрения можно генерировать меньше деталей (своего рода плавающее пятно с четкой детализацией)?
Все верно, некоторые дни время, потраченное непосредственно на разработку действительно удручающе небольшое, но все эти этапы цикла разработки важны для продукта (исключая бестолковые митинги и более, чем короткие «перекуры»).
Мне думается, что автор имеет ввиду процентные части именно времени разработки (если я правильно понял) — а не рабочего дня в целом (того самый «мифического человека-месяца).
Следуя этой метафоре — если это не инди-разработчик, или фрилансер — приходится выбирать удава по критериям — проект интересный/перспективный/комфортный/денежный. Как и в большинстве профессий — конвертация профессиональных навыков и потраченных усилий в средства существования — не прямолинейна и часто имеет эффективность (или соотношение) значительно меньше единицы. Приходится быть разборчивее в выборе удава и вовремя менять его.
Просто есть категория разработчиков (не редкая, нужно заметить), считающих юнит-тесты отдельной разновидностью разработки, считающих отладку — альтернативой юнит-тестам (буквально: «зачем мне юнит-тесты, если я могу отладкой пользоваться»).
Чтобы выглядеть авторитетной, вероятно. Только вот выглядеть (да и быть) авторитетным среди людей ценящих такой необоснованный практикой «статус» по меньшей мере бессмысленно.
Интересно бы узнать — в какую из категорий автор причисляет юнит-тесты.
Однозначно — нет. И это действительно проблема, с которой сталкивался и на других работах.
У меня также сомнения по поводу этого утверждения. Думаю, что в процессе освоения нужно регулярно переоценивать соотеошение усилий, результата и перспективности, чтобы небыло печально, когда достиг уровня мастера в чем-то, что уде можно сделать проще и дешевле другим способом (а то и вовсе уже не актуально).
Скорее они мотивируют действия программиста.
Переехав в начале 2000х в Питер, получил тестовое задание с алгоритмической направленностью. С интернетом (и деньгами) плохо было — купил третий том Кнута (и ещё какую-то книгу) и успешно сделал задание (и получил работу). Всего Кнута конечно не читал. И выбор книг сейчас больше конечно — есть из чего выбрать.
Не претендую на истину — просто наблюдения из жизни программиста:
В начале 2000-х были мысли: приходится постоянно писать велосипеды, что-то с программированием «не так». И тут «повезло» — прочитал «Мифический человеко-месяц» и «Программист-прогматик» (эти книги перевернули мое понимание о программировании). Затем — присоединился на месяц к команде, работающей по XP (eXtream Programming) — работа парами, гибкая разработка (которая сейчас известна как “agile/scrum/kanban/...”), TDD, standup-ы, Smalltalk/Java/C#, узнал о рефакторинге, шаблонах дизайна (design-patterns). Тогда я понял, что это не с «программированием что-то «не так»», а со моим отношением к нему. И недостаточно просто «увлекаться» программированием (к тому времени профессионально работая программистом уже 7 лет) и читая книги про Linux/C++/JavaScript/TCP/IP/SQL/“Невесту программиста» и т.д. Нужно профессионально расти, в том числе регулярно признавая (себе и коллегам), что «я дурак и был не прав» (а значит — «узнал что-то новое, и стал немного умнее или профессионально лучше»). Выше по тексту — я поставил слово «повезло» в кавычках, поскольку убедился, что везение — происходит значительно более часто, чем мы его замечаем, поскольку к нему нужно быть готовым (точнее — нужно себя к нему подготовить) — чтобы в нужный момент увидеть удачную возможность и быть в состоянии воспользоваться ей. Например — нужно достаточно хорошо освоить какой-то фреймворк, что бы суметь получить оффер на «работу-мечту» (для которого этот фреймворк требуется), а для этого хотя-бы быть в состоянии (и хотеть) рассматривать такие позиции на рынке труда. В общем «лучше день потерять, чтобы затем за пять минут долететь» (С). Оцениваю удачу как 90% успеха, но часто только несколько процентов удач многие в состоянии использовать (или даже просто — заметить).
Также приходится смотреть не только «в-глубь» (прокачивая один определенный скил или фреймворк или технологию), но и «в-ширь» — регулярно оглядываясь по сторонам, оценивая тренды и их возможную перспективу на 2-5-10 лет, изучая другие направления (метафора: не фокусироваться только на конной тяге, когда уже мимо начали ездить автомобили и трамваи). И это больше всего мне нравится в современном программировании — не только необходимость постоянно учиться, но и широкие возможности для этого (и да, знание английского минимум upper-intermediate — это «must have»).
А я жало «ковал» молотком до нужной формы — казалось, что дольше не выгорало
Возможно что-то типа экзоскелета на плече-руку-кисть-пальцы (только не с моторами, а «блокираторами»/тормозами на суставах) могло бы остальные поверхности покрыть. А шероховатость — вибромоторами или пьезо-«жужжалками» на концах пальцев иммитировать.