Попробуйте убрать sleep — она в любом случае, даже с аргументом 0, вызывает планировщик задач (и, соответсвенно, отдачу слайсов другим процессам). Равно как и WaitSingleObject/WaitMultipleObjects даже в случае когда там указан нулевой таймаут.
Сделайте просто пустой бесконечный цикл
for(;;);
и посмотрите как он повлияет на производительность всей системы.
Банковский софт должен быть
а) Надежным
б) Еще раз надежным
в) И еще раз надежным.
Т.е. превыше всего надежность. Если тот софт, что пишется внутри банка собственными силами и/или вендорами можно оттестировать на надежность (а тестирование там проводится специально обученными людьми и не в один этап — компонентное, интеграционное, бизнес, нагрузочное...) то надежность платформы на которой все это крутится должна обеспечиваться ее производителем.
И данная платформа (IBM i) достаточно надежна ибо разрабатывалась не под бытовые нужды, а для высокопроизводительных коммерческих серверов.
Что касается собственно АБС (автоматизированной банковской системы). Данная АБС есть система реального времени. Т.е. пользовательские операции тут совершаются не «с 4-х утра до полуночи», а круглосуточно. Даже при том, что сведение баланса (ежемесячный кошмар бухгалтера) в банке происходит ежедневно.
Чего стоит это реальное время для системы… Об этом лучше не говорить ибо в двух словах не описать :-)
Ну и на самом деле бизнес-логика на особенности ОС никак не завязана. Завязана ее конкретная реализация. И не столько на особенности ОС, сколько на особенности используемой банков АБС. А та или иная АБС используется любым банком ибо написать все с нуля своими силами нереально. И ни о каком порте тут речи быть не может.
Ну а что касается темы статьи — тут речь идет не о бизнес-логике, а о том самом тестировании. Без которого ни одна поставка не уйдет в бой. И о посильной автоматизации этого тестирования. Ибо куда проще и спокойнее дорабатывать поставку с тестов, чем бросать все и кидаться срочно затыкать дефект боя (когда некорректная работа обнаруживается уже в промышленной эксплуатации и сказывается на клиентах, вызывая их негативную реакцию и ущерб репутации банка).
Строго говоря, таймеры в планировщике задач используются в любой системе с вытесняющей многозадачностью и не являются исключительным атрибутом RTOS. Без этого любая зависшая (зациклившаяся) задача наглухо вешала бы всю систему.
На практике же, при грамотном распределении приоритетов, все это незаметно для пользователя.
Основной особенностью RTOS является гарантированно быстрая реакция на внешние события (приоритет событий). Вот это уже заметно — когда отклик на тачскрин наступает сразу, а не с задержкой (потому что у системы в этот момент, видите ли, более важные дела есть).
Другое дело — кому все это нужно? Проше вынудить пользователя купить новый девайс помощнее да подороже. Да и все равно ничего серьезного он там делать не будет. Трепаться по мессенждеру, лайкать таких же как он полудурков в мордокниге да постить фоточки «а вот я кушаю, а вот я какаю» в инстаграмм.
Насчет низкой производительности — с чего бы это? При грамотном проектировании не замечал такого.
Впервые столкнулся с кьюниксом (по-моему, это еще не нейтрино было) во второй половине 90-х на октагоновских микрописьках. Позже был небольшой опыт с vxWorks (тоже на промконтролерах). Не было проблем с производительностью.
Сам все еще пользуюсь Blackberry Z30 на BBOS 10.3.3 При слабеньком по нынешним меркам железе (снапдрагон S4 2х1.7 и 2Гб памяти) работает очень шустро в рамках поставленных перед ним задач — это в первую очередь бизнес-девайс, т.е. почта (причем легко и просто интегрируется с Microsoft Active Sync, IBM Lotus Notes Traveler — тут вообще не надо ставить, как на андроиде, дико жрущий батарею IBM Verse, достаточно просто выбрать нужный тип аккаунта и подключиться к своему серверу — вуаля, полная синхронизация — почта, задачи, календарь...), документы и т.д. и т.п.
При этом напрочь отсутствуют лаги, характериные для андроида — все работает плавно и приятно, без тормозов и задержек. Даже когда у тебя одновремнно 3-5 задач в плитках крутятся (при сворачивании задачи в плитку она продолжает работать в фоне, при закрытии честно выгружается из памяти, все просто и понятно).
Ну а что касается разработчиков — многие тут с RTOS работали вообще? :-) По качеству софта на том же гуглплее складывается ощущение, что определенная часть разработчиков — школьники, прочитавшие по диагонали книгу «андроид для олигофренов» и возомнившие себя кульхацкерами.
Тут уже прозвучало мнение, с которым соглашусь — монополизм гугля вызван тем, что сначала они создали ощущение будто писать под андроид легко и просто и туда ломанулось огромное количество народа. Т.е. тупо количеством выдавили все остальное с рынка, а теперь начали закручивать гайки.
То же самое в свое время сделал майкрософт — долгие год они сквозь пальцы смотрели на пиратское распостранение своего софта и таким образом подсадили на этот бесплатный сыр огромное количество народа. Ну а потом прикрыли мышеловку…
Лично мне обидно что практически ушла с рынка (фактически уже ушла) Blackberry OS. Последняя версия была построена на микроядре QNX Neutrino (RTOS изначально разработанная для встроенных систем и вполне успешно работающая на промконтроллерах, серьезном сетевом оборудовании и т.д. и т.п.)
По надежности и безопасности ни андроид (linux), и iOS (FreeBSD) рядом не лежали. Но… система не была поддержана разработчиками (начиная от драйверов и заканчивая приложениями) ибо, как я понимаю, разработка под нее требует более высокой квалификации.
Система пока еще живет частично на своих приложениях, частично на андроидных (да, она поддерживает подсистему Android 4.3 и позволяет устанавливать приложения как в виде apk, так и из альтернативных маркетов типа amazon), но это уже не полноценная жизнь. А жаль.
Ну я выше написал схему, по которой попал на нынешнюю работу. И которую счтиаю удачной. В ней HR выполняют чисто организационную функцию — связаться, пригласить, провести. А собеседуют те люди, с которыми потом работаешь. У меня на собеседовании было человек пять из них тимлид команды в которой сечас работаю и человек, который был наставником в процессе обучения.
Вопросы были больше стратегического характера, никаких тестовых заданий. В основном насколько велики были проекты, насколько велик уровень самостоятельности в принятии решений и т.п.
Ну а без работы тут не останешься. Невпроворот. Есть текучка, есть исправление дефектов с боя, есть достаточно интересные задачи, где решение в лоб по тзине проходит по эффективности и надо придумывать хитрые алгоритмы…
Думаете поможет? :-)
Тут ведь дело в том, как организован процесс в целом и как в нем распределены роли.
Еще зависит от того, кого именно ищут — человека, который с первого дня (условно) начнет гнать код, или разработчика, с опытом и определнным кругозором, которого придется обучить конкретной специфике, но от которого потом можно ожидать каких-то новых в данной области решений, привнесенных и адаптированных «из прошлой жизни».
У нас, например, поощряется работа «на себя». Немв смысле налево, а в смысле до 20% (негласный порог) времни работаешь не над текущими задачами (при всем их обилии и жесткости сроков), а над какими-то общими библиотеками, которые могут потом эффективно применяться всеми, инструментарием, облегчающим дальнеюшую разработку, нестандартными алгоритмами, повышающми эффективность и т.п. Т.е. поощряется творчество, которое может быть полезно для выполнения текущей работы.
Год назад менял работу. Позвали на собеседование в одну маленькую конторку. Маленькую, но очень гордую. На собеседовании кадровица и техдиректор. Все про свою крутость рассказывали и про то, как у них строго с распорядком дня. Дали тестовую задачку. Написать на бумажке алгоритм выявления зацикливания односвязного списка. Написал. В результате сказали что позвонят и не позвонили.
Другая контора нашла сама. Называть не буду, но известная на всю страну. HR только организовали собеседование и провели на место. На самом собеседовании не присутствовали. Только несколько человек из тех с кем сейчас непосредственно работаю и руководитель направления в качестве начальства по видеоканалу.
Все вопросы были общего характера — навыки работы с большими проектами, кто тз ставит, насколь детально прописывалось тз и какова доля самостоятельной разработки. Т.е. определяли кто перед ними — разработчик или кодер.
В целом беседа была непринужденной и располагающей. Хотя не верилось что подойду — совершенно незнакомая предметная область (до этого работал в промавтоматизации, весьма специфическое направление) и абсолютно незнакомая и нечасто встречающаяся у нас платформа IBM i.
Расстались обычным «мы вам сообщим».
На следующий день опять HR — «выслала вам анкету для СБ, заполните и отпрвьте мне».
Дальше 3 месяца «испытательный срок». Но это больше время на обучение (первые два месяца очень тяжелые) и приглядывание к человеку «сработаемся или нет».
Потом узнал что вакансии размещают архитекторы или руководители направлений. Они же выискивают резюме и выставляют на голосование в команде «собеседуем или нет». Если команда решила собеседовать, уже дают задание HR организовать встречу. После всьречи опять голосуют командой — «понравился или нет». Если да — заявка HR на организацию трудоустройства.
Т.о. кадровая служба решает только процедурные вопросы в рамках своей компетенции. А все остально решеается теми, с кем потом придется работать. И, честно скажу, схема видится очень разумной и среди людей, с кем работаю пока не встретил ни одного, кто бы отказал в помощи или консультации. Народа много, но обстановка дружелюбно рабочая.
Сделайте просто пустой бесконечный цикл
for(;;);
и посмотрите как он повлияет на производительность всей системы.
Банковский софт должен быть
а) Надежным
б) Еще раз надежным
в) И еще раз надежным.
Т.е. превыше всего надежность. Если тот софт, что пишется внутри банка собственными силами и/или вендорами можно оттестировать на надежность (а тестирование там проводится специально обученными людьми и не в один этап — компонентное, интеграционное, бизнес, нагрузочное...) то надежность платформы на которой все это крутится должна обеспечиваться ее производителем.
И данная платформа (IBM i) достаточно надежна ибо разрабатывалась не под бытовые нужды, а для высокопроизводительных коммерческих серверов.
Что касается собственно АБС (автоматизированной банковской системы). Данная АБС есть система реального времени. Т.е. пользовательские операции тут совершаются не «с 4-х утра до полуночи», а круглосуточно. Даже при том, что сведение баланса (ежемесячный кошмар бухгалтера) в банке происходит ежедневно.
Чего стоит это реальное время для системы… Об этом лучше не говорить ибо в двух словах не описать :-)
Ну и на самом деле бизнес-логика на особенности ОС никак не завязана. Завязана ее конкретная реализация. И не столько на особенности ОС, сколько на особенности используемой банков АБС. А та или иная АБС используется любым банком ибо написать все с нуля своими силами нереально. И ни о каком порте тут речи быть не может.
Ну а что касается темы статьи — тут речь идет не о бизнес-логике, а о том самом тестировании. Без которого ни одна поставка не уйдет в бой. И о посильной автоматизации этого тестирования. Ибо куда проще и спокойнее дорабатывать поставку с тестов, чем бросать все и кидаться срочно затыкать дефект боя (когда некорректная работа обнаруживается уже в промышленной эксплуатации и сказывается на клиентах, вызывая их негативную реакцию и ущерб репутации банка).
На практике же, при грамотном распределении приоритетов, все это незаметно для пользователя.
Основной особенностью RTOS является гарантированно быстрая реакция на внешние события (приоритет событий). Вот это уже заметно — когда отклик на тачскрин наступает сразу, а не с задержкой (потому что у системы в этот момент, видите ли, более важные дела есть).
Другое дело — кому все это нужно? Проше вынудить пользователя купить новый девайс помощнее да подороже. Да и все равно ничего серьезного он там делать не будет. Трепаться по мессенждеру, лайкать таких же как он полудурков в мордокниге да постить фоточки «а вот я кушаю, а вот я какаю» в инстаграмм.
В целом все уныло, конечно.
Впервые столкнулся с кьюниксом (по-моему, это еще не нейтрино было) во второй половине 90-х на октагоновских микрописьках. Позже был небольшой опыт с vxWorks (тоже на промконтролерах). Не было проблем с производительностью.
Сам все еще пользуюсь Blackberry Z30 на BBOS 10.3.3 При слабеньком по нынешним меркам железе (снапдрагон S4 2х1.7 и 2Гб памяти) работает очень шустро в рамках поставленных перед ним задач — это в первую очередь бизнес-девайс, т.е. почта (причем легко и просто интегрируется с Microsoft Active Sync, IBM Lotus Notes Traveler — тут вообще не надо ставить, как на андроиде, дико жрущий батарею IBM Verse, достаточно просто выбрать нужный тип аккаунта и подключиться к своему серверу — вуаля, полная синхронизация — почта, задачи, календарь...), документы и т.д. и т.п.
При этом напрочь отсутствуют лаги, характериные для андроида — все работает плавно и приятно, без тормозов и задержек. Даже когда у тебя одновремнно 3-5 задач в плитках крутятся (при сворачивании задачи в плитку она продолжает работать в фоне, при закрытии честно выгружается из памяти, все просто и понятно).
Ну а что касается разработчиков — многие тут с RTOS работали вообще? :-) По качеству софта на том же гуглплее складывается ощущение, что определенная часть разработчиков — школьники, прочитавшие по диагонали книгу «андроид для олигофренов» и возомнившие себя кульхацкерами.
Тут уже прозвучало мнение, с которым соглашусь — монополизм гугля вызван тем, что сначала они создали ощущение будто писать под андроид легко и просто и туда ломанулось огромное количество народа. Т.е. тупо количеством выдавили все остальное с рынка, а теперь начали закручивать гайки.
То же самое в свое время сделал майкрософт — долгие год они сквозь пальцы смотрели на пиратское распостранение своего софта и таким образом подсадили на этот бесплатный сыр огромное количество народа. Ну а потом прикрыли мышеловку…
По надежности и безопасности ни андроид (linux), и iOS (FreeBSD) рядом не лежали. Но… система не была поддержана разработчиками (начиная от драйверов и заканчивая приложениями) ибо, как я понимаю, разработка под нее требует более высокой квалификации.
Система пока еще живет частично на своих приложениях, частично на андроидных (да, она поддерживает подсистему Android 4.3 и позволяет устанавливать приложения как в виде apk, так и из альтернативных маркетов типа amazon), но это уже не полноценная жизнь. А жаль.
Вопросы были больше стратегического характера, никаких тестовых заданий. В основном насколько велики были проекты, насколько велик уровень самостоятельности в принятии решений и т.п.
Ну а без работы тут не останешься. Невпроворот. Есть текучка, есть исправление дефектов с боя, есть достаточно интересные задачи, где решение в лоб по тзине проходит по эффективности и надо придумывать хитрые алгоритмы…
Тут ведь дело в том, как организован процесс в целом и как в нем распределены роли.
Еще зависит от того, кого именно ищут — человека, который с первого дня (условно) начнет гнать код, или разработчика, с опытом и определнным кругозором, которого придется обучить конкретной специфике, но от которого потом можно ожидать каких-то новых в данной области решений, привнесенных и адаптированных «из прошлой жизни».
У нас, например, поощряется работа «на себя». Немв смысле налево, а в смысле до 20% (негласный порог) времни работаешь не над текущими задачами (при всем их обилии и жесткости сроков), а над какими-то общими библиотеками, которые могут потом эффективно применяться всеми, инструментарием, облегчающим дальнеюшую разработку, нестандартными алгоритмами, повышающми эффективность и т.п. Т.е. поощряется творчество, которое может быть полезно для выполнения текущей работы.
Другая контора нашла сама. Называть не буду, но известная на всю страну. HR только организовали собеседование и провели на место. На самом собеседовании не присутствовали. Только несколько человек из тех с кем сейчас непосредственно работаю и руководитель направления в качестве начальства по видеоканалу.
Все вопросы были общего характера — навыки работы с большими проектами, кто тз ставит, насколь детально прописывалось тз и какова доля самостоятельной разработки. Т.е. определяли кто перед ними — разработчик или кодер.
В целом беседа была непринужденной и располагающей. Хотя не верилось что подойду — совершенно незнакомая предметная область (до этого работал в промавтоматизации, весьма специфическое направление) и абсолютно незнакомая и нечасто встречающаяся у нас платформа IBM i.
Расстались обычным «мы вам сообщим».
На следующий день опять HR — «выслала вам анкету для СБ, заполните и отпрвьте мне».
Дальше 3 месяца «испытательный срок». Но это больше время на обучение (первые два месяца очень тяжелые) и приглядывание к человеку «сработаемся или нет».
Потом узнал что вакансии размещают архитекторы или руководители направлений. Они же выискивают резюме и выставляют на голосование в команде «собеседуем или нет». Если команда решила собеседовать, уже дают задание HR организовать встречу. После всьречи опять голосуют командой — «понравился или нет». Если да — заявка HR на организацию трудоустройства.
Т.о. кадровая служба решает только процедурные вопросы в рамках своей компетенции. А все остально решеается теми, с кем потом придется работать. И, честно скажу, схема видится очень разумной и среди людей, с кем работаю пока не встретил ни одного, кто бы отказал в помощи или консультации. Народа много, но обстановка дружелюбно рабочая.
Виктор, ведущий разработчик, back-end, IBM i.