Але от проблема — провайдер хоча і видає реальні IP (що не починаються на 10. або 192.168.) але періодично їх міняє (а якщо взагалі не видає то цю статтю далі можна не читати).
Послуга «постійний ІР» рятує, але її надають не всі провайдера, та й коштує вона інколи до половини плати за інтернет.

Для часткового вирішення цієї проблеми існують сервіси типу no-ip чи DynDNS.
Реєструєтесь, встановлюєте на комп’ютер клієнт і отримуєте домен виду user.no-ip.com, який постійно вказує на ваш комп’ютер.
Більшість користувачів це б задовольнило, але не мене

Я б хотів, щоб домен був наприклад macbook.mrgall.com (тобто був би субдоменом в моєму власному домені).

Виявляється це не так вже й складно зробити, достатньо дописати в налаштування DNS такий CNAME запис:

Значення TTL (time to live) потрібно вказати мінімально можливе (в мене це 5хв).

Після цього можна зайти на домашній комп’ютер за допомогою ssh (звісно, якщо у вас на ком’ютері встановлений сервер openssh):

ssh user@macbook.mrgall.com

Найприкольніше це робити сидячи на дивані і керуючи ком’ютером з телефону (для Android’у є ssh-клієнт)

Я пропоную святкувати. Святкувати 8-му річницю дійсно чудового продукту, який зветься Internet Explorer 6!
А як же може бути інакше, якщо він з’явився аж 27 серпня 2001 року (за 2 тижні до трагедії 9/11) але ним і досі користуються 20% інтернет-користувачів в світі (в Україні — 15%)? Мільйони мух не можуть помилятися!
Тому давайте відкинемо всі стереотипи і відзначимо ювілей браузера, який мав, має та ще довго матиме величезний вплив на Веб.

Які ж варіанти святкування? Ось невеликий список того, що ви можете зробити в цей дійсно святковий день. Варіанти йдуть від найпростішого до найрадикальнішого, і нехай кожен веб-майстер обирає самостійно ;)

— Невеликий банер або короткий текст про необхідність дати ювіляру відпочити і пропозицією перейти на актуальні браузери (Opera 9, Firefox 3.5, Internet Explorer 8).
— Великий банер або цілу статтю про те ж саме.
— Блок в шапці сайту, подібний до того, що вже зараз показується на YouTube, Укрбаші, Блогорідері, Блозі Masterpiecer’а та багато інших, якщо зайти на них з ІЕ6 (скріншот для тих, у кого немає можливості це побачити).
— Блок посередині екрану з можливістю його закрити.
— Блок, що буде заміняти собою увесь контент сайту без можливості побачити сайт в ІЕ6.
— Код, що буде спричиняти «вилітання» ІЕ6 (приклад коду в дії).

Запам’ятайте цей день: 27 серпня 2009 року та починайте готуватися вже зараз бо таку подію не можна пропустити (і ще невідомо, чи доживе наш ювіляр до 9-ї річниці ).

Корисні посилання:
Shockingly Big IE6 Warning — плагін для WP
Stop IE6!
Upgrade Browser
Goodbye IE6
IE Death March
IE6 Update
та багато інших — google it!

Дописи в блогах:
Прийшов час смерті Internet Explorer 6!, або не ґвалтуйте труп — Блог masterpiecer’а
Internet Explorer 6: прощання з минулим — Блогорідер
Який браузер кращий? — Sidirom’s Blog
Великий тест браузерів — G3Ds blog
Оголоси війну IE 6 — skinik блоґ
Річниця бразуера Internet Explorer 6 — Блоґ LinuxMan’а
(присилайте пінґбеки або залишайте лінк в коментарях)

Прохання проанонсувати цей заклик до святкувань у Ваших блогах, твіттерах та інших місцях, де ви зазвичай пишете про подібне

Ідея полягала в тому, що варто зробити власні ДНС-сервери, а потім, при переїзді, необхідно лише поміняти ІР адреси одного домену, а решта зміниться автоматично.
Але тоді виникла одна проблема — для доменів .org (наприклад ukrbash.org) я не зміг поміняти ДНС-сервери на ns1/ns2.tereveni.org:
NameServer ns1.tereveni.org is not a valid Nameserver
NameServer ns2.tereveni.org is not a valid Nameserver
Я писав у службу підтримки реєстратора, але вони мені так і не сказали, в чому була причина.

Потім я змінив реєстратора але і в нього поміняти ДНС-сервери для ukrbash.org не вийшло (для ukrbash.com і ukrbash.net я їх поміняв без проблем).
Я написав у їх службу підтримки — мені відповіли, що треба почекати 24 години після трансферу, а потім вже міняти ДНС-сервери. Я для гарантії почекав 2 дні і ще раз спробував — знову невдало.
Я написав ще раз — і мені нарешті пояснили, в чому справа.
Виявляється, що для того, щоб поставити ns1/ns2.tereveni.org як ДНС-сервери для ukrbash.org, необхідно щоб ns1/ns2.tereveni.org були ДНС-серверами для tereveni.org — це вимога зони .org

tereveni.org в мене підтримувався ДНС-серверами реєстратора dns.com.ua.
Довелося перевести tereveni.org на ns1/ns2.tereveni.org, але щоб це все працювало, необхідно, щоб у tereveni.org були такі записи:
tereveni.org. IN NS ns1.tereveni.org.
tereveni.org. IN NS ns2.tereveni.org.
ns1.tereveni.org. IN A 62.149.12.21
ns2.tereveni.org. IN A 195.149.112.1
Якщо не буде 3 і 4 рядків, то відбудеться dns loop і вся конструкція перестане працювати.
Тепер всі мої домени мають ДНС-сервери ns1/ns2.tereveni.org і я можу перенести їх на інший хостинг протягом 5-10хв (+ доба на оновлення кешів ДНС-серверів по всьому світу)

P.S. Це не означає, що я вже збираюсь міняти Колокол на якийсь інший хостинг (Колокол мене повністю влаштовує) але за півроку-рік все може помінятися.

• новий двигунець — зараз фактично є набір скриптів, що мало пов’язані між собою
• англомовна версія — хоча б інформація про мене та резюме
• новий дизайн — є декілька ідей, але вони ще на стадії створення макету
• XHTML 1.0 Strict та utf8 — зараз це є лише в блозі
• AJAX в галереї та скриптах — потрібно не відставати від прогресу
• та багато іншого…

Почав я з 4-го пункту, а саме з перекодування бази в utf8.
Там знаходяться таблиці WordPress’у, галереї, подкасту і т.п.

Таблиці галереї були в cp1251, тому перекодування їх в utf8 пройшло без проблем.
В скрипті галереї я додав лише один рядок (оскільки вона і досі генерує сторінки в cp1251, це зміниться лише після переходу на новий двигунець).
mysql_query("SET NAMES 'cp1251';", $link);

Таблиці подкасту я створював відносно недавно, тому вони вже були в utf8

Таблиці WordPress’у на перший погляд були в cp1251, але спроба поміняти кодування закінчилася невдало — кириличний текст став таким: неопубліковане

Після ґуґління™ я знайшов причину цих глюків.
Раніше (ще 2-3 роки тому) MySQL по замовчуванню налаштовували на cp1251 (якщо це вітчизняний хостинг) або latin1 (якщо зарубіжний). А WordPress взаємодіє з базою в кодуванні utf8 навіть якщо база має зовсім інше кодування.
Тому блоґер спокійно веде свій блоґ навіть не знаючи, які проблеми у нього виникнуть в майбутньому
А ці проблеми рано чи пізно з’являться — після переходу на інший хостинг або після оновлення ПО на поточному. Новий MySQL по замовчуванню починає використовувати utf8 і в блозі збивається кодування.
Це можна тимчасово виправити за допомогою таких рядків в wp-config.php
define('DB_CHARSET', 'cp1251');
define('DB_COLLATE', 'cp1251_general_ci');
Фактично це повернення статусу-кво — для MySQL кодування бази є cp1251 а WordPress взаємодіє з нею в кодуванні utf8.

В такому вигляді мій блоґ міг жити і далі, але я люблю порядок в усьому
Що потрібно зробити — змінити кодування бази (cp1251 -> utf8), при цьому не перекодовуючи базу (оскільки текст в ній вже є в utf8).

Ну а що ж тут важкого? Беремо дамп бази в phpmyadmin, відкриваємо його в текстовому редакторі як файл в кодуванні utf8 і скрізь міняємо
DEFAULT CHARSET=cp1251
на
DEFAULT CHARSET=utf8
Але проблема тут в тому, що phpmyadmin бачить, що база в нас в cp1251, тому при експорті автоматично перекодовує її cp1251 -> utf8 (а цього нам якраз і не треба, оскільки база і так вже в utf8).

Є інших спосіб — потрібно змінити тип усіх текстових полів таблиці (CHAR, VARCHAR, TINYTEXT, TEXT, MEDIUMTEXT, LONGTEXT) на їх бінарні аналоги (BINARY, VARBINARY, TINYBLOB, BLOB, MEDIUMBLOB, LONGBLOB), потім змінити кодування таблиці на utf8 а потім поміняти тип полів назад на текстові.
Лінк в тему — Перенесення Wordpress блогу на інший хостинг
Таблиць у нас 10-15 (залежно від встановлених плагінів) тому це не шлях справжніх самураїв ІТ’шників

Я знайшов швидший спосіб, але він потребує доступу до хостингу по ssh.
Експортуємо базу в тому вигляді, в якому вона є
mysqldump -u користувач --password=пароль --opt --default-character-set=cp1251 --skip-set-charset -Q база > dump.sql
Завантажуємо дамп собі на комп’ютер, відкриваємо його як файл в кодуванні utf8, скрізь міняємо
DEFAULT CHARSET=cp1251
на
DEFAULT CHARSET=utf8
і зберігаємо (теж як utf8, бажано без BOM).
Далі створюємо нову базу (вже в кодуванні utf8) та імпортуємо туди цей файл.
Потім модифікуємо wp-config.php (змінюємо базу зі старої на нову) і, для повної гарантії, додаємо такі рядки:
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', 'utf8_general_ci');

Все, можна спокійно писати в блоґ

Логін зазвичай використовується однаковий (звісно, якщо він не зайнятий), а пароль вже після 5-го разу набридає придумувати і користувачі починають використовувати один і той же пароль на усіх сайтах.

Продвинуті користувачі використовують 2-3 версії паролів для різніх рівнів безпеки — наприклад:

• чати/форуми/блоґи (~90%) — найпростійший пароль
• е-пошта/інтернет-пейджери (~7%) — трохи складніший
• онлайн-банк/електронні гроші/інші важливі сервіси (~3%) — найскладніший

Виникає питання — а чи не має такої технології, що дозволяє на усіх сайтах використовувати один логін/пароль?

Така технологія є, і називається вона OpenID.

Суть її ось в чому — ви реєструєтесь на одному сайті, який є OpenID-провайдером, і використовуєте цей логін на усіх сайтах, що підтримують вхід на сайт за допомогою OpenID.

Де ж знайти OpenID-провайдера?
Виявляється нічого шукати не треба, скоріше за все у вас вже є OpenID, якщо ви зареєстровані на одному з цих сайтів:

• livejournal.com
• blogger.com
• flickr.com
• wordpress.com
• yahoo.com
• yandex.ru
• sourceforge.net

Якщо у вас є блоґ на livejournal.com то ваш OpenID буде ім’я.livejournal.com
Ви можете використовувати його для входу на будь-який сайт, де побачите ось таку іконку:
Наприклад, спробуйте авторизуватися на УкрБаші (де я тиждень тому додав підтримку цієї технології ) і для вас автоматично створиться та авторизується користувач ім’я.livejournal.com (при традиційній реєстрації потрібно вводити логін/пароль і активувати профіль через лінк, що приходить на вашу е-пошту).
Також підтримку OpenID має мій блоґ та блоґ УкрБашу (для коментування дописів).

Але автоматична реєстрація на сайті це ще не все. Ви можете входити на сайт, використовуючи свій OpenID. При цьому, якщо ви обрали постійну авторизацію на сайті OpenID-провайдера, то вводити пароль не потрібно і вхід відбудеться автоматично (крім 1-го разу).
На УкрБаші можна до вже існуючого користувача додати OpenID і використовувати його для входу.

Створений користувач буде мати ім’я та адресу сайту, що використовується як OpenID.
Але чи можна використовувати власний сайт як OpenID?
Виявляється можна — мій OpenID це mrgall.com

Щоб використовувати власний домен як OpenID потрібно:

1. Обрати OpenID-провайдера. Ви можете використовувати ваш існуючий профіль (наприклад на LiveJournal, Яндексі чи Yahoo) або зареєструватися на спеціальному OpenID-провайдері (наприклад myopenid.com).

Я зареєструвався на myopenid.com і мій OpenID це mrgall.myopenid.com.

2. Дізнатися код, що потрібно додати на ваш сайт. Для цього потрібно зайти на вашу сторінку на сайті OpenID-провайдера і у вихідних кодах сайту знайти такі рядки:

<link rel="openid.server" href="http://адреса.серверу" />
<link rel="openid.delegate" href="http://ваш.OpenID" />
<link rel="openid2.provider" href="http://адреса.серверу" />
<link rel="openid2.local_id" href="http://ваш.OpenID" />
<meta http-equiv="X-XRDS-Location" content="http://адреса.сторінки.на.сервері" />

Це записи для OpenID версій 1 і 2, якщо ваш OpenID-провайдер підтримує OpenID лише 1ї версії то рядки 3й та 4й будуть відсутні. 5й рядок теж може бути відсутній.
Якщо ви не знайшли 2й та 4й рядки то не біда, ви можете зробити їх самостійно, підставивши адресу вашої сторінки на сайті OpenID-провайдера.

Якщо ви вирішили використовувати livejournal.com то ваш код буде таким:

<link rel="openid.server" href="http://www.livejournal.com/openid/server.bml" />
<link rel="openid.delegate" href="http://ім’я.livejournal.com" />
<meta http-equiv="X-XRDS-Location" content="http://ім’я.livejournal.com/data/yadis" />


Мій код:

<link rel="openid.server" href="http://www.myopenid.com/server" />
<link rel="openid.delegate" href="http://mrgall.myopenid.com" />
<link rel="openid2.provider" href="http://www.myopenid.com/server" />
<link rel="openid2.local_id" href="http://mrgall.myopenid.com" />
<meta http-equiv="X-XRDS-Location" content="http://mrgall.myopenid.com/xrds" />


3. Додати цей код на ваш сайт. Це потрібно зробити між <head> та </head>.
Приклад ви можете побачити в мене на головній сторінці.

Після цих 3х кроків ви зможете використовувати ваш домен як OpenID

Вдалого користування

Для веб-майстерів, що хочуть додати OpenID на свій сайт:
PHP OpenID Library
Интеграция OpenID в ваш сайт
WP-OpenID

– UTF-8 (Unicode), яка все більше набирає популярності, як серед ОС так і в Інтернеті
– CP1251 (ака Windows-1251), яка залишилась в спадок від старих версій Windows
– KOI8-U (або KOI8-R), яка залишилася в спадок від старих версіх *nix’ів (Linux, FreeBSD)
– MacUkraine (або MacCyrillic), яка залишилася в спадок від старих версіх MacOS
– CP866, яка залишилася в спадок від DOS’у
– ISO 8859-5, яка майже ніде і не використовувалась

Зараз відбувається міграція на UTF-8, що позбавляє проблем з використанням різних мов.

На одному з моїх проектів я аналізую, звідки користувачі заходять на сайт (в основному мене цікавлять, за якими ключовими словами сайт знаходиться в пошукових системах).
І ось тут виникла проблема з кодуваннями, бо деякі пошукові системи (наприклад Яндекс) ще й досі використовують CP1251, а Google може використовувати різні кодування (в залежності від параметрів).
Тому я написав функцію на php (використавши функцію для визначення UTF-8), яка автоматично визначає кодування (підтримується UTF-8, CP1251 та KOI8-U) і перекодовує текст в потрібне.

Вихідний код: Автоматичне визначення кодування

Опис:
string autoencode (string $string, [string $encoding])

Приклад використання:

include("шлях/до/autoencode.php");
$text_utf=autoencode($text, 'utf-8');

В цієї функції є недоліки. Основний – вона визначає кодування, підраховуючи коди маленьких літер (яких в звичайному тексті – більшість). Але якщо в тексті переважають великі літери, то відбувається плутанина між CP1251 та KOI8-U

P.S. Якщо в когось є кращий алгоритм, поділіться
P.S.S. Таблиця з кодуваннями кирилиці

Історично склалося так, що сервери називали ім’ям сервісу, що вони надають.
Наприклад:
ftp.example.com (FTP)
news.example.com (Usenet newsgroup)
mail.example.com (Mail)
www.example.com (World Wide Web)
і т.п.
Тому виникла традиція додавати www. до домену у адресі веб-сайту.
Але насправді www.example.com це лише субдомен у домені example.com і ніякої технічної необхідності у ньому немає.

Коли ви додаєте домен до хостингу, субдомен www автоматично створюється і ваш сайт стає доступним одразу за двома адресами – example.com та www.example.com
Кожен веб-майстер самостійно вирішує, який з них обрати за основний.
Я вже з рік на своїх сайтах використовую варіант example.com, а з www.example.com роблю переадресацію на example.com (наприклад – www.mrgall.com)
Переваги:
- Ваш домен стає на 4 символи коротшим (швидше набирати, швидше диктувати (не треба казати “дабл ю дабл ю дабл ю крапка …”), лаконічніше виглядає і т.п.)
- Ваш домен стає на 1 рівень нижчий (www.example.com – домен 3-го рівня, example.com – другого), отже визначення його ІР адреси відбувається швидше.
- Немає проблем з пошуковими системи (коли вони паралельно індексують example.com та www.example.com або у видачі видають не той домен, який ви обрали за основний).

Найпростіше зробити переадресацію з www.example.com на example.com можна за допомогою mod_rewrite, додавши в .htaccess таке:

RewriteEngine on
RewriteCond %{HTTP_HOST} ^www.example.com
RewriteRule (.*) http://example.com/$1 [R=301,L]

Тоді всі запити виду:

http://www.example.com/path/file.html

будуть переадресовуватися на

http://example.com/path/file.html

Посилання в тему:
no-www.org
nowww.ru

Єдине, за чим потрібно слідкувати – аби не змінилися ІР адреси ДНС-серверів, що підтримують ваші домени, інакше домени перестануть працювати.
В цьому випадку треба оновити ІР адреси субдоменів ns1 та ns2.

Зручний скрипт для перевірки роботи ваших доменів – Squish.net dns checker

“А еще я и на машинке могу, и крестиком вышивать” © Матроскин

Всі нові проекти я верстаю за допомогою XHTML (переписати існуючі або просто виправити помилки, в тому числі і на цьому сайті, все ніяк руки не доходять… )
І час від часу виникає необхідність перевіряти коректність документу. Звісно є валідатор від w3c але для його використання потрібно робити зайві рухи (що для програміста не допустимо )
Є спосіб, як перевіряти документи на валідність прямо в браузері (я використовую Oper’у, але в Firefox це теж буде працювати):
Потрібно ввімкнути обробку XHTML документів через XML парсер.
Якщо сайт написаний за допомогою php, то це можна зробити так:

if (stristr($_SERVER["HTTP_ACCEPT"],"application/xhtml+xml")) header("Content-type: application/xhtml+xml");
else header("Content-type: text/html");

Трохи теорії. XHTML це мова розмітки, що базується на XML (на відміну від HTML, що базується на SGML).
Тому XHTML-документ має бути в першу чергу коректним XML-документом (всі теги мають закриватися, параметри бути в лапках і т.п.).
Також XHTML має передаватися з MIME-типом application/xhtml+xml.
В цьому випадку документ буде оброблятися через XML парсер.

Чому на 99.9% сайтів XHTML передається як text/html?
Бо є такий хрі… чудовий браузер IE6, який погано підтримує XHTML і не розуміє application/xhtml+xml.
Інші браузери (Opera, Firefox, Safari) коректно сприймають application/xhtml+xml тому обробляють XHTML через XML парсер і виводять повідомлення про помилки, якщо документ не коректний.

А навіщо взагалі перевірка на коректність? Адже моя сторінка без проблем показується в усіх браузерах, що ж ще треба?

Показується, бо розробники браузерів витратили дуже багато зусиль на написання двигунців, які, незважаючи на помилки, більш-менш нормально показують сторінки з помилками. Але навіщо примушувати браузери відвідувачів кожного разу виправляти ваші помилки, якщо це можна зробити 1 раз на сервері?
Звісно, потрібно дуже багато зусиль, щоб виправити помилки в уже існуючих проектів. Але, принаймні, нові проекти слід писати без помилок. Тоді, з часом, Інтернет очиститься від сайтів, код яких містить помилок більше, ніж контрольна двієчника. Двієчнику поставлять його заслужену двійку, а хто ж оцінить таких веб-майстрів, якщо більшість відвідувачів не заглядають в код сторінки?
Зараз використовувати application/xhtml+xml на готовому сайті ніхто не буде – бо є значний відсоток відвідувачів, що використовують IE6, але для розробки і відладки такий режим чудово підходить
Я ввімкнув його (правда лише для себе) на УкрБаші і вже виправив 5 чи 6 помилок, яких раніше не помічав. Вони були не на головній сторінці, а валідатором зазвичай перевіряється лише головна.