Category: it

Category was added automatically. Read all entries about "it".

glider

29 октября в 12:00 в Минске расскажу про макросы в Скале

Эту неделю я буду в Минске, поэтому предложил ребятам из коммьюнити scala.by выступить с презентацией про макросы и обсудить потенциально интересные применения макросов на практике.

Спасибо большое Васе Ременюку - он оперативно организовал нашу встречу в эту субботу 29 октября в 12:00 на Купревича 1/1. Регистрация на ивент находится вот тут: http://scala.by/news/2011/10/24/meetup-6.html. Также, по поводу оргвопросов можно отписаться в гугл групсы: http://groups.google.com/group/scala-enthusiasts-belarus/browse_thread/thread/88e476cf1e52a9ff.

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

Пожалуйста, заходите к нам на огонек, ибо мне крайне важно узнать ваше мнение. Для чего в ваших проектах могут быть применены макросы? Есть ли такие задачи, для которых вы плачете, колетесь, но пишете бойлерплейт? Сейчас я всего лишь пишу спеку, поэтому оригинальную идею можно легко подпилить в ту или иную сторону. Не стесняйтесь - и макросы в Скале будут полезны лично для вас и ваших юз-кейсов.

upd. Большое спасибо всем, кто был сегодня на встрече! Ребята, это большая честь рассказать о том, что я делаю, такой заинтересованной аудитории. Также крайне порадовало то, что было столько вопросов буквально с первой минуты презентации. По факту мы обсудили раза в три больше вопросов, чем я заранее планировал =) Слайды лежат на гитхабе: https://raw.github.com/xeno-by/kepler/master/papers/2011-10-29-RuProjectKepler.pdf. Скринкаст будет выложен на днях, об этом я отпишусь отдельно.
glider

github: как в форкнутом репозитории смержиться с апстримом

Я подозревал, что такое возможно, а сегодня, как понадобилось - научился:
* http://help.github.com/fork-a-repo/
* http://stackoverflow.com/questions/849308/pull-push-from-multiple-remote-locations

Заодно догнал, зачем нужно магическое заклинание "git remote add origin git://github.com/username/newproject" для того, чтобы инициализировать только что созданный проект на гитхабе. В принципе, логично, хотя в меркуриале было совсем по-другому.
glider

емакс, часть 3: windows

емакс, часть 1: первый взгляд
емакс, часть 2: восторг
емакс, часть 3: windows
емакс, часть 4: ретроспектива

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

Сразу после запуска емакс встретил меня сообщением об ошибке в скриптах инициализации и антиалиаснутым курьером. "Окей, в принципе никто и не предполагал, что сразу все заработает" - подумал я и нажал Alt+F4, чтобы перезапустить емакс в режиме отладки. В ответ последовало: "<M-f4> is undefined", что в переводе на русский обозначает, что Alt+F4 по умолчанию ни на что не забинджен. Да, поездочка будет долгой...

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

upd. Также я столкнулся с проблемой тормозов. Часть из них была вызвана гитом (см. ниже по тексту), часть из них имела другие причины. Хорошая новость в том, что все удалось починить. Детали см. вот тут: http://xeno-by.livejournal.com/57626.html.

***

Первым делом я обдумал вопрос программного окружения. Так как емакс неслабо использует возможности стандартных юниксовых тулов (например, поиск по пачке файлов (читай, проекту) проще всего реализовать через find+grep), нужно было где-то достать эти самые тулы. Можно было просто вытащить греп и файнд из mingw, но отказываться от шелла тоже не хотелось, ибо писать дакт-тейп на елиспе - удовольствие ниже среднего. В итоге, остались два варианта: 1) запускать емакс из-под цигвина или чего-то подобного (к сожалению, я плохо разбираюсь в теме эмуляции юникса под виндой, поэтому не в курсе, как еще можно поступить в рамках этой опции), 2) юзать NT Emacs (т.е. емакс, скомпилированный в виде нативного виндового приложения), но при этом использовать bash и gnu utils от цигвина.

После чтения емакс-вики и статейки Стива Йегги я решил остановиться на второй возможности. Кроме общефилософского мнения о том, что предпочтительнее юзать нативную прилагу, немаловажным был тот фактор, что цигвин я видел первый раз в жизни, поэтому непонятно, какие косяки меня могли ожидать. В любом случае, и баш, и корные юниксовые утилиты доступны в обоих случаях, поэтому, выбрав NT Emacs, концептуально я ничего не терял. В итоге я поставил цигвин, добавил его bin в виндовый PATH, установил переменную окружения SHELL в c:\cygwin\bin\bash.exe (это все, что нужно для того, чтобы емакс проинтегрировался с цигвиновскими coreutils) и смело пошел навстречу граблям.

Самым первым делом я пофиксил шрифты. Если к сглаживанию как таковому я со временем привык, то сглаженный курьер меня продолжает удивлять и по сей день. Впрочем, оказалось, что установкой одной-единственной переменной можно сразу изменить шрифт для всего окна емакса. Для полноты картины отмечу два нюанса: 1) формат значений этой переменной нетривиален, 2) переменная локальна для фрейма, т.е. для новых окон нужно ее устанавливать заново. За деталями смотрим сюда.

Следующей на очереди была унификация формата сохраненной сессии емакса между виндой и линуксом. Винда успешно поддерживает симлинки, но никакими симлинками не превратить путь типа X:\ в путь типа /foo/bar. И это даже несмотря на то, что емакс прекрасно переваривает прямые слеши вместо обратных и наоборот. Проблема решилась при помощи цигвина. В папке c:\cygwin я воспроизвел структуру рабочего окружения линукса и забросил оттуда симлинки на папки с реальным контентом. А дальше всего лишь осталось заюзать библиотеку cygwin-mount, которая умеет маппить виртуальные юниксовые пути на реальные виндовые пути внутри папки цигвина.

Пришлось также неслабо поисследовать вопрос с хоткеями. В линуксе проблема гвоздями прибитых хоткеев отсутствует - и в метасити, и в компизе можно перебиндить что угодно, включая вещи вроде alt+tab. В винде все несколько грустнее. Во-первых, из коробки емакс не обрабатывал кнопки Win, отдавая их системе. Если в убунте я мог изображать любые сочетания клавиш с участием Win, то в винде эти штучки уже не работали. К счастью, нашлось простое решение. Для того, чтобы Win превратить в super (или во любой другой модификатор), нужно всего лишь установить парочку переменных.

Дальше - интереснее. Если проблемы с win+tab и win+цифры я ожидал, то увидеть занятыми ctrl+esc и даже win+= было удивительно. Вначале я пытался разрулить проблему, копаясь в реестре, но это были просто припарки - там заработало, тут отвалилось. Ситуацию переломил бесплатный тул AutoHotkey. С помощью несложного вида скриптов он позволяет перекрыть и обработать большой спектр хоткеев (я подозреваю, что все, что угодно, кроме ctrl+alt+del), а также даже скомпилировать свои скрипты в standalone икзешники. Кроме того, я перемаппил Caps Lock на Ctrl - это делается регедитом, без всяких тулов.

Конечно, мои изыскания не могли пройти мимо проблемы с разделителями строк. Вначале я подумал, что эту проблему удастся избежать, т.к. емакс достаточно смартовый редактор для того, чтобы автоматически понимать, где \n, а где \r\n. Но после того, как скрипт, отредактированный под виндой, отвалился в линуксе по причине лишнего символа \r, мне стало не до шуток. Была введена политика огораживания, по которой все новосозданные файлы, несмотря на текущую операционку, кодируются с разделителями в стиле юникса. Исключение - бат-файлы, которые без \r\n виндовый интерпретатор не съест. Интуитивно чувствую, что это решение слишком жестко, чтобы быть практичным, но будущее покажет.

Кстати, по концовке оказалось, что проблема была не в емаксе. Символы окончания строки испортил кое-кто другой. Некоторые из вас, вероятно, уже догадались. В честь этого все вместе передадим привет гиту и его core.autocrlf. Впрочем, тема гита на винде выходит за пределы и так уже большого поста.

Последняя грабля была связана снова с гитом. В интернетах много кто жалуется на неторопливость его виндового порта. Как я понял, это связано с тем, что гит юзает идиомы линукса, которые невозможно эффективно замаппить на виндовый апи, в честь чего и тормоза. На горьком опыте я выяснил, для дефолтного сетапа msysgit 1.7.2 операции вида git XXX выполняются минимум 0.3 секунды каждая (ssd, core i7, loads of ram). Все бы ничего, но при открытии каждого файла емаксовая инфраструктура сорс-контроля выполняет более 10 таких операций. Путем красноглазия удалось сократить время до 0.1 секунды на операцию, но это все равно баттхёрт! Пришлось отрубать, но, на счастье, получилось чисто - отключился только хук, но не остальной функционал вроде диффов.

***

tl;dr. Поставлено тулов: 1) Cygwin, 2) NT Emacs. Пришлось подпилить: 1) фонты, 2) имена файлов в сессиях, 3) системные хоткеи винды, 4) политику разделителей строк, 5) интеграцию с гитом. В результате под виндой: 1) gnu тулы из емакса работают, 2) шелл-скрипты из емакса (например, grep+find по проекту) работают, 3) сессии емакса, сохраненные в одной операционке, открываются в другой, 4) функциональность и хоткеи емакса в пределах моего воркфлова одинаковы - и в линухе, и в винде.
glider

емакс, часть 1: первый взгляд

емакс, часть 1: первый взгляд
емакс, часть 2: восторг
емакс, часть 3: windows
емакс, часть 4: ретроспектива

Наконец, переборол свой страх перед емаксом и заставил себя слезть с gedit. За сегодня узнал много чего нового - ecb, dired, tabbar, ну и так, по мелочи настроил .emacs.d. Попутно сгенерилась куча вопросов, вот несколько из них.

1. В чем тайный смысл длинных хоткеев для частых действий? Вот, например, C-x C-_ для redo: требует нажатия пяти клавиш для выполнения весьма распространенной процедуры. Это ведь банально неудобно! Наверное, я что-то упускаю, но что? upd. Просто замаппил redo на C-y при помощи UndoTree. Надеюсь, тайный смысл многокнопочных шорткатов пойму позже.

2. С созданием хоткеев я в целом разобрался, но остался нерешенный момент. Как забиндить C-1? Когда я в init.el пишу (global-set-key (kbd "C-1") 'blah-blah), то хоткей тупо не применяется. Если в этой же строчке заменить С-1, например, на C-=, то все ок. upd. Выяснилось, что C-цифры замаплены на некий digit-argument, но я без понятия что это, поэтому просто заюзал другую комбинацию клавиш.

3. Что по концовке будет удобнее: CUA или стандартный подход емакса к копипасту? upd. Врубил CUA, ибо решил вначале добиться минимально необходимого/привычного набора фич, а потом уже играться с емаксом по ходу работы.

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

5. Как можно удобно сделать инкрементальный поиск по всем файлам проекта? Я нагуглил вариант с запуском диреда с флажком -R и инкрементальным поиском по окошку диреда. Есть ли альтернативные опции с автокомплитом, например, в минибуфере? Как я понял, и ido, и icicles поддерживают только поиск файла в текущей папке. Какие есть еще варианты? (задал вопрос на stackoverflow)

6. Под виндой я привык, что tortoise* регистрирует кастомные оверлеи на иконках файлов, лежащих под сорс-контролем. Файл не менялся после последнего коммита - зелененький, менялся - красненький, ну и в таком духе. Особенная прелесть такого подхода заключается в том, что иконки рекурсивно применяются к папкам, т.о. можно быстро увидеть что закоммитал, а что забыл. Есть ли что-то похожее в емаксе? Я видел, что ECB рисует иконки файлов с учетом их статуса в VCS. Но умеет ли он отображать статус папок? upd. Забил - вообще отключил иконки ECB. Во-первых, они часто глючат, а, во-вторых, магита хватает за глаза - одной кнопкой можно посмотреть статус репозитория, что, в общем-то, и нужно было от иконок.

7. Про какие мастхэв модули я должен знать? Я нашел интересный пост на SO: The single most useful emacs feature - но там больше про мелочи.
glider

Подборка статей и книжек по программированию

На дропбоксе расшарил и проиндексировал библиотечку по программированию (клик). Там есть по разным аспектам функционального программирования, метапрограммирования, теории типов и еще много всякого разного, например, набор статеек и слайдов для подготовки к собеседованию по алгоритмам.

Некоторые креативы в подборке меня впечатлили до состояния просветления по определенным вопросам. Из самых любимых хочу отметить "Оптимизирующие парсер-комбинаторы", "Delimited Continuations" и "Type Classes as Objects and Implicits". Ну и, конечно, как же я мог забыть про "Lightweight Modular Staging: A Pragmatic Approach to Runtime Code Generation and Compiled DSLs"!

Давайте делиться!

upd. К сожалению, анонимусам дропбокс позволяет скачивать только файлы, но не папки целиком. Чтобы обойти проблему, я запаковал снапшоты технических разделов библиотеки и положил их в корень публичной папки Library (см. http://dl.dropbox.com/u/10497693/Library/index.html). Постараюсь регулярно обновлять архивы с учетом новых поступлений.
glider

убунта, часть 4: интероп с виндой

часть 1: первый взгляд
часть 2: установка
часть 3: софт
часть 4: интероп с виндой
часть 5: обратно на винду

Главным вопросом для меня в плане интеропа была организация партишена, общего и для убунты, и для винды. Есть три вида файловых систем, которые хорошо поддерживаются на обеих платформах: FAT, NTFS и ext. Первый вариант отпадает сразу ибо он не журналируется, остаются два.

Вначале я решил использовать NTFS, тем более, что существующие данные уже лежали на виндовом партишене. Немного погуглил и выяснил, что драйвер ntfs-3g под убунту считается довольно стабильным. В файловом менеджере убунты мой NTFS-диск подмаунтился без всяких проблем, поэтому я решил не париться и оставить все как есть. В процессе тестовой эксплуатации выяснилось следующее:
1) Скорость работы с NTFS через убунту примерно в полтора раза хуже скорости через винду.
2) Если с помощью виндового партишен-менеджера делать динамические NTFS-партишены, то есть неплохой шанс, что ntfs-3g откажется их хавать. Возможно, у этой проблемы есть цивилизованные решения, но мне пришлось форматировать диск.

Так как для используемого каждый день хранилища данных эти проблемы уж слишком жестокие, было принято решение мигрировать на ext. На текущий момент есть два драйвера, которые дружат винду с ext: ext2fsd и ext2ifs. Первый достаточно оживленно разрабатывается (последний релиз был в феврале этого года), поэтому сразу поставил я именно его. Однако в процессе использования проявились неприятные моменты. Во-первых, параметры маунтинга ext-разделов не сохраняются между ребутами (автор так и написал в релиз нотах: "это не баг, просто не было времени прикрутить"). Во-вторых, дефолтный режим маунтинга - только на чтение, поэтому после каждой перезагрузки приходилось переподключать диск, что неприятно. В-третьих, даже в режиме r/w я ловил глюки с записью: например, в папках, созданных под убунтой я мог создавать новые файлы, но не мог редактировать старые.

В итоге, пришлось остановиться на ext2ifs. Почему пришлось? Да потому, что последний релиз этой софтины случился почти 3 года назад, и, кроме того, она не поддерживает ext4. Также выяснилось, что софтина не поддерживает размеры inode, большие, чем 128 байт. Юмор ситуации заключается в том, что по умолчанию убунта форматирует ext с ключом -I 256, а поменять размер айнода можно, только пересоздав файловую систему. Ладно, ок - заново забэкапил данные и отформатировал партишен под ext3 -I 128. После этого меня ждал последний бастион: ext2ifs не умеет автомаунтить диск при загрузке системы (или умеет, но эта фича не работает в семерке). Впрочем, это починилось через написание автозагрузочного bat-файлика, который юзает mountvol. Дальше все заработало как часы.

Пару слов про симлинки. ntfs-3g умеет читать симлинки NTFS, но зато не умеет их создавать. Вернее, умеет, но создает их в линуксовом формате, который не распознается виндой. Кроме того, симлинки между NTFS-партишенами у меня не заработали (ессно, я пытался их заюзать, когда оба партишена были подмаунчены). У ext2ifs та же проблема. Читать он умеет, а создавать нет - когда я попробовал заюзать виндовый mklink, он мне написал, что сабжевая файловая система не поддерживает симлинки. Впрочем, симлинки с ext на NTFS, равно как и симлинки с NTFS на ext - работают на ура.

Чтобы два раза не вставать, упомяну еще и самбу. Без проблем получилось расшарить папку из-под убунты и заюзать ее из винды, а также наоборот. Впрочем, и здесь случилась одна загадочная ситуация, причем я пока что не смог ее разрулить. Дано: на десктопе убунта, на ноуте убунта. Если копировать файлы на ноут, то скорость 9-10 MB/s. Если копировать в обратном направлении, то всего лишь 4 MB/s. Вначале я думал, что это из-за того, что ноут пускает данные по wi-fi, но, даже после отключения wi-fi, остались все те же четыре метра в секунду. Загадки во тьме.

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

онсайт собеседование с гуглом, часть третья, последняя

Первая часть
Вторая часть

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

В целом, вопросы можно разделить на две категории: 1) алгоритмические задачки с двойным дном, 2) открытые проблемы дизайна некоей нагруженной системы.

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

Вопросы из второй категории были связаны с тем, как построить ту или иную распределенную систему, которая работает с большими объемами данных и/или обрабатывает много запросов. Поговорили про партишенинг, про оптимизацию объемов трафика, про то, как переходить от обычных структур данных и алгоритмов к распределенным, немного затронули map/reduce. Важной темой также были вопросы в стиле "оцените какой объем будет занимать база данных через 10 лет".

В свете вышесказанного лучший вариант подготовки - неделю вспомнить базовые алгоритмы и неделю-две порешать TopCoder (еще пару мыслей о подготовке я написал в каментах к соседнему посту). На мой взгляд, важнее всего здесь не алгоритмические изыски или знание навороченных структур данных (изучение этих вопросов, конечно, поможет, ибо потренирует нужные отделы мозга, но это время можно употребить с большей пользой). Главное - натренироваться качественно рассматривать возможные варианты входных данных. В этом плане я сильно прокололся на последнем интервью - в упор не увидел два вырожденных случая, в результате чего алгоритм получился неправильным. Также желательно иметь представление о базовых принципах построения распределенных систем. С этими вещами я на практике вообще не сталкивался, но когда-то читал про map/reduce + послушал доклад Олега и Кирилла и этого уже хватило на увлекательную беседу. Впрочем, может, увлекательной она было только для меня, не знаю.

На закуску несколько наблюдений о интервьюерах.
1. Начинаешь что-то писать сразу после выслушивания условия, интервьюер сразу делает пометку. Такое случилось не один раз, поэтому, мне кажется, это неслучайно. Не потому ли, что типа недостаточно подумал?
2. Также несколько раз слышал: "как бы вы писали юнит-тест для данного алгоритма". Насколько я вспоминаю, во всех этих случаях у меня в алгоритме были неточности, поэтому логично предположить, что эта фраза является эвфемизмом для "у вас косяк".
3. Часто случалось так, что после буквально 30-40 секунд обдумывания (вслух или про себя - неважно) мне сразу давали хинт. Интересно, что бы это значило - может, просто интервьюерам хотелось побыстрее перейти к интересной части задачки.
4. В митинг-руме был круглый стол и стулья. Все интервьюеры, кроме последнего, садились не напротив меня, а под углом около 90 градусов от моей позиции. Удивительно, но это сработало и, действительно, делало беседу более приятной. Это было хорошо заметно на контрасте с нашим общением с последним интервьюером.

На этом у меня все. Спасибо за внима.. О! Почти забыл важную вещь. Везде в интернете пишут про кодирование на вайтборде, но на практике все оказалось по-другому. Все пять собеседований я писал код на бумажке =)
glider

онсайт собеседование с гуглом, часть вторая

Первая часть

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

1. За обедом у нас зашла речь об энвайронменте разработки. Поддерживая разговор о средах разработки, моя компаньонка сказала, что вообще не использует IDE. К этому я был готов и с надеждой спросил: "Неужели Emacs?". После недавного опыта с емаксом у меня есть желание разобраться, но я не знаю с чего начать, поэтому особенно ценной была бы возможность пообщаться с живым адептом этого таинственного тула.

Здесь меня постигло разочарование и удивление одновременно - моя собеседница сказала, что использует всего лишь какую-то несложную тулу для редактирования текста (нет, не vi), а больше ей ничего и не надо. Поиск и навигация по коду в ее воркфлове отделены от редактирования и осуществляются в некоем веб-туле аля Google Code Search. Здесь у меня три вопроса:
* Насколько близки возможности этого тула к публичному code search? Вот, я открыл случайный C#-проект в code search. Панелька навигации отображает структуру проекта и даже выделяет семантические элементы внутри файла. Это хорошо, но где гиперлинки в стиле "go to definition"?
* Можно ли поставить этот или аналогичный тул локально и индексировать свои личные проекты?
* Народ, ну как вы обходитесь без интегрированных в редактор кода рефакторингов?!

2. Я не смог удержаться и спросил одного из интервьюеров, а также и девушку за обедом про то, как народ использует 20% времени, которые политикой гугла отводятся на личные проекты. По рассказам (которые также коррелируют и с тем, что мне рассказала Дженни) получается, что можно замутить что-нибудь интересное, представить это что-то широкое публике и при успехе презентации ожидать приток свежих сил на мини-проектик. При особой пользе личного проекта для Мирового Разума, может предоставиться возможность заниматься им фулл-тайм (здесь мне рассказали историю некоего Кости, который сгенерил тул, умеющий в полуавтоматическом режиме искать data races; сейчас, при написании поста я нагуглил немного больше деталей). Звучит отлично, поэтому очень интересно было бы узнать детали.

3. Стала неожиданностью позиция народа относительно альтернативных языков программирования. Как я понял, в гугле есть четыре языка, на которых пишут большинство кода в продакшен - Java, C++, Python и Go. Мои вчерашние собеседники пишут исключительно на Java/C++ и иногда мелкие скрипты на питоне. Go считается мистической экзотикой, которую никто из них не пробовал, но, по слухам, это что-то классное. На провокационные вопросы типа: "а никогда не хотелось заюзать какой-нибудь другой ЯП?" или "согласись, приятно покодить в функциональном стиле?" никто не поддался. А самый первый мой интервьюер даже не слышал, что такое Scala. Отражает ли эта выборка мнений общую картину?

На пока что все. В следующем посте я попробую описать тематику вопросов (вчера было пять собеседований, по 1-3 задачки в каждом) и выскажу соображения по поводу подготовки на основе полученного опыта. К сожалению, тексты задачек я привести не смогу (NDA я не подписывал, но явно высказанной просьбе отказывать не хочу), но, надеюсь, будет интересно.
glider

Телефонное собеседование с гуглом

Примерно в феврале я написал аппликейшн в гугл, после чего через пару недель со мной связалась девочка-рекрутерша по имени Дженни. Сказала, что меня также рекомендует мой бывший одноклассник, который сейчас работает в гугле, поэтому все круто, и предложила поболтать с ней по организационным вопросам. Договорились на через пару дней, но она заболела, а потом просто забыла про запланированный чат =))

В итоге поболтали в начале марта. она немножко повпаривала про то, что такое гугл и про то, что подготовить к собеседованию (по большей части это был рестейт известного блогпоста: http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html), после чего по добазарились о телефонном интервью.

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

***

Чел позвонил минута в минуту, в 12:00. Минут 10-15 мы болтали о моем прошлом экспириенсе (это, кстати, большая проблема - связно и кратко рассказать о том, чем ты занимался. если бы я заранее не готовился и не получил неприятный опыт на одном из недавних интервью, то точно бы залажал), потом началось самое интересное - задачки на алгоритмы.

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

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

Третья задача была про деревья. Необходимо было придумать модификацию обычного бинарного дерева, которая бы могла выполнять некоторые операции очень быстро. В нашем университетском курсе про такое не рассказывали, но тут помогла одна статейка с хабра. Хорошо, что я подготовился к собеседованию - сам бы я фиг додумался, если бы не знал, от чего отталкиваться.

Четвертая задача заключалась в кодировании одной из операций из третьей задачи. Делать это надо было в режиме реального времени в google docs. Началось все хорошо - я набросал структуру данных, проверил в алгоритме краевые условия, упомянул про defensive программирование, различные стратегии работы с ошибками и все дела. И потом неправильно написал алгоритм. Нет, главную идею я выразил правильно, но ошибся в мелочи, причем смог найти ошибку только с третьего раза. Хорошо, что все-таки пофиксил баг, зато потом додумался, как упростить алгоритм, уменьшив количество строчек раза в 1.5-2. Надеюсь, хоть это произвело положительное впечатление.

На этом оказалось, что мы разговариваем уже больше 55 минут, поэтому чел стал закругляться (по регламенту полагается около 45 минут на собеседование). Последовало классическое DYHAQFM, на что я классически ответил, что вопросов нет, но зато собеседование было очень интересным. На этом и разошлись.

***

Выводы:

1) Все было совсем просто, только надо было подготовиться. Так как во время двух недель подготовки я неслабо времени посвятил сортировкам и деревьям, мне было относительно просто. Впрочем, по факту я подготовил и кучу ненужных вещей, например, изучал новинки C# (додумался же сказать Дженни, что я эксперт сишарпа =)), неслабо проштудировал графы и строки (было риальне интересно!), разбирался с map/reduce, вдавался в детали работы континюэйшнов, читал про техники сборки мусора и JIT-компиляции. Наверное, для телефонного интервью это был оверкилл, но зато я поимел кучу фана. Надеюсь, меня пригласят на on-site интервью, где я смогу про все это поговорить. upd. Пригласили, не поговорили (детали ниже).

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

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

upd. Так получилось, что, несмотря на фейл с кодированием задачки, я прошел телефонное интервью, и Дженни прислала приглашение поучаствовать в onsite интервью. На эту тему есть пост в трех частях: первая, вторая и третья.
glider

Conflux: GPGPU для .NET

К моему дню рождения в августе (серьезно, прямо в ночь перед ДР =)) случилось радостное событие - наконец-то удалось допилить Конфлакс до относительно рабочего состояния. А на недавней конференции Application Developer Days 2010 мне представился шанс выступить с докладом. Конечно же, я рассказывал про Конфлакс. В честь этого радостного события приглашаю вас ознакомиться со слайдами или даже посмотреть видео. Если вы никогда не слышали про CUDA, то перед этим лучше прочитать прекрасную презентацию Саймона Грина (для начального знакомства хватит первых 14 слайдов).

Тамбнейл доклада
Просто и ёмко Конфлакс описал antilamer: "в дотнетовской программе (на шарпе, например) можно написать метод, который будет выполняться на CUDA - он в рантайме декомпилируется и перекомпилируется в CUDA PTX". Если вас это описание заинтриговало, то вот как все это можно увидеть своими глазами:
  1) Скачать демку умножения матриц на Конфлаксе.
  2) Пока демка качается, можно посмотреть краткое описание.
  3) Демка состоит из двух частей - для CPU и для GPU. Для запуска демонстрации на CPU не нужно ничего, кроме четвертого дотнета. Для запуска демонстрации на GPU нужны CUDA-видеокарта и CUDA-драйвер.
  4) Обратите внимание на артефакты, которые создает демка. Во-первых, это логи, которые выводятся на консоль. Во-вторых, это динамически генерируемый код (ассемблер NVIDIA пишется в трейс, сгенерированный IL после завершения программы сбрасывается на диск - его можно посмотреть рефлектором). В-третьих, это CFG (графы потока управления) дизассемблированных методов, использованных в кернеле.
  5) Можно скачать исходники Конфлакса и посмотреть, как все работает. Для того, чтобы открыть проект, нужна Visual Studio 2010.

В заключение несколько слов саммари. Конфлакс позволяет программисту в 100% managed коде описать параллельный алгоритм, который потом будет исполняться на GPU. Написанный алгоритм можно прозрачно дебагать, используя стандартные средства Visual Studio, одной строчкой переключившись на CPU бакэнд. Наконец, несмотря на происходящую под капотом магию, Конфлакс не является дополнительным уровнем абстракции, которая может неожиданно протечь - он всего лишь один-к-одному преобразует код на дотнете в код для GPU, в нем можно даже писать ассемблерные вставки и вызывать third-party библиотеки CUDA (например, CUBLAS или CUFFT). Все это является шагом вперед в мире GPGPU для дотнета.