Argentina On Rails

Hace un tiempo que vengo discutiendo y debatiendo esto con colegas, por momentos creo que hay que hacer todo en inglés, pero llegando a ciertas instancias, sobre todo si programamos en objetos, lo más natural es llamar a las cosas por su nombre y no tener que traducir nada en nuestras cabezas.

Cuando trabajaba en el BGBA una convención interesante fue: objetos del negocio, en nuestro idioma, y frameworks y cosas tecnicas en gringo.

Convengamos que si tengo que desarrollar para gringos escribo todo en inglés.

En el caso de programar algo para Argentina o latinoamérica que decisión toman y porque?

Leyendo la entrevista a Zed Shaw sobre Mongrel que sugiero que la lean (intentaremos conseguir la traduccion), me llamo la atencion el concepto de Shibumi, el cual es impresindible tenerlo presente al momento de diseñar y codificar y que a veces tanto nos cuesta haciendo las cosas complicadas.

Shibumi (“elegance”) summons the image of something astringent in sensation, while it hints at that which is unforced or dignified. A shibumi flower arrangement brings into being coolness during a scorching summertime and sunshine on a frigid day. That which is shibumi is quiet in refinement, noble and fulfilling in a manner that is not shaped exclusively by analytical thought. It is the pathos of “not too much,” the use of creative restraint in the supreme sense.

? Shibumi (Ñ) (“elegancia”) convoca la imagen algo astringente en la sensación, mientras que hace alusión a la que sea natural o digno. El que es shibumi es reservado en el refinamiento, noble y satisfaciendo de una forma eso, no es formado exclusivamente por pensamiento analítico. Es el pathos “no de demasiado,” el uso creativo en el sentido supremo.

Intente traducir lo mejor posible.

A que viene esto, a lo simple, a lo natural, a lo que apunta Rails y debemos intentar mantenerlo.

P

Desarrollar aplicaciones teniendo una lengua nativa que no es ingles, nos lleva a tener que tomar ciertas determinaciones sobre como llamar a las models, classes, controllers dentro de nuestro codigo y asi tambien como documentamos y hasta como terminamos comunicandonos con el resto de los colaboradores.

De ahi surge la disyuntiva de que traducimos al español y que no. Mi experiencia me ha llevado a la siguiente definicion:

• Todo lo que es framework (ActiveRecord, AciveSupport, Cache, y otros nuevos objetos especificamente tecnologicos) donde no existen objetos de negocio, va en ingles.
• Donde aparecen los objetos y reglas del negocio es en español.

Esto en Rails nos da un beneficio al momento de hacer los scaffold ya que no tenemos que andar corrigiendo los nombres de los labels y esas cosas.

Ahora al momento de desarrollar una aplicacion multilenguaje habria que analizar un poco mas. Ya veremos esto.

Saludos

P

obviamente IMHO

DRY says that every piece of system knowledge should have one authoritative, unambiguous representation. Every piece of knowledge in the development of something should have a single representation. A system’s knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation. Dave Thomas

Muchos hemos leido acerce el concepto de DRY, y instintivamente y con los ejemplos planteados llegamos a decir que DRY es evitar repetir codigo, pero va mas alla de eso, en esto debemos incluir, Test, Construccion, Compilacion, Esquemas de bases de datos, etc.

Quien es Dave Thomas?

Dave Thomas is a cornerstone of the Ruby community, and is personally responsible for many of its innovative directions and initiatives. He and original co-author Andy Hunt are founders of the Pragmatic Programmers and the Pragmatic Bookshelf.

P

Ajax esta haciendo mucho ruido en todas las plataformas. En el momento de decidir “Ajaxear” mi sitio web, debemos tener en cuenta que dejamos afuera utilizando Ajax.

Desventajas Ajax

• El boton back, stop, y actualizar del browser no siempre funcionan.
• No son bookmarkeables
• No simpre se imprimen bien
• No corren off-line
• Los clicks y las acciones no quedan en el historial del navegador.
• No es indexable por los robots de los buscadores

La respuesta es otra pregunta: Necesitas una Rich Internet Application?

Si estamos interesados en tener una aplicacion rica en internet, quizas no nos interesen la mayoria de los puntos declarados como desventajas, en caso de que la mayoria de estos puntos te pongan en duda, no deberias implementar toda tu aplicacion utilizando Ajax.

Obviamente no quita tener algunos pequeños widgets en Ajax que hagan mas agil tu website.

P

Escuchando hablar de Flex 2, busque si alguien habia investigado en la combinacionde Flex con Rails y encontre esto

RubyOnRails (1.1) and Flex (2.0): Pt 1

Para los que no estamos del lado oscuro de la fuerza, Flex es free, si asi es, lo que se paga es la ide.

Viene ademas con ajax-bridge para interactuar con el scripting del browser. O sea que podemos combinar flex controls con rjs?

Voy a jugar con esto y posteare comentarios al respecto

P

Asi se llama el tutorial que recomiendo acerca de stylesheets, donde se presenta paso a paso explicando en detalle como armar un layout tableless (sin tablas) con css. Ver WikiOnrails Para los que no estan al tanto, se hace mucho hincapie en el evitar las tablas en el html porque hace mas lento el render en los browsers porque hasta que no llega al ultimo /table no muestra nada. Ni hablar de la baja performance de tablas anidadas.

P