Марина пытается искать работу в каких-то других областях, потому что в NHS сейчас попасть, наверное, ещё тяжелее, чем инвестиционный банк. Как правило, отказывают, даже не открывая резюме: "К сожалению, эта вакансия только для тех, кто сейчас работает в NHS".
Ходила вот в фирму, которая выпускает детские книжки по медицине. Как ни странно, в требованиях было указано, что знание казахского и русского языка - дополнительное преимущество. Очень хорошо - два-три казахских слова Марина ещё помнит после школы. Но зачем, интересно, им это надо? Русский ещё можно понять - большой рынок сбыта... а причем тут казахский? Оказывается, что их программист живет в Астане.
Собеседование началось с неожиданного вопроса: "Хочешь ли ты работать в зоопарке?" Это в том смысле, что для работы в sales надо рычать, отбирать, требовать и быть услышанным, а с подчиненными работать, как с обезьянами.
На работу не взяли. "Понимаешь, хороший продавец - это настоящий псих, который с клиента просто так не слезет. А ты вроде производишь впечатление нормального, уравновешенного человека. Это нам не подходит".
пятница, 8 апреля 2011 г.
Банановое пиво
Попробовал пиво из бананового хлеба. Понравилось.
Интересно, что у англичан вполне нормальным считается отпить у коллеги из кружки: "О, я такого не пробовал... Не возражаешь, если глотну?" И так делают не какие-то алкаши или отвязанные подростки, а вполне солидные дядьки в костюмах.
Интересно, что у англичан вполне нормальным считается отпить у коллеги из кружки: "О, я такого не пробовал... Не возражаешь, если глотну?" И так делают не какие-то алкаши или отвязанные подростки, а вполне солидные дядьки в костюмах.
вторник, 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)