А также если есть храниние, то есть и предварительная запись (колеса надо с хранения заранее заказать). Да и скорее всего ты — постоянный клиент.
В первую попавшуюся монтажку я только в экстренном случае поеду, а переобувка только в проверенном месте. Помнится перекинули мне колеса на дисках в Кунцево, покидали грязные колеса в багажник без пакетов, хотя зимние были в пакетах. Да и цена за снять/поставить была сильно завышена. Но это надо было срочно и как всегда «1 декабря внезапно пошел снег».
Проблема в головах клиентов. Если клиент хочет получить качественный сервис, он его найдет. Будет больше таких клиентов — будет меньше бомжомонтажей.
Можно по косвенным признакам. Т.е. я часто вижу, что тут может быть проблема, но иногда даем шанс (на то и нужен испытательный срок). Всё зависит от срочности и количества кандидатов.
Но, почему все останавливаются только на собеседовании? Можно позвонить на прошлые места работы и попросить характеристику на кандидата. В цивилизованных странах это всегда делают и это норма.
Код, отвечаюший за отрисовку картинок на дисплеях (PFD), для не очень большого самолета весил десятки мегабайт текстовых файлов. Но он по большей части был автоматически сгенерен из другой приблуды, где содержимое этих экранов дефайнилось (если очень приближенно) как формы в Delphi.
Кстати в авиации библиотеки редко используют. Они должны быть сертифицированы и поэтому стоят денег. Часто дешевле написать свои функции и сертифицировать как часть своего кода, чем покупать библиотеку целиком.
До боли знакомая картина :)
К счастью у нас для тестов была так круто разработана методика тестирования, что испортить её даже индусы не могли (хотя пытались, честно)))
Её мы применяли для всех новых и переделанных индусовских тестов.
Кстати в какой-то момент заказчик отдал кучу работы китайцам. Сначала было нормально, пока, видимо, самые умные китайцы стажировались в США. А вот когда они вернулись домой и стали учить своих коллег. Результат стал очень сильно похож на индусовский код. Сложно сказать — какой лучше, а какой хуже… он просто чуть другой :)
Цена за час — это просто объяснение, почему отдали в индию. Речь не об этом.
Речь о том, что люди, которые выползли из трущоб не могут мыслить широко и глубоко, иначе они бы не жили там десятилетиями. А те, кто могут, уверяю вас, уже давно там не живут и работают далеко не за 10, а может даже и не за 40 в час.
Качественно протестировать код тоже стоит денег и хороших инженеров. Кстати если брать метрики за строчки кода (да, такие встречаются), то протестировать строчку кода стоит примерно в 2 раза дороже (в часах), чем её написать.
Например у меня была история с одним самолетом. Было, казалось бы, пустяковое изменение — изменение частоты процесса в 2 раза. Это не подразумевало никаких других изменений в коде и тестах, а тесты стали падать (т.к. их требовалось просто перепрогнать). Весь модуль был давно написан и протестирован (угадайте с одной попытки — кем ;)). Но даже когда он попал к нам, специалисты уровня Middle не смогли даже подступиться к причине на первом этапе.
Чтобы не раздувать пост, скажу только что были требования, был код, написанный четко по этим требованиям, и тесты, которые, о боже, тоже написаны по требованиями. Проблема была в том, что требования были неоднозначны.
За полтора года за не сколько итераций удалось привести требования в нормальный вид, и тесты заодно. Почему так долго? Потому что вместо того чтобы плавно и аккуратно исправлять косяки на следующей итерации они выкатывают один CR за 2 дня до дедлайна, в котором «запилены» все непонятные_им_проблемы_в_виде_костылей. Инженер, который не принимал участие в тестировании этого модуля сразу упадет в обморок. Человек с опытом будет громко кричать что это всё г****но и надо переделать, но большинство его замечаний будет проигнорировано. Там по большому счету надо было пару месяцев плотной переписки, чтобы всё привести в порядок. А когда это 2 дня раз в 5 месяцев… ну сами понимаете.
А вот код не успели, потому что сертификация закончилась и времени и бюджета на исправление косяка в одну строчку уже не было, хотя первый раз я им ткнул на эту строчку за подлгода до дедлайна.
К чему это я…
А к тому, что даже очень опытный и дотошный тестировщик не имеет нормальных возможностей убедить разработчиков исправить косяк до того, как этот код начнет перевозить пассажиров. В тех реалиях, которые есть на данный момент.
Более 10 лет работал в разработке авиационного ПО. Уже года три не работаю, но очень отчетливо видна была тенденция к «забиванию» на важные моменты, как то обработка кривых данных с иточника (даже просто анализ того, что пришло по шине, не говоря о синхронизации с другой стороной).
Также была тенденция, что чем больше самолет, тем больше ошибок, и сами ошибки более критичные.
Самый большой самолет, к которому «приложил руку» был менее, чем на 200 мест. Можно только представить, что творится с более крупными.
А причина… перенос «производства ПО» в Индию и Китай. В самих же США на руководящие должности часто назначаются индусы. Да и сами американцы, что «лабали» ПО в штатах еще лет 10-15 назад, часто не отличались «умом и сообразительностью».
Раньше, в 1990-е вакансий на бортовое ПО было мало, и похоже что туда шли (или брали) реально толковых людей. Сейчас же, когда порог входа в IT достаточно низкий, рынок программистов большой, вот и берут кого попало с целью экономии. Согласитесь, что два Джуна в индии обходятся в 10-50 раз дешевле, чем один синьор в США. Да и где их столько взять то?
Так что такая вот тенденция, нехорошая… Проблема на самом деле очень системная.
Всё это, по моему мнению 5+ лет назад, должно было привести к системным катастрофам, и 737 Max тому наглядный пример. Если производители самолетов не сделают правильные выводы, то ситуация будет только ухудшаться.
Но намечалась и положительная тендеция в части ПО. Например есть много небольших производителей авионики, как то Honeywell, Rockwell-Collins, которые одновременно делали примерно одно и то же, как конкурирующие фирмы. Так вот тенденция была в объеднинении усилий вместо конкуренции. Конечный пользователь от этого должен выиграть, т.к. он получит либо более качественный продукт, либо более дешевый. Но тем не менее конкуренция должна оставаться.
И напоследок: экономию на разработке так или иначе задает рынок, т.е. потребитель. А именно — пассажиры. А именно, минимальная цена билета с каким-то допустимым риском для жизни.
Можно создать очень надежный самолет, можно поставить каждому пассажиру катапультируемое кресло с парашютом, можно много чего еще. Но и билет на такой самолет будет стоить в 2-5 раз дороже, чем на «обычный».
Задайте себе вопрос: готовы ли Вы лично платить за перелет такие деньги, вместо обычного? Ведь даже летя на обычном самолете вероятность катастрофы гораздо ниже, чем по дороге в аэропорт. Да и все эти парашюты не дают 100% гарантии, просто чуточку снижают вероятность летального исхода.
Живя рядом с большим аэропортом, около 20 лет на полосе было всего 2 аварии. При том что в час-пик там каждую минуту взлетают и садятся самолеты. А вот по дороге в этот аэропорт серьезные автомобильные аварии случалсь чуть ли не ежедневно.
Так что производители и FAA делают то, что должны, а именно снижают уровень риска до приемлемого. Если с 737 Мах будут в далее такие казусы, большую часть времени они будут проводить на земле в ожидании новой прошивки, и компании перестанут их покупать. Пассажиры тут вряд ли будут голосовать, т.к. «недовольных» вряд ли будет критическая масса. И они скорее будут выбирать более дорогие рейсы на более старых самолетах, что в целом на прибыли компаний вряд ли отразится.
Есть, например на мегафоне. Единственное ограничение — надо чтоб был хоть какой-то расход раз в 2-3 месяца, иначе начинают снимать плату за неиспользование номера (ежедневную и существенную).
Правда стоимость минут и особенно интернета там космическая, по сравнению с Украиной.
Работало у меня пару человек. С опытом от 3-х лет и вообще без опыта.
Так вот тот что вообще без опыта, работал на уровне senior.
А тот что с опытом… Лучше б его не было вообще. Когда он ушел, производительность команды удвоилась.
Есть как минимум один магазин в Москве, где наушников просто дофига и всё можно послушать.
Для себя остановился на модели за $50 (сейчас по рынку стоит). Кстати ей уже более 30 лет.
А также купил с eBay более старшую модель того же бренда в 2 раза дороже, так вот они звучат гораздо хуже, хоть и удобнее.
Эх, вспомнил молодость, как делал цифровой спидометр + тахометр на девятку. Тогда ж еще и ардуины не было — писалось все под PIC16F873 на ассемблере.
Скорость на 3-символьном 7-сегментном LED дисплее. Тахометр — линейная шкала (1 диод — 200 об/мин вроде бы)
Датчик скорости выдает 6 имп/1 метр. Рассчеты показали, что скорость в км/ч равна количеству импульсов за период 0.6 секунд. Кстати очень удачная частота для обновления скорости на цифровом дисплее.
А вот тахометр я сделал иначе — считал время (такты) между импульсами на входе. От чего он получился более «живой».
Однако проект не пошел под двум причинам:
1. Не успел я сотворить хороший конвертер 12-5в (ну не было зарядок для телефонов и прочих импульсных преобразователей в таком количестве, как сейчас)
2. Низкая яркость LED индикаторов — на солнце не видно + надо было как-то решать вопрос яркости ночью.
3. не успел сделать человеческое сохранение одометра в NVM.
Именно так.
Пока на этом выиграли производители продавцы видеокарт/чипов и их акционеры.
Майнеры же окупили свои расходы только те, кто строил фермы в марте-апреле.
Интересно, когда все эти фермы превратятся в тыкву? :)
Помимо покрытия по стркам (SC) и веткам (DC) есть еще полное покрытие условий в ветке (MC/DC).
Однако 100% покрытие кода говорит только о том, что команда тестировщиков добивалась 100% покрытия кода. О качесте тестирования это не говорит вообще:
1. Создание тестовых ситуаций не гарантирует что какие-либо выходые значения проверялись.
2. Если в функции есть две ветки которые тестировали независимо, то результаты их покрытия будет 100% (это покажет любой сборщик). Но при этом элементарно создать комбинацию, которая всё повалит.
int func(int a, int b)
{
int div = 1;
if (a) div = 0;
if (b) return (100/div);
return div;
}
Считали… стоимость (ресурсная) одного кВтч на аккумуляторе в разы выше дневного тарифа из розетки.
Если есть дохлый автомобильный аккум, который стартер уже не тянет, то можно его «припахать» беслатно, но не надо рассчитывать что он больше года проживет в таком режиме.
а теперь про то, какие существуют ИБП (DC-DC) и что они умеют.
Сначала про M*-ATX и их клоны. Они есть трех видов.
1. Uвх ровно 12в
2. Uвх от 14 до ~19в
3. Uвх от 8 до 19в (иногда от 6 до 32в — зависит от модификации)
Мощности у них от 80 до 250Вт.
ИБП есть простые (как pico-UPS) — напряжение либо от БП, либо от батареи (~12В).
Там нет ничего кроме контроллера заряда батареи, но они дешевые и имеют рабочий ток до 10А, чего достаточно для питания даже последних i7 без внешней видеокарты.
Есть OpenUPS(2). Там есть всё что нам надо (USB HID battery), поддержка почти любых аккумуляторов, регулируемый выход (позволяет применять БП типа 1), но меня смущают две вещи:
1. Ток 5А макс
2. цена больше $100
как ни крути, а i7 встает с натягом и то только при использовании 14-18в литиевой батери.
Так что этот пост возможно сподвигнет меня на разработку чего-то подобного, но помощнее (скажем под M4-ATX 250Вт). USB HID наверное на STM32 буду делать.
Кстати тут никто не сказал, но эти DC-DC — путь к абсолютно безшумному компу, так что есть к чему стремиться.
В свое время собрал сервак на железках от CarPC — работал изумительно.
А именно, Pico-UPS + M2-ATX (клон оригинального). И промышленный китайский импульсник на 18В 10А. Можно использовать зарядку от ноута на 16-18в.
На одном и том же аккумуляторе 7Ач время автономной работы отличалось в 3-4 раза, по сравнению с APC back-ups.
КПД такого ИБП + M*-ATX составляет более 80%. При питании от сети — примерно как у стандартного ATX блока птания
Вопрос контроля батареи решился тогда (в 2008-м) иным способом. На pic12 был собран простенький АЦП-проверка напряжения батареи. При падении ниже 12в — блоку питания давалась команда выключения (ACC off), тот в свою очередь нажимал кнопку power на материнке и ждал пока она уйдет в shutdown. Или через 2? минуты жестко рубил питание.
При повышении напряжение выше 14в на 2 минуты — врубаем штатно тем же способом.
В первую попавшуюся монтажку я только в экстренном случае поеду, а переобувка только в проверенном месте. Помнится перекинули мне колеса на дисках в Кунцево, покидали грязные колеса в багажник без пакетов, хотя зимние были в пакетах. Да и цена за снять/поставить была сильно завышена. Но это надо было срочно и как всегда «1 декабря внезапно пошел снег».
Проблема в головах клиентов. Если клиент хочет получить качественный сервис, он его найдет. Будет больше таких клиентов — будет меньше бомжомонтажей.
Но, почему все останавливаются только на собеседовании? Можно позвонить на прошлые места работы и попросить характеристику на кандидата. В цивилизованных странах это всегда делают и это норма.
И… как Ада поможет брать показания с разных датчиков? ;)
К счастью у нас для тестов была так круто разработана методика тестирования, что испортить её даже индусы не могли (хотя пытались, честно)))
Её мы применяли для всех новых и переделанных индусовских тестов.
Кстати в какой-то момент заказчик отдал кучу работы китайцам. Сначала было нормально, пока, видимо, самые умные китайцы стажировались в США. А вот когда они вернулись домой и стали учить своих коллег. Результат стал очень сильно похож на индусовский код. Сложно сказать — какой лучше, а какой хуже… он просто чуть другой :)
Речь о том, что люди, которые выползли из трущоб не могут мыслить широко и глубоко, иначе они бы не жили там десятилетиями. А те, кто могут, уверяю вас, уже давно там не живут и работают далеко не за 10, а может даже и не за 40 в час.
Качественно протестировать код тоже стоит денег и хороших инженеров. Кстати если брать метрики за строчки кода (да, такие встречаются), то протестировать строчку кода стоит примерно в 2 раза дороже (в часах), чем её написать.
Например у меня была история с одним самолетом. Было, казалось бы, пустяковое изменение — изменение частоты процесса в 2 раза. Это не подразумевало никаких других изменений в коде и тестах, а тесты стали падать (т.к. их требовалось просто перепрогнать). Весь модуль был давно написан и протестирован (угадайте с одной попытки — кем ;)). Но даже когда он попал к нам, специалисты уровня Middle не смогли даже подступиться к причине на первом этапе.
Чтобы не раздувать пост, скажу только что были требования, был код, написанный четко по этим требованиям, и тесты, которые, о боже, тоже написаны по требованиями. Проблема была в том, что требования были неоднозначны.
За полтора года за не сколько итераций удалось привести требования в нормальный вид, и тесты заодно. Почему так долго? Потому что вместо того чтобы плавно и аккуратно исправлять косяки на следующей итерации они выкатывают один CR за 2 дня до дедлайна, в котором «запилены» все непонятные_им_проблемы_в_виде_костылей. Инженер, который не принимал участие в тестировании этого модуля сразу упадет в обморок. Человек с опытом будет громко кричать что это всё г****но и надо переделать, но большинство его замечаний будет проигнорировано. Там по большому счету надо было пару месяцев плотной переписки, чтобы всё привести в порядок. А когда это 2 дня раз в 5 месяцев… ну сами понимаете.
А вот код не успели, потому что сертификация закончилась и времени и бюджета на исправление косяка в одну строчку уже не было, хотя первый раз я им ткнул на эту строчку за подлгода до дедлайна.
К чему это я…
А к тому, что даже очень опытный и дотошный тестировщик не имеет нормальных возможностей убедить разработчиков исправить косяк до того, как этот код начнет перевозить пассажиров. В тех реалиях, которые есть на данный момент.
Также была тенденция, что чем больше самолет, тем больше ошибок, и сами ошибки более критичные.
Самый большой самолет, к которому «приложил руку» был менее, чем на 200 мест. Можно только представить, что творится с более крупными.
А причина… перенос «производства ПО» в Индию и Китай. В самих же США на руководящие должности часто назначаются индусы. Да и сами американцы, что «лабали» ПО в штатах еще лет 10-15 назад, часто не отличались «умом и сообразительностью».
Раньше, в 1990-е вакансий на бортовое ПО было мало, и похоже что туда шли (или брали) реально толковых людей. Сейчас же, когда порог входа в IT достаточно низкий, рынок программистов большой, вот и берут кого попало с целью экономии. Согласитесь, что два Джуна в индии обходятся в 10-50 раз дешевле, чем один синьор в США. Да и где их столько взять то?
Так что такая вот тенденция, нехорошая… Проблема на самом деле очень системная.
Всё это, по моему мнению 5+ лет назад, должно было привести к системным катастрофам, и 737 Max тому наглядный пример. Если производители самолетов не сделают правильные выводы, то ситуация будет только ухудшаться.
Но намечалась и положительная тендеция в части ПО. Например есть много небольших производителей авионики, как то Honeywell, Rockwell-Collins, которые одновременно делали примерно одно и то же, как конкурирующие фирмы. Так вот тенденция была в объеднинении усилий вместо конкуренции. Конечный пользователь от этого должен выиграть, т.к. он получит либо более качественный продукт, либо более дешевый. Но тем не менее конкуренция должна оставаться.
И напоследок: экономию на разработке так или иначе задает рынок, т.е. потребитель. А именно — пассажиры. А именно, минимальная цена билета с каким-то допустимым риском для жизни.
Можно создать очень надежный самолет, можно поставить каждому пассажиру катапультируемое кресло с парашютом, можно много чего еще. Но и билет на такой самолет будет стоить в 2-5 раз дороже, чем на «обычный».
Задайте себе вопрос: готовы ли Вы лично платить за перелет такие деньги, вместо обычного? Ведь даже летя на обычном самолете вероятность катастрофы гораздо ниже, чем по дороге в аэропорт. Да и все эти парашюты не дают 100% гарантии, просто чуточку снижают вероятность летального исхода.
Живя рядом с большим аэропортом, около 20 лет на полосе было всего 2 аварии. При том что в час-пик там каждую минуту взлетают и садятся самолеты. А вот по дороге в этот аэропорт серьезные автомобильные аварии случалсь чуть ли не ежедневно.
Так что производители и FAA делают то, что должны, а именно снижают уровень риска до приемлемого. Если с 737 Мах будут в далее такие казусы, большую часть времени они будут проводить на земле в ожидании новой прошивки, и компании перестанут их покупать. Пассажиры тут вряд ли будут голосовать, т.к. «недовольных» вряд ли будет критическая масса. И они скорее будут выбирать более дорогие рейсы на более старых самолетах, что в целом на прибыли компаний вряд ли отразится.
Правда стоимость минут и особенно интернета там космическая, по сравнению с Украиной.
А толку, если мелкие преступления никто не расследует? Пока кто-то сам не признается.
Работало у меня пару человек. С опытом от 3-х лет и вообще без опыта.
Так вот тот что вообще без опыта, работал на уровне senior.
А тот что с опытом… Лучше б его не было вообще. Когда он ушел, производительность команды удвоилась.
Для себя остановился на модели за $50 (сейчас по рынку стоит). Кстати ей уже более 30 лет.
А также купил с eBay более старшую модель того же бренда в 2 раза дороже, так вот они звучат гораздо хуже, хоть и удобнее.
Скорость на 3-символьном 7-сегментном LED дисплее. Тахометр — линейная шкала (1 диод — 200 об/мин вроде бы)
Датчик скорости выдает 6 имп/1 метр. Рассчеты показали, что скорость в км/ч равна количеству импульсов за период 0.6 секунд. Кстати очень удачная частота для обновления скорости на цифровом дисплее.
А вот тахометр я сделал иначе — считал время (такты) между импульсами на входе. От чего он получился более «живой».
Однако проект не пошел под двум причинам:
1. Не успел я сотворить хороший конвертер 12-5в (ну не было зарядок для телефонов и прочих импульсных преобразователей в таком количестве, как сейчас)
2. Низкая яркость LED индикаторов — на солнце не видно + надо было как-то решать вопрос яркости ночью.
3. не успел сделать человеческое сохранение одометра в NVM.
Пока на этом выиграли производители продавцы видеокарт/чипов и их акционеры.
Майнеры же окупили свои расходы только те, кто строил фермы в марте-апреле.
Интересно, когда все эти фермы превратятся в тыкву? :)
40000+ — нет
140000 + нематериальные бонусы — да.
Однако 100% покрытие кода говорит только о том, что команда тестировщиков добивалась 100% покрытия кода. О качесте тестирования это не говорит вообще:
1. Создание тестовых ситуаций не гарантирует что какие-либо выходые значения проверялись.
2. Если в функции есть две ветки которые тестировали независимо, то результаты их покрытия будет 100% (это покажет любой сборщик). Но при этом элементарно создать комбинацию, которая всё повалит.
Если есть дохлый автомобильный аккум, который стартер уже не тянет, то можно его «припахать» беслатно, но не надо рассчитывать что он больше года проживет в таком режиме.
Естати на сутки работы их емкости обычно хватает.
Сначала про M*-ATX и их клоны. Они есть трех видов.
1. Uвх ровно 12в
2. Uвх от 14 до ~19в
3. Uвх от 8 до 19в (иногда от 6 до 32в — зависит от модификации)
Мощности у них от 80 до 250Вт.
ИБП есть простые (как pico-UPS) — напряжение либо от БП, либо от батареи (~12В).
Там нет ничего кроме контроллера заряда батареи, но они дешевые и имеют рабочий ток до 10А, чего достаточно для питания даже последних i7 без внешней видеокарты.
Есть OpenUPS(2). Там есть всё что нам надо (USB HID battery), поддержка почти любых аккумуляторов, регулируемый выход (позволяет применять БП типа 1), но меня смущают две вещи:
1. Ток 5А макс
2. цена больше $100
как ни крути, а i7 встает с натягом и то только при использовании 14-18в литиевой батери.
Так что этот пост возможно сподвигнет меня на разработку чего-то подобного, но помощнее (скажем под M4-ATX 250Вт). USB HID наверное на STM32 буду делать.
Кстати тут никто не сказал, но эти DC-DC — путь к абсолютно безшумному компу, так что есть к чему стремиться.
А именно, Pico-UPS + M2-ATX (клон оригинального). И промышленный китайский импульсник на 18В 10А. Можно использовать зарядку от ноута на 16-18в.
На одном и том же аккумуляторе 7Ач время автономной работы отличалось в 3-4 раза, по сравнению с APC back-ups.
КПД такого ИБП + M*-ATX составляет более 80%. При питании от сети — примерно как у стандартного ATX блока птания
Вопрос контроля батареи решился тогда (в 2008-м) иным способом. На pic12 был собран простенький АЦП-проверка напряжения батареи. При падении ниже 12в — блоку питания давалась команда выключения (ACC off), тот в свою очередь нажимал кнопку power на материнке и ждал пока она уйдет в shutdown. Или через 2? минуты жестко рубил питание.
При повышении напряжение выше 14в на 2 минуты — врубаем штатно тем же способом.