Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, мыщъх, Вы писали:

I> Так то оно так, но я ищу баланс между временем собеседования, шириной опроса и сложностью задачи.
"я вам не завидую" (с). сейчас сам думаю как искать думающих людей. пока нет никаких идей, кроме того, что проверить опыт в определенной предметной области можно по задачкам типа этой: даны числа 78h, 3Сh, 18h, 20h, 10h. вопрос -- какое число лишнее. 30 секунд. и сразу видно какой у человека опыт -- реальный или просто "в общей сумме по совокупности и еще приврал".

Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, minorlogic, Вы писали:

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

M>> Т.е. описываемы вами "трюки" в редких случаях могут быть полезны,
М>согласен. в большинстве случаев они даже вредны и потому использовать трюки можно только в программах из нескольких строк, написанных на один раз.

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

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

Здравствуйте, Vzhyk, Вы писали:

V>19.07.2010 19:04, minorlogic пишет:
>>
>> V>Ну так заказчику (работодателю) нужен не шоколад в коде
>>
>> Какому заказчику ? Вы знакомы с заказчиками описанного кода ? Иогда
>> поделитесь что надо этому (этим) заказчикам. Их устраивает
>> непотдерживаемый, багонасыщенный код ?
V>А откуда ты знаешь, какой код у мыши?
V>Ну не шоколад у него в коде обильно политый майонезом. Но багов-то,
V>например, у него может быть на порядок меньше, чем в твоем шоколадном коде.

Может и динозавры еще не вымерли ? есть же шанс ... ? так о чем это ты ?

19.07.2010 19:12, мыщъх пишет:
>
> "я вам не завидую" (с). сейчас сам думаю как искать думающих людей. пока
> нет никаких идей, кроме того, что проверить опыт в определенной
> предметной области можно по задачкам типа этой: даны числа 78h, 3Сh,
> 18h, 20h, 10h. вопрос -- какое число лишнее. 30 секунд. и сразу видно
> какой у человека опыт -- реальный или просто "в общей сумме по
> совокупности и еще приврал".
Любое.
Подобные задачи или надо формулировать корректно или вообще не давать.

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

Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, Ikemefula, Вы писали:

I>>Здравствуйте, мыщъх, Вы писали:

I>> Так то оно так, но я ищу баланс между временем собеседования, шириной опроса и сложностью задачи.
М>"я вам не завидую" (с). сейчас сам думаю как искать думающих людей. пока нет никаких идей, кроме того, что проверить опыт в определенной предметной области можно по задачкам типа этой: даны числа 78h, 3Сh, 18h, 20h, 10h. вопрос -- какое число лишнее. 30 секунд. и сразу видно какой у человека опыт -- реальный или просто "в общей сумме по совокупности и еще приврал".

78h вроде лишнее, остальные похожи на прерывания и фунцыи дос ?

Здравствуйте, minorlogic, Вы писали:

M>Здравствуйте, мыщъх, Вы писали:

M> Не хочу показаться занудой (хоть я и зануда),
M> но лично на меня ОЧЕНЬ сильно подействовала методика
M> отдавать код на ревью коллегам.
к сожалению, на нашей фирме мой код смотрят всего лишь два человека и оба они работают с ним на высоком абстрактном уровне, т.е. на уровне API, который у меня получился запутанным в силу исторических причин. вот есть сложный движок, состоящий из трех независимых компонент. и есть к нему обертка командой строки. и для тестирования одной самой сложной компоненты так же есть обертка, причем весьма "разговорчивая", к которой для моих потребностей был прикручен дополнительный функционал, реализованный только там и не реализованный движком.

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

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

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

допустим, дана строка и нам нужно разбить ее на токены. допустим, у нас есть функция do_something(char *str, size_t len), которой мы передаем указатель на "world" в строке "hello, world". это _плохая_ функция, т.к. тут очень легко допустить выход за гранцы блока и незаметить.

а вот хорошая функция: do_something(char *str, size_t idx, size_t len), принимающая указатель на "hello, world", индекс "world" и длину всей строки. чем она хороша? а тем что в материнской функции нет нужды химичить в вычислениями длины остатка строки и проверять корректность указателя. переполнение буфера тут допустить практически невозможно, т.к. достаточно перед вызовом проверить что idx меньше len.

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


M> Несмотря на то , что мое детство прошло в Z80 машинных кодах (не ассемблере)
M> сейчас я могу считать код приемлемого качества , только если после ревью
M> ни у кого (из команды)не остается вопросов по коду.
у нас небольшая команда и потому мы не можем позволить себе дублировать работу друг друга. к тому же мы очень-очень слабо взаимодействуем. вот в частности сейчас. я написал код отдал коллеге. коллега спроектировал дизайн базы данных и архитектуру кластера. для него мой код это утилита командной строки и обсуждение идет в основном по схеме: "мыщъх, твою мать!!! а куда ты сохраняешь выходные файлы?!". я (скромно так, потупив взгляд), "в текущую директорию, сорри, но там перед файлами можно поставить префикс и в этот префискс можно засобачить любой путь -- как абсолютный, так и относительный". мне -- "ага, префикс работает. тогда живи пока, но сделай нормальный ключ для выбора директории"

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, мыщъх, Вы писали:

М>>Здравствуйте, Ikemefula, Вы писали:

I>>> Так то оно так, но я ищу баланс между временем собеседования, шириной опроса и сложностью задачи.
М>>"я вам не завидую" (с). сейчас сам думаю как искать думающих людей. пока нет никаких идей, кроме того, что проверить опыт в определенной предметной области можно по задачкам типа этой: даны числа 78h, 3Сh, 18h, 20h, 10h. вопрос -- какое число лишнее. 30 секунд. и сразу видно какой у человека опыт -- реальный или просто "в общей сумме по совокупности и еще приврал".

I>78h вроде лишнее, остальные похожи на прерывания и фунцыи дос ?
эээ нет. лишее 10. 3С — указатель на PE, дальше 78 — таблица экспорта. 18/20 — кол-во элементов в таблице имен и указатель на саму таблицу. при дизассемблировании файлов, работающих с другими файлами эти цифры постоянно мелькают перед глазами.

Времени нет отвечать быстро но краткое резюм по примеру.

ЗАЧЕМ писать свои парсеры а не использовать готовые? Насколько к=во аргументов и проверок может повлиять на скорость работы ? критично ли подобное изменение скорости работы ?

Здравствуйте, Vzhyk, Вы писали:

V>19.07.2010 19:12, мыщъх пишет:

V> Совет: ты просто побеседуй с человек и пусть он тебе рассказывает,
V> что он делал, как и почему. Самое важное, человек должен рассказывать
V> не то, что делала контора, а что ОН именно делал.
в том, что он расскажет, я не сомневаюсь. как проверить, что это не лажа? тестовые задания хотя бы на полчаса это уже не вариант. мне работать надо, а не собеседовать

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

Здравствуйте, minorlogic, Вы писали:

M>ЗАЧЕМ писать свои парсеры а не использовать готовые?
"а нэту" (с)

M> Насколько к=во аргументов и проверок может повлиять на скорость работы ?
смотря, где делать такие проверки. например, в функции выборки символов -- это уже критично, т.к. она вызывается очень часто, а дальше идет мультипаттерг матчинг, т.е. на нормальном трафике (а мы пишем анализаторы трафика), фактически просходит только одна выборка и тут уже есть разница между x = *src++ и x = fecth_char(,,,).

Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, minorlogic, Вы писали:

M>>ЗАЧЕМ писать свои парсеры а не использовать готовые?
М>"а нэту" (с)

Это странная ситуация.

1. Что нет парсеров готовых , подходящих для ваших задач.
2. Что нет парсера использующего внутри компании самописного, а вам приходится что то дописывать вручную находу придумывая велосипеды.

M>> Насколько к=во аргументов и проверок может повлиять на скорость работы ?
М>смотря, где делать такие проверки. например, в функции выборки символов -- это уже критично, т.к. она вызывается очень часто, а дальше идет мультипаттерг матчинг, т.е. на нормальном трафике (а мы пишем анализаторы трафика), фактически просходит только одна выборка и тут уже есть разница между x = *src++ и x = fecth_char(,,,).

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

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

Здравствуйте, minorlogic, Вы писали:

M>Здравствуйте, мыщъх, Вы писали:

M>>>ЗАЧЕМ писать свои парсеры а не использовать готовые?
М>>"а нэту" (с)
M>Это странная ситуация.
M>1. Что нет парсеров готовых , подходящих для ваших задач.
возможно и есть, но о них никто не знает, или знает, но мне не говорит, хотя я всех настойчиво пытаю. задачи -- простые. известные мне парсеры -- сложные.

вот пример задачи, найти следующую последовательность и если найдена, вернуть L1 и L2:

L1:
mov r1, esp
L2:
any_fpu_command
fstenv [r1][-0C]
pop r2

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

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

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

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

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

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

M> В моей команде, мы считаем провалом если приходится писать
M> что то самому и не используем готовые качественные решения.
использовать уже готовые решения это, конечно, хорошо, но я уже обжигался столько раз, что... последний раз пытался заюзать один из готовых парсеров pdf (по отзывам -- хороший). впечатления самые мрачные. сплошные налеты на камни с разбегу. то он не поддерживает esc-символы, ибо не подряжался, молчаливо (молчаливо!!!) перекладывая это на меня. то не хочет разжимать поток, возвращая сжатый контент без сообщений об ошибках. я уже молчу о том, что "%%%PDF-" он вообще за PDF не считает, т.к. ожидает магическое слово сначала файла, а adobe делает разбор с конца файла и PDF может быть и в середине. и уже совсем молчу, про то, что передо мной стояла задача работать даже с обрывками PDF или неправильно "сшитых" файлов, требущих совсем иного подхода в написании парсеров. ИМХО самому написать будет быстрее, чем разбираться с готовым, не говоря уже за то, что если у адобы есть переполнение буфера, то как мы может быть уверены, что его нет у сторонних разработчиков оперсоурсных парсеров pdf?

Здравствуйте, мыщъх, Вы писали:

I>>78h вроде лишнее, остальные похожи на прерывания и фунцыи дос ?
М>эээ нет. лишее 10. 3С — указатель на PE, дальше 78 — таблица экспорта. 18/20 — кол-во элементов в таблице имен и указатель на саму таблицу. при дизассемблировании файлов, работающих с другими файлами эти цифры постоянно мелькают перед глазами.

Жалко, а такая идейка была интересная — 18h — прерываение от таймера, 20h — прерывание дос завершить программу, 3Ch — функция дос создать файл, 10h — прерывание видеосервиса биос

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, мыщъх, Вы писали:

I>Жалко, а такая идейка была интересная — 18h — прерываение от таймера,
ну если хотите асма, то вот вам задачка, которую мне подникнули на собеседование японцы -- сравнить две ячейки памяти на x86 без использования регистров. пусть для определенности это будут [a] и [b]. если они равны, то взвести флаг нуля. в проивном случае очистит. на все про все у вас одна минута.

ЗЫ. без использования регистров это значит, что без использования.

Здравствуйте, мыщъх, Вы писали:

М>ну если хотите асма, то вот вам задачка, которую мне подникнули на собеседование японцы -- сравнить две ячейки памяти на x86 без использования регистров. пусть для определенности это будут [a] и [b]. если они равны, то взвести флаг нуля. в проивном случае очистит. на все про все у вас одна минута.

Сдаётся я и это задание провалил, но могу сделать это для процессора ввода-вывода К1810ВМ89 если откопаю книгу на балконе

Мне кажется надо чтото со стеком и регистром флагов нахимичить

Здравствуйте, мыщъх, Вы писали:

I>>Жалко, а такая идейка была интересная — 18h — прерываение от таймера,
М>ну если хотите асма, то вот вам задачка, которую мне подникнули на собеседование японцы -- сравнить две ячейки памяти на x86 без использования регистров. пусть для определенности это будут [a] и [b]. если они равны, то взвести флаг нуля. в проивном случае очистит. на все про все у вас одна минута.

М>ЗЫ. без использования регистров это значит, что без использования.

Почти без использования

fild a
ficomp b

Здравствуйте, Vzhyk, Вы писали:

V>16.07.2010 20:41, kosmik пишет:
>>
>> среди программистов, настроение "компания
>> мне должна это, это и вот это"
V>А это, это и это — это что?

Например: брать на работу без проверки, платить выше рынка, увеличивать зарплату соответственно произвольному индексу, выбранному сотрудником.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, мыщъх, Вы писали:

М>>ну если хотите асма, то вот вам задачка, которую мне подникнули на собеседование японцы -- сравнить две ячейки памяти на x86 без использования регистров. пусть для определенности это будут [a] и [b]. если они равны, то взвести флаг нуля. в проивном случае очистит. на все про все у вас одна минута.

I>Сдаётся я и это задание провалил,
Мой ответ был такой:
l1:
dec [b]
dec [a]
jnz l1
inc [b]
dec [b]

(это без сохранения самих значений для наглядности). суть в том, что мы мотаем цикл:
for(;)
{
b--;
a--;
if (a==0) break;
}

дальше, если b == 0, то inc [b]/dec [b] взведет флаг нуля. а b будет равно нулю только когда оно равно a.

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

I>Мне кажется надо чтото со стеком и регистром флагов нахимичить
со стеком только для сохранения регистров, да и то можно зающать переменную [c] и потом промотать цикл в обратную сторону. запрета на выдление доп. памяти не было. кстати, требования сохранять а и б -- тоже.

Здравствуйте, мыщъх, Вы писали:

I>>Сдаётся я и это задание провалил,
М>Мой ответ был такой:
М>l1:
М>dec [b]
М>dec [a]
М>jnz l1
М>inc [b]
М>dec [b]

Шота слишком просто Я куда то не туда смотрел.

Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, minorlogic, Вы писали:

M>>Здравствуйте, мыщъх, Вы писали:

M>>>>ЗАЧЕМ писать свои парсеры а не использовать готовые?
М>>>"а нэту" (с)
M>>Это странная ситуация.
M>>1. Что нет парсеров готовых , подходящих для ваших задач.
М>возможно и есть, но о них никто не знает, или знает, но мне не говорит, хотя я всех настойчиво пытаю. задачи -- простые. известные мне парсеры -- сложные.

М>вот пример задачи, найти следующую последовательность и если найдена, вернуть L1 и L2:

М>L1:
М>mov r1, esp
М>L2:
М>any_fpu_command
М>fstenv [r1][-0C]
М>pop r2

М>без использования стороннего кода у меня на си решение в лоб занимает 50 строк с пустыми строками и комментарями (причем, там еще учитывается, что команды могут быть разбавлены мусором).

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

М>вопрос: где найти парсер на котором это было бы короче 50 строк и который работал не хуже моего сишного кода, который при желании можно и оптимизировать.

Может проблема с требованиями ? откуда берется требование на размер парсера 50 строк? Если парсер сложный значит автоматом плохой? Почему же тогда существуют yacc и bizon. И в приведенной выше задаче сразу выделяются 2 подзадачи , максимально быстрый поиск по шаблону и анализ данных в контексте прикладной области.

Мое дело обратить внимание на то что бросается в глаза в первую очередь.

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


M>> В моей команде, мы считаем провалом если приходится писать
M>> что то самому и не используем готовые качественные решения.
М>использовать уже готовые решения это, конечно, хорошо, но я уже обжигался столько раз, что... последний раз пытался заюзать один из готовых парсеров pdf (по отзывам -- хороший). впечатления самые мрачные. сплошные налеты на камни с разбегу. то он не поддерживает esc-символы, ибо не подряжался, молчаливо (молчаливо!!!) перекладывая это на меня. то не хочет разжимать поток, возвращая сжатый контент без сообщений об ошибках. я уже молчу о том, что "%%%PDF-" он вообще за PDF не считает, т.к. ожидает магическое слово сначала файла, а adobe делает разбор с конца файла и PDF может быть и в середине. и уже совсем молчу, про то, что передо мной стояла задача работать даже с обрывками PDF или неправильно "сшитых" файлов, требущих совсем иного подхода в написании парсеров. ИМХО самому написать будет быстрее, чем разбираться с готовым, не говоря уже за то, что если у адобы есть переполнение буфера, то как мы может быть уверены, что его нет у сторонних разработчиков оперсоурсных парсеров pdf?

НЕ стоит смешивать типовые задачи и задачи в специфической области.

Задача поиска по шалону/шаблонам типовая, а анализ PDF может вообще никто и не делал полностью кроме adobe.