Любопытные извращения из мира ИТ

http://thedailywtf.com/series/feature-articles
  • Перевод
Сайт The Daily WTF уже 14 лет собирает курьёзные, дикие и/или печальные истории из мира ИТ. Я перевёл несколько рассказов, показавшихся мне интересными. Все имена и названия компаний изменены.

На работу за 3 000 миль


Правдивая история из личного опыта нашего автора Snoofle. [Оригинал]

Много десятков лет назад оборонный подрядчик DefCon Inc работал на армию США и пытался получить новый контракт на создание какого-то приложения, применяемого в бою. Компания хотела продемонстрировать в своём предложении, что у неё хватит персонала для выполнения этого проекта. Поэтому она наняла более тысячи разнообразных программистов, руководителей проектов, менеджеров и так далее. Военные, изучавшие различные коммерческие предложения, увидели кучу новых сотрудников, абсолютно незнакомых с необходимыми процессами, процедурами и требованиями, поэтому передали контракт другой фирме. Подрядчик, со своей стороны, уволил всю эту тысячу человек.

Спустя несколько месяцев возник ещё один подобный контракт. Компания снова наняла тысячу человек, чтобы показать, что у неё есть персонал. Ещё через несколько месяцев контракт снова был передан другому подрядчику, и компания снова уволила всю тысячу.


На протяжении двух лет такое повторялось несколько раз.

После всего этого основная масса доступных для найма сотрудников уже была в курсе об очень коротком цикле найма-увольнения в компании, поэтому подрядчик не мог привлечь никого, кроме новичков, только что выпустившихся из учебных заведений. Наконец, какого-то руководителя из верхнего звена озарило, что все эти люди только что из-за парты гораздо дешевле, чем опытные разработчики в штате компании, и те, кого компания нанимала-увольняла ради контрактов. Поэтому он выпустил приказ, что весь опытный персонал компании должен быть заменён дешёвыми молодыми сотрудниками. Процесс занял два года, но это всё-таки произошло.

Теперь, когда расходы на зарплаты значительно снизились, и они чертовски разозлили всех опытных разработчиков-кандидатов, компания могла увеличить постоянный штат, не раздувая бюджет на зарплаты. Ей можно было нанимать только молодых, неопытных разработчиков, чтобы наконец-то получить контракт.

К сожалению, у всех этих молодых разработчиков было очень мало опыта, а в фирме больше не осталось побывавших в окопах людей, способных их обучить. Поэтому результатом их двухлетнего контракта стал этого ненадёжный проект, который часто вылетал, вёл себя непредсказуемо и который невозможно было модифицировать. Подобные свойства нежелательны, когда имеешь дело с системой, которая должна стрелять и взрывать.

В какой-то момент один из высших руководителей осознал, что произошло, заставил компанию прекратить вести себя, как слон в посудной лавке, и нанять высокооплачиваемых консультантов. К сожалению, высокооплачиваемые консультанты хорошо помнили о цикле найма-увольнений и не хотели иметь ничего общего с организацией. Спустя какое-то время компании пришлось существенно улучшать условия найма, пока наконец несколько опытных работников согласилось устроиться на работу в качестве штатных сотрудников. Это произошло в Нью-Джерси.

После того, как руководство назначало этих новых сотрудников на проект для ускорения работы над ним, новые сотрудники сказали «Постойте-ка, посередине этого проекта есть огромная дыра!» Руководство ответило, что эта часть проекта засекречена, и может изучаться только людьми с допуском к секретной информации и только на предприятии в Калифорнии. Были запрошены и получены соответствующие допуски, после чего опытных сотрудников отправили на две недели на предприятие в Калифорнии.

Прежде чем соглашаться на поездку, разработчики хотели узнать, как они смогут получать доступ к материалам после изучения. Ведь доступ возможен только на месте, в Калифорнии, а все сотрудники живут и работают в Нью-Джерси. Им сказали, что о подробностях они узнают в Калифорнии.

Ну ладно, все они прилетели на западное побережье, заселились в отели и поехали в офис.

В тот момент им сообщили обо всех проблемах, которые необходимо устранить. В четверг второй недели работы было решено, что для выполнения всех необходимых модернизаций необходимо примерно два года работы. Разработчики опять спросили: «Как же мы будем получать доступ к материалам из Нью-Джерси?» Менеджеры ответили, что вся работа должна выполняться на месте, и они будут оставаться в Калифорнии в течении следующих двух лет. Начиная с ближайшего понедельника.

Но, постойте у них же не было возможности обсудить это с семьёй! Как отсутствие 90% времени одного из родителей повлияет на детей? Захотят ли они жить в гостиницах и аэропортах в течение двух лет? Какого хрена компания не наняла сотрудников на месте, в Калифорнии, а занималась этим в Нью-Джерси?

Оказалось, что поскольку подрядчик находится в Нью-Джерси, нанимаемый им персонал тоже должен быть зарегистрирован там же. Разумеется, если бы об этом сообщили до трудоустройства, то большинство сотрудников (если не все из них) отказалось бы от работы. Если бы они знали, то никто из работников не поднялся бы на борт самолёта и не полетел бы в Калифорнию для ознакомления с проектом.

Можно и не говорить, что остаток рабочего для менеджеры втирали о необходимости жертв ради компании, а разработчики задавались вопросом: «Какого чёрта?» Вечер четверга был занят бесконечными звонками домой. Утром пятницы все сотрудники уволились и направились в аэропорт, чтобы вернуться домой.

Представители армии повели себя достойно и с пониманием отнеслись к тому, что люди не хотят бросать свои дома и семьи на два года. Однако стали гораздо жёстче, когда дело дошло до разговора с подрядчиком и до выполнении его обещаний о наличии опытного персонала на месте работы.

В результате контракт с подрядчиком был расторгнут, а на его место наняли для наведения порядка нового.

Случай отказа


[Оригинал]

image

В первый день на новой работе Себастьян не был особо воодушевлён. Он уже многое повидал и набрался равнодушия и пессимизма. Эта новая работа не должна была отличаться ни одной другой: куча надоедливых коллег, плохо продуманных требований, старых кодовых баз, полных спагетти-кода. Но она хорошо оплачивалась, а он устал от своей старой группы, ему надоели одни и те же привычные лица. Поэтому он внутренне приготовился к слегка новым оттенкам той же офисной политики и муторных заданий.

Он даже особо не расстроился, зайдя в ИТ-отдел за своими учётными данными и услышав жужжание и щёлканье старых серверов 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, который деградировал эволюционировал в XML, который должен быть тривиальным приемлемым способом задания содержащихся в документе формата и полей с доступным на всех платформах парсером, благодаря чему информацией можно обмениваться, не зная ничего, кроме DTD и/или схемы для валидации и парсинга.

Не надеясь на лучшее, для упрощения работы мы написали поверх XML библиотеки обёрток.

К сожалению, они с задачей не справились.


В отрасли здравоохранения какие-то работающие с с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, в качестве замены всего интерфейса.

После этого добавление нового поля стало занимать не больше десяти минут.
Поделиться публикацией
Комментарии 107
    +4
    Шедеврально.
    Спасибо, день стал чуть менее серым :))
      +16
      Виста не была столь плоха, больше похоже что собирали компьютер и настраивали её те же, кто писал странные библиотеки. И Себастьян ну очень упорный, я бы после цветового оформления отказался.
        +2
        Пишу это с ноутбука под Vista. 10 лет, полет нормальный.
          +19
          Себастьян, ты? Бросай эту работу и эти дурацкие шрифты.
          +2
          И Себастьян ну очень упорный, я бы после цветового оформления отказался.
          Вы не нацелены на результат, мы вам перезвоним.
            +5
            Кстати да, в Висте, по сути, произошло много важных и полезных изменений в ядре ОС. Семёрка лишь добавила рюшечек и пофиксила явные баги UI.
            +1

            Виста начала давать по рукам за попытки играть с объектами ядра. Плюс известная история про баг в определении версии винды if (Major >= 5 and Minor >= 1) ..., который перестал работать с вистой 6.0, но работал с семеркой 6.1. Можно было бы подумать, что это байка, но в винда реально врет о своей версии, если не проставить магический гуид в манифесте типа "я знаю, что ты врешь". Например, десятка будет упорно врать, что она семерка, пока не пропишешь <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/> в манифесте.

            +5
            Подтверждаю HAPI — это стон что здесь песней зовется.
              –3
              Понял немногое, но почитать было прикольно)
                +2
                Да, один знакомый улетал в другую страну на 2 месяца, чтоб внедрить софт, который разрабатывали. Но, чтоб 2 года…
                  +1
                  Как-то я работал в одной компании и ездил в командировку на крайний север на обследование на пару дней. Дело было в декабре, стоял мороз за 40. Начальник отдела, что нас принимал, возил нас на своей машине из отеля на объект и обратно. Как-то раз, проезжали мимо группы людей в затянутых по самый нос капюшонах алясках, которые медленно и уныло брели в отель через пургу. Начальник сказал — а это коллеги из компании XXXX уже полгода воюют с нашим отделом YYYYY, пытаясь внедрить систему ZZZZZ и конца и края не видно. Я тогда их очень сильно пожалел…
                  А потом случилось так, что теперь теперь сам тут работаю :)
                    +1
                    Для внедренцев-консалтеров абсолютно нормально быть в командировке полгода, бывает, и дольше. Конечно, обычно они летают домой, и часть времени работают в своем офисе, но все-равно в полях — основная работа.
                    0

                    Одного моего знакомого в перестроечное время отправили в командировку в Африку испытывать уральскую дорожную технику. Ненадолго, на месяц. Потом попросили ещё побыть там, ибо мало было специалистов со знанием французского. Потом ещё и ещё… В итоге в Африке он год проторчал.

                      +2

                      Старые юмористические эпизоды "Железный капут" про забытый секретный танк.
                      Самое то, что можно посмотреть в затянувшейся командировке.

                    +14
                    Это API с приблизительно 15 тысячами вызовов методов! О чём вообще думали эти разработчики?

                    О том, что никто никогда не уволит единственного человека, знающего как работают 15 тысяч методов этого API? Сознательное переусложнение системы, чтобы фирма/разработчик стал совершенно незаменимым, увы, встречается достаточно часто.

                    Скорее всего ребята написавшие этот HAPI получают огромные деньги на обучениях и консультациях пользователей API. Просто это такой бизнес.
                      +9

                      Хахах, однажды нарвался на компанию в которой гендир лично проверял оттенки кнопок, ни разу не обратив внимание на функционал. Так же он был категорически против специализированных баг-трекеров и все проекты велись в трелло, где срочность задачи он определил цветом. Красный — минимальный приоритет, фиолетовый — наивысший.

                        +31
                        похоже он просто не с Земли
                        в Доктор Кто был момент, где говорилось, что красный цвет опасности только на Земле, во всей остальной галактике же эту роль выполняет фиолетовый
                          +5

                          Это многое объясняет!

                            0

                            Градация метеорологических угроз в некоторых странах этой планеты: зеленый<желтый<красный<лиловый (не совсем фиолетовый, но близко)

                              0
                              просто видимый свет у нас сортируют по длине волны, а в остальной галактике — по частоте
                              +16
                              просто видимо ему надо было показать кто в доме хозяин, а в кнопках это было проще всего)
                              когда я учился в ТРТУ, был у нас один очень своеобразный преподаватель. ну знаете, из тех кто «то что вы принесли мне лабу(курсовик) это просто повод для начала разговора». сдавали с 8 утра до 11 ночи. сдавали по пять раз. приходили пересдавать утром и уходили вечером потому что просто не смогли зайти на пересдачу (он за день принял всего троих из толпы (сдали двое)).
                              но тем не менее, имелся верный хак. нужно было организовать рояль в кустах — поместить явную локальную нелепицу и пару нарушений правил оформления на видное место. он это заметит, раскатает тебя в блин… ты посидишь с сокрушённым видом, пойдёшь в общагу, достанешь заранее напечатанные листы с правильным вариантом, вставишь в отчёт/курсовой и через пару дней придёшь на пересдачу. посмотрит — ну вот, давно бы так — давай зачётку.
                              главное чтоб не забыл что он тебя уже вытрепал, а то начнётся по новой)
                              подготовка к жизни в подобных компаниях, блин)
                                +8
                                В госкорпорации одной так и делается. В документ нужно накидать очевидной херни, чтобы начальники могли их повычеркивать с чувством собственной значимости, ты потом это переделываешь, и несешь на подпись Иван Иванычу с благодарностью, какой он внимательный и мудрый. Иногда они что-то пропускают, и эта чушь остается жить в финальной версии.
                                  +1
                                  про это даже Dilbert есть:
                                  image
                                  +4
                                  Напомнило как я в своё время чертежи сдавал преподавательнице на первом курсе.
                                  5 раз я снова и снова выслушивал надуманные недочёты и вносил изменения по одному из чертежей.
                                  Дошло до того, что сдал я этот чертёж только в 6 раз, причём просто принеся свой изначальный вариант работы.
                                  Я тогда ещё получил такой ответ преподавательницы: «Другое дело. Вот так бы сразу и начертил.»
                                  Говорить, что я собственно так сразу и начертил я конечно не стал)
                                    +1
                                    Моё любимое, как меня пытались на экзамене завалить, но в итоге ее рука дрогнула и она написала в зачетке ОТЛ на автомате, после чего произнесла: «но всё равно придете пересдавать», указала ОТЛ в ведомости… Я ответил «Конечно»!
                                    А вот староста раз десять бегал, пока другой наш математик ей на кафедре прилюдно не сказал, что даже окружающие преподы вокруг уже уверены, что тот на ОТЛ знает, кончай мол доставать парня.
                                      +6
                                      По вольной ассоциации мне вспомнилась прямо противоположная история.

                                      Кафедра зоологии позвоночных, зачет по вирусологии. Преподавательница слушает студентов, слушает, морщится, но зачеты ставит. Если задуматься, то и вправду зоология позвоночных от вирусологии удалена достаточно, чтобы не пригодиться практически никогда.

                                      Очередной студент сообщает, что вирусы размножаются делением. Преподавательница светлеет лицом.
                                      — Знаете, я с утра сижу и думаю, кого бы с вашей кафедры заставить выучить вирусологию?..
                                      Вам повезло!
                                      0
                                      Если вдруг препод не может исправить оценку в зачетке или в ведомости (насчет последнего даже не знаю если честно возможно ли такое), то можно было бы так и сказать. Вот была бы песня, проучили бы ее на всю оставшуюся жизнь)
                                        0
                                        Это был не экзамен/зачёт, а лишь сдача одного из десятка чертежей, которые необходимо было выполнить для получения возможности приступить к сдаче зачёта. Так что её лучше было не злить)
                                        0
                                        У нас был случай в университете. Сдавали программу на C++, она была одна и та же для всех. Преподаватель проверял только результат программы. Входные данные тоже были одинаковые и ответ одинаковый. Ну, некоторые ребята пришли на зачет, не ходя на пары особо, программы у них не было. По быстрому сделали программу, которая
                                        просто выводит ответ в консоль: std::count << ответ. )

                                        Когда он узнал в конце о таком обмане, был, мягко говоря, не доволен.

                                          0
                                          Я один раз сдал чертеж с первого раза… Начертил я чертеж, но сделал слишком много исправлений, поэтому не поленился и перечертил идеально на новый лист. Результат? «Это не ты чертил, 3!»
                                            0
                                            «слабая тара» зощенко сразу вспоминается
                                            0

                                            Это называется "метод волосатой руки", поищите историю ;-)

                                              0

                                              Как писно с моей бывшей конторы. Только чуть отличается. Сдаёшь регламент в архитектурный штаб. Они кучу пометок и коментов в документ вставляют. Удаляешь всю чушь, что они в ответ написали, ждёшь два часа и снова отправляешь. С 90% вероятностью документ согласовывают.

                                                +1
                                                подготовка к жизни в подобных компаниях
                                                В отличие от университета и конкретного курса из компании можно уйти в более адекватную. Таких к счастью много.
                                                0
                                                Так ведь радуга.
                                                У вас гендир, видимо, использовал цвета радуги, чтобы оценить степень приоритета.
                                                  0
                                                  Логично, особенно если между ними оранжевый, жёлтый, зелёный, голубой и синий.
                                                  +6
                                                  информационные центры в World Wide Web, созданные для коллекционирования мудрости лучших умов отрасли в знакомом и удобном формате вопросов и ответов
                                                  самое поэтичное определение stackoverflow которое можно придумать))
                                                    +8
                                                    В российских компаниях такое тоже есть.
                                                    Устроился на работу в крупную контору,
                                                    Дали брендовый комп с мизерным количеством оперативной памяти, на котором IDE запускался пару минут, и работал адово медленно.
                                                    Зато безопасность/секьюрность — были на высшем уровне, работа была в винде (а я, вообще-то разраб под никсы), чтобы что-то поставить, надо отловить специального человека, только он мог поставить нужный софт. Выход в интернет был тоже непростой, приложения типа git и т.п. не могли просто так взять и получить что-то с гитхаба.
                                                    Работал 2 недели, все эти 2 недели ждал новые плашки памяти (которые не абы какие, а какие-то фильдиперсовые, просто так не купить) и заодно нормальный хард на 1тб.

                                                    Поставить никсы? Надо согласовать, жди, и когда-нибудь дождешься.
                                                    Поставить нормальный комп? У нас по регламенту только такие, жди апгрейд.

                                                    По прошествии двух недель, устав от бесконечных тормозов вверенной мне тачки, а также от болтовни сотрудников, которые находились со мной в одном помещении, и колторые не прекращали общаться на отвлеченные темы, я решил что хватит.
                                                    И да, ежедневные отчеты о проделанной работе.

                                                    Так-то и з/п предлагалась хорошая, но я осознал, что уставать можно не только от напряженной работы, но и от монотонного ожидания пока отвиснет IDE.
                                                      +3
                                                      Слышал мнение, что разработчику надо давать самый-самый медленный компьютер, чтобы вот едва тянул на пределе, тогда этот разработчик будет всё оптимизировать и писать быстрые программы. А то понапишут, ироды, а оно потом тормозит. Подумал: «Хорошо, что такие фантазёры не бывают начальниками.» Ну, щас — не бывают, встретил как-то и начальника, с гордостью рассказывающего о подобной практике (контора была не айтишная, просто бизнес с небольшим IT-отделом, немного программирующим для внутренних нужд, но тем не менее).
                                                        +1
                                                        Слышал мнение, что разработчику надо давать самый-самый медленный компьютер, чтобы вот едва тянул на пределе, тогда этот разработчик будет всё оптимизировать и писать быстрые программы
                                                        И ждать окончания компиляции часами? Это тоже самое что пересадить таксистов на запорожцы.
                                                        Просто ТЗ должно быть правильное и тестирование.
                                                        Когда в лохматые годы я верстал страничку в нашей конторе то после проверял как она смотрится во ВСЕХ браузерах и если есть косяки то устранял.
                                                        Тогда еще был жив Netscape Navigator.
                                                          +2
                                                          Предлагаю аналогию. Вместо высокоточных роботов, дать рабочим в руки молоток и зубило и предложить им делать микропроцессоры. Есть мнение, что чем больше молоток, тем больше частота процессора выйдет у рабочего.
                                                            +3
                                                            Глупости. Чтобы программа работала «нормально» на «слабом» железе, надо
                                                            1. Определиться что есть «слабое железо» (т.е. сформулировать требования к оборудованию, на котором это будет работать.)
                                                            2. Требовать чтобы оно так было (т.е. вписать сие в ТЗ)
                                                            3. Тестировать на «слабом» железе (т.е. проверять соответствие результата ТЗ)
                                                            4. Ну и крайне желательно чтобы это вообще было осуществимо (т.е. чтобы ТЗ было боле-менее реалистичным. Рендерить фотореалистичную анимацию в реалтайме на древнем компе не возможно)


                                                            Все, больше ничего. И нечего разработчику придумывать лишние неудобства в виде слабого компа, это лишь будет его раздражать напрасно и снижать производительность.
                                                              +1
                                                              разработчику надо давать самый-самый медленный компьютер для тестов
                                                                0

                                                                Разработчику по БД и серверных приложений особенно :)

                                                                +1
                                                                Нормальный хард — это SSD
                                                                  0

                                                                  Очень похоже на ИТ в магните

                                                                  +5
                                                                  Очень повесилило по поводу 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 чтобы достучаться до каждого поля.
                                                                    +1
                                                                    Соответственно группа может быть пропущена, может быть одна, а может быть множество. Поэтому HAPI использует разные подходы чтобы вытащить из подобных структур данные — без итерации, с итерацией и пр.

                                                                    А почему нельзя сделать один метод, который вернёт пустой список, список из одного элемента или список из нескольких элементов, соответственно?
                                                                      0
                                                                      Да запросто. А теперь представь, поскольку стандарт делается не под конкретного Васю Пупкина из 2-ой клиники, что у пациента может быть больше чем одна имя-фамилия (Pablo Diego José Francisco de Paula Juan Nepomuceno María de los Remedios Cipriano de la Santísima Trinidad Ruiz y Picasso), а также несколько идентификаторов, а также несколько телефонов, адресов (а в адресе может быть несколько названий для улицы), медикаментов и чего угодно. А может и не быть. Вместо поля данных может быть NullFavour или null индикатор. Если всё это возвращать списками, то за-итератишься по самые помидоры. Поэтому HAPI позволяет вытаскивать данные и так, и сяк, и наперекосяк. И вероятно поэтому HAPI считается standard de-facto парсинг для HL7v2, а таперь и для FHIR сообщений.
                                                                        +2
                                                                        > и это всё в 300 строк кода!
                                                                        > поскольку стандарт делается не под конкретного Васю Пупкина из 2-ой клиники,
                                                                        Вы только что ответили на свой вопрос

                                                                        0
                                                                        Так такой метод там, вообще-то, есть! Называется getPRODUCT_SERVICE_SECTIONAll, его даже автор найти смог…
                                                                        +2

                                                                        Какой же комитет такие форматы сознательно пишет и аппрувит? Или это все эволюционные наслоения на говно мамонта?
                                                                        Небось, до сих пор длина текстовых полей ограничена в 76 или 80 символов, чтобы на перфокарту влезло.


                                                                        Чую по названиям структурных типов, без кобола здесь не обошлось.

                                                                          +3

                                                                          Мне в этом 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);
                                                                                  }
                                                                              }
                                                                          }

                                                                          Никого ничего не смущает?

                                                                            0
                                                                            public int PRODUCT_SERVICE_SECTIONRepetitionsUsed
                                                                            {
                                                                            get
                                                                            {
                                                                            return this.GetAll(«PRODUCT_SERVICE_SECTION»).Length;
                                                                            }
                                                                            }

                                                                            Я не пишу на шарпе, но это очень сильно походит на автогенеренный код. Если это так — то ничего страшного.
                                                                              +3
                                                                              Квадратичный алгоритм на пустом месте плох независимо от способа создания кода.
                                                                                –3
                                                                                Отвечу сразу вам и tbl
                                                                                Внезапно не всегда O(n^2) это плохо, и не всегда O(n) хорошо.
                                                                                На примере той же сортировки — квадратичный Insertion sort более эффективен на небольших масивах, чем квазилинейная быстрая сортировка. Вплоть до того, что последняя фаза быстрой сортировки во многих библиотечных реализациях делается вставками.

                                                                                Так и тут — я бы не стал утверждать заранее, что код плохой. Если мы точно знаем что длина PRODUCT_SERVICE_SECTION не может быть больше например 5, то возможно это самый оптимальный с точки зрения расхода памяти/скорости/простоты генератора (что весьма немаловажно) способ.

                                                                                А может быть конечно что это просто говнокод. Это весьма вероятно, согласен.
                                                                                Но я бы не стал вот так категорично утверждать что O(n^2) — это всегда ужасно.
                                                                                  +2
                                                                                  Нет никакого смысла в генерации нового массива элементов только для того чтобы узнать его длину на каждой итерации. Даже если длина не больше 5.
                                                                                    +3

                                                                                    Могу я узнать причину минуса? Кто-то считает, что узнавать длину массива за 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");
                                                                                        }
                                                                                    }
                                                                                      0
                                                                                      balexa, вы точно считаете что это нормально?

                                                                                      Я не говорил что это — нормально. И минус вам не я ставил. Не надо приписывать мне утверждения, я GetAll только что увидел.
                                                                                      Да, получение длины на каждой итерации — косяк, тут я согласен. Оптимизатор не убирает это?
                                                                                        +1
                                                                                        и не уберет, если внутри каждой итерации будут вызываться методы, про которые оптимизатор ничего не знает (вдруг они исходную коллекцию модифицируют, так что ее длина меняется?)
                                                                                +1
                                                                                Если уж обычная итерация по линейному списку
                                                                                IEnumerable<EHC_E15_PRODUCT_SERVICE_SECTION> PRODUCT_SERVICE_SECTIONs
                                                                                будет стоить O(n^2), то такой генератор кода надо выбрасывать.
                                                                                +1

                                                                                Что мешает PRODUCT_SERVICE_SECTIONRepetitionsUsed посчитать 1 раз до начала итераций? Потому что где еще можно взяться квадрат я не представляю.


                                                                                А вообще оборачивать тяжелые вычисления в "свойства" я считаю плохой практикой. Пользователь должен понимать, что за foo.X + foo.X может скрываться куча вычислений.

                                                                                  +3
                                                                                  Видимо, религия мешает. Итаксойдетсеанство.
                                                                                    0
                                                                                    В подобных случаях люди иногда самопроизвольно перемещаются в мир ФП и начинают верить, что объекты сами по себе становятся иммутабельными на всю свою глубину, а компилятор по мановению волшебной палочки самопроизвольно включает режим оптимизации "-O99" и применяет мемоизацию.
                                                                                    Да и вообще: «Мы живем в мир быстрых процессоров, нечего экономить на спичках».
                                                                                +1
                                                                                Соответственно группа может быть пропущена, может быть одна, а может быть множество. Поэтому HAPI использует разные подходы чтобы вытащить из подобных структур данные — без итерации, с итерацией и пр.
                                                                                И, оказывается, это можно заменить на 300 строк кода!

                                                                                Да запросто, возвращаем всегда множество и всегда итерируем. За счет унификации функции обработки можно переиспользовать и объединять в цепочки. 2 фамилии значит 2 элемента будет, 0 значит пустой массив. В HTML это стандартная ситуация, jQuery потому и стала популярной, что она это всё инкапсулирует.


                                                                                берём HAPI контекст, парсим в XML. Далее используем всё что угодно, вплоть до E4X чтобы достучаться до каждого поля.

                                                                                Ну он так и сделал видимо. Значения же не меняются от способа получения.

                                                                                  +1
                                                                                  Да запросто, возвращаем всегда множество и всегда итерируем

                                                                                  При всем уважении. Вам не кажется, что подобное утверждение, эмм, несколько самонадеянно? Wayfarer15 как мне показалось в курсе того, какие проблемы решает этот формат, и имеет опыт работы с ним.

                                                                                  Ничего личного, но меня всегда бесило, когда ты простыми словами рассказываешь человеку про проблему, которую решал в несколько итераций достаточно долгое время не один десяток не самых глупых людей, которая имеет достаточно глубокие первопричины, а человек заявляет что-то вроде «это запросто решается, берем по базе, группируем, суммируем и все» и уверен что разбирается в проблеме, несмотря на то, что о существовании этой предметной области узнал 10 минут назад.
                                                                                    +3
                                                                                    Думаю, стоит всё же объяснить — в чём же сложность решения проблемы потенциального наличия во многих свойствах [0..n) значений? Первопричина этого мне понятна — там действительно может много значений, а может не быть ни одного. Но настолько ли эта причина глубокая?
                                                                                    Если проблема кажется простой, но простой на самом деле не является, то стоит объяснять, почему она не простая, а не спрыгивать тут же на «лучшие умы целым отделом полгода думали, как лучше сделать, так что нечего лезть со своими предложениями». А иногда простые проблемы — это действительно простые проблемы, с простыми решениями.
                                                                                      +1
                                                                                      сложность решения проблемы потенциального наличия во многих свойствах [0..n) значений?

                                                                                      Я предполагаю, что для этих значений требуется не только операция поиска. Например. Или там операция поиска какая-нибудь замысловатая, я не знаю. Или там данных стопицот миллионов, из которых половина хранится на кассетах от спектрума. Или еще что.

                                                                                      А может вы оба действительно правы, там и правда переусложнение от кривых индусских ручек, и все можно заменить куском кода на 100 строчек. Но чтобы такое заявлять — надо очень хорошо знать систему и требования. Иначе это звучит как новичковое «да я за неделю на Go/Python/Rust/<подставить язык> всю систему перепишу».

                                                                                      то стоит объяснять, почему она не простая,

                                                                                      Ну далеко не все программисты хорошо разбирающиеся в теме могут выразить свои мысли просто и доходчиво. Ну и человек пытается, как может. А в ответ ему «да хрена ли там, берешь, херак, итерируешь, все работает».
                                                                                        +1
                                                                                        Я почти 15 лет занимаюсь интеграциями на Java с API очень крупных компаний (вплоть до гугла), так вот в 99 случаях из 100, когда ты видишь кривой интерфейс API дело совсем не в том, что технически его нельзя сделать проще (и часто даже не в том, что разработчики криворуки).

                                                                                        Например, не секрет, что разработчики open source проектов часто зарабатывают основные деньги на консультациях и платной помощи. А в не open source сложность системы не позволяет легко с нее перейти к конкурентам (плюс платный саппорт тоже приносит немалые деньги). Вывод — делать слишком простую систему зачастую невыгодно для разработчиков. Просто бизнес, ничего личного.
                                                                                          0
                                                                                          Вывод — делать слишком простую систему зачастую невыгодно для разработчиков.

                                                                                          Бритва Хэнлона
                                                                                            +1
                                                                                            Если бы она всегда работала, то запланированного устаревания техники и сознательного усложнения ее ремонта не существовало бы. Фразе «Is fecit cui prodest» (Сделал тот, кому это было выгодно) на пару тысяч лет больше. :)
                                                                                          +3
                                                                                          Я вовсе не утверждал, что конкретно этот код можно заменить сотней строк, просто выразил неудовольствие подходом «раз сделано сложно, значит так было надо». Я слишком часто вижу, что сложный код для работы с простым проблемным доменом (а проблема возвратить [0; n) элементов — это простая проблема) это скорее признак недостаточного понимания, чем признак того, что проблема на самом-то деле сложна.

                                                                                          Конкретно по этому коду моё лично впечатление от представленных кусочков — это, банально, легаси-код. Сначала там всегда был один элемент и ошибка если его нет, но просят. Потом оказалось, что значений бывает несколько, но старый код для одного значения решено было оставить для краевых случаев (надеюсь, с ошибкой если просят один, а на самом деле там несколько). Потому были добавлены семейства методов getLength<Property> и getElement<Property>(index). Идея позволить доступ обычной итерацией тогда никому в голову не пришла, а когда пришла — уже был написан код, ломать который просто так никто не захотел, и прежние два метода с доступом по индексу убирать не стали.
                                                                                            0
                                                                                            Да, еще легаси и поддержание обратной совместимости в копилку к тому что я говорил. Я к тому, что причин для «сложного апи» куча, и заявлять о впервые услышанной вещи «это говно которое специально усложнили чтобы заработать на консультациях, а так я все переписал в 300 строчек» — ну не знаю. подобное допустимо только от человека который очень хорошо знаком с системой и требованиями.
                                                                                              +1
                                                                                              еще легаси и поддержание обратной совместимости в копилку к тому что я говорил

                                                                                              Нет, наоборот. Легаси и поддержание обратной совместимости (а так же странные пожелания заказчиков или менеджеров) может сделать API и код ужасным независимо насколько умные и квалифицированные ребята над ним работали. То есть утверждение «раз его умные ребята писали, код должен быть хорошим, качественным» не верно.

                                                                                              подобное допустимо только от человека который очень хорошо знаком с системой и требованиями.

                                                                                              Так можно оправдать абсолютно любой ужасный код и архитектуру (вы не работали десять лет с этим кодов, поэтому вы не можете о нем судить).

                                                                                              В большинстве случаев откровенно странные решения можно увидить даже после короткого код ревью, понятно небольшой кол-во таких решений можно объяснить хитрым замыслом, но в одной книги говорилось что качество кода можно определить количеством WTF, который произнесет незнакомый с кодом разработчик, изучая/используя этот код. И если у разработчик произносит WTF постоянно в 99.9% случаях этот код фигня.
                                                                                      +1
                                                                                      Вам не кажется, что подобное утверждение, эмм, несколько самонадеянно?

                                                                                      Согласен, но я не вижу причин не доверять информации из статьи. Человек написал расширяемый парсер, достаточный для текущих и будущих задач. По моему опыту это возможно, ситуация с 0..N элементов есть и в других областях, и есть методы работы с ней. Так что говорить "так не бывает" тоже некорректно.


                                                                                      Мне вот вообще непонятно, зачем возвращать одиночный объект, если потенциально может быть массив. Возможно это из-за ограничений XML, где если вложенный тег один, то нельзя определить, массив это или свойство объекта. Замена библиотечного парсера на свой с указанием "всегда мапить в массив" действительно может решить эту проблему.

                                                                                        0
                                                                                        Да нет никакого ограничения XML. Я посмотрел ту библиотеку, там просто два разных метода. Один метод возвращает объект, другой метод возвращает список. Если нужно обойти все элементы — можно всегда вызывать второй метод, независимо от количества объектов. Совершенно нормальное API.

                                                                                        Под капотом я бы там много чего поменял, но API нормальное.
                                                                                    +1
                                                                                    Нормальная ситуация. :) Я проехал 3200 миль на новое место работы, 4 ночи из них две в палатке.
                                                                                      +2
                                                                                      Представил подписывание трудового договора у костра, смолтолки с коллегами у ручья, вызов к начальнику в палатку.
                                                                                        +1
                                                                                        А я бы так даже поработал недельку-две в году. Было бы офигенно.
                                                                                      +1
                                                                                      Вторая история напомнила недавнюю публикацию на пикабу pikabu.ru/story/dnevnik_odnogo_goda_ili_pervyiy_god_rabotyi_6326465
                                                                                      +2
                                                                                      HAPI напомнил известный в электроэнергетике протокол- IEC 61850/8.1
                                                                                      Кто сталкивался тот поймет ощущение незабываемых недель, когда два крупных вендора (или даже два отдела одного очень крупного вендора) пытались наладить связь друг с другом, в тот момент когда вендор поменьше городил все новые if-чики, что бы связаться хоть с кем-то.
                                                                                        +2
                                                                                        Таких протоколов/форматов данных полно. Есть еще UN/EDIFACT. Не абы кто, а спасители человечества из самого ООН придумали.
                                                                                          0
                                                                                          А чем едифакт плох? Формат как формат. В своей области применения получше XML будет, да и преобразуется однозначно.
                                                                                            +1
                                                                                            Я писал парсер этого чуда. Его нельзя распарсить без словаря. А так как это семейство форматов, то на каждый случай свой словарь.

                                                                                            Если хочется пропустить группу, то нужно ее полностью распарсить.

                                                                                            Там конечно есть элементы для структуры, но я так и не понял зачем они нужны.
                                                                                              0
                                                                                              Как раз таки едифакт хорошо парсится обычным сплитом, по символам которые указаны в UNA. Я тоже писал парсинг едифакта, он парсится очень просто и легко. Более того, его можно легко парсить обычным SAX парсером, переписав контент хандлер. Что собственно все и делают.

                                                                                              Edifact — это как xml. Там внутри может быть что угодно в пользовательском пространстве. Не знаю про какой словарь вы говорите. Проще едифакта разве что только fixed-length форматы парсить
                                                                                                0
                                                                                                Простым сплитом можно получить список элементов. А чтобы восстановить структуру нужно знать какие есть группы и из каких элементов они состоят. Произвольную вложенность он не поддерживает.

                                                                                                Хотя это было давно и поверхностно, может я чего и упустил.
                                                                                                  +1
                                                                                                  знать какие есть группы и из каких элементов они состоят.

                                                                                                  Не нужно. Для парсинга в структуру — не нужно, она однозначно парсится,
                                                                                                  Чтобы получить данные — нужно знать имя сегмента, и порядковый номер внутри него, естественно.

                                                                                                  Произвольную вложенность он не поддерживает.

                                                                                                  Просто потому что это не формат общего назначения. В рамках своей прикладной области это вполне обычный формат

                                                                                                  Если хочется пропустить группу, то нужно ее полностью распарсить.

                                                                                                  Вы о чем? Ищите следующий незаискейпленный апостроф. Хотя мне непонятна сама претензия. В других форматах не так? В том же xml/json?

                                                                                                  И да, по этому комментарию создается впечатление, что у вас в коде ровным слоем спагетти была смешана бизнес-логика приложения с логикой парсинга формата. Не надо так делать. Так конечно, любой формат будет парсить тяжело.
                                                                                                    0
                                                                                                    Вот у меня есть имя сегмента NM1 это может быть именем пациента, именем доктора или именем лаборанта в зависимости от вторичной структуры (У меня это медицинские данные были).

                                                                                                    Апостроф? У меня разделители были другие. Хотя они там могут быть любыми.

                                                                                                    Я бизнес логикой вообще не занимался. Моя задача была все это в доменную модель смапить.
                                                                                                      0
                                                                                                      Апостроф? У меня разделители были другие

                                                                                                      Тогда они указаны в UNA секции
                                                                                                      это может быть именем пациента, именем доктора или именем лаборанта в зависимости от вторичной структуры

                                                                                                      Странно. У вас точно был едифакт?
                                                                                                        0
                                                                                                        Вроде да.

                                                                                                        Выглядит это вот так:

                                                                                                        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~

                                                                                                          0
                                                                                                          Похоже, хоть и нет обязательных с точки зрения UN/Edifact тегов.
                                                                                                          Если бы был заголовок, он выглядел бы как

                                                                                                          UNA:*.? ~

                                                                                                          У вас тильда является разделителем секций, звездочка разделитель данных, двоеточие — разделитель компонентов.
                                                                                                          Все что между тильдой и звездочкой — это имя секции. Поэтому NM1 — это однозначно имя сегмента. Это не может быть ничем другим. Ну, по крайней мере я могу так сказать глядя на приведенный вами кусок.
                                                                                                            0
                                                                                                            Представленный кусок — это HIPAA EDI 837 Healthcare Claim версии 5010. Более того, их там три типа — Professional, Institutional и Dental.
                                                                                                            NM1 несомненно имя сегмента, кто бы спорил, но вот какого именно сегмента — пациента, провайдера, сабскрайбера, биллера или кого?

                                                                                                            Прежде чем комментировать, не плохо бы хоть немного в предметной области разобраться.
                                                                                                              0
                                                                                                              Точно, я припоминаю эти слова. Я недолго там пробыл поэтому детали сразу не вспомнил.
                                                                                                                +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, то для по его парсинга не требовалось бы очевидно медицинское образование.
                                                                                                                  –1
                                                                                                                  Применительно к HL7 есть два вида парсинга, условно назовём их flat parsing и structure parsing. Что ты описываешь и что большинство, в том числе автор 300 строкового парсера делают, это flat parsing. HAPI реализует второй вид парсинга — structure parsing – причём ещё и типы данных распарсивает в отдельные структуры. И далее HAPI позволяет работать с этим используя либо собственные методы, либо в виде XML.

                                                                                                                  Несомненно, flat parsing также будет отлично работать, но ровно до того момента пока не придёт сообщение с двумя и более remittance detail группами, либо пока в группе не появится более одной внутренний группы или сегмента. То, что они прекрасно распарсятся даже не вопрос. Вопрос в том, будут ли они потом также прекрасно обработаны. Потому что flat parsing это скорее CSV. "Прекрасный XML" или JSON подобный результат даёт как раз HAPI, от которого чел упорно отказывается. В результате, в лучшем случае, парсер тупо падает, а в худшем данные теряются, о чём может стать известно через недели или месяцы работы в production. Со всеми неприятными вытекающими последствиями.

                                                                                                                  Применительно к X12 это как работа с loop группами.

                                                                                                                  Кстати, есть какой-то стандарт де-факто парсер для парсинга X12 сообщений аналогичный HAPI, акромя коммерческих типа того же BizTalk?
                                                                                          +19
                                                                                          Вот моя хистори. Семь лет проработал админом в небольшой айтишной фирмочке и в один ни разу не прекрасный день шеф объявил что контора закрывается ибо он уходит в семинарию учится на священника.
                                                                                            0
                                                                                            а обёртки стандартных функций — это классы? Т.е. эти функции являются внутренними методами класса-обёртки?
                                                                                            И зачем вообще создавать для функции обёртку?
                                                                                              0
                                                                                              ----пахло старым кожаным нижним бельём

                                                                                              Кроме БДСМ ничего в голову не приходит.
                                                                                                0
                                                                                                сайт ithappens.me все еще работает и там много много таких историй
                                                                                                  0
                                                                                                  Пока ещё работает.
                                                                                                  Кстати, уже три года как только работает.
                                                                                                  (Может, как ibash, ждут, пока наберётся 50, чтобы сразу зааппрувить?)
                                                                                                  +1
                                                                                                  Так это ж про нас прям: " в такой помешанной на документах компании документация к «чудесным» библиотекам должна быть точно набрана правильным шрифтом с идеально точным оттенком, с правильными заголовками глав и названиями разделов. Но документации… не было" :) Все с тебя требуют подробные отчеты и инструкции, но никто тебе документацию не представляет.
                                                                                                    +1
                                                                                                    он написал общий парсер из одного класса в 300 строк

                                                                                                    У меня был ровно такой случай: в связи с изменением структуры БД перестала работать программа синхронизации баз на нескольких серверах. Мне поручили внести исправления.
                                                                                                    Там были тысячи строк, содержащие явные имена таблиц и полей. Разбираться в них не было никакого желания, да и времени потребовалось бы вагон.
                                                                                                    Написал программу синхронизации, независимую от структуры базы. Уложился строк в двести-триста. То ли голландцы, писавшие код до меня, были совсем малограмотными, то ли им платили за строчку кода.
                                                                                                      +1
                                                                                                      Небольшое пояснение для того большинства, которое вообще не курсе о чём идёт речь.

                                                                                                      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.
                                                                                                        +2
                                                                                                        Как-то когда искал работу, наткнулся на контору (не помню, что разрабатывала), которая располагалась в переделанной квартире. Так вот, помещение, в котором располагались программисты, совмещало в себе также функции прихожей (при том что вход был прорублен напрямую с улицы, безо всяких тамбуров), кухни и кладовки для разного хлама. Пахло пельменями и нестираными носками. Начальник сидел в отдельном помещении и спрашивал меня, кем я вижу себя через 10 лет, а заодно рассказывал, как один из выходцев из его компании уехал работать в Калифорнию. Убегая от них, я чуть не забыл зонтик, хотя на улице шёл мелкий дождь со снегом.

                                                                                                        А историй про работу с госконторами, которые придираются к неправильному шрифту, но им пофиг на содержимого ТЗ, а потом оказывается, что им вовсе не это нужно было, я думаю, в каментах и так наберётся десятка три.
                                                                                                          +1
                                                                                                          #СебастьянИШрифты
                                                                                                          Как-то настраивал WEB-сервер под сайт компании. Программист говорит «Открой наружу порт 3306 — я буду из под винды цепляться из дома к БД». И никакие уговоры не помогли. Была служебка «Открыть» подписанная у директора (ему хрен чего докажешь). Проходит время, «нас» ломают и мы получаем письмо в котором нам намекают, что помимо прочего надо бы порт закрыть. Закрываю по устному распоряжению директора. Скандал с «программистом» типа я не даю работать. Служебка за подписью директора открыть опять и требование написать объяснительную либо почему открыл тогда (служебку старую потерял) либо почему закрыл без служебки сейчас. В любом случае итог -10% ЗП.
                                                                                                          Чтоб было понимание: дырявый сайт на собственном сервере внутри сети, дырявый шлюз под win2003 не обновлявшийся никогда (с 2005 года), 1С в той-же физической сети, что и WEB+почта. У каждого сотрудника по 2 компа просто для того, чтобы были разные IP-адреса. Типа один для интернет другой для 1С. Вопрос «Что помешает потенциальному преступнику сменить IP и добраться до 1С» остался без ответа. Я там выдержал 5 месяцев — очень нужны были деньги и кабинет был вполне :-)

                                                                                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                                          Самое читаемое