воскресенье, ноября 19, 2006

Как назвать сервер

Как-то просматривая свою статистику я обратила внимание на несколько дружно заходящих ко мне хостов каких-то химиков, все они были названы по номерам энзимов: enzyme-а дальше номер. После этого я решила как-нибудь написать пост по поводу идей по именованию хостов и некоторое время рыла Интернет по этому поводу. Вообще системные администраторы подходят к задаче именования серверов творчески. Лучшим доказательством тому является RFC2100 - The Naming of Hosts, написанное в стихах.

Птицы, животные, планеты - все это старые добрые варианты, но это уже старо и неоригинально. Хотя вот интересный вариант: использование названий птиц для поддоменов:
Кондоры (condor) - машины разработчиков
Вороны (raven) - серверы данных
Соколы (falcon) - машины техподдержки
Ястребы (hawk) - интранет
Сапсаны (peregrin) - машины менеджеров
Совы (owl) - машины тестеров

Какие-либо географические названия не очень хорошо подходят для этой цели. Если использовать названия стран или городов, то обращаясь к какому-либо серверу думаешь, что он именно в этом городе и установлен. И сервер moscow.host.ru, установленный в Питере, это как-то странно. Есть еще названия гор и тому подобные вещи. Но они быстро заканчиваются.

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

Вариант, который мне понравился больше всего: драгоценные камни. Топаз, аметист. Жаль, что мне ничего именовать не приходится.

Вот еще цитата из форума для тех, у кого действительно много серверов
Я предпочитаю квантовые/субатомные частицы. Если это рапространить на молекулярный уровень, то у тебя получаются буквально десятки тысяч имен. (Может быть сотни тысяч, я не проверял.)


Модно давать имена серверам по именам богов. Приятно, что у тебя серверной стоит не просто железяка, а Бог Солнца Ра. В ход идут всякие боги: греческие, египетские... Для серверов, как-либо логически связанных можно использовать мифических близнецов, просто парных персонажей. Ромул и Рем, например. В связи с этим мне вспоминается Леденящая Кровь История. Про то, как системный администратор увлекся религией древних ацтеков. И начал называть сервера именами древних ацтекских богов.
Надо сказать, ацтеки букв на имена не жалели. Каждое из имен - это словосочетание, записанное на древнеацтекском. Например: Кетцалькоатль (Quetzalcoatl, он же «пернатый змей»). Вот он, вот он красавец в своем человеческом воплощении.
(Картинка из Википедии)
Главный у них Huitzilopochtli, деликатно переведенный как Уицилопочтли.
Надо сказать, после этого жизнь в компании стала гораздо веселее.

Еще незаезженные варианты:
  • Видные деятели эпохи возрождения - Ботичелли, ДаВинчи, Микельанджело
  • Имена ураганов
  • Кухонная утварь
  • Персонажи из Винни-Пуха
  • Персонажи из комиксов про Дилберта
  • Покемоны! Их, говорят 152 штуки, надолго хватит
  • Любимые RFC и сетевые протоколы

Ну, и если это все надоело до смерти - случайные слова из словаря

Ссылки по теме:
RFC 1178 - Choosing a name for your computer
Боги ацтеков
SERVER NAMES

вторник, ноября 14, 2006

Блоги сотрудников Microsoft

По ссылке с lenta.ru я нашла список блогов сотрудников Microsoft, пишущих на русском языке. Из них я отобрала те, которые пишут на технические темы, маркетинг меня интересует мало...

Алексей Майков TabletPC team, Redmond
Из интересного только задачка с Майкрософтовского интервью. Но блог начат недавно, посмотрим чего там будет дальше.

Арам Григорян специалист по локализации, Redmond
Меня заинтересовал пост по Юзабилити. Еще там периодически публикуются вакансии, если кому интересно.

Константин Исаков Redmond
Программист в Майкрософте. В какой именно группе - я не поняла.
Обещан С++, даже уже немного есть.

Людмила Фокина группа разработчиков SQL Server, Redmond
Обещает рассказывать о SQL Server. Есть несколько постов по построению индексов, потом наступило затишье. Посты читаются несколько тяжеловато для человека далекого от проектирования баз данных.

Олег Исаков Core File Solutions, Redmond
Блог посвящен технологиям Microsoft для хранения и репликации файлов (Microsoft File Storage solution).

В официальном списке нет еще одного блога, Семена Козлова, Avalon Team, Redmond.
Про разработку он пока ничего не пишет, но есть надежда, что будет.

Updated
:
На самом деле в официальном списке не одного блога не хватает. Буду потихоньку добавлять незаслуженно забытые сюда:
Алексей Пахунов SDE, Windows Kernel
Меня больше всего заинтересовали посты про C++ и COM.

вторник, ноября 07, 2006

Конструирование объектов в Дельфи и С++

Статья Exceptional Safety на блоге The Oracle at Delphi послужила предметом разговора за чашкой чая у нас с мужем, где мы обсуждали насколько же по-разному конструируются объекты в Дельфи и С++.

В С++ порядок конструирования объектов зачастую является источником недопонимания. При вызове конструктора класса сначала конструируется объект базового класса, потом его наследника и так далее. Непонятки начинаются при попытке вызова из конструктора базового класса виртуальной функции.


class CBase
{
public:
CBase()
{
cout<<"CBase::CBase"<<endl;
print();
}
virtual void print()
{
cout<<"print CBase::print"<<endl;
}
};

class CDerived : public CBase
{
public:
CDerived()
{
cout<<"CDerived::CDerived"<<endl;
}
virtual void print()
{
cout<<"print CDerived::print"<<endl;
}
};

int main()
{
cout<<"Creating CDerived"<<endl;
CDerived d;
}


Вывод получается такой.

Creating CDerived
CBase::CBase
print CBase::print
CDerived::CDerived


Поскольку vtable CDerived еще не заполнена на момент вызова функции print, будет вызвана функция CBase::print. В Дельфи таблица виртуальных функций, VMT, заполняется перед началом отработки конструктора и таких проблем не возникает.

type
TBase = class
protected
procedure Print; virtual;
public
constructor Create;
end;

TDerived = class(TBase)
protected
procedure Print; override;
public
constructor Create;
end;

{ TBase }

constructor TBase.Create;
begin
inherited Create;
ShowMessage('TBase.Create');
Print;
end;

procedure TBase.Print;
begin
ShowMessage('TBase.Print');
end;

{ TDerived }

constructor TDerived.Create;
begin
inherited Create;
ShowMessage('TDerived.Create');
end;

procedure TDerived.Print;
begin
ShowMessage('TDerived.Print');
end;


При попытке создать экземляр класса TDerived будут выданы следующие соообщения

TBase.Create
TDerived.Print
TDerived.Create


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

В Дельфи все не так как в С++ и с порядком вызова конструктора. Вообще конструкторов может быть несколько и называться они могут по-разному. Но вызывает программист конструктор базового класса явно и тогда, когда ему удобно. Если считает, что это не нужно, то может вообще конструктор базового класса не вызывать.

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

В Дельфи в такой ситуации идет неявный вызов деструктора. Который уберет то, что было проинициализировано, но не тронет то, до чего дело не дошло. Не тронет он потому, что изначально все ссылки проинициализированы nil'ами, нулями. Те поля, для которых память уже выделена, будут иметь значения, отличные от nil. Для освобождения ресурсов в Дельфи есть деструктор по умолчанию Destroy и метод ему в помощь под названием Free. Destroy никогда не надо вызывать явно, он считается служебным, а Free отрабатывает следующим образом.
if Self <> nil then Self.Destroy;

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

Ссылки по теме:
Thinking in C++, vol.2. 1.Exception Handling, Cleaning up.
[17] Exceptions and error handling, C++ FAQ Lite

суббота, ноября 04, 2006

Статья No Silver Bullet

No Silver Bullet: Essence and Accidents of Software Engineering - это классическая статья Фредерика Брукса о трудностях, возникающих при разработке софта.