Мой коллега - ныне солидный бородатый господин - рассказывал, как они резвились в детстве. Это происходило то ли в YMCA, то ли в каком-то другом аналоге пионерлагеря. В основном шутки были стандартные - привязать спящего товарища к кровати, намазать зубной пастой, незаметно вынести кровать на улицу, украсить дерево гигиеническими тампонами.
Но мой коллега - человек творческий, он организавал кое-что посерьезнее, в духе сериала "Кадеты" (момент, когда суворовцы подняли "Запорожец" прапорщика Кантемирова на гимнастические брусья). Детки раздобыли Haynes (справочник по ремонту автомобилей), разобрали учительский Mini, занесли его по частям в столовую и там собрали. На операцию ушло больше семи часов: начали в 11-12 вечера, и с трудом успели до завтрака.
Выехать из столовой или даже достать машину через окно было невозможно. Только снова разбирать.
вторник, 26 апреля 2011 г.
четверг, 21 апреля 2011 г.
SPF softfail из-за неправильного адреса отправителя
Я настроил SPF, чтобы лучше доходила почта, отправляемая моим сайтом. Windows-хостинг у ASP Host Central, письма отправляются с помощью обычной функции mail() из PHP. Но почему-то SPF не помогает, всё равно происходит softfail:
Delivered-To: john.smith@gmail.com
Received: by 10.231.35.199 with SMTP id q7cs118060ibd;
Thu, 21 Apr 2011 03:15:33 -0700 (PDT)
Received: by 10.142.200.1 with SMTP id x1mr4731149wff.82.1303380933251;
Thu, 21 Apr 2011 03:15:33 -0700 (PDT)
Return-Path: <support@asphostserver.com>
Received: from asp157mail.asphostserver.com (174.37.170.227-static.reverse.softlayer.com [174.37.170.227])
by mx.google.com with ESMTP id 9si5563363wfi.117.2011.04.21.03.15.31;
Thu, 21 Apr 2011 03:15:32 -0700 (PDT)
Received-SPF: softfail (google.com: domain of transitioning support@asphostserver.com does not designate 174.37.170.227 as permitted sender) client-ip=174.37.170.227;
Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning support@asphostserver.com does not designate 174.37.170.227 as permitted sender) smtp.mail=support@asphostserver.com
Message-Id: <4db003c4.09098e0a.3793.fffff020SMTPIN_ADDED@mx.google.com>
Received: from asphost157 [127.0.0.1] by asp157mail.asphostserver.com with SMTP;
Thu, 21 Apr 2011 05:14:11 -0500
Date: Thu, 21 Apr 2011 05:14:11 -0500
Subject: Registration on mydomain.com
To: john.smith@gmail.com
From: noreply@mydomain.com
Return-Path: noreply@mydomain.com
Проблема в том, что в SPF я прописал домен mydomain.com, и обратный адрес должен быть noreply@mydomain.com. Но, как видите, письмо почему-то отправляется от имени support@asphostserver.com. Хотя я же вроде указал noreply@mydomain.com в заголовке Return-Path, когда вызывал mail().
Но если присмотреться, то видно, что в емейле на самом деле два Return-Path. И мой, правильный, находится внизу, а сверху всё равно лепится "левый" емейл support@asphostserver.com.
Решение: перед вызовом mail() делаю ini_set("sendmail_from", 'noreply@mydomain.ua') . Это помогает убрать support@asphostserver.com.
Delivered-To: john.smith@gmail.com
Received: by 10.231.35.199 with SMTP id q7cs118060ibd;
Thu, 21 Apr 2011 03:15:33 -0700 (PDT)
Received: by 10.142.200.1 with SMTP id x1mr4731149wff.82.1303380933251;
Thu, 21 Apr 2011 03:15:33 -0700 (PDT)
Return-Path: <support@asphostserver.com>
Received: from asp157mail.asphostserver.com (174.37.170.227-static.reverse.softlayer.com [174.37.170.227])
by mx.google.com with ESMTP id 9si5563363wfi.117.2011.04.21.03.15.31;
Thu, 21 Apr 2011 03:15:32 -0700 (PDT)
Received-SPF: softfail (google.com: domain of transitioning support@asphostserver.com does not designate 174.37.170.227 as permitted sender) client-ip=174.37.170.227;
Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning support@asphostserver.com does not designate 174.37.170.227 as permitted sender) smtp.mail=support@asphostserver.com
Message-Id: <4db003c4.09098e0a.3793.fffff020SMTPIN_ADDED@mx.google.com>
Received: from asphost157 [127.0.0.1] by asp157mail.asphostserver.com with SMTP;
Thu, 21 Apr 2011 05:14:11 -0500
Date: Thu, 21 Apr 2011 05:14:11 -0500
Subject: Registration on mydomain.com
To: john.smith@gmail.com
From: noreply@mydomain.com
Return-Path: noreply@mydomain.com
Проблема в том, что в SPF я прописал домен mydomain.com, и обратный адрес должен быть noreply@mydomain.com. Но, как видите, письмо почему-то отправляется от имени support@asphostserver.com. Хотя я же вроде указал noreply@mydomain.com в заголовке Return-Path, когда вызывал mail().
Но если присмотреться, то видно, что в емейле на самом деле два Return-Path. И мой, правильный, находится внизу, а сверху всё равно лепится "левый" емейл support@asphostserver.com.
Решение: перед вызовом mail() делаю ini_set("sendmail_from", 'noreply@mydomain.ua') . Это помогает убрать support@asphostserver.com.
среда, 20 апреля 2011 г.
Сайт - это не только SEO
Заметка о том, что надо не только заниматься SEO, но и не забывать о качестве продукта. Очень понравился комментарий редактора (вольный перевод - мой):
Как много SEO-экспертов требуется, чтобы заменить лампочку, лампочки, лампу, лампы, светильник, свечение, свет, освещение, торшер, патрон, выключатель, электричество, энергия...?
Как много SEO-экспертов требуется, чтобы заменить лампочку, лампочки, лампу, лампы, светильник, свечение, свет, освещение, торшер, патрон, выключатель, электричество, энергия...?
Один в лавке
Страна готовится к пасхальным каникулам. На следующей неделе всего три рабочих дня, и если взять отгулы, то получится отпуск длиной в 11 дней.
Но я собирался эти три дня работать. Тут оказалось, что все остальные программисты идут в отпуск, и начальник настоятельно попросил меня сделать то же самое: "Тебе ведь будет так одиноко в офисе!" Ну, и, наверное, он считал, что нет смысла работать вне команды: мне будет некому задать вопрос, зато потом, когда я использую сэкономленные дни и уйду в отпуск, команда будет мучаться без меня...
Я поначалу отказался, потому сказал, что подумаю. Подумал и решил, что нехорошо начальнику отказывать, ведь он раньше всегда шёл мне навстречу. Тем более, что отпуск за 2011 год я почти не расходовал. На выходных Марина уже спланировала, как потратим эти три дня неожиданного отпуска. Собирались слетать в Шотландию - билеты на эти рабочие дня очень дешевые, потому что все стараются лететь в начале и в конце этого отпускного периода, а не в середине.
Но всё же решил пока не покупать билеты, а ещё раз поговорить с начальником. И очень хорошо, потому что он передумал. Решил, что надо "оставить в лавке" кого-то из программистов: на следующей неделе тестировщики будут работать, готовить важный релиз, а исправлять найденные ошибки будет некому... Я-то настроился провести в офисе три тихих, спокойных дня, но похоже, что вместо этого придется работать за всех :)
Но я собирался эти три дня работать. Тут оказалось, что все остальные программисты идут в отпуск, и начальник настоятельно попросил меня сделать то же самое: "Тебе ведь будет так одиноко в офисе!" Ну, и, наверное, он считал, что нет смысла работать вне команды: мне будет некому задать вопрос, зато потом, когда я использую сэкономленные дни и уйду в отпуск, команда будет мучаться без меня...
Я поначалу отказался, потому сказал, что подумаю. Подумал и решил, что нехорошо начальнику отказывать, ведь он раньше всегда шёл мне навстречу. Тем более, что отпуск за 2011 год я почти не расходовал. На выходных Марина уже спланировала, как потратим эти три дня неожиданного отпуска. Собирались слетать в Шотландию - билеты на эти рабочие дня очень дешевые, потому что все стараются лететь в начале и в конце этого отпускного периода, а не в середине.
Но всё же решил пока не покупать билеты, а ещё раз поговорить с начальником. И очень хорошо, потому что он передумал. Решил, что надо "оставить в лавке" кого-то из программистов: на следующей неделе тестировщики будут работать, готовить важный релиз, а исправлять найденные ошибки будет некому... Я-то настроился провести в офисе три тихих, спокойных дня, но похоже, что вместо этого придется работать за всех :)
понедельник, 18 апреля 2011 г.
Google Webmasters Central: проблема со старым доменом
Гугль слегка поменял алгоритм верификации в Google Webmaster Tools. У меня имеется mydomain.com.ua, со всех страниц которого происходит перманентное перенаправление на mydoman.ua. Для верификации использовался файл. Раньше работало.
Сегодня вдруг Гугль стал говорить в том смысле, что "не удается проверить право собственности на mydomain.com.ua, потому что файл googleXXX.html перенаправляет на неразрешенный адрес mydoman.ua". Почему "неразрешенный", ведь mydoman.ua у меня верифицирован? Не знаю - то ли у них ошибка, то ли специально решили ужесточить правила.
Можно, конечно, воспользоваться другими методами верификации(meta tag или записать в DNS), но мне не хотелось: про запись в DNS легко забыть, когда переезжаешь на новый хостинг, а meta tag - некрасиво (засоряет главную страницу).
Вместо этого поменял правила в IIS URL Rewrite так, чтобы файл googleXXX.html обслуживался и по старому, и по новому адресу. Для всех остальных файлов по-прежнему делаю перенаправление:
<rule name="DomainRedirects" patternSyntax="ECMAScript">
<match url=".*" />
<conditions logicalGrouping="MatchAll">
<add input="{HTTP_HOST}" pattern="^(www.mydomain.ua|((www.)?(mydomain.com.ua|mydomain.co.ua)))$" />
<add input="{URL}" pattern="googleXXX.html" negate="true" />
</conditions>
<action type="Redirect" url="http://mydomain.ua/{R:0}" redirectType="Permanent" />
</rule>
Интересно было бы почитать, как различные правила URL Rewrite влияют на производительность IIS. Не заставляю ли я его делать лишнюю работу при каждом запросе? Думаю, что нет - по идее, он всё должен кэшировать...
P.S. Как видите, я заодно убираю www., но это уже отдельная тема, из-за которой идут жаркие холиворы.
Сегодня вдруг Гугль стал говорить в том смысле, что "не удается проверить право собственности на mydomain.com.ua, потому что файл googleXXX.html перенаправляет на неразрешенный адрес mydoman.ua". Почему "неразрешенный", ведь mydoman.ua у меня верифицирован? Не знаю - то ли у них ошибка, то ли специально решили ужесточить правила.
Можно, конечно, воспользоваться другими методами верификации(meta tag или записать в DNS), но мне не хотелось: про запись в DNS легко забыть, когда переезжаешь на новый хостинг, а meta tag - некрасиво (засоряет главную страницу).
Вместо этого поменял правила в IIS URL Rewrite так, чтобы файл googleXXX.html обслуживался и по старому, и по новому адресу. Для всех остальных файлов по-прежнему делаю перенаправление:
<rule name="DomainRedirects" patternSyntax="ECMAScript">
<match url=".*" />
<conditions logicalGrouping="MatchAll">
<add input="{HTTP_HOST}" pattern="^(www.mydomain.ua|((www.)?(mydomain.com.ua|mydomain.co.ua)))$" />
<add input="{URL}" pattern="googleXXX.html" negate="true" />
</conditions>
<action type="Redirect" url="http://mydomain.ua/{R:0}" redirectType="Permanent" />
</rule>
Интересно было бы почитать, как различные правила URL Rewrite влияют на производительность IIS. Не заставляю ли я его делать лишнюю работу при каждом запросе? Думаю, что нет - по идее, он всё должен кэшировать...
P.S. Как видите, я заодно убираю www., но это уже отдельная тема, из-за которой идут жаркие холиворы.
пятница, 15 апреля 2011 г.
Переезд на другой домен
Примерно месяц назад перенёс родительский сайт из .com.ua в .ua. Долго не мог на это решиться: сайт создан 12 (!) лет назад. По Интернет-шкале это очень, очень давно. За это время на него появилось огромное количество ссылок. Страшно было растратить это накопленное SEO-богатство.
Но всё-таки желание сократить адрес на четыре символа взяло верх. Я вроде всё сделал по правилам: с каждой страницы старого домена делаю HTTP 301 на новый домен; в robots.txt прописал Host: newdomain.ua и Sitemap: http://newdomain.ua/sitemap.xml; добавил новый домен и sitemap в Google Webmaster Tools; отправил им заявку на смену адреса. Поначалу вроде всё было хорошо: Гугль сразу начал переиндексировать страниц, и в течение недели почти всё запросы по старому домену стали возвращать новый.
Но через две-три недели трафик с Гугля упал аж в два раза! Судя по Google Webmaster Tools, старые ссылки вроде бы привязаны к новому домену, т.е. всё должно быть хорошо. Но, похоже, всё-таки не получается их полностью "унаследовать", Гугль уже не придает им такой большой вес, как раньше. Хотя, может, со временем это пройдет...
Другое возможное объяснение: рейтинг мог упасть просто потому, что Гугль поменял свои алгоритмы. Т.е. они просто теперь считают сайт менее интересным, чем считали раньше. Если это правда, то получается, что перенос на новый домен просто ускорил неизбежное падение - заставил Гугль быстрее пересчитать какие-то там показатели.
Updated: Разобрался. Похоже, дело таки в новом алгоритме "Пандора". У меня есть архив старой версии сайта, который не обновлялся уже 5 лет. Но по каким-то причинам он был отлично проиндексирован поисковиками, да и AdSense CTR там был гораздо выше, чем на остальном сайте. Информация в архиве в основном уже устарела, но убрать было жалко, поскольку она приносила денег. И вот, наконец, Гугль понял, что эти страницы представляют невысокую ценность. Это снизило наши доходы, но, в приниципе, я на Гугль не в обиде, они всё сделали правильно.
Но всё-таки желание сократить адрес на четыре символа взяло верх. Я вроде всё сделал по правилам: с каждой страницы старого домена делаю HTTP 301 на новый домен; в robots.txt прописал Host: newdomain.ua и Sitemap: http://newdomain.ua/sitemap.xml; добавил новый домен и sitemap в Google Webmaster Tools; отправил им заявку на смену адреса. Поначалу вроде всё было хорошо: Гугль сразу начал переиндексировать страниц, и в течение недели почти всё запросы по старому домену стали возвращать новый.
Но через две-три недели трафик с Гугля упал аж в два раза! Судя по Google Webmaster Tools, старые ссылки вроде бы привязаны к новому домену, т.е. всё должно быть хорошо. Но, похоже, всё-таки не получается их полностью "унаследовать", Гугль уже не придает им такой большой вес, как раньше. Хотя, может, со временем это пройдет...
Другое возможное объяснение: рейтинг мог упасть просто потому, что Гугль поменял свои алгоритмы. Т.е. они просто теперь считают сайт менее интересным, чем считали раньше. Если это правда, то получается, что перенос на новый домен просто ускорил неизбежное падение - заставил Гугль быстрее пересчитать какие-то там показатели.
Updated: Разобрался. Похоже, дело таки в новом алгоритме "Пандора". У меня есть архив старой версии сайта, который не обновлялся уже 5 лет. Но по каким-то причинам он был отлично проиндексирован поисковиками, да и AdSense CTR там был гораздо выше, чем на остальном сайте. Информация в архиве в основном уже устарела, но убрать было жалко, поскольку она приносила денег. И вот, наконец, Гугль понял, что эти страницы представляют невысокую ценность. Это снизило наши доходы, но, в приниципе, я на Гугль не в обиде, они всё сделали правильно.
Компьютерный компьютерщик
Собрались брать на работу нового программиста. Он прошел техническое и "менеджерское" собеседование. Осталось собеседование с отделом кадров, но это всегда считалось просто формальностью. Неожиданно кадровик стал ломаться:
- Какой-то он странный, этот парень...
- Почему?
- Да он всё время говорил про программирование, и ни про что больше. Только это его и интересует.
- Ну, так в чем проблема? Мы же его и берем как программиста...
- Не знаю... он так любит эти компьютеры... а вдруг он будет в рабочее время играть в компьютерные игры?
Наверное, отдел кадров предпочел бы послушать про благотворительные марафоны или корпоративные балы-маскарады...
- Какой-то он странный, этот парень...
- Почему?
- Да он всё время говорил про программирование, и ни про что больше. Только это его и интересует.
- Ну, так в чем проблема? Мы же его и берем как программиста...
- Не знаю... он так любит эти компьютеры... а вдруг он будет в рабочее время играть в компьютерные игры?
Наверное, отдел кадров предпочел бы послушать про благотворительные марафоны или корпоративные балы-маскарады...
среда, 13 апреля 2011 г.
Место встречи - Лондон
Из Лондона весь мир ближе, чем из Харькова: много авиарейсов; здоровая конкуренция между перевозчиками и туроператарами; за визами ходить недалеко; нет проблем с прививками, путеводителями, туристическим снаряжением и пр.
Но не только мир ближе ко мне - я тоже стал ближе к миру. Об этом я думал, встречая в Хитроу своего родственника Мишу, которого не видел уже больше 20 лет. Друзья, сокурсники, родственники - многих из них я бы, возможно, никогда больше не увидел, если бы не жил здесь, на перепутье множества дорог. Кто-то едет по делам, а кто-то транзитом...
Самолет прилетал в 9 утра, и сначала я малодушно хотел поспать подольше, а встретится с Мишей и его женоц уже в городе. А потом подумал: такой случай бывает раз в 20 лет, можно и проснуться пораньше!
Раньше не обращал внимание, что в 5-м терминале довольно глупо сделан прилет. Представьте себе длинную букву "К", которая лежит на боку, плоской частью вверх. Пассажиры выходят из этих "верхних" корридоров, а затем идут в разные стороны - кто вправо, кто влево. А некоторые вообще продолжают идти прямо и снова попадают в зону прилета! Конечно, это запрещено, но многие не замечают знак. Двери как бы работают по системе "нипель", но если кто-то другой недавно вышел, то они ещё несколько секунд остаются открытыми.
Более серьезная проблема заключается в том, что ты не знаешь, куда пойдет твой пассажир. Когда людей мало, то нормально. Но когда много пассажиров и встречающих, то очень тяжело контролировать оба выхода сразу: если стоять у одного выхода, то другой тебе просто заслоняют; если стоять посередине, то нужно постоянно и резко крутить головой. А представьте, что к вам в гости едет бабушка, которая никогда не была за границей, не летала на самолете и не знает языка! Надо или встречать вдвоем, или заранее договориться, что встречаетесь посередине (возле табло).
Приятно стоять на прилете: все целуются, радостно плачут. На отлете тоже целуются и плачут, но не радостно...
Мишу я не узнал. Он в детстве очень любил конфеты, был упитанный. С возрастом стал ещё больше. А теперь вот вдруг резко похудел... Я даже решил, что он болеет, но вроде нет.
Когда катались по Темзе, обратил внимание, как настойчиво объявлял капитан: "Это не Гринвич! Гринвич - следующая остановка!" Вроде бы правильно делает, но туристы, слабо знающие язык, могут услышать слово "Гринвич" и выйти раньше времени.
Мы как-то не расчитали время на дорогу, и назад в аэропорт вернулись уже впритык. Впопыхах стали не на тот эскалатор. Наконец, мы у стойки security. Попрощались, и тут мне приспичило: "Давайте обнимемся на прощанье!" Сказано - сделано. Пока обнимались, прибежали бабаи, которые пытались протащить кучу чемоданов в ручную кладь. Их не пускали, а они не понимали и ругались на своем бабайском языке. Уже вечер, соседние стойки закрыты. Наконец, их отодвинули... и тут оказалось, что у Мишиной жены какая-то проблема с билетом. Пришлось идти на check-in и перепечатывать. В самолет они уже бежали.
Но не только мир ближе ко мне - я тоже стал ближе к миру. Об этом я думал, встречая в Хитроу своего родственника Мишу, которого не видел уже больше 20 лет. Друзья, сокурсники, родственники - многих из них я бы, возможно, никогда больше не увидел, если бы не жил здесь, на перепутье множества дорог. Кто-то едет по делам, а кто-то транзитом...
Самолет прилетал в 9 утра, и сначала я малодушно хотел поспать подольше, а встретится с Мишей и его женоц уже в городе. А потом подумал: такой случай бывает раз в 20 лет, можно и проснуться пораньше!
Раньше не обращал внимание, что в 5-м терминале довольно глупо сделан прилет. Представьте себе длинную букву "К", которая лежит на боку, плоской частью вверх. Пассажиры выходят из этих "верхних" корридоров, а затем идут в разные стороны - кто вправо, кто влево. А некоторые вообще продолжают идти прямо и снова попадают в зону прилета! Конечно, это запрещено, но многие не замечают знак. Двери как бы работают по системе "нипель", но если кто-то другой недавно вышел, то они ещё несколько секунд остаются открытыми.
Более серьезная проблема заключается в том, что ты не знаешь, куда пойдет твой пассажир. Когда людей мало, то нормально. Но когда много пассажиров и встречающих, то очень тяжело контролировать оба выхода сразу: если стоять у одного выхода, то другой тебе просто заслоняют; если стоять посередине, то нужно постоянно и резко крутить головой. А представьте, что к вам в гости едет бабушка, которая никогда не была за границей, не летала на самолете и не знает языка! Надо или встречать вдвоем, или заранее договориться, что встречаетесь посередине (возле табло).
Приятно стоять на прилете: все целуются, радостно плачут. На отлете тоже целуются и плачут, но не радостно...
Мишу я не узнал. Он в детстве очень любил конфеты, был упитанный. С возрастом стал ещё больше. А теперь вот вдруг резко похудел... Я даже решил, что он болеет, но вроде нет.
Когда катались по Темзе, обратил внимание, как настойчиво объявлял капитан: "Это не Гринвич! Гринвич - следующая остановка!" Вроде бы правильно делает, но туристы, слабо знающие язык, могут услышать слово "Гринвич" и выйти раньше времени.
Мы как-то не расчитали время на дорогу, и назад в аэропорт вернулись уже впритык. Впопыхах стали не на тот эскалатор. Наконец, мы у стойки security. Попрощались, и тут мне приспичило: "Давайте обнимемся на прощанье!" Сказано - сделано. Пока обнимались, прибежали бабаи, которые пытались протащить кучу чемоданов в ручную кладь. Их не пускали, а они не понимали и ругались на своем бабайском языке. Уже вечер, соседние стойки закрыты. Наконец, их отодвинули... и тут оказалось, что у Мишиной жены какая-то проблема с билетом. Пришлось идти на check-in и перепечатывать. В самолет они уже бежали.
Ломать - не строить
Вот уже полгода хозяева собирались купить одного из наших конкурентов. Всё происходило как бы в обстановке строгой секретности, но тем не менее всё об этом знали. На общем собрании хозяин сказал: "Не упадите со стульев! Сейчас я с вами поделюсь такой замечательной новостью!" А никто и не упал, всё только лениво зевали :)
Нас заверили, что это совершенно не грозит увольнениями. Якобы у тех - свой рынок, у нас - свой. Правда, у нас есть один новый, отличный сайт, который всё-таки прямо конкуриует с теми ребятами. Поэтому его придется закрыть, а трафик перенаправить в дочернюю компанию.
"Связаны ли сокращения в прошлом году с тем, что мы уже тогда планировали эту сделку? Нет, совершенно не связаны". Ага, так мы вам и поверили: ведь сократили в первую очередь именно тех людей, который работали над этим самым, теперь уже ненужным сайтом...
Дочерняя компания - маленький стартап. По неподтвержденным слухам, мы за них заплатили немало: если пересчитать на количество сотрудников, то выходит примерно по три 3 миллиона фунтов за одну голову! Более того, вроде как эти деньги мы взяли в кредит.
Стоило ли оно того? Не знаю. Очень надеюсь, что хозяева понимают, что делают. Потому что мы не понимаем. Наш обречённый сайт выглядит гораздо симпатичнее и по многим параметром лучше. Если бы вложить в его маркетинг и разработку даже намного меньшую сумму, чем мы заплатили, то наверняка можно было бы его раскрутить...
А вот у "дочки" уже пару недель вываливается стандартная ошибка ASP.NET в одном из главных разделов. У нас такое представить невозможно - максимум через полчаса все будут бегать и пытаться починить... Я шучу: "Наверное, там все сейчас бухают. Маленькая фирма, им заплатили по три миллиона на человека... разве кто-то станет теперь напрягаться?"
Как бы то ни было, решение принято на самом высшем уровне. Почему - не нашего холопского ума это дело...
Мне выпала печальная обязанность: убить наш сайт. А вместо него сделать промежуточную страницу (interstitial), которая затем перенаправляет на приобретенный сайт. Перенаправлять прямо сразу нехорошо - это собьет клиентов с толку, ведь убиваемая торговая марка уже успела стать довольно известной.
Я решил сделать interstitial, не используя ни ASP.NET, ни какие-либо веб-сервисы. Так, чтобы это был просто HTML. Пришлось повозиться. Во-первых, нужно поддерживать некоторые старые ссылки, да и ещё несколько доменов и языков. Для этого я использовал IIS Url Rewrite. Из-за того, что сайт статический, пришлось кое-где делать copy-paste. Это не очень хорошо, если в будущем понадобится вносить изменения. Но зато статический сайт будет потреблять гораздо меньше ресурсов, и мы будет знать, что нет никаких зависимостей (ему не нужны ни базы данных, ни сервисы).
Вторая проблема была в том, что дизайнеры придумали довольную хитрую анимацию. Пару дней возился, чтобы она работала во всех браузерах, включая Internet Explorer 6. Сделал. А тут - прикол: оказывается, наш дочерний сайт не поддерживает IE6. Т.е. мой interstitial в IE6 работает, но толку от этого - никакого :) После перенаправления вываливатся ошибка...
Нас заверили, что это совершенно не грозит увольнениями. Якобы у тех - свой рынок, у нас - свой. Правда, у нас есть один новый, отличный сайт, который всё-таки прямо конкуриует с теми ребятами. Поэтому его придется закрыть, а трафик перенаправить в дочернюю компанию.
"Связаны ли сокращения в прошлом году с тем, что мы уже тогда планировали эту сделку? Нет, совершенно не связаны". Ага, так мы вам и поверили: ведь сократили в первую очередь именно тех людей, который работали над этим самым, теперь уже ненужным сайтом...
Дочерняя компания - маленький стартап. По неподтвержденным слухам, мы за них заплатили немало: если пересчитать на количество сотрудников, то выходит примерно по три 3 миллиона фунтов за одну голову! Более того, вроде как эти деньги мы взяли в кредит.
Стоило ли оно того? Не знаю. Очень надеюсь, что хозяева понимают, что делают. Потому что мы не понимаем. Наш обречённый сайт выглядит гораздо симпатичнее и по многим параметром лучше. Если бы вложить в его маркетинг и разработку даже намного меньшую сумму, чем мы заплатили, то наверняка можно было бы его раскрутить...
А вот у "дочки" уже пару недель вываливается стандартная ошибка ASP.NET в одном из главных разделов. У нас такое представить невозможно - максимум через полчаса все будут бегать и пытаться починить... Я шучу: "Наверное, там все сейчас бухают. Маленькая фирма, им заплатили по три миллиона на человека... разве кто-то станет теперь напрягаться?"
Как бы то ни было, решение принято на самом высшем уровне. Почему - не нашего холопского ума это дело...
Мне выпала печальная обязанность: убить наш сайт. А вместо него сделать промежуточную страницу (interstitial), которая затем перенаправляет на приобретенный сайт. Перенаправлять прямо сразу нехорошо - это собьет клиентов с толку, ведь убиваемая торговая марка уже успела стать довольно известной.
Я решил сделать interstitial, не используя ни ASP.NET, ни какие-либо веб-сервисы. Так, чтобы это был просто HTML. Пришлось повозиться. Во-первых, нужно поддерживать некоторые старые ссылки, да и ещё несколько доменов и языков. Для этого я использовал IIS Url Rewrite. Из-за того, что сайт статический, пришлось кое-где делать copy-paste. Это не очень хорошо, если в будущем понадобится вносить изменения. Но зато статический сайт будет потреблять гораздо меньше ресурсов, и мы будет знать, что нет никаких зависимостей (ему не нужны ни базы данных, ни сервисы).
Вторая проблема была в том, что дизайнеры придумали довольную хитрую анимацию. Пару дней возился, чтобы она работала во всех браузерах, включая Internet Explorer 6. Сделал. А тут - прикол: оказывается, наш дочерний сайт не поддерживает IE6. Т.е. мой interstitial в IE6 работает, но толку от этого - никакого :) После перенаправления вываливатся ошибка...
понедельник, 11 апреля 2011 г.
Сотрудник года
Раз в год мы демократическим путем выбираем лучшего сотрудника года. Руководство в этом процессе не участвует. Победитель получает не только почётную грамоту, но и вполне ценный приз. Тем, кто набрал голосов поменьше - просто грамоту. Как обычно, среди номинантов было полно SEOшников и продавцов, но почти не было айтишников. Один сисадмин попал в финал, но вот незадача: он уже уволился, вручать грамоту оказалось некому.
Как и в прошлом году, обиженные айтишники ворчали: "Надо в следующий раз сговориться, проголосовать за кого-то одного, а приз поделить на всех".
Я ещё за полгода придумал, кого буду рекомендовать, и что именно напишу. Опа! Этот человек собрался увольняться. Выбрал другого, продумал рекомендацию. А он тоже уволился! Что за напасть! К счастью, тот первый коллега решил поработать ещё несколько месяцев, поэтому я как раз успел его номинировать. Несколько рекомендаций особенно понравились кадровикам, и их зачитали в слух. Мою прочли первой:
К сожалению, он даже не попал в финал. Проработал 8 лет, на нем держался весь product development. А сейчас вот отправляется в кругосветное путешествие. Тяжело нам будет без него. Это был единственный человек, который мог ответить (или хотя бы попытаться ответить) на любой наш вопрос...
Специальный приз вручили за самую оригинальную рекомендацию: впервые за все годы нашелся человек, который проголосовал за себя. "Он - всегда со мной: на работе, в тренжерном зале, дома. Он никогда со мной не спорит. Наши мысли всегда совпадают".
Тех, кто проработал на компанию 10 лет, пригласили на ланч с хозяином. Народ ворчал: "За 10 лет работы - один бесплатный обед". Но на самом деле это не так уж плохо: вот Пустовойтов пишет, что на "Турбоатоме" выдали по 50 грн тем, кто проработал на заводе аж по 45 (!) лет.
Одного из наших ветеранов незаслуженно забыли: посчитали, что он работал 8 лет, хотя на самом деле 10. Посыпались предположения, что, наверное, первые два года он работал за кэш? Но нет, ошибка произошла потому, что первые два года он был контрактником.
Собрание прошло под девизом "люди - наш главный капитал". Довольно смешно это звучит после недавних сокращений...
Как и в прошлом году, обиженные айтишники ворчали: "Надо в следующий раз сговориться, проголосовать за кого-то одного, а приз поделить на всех".
Я ещё за полгода придумал, кого буду рекомендовать, и что именно напишу. Опа! Этот человек собрался увольняться. Выбрал другого, продумал рекомендацию. А он тоже уволился! Что за напасть! К счастью, тот первый коллега решил поработать ещё несколько месяцев, поэтому я как раз успел его номинировать. Несколько рекомендаций особенно понравились кадровикам, и их зачитали в слух. Мою прочли первой:
Simply the best Product Manager I ever worked with. His specifications are as scientific as a PhD paper, and at the same time as exciting as a blockbuster movie.
К сожалению, он даже не попал в финал. Проработал 8 лет, на нем держался весь product development. А сейчас вот отправляется в кругосветное путешествие. Тяжело нам будет без него. Это был единственный человек, который мог ответить (или хотя бы попытаться ответить) на любой наш вопрос...
Специальный приз вручили за самую оригинальную рекомендацию: впервые за все годы нашелся человек, который проголосовал за себя. "Он - всегда со мной: на работе, в тренжерном зале, дома. Он никогда со мной не спорит. Наши мысли всегда совпадают".
Тех, кто проработал на компанию 10 лет, пригласили на ланч с хозяином. Народ ворчал: "За 10 лет работы - один бесплатный обед". Но на самом деле это не так уж плохо: вот Пустовойтов пишет, что на "Турбоатоме" выдали по 50 грн тем, кто проработал на заводе аж по 45 (!) лет.
Одного из наших ветеранов незаслуженно забыли: посчитали, что он работал 8 лет, хотя на самом деле 10. Посыпались предположения, что, наверное, первые два года он работал за кэш? Но нет, ошибка произошла потому, что первые два года он был контрактником.
Собрание прошло под девизом "люди - наш главный капитал". Довольно смешно это звучит после недавних сокращений...
пятница, 8 апреля 2011 г.
Заливные луга
Несколько месяцев назад Марина ездила на собеседование в Horsham. Это хрен знает, даже на машине больше часа от нас. На поезде Да ещё и офис не самом городе. Добраться до бизнес-парка от станции в принципе можно на служебным автобусе, но, насколько я понял, в него не берут посторонних.
Я вроде нашел другой автобус. Но он ходит раз в час, и потом ещё идти пешком минут 35. Судя по Google Maps, тропинка вроде бы есть.
Ехать на такси прямо из дома слишком дорого, тем более, что надо было ещё там ждать часа два или два с половиной: просили что-то в районе 100 фунтов. В конце концов решили пойти на компромисс: сначала на поезде с пересадкой, потом на такси от станции.
И очень хорошо! Потому что тропинка, которую я высмотрел на карте, на самом деле проходила через заливные луга! Пройти там можно только в болотных сапогах.
На работу Марину не взяли. Видимо, слишком много просила. Мы уже потом нашли их объявление и увидели, что там зарплаты очень, очень далеки от лондонских. Хотя фирма очень известная и богатая. Ну, а просить меньше и тратить больше часа на дорогу, да ещё и покупать для этого машину не было смысла...
Было очень обидно. Ведь этот работодатель был одной из главных причин, почему Марина так спешила сдать на права и спускала деньги на инструкторов: без машины туда добираться нереально, а переехать в Horsham мы в тот момент не могли, потому что пришлось бы досрочно разорвать контракт на аренду квартиры. Кроме того, именно из-за этого собеседования Марина в прошлом году не осталась в Харькове ухаживать за мамой, а вернулась в Лондон. Вернулась, а тут оказалось, что из-за снежных заносов они временно не работали, и собеседование отменили, можно было не прилетать...
Ну, спасибо, что ей хоть дали 15 фунтов, чтобы вернуться к станции на такси. Это в первый раз...
А сам Horsham Марине очень понравился.
Я вроде нашел другой автобус. Но он ходит раз в час, и потом ещё идти пешком минут 35. Судя по Google Maps, тропинка вроде бы есть.
Ехать на такси прямо из дома слишком дорого, тем более, что надо было ещё там ждать часа два или два с половиной: просили что-то в районе 100 фунтов. В конце концов решили пойти на компромисс: сначала на поезде с пересадкой, потом на такси от станции.
И очень хорошо! Потому что тропинка, которую я высмотрел на карте, на самом деле проходила через заливные луга! Пройти там можно только в болотных сапогах.
На работу Марину не взяли. Видимо, слишком много просила. Мы уже потом нашли их объявление и увидели, что там зарплаты очень, очень далеки от лондонских. Хотя фирма очень известная и богатая. Ну, а просить меньше и тратить больше часа на дорогу, да ещё и покупать для этого машину не было смысла...
Было очень обидно. Ведь этот работодатель был одной из главных причин, почему Марина так спешила сдать на права и спускала деньги на инструкторов: без машины туда добираться нереально, а переехать в Horsham мы в тот момент не могли, потому что пришлось бы досрочно разорвать контракт на аренду квартиры. Кроме того, именно из-за этого собеседования Марина в прошлом году не осталась в Харькове ухаживать за мамой, а вернулась в Лондон. Вернулась, а тут оказалось, что из-за снежных заносов они временно не работали, и собеседование отменили, можно было не прилетать...
Ну, спасибо, что ей хоть дали 15 фунтов, чтобы вернуться к станции на такси. Это в первый раз...
А сам Horsham Марине очень понравился.
Как в зоопарке
Марина пытается искать работу в каких-то других областях, потому что в NHS сейчас попасть, наверное, ещё тяжелее, чем инвестиционный банк. Как правило, отказывают, даже не открывая резюме: "К сожалению, эта вакансия только для тех, кто сейчас работает в NHS".
Ходила вот в фирму, которая выпускает детские книжки по медицине. Как ни странно, в требованиях было указано, что знание казахского и русского языка - дополнительное преимущество. Очень хорошо - два-три казахских слова Марина ещё помнит после школы. Но зачем, интересно, им это надо? Русский ещё можно понять - большой рынок сбыта... а причем тут казахский? Оказывается, что их программист живет в Астане.
Собеседование началось с неожиданного вопроса: "Хочешь ли ты работать в зоопарке?" Это в том смысле, что для работы в sales надо рычать, отбирать, требовать и быть услышанным, а с подчиненными работать, как с обезьянами.
На работу не взяли. "Понимаешь, хороший продавец - это настоящий псих, который с клиента просто так не слезет. А ты вроде производишь впечатление нормального, уравновешенного человека. Это нам не подходит".
Ходила вот в фирму, которая выпускает детские книжки по медицине. Как ни странно, в требованиях было указано, что знание казахского и русского языка - дополнительное преимущество. Очень хорошо - два-три казахских слова Марина ещё помнит после школы. Но зачем, интересно, им это надо? Русский ещё можно понять - большой рынок сбыта... а причем тут казахский? Оказывается, что их программист живет в Астане.
Собеседование началось с неожиданного вопроса: "Хочешь ли ты работать в зоопарке?" Это в том смысле, что для работы в sales надо рычать, отбирать, требовать и быть услышанным, а с подчиненными работать, как с обезьянами.
На работу не взяли. "Понимаешь, хороший продавец - это настоящий псих, который с клиента просто так не слезет. А ты вроде производишь впечатление нормального, уравновешенного человека. Это нам не подходит".
Банановое пиво
Попробовал пиво из бананового хлеба. Понравилось.
Интересно, что у англичан вполне нормальным считается отпить у коллеги из кружки: "О, я такого не пробовал... Не возражаешь, если глотну?" И так делают не какие-то алкаши или отвязанные подростки, а вполне солидные дядьки в костюмах.
Интересно, что у англичан вполне нормальным считается отпить у коллеги из кружки: "О, я такого не пробовал... Не возражаешь, если глотну?" И так делают не какие-то алкаши или отвязанные подростки, а вполне солидные дядьки в костюмах.
вторник, 5 апреля 2011 г.
Си-хаш
Сегодня собеседовали француза на должность C# / ASP.NET Developer. На вопросы он отвечал очень хорошо, но при этом не знал, что C# произносится как "си-шарп". Упорно говорил "си-хаш" и даже спорил, когда его поправляли.
Странно. Даже когда жил в Украине, я не говорил "си-решётка" про C# или "точка-нэт" про .NET. А у ж раз приехал в Англию, то желательно знать, как правильно называется твоя должность на английском языке :)
Странно. Даже когда жил в Украине, я не говорил "си-решётка" про C# или "точка-нэт" про .NET. А у ж раз приехал в Англию, то желательно знать, как правильно называется твоя должность на английском языке :)
Судоку
Вопрос на собеседовании: "Расскажите, как бы Вы написали программу для игры в судоку? как реализовать пользовательский интерфейс под Windows? для Веба? какие проверки нужно делать?"
Проблема в том, что я не знал, как в это судоку играть! Вижу каждый день, что люди в метро заполняют какие-то цифры, но сам никогда не интересовался правилами...
Проблема в том, что я не знал, как в это судоку играть! Вижу каждый день, что люди в метро заполняют какие-то цифры, но сам никогда не интересовался правилами...
понедельник, 4 апреля 2011 г.
Третий сверху
Задали стандартный вопросик по SQL Server: "Как найти сотрудника с самой высокой зарплатой?" Ну, это понятно - SELECT TOP 1 emp_id FROM salary ORDER BY salary DESC.
Следующий вопрос немного посложнее: "Найти сотрудника с третьей по величине зарплатой". Я это написал, как обычно, с использованием функции ROW_NUMBER(): отсортировал по убыванию зарплаты, в подзапросе пронумеровал строки, а потом отфильтровал по номеру.
А оказывается, есть более изящное решение: отфильтровать по убыванию, взять трех самых высокооплачиваемых сотрудников, а потом их "перевернуть" (отфильтровать по возрастанию зарплаты и взять самого первого):
SELECT TOP 1 emp_id
FROM
(
SELECT TOP 3 emp_id, salary
FROM salary
ORDER BY salary DESC
) top3
ORDER BY salary
Не уверен, правда, что это работает быстрее моего решения. Очень может быть, что одинаково - у SQL Server 2008 R2 хороший оптимизатор...
Следующий вопрос немного посложнее: "Найти сотрудника с третьей по величине зарплатой". Я это написал, как обычно, с использованием функции ROW_NUMBER(): отсортировал по убыванию зарплаты, в подзапросе пронумеровал строки, а потом отфильтровал по номеру.
А оказывается, есть более изящное решение: отфильтровать по убыванию, взять трех самых высокооплачиваемых сотрудников, а потом их "перевернуть" (отфильтровать по возрастанию зарплаты и взять самого первого):
SELECT TOP 1 emp_id
FROM
(
SELECT TOP 3 emp_id, salary
FROM salary
ORDER BY salary DESC
) top3
ORDER BY salary
Не уверен, правда, что это работает быстрее моего решения. Очень может быть, что одинаково - у SQL Server 2008 R2 хороший оптимизатор...
На "правило 28 дней" могут закрыть глаза?
Наткнулся на интересный абзац о том, как вычислять 5 лет для тех, кто получает ILR после Tier 1:
Иными словами, если ты въехал в страну позже, чем через 28 дней после получения Tier 1 (или HSMP), но не позже, чем через 3 месяца, то, возможно, продлевать визу второй раз не нужно. Очень интересно!
Но не спешите радоваться: во-первых, это пока только проект; во-вторых, написано, что это делается на усмотрение кейсвокера...
2.2 Applications that fall short of the five year continuous period
In some cases, applicants may have been granted 5 years continuous leave, but will not have spent 5 years continuously in the UK before their current leave expires. Caseworkers may count the period between entry clearance being granted and the date the applicant entered the UK towards the 5 years, provided this period was not longer than 3 months.
Иными словами, если ты въехал в страну позже, чем через 28 дней после получения Tier 1 (или HSMP), но не позже, чем через 3 месяца, то, возможно, продлевать визу второй раз не нужно. Очень интересно!
Но не спешите радоваться: во-первых, это пока только проект; во-вторых, написано, что это делается на усмотрение кейсвокера...
пятница, 1 апреля 2011 г.
Sitemap Index
Как известно, в файле XML Sitemap должно быть не больше 50 тысяч URL. Если надо больше, то разбиваешь их на отдельные файлы и ещё создаешь Sitemap index, в котором перечисляешь имена всех sitemaps.
Я столкнулся с неожиданной проблемой: поисковики регулярно пытаются затребовать несуществующие sitemap-файлы. Оказывается, всё дело в задержке между чтением sitemap index и sitemaps. Т.е. Google открывает index и начинает идти по списку. Но за сутки он обычно не успевает скачать все наши sitemaps. А на следующий день они перегенерируются заново, а старые файлы затираются.
Почему же он не успевает? Потому что в сумме эти файлы занимают примерно 10 ГБ! Да, у нас очень много всяких разных URL, мы очень любим SEO :)
Ну, хорошо, 10 ГБ. Но почему мы их стираем каждый день? Оказывается, разработчики пошли по самому простому пути: раз в сутки Windows-сервис лезет в разные базы данных и генерирует все возможные URL; он не пытается проверять, это новый адрес или нет, просто генерирует огромный список. Все адреса записываются в файлы со случайными именами, вроде sitemap_9E683351-E092-4298-A4B7-6DFE219E83A7.xml. На следующий день он все стирает и начинает с нуля.
А вот как бы сделал я: все URL лежат в большой таблице базы данных; Windows-сервис использует MERGE, чтобы вставить недостающие строки. Если строка уже существовала, то с помощью того же самого MERGE обновляем её timestamp. Напротив каждой URL записано имя файла (например, sitemap123.xml), которое присваивается навсегда. Нужно ещё предусмотреть уборку мусора (удаление URL, которые не были обнаружены сегодня). Правда, при удалении возникает проблемка: в некоторых файлах окажется меньше 50 тысяч записей. Можно на это просто закрыть глаза, потому что удаление бывает редко. А можно пытаться заполнить "дыры" новыми URL.
Чем это лучше? Ну, во-первых, это решает описанную выше проблему. Во-вторых, уменьшает ненужный трафик от роботов. Ведь идея sitemap index заключается в том, чтобы роботы знали, какие конкретные sitemaps обновились, чтобы им не приходилось качать всё заново. В снижении трафика помогает не только index, но и Conditional GET (Last-Modified / If-Modified-Since): если конкретный sitemap-файл не меняется месяцами, то сервер просто каждый день возвращает HTTP 304 (Not Modified), а не файл целиком (как это делаем мы сейчас).
Ну, и, наконец, к Гуглю и другим поисковикам надо относится с уважением, стараться облегчить их жизнь. И тогда они ответят взаимностью - быстрее проиндексируют новый контент. А мы, получается, каждый день бомбим Гугль миллионами адресов и заставляем его самостоятельно принять решение о том, что индексировать в первую очередь.
Кстати, многие не знают, но на самом деле Гугль не слишком интересуется тем, что ты указал в полях lastmod и freq. Для него гораздо важнее найти такие URL, которые он ещё не видел раньше. Вот их он обычно индексирует в первую очередь, а не обязательно те страницы, которые ты пометил, как обновленные. По-крайней мере, такое поведение я вижу.
Ну, это всё мечты. А пока, как обычно времени не хватает, поэтому решили проблему очень просто: перегенерируем sitemaps не раз в день, а раз в два дня. Ошибок стало меньше.
Я столкнулся с неожиданной проблемой: поисковики регулярно пытаются затребовать несуществующие sitemap-файлы. Оказывается, всё дело в задержке между чтением sitemap index и sitemaps. Т.е. Google открывает index и начинает идти по списку. Но за сутки он обычно не успевает скачать все наши sitemaps. А на следующий день они перегенерируются заново, а старые файлы затираются.
Почему же он не успевает? Потому что в сумме эти файлы занимают примерно 10 ГБ! Да, у нас очень много всяких разных URL, мы очень любим SEO :)
Ну, хорошо, 10 ГБ. Но почему мы их стираем каждый день? Оказывается, разработчики пошли по самому простому пути: раз в сутки Windows-сервис лезет в разные базы данных и генерирует все возможные URL; он не пытается проверять, это новый адрес или нет, просто генерирует огромный список. Все адреса записываются в файлы со случайными именами, вроде sitemap_9E683351-E092-4298-A4B7-6DFE219E83A7.xml. На следующий день он все стирает и начинает с нуля.
А вот как бы сделал я: все URL лежат в большой таблице базы данных; Windows-сервис использует MERGE, чтобы вставить недостающие строки. Если строка уже существовала, то с помощью того же самого MERGE обновляем её timestamp. Напротив каждой URL записано имя файла (например, sitemap123.xml), которое присваивается навсегда. Нужно ещё предусмотреть уборку мусора (удаление URL, которые не были обнаружены сегодня). Правда, при удалении возникает проблемка: в некоторых файлах окажется меньше 50 тысяч записей. Можно на это просто закрыть глаза, потому что удаление бывает редко. А можно пытаться заполнить "дыры" новыми URL.
Чем это лучше? Ну, во-первых, это решает описанную выше проблему. Во-вторых, уменьшает ненужный трафик от роботов. Ведь идея sitemap index заключается в том, чтобы роботы знали, какие конкретные sitemaps обновились, чтобы им не приходилось качать всё заново. В снижении трафика помогает не только index, но и Conditional GET (Last-Modified / If-Modified-Since): если конкретный sitemap-файл не меняется месяцами, то сервер просто каждый день возвращает HTTP 304 (Not Modified), а не файл целиком (как это делаем мы сейчас).
Ну, и, наконец, к Гуглю и другим поисковикам надо относится с уважением, стараться облегчить их жизнь. И тогда они ответят взаимностью - быстрее проиндексируют новый контент. А мы, получается, каждый день бомбим Гугль миллионами адресов и заставляем его самостоятельно принять решение о том, что индексировать в первую очередь.
Кстати, многие не знают, но на самом деле Гугль не слишком интересуется тем, что ты указал в полях lastmod и freq. Для него гораздо важнее найти такие URL, которые он ещё не видел раньше. Вот их он обычно индексирует в первую очередь, а не обязательно те страницы, которые ты пометил, как обновленные. По-крайней мере, такое поведение я вижу.
Ну, это всё мечты. А пока, как обычно времени не хватает, поэтому решили проблему очень просто: перегенерируем sitemaps не раз в день, а раз в два дня. Ошибок стало меньше.
Подписаться на:
Сообщения (Atom)