Чем занят отдел обработки запросов в Поиске Mail.Ru? Если одним предложением, мы пытаемся «понять» запрос, то есть осуществляем подготовку запроса к поиску, приводим его в вид, пригодный для взаимодействия с нашим индексом, ранжированием, подмесами и прочими компонентами. Если же вы хотите узнать о нашей работе подробнее — добро пожаловать под кат. В этом посте я расскажу об одной из областей нашей работы — парсере запросов.

Всем привет! Мы запускаем свой подкаст под названием «Метрика». Это шоу для тех, кто создает и анализирует продукты и сервисы на различных платформах.

В первом выпуске

Основатели и партнеры компании UIDG Платон Днепровский (hryusha) и Алексей Копылов (copylove) вместе с Дмитрием Кабановым (dmitrykabanov) обсуждают ситуацию с образованием в ИТ и аспекты мотивации в этой области.

На киносъемках очень популярна фраза: «А, фиг с ним, на постпродашкене дорисуем!». Такой чудесной вещи, как доработке на постпродакшене съемочного «фиг с ним», и посвящена сия статья. Здесь я расскажу о личном опыте и пользе использования данного заклинания во время работы над короткометражным фильмом «Секунда свободного падения», режиссёром коего являюсь.





До начала съемок я не планировал пользоваться цифровой обработкой вообще (за исключением разве что цветокоррекции), желая добиться максимально реалистичного изображения. Ну-ну!.. Волшебное «фиг с ним» имеет невероятную мощь, всем чародеям известно это!

Просматривая одно из обучающих видео "Школы разработки интерфейсов" Яндекса, наткнулся на ссылку на офигенный труд израильской веб-программистки Тали Гарсиэль (Tali Garsiel) "How browsers work" (Как работают браузеры).

Она в течение нескольких лет отслеживала всю издаваемую информацию о внутреннем устройстве браузеров, изучала исходный код WebKit и Gecko и, в конце концов, собрала все воедино. Вот что пишет сама Тали:

Когда на 90% компьютеров был установлен IE, приходилось мириться с тем, что это загадочный «черный ящик», однако теперь, когда более половины пользователей выбирает браузеры с открытым исходным кодом, пришло время разобраться, что скрывается у них внутри, в миллионах строк программного кода на C++...

Пролистав, я был поражен — отличная работа. Внутреннее устройство браузеров, алгоритмы разбора — все хорошо иллюстрировано, доступно и понятно. И без излишних подробностей, страниц на 30-40. Как раз то, что нужно. Решил — это надо обязательно перевести. Покопался еще немного — оказалось перевод уже как 1,5 года есть!

Возможно для кого-то это давно уже не новость, но, надеюсь, для тех, кто не слышал, будет полезно (на хабре упоминаний не нашел).

Под катом содержание перевода, чтобы решить стоит ли читать.

Уровень подготовки веб-мастера: средний/высокий

Нам нравится работать с данными. Мы уделяем много времени изучению аналитической информации о наших веб-сайтах. Любой веб-разработчик, которому это тоже интересно, наверняка заметил, насколько увеличился в последнее время объем трафика с мобильных устройств. За последний год значительно вырос процент просмотров страниц наших основных сайтов со смартфонов и планшетных ПК. Это значит, что все больше посетителей используют устройства с современными браузерами, поддерживающими последние версии HTML, CSS и JavaScript. Однако ширина экранов таких устройств обычно ограничена 320 пикселями.

Мы стремимся повысить доступность наших продуктов, то есть предоставить всем пользователям оптимальные возможности для работы с ними. Перед нами стояла дилемма: создать специальные мобильные версии сайтов или адаптировать существующие сайты и новые проекты для просмотра как на настольных компьютерах, так и на мобильных устройствах. Создание двух версий сайта позволило бы нам оптимизировать каждую из них для конкретного оборудования, но использование одного общего сайта дает возможность сохранить канонический URL. При этом исключаются сложные переадресации и упрощается совместное использование веб-адресов. Удобство обслуживания является важным фактором, поэтому мы решили не создавать разные версии страниц, а начали обдумывать, как обеспечить выполнение следующих условий:

1. четкое отображение страниц на экране с любым разрешением;
2. возможность просмотра группы контента на любом устройстве;
3. отсутствие горизонтальной полосы прокрутки независимо от размера окна.

Это перевод поста, опубликованного в англоязычном блоге «Лаборатории Касперского».
Он не столько о вирусах, сколько о демосцене и лучших произведениях в этом жанре искусства.

Недавно Евгений Касперский опубликовал в своем блоге запись «Призраки вирус-оперы, или Ситхи Ассемблера», посвященную сверхкомпактным и мощным вредоносным приложениям, обнаруженным недавно, но написанным в стиле 15-летней давности. Мой возраст позволяет помнить этих парней и их блестящую работу – речь ведь не обязательно о создателях вирусов, они были лишь частью программистского сообщества, специализировавшегося на «ручном» написании кода и программировании на ассемблере. Это похоже на Джедаев и Ситхов из мира «Звездных войн» – существ, чье оружие, лазерные мечи, было крайне специфическим и, несмотря на это, воспринималось всеми остальными героями как одно из самых мощных (кроме шуток, спросите Йоду). Увы, похоже, людей, которые помнят этих мастеров-программистов, осталось трое (я, Касперский и Билл Гейтс). А если серьезно – в сегодняшнем мире, где драйвер мышки занимает 50 мегабайт, довольно трудно вообразить, на что способен хакер старой школы при совсем небольшом количестве выделенных ресурсов. Поэтому я решил показать, о чем говорит Евгений, на несколько ином примере – а вы уж решайте, насколько плохи новости об «олдскульных» авторах заразы.

Что такое хороший язык программирования? Какими качествами и характеристиками он должен обладать? Ответ дать сложно. Вот одно из возможных определений: хороший ЯП должен хорошо решать возложенные на него задачи. Ведь ЯП — лишь инструмент в руках программиста. А инструмент обязан помогать нам в работе. В конце концов, это же и есть причина его создания. Разные ЯП стараются решать разные проблемы (с переменным успехом). Цель, которая ставилась при проектировании Clojure — сделать написанные нами программы простыми. И, как следствие, ускорить их создание, тестирование. А главное, уменьшить время на их понимание, изменение и сопровождение.

Неспокойная политика поискового гиганта по отношению к своим сервисам, в том числе и весьма популярным, судя по всему, продолжается — в интернете с подачи ресурса geek.com ширятся слухи о том, что Google намерен вместо целой плеяды всевозможных сервисов для общения предоставить пользователям один — универсальный.

Ссылаясь на, как принято говорить в таких случаях, надежные источники, обозреватели geek.com утверждают, что Google Talk, Voice, Messenger, Hangout из Google+, Chat for Drive collaboration (к счастью, Gmail останется просто почтой) будут объединены в один сервис Google Babble, который будет унифицировать коммуникационные возможности их всех, и при этом будет работать на основных мобильных платформах, включая Blackberry и Windows Phone.

Вообще, волна слухов вокруг Google относительно политики своих сервисов довольно касается и ряда других служб. Вчера стало известно, что поисковый гигант, по всей видимости, намерен стать конкурентом Evernote, тайно выкатив на обозрение Google Keep. Также оказалось, что теперь Google Talk не принимает в контакт-лист запросы на добавление, отправленные с других Jabber-серверов, по поводу чего Фонд свободного программного обеспечения выразил определенное беспокойство даже с учётом того, что, возможно, эта блокировка вызвана борьбой со спамом.

Записи с последней конференции HPC — High Performance Conference, состоявшейся 6 декабря 2012, никак не анонсировались, хотя заслуживают внимания.

Под катом видеозаписи следующих докладов:

1. Практические вопросы использования NOSQL в высоконагруженном проекте
   Дмитрий Ананьев, Руководитель группы разработки новых сервисов, Мамба
2. Как работает «умная живая миграция» в Jelastic
3. Дмитрий Лазаренко, Директор R&D, Jelastic Russia
4. Parallels Cloud Server как платформа для высокопроизводительных систем
   Дмитрий Мишин, Team-lead отдела серверной виртуализации, Parallels
5. Облачная платформа Windows Azure для высоконагруженных проектов
   Владимир Юнев, Technical evangelist, DPE, Microsoft Russia

и одно видео с фестиваля профессионального развития BitByte:

1. Badoo Desktop: оптимизация приложения на миллион юзеров
   Руководитель проекта десктопных приложений компании Badoo.

Мне постоянно приходится слышать от студентов и начинающих гейм-дизайнеров – да, честно говоря, и от бывалых программистов тоже – один и тот же вопрос, который звучит примерно так: “Какую архитектуру AI мне выбрать для своего проекта?”. Этим вопросом пестрят форумы, его можно услышать на конференции разработчиков игр GDC, и, конечно же, его не один раз вспоминают во время пре-продакшна создатели любой игры – от AAA-класса до инди. Я работаю консультантом по игровому AI, поэтому я постоянно слышу ее от своих клиентов.

Обычно, самый лучший ответ на этот вопрос – «Когда как». Вот только подобный ответ мало кого устраивает, поэтому после него мне приходится устраивать самый настоящий допрос.

В блоге для веб-мастеров инженеры Google подготовили и выложили два руководства разной степени сложности для тех, кто еще не знаком с базовыми методами оптимизации под поисковую машину Google.

Надо сразу сказать, что первое руководство действительно для новичков — профессионалы вряд ли обнаружат там нечто секретное и таинственное. Любопытно только то, что в Google не поленились и подготовили соответствующий одностраничный PDF-документ сразу в 13 языковых редакциях, включая и русский (английская версия). При этом документ (А4) выглядит визуально привлекательно и информативно, так что его можно распечатать и повесить в офисе, если вдруг возникнет необходимость в напоминании банальностей.

Второй документ более серьезного уровня и уже только на английском языке. Он довольно подробно и с примерами описывает различные «best practices» вроде создания уникальных заголовков веб-страниц, заполнения мета-тегов или улучшения структуры URL. Забрать документ можно отсюда.

Итак, как же можно связаться с ровером, находящимся на Марсе? Вдумайтесь — даже когда Марс находится на наименьшем расстоянии от Земли, сигналу нужно преодолеть пятьдесят пять миллионов километров! Это действительно огромное расстояние. Но как же маленькому, одинокому марсоходу удается передавать свои научные данные и прекрасные полноцветные изображения так далеко и в таком количестве? В самом первом приближении, это выглядит примерно вот так (я очень старался, правда):

Заголовок, выраженный словами, понадобился только для поисковой находимости. Но речь пойдёт о роли символьной конструкции «|0» в JavaScript.

Впервые на неё я обратил внимание, когда переводил FAQ про asm.js и читал спецификации этого подмножества языка JavaScript. Там «|0» служит, например, для указания типа значения, возвращаемого из функции: увидели «|0» после значения — значит, перед нами знаковое целое.

Вдругорядь я заметил конструкцию «|0» в примере кода на Гитхабе, где происходило преобразование к целому числу результата деления на 1024².

Тогда глаза мои открылись, и я увидел прекрасные возможности:

( 3|0 ) === 3;       // целые числа не изменяет
( 3.3|0 ) === 3;     // у дробных чисел отбрасывает дробную часть
( 3.8|0 ) === 3;     // не округляет, а именно отбрасывает дробную часть
( -3.3|0 ) === -3;   // в том числе и у отрицательных дробных чисел
( -3.8|0 ) === -3;   // у которых Math.floor(-3.3) == Math.floor(-3.8) == -4
( "3"|0 ) === 3;     // строки с числами преобразуются к целым числам
( "3.8"|0 ) === 3;   // при этом опять же отбрасывается дробная часть
( "-3.8"|0 ) === -3; // в том числе и у отрицательных дробных чисел
( NaN|0 ) === 0;     // NaN приводится к нулю
( Infinity|0 ) === 0;     // приведение к нулю происходит и с бесконечностью,
( -Infinity|0 ) === 0;    // и с минус бесконечностью,
( null|0 ) === 0;         // и с null,
( (void 0)|0 ) === 0;     // и с undefined,
( []|0 ) === 0;           // и с пустым массивом,
( [3]|0 ) === 3;          // но массив с одним числом приводится к числу,
( [-3.8]|0 ) === -3;      // в том числе с отбрасыванием дробной части,
( [" -3.8 "]|0 ) === -3;  // и в том числе с извлечением чисел из строк,
( [-3.8, 22]|0 ) === 0    // но массив с несколькими числами вновь зануляется
( {}|0 ) === 0;                // к нулю также приводится пустой объект
( {'2':'3'}|0 ) === 0;         // или не пустой
( (function(){})|0 ) === 0;    // к нулю также приводится пустая функция
( (function(){ return 3;})|0 ) === 0;    // или не пустая

Итак, во-первых, перед нами удобное средство отбрасывания дробной части.

• По отношению к отрицательным числам оно полезно тем, что дробное число превращается не в ближайшее меньшее целое число (возрастая по модулю), как это случилось бы после «Math.floor()», а в ближайшее меньшее по модулю целое число (возрастая по значению). Нередко именно это и требуется.
   
• По отношению к положительным числам оно полезно уж тем одним, что конструкция «|0» более чем на порядок короче по сравнению с «Math.floor()». Поэтому она может и должна вызывать у разработчиков привыкание не меньшее, чем та принятая в jQuery запись «$()», о которой я говорил четыре дня назад, что с неё никто добровольно не перейдёт обратно на «document.getElementsByClassName()», например.

Во-вторых, перед нами удобное средство преобразования различных типов к целым числам.

Долго думал над заголовком, в итоге в него попали пара интересных вопросов из докладов прошедшей недавно, уже восьмой по счету, конференции «Свободное программное обеспечение в высшей школе».

Мероприятие это традиционно проводится зимой в уютном здании Университета города Переславля-Залесского Ярославской области, в несколько как бы семейной обстановке, а потому совсем широкой общественности не известное. А меж тем, каждый год бывают весьма любопытные доклады, и еще более интересные докладчики. Четыре из них хотелось бы выделить в этом топике, хотя внимания заслуживают все. По традиции тематика докладов (особенно в первый день) выходит за рамки тематики конференции, и тем интереснее их слушать.

1) «СПО. Кризис среднего возраста?» (Хотел вынести в заголовок топика один из слайдов доклада — «Куда уехал цирк?», но воздержался)
В преддверии 30-летнего юбилея движения GNU, известный аналитик Антолий Якушин, человек широчайших познаний в области программного обеспечения, подводит некоторые итоги и, в частности, рассказывает: куда направлен отток разработчиков свободных проектов, так ли это страшно, почему в MIT сейчас так мало свободных проектов, почему Столлман не является социалистом и прочие животрепещущие вопросы

Месяц назад здесь было объявлено, что Алексей Брагин теперь читает авторский курс лекций об операционных системах. С тех пор Алексей успел провести уже несколько занятий, которые были записаны на видео. Думаю, вполне логичным шагом будет поделиться этими записями с сообществом. Что нам стоит поступить так же как, к примеру, сделал MIT?

Прошу принять во внимание, что это пилотный проект. А так конструктивная критика приветствуется, пожелания принимаются.
Приносим извинения за качество звука, смотреть лучше в HD и погромче.

Типичная работа сотрудника глазами самого сотрудника и глазами отдела безопасности

Первые две части данной темы были посвящены преимущественно веб-ресурсам. Эта часть более общая и не имеет как таковой привязки к профилю проекта (все же за исключением пары пунктов). Она освещает возможные, популярные векторы атак на сотрудников и на техническое обеспечение офиса компании (p.s. изначально хотел написать про security-тестирование, но решил «перепрыгнуть» эту тему в силу разных причин).

Автор не несет никакой ответственности за незаконное использование описанных методик и/или инструментов.

Продолжение перевода статьи Джона Оллспоу о личных качествах ведущих разработчиков.

Зрелые разработчики не жалуются просто так

Вместо этого они рассуждают, основываясь на наблюдениях, и предлагают варианты решения найденной ими проблемы. Один опытный менеджер сказал мне: «Никогда не приходи к своему начальнику с жалобами, если у тебя нет готового решения проблемы. И лучше, если решений будет несколько». Но даже если у вас не получилось найти ни одного решения — это уже лучше, чем жаловаться просто так.

Я рад продолжить рассказывать свои взгляды к подходам создания безопасных веб-ресурсов и веб-приложений и перейти от первой части, которая содержит в себе некоторые общеполезные security-инструкции при создании инфраструктуры для проекта, ко второй — разработке самого приложения.

Небольшое предисловие

Меня всегда интересовала история появлений научных понятий. Перед изучающим новый предмет сначала встает череда безликих определений. Некоторые из них таковыми и остаются, другие привлекают внимание и со временем вырастают в полноценные объекты «картины мира». В качестве недоступного идеала такого стремления можно привести высказывание Литлвуда о Рамануджане:

каждое натуральное число было его лучшим другом

Мне всегда было интересно не только освоить понятие, но и разобраться, как оно появилось. За каждым определением всегда стоит личность. Интересно понять, какие идеи лежали в основе того или иного понятия и почему новые определения были восприняты и поддержаны другими людьми с таким энтузиазмом, что остались в учебниках.

Далее будет приведено небольшое исследование подобного рода, объектом которого является понятие регулярного выражения.

Стив Бланк — гуру в области стартапов, основоположник концепции клиентоориентированной разработки, автор культовых книг — The Four Steps to the Epiphany и The Startup Owner's Manual -, фаундер восьми стартапов. Данная статья раскрывает причины, по которым стоит отказаться от традиционных подходов к построению стартапа.

После 20 лет работы в стартапах, я решил остановиться и посмотреть на модель разработки продукта (Product Development Model), которой следовал: понять, почему она была неуспешной в том, что касается нашей работы «вне офиса» — продаж, маркетинга и развития бизнеса.

У каждого стартапа есть какая-нибудь методология по разработке продукта, его запуску и управлению жизненным циклом. В идеальном случае, эти процессы содержат детальные планы, чек-пойнты и майлстоны для каждого этапа вывода продукта на рынок: определение размера рынка, оценка продаж, разработка маркетингово плана, приоритезация фич продукта. Но в конце концов, не смотря на все эти инструменты, 9 из 10 продуктов терпят неудачу.