Да да, выкладывайте, это уже по мне :)
Вид для печати
EW1CK:
Артур, прототип для UI сделать не проблема... Даже можно без написания кода. Сесть или в фотошопе или в Visio сделать все скетчи, да и навигацию показать. Делал такое не раз, готов и опять... Если есть другие мысли или желание помочь, можно раскинуть часть задач, так как форм будет много...
Подумав, решил не открывать новую тему. Так как писать код и даже постановку красиво - времени нет и не будет в ближайшее время, а тяп-ляп не хочется.
Но, возможно, ответы на некоторые вопросы помогут участникам определится с чего начинать.
И самый первый, и по моему мнению, важный вопрос - должна ли быть предусмотрена у логгера возможность как просто командной работы, так и удалённой командной работы.
EW1CK:
Артур, предлагаю использовать визуальные компоненты из библиотеки Flamingo или SWT. Там есть Ribbon Bar, который по мимике 1 : 1, как в 2007-м оффисе. Очень удобный и интуитивный вариант для навигации. Сама Flamingo имеет более, чем 300 различных контролей и легко расширяется.
Конечно должна быть предусмотрена... Будет общий репозиторий, где будет исходный текст и бренчи, если надо... Доступ через обычных клиентов для SVN, CVS.
Peter:
И это будет обязательно... Иначе зачем же мы контест логгер собираемся писать? :)
Да, в принципе, можно раскинуть. Я готов взять кусок работы, давайте раскинем.
Может имеет смысл доку и mock-ups начать складывать в репозиторий ? Вроде вы проект на SF создали уже ?
Добавлено через 1 минуту
С Flamingo никогда не работал, надо посмотреть что за оно.
Добавлено через 16 минут
Что такое удаленная командная работа ? IARU Contest ? Когда команды территориально в разных местах ? Ну так особой разницы нет, главное чтобы они могли по TCP/IP общаться
Да вот поэтому и спрашиваю, что не очень понятно. Если да - то определиться надо сначала с клиент-сервер или p2p со всем что с этим связано, затем с делением клиентов по назначению (мульты, общий вызов, координатор, swl поддержка), потом с самими требованиями к клиентам и уж потом только выбирать среды разработки и прочий инструментарий.
Тем более что при клиент-сервер клиентов можно писать на большинстве языков.
Это конечно имхо.
Добавлено через 7 минут
Разница есть. TCP/IP траффик сам по себе не мгновенен, и у софта есть понятие быстродействия. Соответственно проработав саму идеологию взаимодействия с учётом этих нюансов можно на готовом софте не искать, почему долго идёт синхронизация. Хотя, если везде в шеках на IARU будет оптика или быстрый DSL то скорее всего вы правы.
Имхо.
Ну синхронизация логов будет в любом случае, так или иначе там не запредельные об'емы данных, поэтому gprs возможен без проблем. С другой стороны, зачем это надо. Каk правило в IARU каждая команда работает на своем диапазоне в своей моде и по сути результаты коллег им нужны только чтобы порадоваться, в общем для статистики, не больше. Поэтому особой скорости синхронизации не нужно, если результат даже будет меняться раз в 10 минут, это ни на что имхо не повлияет.
Честно говоря не помню точно можно ли в IARU работать с нескольких позиций в одном и том же моде на одном бенде, но ход мыслей понятен, спасибо.
Добавлено через 2 минуты
Ну в принципе, тут самое главное чтобы лог синхронизировался как можно чаще, желательно после каждой связи. Информации не много, поэтому даже gprs канала хватит, не говоря уже про edge, 3g, DSL и прочий wimax с d-star-ом.
Добавлено через 4 минуты
Тут проблема несколько в другом, некоторые провайдеры взяли моду запрещать открытие соединения извне, вслучае если клиент работает с динамическим IP адресом. Вот как это обойти при синхронизации логов, вот в чем вопрос ...
В принципе GPRS конечно хватит, просто я говорил что не нужно вводить каких-то искусственных ограничений.