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

Ytz>Неееет! Мне так было важно твое одобрение! Что же делать?
выход один — попятчся

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

V>20.07.2011 17:32, мыщъх пишет:

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

V>А так, уверен, что понравится.
визу сделать не проблема. работы просто уйма по всем направлениям. я уже отчаялся найти реверсеров. сейчас ищу просто программистов на си. вот тут дали пару человек в подчинении из австралии. сказал им написать простой парсер pdf, который просто ищет n n obj << filters >> и извлекает фильтр(ы). попросил написать на ANSI C89. казалось бы что проще? даже написал как это писать (предложил заюзать FMS, чтобы не париться за возможные переполнения). работы на день-два. ну если учесть все риски и писать с нуля, то на неделю.

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

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

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

короче, нужны толковые разработчики, а нету... все уже разобраны...

Здравствуйте, мыщъх, Вы писали:
V>>А так, уверен, что понравится.
М>визу сделать не проблема. работы просто уйма по всем направлениям.
да я бы тоже поехал, только всегда задаюсь вопросом — а нафига компании, которая видит меня в первый раз, делать мне эту визу, если и без визы люди есть?

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

__>Здравствуйте, мыщъх, Вы писали:
V>>>А так, уверен, что понравится.
М>>визу сделать не проблема. работы просто уйма по всем направлениям.
__> да я бы тоже поехал, только всегда задаюсь вопросом — а нафига компании,
__> которая видит меня в первый раз, делать мне эту визу, если и без визы люди есть?
зависит от вашей квалификации... ну вот, например, есть такая задача. есть строка вида:
10 0 obj
<</Length 161153/Filter[/ASCIIHexDecode/FlateDecode]/Length1 65932>>

нужно найти num num obj << ... /Filter [ /f1 /f2 ... /fn] ... >>

дальше нужно вернуть массив типа int вида
{FILTER1_ID, FILTER2_ID , , , FILTERn_ID}

для данной строки массив будет выглядеть так: {ASCIIHexDecode_ID, FlateDecode_ID}.

ВОПРОС: за месяц-то уложитесь? и ваш код будет компилироваться только на вашей машине?

ВОПРОС НА ЗАСЫПКУ: хотя требований к скорости особых нет, смогли бы вы реализовать это быстро? и гарантировать, что вам не страшны переполнения буфера и что ваша программа внезапно не рухнет?

E>Интересно, можно ли у нас в России в настоящее время (2011 год) устроиться на работу, если уволили за прогулы?
E>Имеется ввиду на любую работу, не обязательно программистом?

На всё воля Б-жья.

Здравствуйте, мыщъх, Вы писали:
М>10 0 obj <</Length 161153/Filter[/ASCIIHexDecode/FlateDecode]/Length1 65932>>
М>нужно найти num num obj << ... /Filter [ /f1 /f2 ... /fn] ... >>
М>дальше нужно вернуть массив типа int вида
М>{FILTER1_ID, FILTER2_ID , , , FILTERn_ID}
одна строка? длинна? сотни байт, мегабайты, сотни мегабайт, гигабайты?

М>для данной строки массив будет выглядеть так: {ASCIIHexDecode_ID, FlateDecode_ID}.
эти константы по идее уже все известны на момент компиляции?

М>ВОПРОС: за месяц-то уложитесь? и ваш код будет компилироваться только на вашей машине?
да я это за вечер напишу если из условий задачи будет иметь смысл (тут нужно уточнить типичные данные — размеры и кол-ва), то еще +несколько дней и более быструю реализацию под видеокарту могу дать

М>ВОПРОС НА ЗАСЫПКУ: хотя требований к скорости особых нет, смогли бы вы реализовать это быстро? и гарантировать, что вам не страшны переполнения буфера и что ваша программа внезапно не рухнет?
конечно

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

__>Здравствуйте, мыщъх, Вы писали:
М>>10 0 obj <</Length 161153/Filter[/ASCIIHexDecode/FlateDecode]/Length1 65932>>
М>>нужно найти num num obj << ... /Filter [ /f1 /f2 ... /fn] ... >>
М>>дальше нужно вернуть массив типа int вида
М>>{FILTER1_ID, FILTER2_ID , , , FILTERn_ID}
__>одна строка? длинна? сотни байт, мегабайты, сотни мегабайт, гигабайты?
вообще-то, это pdf. размер самого pdf примем неограниченным. 'obj' всегда константа. кол-во фильтров в принципе не ограничено (и там может быть любой мусор), но поскольку имена фильтров известны заранее (и их около дюжины), то все остальное можно игнорировать.


М>>для данной строки массив будет выглядеть так: {ASCIIHexDecode_ID, FlateDecode_ID}.
__>эти константы по идее уже все известны на момент компиляции?
да, известны. для простоты можно возвращать массив указателей на строк с именами фильтров.


М>>ВОПРОС: за месяц-то уложитесь? и ваш код будет компилироваться только на вашей машине?
__>да я это за вечер напишу
дык горячие австралийские парни писали это больше недели вдвоем и еще какие-то библиотеки хотели использовать. а библиотеки... ну вы же понимаете... это лишние зависимости, лишнии проблемы на ровном месте, потенциально лишние баги.

__> если из условий задачи будет иметь смысл (тут нужно уточнить типичные данные — размеры и кол-ва),
__> то еще +несколько дней и более быструю реализацию под видеокарту могу дать
это вырожденный парсер pdf, который только декодирует все стримы, но полного разбора не осуществляет, т.к. одно из его применений -- разбор IP пакетов, а в IP весь pdf целиком не влезет, но нам он весь и не нужен. рабоать это будет в самых разных программных продуктах и на разном железе (включая такое, у которого видеокарт нет как класса, а только ком-порт).

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


М>>ВОПРОС НА ЗАСЫПКУ: хотя требований к скорости особых нет, смогли бы вы реализовать это быстро? и гарантировать, что вам не страшны переполнения буфера и что ваша программа внезапно не рухнет?
__>конечно
вот, а я тут глянул код, который мне прислали и вижу, что там подозрительно много буферов фиксированного размера. конечно, это не значит, что переполнение неизбежно, но... поточные алгоритмы и машины состояний они де-факто свободы от ошибок переполнения. если мы читаем только по одному символу за раз и храним только текущее состояние -- то переполняться там нечему, хотя, конечно, программировать сложнее.

это ваш ответ на вопрос -- почему не используют местных? вот, использовали. они прислали нерабочую программу под gcc, проигнорировав требование ANSI C89. вот это по вашему ANSI C89?

pdf.h:
struct pdf_state;
struct pdf_state *pdf_new(struct buffer *buf);


pdf.c:
struct pdf_state {
struct buffer *buf;
struct pdf_context context[CONTEXT_MAX];
int context_index;
enum token token;
size_t token_len;
};


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

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

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

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

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

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

Здравствуйте, мыщъх, Вы писали:
М>вот, а я тут глянул код, который мне прислали и вижу, что там подозрительно много буферов фиксированного размера. конечно, это не значит, что переполнение неизбежно, но... поточные алгоритмы и машины состояний они де-факто свободы от ошибок переполнения. если мы читаем только по одному символу за раз и храним только текущее состояние -- то переполняться там нечему, хотя, конечно, программировать сложнее.
упираемся в /filter[ и потом начинается уже соб-но сама работа —
по / или пробелу — добавляем в выходной массив идентификатор, если есть такой найденный (поиск не сломался и кол-во совпавших символов равно длине)
по / инициализируем поиск нового id
если там не / бинарным поиском по id делаем шажок в правильную сторону, пар-но помечая, сломался поиск или нет. если сломался то этот шаг пропускается.

ну да, буферы тут вообще не нужны, кроме выходного

М>это ваш ответ на вопрос -- почему не используют местных? вот, использовали. они прислали нерабочую программу под gcc, проигнорировав требование ANSI C89. вот это по вашему ANSI C89?
и где обычно ищут людей конторы американские? в моем представлении это либо те кто массово набирают, тут кроме Микрософта никого не знаю, либо нужно поработать в русском представительстве, а уже потооом... идут разговоры о переезде если ты сильно нужен оказался.

М>скажите -- вот на фига тут декларация структуры в .c файле, а в .h -- структура заюзана, но не декларирована? их мысль мне понятна. хотели вернуть что-то типа хэндла, с которыми работают только их функции, типа черный ящик. вот только зачем для этого ломать совместимость с другими компиляторами мне непонятно.
ну да, смысла нет. + я обычно typedef ами структуры обьявляю, чтобы struct везде не писать, хотя не знаю, входит это в c89 или нет

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

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

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

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

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

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

E>Интересно, можно ли у нас в России в настоящее время (2011 год) устроиться на работу, если уволили за прогулы?
E>Имеется ввиду на любую работу, не обязательно программистом?

По постам erslgoeirjh'а вся его жизнь прослеживается, как на ладони.

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

__>ну да, буферы тут вообще не нужны, кроме выходного
вот, вы все понимаете. вам даже алгоритм объяснять не нужно. в принципе, детали реализации обсуждаемы (можно вычислять хэш имени фильтра, а потом его матчить по lookup таблице, поскольку все фильтры известны заранее и их около дюжины, то хватит и байта, т.к. коллизии легко исключить, но это только один из вариантов и в принципе не самый лучший. будут переносить на питон (ну вдруг) и все поломают. тут переносили чек сумму с ELF на питон с си и конечно забыли, что в питоне a += x на самом деле нужно писать как a = (a + x) & 0xFFFFFFFF; что указывает на непонимание людей как вообще хэш работает).

М>>это ваш ответ на вопрос -- почему не используют местных? вот, использовали. они прислали нерабочую программу под gcc, проигнорировав требование ANSI C89. вот это по вашему ANSI C89?
__>и где обычно ищут людей конторы американские?
в том числе и на rsdn. два штатовских оффера я получил с openrce.org (откликнувшись на объявление о найме). openrce это такой специализированный формум тематический. и оба работодателя сделали визы. по одному из офферов работаю и сейчас.

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

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

> в моем представлении это либо те кто массово набирают,
> тут кроме Микрософта никого не знаю,
ms, google, oracle, intel... это из тех, кто набирает массово.

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

ИМХО самое главное быть напористым и всех пинать.

__> ну да, смысла нет. + я обычно typedef ами структуры обьявляю,
__> чтобы struct везде не писать, хотя не знаю, входит это в c89 или нет
конечно, входит.

Здравствуйте, мыщъх, Вы писали:
М>вот, вы все понимаете. вам даже алгоритм объяснять не нужно. в принципе, детали реализации обсуждаемы (можно вычислять хэш имени фильтра, а потом его матчить по lookup таблице, поскольку все фильтры известны заранее и их около дюжины, то хватит и байта, т.к. коллизии легко исключить, но это только один из вариантов и в принципе не самый лучший. будут переносить на питон (ну вдруг) и все поломают. тут переносили чек сумму с ELF на питон с си и конечно забыли, что в питоне a += x на самом деле нужно писать как a = (a + x) & 0xFFFFFFFF; что указывает на непонимание людей как вообще хэш работает).
да, с хешем еще ньюанс возникает что при добавлении новых слов есть вероятность, что коллизии возникнут, нужно будет хэш ф-ию править, этот вариант лучше годится когда их уже миллионы. а в текущем варианте оптимальнее всего будет небольшое деревце, но, да, его могут легко поломать при переносе

М>многие мои штатовские знакомые работают над собственными проектами в собственных фирмах и активно ищут людей. минусы маленьких фирм -- платить много будут только ведущим разработчикам. на остальных будут экономить, а работать заставят много. плюсы -- скорее всего выделят офис, а не кубик. и скорее всего не будут обращать внимание на subj. в смысле можно работать из дому, когда лень тащиться в офис.
и визы тоже делают? ну, ежели так и будут искать народ со значком ГТО на груди у него, то можете передать мою почту — из профиля, вышлю резюме и могу тестовое задание сделать

>> в моем представлении это либо те кто массово набирают,
>> тут кроме Микрософта никого не знаю,
М>ms, google, oracle, intel... это из тех, кто набирает массово.
че-то на rsdn только про Микрософт и пишут, вон, про Зинку еще недавно. Про другие наборы вообще не слышно.

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

М>вообще-то, это pdf. размер самого pdf примем неограниченным. 'obj' всегда константа. кол-во фильтров в принципе не ограничено (и там может быть любой мусор), но поскольку имена фильтров известны заранее (и их около дюжины), то все остальное можно игнорировать.

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

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

Нет. Требование вполне ясное. Чисто для интереса -- а почему не C99?

E>Интересно, можно ли у нас в России в настоящее время (2011 год) устроиться на работу, если уволили за прогулы?

А что договорится по собственному не получилось?

20.07.2011 20:30, мыщъх пишет:

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

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

З.Ы. Хотя, ты достаточно своеобразен и твой код мы здесь не раз видели
(не назвал бы я его приличным) поэтому тебе придется искать человека,
который будет писать в твоем стиле.

21.07.2011 5:49, мыщъх пишет:

> зависит от вашей квалификации... ну вот, например, есть такая задача.
> есть строка вида:
> 10 0 obj
> <</Length 161153/Filter[/ASCIIHexDecode/FlateDecode]/Length1 65932>>
>
> нужно найти num num obj << ... /Filter [ /f1 /f2 ... /fn] ... >>
>
> дальше нужно вернуть массив типа int вида
> {FILTER1_ID, FILTER2_ID , , , FILTERn_ID}
>
> для данной строки массив будет выглядеть так: {ASCIIHexDecode_ID,
> FlateDecode_ID}.
А чем регекспы не подходят (perl, python, c-шные библиотеки)? Почему
обязательно ручками солнце закатывать?

21.07.2011 6:58, мыщъх пишет:

> но вообще-то под "быстро" я имел ввиду далеко не реактивную скорость.
> если не сказать "быстро" заюзают регулярки. а регулярки это тормоза,
> хотя на них такое пишется за час.
А вот мы видим пример типичного горячего русского парня, который из
постановки задачи дает 10%, а потом у него еще полгода всплывает море
уточняющих моментов.

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

V>А чем регекспы не подходят (perl, python, c-шные библиотеки)? Почему
V>обязательно ручками солнце закатывать?

Думаю, потому что будет медленно по сравнению с конечным автоматом, написанным вручную.

21.07.2011 11:39, mik1 пишет:

> V>А чем регекспы не подходят (perl, python, c-шные библиотеки)? Почему
> V>обязательно ручками солнце закатывать?
>
> Думаю, потому что будет медленно по сравнению с конечным автоматом,
> написанным вручную.
Проверяли? Просто я не специалист в массовой обработки текстов, посему
даже интересно.

З.Ы. Ну а высказывание в стиле "я уверен, что будет медленнее",
напоминает аналогичные высказывания про matlab и С, только вот в реале
чаще наоборот (matlab обгоняет C). Ну и еще учитывая время на разработку...