Согласен — две крайности. Они тут полезны в том что мы хотим понять. Я считаю что оба программиста молодцы, а вот косячник — менеджер.
Программисты вообще всегда молодцы, живут в своем мирке и как знают мирок свой так и пишут.
А вот менеджеры, блин, ну неужели они не могу объяснить какой будет проект:
1) прототип для показа — который выкинут и надо код писать быстрее пусть с утечками памяти немасштабируемый и т.д. (Маркус тут даже перестарался, все можно было написать в main()),
2) серезный проект с ТЗ, которого действительно утверждено — надо показать это ТЗ, диаграмки состояний нарисовать, объяснить как в дальнейшем может развиться система. Какие перспективы сопровождения (Борис не виноват что ему не предоставили полной информации, однако он правильно начал с минимумом абстракций, а потом их наращивал, основной бедой его был повар, который является инициатором выпечки — он фабрика, а не плита, плита — инструмент, который на ровне с рецептом должен использоваться поваром и просто поддерживать температуру определенную, из-за неправильного повора рецепт вперся в плиту зачем-то и пошло поехало, Борис действительно не мог остановиться и развернуть архитектуру вовремя из-за косноязычности менеджера, кирпичи выпекать стало не кому выходит, кстати хороший паттерн чтобы не плодить под пирожки своих поворов — мост / Bridge)
3) стартап, в котором надо делать быстро и с возможность масштабирования. Тут любой подход хорош, единтсвенное надо реализовывать его качественно. Если разобратся в подходах данных программистов, то Борис пишит объектно-ориентированный код, а Маркус — процедурно-ориентированный, ну и кто сказал что последний сложно тестировать? Можно и нужно поколоть его основные методы на составляющие и их так же легко тестировать как объекты. Разница их подходов лишь в том, что у Бориса есть модель объектов, она более наглядна, чем математическая модель Маркуса. А код один и тот же, просто дайте процедурнику объектно ориентированный код, он его поймет, но напишит все посвоему и криво. А если наоборот, то объектник начнет все рефакторить излишни пытаясь структурировать. Так что лучше не мешать программистам, а грамотно менеджерам ставить задачки))
так программно иммено user и создает zip, так что проверку проходит легко. Атрибут запрета мы не выставляем, дабы можно было переносить документы на другое устройство
Да, в Documents. В сохранности остаются файлы только там. Но если закешированные файлы вы попытаетесь сохранить сразу туда, то из Apple Store вероятней всего придет письмо, о том что не следует держать такое обилие файлов, вероятнее всего вам необходимо перевести все в cashes. Вот тут и приходит на выручку zip
Извините, конечно! В данном контесте речь конечно не о бизнеслогике, а о решении. Тоесть один парсер — одно решение, другой парсер или протокол — это другое решение. В данном контексте как раз таки паттерны позволили
«Но это не позволяет заменять одни решения на другие. Возможно речь об интерфейсах?»
так что еще как позволяет!
Согласен: в данной задаче использовался Заместитель для того чтобы изолировать реализацию парсинга. А вот медиатор кстати скорее в задаче кеширования, для того чтобы подменить данные, загружаеммые с сервера локальными. Композитор используется на стыке взаимодействия поставщика данных и кешером с одним и тем же парсером/сериализатором.
Цель наша, да, пиар — какие мы крутые разработчики, создаем крутой продукт.
Поделились опытом, тестами и исходниками.
А вы тут какую цель преследуете? Можит мы вам не подходим по интересам?
>> Многие разработчики используют шаблоны проектирования. Но это не позволяет заменять одни решения на другие. Возможно речь об интерфейсах?
Речь о бизнеслогике. Если нужно кешировать не на день, а до удачного получения соединения с интернет в нескольких логически связанных отделениях, то пишется потомок одной из ветки классов ответственного за кеширование, далее он объявляется ведущим в выборке данных одного или нескольких логических отделений. Занимает это пару строчек кода, а работает на данном принципе кеширования все приложение.
>> Это не назначение паттерна прокси. Это всего лишь следствие его применения.
Согласен, у паттернов нет назначений, но мы легко находим им применение
>Вместо «Android» можно поставить что угодно: «ios|macos|linux|windows|blackberry»
>Информации 0, даже не разработчик знает, что существуют экраны различных разрешений и плотности пикселей, а так же что есть карты памяти, и что плохие приложения тормозят.
Еще вы забыли о том что приложения закрываются и как с этим борятся именно под Андройд.
А так вообще вы же понимаете что не на всех «ios|macos|linux|windows|blackberry» есть проблема с картами памяти и пиксилизацией.
Постановка задачи — это решение задачи на 80%. Какая-то часть займет тестирование, а на написание программ останется совсем малость.
В статье ведется речь о взаимодействии с дизайнерами, овнерами продукта. Описано как производится тестирование приложений под Андройд.
Достаточно много информации на мой взгляд об особенностях архитекртуры Android, которая определенным образом учитывается в разработке.
Что вам еще не хватает, может быть исходный код для примера?
Вам придется подождать обновления 1.2, через неделю выйдет скорее всего. В нем все намного быстрее, корректно отбражаются таблицы и рисунки, ничего не тормозит и не падает) Счастье придет в каждый дом)
Чего же странного? Зарегистрироваться или войти нужно для авторизации в «ПРАВО», на айфоне это сейчас происходит при запуске в первый раз, а будет происходить только при обращении к спецсервисам и только после выпуска обновления. Обновление только задумывается, его еще никто не выкладывал
на айфоне есть сервис «Обновить документы» он требует авторизацию, на iPad его нет пока, но когда появится будет требоваться авторизация только при обращении к нему. Я думаю на iPhone в скором времени будет так же с выходом новой версии
Программисты вообще всегда молодцы, живут в своем мирке и как знают мирок свой так и пишут.
А вот менеджеры, блин, ну неужели они не могу объяснить какой будет проект:
1) прототип для показа — который выкинут и надо код писать быстрее пусть с утечками памяти немасштабируемый и т.д. (Маркус тут даже перестарался, все можно было написать в main()),
2) серезный проект с ТЗ, которого действительно утверждено — надо показать это ТЗ, диаграмки состояний нарисовать, объяснить как в дальнейшем может развиться система. Какие перспективы сопровождения (Борис не виноват что ему не предоставили полной информации, однако он правильно начал с минимумом абстракций, а потом их наращивал, основной бедой его был повар, который является инициатором выпечки — он фабрика, а не плита, плита — инструмент, который на ровне с рецептом должен использоваться поваром и просто поддерживать температуру определенную, из-за неправильного повора рецепт вперся в плиту зачем-то и пошло поехало, Борис действительно не мог остановиться и развернуть архитектуру вовремя из-за косноязычности менеджера, кирпичи выпекать стало не кому выходит, кстати хороший паттерн чтобы не плодить под пирожки своих поворов — мост / Bridge)
3) стартап, в котором надо делать быстро и с возможность масштабирования. Тут любой подход хорош, единтсвенное надо реализовывать его качественно. Если разобратся в подходах данных программистов, то Борис пишит объектно-ориентированный код, а Маркус — процедурно-ориентированный, ну и кто сказал что последний сложно тестировать? Можно и нужно поколоть его основные методы на составляющие и их так же легко тестировать как объекты. Разница их подходов лишь в том, что у Бориса есть модель объектов, она более наглядна, чем математическая модель Маркуса. А код один и тот же, просто дайте процедурнику объектно ориентированный код, он его поймет, но напишит все посвоему и криво. А если наоборот, то объектник начнет все рефакторить излишни пытаясь структурировать. Так что лучше не мешать программистам, а грамотно менеджерам ставить задачки))
Вывод из статьи: менеджеры виноваты во всем
Да, в этой книге очень хороший перевод, трудно не согласиться
«Но это не позволяет заменять одни решения на другие. Возможно речь об интерфейсах?»
так что еще как позволяет!
Поделились опытом, тестами и исходниками.
А вы тут какую цель преследуете? Можит мы вам не подходим по интересам?
Речь о бизнеслогике. Если нужно кешировать не на день, а до удачного получения соединения с интернет в нескольких логически связанных отделениях, то пишется потомок одной из ветки классов ответственного за кеширование, далее он объявляется ведущим в выборке данных одного или нескольких логических отделений. Занимает это пару строчек кода, а работает на данном принципе кеширования все приложение.
>> Это не назначение паттерна прокси. Это всего лишь следствие его применения.
Согласен, у паттернов нет назначений, но мы легко находим им применение
>Информации 0, даже не разработчик знает, что существуют экраны различных разрешений и плотности пикселей, а так же что есть карты памяти, и что плохие приложения тормозят.
Еще вы забыли о том что приложения закрываются и как с этим борятся именно под Андройд.
А так вообще вы же понимаете что не на всех «ios|macos|linux|windows|blackberry» есть проблема с картами памяти и пиксилизацией.
В статье ведется речь о взаимодействии с дизайнерами, овнерами продукта. Описано как производится тестирование приложений под Андройд.
Достаточно много информации на мой взгляд об особенностях архитекртуры Android, которая определенным образом учитывается в разработке.
Что вам еще не хватает, может быть исходный код для примера?
Насчет temp все правильно, эта папка создана для временных файлов