М>шутить изволите? я не в курсе студии и мне просто интересно -- там уже появилась интеграция с системами контроля версий?

Году, помнится, в 2000м, я еще из (5й? 6й? не помню) Студии делал checkout в системе контроля версий (ну и что что SourceSafe ). Не надо на студию набрасывать. В роли инструмента разработчика она — лучшее, что есть для С/С++.

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

KP>Относительно скоро буду менять работу. Куда резюме слать?
Обязательно укажи что можешь собрать C- файл мыщьха .

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

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

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

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

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

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

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


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

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

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

IO> зарплата 35000р меня не очень устраивает.

1. Не умеешь себя подать, продать.
2. Не указал полностью всех своих скилов — может действительно больше никто и не предложет.
3. Никого не слушай — встраиваемые системы — одна из самых высокооплачиваемых ниш, особенно когда дело касается дров. 120-180 тыр смело, если реальный спец. Правда вакансий не так уж и много, но если найти, будешь в шоколаде.

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

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

Это называется — бардак. У нас человек из разработчиков библиотеки даже ревьюит как она используется.

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

К чему тогда вопрос?

М>и я не в курсе как вообще вызывается мой код. может он вызывается неправильно или неоптимально.

Бардак, о чем я и писал выше.

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

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

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

Т>>Файл с расширением .С по умолчанию компилится как сишный, если явно не указано иначе в настройках.
М>если вы создали в студии новый си++ проект и скопипастили файл через буфер обмена, то мне интересно, что нужно указать в настройках, чтобы студия догадалось, что у него когда-то было .C расширение.

Compile As C Code /TC

Другое дело что там нету поддержки c99

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

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

Т>make файлы вместе со студией как правило используют редко ибо они кошмарно неудобны
Т>в сравнении со студийными проектами. Можно придумать конечно пару use case когда
Т>в make будет подправить проще чем в студии, но это будут частные случаи.
шутить изволите? я не в курсе студии и мне просто интересно -- там уже появилась интеграция с системами контроля версий? ну типа задал путь для чекаута -- оно скачало файлы, включило их в проект. если нет -- зачем вообще нужна студия?! как с ней работать-то?! если IDE от слова "интеграция", то это интеграция чего и чем?

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

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

не ко мне вопрос, но ) в студии, не помню с какой версии, но довольно давно, система интеграции с системами контроля версий сделана через плагины. Соответственно существуют плаги и для svn и для git (то что использовал) — бесплатно и опенсурсно. Они довольно удобные надо сказать.

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

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

Это демагогия:
1. Никто не отрицает, что код должен быть понятным, должна быть документация, примеры и т.д. (кстати вы уже писали, что документация есть не всегда, ваши библиотеки используют возможно не оптимально, отчего кстати? Код запутанный, документации нет?).
2. Вести свой бранч и есть бардак. Вот придут ко мне как разработчику и покажут баг, исправлю я его, а потом еще что-то допишу и улучшу, как это в вашу ветку попадет? А могли бы мне в крайнем случае патч прислать.

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

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

М>короче, есть ПЛАН и все ему следуют. только в детских сказаках задачи выполняются независимо. в реальности зависимость очень даже сильная и потому когда на меня падает незапланированная задача это означает либо, что мне придется овертаймить, либо передавать одну из своих задач наименее загруженному члену. вы с этим согласны?

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

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

Когда в компании бардак — безусловно.

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

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

MTD>>>>В большом проекте репозиториев несколько и право на изменение есть только у тех, кто данный код поддерживает.
М>вопрос почему вы считаете ситуацию когда у разных людей разные допуски бардаком?

Не приписывайте мне свои фантазии — разделение прав это замечательно.

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

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

М>считаем, что меня вообще нет. уволился или машина переехала. это что-то меняет?

Натурально бардак

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

До абсурда можно довести что угодно.

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

Ага, жизнь штука непростая, так зачем еще к этому и у себя бардак разводить?

AG>Возможно, ты не умеешь готовить. У меня все работало как часы на убунте и макоси.

Безо всяких "возможно" — мы пишем очень разный софт. Любое достаточно большое (не любительские тырканья, а коммерческая разработка) приложение проще писать и отлаживать именно в Студии. Причем я не одинок в этом подходе.
И сама IDE комфортнее. Хотя бы банально интерфейс лучше продуман.
Если бы не дебаггер, я бы вообще работал в студии, собирал gcc (благо, она это умеет).

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

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

AG>>>Это спорное утверждение. На Eclipse CDT можно прекрасно разрабатывать, при том интеграция лучше и кросс-платформа. На вкус и цвет...

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

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

дебаггер решает узкий класс задач. а логгер практически не имеет ограничений.

М>"дебаггер не нужен" (с). я _действительно_ не понимаю зачем он?

Научишься пользоваться, узнаешь.
Может, даже постигнешь высокое искусство дебажить (в основном в disasm) программы с -O3 и другими оптимизациями.

М>дебаггер решает узкий класс задач. а логгер практически не имеет ограничений.

У логгера есть только одна проблема — ту, что еще тов. Гейзенберг описал. Гугли принцип неопределенности: включая логирование, ты воздействуешь на процесс исполнения. Никогда не сталкивался с вариантом, когда с логами все работает, без — нет?

М>логи покрывают все баги отладчика, а отладчик покрывает возможности лога только частично

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

Короче говоря. Это два разных инструмента. Логи, это как посмертное вскрытие — можно констатировать, что пациент 16.09.2011 заболел триппером, вылечился 25.09.2011, а 14.03.2012 упал в канализационный люк и умер. Дебаггер и crash dump (при умелом использовании) тебе покажет видеосъемку, как пациент шел по улице, смотрел на грудь проходившей мимо женщины, не увидел открытый люк, и упал в него. Потом умер.

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

Так бы сразу и написал — дебаггера у тебя нет, поэтому тебе он не нужен

Логи, даже те, которые пишутся в эти самые mmap'ы, _ВСЕ_РАВНО_ меняют поток исполнения по сравнению с их отсутствием. Банально сбивают тайминги. Дебаггер полностью останавливает виртуальную машину (всю vmware'ю), и это, конечно же, crash dump analysis на ходу получается (т.к. со стоЯщими таймерами и убитыми таймаутами и вообще без времени, можно сказать).
В конце концов, дебаггер позволяет выловить 90% несложных багов намного быстрее, чем "вдумчивое чтение логов". Не говоря уже о том, что гигабайты логов читать (даже с супер-интеллигентными парсерами) ничуть не проще, чем тыкать step-in/step-out.

PS: да, я уже надрочился научился дебажить даже сетевые стеки, благо, MSL'и большие и эмуляция сервера с любыми таймаутами у меня тоже есть.

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

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

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

Работаю в Москве 3 года в НИИ, у нас своя встраиваемая ОС (ОС2000), по сути клон VxWorks, пишу под неё на C(не C++) по стандарту POSIX. Пробовал для интереса запустить свой сетевой драйвер принтера на Linux — заработал. В основном пишу драйвера(принтер, RS-232 на PCI, флэш через SPI, всякие там стороживые таймеры и т.д.), тесты оборудования. Знаю основы архитектуры MIPS и ассемблер под него(посмотреть там в регистре вектор прерывания, дизассемблировать прогу, чтобы узнать, на какой команде железка глюкнула и т.д.).
Знание Linux на уровне администратора(makefile там поправить, ядро пересобрать, скрипт написать и т.д.).

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

В связи с чем вопрос, куда можно податься в Москве программисту с такими навыками, что подучить?

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

IO>Работаю в Москве 3 года в НИИ, у нас своя встраиваемая ОС (ОС2000), по сути клон VxWorks, пишу под неё на C(не C++) по стандарту POSIX. Пробовал для интереса запустить свой сетевой драйвер принтера на Linux — заработал. В основном пишу драйвера(принтер, RS-232 на PCI, флэш через SPI, всякие там стороживые таймеры и т.д.), тесты оборудования. Знаю основы архитектуры MIPS и ассемблер под него(посмотреть там в регистре вектор прерывания, дизассемблировать прогу, чтобы узнать, на какой команде железка глюкнула и т.д.).
IO>Знание Linux на уровне администратора(makefile там поправить, ядро пересобрать, скрипт написать и т.д.).

IO>Всё бы ничего, работа нравится и начальник добрый, но вот зарплата 35000р меня не очень устраивает.

IO>В связи с чем вопрос, куда можно податься в Москве программисту с такими навыками, что подучить?

Я бы на твоем месте попробовал бы сходить в компанию Т-Платформы, или МЦСТ. Там с такими скилами можно нормальную зп получить. И Самсунг, Параллельс еще вроде есть, где твои скилы могут пригодиться.

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

IO>Работаю в Москве 3 года в НИИ, у нас своя встраиваемая ОС (ОС2000), по сути клон VxWorks, пишу под неё на C(не C++) по стандарту POSIX.
IO>Всё бы ничего, работа нравится и начальник добрый, но вот зарплата 35000р меня не очень устраивает.

На пару сайтов по вакансиям разместите ваши резюме (обычно hh мониторят).
В резюме сразу указывайте ожидание по ЗП от 90 тыр. (предложений только больше будет).
Вам позвонят в течение недели.

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

В дополнение к перечисленным Spirit вроде тоже в этой области работает

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

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

AVV>В дополнение к перечисленным Spirit вроде тоже в этой области работает

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

вот из свежего.
http://roem.ru/2012/06/07/addednews49266/

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

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

Кстати да- в 2007г такое видел (собеседовался у них). Хотя если исключить фюрера, спецы у них толковые и область около-железячная, т.е. интересная. Вообще из 3 виденных железячных контор в разных городах и странах, во всех повышенная протечка крыши у владельца и толковые спецы.

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

IO> пишу под неё на C(не C++) по стандарту POSIX. сетевой драйвер принтера на Linux - заработал.
IO> Знаю основы архитектуры MIPS и ассемблер под него(посмотреть там в регистре вектор прерывания,
IO> дизассемблировать прогу, чтобы узнать, на какой команде железка глюкнула и т.д.).
IO> Знание Linux на уровне администратора(makefile там поправить, ядро пересобрать, скрипт написать и т.д.).
IO>В связи с чем вопрос, куда можно податься в Москве программисту с такими навыками, что подучить?
выделенное нам _очень_ и _очень_ интересно. только мы не москва и даже не россия. вы как относитесь к миграции? человек, пишуший на C под MIPS код, который собирается make-файлом -- деньги гребет лопатой (лопата прилагается). код работает на Linux, но достаточно знания POSIX и командной строки.

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

IO>Работаю в Москве 3 года в НИИ, у нас своя встраиваемая ОС (ОС2000), по сути клон VxWorks, пишу под неё на C(не C++) по стандарту POSIX. Пробовал для интереса запустить свой сетевой драйвер принтера на Linux — заработал.
IO>В связи с чем вопрос, куда можно податься в Москве программисту с такими навыками, что подучить?

К сожалению сложилась такая ситуация, что программисты для встраиваемых систем получают ниже, чем остальные (те которые пишут просто на С++/С#/JAVA). Поэтому рекомендация простая — полная переквалификация.

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

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

IO>> пишу под неё на C(не C++) по стандарту POSIX. сетевой драйвер принтера на Linux - заработал.
IO>> Знаю основы архитектуры MIPS и ассемблер под него(посмотреть там в регистре вектор прерывания,
IO>> дизассемблировать прогу, чтобы узнать, на какой команде железка глюкнула и т.д.).
IO>> Знание Linux на уровне администратора(makefile там поправить, ядро пересобрать, скрипт написать и т.д.).
IO>>В связи с чем вопрос, куда можно податься в Москве программисту с такими навыками, что подучить?
М>выделенное нам _очень_ и _очень_ интересно. только мы не москва и даже не россия. вы как относитесь к миграции? человек, пишуший на C под MIPS код, который собирается make-файлом -- деньги гребет лопатой (лопата прилагается). код работает на Linux, но достаточно знания POSIX и командной строки.


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

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

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

IO>>Работаю в Москве 3 года в НИИ, у нас своя встраиваемая ОС (ОС2000), по сути клон VxWorks, пишу под неё на C(не C++) по стандарту POSIX. Пробовал для интереса запустить свой сетевой драйвер принтера на Linux — заработал.
IO>>В связи с чем вопрос, куда можно податься в Москве программисту с такими навыками, что подучить?

S>К сожалению сложилась такая ситуация, что программисты для встраиваемых систем получают ниже, чем остальные (те которые пишут просто на С++/С#/JAVA). Поэтому рекомендация простая — полная переквалификация.

А реально ли переквалифицироваться в программисты Linux и перспективно ли это? Я так понимаю мне придётся изучить C++(STL и Boost), функции ядра, научиться применять на практике ООП и шаблоны проектирования, достаточно ли этого?

Есть ещё начальные знания C#, Sql Server, ну тут мне предстоит изучить ещё кучу всего(знаний, чем отличаются ссылочные от вещественных типов и LEFT JOIN от RIGHT JOIN полагаю недостаточно ) и мой опыт с Linux пропадёт даром.

Ещё есть вариант стать web кодером. Основы mySQL знаю, ковыряться в Linux и настроивать Апач умею(поднимал Trac+SVN), html, php и JavaScript выучить дело нехитрое и можно пытаться устроится быдлокодером

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

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

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

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

IO>>>Работаю в Москве 3 года в НИИ, у нас своя встраиваемая ОС (ОС2000), по сути клон VxWorks, пишу под неё на C(не C++) по стандарту POSIX. Пробовал для интереса запустить свой сетевой драйвер принтера на Linux — заработал.
IO>>>В связи с чем вопрос, куда можно податься в Москве программисту с такими навыками, что подучить?

S>>К сожалению сложилась такая ситуация, что программисты для встраиваемых систем получают ниже, чем остальные (те которые пишут просто на С++/С#/JAVA). Поэтому рекомендация простая — полная переквалификация.

IO>А реально ли переквалифицироваться в программисты Linux и перспективно ли это? Я так понимаю мне придётся изучить C++(STL и Boost), функции ядра, научиться применять на практике ООП и шаблоны проектирования, достаточно ли этого?

IO>Есть ещё начальные знания C#, Sql Server, ну тут мне предстоит изучить ещё кучу всего(знаний, чем отличаются ссылочные от вещественных типов и LEFT JOIN от RIGHT JOIN полагаю недостаточно ) и мой опыт с Linux пропадёт даром.

IO>Ещё есть вариант стать web кодером. Основы mySQL знаю, ковыряться в Linux и настроивать Апач умею(поднимал Trac+SVN), html, php и JavaScript выучить дело нехитрое и можно пытаться устроится быдлокодером

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

Скажем так, двух-трехлетний тестировщик (особенно автоматизатор) в Москве находит на 100+ на руки работу легко (и не в банке).

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

Есть еще Аурига (но не ахти — по своему опыту). Так что с вашими данными работы до "пятой точки". Да еще с руками отхватят. Напиши потом куда устроишься

А за деньгами — топай в консультанты САПа и не парься (вернее парься но за достойные для Москвы деньги).

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

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

IO>> зарплата 35000р меня не очень устраивает.

J>1. Не умеешь себя подать, продать.
J>2. Не указал полностью всех своих скилов — может действительно больше никто и не предложет.
J>3. Никого не слушай — встраиваемые системы — одна из самых высокооплачиваемых ниш, особенно когда дело касается дров. 120-180 тыр смело, если реальный спец. Правда вакансий не так уж и много, но если найти, будешь в шоколаде.
верно

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

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

Очень реально. Не сомневайся.
В резюме сразу указывай от 90 тыр.!
На собеседовании говори, что получаешь на текущем месте 60..80 тыр. (белая + серая).
Тебе дело говорят про то, что с руками разбирают таких спецов (при наличии вакантного места).

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

м> IO> пишу под неё на C(не C++) по стандарту POSIX. сетевой драйвер принтера на Linux - заработал.
м> IO> Знаю основы архитектуры MIPS и ассемблер под него(посмотреть там в регистре вектор прерывания,
м> IO> дизассемблировать прогу, чтобы узнать, на какой команде железка глюкнула и т.д.).
м> IO> Знание Linux на уровне администратора(makefile там поправить, ядро пересобрать, скрипт написать и т.д.).
м> IO>В связи с чем вопрос, куда можно податься в Москве программисту с такими навыками, что подучить?

м> выделенное нам _очень_ и _очень_ интересно. только мы не москва и даже не россия. вы как относитесь к миграции? человек, пишуший на C под MIPS код, который собирается make-файлом -- деньги гребет лопатой (лопата прилагается). код работает на Linux, но достаточно знания POSIX и командной строки.

А что надо знать "специфичного" про архитектуру MIPS?

А то я программку портировал (на C и C++), все вроде пошло...

Про себя: Все то же самое, только ассемблер знаю послабже. И опыта поболее...

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

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

м>> выделенное нам _очень_ и _очень_ интересно. только мы не москва и даже не россия. вы как относитесь к миграции? человек, пишуший на C под MIPS код, который собирается make-файлом -- деньги гребет лопатой (лопата прилагается). код работает на Linux, но достаточно знания POSIX и командной строки.

A>А что надо знать "специфичного" про архитектуру MIPS?
как раз ничего "специфичного" знать не нужно, достаточно писать код на ANSI C в рамках POSIX, который работает везде, в том числе и на MIPS, а не только на машине разработчика (x86, x86-64), а проект собирается make-файлом и автоматом импортируется в любую нормальную IDE из системы контроля версий, благодаря чему я могу работать с ним FAR'е под MS VC, коллега в X-Code под Мак, а другой коллега в эклипсе.

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

A>А то я программку портировал (на C и C++), все вроде пошло...
у нас открыты вакансии на си. почему на си, а не на си++ -- объяснять долго. если есть интерес и желание мигрировать в штаты -- то можно обсудить детали.

J>2. Не указал полностью всех своих скилов — может действительно больше никто и не предложет.
J>3. Никого не слушай — встраиваемые системы — одна из самых высокооплачиваемых ниш, особенно когда дело касается дров. 120-180 тыр смело, если реальный спец. Правда вакансий не так уж и много, но если найти, будешь в шоколаде.

Да да, после СССР остались кучи железнячников, еще новых вырослсло и все со средней зарплатой в два раза ниже обычного кодера.
Не , наверное бывает 1 вакансия раз в пятилетку на нормальные деньги. Но блин 120 тр для С++ спеца получить гораздо проще.

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

М>как можно программировать если сборка проекта занимает неделю многопроцессорного времени и потому осуществляется раз в квартал.

Ну это не важно. Сборка всего проекта != сборка отдельного компонента.

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

м> у нас открыты вакансии на си. почему на си, а не на си++ -- объяснять долго. если есть интерес и желание мигрировать в штаты -- то можно обсудить детали.

А можно ссылочку на вакансию?

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

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

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

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

М>>как можно программировать если сборка проекта занимает неделю многопроцессорного времени и потому осуществляется раз в квартал.
MTD>Ну это не важно. Сборка всего проекта != сборка отдельного компонента.
разумеется, сборку отдельного компонента можно осуществлять хоть каждый день. только смысла в этом нету. "компилируется != работает". это менят стиль разработки. что-то покрывается юнит-тестами, где-то пишутся функции-заглушки для тестирования вашего кода, который взаимодействует с сетевыми сервисами по XML-RPC, только доступа к сервисам у вас нету.

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

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

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

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

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

Отлично.

М>только смысла в этом нету.

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

М>"компилируется != работает".

Кто бы мог подумать?

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

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

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

Это обычный процесс разработки, ничего особенного.

М>начитались "умных" книжек и решили, что рефракторинг -- это хорошо, а это на самом деле очень плохо.

Таки, да — хорошо, но разумно.

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

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

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


MTD> Есть. Отдельные компоненты взаимодействуют между собой по документированным протоколам,
не факт. были два компонента А и Б, которые писал Вася и которые взаимодействовали между собой неким образом, который Вася недокументировал, т.к. описывать подробности своей интимной жизни он не подряжался. затем А передали Алисе, а Б отдали Бобу, потому как Вася свалил и документировал только публичный интерфейс. тут бы самое время документировать механизм взаимодействия между А и Б коль скоро их отдали разным людям, но у Алисы с Бобом и без того хватает работы, т.к. им нужно разобраться в чужом коде и понять как он работает.

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

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

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


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

MTD>Это уже лирика. У каждой команды свой компонент, связи между компонентами задокументированы, все покрыто тестами. Другой команде в чужом коде делать нечего, пусть свой код бранчат.

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

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

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

М>только "официальная" билд система пишется отдельными людьми.

Всегда так было, в чем проблема?

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

Организационные проблемы

MTD>> Есть. Отдельные компоненты взаимодействуют между собой по документированным протоколам,
М>не факт.

Организационные проблемы

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

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

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

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

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

Да ладно — не все так страшно.

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

Это нормально, какие проблемы?

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

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

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

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

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

Это проблема и как раз организационная. Что делать варианта три (чем дальше, тем хуже):
1. Решать проблему организационную — ставить ответственных за код, заставлять их учитывать пожелания
2. Слать патчи
3. Делать обвязку над уже имеющимся кодом, расширяющую его возможности
4. Бранчить и вести свою ветку

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

Да, есть спрос, правда в Москве небольшой, сильно меньше например спроса на яву.

М>ЗЫ. вы все-таки идеалист.

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

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

IO>Всё бы ничего, работа нравится и начальник добрый, но вот зарплата 35000р меня не очень устраивает.

Есть готовность программировать микроконтроллеры (программирование на C, без ОС, либо со специализированной ОС)? Базовые познания в электронике (как работает транзистор)? Умеете
программировать на C, знаете как работает libc и т.п. --> присылайте резюме: job@prosc.ru

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

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

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

MTD> Ничего сложного нет — make, посмотрели чего не хватает,
да, и вообще что сложного в программировании? посмотрели чего не хватает...

MTD> собрали/дописали, повторили до победного
MTD> (это если сборка не сломана, но мы же про этот случай).
огромное кол-во людей не в состоянии откомпилировать си-файл, потому что создают си++ проект в студии. огромное кол-во людей даже не догадываются переключить студию в релиз. и еще большее кол-во людей не знают что такое компилятор, линкер, библиотекарь и если они пишут библиотеку, то помещают все функции в один файл, надеясь, что линкер оснащен AI и выдерет их оттуда самостоятельно. а сколько людей знают почему байтовые символы лучше хранить в char, а возвращать в int, а для индексов есть size_t?


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

MTD>Это проблема и как раз организационная. Что делать варианта три (чем дальше, тем хуже):
MTD>1. Решать проблему организационную — ставить ответственных за код, заставлять их учитывать пожелания
поймите же вы наконец, что взаимодействие между отделами не может быть строиться по схеме "нам нужно -- вы делайте", т.к. руководитель чужого отдела не обязан (да и не должен) удовлетворять чужие потребности за счет своих ресурсов. такое возможно только в очень маленьких компаниях, которые по сути и есть один отдел с одним бюджетом и единым ресурсом. с ростом компании возникает неизбежное разделение и потому в ответ на запрос "нам нужно" последует ответ "а что нам за это будет?" и это в идеальном случае. на практике скорее всего скажут, что у нас составлен план на год вперед и все. и менять его никто не будет, т.к. он уже утвержден. если план постоянно менять, то будет бардак. а если переписывать уже написанный код, это нерациональное использование ресурсов и потому единственным приемлимым решением, устаривающим обе стороны является -- вот вам код, делайте свой бранч, а мы со своей стороны сделаем все возможное, чтобы облегчить и вашу, и нашу жизнь, т.к. в вашем бранче могут оказаться фичи полезные для нас и мердж будет двухсторонним.

MTD>2. Слать патчи
куда слать? вы что? система контроля версий.

MTD>3. Делать обвязку над уже имеющимся кодом, расширяющую его возможности
зачастую это невозможно без вмешательства в код. рассмотрим такой пример. web-сервис распознает фотографии, которые возможно содеражат скрытую инфу и возвращает инфу в xml в виде "имя файла", "результат". допустим, он так же поддерживает архивы. допустим, вы итегрируете его в свою систему, где имя файла это курам на смех и вам нужно хотя бы md5. но жопа в том, что вы не поддерживаете архивы, а потому не можете... эээ... посчитать md5 файла из архива. что делать? бранчить. и добавлять к xml еще и md5 и ссылку на головной объект, который может быть архив в архиве в архиве.

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

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

М>у нас открыты вакансии на си. почему на си, а не на си++ -- объяснять долго. если есть интерес и желание мигрировать в штаты -- то можно обсудить детали.

Что за вакансии?
По какой визе ввозите народ?

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

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

М>>у нас открыты вакансии на си. почему на си, а не на си++ -- объяснять долго. если есть интерес и желание мигрировать в штаты -- то можно обсудить детали.
T>Что за вакансии? По какой визе ввозите народ?
вакансии -- сетевой софт под никсы на си. визы -- весь доступный спектр. конечно, предпочтение отдается аборигенам, но учитывая уровень российских программистов, решение может быть вынесено в пользу российского программиста, особенно если он старой школы и крепкой закалки. поскольу, кадровыми вопросами я не занимаюсь, то ассортимент моих услуг сводится к пересылке вашего cv моему непосредственному руководству. не слишком большая помощь, но ТС задал вопрос очень в тему. нам как раз нужны "программисты C под встраиваемые системы, UNIX", но ТС не рассматривает выездной вариант, автоматически закрывая вопрос, хотя вакансии все еще открыты... и по этой причине, вот по этой причине, нормальные люди съе... еще в обед, чтобы серфить по волнам до понедельника. меня звали. сказали, что дочь расстроится отказу. а мне что делать? а мне работать все выходные, хотя предложение о серфинге поступило непосредственно от руководства, типа мне нужен отдых. какой там отдых... я ту ночь не спал и эту не посплю. так что я очень даже заинтересован в новых людях, главное, чтобы они хорошими были, а то мне уже объяснили в этой ветке, что неправильно когда бранчат мой код без моего ведома. "правильно" по ихнему это когда по доброте душевной я выполняю все их фич реквесты, наплевав на текущие задачи. с такими я в разведку бы не пошел.

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

М>огромное кол-во людей не в состоянии откомпилировать си-файл, потому что создают си++ проект в студии.
Ты про какую студию говоришь?

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

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

М>>огромное кол-во людей не в состоянии откомпилировать си-файл, потому что создают си++ проект в студии.
Т>Ты про какую студию говоришь?
про ms. уже привык, что когда посылаешь людям си файл, то получаешь ответ: не работает. и даже не спрашивашь их что именно у них не работает, т.к. знаешь это заранее. создали новый си++ проект и скопипастили туда си программу. на фига они это сделали? а потому что по другому они не умеют. говоришь им cl file_name.c -- все равно не работает, т.к. переменные окружения не установлены.

Относительно скоро буду менять работу. Куда резюме слать?

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

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

Файл с расширением .С по умолчанию компилится как сишный, если явно не указано иначе в настройках.

М>создали новый си++ проект и скопипастили туда си программу.

Чтоб создать проект, в котором с файлы будут собираться как С++шные надо поковыряться ручками после создания проекта.
Если создать новый проект в MSVC и добавить в него .c файлы как есть, не меняя расширения — всё будет прекрасно.

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

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

М>а сколько людей знают почему байтовые символы лучше хранить в char, а возвращать в int
байтовые символы всё таки лучше хранить в unsigned char

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

KP>Относительно скоро буду менять работу. Куда резюме слать?
шлите на английском на gleet#novabsdm^com, с пометкой, что от питона, а я перешлю руководству, что человека знаю по форуму и знаю, что он неглупый. если будете в наших краях (NOVA), то с удовольствем приглашаю на чай.

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

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

Т>Файл с расширением .С по умолчанию компилится как сишный, если явно не указано иначе в настройках.
если вы создали в студии новый си++ проект и скопипастили файл через буфер обмена, то мне интересно, что нужно указать в настройках, чтобы студия догадалось, что у него когда-то было .C расширение.

М>>создали новый си++ проект и скопипастили туда си программу.
Т>Чтоб создать проект, в котором с файлы будут собираться как С++шные надо поковыряться ручками после создания проекта.
смотря как добавлять файл.

Т>Если создать новый проект в MSVC и добавить в него .c файлы как есть, не меняя расширения — всё будет прекрасно.
это мне объяснять не надо. это надо объяснять тем, кто имея make файл не знает, что с ним делать. я редко запускаю студию, но насколько помню, она позволяет открывать make файлы, написанные под нее.

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

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

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

М>>а сколько людей знают почему байтовые символы лучше хранить в char, а возвращать в int
Т>байтовые символы всё таки лучше хранить в unsigned char
к _хранению_ это не имеет никакого отношения. а вот обрабатывать их принято в int. во всяком случае стандартные сишные библиотеки поступают именно так. взять тот же fgetc(). он же возвращает char, но в int'е. ну или getchar().

если вы будете хранить в char, который может быть signed, то strcpy работать не перестанет даже если символы вылезут за первую половину таблицы. а обрабатывать в int'е их удобнее потому хотя бы потому что это быстрее, да и появляется возможность вернуть -1 как ошибку.

Ушло. Если не получил — дай знать.

P.S. NOVA — это где?

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

KP>Ушло. Если не получил — дай знать.
получил. впечатляет.

KP>P.S. NOVA — это где?
северная вирджиния, штаты. а вы где сейчас территориально?

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

KP>P.S. NOVA — это где?
заглянул к вам в блог. расстроился. вам большой город нужен, а у нас не город, а так — блок 2 x 2 квартала. население -- военные, научные сотрудники, много пенсионеров (военных), а потому очень тихо и бесшумно. иногда, впрочем, бывают разны выставки (например, искусства или фотографии) или приезжают никому неизвестые рок-группы, но редко.

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

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

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

Под мои хотелки, идеально (предположительно т.к. я так ни до одного из них и не доехал) подходят только Сингапур и Куала-Лумпур. А так, где-то одно в минус, где-то другое, приходится вопро рассматривать ооочень комплексно. Кстати, у вас там вроде Вашингтон не долече, что должно несколько скрашивать жизнь

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

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

IO>>Всё бы ничего, работа нравится и начальник добрый, но вот зарплата 35000р меня не очень устраивает.

fk0> Есть готовность программировать микроконтроллеры (программирование на C, без ОС, либо со специализированной ОС)? Базовые познания в электронике (как работает транзистор)? Умеете
fk0>программировать на C, знаете как работает libc и т.п. --> присылайте резюме: job@prosc.ru

Спасибо за предложение, насколько критичны знания электроники?

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

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

М>огромное кол-во людей не в состоянии откомпилировать си-файл, потому что создают си++ проект в студии. огромное кол-во людей даже не догадываются переключить студию в релиз. и еще большее кол-во людей не знают что такое компилятор, линкер, библиотекарь и если они пишут библиотеку, то помещают все функции в один файл, надеясь, что линкер оснащен AI и выдерет их оттуда самостоятельно. а сколько людей знают почему байтовые символы лучше хранить в char, а возвращать в int, а для индексов есть size_t?

Не принимайте на работу таких

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

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

MTD>>2. Слать патчи
М>куда слать? вы что? система контроля версий.

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

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

Ну да — парадокс.

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

KP>Под мои хотелки, идеально (предположительно т.к. я так ни до одного из них и не доехал) подходят только Сингапур и Куала-Лумпур.
Мой коллега получал докторскую степень в сингапуре. очень положительно отзывается о городе. а куала-лумпур напоминат мне малобюдетный американский фильм из серии "мир после атомного взрыва". впрочем, это только если в башнях работать. а если хотите красты, то за городом там у озера расположился филиал фирмы сайберг-секьюрити. туда вас определенно возьмут. и там довольно просторые кабинеты. еще есть клевая фирма F-Secure, которая тоже в KL, но там народ упакован в кубики, причем, мне там сразу отказали, т.к. "больно умный" и предложили или позицию в R&D в Хельсинках или до свидания. пришлось сказать до свидания, т.к. финляндия это не для меня, а в KL там в основном дешевая рабочая сила.

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

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

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

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

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

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

Речь о них идет?
А вообще, вернуться компанию специализирую именно на ИБ — это именно то что я больше всего бы хотел.

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

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

MTD>Не принимайте на работу таких
так и не принимаем.

MTD>Нет, это вы не понимаете, что между отделами могут существовать договорные отношения,
могут существовать, а могут и не существовать.

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

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

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

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

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

KP>Речь о них идет?
да, о них. впрочем, в том офисе я был в 2008 году. они могли и переехать...

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

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

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

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

Тогда передавай мое резюме, а так видно будет.

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

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

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

KP>Тогда передавай мое резюме, а так видно будет.

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

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

fk0>> Есть готовность программировать микроконтроллеры (программирование на C, без ОС, либо со специализированной ОС)? Базовые познания в электронике (как работает транзистор)? Умеете
fk0>>программировать на C, знаете как работает libc и т.п. --> присылайте резюме: job@prosc.ru

IO>Спасибо за предложение, насколько критичны знания электроники?

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

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

KP>Относительно скоро буду менять работу. Куда резюме слать?

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

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

Ясно, последний вопрос, вакансия открыта в Москве? А то в Питер переезжать не планирую

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

KP>>Относительно скоро буду менять работу. Куда резюме слать?
М>шлите на английском на gleet#novabsdm^com, с пометкой, что от питона, а я перешлю руководству, что человека знаю по форуму и знаю, что он неглупый. если будете в наших краях (NOVA), то с удовольствем приглашаю на чай.

Тыж раньше на симантек работал, не?

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

Т>>Файл с расширением .С по умолчанию компилится как сишный, если явно не указано иначе в настройках.
М>если вы создали в студии новый си++ проект и скопипастили файл через буфер обмена, то мне интересно, что нужно указать в настройках, чтобы студия догадалось, что у него когда-то было .C расширение.
/TC ну или просто файл переименовать обратно в .с

М>>>создали новый си++ проект и скопипастили туда си программу.
Т>>Чтоб создать проект, в котором с файлы будут собираться как С++шные надо поковыряться ручками после создания проекта.
М>смотря как добавлять файл.
Add -> Existing item
или
Add -> New item -> и набрать имя файла вместе с расширением .с

Т>>Если создать новый проект в MSVC и добавить в него .c файлы как есть, не меняя расширения — всё будет прекрасно.
М>это мне объяснять не надо. это надо объяснять тем, кто имея make файл не знает, что с ним делать. я редко запускаю студию, но насколько помню, она позволяет открывать make файлы, написанные под нее.
make файлы вместе со студией как правило используют редко ибо они кошмарно неудобны в сравнении со студийными проектами. Можно придумать конечно пару use case когда в make будет подправить проще чем в студии, но это будут частные случаи.

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

Т>>>Если создать новый проект в MSVC и добавить в него .c файлы как есть, не меняя расширения — всё будет прекрасно.
М>>это мне объяснять не надо. это надо объяснять тем, кто имея make файл не знает, что с ним делать. я редко запускаю студию, но насколько помню, она позволяет открывать make файлы, написанные под нее.
Т>make файлы вместе со студией как правило используют редко ибо они кошмарно неудобны в сравнении со студийными проектами. Можно придумать конечно пару use case когда в make будет подправить проще чем в студии, но это будут частные случаи.

к примеру интеграция msvc2010 с build из wdk посредством makefile project для компиляции драйверов много удобнее, чем правка проекта под них + централизованная сборка нескольких проектов под несколько ОС. Впрочем одно (makefile) не отменяет другого (проекты студии) в свете того же CMake.

Т>make файлы вместе со студией как правило используют редко ибо они кошмарно неудобны в сравнении со студийными проектами. Можно придумать конечно пару use case когда в make будет подправить проще чем в студии, но это будут частные случаи.

У кого-то это почти каждый случай ))) Собственно любая генерация кода и использование не только C/C++. Ленивый программер очень часто использует препроцессоры и генерацию кода. Студия с такими кейсами работает крайне криво. Ну и необходимость сборки на другой платформе или для другой таргет платформы добивает студию как билд систему. Остаются только компилер и редактор. От как редактор в комплекте с ассистом — студия вполне себе рулит. В большей степени конечно из за ассиста. Хотя конечно не везде и не всегда, и 2008-ая. Дальше опять просто какой-то эпический фейл.

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

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

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

MTD>Это называется — бардак. У нас человек из разработчиков библиотеки даже ревьюит как она используется.

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

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

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

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

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

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

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

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

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

I>к примеру интеграция msvc2010 с build из wdk посредством makefile project для компиляции драйверов много удобнее, чем правка проекта под них
Это проблема VC2010, они там зачем то vcproj так сломали что даже простой проект под 2010ю импортнуть она не всегда осиливает.
Мы 2010 и 2012 вообще решили пока пропустить, один фиг компилер у нас не МС используется.

Т>Это проблема VC2010, они там зачем то vcproj так сломали что даже простой проект под 2010ю импортнуть она не всегда осиливает.
Т>Мы 2010 и 2012 вообще решили пока пропустить, один фиг компилер у нас не МС используется.

ну нет, просто использование компилятора не из wdk не рекомендуется ms + там довольно много чего настраивать нужно в проекте (хотя только один раз и использовать в качестве шаблона), хоть 2010 хоть 2003 без разницы, но мне это показалось все равно излишне гемморно + теряется возможность компилировать без установки студии, чего многие хотят. Так что makefile project видится мне лучшим решением всё же.

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

Крис, посмотрите пожалуйста личку

KP>>Относительно скоро буду менять работу. Куда резюме слать?
М>шлите на английском на gleet#novabsdm^com, с пометкой, что от питона, а я перешлю руководству, что человека знаю по форуму и знаю, что он неглупый. если будете в наших краях (NOVA), то с удовольствем приглашаю на чай.

Это хорошо когда на постоянку и чумаданы собраны, а вот как фриланс хороший на С найти?

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

SD>... Не надо на студию набрасывать. В роли инструмента разработчика она — лучшее, что есть для С/С++.

Это спорное утверждение. На Eclipse CDT можно прекрасно разрабатывать, при том интеграция лучше и кросс-платформа. На вкус и цвет...

AG>Это спорное утверждение. На Eclipse CDT можно прекрасно разрабатывать, при том интеграция лучше и кросс-платформа. На вкус и цвет...

Я сейчас с этим г...оубожеством _вынужден_ работать на работе. Так вот, Eclipse CDT просто жесть кошмарная в сравнении со студией, особенно жестко глючащая при установке брейкпоинтов и выводе всяких там watches.

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

AG>>Это спорное утверждение. На Eclipse CDT можно прекрасно разрабатывать, при том интеграция лучше и кросс-платформа. На вкус и цвет...

SD>Я сейчас с этим г...оубожеством _вынужден_ работать на работе. Так вот, Eclipse CDT просто жесть кошмарная в сравнении со студией, особенно жестко глючащая при установке брейкпоинтов и выводе всяких там watches.

Возможно, ты не умеешь готовить. У меня все работало как часы на убунте и макоси.

Ты меня раскусил- исключительно наколенке пишу

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

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

Согласен. Правда мне за такое мнение здесь как-то минусов от души поставили

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

AG>>Возможно, ты не умеешь готовить. У меня все работало как часы на убунте и макоси.
М>поддерживаю. кстати, "дебаггер не нужен" (с). я _действительно_ не понимаю зачем он?
Это потому, что ты видимо так и не научился им пользоваться.
Это два сильно разных подхода. Логи и отладочный вывод хорош для отлова определённого круга багов, отладчик — для другого.
Там где хорош отладчик — никакая отладочная печать не поможет. Ибо её придётся воткнуть буквально после каждого выражения, причём каждый раз выводить огромное колво переменных, а то и областей памяти.
Ну и там где хороши логи — там отладчик слабо помогает.
Ну а пользоваться надо уметь всем спектром инструментария — сильно упрощает жизнь.

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

М>а логгер практически не имеет ограничений.
Имеет. Логи на каждый чих писать просто физически не получится.

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

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

AG>>>Возможно, ты не умеешь готовить. У меня все работало как часы на убунте и макоси.
М>>поддерживаю. кстати, "дебаггер не нужен" (с). я _действительно_ не понимаю зачем он?
Т>Это потому, что ты видимо так и не научился им пользоваться.
бинарные файлы отлаживаю всем чем угодно. от удаленной отладки через интерактивную иду, до PyDbg, который есть "собери себе отладчик из лого". кстати, в силу этого у меня стиль отладки довольно специфичный.

if (__DEBUG__) if (break_point_Nxx_enabled) if (условие) __asm{int 0x3}.

уже объяснял преимущество такого подхода. мне условия легче писать в большом окне редактора, а не в маленьком окне псевдоредактора бряков. второе -- мои бряки сохраняются в исходном файле и не зависят от IDE. от платформы они тоже не зависят, если __asm{int 0x3} это макрос. причем, они могут включаться не только путем перекомпиляции, но и правкой конфига.

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

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

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

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

М>>а логгер практически не имеет ограничений.
Т>Имеет. Логи на каждый чих писать просто физически не получится.
да ладно вам. вместо того чтобы давать на Step-in/Step-Over достаточно записать трассу в лог (это даже олька может) и визуализовать ее -- намного быстрее ошибки находятся, особенно если сравнивать поломанную трассу с той, что еще вчера работала. разумеется, сравнение идет на уровне блоков control flow. автоматически подсвечиваются различия. и там мы уже смотрим на значение переменных (регистров) и думает почему оно так.

_интерактивный_ отладчик полезен только для маленьких проектов, состоящих из одного файла (исполняемого). как только у нас появляется хотя бы база данных... ну и потом, если мы говорим не за кружок умелые руки, то промышленное программирование это RESTful, XML-RPC и куча других умных слов. даже если вы пишите калькулятор, задумайтесь -- его же по хорошему неплохо бы включить в Google Apps и вообще сделать web-версию, т.к. "обвязку" написать несложно. во всяком намного проще, чем парсить математические выражения и решать системы уравнений. ядро явно писать на си или плюсах. или на ди. или на хаскеле. но ни один из них не подходит для веба. и там будет или шарп или руби. или жаба. кстати, на вашей девелоперской машине вообще может не быть ни базы данных, ни веб-сервера. вы компилируете си в библиотеку, вызываемую из того же пиона, и делаете SSH на никсовый сервер. вопрос -- как вы будете это отлаживать? интерактивным отладчиком? или все-таки забьете на отладчик и возьмете в руки логгер.

усложним ситуацию. вы разрабатываете модуль для системы, к которой у вас нет доступа, а только спецификация взаимодействия. на вашей локальной машине ваш модуль на си работает и проходит все тесты, а вот в составе системы -- не пашет. отладчик говорите? а это и есть серьезное промышленное программирование. ну даже если вам дадут доступ по SSH. ну зайдете вы туда. а там такой бармалей. куча очередей, куча потоков и куча экземляров вашего модуля выполняется сразу. а если модуль задумается хотя бы на 15 сек -- поток прибивают лопатой. за этим следит отдельный сторож. так что даже подрубившись к своему модулю по gdb вы должны отлаживает его с реактивной скоростью, ибо увеличивать тайм-ауты вам не дадут. т.к. если мы задумаемся на 150 сек, то уже прибивается весь процесс и делает total reset с откатом.

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

SD>У логгера есть только одна проблема — ту, что еще тов. Гейзенберг описал. Гугли принцип неопределенности:
SD>включая логирование, ты воздействуешь на процесс исполнения. Никогда не сталкивался с вариантом,
SD>когда с логами все работает, без — нет?
по хорошему логгирование работает всегда в кольцевой буфер в зашаренной памяти, а оттуда его выгребают или не выгребают.

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

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

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

М>>логи покрывают все баги отладчика, а отладчик покрывает возможности лога только частично

SD>Короче говоря. Это два разных инструмента. Логи, это как посмертное вскрытие — можно констатировать, что пациент 16.09.2011 заболел триппером, вылечился 25.09.2011, а 14.03.2012 упал в канализационный люк и умер. Дебаггер и crash dump (при умелом использовании) тебе покажет видеосъемку, как пациент шел по улице, смотрел на грудь проходившей мимо женщины, не увидел открытый люк, и упал в него. Потом умер.

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

У отладчика есть один критический недостаток: лично в моем случае он доступен хорошо если в 10-20% случаев. А после того как привык оперировать логами, действительно приходишь к выводу о том, что тесты + логи покрывают 99% задач связанных с отладкой.

Я вообще-то писал, что отладчик в eclipse cdt вполне себе работает. И да, в моих условиях задержка на бряк приводила к разрыву соединения, и от того был лог в stderr и бряк в тяжелых случаях. Того кода C-го была тонкая прослойка между os api и java. Опять таки- жаба (python, scala, нужное подставить) в eclipse отлично отлаживается.
Imho любой интерактивный отладчик- это костыли, чтобы любой условный индус мог таки написать код, проблема только что не всегда отладка по брякам возможна. В особенности поразительно, как SkyDance умудряется по-живому отлаживать сетевой стек.

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

KP>У отладчика есть один критический недостаток: лично в моем случае он доступен хорошо если в 10-20% случаев.
как интересно. в моем случае тоже, т.к. приходится писать встраиваемые системы на никсах, причем доступа к самой системе у меня нет, т.к. нет допуска и потому на моей стороне возможности отладки ограничены (не говоря о том, что у меня нет набора реальных данных для тестов и данные приходится генерировать от балды). что там можно отладить? одна из ошибок была связана с утечкой памяти в результате ее фрагментации и это проявлялось только в реальной системе на полной загрузке и далеко не сразу, а когда последовательность запросов на выделение буферов была такой, что... ну в общем там сначала выделяется блок для быстрой проверки, а затем блок для дополнительной проверки. первый блок обычно освобождается быстрее, а второй блок -- большего размера. и все это в многопоточной системе. и проявляется только в определенных комбинациях размеров буферов, кол-ва потоков и кол-ва физических ядер.

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

так же на никсах активно используются очень разные языки. отдельные функи на си, а на питоне "клей", а различные компоненты сношаются через XML-RPC, который пишется на чем-то очень сильно высокоуровневом. на самом высоком уровне все крутится в четырех волшебных словах GET, POST, PUT, DELETE (get_obj, add_obj, update_obj, free_obj), а путь на низ небыстрый и через кучу слоев абстракции.

какой отладчик может с этим работать?

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

AG> В особенности поразительно, как SkyDance умудряется по-живому отлаживать сетевой стек.



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

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

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

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

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

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

SD>Порой ты вроде разумно пишешь.
Увы чем дальше тем реже. Всё больше про секас и нигеров.

SD>Мне логгер еще ни разу не позволил вернуть IP (который регистр, а не адрес) назад и _с текущими переменными_ еще раз выполнить по шагам вот эту функцию. Про принцип неопределенности я уже писал — включенное логирование изменяет поведение программы.
А ещё логгинг не даёт возможности в определённый момент по результатам анализа состояния пропустить кусок кода, поменять значение переменных, чтоб выполнение пошло иначе. И прочая и прочая.

SD>Короче говоря. Это два разных инструмента. Логи, это как посмертное вскрытие — можно констатировать, что пациент 16.09.2011 заболел триппером, вылечился 25.09.2011, а 14.03.2012 упал в канализационный люк и умер. Дебаггер и crash dump (при умелом использовании) тебе покажет видеосъемку, как пациент шел по улице, смотрел на грудь проходившей мимо женщины, не увидел открытый люк, и упал в него. Потом умер.
+100

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

KP>У отладчика есть один критический недостаток: лично в моем случае он доступен хорошо если в 10-20% случаев. А после того как привык оперировать логами, действительно приходишь к выводу о том, что тесты + логи покрывают 99% задач связанных с отладкой.
Ну, 99% это сильно завышено.
Зато логи + отладчик покрывают существенно больше.

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

SD>>У логгера есть только одна проблема — ту, что еще тов. Гейзенберг описал. Гугли принцип неопределенности:
SD>>включая логирование, ты воздействуешь на процесс исполнения. Никогда не сталкивался с вариантом,
SD>>когда с логами все работает, без — нет?
М>по хорошему логгирование работает всегда в кольцевой буфер в зашаренной памяти, а оттуда его выгребают или не выгребают.
Ага, плавали знаем. Чуть чуть быстрее говна посыпалось в лог и опа, не успели выгрести и теперь ценность лога стремится к нулю.

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

М>с вами все ясно.
Кто бы говорил, ага.

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

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

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

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

Т>Ну так и говори: отладчика в моих условиях нету.
Т>А то рассказываешь тут про вкус устриц тем, кто их ест постоянно.

Расскажи еще про устриц- ты меня заинтриговал.

KP>У отладчика есть один критический недостаток: лично в моем случае он доступен хорошо если в 10-20% случаев. А после того как привык оперировать логами, действительно приходишь к выводу о том, что тесты + логи покрывают 99% задач связанных с отладкой.

Удивлен, честно сказать. Что за проект? Поддержка чего-то большого и старого?
В моей практике, 90% багов — из-за невнимательности и copy-paste, и их по логам банально дольше искать.

Я хоть и согласен с постулатом "без дебаггера можно обойтись", но несложные баги (которых, опять же, всегда больше, чем сложных — прим. КО) с дебаггером найти проще, чем без.

Кстати, а что вы делаете, если есть только crash dump? Логи — сплошной mess видимо, расстреляли их память.

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

Т>>Ну так и говори: отладчика в моих условиях нету.
Т>>А то рассказываешь тут про вкус устриц тем, кто их ест постоянно.

AG>Расскажи еще про устриц- ты меня заинтриговал.
Вкусные.
Меньше чем medium size брать нет смысла.
Что тебе ещё рассказать?

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

IO>В связи с чем вопрос, куда можно податься в Москве программисту с такими навыками, что подучить?

Если Зеленоград не пугает, вакансия

Автор: Costik
Дата: 15.06.11

ещё актуальна.

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

.....

М>дайте пример, когда отладчик действительно полезен и незаменим.

1) есть у нас есть процесс, в процесс загружено 100500 плагинов, в том числе сторонних и наблюдается утечка памяти;
2) если нужен анализ дедлока, креша, всех тех случаев, когда у бага есть некое устойчивое состояние;
3) если нужен анализ деградации производительности системы — иногда это проще делать инструментами;
4) если бага в большом проекте, где пересобрать всю систему — 6-8 часов, а компонент не локализован, то его нужно локализовать, логов на все случаи жизни не напасешься;
5) добавим все случаи, когда есть система, с ней нужно работать, но нет спеки. бумс, что-то не работает. вбил бряку по условию или от безысходности if (...) __asm int3, вытащил из отладчика за 5 минут все, что дампил бы двое суток.
6) когда нужно бысто проверить предположение, не пересобирая все подряд;

еще?