Занимаемся различной электроникой. Сопутствующие програмки для PC до этого писали под Delfi. Понятно, что тема себя изжила.
Подыскиваем новый пакет для дальнейшей деятельности.
RAD студия выглядит как-то оторвано от общего потока.
VS кажется слишком монстрообразной. Текучка программистов значительная и боимся сложностей с поддержкой написанных пакетов.
Скачал и установил QT (QT Creator). Вроде выглядит привлекательно. Поддерживается, развивается. Локализация русская. Много примеров. Форумы. Бесплатная.

Кто поделится своими наблюдениями. Посоветует. Замечания.
Заранее благодарю.

Все "cопутствующие програмки для PC " написанные еще на D2, прекрасно дышат под любой NT, включая w7.
В трехстах килобайтах несут все самое необходимое, включая VCL.
Запустил и работает...
Или хочется потрахаццо с луниксами, дот NET-ами и другими монстроидальными жабообразностями?
Хочется на каждом клиентском компе толстый интернет для обновления этой байды/поиска старых версий для отката?
Есть положительный опыт юзания новых сред от некрочипа и атмел?

Разъясните подробней насчет "тема себя изжила".
Непонятно

Присоединяюсь.
Для "сопутствующих программок" мне прекрасно хватает D7, более новые версии только медленнее работают и делают намного более крупные EXE. И не надо грузить в систему всякие дополнительные вещи, в EXE всё есть. А если новый профессиональный программист не может прочесть код на Delphi, то он не очень-то профессионален.

Есть два направления для RAD. Если нравятся плюсы, то QTCreator в руки, если шарп, то студия(она хоть и монстр но у нее столько плюшек, которые ускоряют написание). Студию сожно заменить на SharpDevelop или Monodevelop. Никаких проблем у клиентов это не вызывает. Затачивание ПО под mono фреймворк позволит без гемора запускать программу как под вин так и лин. В большинстве случаев простое ПО под .net и без допиливания запускается под mono.
С некрочипом дела не имел. Под атмел пишу в codeblocks.


делфи давно подох и разложился

Запахло священной войной...

Вместе с борландом

В общем, это как пикад. Смысл оставлять (а тем более покупать за деньги) есть только для поддержания большого количества "нажитого непосильным трудом".

Сорри за лирическое отступление.
По теме:
Если "Сопутствующие програмки для PC" предполагаются чисто под винду, то и среду разработки логично взять родную - MSVS.
Если подразумевается кроссплатформенность - тогда ориентация на C#/Mono, GTK, Qt.
Кстати, насчёт "бесплатности" Qt - это ещё большой вопрос.
Пока лицензия LGPL, но ввиду планомерного подминания Nokia (владельца прав) под MS возможны варианты.

Какие именно сопутствующие программы обсуждаются? Ну какая область применения?

Ну будет как с жадным до бабала Ораклом, который очень хотел "монетизировать" OpenOffice. Часть ядра разработчиков ушла и организовала форк LibreOffice, котрый сразу заменил ОО во многих линуксовах дистрах. Оракл какое-то время делал хорошую мину при плохой игре и не хотел отдавать никому бренд OpenOffice, а потом сломался и отдал весь ОО Apache. "Монетизация" из-за LibreOffice с треском провалилась.

если нужно все-в-одном, беспроблемная кроссплатформенность, наличие мощных средств разработки и кучи бесплатных библиотек, можете посмотреть на Java/Scala

Программисты (за исключением одного) работают и с железом и с ПО для PC. Собственно и сам так. Работа там в С и здесь с D7 - мягко говоря напрягает. Да и смысла не вижу. Уход в билдер координально не решает проблему. Не собираюсь спорить, ну думаю что большинству очевидно. Сам D7 сейчас уже не поддерживается и не отвечает текущим требованиям.
Приложения пишем - обычные для таких контор. Сервисные пакеты для своих приборов. Удалённый съём данных с приборов. Хранение и обработка результатов, генераторы отчётов. Объединение в сеть. Обслуживание стендов и так далее. Короче интерфейс пользователя + работа с изделиями 232/485/ethernet.
По поводу кроссплатформенности - раньше (естественно) вопросы не возникали. В текущий момент - приходится подумывать. То есть если есть такая возможность, то я думаю это всё же плюс. Хотябы имиджевый.
Я пока не принял решение - именно по этому к Вам и обращаюсь. Хочется услышать разные мнения. Очень бы хотелось послушать тех, кто пытается применять другие пакеты в рамках небольшой конторы. Плюсы и минусы.


Как раз по D7 координальных вопросов не возникает. Хотя тоже ... Боимся, что такие проблемы пойдут с переходом на MSVS.
По D7 тоже не всё гладко. Приходит новый программист. Пол года въезжает в тему. Потом год чёто правит, ругая попутно всё то, что написали предыдущие, потом уходит... Ну и так далее... )) Написанный крупный проект сервер-арм писался уже 4-5 программерами и представляет собой безсистемную сборку их творений. Иногда начинает тихо ехать крыша. Там исправишь - тут вылазит. ))

Это от среды разработки никак не зависит

Сам раньше писал всё на дельфи. Потом начало раздражать - дельфи тут, С в МК. В итоге перешел на Qt, правда связь только через RS-232 (последнее время через USB мост).

+1 за Java+Eclipse в качестве среды разработки.

А я вот по ряду причин никогда не пользовался поддержкой Delphi...
Не в порядке спора, а для себя интересно: чего Вам не хватает в Delphi 7 для Ваших задач?

А когда тут Delphi, а там VHDL - вообще! Особенно после 23 часов вспоминать, где какой синтаксис оператора case...

Разных готовых компонентов для Delphi по прежнему больше чем для VS. Соответственно на Delphi можно по прежнему быстрее написать крутую визуальную прогу чем в VS, за исключением облачных апликаций.

Но MS планирует в облаках полностью запускать весь MS Office. И тут интересный вариант был бы Visual Basic вернее VBA.
Приложения с VBA на базе Excel или Access смотрятся очень мощно и пишутся в лет.
Написанное на VBA имеет шанс без изменений быть портированным в облака и сильно упростить размещение и тех.поддержку софта для клиентов.

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

Касательно языка и кросплатформенности - если есть время, то можете поэкспериментировать. В нашей конторе исторически использовались три языка: С,C++ и Delphi. К программистам нареканий не было, но стыковка разных модулей отнимала время и средства. В итоге было решено сделать три проекта на С++ и три на Delphi. Во всех случаях было требование переносимости, оценивалось общее время разработки нормализованное по сложности задачи. Также сознательно в ТЗ не были внесены некоторые пункты, с целью оценить время внесения изменений. Библиотеки и инструментарий программисты могли выбирать сами (в пределах разумного конечно).

Итог был (для меня) неожиданный - победил lazarus.freepascal.org. Один из программистов был сильно недоволен, но не привел убедительной аргументации, а обещание уволиться не выполнил.

С инструментарием с доступным исходным кодом нужно быть осторожным - особо инициативные пытались использовать свои патчи к fpc, но это было запрещено административно.

Когда-то для разработки софта для РС (для внутренних нужд) пользовался Borland C++Builder. Потом, освоивши Python, многие вещи делал на нём. Но иногда встаёт необходимость именно в полноценном экзешнике с нативно исполняемым кодом. Развитие билдера не понравилось - в отличие от пятёрки, которая была проста, быстра и достаточно стабильна, последние версии выглядят монстроидально, громоздко и мутно.

Подыскивал замену, остановился на Qt. Сейчас лабаю небольшую программку для внутренних нужд. Навскидку могу сказать следующее:

1. Qt - это не RAD система. То, что там есть Designer, не делает его таковой. В отличии от дельфей и билдера, где можно было накидать на форму компонентов (в том числе и неграфических) и быстренько в полувизуальной манере запрограммировать поведение - евенты повесить, задать значение всех свойств по умолчанию и т.п., тут такие номера не проходят. На форму можно положить некоторые виджеты, но по большому счёту этим всё и ограничивается. Т.е. от дизайнера эффективно можно получить только геометрическое размещение виджетов и всё. Остальное - назначение событий, их обработка, инициализация и настройка - всё это делается руками в коде. Это не так удобно как борландовских продуктах, но склонен считать, что это более правильный подход, хотя он и требует глубже вникать в систему и разбираться с её потрохами. Поэтому Appication Development получается не такой уж и Rapid
   
2. Среда разработки Qt Creator (как и почти все среды) весьма отстойна. Да, там многие вещи делаются неплохо, но есть и масса неприятных мелочей, начиная от того, что курсор в редакторе прыгает по тексту при вертикальном перемещении в зависимости от конца строк и заканчивая тем, что нет удобного расположения редактируемых окошек в виде привычных по многим программам табов. Собираюсь со временем перелезть на свой любимый слик. Самое сложное тут - это переделать среду сборки под сконс, избавившись от make и, как следствие, их инструмента организации проекта qmake. Основное тут - это разобраться с moc (meta-object compiler).
   
3. Качество самого фреймворка в целом на высоте. Но отдельные программные его модули оставляют желать лучшего. Например, QtSQL не приходится рассматривать как полноценную библиотеку, целиком пригодную для написания сложных программ. Её слой драйверов и низкоровневого БД API вполне вменяемые, но вот про третий слой - прикладные модули (QSqlTableModel и подобные) этого сказать нельзя. В общем, нужно в каждом случае внимательно смотреть, на каком уровне выполнен прикладной модуль. Мнение обычно можно составить, читая посты на форумах - информации предостаточно. Правда, я сперва набил немного шишек на этом модуле, а потом уже накопал на форумах, что проблема не нова.
   
4. При организации всех классов Qt используется идеология на основе паттерна PImpl (Pointer to Private Implementation). Она имеет свои плюсы и минусы. Главное, для чего они её заюзали - поддержание бинарной совместимости (по крайней мере, в пределах мажорных номеров версий). Правда, мой опыт показал, что это в реале не работает, во всяком случае, не всегда - при переходе с версии 4.6.3 (а под неё мной руками были собраны драйвера для сервера MySQL) на крайнюю версию 4.7.3 программа отказалась вязаться с сервером. Пересборка драйверов порулила проблему.
   Ещё одно преимущество такого подхода - более быстрая загрузка программы. Программа действительно грузится и работает быстро. Но при отладке этот подход доставляет проблемы: несмотря на open source реализация потрохов видна не на всю глубину. И постоянно сталкиваться с кодом Q_D(class_name); и далее d->... - не добавляет комфорта. Разбираться с этим кодом сложнее, чем с написанным явно, т.к. приходится искать определения этой приватной имплементации.
   
5. Бесплатная лицензия имеет некоторые ограничения. В частности, в ней не предусмотрена сборка статической версии программы, чтобы получить самодостаточный экзешник. Поэтому придётся тащить как миниум один или два рантаймных модулей библиотек - QtCore, QtGui. Цена вопроса - 12 мегов.

В целом, фреймворк достойный. Реальной альтернативы я ему не вижу. Конечно, для эффективной работы с ним придётся изрядно погнуть моск под его подходы: например, повсеместно используется new для создания объектов и очень редко можно увидеть delete - там широко применяется подход через удаление объектов в деструкторе предка, поэтому в каждом объекте виджета в конструкторе есть аргументом указатель на предка QObject *parent; или, скажем, строго заданная схема создания объектов-виджетов, при которой все объекты-виджеты создаются не в конструкторах, а уже во время запуска самой программы, т.е. после старта main().

Пристальное внимание надо уделить таким аспектам, как передача сообщений по схеме signal/slot, event'ам и event filter'ам. Это базовые вещи, без хорошего понимания которых, более-менее серьёзную программу не создать.

В общем, не всё там так просто и безпроблемно, но если готовы потратить силы и время на освоение, то дело это считаю достойным. Сам в процессе.

Ну, например, простой пример. Симуляторы разные. Где желательно полный перенос текста программы.

2 dxp. Огромное спасибо за развёрнутый ответ. Тем более что ваши знания в плюсах на голову больше моих.
Я ковыряюсь недели 2-3. Тем не менее по пунктам ...
1 - я уже понял в полном объёме. И вот тут у меня несколько вопросов. Надо ли вообще дизайнер? Или единожды делаешь размещение и лучше больше к нему не возвращаться? Он там хидер генерит автоматически и в случае изменений, соответственно его херит. Так есть вариант просто использовать другой хидер, взявши генерируемый за основу.
)) Не пинайте больно - я ещё сквозную идею не ухватил пакета. В дельфях форма менялась по ходу написания неоднократно. Часто так и писалось. Накидал компонентов - обработал, накидал ещё.
2. Тоже почти согласен. Особенно TAB убивает. Хотя остальное вполне понравилось. Особенно замена "." на "->" очень удобно. ))
Только мне слик не нравится. Вопрос: Зачем среду сборки менять???
И ещё один вопрос. В одном случае добился (!!) что абсолютно правильный проект вызывал ошибку при сборке. Причём ошибку VS почему-то. С предложением отослать )). Насколько сам пакет устойчиво работает???
3. SQL пока не нужен, но не исключаю естественно. Мне бы больше по работе с железом. Например с портами.
4. Насчёт отладки. Я решил, что просто не разобрался. Но пока мне показалось, что отладка ещё хуже чем в D7. Ну она уже и там далеко не на высоте. Насколько я заблуждаюсь?

Спасибо.

Вообще, имхо, нужен. Иногда надо разместить виджеты на форме и визуальный режим тут очень кстати. Но это, в общем-то, и всё. Не нужно от дизайнера хотеть кодогенерации, код лучше писать самому. С него достаточно того, что он позволяет настроить геометрию графических объектов - делать это в коде менее удобно, т.к. обычно приходится делать несколько итераций, чтобы добиться приемлемого вида.

Сам дизайнер держит всю информацию об объектах на форме в .ui файле. Он также генерит заголовок ui_xxx.h и может вставлять код (слоты в основном) при команде "Перейти к слоту...". Заголовок ui_xxx.h руками править не надо.


Ну, и тут так же. Только тут нет на форме невизуальных компонентов. Тут форма - это чисто для создания внешнего вида. Это у Борланда форма частично использовалась в качестве инструмента кодогенерации - можно было создавать объекты и подключать их к работе прямо мышкой. Потому оно и RAD система. А тут всё традиционно. По большому счёту это правильно, хотя после той расслабухи немного ломает.


Насчёт слика - это вы зря. Систему сборки я хочу менять потому, что меня тошнит от make и makefiles. Наелся этого. Давно юзаю SCons и очень этим доволен. Вот и хочу поднять сборку на его основе. Закончу этот проектик и попробую перетащить. В принципе, на SConc'е руление опциями проекта будет почти таким же, как и в их .pro файле.


У меня бывали падения a-la Segmentaion Fault, но во всех случаях сам был дурак. Как правило к этому приводят ошибки работы с памятью. Тут надо быть аккуратным. И иметь в виду, что ни один виджет не должен создаваться до инициализации приложения (создания объекта QApplication). Иначе работать не будет, а будут только неприятности в виде падений и глюков. Такая там идеология, надо быть в рамках.


С портами не привелось пока работать. Но думаю, что принципиальных проблем тут быть не должно. Допускаю, что какие-то вопросы возникнут, но это всё обычные рабочие моменты.


Отладчик там убогий. Он очень тормозной и весьма глючный. Мне сказали, что он портирован с линуха и там он работает не в пример лучше.

В принципе, сам-то дебаггер там - это GDB, а в оболочка предоставляет только фронт-энд к нему. Фронт-энды к GDB есть и другие, и получше. Слик, кстати, тоже умеет быть фронт-эндом к GDB. Люди, которые пробовали эту связку, отзывались очень похвально (знаю такого человека лично). Когда я переползу на свою среду (слик+сконс), тоже попробую.

Да уж. Отличный способ побороть текучку программистов - перейти с дельфей, которые знает практически каждый второй, на QT, который знаком очень немногим. Текучка от этого точно прекратится, все сбегут, и всё

Сначала надо перейти с дельфей на си-плюс-плюс, а потом уже на кути.

Им кажется, что знают, и даже собаку съели, хотя едва-ли каждый сотый из дельфийских "программистов" приступил к этой закуске. Это к сожалению порождает чрезмерно часто и удручающие качество продукта и ту самую "текучку" - наваяли что-то по быстрому и рванули лепить следующее

Сегодня только получил рассылку от Embarcadero. Оказывается у них уже есть продукт для создания облачных приложений - Embarcadero Delphi Prism XE
И на нем можно программировать даже айфоны.

После этого, конечно всякие QT идут в топку.
Хотя в течении обсуждения я не уловил причин почему при таких недостатках QT удостоился вообще какого-то внимания.

Каких недостатков?

Думаете, среди QT-программистов процент грамотных сильно выше? Сомневаюсь. Ну пусть даже немножко повыше, пусть не каждый сотый, а каждый 20й. В любом случае, в абсолютных числах грамотных дельфи-программистов значительно больше



Я поначалу испугался, когда узнал о продаже дельфей Embarcadero. Теперь вижу, что они молодцы, всё делают грамотно, может даже грамотнее чем Борланд.

Да. C++ + Qt имеет более высокий порог вхождения. Исходя из этого шутки про делфи-"программистов" вполне уместны.

Потому я и написал - каждый двадцатый вместо каждого сотого. Результирующего соотношения это не меняет.

Я извиняюсь, просто загромождать не хотел.
Не надо мешать всё в кучу.
От D7 просто пора уходить. Это я не хочу обсуждать. Причин я могу перечислить много. Уже довольно много пошло на ARM компов. Буки, к примеру. W8 решит проблему. А D7 кто перетранслирует? Уже указанные и не только мной, проблемы работы с разными языками. Выбор в России "национальной ОС". Хочешь не хочешь, но часть корпоративных компов перейдёт под Linux. У нас уже есть такие примеры. Газовики, в частности. А мы учётом газа, тепла и т.п. То есть кросплатформенность, в принципе понадобится. По крайней мере я так считаю. Пусть в одном случае из 50, от этого не легче.
Проблема текучки - не так проблематична. Проблематична низкая квалификация писателей, отсутствие общего подхода, отсутствие должного контроля. В этом смысле, C++ чуть более распологающий к порядку язык. Если бы всё решалось на уровне объектов, заимствовалось - документировалось, то было бы легче.
Понятно, что требуется человек, который определяет общую концепцию приложения, а только потом пишется это приложение. К сожалению, до сих пор писалось прямо на экране.
Приведу пример. Для выдачи команды в прибор, сейчас динамически создаётся отдельный поток и ставится в очередь потоков. Ну и поехало - в одном потоке - создаётся, в другом - уничтожается. Теперь где-то утечка памяти - найти программист не может. Координально менять - просто всё переписать надо. Приложение таково, что можно было бы создавать законченные объекты - тащить их из приложение в приложение и больше к этому не возвращаться.
===
Но и это я не хочу обсуждать. Я просто пытаюсь сорентироваться на перспективу. Для того, чтобы наметить работы на будущее.
Я рассматриваю и RAD. Но пока никто не описал преимуществ. А денег он стоит. А перспективы его - не менее туманны.
===
Облачные технологии нам не к чему пока. Насколько я понимаю. Как и VBA. Мы не офисные пакеты пишем, а пакеты привязанные к нашему железу.

для решения этих проблем есть языки с встроенным сборщиком мусора, многозадачностью, и другими плюшками.

Спасибо за ссылку на кроссплатформенную, бесплатную и, судя по Вашему рассказу, достойную замену Delphi

Ну вы прям описали жуткое будущее.
В том и проблема, что это не будущее, а прошлое.
Это в прошлом остается когда для 5% юзеров почему-то вцепившихся в линуксы надо было ломать голову как сделать им достойную прогу.
Проблема уже решена для любителей халявного и низко бюджетного софта. Это перенос софта в облака.

Уже все кому не лень бросились делать учет электроэнергии и всех других счетчиков прямо в инете.
И Digi, и Microchip, и GE и еще куча монстров.

Глазом не успеете моргнуть как ваши решения для десктопов станут бесполезны.
Либо вас легко обойдут конкуренты тока намекнувшие, что у них все нахаляву и прямо щас и с любого мобильного дивайса.
Да, национальная платформа, а почему национальная не поняли? Потому что будет централизовано на государственных серверах, а юзеры просто превратятся в удаленные терминалы. И QT уже не поможет!

Вполне приемлемая замена Delphi. Не все гладко, конечно, но непреодолимых препятствий нет.


Согласен, приходилось просматривать несколько крупных (до сотни форм) проектов. Видно, что QT ребята знают хорошо, но качество собственного кода крайне низкое.

Если честно, я не совсем понимаю каким боком тут "Digi, и Microchip, и GE". И чем они могут помочь при установке сартифицированных счётчиков или тепловычислителей. Поверьте - всё решается на несколько другом уровне.
И сейчас различных прог достаточно. Плюс огромное количество SCADA. В некоторые мы интегрировали свои приборы (бесплатно) и что? Непойму.
У нас есть и платные проги - и люди их покупают. Так как западные - тоже не бесплатные. Но даже если всё это ляжет - и что? Корпорация Microchip не напишет за нас программу, которая будет работать с нашим прибором. Ни в облаках не на земле. Ей это просто не надо. Свою мы поставляем бесплатно.
Китайцы бы нас давно задавили, да только их не интересует серийность в несколько сот штук. И в несколько тысяч тоже. Учитывая наше чиновничество и метрологию. Сейчас делали подтверждение сертификата, тянется хрен сколько. За это время один новый гост вышел и один изменили. Уже 5 раз переделывали. У кого нервы выдержат, при такой прибыльности?

А при том, что по ним можно установить куда дует ветер.

А ветер дует таким образом, что если счетчики не получат сетевых интерфейсов, то даже сотню будет трудно продать скоро.
Время платных программ для отрасли AMR кончается.

Если вы делаете нишевые продукты с маленькими тиражами, то тем более странно, что вы фокусируетесь на клиентах с линукс платформами, а не решаете проблему разом переходом на WEB интерфейсы и достигая таким образом абсолютной кросплатформенности.

Вы немного не в курсе как строятся системы коммерческого учета - в счетчиках сетевые устройства и веб-интерфейс нафик не нужны - ставятся УСПД (устройства сбора и передачи данных) а на их основе стрится система любой сложности. Во первых данные по потреблению ЭЭ - конфиденциальны, перепрограамировать счетчики на работающей системе нельзя, стоить такой счетчик будет при этом намного дороже. Там достаточно rs-485/422 - в крайнем случае модем для беспроводного доступа.



Ерунда полная - QT к Linux имеет такое же отношение как и Nokia т.е. никакого - это кроссплатформенная библиотека.

К сказанному sasamy, добавлю следующее. Наличие и тип интерфейса - ничего не меняет. Абсолютно. В ближайшем же приборе появится ethernet и что это изменит?






Поясните. Почему?
Я ещё раз повторяю. Существуют программы как зарубежные так и российские. Здесь уже нечего выдумывать. Любая SCADA решает поставленную задачу. Только они громоздки, дороги, а настройка их под конкретное предприятие обойдётся в очень приличную сумму денег. Это очень эффективное решение для крупного предприятия. Но не для мелкого. Для мелкого легче поставить нашу прогу.

Никуда эти юзеры не денутся, а их количество будет только расти. Не слушайте Прянишникова (президент M$ в России), сказавшего, что Линукс заканчивается.

Поднимаю тему, если не наскучило...

Мне немножко непонятно. Может быть, потому что каждый говорит о своем.
Актуальность в моей конторе - официальное отсутствие поддержки Delphi 7 и лицензия на одно рабочее место. Поэтому также как и у автора топика поиск возможной замены.

Совсем непонятно, почему QT? Первый шаг это ведь все равно будет Minimalist Gnu... Но я не уверена, что я смогу использовать его в системах с железом (возьмем в качестве примера - платы от LCard...).
Lazarus не пашет, у него скромные возможности (года три назад эту тему изучали...может все кардинально изменилось?)

А если не работать с железом, то Excel+VBA вполне достаточно.


P.S.: флейм насчет кроссплатформенности - в прошлом году была во Франции, программерские фирмы рекламируют свои продукты тремя ярлычками Windowsским флажком, линуксовым пингвином и яблоком надкушенным. Офисное ПО вроде предлагалось при этом...

Согласен, что будущее за облаками.

А кто-нибудь из присутствующих использует в качестве инструментальной среды проектирования верхнего уровня OpenWatcom (http://www.openwatcom.org/index.php/Main_Page) ?

Заранее спасибо! Извинения за занудство, тема всё ещё актуальна

Три года - это целая эпоха. Поинтересуйтесь еще. С 12+ мегабайтовыми ехешниками бороться можно, пересобрав среду. Возни поболее, чем с дельфи, конечно, но оттуда можно надергать оч много полезных сорцов. А вообще-то главное - это развитие FPC.


Думается, что ГЦЦ всегда будет лучше ваткома.