Требуются специалисты по C++ и C#

[Poryadok]

Мы нанимаем С++ и С# разработчиков!

С++ - нужно пару человек, нужно знать программирование под Windows, желательно знать COM, иметь опыт программирования межпроцессного взаимодействия и работы с промышленным оборудованием.
C# - нужен специалист по semiconductor factory automation. Знание factory automation - большой плюс. Если не знаете, но хорошо знаете C# - тоже подойдёт, научим. Также нужно знать WinForms и WPF.

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

Фирма не делает новые H1B, но трансферит существующие
Фирма спонсирует relocation

Плюсы:
Интересная работа на самом передовом крае науки и технологий
Постоянная позиция, всякие разные бенефиты
Очень хороший доброжелательный коллектив и вменяемые менеждеры
Многонациональный коллектив без перекоса в сторону какой-нибудь одной народности
Прямо за дверью офиса начинается парк с прудами и гусями
Public компания (т.е. если вдруг бонус в стоках, то это - реальные деньги)
Если командировки, то не слишком часто и в Европу - у нас там филиалы (в основном в Чехию)
Это Орегон. Зимой нет снега (но есть снег в горах), летом не жарко и сухо, до океана полтора часа езды, до горнолыжных курортов - два. Красивая природа - горы, водопады. В реке Коламбия можно рыбачить на осетров (или на что-нибудь поменьше).
Низкая преступность. Доброжелательные люди.
Доступные цены на жильё (сравните с Калифорнией)
Очень много белых американцев и мало цветного населения (есть латиносы, но намного меньше, чем в Калифорнии)
Солнце не такое жгучее, как в более южных штатах (меньше возиться с кремом от загара)

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

Для справки - работа - в Хиллсборо, это пригород Портланда. Общее население Portland Metro - 2.3 миллиона человек - меньше, чем в Сиэттле, но больше, чем другие metro в северо-западном регионе.

Название компании - FEI.

Кому интересно - шлите резюме!

[DropAndDrag]

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

ИМХО, но FEI инструменты не блещут хорошим исполнением могу привести прикольные доводы
кстати, мне любопытно. а что хорошего в использовании COM интерфейса?

[Poryadok]

Поделитесь опытом:
- какой был микроскоп - TEM или SEM? У нас по миру несколько команд. Например, TEM команда сидит в Голландии и их "исполнение" с нашим связано очень слабо.
- что такое не "хорошее исполнение"? Надёжность или интерфейс?

В COM интерфейсе много напряга. Например, коллекшн писать - радости мало. Но - какая альтернатива для межпроцессного взаимодействия на industrial scale? Если писать hello world, то можно ручками RPC нарисовать, а если тысячи интерфейсов, миллионы строк кода, то непонятно чем COM под виндой заменить без переползания на C#.

[DropAndDrag]

знаю, что есть 4 штуки - старый еще Win2000 и 3 новых TEM (Technae) WinXP. может быть еще у кого-то есть. есть еще несколько приборов другого типа, может быть это и SEM
делюсь:
- стандартная комбинация TEM это компьютер с микроскопом и support компьютер. компьютер с микроскопом собирает гигабитные файлы, а пришел с 2 небольшими дисками. ну за лимон+ можно было бы потратить баксов 150 и поставить второй диск побольше - даже не о RAID пишу ))) а за 100+ тыс service contract на каждый (!) инструмент, наверное можно было бы и проапргейдить на 150 баксов?
почему-то support компьютер имел диски побольше и народ решил измеренные данные сразу запихивать туда через shared disk. облом-с. пишут ГБ, а находят какой-то ошметок. тогда продолжили писать на локальный диск, а потом копировать на support, но все равно копировались медленно и не всегда.
вот тут я как раз первый раз коснулся. выяснилось, что у компьютера с микроскопом 1Гб сетевая карта, а у support компьютера запихнули супер 100 Мб хаб! и наладчики, и наш IT support ходили кругами наверное пару лет ... пришлось исправить, да и вообще support компьютер отправить в отставку.
- я делал систему смешивать кучу различных газов для ETEM и ошивался рядом. выяснилось, что микроскоп не переваривает планового выключения. даже если просто сделать reboot компьютера каждый второй раз проблемы.
- полез в потроха. можно получить библиотеку, чтобы сделать свои методы, как измерения, так и обработки данных. есть кое-какие примеры (C++, JavaScript, HTML), но документация - практически нулевая. все, что мы хотели - это помахать пучком и измерять в каждой точке. выяснилось (это отдельная песня, так как доментация никакая) библиотеки заточены на 3 метода. единственный вариант - это новое положение пучка = новый эксперимент, а старт-стоп этого эксперимента занимают кучу времени. вообщем, то что нужно и можно сделать за доли секунды будет делаться часами! если это будет какой-то биологический sample, но яйца у него от электронного пучка отвалятся однозначно. и даже у небиологоческого будут необратимые изменения. чем думал архитектор - не ясно, но ясно, что надо отрывать за таки дела ну и вообще саппорт - это просто песня. кто-то с Германии дал библиотеку, в инете есть его презентации по библиотекам, но отвечать на вопросы не смог. поддержка из Хилсборо, тоже никакая. кто-то из другого места из штатов почему-то писал какие-то отрывки и в конце концов подтвердил, что да, так медленно и должно быть.
- чтобы махать пучком есть вариант подобраться через железо. в нашей конфигурации есть мультиплексор, которые переключается вручную (!) и позволяет управлять или FEI, или Gatan. но есть еще и 3-ий канал. попросили документацию интерфейса - не дали спрашивается, если уж прямым Gatan конкурентам-кооператорам дали, то что уж другим не дать?

по поводу COM.
мне кажется все можно затащить в один компьютер. в любой момент работает одна камера, остальное работающее оборудование технологическое и оно не должно быть прожорливым. если уж действительно надо distributed, то можете посмостреть CA у EPICS и подобных систем. кстати, OPC ушел с COM-DCOM хотя O у OPC - это OLE.

[Poryadok]

Это просто кошмар! Надеюсь, наши голландские коллеги, которые делали Текнаи, с тех пор исправились. А мы делаем sem для полупроводниковой промышленности. У нас все на win7 64 бита, и хард драйвов в некоторых микроскоп ПиСи аж 3 штуки, вот завтра уточню везде ли гигабитные сетевые карточки, но думаю, что везде. Система скриптинга у нас нынче драг-н-дроп мышкой, при этом очень мощная, и мы заказчиков ей обучаем.

[DropAndDrag]

вот и я о том же )))
реально мало компаний, которые конкретно отвечают за свой продукт. так же очень сложно и редко удается достучатся к знающему человеку, чтобы обсудить возможности.
очень часто компании не стараются сделать лучше продукт, чтобы была заинтересованность купить, а пытаются содрать бабла на тех саппорте. приезжающий саппорт с гордым именем инженеры - это отдельная песня. часто, люди не имеют элементарных понятий. пару раз доходило до совсем смешного. позовут, послушаешь бред "инженеров", посмотришь user документацию, на сам прибором, а потом разговариваешь с удаленной поддержкой стоящих рядом "инженеров" пытаясь найти какой кусок вырубился.
время уже пришло к 10 гб мы получили первый прибор, вернее 2 прибора внутрях которых по компу и соединены они с сервером на Linux. у сервера плата с 4 10 гб. очень надеюсь, что не hub
я создал тему про сбалансированный компьютер с 10 гб сетевой карточкой, но видимо народ не в теме.
небольшие изыски по инету показали, что просто так воспользоваться пока сложно. на Windows надо иметь SMB3, который есть у Window 8 (которой наша компания сказала - нет) и Windows Server 2012 (у компании нету volume license, но нашел для тестирования). У Linux (приборов мало на нем) тоже разработали multithread ftp или другой протокол, но только у последних Linux. Кажется Стендфорд разработал какую-то приблуду - bcopy (?). Может и для Windows что-то почти самопальное есть. Еще непонятки в Samba. Хоть сам файл-сервер может быть и быстрый, но прокачать через Samba - это вопрос.

Судя по отчету о Synergy file server у Windows 7 с SMB 2 тоже есть улучшение (непонятно приведенный графики то ли на 4, то ли на 2 клиента)
С Windows XP все значительно хуже, новые карточки не имеют драйверов. Но там и смысла нету копаться ...

[M. Ridcully]

Ааа, COM - как вспомню, так вздрогну! Free-threaded marshaling, apartment models & CComBSTR, windows registry and CLSIDs - never again!
Не найдёте вы никого.

PS: Колееге как-то (давно) кошмар приснился - оказался он в незнакомом месте, хочет у прохожих спросить, как домой пройти - а никто из них IUnknown не поддерживает!

[Poryadok]

Ужасность COMа сильно overrated
И не так сложно под него писать.
Особенно когда библиотеки уже на все случаи жизни отшлифованы - за ними ком-а уже почти и не видно.

[DropAndDrag]

я тоже с СОМ не очень разобрался. с одной стороны там старательно пытались все запутать, а с другой стороны никогда не было время спокойно разобраться. последний раз мучался с какие-то приколом, который в старом VB работал, а в C# нет. в итоге кажется написал dll на VB, а уже ее вызвал на C#, а может быть на C++. ну и понятно долго плевался )))

[Poryadok]

Ну, хорошо, я понимаю, C++ с КОМ-ом может кому-то не нравится. Но почему никто не заинтересовался C# позицией? Там КОМ знать не нужно, С++ - тоже, работа с роботами (factory automation). Причём низкоуровневое программирование роботов не нужно - оно делается другими людьми. Нужно просто следить, чтобы роботы дружили. Это же так здорово когда роботы дружат!

[DropAndDrag]

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

[Prosche]

Автоматизация это клево, помню в молодые годы автоматизировали водопровод, офигенно интересно было, работал за идею, денег платили, 300$ в месяц, как щас помню, но так круто было, когда ты нажимаешь кнопочку в своей апликухе, а за стеной включается громадный насос второго подьема, да так что весь дом начинает ходуном ходить. Помню смешно получилось с одним таким насосом, глав. инженер местный, вместо того чтобы протестить задвижку перед насосом, сказал чтобы я включил сам насос, я еще переспросил удивленно, точно насос? переклинило его чета, мы только все поставили, подрубили, шкафы там с релюшками, компы, еще ничего толком не тестили, как все подключено, SCADA (прога) наша сырая совсем была, да и по схеме я вижу, что задвижка перед насососом закрыта.... ну хозяин-барин, думаю, мож насос реально еще не подключен, реле щелкнет и все, я и включил.... как он орал, как он бежал ко мне с воплем "выключаааааай!!!" Повезло что мы все талантливо сделали и команда на отключение прошла, страшно подумать если бы перепутали что-то. Не помню, была ли там аварийная автоматика какая или нет. Очистные тоже интересно было автоматизировать, там богатое хозяйство, первичная очистка, аэротенки, метантенки, шнеки, фермы ползают... и в итоге всем этим управляла моя программа, полностью в автоматическом режиме, операторы только следили, чтобы все хорошо было. богом себя чувствовал хмм.... увлекся. извините. эт я так, тему апнуть

[mynameiszb]

Автоматика... Хе - а вы симулятор ядерного реактора гоняли в живую? Многоблочный? С отказами?.. Эх, песня, когда режимы кривые втыкаешь и у тебя активная зона в поддон стекает вместе с остатками системы ..

А потом это же самое - на вебе. Да с обучением студентов. Лепота...

А по топику - что-то меня слово Орегон смущает. Отмечу - не Потрланд, а именно "водопады, форель по вечерам и снега по шею 6 месяцев в году"

[oshibka_residenta]

Ну, хорошо, я понимаю, C++ с КОМ-ом может кому-то не нравится. Но почему никто не заинтересовался C# позицией? Там КОМ знать не нужно, С++ - тоже, работа с роботами (factory automation). Причём низкоуровневое программирование роботов не нужно - оно делается другими людьми. Нужно просто следить, чтобы роботы дружили. Это же так здорово когда роботы дружат!

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

[oshibka_residenta]

Ааа, COM - как вспомню, так вздрогну! Free-threaded marshaling, apartment models & CComBSTR, windows registry and CLSIDs - never again!
!

+100

[Archie]

Ааа, COM - как вспомню, так вздрогну! Free-threaded marshaling, apartment models & CComBSTR, windows registry and CLSIDs - never again!
!

+100

-100, нет там ничего ужасного, нужно уметь готовить. Не нравится CComBSTR, используйте другой или напишите свой)
По поводу интерфейсов действительно нет альтернативы, я в свое время сделал кодагенератор да и все

[mynameiszb]

Почитал аббревиатуры, напомнило:

Один мальчик выложил на GitHub в open source облачный распределенный BigData IoT SaaS мэшап с TDD, BDD, DDD, ATDD, STDD, DRY, CQRS, SPoF, EAFP, IoC, DI, DVCS, YAGNI, TMTOWTDI, convention over configuration, zero configuration, SEO, Scrum, microservices, Docker, Cassandra, Hadoop, Cucumber, responsive isomorphic Angular, machine learning, data mining, loose coupling, event sourcing, FRP и Kanban. Но без MongoDB. Потом его все равно в ад забрали, конечно...

[Poryadok]

Автоматика... Хе - а вы симулятор ядерного реактора гоняли в живую? Многоблочный? С отказами?.. Эх, песня, когда режимы кривые втыкаешь и у тебя активная зона в поддон стекает вместе с остатками системы ..

А потом это же самое - на вебе. Да с обучением студентов. Лепота...

А по топику - что-то меня слово Орегон смущает. Отмечу - не Потрланд, а именно "водопады, форель по вечерам и снега по шею 6 месяцев в году"

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

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

[oshibka_residenta]

Ааа, COM - как вспомню, так вздрогну! Free-threaded marshaling, apartment models & CComBSTR, windows registry and CLSIDs - never again!
!

+100

-100, нет там ничего ужасного, нужно уметь готовить.

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

[M. Ridcully]

-100, нет там ничего ужасного, нужно уметь готовить. Не нравится CComBSTR, используйте другой или напишите свой)
По поводу интерфейсов действительно нет альтернативы, я в свое время сделал кодагенератор да и все

Я тоже делал свой кодогенератор, который принимал на входе TypeLib - ну как директива #import, только более кастомизируемый. Вместо того, чтобы собственно логику писать.
Бывают сложности естественные - когда сама по себе проблема сложная - таких сложностей я не боюсь. А бывает, когда сложности на пустом месте человек сам себе придумывает - это COM.

[Poryadok]

Ааа, COM - как вспомню, так вздрогну! Free-threaded marshaling, apartment models & CComBSTR, windows registry and CLSIDs - never again!
!

+100

-100, нет там ничего ужасного, нужно уметь готовить.

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

Так Hello World без КОМ-а писать легче - никто не спорит. А вот когда несколько лет назад у нас на 32-битной ВинХП процесс перестал помещаться в память одного процесса (в том числе потому, что большие изображения много места занимают), разделить один процесс на два удалось простым переписывание конфигов (переводом части загружаемых модулей в другой процесс). Потому что всё модульное и всё через КОМ коннектится, и ему не важно - в том же процессе или в другом. (правда, у нас ещё КОМ немного кастомизированый). Если вы знаете какие-нибудь достойные альтернативы - поделитесь пожалуйста.

[olis]

А сервис или скажем драйвер вместо COM не лучше будет?

[DropAndDrag]

Так Hello World без КОМ-а писать легче - никто не спорит. А вот когда несколько лет назад у нас на 32-битной ВинХП процесс перестал помещаться в память одного процесса (в том числе потому, что большие изображения много места занимают), разделить один процесс на два удалось простым переписывание конфигов (переводом части загружаемых модулей в другой процесс). Потому что всё модульное и всё через КОМ коннектится, и ему не важно - в том же процессе или в другом. (правда, у нас ещё КОМ немного кастомизированый). Если вы знаете какие-нибудь достойные альтернативы - поделитесь пожалуйста.

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

Самому не приходилось использовать - не надо было. Правда пришлось разок использовать динамические dll для того, чтобы доказать наличие бага в EPICS. LabVIEW подгружает dll динамически и программа повисала на выходе. Для C/C++ разработчика пришлось написать в С/С++, чтобы стрелки не переводил.

[Poryadok]

Динамически загружать-выгружать dll-и? В системе с миллионами строк кода, которая работает неделями не выключаясь и управляет оборудованием на миллионы баксов? Серьёзно? А если dll загрузился, но не смог выделить себе памяти под переменные? Нужна обработка ошибок, ага. Только перелопатить миллоны строк кода чтобы везде-везде вставить железобетонную обработку ошибок - нетривиальная задача. А если значительная часть кода - от разных third-party - как говорится, good luck.

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

[DropAndDrag]

неделями ))) уехал, а через несколько лет мой коллега написал, что в конце-концов вырубился компьютер, который был мной установлен с программой на несколько датчиков. стали разбираться откуда данные приходили и вспомнили меня )))
если нужна надежность, то да, надо грузить все в самом начали и потом уже больше ничего не подгружать - как вы и пишите. правда в real-time OS сеть все равно будет брать-отдавать память - так что клиентов убить до 1! а Windows наверное много, что будет грызть память. Да и в конце концов - клиент может что-нибудь установить и сам
если у вас программа грузится в память, то тогда у вас нету с этим проблем. если проблема есть, то ставьте 2 уровня - один для оборудования, другой с UI. да, становится сложнее, но другого варианта нету.
это как бы в принципе ...
а с другой стороны LabVIEW грузит (ну точно грузило в году 2005) dll динамически. и ведь есть товарищи, кто черти че делает на ней. и достаточно надежно работает. вон NI пишет, что и NASA использует.
по поводу ошибок - блин, достает и иногда приходится делать (много систем однодневок). если уж делаю, то пишу в лог, где возникла ошибка, и все выкидываю наверх. если часть системы сдохла (скажем вырубилась одна камера, а есть еще другая(другие) ), то ее выключаю. если критичный элемент - то всю систему. система обработки ошибок становится простая
ИМХО. система или работает или нет. пример, с выделением памяти в 2 раза меньше памяти - по-моему практически не применим в автоматизации. советы - принимаются.