Pull to refresh

Comments 117

UFO just landed and posted this here
Виста не была столь плоха, больше похоже что собирали компьютер и настраивали её те же, кто писал странные библиотеки. И Себастьян ну очень упорный, я бы после цветового оформления отказался.
Пишу это с ноутбука под Vista. 10 лет, полет нормальный.
Себастьян, ты? Бросай эту работу и эти дурацкие шрифты.
И Себастьян ну очень упорный, я бы после цветового оформления отказался.
Вы не нацелены на результат, мы вам перезвоним.
Кстати да, в Висте, по сути, произошло много важных и полезных изменений в ядре ОС. Семёрка лишь добавила рюшечек и пофиксила явные баги UI.
Вспомнил, как лет 12 назад скачивал, распечатывал и с упоением читал официальное русскоязычное трёхсотстраничное руководство по Висте. Описывался не только интерфейс, а и некоторые «подкапотные» фишечки.

Ещё статьи Руссиновича тогда на меня впечатление произвели, особенно смаковал его
Управление учетными записями пользователей Windows Vista: взгляд изнутри

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

Я б, наверное, остался. Во-первых, люблю сложные задачи. Во-вторых, не захотел бы пополнить собой «список неудачников, не справившихся со шрифтом за 4 года».

Немного удивился, как можно было напутать с цветами. В Википедии сказано, что зелёный — это 00FF00, а фиолетовый — это 5A009D. Полагаю, просто существуют разные стандарты соответствия «название цвета — шестнадцатиричный код»…
Подтверждаю HAPI — это стон что здесь песней зовется.
UFO just landed and posted this here
Да, один знакомый улетал в другую страну на 2 месяца, чтоб внедрить софт, который разрабатывали. Но, чтоб 2 года…
Как-то я работал в одной компании и ездил в командировку на крайний север на обследование на пару дней. Дело было в декабре, стоял мороз за 40. Начальник отдела, что нас принимал, возил нас на своей машине из отеля на объект и обратно. Как-то раз, проезжали мимо группы людей в затянутых по самый нос капюшонах алясках, которые медленно и уныло брели в отель через пургу. Начальник сказал — а это коллеги из компании XXXX уже полгода воюют с нашим отделом YYYYY, пытаясь внедрить систему ZZZZZ и конца и края не видно. Я тогда их очень сильно пожалел…
А потом случилось так, что теперь теперь сам тут работаю :)
Для внедренцев-консалтеров абсолютно нормально быть в командировке полгода, бывает, и дольше. Конечно, обычно они летают домой, и часть времени работают в своем офисе, но все-равно в полях — основная работа.

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

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

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

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

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

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

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

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

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

просто видимый свет у нас сортируют по длине волны, а в остальной галактике — по частоте
просто видимо ему надо было показать кто в доме хозяин, а в кнопках это было проще всего)
когда я учился в ТРТУ, был у нас один очень своеобразный преподаватель. ну знаете, из тех кто «то что вы принесли мне лабу(курсовик) это просто повод для начала разговора». сдавали с 8 утра до 11 ночи. сдавали по пять раз. приходили пересдавать утром и уходили вечером потому что просто не смогли зайти на пересдачу (он за день принял всего троих из толпы (сдали двое)).
но тем не менее, имелся верный хак. нужно было организовать рояль в кустах — поместить явную локальную нелепицу и пару нарушений правил оформления на видное место. он это заметит, раскатает тебя в блин… ты посидишь с сокрушённым видом, пойдёшь в общагу, достанешь заранее напечатанные листы с правильным вариантом, вставишь в отчёт/курсовой и через пару дней придёшь на пересдачу. посмотрит — ну вот, давно бы так — давай зачётку.
главное чтоб не забыл что он тебя уже вытрепал, а то начнётся по новой)
подготовка к жизни в подобных компаниях, блин)
В госкорпорации одной так и делается. В документ нужно накидать очевидной херни, чтобы начальники могли их повычеркивать с чувством собственной значимости, ты потом это переделываешь, и несешь на подпись Иван Иванычу с благодарностью, какой он внимательный и мудрый. Иногда они что-то пропускают, и эта чушь остается жить в финальной версии.
про это даже Dilbert есть:
image
Напомнило как я в своё время чертежи сдавал преподавательнице на первом курсе.
5 раз я снова и снова выслушивал надуманные недочёты и вносил изменения по одному из чертежей.
Дошло до того, что сдал я этот чертёж только в 6 раз, причём просто принеся свой изначальный вариант работы.
Я тогда ещё получил такой ответ преподавательницы: «Другое дело. Вот так бы сразу и начертил.»
Говорить, что я собственно так сразу и начертил я конечно не стал)
UFO just landed and posted this here
По вольной ассоциации мне вспомнилась прямо противоположная история.

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

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

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

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

Один в один моя история о_О Не на радиотехническом УПИ случайно учились?

Даже и близко нет)
Думаю с подобной ситуацией сталкивался практически каждый студент технической специальности))

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

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

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

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

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

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


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

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

Один комп нормальный — для разработки. Второй старый — для тестирования и отлавливания «узких мест». Периферию через KVM. Такой вариант вас бы устроил? Естественно, если бы стояла задача написания оптимальной по ресурсам программы.
Нормальный хард — это SSD

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

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

А почему нельзя сделать один метод, который вернёт пустой список, список из одного элемента или список из нескольких элементов, соответственно?
Да запросто. А теперь представь, поскольку стандарт делается не под конкретного Васю Пупкина из 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 сообщений.
> и это всё в 300 строк кода!
> поскольку стандарт делается не под конкретного Васю Пупкина из 2-ой клиники,
Вы только что ответили на свой вопрос

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

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


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

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

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

UFO just landed and posted this here
Квадратичный алгоритм на пустом месте плох независимо от способа создания кода.
UFO just landed and posted this here
Нет никакого смысла в генерации нового массива элементов только для того чтобы узнать его длину на каждой итерации. Даже если длина не больше 5.

Могу я узнать причину минуса? Кто-то считает, что узнавать длину массива за 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");
    }
}
UFO just landed and posted this here
и не уберет, если внутри каждой итерации будут вызываться методы, про которые оптимизатор ничего не знает (вдруг они исходную коллекцию модифицируют, так что ее длина меняется?)
Если уж обычная итерация по линейному списку
IEnumerable<EHC_E15_PRODUCT_SERVICE_SECTION> PRODUCT_SERVICE_SECTIONs
будет стоить O(n^2), то такой генератор кода надо выбрасывать.

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


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

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

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


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

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

UFO just landed and posted this here
Думаю, стоит всё же объяснить — в чём же сложность решения проблемы потенциального наличия во многих свойствах [0..n) значений? Первопричина этого мне понятна — там действительно может много значений, а может не быть ни одного. Но настолько ли эта причина глубокая?
Если проблема кажется простой, но простой на самом деле не является, то стоит объяснять, почему она не простая, а не спрыгивать тут же на «лучшие умы целым отделом полгода думали, как лучше сделать, так что нечего лезть со своими предложениями». А иногда простые проблемы — это действительно простые проблемы, с простыми решениями.
UFO just landed and posted this here
Я почти 15 лет занимаюсь интеграциями на Java с API очень крупных компаний (вплоть до гугла), так вот в 99 случаях из 100, когда ты видишь кривой интерфейс API дело совсем не в том, что технически его нельзя сделать проще (и часто даже не в том, что разработчики криворуки).

Например, не секрет, что разработчики open source проектов часто зарабатывают основные деньги на консультациях и платной помощи. А в не open source сложность системы не позволяет легко с нее перейти к конкурентам (плюс платный саппорт тоже приносит немалые деньги). Вывод — делать слишком простую систему зачастую невыгодно для разработчиков. Просто бизнес, ничего личного.
UFO just landed and posted this here
Если бы она всегда работала, то запланированного устаревания техники и сознательного усложнения ее ремонта не существовало бы. Фразе «Is fecit cui prodest» (Сделал тот, кому это было выгодно) на пару тысяч лет больше. :)
Я вовсе не утверждал, что конкретно этот код можно заменить сотней строк, просто выразил неудовольствие подходом «раз сделано сложно, значит так было надо». Я слишком часто вижу, что сложный код для работы с простым проблемным доменом (а проблема возвратить [0; n) элементов — это простая проблема) это скорее признак недостаточного понимания, чем признак того, что проблема на самом-то деле сложна.

Конкретно по этому коду моё лично впечатление от представленных кусочков — это, банально, легаси-код. Сначала там всегда был один элемент и ошибка если его нет, но просят. Потом оказалось, что значений бывает несколько, но старый код для одного значения решено было оставить для краевых случаев (надеюсь, с ошибкой если просят один, а на самом деле там несколько). Потому были добавлены семейства методов getLength<Property> и getElement<Property>(index). Идея позволить доступ обычной итерацией тогда никому в голову не пришла, а когда пришла — уже был написан код, ломать который просто так никто не захотел, и прежние два метода с доступом по индексу убирать не стали.
UFO just landed and posted this here
еще легаси и поддержание обратной совместимости в копилку к тому что я говорил

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

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

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

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

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


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

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

Под капотом я бы там много чего поменял, но API нормальное.
Нормальная ситуация. :) Я проехал 3200 миль на новое место работы, 4 ночи из них две в палатке.
Представил подписывание трудового договора у костра, смолтолки с коллегами у ручья, вызов к начальнику в палатку.
А я бы так даже поработал недельку-две в году. Было бы офигенно.
Начал читать как выдуманный текст с вкраплениями известных персонажей, потом смутили фотки, к концу уже пришло осознание реальности истории.

Потом уже просто офигевал от этой Сима-Ленд…
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
HAPI напомнил известный в электроэнергетике протокол- IEC 61850/8.1
Кто сталкивался тот поймет ощущение незабываемых недель, когда два крупных вендора (или даже два отдела одного очень крупного вендора) пытались наладить связь друг с другом, в тот момент когда вендор поменьше городил все новые if-чики, что бы связаться хоть с кем-то.
Таких протоколов/форматов данных полно. Есть еще UN/EDIFACT. Не абы кто, а спасители человечества из самого ООН придумали.
UFO just landed and posted this here
Я писал парсер этого чуда. Его нельзя распарсить без словаря. А так как это семейство форматов, то на каждый случай свой словарь.

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

Там конечно есть элементы для структуры, но я так и не понял зачем они нужны.
UFO just landed and posted this here
Простым сплитом можно получить список элементов. А чтобы восстановить структуру нужно знать какие есть группы и из каких элементов они состоят. Произвольную вложенность он не поддерживает.

Хотя это было давно и поверхностно, может я чего и упустил.
UFO just landed and posted this here
Вот у меня есть имя сегмента NM1 это может быть именем пациента, именем доктора или именем лаборанта в зависимости от вторичной структуры (У меня это медицинские данные были).

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

Я бизнес логикой вообще не занимался. Моя задача была все это в доменную модель смапить.
UFO just landed and posted this here
Вроде да.

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

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~

UFO just landed and posted this here
Представленный кусок — это HIPAA EDI 837 Healthcare Claim версии 5010. Более того, их там три типа — Professional, Institutional и Dental.
NM1 несомненно имя сегмента, кто бы спорил, но вот какого именно сегмента — пациента, провайдера, сабскрайбера, биллера или кого?

Прежде чем комментировать, не плохо бы хоть немного в предметной области разобраться.
Точно, я припоминаю эти слова. Я недолго там пробыл поэтому детали сразу не вспомнил.
UFO just landed and posted this here
Применительно к 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?
Вот моя хистори. Семь лет проработал админом в небольшой айтишной фирмочке и в один ни разу не прекрасный день шеф объявил что контора закрывается ибо он уходит в семинарию учится на священника.
а обёртки стандартных функций — это классы? Т.е. эти функции являются внутренними методами класса-обёртки?
И зачем вообще создавать для функции обёртку?
----пахло старым кожаным нижним бельём

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

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

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

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

«Завтра к 9 часам утра у вас должен быть готовый проектный документ на шести страницах
Пропущены подчеркнутые слова (We need a six-page design document by 9AM tomorrow.).

Перевод, местами, конечно, "фрилансерский". Это же не русский, ребята..

Каждый узнал немного себя в Себастьяне :)
Sign up to leave a comment.

Articles