Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Воскресенье вечер

Раскопал, что лучше бы мне заменить домашний роутер: оказывается, у меня neutered model (возможно, Rinet мне поставил эту модель потому, что она стоила дешевле), а neutered -- это означает с маленькой памятью, нехватка которой приводит к зависаниям роутера под даже небольшой нагрузкой (http://dd-wrt.com/wiki/index.php/Version_5_And_6_Router_Information -- у меня как раз версия 6).
* * *
Николай Суслов начал работу по обеспечению коллаборативного программирования в Croquet -- http://nsuslovi.blogspot.com/2009/07/live-and-collaborative-coding-in.html

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

Мне все чаще кажется, что эти "виртуальные 3D-миры" и "игровые миры" просто обкатывают разные интересные концепции для совсем "неигровых" и "не3D-мировых" применений -- уж такова оказывается их роль в истории.
* * *
Неделю назад JetBrains выпустил первую версию MPS (http://www.jetbrains.com/mps/).

Как всегда с новыми технологиями, пока это вполне rocket science. Мне представляется, что работу "тупого программиста" делят на две части -- "нетупого программиста" (чтобы описать DSL и заставить все это работать) и "совсем тупого, возможно даже непрограммиста". Итого сложность не уменьшается, а просто оказывается более неравномерно распределенной по головам.

Через десять лет это все уже будет легко, понятно, и этому (работе с абстрактным синтаксисом, синтаксисом не-текстов) будут учить уже на первом курсе программистских специальностей (если, конечно, через десять лет сохранится понятие "первый курс").
* * *
В тупой работе, которой я занимаюсь сейчас целыми сутками, меня поддерживает только одно: учебники читать нынешние инженеры будут вряд ли, а вот стандарты на русском языке -- прочтут. Тупость работы несколько скрашивает тот факт, что каждые десять минут приходится решать какую-нибудь головоломку -- а каждую пару часов головоломка бывает даже интересна.
* * *
Если четко понимать, что за словом model не стоит ничего, кроме указания на описание неупоминаемого "чего-то" в соответствии с каким-то методом (т.е. model -- это просто элементарное описание в группе описаний aka view, порождаемой при помощи какого-то языка из соответствующего метода описаний aka viewpoint language), то нужно переводить model как "описание". И тогда огромные массивы айтишного канцелярита становятся существенно проще.

Если непонятное слово process (для которого десять раз потом делаются оговорки, что никакой последовательности действий не подразумевается, а речь идет только об описании строительного материала для процессов -- различие, четко зафиксированное только в SPEM 2 как MethodContent и use of MethodCotent) обозвать понятным словом "практика", то опять же -- айтишный канцелярит становится понятнее.

Если непонятное слово reference переводить как "типовой" (правда, это слово каждый раз нужно переводить по-разному, но часто -- именно "типовой"), и вновь айтишный канцелярит становится менее эзотеричным.

Но беда приходит в тот момент, когда требуется переводить "методом обложки". Тогда вся тавтология бесчисленных повторов и избыточностей, скрытых в канцелярите вылезает наружу. Вот, полюбуйтесь: это вступление к ISO 24774.

A number of international, national and industry standards describe process reference models. The process descriptions used in such models vary in format, content and level of prescription. The purpose of this Technical Report is to encourage uniformity in the description of processes. Uniform description of processes across process reference models allows the combination of processes from different reference models, eases the development of new models and facilitates comparison of models.

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

In order for future standards and revisions of current standards to select the appropriate forms of process description and apply them in a consistent fashion, it is desirable to develop a common characterization of all of these forms of process description. This Technical Report presents guidelines for the description of processes in terms of their format, content and level of prescription.

Чтобы при разработке новых и пересмотре имеющихся стандартов выбирались и последовательно применялись подходящие формы описания практик, желательно разработать общий набор описателей для всех таких форм описания. Настоящий технический отчет содержит руководство к описанию практик в терминах их формата, состава и степени обязательности.

The guidelines in this Technical Report can be applied to any process model developed for any purpose. They have been made publicly available as a Technical Report with the intention of establishing a uniform description of processes across all process models, from all sources, for all purposes.

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


Интересно было бы перевести это все не "методом обложки", а по-человечески -- хотя бы сокращая тавтологию и плеоназмы. Методом обложки-с-человеческим-лицом. А поскольку переводы "методом обложки" уже есть, то даже не перевести, а литературно отредактировать уже имеющееся -- без потери смысла.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 7 comments