Ну это же не совсем так - в общественное достояние будут переходить конкретные старые мультфильмы, а Микки как персонаж является маркой вроде логотипа. Такие штуки защищены вечно (вы же не ожидаете разрешения лепить куда угодно эмблему Mercedes, например).
Наше время есть за что ругать, но обращаться к писателям прошлого за "философией будущего" довольно забавно. Ведь за пределами понятного во все времена желания улучшить жизнь человека начиналась обыкновенная экспансионистская концепция времён Колумба и Кортеса. Достичь, открыть, завоевать. Не, я даже не хочу критиковать -- романтика всей этой движухи совершенно понятна и не нуждается в обосновании. Но называть её "ориентиром будущего" или, не знаю, прогрессом в мышлении я не готов. Так что, если хочется, можно поностальгировать о том, как интересно и радостно нам жилось на заре колониальных империй, но "философию будущего" я бы искал где-то в другом месте. Скажем, идея познания и переустройства своего физического тела вполне заслуживает внимания -- не как конечная цель, а как этап, который хорошо бы пройти, прежде чем начинать мыслить в космическом масштабе.
Вот такая у меня идея для произведения. Но, боюсь, она слишком мрачная и нереалистичная, и читатели её не воспримут...
Да не в этом дело, как мне кажется. Этих антиутопий уже как собак нерезаных, и многие авторы тоже опираются на актуальную повестку (на что же ещё опираться). Ну и в итоге начинаешь воспринимать весь этот каталог просто как медицинскую энциклопедию: окей, +1 шиздецома, которая может поджидать человечество. Когда сценариев апокалипсиса так много, относишься к каждому из них как к маловероятному, да и вообще весь этот список меньше трогает.
Слово "философы" в данном контексте я читаю с негативной коннотацией. Если прав, то вынужден к нему присоединиться: проблема не в круге вопросов, а в уровне дискуссии.
В данном случае это чистой воды диванные разговоры, потому что модели бессмысленно обсуждать без формул, например. Ну и пинать предыдущие модели бездоказательно -- тоже как-то несимпатично.
Если ограничиться вот прямо первым абзацем, я не думаю, что классическая экономика не может объяснить "растущее неравенство", ведь ровно это и происходило при развитии капитализма, например. Ничего нового. Ну а уж если сравнить с каменным веком, где, видимо, почти все равны были, то и подавно.
Опыт показывает, что автора интересуют деньги в этом году, а не тонким слоем в течение ближайших 40 лет. Что, впрочем, не отменяет того факта, что денег (по крайней мере, в русскоязычном сегменте этого рынка) здесь нет вообще, и оригинальные книги пишутся исключительно из любви к искусству / ради опыта / эксперимента / резюме и т.п.
Ну, я предлагаю разделить всю эту тему на три разных вопроса: 1) что даёт TDD; 2) зачем формальные тесты и 3) что вообще тестировать.
"Не тестируем тривиальные вещи" или "не тестируем GUI/CSS/одноразовый код" -- это про (3). Пункт (2) сразу про две вещи: код (на уровне компонентов) гарантированно работает как заявлено в соответствии с указанным входом-выходом и про некую "живую" документацию, позволяющую понять, как этим кодом можно пользоваться, что важно для меня будущего или других участников, но неактуально для кода вида "написал и забыл". А вот (1) ещё про то, что вы на выходе получаете архитектуру, обладающая рядом свойств, среди которых есть "тестируемость".
То что вы называете архитектуру обладающую любыми свойствами кроме "можно написать юнит тесты" плохой
Это не я называю, это мнение автора исходного поста, а также ряда других авторов. Слово "плохой" здесь слишком обобщающее и абстрактное, но я думаю, что невозможность протестировать отдельные компоненты системы никак не может считаться достоинством, так что да, это изъян архитектуры, как ни крути. Вы можете с ним мириться или считать в своей работе несущественным, конечно.
А возможность написать юнит тесты не так важна.
Ну, получается, что и нет предмета спора. Вы не считаете невозможность протестировать компоненты достоинством? Нет, вы просто полагаете, что этот недостаток в данном случае не очень важен. Я не вижу способа доказать или опровергнуть это утверждение, тут мы уже переходим в область мнений и оценок.
У меня совершенно не радикальные воззрения, это вы, как мне кажется, юлите. Я же задал простой вопрос: вы согласны с тем, что архитектура, которую нельзя протестировать -- плохая? Если не согласны, тогда чего мы обсуждаем? А если согласны, то с чем спорим?
Вопрос о том, держится ли бизнес Кликхауса на системе, состоящей из непротестированных компонентов, не является предметом мнения. Это фактический вопрос, и ответ на него либо "да", либо "нет". Причём "нет" ещё не трагедия -- ну вот так, и что? Живём же.
Архитектура и бизнес -- это в принципе вещи связанные, но разные. Можно иметь идеальную архитектуру и ноль доходов и наоборот, поэтому странно обсуждать эти штуки в одном абзаце. А что касается юнит-тестов -- мы вообще обсуждаем не их, а TDD как методику, by design позволяющую получить тестируемый код. Если получение тестируемого кода не считается достойной целью -- ну флаг в руки, я же не пытаюсь переделать весь мир, но говорить о свойствах кода и архитектуры с заказчиком и командой же можно открыто?
Ещё раз, давайте отталкиваться от совместного понимания. Либо вы согласны с мнением выше ("нетестируемая архитектура плоха"), либо нет. Если согласны, то ваша реплика звучит так: "у меня плохая архитектура в проекте везде, но так надо". Хорошо, надо так надо.
Если нетестируемый юнит тестами быстрый код экономит бизнесу миллион долларов в месяц на железе, то это хорошая архитектура или нет?
Аналогично, давайте эту фразу переформулируем так: "на сегодняшний день у меня бизнес держится на системе, состоящей из непротестированных компонентов без формализованных примеров входа-выхода, и пока это работает".
Я на текущее обсуждение смотрю не как на поиск серебряной пули или единственно верного подхода, а на желание выложить на стол все карты. Вот вы заказчику так и говорите: я верю, что смогу сделать систему быстрее, и работать она будет шустрее, но при этом состоять она будет из сильно связанных и непротестированных компонентов. А там пусть заказчик уже и думает, нравится ему такое или нет.
Это все совсем не синонимы. И в разных местам может быть нужно разное.
Ну я ссылаюсь на текст выше, в котором сказано, что тестируемость есть необходимое, но недостаточное условие хорошей архитектуры. При этом автор не просто мнение высказывает, он повторяет то, что неоднократно сказано другими. Отсюда прямо следует, что если код плохо тестируем, он имеет плохую архитектуру.
Плохая архитектура может быть лучше с точки зрения производительности, читабельности и проч., но разумно предположить, что это будет касаться отдельных модулей, а не всего вместе. Таким образом, можно, например, начать с TDD, а для непокрытых участков писать прямо в комментарии, что тут плохая архитектура потому-то и потому-то, мы в курсе.
Фаззинг тесты не пробовали?
Собираюсь, но пока нет. По-хорошему всё делать надо, конечно :) Тема TDD интересна тем, что она прямо влияет на процесс и архитектуру, а не только решает вопросы на этапе QA.
но примерно через год-два работы с TDD вы будете намного глубже видеть как плюсы, так и минусы этого подхода. Потому что у вас будет с чем сравнивать.
Вероятно. На нынешнем этапе я пытаюсь исходить из минимального количества аксиом, которые мне представляются необходимыми при любом раскладе. Например, как вам такая логика:
Если я создаю некий компонент, то не проверить его работоспособность -- это попросту непрофессионально. Ну не знаю, "у меня компилируется, а там трава не расти", "я всё сделал по рецепту и сварил суп, а вкусный или нет -- не пробовал". Соответственно, я его тестирую. Если я его тестирую, нет никакой причины не протестировать его не руками, а автоматом.
Далее, если компонент меняется, то (см. выше) я всё равно его должен протестировать, иначе как мне убедиться, что ничего не сломалось. Поэтому, да, тест тоже придётся подправить. Но я в любом случае буду его тестировать. Тут важна гранулярность, конечно, я не тестирую private-методы, потому что это не API.
Если тест написать сложно, я могу его не писать и не тестировать (мы же не догматики и не перфекционисты), но отсутствие теста -- это сигнал, что тут код тяжело тестируется, а значит, архитектура данного компонента так себе, и по возможности требуется рефакторинг.
Если мы говорим об интеграционных или приёмочных тестах -- ну как бы я двумя руками за, понятно, что они нужны. Но наша программа -- это дискретная система с миллионами состояний, проверить которые я не могу. Изменился компонент A, приёмочный тест говорит, что всё ОК. Юнит-тесты ненадёжны, но приёмочные тоже ненадёжны, потому что из миллионов вариантов будет тестироваться меньше процента. Соответственно, я хотя бы должен убедиться, что компонент сам по себе работает (иначе непрофессионально, см. пункт 1, что возвращает к самому началу).
Вот, это самые общие соображения, в которых нет никакого фанатизма или попытки продавить конкретный подход к чему бы то ни было.
Это разумное соображение, оно пересекается с другой цитатой с MSDN: "after code reviews, smoke testing is the most cost effective method for identifying and fixing defects in software". Это, правда, мнение, доказательств нет.
Собственно, в первой реплике я же сразу упомянул, что "обеспечение качества" для меня тут не на первом месте. На первом месте именно архитектура, заточенная под тестирование, потому что она отсекает массу плохих архитектур.
Так ровно это же написано в оригинальном посте, который мы тут обсуждаем: "общепризнанно, что хорошо спроектированный код также поддается тестированию". Да, это необходимо, но недостаточно.
Но по личному опыту (своего кода и кода, с которым приходится иметь дело) могу сказать, что к среднему обычному коду не очень просто прикрутить тесты (без обилия моков и вот этого всего), что означает, что он не спроектирован хорошо. Иными словами, мне кажется, что без фактического тестирования очень трудно заставить себя писать легко тестируемый код. Гипотетически можно, на практике далеко не всегда видно, где тестируемость ломается.
Я не уверен, что вы можете этим ракету заправить, но да, продаётся 灯油 (перевода кроме "керосин" я не знаю), и заливается это дело вот в такого типа агрегаты.
Да нет, у меня масса самого разного опыта за плечами, если я "перехожу на TDD", это не значит, что я перехожу с "hello, world", ну честно.
Собственно, ровно по причинам, о которых вы говорите, у меня всегда случался какой-то затык, и приходилось плюнуть на тесты. Но я стараюсь делать выводы и подходить к TDD, скажем так, с обновлённым набором предпосылок. Ну об этом можно подробнее поговорить, конечно.
проект становится Легаси через два месяца от старта разработки.
Это утверждение занятным образом пересекается с известным определением Майкла Фезерса: "To me, legacy code is simply code without tests."
Не соглашусь. Я сам медленно и тяжело перехожу на TDD, но это, наверно, и хорошо, т.к. выскажусь не как фанбой.
Если у вас тесты увеличивают трудозатраты, то это ведь не потому, что ты пишете пару строк теста? Всё равно вам надо как-то тестировать написанное. Причина, вероятно, в том, что написанный код автотестировать по какой-либо причине трудно.
А если тестировать трудно, значит, он не очень хорошо написан, и, скорее всего, в нём хромает соответствие single responsibility principle. Для меня ценность TDD в основном в том, что эта методология заставляет писать такой код, который легко тестировать (и не увеличивать трудозатраты). То есть у меня изначально отнимают целый ряд плохих вариантов структуры программы.
Уже нет. Я застал когда-то все эти раскладушки типа Sharp, которые были завязаны на местных операторов и на стандарт CDMA. Но это уже был последний вздох, потом iPhone победил всех. Сейчас по факту либо iPhone, либо Galaxy, либо что-то дешёвое, выданное оператором (под своим брендом, но это просто шильдик, и залоченный).
Да жить в комфорте -- это не совсем про Японию, если честно. Попробуйте, например, пожить сезон без центрального отопления, таская с автозаправки керосин для горелки. Ну потому что это дешевле и теплее кондиционера с обогревом.
Отставание тоже имеется, достаточно вспомнить популярный японский софт... которого нет. На эту тему даже статьи писали. В целом причина -- упор на "железячную" индустрию, которая уже менее заметна, чем в 80х, но до сих пор связанные с софтом отрасли на втором плане.
Тут, конечно, немного о другом говорится, но это связанные вещи, как мне кажется.
Это немного разговор ни о чём. Понятно, что есть ошибки первого и второго типа (ложноположительные и ложноотрицательные). Задача системы состоит в оптимизации "в целом", а не в полном искоренении ошибок обоих типов, что невозможно. Если же сосредоточиться только на минимизации ложноотрицательных, т.е. поощрять людей вызывать скорую при любом чихе, то просто будут умирать другие люди, до которых не доехали.
Ну это же не совсем так - в общественное достояние будут переходить конкретные старые мультфильмы, а Микки как персонаж является маркой вроде логотипа. Такие штуки защищены вечно (вы же не ожидаете разрешения лепить куда угодно эмблему Mercedes, например).
Наше время есть за что ругать, но обращаться к писателям прошлого за "философией будущего" довольно забавно. Ведь за пределами понятного во все времена желания улучшить жизнь человека начиналась обыкновенная экспансионистская концепция времён Колумба и Кортеса. Достичь, открыть, завоевать. Не, я даже не хочу критиковать -- романтика всей этой движухи совершенно понятна и не нуждается в обосновании. Но называть её "ориентиром будущего" или, не знаю, прогрессом в мышлении я не готов. Так что, если хочется, можно поностальгировать о том, как интересно и радостно нам жилось на заре колониальных империй, но "философию будущего" я бы искал где-то в другом месте. Скажем, идея познания и переустройства своего физического тела вполне заслуживает внимания -- не как конечная цель, а как этап, который хорошо бы пройти, прежде чем начинать мыслить в космическом масштабе.
Да не в этом дело, как мне кажется. Этих антиутопий уже как собак нерезаных, и многие авторы тоже опираются на актуальную повестку (на что же ещё опираться). Ну и в итоге начинаешь воспринимать весь этот каталог просто как медицинскую энциклопедию: окей, +1 шиздецома, которая может поджидать человечество. Когда сценариев апокалипсиса так много, относишься к каждому из них как к маловероятному, да и вообще весь этот список меньше трогает.
Слово "философы" в данном контексте я читаю с негативной коннотацией. Если прав, то вынужден к нему присоединиться: проблема не в круге вопросов, а в уровне дискуссии.
В данном случае это чистой воды диванные разговоры, потому что модели бессмысленно обсуждать без формул, например. Ну и пинать предыдущие модели бездоказательно -- тоже как-то несимпатично.
Если ограничиться вот прямо первым абзацем, я не думаю, что классическая экономика не может объяснить "растущее неравенство", ведь ровно это и происходило при развитии капитализма, например. Ничего нового. Ну а уж если сравнить с каменным веком, где, видимо, почти все равны были, то и подавно.
Опыт показывает, что автора интересуют деньги в этом году, а не тонким слоем в течение ближайших 40 лет. Что, впрочем, не отменяет того факта, что денег (по крайней мере, в русскоязычном сегменте этого рынка) здесь нет вообще, и оригинальные книги пишутся исключительно из любви к искусству / ради опыта / эксперимента / резюме и т.п.
Ну, я предлагаю разделить всю эту тему на три разных вопроса: 1) что даёт TDD; 2) зачем формальные тесты и 3) что вообще тестировать.
"Не тестируем тривиальные вещи" или "не тестируем GUI/CSS/одноразовый код" -- это про (3). Пункт (2) сразу про две вещи: код (на уровне компонентов) гарантированно работает как заявлено в соответствии с указанным входом-выходом и про некую "живую" документацию, позволяющую понять, как этим кодом можно пользоваться, что важно для меня будущего или других участников, но неактуально для кода вида "написал и забыл". А вот (1) ещё про то, что вы на выходе получаете архитектуру, обладающая рядом свойств, среди которых есть "тестируемость".
Это вопрос цены и целесообразности. Выше же написали:
С текстом далее я не согласен, но вот этот симптом же не про плохой фреймворк, а про то, что вся эта деятельность становится нудной и бессмысленной.
Это не я называю, это мнение автора исходного поста, а также ряда других авторов. Слово "плохой" здесь слишком обобщающее и абстрактное, но я думаю, что невозможность протестировать отдельные компоненты системы никак не может считаться достоинством, так что да, это изъян архитектуры, как ни крути. Вы можете с ним мириться или считать в своей работе несущественным, конечно.
Ну, получается, что и нет предмета спора. Вы не считаете невозможность протестировать компоненты достоинством? Нет, вы просто полагаете, что этот недостаток в данном случае не очень важен. Я не вижу способа доказать или опровергнуть это утверждение, тут мы уже переходим в область мнений и оценок.
У меня совершенно не радикальные воззрения, это вы, как мне кажется, юлите. Я же задал простой вопрос: вы согласны с тем, что архитектура, которую нельзя протестировать -- плохая? Если не согласны, тогда чего мы обсуждаем? А если согласны, то с чем спорим?
Вопрос о том, держится ли бизнес Кликхауса на системе, состоящей из непротестированных компонентов, не является предметом мнения. Это фактический вопрос, и ответ на него либо "да", либо "нет". Причём "нет" ещё не трагедия -- ну вот так, и что? Живём же.
Архитектура и бизнес -- это в принципе вещи связанные, но разные. Можно иметь идеальную архитектуру и ноль доходов и наоборот, поэтому странно обсуждать эти штуки в одном абзаце. А что касается юнит-тестов -- мы вообще обсуждаем не их, а TDD как методику, by design позволяющую получить тестируемый код. Если получение тестируемого кода не считается достойной целью -- ну флаг в руки, я же не пытаюсь переделать весь мир, но говорить о свойствах кода и архитектуры с заказчиком и командой же можно открыто?
Ещё раз, давайте отталкиваться от совместного понимания. Либо вы согласны с мнением выше ("нетестируемая архитектура плоха"), либо нет. Если согласны, то ваша реплика звучит так: "у меня плохая архитектура в проекте везде, но так надо". Хорошо, надо так надо.
Аналогично, давайте эту фразу переформулируем так: "на сегодняшний день у меня бизнес держится на системе, состоящей из непротестированных компонентов без формализованных примеров входа-выхода, и пока это работает".
Я на текущее обсуждение смотрю не как на поиск серебряной пули или единственно верного подхода, а на желание выложить на стол все карты. Вот вы заказчику так и говорите: я верю, что смогу сделать систему быстрее, и работать она будет шустрее, но при этом состоять она будет из сильно связанных и непротестированных компонентов. А там пусть заказчик уже и думает, нравится ему такое или нет.
Ну я ссылаюсь на текст выше, в котором сказано, что тестируемость есть необходимое, но недостаточное условие хорошей архитектуры. При этом автор не просто мнение высказывает, он повторяет то, что неоднократно сказано другими. Отсюда прямо следует, что если код плохо тестируем, он имеет плохую архитектуру.
Плохая архитектура может быть лучше с точки зрения производительности, читабельности и проч., но разумно предположить, что это будет касаться отдельных модулей, а не всего вместе. Таким образом, можно, например, начать с TDD, а для непокрытых участков писать прямо в комментарии, что тут плохая архитектура потому-то и потому-то, мы в курсе.
Собираюсь, но пока нет. По-хорошему всё делать надо, конечно :) Тема TDD интересна тем, что она прямо влияет на процесс и архитектуру, а не только решает вопросы на этапе QA.
Вероятно. На нынешнем этапе я пытаюсь исходить из минимального количества аксиом, которые мне представляются необходимыми при любом раскладе. Например, как вам такая логика:
Если я создаю некий компонент, то не проверить его работоспособность -- это попросту непрофессионально. Ну не знаю, "у меня компилируется, а там трава не расти", "я всё сделал по рецепту и сварил суп, а вкусный или нет -- не пробовал". Соответственно, я его тестирую. Если я его тестирую, нет никакой причины не протестировать его не руками, а автоматом.
Далее, если компонент меняется, то (см. выше) я всё равно его должен протестировать, иначе как мне убедиться, что ничего не сломалось. Поэтому, да, тест тоже придётся подправить. Но я в любом случае буду его тестировать. Тут важна гранулярность, конечно, я не тестирую private-методы, потому что это не API.
Если тест написать сложно, я могу его не писать и не тестировать (мы же не догматики и не перфекционисты), но отсутствие теста -- это сигнал, что тут код тяжело тестируется, а значит, архитектура данного компонента так себе, и по возможности требуется рефакторинг.
Если мы говорим об интеграционных или приёмочных тестах -- ну как бы я двумя руками за, понятно, что они нужны. Но наша программа -- это дискретная система с миллионами состояний, проверить которые я не могу. Изменился компонент A, приёмочный тест говорит, что всё ОК. Юнит-тесты ненадёжны, но приёмочные тоже ненадёжны, потому что из миллионов вариантов будет тестироваться меньше процента. Соответственно, я хотя бы должен убедиться, что компонент сам по себе работает (иначе непрофессионально, см. пункт 1, что возвращает к самому началу).
Вот, это самые общие соображения, в которых нет никакого фанатизма или попытки продавить конкретный подход к чему бы то ни было.
Это разумное соображение, оно пересекается с другой цитатой с MSDN: "after code reviews, smoke testing is the most cost effective method for identifying and fixing defects in software". Это, правда, мнение, доказательств нет.
Собственно, в первой реплике я же сразу упомянул, что "обеспечение качества" для меня тут не на первом месте. На первом месте именно архитектура, заточенная под тестирование, потому что она отсекает массу плохих архитектур.
Так ровно это же написано в оригинальном посте, который мы тут обсуждаем: "общепризнанно, что хорошо спроектированный код также поддается тестированию". Да, это необходимо, но недостаточно.
Но по личному опыту (своего кода и кода, с которым приходится иметь дело) могу сказать, что к среднему обычному коду не очень просто прикрутить тесты (без обилия моков и вот этого всего), что означает, что он не спроектирован хорошо. Иными словами, мне кажется, что без фактического тестирования очень трудно заставить себя писать легко тестируемый код. Гипотетически можно, на практике далеко не всегда видно, где тестируемость ломается.
Я не уверен, что вы можете этим ракету заправить, но да, продаётся 灯油 (перевода кроме "керосин" я не знаю), и заливается это дело вот в такого типа агрегаты.
Да нет, у меня масса самого разного опыта за плечами, если я "перехожу на TDD", это не значит, что я перехожу с "hello, world", ну честно.
Собственно, ровно по причинам, о которых вы говорите, у меня всегда случался какой-то затык, и приходилось плюнуть на тесты. Но я стараюсь делать выводы и подходить к TDD, скажем так, с обновлённым набором предпосылок. Ну об этом можно подробнее поговорить, конечно.
Это утверждение занятным образом пересекается с известным определением Майкла Фезерса: "To me, legacy code is simply code without tests."
Не соглашусь. Я сам медленно и тяжело перехожу на TDD, но это, наверно, и хорошо, т.к. выскажусь не как фанбой.
Если у вас тесты увеличивают трудозатраты, то это ведь не потому, что ты пишете пару строк теста? Всё равно вам надо как-то тестировать написанное. Причина, вероятно, в том, что написанный код автотестировать по какой-либо причине трудно.
А если тестировать трудно, значит, он не очень хорошо написан, и, скорее всего, в нём хромает соответствие single responsibility principle. Для меня ценность TDD в основном в том, что эта методология заставляет писать такой код, который легко тестировать (и не увеличивать трудозатраты). То есть у меня изначально отнимают целый ряд плохих вариантов структуры программы.
Уже нет. Я застал когда-то все эти раскладушки типа Sharp, которые были завязаны на местных операторов и на стандарт CDMA. Но это уже был последний вздох, потом iPhone победил всех. Сейчас по факту либо iPhone, либо Galaxy, либо что-то дешёвое, выданное оператором (под своим брендом, но это просто шильдик, и залоченный).
Да жить в комфорте -- это не совсем про Японию, если честно. Попробуйте, например, пожить сезон без центрального отопления, таская с автозаправки керосин для горелки. Ну потому что это дешевле и теплее кондиционера с обогревом.
Отставание тоже имеется, достаточно вспомнить популярный японский софт... которого нет. На эту тему даже статьи писали. В целом причина -- упор на "железячную" индустрию, которая уже менее заметна, чем в 80х, но до сих пор связанные с софтом отрасли на втором плане.
Тут, конечно, немного о другом говорится, но это связанные вещи, как мне кажется.
Планетарные бои тоже по-своему ностальгичны и интересны. Это же ремейк Nether Earth 1987 года со Спектрума.
Это немного разговор ни о чём. Понятно, что есть ошибки первого и второго типа (ложноположительные и ложноотрицательные). Задача системы состоит в оптимизации "в целом", а не в полном искоренении ошибок обоих типов, что невозможно. Если же сосредоточиться только на минимизации ложноотрицательных, т.е. поощрять людей вызывать скорую при любом чихе, то просто будут умирать другие люди, до которых не доехали.