# Note that this schema.rb definition is the authoritative source for your
# database schema. If you need to create the application database on another
# system, you should be using db:schema:load, not running all the migrations
# from scratch. The latter is a flawed and unsustainable approach (the more migrations
# you'll amass, the slower it'll run and the greater likelihood for issues).
 
# Учтите, что schema.rb является авторитетным источником данных о
# структуре базы данных. Если вам нужно воспроизвести базу на другой
# машине, нужно выполнить db:schema:load, а не прогонять все миграции
# с нуля - это ущербный и обреченный на провал подход (чем больше миграций
# накопится в проекте, тем медленне они будут проходить и тем больше вероятность ошибок).

Он говорит о двух вещах.

Во-первых, при развертывании проекта, особенно если он уже старый и миграций поднакопилось, нужно выполнять не rake db:migrate, а rake db:schema:load. Вторая команда выполняет фактически всего одну миграцию и не выполняет всяческих отменяющих друг друга команд (знаешь, как бывает – поле добавили, потом через неделю вынормализировали и убрали).

Надо заметить, что если в базе есть какие-нибудь нестандартные поля, например, поля полнотекстового поиска Postgres, то соответствующая таблица в schema.rb попросту не попадет. В таком случае у тебя есть три выхода: либо добавить файл схемы в игнор, чтоб людей не смущать, либо патчить адаптер БД, что мне желаемого результата не дало, либо использовать схему в SQL (config.active_record.schema_format = :sql). Но не тут-то было: SQL-схема не обновляется автоматически после миграций и не используется в задачах типа db:setup. Соответствующий патч лежит в багтрекере Rails уже аж две недели.

Во-вторых, что более важно, в миграциях не должно быть логики по наполнению базы – хотя бы потому, что это нарушает вышеупомянутое соглашение. По соглашению, наполнение базы нужно делать в db/seeds.rb.

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

Пункт ноль: VirtualBox обеспечен поддержкой со стороны Sun Oracle, а coLinux – любительская разработка.

Виртуализация и производительность

coLinux представляет собой порт ядра Linux, работающий непосредственно из-под Windows, причем в привилегированном (Ring 0) режиме. Это значит, что все, кроме периферийных устройств, доступно ему без виртуализации: с одной стороны, так быстрее, с другой – (пока) coLinux совершенно не работает под 64-битной Windows.

VirtualBox же, в последних своих версиях, использует аппаратную виртуализацию, доступную в современных процессорах (Intel VT-x), чтобы обеспечить практически тот же эффект.

Тут надо понимать, что есть два вида виртуальных машин: одни эмулируют процессор, то есть обеспечивают его функции программно, а другие -перекомпилируют код под реальный процессор, либо, в случае одинаковости реального и виртуального процессоров, выполняют код «как есть», без каких-либо изменений.

Мораль в том, что современная виртуализация, даже в своей «потребительской» ипостаси – дико быстрая штука. Потому я и не буду сравнивать производительность.

Еще я не буду сравнивать производительность потому, что у меня 64-битная Windows 7 и coLinux не работает, кроме того, раньше coLinux не заводился и на 32-битной Windows 7 (еще beta 7000), а когда заводился (на XP) – работал пренебрежительно хорошо.

Ненавязчивость

coLinux умеет запускаться как в оконном режиме, так и в режиме сервиса. VirtualBox, сам по себе, – только в оконном, но мы-то знаем о программе, позволяющей запускать VirtualBox сервисом. В любом случае Linux будет работать в фоне и никак о себе не напоминать.

coLinux проблематично относится к засыпанию Windows и совсем никак не относится к сохранению состояния машины (при выключении компьютера, разумеется, выключается и Linux). VirtualBox позволяет в любой момент сохранить виртуалку и замечательно переносит гибернацию.

GUI

Если вам зачем-то (зачем же? зачееем?) надо запускать GUI-программы из-под Linux, для VirtualBox доступно точно то же самое решение, что и для coLinux/andLinux: Xming. Кроме этого, VirtualBox предоставляет т.н. Seamless Mode – режим, в котором оконные менеджеры Windows и Linux сливаются воедино. Не буду врать, я этого не пробовал.

vim в PuTTY, gVim под Windows, gVim под Xming – где какой?

Сеть

В плане поддержки сети возможности coLinux и VirtualBox ваще идентичны.

Жесткие диски

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

Периферия

Подключить USB-устройство к VirtualBox достаточно просто, я подключал внешний диск с разделами в ext3, причем Linux его определял и использовал как обыкновенный внешний диск.

Можно ли подключить USB-устройство к coLinux? Я пока не узнал…

• Bundler из Passenger не находит гемов, установленных в домашний каталог пользователя, то есть установленных посредством bundle install.
• RailsEnv, установленный в конфиге Passenger, не используется, то есть всегда используется production

UPD: как на самом деле обстоят дела

На самом деле проблема в том, что я не вызывал bundle lock. Эта команда (что никак не очевидно) не только «запирает» набор зависимостей. Она также создает файл Gemfile.lock, в котором находится информация о том, откуда эти зависимости брать. И ошибка

git://repo/path.git (at master) is not checked out. Please run `bundle install` (Bundler::PathError)

на самом деле значит, что нужно было вызвать bundle lock.

UPD 2: в Bundler 1.0 (gem install bundler --pre) команда bundle lock не используется, а точнее отрабатывает автоматически при bundle install. А проблема моя была в том, что у меня стояло PassengerUserSwitching off (пользователь-то один), ввиду этого Passenger видимо не отдавал Bundler-у путь к домашнему каталогу и Bundler пользовался только системными гемами. Мораль: какие-то третьи рельсы сильно связанные.
/UPD 2

Кроме того, переназначение ENV['RAILS_ENV']=ENV['RACK_ENV'] совершенно необязательно, достаточно всего лишь указать правильный RackEnv в настройках Passenger.

А config.ru можно оставить в покое.

/UPD: все, что дальше, можно не читать
Помучавшись немного, я нашел источник этих проблем: приложения Rails 3 являются и рассматриваются как полноценные приложения Rack.

Из этого следует (я так понимаю), что переменные окружения в Rails не попадают, их нужно объявлять отдельно в config.ru, то есть в конфиге Rack. Не попадает туда BUNDLER_HOME. Кроме того, поскольку Passenger обрабатывает Rails-приложения как Rack-приложения, вместо директивы RailsEnv нужно использовать RackEnv, а потом в том же config.ru присваивать ее обратно.

Резюмируя, нужно в конфиг Passenger добавить RackEnv development, а в начало config.ru вписать следующие строки:

require 'etc'
ENV['RAILS_ENV'] = ENV['RACK_ENV']  if !ENV['RAILS_ENV'] && ENV['RACK_ENV']
ENV['BUNDLER_HOME'] = Etc.getpwuid.dir # домашний каталог пользователя

Беспарольный sudo

Поскольку никто, кроме тебя, на виртуалку попасть не сможет, целесообразно убрать пароль с sudo. Так удобнее. Для этого в /etc/sudoers нужно дописать строку

%username% ALL=NOPASSWD: ALL

где %username%, конечно – логин твоего пользователя, %username%.

Настройка сети

Вышеупомянутые статические настройки. Возможно, придется поменять IP-адреса (я почти уверен, что не придется) – правильные можно подсмотреть в выдаче ifconfig.

# /etc/network/interfaces

# Loopback - не забудь его не убрать
auto lo
iface lo inet loopback

# NAT - служит выходом в Интернет, потому и gateway.
auto eth0
iface eth0 inet static
address 10.0.2.15
gateway 10.0.2.2
netmask 255.255.255.0
network 10.0.2.0
broadcast 10.0.2.255

# Host-only адаптер
auto eth1
iface eth1 inet static
address 192.168.56.101
netmask 255.255.255.0
network 192.168.56.0
broadcast 192.168.56.255

Остается настроить статический DNS. Проблема вот в чем: виртуальная машина получает свои DNS посредством DHCP у машины-хозяина, причем получает в момент загрузки. Предположим теперь, что я загрузил виртуалку дома, и она получила в качестве DNS мой роутер 192.168.1.1. Потом я пошел на работу, выключив (или усыпив) ноут – виртуалка при этом сохранила свое состояние, при чем для нее ничего не поменялось вообще. Она по-прежнему использует в качестве DNS роутер – уже недоступный – и поэтому теряет способность разрешать доменные имена. Довольно-таки неочевидный затык.

Чтобы избавиться от этого, в файл /etc/dhcp3/dhclient.conf добавляем строчку:

# Принудительно используем сервера OpenDNS (можешь указать любые другие)
supersede domain-name-servers 208.67.222.222,208.67.220.220;

По-моему это не идеальный конфиг, по уму надо все настройки перенести в dhclient.conf, но пока и так работает.

Настройка SSH

SSH-сервер по умолчанию в Убунте не стоит:

sudo apt-get install openssh-server

Предположим, ты используешь PuTTY. Тогда тебе остается сгенерировать им SSH-ключ – для удобства без ключевой фразы – и:

mkdir ~/.ssh
echo "public key copypasted from putty" >~/.ssh/authorized_keys

После чего используем сгенерированный ключ для беспарольного входа на виртуалку. А если средствами ярлыка или BAT-файла вызывать putty -load virtualbox_session_name – то даже без путтевского окна настроек.

Установка VirtualBox Guest Additions

Данная штука нужна обязательно хотя бы потому, что без нее на виртуалке сбивается время. Тут все просто – монтируем образ, предоставляемый VirtualBox-ом, и выполняем

sudo /media/cdrom/VBoxLinuxAdditions-x86.run

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

Настройка Samba

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

Устанавливаем самбу:

sudo apt-get install samba

и прописываем такой себе минимальный конфиг (/etc/samba/smb.conf):

[global]
workgroup = WORKGROUP
interfaces = lo eth1
bind interfaces only = yes

security = share
map to guest = bad user

usershare allow guests = yes
guest account = %username%

[home]
path = /home/%username%
guest ok = yes
guest only = yes
read only = no
directory mask = 0755
create mask = 0644

С таким конфигом можно заходить из Windows на \\192.168.56.101\home и смотреть домашнюю папку своего пользователя.

Хосты

Чтобы не прописывать виртуальные хосты по несколько раз (на самой виртуалке, на машине-хозяине, на других виртуалках), имеет смысл настроить легонький DNS-сервер dnsmasq. Я до этого пока не добрался, прописываю хосты ручками.

Резюмируя

Вот и все. Пожалуй, все.

Я понимаю, что пишу не в стиле руководства для новичков – увы, излагать в духе «запустите sudo nano… кстати, nano – это такой текстовый редактор… для начала найдите на клавиатуре буковку эс… эс как доллар» я терпеть не могу. Гугл с удовольствием поможет разобраться в мелких деталях.

Надеюсь, помогу кому-нибудь слезть с денвера или Ruby for Windows в адекватную для веб-разработки среду. Ну или бросить мытарства с гномами-кедами-компизами без всякого ущерба для работы.

Вопросы? Предложения?

Что нам понадобится? (Более-менее) современный процессор, Windows, VirtualBox, образ Default Linux и немного волшебного соуса.

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

Базовая настройка

Искренне надеюсь, что у тебя получится установить Ubuntu в виртуалбокс. Единственный момент, который я бы хотел уточнить, это настройка сети.

Сетевые адаптеры

В VirtualBox есть три вида сетевых адаптеров: bridged, NAT, и host-only. По умолчанию VirtualBox создает для виртуалки один bridged-адаптер. Этот адаптер регистрирует виртуалку как еще одну машину в сети машины-хозяина, и я нахожу это крайне неудобным. Поэтому я подключаю к виртуалке два адаптера:

NAT-адаптер проксирует соединение от виртуалки через соединение машины-хозяина в Интернет.

Host-only адаптер создает виртуальную сеть без выхода в мир. В этой сети регистрируются все виртуалки, имеющие host-only адаптер, что удобно использовать для отладки сайтов, как с машины-хозяина, так и с других виртуалок (IE на XP, например).

Использование такого набора адаптеров в Linux требует особой настройки сети (например, DHCP не имеет смысла), о которой я расскажу попозже – работать будет и «из коробки».

Установка VirtualBox в виде Windows-сервиса

Я никак не понимаю, почему такая важная возможность не включена в ядро VirtualBox. Так или иначе, после долгих поисков удобной утилиты я нашел vboxctrl. Она позволяет запускать сколько угодно (сколько в память влезет, извращенец) виртуальных машин в качестве полноценных сервисов, которые и засыпают, и просыпаются, и корректно завершают работу вместе с Windows, и уж разумеется не висят в панели задач (а первый месяц я все же мучался, попадая alt+tabом в виртуалку). При этом vboxctrl не мешает запускать обыкновенные виртуалки, например, с той же XP.

Настройка vboxctrl тривиальна: его нужно скачать и указать в ini-файле путь к машине.

Рекомендую указать ShutdownCommand = savestate – виртуалка будет мгновенно включаться и выключаться с полным сохранением окружения.

После настройки vboxctrl выполняем vboxctrl -i – получаем сервис. Он запускается вместе с Windows, даже без логина. Останавливают и запускают его через обыкновеную панель сервисов.

SSH

Раз мы остались без прямого окна в виртуальную машину, придется (не то слово) настраивать SSH. На самом деле нужно было это сделать еще до сервисализации виртуалки. Настройка SSH заключается в установке openssh-server на Linux, PuTTY на Windows и пробрасывании SSH-ключа.

В следующей статье – SSH, настройки сети, Samba, безопасность и другое.

Месяца четыре назад я понял, что бороться с графическим интерфейсом Убунты (то есть с Gnome) бессмысленно. Равно как и мириться. Увы, приходится только принять как факт, что крупные разработчики дектопного ПО не видят линукс в списке целевых ОС. На это натыкаешься постоянно. Ладно, можно хвалиться шикарной консолью и там возможностью «все под себя настраивать» (в особо тяжелых случаях – пересобирать). Но будьте честны и положите на противоположную чашу весов тормозящий Браузер и, скажем, невозможность без бубна подключить к компьютеру банальнейшую нокию.

При всем при этом разрабатывать серверное ПО (скажем попроще, сайты) на Windows – это как учиться в универе: даже если все правильно сделаешь, все равно потом работать будет. Особенно если это сайты на Rails.

Я решил, что сильные стороны данных ОС можно совмещать, компенсируя недостатки одной преимуществами другой. Тут представьте, пожалуйста, иллюстрацию про дружащих пингвина с окном или что-нибудь такое.

Речь идет о виртуальном Linux-сервере под VirtualBox на Windows. Да, именно так я и живу последние четыре месяца. Поверьте, это гораздо приятнее использования Wine для запуска игрушек и перехода с Firefox на Chrome, потому что первый тормозит.

По поводу производительности: Ubuntu 10.04, которая крутится у меня постоянно в фоновом режиме, практически не утруждает полуторагигагерцный процессор моего CULV-ноута. Да и с чего бы ей его утруждать – современные технологии виртуализации позволяют как память, так и процессор (да и жесткий диск) под виртуалку выделять по мере необходимости.

Измерений скорости я не производил, но субъективно сайты на Rails работают вполне комфортно, а это уже (очень, очень) хороший показатель.

Недостатки: раздельная файловая система. Приходится прокидывать Samba, либо монтировать папки внутрь виртуалки с помощью vboxfs. Невозможность работать с файлами, находящимися под Windows, средствами консоли (не считая smbfs и, некоторым образом, cygwin). Не работают IDE, считающие своим долгом поменять мне database.yml (привет, НетБинз) и вытворять прочие шалости, которые положено делать руками в консоли.

Преимущества: мгновенное засыпание/пробуждение виртуалки (а ваши линуксы уже уходят в hibernate?). Благополучный вход и выход из хибернейта вместе с виндой. «Чистое» серверное окружение линукса. Возможность при переустановке ОС полностью сохранить рабочее окружение. Возможность отказаться от пароля sudo.

Меньше слов и больше дела в следующей статье.

Можно, конечно, делать это с помощью Google Analytics и вытягивать информацию оттуда, но, по-моему, это слишком сложное решение для такой простой задачи – потому-то и был написан этот плагин.

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

class PostsController
  def show
    # ...
    track_page_view(@post)
  end
end

При этом создается новый объект PageView с данными о посещении. Повторные посещения тем же пользователем не учитываются. Посещения ботов тоже не учитываются.

Последний раз я занимался кешированием страниц на сайте без аутентификации. Что даже более важно – сайт этот для всех выглядит одинаково, поэтому проблему отдачи страниц из кеша можно было легко сгрузить на Апач. К сожалению, так легко кешируются только самые простые сайты.

На этот раз стратегия такая: кешируем все страницы, но только для незалогиненных пользователей. Фишка в том, что факт залогиненности можно замечательно отследить сервером на основании куков и отдача кеша будет происходить без участия Rails. Для сайтов, скажем так, несоциальных, то есть таких, где авторизация не является обязательным действием, такая стратегия очень хорошо снижает нагрузку на сервер.

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

Flash, в смысле уведомления

Наиболее очевидный динамический элемент страницы – флеш. Чтобы выводить флеш на закешированных страницах, Pivotal Labs когда-то делали плагин CacheableFlash, но он рассчитан на Prototype. Потому-то я его и портировал в плагин CacheableFlash for jQuery.

Принцип работы плагина прост: в after_filter флеш заносится в куку, а в яваскрипте забирается оттуда. Надо заметить, что это не работает с flash.now, что, по-моему, вполне логично, поскольку flash.now нужен только на динамических страницах типа форм. Выводить его придется отдельно. Вообще у меня это таким хелпером делается:

def render_flash
  messages = {:error => [], :notice => []}
  flash.each do |type, message|
    messages[type] ||= []
    messages[type] << message
  end
  messages.to_a.map do |m|
    content_tag('div', m[1].join('<br/>'), :class => ['flash',m[0]].join(' '))
  end.join
end

Он и flash.now выводит, и место под динамический флеш подготавливает.

Другие элементы

Остальные динамические элементы – у меня на CarGid это был счетчик объявлений, отобранных пользователем «в блокнот» – выводятся таким же способом. Разумеется, нужно помнить, что объем кук не резиновый и что особо ценную информацию туда лучше не писать (хотя какая ценная информация у незалогиненного пользователя?)

Большие динамические элементы можно подгружать отдельным запросом. Сам понимаешь, что такое решение гораздо хуже.

Обновление кеша в результате действий незалогиненных пользователей

У меня незалогиненные пользователи могут оставлять комментарии. Разумеется, после добавления комментария его нужно показать пользователю – поэтому страницу с комментариями нужно убрать из кеша.

Настройка кеширования в контроллерах

По умолчанию рельсы кладут кеш прямо в public. Разумеется, это нам не подходит, потому кеш нужно перенести в public/cache:

# config/environments/production.rb
config.action_controller.page_cache_directory = File.join(RAILS_ROOT, :public, :cache)

Чтобы кеширование происходило только без наличия залогиненного пользователя, замечательно подходит условно-стандартный метод Authlogic current_user:

class MainController < ActionController::Base
  caches_page :index, :unless => :current_user
end

Остается растыкать caches_page по контроллерам, чтобы Rails начали складывать в кеш правильные страницы.

Настройка nginx

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

# убираем слеш из конца URL - его любят навешивать некоторые обозреватели
rewrite ^(.+)/$ $1 permanent;
 
# запросы POST можно смело передавать прямо в Rails
if ($request_method !~ ^(GET|HEAD)$) {
  break;
}
 
# эта директива запрещает прямой доступ к каталогу cache извне
location ^~ /cache {
  internal;
}
 
# есть куки Authlogic - отключаем кеширование
if ($cookie_user_credentials) {
  break;
}
 
# наконец, проверяем наличие страницы в кеше и отдаем ее оттуда
if (-f $document_root/cache/index.html) {
  rewrite ^/$ /cache/index.html last;
}
if (-f $document_root/cache/$request_uri) {
  rewrite .* /cache/$request_uri last;
}
if (-f $document_root/cache/$request_uri.html) {
  rewrite .* /cache/$request_uri.html last;
}

Это все, что касается nginx. Наверно, надо заметить, что переместить папку с кешем из-под document_root не получится. Можно сделать симлинк, если очень хочется.

Чем плох Slicehost?

Год и десять месяцев назад я переехал с шаред-хостинга на Slicehost. Поскольку ничего толком о впсках я не знал, выбрал самых надежных и популярных. Линод был на втором месте, кстати.

Чем плох слайсхост? Slicehost прекрасен! Никаких к ним нареканий нет, ни по аптайму, ни по предоставляемым услугам. К тому же, они достаточно либеральны с оплатой, один раз даже на неделю разрешили задержаться.

Да вот пинг из Украины к датацентру Slicehost в Миссури составляет порядка 250 мс. Многовато.

Почему Linode?

Linode, надо сказать, не менее респектабельный хостер, чем Slicehost.

У Linode недавно появился датацентр в Лондоне. Пинг до него около 80 мс – не такой хороший, как у национальных хостеров, но вполне достаточный. Кроме этого, Линод позволяет переносить машину из одного датацентра в другой совершенно бесплатно и автоматически (чтобы сделать это на слайсхосте, нужно создавать еще одну машину в новом ДЦ и клонировать в нее старый диск).

У Linode процентов на 20 меньше цены. Кроме того, Линод позволяет докупать ресурсы по отдельности – например, только память, что существенно для наших любимых рельсов.

У Linode очень удобный менеджер DNS. Например, создание типичной доменной записи (A + A для www и mail + 5 NS + MX) происходит автоматически. Кроме того, Линод позволяет автоматически переносить DNS-записи, но для этого исходный сервер должен поддерживать AXFR, Slicehost, например, этого сделать не дает.

Кстати, GoDaddy порадовали возможностью сменить NSы всем доменам сразу.

Еще Linode самостоятельно рисует графики загрузки процессора, диска и сети. Мелочь, а приятно.

Резюмируя: если ты живешь в Украине и выбираешь VPS для своих проектов, если тебя не смущает отсутствие русскоязычной поддержки и ты не настаиваешь на расположении сервера в UA-IX, бери Linode. Будет хотя бы уверенность, что его не конфискуют вместе с соседями-порнографистами.

Почему nginx?

Я недавно настраивал другой VPS (кстати, на uh.ua, тоже пока не расстраивают) для CarGidа, вот тогда и оценил, что nginx ест намного меньше памяти, чем апач. Это ну очень критично на впске. Настолько критично, что можно отказаться от привычек и лени и посмотреть в сторону этого замечательного сервера, о котором и без меня написано много хорошего.

Если ты не в курсе, то Passenger поддерживает nginx, поэтому рельсы под ним поднимаются никак не сложнее, чем под апачем. И намного проще, чем PHP.

В чем же разница между этими функциями? А вот в чем:

>> Time.now.class
=> Time
>> Time.now.to_s :db
=> "2010-06-04 19:00:00"
>> Time.zone.now.class
=> ActiveSupport::TimeWithZone
>> Time.zone.now.to_s :db
=> "2010-06-04 16:00:11"

Дело в том, что Rails, начиная с версии 2.1, хранят время в базе в UTC, а при сохранении и чтении переводят его из и в часовой пояс, используемый в приложении.

За перевод времени в UTC отвечает, как ни странно, метод to_s(:db). Точнее странно то, что, хоть он и доступен у объекта типа Time, работает он неверно и отдает время в текущем часовом поясе. Если использовать Time.now в условиях запроса – они сместятся на определенное количество часов. Если записывать Time.now в базу – в базу запишется неправильное значение, потому что при чтении рельсы лишний раз добавят к нему смещение часового пояса.

Короче, наиболее простым и адекватным решением этой проблемы будет замена по всему проекту Time.now на Time.zone.now.

…А еще из-за это проблемы не стоит использовать в запросах функцию MySQL NOW() и аналогичные, поскольку они ничего не знают о настройках рельсов.