Comments 117
И Себастьян ну очень упорный, я бы после цветового оформления отказался.Вы не нацелены на результат, мы вам перезвоним.
Ещё статьи Руссиновича тогда на меня впечатление произвели, особенно смаковал его
Управление учетными записями пользователей Windows Vista: взгляд изнутри
Виста начала давать по рукам за попытки играть с объектами ядра. Плюс известная история про баг в определении версии винды if (Major >= 5 and Minor >= 1) ...
, который перестал работать с вистой 6.0
, но работал с семеркой 6.1
. Можно было бы подумать, что это байка, но в винда реально врет о своей версии, если не проставить магический гуид в манифесте типа "я знаю, что ты врешь". Например, десятка будет упорно врать, что она семерка, пока не пропишешь <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
в манифесте.
Немного удивился, как можно было напутать с цветами. В Википедии сказано, что зелёный — это 00FF00, а фиолетовый — это 5A009D. Полагаю, просто существуют разные стандарты соответствия «название цвета — шестнадцатиричный код»…
А потом случилось так, что теперь теперь сам тут работаю :)
Одного моего знакомого в перестроечное время отправили в командировку в Африку испытывать уральскую дорожную технику. Ненадолго, на месяц. Потом попросили ещё побыть там, ибо мало было специалистов со знанием французского. Потом ещё и ещё… В итоге в Африке он год проторчал.
Это API с приблизительно 15 тысячами вызовов методов! О чём вообще думали эти разработчики?
О том, что никто никогда не уволит единственного человека, знающего как работают 15 тысяч методов этого API? Сознательное переусложнение системы, чтобы фирма/разработчик стал совершенно незаменимым, увы, встречается достаточно часто.
Скорее всего ребята написавшие этот HAPI получают огромные деньги на обучениях и консультациях пользователей API. Просто это такой бизнес.
Хахах, однажды нарвался на компанию в которой гендир лично проверял оттенки кнопок, ни разу не обратив внимание на функционал. Так же он был категорически против специализированных баг-трекеров и все проекты велись в трелло, где срочность задачи он определил цветом. Красный — минимальный приоритет, фиолетовый — наивысший.
когда я учился в ТРТУ, был у нас один очень своеобразный преподаватель. ну знаете, из тех кто «то что вы принесли мне лабу(курсовик) это просто повод для начала разговора». сдавали с 8 утра до 11 ночи. сдавали по пять раз. приходили пересдавать утром и уходили вечером потому что просто не смогли зайти на пересдачу (он за день принял всего троих из толпы (сдали двое)).
но тем не менее, имелся верный хак. нужно было организовать рояль в кустах — поместить явную локальную нелепицу и пару нарушений правил оформления на видное место. он это заметит, раскатает тебя в блин… ты посидишь с сокрушённым видом, пойдёшь в общагу, достанешь заранее напечатанные листы с правильным вариантом, вставишь в отчёт/курсовой и через пару дней придёшь на пересдачу. посмотрит — ну вот, давно бы так — давай зачётку.
главное чтоб не забыл что он тебя уже вытрепал, а то начнётся по новой)
подготовка к жизни в подобных компаниях, блин)
5 раз я снова и снова выслушивал надуманные недочёты и вносил изменения по одному из чертежей.
Дошло до того, что сдал я этот чертёж только в 6 раз, причём просто принеся свой изначальный вариант работы.
Я тогда ещё получил такой ответ преподавательницы: «Другое дело. Вот так бы сразу и начертил.»
Говорить, что я собственно так сразу и начертил я конечно не стал)
Кафедра зоологии позвоночных, зачет по вирусологии. Преподавательница слушает студентов, слушает, морщится, но зачеты ставит. Если задуматься, то и вправду зоология позвоночных от вирусологии удалена достаточно, чтобы не пригодиться практически никогда.
Очередной студент сообщает, что вирусы размножаются делением. Преподавательница светлеет лицом.
— Знаете, я с утра сижу и думаю, кого бы с вашей кафедры заставить выучить вирусологию?..
Вам повезло!
просто выводит ответ в консоль: std::count << ответ. )
Когда он узнал в конце о таком обмане, был, мягко говоря, не доволен.
Один в один моя история о_О Не на радиотехническом УПИ случайно учились?
Это называется "метод волосатой руки", поищите историю ;-)
Как писно с моей бывшей конторы. Только чуть отличается. Сдаёшь регламент в архитектурный штаб. Они кучу пометок и коментов в документ вставляют. Удаляешь всю чушь, что они в ответ написали, ждёшь два часа и снова отправляешь. С 90% вероятностью документ согласовывают.
подготовка к жизни в подобных компанияхВ отличие от университета и конкретного курса из компании можно уйти в более адекватную. Таких к счастью много.
У вас гендир, видимо, использовал цвета радуги, чтобы оценить степень приоритета.
информационные центры в World Wide Web, созданные для коллекционирования мудрости лучших умов отрасли в знакомом и удобном формате вопросов и ответовсамое поэтичное определение stackoverflow которое можно придумать))
Устроился на работу в крупную контору,
Дали брендовый комп с мизерным количеством оперативной памяти, на котором IDE запускался пару минут, и работал адово медленно.
Зато безопасность/секьюрность — были на высшем уровне, работа была в винде (а я, вообще-то разраб под никсы), чтобы что-то поставить, надо отловить специального человека, только он мог поставить нужный софт. Выход в интернет был тоже непростой, приложения типа git и т.п. не могли просто так взять и получить что-то с гитхаба.
Работал 2 недели, все эти 2 недели ждал новые плашки памяти (которые не абы какие, а какие-то фильдиперсовые, просто так не купить) и заодно нормальный хард на 1тб.
Поставить никсы? Надо согласовать, жди, и когда-нибудь дождешься.
Поставить нормальный комп? У нас по регламенту только такие, жди апгрейд.
По прошествии двух недель, устав от бесконечных тормозов вверенной мне тачки, а также от болтовни сотрудников, которые находились со мной в одном помещении, и колторые не прекращали общаться на отвлеченные темы, я решил что хватит.
И да, ежедневные отчеты о проделанной работе.
Так-то и з/п предлагалась хорошая, но я осознал, что уставать можно не только от напряженной работы, но и от монотонного ожидания пока отвиснет IDE.
И ждать окончания компиляции часами? Это тоже самое что пересадить таксистов на запорожцы.
Просто ТЗ должно быть правильное и тестирование.
Когда в лохматые годы я верстал страничку в нашей конторе то после проверял как она смотрится во ВСЕХ браузерах и если есть косяки то устранял.
Тогда еще был жив Netscape Navigator.
- Определиться что есть «слабое железо» (т.е. сформулировать требования к оборудованию, на котором это будет работать.)
- Требовать чтобы оно так было (т.е. вписать сие в ТЗ)
- Тестировать на «слабом» железе (т.е. проверять соответствие результата ТЗ)
- Ну и крайне желательно чтобы это вообще было осуществимо (т.е. чтобы ТЗ было боле-менее реалистичным. Рендерить фотореалистичную анимацию в реалтайме на древнем компе не возможно)
Все, больше ничего. И нечего разработчику придумывать лишние неудобства в виде слабого компа, это лишь будет его раздражать напрасно и снижать производительность.
разработчику надо давать самый-самый медленный компьютер для тестов
Разработчику по БД и серверных приложений особенно :)
Очень похоже на ИТ в магните
Соответственно группа может быть пропущена, может быть одна, а может быть множество. Поэтому HAPI использует разные подходы чтобы вытащить из подобных структур данные — без итерации, с итерацией и пр.
И, оказывается, это можно заменить на 300 строк кода! Жаль в оригинале ссылки нет на этот шедевр.
Я правильно понял, что более 100 типов HL7v2 сообщений, созданных из комбинации почти 200 сегментов с использованием около 90 типов данных (многие из которых сложные), да всё это ещё и помноженное на версии от 2.1 до 2.9 — и это всё в 300 строк кода! Вы серьёзно!?
Или аноним тупо распарсил EHC_E15 (Payment/Remittance Advice) сообщение согласно спеке какого-нибудь LabCorp для одной единственной версии стандарта HL7v2? Если именно так, то это можно и в две строчки сделать — берём HAPI контекст, парсим в XML. Далее используем всё что угодно, вплоть до E4X чтобы достучаться до каждого поля.
Соответственно группа может быть пропущена, может быть одна, а может быть множество. Поэтому HAPI использует разные подходы чтобы вытащить из подобных структур данные — без итерации, с итерацией и пр.
А почему нельзя сделать один метод, который вернёт пустой список, список из одного элемента или список из нескольких элементов, соответственно?
Какой же комитет такие форматы сознательно пишет и аппрувит? Или это все эволюционные наслоения на говно мамонта?
Небось, до сих пор длина текстовых полей ограничена в 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);
}
}
}
Никого ничего не смущает?
Могу я узнать причину минуса? Кто-то считает, что узнавать длину массива за 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");
}
}
IEnumerable<EHC_E15_PRODUCT_SERVICE_SECTION> PRODUCT_SERVICE_SECTIONs
будет стоить O(n^2), то такой генератор кода надо выбрасывать.Что мешает PRODUCT_SERVICE_SECTIONRepetitionsUsed посчитать 1 раз до начала итераций? Потому что где еще можно взяться квадрат я не представляю.
А вообще оборачивать тяжелые вычисления в "свойства" я считаю плохой практикой. Пользователь должен понимать, что за foo.X + foo.X может скрываться куча вычислений.
Да и вообще: «Мы живем в мир быстрых процессоров, нечего экономить на спичках».
Соответственно группа может быть пропущена, может быть одна, а может быть множество. Поэтому HAPI использует разные подходы чтобы вытащить из подобных структур данные — без итерации, с итерацией и пр.
И, оказывается, это можно заменить на 300 строк кода!
Да запросто, возвращаем всегда множество и всегда итерируем. За счет унификации функции обработки можно переиспользовать и объединять в цепочки. 2 фамилии значит 2 элемента будет, 0 значит пустой массив. В HTML это стандартная ситуация, jQuery потому и стала популярной, что она это всё инкапсулирует.
берём HAPI контекст, парсим в XML. Далее используем всё что угодно, вплоть до E4X чтобы достучаться до каждого поля.
Ну он так и сделал видимо. Значения же не меняются от способа получения.
[0..n)
значений? Первопричина этого мне понятна — там действительно может много значений, а может не быть ни одного. Но настолько ли эта причина глубокая?Если проблема кажется простой, но простой на самом деле не является, то стоит объяснять, почему она не простая, а не спрыгивать тут же на «лучшие умы целым отделом полгода думали, как лучше сделать, так что нечего лезть со своими предложениями». А иногда простые проблемы — это действительно простые проблемы, с простыми решениями.
Например, не секрет, что разработчики open source проектов часто зарабатывают основные деньги на консультациях и платной помощи. А в не open source сложность системы не позволяет легко с нее перейти к конкурентам (плюс платный саппорт тоже приносит немалые деньги). Вывод — делать слишком простую систему зачастую невыгодно для разработчиков. Просто бизнес, ничего личного.
[0; n)
элементов — это простая проблема) это скорее признак недостаточного понимания, чем признак того, что проблема на самом-то деле сложна.Конкретно по этому коду моё лично впечатление от представленных кусочков — это, банально, легаси-код. Сначала там всегда был один элемент и ошибка если его нет, но просят. Потом оказалось, что значений бывает несколько, но старый код для одного значения решено было оставить для краевых случаев (надеюсь, с ошибкой если просят один, а на самом деле там несколько). Потому были добавлены семейства методов
getLength<Property>
и getElement<Property>(index)
. Идея позволить доступ обычной итерацией тогда никому в голову не пришла, а когда пришла — уже был написан код, ломать который просто так никто не захотел, и прежние два метода с доступом по индексу убирать не стали.еще легаси и поддержание обратной совместимости в копилку к тому что я говорил
Нет, наоборот. Легаси и поддержание обратной совместимости (а так же странные пожелания заказчиков или менеджеров) может сделать API и код ужасным независимо насколько умные и квалифицированные ребята над ним работали. То есть утверждение «раз его умные ребята писали, код должен быть хорошим, качественным» не верно.
подобное допустимо только от человека который очень хорошо знаком с системой и требованиями.
Так можно оправдать абсолютно любой ужасный код и архитектуру (вы не работали десять лет с этим кодов, поэтому вы не можете о нем судить).
В большинстве случаев откровенно странные решения можно увидить даже после короткого код ревью, понятно небольшой кол-во таких решений можно объяснить хитрым замыслом, но в одной книги говорилось что качество кода можно определить количеством WTF, который произнесет незнакомый с кодом разработчик, изучая/используя этот код. И если у разработчик произносит WTF постоянно в 99.9% случаях этот код фигня.
Вам не кажется, что подобное утверждение, эмм, несколько самонадеянно?
Согласен, но я не вижу причин не доверять информации из статьи. Человек написал расширяемый парсер, достаточный для текущих и будущих задач. По моему опыту это возможно, ситуация с 0..N элементов есть и в других областях, и есть методы работы с ней. Так что говорить "так не бывает" тоже некорректно.
Мне вот вообще непонятно, зачем возвращать одиночный объект, если потенциально может быть массив. Возможно это из-за ограничений XML, где если вложенный тег один, то нельзя определить, массив это или свойство объекта. Замена библиотечного парсера на свой с указанием "всегда мапить в массив" действительно может решить эту проблему.
Под капотом я бы там много чего поменял, но API нормальное.
Потом уже просто офигевал от этой Сима-Ленд…
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
Кто сталкивался тот поймет ощущение незабываемых недель, когда два крупных вендора (или даже два отдела одного очень крупного вендора) пытались наладить связь друг с другом, в тот момент когда вендор поменьше городил все новые if-чики, что бы связаться хоть с кем-то.
Если хочется пропустить группу, то нужно ее полностью распарсить.
Там конечно есть элементы для структуры, но я так и не понял зачем они нужны.
Хотя это было давно и поверхностно, может я чего и упустил.
Апостроф? У меня разделители были другие. Хотя они там могут быть любыми.
Я бизнес логикой вообще не занимался. Моя задача была все это в доменную модель смапить.
Выглядит это вот так:
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~
NM1 несомненно имя сегмента, кто бы спорил, но вот какого именно сегмента — пациента, провайдера, сабскрайбера, биллера или кого?
Прежде чем комментировать, не плохо бы хоть немного в предметной области разобраться.
Несомненно, flat parsing также будет отлично работать, но ровно до того момента пока не придёт сообщение с двумя и более remittance detail группами, либо пока в группе не появится более одной внутренний группы или сегмента. То, что они прекрасно распарсятся даже не вопрос. Вопрос в том, будут ли они потом также прекрасно обработаны. Потому что flat parsing это скорее CSV. "Прекрасный XML" или JSON подобный результат даёт как раз HAPI, от которого чел упорно отказывается. В результате, в лучшем случае, парсер тупо падает, а в худшем данные теряются, о чём может стать известно через недели или месяцы работы в production. Со всеми неприятными вытекающими последствиями.
Применительно к X12 это как работа с loop группами.
Кстати, есть какой-то стандарт де-факто парсер для парсинга X12 сообщений аналогичный HAPI, акромя коммерческих типа того же BizTalk?
И зачем вообще создавать для функции обёртку?
Кроме БДСМ ничего в голову не приходит.
он написал общий парсер из одного класса в 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.
А историй про работу с госконторами, которые придираются к неправильному шрифту, но им пофиг на содержимого ТЗ, а потом оказывается, что им вовсе не это нужно было, я думаю, в каментах и так наберётся десятка три.
Как-то настраивал WEB-сервер под сайт компании. Программист говорит «Открой наружу порт 3306 — я буду из под винды цепляться из дома к БД». И никакие уговоры не помогли. Была служебка «Открыть» подписанная у директора (ему хрен чего докажешь). Проходит время, «нас» ломают и мы получаем письмо в котором нам намекают, что помимо прочего надо бы порт закрыть. Закрываю по устному распоряжению директора. Скандал с «программистом» типа я не даю работать. Служебка за подписью директора открыть опять и требование написать объяснительную либо почему открыл тогда (служебку старую потерял) либо почему закрыл без служебки сейчас. В любом случае итог -10% ЗП.
Чтоб было понимание: дырявый сайт на собственном сервере внутри сети, дырявый шлюз под win2003 не обновлявшийся никогда (с 2005 года), 1С в той-же физической сети, что и WEB+почта. У каждого сотрудника по 2 компа просто для того, чтобы были разные IP-адреса. Типа один для интернет другой для 1С. Вопрос «Что помешает потенциальному преступнику сменить IP и добраться до 1С» остался без ответа. Я там выдержал 5 месяцев — очень нужны были деньги и кабинет был вполне :-)
Пропущены подчеркнутые слова (We need a six-page design document by 9AM tomorrow.).
Перевод, местами, конечно, "фрилансерский". Это же не русский, ребята..
Любопытные извращения из мира ИТ