Поисковые подсказки (саджест) — это не только пользовательский сервис, но ещё и очень мощная языковая модель, хранящая миллиарды поисковых запросов, поддерживающая нечёткий поиск, персонализацию и многое другое. Мы научились использовать саджест для того, чтобы предугадывать итоговый запрос пользователя и загружать поисковую выдачу до нажатия кнопки «Найти».

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

Привет, меня зовут Дмитрий, мне 35 лет. Раньше я часто слышал, что программист — профессия для молодых. Тем не менее прошлым летом я получил приглашение в Яндекс и перебрался работать в Москву.

В этой статье я хотел бы затронуть вопрос, который не раз обсуждался на Хабре: насколько реально быть программистом после 35–40 лет? Не ведущим архитектором, не тимлидом, не менеджером проекта, а именно программистом? Я не согласен с мнением, что программирование — это удел молодых. Считаю его вредным и сейчас расскажу почему.

Существует несколько доводов, на которые опирается этот миф. Давайте-ка их подробно рассмотрим.

«Восьмерка» еще даже не вышла RTM а я уже пишу про нее пост. Зачем? Ну, основная идея что тот, кто предупрежден — вооружен. Так что в этом посте будет про то что известно на текущий момент, а если это все подстава, ну, поделом.

• его можно отследить по IMEI, а смена IMEI явно не бесплатна;
• на телефоне могут быть установлены блокировки, снять которые так же не бесплатно;
• есть приложения с режимом «Антивор», которые передают фото, видео и аудио;
• даже встроенные возможности Android (и, полагаю, iOS) имеют функцию геолокации пропавшего устройства;
• устройство может иметь особые приметы, которые довольно сложно устранить «бесплатно»;
• наверняка где-то рядом есть камеры видеонаблюдения, свидетели и т.п.;
• при продаже краденного за него сложно будет выручить большую сумму денег.

• Убивают носителя быстрее, чем будет выработан иммунный ответ.
• Меняются быстрее, чем иммунная система сможет «распознать» патогены.
• Маскируются и прячутся в местах, где очень сложно получить доступ к патогену.

Почему путешествия опасны?

Истории успеха любят все. И на хабре их достаточно много.

«Как я получил работу с зарплатой 300 000 долларов в Кремниевой долине»
«Как я получил работу в Google»
«Как я заработал 200 000 $ в 16 лет»
«Как я попал в Топ AppStore с простым приложением курса валют»
«Как я …» и еще тысяча и одна подобная история.

Это же здорово, что человек добился успеха и решил об этом рассказать! Читаешь и радуешься за него. Но большинство таких историй объединяет одно: ты не можешь повторить путь автора! Либо ты живешь не в то время, либо не в том месте, либо ты родился мальчиком, либо…

Я думаю, что истории неуспеха в этом плане часто бывают полезней. Тебе просто не нужно делать то, что сделал автор. А это, согласитесь, гораздо проще, чем пытаться повторить чей-то опыт. Просто такими историями люди обычно не хотят делиться. А я расскажу.

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

Меня зовут Денис Исаев, и я руковожу одной из бэкенд групп в Яндекс.Такси. Сегодня я поделюсь с читателями Хабра описанием проблем, которые могут возникнуть, если не учитывать идемпотентность распределенных систем в своем проекте. Для этого я выбрал формат вымышленных историй о стажёре Васе, который только-только учится работать с API. Так будет нагляднее и полезнее. Поехали.

В команде эксплуатации подумали, что наш опыт с Microsoft SQL в нагруженной среде больше нельзя скрывать, и потому родилась эта статья. В ней я расскажу о нюансах работы с этой СУБД из практики.

Microsoft SQL Server давно нашел свое место в семействе продуктов Яндекс.Денег и успешно решает задачу сбора разрозненной информации обо всех операциях из множества отдельных сервисов. Без такой сборки воедино нельзя было бы отследить платеж, собрать статистику или решить проблему.

Все сказанное далее будет полезно администраторам крупных БД – тем, кто заботится о быстрой и точной работе аналитики Microsoft SQL Server 2012-2014.

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

WITH RECURSIVE numbers AS (SELECT 0 AS n UNION ALL SELECT n+1 FROM numbers WHERE n<89),
pixels AS (SELECT rows.n as row, cols.n as col FROM numbers as rows CROSS JOIN
numbers as cols WHERE rows.n > 4 AND rows.n < 38 AND cols.n > 9 AND cols.n < 89),
rawRays AS (SELECT row, col, -0.9049 + col * 0.0065 + row * 0.0057 as x,
-0.1487 + row * -0.0171 as y, 0.6713 + col * 0.0045 + row * -0.0081 as z FROM pixels),
norms AS (SELECT row, col, x, y, z, (1 + x * x + y * y + z * z) / 2 as n FROM rawRays),
rays AS (SELECT row, col, x / n AS x, y / n AS y, z / n AS z FROM norms),
iters AS (SELECT row, col, 0 as it, 0 as v FROM rays UNION ALL
SELECT rays.row, rays.col, it + 1 AS it, v + MAX(ABS(0.7+v*x) - 0.3,
ABS(0.7+v*y) - 0.3, ABS(-1.1+v*z) - 0.3, -((0.7+v*x) * (0.7+v*x) +
(0.7+v*y) * (0.7+v*y) + (-1.1+v*z) * (-1.1+v*z)) * 1.78 + 0.28) AS v
FROM iters JOIN rays ON rays.row = iters.row AND rays.col = iters.col WHERE it < 15),
lastIters AS (SELECT it0.row, it0.col, it0.v AS v0, it1.v AS v1, it2.v AS v2
FROM iters as it0 JOIN iters AS it1 ON it0.col = it1.col AND it0.row = it1.row
JOIN iters AS it2 ON it0.col = it2.col AND it0.row = it2.row
WHERE it0.it = 15 AND it1.it = 14 AND it2.it = 13),
res AS (SELECT col, (v0 - v1) / (v1 - v2) as v FROM lastIters)
SELECT group_concat(
substr('$@B%8&WM#*oahkbdpqwmZO0QLCJUYXzcvunxrjft/|()1{}[]?-_+~<>i!lI;:,"^. ',
round(1 + max(0, min(66, v * 67))), 1) || CASE WHEN col=88 THEN X'0A' ELSE '' END, '')
FROM res;