Сегодня, копаясь в svn репозиториях за которые мы отвечаем, обнаружил, что все файлы, на наших Unix машинах, имеют концы строк в DOS-стиле. Кроме того, все исходники имеют установленный бит запускаемого файла, что уж совсем нехорошо.
Неправильные концы строк тоже ни к чему хорошему не приводят. И патч создать труднее, и даже билд упасть может.

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

Чтобы исправить это положение необходимо для каждого текстового файла в проекте выставить svn свойство svn:eol-style в native. И удалить свойство svn:executable.

Кроме того, subversion-клиент можно сконфигурировать, чтобы для всех добавляемых в проект файлов нужные свойства выставлялись автоматически. Для этого необходимо в конфигурационный файл прописать значения свойств по умолчанию.
Конфигурация svn расположена в ~/.subversion/config, на *nix системах, и в файле C:\Documents and Settings\{username}\Application Data\Subversion\config, на Windows системах.
Хороший пример конфигурационного файла можно увидеть в Apache: http://www.apache.org/dev/svn-eol-style.txt

Больше узнать о svn свойствах можно, например, тут: http://svnbook.red-bean.com/en/1.1/ch07s02.html

Хочу выразить своё большое человеческое спасибо разработчикам VirtualBox за упрощение создания хост-интерфейсов для виртуальных машин на Windows, в версии 2.1.2.

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

Kudos вам, дорогие товарищи!

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

Обычно всё организовано посылкой электронного письма ответственному за решение проблем. Ну может на алиас ответственных. Все признают, что письма то теряются, то забываются, комментарии посылаются не всем, статус запроса не посмотреть, историю не найти и т.д. Но все упорно считают, что якобы «лёгкость» отправки письма, по сравнению с отправкой веб-формы, искупает все эти ужасы и проблемы. Ну вот объясните мне, чем легче-то  письмо отправить?!

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

Так что, не сдаваться и продвигать прогресс в массы! 🙂

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

Мне её давали на собеседовании в Exigen.

Задача

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

Читать далее

Задачка, которую используют на собеседования в Microsoft. Исключительно на сообразительность.

Задача

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

Как, за один поход в первую комнату, узнать какой выключатель включает какую лампочку?

Решение

Включаем первый выключатель и ждем некоторое время, затем выключаем. Включаем еще один выключатель и идём в первую комнату. Лампочка, включаемая вторым выключателем горит. Лампочка, включаемая первым выключателем, теплая.

NB: Очевидно, что задача применима только к лампочкам накаливания.

Это достаточно давняя история, но, тем не менее, очень показательная.

Однажды у меня умер Siemens S55, который служил мне верой и правдой несколько лет. Умер быстро и без предупреждения. Просто выключился и отказался включаться.

«Бывает», подумал я. За контакты я тоже не перживал, т.к. все две с лишним сотни контактов у меня регулярно синхронизировались с Outlook. Но жить без сотового телефона нынче трудно и непривычно, плюс поджимала необходимость уехать на следующий день в другой город. Одним словом, времени на выбор нового телефона и его покупку у меня оставалось несколько часов.

Я составил список необходимых мне функций, вылез в интернет и нашел там самый недорогой телефон, в котором был весь набор. Им оказался Nokia 6021. Он и был куплен.

Читать далее

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

Практически неизбежное «зло» в такой команде — появление сотрудников с амбициями карьерного роста. Часть руководителей воспринимает таких сотрудников как угрозу их спокойной жизни и своему личному положению. А также начинает выдавливать и/или принижать их достоинства всеми правдами и неправдами.

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

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

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

А IT рынок маленький, кто знает где еще придется встретиться 🙂

А конкуренция? Не нужно её бояться, нужно самому развиваться и расти. У тебя ведь тоже есть амбиции и ты не собираешься сидеть на этом месте до пенсии 🙂

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

Остались недоделанные дела. Основное — это необходимость поставить в компании процесс разработки программного обеспечения на промышленные рельсы. Начать с багтрака и комментов в svn, без которых жить вообще нельзя. Ввести code review, чтобы провести ревизию кода, улучшить его и, самое главное, потренировать разработчиков видеть свои и чужие ошибки, а также возможности оптимизировать код. И так далее. Толкать я в эту сторону начал, но закончить не успел.

Всем остающимся в ЛМА удачи и успехов!

Следующим местом моей работы будет компания Sun Microsystems. Команда релиз инжиниринга J2ME проектов. В России я буду единственным членом команды, остальные в Штатах, включая менеджера (work from home! 🙂 ).

Это, фактически, возвращение в родные пенаты, т.к. я проработал на эту компанию более 5 лет и многих там знаю. Кроме того, это компания с которой мы конкурировали в проекте Apache Harmony.

Труба зовёт! И впереди меня ждут новые люди, новая работа и новый опыт.

Удачи и успехов мне! 🙂

P.S. Теперь опять придется говорить про Sun исключительно в рамках корпоративной этики 🙂

Задачка классическая и очень простая. Посему имеет смысл ее использовать только для совсем уж начинающих программистов.

Хотя меня как-то недавно тоже попросили ее решить 🙂

Задача

Развернуть строку символов. Как вариант, можно попросить развернуть массив.

Решение

Решений опять же много. Предлагаю все решения, где для разворота массива понадобился еще один массив считать незачётом. Можно это требование внести в условие, но, ИМХО, лучше посмотреть не предложит ли вдруг кандидат подобного решения и уже потом ввести это дополнительное ограничение. Единственным оправданием можно считать вопрос о том необходимо ли сохранить исходную строчку. Но это замечание не относится к Java, т.к. там придется выносить символы из строки в массив. И этот массив, очевидно, беречь нам ни к чему.

Краше всего на C/C++, где строчки — те же самые массивы. Будем использовать такую милую любому настоящему программисту на C арифметику указателей.

void reverseString(char *str)
{
    int i = 0;
    int len = strlen(str)-1;
    for (; i <= len/2; i++)
    {
        char c = *(str+i);
        *(str+i) = *(str+len-i);
        *(str+len-i) = c;
    }
}

На Java, как я говорил, выглядит менее элегантно, т.к. со строкой нельзя работать, как с массивом. И получатеся нечто вроде:

String reverseString(String s) {
    char []str = s.toCharArray();
    int len = str.length-1;
    for (int i = 0; i <= len/2; i++) {
        char c = str[i];
        str[i] = str[len-i];
        str[len-i] = c;
    }
    return new String(str);
}

Эта задачка применялась, как минимум, на собеседованиях в Sun Microsystems. Задачка миленькая, несложная, на сообразительность.

Задача

Отсортировать массив, состоящий только из единиц и двоек.

Решения

Решений, как у большинства задачек много. Приведем некоторые.

  1. Сложить все  элементы массива и вычесть из суммы длину массива. Результатом будет количество двоек в массиве. Далее массив заливается нужным количеством последовательных двоек и единиц.
  2. Посчитать количество единиц и двоек, пройдя по массиву. Далее опять заливаем массив нужным количеством двоек и единиц.
  3. Запускаем в цикле два счетчика, сближающихся с противоположных концов массива. Меняем местами соответствующие значения, по необходимости.

В третьем варианте что-то вроде:

public void sort12(int []array) {
    int i = 0;
    int j = array.length-1;
    for (; i<j; i++) {
        // Сортируем по возрастанию
        if (array[i] == 2) {
            for (; array[j] == 2; j--);
            array[i] = 1;
            array[j] = 2;
            j--;
        }
    }
}

Первый вариант представляется самым оптимальным, с точки зрения производительности: сравнений нет, все действия с массивом последовательные. В нём как раз проявляется сообразительность 🙂

Второй вариант похуже, но тоже ничего.

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