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

Например по моему опыту, коробочные это либо кросс-платформа C++, либо VC++; инвестиционные- юникс Java или C++; медицинские- unix Java + Windows C#.
А что по embedded?

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

AG>Интересует культура в таких компаниях, предпочитаемые инструменты/языки программирования, и в общем сравнение зп с компаниями других типов: коробочных, инвестиционных банков, производителей медицинского софта.

AG>Например по моему опыту, коробочные это либо кросс-платформа C++, либо VC++; инвестиционные- юникс Java или C++; медицинские- unix Java + Windows C#.
AG>А что по embedded?

C, реже С++, Embedded Linux (ucLinux), маленькие RTOS или вообще без операционки.
Зп имхо чуть ниже по рынку.

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

AK>C, реже С++, Embedded Linux (ucLinux), маленькие RTOS или вообще без операционки.
AK>Зп имхо чуть ниже по рынку.

Ниже- это насколько, и в каком городе? Как культура (дресс-код, формальности), общий интерес к работе? Какой обычный набор скиллов нужен разработчику? В случае мелких устройств наверно только C и ассемблер, но если есть обвязка, связь девайса с сервером- на чем сервер, на Java, Python или еще чем-то?

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

AG>Ниже- это насколько, и в каком городе? Как культура (дресс-код, формальности), общий интерес к работе? Какой обычный набор скиллов нужен разработчику? В случае мелких устройств наверно только C и ассемблер, но если есть обвязка, связь девайса с сервером- на чем сервер, на Java, Python или еще чем-то?
эмбеддед это железки, платы, компорты, провода, осциллографы, программаторы, асм, Си, монтажники, наладчики, суровые заказчики в Сибири — дресс-код и формальности отсутствуют как класс, ибо там нужно как правило уметь паять и держать отвертку. Зарплата ниже (пережитки НИИшной специфики) компенсируется интересностью, общением со множеством разных людей, халтурой и уважением гуманитариев)

добавлю что продвинутость фирмы можно оценить по используемым микроконтроллерам: любые 8-мибитные контроллеры говорят о "железной" направленности продутов, значит придется много возиться с разводкой плат, отладкой "в железе". 32-битные контроллеры (ARM etc) говорят о том что придется возиться с уже готовым железом и софт в них крутится сложнее, скорее всего придется полностью посвятить себя отладке софта на Си++)

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

AG>Интересует культура в таких компаниях, предпочитаемые инструменты/языки программирования, и в общем сравнение зп с компаниями других типов: коробочных, инвестиционных банков, производителей медицинского софта.

AG>Например по моему опыту, коробочные это либо кросс-платформа C++, либо VC++; инвестиционные- юникс Java или C++; медицинские- unix Java + Windows C#.
AG>А что по embedded?

В моем отделе разработка идет под Linux на C++, используем Boost, собираем CMake. Разработчиков ищу сильных, так как система сложная, из нескольких независимых модулей: обработка данных, архивирование, передача на верхний уровень и т.д., поддержка апдейтов на лету, разного железа. Кроме этого человек должен знать на базовом уровне электротехнику, читать несложные схемы, уметь пользоваться осцилографом, тестером, паяльником. Есть ребята которые программируют микроконтроллеры, так у них как правило все сводиться к "получил байт — послал байт", пишут они на С, программы довольно простые, умение программировать слабенькое, это даже скорее электронщики с опцией программирования. Обстановка как у меня на фотографии в профиле — куча железок кругом, проводов, все это глючит и горит периодически. Делаем мы комплексы мониторинга, чего не суть. Про зарплату не знаю — не сравнивал, на жизнь хватает, но тут все индивидуально.

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

AG>А что по embedded?

Типично есть плохого качества (ошибки в компиляторе которые приходится ловить и исключать самостоятельно) C-компилятор кое-как поддержививающий "ANSI-C", не более того. C++ может быть, а может нет, скорей нет. В комплекте компилятора есть неполноценная C-библиотека, некоторые функции приходится дописывать самостоятельно. Готовых библиотек зачастую нет или их использовать невозможно, за редкими исключениями. Но и те исключения чаще платные, а работодатель не стремится раскошелиться, украсть сложно
и чревато проблемами (из-за поддержки) -- проще не использовать. Да, компилятор, средства отладки и т.п. -- чаще всё ворованное
(ни разу не видел купленного). Покупается обычно самый дешёвый программатор, с которым отлаживать исключительно неудобно. Собственно отладчик часто сам "неотлаженный" и рассматривание дампа памяти с листигами компилятора (вместо того, чтоб это всё видеть в отладчике) -- нормальная практика. Соответственно разбираться на самом низком "уровне ассемблера" -- необходимо.
Другие языки программирования -- скорей нонсенс. Если мы говорим не о готовой "аппаратной платформе", а о программировании голого микроконтроллера или микропроцессора. ОС может быть, а может не быть, в зависимости от задачи. Если что не микропроцессор с очень большой внешней памятью, то никакой это не linux, а скорей специфическая ограниченная ОС, все функции которой заключаются в переключении между потоками и примитивах синхронизации.
В любом случае всё аппаратно-зависимое приходится писать самостоятельно -- от обработки исключений и прерываний процессора, частично модифицировать C-стартап, до собственно работы с железом. Последнее включает в себя в том числе практически всегда
внешние по отношению к микроконтроллеру или микропроцессору устройства, часто со сложными алгоритмами управления -- собственно ради них всё и затевается часто. В некоторых задачах может быть натуральный realtime, там брейкпоинт не поставишь и мышой по экрану не поелозишь, алгоритм частично можно "моделировать" на PC на тестовых данных, а потом переносить на железо.

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

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

AG>А что по embedded?

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

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

Речь об embedded.

AK>>Зп имхо чуть ниже по рынку.
AG>Ниже- это насколько, и в каком городе?

С Санкт-Петербурге. Процентов на 20 ниже.

AG> Как культура (дресс-код, формальности), общий интерес к работе?
AG> Какой обычный набор скиллов нужен разработчику?

Забыл ещё. В этой области "чистые программисты" существовать не могут. Надо всё же иногда и за осциллограф подержаться и понимать какие процессы там происходят. Разбираться кое-как в современной электронике и электронике вообще. BGA паять уметь не надо... Формальности -- вовремя на работу приходить заставляют.

AG> В случае мелких устройств наверно только C и ассемблер,

Не надо пренебрежительно относиться ни к C, ни к ассемблеру. Большинство "крутых программистов на C++" нормально программировать на C не умеют, это вообще то умение за которое стоит платить деньги. Ассемблер нужен не чтоб писать на нём, а скорей чтоб понимать что компилятор выдаёт, ну иногда 5 строчек написать. Ассемблер как язык программирования нужен для совсем мелких микроконтроллеров.

AG> но если есть обвязка, связь девайса с сервером- на чем сервер, на Java, Python или еще чем-то?

Да какая разница на чём. Что лучше подходит для задачи или что лучше знает тот, кто будет писать сервер. Хотя для тех задач, что возможен LOR-эффект -- я бы предпочёл не видеть там ни Java, ни Python. Скорей perl или голый C(++). Но боюсь, опять же, что и C++ уметь надо, и "большинство крутых C++ программистов" язык знают, а программировать нормально не умеют... Потом Java со своими серверами требующими гигабайт памяти плохо совместима с реальными условиями, где гигабайты стоят денег, если это не единственый сервер на столе у разработчика.

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

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

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

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

Разводкой плат приходится заниматься всегда отдельно взятому человеку.
А "отладкой в железе" придётся заниматься всегда и для 32-битных MCU всё только сложней будет.

O> 32-битные контроллеры (ARM etc) говорят о том что придется возиться с уже готовым железом и софт в них крутится сложнее, скорее всего придется полностью посвятить себя отладке софта на Си++)

И не факт, что там будет C++. Скорей "C с объектами". Об STL и boost лучше сразу забыть.

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

AG>>А что по embedded?
Ytz> Есть ребята которые программируют микроконтроллеры, так у них как правило все сводиться к "получил байт — послал байт", пишут они на С, программы довольно простые, умение программировать слабенькое, это даже скорее электронщики с опцией программирования.

Не совсем так, но очень близко к истине. На счёт "послал байт" -- мне нравится формулировка.

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

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

AG>>Ниже- это насколько, и в каком городе? Как культура (дресс-код, формальности), общий интерес к работе? Какой обычный набор скиллов нужен разработчику? В случае мелких устройств наверно только C и ассемблер, но если есть обвязка, связь девайса с сервером- на чем сервер, на Java, Python или еще чем-то?
O>эмбеддед это железки, платы, компорты, провода, осциллографы, программаторы, асм, Си, монтажники, наладчики, суровые заказчики в Сибири — дресс-код и формальности отсутствуют как класс, ибо там нужно как правило уметь паять и держать отвертку. Зарплата ниже (пережитки НИИшной специфики) компенсируется интересностью, общением со множеством разных людей, халтурой и уважением гуманитариев)

Железки и провода- это мне интересно. На самом деле в интересующей меня вакансии роль как раз подразумевает умение писать/читать C, C++, Java и Python, а сама компания не российская. Вот интересно, насколько отличается на западе зп в embedded от зп в инвест. банке? Я знаю, тут на форуме есть товарищи из заграниц.

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

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

fk0> И не факт, что там будет C++. Скорей "C с объектами". Об STL и boost лучше сразу забыть.

Всё зависти от возможности железяки и задач. Встречались проекты, где использовался и boost и STL.

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

AG>Интересует культура в таких компаниях, предпочитаемые инструменты/языки программирования, и в общем сравнение зп с компаниями других типов: коробочных, инвестиционных банков, производителей медицинского софта.

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

Общее, наверное, то, что в мире embedded нет общепринятого mainstream'ового подхода. Поэтому в соседних конторах к решению одной и той же задачи будут подходить совершенно по-разному.

И второе. Поскольку на embedded рынке меньше спрос и меньше предложение рабочей силы, то разброс в условиях будет заметно больше. Т.е., есть шанс как столкнуться с заметно лучшими предложениями, чем на "обычном" рынке, так и с заметно худшими.

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

AG>Интересует культура в таких компаниях, предпочитаемые инструменты/языки программирования, и в общем сравнение зп с компаниями других типов: коробочных, инвестиционных банков, производителей медицинского софта.

AG>Например по моему опыту, коробочные это либо кросс-платформа C++, либо VC++; инвестиционные- юникс Java или C++; медицинские- unix Java + Windows C#.
AG>А что по embedded?

Очень часто сидят низкоквалифицированные кодеры, активно надрачивающие на Plain C. В полной уверенности, что my_init(&my_struct, a); my_func(&my_struct, b); my_free(&my_struct); будет работать в стопицот раз быстрее, чем MyClass(a).func(b); Инновации не любят, ибо "а зачем разбираться, и так все работает". Но, возможно, не везде так...

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

П>Очень часто сидят низкоквалифицированные кодеры, активно надрачивающие на Plain C. В полной уверенности, что my_init(&my_struct, a); my_func(&my_struct, b); my_free(&my_struct); будет работать в стопицот раз быстрее, чем MyClass(a).func(b); Инновации не любят, ибо "а зачем разбираться, и так все работает". Но, возможно, не везде так...

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

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

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

П>>Очень часто сидят низкоквалифицированные кодеры, активно надрачивающие на Plain C. В полной уверенности, что my_init(&my_struct, a); my_func(&my_struct, b); my_free(&my_struct); будет работать в стопицот раз быстрее, чем MyClass(a).func(b); Инновации не любят, ибо "а зачем разбираться, и так все работает". Но, возможно, не везде так...

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

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

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

Осталось только доказать, что решение задачи с помощью классов однозначно является более простым, чем без них (ура! намечается холовар Си vs C++ )

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

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

А, и да, забыл спросить. Признаком какой квалификации является догматическое мышление?

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

fk0>> И не факт, что там будет C++. Скорей "C с объектами". Об STL и boost лучше сразу забыть.
AK>Всё зависти от возможности железяки и задач. Встречались проекты, где использовался и boost и STL.

Это когда под embedded понимается встраивание практически ibm-pc. Для однокристалльных решений -- скорей таки забыть.