Ниже привели пример стандарта из области книгоиздательства, но там name и key name. Если считать last name - это всегда key name (в русской культуре это будет фамилия, в исландской - отчество), то логика прослеживается. Но тогда уж и назвать поле key_name.
Транслит выглядит ужасно, конечно. Но представьте, что некая сущность из предметной области не имеет эквивалента в английской/американской культуре и, соответственно, не может быть адекватно переведена. Как бы Вы её назвали?
Разделение на name и key name выглядит логичным и удобным для книгоиздателей. Например, неключевое имя можно, наверное, сократить до инициалов в библиографии.
Но для документооборота, по крайней мере в России, на мой взгляд не очень: слишком громоздко и не имеет отчества в виде отдельного поля.
При всём радикализме (подводные камни коллеги уже указали) сам подход подкупает: что может быть естественнее, чем брать имена для доменной модели непосредственно из предметной области? И на родном для неё языке.
Прочитав статью я не понял суть проблемы, стоявшей перед автором. Поэтому мой комментарий может быть нерелевантным.
В общем случае, объектная модель, реализованная на back-end не может быть без изменений перенесена на front-end. Для последнего всегда создаются какие-нибудь views. Исключение - это всякие специфичные CRUD-интерфейсы, вероятно у автора что-то такое?
Писать на GWT и ему подобном может казаться быстрым, пока не случится какая-нибудь непонятная проблема (например баг в реализации, баг в браузере, недокументированное поведение компонента и пр.). На поиск проблемы может уйти всё сэкономленное время, а решение и вовсе может не найтись. Всё же лучше использовать отдельные инструменты для back- и front-end.
Но вообще написать драйвер для АЦП, реализующий SCPI-вольметр, — отличная идея. Если его дополнить эмулятором последовательного порта, то получим программный адаптер. В ряде случаев может получиться замена лабораторному вольтметру.
К тому же вольтметры позволяют переключать диапазоны измерений, например в В7-28 их 5 по постоянному напряжению. Программно это не реализовать без радикальной потери в точности.
Часть функциональности возможно решить только схемотехнически, например автоподстройка ноля, или регулировка входного сопротивления.
Шумоподавление и усреднение можно реализовать программно, при этом частоту опроса АЦП потребуется сделать максимально возможной. Правда 7 знаков вряд ли получится. И, наверное, схемотехническое решение всё равно даст выигрыш в точности, но не берусь утверждать — не специалист.
К сожалению, не могу помочь, у нас в лаборатории нет Щ-300.
Когда я писал прошивку для В7-28, то пользовался техническим описанием (в бумажном виде), а непонятные места проверял на действующем приборе.
Если измерять напряжение простым АЦП, то Вы получите шум уже во 2-3 знаке, в первую очередь из-за наводок по цепи питания 50 Гц. АЦП это только часть цифрового вольтметра.
Это не нарушает условия пользования YouTube?
А какая связь между возможностью платной поддержки и наличием закрытого кода?
Автор, пока писал статью, боролся с искушением добавить шутку на тему «родителя №» ;)
Ниже привели пример стандарта из области книгоиздательства, но там name и key name. Если считать last name - это всегда key name (в русской культуре это будет фамилия, в исландской - отчество), то логика прослеживается. Но тогда уж и назвать поле
key_name.При всех недостатках это официальный документ. Предметная область как она есть.
Транслит выглядит ужасно, конечно. Но представьте, что некая сущность из предметной области не имеет эквивалента в английской/американской культуре и, соответственно, не может быть адекватно переведена. Как бы Вы её назвали?
Правда, сама предметная область может измениться в процессе автоматизации, одни сущности добавятся, другие исчезнут.
Ну в России, положим, «по бумажкам» должны быть имя и фамилия, но не first/last. В США, конечно, другое дело.
Разделение на name и key name выглядит логичным и удобным для книгоиздателей. Например, неключевое имя можно, наверное, сократить до инициалов в библиографии.
Но для документооборота, по крайней мере в России, на мой взгляд не очень: слишком громоздко и не имеет отчества в виде отдельного поля.
При всём радикализме (подводные камни коллеги уже указали) сам подход подкупает: что может быть естественнее, чем брать имена для доменной модели непосредственно из предметной области? И на родном для неё языке.
Не уверен насчёт анкеты, но в СНИЛСе у неё скорее всего было бы Романова Екатерина Алексеевна.
Недоступно из России.
А как проверяются сетевые ошибки, например когда вообще не удалось подключиться к сервису?
Ничего не сказано про локализацию.
Прочитав статью я не понял суть проблемы, стоявшей перед автором. Поэтому мой комментарий может быть нерелевантным.
В общем случае, объектная модель, реализованная на back-end не может быть без изменений перенесена на front-end. Для последнего всегда создаются какие-нибудь views. Исключение - это всякие специфичные CRUD-интерфейсы, вероятно у автора что-то такое?
Писать на GWT и ему подобном может казаться быстрым, пока не случится какая-нибудь непонятная проблема (например баг в реализации, баг в браузере, недокументированное поведение компонента и пр.). На поиск проблемы может уйти всё сэкономленное время, а решение и вовсе может не найтись. Всё же лучше использовать отдельные инструменты для back- и front-end.
Шумоподавление и усреднение можно реализовать программно, при этом частоту опроса АЦП потребуется сделать максимально возможной. Правда 7 знаков вряд ли получится. И, наверное, схемотехническое решение всё равно даст выигрыш в точности, но не берусь утверждать — не специалист.
Когда я писал прошивку для В7-28, то пользовался техническим описанием (в бумажном виде), а непонятные места проверял на действующем приборе.