В России в частном строительстве сейчас применяются примерно все технологии, которые существуют в мире. Некоторые типа SIP внедряются с опережением на годы от стран происхождения. Он появился в штатах, а я от знакомых оттуда услышал про SIP на 10 лет позже, чем у нас.
Несмотря на это, свой дом я построил каменным — монолитный железобетон в каркасе, газобетонные стены в 30 см толщиной. К ним ещё 10 см минваты. Всё это для того, чтобы скомпенсировать теплопотери через ростовые окна, занимающие примерно 1/3 стен первого и все торцы второго этажа.
Есть в телевидении такая тема, как SDI. Это коаксиальный кабель, по которому передается видео на частотах до 10 гигабит. 4K в сыром несжатом виде, по 4 байта на пиксель — как нехрен делать. Очень удобно работает: воткнул провод и сразу всё видно (конечно же нет, но об этом попозже).
Но мир требует перехода на IP, а с ним беда: он в десятки раз дешевле, что недопустимо для старых компаний. Значит что надо сделать? Надо придумать такой типа-IP протокол, в который нельзя влезть без FPGA плат, обеспечивающих синхронный риалтаймовый ethernet на скоростях порядка 10 гигабит в секунду.
Людям, не погружавшимся в проблематику, кажется что баг очень легко отличается от фичреквеста: баг — это когда не работает, как надо, а фичреквест — это не работало никогда, но хочется чтобы работало.
Так вот неприятная новость: это так далеко не всегда работает, сейчас покажу где оно работает, а где нет.
Познакомился с тем, что сейчас предлагается на рынке для организации водопровода и отопления в частном доме.
Для начала отопление рассматриваю водяное, потому как есть большой шанс на газ, а значит тепла будет много, так что электрическое отопление отметается даже в виде инверторов/тепловых насосов. Электричества не очень много, а мне ещё машину заряжать.
Итак: холодная вода, горячая вода, радиаторы и теплые полы (потому что везде плитка).
На рынке наблюдаются следующие системы трубопроводов:
ПНД трубы (уличные)
Старая добрая сталь с ржавыми трубами
Полипропилен
Металлопласт
Шитый полиэтилен (их несколько разных и они несовместимы)
Тонкостенная нержавеющая сталь (valtec и vier кажется монополисты)
надо упомянуть медь, но зачем — я вообще не понял
Забегая вперед: полипропилен самый безгеморойный вариант на круг, но есть ньюансы, так что можно идти с шитым полиэтиленом на все нужды. Нержавейку брать не надо.
ПНД
ПНД трубы — это то, что кладут на улице, закапывают в землю для воды, газа, электричества. Обжимаются ручными фитингами, т.е. для сборки такого водопровода нужны специальные ножницы (и никак без них не получится) и всё. Специальные ключи для закручивания фитингов настолько не нужны, что они крайне редко продаются.
Для горячей воды они, кажется, не подходят вообще и они слишком не ахти, чтобы их пихать домой.
Пока что важнейшим открытием в бизнесе этого года для меня стала терминология средств и задач.
У клиентов есть долгосрочные цели. Для их достижения нужно решать задачи, для которых нужны средства.
Сервисные организации решают сразу задачи клиента, не погружая его в средства. Яндекс метрика как-то собирает данные и рассказывает клиенту, какие страницы посещались, где есть проблемные места. Клининг просто оставляет после себя чистый офис. Такие организации иногда могут дать SLA на свои услуги и в целом довольно предсказуемо умеют возвращать всё в состояние «верните как работало»
Экспертные организации очень хорошо ориентируются в готовых средствах и могут за клиента обеспечить подбор средств. Это очень важно, ведь выбор средств может быть чудовищным. Этот класс организаций во многом существует из-за неполного доступа к знаниям. Так, например техническая/экспертная поддержка у такой компании (например это бывают интеграторы) зарабатывает на ограниченном доступе к знаниям. Один из характерных паттернов поведения таких организаций в том, что они работают с задачами, как с заведомо имеющими решение, надо просто подобрать настройки и комбинацию (т.е. поднять тайные знания). Такое возникает на фоне того, что средства они берут у тех, кто их сделал, а с ними всасывают и знания об их применимости.
А вот когда средств не хватает, их нужно создавать. Этим занимаются инженерные организации. В экспертных они плохо живут — разный темп жизни, могут быть внутри сервисных, но там у них размыта их орг структура, а могут жить отдельной. Наша компания Эрливидео — в чистом виде инженерная организация, создающая средства для решения задач клиентов.
Не мы вещаем телевидение и пишем IP камеры, это делают наши клиенты, но с помощью нашего софта.
В каком-то российском подразделении Хуавея количество эскалаций тикетов технической поддержки наверх в Китай было менее 1%. У нас количество обращений в техподдержку, заканчивающиеся тикетом в редмайне порядка 30% Это расшифровывается на этом языке так: техподдержка хуавея решает задачи клиентов и у них в 99% случаев для этого есть все средства и знания. У нас же обращаются в поддержку, когда средства не решают какие-то новые задачи (ведь старые то решаются) и техподдержка фиксирует в виде новых знаний о рынке, о задачах клиентов в 30% случаев.
Т.е. у нас даже техническая поддержка работает с другими функциями, чем в сервисной организации.
Из обихода автоматически выкидываются такие термины как «фичи», «баги».
Фича — это такая доработка средств под новую задачу, которая воспринимается клиентом без негативных эмоций. Но разговор про «а сделайте мне такую фичу» мы теперь переводим в «какие у вас задачи, что вам не хватает того, что уже есть». А раз не хватает, то скорее всего задачи новые.
Баг — это чаще всего такая фича, которая воспринимается клиентом негативно. Он ожидал, что наше средство подойдет под его задачи, а оно не подошло и он расстроен. В любом случае сначала надо выяснить его задачи и только потом кидаться жечь миллионы денег на создание нового средства.
Регрессия — это когда мы вообще не знали о задаче и что-то сломали, а клиент пришел и ругается: говорит вчера его задача решалась, а сегодня нет. Значит ему это реально нужно (иначе не пришел бы), а мы не знали о задачах. В отличие от «бага», который ещё непонятно будет ли кому-то всерьез нужен, «регрессия» — это подтвержденный business impact
С программисткой точки зрения тесты — это кодифицированные знания о рынке, о его задачах.
Ещё очень важный момент напоследок.
Технари, будучи людьми глубоко эмоциональными (в отличие от очень рациональных сейлзов и прочих т.н. гуманитариев), эмоционально очень сильно прикипают к средствам. Отхватить в зубы за неуважительное отношение к макросам емакса или дрелям хилти — да почему бы и нет.
На переговорах технари устраивают бешеные срачи про средства. Это эмоции, это подтверждение их экспертности. Усомниться в средстве — это то же самое, что поставить вопрос ребром: «а кто пустил этого задрота сюда за стол», даже если никто вообще этого не имел ввиду. Спорить о средствах бессмысленно и там можно только ломать людей, которые вам это припомнят.
А вот обсуждение задач проходит на порядки легче. Как только мы переходим от средств к задачам, то сразу становится ясно, что запускать постгрес на пошаренном через NFS каталоге, экспортированном через plan9 fs из цефа не требуется. Ни в коем случае нельзя говорить, что это плохое средство, достаточно просто обсудить задачи и прийти к выводу, что сейчас пока до таких материй не доросли.
В чём тут дело? Средства — клевые, они блестят свежим хромом, от них пахнет смесью спецдезодоранта, пластика и хрустом свежераспаковываемого хельм чарта. Их хочется тащить в дом, посмотрите на свой собственный шкаф с инструментами. Задачи — мерзкие, их надо делать. Их все с радостью готовы урезать: «хорошо, если мне машина нужна ездить к теще, то для раз в два года, могу и не покупать её»
А дальше всё таки включается банальная логика: если предлагаются средства, которые решают очерченный круг задач, то больше ничего не нужно. А если очень хочется втащить что-то, то надо плясать от задач. Правда иногда бывает нужно помочь клиенту, потому что не каждый готов писать, что у него задача — купить себе квартиру с отката, полученного за втаскивание в проект Netapp стораджа, который дорогой, медленный и нахрен не нужен.
Собрался всё таки строить дачный дом. Сначала всю зиму провозились со строителями, которые хотели строить из полистиробетона, но стало ясно, что без конструкционного расчета, в котором будут рассчитаны все прочности, изгибы и т.п. это делать нельзя. В итоге с первой бригадой просто сожгли впустую время и деньги на проект.
У тех, кто строит из монолитного бетона, нашелся конструктор, который выдал нам объёмный матричный прочностный расчёт и стало ясно, что желаемую конфигурацию (с огромной террасой) построить получится.
Быстрее всех отработали Россети: я скачал из кадастра карту участка, намалевал на ней в Preview примерное расположение дома, ткнул какую-то черточку с надписью «тут будет столб для электричества» и этот план подключения их устроил полностью. Приехал электрик, поставил столб, выдал счетчик, сделал всё вообще без моего участия.
Количество тонн всякого строительного барахла, которое завозится на участок, конечно пугает: одной только арматуры 12 тонн.
В этом году на даче, конечно, не получится провести лето, это уже на следующий год.
Выступал с докладом про инженерную культуру в нашей компании и разобрался со старым внутренним конфликтом. Дальше я буду помечать курсивом спецтермины, которые ссылаются на работы Щедровицкого и другие материалы по деятельности.
Цели, задачи, средства
Клиент достигая своих целей на рынке, решает свои задачи. Для решения каждой задачи ему нужны средства.
Иногда средства уже есть на рынке и он просто может ими воспользоваться. Такой клиент приходит к нам молча, берет триал, потом покупает и пользуется. Таких все разработчики софта любят, но они не принесут развитие.
Если не брать закрытые (которые вообще непонятно зачем писать свои сегодня с нуля), то есть Ardupilot, PX4, Betaflight. Можно найти что-то ещё и всякие форки типа ArduCopter, но их отложим в сторону.
Упрощенная до предела ситуация такая: betaflight для fpv, px4 для программистов, а ardupilot ни для тех, ни для других.
У бетафлайта самая широкая поддержка самых дешевых полетников, вроде как всякие тонкие настройки именно ручного управления. Короче, акробатика и пролеты под едущим грузовиком — туда.
Ardupilot и PX4 это прям два разных мира: практичные железячники и программисты.
Мозгом дрона является его полетный контроллер. Это тот прибор, который сделал возможным создание такого противоестественного монстра, как квадрокоптер.
Нормальный самолет сразу после живорождения из утробы почти сразу умеет махать крыльями и лететь и его стабилизирует физика процесса. Квадрокоптер же антистабильный. После рождения из желтого пакета с почты, он не может ничего до заливки в него прошивки с компьютера.
Если мозг выключится хотя бы на секунду и моторы продолжат вращаться с той же скоростью, то он перевернется, упадет вам в офисе на ковролин пропеллерами вниз, потом полетник очухается, врубит моторы на полную и надо будет что-то придумывать с четырьмя дырками в полу (нужны годные отмазки, потому что на инопланетян списали поцарапанный потолок).
Продолжение изначального поста. Напоминаю про дисклеймер: тут лекция для колхозников, а не для дачников, так что если вам что-то режет глаза — поделитесь своими знаниями.
Что получилось узнать про ситуацию с моторами для квадрокоптеров, условно до миллиона рублей.
Внутренняя структура
Во-первых, они все бесщеточные (brushless). Есть с щётками, но это для машинок и для чего-то ещё. Тут такие уже не встречаются.
Обмотки стоят на месте, вокруг них вращается железный ротор. Железный ротор иногда стараются сделать сразу вентилятором, чтобы он обдувал себя же и охлаждал.
Волею рынка, познакомился с дронами (квадрокоптерами). Ситуация с ними такая:
есть закрытый DJI, в который влезть на грани невозможного. Какой-то бизнес с ними выстроить можно, но это на уровне дружбы с гуглом/микрософтом
есть какое-то количество игрушек, их оставим в стороне
талантливые команды делают какие-то разовые сборки из серии «соберем вам дрон за полтора миллиона рублей»
в разнообразии присутствует класс fpv дронов, которые по характеристикам вполне обходят DJI, но попытка поднять 7-дюймовую химеру в офисе (а где же его ещё испытывать то после покупки) может закончиться поездкой в больницу. Ремонт в офисе точно делать прийдется, а вот без больницы мы обошлись, потому что догадливые. https://www.youtube.com/watch?v=-W_nFlIAWFM для затравки — чем круты fpv дроны. Тем, что именно в этом классе есть long range.
Что мне больше всего импонирует в классе fpv дронов, так это повсеместная открытость. Практически каждый компонент существует в опенсорс виде.
Человек в рамках своей повседневной деятельности погружен в те темы и вопросы, которые находятся возле него и его окружают. Сложно разбираться в том, что далеко, особенно когда ты глубоко копаешь свою работу.
При продаже ему чего-то возникает проблема, что надо из одного колодца компетентности (надеюсь, этот термин понятен) перебросить идею в другой. Аналогичная задача возникает и при обмене знаниями.
Проблема в том, как сформулировать в терминах понятных покупателю, что же ты ему продаешь. Проблема тем сложнее, чем сложнее сам продукт (т.е. то, что покупает клиент). И на этой метафоре хорошо понятен продукт: это не то, что находится в нашем колодце компетентности, а то, что попадает в другой.
Древние философы выстраивали модель обмена знаниями вокруг концепции наличия пространства сверхидей, которые тенями отражаются в наш мир. Т.е. как будто бы можно принять волшебную таблетку и нырнуть в мир сверхидей, где косность нашего языка не будет мешать выражению мыслей. Эту мысль не забросили, по крайней мере это самое частое оправдание трипов: скинуть оковы разума и погрузиться в пространство чистых мыслей.
Мы разработали и продаем программно-аппаратный комплекс для транскодирования (Flussonic Coder). От термина ПАК сводит зубы, но ничего лучше я не встречал и не видел даже в английском языке.
Смысл этой аббревиатуры в том, что мы подобрали всё железо, весь софт, их отладили вместе как единый продукт. Это отличается от варианта, когда наш клиент сам собирает себе сервер, ставит в него какое-то железо и админит убунту на нём.
Поскольку мы никого не пускаем туда и продаем это всё вместе, то и тестировать надо наш софт вместе с линуксом. Разберем несколько аспектов этой задачи.
Мы продаем железку для транскодирования, на которой находится упакованный нами линукс, т.е. прошивка (такая же как на роутере или ip-камере). Всё преднастроено и собрано в програмно-аппаратный комплекс.
Конечно же там внутри стандартная убунта с минимальными модификациями, но вокруг этого добавлен ряд вещей, позволяющих работать именно с целиковой железкой, а не с флюссоником, стоящем на сервере, настроенном админом.
Чтобы описать, что мы там навертели внутри, надо сначала описать, какие функции надо было реализовать средствами прошивки, почему не достаточно просто поставить убунту и успокоиться:
Пропустив через себя API-first подход с полноценным повсеместным внедрением OpenAPI в компании, стало сильно яснее, что у нас происходит с тестами.
Опытные программисты вообще любят тесты, потому что без них совсем плохо и больно. Что такое автоматический тест? Это симуляционный прогон в моделированных условиях.
По сценариям тестов прогоняют софт (это очень дешево), реальные вещи (перед полетом, самолету крылья выкручивают наверх и завязывают бантиком, чтобы убедиться в их прочности), а заодно и цифровые двойники реальных вещей.
Программисты довольно условно, но разделяют тесты на юнит-тесты и интеграционные (тут пропущена бездна материала, так что упростим пока до этого деления). Интеграционные проверяют что софтина в комплексе, как черный ящик ведет себя так, как от неё это ожидают.
Интеграционные тесты
Грубо говоря задача интеграционных тестов не допустить:
Одно из открытий, которые стоило сделать лет 10 назад — бизнес-модель продукта.
Для программиста это всё звучит как булшит бинго, а продукт — это экзешник (пакет), который скачивает себе клиент.
Нет. Продукт — это та эфемерная абстрактная сущность, за которую отдает деньги клиент, только то, за что он платит. Продуктом в ресторане может быть просто милая официантка, которая так заразительно смеется, что приходящие мужики готовы терпеть омерзительный кофе просто чтобы ей полюбоваться.
С ростом сложности продукта (я не знаю, насколько на самом деле сложны FMCG продукты, вполне возможно что там лютый ад похлеще какой-нибудь CRM) конечно роль милой официантки падает, но растет другое: невозможно поместить в головы тех, кто будет покупать тот же набор идей, что и у тех, кто это делает.
Т.е. те, кто написали софт и те, кто его будут покупать и оплачивать думают гарантированно о разных вещах. У одного в голове офигенно склеенные горутины с фабриками адаптеров, у другого довольно неплохая штука, помогающая добывать на 10% больше денег с арбитража рекламы, чем предыдущее решение. И вот продукт — это как раз второе.
На днях тут слегка подискутировал с одним программистом (уверен, что он очень толковый человек) на тему того, что webrtc — это почти всё телефония, потому что люди покупают тот же продукт. Раньше ты звонил по телефону, потом по скайпу, теперь по телеграму. Та же самая телефония, просто сменилась внешность телефона. Но для него эта мысль была крамолой, ведь там же ВСЁ СОВЕРШЕННО РАЗНОЕ.
И вот теперь мы подходим к тому, что же такое продукт. Очень простой, эффективный и действенный способ его описать — сформулировать в виде value proposition canvas и/или business model canvas что вообще происходит. Это два немного разных документа, но их объединяет то, что их надо заполнять не более чем на А4. Писать дальше нет никакого практического смысла (пока конечно эти штуки новы для вас).
И потом начинается магия.
Внезапно оказывается можно прийти к маркетологу и спросить: с какими атрибутами продукта сочетается твоя активность за последний месяц? Возможно он в первый раз в жизни получит в руки четкий план работы вместо выдаивания из себя непонятных креативов.
Программиста можно спросить: а зачем ты пилил поддержку CEPH втихаря последние 3 месяца? Какую составляющую value proposition ты поддерживал этой деятельностью.
Ну и можно будет привязывать всю аналитику уже к этим моделям. Т.е. при своей простоте они позволяют померять, оттолкнуться от чего-то на следующей итерации и, что самое важное, позволяют синхронизировать людей, которые вообще друг с другом общаться не будут и направить их в нужную сторону.
Круто, когда подобное получается сделать начиная с 10-20 человек.
Полугодовой опыт владения теслой такой: очень быстрая, просто суперкар по довольно средней цене, но постоянный геморрой в ежедневной эксплуатации. Ближайший аналог — BMW M5, но он в 2,5 раза дороже по довоенным ценам.
Электромобиль сегодня — сугубо внутригородская машина с перемещением от розетки до розетки. Зимой её пробег менее 200 км.
Итого, первый тезис: никакого прорыва в потребительских качествах в электромобилях нет.
Что интересно, так это то, что его зарядка по коммерческим ценам близка к бензину. Если заряжать по домашним ночным ценам, то почти бесплатно, но днем в городе в 10 раз больше. Т.е. никакого прорыва в энергоэффективности нет, есть просто чудовищные дотации российского государства физикам для ночного домашнего потребления. Ну и конечно ещё есть бесплатные городские зарядки в Москве, за что так же спасибо.
Примерные цифры такие: 3 раза в неделю в офисе заряжаю порядка 25 киловатт-часов (беру из памяти числа, так что они не точны, но не на порядок). Это было бы по 500 рублей на частной зарядке, 70 рублей дома ночью. Ну а я ничего не плачу, потому что в офисе с меня денег не берут, город денег не берет. Я ей вообще как велосипедом пользуюсь, даже за парковку деньги не берут.
Второй тезис: электромобили не дешевле в энергии. Просто государство отнимает деньги у того мужика на логане и отдает их мне. Для чего — мне не очень понятно.
Продолжаю внедрять и развивать тему с внедрением API-first подхода в компании.
Словарик с программисткого на бизнесовый
В понедельник ходил на Devopsconf рассказывать про openapi.
vk.com
Что очень интересно: эмоциональная, иррациональная часть коллектива (т.е. программисты) любят забалтывать всё это.
<i>у меня тут кодогенератор, ему нужно чтобы были вот такие штуки</i>. И так у вас вместо документа, понятного бизнесу, появляется ещё один кусок программного кода, который удовлетворяет сиюминутную хотелку какого-то безымянного автора кодогенератора, разрушая тонкую связь у вас в компании. Отказать сразу.
Ещё включают душнилу и начинают предельно кропотливо настраивать объекты на вход и на выход. Они почти всегда отличаются настолько, что если попытаться отразить, какие именно поля можно запихивать в систему, а какие нельзя, то получится два объекта. В итоге вместо одной формы и структуры объекта, вместо того, чтобы наконец договориться называть одним и тем же словом одну и ту же вещь, вы получаете кусок программы, который мешает программисту жить и совершенно бесполезен для бизнеса. Если программистам очень хочется использовать схему для кодогенерации сразу включая права доступа к тем или иным полям, это можно делать или сторонними средствами, или какой-то метаинформацией.
За 4 месяца мы почти полностью внедрили в большинстве продуктов флюссоника работу с OpenAPI и с подходом API first.
Для тех, кто смутно понимает о чём речь, сразу добавлю несколько атрибутов, которые должны пояснить что именно происходит.
Речь идет о том, что у нас в отдельном репозитории лежат текстовые файлы, которые могут редактировать и читать продакты, поддержка, программисты, тестировщики, даже клиенты. Из этих текстовых файлов генерируется код, который гарантирует что общение компьютерной системы с внешним миром происходит по форматам, описанным в этих файлах.
Если у вас в проекте внедрен OpenAPI, но он генерируется из кода, то забудьте, это фигня, притом довольно бессмысленная. Непонятно зачем этим пользоваться.
Что по сути получилось? Это шикарный механизм, позволяющий:
1. Зафиксировать требования от менеджмента исполнителям. Причем менеджеру не требуется дожидаться реализации, можно смоделировать систему вообще без её поведения. Только на основе модели данных можно уже очень много продумать в голове и спрогнозировать, как этим вообще пользоваться.
2. Унифицировать и структурировать общение между командами.
3. Поднять обмен знаниями на совершенно иной уровень. Очень важный момент в том, что кодогенерация дает гарантии того, что работать будет так, как описано.
Штука вообще недооцененная, кода вокруг мало. Ощущение, что большие живут на инструментах явы, а остальные недооценивают пользу всего этого.
Одна из индустрий, где мы (flussonic) работаем, это видео развлечения.
Мы полностью выпадаем из онлайн кинотеатров (фильмы), там технические задачи решаются просто большим количеством SSD, а вот в доставке прямого эфира наш софт очень нужен.
Сегодня я наблюдаю три поколения эфирного телевидения:
Мы в этом году сделали и сейчас начинаем продавать свою собственную железку: аппаратный транскодер.
Это большой переход для софтверной компании, потому что совершенно новые процессы, новые задачи.
Я не буду пока что рассказывать про все страдания от процесса разработки железа, но хочу немного поделиться про софтверную часть того, что называется appliance (как это будет по-русски?)
В отличие от продажи софта на сервер, который админим не мы, тут всё начиная от ядра готовим мы.
Структура самого транскодера внутри нетривиальная, это хитрый девайс с пачкой процессоров и несколькими линуксами.
Во-первых, оказалось совершенно непонятно, как нанять и какие требования выкатить человеку, который может подпатчить systemd, но при этом понимать, что ему надо патчить не на компьютере, а в репозитории.
Во-вторых, всплыла пачка интересных сложностей с линуксом.
Например, патчи к конфигу ядра плохо переживают апдейт самого ядра, т.е. надо ещё здорово попотеть, чтобы обновить само ядро.
При этом навыки программиста помогают делать простые и стабильные решения (типа положить файлик в /etc/что-то-там.d вместо sed-редактирования /etc/что-то-там)
В-третьих, очень непривычна невозможность внятного полноценного тестирования иначе кроме как руками.
Очень во многом эта работа перекликается с нашим Flussonic Iris (напоминаю, это прошивка для IP-камер, таким занимается буквально пара команд в стране). Нужно постоянно решать, как пользоваться линуксом: использовать системный код или писать своё.
В прошлом году я наконец смог выделить нормальное количество денег на разработку своей прошивки для IP камер. Эта идея у меня была года так с 2013, но не было сил и денег на это.
Теперь у меня целая команда занимается этим проектом и мы активно продвигаемся.
Ситуация такая: на сегодняшний день в хроме/лисе нельзя зайти ни на одну IP камеру из известных мне и посмотреть, чего она видит. Есть некоторые российские проекты типа polyvision или trassir, которые пихают flash, но они опоздали на несколько лет. Флеш уже списан, похоронен и перестал смрадно вонять.
Наша прошивка для IP камеры судя по тому что я знаю первая в мире, которая позволяет получить видео без задержки в HTML5 интерфейсе даже без webrtc.
Сейчас мы собираем прошивку, которая встает на камеры на hi3516a + imx178, но в планах конечно вся линейка хайсиликона.
