Emponderar a los usuarios

Cuando estaba en la universidad, retomé el contacto con las computadoras después de un largo tiempo y conocí el DOS de Microsoft.

Estaba frente a una pantalla negra con el prompt C:\> esperando a que ingresara algo. Cuando lo hacía, me respondía.

Me sentía fascinado.

Aprendí a usar casi todos los comandos de la consola, y a programar nuevos comandos.

• En la consola command, se pueden ejecutar comandos cuyas salidas pueden ser entradas de otros comandos.
• Se pueden crear fácilmente nuevos comandos batch ejecutables desde la consola. Ya que los batch son archivos de texto simple y la consola tiene algunos comandos para generarlos.
• Un comando podría generar nuevos comandos dinámicamente. Es decir, un batch se podría generar dentro de la rutina de un comando y ser ejecutado luego dentro del mismo comando.
• Los programas de pantalla completa, aunque impresionantes, rompen el esquema de reutilización de comandos al apropiarse de toda la interfaz.

Más tardee, conocí Linux y la consola de comandos bash, donde se pueden observar puntos similares.

En la interfaz gráfica de Windows, en cambio:

• En el escritorio, se pueden ejecutar aplicaciones, pero estas ejecuciones son aisladas y no se puede realizar ejecuciones compuestas donde la salida de una aplicación sea la entrada de otra, dinámicamente.
• No hay herramientas para construir fácilmente nuevos programas desde el escritorio. Las aplicaciones no son interpretadas, sino ejecutadas desde un binario, y construir ese binario requiere conocimientos y herramientas especializadas.
• No hay una forma sencilla de construir aplicaciones que puedan generar otras aplicaciones dinámicamente, dentro de su ejecución. No es sencillo construir compiladores.
• La reutilización de las características de una aplicación es difícil. Cada característica está pegada a la aplicación. Cada mejora de características requiere una nueva versión realizada principalmente por quienes la programaron.

Algo parecido se puede decir de las interfaces gráficas de Linux (Gnome) y de la Mac (OSX), que vine a conocer luego.

En la interfaz gráfica de la Web, en el browser, se muestra una aplicación:

• Cómo hacer que la aplicación sea un entorno donde se puedan ejecutar componentes que puedan componerse para formar nuevos componentes?
• Cómo hacer que sea fácil crear componentes con los componentes presentes en el entorno?
• Cómo hacer que un componente pueda generar dinámicamente otros componentes dentro de su ejecución?
• Cómo prevenir que un componente pueda apropiarse de la interfaz?

Me parece distinguir que ese conjunto de características facilita que un sistema pueda ser extendido con la participación de sus usuarios.

El conjunto de comandos DOS y bash, puede ser fácilmente extendido por sus usuarios. Habrá programadores capaces de hacer nuevos binarios, pero la capacidad de hacer scripts, batch o bash, está disponibles de inmediato.

El conjunto de aplicaciones en Windows (o Gnome, o OSX) no puede ser fácilmente extendido por sus usuarios. Sólo puede serlo a través de programadores capaces de hacer nuevos binarios.

Uno se puede preguntar si esta limitación es puesta a propósito.

Al limitar que los usuarios puedan extender el sistema que usan, las empresas proveedoras de software se aseguran el papel de intermediarios, entre los usuarios y las soluciones que los usuarios requieren.

Y es conocido en el comercio que el intermediario siempre gana.

Así que me parece que la cuestión de limitar la extensibilidad del sistema por parte de los usuarios puede ser algo diseñado.

Sin embargo, ¿por qué ocurre también en la interfaz gráfica de Linux?. Siendo la comunidad Linux un fuerte representante del movimiento de software libre (promotor de dar a la gente la libertad de usar el software como quiera), esperaría que hubieran escritorios que permitieran componer aplicaciones visualmente, siguiendo la filosofía de composición de comandos que está presente en la consola.

Quizás sea que están distraidos por las complejidades de otros problemas.

Pero me parece que resolver esta situación sería muy interesante. Un escritorio así, emponderaría a los usuarios para crear cosas, sus propias cosas, y compartirlas en comunidad.

A mediados de los 80, Hypercard, de Bill Atkinson, fue una aplicación gráfica que facilitaba a los usuarios la creación de sus propias soluciones y a compartirlas. Atkinson insistió en que se distribuyera de modo gratuito y Apple insistió en encontrarle alguna manera de obtener ganancias. Finalmente, el desarrollo de Hypercard se estancó y Steve Jobs canceló su desarrollo, cuando volvió a mediados de los 90.

Aunque hoy hay fans que recuerdan el legado de Hypercard, me parece que se enfocan más en las cualidades técnicas (como la interfaz gráfica, que sirvió de inspiración a VisualBasic y otras herramientas), que en la cualidad social de emponderar a los usuarios para hacer sus propias soluciones.

Quizás sea posible implementar la idea en la web, usando componentes que puedan componerse para formar nuevos componentes, tanto a mano como dinámicamente.

Quizás React pueda ser una buena opción para eso. (Sin embargo, la forma en que se suele usar React, con Webpack para generar compilados, parece una especie de barrera. A veces parece como si las compilaciones fueran una forma de dejar fuera a los demás y ponerse uno como intermediario.)

Transcrito de http://rulokoba.blogspot.pe/2017/05/un-entorno-que-empondere-los-usuarios.html

Programando tu propia comida

En un inicio, si alguien tenía una computadora era para programar algo que solucionara su problema en particular.

Habían recetas de soluciones que se compartían entre la gente que programaba.

Cuando mucha gente trabajaba sobre cierto programa, se iban estableciendo costumbres y estándares para facilitar la comunicación entre las personas.

Nuevas formas de programar fueron emergiendo para facilitar que más gente pudiera programar soluciones más complejas con más facilidad.

Poco a poco, ya no fue necesario conocer de electrónica, ni de cuestiones específicas del hardware de la computadora. Luego, no fue necesario usar siglas mnemotécnicas sino expresiones muy parecidas al inglés.

Entonces, en algún momento, alguien notó que una computadora podía tener usuarios que no programaran, sino que usaran interfaces simples para realizar acciones sin componer nuevos programas.

Más tarde, alguien más notó que esos programas con interfaces simples podrían ser vendidos. Y luego, que para asegurar la dependencia podían limitar la posibilidad de hacer nuevos programas.

El software comercial permite resolver muchos problemas. Pero cada nueva característica, cada mejora, depende de que el proveedor del programa lo incorpore en la siguiente versión, por la que tendremos que pagar.

El software libre aparece como una respuesta a esta situación. Al obligar a que el código fuente de cada programa este disponible y cada usuario tenga la libertad de modificarlo y redustribuirlo, ayudó a que quienes tuvieran el conocimiento técnico suficiente pudieran ayudar con la evolución del software.

Sin embargo, la barrera es muy alta. El software actual, comercial o libre, sigue el esquema de aplicaciones paquete de muy difícil manufactura. Se necesita avanzados conocimientos de programación para lograr algo así. Además, son productos de uso final que difícilmente se comunican entre sí y que prácticamente no se pueden desagregar ni componer para formar nuevas soluciones.

A fines de los '80, Apple, una empresa con el estilo de proveer productos de cómputo que los usuarios no pueden alterar ni extender, tuvo un producto llamado Hypercard, creado por Bill Atkinson, que permitía a los usuarios componer visualmente secuencias de acciones y expresar los detalles en el lenguaje Hypertalk, muy simple y fácil de leer y escribir. Es decir, creó un entorno que permitía que los usuarios finales pudieran hacer programas para solucionar sus problemas particulares. Como antes, apareció una comunidad que compartía sus recetas.

Por alguna razón, está iniciativa no recibió el apoyo adecuado. Las siguientes versiones del producto limitaban las capacidades de creación y buscaba colocar a Apple como intermediario, otra vez, de las soluciones que la comunidad de usuarios era capaz de realizar por si misma.

Cuando Steve Jobs (precisamente, uno de los primeros en notar cómo hacer negocios con el software) regresó a la dirección, uno de los proyectos que canceló fue el de Hypercard.

Cosas como Hypercard necesitan una comunidad de usuarios emponderados, capaces de crear soluciones cuya explotación no puedes controlar.

Hay proyectos que tomaron la posta de ciertas ideas de Hypercard. Como VisualBasic, con su interfaz visual. Pero parece que siempre orientados a programadores, no a un público laico.

Parece más probable que una iniciativa que herede el espíritu de Hypercard provenga del software libre que del software comercial.


Hoy, el software comercial ha logrado que prácticamente cada persona cuente con una computadora en la mano. Gracias a ella puede consumir los productos que les preparan. La barrera técnica para preparar esos productos es tan alta y los consumidores tan ávidos de soluciones que se ha vuelto notoria la falta de capacidad para cubrir esa demanda.

Es como si hubiera pocos restaurantes para muchos comensales.

La comunidad de programadores, que son como los cocineros, ha optado por buscar modos de mejorar su respuesta, optimizando la forma en que programan, automatizando procesos, etc.

Los gobiernos están promoviendo la enseñanza de programación para aumentar el número de programadores. Es como aumentar el número de chefs y restaurantes.

Y sigue el aumento de gente con nuevas ideas de aplicaciones. Son como comensales con nuevas ideas de platillos, buscando chefs que los entiendan, o incluso financiandose un pequeño restaurante para poder ofrecer al mundo ese platillo que imaginan.

Ellos necesitan programadores porque, a diferencia del mundo de los comensales que también pueden cocinar, en el mundo de las aplicaciones es tan alta la valla de entrada que es como si sólo existieran cocinas industriales y ollas gigantes y sólo ingredientes al por mayor. La poca gente que puede preparar sus alimentos son los que saben hacer sus propias hogueras y utensilios para cocinar. O las que comen sushi.

¿Qué podemos hacer en este escenario?

Además de los cocineros tratando de cocinar más rápido y de los gobiernos tratando de hacer más cocineros, hay otras iniciativas en curso.

Hay el equivalente a cocinas comunitarias, donde cocineros pueden alquilar un espacio.

Hay el equivalente a máquinas expendedoras, donde se pueden conseguir golosinas, cafe o sandwich. Administradores de contenido que te permiten combinar algunas opciones para armar un refrigerio.

Los avances en inteligencia artificial están permitiendo máquinas expendedoras capaces de preparar algunas comidas básicas. Es decir, acciones simples como encender las luces, monitorear el refrigerador, sintonizar la tv o hacer consultas en Google, obedeciendo comandos en el lenguaje del usuario.


Quizás a estas alturas ya hayas notado qué ha pasado y qué se podría hacer.

Es como si se hubiera convencido a todo el mundo que la única forma de comer decentemente es en un restaurante o comprando algo hecho por un cocinero profesional.

¿Qué vendría a ser Hypercard? Quizás algo así como una máquina expendedora pero no de comida, sino de pequeños utensilios para cocinar, o de partes modulares para armar esos utensilios, y de ingredientes al por menor.

El símil deja ver que así como todo el mundo puede cocinar aprendiendo unas pautas básicas, la programación podría ser algo más asequible también.

El poder de la inteligencia artificial también podría ayudar, si se le permitiera disgregar soluciones existentes y componerlas en nuevas soluciones y a la comunidad de usuarios compartirlas libremente.

La clave es una libertad efectiva para componer nuevos programas a partir de otros, y de poder compartirlos libremente.

Si no puedes cocinar, dependes de alguien más para algo que debería ser una libertad básica.

No digo que no haya restaurantes. Tampoco que atendamos restaurantes usando expendedoras. Digo que no debe ser prohibitivo cocinar uno mismo.

Cada persona debe tener la libertad, y el poder, de resolver sus propios problemas, sin intermediarios.

Programar debe ser una actividad al alcance de cualquier persona.

Porque cada cambio en el mundo nace de una persona, no de un rebaño.

Y el mundo está necesitando cambios significativos más rápido de lo que se le puede proveer.

Necesitamos herramientas de programación más asequibles. El equivalente a una cocina de hogar o una hornilla. Ollas pequeñas y personales. Ingredientes al por menor. Recetas familiares.

Necesitamos liberar la creatividad de las personas para descubrir nuevas experiencias y soluciones... nuevos sabores.

Tú debes poder programar

Porque los programas están construyendo tu vida

En la Edad Media, la gente recurría a escribientes para que les redactara sus escritos.

Cosas como Actas, Títulos, Leyes, Poemas, Cartas, Cosas Importantes.

Mientras la demanda estuvo limitada a religiosos y nobles, los escribientes fueron suficientes.

Cuando la gente aprendió a usar los escritos en su vida, la demanda aumentó, y los escribientes que había no eran suficientemente numerosos ni suficientemente rápidos para redactar lo que les requerían.

En el mundo actual, la gente recurre a los programadores para que les haga sus programas.

Mientras la demanda estuvo limitada al gobierno y las empresas, los programadores fueron suficientes.

Cuando el Internet acelera a que la gente use los programas en su vida, la demanda de programadores aumentó y ya estamos notando que no son lo suficientemente numerosos ni lo suficientemente rápidos para hacer los programas que queremos.

(Sí, quizás es mejor dar un paso atrás e imaginar que no eres un programador para tener una perspectiva más amplia de estas cosas).

¿Qué está pasando ahora?

Los escribientes están mejorando sus técnicas para crear escritos.

Como ha quedado patente, casi nunca el cliente sabe cuál es exactamente el mensaje que quiere que se escriba, eso se va descubriendo en el camino, iterativamente, de manera ágil.

En realidad, hay un conjunto de técnicas de redacción defensiva y buenas prácticas para facilitar cambiar las cosas si el cliente de pronto cambia de opinión sobre algo. (Quizás ya no quiera mandar el poema a Rosa sino a María. Quizás no quiere un tono tan formal, etc.)

Por supuesto está la cuestión de la calidad. Es bien sabido que es mejor recibido un mensaje bien presentado, así que elegimos el mejor pergamino y las mejores tintas. También cuidamos el estilo de la letra y el arte de las iluminaciones que van alrededor.

Cada cierto tiempo se prepara un pergamino con la caligrafía y las iluminaciones propias del final, para que el cliente vaya evaluando el resultado. Esto es gracias a que los avances tecnológicos han permitido abaratar enormemente el costo de los pergaminos y la tinta.

Los escribientes más vanguardistas han optado por indagar en el destinatario (Rosa o María) para estar seguros que el mensaje será el que les gustaría escuchar en primer lugar. El tipo de letra y papel o pergamino que les guste, los colores, etc. y así tener una mejor experiencia de usuario.

Pero la demanda sube y sube y los programadores escribientes no se dan a basto.

Muchos están tratando de automatizar algunas cosas, creando formatos con espacios en blanco donde pueda ir el mensaje customizado.

Hay quienes invierten en mecanismos de relojería capaces de tomar las plumas y la tinta y reproducir la caligrafía de los escribientes de manera asombrosa, pero aún es una solución demasiado sofisticada y cara.

También hay por ahí un tipo proponiendo el uso de unos moldes de letras y tipos movibles.


Bueno, como habrás notado, estamos en el siglo XXI con un patrón de problema del siglo XV.

Sabemos cómo sigue la historia.

Sí, la imprenta fue algo muy importante que ayudó a difundir más fácilmente los textos. Pero lo que realmente cambió al mundo fue que la gente estaba usando textos para cambiar su vida.

El conjunto papel y lápiz, pergamino y tinta fue potenciado por la imprenta.

Hoy hay sistemas equivalentes a pergaminos caligrafiados. Con escribientes defendiendo con su corazón por qué usar ese tipo de pergamino y tinta, y ese tipo de caligrafía. Casas de escribientes tratando de tener a los mejores o formarlos lo más pronto posible, porque el mercado no espera.

Curiosamente, nadie parece preocuparse por dar a la gente papel y lápiz que pueda usar sin necesidad de ser educado en las artes de escribiente.

Porque eso es lo que necesitamos ahora. Una herramienta que permita programar a cualquier persona, sin necesidad de ser educada en las artes, o la profesión, de la programación.

Sí, Internet es algo muy importante que ayuda a difundir más fácilmente el conocimiento y a comunicarnos. Pero lo que realmente está cambiando al mundo es que la gente está usando a los programas para cambiar su vida.

Necesitamos dejar de depender de escribientes que lo hagan por nosotros. Necesitamos nuestro propio papel y lápiz para programar nosotros mismos el mundo que imaginamos.

Escribir no es solo un arte o una profesión; es un derecho. Igual programar.

Saber usar lo que hay

Una idea común:

• No es necesario usar ningún framework complicado. Puedo implementarlo yo mismo.

Ok, siempre y cuando:

• Estará bien documentado este nuevo framework (así es, vas a crear un framework que sólo tú conoces), y preparado para evolucionar (así es, eventualmente le encontrarán cosas que mejorar)
• Puedes costear ese desarrollo extra.
  Ese montón de esfuerzo y tiempo puede ser interesante para el desarrollador, por amor al arte, pero podría también ser enfocado mejor a la idea principal del producto en lugar de a la herramienta.
• No estará documentado pero no importa porque solamente tú vas a mantener el proyecto
• No estará documentado pero no importa porque el producto tendrá una vida corta

Es decir, no es buena idea cuando:

• No hay tiempo ni recursos para documentar o preparar el framework para evolucionar
• No hay documentación, no estarás disponible eternamente, y eventualmente alguien más va a mantener el proyecto
• No hay documentación y el producto tendrá una vida mediana o larga
  Ya que aún cuando sólo tú seas quien le seguirá haciendo manteniemiento, luego de unas semanas sentirás como si lo hubiera escrito otra persona

Reinventar la rueda cuando estudias algo es instructivo. Se puede aprender muchas cosas.

Pero cuando es otro el problema principal, reinventar la rueda, estando disponible algún estandar, puede ser muy improductivo. Es apostar que se puede hacer algo tan genial que superará la gran cantidad de horas de experiencia y experimentación acumuladas en el estandar, además de la comunidad de productos derivados, guías y expertos disponibles.

Si el caballo ha ganado algunas carreras antes, puede ser. Pero si es nuevo, o se trata de puro azar, no parece muy recomendable.

Así que es importante reconocer que siempre se usará un framework. La cuestión es si usarás uno más estándar, aceptando sus pros y contras, o si usarás el tuyo propio, el que irá surgiendo sobre la marcha.

Es bonito cuando algo nuevo surge. Algo diferente y mejor que cualquier cosa que hay. Es excelente cuando uno tiene la confianza de hacer algo así. El intentarlo te puede dar un gran poder sobre el destino del proyecto. Y con un gran poder viene una gran responsabilidad. Es mejor si tienes la experiencia para distinguir si puedes asumirla, y si es oportuno.

Es importante recordar que para resolver un problema o desarrollar un proyecto, las herramientas no son lo determinante. Tampoco simplemente usar bien cierta herramienta. Puedes tener un martillo de muy buena calidad y ser excelente con el martillo, pero será complicado usarlo ara ajustar un tornillo.

Más importante es hacer buen uso de aquellas que tengas disponible y te ayuden a resolver el problema.

El mito del mejor software

Hay una historia acerca de un hombre al pie de un farol, buscando sus llaves. Alguien que llega para ayudarle, después de un rato le pregunta si está seguro que las perdió allí. "No, las perdí en la esquina", le contesta, "pero aquí hay más luz".

Un absurdo similar puede ocurrir cuando se elige una tecnología arbitrariamente y no por si contribuye efectivamente al problema que se quiere solucionar.

Cuando alguien se afana en manejar la mejor tecnología, reducir su código y optimizar la carga, simplemente "porque sí", porque es "la forma correcta", en realidad está imitando a aquel hombre. Esmerarse en hacer el mejor software posible es un problema diferente. Pero buscamos ahí porque es un problema donde tenemos más luz.

Nos gusta resolver el problema del mejor software, donde tenemos más luz, que el problema que realmente tenemos que resolver, donde aún está oscuro.

Puedes notar que a muchos programadores les gusta entrar a ese juego de juzgar la virtud de una solución en función de la tecnología usada para construirla.

"¿Con qué lo hicieron?"

Un programador puede tener preferencia por las tecnologías de vanguardia, otro por las super optimizadas, otro por las escalables, etc. Siempre será posible escoger un escenario desfavorable para cualquier tecnología con la que no simpaticemos.

Es una discusión no productiva. Hacer el mejor software no garantiza que se solucione el problema. No es que esté mal buscar la excelencia técnica; simplemente se trata de otro problema.

"¿Funcionó?"

Sería una pregunta más razonable. Una vez que una solución funciona, es cuestión de iterar para llegar a las optimizaciones o solucionar problemas relacionados.

La verdadera tarea no es hacer el mejor software posible sino solucionar un problema.

Hay muchos ejemplos de buenas soluciones hechas con software que se mira por sobre el hombro (Wikipedia, WordPress, Drupal, la base de Facebook, por ejemplo, son hechos con PHP).

Una solución no es buena por el software con que se hace, sino por su oportunidad y relevancia.

Resolución Iterativa de Problemas

Hemos sido educados con un sesgo importante hacia la resolución determinista de problemas.

La forma determinista postula que hay una forma correcta de resolver un problema. Ya sea porque es la más económica, o la más veloz. La solución.

La economía o el tiempo suelen ser los criterios últimos para evaluar una solución.

La forma determinista es como resolvemos los problemas que ya sabemos cómo se resuelven.

Como cuando aprendes a resolver problemas tipo para un exámen de admisión, o los casos de actuación en un protocolo.

¿Has resuelto alguna vez el problema de los dos trenes? Uno parte de A, el otro de B, distante tantos km, a tales velocidades, averiguar a qué hora se cruzan. Un problema con una solución ya conocida. Eso es resolución determinista de un problema. La forma con la que nos han enseñado a pensar. No funciona muy bien para explorar.

La forma iterativa es como realmente resolvemos los problemas cuya solución no conocemos.

Consiste en esbozar diversas alternativas y disparar tentativamente para encontrar alguna que funcione. Una vez que se tiene una línea que llegue al otro lado, se va iterando, corrigiendo la dirección, el apoyo, el material, hasta que poco a poco se tiene un puente que permita cruzar. Una solución.

¿Has jugado Angry Birds? Tienes una honda y varios proyectiles para intentar derrumbar una estructura. Sólo tienes pesos aproximados, alguna idea del viento. ¿Cómo lo resuelves? Lanzando cosas, usando diferentes combinaciones de impulso y ángulo hasta encontrar una respuesta satisfactoria. Eso es resolución iterativa de un problema. Así es como resolvemos las cosas por descubrimiento. Algo que vale la pena aprender a hacer mejor.

La forma iterativa admite muchas soluciones. Cualquiera respuesta que satisfaga la necesidad es una solución. Esta solución puede ser iterada, para optimizarse, para que sea más económica, para que sea replicable o escalable.

La economía o el tiempo pueden ser criterios para evaluar una solución iterativa. Pero sería ingenuo limitarse a ello.

Ya que la solución se va iterando, tiene valor la mantenibilidad; qué tan facil es entender la solución, corregirla y evolucionarla.

En la resolución iterativa de problemas los intentos de optimización prematura tienen el efecto de limitar las opciones disponibles y hacer más complicada la resolución.

Cuando la solución sea muy conocida, se podría usar de modo determinista, como en los libros de texto.

Un problema de los libros de texto es que no te cuentan la forma iterativa en que se se resuelven los problemas.

Cuando las metodologías agiles proponen una forma iterativa de organizar el desarrollo de un proyecto, puede haber una resistencia social (la jerarquía vertical resistiéndose a ser horizontal), y también una resistencia cultural.

Pienso que la resistencia cultural es básicamente el pensamiento determinista resistiéndose a ser iterativo. La gente desconfía de las soluciones iterativas. Básicamente porque no ha sido educada para resolver problemas iterativamente.

Vistas esquemáticas

En el diseño gráfico, la vista de alambre ayuda a abstraerse de los detalles y concentrarse en la estructura. Sería demasiado complicado e incómodo tener que trabajar todo el tiempo con la vista final. Además de innecesariamente costoso.

Sin embargo, muchas veces desarrollamos software trabajando todo el tiempo con la vista final.

Sería util poder contar con una especie de vista de alambre, además de a vista final. Esa vista esquemática pueda ayudar a abstraernos de los detalles estéticos de la interfaz y permitir apreciar mejor la estructura de la aplicación, o el flujo de solicitudes y respuestas.

El desarrollo de una vista de alambre podría ayudar también a construir un mejor software.

Reutilizar código

Hay programadores que parecen tomar la reutilización de código como un mandamiento que hay que cumplir mecánicamente para ser un buen programador.

Pero, como aprendimos con los diez mandamientos, la bondad de algo no está tanto en obedecer mecánicamente sino en comprender el por qué.

[Leer más]

Sobre frameworks

Algunos desarrolladores dicen que prefieren no usar frameworks.

Empiezan desde cero y van completando el sistema con ayuda de los patrones y librerías que les parecen más adecuados.

Felicidades, eso es un framework. Cualquier desarrollador que quiera corregir o agregar algo al sistema tendrá que familiarizarse con las peculiaridades de ese nuevo esquema.

Seamos claros. Siempre se usa un framework. Si no es el de los demás, es el tuyo. Si no lo tienes hecho, irá surgiendo en el proceso.

¿Cuál es la ventaja de un framework propio? Que si el desarrollo es reciente probablemente estés muy familiarizado con él y puedas hacer cualquier cosa más rápido y mejor que alguien que no lo conoce (todos los demás).

En cierto modo, usar un framework propio, alimenta la ilusión de falsa competencia, porque eres el mejor en el juego (que nadie ha practicado tanto como tú).

Por supuesto que hay proyectos que requieren una solución a la medida, particular y específica. ¿Pero pertenece tu proyecto a ese grupo exclusivo de clientes que necesita un sastre? ¿O es como el 90% de los proyectos usuales? Quizás seas un buen costurero, quizás seas un buen sastre, pero, ¿que es lo que realmente necesita el cliente? ¿se sentirá cómodo en la playa con sus shorts de diseño? (el cual no puede forzar mucho porque no ha sido tan probado como los más baratos shorts que pudo haber elegido).

Muéstrame alguien que reniegue de usar un framework conocido y posiblemente encontremos que, aunque sea buen programador, no domina ninguno. Es natural querer usar lo que mejor manejamos, pero no es justo negar la virtudes de lo que no hemos probado o aún no conocemos a profundidad.

No existe tal cosa como un proyecto hecho sin frameworks, sólo con estándares. Lo que en realidad hay es un nuevo framework surgido en el transcurso del desarrollo, impregnado con las particulares opiniones del desarrollador sobre como se deben hacer las cosas correctamente, probablemente con escasa documentación y comunidad mínima (esas cosas requieren más horas hombre que las que pueda pagar cualquier cliente).

Existe la posibilidad de que el nuevo framework tenga alguna ventaja sobre los demás. Entonces, la manera más eficiente de que evolucione es que se vuelva open source. Si realmente es bueno, la comunidad llegará para usarlo, probarlo, documentarlo y difundirlo.

Encontrarás muchas razones por la que un proyecto open source es una mejor opción para hacer mejor software.

Cuando se hace software es importante reutilizar aquello que es bueno. Para reutilizar software, o para mantenerlo, con comodidad, es importante documentación y ejemplos. Para documentar y discutir casos y soluciones, una buena comunidad es grandiosa.

Pienso que un software es mejor cuanto más mantenible es. Algunos piensan que es mejor lo que corre más rápido, pero no se puede hacer muchas optimizaciones sobre código ilegible (y la optimización prematura es el camino a todo tipo de problemas). Otros piensan que es mejor software si usas menos líneas de código, pero no podrá evolucionar con facilidad si esa obsesión de menos líneas conduce a código menos legible que requiera numerosos hacks mentales tan sólo para aclarar la intención.

Además, el código lo va a correr una computadora, a la que le da lo mismo. Todas esas cosas de buenas prácticas, organización, frameworks, etc, no es por ellas, sino para la gente. Así que es más importante escribir buen código para la gente.

Pienso que un código es más mantenible si es más legible y si es más fácil de depurar. No importa que sea muy largo o parezca inocente, porque esa sencillez permitirá obtener versiones optimizadas también con facilidad.

Aprender un framework cuesta, pero usar un framework conocido puede hacer que tu proyecto sea más mantenible y una mejor opción para tu cliente. Si te gusta crear cosas nuevas, suele haber espacio para plugins (y mejor feedback para tu trabajo). Si quieres realmente ser autor de un framework, aprenderás mucho de la comunidad antes de intentar crear una. Puede que te ayude tener mejor perspectiva conocer a otros con muy alto nivel colaborando con entusiasmo en proyectos open source. Aprenderás a valorar la gran cantidad de tiempo y conocimientos que se puede condensar en un proyecto abierto, más allá de lo que puedas imaginar.

Git: Un Cuento de Tres árboles

Hoy vi una presentación muy iluminadora sobre git, Un Cuento de Tres árboles, por Scott Chacon:

• http://www.slideshare.net/startechconf/scott-chacon-cuento-de-tres-rboles
• http://vimeo.com/38958167

ARCHIVOS: Es el árbol donde hacemos nuestros cambios

STAGE: Es el árbol intermedio, nuestro futuro commit

HEAD: Es el árbol del commit más reciente

Hacer

vim file.txt

  creo file.txt en ARCHIVOS

git add file.txt

  agrega file.txt al STAGE

git commit

  crea un nuevo commit con lo que esté en STAGE y lo hace HEAD

Deshacer

git reset --soft HEAD~

  deshace el último movimiento del HEAD

git reset HEAD~

  deshace el último movimiento del HEAD y copia el commit apuntado al STAGE

git reset --hard HEAD~

  deshace el último movimiento del HEAD, copia el commit apuntado al STAGE y también a ARCHIVOS

Diferencias

git diff

  muestra las diferencias de ARCHIVOS con STAGE

git diff HEAD

  muestra las diferencias de ARCHIVOS con HEAD

git diff --cached

  muestra las diferencias de STAGE con HEAD

Ver

cat file.txt

  muestra el contenido del archivo en ARCHIVOS

git show :0:file.txt

  muestra el contenido del archivo en STAGE

git show HEAD:file.txt

  muestra el contenido del archivo en HEAD

Fuente original: http://akcaprendiendo.blogspot.com/2014/06/git-un-cuento-de-tres-arboles.html

En equipo

Es muy diferente escribir código solo que en equipo.

Cuando eres solo una persona, tienes más libertad para elegir lo que te gusta o desechar lo que no te gusta. Para elegir usar patrones que solo tu conoces, para inventar tu propio framework, para usar los hackings que te gustan...

Cuando eres solo una persona, escribes código para solucionar un problema. Y punto.

Pero cuando estás en un equipo, escribes código para solucionar el problema de modo que otros puedan entender la solución y mantenerla.

Eso puede ser un poco más complicado. Porque la mayoría de tu equipo puede tener otras preferencias de formato, usar mejor otros frameworks, y cosas como los hackings (que te hacen googlear media hora para entenderlos), no son recomendados.

Pierdes la sensación de control total que puedes sentir cuando dominas tu código. En su lugar, va apareciendo el sentimiento de que todo es caos.

Y, sin embargo, del caos surge un orden, y soluciones valiosas, si las sabes ver. Es cuestión de abrir la mente para estar dispuesto a aprender... que nunca se acaba de aprender. Y que hay soluciones que no son tuyas ni mías, sino de ambos.

Cuando aparece la sinergia, donde uno más uno es más que dos, es como magia que jamás conocerías si no fuera porque trabajas en equipo. Y entonces, lo valoras.

¿Cuál es el mejor lenguaje de programación?

¿Cuál es el mejor lenguaje de programación?

Aquel que te permite resolver mejor el problema que enfrentas.

Los lenguajes son herramientas.

¿Cuál es la mejor herramienta?

¿Un martillo, una sierra, un hacha, unos alicates, una navaja suiza?

Depende de lo que necesites hacer.

Si eres muy hábil con el hacha quizás puedas usarla para clavar clavos, cortar madera, y preparar sushi.

Pero si tienes un equipo, puede pasar un largo tiempo hasta que todos logren ese nivel de hacking. Y el tiempo también es parte de la ecuación.

También la gente se vuelve parte de la ecuación. Para muchos no es fácil respetar las diferencias y distinguir las particulares habilidades de los demás.

Hay jefes de proyecto que reniegan y se frustran porque nadie más en su equipo logra hacer sushi con el hacha tan potente y de buena calidad que han comprado. Mango de roble, acero americano. ¿Por qué no pueden ser como él? Si escuchara un poco, tal vez llegaría a enterarse que hay un chef entre ellos, que podría preparar el sushi con un pequeño cuchillo que tiene. O, mucho mejor, si le dieran un Ginzu 2013, en lugar de la pesada hacha que le saca ampollas de las manos.

Si finalmente se haciera evidente el hecho que el sushi se prepararía mejor con un cuchillo de cocina, el jefe lo aceptaría a regañadientes, no sin antes haber soltado algunas preguntas como: ¿Y es escalable?

Analizando si el salvavidas es perfectamente circular.

Quizás esa forma de ver los problemas se vuelve un hábito.

Quizás, en el fondo, haya un miedo, quién sabe, cuando se quiere que todo sea perfecto y seguro antes de empezar.

MacGyver salía a sus misiones sin mochila, ni nada en los bolsillos, en la confianza de que podría manejar cualquier situación con lo que encontrara en el camino.

Alguien puede querer lo más potente, lo más fuerte, lo más escalable y garantizado, no tanto porque sea la mejor respuesta al problema, sino porque le da miedo caminar sin protección, sentir el viento en la cara, la arena bajo los pies, el sonido del mar incontrolable. Quizás porque no sabe nadar. O porque una ola lo revolcó y le dejó un trauma hace tiempo.

¿Cuál es el mejor lenguaje de programación? Es una pregunta incompleta. ¿Cuál es el mejor lenguaje de programación, para este problema? está un poco mejor.

¿Y cuál es el problema? Esa quizás es la pregunta por la que se debe empezar. Y tomar en cuenta que nosotros también nos volvemos parte de la ecuación.

El lenguaje de programación correcto

"Las especies que sobreviven no son las más fuertes, sino las que se adaptan mejor al cambio"

-- Darwin

En internet, parece ocurrir algo similar. No prosperan los lenguajes de programación que te hagan más fuerte, sino los que te permitan adaptarte mejor al cambio... en cierto ambiente.

Por ejemplo, php es popular en proyectos educativos y sociales. Java es popular en proyectos empresariales. C es popular en proyectos técnicos. Otras alternativas importantes son Python, Ruby, etc.

Muchas personas tienen sus preferencias y a veces tienden a tomar posiciones, pero es importante ver más allá y recordar cuál es la razón por la que programamos.

Cada lenguaje existe por alguna razón. Porque de algún modo es la mejor respuesta para cierto problema. Porque es la mejor especie en cierto ambiente.

Pienso que no hay una solución "correcta" ni una manera "correcta" de hacer las cosas universalmente. Cada problema contiene su solución, y es importante estar atento a la solución que te está cantando el problema, en lugar de pretender que escuche la que nos gusta cantar.

Así podemos aprender nuevas canciones :-)

¿Cuánto puede mejorar tu software? ¿Qué tan clara es la especificación? A más ciclos de desarrollo, más probabilidad de acercarse al ideal.

¿Cuántos ciclos de desarrollo puedes realizar? ¿Qué tan sencillo es de iterar o incrementar? A más contribuyentes, más probabilidad de encontrar excelentes contribuciones.

¿Cuántos contribuyentes puedes encontrar? ¿Qué tan sencillo es comunicarse? Hay más probabilidad de encontrarlos si los lenguajes son más atractivos, los entornos de desarrollo más asequibles, el camino de inicio más motivador.

Quizás por eso un lenguaje de programación no tan fuerte puede a veces llegar tan lejos. Es importante tener en cuenta el ambiente para prosperar.

Spaghetti code

Se nos ha enseñado acerca del código spaghetti. Como los producidos por abusar del goto en BASIC. O por abusar de los callbacks en Javascript.

Algunos se precipitan en afirmar que los goto no son buenos. Y aunque es un poco difícil afirmar lo mismo de los callbacks, a veces se apresuran en tomar esa postura.

Lo cierto es que el goto puede ser útil, igual que el callback. Lo que no nos parece bueno es el spaghetti que se produce cuando se abusa de ellos. Es importante notar la diferencia.

Los lenguajes de programación modernos tienen la tendencia a eliminar la posibilidad de abuso de goto limitando las estructuras de control de flujo. Es más fácil controlar un problema si no hay opción de que se produzca, en primer lugar.

Sin embargo, más allá de eso, resulta que desde el punto de vista de la máquina, tanto el código spaghetti como uno más estructurado son igualmente correctos y válidos. La buena estructura es una preferencia humana, para facilitar el desarrollo y mantenimiento. El spaghetti code le da igual a la máquina, es al humano el que tiene problemas con él. También es importante recordar eso.

Si hubiera alguna manera de moverse con facilidad y seguridad por el código spaghetti, no habría tanto problema. Me pregunto si habrá algún modo de manejar ese aparente caos, en lugar de evitar que se produzca.

Quizás nunca se puede evitar del todo la ocurrencia del caos, tan solo postergarlo lo más posible. Es conocido que, según crece un proyecto de desarrollo, es más complicado mantenerlo estructurado y oponerse al caos.

Pero, ¿sería posible manejar el caos, en lugar de huir de él? ¿alguna metodología? O, si es demasiado para un humano, ¿sería posible hacerlo con ayuda de un asistente?, ¿podríamos pasar de ser autoempleados en programación a procurarnos la ayuda de la computadora y pasar a otro nivel?

Crédito de la imágen: http://upload.wikimedia.org/wikipedia/commons/e/ee/Tarako_spaghetti.jpg

Resolviendo Soporte Drag para Flexslider

Es posible usar el plugin jquery.event.drag para proveer soporte para drag a Flexslider (es decir que permita arrastrar los sliders con el ratón en el desktop, de modo similar a como permite hacerlo en un dispositivo tipo touch):

- Usando el plugin jquery.event.drag (http://threedubmedia.com/code/event/drag/)
- En jquery.flexslider.js, copio el bloque que da soporte a mousewheel y lo uso como base para el soporte para drag:

...
// MOUSEWHEEL:
if (vars.mousewheel) {
  slider.bind('mousewheel', function(event, delta, deltaX, deltaY) {
    event.preventDefault();
    var target = (delta < 0) ? slider.getTarget('next') : slider.getTarget('prev');
    slider.flexAnimate(target, vars.pauseOnAction);
  });
}
// DRAG:
if (vars.drag) {
  slider.bind('drag', function(event, delta) {
    event.preventDefault();
    var target = (delta.deltaX < 0) ? slider.getTarget('next') : slider.getTarget('prev');
    slider.flexAnimate(target, vars.pauseOnAction);
  });
}
...

- También agrego 'drag' en los defaults de flexslider:

...
$.flexslider.defaults = {
  ...
  mousewheel: false,
  drag: false,
...

- Entonces, en el script, se puede usar 'drag: true' cuando se requiera:

$('.flexslider').flexslider({
  animation: 'slide',
  slideshow: false,
  drag: true
});

Referencia:  Request: add mouse dragging for desktop users

Vertical Site

Introducción
La motivación fue hacer un site similar a:

• http://www.soleilnoir.net/believein
• http://discover.store.sony.com/tablet

Revisando believein (pude bajar el site usando wget, Firebug y un poco de paciencia), me resultaba un poco difícil encontrar la clave del comportamiento que veía.

Encontré una aproximación en Curtain.js. Sin embargo, cuando requería modificar la presentación, también me resultaba un poco difícil encontrar dónde hacerla.

Decidí reinventar la rueda de este caso, para tratar de comprender las ideas del proceso de solución.

Los sites que revisé me dieron pistas.

En este tutorial trato de resumir el proceso.

vertical-site@github

Simple HTML

• Todo el contenido está presente en el mismo documento.
• El contenido se divide en secciones a las que denomino pages.
• Cada page es el destino de un link del menú. Esto permite una navegación simple a enlaces internos.

Aplicando estilos básicos:

index.html
style.css

Nav fixed

• Se fijan los elementos de navegación: cabecera y menú.
  En simple_html, estaban dentro de page-0 (para permitir ver el menú cuando se fuera a HOME). Como ahora serán siempre visibles, eso no es necesario.
  
• Se implementa un indicador de posición, que señale en el menú la página activa.
• En el menú, aparece resaltado el link a.active
• El link se activa si el url cambia
• El url cambia
• cuando se ingresa a mano
• cuando se hace click en un enlace del menú
• cuando se hace scroll
• El plugin address permite responder ante un cambio del url.
  

index.html
style.css
script.js

Scrollto

• Scroll animado suave.

index.html
style.css
script.js

(continuará...)

Escribiendo aplicaciones para Facebook

Escribiendo aplicaciones para Facebook
A pesar de la documentación que hay en https://developers.facebook.com/docs/, necesitaba algo que me diera una perspectiva en el tema. Leyendo un poco en otras fuentes, fui entendiendo la idea.

La idea
¿Qué es una aplicación para Facebook? Imaginaba que sería algo como un programa, construido con un framework, en un cierto lenguaje y con cierto esquema, que Facebook ejecutaba para los usuarios que lo hubieran jalado de la galería de aplicaciones.

Pero no es así. Se trata de aplicaciones web escritas en el lenguaje y esquema que uno prefiera, corriendo en el hosting que uno prefiera y que uno puede asociar con Facebook siguiendo ciertos esquemas.

En el esquema Website, la aplicación tiene su propio url, como de costumbre. El usuario accede y la aplicación puede hacer internamente invocaciones a los servicios de Facebook antes de mostrar un resultado al usuario.

En el esquema Application, la aplicación tiene su propio url, como de costumbre, pero Facebook actúa como proxy, asignándole a la aplicación un url bajo su dominio. El usuario accede al url dentro de Facebook, Facebook pasa los requerimientos al url externo de la aplicación, la aplicación puede hacer internamente invocaciones a los servicios de Facebook antes de devolver un resultado, Facebook recibe ese resultado y lo publica en un iframe.

Referencias

• "Facebook Application Development, For Dummies"
  Jesse Stay, 2011
  ISBN: 978-0-470-76873-0

En el Dojo

Hoy asistí a un dojo de programación. Me ha parecido una experiencia muy enriquecedora.

Un dojo de programación trata de seguir la idea de un dojo de artes marciales en cuanto a formar un ambiente donde podamos ejercitarnos fuera de la contienda real (que viene a ser el día a día con los proyectos que desarrollamos).

La práctica se trató esta vez de usar TDD y una especie de Pair Programming para resolver el problema de convertir números arábigos, los que usamos normalmente, a la notación romana.

TDD son las iniciales de Test Driven Development, Desarrollo Guiado por Pruebas. Pablo Tortorella, quien nos guiaba, dijo que le parecía mejor pensar en Desarrollo Guiado por Ejemplos, ya que una prueba es en realidad un caso particular que ponemos como ejemplo para que el programa que hacemos lo intente resolver. Un ambiente de pruebas toma la prueba y la lleva a cabo a ver si el programa la pasa. Entonces, en TDD: 1) definimos una prueba simple 2) corremos la prueba (incluso sin tener ningún programa; es importante ver que falla) 3) se enfoca uno en implementar en el programa lo mínimo necesario hasta lograr pasar la prueba 4) si se nota que algo puede refactorizarse (simplificar, eliminar duplicaciones o dependencias innecesarias), hacerlo, luego pasar al paso 1) e ir repitiendo el ciclo, con pasitos de bebe, dejando que el programa evolucione hasta el nivel que deseemos.

Para alguien habituado a programar al estilo tradicional, donde se pretende resolver todo el problema en la fase de diseño, antes incluso de empezar a programar, puede costar un poco enfocarse en pequeños pasos y no intentar codificar toda la solución de una vez. Pero el estilo tradicional realmente tiene problemas. Precisamente en respuesta a esos problemas surgieron cosas como la eXtreme Programming, TDD y Agile.

En el caso del problema de la conversión a números romanos, probablemente uno imagine ahora, sin necesidad de programar, una manera de resolver el problema y podría programarla en un rato. Pero, deténgase y trate de hacerlo en pequeños pasos, ideando una prueba simple y trivial cada vez, para ver a dónde va conduciendo.

Con el dojo me di cuenta que, conforme avanzan las iteraciones, van apareciendo patrones que van sugiriendo la solución. El tiempo de la práctica se acabó, pero creo que eventualmente llegaríamos a solucionar el problema.

Camino de regreso, recordaba la forma en que el código iba proponiéndose y refactorizándose. Había cierto algoritmo en eso. Me pregunto si sería posible programar a una computadora para que halle esa solución evolutiva usando TDD. Quizás sí. Entonces, me pregunto si sería posible que una computadora, o un conjunto de computadoras, realizando pequeños pasos de bebe, resolviendo casos triviales, puedan resolver cualquier tipo de problema de programación, simplemente por evolución, usando TDD. Me pregunto si será ese el futuro.

Crédito de la imagen: CIO Dojo

Creando nuevas opciones

Caminando por una tienda, encontré un juguete con forma de notebook.

Lo encendí y comencé a navegar por las distintas opciones que ofrecía.

Había juegos para aprender el alfabeto, los números, las notas musicales, para escribir mensajes, y así por el estilo.

Pensé que llegaría un momento en que uno habría explorado todas las opciones. Entonces querria más.

La diferencia entre una computadora y el juguete era que no había opción para agregar cosas. O quitar cosas. O modificar las que habían.

¿Cuántas personas usan las computadoras de ese modo? Es decir, como un gran conjunto de opciones que consumir, simplemente, sin poder modificarlas. Un ejemplo que me viene a la mente es el de los diccionarios. Sería tan útil que nos permitieran agregar nuestras propias definiciones y, sin embargo, debemos conformarnos con descargar las que hayan hecho otros.

Se podría pensar que es algo que le corresponde a los programadores. Pero pienso que programar una computadora debería ser algo tan simple que podamos hacerlo todos.

Me parece que con la consola de comandos íbamos por un camino que eventualmente nos conduciria a intérpretes de lenguajes humanos. Primero por escrito y luego por voz. Un día cercano podríamos comandar una computadora como si conversáramos con ella, como en Star Trek.

Pero apareció el sistema de menús y ratón y hubo un desvío.

Un sistema de menús presenta las opciones en una estructura jerárquica. Eso permite verlas con más claridad. El ratón permite navegar en ese sistema. Comparado con escribir los comandos, puede resultar más cómodo, más rápido... para ciertas cosas.

Quienes usan la consola de comandos pueden notar que hay cosas que la consola permite y el sistema de menús no.

Si usamos la consola de comandos simplemente como un modo de llegar a las opciones que ofrece el sistema de menús, no hay mucha ventaja (sería más cómodo usar el ratón). La magia de la consola de comandos aparece cuando permite crear nuevas opciones y manipularlas con una expresividad que quizás esté más allá de las posibilidades de un sistema jerárquico de presentación.

Los lenguajes de programación son un modo de crear esas nuevas opciones. Antes, en la época de la consola de comandos, se hacía el intento de acercar estos lenguajes a la gente. Estaban BASIC, LOGO y así por el estilo. Pero eso fue decayendo conforme se popularizaba el ratón.

El problema con el mundo del ratón es que tiene un límite, igual que el juguete. Como en una tierra plana, llegará el momento, tarde o temprano, en que se habrá recorrido cada opción y, parado en el borde de ese mundo, querrá más.

Claro que los programadores se encargarán de ampliarlo, proveyendo nuevas opciones que estarán disponibles con solo pasar a la siguiente versión. Dependemos de ellos para eso. Pero ¿no sería mejor que cada uno pudiera crear por si mismo nuevas opciones, en lugar de tener que esperar a que a alguien más se les ocurra y las programe?

En el desarrollo de programas, se va tomando más en cuenta el papel del usuario en la definición del producto y su implementación. Las ideas de los usuarios (recolectadas a través de foros o emails) son tomadas en cuenta en el diseño. Los errores que encuentran ayudan a mejorar el producto. Se compite para ver quién logra escuchar mejor a los usuarios y traducir lo que dicen a mejoras en el software. Pero, viéndolo bien, es como si los usuarios programaran las computadoras a través de los programadores. ¿No sería mejor que la programación pudiera ser directa?

Yo soy programador, pero me parece que muchas veces estamos cumpliendo simplemente el rol de intermediarios es una tarea que debería poder ser realizada directamente por los usuarios. Programar debería ser algo mas simple y cualquier persona debería sentirse capaz de comunicar a la computadora lo que quisiera que hiciera. Encontrar un modo en que la gente pueda definir nuevas opciones, o expresarlas de otro modo, luego compartirlas con los demás y permitir que evolucionen.

Imagine que puede agregar opciones a su árbol de menús. Imagine que puede operar con las opciones que ya tiene para crear otras nuevas. Imagine que incluso puede crear nuevas operaciones para manipular esas opciones. Imagine que puede compartir todo eso con otros usuarios. Y todo eso de un modo que le resulta natural, lógico, simple.

Esa forma de ver la computación era más evidente cuando se usaba la consola de comandos, ese infinito universo negro poblado de letras fosforescentes. Pero pienso que también se podría hacer en el sistema de menús, si abrimos la puerta.

Liberando los sitios dinámicos

Imagine que le hicieran una página web y, un tiempo después, usted quiere modificar el documento HTML.

Imagine que puede abrirla en cualquier editor de texto, modificarla y volverla a grabar. Sin importar si se hizo en Dreamweaver, Geany, Notepad, o cualquier otro. Qué libertad.

Claro que no sólo lo podemos imaginar, de hecho podemos hacerlo.

Entonces, ¿por qué hemos permitido que esta libertad y conveniencia sea recortada por los frameworks? Porque eso es lo que ocurre.

Cuando hacemos un sitio dinámico, digamos en CakePHP, y, un tiempo después, usted quiere modificarlo, tiene que usar no sólo CakePHP, sino la misma versión de CakePHP. Del mismo modo si hubiera usado Zend, CodeIgniter o Drupal.

Es como si le dijeran que para abrir un HTML tiene que usar Notepad 4 y no otro, porque no es compatible. Que si quiere el mismo site para Notepad 5 hay que volverlo a hacer.

Sí, un site dinámico es más complejo que un documento HTML, pero la razón es similar. Es importante que el producto sea independiente de la herramienta usada para fabricarla. No sólo porque es un gran ahorro de esfuerzo y duplicidad. Sino también para que tengamos la libertad de elegir cualquier herramienta que queramos.

En el desarrollo web han aparecido islas, o silos. Al comienzo fue entre lenguajes, como ASP, JSP, PHP, Python, Ruby. Luego entre frameworks dentro de esos lenguajes. Y entre versiones de un mismo framework.

Muchos desarrolladores se amarran a cierta plataforma porque sus productos no pueden ser modificados con otra. Expresar un sitio dinámico en otro framework (o versión de framework) puede ser tanto trabajo como hacerlo de nuevo.

Después de todos los discursos que nos dan sobre la reinvención de la rueda, KISS (Keep It Simple, Stupid: Mantenlo Simple, Estúpido), DRY (Don't Repeat Yourself: No te Repitas), etc ¿no le parece poco razonable?

Hay razones por las que se prefirió que los protocolos web usaran texto simple. Para que cualquiera pudiera entrar a manejarlos. Quizás debemos recordarlo más seguido.

Imagine que le hicieran un sitio dinámico y, un tiempo después, usted quiere modificar el site.

Imagine que puede usar cualquier framework, modificarlo y guardarlo. Sin importar si se hizo en Drupal 6 o Drupal 7. O si se hizo en Zend o CodeIgniter. Incluso sin importar si se hizo en PHP, Ruby, Python o ASP. Qué libertad.

Claro que sólo lo podemos imaginar, pero podemos hacerlo.

Programando Web

Lea el artículo original en Programando Web.