За последние восемь месяцев я прошел собеседования в самых разных компаниях — DeepMind в Google, Wadhwani Institute of AI, Microsoft, Ola, Fractal Analytics и некоторых других — в основном на позиции Data Scientist, Software Engineer и Research Engineer. По ходу дела мне предоставлялись возможности не только пообщаться со многими талантливыми людьми, но также по-новому взглянуть на себя с пониманием того, что хотят услышать работодатели, когда беседуют с кандидатами. Думаю, если бы я располагал этой информацией раньше, то мог бы избежать многих ошибок и подготовиться к собеседованиям куда лучше. Это и стало импульсом к написанию данной статьи — возможно, она поможет кому-нибудь получить работу мечты.


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

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

— Саш, очевидно, работа не приносит тебе удовольствия, — Слава проговаривал бесспорные вещи. Четвертую неделю вместо работы я мчался на очередной детский турнир по футболу. Когда у тебя трое детей, можно 120% своего времени занять их увлечениями. — У меня есть к тебе предложение. Давай отправим тебя в отпуск на год? Я за это время закрою собой бизнес. Доходы, по-прежнему, пополам. Потом ты вернешься с новыми силами, и, может быть, я на год в отпуск схожу.

Честно говоря, я недолго думал над этим предложением. От работы реально подташнивало, и перспектива на год избавиться от этого источника тошноты манила как никогда раньше. Мы ударили по рукам.

Я думаю, что многие из вас хотя бы раз встречали в ленте Хабра одну из моих подборок «Интересностей и полезностей для веб-разработчика». Первый выпуск 15 августа 2013 года появился на фоне банальной идеи поделиться ценными инструментами, которые я уже использую или сохранил в закладках на будущее. Изначально даже не предполагалось, что мое публичное коллекционирование станет серийным, но с тех пор я опубликовал 41 дайджест.

Конечно, со временем появились обязанности перед аудиторией, сроки публикации и само написание стало требовать больше времени. Значительно вырос список для мониторинга интересностей и полезностей. Сейчас это несколько тематических сабретитов, GitHub трендинг, HackerNews, ProductHunt и десятки аккаунтов в твиттер Smashing Magazine, CSS Tricks, Codrops, David Walsh Blog, Alist Apart, Poul Irish, Tuts+, SitePoint и тд. Хочу на этом месте выразить благодарность Александру Маслову drakmail, который практически полностью предоставляет информацию для Ruby и Go рубрик, а также помогает с другими.

Животные – это платформы с очень ограниченной памятью, вычислительными способностями и возможностями модификаций. Разработчикам энимал-сцены приходится выдавать практически гениальные низкоуровневые алгоритмы. Правда, большое количество хардкода вызывает характерные проблемы с отсутствием проверки в экзотических условиях. Та же фильтрация входных данных делается очень и очень криво.


Уязвимость рекурсивных алгоритмов навигации муравья: спираль смерти

Не знаю, кто писал большую часть птиц, но я хочу обратить внимание на особенность, позволяющую провести инъекцию произвольного яйца в гнездо. Дело в том, что птица проверяет только расположение и количество яиц, но не их хэши. В 20% случаев кукушка, эксплуатирующая этот баг, может внести яйцо с сохранением контрольной суммы, чего вполне достаточно для повышения прав в гнезде.

Но пойдём далее. Я не знаю, кто разрабатывал архитектуру ящериц, но они бегают в одном процессе, а дышат в другом. При этом платформа не поддерживает многозадачность, поэтому костыль с максимальной длиной бега в 4-6 секунд просто эпичен.

Пришло время собрать в одном месте все-все-все мифы и разоблачения одного из самых противоречивых с точки зрения читателей камерофонов — Lumia 1020. (Внимание, много фото, красивых фото)

А также гвоздь программы, впервые на хабре, у всех на глазах: работа с RAW-исходниками, полученными с 1020, и их обработка.

Садитесь поудобнее, мы начинаем ;)
Какие вопросы чаще всего приходят в голову, когда читатель слышит выражение: «Камерофон Lumia 1020 с камерой в 41 мегапиксель»?

1. 41 мегапиксель, как он там умещается?
2. Соответствует ли остальное железо заявленному уровню фотомодуля?
3. И всё же, там правда столько мегапикселей?
4. Да даже если столько, какая от них польза? Зачем так много?
5. Предположим, что в этом есть смысл, но RAW в смартфоне — это же перебор, толку от него с такой матрицы?!!
6. Всё равно зеркалка лучше!

P.S. Да, у автора всё так же остался приступ «Люди любят обиженных» и он всё ещё отчаянно пытается восстановить честь финских инженеров, чьи достижения, по мнению автора, были незаслуженно проигнорированы в свете последних событий.


Пойдём по порядку.

1. 41 мегапиксель, как он там умещается?

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

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

Бытует мнение, что на электронных книгах с e-ink дисплеями, можно комфортно читать только текстовые книжки, где можно выставить большой шрифт, а вот pdf и тем более сканы в djvu читать практически невозможно, глаза сломаешь разбирать мелкие буквы на небольшом дисплее. Спешу вас разуверить, читать такие книги вполне можно комфортно.

Хотелось бы немного рассказать о тех ошибках, которые очень опасно совершать особенно сейчас, особенно в странах или городах золотого миллиарда. Думаю каждый работающий или сталкивающийся с деятельностью большой или не очень компании (или гос структуры) как и я удивляется на сколько же всё не эффективно и поражается как при таком раздолбайстве и пофигизме шестерёнок машина всё еще работает.

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

Гораздо интереснее читать реальные истории людей, которые описывают свой опыт собеседований в ту или иную известную компанию. Что спрашивали, что не спрашивали, какая была атмосфера, сколько проходило интервью? Такие данные много полезнее, чем «а зазубри еще это, авось спросят».

Итак, я хочу рассказать о том, как представители компании Zynga приезжали в Москву в поисках нужных людей. О своем опыте общения с ними, об ошибках и сделанных выводах.

Ну, и картиночка на затравку.

Жили-были в двух соседних деревушках Вилларибо и Виллабаджо две команды разработчиков. И те и другие делали ревью кода, писали тесты, приводили рефакторинг, но через год разработки в Вилларибо уже выпустили релиз и вышли в продакшн, а в Виллабаджо все еще проводят рефакторинг и чинят баги. В чем же дело?

Разработка ПО – область, подверженная рискам. В нашей сфере при наступлении одного или нескольких рисков, срок поставки рабочей версии может сдвинуться не на привычные и комфортные 10-20%, а на все 150-300%. И надо признаться, что это далеко не предел.

Мы можем либо скрестить пальцы и надеяться, что удача будет сопутствовать проекту во всем, либо признать, что по статистике большая часть проектов по разработке ПО «проваливается» и предпринять дополнительные усилия по ослаблению возможных рисков.
Моя практика показывает, что клиенты крайне неохотно работают по схеме T&M и чаще предпочитают Fixed Price. В условиях зафиксированной стоимости наступление рискового случая означает автоматическое снижение рентабельности проекта: сотрудники получают зарплату ежемесячно, а не за сданные проекты.

До Agile и XP вся ответственность за работу с рисками ложилась на менеджеров. В гибких методологиях разработчики гораздо больше вовлечены в процесс и делят ответственность с менеджерами. Однако, принципы XP и Agile – больше методологические, чем технологические. Я думаю, что с рисками эффективнее работать комплексно на всех уровнях, в том числе на самом низком уровне, т.е. во время проектирования и написания кода.

Почему об этом следует думать разработчику, если есть менеджер?

1. Не секрет, что если факап случится, менеджмент примет единственное «супер-умное» решение: «давайте поработаем сверхурочно и в выходные»
2. Премии сотрудники получают тоже обычно за в срок сданные, а не за проваленные проекты
3. Чувство сделанного дела, в конце концов. Гораздо приятнее сдать проект во время и видеть улыбку клиента, чем с опозданием в полгода отвязаться от «трудного ребенка»

С моей точки зрения спокойная рабочая обстановка вместо авралов и бонусы – неплохая мотивация, чтобы начать заботиться об этом.

Примерно неделю назад Vasyutka опубликовал пост про распознавание номеров и обещал, что мы выложим софт, который можно будет опробовать. Мы немножко схитрили, не рассказав все подробнее. Ну, а то бы никакой интриги не было! Ядро алгоритма распознавания мы сделали с полгода назад, но тот проект, для которого оно было сделано, не двинулся. Он остановился где-то на альфа-версии. Подумав, и посовещавшись с заказчиком, мы решили, что это нехорошо, когда такой алгоритм пылится на полке и не приносит пользу обществу. С другой стороны выкладывать все исходники распознающей части не хотелось. Тогда и родилась идея, о которой пойдёт речь в этой статье.

Решили мы, собственно, сделать открытый сервер, который бы распознавал номера, приходящие http-запросами. Так как вся идея некоммерческая, то сервер, конечно, слабенький, но на то, чтобы народ игрался, надеюсь, его хватит.
А вот тут крутой поворот сюжета. Пост этот не про протокол обращения к серверу. Об этом будет следующий пост. Этот пост о программе, которую мы начали делать как пример работы с сервером, но которая вылилась в интересную на наш взгляд концепцию. В статье будет рассказано про Android-приложение, которым можно сфотографировать номер автомобиля… И обругать владельца бранным словом! Ну, или посмотреть статистику того, сколько раз сего автомобилиста обругали.
Те, кому невтерпёж, смогут расковырять работу с сервером из исходников в конце статьи. Остальных подержим пару дней в напряжении, а потом выложим законченный мануал.

Рад сообщить, что вышел перевод отличнейшего учебника Дасгупты, Пападимитриу, Вазирани «Алгоритмы», над которым я работал последние несколько лет. В книге многие алгоритмы объяснены гораздо короче и проще, чем в других учебниках: с одной стороны, без излишнего формализа, с другой — без потери математической строгости. Откройте книгу на каком-нибудь известном вам алгоритме и убедитесь в этом. =)

В общем, угощайтесь: печатный вариант перевода, электронный вариант перевода (PDF), печатный вариант оригинала, электронный вариант оригинала (PDF).

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

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

Цель данной статьи, показать принцип дешифровки, зашифрованных скриптов, чтобы например расшифровать залитый злоумышленником вирус на PHP.

Тема SOLID-принципов и в целом чистоты кода не раз поднималась на Хабре и, возможно, уже порядком изъезженная. Но тем не менее, не так давно мне приходилось проходить собеседования в одну интересную IT-компанию, где меня попросили рассказать о принципах SOLID с примерами и ситуациями, когда я не соблюл эти принципы и к чему это привело. И в тот момент я понял, что на каком-то подсознательном уровне я понимаю эти принципы и даже могут назвать их все, но привести лаконичные и понятные примеры для меня стало проблемой. Поэтому я и решил для себя самого и для сообщества обобщить информацию по SOLID-принципам для ещё лучшего её понимания. Статья должна быть полезной, для людей только знакомящихся с SOLID-принципами, также, как и для людей «съевших собаку» на SOLID-принципах.

На хабре уже присутствует некоторое количество статей, посвященных процессу прототипирования в разработке программного обеспечения. Есть достаточно фундаментальные статьи с обзорами стандартов и расчетами, есть статьи про прототипирование устройств, есть цикл из двух статей про процесс выбора инструмента для прототипирования. К сожалению, процесс создания прототипов мобильных приложений освещен очень скудно – в виде единственной статьи в 2010 году, и пара слов в статье Разработка мобильных приложений: с чего начать.

Хотелось бы исправить эту ситуацию, и предложить вашему вниманию большой обзор доступных инструментов для прототипирования мобильных приложений.

Согласно статистике, 59% мобильных приложений не окупает затраты при его разработке.
Оригинальная идея и хорошая реализация — только половина пути к успеху.
Хорошее приложение, но без маркетинга, с большой вероятностью провалиться, а плохое при грамотном продвижении может окупить себя в десятки раз.

Далее разберем приемы продвижения приложения без вложения средств.

ASO оптимизация

Происходит в два шага и у каждого своя цель:
1. Непосредственно поисковая оптимизация (SEO),
2. Визуальная оптимизация.

Цель первого — повысить searching ranks. То есть сделать так, чтобы Ваше приложение могли найти как можно больше людей, используя поисковик.

Существует три основных бесплатных приема.
1) Название приложения. Очень важно выбрать правильное название. Именно от него в основном зависит, сколько людей найдут Вас, используя поиск. Старайтесь сделать так, чтобы название включало основные ключевые поисковые слова.
Пример: приложение на тему «Развлекательные игры для вечеринок» лучше назвать «Развлечения для вечеринок». Сразу 2 ключевых слова: развлечения и вечеринки. Не стоит называть, к примеру, «Развлекуха» или «Мимоза».
2) Описание. Большинство пользователей читает только первый абзац. Постарайтесь сделать его максимально информативным и привлекательным. Также используйте по максимуму ключевые слова в тексте.
Пример: приложение на тему «Кулинария». Используйте в описании примерно следующие слова: кухня, рецепты, вкусно, приготовление и тд.
3) Перевод. Прирост пользователей до 15%. Используйте основные языки (английский, немецкий, китайский и др). Постарайтесь обеспечить качественный перевод и не переводить текст в гугл переводчике, других программах.

Под андроид существует немало различных программ, реализующих тот или иной функционал по перехвату и анализу трафика.
В большинстве своем это однозадачные утилиты, выполняющие 1-2 функции (droidsheep, faceniff), хотя есть и комплексные тулкиты с большим заявленным набором функций (dsploit).

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

Книги, которые должен прочитать Java программист: от новичка до профессионала

[Примечание переводчика: термины градации «профессионализма» оставлены англоязычные в связи с трудностью их адекватного перевода на русский и несовпадением с привычными Junior-Middle-Senior-Lead. Перевод достаточно вольный — если знаний языка хватает, то лучше читать оригинал, как и советует автор. Оба языка для меня не родные, так что про ошибки сообщайте в личку — исправим. Здесь и далее в квадратных скобках примечания переводчика]

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