На работу за 3 000 миль
Правдивая история из личного опыта нашего автора Snoofle. [Оригинал]
Много десятков лет назад оборонный подрядчик DefCon Inc работал на армию США и пытался получить новый контракт на создание какого-то приложения, применяемого в бою. Компания хотела продемонстрировать в своём предложении, что у неё хватит персонала для выполнения этого проекта. Поэтому она наняла более тысячи разнообразных программистов, руководителей проектов, менеджеров и так далее. Военные, изучавшие различные коммерческие предложения, увидели кучу новых сотрудников, абсолютно незнакомых с необходимыми процессами, процедурами и требованиями, поэтому передали контракт другой фирме. Подрядчик, со своей стороны, уволил всю эту тысячу человек.
Спустя несколько месяцев возник ещё один подобный контракт. Компания снова наняла тысячу человек, чтобы показать, что у неё есть персонал. Ещё через несколько месяцев контракт снова был передан другому подрядчику, и компания снова уволила всю тысячу.
На протяжении двух лет такое повторялось несколько раз.
После всего этого основная масса доступных для найма сотрудников уже была в курсе об очень коротком цикле найма-увольнения в компании, поэтому подрядчик не мог привлечь никого, кроме новичков, только что выпустившихся из учебных заведений. Наконец, какого-то руководителя из верхнего звена озарило, что все эти люди только что из-за парты гораздо дешевле, чем опытные разработчики в штате компании, и те, кого компания нанимала-увольняла ради контрактов. Поэтому он выпустил приказ, что весь опытный персонал компании должен быть заменён
Теперь, когда расходы на зарплаты значительно снизились, и они чертовски разозлили всех опытных разработчиков-кандидатов, компания могла увеличить постоянный штат, не раздувая бюджет на зарплаты. Ей можно было нанимать только молодых, неопытных разработчиков, чтобы наконец-то получить контракт.
К сожалению, у всех этих молодых разработчиков было очень мало опыта, а в фирме больше не осталось побывавших в окопах людей, способных их обучить. Поэтому результатом их двухлетнего контракта стал этого ненадёжный проект, который часто вылетал, вёл себя непредсказуемо и который невозможно было модифицировать. Подобные свойства нежелательны, когда имеешь дело с системой, которая должна стрелять и взрывать.
В какой-то момент один из высших руководителей осознал, что произошло, заставил компанию прекратить вести себя, как слон в посудной лавке, и нанять высокооплачиваемых консультантов. К сожалению, высокооплачиваемые консультанты хорошо помнили о цикле найма-увольнений и не хотели иметь ничего общего с организацией. Спустя какое-то время компании пришлось существенно улучшать условия найма, пока наконец несколько опытных работников согласилось устроиться на работу в качестве штатных сотрудников. Это произошло в Нью-Джерси.
После того, как руководство назначало этих новых сотрудников на проект для ускорения работы над ним, новые сотрудники сказали «Постойте-ка, посередине этого проекта есть огромная дыра!» Руководство ответило, что эта часть проекта засекречена, и может изучаться только людьми с допуском к секретной информации и только на предприятии в Калифорнии. Были запрошены и получены соответствующие допуски, после чего опытных сотрудников отправили на две недели на предприятие в Калифорнии.
Прежде чем соглашаться на поездку, разработчики хотели узнать, как они смогут получать доступ к материалам после изучения. Ведь доступ возможен только на месте, в Калифорнии, а все сотрудники живут и работают в Нью-Джерси. Им сказали, что о подробностях они узнают в Калифорнии.
Ну ладно, все они прилетели на западное побережье, заселились в отели и поехали в офис.
В тот момент им сообщили обо всех проблемах, которые необходимо устранить. В четверг второй недели работы было решено, что для выполнения всех необходимых модернизаций необходимо примерно два года работы. Разработчики опять спросили: «Как же мы будем получать доступ к материалам из Нью-Джерси?» Менеджеры ответили, что вся работа должна выполняться на месте, и они будут оставаться в Калифорнии в течении следующих двух лет. Начиная с ближайшего понедельника.
Но, постойте у них же не было возможности обсудить это с семьёй! Как отсутствие 90% времени одного из родителей повлияет на детей? Захотят ли они жить в гостиницах и аэропортах в течение двух лет? Какого хрена компания не наняла сотрудников на месте, в Калифорнии, а занималась этим в Нью-Джерси?
Оказалось, что поскольку подрядчик находится в Нью-Джерси, нанимаемый им персонал тоже должен быть зарегистрирован там же. Разумеется, если бы об этом сообщили до трудоустройства, то большинство сотрудников (если не все из них) отказалось бы от работы. Если бы они знали, то никто из работников не поднялся бы на борт самолёта и не полетел бы в Калифорнию для ознакомления с проектом.
Можно и не говорить, что остаток рабочего для менеджеры втирали о необходимости жертв ради компании, а разработчики задавались вопросом: «Какого чёрта?» Вечер четверга был занят бесконечными звонками домой. Утром пятницы все сотрудники уволились и направились в аэропорт, чтобы вернуться домой.
Представители армии повели себя достойно и с пониманием отнеслись к тому, что люди не хотят бросать свои дома и семьи на два года. Однако стали гораздо жёстче, когда дело дошло до разговора с подрядчиком и до выполнении его обещаний о наличии опытного персонала на месте работы.
В результате контракт с подрядчиком был расторгнут, а на его место наняли для наведения порядка нового.
Случай отказа
[Оригинал]
В первый день на новой работе Себастьян не был особо воодушевлён. Он уже многое повидал и набрался равнодушия и пессимизма. Эта новая работа не должна была отличаться ни одной другой: куча надоедливых коллег, плохо продуманных требований, старых кодовых баз, полных спагетти-кода. Но она хорошо оплачивалась, а он устал от своей старой группы, ему надоели одни и те же привычные лица. Поэтому он внутренне приготовился к слегка новым оттенкам той же офисной политики и муторных заданий.
Он даже особо не расстроился, зайдя в ИТ-отдел за своими учётными данными и услышав жужжание и щёлканье старых серверов Packard Bell. Себастьян просто опустил на несколько уровней свою планку требований к рабочему компьютеру, и вернулся в новый офис. Да, его должность подразумевала собственный офис и соответствующую оплату. Ради этого он мог смириться со многим другим.
Его логин сработал с первой попытки, что было приятной неожиданностьюю. Он ожидал Windows XP; когда загрузилась Vista, он не был уверен, стоит ли ему радоваться более новой ОС, или ужасаться тому, что это Vista. Завершив получение полномочий администратора и урезав UAC, он даже на какое-то время мог притвориться, что это «семёрка». «Чтобы испугать меня, потребуется что-то большее», — подумал он и запустил Outlook.
Во входящих уже была почта: несколько приветственных писем с информацией для новых сотрудников, а также первая задача от его менеджера. Впечатлённый, если не сказать больше, эффективностью назначения задач, он открыл письмо от своего нового руководителя.
Первое письмо было примерно таким:
Здравствуйте, Себастьян, добро пожаловать в нашу идеально отточенную рабочую среду. В ней всё делается правильно. При создании проектных документов вы будете работать с Bonk-Word (веб-приложение для документирования компании IBM). Не забывайте часто сохранять работу! При аварийном завершении Bonk-Word вам необходимо будет написать письмо в отдел ИТ для его перезапуска.
Компания составляет проектную документацию. Пишите всё в страдательном залоге, используйте фиолетовый для обозначения заголовком глав и зелёный — для заголовков разделов. Документы ежедневно проверяются президентом компании в 9 утра, так что будьте к этому готовы. Ошибки в заголовках станут «чёрной меткой» в вашем личном деле.
Начните с проектирования решения проблемы со шрифтами на Macintosh, которую мы не можем решить четыре года. Завтра к 9 часам утра у вас должен быть готовый проектный документ из шести страниц. Спасибо.
«Шесть страниц на завтра?», — забеспокоился Себастьян. «Наверно, я возрадовался эффективности слишком рано. Ну, по крайней мере, не будет скучно», — он хрустнул костяшками пальцев, открыл Bonk-Word и начал разбираться с так называемыми проблемами со шрифтами.
Первое, что он выяснил — менеджер не шутил о частом сохранении. К концу дня он мысленно делал ставки: что свалится первым — Bonk-Word или сама Vista. Оба они крашились примерно через каждые полчаса. Но ведение статистики вылетов на листочке почему-то успокаивало Себастьяна. Оно напоминало ему: в мире что-то ещё работает. Простейшие математические действия не впечатляли, но были надёжными. Регулярными. Стабильными.
Возможно, в этом офисе Себастьян чувствовал себя одиноко. Но он был тихим и отдельным. Пусть постоянные вылеты раздражали, но Себастьян всё-таки двигался вперёд. Он задержался на работе, чтобы изучить разнообразную литературу, посвящённую рендерингу шрифтов, в том числе спецификацию Postscript, сопроводительную литературу с рекомендациями по его использованию и информационные центры в World Wide Web, созданные для коллекционирования мудрости лучших умов отрасли в знакомом и удобном формате вопросов и ответов. Он пространно описал в документе «создание программы на Python для рендеринга каждого символа». Он потратил две страницы на описание того, что можно было рассказать в двух словах.
«Если им нужно шесть страниц, они получат шесть страниц», — думал Себастьян.
Первый день оказался странным, но Себастьян видел, что вполне выдержит это в течение как минимум нескольких лет. Он закончил работу, вышел из здания (которое подозрительно пахло старым кожаным нижним бельём) и медленно подошёл к своему «бесплатному месту на парковке» (ещё одно преимущество, оправдывающее эту работу в его глазах). Медленно — потому что стоянка была совершенно разъедена ржавчиной, и во многих местах бетон полностью отвалился, обнажив арматуру пола и колонн.
Следующим утром, ровно в 9:00, Себастьян находился в офисе своего менеджера, ожидая первой проверки проекта от президента компании, позвонившего по телефону. Себастьян чувствовал себя некомфортно от разговора с президентом напрямую, учитывая то, что в к компании было шестьдесят сотрудников, но ему пришлось это вытерпеть.
«Я сделал, как просили, и в нужном объёме. Скорее всего, это просто формальность, после которой я смогу приступить к работе».
Спустя час униженный и измотанный Себастьян вернулся в свой офис. В его ушах всё ещё звенела полученная им абсурдная, но жестокая критика. По словам президента, его заголовки разделов были едва «зеленоватыми», а не зелёными, как требовала компания, а заголовки глав — непростительно «красноватыми» вместо ожидаемо фиолетовых. Кроме того, ему недвусмысленно сообщили, что отладить шрифты с помощью Python «невозможно». Вместо него Себастьяну приказали работать на C++ и использовать «чудесные» программные библиотеки компании. Ожидая звонка президента, менеджер Себастьяна расхваливал документ, но во время проверки не сказал ни слова, неотрывно смотря на кирпичную стену за своим столом.
Себастьян закрыл дверь офиса, отгородившись от остальной части компании. Он сел на свой роскошный кожаный стул и уставился на экран едва работавшего компьютера. Он снова открыл свой документ, а потом перезапустил машину, потому что Vista решила вылететь. Когда компьютер снова загрузился, он проверил свой банковский счёт, подумал о платежах по ипотеке, и сжал зубы.
«Ну ладно», — сказал он вслух в пустом офисе. «Взглянем на эти библиотеки».
Первое, что он начал искать — это документация. Естественно, что в такой помешанной на документах компании документация к «чудесным» библиотекам должна быть точно набрана правильным шрифтом с идеально точным оттенком, с правильными заголовками глав и названиями разделов. Но документации… не было. Была уйма проектных документов с идеальным зелёным и фиолетовым цветами. Но в них описывалась только методология разработки библиотеки и ничего не говорилось об её использовании.
«Я что, схожу с ума?», — спросил себя Себастьян, когда машина перезагрузилась в третий раз. «Возможно, код самодокументированный...»
Он испытал ужас, но особого удивления не было: библиотеки состояли из плохо продуманных обёрток строковых функций из стандартной библиотеки.
Несмотря на постоянные фиаско, Себастьян держал удар. Его ежедневно вызывали для очередного раунда словесных запугиваний. Компания за четыре года не могла справиться с этой шрифтовой проблемой; тем не менее, ничто из предлагаемого им не устраивало президента. Себастьян отказался от собственной библиотеки компании, начав решать проблему на известном ему Python; в конце концов, если его всё равно будут гнобить, то зачем делать то, что тебе говорят? Но что бы он ни применял: собственный тестер на Python, или тестер Microsoft, или Apple, или Adobe — шрифт оставался полным хаосом. 488 неискоренимых, неисправимых, не решаемых заплатками конструктивных ошибок.
Президент категорически отказывался признать правду. Он утверждал, что это вина Себастьяна, ведь тот не использует великолепные библиотеки C++.
Исчерпав все варианты, Себастьян оставил ключ от ржавеющего гаража на столе менеджера вместе с заявлением об уходе. Он попрощался со своим милым офисом и адской машинкой, которую выдавали за компьютер. Глубоко вдохнул, в последний раз почувствовав муторный запах кожи и вышел, окончательно и бесповоротно.
Почему-то он сомневался, что будет скучать по компании.
От такого здравоохранения можно заболеть
[Оригинал]
В любой отрасли есть информация, которую необходимо переносить между несовместимыми системами. Если вы жили жизнью праведника, то эти системы были просто разными приложениями на одной платформе. Однако если вы отклонились от благого пути, то эти системы были написаны на разных языках для разных платформ, работающих в разных операционных системах с разным порядком следования байтов. Представьте какое-нибудь Java-приложение в Safari под какой-нибудь версией Mac OS, которому нужно обмениваться данными с какой-то версией .NET под какой-нибудь версией Windows, которой, в свою очередь, нужно общаться с какой-то версией COBOL с двоичным кодом EBCIDIC, работающей на каком-нибудь мейнфрейме.
Задолго до того, как кто-нибудь мог вообразить подобный кошмар, мы работали с SGML, который
К сожалению, они с задачей не справились.
В отрасли здравоохранения какие-то работающие с сopen-source ребята создали проект (H)ealthcare (API), или HAPI, который по сути является объектно-ориентированным парсером текстовых сообщений отрасли здравоохранения. К сожалению, они, похоже, страдали от синдрома «не знаю, когда остановиться».
Вместо того, чтобы реализовать обобщённый парсер, который просто разбивает строку с разделителями или строку фиксированного формата на список из значений текстовых полей, последняя версия реализует 1205 разных парсеров, каждый из которых имеет собственную высокоуровневую структуру данных. Самые высокоуровневые структуры имеют десятки подструктур. Каждый парсер имеет один или несколько методов доступа к каждому полю. Поле может быть единственным экземпляром или списком экземпляров, и в этом случае необходимо программно определять, какой метод доступа использовать.
Это API с приблизительно 15 тысячами вызовов методов! О чём вообще думали эти разработчики?
Например, класс: EHC_E15_PAYMENT_REMITTANCE_DETAIL_INFO может иметь от нуля и более product service разделов. Поэтому я сразу же начинаю думать о каком-нибудь массиве или списке. Поэтому вместо чего-то наподобие такого:
EHC_E15_PAYMENT_REMITTANCE_DETAIL_INFO info = ...;
List<EHC_E15_PRODUCT_SERVICE_SECTION> prodServices = info.getProductServices();
// итерируем
… нам требуется выполнить что-то из этого:
// Получаем подструктуру
EHC_E15_PAYMENT_REMITTANCE_DETAIL_INFO info = ...;
// Получаем из подструктуры встроенные product-service
// ...если мы точно знаем, что в сообщение он только один:
EHC_E15_PRODUCT_SERVICE_SECTION prodSvc = info.getPRODUCT_SERVICE_SECTION();
// ...если мы не знаем, сколько их будет:
int n = infos.getPRODUCT_SERVICE_SECTIONReps();
for (int i=0; i<n; i++) {
EHC_E15_PRODUCT_SERVICE_SECTION prodSvc = info.getPRODUCT_SERVICE_SECTION(i);
// используем это
}
// ...или можно просто взять их и выполнить итерацию
List<EHC_E15_PRODUCT_SERVICE_SECTION> allSvcs = info.getPRODUCT_SERVICE_SECTIONAll();… и нужно вызвать нужный метод, иначе рискуешь получить исключение. Но если существует множество способов выполнения одной задачи через API, то возникает множество способов её выполнения в коде с помощью API, что неизбежно приводит к проблемам.
Можно сказать: «Да ладно, всё не ТАК уж плохо»; достаточно использовать то, что тебе нужно. Но потом ты осознаёшь, что некоторые из этих структур данных встроены на десять и более уровней вглубь, у каждой есть десятки подструктур и/или полей, и у всех них несколько методов доступа. Да ещё у всех них реально длинные названия. А потом ты осознаёшь, что разработчики HAPI устали печатать текст и начали использовать для всего сокращения с такими понятными названиями структур данных, как LA1, ILT и PCR.
API пытается быть полезным: если он не находит в поле, парсинг которого ты запрашиваешь, ожидаемого, то он выбрасывает исключение, и тебе нужно самостоятельно разбираться, что пошло не так. Разумеется, при этом подразумевается, что ты уже знаешь, что тебе передаётся в потоке данных.
Аноним работал в здравоохранении и занимался поддержкой библиотеки, обёрнутой вокруг HAPI. Ему регулярно давали задания (на выполнение которых отводилось по несколько недель) по простому парсингу одного дополнительного поля. Потратив кучу времени на пережёвывание томов документации по API, он написал общий парсер из одного класса в 300 строк с несколькими split, substring, parseDate и parseInt, в качестве замены всего интерфейса.
После этого добавление нового поля стало занимать не больше десяти минут.
Комментарии (97)
roscomtheend
04.12.2018 13:38Виста не была столь плоха, больше похоже что собирали компьютер и настраивали её те же, кто писал странные библиотеки. И Себастьян ну очень упорный, я бы после цветового оформления отказался.
lightman
05.12.2018 10:43И Себастьян ну очень упорный, я бы после цветового оформления отказался.
Вы не нацелены на результат, мы вам перезвоним.
tangro
05.12.2018 12:50Кстати да, в Висте, по сути, произошло много важных и полезных изменений в ядре ОС. Семёрка лишь добавила рюшечек и пофиксила явные баги UI.
AndrewTishkin
05.12.2018 14:23Вспомнил, как лет 12 назад скачивал, распечатывал и с упоением читал официальное русскоязычное трёхсотстраничное руководство по Висте. Описывался не только интерфейс, а и некоторые «подкапотные» фишечки.
Ещё статьи Руссиновича тогда на меня впечатление произвели, особенно смаковал его
Управление учетными записями пользователей Windows Vista: взгляд изнутри
PsyHaSTe
06.12.2018 13:25Виста начала давать по рукам за попытки играть с объектами ядра. Плюс известная история про баг в определении версии винды
if (Major >= 5 and Minor >= 1) ..., который перестал работать с вистой6.0, но работал с семеркой6.1. Можно было бы подумать, что это байка, но в винда реально врет о своей версии, если не проставить магический гуид в манифесте типа "я знаю, что ты врешь". Например, десятка будет упорно врать, что она семерка, пока не пропишешь<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>в манифесте.
striver
04.12.2018 14:42Да, один знакомый улетал в другую страну на 2 месяца, чтоб внедрить софт, который разрабатывали. Но, чтоб 2 года…
safari2012
04.12.2018 18:49Как-то я работал в одной компании и ездил в командировку на крайний север на обследование на пару дней. Дело было в декабре, стоял мороз за 40. Начальник отдела, что нас принимал, возил нас на своей машине из отеля на объект и обратно. Как-то раз, проезжали мимо группы людей в затянутых по самый нос капюшонах алясках, которые медленно и уныло брели в отель через пургу. Начальник сказал — а это коллеги из компании XXXX уже полгода воюют с нашим отделом YYYYY, пытаясь внедрить систему ZZZZZ и конца и края не видно. Я тогда их очень сильно пожалел…
А потом случилось так, что теперь теперь сам тут работаю :)befart
04.12.2018 19:40Для внедренцев-консалтеров абсолютно нормально быть в командировке полгода, бывает, и дольше. Конечно, обычно они летают домой, и часть времени работают в своем офисе, но все-равно в полях — основная работа.
shoorick
04.12.2018 22:43Одного моего знакомого в перестроечное время отправили в командировку в Африку испытывать уральскую дорожную технику. Ненадолго, на месяц. Потом попросили ещё побыть там, ибо мало было специалистов со знанием французского. Потом ещё и ещё… В итоге в Африке он год проторчал.
Deosis
05.12.2018 07:57Старые юмористические эпизоды "Железный капут" про забытый секретный танк.
Самое то, что можно посмотреть в затянувшейся командировке.
vedenin1980
04.12.2018 15:11+1Это API с приблизительно 15 тысячами вызовов методов! О чём вообще думали эти разработчики?
О том, что никто никогда не уволит единственного человека, знающего как работают 15 тысяч методов этого API? Сознательное переусложнение системы, чтобы фирма/разработчик стал совершенно незаменимым, увы, встречается достаточно часто.
Скорее всего ребята написавшие этот HAPI получают огромные деньги на обучениях и консультациях пользователей API. Просто это такой бизнес.
CAJAX
04.12.2018 15:25Хахах, однажды нарвался на компанию в которой гендир лично проверял оттенки кнопок, ни разу не обратив внимание на функционал. Так же он был категорически против специализированных баг-трекеров и все проекты велись в трелло, где срочность задачи он определил цветом. Красный — минимальный приоритет, фиолетовый — наивысший.
SpiritOfDarkDragon
04.12.2018 15:36+6похоже он просто не с Землив Доктор Кто был момент, где говорилось, что красный цвет опасности только на Земле, во всей остальной галактике же эту роль выполняет фиолетовыйvlx
05.12.2018 10:46Градация метеорологических угроз в некоторых странах этой планеты: зеленый<желтый<красный<лиловый (не совсем фиолетовый, но близко)
fedorez
04.12.2018 17:42+4просто видимо ему надо было показать кто в доме хозяин, а в кнопках это было проще всего)
когда я учился в ТРТУ, был у нас один очень своеобразный преподаватель. ну знаете, из тех кто «то что вы принесли мне лабу(курсовик) это просто повод для начала разговора». сдавали с 8 утра до 11 ночи. сдавали по пять раз. приходили пересдавать утром и уходили вечером потому что просто не смогли зайти на пересдачу (он за день принял всего троих из толпы (сдали двое)).
но тем не менее, имелся верный хак. нужно было организовать рояль в кустах — поместить явную локальную нелепицу и пару нарушений правил оформления на видное место. он это заметит, раскатает тебя в блин… ты посидишь с сокрушённым видом, пойдёшь в общагу, достанешь заранее напечатанные листы с правильным вариантом, вставишь в отчёт/курсовой и через пару дней придёшь на пересдачу. посмотрит — ну вот, давно бы так — давай зачётку.
главное чтоб не забыл что он тебя уже вытрепал, а то начнётся по новой)
подготовка к жизни в подобных компаниях, блин)befart
04.12.2018 19:49+5В госкорпорации одной так и делается. В документ нужно накидать очевидной херни, чтобы начальники могли их повычеркивать с чувством собственной значимости, ты потом это переделываешь, и несешь на подпись Иван Иванычу с благодарностью, какой он внимательный и мудрый. Иногда они что-то пропускают, и эта чушь остается жить в финальной версии.
kolyan222
04.12.2018 22:04+2Напомнило как я в своё время чертежи сдавал преподавательнице на первом курсе.
5 раз я снова и снова выслушивал надуманные недочёты и вносил изменения по одному из чертежей.
Дошло до того, что сдал я этот чертёж только в 6 раз, причём просто принеся свой изначальный вариант работы.
Я тогда ещё получил такой ответ преподавательницы: «Другое дело. Вот так бы сразу и начертил.»
Говорить, что я собственно так сразу и начертил я конечно не стал)Am0ralist
04.12.2018 22:35Моё любимое, как меня пытались на экзамене завалить, но в итоге ее рука дрогнула и она написала в зачетке ОТЛ на автомате, после чего произнесла: «но всё равно придете пересдавать», указала ОТЛ в ведомости… Я ответил «Конечно»!
А вот староста раз десять бегал, пока другой наш математик ей на кафедре прилюдно не сказал, что даже окружающие преподы вокруг уже уверены, что тот на ОТЛ знает, кончай мол доставать парня.MTyrz
04.12.2018 23:16+2По вольной ассоциации мне вспомнилась прямо противоположная история.
Кафедра зоологии позвоночных, зачет по вирусологии. Преподавательница слушает студентов, слушает, морщится, но зачеты ставит. Если задуматься, то и вправду зоология позвоночных от вирусологии удалена достаточно, чтобы не пригодиться практически никогда.
Очередной студент сообщает, что вирусы размножаются делением. Преподавательница светлеет лицом.
— Знаете, я с утра сижу и думаю, кого бы с вашей кафедры заставить выучить вирусологию?..
Вам повезло!
Acuna
05.12.2018 01:19Если вдруг препод не может исправить оценку в зачетке или в ведомости (насчет последнего даже не знаю если честно возможно ли такое), то можно было бы так и сказать. Вот была бы песня, проучили бы ее на всю оставшуюся жизнь)
kolyan222
05.12.2018 09:53Это был не экзамен/зачёт, а лишь сдача одного из десятка чертежей, которые необходимо было выполнить для получения возможности приступить к сдаче зачёта. Так что её лучше было не злить)
stdpmk
05.12.2018 14:06У нас был случай в университете. Сдавали программу на C++, она была одна и та же для всех. Преподаватель проверял только результат программы. Входные данные тоже были одинаковые и ответ одинаковый. Ну, некоторые ребята пришли на зачет, не ходя на пары особо, программы у них не было. По быстрому сделали программу, которая
просто выводит ответ в консоль: std::count << ответ. )
Когда он узнал в конце о таком обмане, был, мягко говоря, не доволен.
easty
05.12.2018 21:54Как писно с моей бывшей конторы. Только чуть отличается. Сдаёшь регламент в архитектурный штаб. Они кучу пометок и коментов в документ вставляют. Удаляешь всю чушь, что они в ответ написали, ждёшь два часа и снова отправляешь. С 90% вероятностью документ согласовывают.
DocJester
05.12.2018 07:39Так ведь радуга.
У вас гендир, видимо, использовал цвета радуги, чтобы оценить степень приоритета.
chimvl
04.12.2018 18:35информационные центры в World Wide Web, созданные для коллекционирования мудрости лучших умов отрасли в знакомом и удобном формате вопросов и ответов
самое поэтичное определение stackoverflow которое можно придумать))
Thoth777
04.12.2018 18:54+5В российских компаниях такое тоже есть.
Устроился на работу в крупную контору,
Дали брендовый комп с мизерным количеством оперативной памяти, на котором IDE запускался пару минут, и работал адово медленно.
Зато безопасность/секьюрность — были на высшем уровне, работа была в винде (а я, вообще-то разраб под никсы), чтобы что-то поставить, надо отловить специального человека, только он мог поставить нужный софт. Выход в интернет был тоже непростой, приложения типа git и т.п. не могли просто так взять и получить что-то с гитхаба.
Работал 2 недели, все эти 2 недели ждал новые плашки памяти (которые не абы какие, а какие-то фильдиперсовые, просто так не купить) и заодно нормальный хард на 1тб.
Поставить никсы? Надо согласовать, жди, и когда-нибудь дождешься.
Поставить нормальный комп? У нас по регламенту только такие, жди апгрейд.
По прошествии двух недель, устав от бесконечных тормозов вверенной мне тачки, а также от болтовни сотрудников, которые находились со мной в одном помещении, и колторые не прекращали общаться на отвлеченные темы, я решил что хватит.
И да, ежедневные отчеты о проделанной работе.
Так-то и з/п предлагалась хорошая, но я осознал, что уставать можно не только от напряженной работы, но и от монотонного ожидания пока отвиснет IDE.
SquareRootOfZero
05.12.2018 05:09Слышал мнение, что разработчику надо давать самый-самый медленный компьютер, чтобы вот едва тянул на пределе, тогда этот разработчик будет всё оптимизировать и писать быстрые программы. А то понапишут, ироды, а оно потом тормозит. Подумал: «Хорошо, что такие фантазёры не бывают начальниками.» Ну, щас — не бывают, встретил как-то и начальника, с гордостью рассказывающего о подобной практике (контора была не айтишная, просто бизнес с небольшим IT-отделом, немного программирующим для внутренних нужд, но тем не менее).
Dioxin
05.12.2018 11:41Слышал мнение, что разработчику надо давать самый-самый медленный компьютер, чтобы вот едва тянул на пределе, тогда этот разработчик будет всё оптимизировать и писать быстрые программы
И ждать окончания компиляции часами? Это тоже самое что пересадить таксистов на запорожцы.
Просто ТЗ должно быть правильное и тестирование.
Когда в лохматые годы я верстал страничку в нашей конторе то после проверял как она смотрится во ВСЕХ браузерах и если есть косяки то устранял.
Тогда еще был жив Netscape Navigator.
striver
05.12.2018 11:59Предлагаю аналогию. Вместо высокоточных роботов, дать рабочим в руки молоток и зубило и предложить им делать микропроцессоры. Есть мнение, что чем больше молоток, тем больше частота процессора выйдет у рабочего.
RiseOfDeath
05.12.2018 12:33Глупости. Чтобы программа работала «нормально» на «слабом» железе, надо
- Определиться что есть «слабое железо» (т.е. сформулировать требования к оборудованию, на котором это будет работать.)
- Требовать чтобы оно так было (т.е. вписать сие в ТЗ)
- Тестировать на «слабом» железе (т.е. проверять соответствие результата ТЗ)
- Ну и крайне желательно чтобы это вообще было осуществимо (т.е. чтобы ТЗ было боле-менее реалистичным. Рендерить фотореалистичную анимацию в реалтайме на древнем компе не возможно)
Все, больше ничего. И нечего разработчику придумывать лишние неудобства в виде слабого компа, это лишь будет его раздражать напрасно и снижать производительность.
Wayfarer15
04.12.2018 19:38+2Очень повесилило по поводу HAPI, как сама статья, так и комментарии. Похоже народ не до конца догоняет о чём пишет. Для начала, приведённая в статье PAYMENT_REMITTANCE_DETAIL_INFO — это опциональная повторяющаяся группа, состоящая из пары обязательных сегментов, нескольких обязательных повторяющихся сегментов и одного опционального повторяющегося сегмента внутри группы. Каждый из сегментов содержит свои поля данных которые также могут повторяться.
Соответственно группа может быть пропущена, может быть одна, а может быть множество. Поэтому HAPI использует разные подходы чтобы вытащить из подобных структур данные — без итерации, с итерацией и пр.
И, оказывается, это можно заменить на 300 строк кода! Жаль в оригинале ссылки нет на этот шедевр.
Я правильно понял, что более 100 типов HL7v2 сообщений, созданных из комбинации почти 200 сегментов с использованием около 90 типов данных (многие из которых сложные), да всё это ещё и помноженное на версии от 2.1 до 2.9 — и это всё в 300 строк кода! Вы серьёзно!?
Или аноним тупо распарсил EHC_E15 (Payment/Remittance Advice) сообщение согласно спеке какого-нибудь LabCorp для одной единственной версии стандарта HL7v2? Если именно так, то это можно и в две строчки сделать — берём HAPI контекст, парсим в XML. Далее используем всё что угодно, вплоть до E4X чтобы достучаться до каждого поля.Rsa97
04.12.2018 22:45Соответственно группа может быть пропущена, может быть одна, а может быть множество. Поэтому HAPI использует разные подходы чтобы вытащить из подобных структур данные — без итерации, с итерацией и пр.
А почему нельзя сделать один метод, который вернёт пустой список, список из одного элемента или список из нескольких элементов, соответственно?Wayfarer15
04.12.2018 23:28Да запросто. А теперь представь, поскольку стандарт делается не под конкретного Васю Пупкина из 2-ой клиники, что у пациента может быть больше чем одна имя-фамилия (Pablo Diego Jose Francisco de Paula Juan Nepomuceno Maria de los Remedios Cipriano de la Santisima Trinidad Ruiz y Picasso), а также несколько идентификаторов, а также несколько телефонов, адресов (а в адресе может быть несколько названий для улицы), медикаментов и чего угодно. А может и не быть. Вместо поля данных может быть NullFavour или null индикатор. Если всё это возвращать списками, то за-итератишься по самые помидоры. Поэтому HAPI позволяет вытаскивать данные и так, и сяк, и наперекосяк. И вероятно поэтому HAPI считается standard de-facto парсинг для HL7v2, а таперь и для FHIR сообщений.
Krypt
05.12.2018 00:24> и это всё в 300 строк кода!
> поскольку стандарт делается не под конкретного Васю Пупкина из 2-ой клиники,
Вы только что ответили на свой вопрос
mayorovp
05.12.2018 10:00Так такой метод там, вообще-то, есть! Называется getPRODUCT_SERVICE_SECTIONAll, его даже автор найти смог…
tbl
05.12.2018 09:04Какой же комитет такие форматы сознательно пишет и аппрувит? Или это все эволюционные наслоения на говно мамонта?
Небось, до сих пор длина текстовых полей ограничена в 76 или 80 символов, чтобы на перфокарту влезло.
Чую по названиям структурных типов, без кобола здесь не обошлось.
mayorovp
05.12.2018 10:07Мне в этом API другое "нравится" (в C#-версии).
Вот так находится количество секций (код я упростил для лучшего понимания):
public int PRODUCT_SERVICE_SECTIONRepetitionsUsed { get { return this.GetAll("PRODUCT_SERVICE_SECTION").Length; } }
А вот так возвращается последовательность этих секций:
public IEnumerable<EHC_E15_PRODUCT_SERVICE_SECTION> PRODUCT_SERVICE_SECTIONs { get { for (int rep = 0; rep < PRODUCT_SERVICE_SECTIONRepetitionsUsed; rep++) { yield return (EHC_E15_PRODUCT_SERVICE_SECTION)this.GetStructure("PRODUCT_SERVICE_SECTION", rep); } } }
Никого ничего не смущает?
balexa
05.12.2018 15:49public int PRODUCT_SERVICE_SECTIONRepetitionsUsed
{
get
{
return this.GetAll(«PRODUCT_SERVICE_SECTION»).Length;
}
}
Я не пишу на шарпе, но это очень сильно походит на автогенеренный код. Если это так — то ничего страшного.mayorovp
05.12.2018 15:57Квадратичный алгоритм на пустом месте плох независимо от способа создания кода.
balexa
05.12.2018 17:05Отвечу сразу вам и tbl
Внезапно не всегда O(n^2) это плохо, и не всегда O(n) хорошо.
На примере той же сортировки — квадратичный Insertion sort более эффективен на небольших масивах, чем квазилинейная быстрая сортировка. Вплоть до того, что последняя фаза быстрой сортировки во многих библиотечных реализациях делается вставками.
Так и тут — я бы не стал утверждать заранее, что код плохой. Если мы точно знаем что длина PRODUCT_SERVICE_SECTION не может быть больше например 5, то возможно это самый оптимальный с точки зрения расхода памяти/скорости/простоты генератора (что весьма немаловажно) способ.
А может быть конечно что это просто говнокод. Это весьма вероятно, согласен.
Но я бы не стал вот так категорично утверждать что O(n^2) — это всегда ужасно.mayorovp
05.12.2018 17:40Нет никакого смысла в генерации нового массива элементов только для того чтобы узнать его длину на каждой итерации. Даже если длина не больше 5.
mayorovp
06.12.2018 12:03+1Могу я узнать причину минуса? Кто-то считает, что узнавать длину массива за O(N) на каждой итерации — нормально?
Или нужно больше аргументов? Пожалуйста. Вот реализация метода GetAll:
public virtual IStructure[] GetAll(String name) { AbstractGroupItem item = GetGroupItem(name); if (item == null) throw new HL7Exception("The structure " + name + " does not exist in the group " + GetType().FullName, HL7Exception.APPLICATION_INTERNAL_ERROR); IStructure[] all = new IStructure[item.Structures.Count]; for (int i = 0; i < item.Structures.Count; i++) { all[i] = item.Structures[i]; } return all; }
Как видно, он каждый раз создает и заполняет новый массив — только ради того, чтобы у этого массива взяли длину, а сам массив выкинули. И это делается на каждой итерации. balexa, вы точно считаете что это нормально?
К слову, в базовом классе уже есть правильный метод, который не делает этой всей ерунды — только кодогенератор забыл его вызвать!
public int PRODUCT_SERVICE_SECTIONRepetitionsUsed { get { return this.currentReps("PRODUCT_SERVICE_SECTION"); } }balexa
06.12.2018 13:10balexa, вы точно считаете что это нормально?
Я не говорил что это — нормально. И минус вам не я ставил. Не надо приписывать мне утверждения, я GetAll только что увидел.
Да, получение длины на каждой итерации — косяк, тут я согласен. Оптимизатор не убирает это?tbl
07.12.2018 01:48и не уберет, если внутри каждой итерации будут вызываться методы, про которые оптимизатор ничего не знает (вдруг они исходную коллекцию модифицируют, так что ее длина меняется?)
tbl
05.12.2018 15:59Если уж обычная итерация по линейному списку
будет стоить O(n^2), то такой генератор кода надо выбрасывать.IEnumerable<EHC_E15_PRODUCT_SERVICE_SECTION> PRODUCT_SERVICE_SECTIONs
PsyHaSTe
06.12.2018 13:32+1Что мешает PRODUCT_SERVICE_SECTIONRepetitionsUsed посчитать 1 раз до начала итераций? Потому что где еще можно взяться квадрат я не представляю.
А вообще оборачивать тяжелые вычисления в "свойства" я считаю плохой практикой. Пользователь должен понимать, что за foo.X + foo.X может скрываться куча вычислений.
mayorovp
06.12.2018 13:38+2Видимо, религия мешает. Итаксойдетсеанство.
tbl
07.12.2018 01:56В подобных случаях люди иногда самопроизвольно перемещаются в мир ФП и начинают верить, что объекты сами по себе становятся иммутабельными на всю свою глубину, а компилятор по мановению волшебной палочки самопроизвольно включает режим оптимизации "-O99" и применяет мемоизацию.
Да и вообще: «Мы живем в мир быстрых процессоров, нечего экономить на спичках».
michael_vostrikov
05.12.2018 14:32Соответственно группа может быть пропущена, может быть одна, а может быть множество. Поэтому HAPI использует разные подходы чтобы вытащить из подобных структур данные — без итерации, с итерацией и пр.
И, оказывается, это можно заменить на 300 строк кода!Да запросто, возвращаем всегда множество и всегда итерируем. За счет унификации функции обработки можно переиспользовать и объединять в цепочки. 2 фамилии значит 2 элемента будет, 0 значит пустой массив. В HTML это стандартная ситуация, jQuery потому и стала популярной, что она это всё инкапсулирует.
берём HAPI контекст, парсим в XML. Далее используем всё что угодно, вплоть до E4X чтобы достучаться до каждого поля.
Ну он так и сделал видимо. Значения же не меняются от способа получения.
balexa
05.12.2018 17:15+1Да запросто, возвращаем всегда множество и всегда итерируем
При всем уважении. Вам не кажется, что подобное утверждение, эмм, несколько самонадеянно? Wayfarer15 как мне показалось в курсе того, какие проблемы решает этот формат, и имеет опыт работы с ним.
Ничего личного, но меня всегда бесило, когда ты простыми словами рассказываешь человеку про проблему, которую решал в несколько итераций достаточно долгое время не один десяток не самых глупых людей, которая имеет достаточно глубокие первопричины, а человек заявляет что-то вроде «это запросто решается, берем по базе, группируем, суммируем и все» и уверен что разбирается в проблеме, несмотря на то, что о существовании этой предметной области узнал 10 минут назад.
transcengopher
05.12.2018 17:41+1Думаю, стоит всё же объяснить — в чём же сложность решения проблемы потенциального наличия во многих свойствах
[0..n)значений? Первопричина этого мне понятна — там действительно может много значений, а может не быть ни одного. Но настолько ли эта причина глубокая?
Если проблема кажется простой, но простой на самом деле не является, то стоит объяснять, почему она не простая, а не спрыгивать тут же на «лучшие умы целым отделом полгода думали, как лучше сделать, так что нечего лезть со своими предложениями». А иногда простые проблемы — это действительно простые проблемы, с простыми решениями.balexa
05.12.2018 18:13сложность решения проблемы потенциального наличия во многих свойствах [0..n) значений?
Я предполагаю, что для этих значений требуется не только операция поиска. Например. Или там операция поиска какая-нибудь замысловатая, я не знаю. Или там данных стопицот миллионов, из которых половина хранится на кассетах от спектрума. Или еще что.
А может вы оба действительно правы, там и правда переусложнение от кривых индусских ручек, и все можно заменить куском кода на 100 строчек. Но чтобы такое заявлять — надо очень хорошо знать систему и требования. Иначе это звучит как новичковое «да я за неделю на Go/Python/Rust/<подставить язык> всю систему перепишу».
то стоит объяснять, почему она не простая,
Ну далеко не все программисты хорошо разбирающиеся в теме могут выразить свои мысли просто и доходчиво. Ну и человек пытается, как может. А в ответ ему «да хрена ли там, берешь, херак, итерируешь, все работает».vedenin1980
05.12.2018 18:44Я почти 15 лет занимаюсь интеграциями на Java с API очень крупных компаний (вплоть до гугла), так вот в 99 случаях из 100, когда ты видишь кривой интерфейс API дело совсем не в том, что технически его нельзя сделать проще (и часто даже не в том, что разработчики криворуки).
Например, не секрет, что разработчики open source проектов часто зарабатывают основные деньги на консультациях и платной помощи. А в не open source сложность системы не позволяет легко с нее перейти к конкурентам (плюс платный саппорт тоже приносит немалые деньги). Вывод — делать слишком простую систему зачастую невыгодно для разработчиков. Просто бизнес, ничего личного.balexa
05.12.2018 19:10vedenin1980
05.12.2018 19:22Если бы она всегда работала, то запланированного устаревания техники и сознательного усложнения ее ремонта не существовало бы. Фразе «Is fecit cui prodest» (Сделал тот, кому это было выгодно) на пару тысяч лет больше. :)
transcengopher
05.12.2018 20:18+2Я вовсе не утверждал, что конкретно этот код можно заменить сотней строк, просто выразил неудовольствие подходом «раз сделано сложно, значит так было надо». Я слишком часто вижу, что сложный код для работы с простым проблемным доменом (а проблема возвратить
[0; n)элементов — это простая проблема) это скорее признак недостаточного понимания, чем признак того, что проблема на самом-то деле сложна.
Конкретно по этому коду моё лично впечатление от представленных кусочков — это, банально, легаси-код. Сначала там всегда был один элемент и ошибка если его нет, но просят. Потом оказалось, что значений бывает несколько, но старый код для одного значения решено было оставить для краевых случаев (надеюсь, с ошибкой если просят один, а на самом деле там несколько). Потому были добавлены семейства методовgetLength<Property>иgetElement<Property>(index). Идея позволить доступ обычной итерацией тогда никому в голову не пришла, а когда пришла — уже был написан код, ломать который просто так никто не захотел, и прежние два метода с доступом по индексу убирать не стали.balexa
06.12.2018 11:50Да, еще легаси и поддержание обратной совместимости в копилку к тому что я говорил. Я к тому, что причин для «сложного апи» куча, и заявлять о впервые услышанной вещи «это говно которое специально усложнили чтобы заработать на консультациях, а так я все переписал в 300 строчек» — ну не знаю. подобное допустимо только от человека который очень хорошо знаком с системой и требованиями.
vedenin1980
06.12.2018 12:47еще легаси и поддержание обратной совместимости в копилку к тому что я говорил
Нет, наоборот. Легаси и поддержание обратной совместимости (а так же странные пожелания заказчиков или менеджеров) может сделать API и код ужасным независимо насколько умные и квалифицированные ребята над ним работали. То есть утверждение «раз его умные ребята писали, код должен быть хорошим, качественным» не верно.
подобное допустимо только от человека который очень хорошо знаком с системой и требованиями.
Так можно оправдать абсолютно любой ужасный код и архитектуру (вы не работали десять лет с этим кодов, поэтому вы не можете о нем судить).
В большинстве случаев откровенно странные решения можно увидить даже после короткого код ревью, понятно небольшой кол-во таких решений можно объяснить хитрым замыслом, но в одной книги говорилось что качество кода можно определить количеством WTF, который произнесет незнакомый с кодом разработчик, изучая/используя этот код. И если у разработчик произносит WTF постоянно в 99.9% случаях этот код фигня.
michael_vostrikov
05.12.2018 19:09+1Вам не кажется, что подобное утверждение, эмм, несколько самонадеянно?
Согласен, но я не вижу причин не доверять информации из статьи. Человек написал расширяемый парсер, достаточный для текущих и будущих задач. По моему опыту это возможно, ситуация с 0..N элементов есть и в других областях, и есть методы работы с ней. Так что говорить "так не бывает" тоже некорректно.
Мне вот вообще непонятно, зачем возвращать одиночный объект, если потенциально может быть массив. Возможно это из-за ограничений XML, где если вложенный тег один, то нельзя определить, массив это или свойство объекта. Замена библиотечного парсера на свой с указанием "всегда мапить в массив" действительно может решить эту проблему.
mayorovp
05.12.2018 20:36Да нет никакого ограничения XML. Я посмотрел ту библиотеку, там просто два разных метода. Один метод возвращает объект, другой метод возвращает список. Если нужно обойти все элементы — можно всегда вызывать второй метод, независимо от количества объектов. Совершенно нормальное API.
Под капотом я бы там много чего поменял, но API нормальное.
AlexeiZavjalov
04.12.2018 22:26Вторая история напомнила недавнюю публикацию на пикабу pikabu.ru/story/dnevnik_odnogo_goda_ili_pervyiy_god_rabotyi_6326465
AndrewTishkin
05.12.2018 14:46Начал читать как выдуманный текст с вкраплениями известных персонажей, потом смутили фотки, к концу уже пришло осознание реальности истории.
Потом уже просто офигевал от этой Сима-Ленд…
66.ru/news/business/195760
www.znak.com/2018-05-29/kuyvashevu_proveli_ekskursiyu_po_zolotym_zalam_sima_lenda_i_poprosili_o_lgotah_dlya_biznesa
tmteam
05.12.2018 02:29HAPI напомнил известный в электроэнергетике протокол- IEC 61850/8.1
Кто сталкивался тот поймет ощущение незабываемых недель, когда два крупных вендора (или даже два отдела одного очень крупного вендора) пытались наладить связь друг с другом, в тот момент когда вендор поменьше городил все новые if-чики, что бы связаться хоть с кем-то.a_e_tsvetkov
05.12.2018 08:39Таких протоколов/форматов данных полно. Есть еще UN/EDIFACT. Не абы кто, а спасители человечества из самого ООН придумали.
balexa
05.12.2018 18:37А чем едифакт плох? Формат как формат. В своей области применения получше XML будет, да и преобразуется однозначно.
a_e_tsvetkov
05.12.2018 19:25Я писал парсер этого чуда. Его нельзя распарсить без словаря. А так как это семейство форматов, то на каждый случай свой словарь.
Если хочется пропустить группу, то нужно ее полностью распарсить.
Там конечно есть элементы для структуры, но я так и не понял зачем они нужны.balexa
06.12.2018 11:37Как раз таки едифакт хорошо парсится обычным сплитом, по символам которые указаны в UNA. Я тоже писал парсинг едифакта, он парсится очень просто и легко. Более того, его можно легко парсить обычным SAX парсером, переписав контент хандлер. Что собственно все и делают.
Edifact — это как xml. Там внутри может быть что угодно в пользовательском пространстве. Не знаю про какой словарь вы говорите. Проще едифакта разве что только fixed-length форматы парситьa_e_tsvetkov
06.12.2018 11:57Простым сплитом можно получить список элементов. А чтобы восстановить структуру нужно знать какие есть группы и из каких элементов они состоят. Произвольную вложенность он не поддерживает.
Хотя это было давно и поверхностно, может я чего и упустил.balexa
06.12.2018 12:46знать какие есть группы и из каких элементов они состоят.
Не нужно. Для парсинга в структуру — не нужно, она однозначно парсится,
Чтобы получить данные — нужно знать имя сегмента, и порядковый номер внутри него, естественно.
Произвольную вложенность он не поддерживает.
Просто потому что это не формат общего назначения. В рамках своей прикладной области это вполне обычный формат
Если хочется пропустить группу, то нужно ее полностью распарсить.
Вы о чем? Ищите следующий незаискейпленный апостроф. Хотя мне непонятна сама претензия. В других форматах не так? В том же xml/json?
И да, по этому комментарию создается впечатление, что у вас в коде ровным слоем спагетти была смешана бизнес-логика приложения с логикой парсинга формата. Не надо так делать. Так конечно, любой формат будет парсить тяжело.a_e_tsvetkov
06.12.2018 13:17Вот у меня есть имя сегмента NM1 это может быть именем пациента, именем доктора или именем лаборанта в зависимости от вторичной структуры (У меня это медицинские данные были).
Апостроф? У меня разделители были другие. Хотя они там могут быть любыми.
Я бизнес логикой вообще не занимался. Моя задача была все это в доменную модель смапить.balexa
06.12.2018 13:35Апостроф? У меня разделители были другие
Тогда они указаны в UNA секции
это может быть именем пациента, именем доктора или именем лаборанта в зависимости от вторичной структуры
Странно. У вас точно был едифакт?a_e_tsvetkov
06.12.2018 13:40Вроде да.
Выглядит это вот так:
ISA*00* *00* *01*9012345720000 *01*9088877320000 *100822*1134*U*00200*000000007*0*T*:~
GS*HC*901234572000*908887732000*20100822*1615*7*X*005010X222~ ST*837*0007*005010X222~
BHT*0019*00*123BATCH*20100822*1615*CH~
NM1*41*2*ABC CLEARINGHOUSE*****46*123456789~
PER*IC*WILMA FLINTSTONE*TE*9195551111~
NM1*40*2*BCBSNC*****46*987654321~
HL*1**20*1~
NM1*85*1*SMITH*ELIZABETH*A**M.D.*XX*0123456789~
N3*123 MUDD LANE~
N4*DURHAM*NC*27701~
REF*EI*123456789~
HL*2*1*22*0~
SBR*P*18*ABC123101******BL~
NM1*IL*1*DOUGH*MARY*B***MI*24670389600~
N3*P O BOX 12312~
N4*DURHAM*NC*27715~
DMG*D8*19670807*F~
NM1*PR*2*BCBSNC*****PI*987654321~
CLM*PTACCT2235057*100.5***11::1*Y*A*Y*N~
REF*EA*MEDREC11111~
HI*BK:78901~
LX*1~
SV1*HC:99212*100.5*UN*1*12**1**N~
DTP*472*D8*20100801~
SE*24*0007~
GE*1*7~
IEA*1*000000007~
balexa
06.12.2018 15:29Похоже, хоть и нет обязательных с точки зрения UN/Edifact тегов.
Если бы был заголовок, он выглядел бы как
UNA:*.? ~
У вас тильда является разделителем секций, звездочка разделитель данных, двоеточие — разделитель компонентов.
Все что между тильдой и звездочкой — это имя секции. Поэтому NM1 — это однозначно имя сегмента. Это не может быть ничем другим. Ну, по крайней мере я могу так сказать глядя на приведенный вами кусок.Wayfarer15
06.12.2018 21:20Представленный кусок — это HIPAA EDI 837 Healthcare Claim версии 5010. Более того, их там три типа — Professional, Institutional и Dental.
NM1 несомненно имя сегмента, кто бы спорил, но вот какого именно сегмента — пациента, провайдера, сабскрайбера, биллера или кого?
Прежде чем комментировать, не плохо бы хоть немного в предметной области разобраться.a_e_tsvetkov
07.12.2018 05:38Точно, я припоминаю эти слова. Я недолго там пробыл поэтому детали сразу не вспомнил.
balexa
07.12.2018 11:06+1но вот какого именно сегмента — пациента, провайдера, сабскрайбера, биллера или кого?
Естественно, это нужно знать предметную область. Только при чем тут формат?
Почитайте топик с начала, речь шла о том что якобы невозможно понять NM1 — имя сегмента или так зовут врача. Я же говорю что тут все однозначно и парсится сам едифакт очень просто. Даже если вдруг вам зачем-то понадобилось писать парсинг самостоятельно.
Ну был бы тут не ужасный едифакт, а прекрасный xml, чем бы вам это помогло, не зная предметной области?
<nm1> <field1>IL</field1> <field2>1</field2> <salutation>MI</salutation> <name>MARY</name> <thirdname>DOUGH</thirdname> <midname/> </nm1>
Вот не зная предметной области (хотя из нагугленнного xsd видно что первое поле EntityIdentifierCode, которое (у Мэри равно IL, а второе EntityTypeQualifier = 1), как вы поймете из формата и вышеприведенного куска — кто это — врач, пациент, похоронный агент? Никак. Для этого надо знать предметную область. Но чтобы понять что nm1 — это название тега, а не данные, знание предметной области и словарь тегов не нужен.
И да, в XML едифакт однозначно превращается с помощью ISO 20625 и легко гуглящихся XSD конкретно для вашего формата.
Я с едифактом работал достаточно много. Правда в финансовой сфере. И не вижу причин, зачем для задачи парсинга — не аналитики, не обработки и т.п. знать предметную область.
Согласитесь, если бы в медицинской сфере использовался скажем json, то для по его парсинга не требовалось бы очевидно медицинское образование.
arthi7471
05.12.2018 10:50+1Вот моя хистори. Семь лет проработал админом в небольшой айтишной фирмочке и в один ни разу не прекрасный день шеф объявил что контора закрывается ибо он уходит в семинарию учится на священника.
demsp
05.12.2018 12:28а обёртки стандартных функций — это классы? Т.е. эти функции являются внутренними методами класса-обёртки?
И зачем вообще создавать для функции обёртку?
BalinTomsk
05.12.2018 23:28----пахло старым кожаным нижним бельём
Кроме БДСМ ничего в голову не приходит.
webmascon
06.12.2018 00:00сайт ithappens.me все еще работает и там много много таких историй
Squoworode
06.12.2018 20:20Пока ещё работает.
Кстати, уже три года как только работает.
(Может, как ibash, ждут, пока наберётся 50, чтобы сразу зааппрувить?)
helgisbox
06.12.2018 12:33Так это ж про нас прям: " в такой помешанной на документах компании документация к «чудесным» библиотекам должна быть точно набрана правильным шрифтом с идеально точным оттенком, с правильными заголовками глав и названиями разделов. Но документации… не было" :) Все с тебя требуют подробные отчеты и инструкции, но никто тебе документацию не представляет.
sergeperovsky
06.12.2018 18:14+1он написал общий парсер из одного класса в 300 строк
У меня был ровно такой случай: в связи с изменением структуры БД перестала работать программа синхронизации баз на нескольких серверах. Мне поручили внести исправления.
Там были тысячи строк, содержащие явные имена таблиц и полей. Разбираться в них не было никакого желания, да и времени потребовалось бы вагон.
Написал программу синхронизации, независимую от структуры базы. Уложился строк в двести-триста. То ли голландцы, писавшие код до меня, были совсем малограмотными, то ли им платили за строчку кода.
Wayfarer15
06.12.2018 22:04Небольшое пояснение для того большинства, которое вообще не курсе о чём идёт речь.
HL7v2 – стандарт передачи медицинских данных. Появился тогда, когда некоторые из вас ещё либо не родились, либо в первый класс не пошли. Для своего времени он был не лучше и не хуже других подобных форматов – X12, AFTN и прочее.
HAPI – Java библиотека, родилась в недрах канадской University Health Network как пост-док примерно в 2000 году. В дальнейшем поддерживалась и развивалась James Agnew. К слову сказать, я знаком с James. HAPI — это open-source free library. Портов в C# или куда-то ещё официально не существует. Если вы нашли, значит это какая-то самоделка.
James Agnew – не берёт ни каких денег за консультацию по HAPI. В текущий момент они развивают другой продукт – HAPI FHIR – также open-source free library. Коммерческий вариант этого продукта называется SmileCDR.
FHIR – стандарт передачи медицинских данных, впервые был аннонсирован примерно в 2010 году. Есть надежда, что первая нормативная версия появится в начале 2019 г. Т.е. почти 10 лет огромное количество признанных экспертов в своей области обсуждают каким должен быть новый медицинский стандарт. (За это время было отправлено около 13 тыс change request'ов.)
Это всё значит, что если какой-то лох, которому было лень прочитать документацию как по HL7v2, так и HAPI, вдруг решил, что он умнее всех на свете, который без понятия, что есть HL7 interface engine от open-source free до сильно платных коммерческих, вдруг сотворил что-то на 300 строк кода (мне не понятно, откуда 300, я уже сказал, что достаточно двух строк, чтобы перевести в XML и далее ровно столько строк, сколько полей в сообщении), то большие поздравления его организации в будущей поддержки всего этого. Я не вижу ни единого повода для умиления.
Ещё раз обращаю внимание, что если вы ковыряли какой-то энергетический протокол или самопальный API или видели HL7 «из-за спины», то поверьте, HL7v2 сложнее всего этого вместе взятого. Его можно сопоставить разве что с X12 (кстати, HL7 покрывает HIPAA часть X12). Что, однако, не означает, что адекватный, не очень ленивый человек не сможет его осилить, тем более, что в отличии от X12, все спеки по HL7 бесплатны и доступны.
Если есть вопросы конкретно по HL7v2, HL7v3, FHIR, HAPI или HL7 interface engine можете в PM.
tvr
Шедеврально.
Спасибо, день стал чуть менее серым :))