| |
 Уход от Delfi, на конторе |
|
|
|
|
 Jun 8 2011, 08:13
|
Местный
Группа: Свой
Сообщений: 481
Регистрация: 1-08-05
Пользователь №: 7 267
|
Все "cопутствующие програмки для PC " написанные еще на D2, прекрасно дышат под любой NT, включая w7. В трехстах килобайтах несут все самое необходимое, включая VCL. Запустил и работает... Или хочется потрахаццо с луниксами, дот NET-ами и другими монстроидальными жабообразностями? Хочется на каждом клиентском компе толстый интернет для обновления этой байды/поиска старых версий для отката? Есть положительный опыт юзания новых сред от некрочипа и атмел?  Разъясните подробней насчет "тема себя изжила". Непонятно 
|
|
|
|
|
|
|
|
Jun 8 2011, 09:00
|
Профессионал
Группа: Свой
Сообщений: 1 292
Регистрация: 26-06-07
Пользователь №: 28 718
|
Есть два направления для RAD. Если нравятся плюсы, то QTCreator в руки, если шарп, то студия(она хоть и монстр но у нее столько плюшек, которые ускоряют написание). Студию сожно заменить на SharpDevelop или Monodevelop. Никаких проблем у клиентов это не вызывает. Затачивание ПО под mono фреймворк позволит без гемора запускать программу как под вин так и лин. В большинстве случаев простое ПО под .net и без допиливания запускается под mono. С некрочипом дела не имел. Под атмел пишу в codeblocks. Цитата Разъясните подробней насчет "тема себя изжила". делфи давно подох и разложился
|
|
|
|
|
|
|
|
Jun 8 2011, 09:23
|
Беспросветный оптимист
Группа: Свой
Сообщений: 4 640
Регистрация: 26-12-07
Из: Н.Новгород
Пользователь №: 33 646
|
Цитата(smalcom @ Jun 8 2011, 13:00)  делфи давно подох и разложился Вместе с борландом Цитата В феврале 2006 года Borland Software Corporation объявила о своих планах полностью переключиться на разработку и поддержку средств управления жизненным циклом приложений (Application Lifecycle Management, ALM). В рамках этого плана Borland приобрела компанию-поставщика ALM-решений Segue Software Inc и анонсировала планы о поиске покупателя на часть бизнеса компании, связанного с созданием средств разработки приложений, включая линейки Borland Developer Studio (Delphi, C++Builder, C#Builder) и JBuilder. Покупателя не нашлось, поэтому направление интегрированных средств разработки (Integrated Development Environment, IDE), было выделено в коммерчески самостоятельное подразделение CodeGear. А в Интернете даже появился проект по сбору средств на приобретение Delphi с целью сделать его Open Source продуктом.[3]
7 мая 2008 года компания Embarcadero Technologies приобрела у Borland Software её подразделение CodeGear за 23 млн долларов и 7 млн долларов в дебиторских задолженностях, доставшихся Borland.
6 мая 2009 стало известно о том, что компания Borland Software будет продана за 75 млн долларов британской компании Micro Focus, специализирующейся на поддержке крупных корпоративных систем на языке COBOL. В общем, это как пикад. Смысл оставлять (а тем более покупать за деньги) есть только для поддержания большого количества "нажитого непосильным трудом". Сорри за лирическое отступление. По теме: Если "Сопутствующие програмки для PC" предполагаются чисто под винду, то и среду разработки логично взять родную - MSVS. Если подразумевается кроссплатформенность - тогда ориентация на C#/Mono, GTK, Qt. Кстати, насчёт "бесплатности" Qt - это ещё большой вопрос. Пока лицензия LGPL, но ввиду планомерного подминания Nokia (владельца прав) под MS возможны варианты.
--------------------
Программирование делится на системное и бессистемное. ©Моё :)
— а для кого-то БГ — это Bill Gilbert =)
|
|
|
|
|
|
|
|
Jun 8 2011, 10:36
|
Гуру
Группа: Свой
Сообщений: 2 712
Регистрация: 28-11-05
Из: Беларусь, Витебск, Строителей 18-4-220
Пользователь №: 11 521
|
Программисты (за исключением одного) работают и с железом и с ПО для PC. Собственно и сам так. Работа там в С и здесь с D7 - мягко говоря напрягает. Да и смысла не вижу. Уход в билдер координально не решает проблему. Не собираюсь спорить, ну думаю что большинству очевидно. Сам D7 сейчас уже не поддерживается и не отвечает текущим требованиям. Приложения пишем - обычные для таких контор. Сервисные пакеты для своих приборов. Удалённый съём данных с приборов. Хранение и обработка результатов, генераторы отчётов. Объединение в сеть. Обслуживание стендов и так далее. Короче интерфейс пользователя + работа с изделиями 232/485/ethernet. По поводу кроссплатформенности - раньше (естественно) вопросы не возникали. В текущий момент - приходится подумывать. То есть если есть такая возможность, то я думаю это всё же плюс. Хотябы имиджевый. Я пока не принял решение - именно по этому к Вам и обращаюсь. Хочется услышать разные мнения. Очень бы хотелось послушать тех, кто пытается применять другие пакеты в рамках небольшой конторы. Плюсы и минусы. Цитата(DSIoffe @ Jun 8 2011, 11:49) А если новый профессиональный программист не может прочесть код на Delphi, то он не очень-то профессионален. Как раз по D7 координальных вопросов не возникает. Хотя тоже ... Боимся, что такие проблемы пойдут с переходом на MSVS. По D7 тоже не всё гладко. Приходит новый программист. Пол года въезжает в тему. Потом год чёто правит, ругая попутно всё то, что написали предыдущие, потом уходит... Ну и так далее... )) Написанный крупный проект сервер-арм писался уже 4-5 программерами и представляет собой безсистемную сборку их творений. Иногда начинает тихо ехать крыша. Там исправишь - тут вылазит. ))
|
|
|
|
|
|
|
|
Jun 8 2011, 11:02
|
Местный
Группа: Свой
Сообщений: 473
Регистрация: 10-09-06
Из: Тольятти. Самарская обл.
Пользователь №: 20 249
|
Цитата(ukpyr @ Jun 8 2011, 14:21) если нужно все-в-одном, беспроблемная кроссплатформенность, наличие мощных средств разработки и кучи бесплатных библиотек, можете посмотреть на Java/Scala +1 за Java+Eclipse в качестве среды разработки.
--------------------
Если все, то не я...
|
|
|
|
|
|
|
|
Jun 8 2011, 11:21
|
Дима
Группа: Свой
Сообщений: 1 683
Регистрация: 15-12-04
Из: Санкт-Петербург
Пользователь №: 1 486
|
Цитата Сам D7 сейчас уже не поддерживается и не отвечает текущим требованиям. А я вот по ряду причин никогда не пользовался поддержкой Delphi... Не в порядке спора, а для себя интересно: чего Вам не хватает в Delphi 7 для Ваших задач? Цитата Сам раньше писал всё на дельфи. Потом начало раздражать - дельфи тут, С в МК. А когда тут Delphi, а там VHDL - вообще! Особенно после 23 часов вспоминать, где какой синтаксис оператора case...
--------------------
|
|
|
|
|
|
|
|
Jun 8 2011, 11:30
|
Профессионал
Группа: Свой
Сообщений: 1 003
Регистрация: 20-01-05
Пользователь №: 2 072
|
Цитата(SasaVitebsk @ Jun 8 2011, 13:36) Написанный крупный проект сервер-арм писался уже 4-5 программерами и представляет собой безсистемную сборку их творений. Иногда начинает тихо ехать крыша. Там исправишь - тут вылазит. )) Это недоработка ваша или вашего начальства. В программирование крупных армов сам не лезу, но периодически просматриваю "чего там понаписали". Если обнаруживаю явный бред, то собираемся и корректируем идеологию. Касательно языка и кросплатформенности - если есть время, то можете поэкспериментировать. В нашей конторе исторически использовались три языка: С,C++ и Delphi. К программистам нареканий не было, но стыковка разных модулей отнимала время и средства. В итоге было решено сделать три проекта на С++ и три на Delphi. Во всех случаях было требование переносимости, оценивалось общее время разработки нормализованное по сложности задачи. Также сознательно в ТЗ не были внесены некоторые пункты, с целью оценить время внесения изменений. Библиотеки и инструментарий программисты могли выбирать сами (в пределах разумного конечно). Итог был (для меня) неожиданный - победил lazarus.freepascal.org. Один из программистов был сильно недоволен, но не привел убедительной аргументации, а обещание уволиться не выполнил. С инструментарием с доступным исходным кодом нужно быть осторожным - особо инициативные пытались использовать свои патчи к fpc, но это было запрещено административно.
|
|
|
|
|
|
|
|
Jun 8 2011, 13:33
|
Adept
Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343
|
Цитата(SasaVitebsk @ Jun 8 2011, 14:29) Скачал и установил QT (QT Creator). Вроде выглядит привлекательно. Поддерживается, развивается. Локализация русская. Много примеров. Форумы. Бесплатная.
Кто поделится своими наблюдениями. Посоветует. Замечания.
Заранее благодарю. Когда-то для разработки софта для РС (для внутренних нужд) пользовался Borland C++Builder. Потом, освоивши Python, многие вещи делал на нём. Но иногда встаёт необходимость именно в полноценном экзешнике с нативно исполняемым кодом. Развитие билдера не понравилось - в отличие от пятёрки, которая была проста, быстра и достаточно стабильна, последние версии выглядят монстроидально, громоздко и мутно. Подыскивал замену, остановился на Qt. Сейчас лабаю небольшую программку для внутренних нужд. Навскидку могу сказать следующее: - Qt - это не RAD система. То, что там есть Designer, не делает его таковой. В отличии от дельфей и билдера, где можно было накидать на форму компонентов (в том числе и неграфических) и быстренько в полувизуальной манере запрограммировать поведение - евенты повесить, задать значение всех свойств по умолчанию и т.п., тут такие номера не проходят. На форму можно положить некоторые виджеты, но по большому счёту этим всё и ограничивается. Т.е. от дизайнера эффективно можно получить только геометрическое размещение виджетов и всё. Остальное - назначение событий, их обработка, инициализация и настройка - всё это делается руками в коде. Это не так удобно как борландовских продуктах, но склонен считать, что это более правильный подход, хотя он и требует глубже вникать в систему и разбираться с её потрохами. Поэтому Appication Development получается не такой уж и Rapid
- Среда разработки Qt Creator (как и почти все среды) весьма отстойна. Да, там многие вещи делаются неплохо, но есть и масса неприятных мелочей, начиная от того, что курсор в редакторе прыгает по тексту при вертикальном перемещении в зависимости от конца строк и заканчивая тем, что нет удобного расположения редактируемых окошек в виде привычных по многим программам табов. Собираюсь со временем перелезть на свой любимый слик. Самое сложное тут - это переделать среду сборки под сконс, избавившись от make и, как следствие, их инструмента организации проекта qmake. Основное тут - это разобраться с moc (meta-object compiler).
- Качество самого фреймворка в целом на высоте. Но отдельные программные его модули оставляют желать лучшего. Например, QtSQL не приходится рассматривать как полноценную библиотеку, целиком пригодную для написания сложных программ. Её слой драйверов и низкоровневого БД API вполне вменяемые, но вот про третий слой - прикладные модули (QSqlTableModel и подобные) этого сказать нельзя. В общем, нужно в каждом случае внимательно смотреть, на каком уровне выполнен прикладной модуль. Мнение обычно можно составить, читая посты на форумах - информации предостаточно. Правда, я сперва набил немного шишек на этом модуле, а потом уже накопал на форумах, что проблема не нова.
- При организации всех классов Qt используется идеология на основе паттерна PImpl (Pointer to Private Implementation). Она имеет свои плюсы и минусы. Главное, для чего они её заюзали - поддержание бинарной совместимости (по крайней мере, в пределах мажорных номеров версий). Правда, мой опыт показал, что это в реале не работает, во всяком случае, не всегда - при переходе с версии 4.6.3 (а под неё мной руками были собраны драйвера для сервера MySQL) на крайнюю версию 4.7.3 программа отказалась вязаться с сервером. Пересборка драйверов порулила проблему.
Ещё одно преимущество такого подхода - более быстрая загрузка программы. Программа действительно грузится и работает быстро. Но при отладке этот подход доставляет проблемы: несмотря на open source реализация потрохов видна не на всю глубину. И постоянно сталкиваться с кодом Q_D(class_name); и далее d->... - не добавляет комфорта. Разбираться с этим кодом сложнее, чем с написанным явно, т.к. приходится искать определения этой приватной имплементации.
- Бесплатная лицензия имеет некоторые ограничения. В частности, в ней не предусмотрена сборка статической версии программы, чтобы получить самодостаточный экзешник. Поэтому придётся тащить как миниум один или два рантаймных модулей библиотек - QtCore, QtGui. Цена вопроса - 12 мегов.
В целом, фреймворк достойный. Реальной альтернативы я ему не вижу. Конечно, для эффективной работы с ним придётся изрядно погнуть моск под его подходы: например, повсеместно используется new для создания объектов и очень редко можно увидеть delete - там широко применяется подход через удаление объектов в деструкторе предка, поэтому в каждом объекте виджета в конструкторе есть аргументом указатель на предка QObject *parent; или, скажем, строго заданная схема создания объектов-виджетов, при которой все объекты-виджеты создаются не в конструкторах, а уже во время запуска самой программы, т.е. после старта main(). Пристальное внимание надо уделить таким аспектам, как передача сообщений по схеме signal/slot, event'ам и event filter'ам. Это базовые вещи, без хорошего понимания которых, более-менее серьёзную программу не создать. В общем, не всё там так просто и безпроблемно, но если готовы потратить силы и время на освоение, то дело это считаю достойным. Сам в процессе.
--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
|
|
|
|
|
|
|
|
Jun 9 2011, 06:16
|
Гуру
Группа: Свой
Сообщений: 2 712
Регистрация: 28-11-05
Из: Беларусь, Витебск, Строителей 18-4-220
Пользователь №: 11 521
|
Цитата(DSIoffe @ Jun 8 2011, 14:21) Не в порядке спора, а для себя интересно: чего Вам не хватает в Delphi 7 для Ваших задач? Ну, например, простой пример. Симуляторы разные. Где желательно полный перенос текста программы. 2 dxp. Огромное спасибо за развёрнутый ответ. Тем более что ваши знания в плюсах на голову больше моих. Я ковыряюсь недели 2-3. Тем не менее по пунктам ... 1 - я уже понял в полном объёме. И вот тут у меня несколько вопросов. Надо ли вообще дизайнер? Или единожды делаешь размещение и лучше больше к нему не возвращаться? Он там хидер генерит автоматически и в случае изменений, соответственно его херит. Так есть вариант просто использовать другой хидер, взявши генерируемый за основу. )) Не пинайте больно - я ещё сквозную идею не ухватил пакета. В дельфях форма менялась по ходу написания неоднократно. Часто так и писалось. Накидал компонентов - обработал, накидал ещё. 2. Тоже почти согласен. Особенно TAB убивает. Хотя остальное вполне понравилось. Особенно замена "." на "->" очень удобно. )) Только мне слик не нравится. Вопрос: Зачем среду сборки менять??? И ещё один вопрос. В одном случае добился (!!) что абсолютно правильный проект вызывал ошибку при сборке. Причём ошибку VS почему-то. С предложением отослать )). Насколько сам пакет устойчиво работает??? 3. SQL пока не нужен, но не исключаю естественно. Мне бы больше по работе с железом. Например с портами. 4. Насчёт отладки. Я решил, что просто не разобрался. Но пока мне показалось, что отладка ещё хуже чем в D7. Ну она уже и там далеко не на высоте. Насколько я заблуждаюсь? Спасибо.
|
|
|
|
|
|
|
|
Jun 9 2011, 07:26
|
Adept
Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343
|
Цитата(SasaVitebsk @ Jun 9 2011, 13:16) 1 - я уже понял в полном объёме. И вот тут у меня несколько вопросов. Надо ли вообще дизайнер? Или единожды делаешь размещение и лучше больше к нему не возвращаться? Он там хидер генерит автоматически и в случае изменений, соответственно его херит. Так есть вариант просто использовать другой хидер, взявши генерируемый за основу. Вообще, имхо, нужен. Иногда надо разместить виджеты на форме и визуальный режим тут очень кстати. Но это, в общем-то, и всё. Не нужно от дизайнера хотеть кодогенерации, код лучше писать самому. С него достаточно того, что он позволяет настроить геометрию графических объектов - делать это в коде менее удобно, т.к. обычно приходится делать несколько итераций, чтобы добиться приемлемого вида. Сам дизайнер держит всю информацию об объектах на форме в .ui файле. Он также генерит заголовок ui_xxx.h и может вставлять код (слоты в основном) при команде "Перейти к слоту...". Заголовок ui_xxx.h руками править не надо. Цитата(SasaVitebsk @ Jun 9 2011, 13:16) )) Не пинайте больно - я ещё сквозную идею не ухватил пакета. В дельфях форма менялась по ходу написания неоднократно. Часто так и писалось. Накидал компонентов - обработал, накидал ещё. Ну, и тут так же. Только тут нет на форме невизуальных компонентов. Тут форма - это чисто для создания внешнего вида. Это у Борланда форма частично использовалась в качестве инструмента кодогенерации - можно было создавать объекты и подключать их к работе прямо мышкой. Потому оно и RAD система. А тут всё традиционно. По большому счёту это правильно, хотя после той расслабухи немного ломает. Цитата(SasaVitebsk @ Jun 9 2011, 13:16) Только мне слик не нравится. Вопрос: Зачем среду сборки менять??? Насчёт слика - это вы зря. Систему сборки я хочу менять потому, что меня тошнит от make и makefiles. Наелся этого. Давно юзаю SCons и очень этим доволен. Вот и хочу поднять сборку на его основе. Закончу этот проектик и попробую перетащить. В принципе, на SConc'е руление опциями проекта будет почти таким же, как и в их .pro файле. Цитата(SasaVitebsk @ Jun 9 2011, 13:16) И ещё один вопрос. В одном случае добился (!!) что абсолютно правильный проект вызывал ошибку при сборке. Причём ошибку VS почему-то. С предложением отослать )). Насколько сам пакет устойчиво работает??? У меня бывали падения a-la Segmentaion Fault, но во всех случаях сам был дурак. Как правило к этому приводят ошибки работы с памятью. Тут надо быть аккуратным. И иметь в виду, что ни один виджет не должен создаваться до инициализации приложения (создания объекта QApplication). Иначе работать не будет, а будут только неприятности в виде падений и глюков. Такая там идеология, надо быть в рамках. Цитата(SasaVitebsk @ Jun 9 2011, 13:16) 3. SQL пока не нужен, но не исключаю естественно. Мне бы больше по работе с железом. Например с портами. С портами не привелось пока работать. Но думаю, что принципиальных проблем тут быть не должно. Допускаю, что какие-то вопросы возникнут, но это всё обычные рабочие моменты. Цитата(SasaVitebsk @ Jun 9 2011, 13:16) 4. Насчёт отладки. Я решил, что просто не разобрался. Но пока мне показалось, что отладка ещё хуже чем в D7. Ну она уже и там далеко не на высоте. Насколько я заблуждаюсь? Отладчик там убогий. Он очень тормозной и весьма глючный. Мне сказали, что он портирован с линуха и там он работает не в пример лучше. В принципе, сам-то дебаггер там - это GDB, а в оболочка предоставляет только фронт-энд к нему. Фронт-энды к GDB есть и другие, и получше. Слик, кстати, тоже умеет быть фронт-эндом к GDB. Люди, которые пробовали эту связку, отзывались очень похвально (знаю такого человека лично). Когда я переползу на свою среду (слик+сконс), тоже попробую.
--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
|
|
|
|
|
|
|
|
Jun 9 2011, 09:34
|
фанат дивана
Группа: Свой
Сообщений: 3 387
Регистрация: 9-08-07
Из: Уфа
Пользователь №: 29 684
|
Цитата(zltigo @ Jun 9 2011, 14:52) Им кажется, что знают, и даже собаку съели, хотя едва-ли каждый сотый из дельфийских "программистов" приступил к этой закуске. Думаете, среди QT-программистов процент грамотных сильно выше? Сомневаюсь. Ну пусть даже немножко повыше, пусть не каждый сотый, а каждый 20й. В любом случае, в абсолютных числах грамотных дельфи-программистов значительно больше Цитата(AlexandrY @ Jun 9 2011, 14:58) Сегодня только получил рассылку от Embarcadero. Я поначалу испугался, когда узнал о продаже дельфей Embarcadero. Теперь вижу, что они молодцы, всё делают грамотно, может даже грамотнее чем Борланд.
--------------------
Если бы я знал, что такое электричество...
|
|
|
|
|
|
|
|
Jun 9 2011, 13:57
|
Гуру
Группа: Свой
Сообщений: 2 712
Регистрация: 28-11-05
Из: Беларусь, Витебск, Строителей 18-4-220
Пользователь №: 11 521
|
Я извиняюсь, просто загромождать не хотел.
Не надо мешать всё в кучу.
От D7 просто пора уходить. Это я не хочу обсуждать. Причин я могу перечислить много. Уже довольно много пошло на ARM компов. Буки, к примеру. W8 решит проблему. А D7 кто перетранслирует? Уже указанные и не только мной, проблемы работы с разными языками. Выбор в России "национальной ОС". Хочешь не хочешь, но часть корпоративных компов перейдёт под Linux. У нас уже есть такие примеры. Газовики, в частности. А мы учётом газа, тепла и т.п. То есть кросплатформенность, в принципе понадобится. По крайней мере я так считаю. Пусть в одном случае из 50, от этого не легче.
Проблема текучки - не так проблематична. Проблематична низкая квалификация писателей, отсутствие общего подхода, отсутствие должного контроля. В этом смысле, C++ чуть более распологающий к порядку язык. Если бы всё решалось на уровне объектов, заимствовалось - документировалось, то было бы легче.
Понятно, что требуется человек, который определяет общую концепцию приложения, а только потом пишется это приложение. К сожалению, до сих пор писалось прямо на экране.
Приведу пример. Для выдачи команды в прибор, сейчас динамически создаётся отдельный поток и ставится в очередь потоков. Ну и поехало - в одном потоке - создаётся, в другом - уничтожается. Теперь где-то утечка памяти - найти программист не может. Координально менять - просто всё переписать надо. Приложение таково, что можно было бы создавать законченные объекты - тащить их из приложение в приложение и больше к этому не возвращаться.
===
Но и это я не хочу обсуждать. Я просто пытаюсь сорентироваться на перспективу. Для того, чтобы наметить работы на будущее.
Я рассматриваю и RAD. Но пока никто не описал преимуществ. А денег он стоит. А перспективы его - не менее туманны.
===
Облачные технологии нам не к чему пока. Насколько я понимаю. Как и VBA. Мы не офисные пакеты пишем, а пакеты привязанные к нашему железу.
|
|
|
|
|
|
|
|
Jun 9 2011, 15:57
|
Ally
Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050
|
Цитата(SasaVitebsk @ Jun 9 2011, 16:57) ===
Но и это я не хочу обсуждать. Я просто пытаюсь сорентироваться на перспективу. Для того, чтобы наметить работы на будущее.
Я рассматриваю и RAD. Но пока никто не описал преимуществ. А денег он стоит. А перспективы его - не менее туманны.
===
Облачные технологии нам не к чему пока. Насколько я понимаю. Как и VBA. Мы не офисные пакеты пишем, а пакеты привязанные к нашему железу. Ну вы прям описали жуткое будущее.  В том и проблема, что это не будущее, а прошлое. Это в прошлом остается когда для 5% юзеров почему-то вцепившихся в линуксы надо было ломать голову как сделать им достойную прогу. Проблема уже решена для любителей халявного и низко бюджетного софта. Это перенос софта в облака. Уже все кому не лень бросились делать учет электроэнергии и всех других счетчиков прямо в инете. И Digi, и Microchip, и GE и еще куча монстров. Глазом не успеете моргнуть как ваши решения для десктопов станут бесполезны. Либо вас легко обойдут конкуренты тока намекнувшие, что у них все нахаляву и прямо щас и с любого мобильного дивайса. Да, национальная платформа, а почему национальная не поняли? Потому что будет централизовано на государственных серверах, а юзеры просто превратятся в удаленные терминалы. И QT уже не поможет!
|
|
|
|
|
|
|
|
Jun 10 2011, 04:18
|
Профессионал
Группа: Свой
Сообщений: 1 003
Регистрация: 20-01-05
Пользователь №: 2 072
|
Цитата(Konst_777 @ Jun 9 2011, 18:59) Спасибо за ссылку на кроссплатформенную, бесплатную и, судя по Вашему рассказу, достойную замену Delphi  Вполне приемлемая замена Delphi. Не все гладко, конечно, но непреодолимых препятствий нет. Цитата(AHTOXA @ Jun 9 2011, 13:34) Думаете, среди QT-программистов процент грамотных сильно выше? Сомневаюсь. Согласен, приходилось просматривать несколько крупных (до сотни форм) проектов. Видно, что QT ребята знают хорошо, но качество собственного кода крайне низкое.
|
|
|
|
|
|
|
|
Jun 10 2011, 05:58
|
Гуру
Группа: Свой
Сообщений: 2 712
Регистрация: 28-11-05
Из: Беларусь, Витебск, Строителей 18-4-220
Пользователь №: 11 521
|
Цитата(AlexandrY @ Jun 9 2011, 18:57) Уже все кому не лень бросились делать учет электроэнергии и всех других счетчиков прямо в инете. И Digi, и Microchip, и GE и еще куча монстров. Глазом не успеете моргнуть как ваши решения для десктопов станут бесполезны. Либо вас легко обойдут конкуренты тока намекнувшие, что у них все нахаляву и прямо щас и с любого мобильного дивайса. Да, национальная платформа, а почему национальная не поняли? Потому что будет централизовано на государственных серверах, а юзеры просто превратятся в удаленные терминалы. И QT уже не поможет! Если честно, я не совсем понимаю каким боком тут "Digi, и Microchip, и GE". И чем они могут помочь при установке сартифицированных счётчиков или тепловычислителей.  Поверьте - всё решается на несколько другом уровне. И сейчас различных прог достаточно. Плюс огромное количество SCADA. В некоторые мы интегрировали свои приборы (бесплатно) и что? Непойму. У нас есть и платные проги - и люди их покупают. Так как западные - тоже не бесплатные. Но даже если всё это ляжет - и что? Корпорация Microchip не напишет за нас программу, которая будет работать с нашим прибором. Ни в облаках не на земле. Ей это просто не надо. Свою мы поставляем бесплатно. Китайцы бы нас давно задавили, да только их не интересует серийность в несколько сот штук. И в несколько тысяч тоже. Учитывая наше чиновничество и метрологию. Сейчас делали подтверждение сертификата, тянется хрен сколько. За это время один новый гост вышел и один изменили. Уже 5 раз переделывали. У кого нервы выдержат, при такой прибыльности?
|
|
|
|
|
|
|
|
Jun 10 2011, 07:11
|
Ally
Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050
|
Цитата(SasaVitebsk @ Jun 10 2011, 08:58) Если честно, я не совсем понимаю каким боком тут "Digi, и Microchip, и GE". А при том, что по ним можно установить куда дует ветер. А ветер дует таким образом, что если счетчики не получат сетевых интерфейсов, то даже сотню будет трудно продать скоро. Время платных программ для отрасли AMR кончается. Если вы делаете нишевые продукты с маленькими тиражами, то тем более странно, что вы фокусируетесь на клиентах с линукс платформами, а не решаете проблему разом переходом на WEB интерфейсы и достигая таким образом абсолютной кросплатформенности.
|
|
|
|
|
|
|
|
Jun 10 2011, 08:36
|
Знающий
Группа: Участник
Сообщений: 783
Регистрация: 22-11-08
Пользователь №: 41 858
|
Цитата(AlexandrY @ Jun 10 2011, 11:11) А ветер дует таким образом, что если счетчики не получат сетевых интерфейсов, то даже сотню будет трудно продать скоро. Вы немного не в курсе как строятся системы коммерческого учета - в счетчиках сетевые устройства и веб-интерфейс нафик не нужны - ставятся УСПД (устройства сбора и передачи данных) а на их основе стрится система любой сложности. Во первых данные по потреблению ЭЭ - конфиденциальны, перепрограамировать счетчики на работающей системе нельзя, стоить такой счетчик будет при этом намного дороже. Там достаточно rs-485/422 - в крайнем случае модем для беспроводного доступа. Цитата Если вы делаете нишевые продукты с маленькими тиражами, то тем более странно, что вы фокусируетесь на клиентах с линукс платформами, а не решаете проблему разом переходом на WEB интерфейсы и достигая таким образом абсолютной кросплатформенности. Ерунда полная - QT к Linux имеет такое же отношение как и Nokia т.е. никакого - это кроссплатформенная библиотека.
|
|
|
|
|
|
|
|
Jun 10 2011, 09:21
|
Гуру
Группа: Свой
Сообщений: 2 712
Регистрация: 28-11-05
Из: Беларусь, Витебск, Строителей 18-4-220
Пользователь №: 11 521
|
К сказанному sasamy, добавлю следующее. Наличие и тип интерфейса - ничего не меняет. Абсолютно. В ближайшем же приборе появится ethernet и что это изменит? Цитата(AlexandrY @ Jun 10 2011, 10:11) Время платных программ для отрасли AMR кончается. Поясните. Почему? Я ещё раз повторяю. Существуют программы как зарубежные так и российские. Здесь уже нечего выдумывать. Любая SCADA решает поставленную задачу. Только они громоздки, дороги, а настройка их под конкретное предприятие обойдётся в очень приличную сумму денег. Это очень эффективное решение для крупного предприятия. Но не для мелкого. Для мелкого легче поставить нашу прогу.
|
|
|
|
|
|
|
|
Dec 20 2011, 06:19
|
;
Группа: Участник
Сообщений: 5 646
Регистрация: 1-08-07
Пользователь №: 29 509
|
Цитата(Виктория @ Dec 6 2011, 16:54) Lazarus не пашет, у него скромные возможности (года три назад эту тему изучали...может все кардинально изменилось?) Три года - это целая эпоха. Поинтересуйтесь еще. С 12+ мегабайтовыми ехешниками бороться можно, пересобрав среду. Возни поболее, чем с дельфи, конечно, но оттуда можно надергать оч много полезных сорцов. А вообще-то главное - это развитие FPC. Цитата(Виктория @ Dec 19 2011, 11:14) в качестве инструментальной среды проектирования верхнего уровня OpenWatcom Думается, что ГЦЦ всегда будет лучше ваткома.
Сообщение отредактировал _Pasha - Dec 20 2011, 06:22
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
