configuration - una - que es el lenguaje ensamblador en programacion

¿En qué momento un archivo de configuración se convierte en un lenguaje de programación?

Question

He estado reflexionando sobre los archivos de configuración y su relación con el código durante un tiempo y, según el día y la dirección del viento, mis opiniones parecen cambiar. Cada vez más, sigo volviendo a la realización que tuve por primera vez mientras aprendía Lisp: hay poca diferencia entre los datos y el código. Esto parece doblemente cierto para los archivos de configuración. Cuando se mira con la luz adecuada, un script de Perl es poco más que un archivo de configuración para Perl. Esto tiende a tener consecuencias bastante graves para tareas como control de calidad y divisiones de trabajo como quién debería ser responsable de cambiar los archivos de configuración.

El avance del archivo de configuración al lenguaje completo es generalmente lento y parece estar impulsado por el deseo de tener un sistema genérico. La mayoría de los proyectos parecen comenzar siendo pequeños con algunos elementos de configuración, como dónde escribir registros, dónde buscar datos, nombres de usuario y contraseñas, etc. Pero luego comienzan a crecer: las características se pueden activar o desactivar, los tiempos y el orden de las operaciones comienzan a controlarse e, inevitablemente, alguien quiere comenzar a agregarle lógica (por ejemplo, use 10 si la máquina es X y 15 si la máquina es Y). En un cierto punto, el archivo de configuración se convierte en un lenguaje específico del dominio, y uno mal escrito.

Ahora que he divagado para preparar el escenario, estas son mis preguntas:

1. ¿Cuál es el verdadero propósito de un archivo de configuración?
2. ¿Debería intentarse mantener los archivos de configuración simples?
3. ¿Quién debería ser responsable de realizar cambios en ellos (desarrolladores, usuarios, administradores, etc.)?
4. ¿Deberían estar controlados por la fuente (ver pregunta 3)?

Como dije antes, mis respuestas a estas preguntas cambian constantemente, pero ahora estoy pensando:

1. para permitir que los que no son programadores cambien grandes trozos de comportamiento rápidamente
2. sí, cualquier cosa que no sea de grano grueso debe estar en el código
3. los usuarios deben ser responsables de los archivos de configuración y los programadores deben ser responsables de una capa de configuración entre los archivos de configuración y el código que da un control más detallado de la aplicación
4. no, pero la capa intermedia de grano más fino debe ser

Answer 1

Aquí están mis pensamientos:

1. Permitir que el comportamiento del tiempo de ejecución de una aplicación se modifique fácilmente. Esto puede ser realizado por programadores o no programadores, según las necesidades. Esto puede ser durante el desarrollo, pero a menudo veo los archivos de configuración como una forma de ayudar a que un programa sea más flexible en cualquier punto.

2. Sí. Creo que los archivos de configuración deben ser lo más simples posible, dada la restricción de que puede necesitar varias opciones para controlar los diferentes comportamientos de su tiempo de ejecución. Prefiero agrupar las configuraciones y simplificarlas tanto como sea posible.

3. Depende de qué y por qué se realiza el cambio. Si los usuarios van a cambiarlo, se debe crear un front-end para ocultarlos de los detalles. Lo mismo ocurre a menudo con los no desarrolladores en general.

4. A menudo, la fuente controla la configuración "predeterminada", pero tengo una manera de anular esto por sistema para el tiempo de ejecución real.

En cuanto a agregar lógica al archivo de configuración, evitaría esto. Creo que es mejor que el archivo de configuración active la lógica en su aplicación. El comportamiento en los archivos de configuración conduce a una falta de mantenimiento y comprensión, en mi experiencia. Prefiero que los archivos de configuración sean lo más simples posible.

Answer 2

Cada esquema de archivo de configuración (lo suficientemente longevo) eventualmente se convierte en un lenguaje de programación. Debido a todas las implicaciones que describe, es sensato que el diseñador de archivos de configuración se dé cuenta de que está creando un lenguaje de programación y un plan en consecuencia, para que no cargue a los futuros usuarios con un legado malo.

Answer 3

Creo que su pregunta es muy relevante dado el cambio a "interfaces fluidas". Muchos desarrolladores han "visto la luz" con respecto a las aplicaciones configuradas en XML. Usar XML puede ser muy detallado y difícil de editar correctamente (especialmente si no se proporciona un esquema). Tener una interfaz fluida permite al desarrollador configurar la aplicación en un lenguaje específico de dominio con la ayuda de algunos pares clave-valor de un archivo de configuración de texto plano (o quizás parámetros de línea de comandos). También hace que sea muy fácil configurar y configurar nuevas instancias de la aplicación para probar o lo que sea.

Aquí están mis respuestas a su pregunta:

• ¿Cuál es el verdadero propósito de un archivo de configuración?

Un archivo de configuración es una forma de permitir al usuario personalizar el comportamiento de su programa en tiempo de ejecución.

• ¿Debería intentarse mantener los archivos de configuración simples?

Idealmente, creo que los archivos de configuración deberían al menos complementarse con una interfaz fluida para configurar el programa (esto es útil en muchos aspectos). Si necesita un archivo de configuración, debe mantenerse muy simple, nada más que pares clave-valor.

• ¿Quién debería ser responsable de realizar cambios en ellos (desarrolladores, usuarios, administradores, etc.)?

Creo que la respuesta a esto depende de tu organización. Debe ser responsabilidad de la persona que implementa el software asegurarse de que esté configurado correctamente.

• ¿Deberían estar controlados por la fuente (ver pregunta 3)?

Robaré esta respuesta de otra persona :) Me gusta la idea de almacenar una configuración de plantilla en el control de fuente y modificarla para las necesidades de cada usuario local. Las posibilidades son que el archivo de configuración de un desarrollador sea la pesadilla de otro desarrollador, por lo que es mejor dejar las cosas que varían según el usuario fuera del control de la fuente. Tener una plantilla también es una buena manera de que la persona que implementa la aplicación (u otros desarrolladores) vea exactamente qué valores son válidos para el archivo de configuración.

Answer 4

De acuerdo. Tendrás algunos usuarios que quieren una configuración realmente simple, deberías dárselos. Al mismo tiempo, tendrá constantes solicitudes de "¿Puede agregar esto? ¿Cómo lo hago en el archivo de configuración?", No veo por qué no puede admitir ambos grupos.

El proyecto en el que estoy trabajando actualmente usa Lua para su archivo de configuración. Lua es un lenguaje de scripting, y funciona bastante bien en este escenario. Hay disponible un ejemplo de nuestra configuración predeterminada .

Notará que se trata principalmente de declaraciones clave = valor, donde el valor puede ser cualquiera de los tipos incorporados de Lua. Lo más complicado son las listas, y no son realmente complicadas (es solo cuestión de sintaxis).

Ahora estoy esperando que alguien pregunte cómo configurar el puerto de su servidor a un valor aleatorio cada vez que lo inician ...

Answer 5

Depende de lo que acuerdes con otros desarrolladores en el equipo. ¿Está utilizando archivos de configuración solo como archivos de configuración o está creando una aplicación Model Driven ?

Síntomas del archivo de configuración convirtiéndose en un lenguaje de programación:

• Los pares nombre = valor comienzan a depender el uno del otro
• sientes la necesidad de tener control de flujo (por ejemplo, si (esto) que eso )
• la documentación del archivo de configuración se vuelve esencial para seguir desarrollando (en lugar de simplemente usar la aplicación)
• antes de que el valor de config sea leído, requiere tener algún contexto (es decir, los valores dependen de algo externo al archivo config mismo)

Answer 6

El código de nuestras aplicaciones se vuelve menos importante ... Hay secuencias de comandos, hay todo tipo de atributos que definen el comportamiento de clases, métodos, argumentos de métodos y propiedades. Los usuarios pueden definir desencadenantes de base de datos y restricciones de base de datos. Puede haber archivos de configuración muy complicados. En ocasiones, el usuario puede definir hojas de estilo XSLT para manipular las entradas y salidas porque nuestros sistemas deben estar abiertos (SOA). Y hay cosas como BizzTalk que también necesita una configuración compleja. Los usuarios pueden definir flujos de trabajo complejos.

Tenemos que escribir un código mejor para tratar con este entorno complejo, por lo que el código de nuestras aplicaciones se vuelve más importante ...

Answer 7

He visto programas de Python donde el archivo de configuración es código. Si no necesita hacer nada especial (condicionales, etc.), no se ve muy diferente de otros estilos de configuración. por ejemplo, podría hacer un archivo config.py con cosas como:

num_threads = 13
hostname = ''myhost''

y la única carga para el usuario, en comparación con (por ejemplo) los archivos INI, es que necesita poner '''' alrededor de las cadenas. Sin duda, podrías hacer lo mismo en otros idiomas interpretados. Te brinda la posibilidad ilimitada de complicar tu archivo de configuración si es necesario, a riesgo de asustar a tus usuarios.

Answer 8

Los archivos de configuración invariablemente se abren camino hasta convertirse en "lenguajes de programación completos" feos e ilógicos. Se necesita arte y habilidad para diseñar buenos lenguajes de programación, y los lenguajes de configuración convertidos en lenguaje de programación tienden a ser horrendos.

Un buen enfoque es utilizar un lenguaje bien diseñado, digamos python o ruby, y utilizarlo para crear una DSL para su configuración. De esta forma, su lenguaje de configuración puede seguir siendo simple en la superficie, pero en realidad puede ser el lenguaje de programación completo.

Answer 9

Preguntas muy interesantes!

Tiendo a limitar mis archivos de configuración a un formato muy simple de "clave = valor", porque estoy totalmente de acuerdo con usted en que los archivos de configuración pueden convertirse muy rápidamente en programas completos. Por ejemplo, cualquiera que haya intentado alguna vez "configurar" OpenSER conoce la sensación de la que está hablando: no es configuración, es programación (dolorosa).

Cuando necesita que su aplicación sea muy "configurable" en formas que no puede imaginar hoy, entonces lo que realmente necesita es un sistema de complementos . Necesita desarrollar su aplicación de forma que otra persona pueda codificar un nuevo complemento y conectarlo a su aplicación en el futuro.

Por lo tanto, para responder a sus preguntas:

1. ¿Cuál es el verdadero propósito de un archivo de configuración?

   Yo diría que permite que las personas que instalarán su aplicación puedan modificar algunos parámetros relacionados con la implementación, como el nombre de host, el número de subprocesos, los nombres de los complementos que necesita y los parámetros de implementación para esos complementos (consultar configuración de FreeRadius para un ejemplo de este principio), etc. Definitivamente no es el lugar para expresar la lógica de negocios.

2. ¿Debería intentarse mantener los archivos de configuración simples?

   Seguro. Como sugirió, "programar" en un archivo de configuración es horrible. Creo que debería evitarse.

3. ¿Quién debería ser responsable de realizar cambios en ellos (desarrolladores, usuarios, administradores, etc.)?

   En general, diría administradores, que implementan la aplicación.

4. ¿Deberían estar controlados por la fuente (ver pregunta 3)?

   Normalmente no controlo el origen de los archivos de configuración, pero sí control de origen de un archivo de configuración de plantilla, con todos los parámetros y sus valores predeterminados, y comentarios que describen lo que hacen. Por ejemplo, si un archivo de configuración se llama database.conf , usualmente control de fuente un archivo llamado database.conf.template . Ahora, por supuesto, estoy hablando de lo que hago como desarrollador . Como administrador , es posible que desee controlar la fuente de la configuración real que elegí para cada instalación. Por ejemplo, administramos unos pocos cientos de servidores de forma remota, y necesitamos hacer un seguimiento de sus configuraciones: elegimos hacer esto con el control de origen.

Editar : aunque creo que lo anterior es cierto para la mayoría de las aplicaciones, siempre hay excepciones, por supuesto. Su aplicación puede permitir a sus usuarios configurar dinámicamente reglas complejas, por ejemplo. La mayoría de los clientes de correo electrónico permiten a los usuarios definir reglas para la administración de sus correos electrónicos (por ejemplo, "todos los correos electrónicos provenientes de ''john doe'' y no tenerme en el campo Para: deben descartarse"). Otro ejemplo es una aplicación que permite al usuario definir una nueva oferta comercial compleja. También puede pensar en aplicaciones como Cognos que les permiten a sus usuarios crear informes complejos de bases de datos. El cliente de correo electrónico probablemente le ofrecerá al usuario una interfaz simple para definir las reglas, y esto generará un archivo de configuración complejo (o incluso quizás un poco de código). Por otro lado, la configuración definida por el usuario para las ofertas comerciales podría guardarse en una base de datos, de una manera estructurada (ni una simple clave = estructura de valor ni una porción de código). Y algunas otras aplicaciones incluso pueden permitir al usuario codificar en python o VB, o algún otro lenguaje con capacidad de automatización. En otras palabras ... su millaje puede variar.

Answer 10

Puede recurrir a la teoría de la computación para definir lo que cuenta como lenguaje de programación. Si su formato de archivo de configuración es Turing Complete, entonces cuenta razonablemente como un lenguaje de programación. Según esta definición, un formato de archivo para describir los niveles de Sokoban cuenta como un lenguaje de programación (ver here ). Hay otros niveles de complejidad debajo de Turing Complete que también pueden contar, como las gramáticas regulares y los autómatas de empuje .

Otra forma de verlo es que muchos archivos de configuración solo son capaces de marcado de datos, mientras que un lenguaje de programación apropiado debe ser capaz de implementar algorithms . Por ejemplo, JSON es un formato de archivo de configuración, mientras que ECMA Script es un lenguaje de programación.

Answer 11

Recientemente estaba trabajando en un proyecto y me di cuenta de que quería tener condicionales dentro de mi archivo de configuración, que anteriormente había sido muy simple de la forma:

key = val
key2 = val
name = `hostname`

No quería escribir un mini-lenguaje, porque a menos que lo hiciera con mucho cuidado no podría permitir la flexibilidad que sería útil.

En cambio, decidí que tendría dos formas:

1. Si el archivo comenzó con "#!" y era ejecutable, analizaría el resultado de ejecutarlo.

2. De lo contrario, lo leería como está

Esto significa que ahora puedo permitir que las personas escriban "archivos de configuración" que se ven así:

#!/usr/bin/perl if ( -x /bin/foo ) { print <<EOF; foo=me bar=you EOF } else { print <<EOF; foo=bar bar=foo EOF }

De esta forma obtengo el poder de un archivo de configuración dinámica si el usuario quiere usarlo, y la simplicidad de no tener que escribir mi propio mini-lenguaje.

Answer 12

Sí, los archivos de configuración deberían ser simples. No deberían contener ellos mismos la "lógica", piense en ellos como una lista de expresiones en declaraciones if, no en las declaraciones condicionales en su totalidad.

Están ahí para permitir que el usuario decida cuál de las opciones codificadas en la aplicación debe usarse, así que no intentes complicarlas, terminará siendo autodestructivo: puedes terminar escribiendo archivos de configuración simple para controlar cómo el archivo de configuración original debería configurarse de otra manera!

Answer 13

Seré contrario y presentaré que es solo un lenguaje cuando incorpora más de lo que se puede representar por XML; o bien cuando XML se considera un idioma.

Alternativamente, la mayoría de los archivos de configuración se pueden considerar como clases, pero solo con propiedades y sin métodos. Y sin métodos, no creo que sea un lenguaje.

En definitiva, "lenguaje" es una abstracción blanda, pero sí, los bordes son ambiguos.

Answer 14

Soy un gran fan de usar programas de Python como archivos de configuración, especialmente para daemons. Me gusta tomar la táctica de hacer que el daemon esté completamente vacío de configuración, excepto el "puerto de configuración". El programa python luego se conecta al daemon y procede a crear objetos en el daemon y conectarlos entre sí para crear la configuración deseada. Una vez que todo está configurado, el daemon puede dejarse ejecutar por sí mismo. Los beneficios, por supuesto, son que obtiene un lenguaje de programación completo para escribir sus archivos de configuración y, como ya tiene una forma de hablar con el daemon desde otro programa, puede usarlo para depurar y obtener estadísticas. La desventaja principal es tener que lidiar con los mensajes de otro programa que llega en cualquier momento.

Answer 15

Tengo una filosofía diferente sobre los archivos de configuración. Los datos sobre cómo debe ejecutarse una aplicación son datos y, por lo tanto, pertenecen a un almacén de datos, no a un código (un archivo de configuración IMO es un código). Si los usuarios finales necesitan poder cambiar los datos, la aplicación debe proporcionar una interfaz para hacerlo.

Solo uso archivos de configuración para apuntar a los almacenes de datos.

Answer 16

Tiendo a estar de acuerdo con la premisa de esta pregunta. Evito meterme en problemas al predecir anticipadamente que esto va a suceder y, por lo tanto, nunca implementar mi propio sistema de configuración.

• O utilizo la facuilidad de configuración de los sistemas operativos (como un plist o gconf o lo que sea apropiado),
• O un simple archivo plano, como puede ser manejado por algo así como un analizador INI listo para usar.
• Muerde la bala y conecta un analizador de lenguaje ligero, generalmente lua, a veces tcl en la aplicación,
• O almacene datos en una base de datos relacional SQLite o similar.

Y me resigno a vivir con cualquier decisión que tome, o si no puedo, refactorizar para utilizar una de las opciones anteriores que mejor se adapte a la aplicación.

El punto es que realmente no hay ninguna razón para usar una solución de configuración propia. Por un lado, es más difícil para sus usuarios tener que aprender un nuevo formato de configuración específico de la aplicación. Por otro lado, se beneficia de todas las soluciones y correcciones de errores que se obtienen de forma gratuita cuando se utiliza una solución lista para usar. Finalmente, Feature creep se descansa, porque, bueno, en realidad no puedes agregar una función más sin realmente hacer una revisión importante porque el sistema de configuración no está realmente en tus manos en primer lugar.

Answer 17

Uno de los propósitos del trabajo de "Oslo" en Microsoft es permitir (aunque no requerir) la resolución de este problema.

1. Una aplicación se enviaría con modelos de cualquier componente nuevo que incluya. También usaría los modelos existentes. Por ejemplo, podría incluir un servicio web, por lo que podría reutilizar el modelo de sistema de un servicio web.
2. Los modelos incluirán metadatos que los describen, incluida información suficiente para las herramientas para acceder a ellos, ya sea de forma textual o gráfica.
3. Partes de los modelos corresponderán a "configuración"

Esto significa que el equivalente de los archivos de configuración de hoy en día puede ser lo suficientemente rico como para permitir tanto la edición textual como la gráfica de su configuración. La herramienta gráfica se suministrará con "Oslo" (nombre de código "Cuadrante").