По мотивам bash'а.

Для тех, кто недостаточно хорошо помнит гимн РФ:
for i in {200..225}; do nslookup 62.76.96.$i | grep "(?<=name = ).*$" -o -P ; done

upd Варианты улучшенные:

лаконичный
dig -t ptr +short {200..225}.96.76.62.in-addr.arpa

винда с PowerShell
for ($i=200; $i -le 223; $i++){(nslookup 62.76.96.$i)[3].ToString().Replace('.', ' ').Substring(9)}

винда без PowerShell
for /l %i in (200,1,255) do nslookup 62.76.96.%i

Мой список книг, которые мне хочется прочесть, изрядно вырос, спасибо топику “запасаемся на зиму”. Под катом вы обнаружите список книг, составленный по комментариям в том топике.

На странице стоимости компонентов EC2 на Амазоне есть одна строчка, на которую сначала можно не сильно обратить внимание, но которая может привести к серьезным финансовым затратам — Data Transfer, трафик. Если аренду инстансов и EBS-томов можно запланировать и контролировать, то трафик предсказать довольно сложно, а игнорировать его не даст ежемесячный счет)

Для примера: средний новостной сайт, 30 тысяч посещений в сутки, его вполне потянет небольшой small или даже micro instance. Возьмем полный размер страницы 2 мегабайта, месячный трафик тогда будет (без учета закэшированного контента) — 30000 * 0.002 * 30 = 1800 GB или $216. Получается стоимость Data Transfer даже больше аренды самого инстанса! На S3 ситуация с ценами на трафик точно такая же.

Дарова, хабр! (ничего оригинальнее не придумал)

Сомневаюсь что эта заметка тянет на полноценный пост, но я все же оставлю ее здесь. О чем же пойдет речь?

Все мы слышали о Git. Все мы знаем что он — хорош. Но лишь немногие пытаются что-то с ним делать, как-то его протвикерить. Сразу говорю, тут не будет ничего паранормального, только немного работы с файлом .gitconfig. Да-да, именно с тем файлом, который так трепетно пылится у вас в домашней директории.

Так, мне уже немного надоело писать этот, по сути, бессмысленный вступительный текст, так что давайте уже начнем что-то делать.

Очень часто бывает так, что владелец интернет-магазина выделяет огромные деньги на рекламу — размещает свои товары в торговых сетях, даёт объявления в системах контекстной рекламы, ставит баннеры на сайтах близких по тематике. Все это, безусловно, привлекает огромное количество посетителей, но проблема в том, что лишь ничтожно малая часть из них действительно совершает заказ. Именно этой проблеме и посвящена данная статья.

Пару недель назад разработчики Google Chromium опубликовали новость о поддержке технологии WebSocket. В айтишном буржунете новость произвела эффект разорвавшейся бомбы. В тот же день различные очень известные айтишники опробовали новинку и оставили восторженные отзывы в своих блогах. Моментально разработчики самых разных серверов/библиотек/фреймворков (в их числе Apache, EventMachine, Twisted, MochiWeb и т.д.) объявили о том, что поддержка ВебСокетов будет реализована в их продуктах в ближайшее время.
Что же такого интересного сулит нам технология? На мой взгляд, WebSocket — это самое кардинальное расширение протокола HTTP с его появления. Это не финтифлюшки, это сдвиг  парадигмы HTTP. Изначально синхронный протокол, построенный по модели «запрос — ответ», становится полностью асинхронным и симметричным. Теперь уже нет клиента и сервера с фиксированными ролями, а есть два равноправных участника обмена данными. Каждый работает сам по себе, и когда надо отправляет данные другому. Отправил — и пошел дальше, ничего ждать не надо. Вторая сторона ответит, когда захочет — может не сразу, а может и вообще не ответит. Протокол дает полную свободу в обмене данными, вам решать как это использовать.

Я считаю, что веб сокеты придутся ко двору, если вы разрабатываете:
— веб-приложения с интенсивным обменом данными, требовательные к скорости обмена и каналу;
— приложения, следующие стандартам;
— «долгоиграющие» веб-приложения;
— комплексные приложения со множеством различных асинхронных блоков на странице;
— кросс-доменные приложения.

Передо мной частенько вставала задача написать какой-нибудь Java-сервис. В качестве ОС мы используем по большей части линукс, так что удобнее всего управляться с такими сервисами — работать с ними как с демонами. То есть, запускаем:

start-stop-daemon --start --make-pidfile --pidfile /var/run/myservice.pid --exec /usr/bin/java — -jar myservice.jar

, и останавливаем:

start-stop-daemon --stop --quiet --oknodo --pidfile /var/run/myservice.pid

Команда --stop посылает JVM сигнал SIGTERM и сервис останавливается. Все как бы неплохо, JVM завершается в штатном порядке, если только вам не нужно выполнить по завершении работы сервиса какое-либо действие. Например явно освободить ресурс, или написать что-нибудь приятное в stdout.

Но все не так страшно, благо JVM начиная с 1.3.1 позволяет обрабатывать сигналы. За ответом как — под хабракат.