Насколько знаю бизнес-логика пишется на Java и прочих Haskell-ах, а тут ассемблер среднего уровня (если C++ есть ассемблер высокого уровня).
Java мы используем только для вебсервисов и под них выделен отдельные сервер в кластере. Ибо работает медленно, а памяти жрет как не в себя.
С Хаскелем не сталкивался — нет его у нас…
Основной язык — RPG Вполне себе высокого уровня. На нем пишется основная часть кода. Что-то системное пишется на С/С++.
Причем, на AS/400 есть такая концепция — ILE Вкратце — можно написать несколько модулей на разных языках (из состава поддерживаемых в ILE — Cobol, RPG, C/C++, CL) и собрать их в одну программу. Т.е. из процедуры, написанной на RPG можно вызывать функции, написанные на С/С++ и наоборот. Главное — правильно описать прототипы.
Ну или можно напрямую из RPG программ вызывать функции С-шной библиотеки (работа с файлами, qsort, bsearch и т.п.) — компилятор их сам найдет :-)
Компиляторы всех ILE языков есть часть системы. Ну вот простейший пример (кусок инсталлятора на языке CL — это системный язык AS/400):
CRTCPPMOD — модуль написан на С++
CRTSQLRPGI — модуль написан на SQLRPG — RPG с использование SQL команд внутри RPG кода
CRTRPGMOD — модуль на «чистом» RPG без SQL
CRTPGM — собираем все модули в один программный объект
Если на С функция выглядит как
extern "C" int WordsCount(char *pBuffer, int nBuffLen)
то на RPG ее прототип будет:
// количество слов в строке
dcl-pr WordsCount int(10) extproc(*CWIDEN : 'WordsCount');
pBuffer char(65535) const options(*varsize);
nBuffLen int(10) value;
end-pr;
И оно вызывается и работает.
Посему, что проще на RPG — пишем на RPG. Что проще на С/С++ — пишем на С/С++ :-)
Есть достаточно сложные реализации, например, у меня есть реализация SkipList на С++ (с классами, объектами), к ней Сишный враппер и RPG прототипы, позволяющие создавать из RPG объект SkipList (возвращается хендлер объекта) и потом работать с ним уже из RPG программ.
Есть и более сложные вещи — скажем, батчмашина для распараллеливания обработки. Сама машина написан на С++, но используется из RPG
Тут через spawn запускается несколько процессов (JOB) — обработчиков (программа ELB07S), количество процессов указано в WorkersCount.
Создаются очереди для обмена данными DQELBMAST — Мастер->обработчики и DQELBWORK — обработчики->мастер
А затем мастер готови пакеты данных для обработки и выдает их в очередь
Ну и всякая обвязка — контроль за состоянием очереди, состоянием заданий и т.п. Все это прописано внутри объекта на С++ НО используется из RPG.
При закрытии дня работа не останавливалась, тут к сожалению деталей реализации не знаю, работал все-таки аудитором, а не разрабом.
Ну формально она не останавливется. Просто операции откладываются до нового дня.
Я не говорю что у нас лучше всех :-) Просто есть так а есть этак. Вот у нас так…
При этом была высока доля ручных операций
Ну вот мы стремимся эту долю сокращать всемерно.
По скулю — если отключить оптимизацию запросов нельзя обойтись без построения плана запроса?
Нет. План запроса все равно строится. Хотя бы для того, чтобы понять какие индексы подцепить.
В ряде случаев скуль эффективнее. А в ряде нет. Наша задача — понимать где как лучше :-)
вам-то, наверное, в работе нужно знание алгоритмов
Да на самом деле не сильно. Логика у нас в целом туповатая в 99% случаев. Больше общие паттерны — как ту же батчмашину эффективно построить, как правильно распределить роли между мастером и обработчиками…
Очень много требований к обработке ошибок, их логированию и мониторингу.
Ну систему с ее особенностями представлять надо. А система ни на что не похожа. Она «объектная» — «все есть объект». И очень много специфических типов объектов. Надо их понимать как оно работает и что когда и где использовать.
Ну иногда нестандартное что-то бывает, конечно, но там просто фантазию включать надо :-)
Ну… Я затруднюсь перечислить все, что у нас делает АБС. Наверное, проще сказать «все» :-)
АБС бывают разные. Вот пример. Обслуживался когда-то в одном небольшом банке. И, видимо, АБС там была достаточно простой. Ибо ситуация такая: есть счет, к нему привязаны две карты. А надо понимать, что остаток на счете и остаток по карте — это две разные вещи. И было там так. Есть на счет 10тр. В статике обе карты показывают по 10тр доступных средств. Заходим в магазин, покупаем что-то на 10тр, расплачиваемся первой картой. После этого смотрим остатки. Остаток по счету 10тр. Остаток по первой карте (которой платили) — 0р. Остаток по второй карте 10тр. Заходим в другой магазин, покупаем еще на 10тр, расплачиваемся второй картой. Смотрим остатки — по счету 10тр, по обеим картам 0р. На следующий день (иногда через день, все это сводится воедино и на счете получается технический овердрафт в -10тр. Так работает АБС.
У нас такое невозможно — АБС работает в реальном времени и все эти остатки синхронизируются в течении нескольких секунд. Но ценой нагрузки на сервер, конечно — все это должно обрабатываться быстро.
Второй пример. Баланс (который притча во языцах каждого бухгалтера) в банке сводится не раз в месяц, а каждый день. Это называется EOD — End-Of-Day (переход на следующий операционный день) и занимает несколько часов ночью. Некоторые АБС на это время приостанавливают работу банка (т.е. все операции как бы проводятся, но фактически складываются в кеш и проходят уже после EOD следующим днем). Но, опять же, не у нас. У нас перед началом EOD создается т.н. «юнит ночного ввода» как копия основного юнита и все операции переносятся туда и продолжают выполняться. А в основном юните проходит EOD. По завершении которого юнит переходит в следующий день и все изменения, что произошли в течении EOD в ночном юните «накатываются» в дневной. Тоже лишние танцы с бубном, но обеспечивают непрерывную работу системы. Естественно, все это автоматизировано.
Открывает клиент счет — банк должен предоставить данные в налоговую. Система сама отслеживает изменения в таблице счетов и как только бухрежим по счету перешел из состояния «зарезервирован» в состояние «активен», сама формирует сообщение для налоговой и отсылает его через MQ в соотв. внешнюю систему, которая уже отвечает за передачу данных.
Карточки клиентов (клиентские данные) — это тоже часть АБС. А там много чего понавешаено. Те же риски клиентов (страновые, репутационные...) — все это обрабатывается автоматом по изменению клиентских данных.
Комплаенс. Моя тема. Росфинмониторинг регулярно присылает списки всяких злодеев. Разбираются и раскладываются по базе они автоматом (последнее время как раз этим занимаюсь). Пришел новый список, разложился — запускается процедура серки клиентов. Это прогоняются все активные клиенты (несколько десятков миллионов если что) и для каждого производится поиск совпадений со списками злодеев — по именам, ДР, ДУЛ (документ удостоверяющий личность), ИНН, адресам. Формируется отчет по совпадениям (полные, частичные). Это все автоматом тоже. Соответсвенно, есть набор APIшек для проверки совпадений… Тоже наша работа… Они же используются для контроля платежей — от кого, кому (а не пособствуем ли мы финансированию террористов?)…
Все это и еще очень много чего является функциями АБС. И любое изменение требования регулятора приводит к необходимости доработки той или иной функции. Чем мы и занимаемся :-)
В результате на серверах одновременно крутятся тысячи фоновых процессов. Тут, кстати, проявляется одно из преимуществ AS/400 — она изначально сделана для такой работы. В силу ряда особенностей в ней минимизированы до предела накладные расходы на смену контекста при переключении между процессами. Так что она еще очень долго будет жить и развиваться в этой нише — там, где требуется одновременная работа многих процессов.
Что касается скуля… По нашим наблюдениям он далеко не всегда является оптимльным с точки зрения производиетльности и потребления ресурсов. Просто потому что перед выполнением требует времени и ресурсов на построение плана запроса. С этим можно мирится для статических или параметризированных запросов — один раз построил план и пользуйся им. А вот если запрос динамический и формируется на лету… И при этом вызывается десятки тысяч раз в секунду… Получается очень дорого.
Была у меня задача — запрос содержал конструкцию where… in (...) где список in(...) формировался каждый раз заново из входных данных. По нагрузочной статистике на это уходило до 36% времени и до 33% процессорных ресурсов данной процедуры. К счастью, RPG позволяет не только скулем работать, но и прямым обращением к таблицам (функции позиционирования по индексному файлу, чтения из таблиц...). Переписал, избавившись от скуля. Да, больше кода. Но стало быстрее работать и меньше грузить процессор. А функция была критичная — как раз поиск совпадений по наименованию со списком злодеев. Т.е. вызываться она могла в определенных ситуациях десятки миллионов раз подряд.
Фактически скулем пользуемся когда надо делать большие сложные выборки по нескольким таблицам. И можно использовать статический параметризированный запрос.
А вот прочитать одну запись из таблицы по ключу (или выбрать десяток-сотню записей) — это быстрее «нативным» RPG. Или проверить наличие в таблице записи с заданным значением ключа (просто есть или нет — содержимое записи не интересует) — тут даже в саму таблицу лезть не надо, просто посмотреть индексный файл.
В общем, там очень много тонкостей, требующих знания языка, платформы на которой работаешь… И смешно читать как человек «правит код на Go самого Go не зная».
У нас его изначально не было. Сразу все на RPG. Который по синтаксису приятнее кобола, по возможностям (в плане работы с БД, нативной поддержки типов с фиксированной точкой и т.п.) как минимум не хуже.
Но кобол поддерживется в концепции ILE (С/С++, CL, RPG, COBOL) и его компилятор встроен в систему. Так что возможность писать на нем формально есть :-)
Ну не все так страшно на самом деле. Система вполне себе живет и развивается как по железу, так и по софту. Относительно недавно появились системы PowerS9. На подходе (если еще на вышли) — 10-е.
Версия самой ОС 7.4 вышла в прошлом году. TR-ы (обновления внутри версии) выходят регулярно (мы сейчас в процессе перехода с 7.3TR9 на проде на 7.4TR3 которые уже раскатаны на тестовых средах)
Да, у нас она не популярна (я знаю три банка, которые на ней работают — Альфа, Райф и Рос, ну может еще где-то есть). Но в мире она достаточно распостранена — банки, страховые компании, госструктуры.
Просто на фоне всеобщего засилия мобильной и вебразработки это выглядит нишево, но ниша эта стабильна.
В целом, это свой рынок, вполне устойчивый. Аналогично можно сказать и про многие другие аспекты разработки — та же промавтоматизация, встроенные системы. Уступает по объему вебразработке, но средняя квалификация работающих там людей достатчоно высока.
Главный разработчик ЦБС (Центральных Банковских Систем) в Альфа-Банке. Чтобы понятнее — это бэкенд глубже некуда — команда ядровых функций АБС (Автоматизированной Банковской Системы). Т.е. все, что происходит «наверху» так или иначе приходит к нам. А также все, что крутится в фоне, обеспечивая работу банка.
Работает все это на платформе IBM i (бывш. AS/400) на серверах IBM PowerS9. Пишем на IBM'овском языке RPG (ну и частично на C/C++ там, где нужно более глубокое взаимодействие с системой). Впрочем, до этого я работал в совсем другой области и на С, а позже на С++ пишу года этак с 89-90-го (т.е. стаж в разработке кой-какой имеется, равно как и понимание как надо и как не надо в достаточно широком круге вопросов от работы с БД, распараллеливания обработки больших массивов данных до межпроцессного взаимодействия в гетерогенных распределенных системах).
И решать олимпиадные задачки яндыха до того, как определены позиции что мне могут предложить, что могу предложить я и насколько все это взаимно интересно — ну как-то совсем не с руки.
Девочка-рекрутер мое резюме читала и была в курсе что к чему. И я сразу поставил условие что для начала будет просто разговор для определения позиций. А дальше уже решим.
Но интервьюер был или не в курсе, или просто не в состоянии отойти от привычного шаблона — сходу завалить олимпиадными задачками.
Ну а мне не настолько нужны деньги чтобы прогибаться.
Чтобы поправить строчку в Го сервисе, мне не надо изучать Го.
И привел пример того, что не зная языка, Вы просто не увидите ошибку. Вы не сможете по тексту понять что оно должно делать и что делает на самом деле. И скорее всего не найдете даже то место, где надо править.
Если, конечно, это задача чуть сложнее уровня «Hello World!».
найти автора кода и спросить у него
Уволился пять лет назад.
найти группу, которая ментейнит код, и спросить у них
А зачем тогда Вы там нужны?
не пропускать код на ревью, который никто не понимает
Те, кто пишут на этом языке, прекрасно его понимают. Тут проще не допускать до ревью того, кто не знает этого языка.
использовать языки, где не будет проблем с пониманием
Проще использовать тех специалистов, которые понимают основной язык, используемый в разработке в данной области. И не использовать тех, кто берет на себя смелость править код, не понимая языка на котором он написан.
Вам так не кажется?
Вы же не предлагаете это все спрашивать у кандидата? Или вы ищете жестко под одну задачу заточенного человека?
Я как раз предлагаю не гонять кандидата по олимпиадным задачам. Но в денном случае речь не о том. А об одной конкретной Вашей фразе.
Чтобы поправить строчку в Го сервисе, мне не надо изучать Го.
Чтобы поправить строчку, надо сначала ее найти. Среди тысяч других. А чтобы найти (по описанию дефекта типа «у нас тут должно быть так, а по факту вот этак») нужно этот код прочитать и понять что и как он делает.
А вот скажите, как часто в работе попадаются задачи из тех, что предлагаются на собесе?
Я вот не могу вспомнить сходу что-то такое приходилось делать…
Зато сплошь и рядом попадаются задачи, которые требуют некоторой фантазии для решения. Например как один запрос «в лоб», выполняющийся 3 секунды, разбить на несколько, выделить высокоселективные предвыборки на основе частотного словаря, уйти от использования медленных агрегатных функций, и в результате получить тот же результат, гарантированно укладываясь в 150-200мс. Вот это вполне реальная задача, решающая реальную проблему бизнеса.
Или как оптимизировать параллельную многопоточную обработку большого массива данных, которая занимает 15-17 часов, не трогая собственно обработчик, только за счет оптимизации механизма распараллеливания, уменьшив время обработки до 9-ти часов при том же количестве потоков.
Подобных задач на самом деле у нас встречается очень много. И для каждой требуется индивидуальный подход. И тут важнее умение человека думать нестандартно, чем знание им заученных алгоритмов и типовых задачек.
И лично в моей практике есть примеры людей, которые приходили совсем нулевыми, но буквально за полгода раскрывались в достаточно перспективного разработчика. Алгоритмические задачки таких отсеивают сходу, а вот вопросы на подумать скорее помогут распознать потенциал.
Причем даже скорость не всегда является абсолютным приоритетом.
Мы же не про сферического коня в абсолютном вакууме, а про некий реальный процесс, работающий в окружении десятков, сотен, тысяч других процессов. И нам важна не только скорость, но и ресурсоемкость этого процесса. Что толку в его скорости, если он под себя отбирает столько ресурсов, что все остальное встает колом пока он работает?
В результате задача уже формулируется примерно так: «есть временное окно, в котором загрузка сервера составляет XX%. Необходимо уложиться в это временное окно так, чтобы загрузка сервера не превысила YY%»
А это уже те аспекты, про которые на олимпиадах нет.
Вот да. В Альфу у меня именно такое и было собеседование.
Никаких тестов, просто поговорили — чем они занимаются, чем я занимался.
Интервьюеров тут тоже нет. Беседуют члены команды (тимлид, техлид, функциональный руководитель...) — те, с кем потом работать.
Испытательный срок есть, но это больше обучение — найти готового спеца на RPG и AS/400 у нас малореально…
Не знаю :-)
Просто в голову как-то пришло само. Всплыло из глубин подсознания, а уж как оно там оказалось… Может и от Успенского (хотя не могу сказать чтобы когда-то серьезно им увлекался, хотя наверняка что-то его читал/слышал).
Мда… Хорошо что в свое время не повелся на эту тему…
Уже работая там где работаю :-) получил неожиданно письмо от яндыхового рекрутера. Некоторое время пытался объяснить девочке что работу уже не ищу, что текущая работа устраивает и все такое. Как об стену горох. То ли ей за каждого кандидата, которого она на собес затащит, баллы идут вне зависимости от результата, то ли она действительно уверена, что яндых есть предел мечтаний для каждого разработчика.
Ладно,
Знаешь, кто такой зануда? Это человек, с которым легче переспать, чем объяснять, почему ты этого не хочешь!
(с) Ностальгия
договорились что встречусь по скайпу просто поговорить. Чем занимаются они, что умею я, что мне могут предложить…
Началось с того, что в назначенное время в скайп засунулся интервьюер и сказал что интервью переносится на полчаса. Ну ладно… Может форсмажор какой…
Через полчаса наконец состыковались. И началось сходу «я тут вам подготовил ряд тестовх заданий...»
Стоп. Мы так не договаривались. Я уже давно вышел из возраста юноши пылкого со взором горящим, олимпиадные задачки меня не интересуют — это вы для джунов оставьте. Мне интересно чем вы там вообще занимаетесь и есть ли там для меня какой-то интерес.
Хотите проверить — задавайте конкретные вопросы из жизни. Как решить вот такую проблему. Или с какой стороны я бы подошел вот к такой задаче. На понимание сути, так сказать.
В общем, проговорил ему что-то в этом плане и попрощался. Товарищ, похоже, так и не понял. Ну и бог с ним.
Ну справедливости ради Микрософту это не надо. Они своей политикой (в течении многих лет просто не обращали внимание на то, что их софт копируется нелегально) подсадили весь мир на свой офис.
Что касается Опена и Либры… Чем они так лучше МС? Ну кроме того, что официально бесплатны?
Интерфейс МС не блещет, мягко говоря, но интерфейс Либры это уже за гранью добра и зла.
Берем документ МС (страниц этак на 300) в котором есть оглавление. Открываем в МС, включаем «область навигации» и получаем возможность быстро и удобно перемещаться по разделам. Открываем тот же документ и пытаемся открыть панель навигации. Что-то открывается, да. Но вид убогий, пользоваться дико неудобно, еще и съезжает все (сталкивался что структура вложенных заголовков съезжает, какие-то заголовки не показываются, какие-то дублируются...)
А с документами такими приходится работать много (BRD, FSD...) и без навигации быстро перемещаться по документу нереально.
Так что и рад бы либрой пользоваться, но производительность падает. И приходится МС…
Что касается стабильности… Win10 Pro 2004. Рабочий ноут не выключается с тех пор, как сел на удаленку (год уже как). Ну изредка просит перезагрузиться для наката каких-то обновлений. Но это за все время буквально несколько раз было. Не упало ничего не разу. Все работает быстро и стабильно.
Может быть потому, что не ставлю лишних обновлений? Только необходимые?
Насколько нас учили когда-то, там проблемы были больше в экономической целесообразности в то время. Технология более совершенная, по сравнению с газодиффузией, но существенно более дорогая на этапе строительства.
Немного занимался ультрацентрифугами. В свое время (еще когда работал после выпуска в Институте Теплофизики УрО РАН) была у меня тема по исследованию кавитационной прочности жидкостей (отрицательные давления в жидкостях, прочность жидкости на разрыв). И первой установкой была газовая ультрацентрифуга, где жидкость в ячейке рвалась центробежными силами.
Устройство было крайне простым — статор представлял из себя воронку, в образующей которой располагались (под хитрым пространственным углом) сопла. Ротор — конус с отфрезерованными на поверхности лопатками. При подаче сжатого газа через сопла статора ротор приподнимался над поверхностью статора раскручивался.
Я у себя использовал стальной ротор диаметром 50мм. Раскручивал его сжатым воздухом (давление порядка 10бар) до скоростей 2500 Гц (да, именно, герц — 2500 оборотов в секунду). Больше не удавалось — там уже трение поверхности ротора о воздух, скорости истечения газа из сопла и прочие граничные условия. Но мне хватало. Работал с пропаном (в жидкой фазе), его рвало где-то на 1500 гц.
Поскольку физического контакта ротора со статором не было, никакой особой балансировки не требовалось. Ротор точился на обычном станке (ну для фрезировки лопаток некоторую оснастку пришлось придумать и сделать за неимением доступа к хорошим координатным станкам в то время и в том месте). Сверху на нем размещалась Z-образная ячейка с пропаном. Все. Вся балансировка происходила автоматически.
Остальное уже обвязка — высокочастоный стробоскоп на лампе ИСШ (сведодиодов мощных тогда еще не было) для наблюдения. Измерение скорости — отражающий сектор на поверхности статора + точечтный источник света + фотодиод + частотомер + схема синхронизации для стробоскопа.
Максимальные скорости вращения для такой конструкции были зафиксированы в одной из западных статей — 21000 Гц. Но там ротор был мелкий, 9мм, плюс сопла Лаваля (мне недоступно было технологически их изготовить) плюс крутили сжатым водородом (скорость истечения выше чем с воздухом).
А были еще ультрацентрифуги с магнитным подвесом, которые раскручивались вращающимся магнитным полем. Попадалась статья из какого-то Пермского НИИ где товарищ шарики для шарикоподшипников на прочность испытывал в такой системе. Он в вакууме шарик в магнитном подвесе магнитным полем раскручивал до 360кГц (после чего он принимал форму геоида и затем разрушался).
А есть еще газовые ультрацентрифуги, применяемые на производствах по разделению изотопов урана (рабочее тело — UF6 — гексафторид урана, в центрифугах разделяется на фракции, обогащенные по 235-му и 238-му изотопам). На УЭХК (Уральский Электро-Химический Комбинат целый завод на таких работает, причем, первые центрифуги там были запущены в 1957-м году (до этого использовался газодиффузионный метод), а с 1961-го года центробежный метод введен в промышленную эксплуатацию.
Так что вся эта история про необходимость заказа на западе, хитрые подвесы выглядит как-то не очень правдоподобно. Были у нас свои разработки.
Про документацию (MSDN) +100500!
От линуха бог миловал, но сейчас работаю под AS/400 (IBM i) — доки от IBM (Knowlege Center) на порядок хуже MSDN. И написаны кривым языком и с примерами так себе. Правда, и система посложнее винды и линуха вместе взятых…
Java мы используем только для вебсервисов и под них выделен отдельные сервер в кластере. Ибо работает медленно, а памяти жрет как не в себя.
С Хаскелем не сталкивался — нет его у нас…
Основной язык — RPG Вполне себе высокого уровня. На нем пишется основная часть кода. Что-то системное пишется на С/С++.
Причем, на AS/400 есть такая концепция — ILE Вкратце — можно написать несколько модулей на разных языках (из состава поддерживаемых в ILE — Cobol, RPG, C/C++, CL) и собрать их в одну программу. Т.е. из процедуры, написанной на RPG можно вызывать функции, написанные на С/С++ и наоборот. Главное — правильно описать прототипы.
Ну или можно напрямую из RPG программ вызывать функции С-шной библиотеки (работа с файлами, qsort, bsearch и т.п.) — компилятор их сам найдет :-)
Компиляторы всех ILE языков есть часть системы. Ну вот простейший пример (кусок инсталлятора на языке CL — это системный язык AS/400):
CRTCPPMOD MODULE(QTEMP/DTAQ) SRCFILE(&ASRC/&SRCF) SRCMBR(DTAQ) OUTPUT(*PRINT)-
DBGVIEW(*SOURCE)
CRTCPPMOD MODULE(QTEMP/BATCHM) SRCFILE(&ASRC/&SRCF) SRCMBR(BATCHM) OUTPUT(*PRINT)-
DBGVIEW(*SOURCE)
CRTCPPMOD MODULE(QTEMP/BATCHMWRP) SRCFILE(&ASRC/&SRCF) SRCMBR(BATCHMWRP)-
OUTPUT(*PRINT) DBGVIEW(*SOURCE)
CRTSQLRPGI OBJ(QTEMP/ELB03S) SRCFILE(&ASRC/&SRCF) SRCMBR(ELB03S) DBGVIEW(*SOURCE)-
COMMIT(*NONE) OBJTYPE(*MODULE) RPGPPOPT(*LVL2) SRTSEQ(*HEX) OUTPUT(*PRINT)-
LANGID(RUS)
CRTRPGMOD MODULE(QTEMP/ELB07PROC) SRCFILE(&ASRC/&SRCF) SRCMBR(ELB07PROC)-
DBGVIEW(*COPY)
CRTPGM PGM(&ALIB/ELB03S) MODULE((QTEMP/BATCHM) (QTEMP/BATCHMWRP) (QTEMP/DTAQ)-
(QTEMP/ELB03S) (QTEMP/ELB07PROC) ) BNDDIR((*LIBL/LESBNDDIR) ) ACTGRP(*CALLER)-
TGTRLS(*CURRENT) STGMDL(*SNGLVL) ALWUPD(*YES) ALWLIBUPD(*NO) ENTMOD(QTEMP/ELB03S)
Сначала компилируем модули:
CRTCPPMOD — модуль написан на С++
CRTSQLRPGI — модуль написан на SQLRPG — RPG с использование SQL команд внутри RPG кода
CRTRPGMOD — модуль на «чистом» RPG без SQL
CRTPGM — собираем все модули в один программный объект
Если на С функция выглядит как
то на RPG ее прототип будет:
// количество слов в строке
dcl-pr WordsCount int(10) extproc(*CWIDEN : 'WordsCount');
pBuffer char(65535) const options(*varsize);
nBuffLen int(10) value;
end-pr;
И оно вызывается и работает.
Посему, что проще на RPG — пишем на RPG. Что проще на С/С++ — пишем на С/С++ :-)
Есть достаточно сложные реализации, например, у меня есть реализация SkipList на С++ (с классами, объектами), к ней Сишный враппер и RPG прототипы, позволяющие создавать из RPG объект SkipList (возвращается хендлер объекта) и потом работать с ним уже из RPG программ.
Есть и более сложные вещи — скажем, батчмашина для распараллеливания обработки. Сама машина написан на С++, но используется из RPG
// Создаем многопочку
Master = Batch_CreateMaster('*LIBL' : 'ELB07S' : '' : 'ETLPROC' :
DtaQLib : 'DQELBMAST' : 'DQELBWORK' :
WorkersCount :
(%size(t_qdsClient) * SendBlockSize) :
(%size(t_qdsClient) * SendBlockSize) :
PingTime : ResendCount : RecieveTimeout :
strError);
Тут через spawn запускается несколько процессов (JOB) — обработчиков (программа ELB07S), количество процессов указано в WorkersCount.
Создаются очереди для обмена данными DQELBMAST — Мастер->обработчики и DQELBWORK — обработчики->мастер
А затем мастер готови пакеты данных для обработки и выдает их в очередь
Batch_MasterSendData(Master : pData : DataLen : ErrStr)Ну и всякая обвязка — контроль за состоянием очереди, состоянием заданий и т.п. Все это прописано внутри объекта на С++ НО используется из RPG.
Ну формально она не останавливется. Просто операции откладываются до нового дня.
Я не говорю что у нас лучше всех :-) Просто есть так а есть этак. Вот у нас так…
Ну вот мы стремимся эту долю сокращать всемерно.
Нет. План запроса все равно строится. Хотя бы для того, чтобы понять какие индексы подцепить.
В ряде случаев скуль эффективнее. А в ряде нет. Наша задача — понимать где как лучше :-)
Да на самом деле не сильно. Логика у нас в целом туповатая в 99% случаев. Больше общие паттерны — как ту же батчмашину эффективно построить, как правильно распределить роли между мастером и обработчиками…
Очень много требований к обработке ошибок, их логированию и мониторингу.
Ну систему с ее особенностями представлять надо. А система ни на что не похожа. Она «объектная» — «все есть объект». И очень много специфических типов объектов. Надо их понимать как оно работает и что когда и где использовать.
Ну иногда нестандартное что-то бывает, конечно, но там просто фантазию включать надо :-)
АБС бывают разные. Вот пример. Обслуживался когда-то в одном небольшом банке. И, видимо, АБС там была достаточно простой. Ибо ситуация такая: есть счет, к нему привязаны две карты. А надо понимать, что остаток на счете и остаток по карте — это две разные вещи. И было там так. Есть на счет 10тр. В статике обе карты показывают по 10тр доступных средств. Заходим в магазин, покупаем что-то на 10тр, расплачиваемся первой картой. После этого смотрим остатки. Остаток по счету 10тр. Остаток по первой карте (которой платили) — 0р. Остаток по второй карте 10тр. Заходим в другой магазин, покупаем еще на 10тр, расплачиваемся второй картой. Смотрим остатки — по счету 10тр, по обеим картам 0р. На следующий день (иногда через день, все это сводится воедино и на счете получается технический овердрафт в -10тр. Так работает АБС.
У нас такое невозможно — АБС работает в реальном времени и все эти остатки синхронизируются в течении нескольких секунд. Но ценой нагрузки на сервер, конечно — все это должно обрабатываться быстро.
Второй пример. Баланс (который притча во языцах каждого бухгалтера) в банке сводится не раз в месяц, а каждый день. Это называется EOD — End-Of-Day (переход на следующий операционный день) и занимает несколько часов ночью. Некоторые АБС на это время приостанавливают работу банка (т.е. все операции как бы проводятся, но фактически складываются в кеш и проходят уже после EOD следующим днем). Но, опять же, не у нас. У нас перед началом EOD создается т.н. «юнит ночного ввода» как копия основного юнита и все операции переносятся туда и продолжают выполняться. А в основном юните проходит EOD. По завершении которого юнит переходит в следующий день и все изменения, что произошли в течении EOD в ночном юните «накатываются» в дневной. Тоже лишние танцы с бубном, но обеспечивают непрерывную работу системы. Естественно, все это автоматизировано.
Открывает клиент счет — банк должен предоставить данные в налоговую. Система сама отслеживает изменения в таблице счетов и как только бухрежим по счету перешел из состояния «зарезервирован» в состояние «активен», сама формирует сообщение для налоговой и отсылает его через MQ в соотв. внешнюю систему, которая уже отвечает за передачу данных.
Карточки клиентов (клиентские данные) — это тоже часть АБС. А там много чего понавешаено. Те же риски клиентов (страновые, репутационные...) — все это обрабатывается автоматом по изменению клиентских данных.
Комплаенс. Моя тема. Росфинмониторинг регулярно присылает списки всяких злодеев. Разбираются и раскладываются по базе они автоматом (последнее время как раз этим занимаюсь). Пришел новый список, разложился — запускается процедура серки клиентов. Это прогоняются все активные клиенты (несколько десятков миллионов если что) и для каждого производится поиск совпадений со списками злодеев — по именам, ДР, ДУЛ (документ удостоверяющий личность), ИНН, адресам. Формируется отчет по совпадениям (полные, частичные). Это все автоматом тоже. Соответсвенно, есть набор APIшек для проверки совпадений… Тоже наша работа… Они же используются для контроля платежей — от кого, кому (а не пособствуем ли мы финансированию террористов?)…
Все это и еще очень много чего является функциями АБС. И любое изменение требования регулятора приводит к необходимости доработки той или иной функции. Чем мы и занимаемся :-)
В результате на серверах одновременно крутятся тысячи фоновых процессов. Тут, кстати, проявляется одно из преимуществ AS/400 — она изначально сделана для такой работы. В силу ряда особенностей в ней минимизированы до предела накладные расходы на смену контекста при переключении между процессами. Так что она еще очень долго будет жить и развиваться в этой нише — там, где требуется одновременная работа многих процессов.
Что касается скуля… По нашим наблюдениям он далеко не всегда является оптимльным с точки зрения производиетльности и потребления ресурсов. Просто потому что перед выполнением требует времени и ресурсов на построение плана запроса. С этим можно мирится для статических или параметризированных запросов — один раз построил план и пользуйся им. А вот если запрос динамический и формируется на лету… И при этом вызывается десятки тысяч раз в секунду… Получается очень дорого.
Была у меня задача — запрос содержал конструкцию where… in (...) где список in(...) формировался каждый раз заново из входных данных. По нагрузочной статистике на это уходило до 36% времени и до 33% процессорных ресурсов данной процедуры. К счастью, RPG позволяет не только скулем работать, но и прямым обращением к таблицам (функции позиционирования по индексному файлу, чтения из таблиц...). Переписал, избавившись от скуля. Да, больше кода. Но стало быстрее работать и меньше грузить процессор. А функция была критичная — как раз поиск совпадений по наименованию со списком злодеев. Т.е. вызываться она могла в определенных ситуациях десятки миллионов раз подряд.
Фактически скулем пользуемся когда надо делать большие сложные выборки по нескольким таблицам. И можно использовать статический параметризированный запрос.
А вот прочитать одну запись из таблицы по ключу (или выбрать десяток-сотню записей) — это быстрее «нативным» RPG. Или проверить наличие в таблице записи с заданным значением ключа (просто есть или нет — содержимое записи не интересует) — тут даже в саму таблицу лезть не надо, просто посмотреть индексный файл.
В общем, там очень много тонкостей, требующих знания языка, платформы на которой работаешь… И смешно читать как человек «правит код на Go самого Go не зная».
Но кобол поддерживется в концепции ILE (С/С++, CL, RPG, COBOL) и его компилятор встроен в систему. Так что возможность писать на нем формально есть :-)
Версия самой ОС 7.4 вышла в прошлом году. TR-ы (обновления внутри версии) выходят регулярно (мы сейчас в процессе перехода с 7.3TR9 на проде на 7.4TR3 которые уже раскатаны на тестовых средах)
Да, у нас она не популярна (я знаю три банка, которые на ней работают — Альфа, Райф и Рос, ну может еще где-то есть). Но в мире она достаточно распостранена — банки, страховые компании, госструктуры.
Просто на фоне всеобщего засилия мобильной и вебразработки это выглядит нишево, но ниша эта стабильна.
В целом, это свой рынок, вполне устойчивый. Аналогично можно сказать и про многие другие аспекты разработки — та же промавтоматизация, встроенные системы. Уступает по объему вебразработке, но средняя квалификация работающих там людей достатчоно высока.
Главный разработчик ЦБС (Центральных Банковских Систем) в Альфа-Банке. Чтобы понятнее — это бэкенд глубже некуда — команда ядровых функций АБС (Автоматизированной Банковской Системы). Т.е. все, что происходит «наверху» так или иначе приходит к нам. А также все, что крутится в фоне, обеспечивая работу банка.
Работает все это на платформе IBM i (бывш. AS/400) на серверах IBM PowerS9. Пишем на IBM'овском языке RPG (ну и частично на C/C++ там, где нужно более глубокое взаимодействие с системой). Впрочем, до этого я работал в совсем другой области и на С, а позже на С++ пишу года этак с 89-90-го (т.е. стаж в разработке кой-какой имеется, равно как и понимание как надо и как не надо в достаточно широком круге вопросов от работы с БД, распараллеливания обработки больших массивов данных до межпроцессного взаимодействия в гетерогенных распределенных системах).
И решать олимпиадные задачки яндыха до того, как определены позиции что мне могут предложить, что могу предложить я и насколько все это взаимно интересно — ну как-то совсем не с руки.
Девочка-рекрутер мое резюме читала и была в курсе что к чему. И я сразу поставил условие что для начала будет просто разговор для определения позиций. А дальше уже решим.
Но интервьюер был или не в курсе, или просто не в состоянии отойти от привычного шаблона — сходу завалить олимпиадными задачками.
Ну а мне не настолько нужны деньги чтобы прогибаться.
И привел пример того, что не зная языка, Вы просто не увидите ошибку. Вы не сможете по тексту понять что оно должно делать и что делает на самом деле. И скорее всего не найдете даже то место, где надо править.
Если, конечно, это задача чуть сложнее уровня «Hello World!».
Уволился пять лет назад.
А зачем тогда Вы там нужны?
Те, кто пишут на этом языке, прекрасно его понимают. Тут проще не допускать до ревью того, кто не знает этого языка.
Проще использовать тех специалистов, которые понимают основной язык, используемый в разработке в данной области. И не использовать тех, кто берет на себя смелость править код, не понимая языка на котором он написан.
Вам так не кажется?
Я как раз предлагаю не гонять кандидата по олимпиадным задачам. Но в денном случае речь не о том. А об одной конкретной Вашей фразе.
Могу поспорить, что Вы не скажете в чем тут ошибка:
if %check(%trim(chDInp): '0123456789') = 0;
Оно скомпилируется. И будет работать. Но неправильно. И будет дефект.
Или вот такое:
setgt (CRF: DInp: Ist: qdsGZRRL1.GZOSI) RRU01LF;
if %found(RRU01LF);
…
endif;
Тоже скомпилируется. И тоже будет работать. Но неправильно.
Чтобы понять почему надо таки знать язык на котором это написано. И тонкости работы его встроенных функций.
Они что, всерьез думали, что я пойду «перекладывать джсоны» со своей текущей позиции? Вот вот прям серьезно? Все брошу и побегу?
Я понимаю мальчиков, которых на рынке рупь за пучок так гонять…
Чтобы поправить строчку, надо сначала ее найти. Среди тысяч других. А чтобы найти (по описанию дефекта типа «у нас тут должно быть так, а по факту вот этак») нужно этот код прочитать и понять что и как он делает.
Я вот не могу вспомнить сходу что-то такое приходилось делать…
Зато сплошь и рядом попадаются задачи, которые требуют некоторой фантазии для решения. Например как один запрос «в лоб», выполняющийся 3 секунды, разбить на несколько, выделить высокоселективные предвыборки на основе частотного словаря, уйти от использования медленных агрегатных функций, и в результате получить тот же результат, гарантированно укладываясь в 150-200мс. Вот это вполне реальная задача, решающая реальную проблему бизнеса.
Или как оптимизировать параллельную многопоточную обработку большого массива данных, которая занимает 15-17 часов, не трогая собственно обработчик, только за счет оптимизации механизма распараллеливания, уменьшив время обработки до 9-ти часов при том же количестве потоков.
Подобных задач на самом деле у нас встречается очень много. И для каждой требуется индивидуальный подход. И тут важнее умение человека думать нестандартно, чем знание им заученных алгоритмов и типовых задачек.
И лично в моей практике есть примеры людей, которые приходили совсем нулевыми, но буквально за полгода раскрывались в достаточно перспективного разработчика. Алгоритмические задачки таких отсеивают сходу, а вот вопросы на подумать скорее помогут распознать потенциал.
Мы же не про сферического коня в абсолютном вакууме, а про некий реальный процесс, работающий в окружении десятков, сотен, тысяч других процессов. И нам важна не только скорость, но и ресурсоемкость этого процесса. Что толку в его скорости, если он под себя отбирает столько ресурсов, что все остальное встает колом пока он работает?
В результате задача уже формулируется примерно так: «есть временное окно, в котором загрузка сервера составляет XX%. Необходимо уложиться в это временное окно так, чтобы загрузка сервера не превысила YY%»
А это уже те аспекты, про которые на олимпиадах нет.
Никаких тестов, просто поговорили — чем они занимаются, чем я занимался.
Интервьюеров тут тоже нет. Беседуют члены команды (тимлид, техлид, функциональный руководитель...) — те, с кем потом работать.
Испытательный срок есть, но это больше обучение — найти готового спеца на RPG и AS/400 у нас малореально…
Просто в голову как-то пришло само. Всплыло из глубин подсознания, а уж как оно там оказалось… Может и от Успенского (хотя не могу сказать чтобы когда-то серьезно им увлекался, хотя наверняка что-то его читал/слышал).
Уже работая там где работаю :-) получил неожиданно письмо от яндыхового рекрутера. Некоторое время пытался объяснить девочке что работу уже не ищу, что текущая работа устраивает и все такое. Как об стену горох. То ли ей за каждого кандидата, которого она на собес затащит, баллы идут вне зависимости от результата, то ли она действительно уверена, что яндых есть предел мечтаний для каждого разработчика.
Ладно,
договорились что встречусь по скайпу просто поговорить. Чем занимаются они, что умею я, что мне могут предложить…
Началось с того, что в назначенное время в скайп засунулся интервьюер и сказал что интервью переносится на полчаса. Ну ладно… Может форсмажор какой…
Через полчаса наконец состыковались. И началось сходу «я тут вам подготовил ряд тестовх заданий...»
Стоп. Мы так не договаривались. Я уже давно вышел из возраста юноши пылкого со взором горящим, олимпиадные задачки меня не интересуют — это вы для джунов оставьте. Мне интересно чем вы там вообще занимаетесь и есть ли там для меня какой-то интерес.
Хотите проверить — задавайте конкретные вопросы из жизни. Как решить вот такую проблему. Или с какой стороны я бы подошел вот к такой задаче. На понимание сути, так сказать.
В общем, проговорил ему что-то в этом плане и попрощался. Товарищ, похоже, так и не понял. Ну и бог с ним.
Что касается Опена и Либры… Чем они так лучше МС? Ну кроме того, что официально бесплатны?
Интерфейс МС не блещет, мягко говоря, но интерфейс Либры это уже за гранью добра и зла.
Берем документ МС (страниц этак на 300) в котором есть оглавление. Открываем в МС, включаем «область навигации» и получаем возможность быстро и удобно перемещаться по разделам. Открываем тот же документ и пытаемся открыть панель навигации. Что-то открывается, да. Но вид убогий, пользоваться дико неудобно, еще и съезжает все (сталкивался что структура вложенных заголовков съезжает, какие-то заголовки не показываются, какие-то дублируются...)
А с документами такими приходится работать много (BRD, FSD...) и без навигации быстро перемещаться по документу нереально.
Так что и рад бы либрой пользоваться, но производительность падает. И приходится МС…
Что касается стабильности… Win10 Pro 2004. Рабочий ноут не выключается с тех пор, как сел на удаленку (год уже как). Ну изредка просит перезагрузиться для наката каких-то обновлений. Но это за все время буквально несколько раз было. Не упало ничего не разу. Все работает быстро и стабильно.
Может быть потому, что не ставлю лишних обновлений? Только необходимые?
Устройство было крайне простым — статор представлял из себя воронку, в образующей которой располагались (под хитрым пространственным углом) сопла. Ротор — конус с отфрезерованными на поверхности лопатками. При подаче сжатого газа через сопла статора ротор приподнимался над поверхностью статора раскручивался.
Я у себя использовал стальной ротор диаметром 50мм. Раскручивал его сжатым воздухом (давление порядка 10бар) до скоростей 2500 Гц (да, именно, герц — 2500 оборотов в секунду). Больше не удавалось — там уже трение поверхности ротора о воздух, скорости истечения газа из сопла и прочие граничные условия. Но мне хватало. Работал с пропаном (в жидкой фазе), его рвало где-то на 1500 гц.
Поскольку физического контакта ротора со статором не было, никакой особой балансировки не требовалось. Ротор точился на обычном станке (ну для фрезировки лопаток некоторую оснастку пришлось придумать и сделать за неимением доступа к хорошим координатным станкам в то время и в том месте). Сверху на нем размещалась Z-образная ячейка с пропаном. Все. Вся балансировка происходила автоматически.
Остальное уже обвязка — высокочастоный стробоскоп на лампе ИСШ (сведодиодов мощных тогда еще не было) для наблюдения. Измерение скорости — отражающий сектор на поверхности статора + точечтный источник света + фотодиод + частотомер + схема синхронизации для стробоскопа.
Максимальные скорости вращения для такой конструкции были зафиксированы в одной из западных статей — 21000 Гц. Но там ротор был мелкий, 9мм, плюс сопла Лаваля (мне недоступно было технологически их изготовить) плюс крутили сжатым водородом (скорость истечения выше чем с воздухом).
А были еще ультрацентрифуги с магнитным подвесом, которые раскручивались вращающимся магнитным полем. Попадалась статья из какого-то Пермского НИИ где товарищ шарики для шарикоподшипников на прочность испытывал в такой системе. Он в вакууме шарик в магнитном подвесе магнитным полем раскручивал до 360кГц (после чего он принимал форму геоида и затем разрушался).
А есть еще газовые ультрацентрифуги, применяемые на производствах по разделению изотопов урана (рабочее тело — UF6 — гексафторид урана, в центрифугах разделяется на фракции, обогащенные по 235-му и 238-му изотопам). На УЭХК (Уральский Электро-Химический Комбинат целый завод на таких работает, причем, первые центрифуги там были запущены в 1957-м году (до этого использовался газодиффузионный метод), а с 1961-го года центробежный метод введен в промышленную эксплуатацию.
Так что вся эта история про необходимость заказа на западе, хитрые подвесы выглядит как-то не очень правдоподобно. Были у нас свои разработки.
От линуха бог миловал, но сейчас работаю под AS/400 (IBM i) — доки от IBM (Knowlege Center) на порядок хуже MSDN. И написаны кривым языком и с примерами так себе. Правда, и система посложнее винды и линуха вместе взятых…