Про фиксацию поведения да, подзабыл. Просто как-то мне в работе по большей части не приходилось возвращаться к старым методам, чтобы что — то изменить. Когда приходилось — например, это было изменение метода получения настроек с видеокамеры, чтобы считать новые настройки, появившиеся в новой прошивке или просто потребовавшиеся. И протестировать то, что он действительно возвращает все возможные значения без веб-интерфейса никак, нужно вручную менять их на камере и прогонять метод каждый раз. Ну, полагаю, здесь бы еще могли спасти mock-объекты, чтобы сымитировать поведение камеры, хотя анализировать поведение нескольких десятков моделей чтобы создать объект, который скорее всего нужен один раз, т.к. в каждой новой прошивке поведение может измениться радикально — это чересчур.
Другой момент, когда приходилось возвращаться к старому, подразумевал переделку достаточно большой схемы работы как таковой. Каким методом автоматизированного тестирования можно охватить целый процесс, схему работы, состоящий из нескольких потоков, и охватывающий несколько классов? С отдельными методами проблем не возникало, сами по себе они работали прекрасно. Да в общем и со схемой тоже только пару раз обнаружились дедлоки — и установить ситуацию, в которой они возникали, так и не удалось — решили долгим и вдумчивым всматриванием в код и добавлением еще одной критической секции. Полагаю, юнит-тест можно было бы использовать, чтобы удостовериться что поведение не изменилось. Хотя проблем и так не возникло. Т.е. возможно они возникли, но обнаружить таковых не удалось и ситуаций, в которых они могли бы возникать, мы представить тоже не смогли. Затем остались проблемы с просадками производительности и утечкой памяти. Тут, я так понимаю, тесты тоже не использовать, т.к. фиксировать требуется поведение в достаточно сложном процессе, да и плюс к тому, всегда остаются неохваченные ситуации и неизвестные факторы.
Вот когда в результате одного из обновлений камеры научились слать в заголовках пакетов видеопотока дополнительную информацию, и была мысль переписать парсер для поддержки этой возможности, тогда да, понимаю, как можно было бы использовать тесты — наловить несколько разных пакетов, и подсовывать их в тестах парсеру, затем расширить его, и проверить что старые пакеты парсятся так же. Но таких ситуаций было, ну, наверное, две за год с небольшим.
Строго говоря — когда шум от ПК ниже чем уровень фонового шума ночью — то не важно, каким образом этого добились. Тихая коробка для HDD + эластичный подвес + отсутствие прямых путей для прохождения звука от дисков наружу корпуса + покрытие поверхностей звукопоглощающим покрытием.
Подозреваю, что есть большая разница между изменением каких-либо конкретных реализаций и изменением принципиальной структуры. Может статься так, что новый требуемый функционал просто вообще не реализуем без новой структуры — тогда придется разрабатывать заново и переписывать самую суть структуры проекта. Структуру нужно, подозреваю, разрабатывать с запасом, закладывая в нее то, что может потребоваться больше, чем указано в техзадании, как в количественных, так и в качественных смыслах, и учитывая что многое может поменяться.
Про юнит-тесты и тестирование вообще — хочу спросить, а как же их реально применять? Как понять, куда их можно приткнуть? Особенно в тех случаях, когда код работает с чужими софтом/железом, когда неизвестны граничные условия и неизвестно достоверно, что и как должно быть.
Может что и поменялось. Во время первого сенса у меня было желание использовать их звонилку и смс-клиент. Но оказалось, что без замены части системных apk от чистого андроида на «сенсовые», они не работают, а после замены — не работает все остальное.
Жесткой железозависимости нет, но программная все же есть, и именно программные фичи все же приходится им переносить из исходников AOSP в свои. Это конечно не отменяет того, что вендоры с этой т.з. — злобные буратины.
Ну, во-первых, нормально портируется он только на те аппараты, которые близки железно, а во-вотрых — это не один apk, а порядка 30, и они включают себя например собственно framework.apk.
А правки таки имеют место быть. В основном, правда, только под камеры и воспроизведение видео, остальное все более-менее у всех одинаково.
Да нет, не в том плане. Под виджетом я имел в виду не то, что на главном экране, а элементы графического интерфейса — кнопки, скроллбары, и т.д.
Я к тому, что это вообще не приложения. Это другой андроид, который просто тоже поддерживает те же приложения. Созданный практически параллельно, с кучей своих собственных API и прочего. И обновление не сводится к обновлению драйверов, перекомпиляции выкаченных исходников AOSP, некоторой конфигурации и установке своих лаунчеров и прочего.
Т.е., вашими же словами: «Тач виз и сенс — это всего лишь софт, которому не важна аппаратная часть телефона. А если важна — значит производитель этого софта не дружит с головой или слишком хочет денег.»
Так вот именно что важна. Насчет тачвиза правда не скажу, он вроде немного полегче все же, но сенс — это не андроид с поставленным поверх набором приложений. Это сенс, поддерживающий приложения андроида. Несколько преувеличенно конечно, но это так.
Так для них ведь реально меняется почти все. В случае сенса, например, тот андроид что там есть — это на 50%(утрированно) сделанное по аналогии и по документации. Сенс — это не надстройка, это сама система. Там свои виджеты, почти все свое. И портировать элементы новой версии Андроида в нее — это действительно проблема.
Совершенно согласен с проблемами обновлений и фрагментации, изложенными в первом посте. На мой взгляд, оптимальна для пользователей модель WP7 — когда есть выбор различных устройств, но ОС совершенно идентичная и обновления всем приходят одинаково. Разнообразие устройств, конечно, усложняет это, но не делает невозможным.
Сильные изменения в API и необходимость рефакторинга программ — это не так страшно, если нет «зоопарка версий.» В идеале, предварительно происходит выпуск новой версии ОС в виде версии для разработчиков, с зафиксированным API, которую они могут поставить на свои телефоны самостоятельно, и протестировать/переписать свою программу на новой версии ОС. Через 3 месяца обновление становится доступно всем, а программы уже оказываются адаптированы разработчиками.
К сожалению, Гугл вряд ли действительно возьмется за платформу ежовыми рукавицами, так что остается только помечтать.
Со стороны производителей аппаратов — их действительно ограничивает еще и необходимость адаптировать систему под свое железо. Каких-то спецификаций нет, Гугл просто договаривается с одним из производителей, разрабатывает очередной нексус, а затем выпускает аппарат и исходники под него. Остальным же приходится адаптировать, опираясь на исходники, а не заранее выпущенную спецификацию. Это одна из проблем.
Далее, можно было бы действительно решить немалую часть проблем с обновлением, разбив систему на несколько уровней ( я как-то об этом писал).
1. Ядро системы, драйвера. Зависят от производителя.
2. Собственно фреймворк Android. Обновляется независимо от 1го уровня, умеет определять и отключать/эмулировать те фичи, для которых пока нет поддержки в драйверах. Поставляется Гуглом, обновляется везде и у всех одновременно. Производители не могут вносить в него изменения. Сюда также входят все основные приложения — штатный набиратель, контакты, и т.д.
3. Надстройки. Это Google Apps и надстройки производителей. Являются, по сути, обычными приложениями, разве что не удаляются, но они должны быть отключаемы. Используют только API описанные в п.2 и не предоставляют никаких API сами. (интенты не в счет)
4. Пользовательские приложения — ну, тут все понятно.
Таким образом получаем систему, которая достаточно актуально обновляется, разработчики не имеют проблем с недокументированными моментами, пользователь всегда может вернуться к голому андроиду либо же пользоваться надстройками вендора.
Таким образом, будет реализовано наличие более-менее адекватной экосистемы, которая сейчас в андроиде доступна разве что пользователям Nexus'ов и CyanogenMod.
Модерация на маркете — сильно спорный вопрос. Можно в принципе разделить его на модерируемую и немодерируемую часть, прохождение модерации добровольное, у модерированных приложений есть какие-либо приоритеты перед немодерированными.
Ну я не на голый линолеум укладываюсь, а использую пляжную подстилку. Можно покрывало, еще что-нибудь. Можно хоть прямо на кровати, если не сильно уж мягкая.
Тоже всегда имел проблему с засыпанием. Пошерстив по памяти хабр и вспомнив кое-какие упражнения, сделал комплекс из 4 упражнений на ~10 минут:
1) Вращения
Стоя, ноги на ширине плеч, руки вдоль тела расслаблены. Поворачиваемся влево, не поворачивая таз, только скручивая спину и шею. Без излишеств, без особых усилий, но градусов на 170 голова должна повернуться. И сразу вправо, так и крутимся вправо — влево 100 раз. Главное, без напряжения это делать, в естественном темпе.
2) Выгибание спины
Ложимся на пол на живот, упираемся руками в пол и поднимаемся, примерно как отжимание, но не напрягая спину и пресс, не отрывая таз от пола. Только выгибая назад спину. Руки лучше поставить немного перед собой, чтобы они были под углом около 45 градусов к полу. Считаю по дыханию до 60, т.е. около 2х минут.
3) Прогиб вперед
Встаем на колени, таз прижат к пяткам. Сцепляем вытянутые и опущенные руки за спиной. Ровно и глубоко дышим 6-8 раз, на последний раз выдыхаем частично, наклоняемся туловищем вперед, упираемся лицом в пол, руки, все так же вытянутые и сцепленные, закидываем как можно дальше вперед, дыхание задерживаем, считаем до 10, и на исходную. 5-6 раз.
4) Вытягиваем верх спины
На коленях, как в предыдущем упражнении. Наклоняемся туловищем вперед, прижимаемся к полу, руки вытягиваем вперед, так что они получаются сверху-сбоку от головы, как можно сильнее, кладем ладонями на пол, так, чтобы трение «держало» руки вытянутыми (на линолеуме лучше всего). Глубоко и плавно дышим, причем лучше, чтобы дыхание ощущалось горлом. На полном вдохе должно чувствоваться, как натягиваются мышцы возле лопаток. 20 дыханий — около 3х минут.
После этого просто ложусь и стараюсь дышать глубоко и ровно. Засыпаю минут за 10.
Так вот в комменте повыше ответ. Принимаешь решение взять помидор взамен указанных — ругаются и говорят что надо только те. Можно на самом деле и другие, но вот только разъяснить критерии отбора никто не может.
Отлично, для десктопа самое то. Планшетам же нужен несколько другой интерфейс имхо, возможно, с тайловым WM.
Жаль что вряд ли МС решится выкинуть все старое в отдельную виртуальную машину и сделать саму ОС действительно по-новой.
Другой момент, когда приходилось возвращаться к старому, подразумевал переделку достаточно большой схемы работы как таковой. Каким методом автоматизированного тестирования можно охватить целый процесс, схему работы, состоящий из нескольких потоков, и охватывающий несколько классов? С отдельными методами проблем не возникало, сами по себе они работали прекрасно. Да в общем и со схемой тоже только пару раз обнаружились дедлоки — и установить ситуацию, в которой они возникали, так и не удалось — решили долгим и вдумчивым всматриванием в код и добавлением еще одной критической секции. Полагаю, юнит-тест можно было бы использовать, чтобы удостовериться что поведение не изменилось. Хотя проблем и так не возникло. Т.е. возможно они возникли, но обнаружить таковых не удалось и ситуаций, в которых они могли бы возникать, мы представить тоже не смогли. Затем остались проблемы с просадками производительности и утечкой памяти. Тут, я так понимаю, тесты тоже не использовать, т.к. фиксировать требуется поведение в достаточно сложном процессе, да и плюс к тому, всегда остаются неохваченные ситуации и неизвестные факторы.
Вот когда в результате одного из обновлений камеры научились слать в заголовках пакетов видеопотока дополнительную информацию, и была мысль переписать парсер для поддержки этой возможности, тогда да, понимаю, как можно было бы использовать тесты — наловить несколько разных пакетов, и подсовывать их в тестах парсеру, затем расширить его, и проверить что старые пакеты парсятся так же. Но таких ситуаций было, ну, наверное, две за год с небольшим.
Про юнит-тесты и тестирование вообще — хочу спросить, а как же их реально применять? Как понять, куда их можно приткнуть? Особенно в тех случаях, когда код работает с чужими софтом/железом, когда неизвестны граничные условия и неизвестно достоверно, что и как должно быть.
Жесткой железозависимости нет, но программная все же есть, и именно программные фичи все же приходится им переносить из исходников AOSP в свои. Это конечно не отменяет того, что вендоры с этой т.з. — злобные буратины.
А правки таки имеют место быть. В основном, правда, только под камеры и воспроизведение видео, остальное все более-менее у всех одинаково.
Я к тому, что это вообще не приложения. Это другой андроид, который просто тоже поддерживает те же приложения. Созданный практически параллельно, с кучей своих собственных API и прочего. И обновление не сводится к обновлению драйверов, перекомпиляции выкаченных исходников AOSP, некоторой конфигурации и установке своих лаунчеров и прочего.
Т.е., вашими же словами: «Тач виз и сенс — это всего лишь софт, которому не важна аппаратная часть телефона. А если важна — значит производитель этого софта не дружит с головой или слишком хочет денег.»
Так вот именно что важна. Насчет тачвиза правда не скажу, он вроде немного полегче все же, но сенс — это не андроид с поставленным поверх набором приложений. Это сенс, поддерживающий приложения андроида. Несколько преувеличенно конечно, но это так.
Сильные изменения в API и необходимость рефакторинга программ — это не так страшно, если нет «зоопарка версий.» В идеале, предварительно происходит выпуск новой версии ОС в виде версии для разработчиков, с зафиксированным API, которую они могут поставить на свои телефоны самостоятельно, и протестировать/переписать свою программу на новой версии ОС. Через 3 месяца обновление становится доступно всем, а программы уже оказываются адаптированы разработчиками.
К сожалению, Гугл вряд ли действительно возьмется за платформу ежовыми рукавицами, так что остается только помечтать.
Со стороны производителей аппаратов — их действительно ограничивает еще и необходимость адаптировать систему под свое железо. Каких-то спецификаций нет, Гугл просто договаривается с одним из производителей, разрабатывает очередной нексус, а затем выпускает аппарат и исходники под него. Остальным же приходится адаптировать, опираясь на исходники, а не заранее выпущенную спецификацию. Это одна из проблем.
Далее, можно было бы действительно решить немалую часть проблем с обновлением, разбив систему на несколько уровней ( я как-то об этом писал).
1. Ядро системы, драйвера. Зависят от производителя.
2. Собственно фреймворк Android. Обновляется независимо от 1го уровня, умеет определять и отключать/эмулировать те фичи, для которых пока нет поддержки в драйверах. Поставляется Гуглом, обновляется везде и у всех одновременно. Производители не могут вносить в него изменения. Сюда также входят все основные приложения — штатный набиратель, контакты, и т.д.
3. Надстройки. Это Google Apps и надстройки производителей. Являются, по сути, обычными приложениями, разве что не удаляются, но они должны быть отключаемы. Используют только API описанные в п.2 и не предоставляют никаких API сами. (интенты не в счет)
4. Пользовательские приложения — ну, тут все понятно.
Таким образом получаем систему, которая достаточно актуально обновляется, разработчики не имеют проблем с недокументированными моментами, пользователь всегда может вернуться к голому андроиду либо же пользоваться надстройками вендора.
Таким образом, будет реализовано наличие более-менее адекватной экосистемы, которая сейчас в андроиде доступна разве что пользователям Nexus'ов и CyanogenMod.
Модерация на маркете — сильно спорный вопрос. Можно в принципе разделить его на модерируемую и немодерируемую часть, прохождение модерации добровольное, у модерированных приложений есть какие-либо приоритеты перед немодерированными.
В соседней статье было хорошо сказано в комментариях — нужно стратегическое мышление. И тактические шаги для движения по намеченному направлению.
1) Вращения
Стоя, ноги на ширине плеч, руки вдоль тела расслаблены. Поворачиваемся влево, не поворачивая таз, только скручивая спину и шею. Без излишеств, без особых усилий, но градусов на 170 голова должна повернуться. И сразу вправо, так и крутимся вправо — влево 100 раз. Главное, без напряжения это делать, в естественном темпе.
2) Выгибание спины
Ложимся на пол на живот, упираемся руками в пол и поднимаемся, примерно как отжимание, но не напрягая спину и пресс, не отрывая таз от пола. Только выгибая назад спину. Руки лучше поставить немного перед собой, чтобы они были под углом около 45 градусов к полу. Считаю по дыханию до 60, т.е. около 2х минут.
3) Прогиб вперед
Встаем на колени, таз прижат к пяткам. Сцепляем вытянутые и опущенные руки за спиной. Ровно и глубоко дышим 6-8 раз, на последний раз выдыхаем частично, наклоняемся туловищем вперед, упираемся лицом в пол, руки, все так же вытянутые и сцепленные, закидываем как можно дальше вперед, дыхание задерживаем, считаем до 10, и на исходную. 5-6 раз.
4) Вытягиваем верх спины
На коленях, как в предыдущем упражнении. Наклоняемся туловищем вперед, прижимаемся к полу, руки вытягиваем вперед, так что они получаются сверху-сбоку от головы, как можно сильнее, кладем ладонями на пол, так, чтобы трение «держало» руки вытянутыми (на линолеуме лучше всего). Глубоко и плавно дышим, причем лучше, чтобы дыхание ощущалось горлом. На полном вдохе должно чувствоваться, как натягиваются мышцы возле лопаток. 20 дыханий — около 3х минут.
После этого просто ложусь и стараюсь дышать глубоко и ровно. Засыпаю минут за 10.
Жаль что вряд ли МС решится выкинуть все старое в отдельную виртуальную машину и сделать саму ОС действительно по-новой.