Я под андроид пишу совсем недавно, но по-моему в самом фреймворке ОС предостаточно механизмов/инструментов для разделения этих трех уровней приложения. Разве что иногда нужно вынести некоторые вещи в общие классы. Зачем еще какой-то огород городить…
А собственно что про саму библиотеку? Может быть стоило описать пример практического использования или реализации хотя бы простого варианта рекомендательной системы.
Да, в транке работа практически не ведется, только исправляются ошибки, т.е. поддерживается его стабильность. А в качестве mainline используется ветка feature-testing, которая начинается от транка и используется для совместного тестирвания нового функционала.
Однако мне кажется что держать функционал в mainline и контролировать его использование/неиспользование сложнее, чем просто собирать билды из feature-веток. Особенно если компоненты приложения слабосвязаны. Ну то есть можно наверное даже комбинировать подходы, просто вариант с ветками мне кажется более упорядоченым и очевидным. По крайней мере можно быстро посмотерть какие ветки слиты в билд и соотв. какие функции есть, а каких нет.
Постоянная интеграция избавляет от проблем с мержами, но хорошо ли в основную ветку сливать незаконченный функционал?
У нас в проекте по этой причине есть 2 дополнительные ветки, помимо trunk: для тестироавния багфиксов, которые нашлись в стабильной версии и для тестирования нового функционала. Вот с ними идет постоянная синхронизация. Но при этом в стабильную версию(trunk) сливаются только исправления.
А из функциональных веток уже создаются билды и потом один из них становится следующей стабильной версией.
Хорошая статья и обсуждение в комментах)
В текущем проекте после того как была «сформирована» архитектура, потом переформирована и снова и снова. Пришел к мысли о «проектировании через эксперимент». Когда важные архитектурные изменения, но не фундаментальные, вносятся в соответствии с реальными требованиями и поведением пользователей и системы под их воздействием.
Думаю не совсем. У данной платформы по идее хорошие перспективы за счет более низкого порога вхождения из-за применяемых технологий. Все веб-разработчики смогут быстро адаптироваться к новой среде.
Так а что тут удивительного. Меня как пользователя всегда раздражало то, что для просмотра картинок из результатов надо идти на какойто левый сайт. Пользователь, когда ищет изображения, хочет посмотреть изображения, а не сайт на котором они расположены. Все логично.
А то что трафик упал, ну извините. Был полезный побочный эффект, теперь нету.
Да, побольше бы больше конкретики. Например почему сказали только об облачных решениях. Если приложение не использует какую-либо облачную платформу, но нужны очереди. Только ради этого не всегда стоит менять серверную инфраструктуру.
Я так понял пост задумывался как мотиватор к использованию очередей сообщений в проектах. Тогда наверное стоило больше рассказать о подходах к построению архитектуры, основанной на очередях.
Я вот наверное злой какойто. Но блин, эта штука есть в php уже давно и поэтому меня немного поражают неокторые комментарии к статье. Статья то хорошая. Но какой блин нахрен ассемблер, причем он тут вообще? Причем тут списки продуктов? Ну то есть понятно, что оно так или иначе приведет либо к прикладной задаче, либо будет прослеживаться ряд аналогий. Но это же библиотека, которая позволяет использовать классические структуры данных в своих задачах и делать это удобно.
Насчет использования — очереди собственно для очередей чего угодно: сообщения, задачи… ну многие другие ситуации часто являются подмножествами. FixedArray — очевидно для того, чтобы знать о размере занимаемой памяти. Хранилище объектов удобная штука когда нужно хранить набор объектов определенного типа + оно реализует ряд интерфейсов типа итератор, array access и других, что тоже полезно.
Это же хорошие и удобные штуки, да еще и в ООП стиле.
Однако мне кажется что держать функционал в mainline и контролировать его использование/неиспользование сложнее, чем просто собирать билды из feature-веток. Особенно если компоненты приложения слабосвязаны. Ну то есть можно наверное даже комбинировать подходы, просто вариант с ветками мне кажется более упорядоченым и очевидным. По крайней мере можно быстро посмотерть какие ветки слиты в билд и соотв. какие функции есть, а каких нет.
У нас в проекте по этой причине есть 2 дополнительные ветки, помимо trunk: для тестироавния багфиксов, которые нашлись в стабильной версии и для тестирования нового функционала. Вот с ними идет постоянная синхронизация. Но при этом в стабильную версию(trunk) сливаются только исправления.
А из функциональных веток уже создаются билды и потом один из них становится следующей стабильной версией.
В текущем проекте после того как была «сформирована» архитектура, потом переформирована и снова и снова. Пришел к мысли о «проектировании через эксперимент». Когда важные архитектурные изменения, но не фундаментальные, вносятся в соответствии с реальными требованиями и поведением пользователей и системы под их воздействием.
А то что трафик упал, ну извините. Был полезный побочный эффект, теперь нету.
Я так понял пост задумывался как мотиватор к использованию очередей сообщений в проектах. Тогда наверное стоило больше рассказать о подходах к построению архитектуры, основанной на очередях.
Насчет использования — очереди собственно для очередей чего угодно: сообщения, задачи… ну многие другие ситуации часто являются подмножествами. FixedArray — очевидно для того, чтобы знать о размере занимаемой памяти. Хранилище объектов удобная штука когда нужно хранить набор объектов определенного типа + оно реализует ряд интерфейсов типа итератор, array access и других, что тоже полезно.
Это же хорошие и удобные штуки, да еще и в ООП стиле.