С такой махровой демагогией спорить тяжело. Но кстати все эти ваши квоты и новые мигранты это одно из того, что делает экономику США такой сильно. А именно благодаря тому что выжимает из общества все что можно, даже самые маленькие меньшинства, и пытается их запихнуть в экономику, чтобы еще больше увеличить внутренние потребление и человеческий потенциал.
Ну любой банк обвалится, если к нему придут все вкладчики забирать деньги. Только чем банк больше, тем меньше вероятность этого. А для самой передовой экономики мира (с точки зрения технологий и человеческого капитала) эта вероятность близка к падению метеорита.
Ну и это в принципе самобалансирующаяся система. Инвесторы уходят, ставки растут, инвесторы приходят назад. Не говоря уже о том, что как показал опыт пандемии все ЦБ завязаны друг на друга, и не заинтересованы в падении друг друга. То есть падать некуда, потому как все в одной лодке.
Китай окончательно перешёл в разряд развитых стран
Ну прям-таки. А ничего что по ВВП по ППС на душу населения (единственный хоть чуть чуть объективный показатель благосостояния) Китай на 80 месте. Отставая даже от Беларуси, не говоря уже о России.
Нет никакой проблемы госдолга в США. Была "проблема" его быстрого роста, в результате массового печатанья денег в пандемию, чтобы не допустить схлопывания потребления (и соответственно спирали падения экономики). Хотя сам рост не проблема, проблема в том что по окончании пандемия возникла проблема дефицита уже производства (в частности из-за отложенного потребления), а это привело к инфляции (что как раз является проблемой). Но проблему инфляции сейчас решат просто сжиманием денежной массы (что собственно и происходит), экономика адаптируется и продолжит жить как раньше.
А сам госдолг (что США, что Китая) вообще особой роли не играет, он полностью управляем финансовыми институтами США, это всего лишь циферки в компьютере.
Все эти финансовые выкрутасы не так уж и важны. В конечном итоге финансовая система подстроится (также как и с госдолгом США).
Фундаментальная проблема Китая - ловушка средних доходов. Для дальнейшего роста Китая ему необходим рост потребления среднего класса (ну и прежде всего его создание), а следствием или причиной этого является создание гражданского общества, которое в свою очередь неизбежно создает политические риски. Собственно поэтому пока не помню случаев в истории, когда государство преодолевало ловушку средних доходов, не избавившись при этом от диктатуры. А именно туда сейчас движется Китай. Так что торможение его экономики в ближайшее десятилетие неизбежно.
Довольно странное решение. В сессии кешируются данные, данные могут быть переиспользованы, и это как бы хорошо. Если сессии начинают потреблять много памяти, уменьшаем лимиты памяти на сессии, либо оптимизируем код. Реинициализация сессий приводит к тому, что эффект от кеширования пропадает.
Проблема в том, что в Postgres похоже есть явная утечка памяти (во всяком случае при работе с временными таблицами и большом количестве разных сложных запросов). То есть долго существующие соединения при такой схеме постепенно подъедают память, пока не сожрут ее полностью. Это очень хорошо на графиках мониторинга видно (выключаешь перестарт соединений, линия потребления начинает постепенно уходить вниз до нуля, после чего здравствуй своп / oom killer и сервер БД ложится). Видимо поэтому существуют мифы, что Postgres не тянет больше 1к одновременных соединений и вообще без пулинга из очень малого количества соединений не может эффективно работать.
Ну и надо сказать, что при выборе соединений на перестарт используется сложная система скоринга (пытающаяся определить "зажравшиеся" соединения) и один из параметров это время жизни соединения, который все же старается не перестартовывать недолго существующие соединения, чтобы эффективно утилизировать использование их кэшей.
Не понял примера вашего с join'ом. Join это чистая композиция (например в lsFusion): habr.com/ru/company/lsfusion/blog/458376/#rest
Да в структурном программировании композиция проще и понятнее (так как оперирует функциями, а не таблицами), чем join. Но скажем цикл, разбиение или примитивная рекурсия в комбинаторном (SQL) проще.
В любом случае непонятно какое отношении это к ООП имеет. ООП это прежде всего про наследование и полиморфизм (ООП может быть как в структурном, так и в комбинаторном программировании), вы же рассуждаете про то, что SQL оперирует таблицами, а не функциями. Да это создает дополнительную accidental complexity, но опять-таки причем тут ООП?
Теперь бы еще поддержать рекурсии, наследование с полиморфизмом, сессии изменений, события, ограничения, логику представлений, и еще много чего и получится lsFusion.
Вы делаете слишком много домыслов. Лучше воздержаться от этого.
Рынок информационных систем он такой. Ни у кого нет общей картины, все сплошные обобщения личного опыта и гипотезы (просто потому что рынок очень большой и неоднородный)
Но большая часть кастомизации — это отчетики, печатные формы, АРМ и прочие простые вещи.
Давайте не смешивать. Отчетики и печатные формы в любой технологии достаточно несложная вещь. Я видел как люди к коробочным решениям на Oracle сбоку подключались и лепили там отчеты на CrystalReports. Порог входа при этом очень низкий в любой технологии. Плюс не забываем про навернутые BI, где пользователи много отчетов сами могут делать.
АРМам (а они ввод предполагают) как раз надо вот это вот все — управляемые формы, управляемые блокировки, как правильно условия для динамических списков писать и т.д. и т.п.
То есть про порог входа, это не личное мнение, а в том числе мнение многих 1С разработчиков, что та же УТ сейчас настолько сложной стало, что лезть туда уже мало кто хочет (а многие даже с 7.7 по этой причине не хотят уходить, так как она гораздо проще).
Скажем, у SAP есть большая фишка — интернациональность. На РФ точно могут работать все компании СНГ (ваши земляки из EPAM тому пример), а так же из любой страны Европы. Судить о квалификации всех 40+ партнеров в РФ не могу.
Ну по такой логике и Odoo превосходит 1С по числу разработчиков, только в РФ это им не так сильно помогает (хотя и помогает). Собственно SAP хороший пример, что на самом деле даже 40 партнеров (из которых наверное половина бутафорских) более чем достаточно.
По поводу количества автоматизированных рабочих мест, последнее, что я видел — это 80+% рабочих мест автоматизированы с помощью 1С.
В таких случаях обычно эти рабочие места выполняют самые примитивные процессы, а вся сложность и кастомизация все равно в том же SAP. Но например если взять Топ-30 розничных сетей, там большинство все же SAP и местные какие-то самописки.
По порогу вхождения надо смотреть больше не написание кода, а на решение типовых учетных задач. Та же 1С позволяет накидать простую рабочую систему практически без написания кода. Так же есть большой рынок обновлений и простых доработок, которые позволяют зайти в профессию с максимально легких задач (сам так начинал).
Не совсем понял. Все типовые же сейчас на УФ, управляемых блокировках и т.п. Чтобы там что-то дорабатывать нужно понимать «кто все эти люди». Даже если речь о простеньких отчетах, тот же СКД по сложности уже превосходит любую Reporting system, так как туда намешали дикое количество функционала (той же аналитики, которая обычно идет в отдельных контурах).
То есть чтобы ковыряться в том же УТ или БУХ сейчас, нужно иметь очень неслабый уровень интеллекта и опыта, а это как бы основные (самые распространенные) продукты у 1С.
Думаю, главная причина в создании такого рынка — это инфраструктура франчайзи в купе с тем, что решения 1С стали стандартом де-факто для SMB в РФ.
Хотя как правильно кто-то отмечал ниже, наверное самый простой способ победить 1С, получить распостранение на мировых рынках и сыграть на «чемоданческих настроениях». Во всяком случае по опыту, сейчас так Odoo двигается на российском рынке.
Одного десятка компаний точно не хватит. Если только вы планируете существовать на уровне пары сотен клиентов, из которых будет не более нескольких десятков действительно крупных.
Да ладно. У того же SAP наверное около одного или нескольких десятков компаний в России, которые реально могут его поддерживать (а не просто значатся в списке партнеров), а если взять количество сотрудников в компаниях, которые работают на SAP, то это количество будет соизмеримо с компаниями работающими на 1С. Ну и у самого 1С, насколько я видел топ-5 франчайзеров покрывают наверное минимум 30 процентов рынка (в Беларуси так точно такая ситуация).
Ну а про порог входа в 1С не шутит разве ленивый
Ну так это в 7.7 было. И то она гораздо менее декларативна чем тот же lsFusion была. А в 8.3 с их управляемыми блокировками, РеквизитамиФормыВЗначение, &НаСервереБезКонтекста, сотней всяких избыточных абстракций и т.п., порог входа уже выше чем в .Net или условный Python (Odoo).
А возможность наращивать ораву появилось скорее из-за того что они Бух и ЗУП консолидировали. Ну и да простота и бесплатность (пиратство) 7.7. помогли.
очень большие компании используют полностью кастомную разработку
Согласен, даже рынок полного custom made никто не отменял.
Т.е. нет риска оказать без кадров и возможности сопровождать решение.
Ну строго говоря для этого 100к разработчиков не надо. Одного десятка компаний сведет риск к минимальному, и на первое место выйдут уже первые два упомянутых вами фактора: качество платформы и TCO (затраты на покупку ОС, СУБД, платформу, оборудования и т.п.). Плюс важный момент — порог входа, если он очень низкий это даже может дать большие преимущества чем наличие большого количества специалистов (где их может быть много но все равно дефицит)
У нас вся инфраструктура на гитхабе (точнее сейчас туда документацию переносим, тогда точно будет вся). Но при этом нужно понимать, что, как я уже писал, баги у нас имеют наивысший приоритет, то есть мы их фиксим сразу когда их нам сообщают / мы обнаруживаем, поэтому часто задачи создаются уже постфактум.
Вы же понимаете, что бизнесу фиолетово коробочное решение или нет. Ему нужно решить свои проблемы (то есть получить ИТ-систему которая будет эффективно автоматизировать именно его процессы, как текущие так и будущие) быстро / дешево / с минимальными рисками. А будет это 100% коробочное решение, 60% коробочное 40% доработки, или 100% разработки, уже дело десятое. Если опять-таки устроит бизнес по срокам и стоимости (так например некоторые бизнесы готовы ждать, некоторые нет и т.п.)
Я знаю что такое расширения и упоминал несколько раз в своих статьях.
Нужно понимать, что:
а) во-первых, расширения это частный случай модульности, когда у вас основное решение — один модуль, а расширение — еще один модуль зависящий от этого модуля. Поэтому в идеальной системе должна быть не только возможность добавлять свои модули, но и выключать существующие модули и / или выбирать между ними.
б) в императивных языках возможности расширений очень ограничены (тут я писал об этом). Критически важно уметь расширять запросы, иметь событийную архитектуру, полиморфизм и т.п. (вот тут я приводил примеры этой проблематики и человек мне так ничего и не ответил на них)
И если бы вы чуть больше погрузились в lsFusion, то поняли бы что в плане расширений / модульности lsFusion превосходит существующие технологии на порядок. Впрочем, естественно, никто не мешает вам «подождать на берегу», пока время подтвердит или опровергнет этот тезис :)
В этом и фокус, что по опыту в настолько высокодекларативной среде как lsFusion, такие ошибки не возникают. Проверено опытом (при том что у нас у многих клиентов по 5 доработок в день и ежедневные обновления).
Подождите, важная часть SaaS это multi-tenancy, а если есть доработки (где с multi-tenancy очень много вопрос), то это чистый PaaS и скорее ближе к хостингу. Ну и собственно весь смысл в SaaS это отсутствии тесного контакта с клиентом (в том числе, например, за счет интуитивности интерфейсов и всяческих подсказок), а доработки это как раз классическая модель рынка бизнес-приложений.
И как бы 1С не развивали технологию расширений, но когда все сделано на SQL запросах, но при этом жестко императивно в строках без оптимизатора, когда нет полиморфизма, эти расширения по определению будут очень ограниченными (собственно такая проблема с модульностью яркий тому пример). Уж точно далеко для подходов используемых в lsFusion.
А средний бизнес это какой? Вот у нас сейчас основные клиенты это компании с 4-10к сотрудников и 200-500 млнов долларов в год оборотами. И основное что мы им продаем это как раз то что я писал в этом комментарии. То есть набор модулей из которых собирается решение, но что главное непрерывную реализацию всех хотелок с космической скоростью без накапливания технического долга (собственно у нас по сути на этом рынке в этом плане непонятно кто вообще конкуренты, потому как вести столько проектов одновременно в agile практически никто не может). Сейчас у нас процентов 70 крупного ритейла Беларуси и я думаю в течении ближайших 5-10 лет мы еще больше увеличим эту долю. И все это на мой взгляд именно благодаря платформе (всем этим 30 пунктам этой статьи). Это достаточно уникальное value который мало кто на рынке может предложить.
А рынок готовых решений судя по оборотам в ЕГРЮЛ соответствующих компаний (и общению с ними) наоборот сильно сужается, так как большинство как-то уже автоматизированы и на самом деле по опыту единственный вариант им что-то внедрить, это: внедрить as is с непрерывной интеграцией, после чего превратить в to be из смеси а) того что есть у тебя, б) то что всегда хотел заказчик, но у него не было, в) оставить то что есть, что себя уже зарекомендовало. Ну а дальше непрерывный цикл доработок по agile в рамках новых идей / изменений бизнеса и т.п.
У вас почему-то две крайности получается. Либо коробка (причем без модульности у вас может быть много лишних данных и проверок, которые придется заполнять или которые просто будут убивать эргономичность), либо разработка с нуля. Хотя очевидно, что идеальное решение это крупноблочное строительство с доработкой отдельных блоков и разработкой недостающих. И модульность с возможностями рефакторинга / быстрой и простой разработки тут выходят на первый план.
Я думал мы с другими электромобилями сравниваем. Ок тогда все это плюс разгон за 4 секунды, без передач и вообще трущихся частей (то есть гораздо меньше обслуживания надо), с очень крутой безопасностью (нельзя перевернуть, двигатель в салон не уедет), бесшумность, экологичность, возможность заправлять ночью (пусть и очень долго).
Как будто другие компании не выпускали «спорные» с дизайнерской точки зрения машины.
Кстати именно такие нет. Но опять-таки я тут все вместе сравнивал.
Фейсбук делал совершенно новый продукт. Рынок соц. сетей с ним только появлялся. Кто-то думает что сейчас может появится другой фейсбук?
Я про пирамиду и финпоказатели. Но вообще уже появлялись другие фейсбуки — инстаграмм, твиттер, ютуб, тикток, вот сейчас клабхаус например.
Но в отличии от ракет, в автомобилях такой революции не свершилось.
То есть переход с бензина на электричество (и скажем зарядка автомобилей дома по ночам) — это не революция? Ну ок.
О, трамписты-популисты на марше.
С такой махровой демагогией спорить тяжело. Но кстати все эти ваши квоты и новые мигранты это одно из того, что делает экономику США такой сильно. А именно благодаря тому что выжимает из общества все что можно, даже самые маленькие меньшинства, и пытается их запихнуть в экономику, чтобы еще больше увеличить внутренние потребление и человеческий потенциал.
Ну любой банк обвалится, если к нему придут все вкладчики забирать деньги. Только чем банк больше, тем меньше вероятность этого. А для самой передовой экономики мира (с точки зрения технологий и человеческого капитала) эта вероятность близка к падению метеорита.
Ну и это в принципе самобалансирующаяся система. Инвесторы уходят, ставки растут, инвесторы приходят назад. Не говоря уже о том, что как показал опыт пандемии все ЦБ завязаны друг на друга, и не заинтересованы в падении друг друга. То есть падать некуда, потому как все в одной лодке.
Китай окончательно перешёл в разряд развитых странНу прям-таки. А ничего что по ВВП по ППС на душу населения (единственный хоть чуть чуть объективный показатель благосостояния) Китай на 80 месте. Отставая даже от Беларуси, не говоря уже о России.
Нет никакой проблемы госдолга в США. Была "проблема" его быстрого роста, в результате массового печатанья денег в пандемию, чтобы не допустить схлопывания потребления (и соответственно спирали падения экономики). Хотя сам рост не проблема, проблема в том что по окончании пандемия возникла проблема дефицита уже производства (в частности из-за отложенного потребления), а это привело к инфляции (что как раз является проблемой). Но проблему инфляции сейчас решат просто сжиманием денежной массы (что собственно и происходит), экономика адаптируется и продолжит жить как раньше.
А сам госдолг (что США, что Китая) вообще особой роли не играет, он полностью управляем финансовыми институтами США, это всего лишь циферки в компьютере.
Все эти финансовые выкрутасы не так уж и важны. В конечном итоге финансовая система подстроится (также как и с госдолгом США).
Фундаментальная проблема Китая - ловушка средних доходов. Для дальнейшего роста Китая ему необходим рост потребления среднего класса (ну и прежде всего его создание), а следствием или причиной этого является создание гражданского общества, которое в свою очередь неизбежно создает политические риски. Собственно поэтому пока не помню случаев в истории, когда государство преодолевало ловушку средних доходов, не избавившись при этом от диктатуры. А именно туда сейчас движется Китай. Так что торможение его экономики в ближайшее десятилетие неизбежно.
Проблема в том, что в Postgres похоже есть явная утечка памяти (во всяком случае при работе с временными таблицами и большом количестве разных сложных запросов). То есть долго существующие соединения при такой схеме постепенно подъедают память, пока не сожрут ее полностью. Это очень хорошо на графиках мониторинга видно (выключаешь перестарт соединений, линия потребления начинает постепенно уходить вниз до нуля, после чего здравствуй своп / oom killer и сервер БД ложится). Видимо поэтому существуют мифы, что Postgres не тянет больше 1к одновременных соединений и вообще без пулинга из очень малого количества соединений не может эффективно работать.
Ну и надо сказать, что при выборе соединений на перестарт используется сложная система скоринга (пытающаяся определить "зажравшиеся" соединения) и один из параметров это время жизни соединения, который все же старается не перестартовывать недолго существующие соединения, чтобы эффективно утилизировать использование их кэшей.
habr.com/ru/company/lsfusion/blog/458376/#rest
Да в структурном программировании композиция проще и понятнее (так как оперирует функциями, а не таблицами), чем join. Но скажем цикл, разбиение или примитивная рекурсия в комбинаторном (SQL) проще.
В любом случае непонятно какое отношении это к ООП имеет. ООП это прежде всего про наследование и полиморфизм (ООП может быть как в структурном, так и в комбинаторном программировании), вы же рассуждаете про то, что SQL оперирует таблицами, а не функциями. Да это создает дополнительную accidental complexity, но опять-таки причем тут ООП?
Теперь бы еще поддержать рекурсии, наследование с полиморфизмом, сессии изменений, события, ограничения, логику представлений, и еще много чего и получится lsFusion.
Рынок информационных систем он такой. Ни у кого нет общей картины, все сплошные обобщения личного опыта и гипотезы (просто потому что рынок очень большой и неоднородный)
Давайте не смешивать. Отчетики и печатные формы в любой технологии достаточно несложная вещь. Я видел как люди к коробочным решениям на Oracle сбоку подключались и лепили там отчеты на CrystalReports. Порог входа при этом очень низкий в любой технологии. Плюс не забываем про навернутые BI, где пользователи много отчетов сами могут делать.
АРМам (а они ввод предполагают) как раз надо вот это вот все — управляемые формы, управляемые блокировки, как правильно условия для динамических списков писать и т.д. и т.п.
То есть про порог входа, это не личное мнение, а в том числе мнение многих 1С разработчиков, что та же УТ сейчас настолько сложной стало, что лезть туда уже мало кто хочет (а многие даже с 7.7 по этой причине не хотят уходить, так как она гораздо проще).
Ну по такой логике и Odoo превосходит 1С по числу разработчиков, только в РФ это им не так сильно помогает (хотя и помогает). Собственно SAP хороший пример, что на самом деле даже 40 партнеров (из которых наверное половина бутафорских) более чем достаточно.
В таких случаях обычно эти рабочие места выполняют самые примитивные процессы, а вся сложность и кастомизация все равно в том же SAP. Но например если взять Топ-30 розничных сетей, там большинство все же SAP и местные какие-то самописки.
Не совсем понял. Все типовые же сейчас на УФ, управляемых блокировках и т.п. Чтобы там что-то дорабатывать нужно понимать «кто все эти люди». Даже если речь о простеньких отчетах, тот же СКД по сложности уже превосходит любую Reporting system, так как туда намешали дикое количество функционала (той же аналитики, которая обычно идет в отдельных контурах).
То есть чтобы ковыряться в том же УТ или БУХ сейчас, нужно иметь очень неслабый уровень интеллекта и опыта, а это как бы основные (самые распространенные) продукты у 1С.
Именно. Причина распространенности такая же как у SAP — «давно тут сидим» ©. Только опять-таки после какого-то уровня (на примере того же SAP) количество разработчиков уже не играет такой роли, а скорее наоборот позволяет дифференцировать себя на рынке (например, не знаю как сейчас, но раньше ABAP разработчики ценились выше 1С, потому как были более редкими).
Хотя как правильно кто-то отмечал ниже, наверное самый простой способ победить 1С, получить распостранение на мировых рынках и сыграть на «чемоданческих настроениях». Во всяком случае по опыту, сейчас так Odoo двигается на российском рынке.
Да ладно. У того же SAP наверное около одного или нескольких десятков компаний в России, которые реально могут его поддерживать (а не просто значатся в списке партнеров), а если взять количество сотрудников в компаниях, которые работают на SAP, то это количество будет соизмеримо с компаниями работающими на 1С. Ну и у самого 1С, насколько я видел топ-5 франчайзеров покрывают наверное минимум 30 процентов рынка (в Беларуси так точно такая ситуация).
Ну так это в 7.7 было. И то она гораздо менее декларативна чем тот же lsFusion была. А в 8.3 с их управляемыми блокировками, РеквизитамиФормыВЗначение, &НаСервереБезКонтекста, сотней всяких избыточных абстракций и т.п., порог входа уже выше чем в .Net или условный Python (Odoo).
А возможность наращивать ораву появилось скорее из-за того что они Бух и ЗУП консолидировали. Ну и да простота и бесплатность (пиратство) 7.7. помогли.
Согласен, даже рынок полного custom made никто не отменял.
Ну строго говоря для этого 100к разработчиков не надо. Одного десятка компаний сведет риск к минимальному, и на первое место выйдут уже первые два упомянутых вами фактора: качество платформы и TCO (затраты на покупку ОС, СУБД, платформу, оборудования и т.п.). Плюс важный момент — порог входа, если он очень низкий это даже может дать большие преимущества чем наличие большого количества специалистов (где их может быть много но все равно дефицит)
Нужно понимать, что:
а) во-первых, расширения это частный случай модульности, когда у вас основное решение — один модуль, а расширение — еще один модуль зависящий от этого модуля. Поэтому в идеальной системе должна быть не только возможность добавлять свои модули, но и выключать существующие модули и / или выбирать между ними.
б) в императивных языках возможности расширений очень ограничены (тут я писал об этом). Критически важно уметь расширять запросы, иметь событийную архитектуру, полиморфизм и т.п. (вот тут я приводил примеры этой проблематики и человек мне так ничего и не ответил на них)
И если бы вы чуть больше погрузились в lsFusion, то поняли бы что в плане расширений / модульности lsFusion превосходит существующие технологии на порядок. Впрочем, естественно, никто не мешает вам «подождать на берегу», пока время подтвердит или опровергнет этот тезис :)
И как бы 1С не развивали технологию расширений, но когда все сделано на SQL запросах, но при этом жестко императивно в строках без оптимизатора, когда нет полиморфизма, эти расширения по определению будут очень ограниченными (собственно такая проблема с модульностью яркий тому пример). Уж точно далеко для подходов используемых в lsFusion.
А рынок готовых решений судя по оборотам в ЕГРЮЛ соответствующих компаний (и общению с ними) наоборот сильно сужается, так как большинство как-то уже автоматизированы и на самом деле по опыту единственный вариант им что-то внедрить, это: внедрить as is с непрерывной интеграцией, после чего превратить в to be из смеси а) того что есть у тебя, б) то что всегда хотел заказчик, но у него не было, в) оставить то что есть, что себя уже зарекомендовало. Ну а дальше непрерывный цикл доработок по agile в рамках новых идей / изменений бизнеса и т.п.
Я думал мы с другими электромобилями сравниваем. Ок тогда все это плюс разгон за 4 секунды, без передач и вообще трущихся частей (то есть гораздо меньше обслуживания надо), с очень крутой безопасностью (нельзя перевернуть, двигатель в салон не уедет), бесшумность, экологичность, возможность заправлять ночью (пусть и очень долго).
Кстати именно такие нет. Но опять-таки я тут все вместе сравнивал.
Я про пирамиду и финпоказатели. Но вообще уже появлялись другие фейсбуки — инстаграмм, твиттер, ютуб, тикток, вот сейчас клабхаус например.
То есть переход с бензина на электричество (и скажем зарядка автомобилей дома по ночам) — это не революция? Ну ок.