Уфф, ну и навозился я с этим эр-эс-эс-ом, пока заставил его работать по-человечески!
Проблема изначально была в том, что мой хостинг любит показывать рекламу на всех страницах, превышающих некий пороговый размер. Соответственно, генерируемый мною RSS-поток оказывался ни разу не валидным, а как раз наоборот - инвалидным. В связи с этим я изобрел солюшен: создавать на сервере файл с расширением .xml, который и служил в качестве моего RSS-потока весь последний месяц. Каждый раз, когда я добавлял запись, мой сайт запускал скрипт, перезаписывающий данный файл.
И все-то было хорошо, только вот было нехорошо. Некрасиво было, одним словом. Поэтому сегодня я задался целью все исправить. Несколько раз прогнав свой урл через FeedValidator.Org, я исправил:
а) проблемы с кодировкой: реально было UTF-16, а в заголовке выбрасывалась WIN-1251. Теперь там всегда WIN-1251.
б) content-type - был он text/xml, а стал - application/rss+xml.
К такому контент-тайпу мой хостинг не умеет добавлять рекламу, поэтому теперь RSS-поток работает круче в сто раз - теперь он действительно поток, а не файл, потому что генерируется на лету.
В связи с вышесказанным Редкого Свинского Свина на данной территории прошу считать укрощенным.
Число и подпись.
UPD 27.12.2007: этот пост уже не актуален - тут я рассказываю, как я мучался с RSS, когда использовал WebWizJournal на lonewolf.od.ua.
Из этических соображений
Собрался я тут пойти на концерт одной группы (название группы я не пишу из этических соображений). В связи с этим я вышел в инет, чтобы узнать диапазон цен на билеты, где был приятно удивлен: Google одним из первых результатов выдал сайт (название которого я не пишу из этических соображений), на котором эти самые билеты можно сразу и заказать. На следующий день их доставит курьер. Заказав 2 билета, вчера я лег спать в ожидании сегодня.
Сегодня мне перезвонил женский голос и мы договорились, на какое время мне нужно доставить эти билеты (время я не указываю из этических соображений). Когда время наступило, билеты мне принес почему-то один знакомый программист (имя которого я не пишу из этических соображений). На мой вопрос: "А чего ж ты подрабатываешь курьером?" он ответствовал примерно такой историей.
В общем, именно он писал этот сайт, с которого я делал заказ. Сам сайт существует всего пару дней, я у них первый клиент. А поскольку курьерская служба еще не функционирует, то билеты, кроме как программисту, отнести оказалось некому. Вот он их и принес. Короче, дал я ему денег за билеты (сколько денег - не пишу из этических соображений), и мы разошлись.
Как справедливо мне советует другой программист (имя которого я не пишу из этических соображений):
- Сережа, не пиши сайты! Особенно с предложениями интим-услуг :)
Сегодня мне перезвонил женский голос и мы договорились, на какое время мне нужно доставить эти билеты (время я не указываю из этических соображений). Когда время наступило, билеты мне принес почему-то один знакомый программист (имя которого я не пишу из этических соображений). На мой вопрос: "А чего ж ты подрабатываешь курьером?" он ответствовал примерно такой историей.
В общем, именно он писал этот сайт, с которого я делал заказ. Сам сайт существует всего пару дней, я у них первый клиент. А поскольку курьерская служба еще не функционирует, то билеты, кроме как программисту, отнести оказалось некому. Вот он их и принес. Короче, дал я ему денег за билеты (сколько денег - не пишу из этических соображений), и мы разошлись.
Как справедливо мне советует другой программист (имя которого я не пишу из этических соображений):
- Сережа, не пиши сайты! Особенно с предложениями интим-услуг :)
C++: const-методы класса. Как не дублировать код
Из последнего задания: "особое внимание уделить избавлению от copy-paste, как, например, в методах "find" из HashImpl".
Методов find в классе HashImpl, реализующем хранение произвольных данных по хеш-ключам, есть два:
Первый вариант будет вызываться для константного объекта, а второй - для неконстантного. Проблема следующая: код этих методов звучит не просто как "return & mHash[key]", а реализует какой-никакой, а все же алгоритм поиска. Да и хешей там два - первичный и вторичный, что еще немножко усложняет ситуацию. Внутри методов используются всякие вспомогательные указатели на внутренние данные класса, которые в константном методе должны быть константными, а в неконстантных - соответственно, неконстантными.
Отсюда формулируем вопрос: как избежать дублирования кода для константной (const) и неконстантной версий одного и того же метода, реализующего нетрививальный алгоритм? Примечание: константный объект может пользоваться только методами, объявленными с квалификатором const, и не может использовать неконстантные указатели и неконстантные ссылки на свои данные - в частности, не может их возвращать.
Нарытые варианты решения:
1. Вызывать константный метод из неконстантного.
Чем плох: константный метод вернет константный указатель, с которого затем придется снимать константность, используя const_cast
2. Объявлять хеш-таблицы как mutable, чтобы иметь право изменять их в константном методе
Чем плох: mutable - грязный хак. Если программист серьезно размышляет об использовании mutable - ему надо выйти проветриться (цитатирую Мишу Нореля). Короче, тоже не наш метод.
3. Использовать неконстантные указатели "через один указатель"
Объясняю популярно. Если в классе Foo есть поле mData типа Bar, то из константного метода нельзя сделать return & mData.getItem(key). Но зато если эту же mData объявить как Bar*, выделяя память для него в конструкторе, то из константной функции можно сделать return & (mData->getItem(key)).
Чем плох: не удовлетворяет требованиям к классу: необходимо использовать статическую инициализацию. И класс-то вовсе не класс, а шаблон, один из параметров которого - размер хеш-таблицы. Опять облом.
4. Хранить рядом с данными указатель на них, и возвращать item через него (см. метод 3)
Ну, типа объявить в классе Foo два поля: Bar mData и Bar* mDataPtr, присвоив последнему mDataPtr = & mData в конструкторе.
Чем плох: См., во-первых, метод 1. Если объект будет размещен в защищенной от записи памяти, то при записи по указателю mDataPtr будет жопа. Во-вторых, sizeof всех объектов увеличится на 4 байта. Если объектов будет миллион, то мы проебем 4 метра памяти, что для целевой платформы может быть нехорошо.
5. Написать еще одну константную функцию для поиска
Да-да, пишем третью функцию:
Такой метод можно вызывать из обоих версий find. Он вернет ключ, по которому хранится искомый item. А потом константный find может вернуть const Item* p = & mData[resKey], а неконстантный - Item* p = & mData[resKey].
Чем плох: Добавляются лишние вызовы, немножко падает производительность, дыр-пыр-тыр, бла-бла-бла. Все это, по сравнению с проблемами предыдущих вариантов - суть мелочи, поэтому я остановился именно тут.
Итого: я не люблю C++, среди много-прочего, как раз за такие вот мансы. Ну, типа, придумали мы слово const - и теперь ловим сопутствующие проблемы. Зато (sic!) мы получаем неибацца свободу выбора решений таких проблем...
А свободу, как известно, не купишь :)
Методов find в классе HashImpl, реализующем хранение произвольных данных по хеш-ключам, есть два:
1) const Item* find (KeyType key) const
2) Item* find (KeyType key)
Первый вариант будет вызываться для константного объекта, а второй - для неконстантного. Проблема следующая: код этих методов звучит не просто как "return & mHash[key]", а реализует какой-никакой, а все же алгоритм поиска. Да и хешей там два - первичный и вторичный, что еще немножко усложняет ситуацию. Внутри методов используются всякие вспомогательные указатели на внутренние данные класса, которые в константном методе должны быть константными, а в неконстантных - соответственно, неконстантными.
Отсюда формулируем вопрос: как избежать дублирования кода для константной (const) и неконстантной версий одного и того же метода, реализующего нетрививальный алгоритм? Примечание: константный объект может пользоваться только методами, объявленными с квалификатором const, и не может использовать неконстантные указатели и неконстантные ссылки на свои данные - в частности, не может их возвращать.
Нарытые варианты решения:
1. Вызывать константный метод из неконстантного.
Чем плох: константный метод вернет константный указатель, с которого затем придется снимать константность, используя const_cast
2. Объявлять хеш-таблицы как mutable, чтобы иметь право изменять их в константном методе
Чем плох: mutable - грязный хак. Если программист серьезно размышляет об использовании mutable - ему надо выйти проветриться (цитатирую Мишу Нореля). Короче, тоже не наш метод.
3. Использовать неконстантные указатели "через один указатель"
Объясняю популярно. Если в классе Foo есть поле mData типа Bar, то из константного метода нельзя сделать return & mData.getItem(key). Но зато если эту же mData объявить как Bar*, выделяя память для него в конструкторе, то из константной функции можно сделать return & (mData->getItem(key)).
Чем плох: не удовлетворяет требованиям к классу: необходимо использовать статическую инициализацию. И класс-то вовсе не класс, а шаблон, один из параметров которого - размер хеш-таблицы. Опять облом.
4. Хранить рядом с данными указатель на них, и возвращать item через него (см. метод 3)
Ну, типа объявить в классе Foo два поля: Bar mData и Bar* mDataPtr, присвоив последнему mDataPtr = & mData в конструкторе.
Чем плох: См., во-первых, метод 1. Если объект будет размещен в защищенной от записи памяти, то при записи по указателю mDataPtr будет жопа. Во-вторых, sizeof всех объектов увеличится на 4 байта. Если объектов будет миллион, то мы проебем 4 метра памяти, что для целевой платформы может быть нехорошо.
5. Написать еще одну константную функцию для поиска
Да-да, пишем третью функцию:
void findHadler (KeyType key, KeyType & resKey) const
Такой метод можно вызывать из обоих версий find. Он вернет ключ, по которому хранится искомый item. А потом константный find может вернуть const Item* p = & mData[resKey], а неконстантный - Item* p = & mData[resKey].
Чем плох: Добавляются лишние вызовы, немножко падает производительность, дыр-пыр-тыр, бла-бла-бла. Все это, по сравнению с проблемами предыдущих вариантов - суть мелочи, поэтому я остановился именно тут.
Итого: я не люблю C++, среди много-прочего, как раз за такие вот мансы. Ну, типа, придумали мы слово const - и теперь ловим сопутствующие проблемы. Зато (sic!) мы получаем неибацца свободу выбора решений таких проблем...
А свободу, как известно, не купишь :)
Послание Святого Павла к гермафродитам
Дорогие гермафродиты!
Go fuck yourself!
Всегда ваш,
Святой Павел.
Go fuck yourself!
Всегда ваш,
Святой Павел.
Complementing Klaymen!!!
Привет, я Вилли. Вилли Баранкин. Если ты это смотришь, то ты молодец. Вилли счастлив."Немало попыток я предпринял в свое время, чтобы найти в Инете саундтрек к ахуительной игрушке The Neverhood. Итак, что мы знаем о ней?
1. Написана она была свежеиспеченной студией The Neverhood, по заказу Dreamworks Interactive (да, ТОЙ САМОЙ Dreamworks!). За год они ее написали.
2. На создание декораций было потрачено три тонны пластилина
3. Съемкой и производством руководил Стивен Спилберг. Пэрсонально.
Но речь не о том. Этот пост должен был быть про то, как мне работается в Люксофте первые две недели, но эта тема пока что продолжает вызревать – события развиваются здесь слишком стремительно, в Билайте я к такому не привык.
Поэтому пост посвящен тому, что наконец-то я нашел саундтрек The Neverhood!!! Кусочек был в расшаренной папке одного сотрудника, а еще кусочек я скачаю с не-скажу-откуда, когда попаду в инет снова. Ура! Ура! Ура!
Интрига же сегодня заключается в том, что, оказывается, главная тема (та, которая играет в Credits), оказывается, имеет слова! Не берусь судить, насколько они осмыслены, но тем не менее:
Complementing Klaymen
Clitton Clatton Klogg
We behold it's Hoborg
Big Robot Bil is odd!
The Clockwork Beast and Frenchy guy are with them. Hard to see:
Crit Unit "A" – oh what a day! – he joins Crit Unit "B"
At the Neverhood
Neverhood
Neverhood!
Эту бню надо петь все время, варьируя ее, например, так:
K k k k Klaymen
K k k k Klogg
Ho ho ho ho Hoborg
Big Robot Bil is odd!
C....C....C....C....Clockwork Beast, F....F....Frenchy.... gee!
Crit Unit "A" – oh what the hey! – he joins Crit Unit "B"
At the Neverhood…
Hey ho
Hey ho
Hey ho!
Подписаться на:
Сообщения
(
Atom
)
Сообщения
