Без рубрики
Что ж, смену хостинга можно считать законченной, данные пересены, сервер настроен, домены уперты.
Чем плох 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.
Нокия тут в Украине развернула масштабную кампанию по продвижению навигационных телефонов – на биллбордах, по телевизору, все такое. Захотелось посмотреть, что ж там за карты.
(Я последнее время на своей Nokia 5800 пользуюсь Мобильными Яндекс.Картами, поскольку их кеш можно скачать через компьютер и экономить потом трафик. Увы, МЯК не умеют прокладывать маршруты, да и к тому же являются растровыми.)
Итак. Ovi Maps предустанавливаются на все свежие смартфоны от Nokia. Свежую версию можно скачать с сайта Nokia. Свежие карты можно скачать с помощью Ovi Suite.
…Прискорбно, но на картах Украины, которые скачиваются из Ovi Suite, есть только крупные дороги, даже Киев практически не детализирован.
Немного погуглив, я выяснил, что можно совершенно безвозмездно загрузить и другую версию карт – с городами. С помощью Nokia Map Loader. Вот только ссылки на этот самый Map Loader с сайта Нокии нет.
Нашелся Nokia Map Loader на CNET – очевидно, вполне себе официальная версия.
Map Loader загружает 70 мегабайт карт вместо тех 7, что загружает Ovi Suite – на них оказалась, помимо всего прочего, детальная карта Днепропетровска с возможностью прокладывать маршруты, как автомобильные, так и пешие.
Я тут занялся оптимизированием RentFeed, где большую часть страниц можно положить в кеш и обновлять несколько раз в день. Самый тупой и быстрый кеш в виде статических файлов, отдаваемых непосредственно апачем.
Рельсы умеют такое делать «из коробки», практически одной строчкой:
class SomeController < ApplicationController
caches_page :index
def index
end
end
Все! Кеш уже работает. Правда, почему-то рельсы не предусматривают две вещи. Кеш не работает с GET-параметрами – раз. Хранится прямо в public – два.
GET-параметры
Тут все просто: хочешь, чтобы для разного набора параметров кешировались разные страницы – помещай параметры в путь. Кстати, к таким ссылкам и Google лучше относится.
Для меня это в первую очередь касалось постраничной разбивки. Если ты используешь will_paginate, то тебе достаточно вынести URL с номером страницы в таблицу роутов:
map.resources :items
map.paged_items '/items/page/:page', :controller => 'items', :action => 'index'
Перемещаем кеш в более удобное место (например, в public/cache)
Путь к кешу указывается в конфиге:
# config/environments/production.rb
config.action_controller.page_cache_directory = RAILS_ROOT+"/public/cache/"
Осталось научить Apache забирать кеш из нужного каталога. Решается это довольно простыми реврайтами, не считая того, что отдавать нужно только файлы, которые точно лежат в кеше – иначе Rails станет получать неправильные пути и перестанет работать.
В общем, нужен вот такой .htaccess:
# public/.htaccess
RewriteEngine On
# убираем слеш в конце пути
RewriteCond %{REQUEST_URI} ^([^.]+)/$
RewriteRule ^[^.]+/$ /%1 [QSA,L]
# перенаправляем в кеш, только если там есть файл
RewriteCond %{THE_REQUEST} ^(GET|HEAD)
RewriteCond %{DOCUMENT_ROOT}/cache/%1 -f
RewriteRule ^.+$ /cache/%1 [QSA,L]
# то же для страниц без расширения (к ним Rails приписывает .html)
RewriteCond %{THE_REQUEST} ^(GET|HEAD)
RewriteCond %{REQUEST_URI} ^([^.]+)$
RewriteCond %{DOCUMENT_ROOT}/cache/%1.html -f
RewriteRule ^[^.]+$ /cache/%1.html [QSA,L]
# то же для пустого пути
RewriteCond %{THE_REQUEST} ^(GET|HEAD)
RewriteCond %{DOCUMENT_ROOT}/cache/index.html -f
RewriteRule ^$ /cache/index.html [QSA,L]Теперь можно очищать весь кеш вместе обыкновенным rm -rf public/cache/*.
Если на работу не берут – твоя проблема не в том, что на дворе кризис, рабочих мест мало, что у тебя плохое резюме, что ты мало вращался в каких-то там «кругах», прочитал мало книжек или плохо учился (ничему не учили?) в универе.
Тебе просто нужен практический опыт. Практический. Опыт.
Бери свою фантазию в руки, сам придумай себе проект и реализуй его самостоятельно. Или клонируй чужой, если фантазии не хватает (а вообще я не представляю, куда без нее в программисты).
Просто привыкай проектировать и писать код. А потом иди на собеседование другим человеком. С опытом.
Не надейся, что подвернется случай или что опыт придет сам собой. Не ищи помощи на фрилансе – там на начальном уровне проекты скучные и унылые. Не участвуй в опенсорс-проектах – только тебя там не хватало.
Удачи.
UPD: Мое плохое отношение к опенсорсу основывается на большом количестве людей, которые делают из программирования не за деньги, а ради удовольствия какую-то религию, а из себя, соответственно, мучеников за идею и борцов за свободу.
До недавних времен первым делом после создания git-репозитария я добавлял в .gitignore разнообразные служебные и резервные файлы, которыми IDE и редакторы засоряют проект.
Так вот, сделать это можно раз и навсегда, поскольку git поддерживает глобальный .gitignore.
Сотоварищей он не спасет. По-моему это вполне законно – инструментарий у каждого свой, поэтому и резервные копии у каждого свои.
Так вот, сначала сообщаем гиту о наличии глобального файла .gitignore:
git config --global core.excludesfile ~/.gitignore
…а потом отправляем в ~/.gitignore список ненавистных файлов. У меня такой:
*.*.sw*
*~
*.log
Thumbs.db
nbproject
Подробнее о gitignore
Что касается непосредственно разработки на Rails:
- zsh – осваиваю понемногу;
- Vim – универсальный редактор;
- Ruby Enterprise Edition – тешу себя мыслью, что он быстрее обычного руби;
- Apache + Passenger – очень удобно, подхватывает (почти все) изменения автоматически, гораздо удобнее монгрела/вебрика, которые надо перезапускать;
- Firefox – потому что нет альтернатив;
- Firebug – удобно аякс отлаживать, ибо и json-, и html- ответы можно смотреть «на месте»;
- meld – моя любимая диффалка/мерджилка, прописана в git mergetool.
Остальное:
- Gnome – хотя бы потому, что Firefox;
- Gnome-Do – вместо панели задач, дока, горячих клавиш и ярлыков;
- del.icio.us – например, чтобы синхронизироваться с Firefox под Windows;
- VLC – играет любые фильмы;
- mocp – играет музыку, не навязывая какой-то библиотеки и всяких умных плейлистов;
- Picasa – просто умница.
Бывает такое, что путаешь свою версию сайта с той, что работает в миру? Например, если они открыты в соседних вкладках браузера? Эта проблема решается ровно одной строчкой в конфиге Apache:
AliasMatch ^/favicon\.ico$ "/location/of/dev_favicon.ico"
После этого (и при включенном mod_alias, как это обычно бывает) у всех локальных сайтов будет одна и та же фавиконка. Я ее сделал красной: 
.
Еще можно подменять им стили с помощью Stylish, типа:
@namespace url(http://www.w3.org/1999/xhtml);
@-moz-document domain("localhost")
{
html {border: solid 5px red !important} /* сложно не заметить толстую красную рамку */
}Тоже работает. Но придется для каждого сайта (домена) прописывать отдельно. Если только ты не размещаешь все dev-сайты в какой-нибудь особенной доменной зоне – я, например, привык класть их в .dev. Тогда вообще все просто – заменяешь в стиле localhost на dev и стиль подхватывается на всех сайтах.
В общем, понадобится sshfs – штука для монтирования ssh-каталогов в локальные. Конечно, она есть в репозитариях Ubuntu.
В смонтированном таким образом каталоге можно выполнять практически любые утилиты, имеющиеся на локальной машине. Например, git pull.
# Монтируем каталог
mkdir ssh-export
sshfs -o workaround=rename the.deploy.server:/the/deploy/path ssh-export
cd ssh-export
# Обновляем
git pull
# Отмонтировываем
cd ..
fusermount -u ssh-export
rm -rf ssh-export
Причина использования workaround=rename описана в Git FAQ.
Замечу, что скорость этого способа все же меньше, чем у rsync, потому что rsync сжимает данные. Зато он гораздо удобнее и позволяет выкладывать код на сервер любым душе угодным образом.
Еще я пробовал использовать git через FTP с помощью curlftpfs, но, увы, git не хочет работать без возможности залочить файл.
Другие способы обойтись без системы контроля версий – в статье «Грамотное разворачивание сайта без VCS».
Начинаю цикл обзора моих рабочих инструментов. На это меня натолкнул пост Джеймиса Бака про то, что свои инструменты надо не просто знать – в них нужно разбираться.
Будет ли это оффтопиком? Да нет, конечно! Я же о веб-разработке буду писать. Думаю, коллегам понравится.
Обзор будет из четырех частей: 1) преимущества предмета; 2) недостатки; 3) почему я использую именно его; 4) как узнать о нем что-то новое. Естественно, все это субъективно, прошу комментировать, критиковать и подвергать сомнению.
Начну я с операционки, то есть с Linux (клиентской операционки). Я работаю на Ubuntu Linux 9.04.
читать дальше →
Специально для всех сомневающихся и режущих мой слух словом «рАби»:
Спасибо Яндексу за это.
Подписаться на RSS
