*** ВНИМАНИЕ: Блог переехал на другой адрес - demin.ws ***

вторник, 28 декабря 2010 г.

Коллекции электронных книг

Решил собрать в одном месте ссылки на ресурсы с электронными книгами (в одном из недавних постов в коментах была отличная подборка).

Буду признателем за информацию на подобные ресурсы. Обновления буду добавлять в пост.

Opengrok

Исходники – это основной источник информации для программиста, особенно если в компании (или проекте) размер кодовой базы переваливает за 200-300 тысяч строк.

Чтобы найти драгоценное зерно в такой куче, нужна правильная утилита для просмотра, а главное, поиска (типа «дай-ка я гляну, как народ эту функцию вызывает?» или «как там правильно создать экземпляр этого класса?» и т.д.).

Большинство систем контроля версий имеют веб-интерфейс для подобных целей. Также есть независимые системы, и одна из них называется Opengrok.


Это система с открытым кодом под лицензией CDDL. Может индексировать репозитории почти всех основных систем контроля версий, а для некоторых понимает и историю файлов. Множество критериев поиска. Крайне полезно, что можно одновременно подключать для индексирования несколько репозиториев, причем от разных VCS. Естественно, при просмотре исходник представляется гипертекстовым документом, через который можно двигаться дальше.

Кстати, можно вживую пощупать Opengrok на исходниках OpenSolaris’а.

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

P.S. Я как-то в целом давно не писал про всякие организационные примочки, облегчающие работу программиста.

Поэтому, небольшой списочек из старенького, но все еще актуального:

понедельник, 27 декабря 2010 г.

Атомарность типа int и указателя

Меня давно занимает вопрос атомарности типа int (да и любого типа, равного по длине шине процессора, например, указателя или float для x86).

Ясно, что в теории, нельзя полагаться на факт такой атомарности. Но давайте конкретизируем: платформа x86, и переменная объявлена как «volatile int a». Тут я не играюсь с «reinterpret_cast»’ом и приведением указателей, то есть можно гарантировать, что компилятор обеспечит правильное выравнивание, соответствующее шине процессора и памяти, тем самым гарантируя, что доступ к этой ячейке произойдет за один такт.

Есть ли хоть какой-то шанс с ненулевой вероятностью, что какое-то вычисление (команда процессора) по отношению к «а» может быть тут неатомарна? Может ли так быть, что операция «a++» или «a += arbitrary_stuff» и т.д. выполниться не целиком?

Так как переменная volatile, значит любые оптимизации будут компилятором запрещены, и не выйдет так, что вместо полноценной 32-х битной команды (обнуления, инкремента, умножения и т.д) компилятор использует, например, каскад двух 8-ми битных команд для операции, которую можно сделать одной 32-х битной.

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

Ясно, что правилом хорошего тона считается не полагаться на атомарность int’а. Но современная архитектура процессоров (микроконтроллеры пока не берем) практически гарантирует эту атомарность, разве нет?

воскресенье, 19 декабря 2010 г.

В блоге новая система комментирования DISQUS

Подглядел у "One Div Zero" - движок комментирования DISQUS и установил себе.

Что это такое? Это весьма продвинутый движок комментирования (с шахматами и гимназистками) со множеством современных примочек на замену стандартному: сортировка при просмотре, кнопки Не/Нравится, ответ на конкретный комментарий. Ну и разные административные/модераторские возможности.

В целом, ничего особенно, но по сравнению со стандартным движком Блогспота - это небо и земля.

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

Вобщем, посмотрим. Будут глюки - пишите.

UPDATE: Оказывается, тут можно редактировать собственные комментарии. Ура!

суббота, 18 декабря 2010 г.

А какая у вас зарплата?

Когда я ходил на свои первые интервью в Англии, меня приводил в недоумение вопрос, который почти всегда задают рекрутеры (независимые агенты или сотрудники отделов кадров конкретной компании) – «А какая у вас сейчас зарплата?». Не имея достаточно опыта подобного общения и толком не понимая причину этого вопроса, я имел глупость говорить эту сумму.

Обычно рекрутеры объясняют причину этого вопроса так, мол, это требование клиента, так как клиент хочет понимать, какой потенциальный скачок зарплаты ты себе хочешь. И часто, когда я пытался сопротивляться ответу на этот вопрос, агенты говорили, что тогда они не смогут дальше продвигать мое резюме клиенту. Часто люди на это ведутся, как велся и я.

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

Почему компании хотят знать вашу текущую зарплату? Все просто. После того, как успешно прошел все собеседования, и принято решения тебя брать, в работу включаются внутренние рекрутеры компании, цель которых нанять человека за возможно меньшие деньги. И если вдруг выходит, например, что ты пытаешься договориться на сумму, в два раза превышающую, что было раньше, это может быть еще одним доводом при обсуждении зарплаты, чтобы ее сбить (типа «где вы видели повышения зарплаты сразу в два раза?»). Действительно, для рынка труда в Англии это действительно маловероятное повышение, но, опять-таки, к переговорам это не имеет никого отношения.

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

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

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

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

Вот.

Кстати, может кто-нибудь поделиться опытом устройства на работу через кадровые агентства в России и других республиках и государствах нашего региона?

вторник, 7 декабря 2010 г.

Интервью с домашним заданием

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

И вовсе не потому, что я часто люблю менять работу (совсем наоборот). А потому, что в этом процессе есть несколько полезных сторон.

Для начала – это вызов. Задача, которую надо решить (ведь помните, что мы должны быть разносторонними, а не только на С++ программировать). Это как участвовать в ТопКодере. У меня это всегда легкое (а порой и не очень легкое) волнение и ощущение бабочек внизу живота. Предлагаемая задача не решается в лоб академическими знаниями и всегда требует, чтобы ты себя проявил.

Затем идет чисто практическая сторона – опыт, который никаким другим способом не получить. Даже если тебя все устраивает на текущей работе или собственном бизнесе, всякое может случиться, и иметь опыт устройства на работу (как бы формально и прагматично это не звучало) иметь стоит. К тому же усилий для его получения надо не так и много. Чтобы успешно пройти интервью – надо уметь это делать. Хоть многие компании и заявляют, что они целенаправленно набирают специалистов, а не специалистов по устройству на работу – это блеф. Люди всегда оценивают людей. И порой надо догадаться, что за критерии отбора скрыты за вопросами и задачами, предлагаемыми тебе на интервью.

Например, многие думают, что все интервьюеры – это супер/мега/экстра спецы, которые видят тебя насквозь. И причина этому – просто что «он» задает тебе вопросы, а не ты ему. Хотя в большинстве случаев, особенно в больших компаниях, интервьюируют обычные разработчики (а некоторые и без особого желания), и если догадаешься, что ему надо – успех гарантирован.

Лично я понял, увы, не сразу, насколько важно быть не только технически подкованным, но и собрать максимально информации и компании, а по возможности и о предстоящем интервьюере. Благо сейчас у всех есть блоги, ЖЖ, Фейсбук, ЛинкедИн, МайСпейс и т.д.

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

Ну и под занавес – наблюдение процесса интервью со стороны кандидата позволяет лучше интервьюировать самому. Быстро начинаешь понимать цену, смысл и назначение тех или иных вопросов. Мне это очень помогает при интервьюировании в Блумберге.

Ладно, это лирика.

Хочу поделиться интересным примером.

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

Затем, они мне прислали домашнее задание.

Суть задачи: есть шахматная доска MxN и набор фигур: короли, ферзи, слоны, кони и ладьи (каждой фигуры есть некоторое количество). Пешек нет, и цвет фигур не имеет значения. Надо сгенерировать все возможные расстановки данных фигур на поле. В расстановке должны участвовать в точности все данные фигуры.

Было дано несколько простых тестовых данных. Для задачи большой размерности (поле 7 на 7, 2 короля, 2 ферзя, 2 слона и одна ладья) надо только вывести количество возможных позиций.

И далее было самое главное ограничение: можно писать задачу на любом языке, кроме C, C++, C#, Java, Python, PHP, Pascal.

Срок – неделя.

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

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

Ну, в общем, суть понятна. Задача была не в задаче, а в «показать себя разносторонним программистом», не который если что, так расчехляет С++.

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

Вот.

P.S. Для желающих – исходники мой оригинальной программы на С++. Там же есть версия на Go, но плюсовый вариант содержит самый быстрый алгоритм, который я сумел придумать.

У меня больше нет идей, чтобы еще можно ускорить.

Желающие могут попробовать. Было бы очень интересно время работы теста #3.

Тесты (можно и добавлять свои) и проверяющая система уже встроены прямо в исходник. Его можно скомпилировать:

cl /O2 /EHsc problem.cpp

У меня печатается:

Case #0 OK (line 235)
Case #1 OK (line 248)
Case #2 OK (line 271)
Case #3 OK (line 318) time 1.495s

Для своей версии вам надо переписать функцию “solve()”. Присваивая переменной «problem_filter» значения, отличные от «-1», можно запускать не все тесты, а по одному.

Вообще, я спользую эту мини проверяющую систему для олимпиадных задач. Предложения приветствуются.