У меня есть два вопроса:

1) Что творится с этим долбанным фреймворком? Где нормльные книги, где нормальные статить, где нормальные доки? В официальных доках черт ногу сломит (это отличительная черта гугла, например, в доках по апи ютуба и гугл плюса тоже самое), при попытки нагуглить какую-то банальную вещь сразу натыкаешься на version-hell. Я на столько отчаялся в поисках нормальной обучающей инфы, что даже купил вот эту книгу, но меня ждал сюрприз - книга предполагает, что я знаю TensorFlow, лол.

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

Вот так я создаю и тренирую модель:

def build_model(learning_rate=0.1):
    tf.reset_default_graph()
    
    net = tflearn.input_data([None, VOCAB_SIZE])
    net = tflearn.fully_connected(net, 125, activation='ReLU')
    net = tflearn.fully_connected(net, 25, activation='ReLU')
    net = tflearn.fully_connected(net, 2, activation='softmax')
    regression = tflearn.regression(
        net, 
        optimizer='sgd', 
        learning_rate=learning_rate, 
        loss='categorical_crossentropy')
    
    model = tflearn.DNN(net)
    return model

Создаем модель:

model = build_model(learning_rate=0.75)

Тренируем:

model.fit(
    X_train, 
    y_train, 
    validation_set=0.1, 
    show_metric=True, 
    batch_size=128, 
    n_epoch=30)

Далее, я пытаюсь сохранить модель:

saver = tf.train.Saver()
sess = tf.Session()
sess.run(tf.global_variables_initializer())
saver.save(sess, './sentiment-model')

Получаю вот такие варнинги:

WARNING:tensorflow:Error encountered when serializing data_preprocessing.
Type is unsupported, or the types of the items don't match field type in CollectionDef.
'NoneType' object has no attribute 'name'
WARNING:tensorflow:Error encountered when serializing data_augmentation.
Type is unsupported, or the types of the items don't match field type in CollectionDef.
'NoneType' object has no attribute 'name'
WARNING:tensorflow:Error encountered when serializing summary_tags.
Type is unsupported, or the types of the items don't match field type in CollectionDef.
'dict' object has no attribute 'name'

Но файлики таки создаются:

checkpoint
sentiment-model.data-00000-of-00001		
sentiment-model.index			
sentiment-model.meta

И вот что делать дальше, я не понимаю абсолютно. По идее, нужно выполнить код, типа этого:

sess = tf.Session()
new_saver = tf.train.import_meta_graph('sentiment-model.meta')
new_saver.restore(sess, tf.train.latest_checkpoint('./'))
all_vars = tf.get_collection('vars')
for v in all_vars:
    v_ = sess.run(v)
    print(v_)

Но тут я получаю ошибку:

"The name 'SGD' refers to an Operation not in the graph."

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

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

Вот нарисовал картинку: http://savepic.ru/15045931.png

Вход - 9 нейронов x1...x9, которые не нейроны, а скорее «сенсоры», хотя почему-то везде называются «нейроны входного слоя». Нейрон - это то, что делает какую-то операцию со входами, а тут на X1...x9 входов нет, они сами уже чисто «выход», выдают прямо значения пикселей картинки, значит это скорее как сенсоры в глазу, а не нейроны. x1...x9 — сенсоры. Меня сильно смущает понятие нейрона, я всегда начинаю думать - «суммирование каких взвешенных входов делают эти нейроны? Никаких? Почему это тогда нейроны?». Короче, сенсоры. Далее.

Наша входная обрабатываемая картинка пускай будет 32*32, канал - 1 (ч/б).

9 сенсоров смотрят на фрагмент 3*3 входной картинки, нейрон X10 таким образом выполняет свёртку и математически совокупность весов w1...w9 являются ядром свёртки, верно? Потому нейросеть называется свёрточной. В русской википедии про CNN-нейросети тынц совокупность весов w1...w9 называется матрица весов.

Сенсоры x1-x9 «подключены» к входной кратинке именно так: в единицу времени смотрят на её окрестность: значение каждого пикселя умножается на соответствующий W, получаем SUM(x * w). В англоязычных статьях-видосах эта операция называется Dot Product https://en.wikipedia.org/wiki/Dot_product или скаярное произведение по-нашему. Это и есть свёртка? Выход этой операции (свёртки): скаляр (число). Мы «свернули» 9 пикселей в один. Кстати, свёрткой могут называть как одну операцию над 9 пикселями так и целую результирующую картинку, состоящую из множества результатов свёртки над каждыми 9-пиксельными регионами, когда мы пробежим этим 9-пиксельным окном по всему входному изображению (читать далее).

У меня на картинке показан только 1 нейрон «скрытого слоя» - X10.

В куче статей и видосов сказано, что нейрончик X10 (который ядро свёртки) называется filter. почему такой термин? Почему не ядро свёртки?

Итак, физически происходит следующее (насколько это верно?): мы пробегаем нашим ядром свёртки (окном 3*3 - можно 5*5, тогда входных сенсоров будет 25) по входной картинке с шагом, например 1 (настраивается): то есть ставим наше «окно захвата» - «окно свёртки» 3*3 на все возможные позиции на картинке и снимаем для каждой такой позиции значение на выходе X10, рисуя для каждой отдельной позиции окна (3*3) пиксель на выходнуй картинке. У меня показано как стрелка из X10 тычет (записывает) пиксель выходной картинки для данного 3*3 окна. Смещая наше входное окно 3*3 на 1 пиксель вправо, получаем значение следующего справа пикселя выходной картинки. Вот GIF из википедии: https://upload.wikimedia.org/wikipedia/commons/thumb/4/4f/3D_Convolution_Anim...

Эта вторая картинка называется feature map?

Нейрон X10 (с его весами входов w1...w9), т.е. filter, т.е. ядро свёртки, бегающее по входной картинке, можно интерпретировать как «признак». Т.е. совокупность весов w1...w9 как-бы кодирует некую графическую микро-фичу, признак. Например кодирует маленькую наклонную линию (веса w1...w9 будут по какой-то диагонали большими, остальное будет 0, например). Выходная картинка (картинка, куда пишет X10) - это будет как «карта признаков», т.е. на какой позиции входной картинки этот признак (наклонная линия) встретился (результат свёртки будет иметь высокое значение выше нуля) или не встретился (ноль или ниже). Т.е. мы на выходе получаем такую карту, которая показывает где (в каком квадрате 3*3) эта наклонная линия есть на входном изображении.

И это всё только с 1 нейроном входного слоя X10. Одно-нейронный слой (такое вы видите впервые только на нашей картинке!), а уже сколько важного.

Эта недо-нейросеть уже имеет смысл: например если X10 кодировал наклонную линию «от нихнего левого до верхнего правого» (знак слеш) (т.е. маленькую фичу, которая вписывается в 3*3), то если мы нарисуем на входной картинке одну длинную такую диагональ, то на выходной нейросетевой картинке получим точки по этой диагонали - нейросеть нашла много раз этот признак вдоль нашей «большой» диагонали (по-сути диагональ составлена из множества маленьких). Если линия на входной картинке была жирная, то тогда имеет смысл сначала найти края (edges), потом уже натравливать нашу фичу. Но это другая история. Причём края может выделять та же самая нейросеть...

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

Самый интересный вопрос

Теперь посмотрим на типичную схему нейросети, которая рисуется на каждом углу: https://i.stack.imgur.com/9jzpy.jpg

Три нейрона входного слоя. Они же три фильтра. Каждый из них описанным выше способом бегает по входной картинке и создаёт карту признаков (feature map). Получаются 3 независимых карты признаков. Далее стоит выходной нейрон, который берёт входы со всех 3 нейронов. Как он это делает? На входы последнего выходного нейрона подаются результаты работы фильтров (нейронов скрытого слоя) когда каждый из них КУДА смотрит? Обязательно в одну и ту же область картинки? Т.е. вспоминая про feature map (карта признаков, которых у нас тут три - каждая на выходе своего фильтра), входной нейрон берёт значения из разных карт признаков (ведь 3 синапса выходного нейрона подключены на РАЗНЫЕ нейроны скрытого слоя - значит смотрят на разные карты признаков)? Но из какой именно точки этих карт признаков? Из точки с одной и той же кооринатой? То есть выходной нейрон умеет видеть только информацию вида "в какой мере 3 признака (реализованные 3-мя фильтрами) присутствуют в одном и том же месте картинки"? Выходной нейрон никогда не «увидит» ситуации вида «признак 1 в центре, признак 2 в углу, признак 3 в другом углу»? Скажем, если бы мы захотели сделать свёртку свёртки, то есть иметь второй скрытый слой до выходного нейрона, то есть наложить ещё какой-то фильтр на карту фич первого фильтра, то я теряюсь как это можно показать на подобной примитивной схеме нейросети и используется ли это вообще где-либо и если да, то как изображается схематически?

Объява: вступлю в приватную переписку по сабжу: data.structures@yandex.ru

Собственно вопрос:
ВШЭ
Программа «Машинное обучение и майнинг данных»
36 часов
https://cs.hse.ru/dpo/datamining

Кто-нибудь в курсе, что за курс, стоящий?
Какой уровень матана нужен?
Можно в принципе научиться чему-нибудь за 36 часов?
Мозг не закипит?

Вопрос по qjs api (qjsengine) бывший qtscript.

Когда выводишь в консоль к примеру командой: «print(„hello world!“); Получается след. выхлоп: „js: hello world!“

Вопрос как избавиться от приставки „js: “ - сделать чистый вывод без этого информационного дополнения???? В qtscript такого не было....

Результат нескольких лет труда одного паренька: https://github.com/andyjko/whyline

В действии: https://www.youtube.com/watch?v=t6gVZ-qZ4sI

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

Переворот в отладке? Какому технологическому стеку (помимо java/jvm в данном случае) ещё подвластно подобное? Теоретически, на Smalltalk вполне себе можно замутить. Или на JavaScript. Ещё?

Нужно чтоб питон-скритп запустил программу и через некоторое время написал строчку в программу.

Если просто представить, то есть CPP программа:

#include <iostream>
#include <fstream>

using namespace std;
int main()
{
   std::string input;
   int i = 0;
   ofstream myfile("/var/tmp/result.txt", ios::out);
   while (1)
   {
      std::cin >> input;
      std::cout << "get: " << input << "; i = " << i << std::endl;
      myfile << "get: " << input << "; i = " << i << std::endl;
      i++;
      if (i > 10 )
         return 0;
   }
}

#!/usr/bin/python
from subprocess import Popen, PIPE
import time

CMD="/home/y/test/build-console-Desktop/./myApp"
handle = Popen(CMD, shell=True, stdin=PIPE) 

time.sleep(2)
print "write now"
handle.stdin.write("123")
handle.stdin.flush()
handle.stdin.close()
time.sleep(2)

$ ./test_py/test_small.py
write now # - это пишет питон
get: 123; i = 0 # это и до конца CPP
get: 123; i = 1
get: 123; i = 2
get: 123; i = 3
get: 123; i = 4
get: 123; i = 5
get: 123; i = 6
get: 123; i = 7
get: 123; i = 8
get: 123; i = 9
get: 123; i = 10

Привет всем, кто запускает Linux с флешки!

Вы наверняка попадали в ситуации, когда кто-то задевал флешку, с которой работает система, или подключал рядом с USB-жёстким диском требовательный к питанию смартфон, в результате чего устройство на долю секунды теряло питание, сбрасывалось и переподключалось. Система оказывалась в дико неприятном состоянии, в котором вот оно, корневое устройство, но ни одна команда, кроме тех, которые ещё лежат в кэше, не работает, и даже Alt+SysRq+S,U не поможет предотвратить потерю данных: устройство, на которое можно было бы сбросить кэш, уже отключено, и убедить ядро обратиться к другому невозможно. Фрустрации добавляло ещё и то, что Windows To Go с этим прекрасно справляется, зависая, пока флешку не вставят обратно (с выключением по минутному таймауту).

Оказывается, в Linux это тоже просто обойти. Достаточно создать при помощи dmsetup логический диск в режиме linear и при помощи правил udev делать ему suspend, если устройство было удалено, и создавать ему новую таблицу и делать resume, когда устройство с тем же UUID вставят обратно. На всякий случай, memlockd позволяет удержать в кэше бинарники udev, dmsetup, busybox и blockdev, на которых всё работает. Готовые скрипты (в расчёте на initramfs-tools) лежат на https://github.com/aitap/switchblock/. Адаптировать на другие initramfs должно быть несложно, потому что это всего лишь правило udev + вызываемые из него файлы.

Если кому-то будет интересно, готов принять pull request'ы со скриптами сбора пакетов.

Представьте себе круглую батарейку на 1,5В, к полюсам которой припаяны бесконечно прочные длинные проводники, с нулевым сопротивлением, замкнутые в цепь с лампочкой. Теперь мы, держа патрон с лампочкой в руках, отшвыриваем батарейку с субсветовой скоростью от себя. Что будет с током? Напряжение и сила тока упадут? Или что? Или как?

Старый лоровский акк потерял (Edible), запилил этот.

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

[C-TH][        07_all_coloured.c:0009] Malloc :              0x00000190 B (0x09A9C008) : Success
[C-TH][        07_all_coloured.c:0013] Realloc: (0x09A9C008) 0x00000320 B (0x09A9C028) : Success
[C-TH][        07_all_coloured.c:0017] Free   : (0x09A9C028)                           : Success
[C-TH][        07_all_coloured.c:0019] Calloc :              0x00000080 B (0x09A9C008) : Success
[C-TH][        07_all_coloured.c:0022] Free   : (0x09A9C008)                           : Success

Может стрелять в stdout/stderr/файл. Может убрать необходимость проверять на null, может красить выхлоп с помощью ANSI-кодов.

https://github.com/codemeow/c-heetah

Берите, кому надо.

Ъ: https://see.stanford.edu/Course/CS229

!Ъ: Стэнфорд выложил курс по ML, который читает Andrew Ng (если кто не в курсе - патриарх этой области нынче, вместе с Лекуном). По беглому осмотру - есть существенные отличия от курса ML, который был начитан этим же ученым для Coursera.

Тихо и незаметно количество сообщений перевалило за 12.000.000. Как узнать кто взял гет?

Бьерн Страуструп и Герб Саттер опубликовали в открытом доступе объемный документ, содержащий основные принципы разработки на современном С++. Авторы надеются, что следование данным принципам позволит разработчикам эффективно использовать язык и писать безопасный и поддерживаемый код.

C++ Core Guidelines: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md/

есть вот такое:

double a, b, c;
vector<double> V;

for (int i = 0; i < V.size(); ++i) {
	if(i > 1) V[i] = f(V.at(i-2), V.at(i-1));
	else 	  V[i] = i;
}

как можно узнать(посчитать) побыстрее V.back()? можно и без vector, for...

Короче дали на работе задачку - сделать изображение серпа и молота не распозноваемым. Ну вы знаете про решение нового украинского правительства. Изображений миллионы. Ясно, что нужно применять gm. Кое-что читал про преобразование Хафа для поиска геометрических фигур. Но непонятно: Применим ли он для поиска изображения серпа и молота? Есть ли готовая реализация на Python или JavaScript Хватит ли производительности этих языков для обработки миллионов изображений? Зы на хабре был. Ничего подобного не нашел Спасибо

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

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

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

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

UPD: сам читал всего одну книгу - Жданов А.А. «Автономный искусственный интеллект». Еще смотрел очень интересный курс лекций про паттерно-волновую теорию интеллекта, но там ваще жесть. Видимо кроме автора ни кто не понимает, как она работает.

Винни Пух грызёт опилки.

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

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

- Пригодиттся. - шамкал Кролик с набитым ртом. Ему давно надо было присобачить новый раздел для компиляния генты - на прочих была убунта и порнуха в шифрованных каталогах. Повезло, однозначно повезло, радовался Кролик, и носитель и энергия для чипа в одном флаконе, пора делать лапы, пока они целы. Вокруг копошились ослики, зайцы, белки, волки, лисы, и даже один исхудавший слонопотам с вымазанным зелёнкой хоботом - кого в стергах только не было. Нормальных зверей там только не было. И совести. Поверху кучи-малы громящей и пожирающей стеллаж с пуховыми пищевыми запасами сновала опустившаяся Сава. Лезть в кучу она опасалась из боязни поломать крылья и подло крысятничала у более крепких и шустрых интернетпользователей. «Интернет приходит в каждый дом, дорогие товарищи! Широкополосный, беспроводной, а для установивших стимулирующий чип и подписавшихся на обновления ещё и бесплатный!», вещала реклама с придыханием на каждом углу, засоряя мозг баннерами и бегущей строкой всем кто подключился к интернету но не озаботился установкой хакерского резака траффика.

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

Оглядевшись по сторонам Винни вернулся в дом. Оторвашись от коннекта, жрать теперь хотелось неимоверно, в железячном режиме голод как-то не чувствовался, но стоило вернуться в реал как проблемы накатывались снежным комом. Вот и сейчас, надо было что-то зубануть, но оставлять хату с раздолбанной дверью чтобы добежать до гомозина и отовариться жрачкой, нельзя было категорически. Завтра. А завтра придёт его индийский друг кодер Тигра, вместе они с дверью что-нибудь придумают. Вместе они забабахают такую континентальную оборону что тухлые стервятники получат шишь от Кузькиной матери а не пищевые запасы Пуха... Но вот сегодня... Сегодня до завтра ещё надо дожить. И посему усталый и голодный медведь кое как забаррикадировал дверной проём деревяшками схваченными шурбовёртом и поплёлся в соседнюю комнату харчить опилки оставшиеся от изготовления няшных противовампирских колышков. Его чип в случае необходимости мог харчить почти любую органику, даже тухлую черепаху мог пустить на килобайты. Кстати, пацаны, а когда вы в последний раз видели черепаху Тортиллу? Нет, ну в самом деле интересно, может быть она где-то затаилась и её отсутствие просто совпадение. Да, хорошо что после культурного и мирного погрома сохранилась неповрежённой банка кетчупа в небьющейся упаковке. С кетчупом опилки однозначно полезнее! Гуляй миша, жуй опилки!

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

- на сервере: Scala, Spray;

- для персистенсу: Slick. БД для прототипа хватит и H2;

- на клиенте: хочу js во все поля, одностраничность и все такое.

Вместо скаловских либ могу рассмотреть вообще что угодно из жабомира. Саму скалу менять не хочется.

Вопросы такие:

1. Жизнеспособно ли такое сочетание:

- для создания прототипа;

- для продакшена.

2. Если нет, что на что нужно заменить?

3. Что можно почитать о правильной архитектуре неэнтерпрайзных веб-приложений? Интересуют не книги типа Learning HTML5/CSS и не мануалы по библиотекам/фреймворкам, а именно цельное руководство по всему процессу, по лучшим практикам и т.д.? Язык предпочтительно английский.

у меня есть java-класс. объект этого класса обычно содержит ссылки на несколько десятков тысяч объектов более мелких классов и несколько длинных векторов. кроме того, есть расчетный модуль на с++, которому надо передать объект этого «толстого» класса.

посоветуйте, как лучше передать данные в с++, так чтобы на (де)сериализацию тратилось как можно меньше времени?

есть ли возможность передать данные в с++ код без копирования, без сериализации? так, чтобы с++ «разделял» ту же область памяти, что и java?

p.s. классы содержит векторы чисел и списки объектов (по ~10 числовых полей) что-то подобное, вроде бы, умеет cap'n'proto. но умеет ли он быстро сериализовать из java в c++ - я не понял

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

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

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

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

Особи, способные генерировать удачную идею в rолове (а лучше в Visio), а затем выполнить ее полноценную конкретизацию в коде, становясь, таким образом, единственными участниками процесса, встречаются очень редко. Недостаток архитекторов в том, что их код часто служит только одному хозяину, а исполнять чужие команды категорически отказывается.

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

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

Конструктивист.

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

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

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

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

Художник.

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

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

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

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

Инженер.

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

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

Ученый.

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

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

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

Лихач.

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

Волшебник.

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

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

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

Минималист.

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

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

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

Аналогист.

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

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

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

Трюкач.

Трюкачи слишком увлекаются разными технологическими трюками. Они постоянно осваивают разные новинки, но результат от этого не улучшается. Трюкачи, при всех их познаниях в технологии, часто не могут усвоить конечное назначение программы.

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

Разгильдяй.

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

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

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

Тормоз.

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

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

Помогите тормозу регулярно добиваться небольших успехов, и тогда все наладится.

Любитель.

Любители очень хотят стать настоящими программистами. Тщательно изучив какой-нибудь инструмент написания макрокоманд, они возводят себя в ранг хакеров. Единственная причина, по которой они бросают уютные мест в отделах поддержки пользователей и тестирования, Заключается в том< что, по их мнению, быть программистом - это очень круто.

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

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

Профан.

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

Эклектик.

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

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

Ковбои.

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

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

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

А кто вы? :D