Позиции «отстающих» были заложены еще тогда. Поверьте на слово — родители всю жизнь в РАН, сам там начинал трудовую деятельность в конце 80-х
У жены родители в ВУзе всю жизнь проработали.
Так что что такое «советская наука» знаю из первых рук. Не была она передовой очень и очень давно уже.
С инструментами для разработки под платформы Apple сложнее — там очень много наследия из времён Objective-C, старого и неудобного системного API.
Вот пока разработчик досконально это самое «системное API» не изучит и не начнет понимать как оно там внутри все работает, нормального продукта от него трудно ждать.
«Нормальный» это прежде всего функциональность плюс стабильность при минимальных требованиях к ресурсам.
О господи… Вы бы хоть карту посмотрели для интереса.
Каким боком там Челябинск? ВУРС проходит примерно посередине между Челябинском и Екатеринбургом перпендикулярно трассе их соединяющей.
Там действительно есть длинный, но достаточно узкий «язык» от Озерска на восток. Но при этом сам Озерск, Касли, Кыштым он не затрагивает. В том же Карабаше (недалеко) экологическая ситуация и заболеваемость хуже в разы (если не на порядок) по совершенно иными причинам и безо всякой радиации.
Ну и чтобы два раза не вставать
Позже Мазин рассказал журналисту: «Я за ядерную энергию, я думаю, что ядерная энергия — необходимый элемент борьбы с глобальным потеплением». Потом он согласился с твитом о том, что «Чернобыль» не может произойти в США.
Угу. Только началось все с Тримайл Айленд. Первая, насколько помню, официально признанная крупная авария на АЭС.
Но сейчас там такого произойти не может, это точно. Последний энергоблок в США был введен в строй в 1979-м году. С тех пор ничего не построили. Попытка построить новую АЭС привела к банктроству основного подрядчика — Вестингауз и признанию того, что в США нет компании, которая способна самостоятельно построить корпус водно-водяного реактора (заказы размещаются в Южной Корее и Италии, потом еще куча приключений с перевозкой — история весьма занимательная).
Даже без брокерской деятельности нагрузка очень велика. Просто на обычных операциях.
А еще в банке баланс сводится каждый день. Так называемый EOD (End-Of-Day). А если АБС (Автоматизированная Банковская Система) работает в режиме реального времени, то там совсем весело — перед переходом в EOD создается т.н. «юнит ночного ввода» где продолжают идти все операции. А по окончании EOD производится «накат» — перенос всех изменений из ночного юнита в дневной (который уже перешел на следующий день). И попутно формируются различные отчеты и т.п.
А еще проверки операций для комплаенса, проверки пользователей на всякие риски и много-много чего.
В результате на сервере одновременно крутится огромное количество задач с конкурентным доступом к данным.
Любой сбой приводит к финансовым потерям и репутационным убыткам. В результате каждая новая задача проходит многоэтапное тестирование
1. Компонентное — на соответсвие ТЗ и отсутствие грубых ошибок, приводящих к падению задачи.
2. Бизнес — на соответствие заявки на разработку (т.е. это тест ТЗ + его реализации)
3. Интеграционное — на непротиворечивость взаимодействия со всеми остальными компонентами системы и отсутствия конфликтов в работе
4. Для регулярно запускаемых задач (те же отчеты, к примеру) еще обязательно нагрузочное тестирование — сколько ресурсов потребляет задача и насколько она оптимальна.
По факту казалось бы ничего сложного в разработке нет — обычная работа с БД. А на практике постоянная голована боль о том, чтобы каждую операцию пытаться сделать максимально эффективной. Не злоупотреблять «тяжелыми» операциями, по возможнсти вынося их из цикла. Там где можно сократить количество обращений к БД — кешировать все что можно. Задачи с большим количеством вычислений распараллеливать на мастера, выдающего задания и фиксирующего результаты и исполнителей (5-10 параллельных задач), обрабатывающих выданные блоки информации. Тут сразу встает вопрос эффективного межпроцессного взаимодействия (обмена данными) и контроля мастера за исполнителями… И т.д. и т.п.
Ну не совсем так. В банковских системах основная проблема в том, что часто приходится оперировать большими объемами данных (ну скажем, пройтись по нескольким десяткам миллионов записей в одной таблице, а для большинства записей подтянуть еще десяток из другой таблицы). Потом по полученным данным еще из третьей таблицы что-то выбрать, сопоставить то что есть с тем что должно быть и внести необходимые изменения. И все это должно сработать за некоторое разумное время (т.е не пол дня, а полчаса, например). И работает все это наряду с еще сотней задач. Т.е. оно не должно сильно грузить систему.
Т.е. все упирается в производительность и эффективность при работе с большими объемами данных, распределенных по нескольким местам. И далеко не всегда удается решить задачу в лоб, одним скулевым запросом. Была такая ситуация — проверка наличия строки в таблице. Но строки там хранятся группами в виде набора слов. Лобовое решение через listagg работает, но время примерно 2.5сек. А по ТЗ надо укладываться в 150-200мс. Вот и приходится мудрить с высокоселективными предвыборками, частотным словарем и т.д. и т.п.
Насчет системы сдерживания вопрос спорный. Взять хотя бы «Патриотический Акт», принятый в США после 9-11. Никаких «общественных институтов» дам и близко не подпустили. Просто приняли «из соображений госбезопасности».
Есть и другие примеры того, как госслужбы обходят любые институты когда им это выгодно — самый просто способ наложить гриф «Top Secret» мотивируя соображениями национальной безопасности.
Увы, но спецслужбы всегда и везде стремились, стремятся и будут стремиться получить возможность неограниченного контроля на всем до чего дотянутся. И противовесом может быть не общественный институт, а конкретные структуры с большими возможностями и полномочиями, потенциально страдающие от сих стремлений.
AS/400 плавно превратилась в IMB i И все еще живее всех живых. Просто не на каждом углу встречается в силу высокой стоимости — только у тех, кому настолько нужна производительность и надежность, что он готов за это платить
Вот уж воистину… Сейчас любой школьник, написавший пару учебных приложений на джаве, мнит себя нереальным гуру и раздает всем советы «космического масштаба космической же глупости» (с)
Упс. Лет двадцать с лихом в промавтоматизции проработал и ту такое…
Операционные системы реального времени (ОСРВ) – это операционные системы, способные обеспечить предсказуемое время обработки непредсказуемо возникающих внешних событий. Разделяют ОС «жесткого» и «мягкого» реального времени: для первых временные характеристики гарантированы, и выход за их пределы расценивается как отказ, для вторых временные ограничения, как правило, соблюдаются, и выход за их пределы считается снижением производительности.
Именно для этого они и разрабатывались. Чтобы ни происходило внутри системы, она должна отреагировать на поступление внешнего сигнала в течении заданного времени.
И какой бы вы приоритет не задавали UI потокам на андроиде, оно будет лагать если в это время андроиду запитимет память оптимизировать. Мы же знаем, что при «закрытии» приложения на андроиде физически оно из памяти не выгружается (что они курили когда такую фигню придумывали?) до тех пор пока системе не потребуется больше памяти и она не начнет ревизию что сейчас можно выгрузить.
Ну еще сборщик мусора javaмашины может активироваться и тормознуть систему.
Всему этому глубоко по барабану какие у вас там приоритеты для UI стоят.
Попробуйте убрать 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 на организацию трудоустройства.
Т.о. кадровая служба решает только процедурные вопросы в рамках своей компетенции. А все остально решеается теми, с кем потом придется работать. И, честно скажу, схема видится очень разумной и среди людей, с кем работаю пока не встретил ни одного, кто бы отказал в помощи или консультации. Народа много, но обстановка дружелюбно рабочая.
У жены родители в ВУзе всю жизнь проработали.
Так что что такое «советская наука» знаю из первых рук. Не была она передовой очень и очень давно уже.
Вот пока разработчик досконально это самое «системное API» не изучит и не начнет понимать как оно там внутри все работает, нормального продукта от него трудно ждать.
«Нормальный» это прежде всего функциональность плюс стабильность при минимальных требованиях к ресурсам.
Каким боком там Челябинск? ВУРС проходит примерно посередине между Челябинском и Екатеринбургом перпендикулярно трассе их соединяющей.
Там действительно есть длинный, но достаточно узкий «язык» от Озерска на восток. Но при этом сам Озерск, Касли, Кыштым он не затрагивает. В том же Карабаше (недалеко) экологическая ситуация и заболеваемость хуже в разы (если не на порядок) по совершенно иными причинам и безо всякой радиации.
Ну и чтобы два раза не вставать
Угу. Только началось все с Тримайл Айленд. Первая, насколько помню, официально признанная крупная авария на АЭС.
Но сейчас там такого произойти не может, это точно. Последний энергоблок в США был введен в строй в 1979-м году. С тех пор ничего не построили. Попытка построить новую АЭС привела к банктроству основного подрядчика — Вестингауз и признанию того, что в США нет компании, которая способна самостоятельно построить корпус водно-водяного реактора (заказы размещаются в Южной Корее и Италии, потом еще куча приключений с перевозкой — история весьма занимательная).
А еще в банке баланс сводится каждый день. Так называемый EOD (End-Of-Day). А если АБС (Автоматизированная Банковская Система) работает в режиме реального времени, то там совсем весело — перед переходом в EOD создается т.н. «юнит ночного ввода» где продолжают идти все операции. А по окончании EOD производится «накат» — перенос всех изменений из ночного юнита в дневной (который уже перешел на следующий день). И попутно формируются различные отчеты и т.п.
А еще проверки операций для комплаенса, проверки пользователей на всякие риски и много-много чего.
В результате на сервере одновременно крутится огромное количество задач с конкурентным доступом к данным.
Любой сбой приводит к финансовым потерям и репутационным убыткам. В результате каждая новая задача проходит многоэтапное тестирование
1. Компонентное — на соответсвие ТЗ и отсутствие грубых ошибок, приводящих к падению задачи.
2. Бизнес — на соответствие заявки на разработку (т.е. это тест ТЗ + его реализации)
3. Интеграционное — на непротиворечивость взаимодействия со всеми остальными компонентами системы и отсутствия конфликтов в работе
4. Для регулярно запускаемых задач (те же отчеты, к примеру) еще обязательно нагрузочное тестирование — сколько ресурсов потребляет задача и насколько она оптимальна.
По факту казалось бы ничего сложного в разработке нет — обычная работа с БД. А на практике постоянная голована боль о том, чтобы каждую операцию пытаться сделать максимально эффективной. Не злоупотреблять «тяжелыми» операциями, по возможнсти вынося их из цикла. Там где можно сократить количество обращений к БД — кешировать все что можно. Задачи с большим количеством вычислений распараллеливать на мастера, выдающего задания и фиксирующего результаты и исполнителей (5-10 параллельных задач), обрабатывающих выданные блоки информации. Тут сразу встает вопрос эффективного межпроцессного взаимодействия (обмена данными) и контроля мастера за исполнителями… И т.д. и т.п.
Так что скучать не приходится :-)
Т.е. все упирается в производительность и эффективность при работе с большими объемами данных, распределенных по нескольким местам. И далеко не всегда удается решить задачу в лоб, одним скулевым запросом. Была такая ситуация — проверка наличия строки в таблице. Но строки там хранятся группами в виде набора слов. Лобовое решение через listagg работает, но время примерно 2.5сек. А по ТЗ надо укладываться в 150-200мс. Вот и приходится мудрить с высокоселективными предвыборками, частотным словарем и т.д. и т.п.
Есть и другие примеры того, как госслужбы обходят любые институты когда им это выгодно — самый просто способ наложить гриф «Top Secret» мотивируя соображениями национальной безопасности.
Увы, но спецслужбы всегда и везде стремились, стремятся и будут стремиться получить возможность неограниченного контроля на всем до чего дотянутся. И противовесом может быть не общественный институт, а конкретные структуры с большими возможностями и полномочиями, потенциально страдающие от сих стремлений.
Увы, как бы это ни было цинично, но это так.
https://embedded.prosoft.ru/tags/osrv/
Именно для этого они и разрабатывались. Чтобы ни происходило внутри системы, она должна отреагировать на поступление внешнего сигнала в течении заданного времени.
И какой бы вы приоритет не задавали UI потокам на андроиде, оно будет лагать если в это время андроиду запитимет память оптимизировать. Мы же знаем, что при «закрытии» приложения на андроиде физически оно из памяти не выгружается (что они курили когда такую фигню придумывали?) до тех пор пока системе не потребуется больше памяти и она не начнет ревизию что сейчас можно выгрузить.
Ну еще сборщик мусора javaмашины может активироваться и тормознуть систему.
Всему этому глубоко по барабану какие у вас там приоритеты для UI стоят.
Сделайте просто пустой бесконечный цикл
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.