Чувствую какой я профан в многокомпонентных системах :( Опять я пытался «ремонтировать двигатель через выхлопную трубу». С другой стороны, мы сильно ограничены в ресурсах, и потянуть все эту махину это вообще невообразимо в нашем случае.
Написать то можно. А что это по сути изменит? Только если при подключении клиента в первую очередь делать фулл валидацию WSDL (проверку всех интервейсов). Окей, а далее. Сервер идет в БД, WEB смотрит в БД, как их связать c WSDL?
Изменения компоненты в одной системе без изменения всех её использующих, скорее всего, приведет к ошибке компиляции, что CI быстро покажет. Изменения в подпроектах к ошибки компиляции в смежных продпроектах не приводят. А выявляются на этапе работы, т.е. грубо говоря, нужна полная функциональная регрессия. Полную функциональную регрессию построить не всегда удается, а у нас и подавно. И того при 4 звенной архитектуре для внедрения одной фичи нужно согласовать до 4 компонент.
В начале у нас был только транк, и это был, простите ужас. Получить билд системы, с полной согласованность по функционалу вообще нельзя было. Мы пришли к боле менее консенсусу. Что транк это свалка, и для каждого релиза у нас будет tag.
В начале мы пробовали сперва приводить в транке все подпроекты к одному состоянию далее делать срез транка, вот вам тег-релиз для тестирования. Но данный подход отпал из-за разной скорости реализации различных компонент. Теперь мы, как правило, вначале создаем tag и далее каждый подпроект переноситься туда по факту реализации в нем всех заявленных функций для данного тега. Это чуть получше, но тоже не удобно.
А еще важный момент, что сейчас все подпроекты лежат в общем для них тнаке. Что опять таки не очень удобно, но и разнести их в разные репы тоже не видится решением проблемы. Так как сейчас у нас как бы есть Мажорная версия проекта, которая лежит к корне транка и она явлется камнем согласования между компонентами, что мол компонента A версии 1.3 не совместима с компонентой B если она уже версии 1.4.
Вот, примерно такая каша и происходит. Было бы интерестно послушать тех кто уже прошел этот путь.
возможно плохо написал. Под «самостоятельные» я имел в виду, что они ведутся разными разработчиками под под разные языки и платформы. По сути да, это компоненты одной системы.
А есть у кого опыт ведения проекта состоящего из нескольких подпроектов. Подпроекты это не просто отдельные компоненты ПО, это самостоятельные проекты на разных платформах/языках но при этом они все завязаны друг на друге в одну систему.
К примеру, несколько мобильных платформ, сервер, БД, web. Интересно услышать об опыте ведения таких проектов в VCS. Какие существует стратегии или методики держать всю эту ораву разношёрстных проектов в одной узде.
Знание алгоритмов, структур данных и прочих алгоритмических задач дает шанс свести текущую задачу к общеизвестной уже решенной, таким образом решить текущую задачу более оптимальным способом нежели ты бы выдумал.
Я верю в это, но на практике не получается. Либо я не знаю те алгоритмы и структуры данных к которым могли бы свестись мои задачи, решение которых мне приходится порой выдумывать.
Найдите в вашем городе English Communication Club или English Gaming Club. Эффект появляется после пары занятий, когда вы привыкните к людям. Со временем уходит страх говорить неправильно (внутри этого коллектива). А это уже хорошая отправная точка и постоянный мотиватор.
Я таки не понял, результатом сборки получается бинарный файл? А как один бинарный файл запускается на разных ОС где тупо разный формат исполняемого бинарного файла?
Таки до конца не осознал, надо еще пару раз перечитать.
Первый аспект который я не понял. class X это заменитель типа char? т.е. в строке
xs s1((X*)«1234567890»);,
X* x = (X*) «1234567890», x будет воспринят как указатель на массив из элементов X?
Еще я немного удивлен тем что не используются операции типа memcpy для копирования _CharT* _M_p.
Не, ну а кто вам мешает бороться с дезой дезой.
Хлеб против театра
Творог против… утина
Электрический столб против… теранов
Это как?
В начале у нас был только транк, и это был, простите ужас. Получить билд системы, с полной согласованность по функционалу вообще нельзя было. Мы пришли к боле менее консенсусу. Что транк это свалка, и для каждого релиза у нас будет tag.
В начале мы пробовали сперва приводить в транке все подпроекты к одному состоянию далее делать срез транка, вот вам тег-релиз для тестирования. Но данный подход отпал из-за разной скорости реализации различных компонент. Теперь мы, как правило, вначале создаем tag и далее каждый подпроект переноситься туда по факту реализации в нем всех заявленных функций для данного тега. Это чуть получше, но тоже не удобно.
А еще важный момент, что сейчас все подпроекты лежат в общем для них тнаке. Что опять таки не очень удобно, но и разнести их в разные репы тоже не видится решением проблемы. Так как сейчас у нас как бы есть Мажорная версия проекта, которая лежит к корне транка и она явлется камнем согласования между компонентами, что мол компонента A версии 1.3 не совместима с компонентой B если она уже версии 1.4.
Вот, примерно такая каша и происходит. Было бы интерестно послушать тех кто уже прошел этот путь.
К примеру, несколько мобильных платформ, сервер, БД, web. Интересно услышать об опыте ведения таких проектов в VCS. Какие существует стратегии или методики держать всю эту ораву разношёрстных проектов в одной узде.
Я верю в это, но на практике не получается. Либо я не знаю те алгоритмы и структуры данных к которым могли бы свестись мои задачи, решение которых мне приходится порой выдумывать.
А почему клиент может один фрейм два раза отправить?
Фрейм это «Клиент серверу во время игры»?
Интересный пост для начала изучения проблем гем дева, python и Twisted:) по разбираюсь.
Первый аспект который я не понял. class X это заменитель типа char? т.е. в строке
xs s1((X*)«1234567890»);,
X* x = (X*) «1234567890», x будет воспринят как указатель на массив из элементов X?
Еще я немного удивлен тем что не используются операции типа memcpy для копирования _CharT* _M_p.