IT-компании
Управление персоналом
Управление разработкой
Комментарии 106
+4
Шедеврально.
Спасибо, день стал чуть менее серым :))
+16
Виста не была столь плоха, больше похоже что собирали компьютер и настраивали её те же, кто писал странные библиотеки. И Себастьян ну очень упорный, я бы после цветового оформления отказался.
+2
И Себастьян ну очень упорный, я бы после цветового оформления отказался.
Вы не нацелены на результат, мы вам перезвоним.
+5
Кстати да, в Висте, по сути, произошло много важных и полезных изменений в ядре ОС. Семёрка лишь добавила рюшечек и пофиксила явные баги UI.
+1
Вспомнил, как лет 12 назад скачивал, распечатывал и с упоением читал официальное русскоязычное трёхсотстраничное руководство по Висте. Описывался не только интерфейс, а и некоторые «подкапотные» фишечки.

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

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

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

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

+2

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

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

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

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

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

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

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

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

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

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

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

0
Я один раз сдал чертеж с первого раза… Начертил я чертеж, но сделал слишком много исправлений, поэтому не поленился и перечертил идеально на новый лист. Результат? «Это не ты чертил, 3!»
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
разработчику надо давать самый-самый медленный компьютер для тестов
+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 может скрываться куча вычислений.

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 сложность системы не позволяет легко с нее перейти к конкурентам (плюс платный саппорт тоже приносит немалые деньги). Вывод — делать слишком простую систему зачастую невыгодно для разработчиков. Просто бизнес, ничего личного.
+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
А я бы так даже поработал недельку-две в году. Было бы офигенно.
+3
Начал читать как выдуманный текст с вкраплениями известных персонажей, потом смутили фотки, к концу уже пришло осознание реальности истории.

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

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