Простите, пока прочитал комментарии, забыл в чем вопрос.
Чтобы сделать хорошее резюме, зайдите на линкдин, найдите очень опытных товарищей и посмотрите что у них в summary написано. Желательно смотрите западных менеджеров, у них ПМы заметно более профессиональны.
Да, я думаю других способов привлечения не нужно. Пусть дизайнеры пиарятся креативом.
Хорошо, что вы поняли. Тогда вы поняли, что ваш вопрос лежит в плоскости архитектуры, а не реализации. Ну и ответьте на простой вопрос из ООП — являются ли секции состоянием сущности Application. Тогда я вам отвечу как нужно реализовывать (хотя вы и сами автоматом будете знать). Ответить же на этот вопрос можно лишь поняв что за приложение вы разрабатываете (уяснив требования).
Не очень понятно что вы в целом хотите.
— Разобраться как работают шейдера, особенно пиксельные? (что не зависит от языка)
— Книгу по GLSL (OpenGL shading language)? (не зависит от Java/Android)
— Особенности работы с шейдерами в Android SDK?
Потому что есть 2 веши, которые в объединении дают такой результат:
— шутеры — не казуальные игры.
— на планшете неудобно играть в шутеры.
Вот и результат — в шутеры играют на консолях и компах.
> Тем более речь не о кодировании а о, возможно, бездумном сливании форка с апстримом :)
При чем тут кривые руки? Это недостатки процесса интеграции, который возможно, у вас вообще не определен. Дело достаточно ответственное и требует прописанных процедур. Вам, как достаточно зрелому разработчику, рекомендую посматривать CMMI — там подробно описано как не проё###### такие вещи. www.software-quality-assurance.org/cmmi-product-integration.html
Richard_Ferlow, а что странного? Вы считаете, что BSOD должен быть либо у всех, либо ни у кого? Скорее всего это проблемы совместимости железа с ОС. Очевидно, не у всех будет BSOD.
Можно сделать такой себе «хак» с помощью appointment slots (часы приема) — сделать слот, в котором 3 интервала и тогда смогут записаться только 3 человека.
Чтоб еще немного разложить по полочками что есть что…
Есть всего 2 библиотеки для программирования 3D графики — OpenGL и DirectX, которые частично или полностью реализованы аппаратно. В каждой из этих библиотек используется свой язык программирования шейдеров — GLSL в OpenGL и HLSL в DirectX.
GLSL — расшифровывается OpenGL Shading Language.
HLSL — расшифровывается High Level Shading Language.
Вообще есть достаточно типичный путь развития технологий, завязанных на железо. Выпускает какая-то компания1 железку и предоставляет язык/библиотеку для программирования под эту железку. Компания2 выпускает аналогичную железку и свой язык/библиотеку для программирования под их железку. Еще могут быть компании 3,4,5… В итоге программисты не очень радуются жизни, сообщают компаниям производителям железок, что они офигенны, сделали классные технологии, но очень хотелось бы писать единый код, который будет работать на всех компьютерах. В итоге компании 1 и 2 садятся вместе и придумывают стандартный единый язык/библиотеку, которая должна работать с их железками и обещают в будущем выпускать железки, которые поддерживают этот язык/библиотеку. Программисты очень радуются созданию стандартного языка/библиотеки, но она не работает на старом железе, да и компании 3,4,5 как-то не спешат переходить…
Думаю, это вам должно напоминать текущую ситуацию с программированием GPGPU. Есть CUDA от NVidia, есть стандартизированный OpenCL. CUDA будет всегда работать немножко быстрее чем OpenCL на карточках NVidia, так как это родная технология. Но с точки зрения программистов, OpenCL наиболее привлекателен как стандартная технология, которая обязана работать везде и всюду (по крайней мере в будущем так будет).
Аварии — это совершенно другая вещь, оценка сроков тут не при чем. Затягивание сроков в 10-20 раз — это немыслимо. Какой это проект рассчитывали на 5 лет, а делали 50-100 лет?
esupport.sony.com/US/perl/support-info.pl?info_id=927#return_order_2