четверг, мая 31, 2007

Интересный блог

Я уже достаточно давно читаю блог Элдара Мусаева "Мысли которые не удалось удержать в голове". Читать собственно начал с того момента как прослушал его замечательный ролик на русском Channel 9 - "Про маразм и program management", зашел на блог ... да так там и остался :-) Рекомендую!

четверг, мая 24, 2007

Две интересных статьи

Обнаружил две интересные статьи. В частности они касаются некоторых вопросов, которые обсуждались в моих постах про "Дао Русского программиста", про то как научиться программировать и про то какие знания необходимы программисту.

Почитайте, интересно:

  1. Why a career in computer programming sucks?
  2. The death of the generalist software developer

вторник, мая 22, 2007

Полезный ключ компилятора MS VC++

Я уже довольно давно читаю блог команды разработчиков Visual C++ и должен сказать что это довольно таки занудный блог. Но вот последняя статья в нем - буквально таки жемчужина.

Не очень часто мы сталкиваемся с проблемой неодинакового выравнивания одних и тех же классов в разных единицах трансляции. Проблему трудно диагностировать и даже очень трудно. Так вот статья рассказывает про замечательный и конечно же НЕ документированный и не поддерживаемый ключ компилятора:

/d1reportSingleClassLayoutXXX, где XXX - интересующее нас имя класса.

При компиляции с этим ключом, компилятор показывает, как с его точки зрения "разложился" класс XXX. Вот код из статьи:

// a.h – share class definition (code has been corrected from original post)

#pragma once

class Test_A {
public
:

Test_A(){ c = 'X'; data = 0; }

~Test_A(){ if(data) delete [] data; }

char c;
char* data;

};

void Test_A_Loader(Test_A&);

// loader.cpp - loader defn.
#include
//for strcpy
#include
"a.h"

void Test_A_Loader(Test_A& a) {

a.c = 'p';
a.data = new char[10];
strcpy(a.data, "3.14159");

}

// main.cpp - main program
#include
// for printf

#include "a.h"

int main(){

Test_A a;
Test_A_Loader(a);
printf("%c : %c %c %c %c\n", a.c, a.data[0], a.data[1], a.data[2], a.data[3]);

}

Данный код компилируется вот так (для того чтобы воспроизвести ошибку):

cl main.cpp /Zp2 /c
cl loader.cpp /Zp1 /c
link main.obj loader.obj


При этом конечно возникает ошибка с выравниванием, поскольку класс Test_A выровнен по разному в единице трансляции main.cpp и в единице трансляции loader.cpp.

А вот вывод компилятор при использовании волшебного ключика '/d1reportSingleClassLayoutTest_A' (почему то в статье вывод компилятора целиком не приведён, а мне кажется что это интересно):

1>------ Build started: Project: ClassLayout, Configuration: Debug Win32 ------
1>Compiling...
1>stdafx.cpp
1>Compiling...
1>loader.cpp
1>class Test_A size(5):
1> +---
1> 0 | c
1> 1 | data
1> +---
1>class Test_A size(5):
1> +---
1> 0 | c
1> 1 | data
1> +---
1>Compiling...
1>ClassLayout.cpp
1>class Test_A size(6):
1> +---
1> 0 | c
1> | <alignment member> (size=1)
1> 2 | data
1> +---
1>class Test_A size(6):
1> +---
1> 0 | c
1> | <alignment member> (size=1)
1> 2 | data
1> +---
1>Linking...
1>Embedding manifest...
1>Build log was saved at "file://l:\ClassLayout\Debug\BuildLog.htm"
1>ClassLayout - 0 error(s), 0 warning(s)
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

Вот такой вот замечательный ключик. А я уж от их блога отписываться хотел.


среда, мая 16, 2007

Ответ на статью: Путь без конца или Дао русского программиста

Я сегодня выступаю в не очень привычном для себя жанре. Этот пост - ответ.

Я думаю что Максима Кононенко, также известного как Mr.Parker знают все. Ну если и не знают, то слышали про него уж точно очень многие. Он - создатель популярного сайта Владимир Владимирович™, известный блоггер, сетевой писатель и журналист. А также программист. Вот я как раз про это. Некоторое время назад вышел пост Максима под названием: Путь без конца или Дао русского программиста. Именно этот пост я и хочу здесь разобрать. Так что уж не обессудьте, для того чтобы читать дальше придётся сначала сначала прочитать исходный пост.

(замечание: данный ответ также опубликован и как комментарий к самому посту Максима - только без вступительной части)

К вопросу о терминологии

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

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

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

О предмете программирования

Я хочу остановиться на вопросе о предмете программирования. И я прочёл (не буквально, а "увидел", "интерпретировал") в самом посте, а также, кажется в каких-то ответах автора к комментариям на LiveJournal (затрудняюсь их сейчас здесь привести) мнение о том, что программирования как предмета не существует. То есть мне показалось, что автор утверждает: нет никакой "computer science", есть несколько областей математики, плюс некоторые ремесленные приёмы.

Я увидел эту мысль и в утверждениях что "нигде программированию не учат 5 лет" и в том что "
что программирование - не ахти какое сложное занятие".

Я же убежден что "программирование имеет свой предмет, не сводящийся ни к конкретным языкам и системам, ни к методам построения быстрых алгоритмов" (Шень А. "Программирование: теоремы и задачи"). Попробую объясниться.

Дело в том, что программирование, также как и математика, например или к примеру, упоминаемая автором медицина - это очень "широкая" дисциплина. Человек, пишущий скажем компилятор - программист, человек пишущий "графический движок" игры - тоже программист, пишущий plug-in к браузеру Firefox - тоже, пишущий адресную книгу для сотового телефона тоже, но и пишущий на php формочку, чтобы отправить письмо со своего веб-сайта - тоже. Есть масса разных ответвлений и уровней. Как и везде - есть сложные части, а есть простые, есть требующие больших знаний в "сопутствующих" областях, а есть меньших.

Тем не менее, есть некоторые общие моменты, которые сводят всех этих людей. Это необходимость сформулировать и выбрать абстракции, организовать взаимодействия объектов, построенных на основе этих абстракций между собой, продумать последовательность этих взаимодействий и добиться желаемого результата. (для буквоедов: не придирайтесь к слову "объекты" - я не имел ввиду объектно-ориентированную парадигму проектирования). Это очень важно иметь ввиду при рассмотрении дисциплины программирования.

Остальное

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

P.S. Вот ещё что хотелось сказать. Ведь Максим Кононенко написал ещё и рассказ Покемон. Удивительно что один и тот же человек написал две такие совершенно разные [по духу] работы.

четверг, мая 10, 2007

Научиться программировать ...

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

Это сложный вопрос и я конечно не смогу на него ответить, так что я разочарую тех, кто надеялся получить какой-то готовый рецепт. Когда-то давно я прочитал замечательное эссе Питера Норвига на эту тему. Эссе называется "Научитесь программировать за 10 лет". Его можно прочитать в первоисточнике, а также в русском переводе. Эссе посвящено тому, как по мнению Норвига нужно подходить к (само)обучению программированию, а название это естественно пародия на многочисленные книги типа "Научитесь XXX за 21 день".

Сегодня я ещё раз перечитал это эссе, и заметил там для себя что-то, чего не замечал раньше. Ну, точнее замечал, но как-то не придавал должного внимания. А именно, отношение Норвига к поверхностному обучению. В самом начале эссе, он в шутку разбирает что бы могло на самом деле обозначать название книги "Изучите Паскаль за 3 дня". В частности, Норвиг пишет: "... за три дня вы можете получить только поверхностное представление о языке, а не глубокое понимание. Как говорил Александр Поуп - "Недостаточное обучение - это очень опасная вещь".

Это очень верное замечание, на которое стоит обратить внимание. Именно поэтому в одном из своих предыдущих постов, посвящённом вопросам на собеседовании, я и писал что необходимо проверять базовые знания. Задавать "простейшие" вопросы(в кавычках, поскольку это вопросы на самом деле не простые, просто мы настолько привыкли давать на них ответы-"отписки", что не очень задумываемся о сути). Проверять именно глубину знаний. Проверять что человек умеет программировать, и не впадёт в ступор, когда закон
"закон дырявых абстракций" (The law of leaky abstractions") покажет себя.

Перечитайте ещё раз статью Норвига (ну или прочитайте её, если не читали раньше). На самом деле она ведь не только про программирование ;-)

среда, мая 09, 2007

С праздником!

Поздравляю!

среда, мая 02, 2007

Хорошие вопросы

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

Все соображения на тему "Как проводить собеседование" напоминают мне одну известную шутку.

Молодую девушку пригласили на свидание и она спрашивает маму - "Как вести беседу?" Мам отвечает - "Ну поговорите сначала о погоде, потом, к примеру, о музыке, а потом скажи что-нибудь остренькое". Во время свидания сразу же после встречи девушка и говорит: "Какая чудная погода, училась музыке три года, бритва."

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

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

  1. Что такое порт? (в смысле TCP/IP порт) Зачем он нужен? (В смысле - для чего используется)
  2. Зачем нужна операционная система? (В смысле - для чего используется)
  3. Зачем нужны точки в ip-адресе?
  4. Как определить в какую сторону растёт стек?
  5. Зачем нужен компилятор?
  6. Ведь микропроцессор оперирует исключительно двоичными числами? А как же получаются буквы?
  7. Что такое программа? (компьютерная программа)
  8. Что такое "сложность вычисления"?
  9. Зачем нужны системы управления базами данных? Да и сами базы данных?
  10. Что такое ASP (или JSP, или PHP, или ... )? На самом деле этот вопрос не совсем то, чем кажется. Я вероятно просто не смог его аккуратно сформулировать. В качестве ответа я конечно ожидал бы не расшифровку аббревиатуры и даже не краткое описание самой технологии. Я ожидал бы беседы о том, как работает типичный web-сайт.
Замечание: некоторые из вопросов могут показаться слишком лёгкими или слишком "общими" или даже оскорбительными чтобы задавать их человеку с серьёзным опытом работы. Мне кажется, что это не так.
  1. Вопросы являются лёгкими, если ты знаешь правильные ответы. Это прекрасно!
  2. "Общими" или даже "расплывчатыми" вопросы сделаны специально - чтобы спровоцировать обсуждение.
  3. А насчёт того можно ли задавать человеку с 10-летним опытом работы вопрос "что такое программа"... Ну понимаете, представьте себе на секундочку, что он не ответит.
    (кстати, в качестве ответа на такой вопрос вполне могут послать в края отдалённые и всем известные ... в большинстве случаев я бы считал это правильным ответом :-))

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

Более того, мне хотелось бы надеяться, что эти вопросы полезны сами по себе. Что я имею ввиду? Многие вопросы для собеседований ценны только до тех пор, пока кто-то не прочитал на них ответ. В частности, такой проблемой страдают многие "каверзные" вопросы, такие как задача о взвешиваниях 8 монет, перевозе разных тварей через реку и так далее. В большинстве случаев, при задавании подобных вопросов проверяется не столько "логическое" мышление, сколько слышал раньше человек этот вопрос (и ответ на него) или нет.

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