Open Source - контест лог под Линукс

**R8TX** · 12.04.2009, 08:53

Сообщение от EW1CK

Вот по-этому мы до сих пор и не ломанулись генерить код, а принимаем нужные решения по техническому дизайну.

По-моему вообще нужно исходить из того, что сейчас наиболее привычно программистам. Если Вы заложитесь на трудоемкие или малопопулярные средства разработки, будет очень трудно найти помощников, а без них проект заглохнет очень скоро.

**I love radio** · 12.04.2009, 11:08

Сейчас кстати выпущены среды .net и ее аналог под Linux - Mono. Данные среды призваны способствовать написанию программ на тех языках, которые удобны программистам. Например над одной программой может работать целая команда разработчиков, но каждый при этом может писать на удобном ему языке. Отсюда же вытекает, что программы, написанные с использованием этих сред, могут быть легко портированы из одной операционной системы в другую и соответствеено наоборот. Сам я правда не программист, читал об этом в журналах.

**RX4HX** · 12.04.2009, 13:31

Сообщение от I love radio

Например над одной программой может работать целая команда разработчиков, но каждый при этом может писать на удобном ему языке.

Все таки мне интересно: в работе над одним проеком в комманде самое сложное - синхронизация действий комманды. По этому в целях упрощения обычно и выбирается единая среда разработки.
Мало того, что нет по сути ни менеджера проекта, ни ведущего программиста, так еще и средства разработки предлагается сделать разные.
Как вы собираетесь все куски вместе собирать???

Сообщение от I love radio

могут быть легко портированы из одной операционной системы в другую и соответствеено наоборот

Как меня достала эта фраза!!!!

Скажите, кто нибудь из присутствующих вообще хоть раз пробовал что либо куда нибудь портировать?!!! Пробовал???
Я - пробовал! Многие другие пробовали. Итог: зачастую проще под новую операционку с нуля проект написать, чем портировать. Пока на сегодняшний день разговоры про легкое портирование - не более чем маркетинговый ход компаний типа Майкрософт.
Как правильно сказал RX9TX - чего мучиться и писать что то свое - портируйте N1MM!

**RN9RQ** · 12.04.2009, 15:24

Сообщение от RX4HX

Как меня достала эта фраза!!!!

Скажите, кто нибудь из присутствующих вообще хоть раз пробовал что либо куда нибудь портировать?!!! Пробовал???
Я - пробовал! Многие другие пробовали. Итог: зачастую проще под новую операционку с нуля проект написать, чем портировать. Пока на сегодняшний день разговоры про легкое портирование - не более чем маркетинговый ход компаний типа Майкрософт.
Как правильно сказал RX9TX - чего мучиться и писать что то свое - портируйте N1MM!

Все решается просто при применении действительно трансплатформенных средств. При правильном подходе один и тот же код работает на любой платформе. Возьмите для интереса linux софт и попробуйте его перенести ан винду - это в разы проще, чем обратно.
Сейчас для диплома и аспирантуры пишем сапр, и пока нет необходимости вообще как-то разделять код, он работает под обоими платформами (GCC Perl графика openCASCADE)

**R8TX** · 12.04.2009, 19:45

С cwdaemon действительно проблемы, может самим придется писать замену?

--------------------
Many Windows loggers have a CW interface enabling to use F-keys or direct typing into a dedicated box. In Linux, there is possible to evaluate cwdaemon but there is a rough edge - this daemon was initially made by not so keen high-speed operators so the versions 0.8 and down are rather useless at speeds above 20 WPM. Since the mostly used speed range is from 30 to 45 WPM, you will need a custom-built low latency kernel, then the cwdaemon ver. 0.9.1 and above is quite good up to 40 WPM, acceptable to 50 WPM and can be used up to 60 WPM but the speed setting and weighting is not very accurate. A good advantage of cwdaemon is the standard parallel port interface compatible with N6TR's TRlog, CT by K1EA and many others.
--------------------

**I love radio** · 12.04.2009, 19:46

Портировать не приходилось, поскольку этим в приципе не занимаюсь, не программист, но вот из исходных кодов ставил проги и неоднократно. Главное, что бы код был доступен и открыт. Более того такие проги существуют чаще всего в вариантах не для двух а для большего количества систем, например это windows, linux, MacOsX да еще и FreeBSD, а то и более - тот же OpenSolaris. За примерами далеко ходить не нужно - возмите хотя бы браузер Firefox. Вопрос же о том портировал кто-то или нет считаю не совсем корректным, поскольку на этом форуме собрались в большей степени радиолюбители, а потому специалистов по портированию здесь просто мало. Кроме того как верно написал RN9RQ вопрос в изначально выбранной среде написания. Ну и о java забывать не стоит.

Все таки мне интересно: в работе над одним проеком в комманде самое сложное - синхронизация действий комманды. По этому в целях упрощения обычно и выбирается единая среда разработки.

Я думаю что это вопрос масштабности ПО, а так же веления времени. Если вы пишите небольшую программу, то вполне логично выбрать одно средство. Если же речь идет о масштабном проекте, то вы просто можете оказаться в ситуации, когда не сможете найти группу людей, пишущих на одном и том же языке и находящихся в одном месте планеты. Это как сборка крупного самолета - двигатели делают во Англии, фюзеляж во Франции, материалы поставляет Германия, а электроника идет из страны восходящего солнца (ну и в России что-то то же пусть делают в нашем примере

). Все при этом говорят на совершенно разных языках и используют свое собственное, отличное от чужого оборудование и технологии, но самолет все равно полетит. Так и сдесь - сделайте открытым компилятор, дайте профессионалам портировать его один единственный раз и люди смогут использовать одно и о же ПО на совершенно разных платформах.

**VE3EUT** · 12.04.2009, 20:18

Сообщение от RX9TX

По-моему вообще нужно исходить из того, что сейчас наиболее привычно программистам. Если Вы заложитесь на трудоемкие или малопопулярные средства разработки, будет очень трудно найти помощников, а без них проект заглохнет очень скоро.

Именно так, но я бы назвал это не средствами разработки, а скорее технологическим стеком, т.е. набором технологий и фреймворков. И выбор тут не такой большой на самом деле, а именно:
C/Qt
C/GTK
J2EE/Spring/Hibernate плюс какой-нибудь MVC тила GWT,JSF,ZK
J2SE/RCP/Hibernate
Mono/Jitsu/NHibernate

А средства разработки, если это среда разработки это уже личное дело каждого.

Добавлено через 32 минуты

Сообщение от RX9TX

С cwdaemon действительно проблемы, может самим придется писать замену?

Так я и писал уже что на 60 wpm есть проблемы, но они решаемы, я делал прототип драйвера ядра, там все не сложно. На 50wpm все нормально работает.

**RN9RQ** · 12.04.2009, 20:58

С чего бы вы взяли?
одной графики начиная от motiff fltk wxwidgets и много много других либ,
Языков куча, модула ада хаскелл R тот же python продолжать можно долго...
Нет и опяить этот быдломоно и быдлоджава...

**RX4HX** · 12.04.2009, 21:04

Сообщение от RN9RQ

модула ада хаскелл R

Чую, последователей будет "море"!

**VE3EUT** · 12.04.2009, 22:15

Сообщение от RN9RQ

С чего бы вы взяли?
одной графики начиная от motiff fltk wxwidgets и много много других либ,

Хорошая опечатка по Фрейду, motiff в отличие от smirnoff пишется с одной f на конце. Вообще вы сами много софта под motif написали ? Как он вам по сравнению с тем же Qt ? Вы немого не о том говорите. Нам не нужен набор графических компонентов, их полно всяких и разных. Нам нужен более высокоуровневый фреймворк, который позволит писать свои компоненты и расширять клиент по мере надобности без переписывания и рефакторинга. Если знаете нечто аналогичное RCP, я буду рад узнать для себя что-либо новое

Сообщение от RN9RQ

Языков куча, модула ада хаскелл R тот же python продолжать можно долго...
Нет и опяить этот быдломоно и быдлоджава...

Забыли LISP, SmallTalk и Eiffel для полноты коллекции. Юноша, если бы вы знали, как начинают с возрастом утомлять эти пионЭры с горящими глазами, которые делят технологии на тру и не тру.
Из всего, что вы перечислили, наверное python подошел бы, но под него нет уже написанного готового фреймворка, аналога RCP, который бы нам позволил быстро надевелопить клиента, причем не тратя время на разработку самого настраиваемого контейнера компонентов с удобными плаг-инными интерфейсами и прочими рюшечками и бантиками. У нас не так много ресурсов чтобы тратить их на эту ерунду, изобретая велосипед в который раз, хотелось бы состедоточиться на более прикладных задачах. Надеюсь, ход мысли понятен.

**RX1AL** · 12.04.2009, 23:15

EW1CK:
Артур, приветствую... Сегодня полдня потратил на то, чтобы в UML прорисовать все необходимые блоки и их логику взаимодействия. Кое-какие моменты надо будет уточнять. Саму диаграмму могу выложить в топике в двух форматах ER-Enterprise Architect, Visio 2007. Вторую половину дня потратил на изучения некоторых "скользких" моментов по описанию возможностей N1MM. Кое-что есть, что вызовет у нас возможно трудности в реализации.

Относительно средств разработки, думаю мы определились в плане Eclipse RCP. Думается будет лучшим начать писать standalone клиента для начала, чем делать его веб-базированным. Следующее: поскольку надобность в базе для нас с одной стороны стоит вопросом, с другой стороны нет, предлагаю (не настаиваю) взять и начать с простого (расширений в сторону усложнения, навалом) с XML ориентированной системы хранения данных. При этом в эту концепцию прекрасно вписывается и JLINQ, плагин для Eclipse, обеспечивающий для Hibernate дополнительную функциональность работы с entities. Работает в связке с JDBC. Нам это здорово поможет, да легкость структурирования объектов и классов, а также всей бизнес логики реализуется просто. Валидация добавлена по умолчанию уже. Кроме того, в случае применения аттрибутов, мы сможем реализовать и некую систему бизнес правил (business rules), которые нам потребуются. Несколько тестов я сегодня написал на JLINQ, по сути тоже самое, что и ADO.NET Entity Framework для дотнет. Думаю, вы в курсе.

Следующее, что необходимо сделать, обриcовать всю иерархию классов и объектов, которые нам нужны. Я потихоньку сел за это в UML. На следующей неделе выложу результаты. Используются generics типы во многих местах, ну без этого уже тяжело...

У некоторых оппонентов есть неплохие мысли, но использовать систему Scala, для интеграции многих языков в один фреймворк, несмотря на её столь широкую маркетинговую рекламу, пока не хочется. Вот будет что-то уже реальное на ней, тогда. А писать на ней только из-за "бантиков и рюшечек" не хочется ей-богу. Этих бантиков на RCP написано уже куча.

ПС Для большей информации, смотрите Quaere - это именно то, что описано выше. Есть DSL и основа на JPA.

**RN9RQ** · 13.04.2009, 03:20

EW1CK
Я еще забыл и свой любимый Perl и руби и много еще чего интересного.
И большое число графических библиотек.
И я благодарю судьбу, за то, что она меня салагу-первокурсника, у которого не хватало денег чтобы просто прожить в общаге, забросила в отдел где были и великолепниые инженеры по радиоэлектронике и прекрасные програмиисты, как вы пишете "пионЭры с горящими глазами", некоторым из этих пионЭров в то время бьло уже далеко за 40
и под motif, кстати еще даже не open motif я успел чуть-чуть по писать под операционную систему, название которой вы вряд ли даже слышали.
Айклипсом вашим можно разве что подтереться, нет ни одно сколь-нибудь популярного открытого проекта, построенного на эклипсе и направленного не на эклипс, как говориться десятки тысяч свободных разработчиков не могут ошибаться. но куда им до Вас вы же все умные и опаленные опытом.
Я при первой публикации целей попунктно понял куда катится этот едва зародившийся проект, поэтому сразу и написал что в этом я копаться не буду.
Удачи что называется.

Добавлено через 40 секунд
"Мышки плакали и кололись, но продолжали жрать кактус"

**VE3EUT** · 13.04.2009, 04:03

Сообщение от RX1AL

Саму диаграмму могу выложить в топике в двух форматах ER-Enterprise Architect, Visio 2007. Вторую половину дня потратил на изучения некоторых "скользких" моментов по описанию возможностей N1MM. Кое-что есть, что вызовет у нас возможно трудности в реализации.

Михал, если можно то в Visio 2003, удобнее всего. А что за скользкие моменты ?

Добавлено через 2 минуты

Сообщение от RX1AL

Валидация добавлена по умолчанию уже. Кроме того, в случае применения аттрибутов, мы сможем реализовать и некую систему бизнес правил (business rules), которые нам потребуются. Несколько тестов я сегодня написал на JLINQ, по сути тоже самое, что и ADO.NET Entity Framework для дотнет. Думаю, вы в курсе.

JLINQ пойдет в принципе, но вопрос в следующем, будем ли мы логи хранить на каждом клиенте и реплицировать или это будет выглядеть как-то по-другому ?

**RX1AL** · 13.04.2009, 04:46

RN9RQ:
Роман, не умаляя никоим образом ваших программистких навыков скажу просто. Во-первых, Eclipse никогда не являлся никаким языком программирования, а был и есть Open Source IDE для многих платформ, включая и С++, J2EE, .NET и другие специальные для автоматизации, embedded и real-time приложений.
Во-вторых, именно под Eclipse написано столько уже application frameworks, что с ним не сможет сравниться ни один из имеющихся сейчас на рынке продуктов. Кроме того, Eclipse поддерживает Dynamic Languages, чего нет даже у Микрософт пока - есть только попытки, создать нечто подобное, и появится только в версии 4.0. В-третьих, на базе application frameworks уже реализовано в мире огромное множество enterprise проектов, которые внедрены во многих отраслях промышленности. Вероятно вы просто не в курсе...
В-четвертых, если бы весь мир плевался бы от него, то не проводились бы каждый год конференции DoorOpen, посвященные развитию данной платформы и её значимости для Open Source комьюнити. Взгляните хотя бы на Ganymede, если вы не в курсе. Относительнo вашей сильной неприязни к этому, я могу повторить лишь то, что сказал Артур - это лишь молодость и отсутствие нужного опыта. Я думаю, у Артура, да и у меня за плечами его несколько побольше в плане разработки больших проектов... не обижайтесь, но и я старше вас. Причём намного.

Попробуйте создать альтернативу и вы поймете, о чем мы здесь рассуждаем. Только когда наступите на грабли, приходите и мы вам объясним, где и почему это произошло. Мы не рвемся на абразуру, как матросовы, чтобы потом не сказать, как в анекдоте "грё...ый гололёд". Надо сначала всё взвесить, а потом приниматься за пилот-версию, а не делать сразу же беты или релизы. Вы наверное знакомы с таким понятием, как proof of concept? Если да, то вы нас поймете, если нет, то познакомьтесь. Очень полезно.

ПС И для сравнения, Роман. После подробной постановки задачи, программисты на Eclipse пишут за 4-5 месяцев приложения энтерпрайз уровня, группой из 3-4 человек. Если вы будете писать тоже на Qt, TCL/TK (не принижая их достоинств) - потратите год-два, как минимум, если не больше.

EW1CK:
Артур, как скажете, в таком формате и сконвертирую, тем более совместимость сверху вниз ещё поддерживается. Касательно JLINQ, точнее Quaere - я предлагаю хpанить логи на каждом из клиентов и использовать репликацию. Ну как-то привычнее. Если есть аналогия сервисам Sync, рад услышать что-то новое, но пока они в стадии альфа... и не хочется связываться. Есть дедовские, проверенные способы - на них и будем делать. Будет, что-то новое, опробованное - перейдем на них. Развитие должно быть последовательным, а не сразу все на 1-2-3 - проходили уже...

ПС По тонким моментам, составлю табличку и выложу. В основном там момемнты, связанные со статистикой, рейтами в реальном времени и мультами.

**VE3EUT** · 13.04.2009, 05:29

Сообщение от RX1AL

Следующее, что необходимо сделать, обриcовать всю иерархию классов и объектов, которые нам нужны. Я потихоньку сел за это в UML. На следующей неделе выложу результаты. Используются generics типы во многих местах, ну без этого уже тяжело...

Мне кажется это может в принципе подождать, вернее класс-диаграммами заниматься можно и нужно, но самое важное сейчас это продумать концепцию пользовательского интерфейса, а еще лучше сделать прототип UI и поругать его с точки зрения функциональности.

Еще вопрос на который предстоит ответить, будем ли мы заморачиваться со скоростями больше 50wpm на данном этапе. Предлагаю пока эту проблему отложить на потом и использовать cwdaemon как есть. Потом его можно будет поправить или заменить чем-то еще.

Еще вопрос, это интерфейс с hamlib, нужно подумать, будем ли мы заморачиваться и дергать его через RCP или просто будем дергать через JNI. Я бы наверное предпочел второй вариант.