Personalizar las páginas de error (404, 500, ...) en Apache Tapestry

16/05/2022
Artículo original

Apache Tapestry
Al desarrollar una aplicación y sobre todo si se trata de una página web pública a la que puede acceder cualquier usuario de internet es casi obligatorio hacer que las páginas de los diferentes códigos de error HTTP tenga el mismo estilo que el resto de las páginas de la aplicación y con el contenido que queramos indicar al usuario para que sepa porque se ha producido ese error y que puede hacer.

En Tapestry se puede redefinir la página de cualquier error HTTP, los más habituales son la del código de error 404 que es la de una página no encontrada o la del código de error 500 que es la página que se mostrará cuando se haya producido un error en el servidor.

Lo que hay que añadir para tener estas páginas personalizadas es un poco de xml en el archivo descriptor de la aplicación web (web.xml) y crear las propias páginas con el contenido que deseemos.

El código xml que debemos añadir es el siguiente:


En él indicamos que el filtro de Tapestry se encargue también de gestionar las páginas de los códigos de error y más tarde indicamos cuales son sus URL.

Una vez modificado el archivo web.xml deberemos crear las páginas personalidazas, no es diferente de cualquier otra página pero algo que nos puede interesar es distinguir si estamos en el modo producción o en el modo desarrollo para sacar más o menos información. En desarrollo nos puede ser útil disponer de esa información adicional. El símbolo SymbolConstants.PRODUCTION_MODE nos indica si estamos en modo producción y lo podemos configurar de diferentes formas, una de ellas es como un a contribución en el módulo de la aplicación.


La página de cualquier otro código de error HTTP sería similar a esta. Si quisiéramos mostrar una página de un código de error en la lógica de un componente debemos devolver en el manejador de evento un objeto HttpError:


Esta es una captura de pantalla de la página 404 con la aplicación en modo desarrollo.



Para finalizar la página de error 500 en Tapestry es diferente de la página cuando se produce una excepción en el servidor. Cuando se produce un excepción y no se controla de alguna forma Tapestry muestra la página ExceptionReport que explicaré como personalizar en otra entrada y que no es diferente de lo visto aquí.

Como en el resto de entradas el código fuente completo lo puedes encontrar en mi repositorio de GitHub. Si quieres probarlo en tu equipo lo puedes hacer de forma muy sencilla con los siguientes comandos y sin instalar nada previamente (salvo java y git). Si no dispones de git para clonar mi repositorio de GitHub puedes obtener el código fuente del repositorio en un archivo zip con el anterior enlace.


Referencia:
Documentación sobre Apache Tapestry

Razones para NO usar un IDE

16/05/2022
Artículo original

Un IDE, con permiso de la definición en la wikipedia, no deja de ser un editor de texto y una serie de utilidades que facilitan el trabajo de desarrollo, tales como configuración de los parámetros del compilador, debugger, ayuda en la sintáxis, documentación del lenguaje, etc.

Hace ya cosa de un par de años que no uso un IDE, bueno, uso vim como "IDE" y las razones son las siguientes:

- Me obliga normalmente a usar el editor que el IDE quiere. Con vim uso siempre, para editar lo que edite, las mismas combinaciones de teclas, misma configuración y en todas las máquinas en las que trabajo solo con llevarme el .vimrc

- Tiende a añadir complejidad. Los makefiles que se generan, los wizards de código, etc tienden a añadir mucho código que realmente no sabes como funciona y que es difícil de modificar.

- La ayuda con la sintáxis o el autocomplete. Aunque pueda parecer una maravilla me parece uno de los inventos más perversos. Usé eclipse durante más de un año y medio con java y un día intenté hacer un pequeño programa en el editor de texto y compilarlo con javac... fue imposible, no recordaba nada, cual eran los imports que debía hacer (eclipse lo hace como mágia), nombres de clases, excepciones que debía capturar...

- Trabajo en máquinas remotas. Muchas veces tienes que editar ficheros o incluso programar en una máquina que solo tienes acceso ssh. Usando vim es transparente el estar en tu máquina o en otra por ssh.

- Si no lo usas aprendes a manejar las cosas que pasan por debajo. Cuántos habrá que no sepan crear un .jar sin eclipse, como se especifica a gcc una librería o el path donde encontrar las cabeceras... sin contar aquellos que se sorprenden cuando puedes hacer todas esas cosas que hace el IDE pero sin el IDE. Si sabes como crear un .jar puedes estar tranquilo que con el IDE sabrás hacerlo igual de bien.


Sé que todo esto que digo suena a programador masoca, pero si de verdad quieres conocer lo que estás haciendo con detalle debes conocer lo que hay por debajo.

Bien es cierto que hay cosas muy útiles, por ejemplo la documentación siempre a mano, pero qué tiene eso que no tenga un man o un pydoc en la consola, una búsqueda en todo el proyecto, aunque no la cambio un ack-grep... lo único para lo que no he encontrado algo tan potente como eclipse es para las refactorizaciones... pero los buenos programadores nunca nos confundimos :P

Necesitamos buenos técnicos

16/05/2022
Artículo original

Para empezar, una frase:

Más hacer y menos hablar


es un ejemplo que define muy bien lo que está pasando ahora mismo. Nos hemos hartado de montar castillos sobre las nubes y cuando ya no podíamos llegar más algo nos la hemos pegado.

Estamos en un punto en el que una persona hace 1 año sin apenas saber sumar podía comprar una vivienda y sacarla un 30% sin despeinarse o que nos vendan la leche por que tiene calcio "de leche" -esta misma noche he visto un anuncio de pascual en TV, se habrán parado a verlo, alejandose unos metros de la pantalla, los creadores?-

Estoy hasta las narices de humo, quiero que cuando vaya al taller con mi coche venga un técnico y que sin pensar sepa lo que es ese ruido que apenas se escucha, y me da igual que el taller cumpla la norma de turno, quiero que cuando vaya al médico éste tenga los huevos pelados de tratar con pacientes, que sepa que me pasa o como mínimo que tenga recursos para saber qué hacer, quiero que cuando llame al banco a preguntar no me insten a hablar con "fulanito de tal" que es el que "lleva estas cosas".

Quiero que haya gente que sepa, gente preparada, que sepa hacer, que me solucione, que me aporte.

Pero claro, para hacer todo eso necesitamos muchos años de preparación -sí, de esas cosas que nunca valen para nada en la universidad-, mucha experiencia, dedicación, gusto por hacer las cosas bien... y una recompensa (social, económica, del tipo que sea), pero para que me voy yo a esforzar si puedo pasar de #ponga aquí su puesto vendehumista de moda# una temporada y eso de escornarse no está bien visto -menudo pringao que diría aquel-

Cada vez que veo a alguien haciendo bien su trabajo me resulta imposible no soltarle un "da gusto pagar cuando la gente hace las cosas bien"

Una semana como gestor de proyecto

16/05/2022
Artículo original

Primero de todo decir que no soy ni jefe de proyecto ni nada que se le acerque. La palabra jefe, gestor, responsable se usa con demasiada soltura, ser un gestor competente es muy difícil y requiere mucho tiempo, exactamente igual que ser bueno en otros ámbitos más un toque de sensibilidad con el prójimo.

En España los títulos de gestión (jefe de proyecto, jefe de sección, gestor de blabla) se usan como complemento a los absurdos salarios, "fulanito, vas a ser responsable jefe del proyecto amoeba-ultra-2.0, vas a llevar toda la gestión, sabemos que podemos confiar en ti, blablabla...", pero realmente no responden a una experiencia por parte de la persona que está en ese puesto, en la mayoría de los casos (*).

Nuestro scrum manager de cabecera en la empresa estaba de vacaciones, así que decidí tratar de hacer un sprint como mandan los canones de scrum, bueno, realmente como yo lo aprendí de @jmnavarro en mi estancia en unkasoft, con su reunión con cliente, elección de tareas del backlog, estimación, su avance, su burndown chart y finalmente la retrospectiva.

Decir que el desarrollo fue bien, se terminó en plazo, con calidad más que suficiente, pero eso no le interesa a nadie, aquí lo interesante es ver en donde metí la pata hasta el fondo, ¿no?:

- Puñetazos encima de la mesa: He tomado elecciones en base a mi experiencia por encima de las decisiones de mis compañeros, lo cual puede estar bien, pero no deja de ser un error. No dejar elegir su camino a tus compañeros es un grave error, aunque sepas sí o sí que hay formas mejores de hacer las cosas. Si la idea es formar un equipo de desarrollo a un buen nivel todo el mundo debe aprender y la mejor forma de aprender es afrontando problemas tú solito.

- Meterme en las tareas de mis compañeros: En un momento puntual decidí terminar a machete una tarea de un compañero (además de gestor, programo, ¿te suena?) ya que estaba bloqueando el desarrollo. Desde el punto de vista del proyecto es lógico hacerlo, pero no me paré a pensar que mi compañero se podría sentir ofendido, dolido por haber terminado algo en lo que estaba trabajando. Mil veces prefiero llegar tarde un sprint a tener un roce absurdo.

- Notificar los errores: no hay cosa más difícil que decir a alguien que la ha mangado. Y no quiero decir hacerlo sin que se sienta ofendido.

En resumen, si no tienes un poco de tacto, mano izquieda, inteligencia emocional, como lo quieras llamar, es mejor que te quedes como un buen técnico.

No hay nada mejor que las curas de humildad que la vida te da de gratis y que la memoria te recuerde los malos ratos que hiciste pasar a algún que otro gestor de forma innecesaria, mis disculpas atradas.





(*) En mi corta-pero-intensa vida laboral solo recuerdo a un par de personas haber estado a la altura de un puesto así, y cada día que pasa me acuerdo más de alguno de ellos :)

Pruebas unitarias de código que accede a base de datos

16/05/2022
Artículo original

Hibernate
Una de las dificultades que nos solemos encontrar a la hora de hacer pruebas unitarias es como probar el código que accede a la base de datos. El problema es que ese código necesita de una base de datos para ejecutarse, si se usa una base de datos como MySQL o PosgreSQL más que una prueba unitaria puede considerarse una prueba de integración y las pruebas pasan a depender de ese sistema externo con lo que las pruebas no son autónomas.

La base de datos H2 es una base de datos que puede ser embebida en una aplicación. Esta característica hace que pueda servir como base de datos contra la que lanzar los teses sin necesidad de una base de datos externa, además puede ejecutarse en memoria y sin comunicación de red lo que hace que sea muy rápida y los teses también. Tampoco es una solución perfecta ya que H2 puede tener un comportamiento diferente de la base de datos real pero en la mayoría de los casos nos servirá perfectamente.

Siguiendo los artículos anteriores en los que explicaba como acceder a una base de datos en una aplicación Java «standalone» y como hacer búsquedas en entidades de comino usando sin utilizar likes veamos como sería hacer una prueba unitaria de ese código que accede a la base de datos usando JUnit.

El método beforeClass inicializa la persistencia y crea el DAO. El método before borra los datos que haya creado un test anterior y crear los datos de prueba que una prueba puede esperar que existan, en este caso se trata de un único producto. Las pruebas consisten en probar el método findAll y search del DAO (el método removeAll puede considerarse probado en el before aunque podría crearse un caso de prueba específico):

En las pruebas unitarias al código que use el DAO puede proporcionársele un «stub» de este haciendo que devuelva los datos que necesitemos y sin necesidad de una base de datos como H2 pero para probar el DAO hay que disponer de una base de datos. Como es código que también puede contener fallos es bueno que también esté cubierto con algunas pruebas. Con Hibernate todo será más sencillo ya que con este además de abstraernos de la base de datos específica puede crear el esquema con las tablas y campos a partir del modelo de forma que antes de pasar los teses no necesitemos lanzar un script con sentencias SQL para crear las tablas.

Usar H2 como la base de datos contra que lanzar las pruebas unitarias es una solución imperfecta ya que idealmente la base de datos debería ser igual a la base de datos que vaya a usar la aplicación real (probablemente MySQL o PosgreSQL). H2 tiene la ventaja de que los teses se ejecutarán más rápido que con un sistema real externo y que las pruebas son más autónomas ya que no depende de ese sistema externo, aún así si hacemos uso de elementos nativos de la base de datos y queremos que queden cubiertos con pruebas no nos quedará más remedio que disponer de una base de datos «más real» que H2 para ellas aunque como decía estas pasarán a ser más de integración que unitarias.

Como el resto de ejemplos que escribo en el blog el código fuente lo puedes encontrar en mi repositorio de GitHub. Para probar este código en tu equipo basta con ejecutar:

Referencia:
Código fuente acceso a base de datos con Hibernate y JPAhttp://stackoverflow.com/questions/82949/before-and-after-suite-execution-hook-in-junit-4-x

Búsquedas de texto completo en objetos de dominio

16/05/2022
Artículo original

Hibernate
Si hace un tiempo hablaba de un problema muy común que nos encontramos al desarrollar una aplicación como los es internacionalizar los textos de algunos campos de una entidad de dominio, el hacer búsquedas de texto completo sobre esos campos más allá del like que nos ofrece el lenguaje SQL de las base de datos también es un problema a resolver.

La primera solución que se nos puede ocurrir es hacer las búsquedas empleando el like del lenguaje SQL de la base de datos relacional que usemos. Sin embargo, el like de SQL tiene varias limitaciones y además es lento, supone una carga para la base de datos y las coincidencias son muy limitadas no teniendo en consideración peculiaridades del idioma como tildes y aproximaciones. Para tratar de resolver estos problemas podemos usar la librería Hibernate Search que a partir de las clases de dominio y de las propiedades sobre las que queramos hacer búsquedas creará un indice de Lucene para realizar búsquedas más rápidamente y con mejores resultados.

Hibernate Search
Con Hibernate Search que se apoya en Lucene podemos obtener resultados que son aproximaciones a la palabra búsqueda, por ejemplo, si buscamos «refactor» podemos obtener coincidencias para las palabras «refactors», «refactored» y «refactoring» en el lenguaje inglés. Cada lenguaje tiene sus propias reglas de análisis para buscar estas aproximaciones y hay analizadores para la mayoría de lenguajes. Además, podemos obtener una aproximación de las coincidencias encontradas totales al estilo de como hace Google.

Continuando el ejemplo de como usar Hibernate en una aplicación «standalone» vamos a ver que hay que hacer para crear el índice y como realizar una búsqueda empleando Hibernate Search.

SQL
Otra alternativa a Hibernate Search es si la base de datos soporta «full text search», es decir, el motor de la base de datos soporta en la sintaxis de las sentencias SQL búsquedas de texto completo. En MySQL es posible pero hasta la versión 5.5 solo si la tabla está definida con MyISAM aunque a partir de la versión 5.6 es posible hacerlo con InnoDB que es el modelo de almacenamiento recomendado. La sintaxis de la sentencia SQL para MySQL sería:

En PostgreSQL la sintaxis «full text search» es diferente:


Aunque con soluciones específicas del motor de la base de datos como esta perdemos la abstracción de la base de datos que proporciona Hibernate nos evitamos el tener que mantener el índice de Lucene con Hibernate Search.

Elasticsearch
Otra posibilidad muy interesante y tan buena o mejor que las anteriores es utilizar elasticsearch aunque al igual que con Hibernate Search debamos mantener e índice y los datos sincronizados pero eso probablemente sea tema para otra entrada :).

Referencia:
Código fuente búsqueda con Hibernate Search
Internacionalización (i18n) de campos con Hibernate
http://wiki.apache.org/solr/LanguageAnalysis
http://eraunatonteria.wordpress.com/tag/full-text-search/
http://dev.mysql.com/doc/refman/5.0/es/fulltext-search.html

Libro sobre desarrollo de aplicaciones con Apache Tapestry

16/05/2022
Artículo original

Recientemente he publicado PlugIn Tapestry, un libro acerca del desarrollo de aplicaciones web en el lenguaje Java y con el framework Apache Tapestry.

PlugIn Tapestry
Apache Tapestry es un framework orientado a componentes para crear aplicaciones web rápidas, dinámicas, robustas y altamente escalables en la plataforma Java. Al basarse en componentes es distinto de los muchos basados en acciones similares en esencia a Struts que podemos encontrar en la plataforma Java como SpringMVC, Grails y Play! y también de los muchos otros en los que la principal diferencia es el lenguaje como Django (Python), Symfony (PHP), .NET MVC (C#) o Ruby On Rails (Ruby).

Incluyendo la descripción de las características del framework el libro trata la mayoría de aspectos que puede necesitar una aplicación o página web, entre ellos:
  • Introducción, principios y características
  • Inicio rápido
  • Páginas y componentes
  • Contenedor de dependencias (IoC)
  • Assets (imágenes, estilos, javascript) y módulos RequireJS
  • Formularios
  • Internacionalización (i18n) y localización (l10n)
  • Persistencia web
  • Persistencia en bases de datos
  • Ajax
  • Seguridad (autenticación, autorización, XSS, Inyección SQL)
  • Librerías de componentes
  • Pruebas unitarias, de integración y funcionales (JUnit/Mockito, Spock, Geb)
  • Y algunas cosas más

El libro está basado en la siguiente versión de Tapestry, la 5.4, que actualmente está en estado alpha (aunque la mayoría servirá para la versión final y para la versión 5.3 actual). Esta versión tiene como principal novedad la parte cliente de las aplicaciones con la inclusión de RequireJS y la definición de los archivos Javascript mediante módulos. También incorpora una capa de abstracción que permite usar cualquier librería como apoyo a la funcionalidad que necesita proporcionar ya sea Prototype, jQuery, cualquier otra que prefiramos o nueva que se desarrolle en un futuro.

Además del libro he desarrollado una pequeña aplicación (disponible en mi repositorio de GitHub) con unos pocos ejemplos que puedes probar en tu equipo sin necesidad de instalar nada previamente, salvo Git y el JDK. Más de 200 páginas de documentación que permitirán al lector descubrir mucha de la magia que puede ofrecer este framework. Además en mi blog puedes encontrar varias entradas sobre muchos de los temas tratados de forma individual y que he utilizado para escribir el libro.

Puedes descargarlo desde la página que he preparado para ello de forma totalmente libre y al inmejorable precio de 0,00€ impuestos incluidos. Tienes mi permiso (es más, animo a ello) para compartirlo, distribuirlo en redes P2P, subirlo a cualquier página web o «piratearlo» cuantas veces quieras, siempre que respetes la licencia Creative Commons bajo la cual lo he publicado.

Apache Tapestry

Algunas características destacadas de Apache Tapestry son:

Java
Normalmente se usa el lenguaje Java con lo que el compilador y el asistente de código de tu IDE te ayudarán.

Políglota
Si prefieres puedes utilizar Groovy, Scala o cualquier otro lenguaje soportado por la JVM.

Productivo
La recarga de clases en caliente evitará que tengas que reiniciar el servidor para ver tus cambios aplicados. Simplemente actualiza el navegador.

Rápido
El framework está programado en Java sin hacer uso de reflection. Incorpora varias optimizaciones que harán tu aplicación más eficiente sin trabajo por tu parte como compresión gzip, minificación y agregación css/javascript, cacheo agresivo en el cliente de assets, supresión de espacios en blanco innecesarios, ...

Basado en componentes
Los componentes son piezas autónomas y resusables de código. Para usar uno simplemente necesitarás conocer sus parámetros todo lo demás como archivos javascript, hojas de estilo y mensajes localizados son proporcionados por el componente. Los componentes pueden lanzar eventos y diferentes contenedores comportarse de diferente forma ante el mismo evento.

Informe de error avanzado
El informe te proporciona mucha más información que simplemente la traza de la excepción, verás que se estaba haciendo, que fué mal y como coregirlo. Con toda esta información solucionar las excepciones será mucho más rápido y fácil. El informe de error también es presentado en caso de errores en las peticiones AJAX.

Testable
Puedes probar los componentes de forma unitaria, el html generado o hacer pruebas de integración y funcionales. Los componentes son POJOs que no necesitan heredar ni implementar ninguna clase del framework. Podrás utilizar la herramienta que desees JUnit/Mockito, Spock, Geb, ...

Extensible, adaptable y modular
Gracias al contenedor de dependencias y a que los servicios están programados en base a interfaces puedes definir una nueva implemetación que modifique el comportamiento del framework. Todo servicio en el contenedor de dependencias puede ser redefinido, la mayoría de las cosas son servicios. Exiten módulos para Hibernate, Apache Shiro, Quartz, ... y si no existe puedes usar cualquier librería como RESTEasy, JasperReports, EHCache, JFreeChart, RestFB...

i18N y l10N
Puedes tener catálogos de mensajes por componente o de manera global en la aplicación. Los assets (imágenes, css, ...) tanbién son localizables y tener una plantilla con un contenido totalmente diferente según el idioma del usuario.

Convención sobre configuración
Las convenciones permiten evitar la configuración y los posibles errores que podemos cometer al realizarla. Pero más importante, hace que cualquier programador que conozca las convenciones sepa inmediatamente como están organizadas todas las cosas con lo que el tiempo de aprendizaje se reduce considerablemente.

Librerías de componentes
Los componentes comunes a varios proyectos pueden ser agregados en una librería de componentes (no es más que un archivo jar) para ser reutilizados. Nuevamente para usar los componentes solo tendrás que preocuparte de los parámetros, todos los recursos que necesiten serán extraídos de la librería. No necesitarás copiar y pegar archivos de un proyecto a otro, solo agregar una dependencia o jar a tu proyecto.

Según su principal desarrollador (Howard Lewis Ship, que obtuvo el premio Java Champion en 2010 [1] y Duke's Choice Award por el framework [2] en la categoría open source), y modestia aparte, piensa que Tapestry ha sido un líder desde una perspectiva puramente tecnológica. Estas son algunas cosas que cree que hizo primero y todavía piensa que lo hace mejor que nadie:
  • Componentes reusables (2001)
  • Informe de excepción detallado y útil (2001)
  • Instrumentación invisible en las plantillas (2002)
  • Informe de error con precisión de linea (2004)
  • Metaprogramación y modificación de bytecode (2005)
  • Recarga de clases en caliente (2006)
  • Informe de error completo para peticiones Ajax (2012)

¿Te ha parecido poco? ¡Descubre más en el libro!. Que lo disfrutéis, usar el siguiente enlace para ¡descargarlo!

Acceso a base de datos con Hibernate y JPA

16/05/2022
Artículo original

Hibernate
Si usamos Hibernate como la capa de persistencia de nuestra aplicación es muy probable que lo usemos a través de una aplicación web. Sin embargo, en algún caso como una migración de datos, la generación de algún informe o extracción de datos que no queramos o no nos sea posible hacerla en la aplicación web por el tiempo que tarda o la carga que supone para la aplicación web nos puede interesar usar Hibernate desde una aplicación Java normal lanzada desde linea de comandos.

Para ello deberemos obtener el objeto Session si usamos hibernate directamente o el EntityManager si usamos hibernate a través de JPA. La API de JPA es una capa de abstracción para varias librerías de persistencia, ORM, similares a Hibernate. Si Hibernate nos abstrae de la base de datos, JPA nos abstrae del framework de persistencia que vayamos a usar de forma que podamos reemplazarlo por otro sin realizar ninguna modificación al código JPA. Si ya sabemos usar Hibernate usar JPA no nos supondrá mucha dificultad ya que JPA se basa en gran medida en Hibernate.

En el siguiente ejemplo se puede ver como obtener un EntityManager, eliminar todos los objetos y hacer una búsqueda.

En el ejemplo he usado un dao genérico que nos puede servir para cualquier tipo de entidad, aunque el dao contenga operaciones básicas como probablemente sean comunes a todas las entidades que tengamos nos será de gran utilidad. A continuación las anotaciones que debemos usar para la entidad a persistir, nada distinto de lo que haríamos en una aplicación web.

Si JPA no tuviese alguna funcionalidad que si tuviese hibernate desde JPA podemos obtener el objeto Session con el que acceder a la API de hibernate.

Ejecutando la aplicación HibernateJPA obtendremos lo siguiente en la consola:

Como comentaba usar Hibernate en una aplicación Java normal no será lo habitual pero este ejemplo es el primer paso para que explique con un ejemplo simple como resolver otro de los problemas que suele ser habitual en muchas aplicaciones que es como hacer búsquedas sobre los objetos de dominio y no me refiero a usar likes de SQL que tienen varias limitaciones aparte de ser lentas si la tabla de búsqueda tiene muchos registros sino usando Hibernate Search.

Para probar los ejemplos en tu equipo puedes hacerlo con los siguientes comandos:

Si te ha interesado esta entrada quizá también te interese como hacer internacionalización (i18n) de campos con Hibernate y como hacer búsquedas de texto completo en objetos de dominio.

Referencia:
Código fuente acceso a base de datos con Hibernate y JPA
http://docs.jboss.org/hibernate/core/3.6/quickstart/en-US/html/hibernate-gsg-tutorial-jpa.html
http://www.manning.com/bauer2/
http://www.apress.com/9781430219569

JavaHispano Podcast - 079 - Noticias Marzo 2010 (a)

16/05/2022
Artículo original


¿Programar en español o en inglés? - Opinión

16/05/2022
Artículo original


En una ocasión me encontré con un proyecto en el que el responsable había decidido hacer el proyecto en inglés. La cuestión es ¿es ventajoso programar en inglés?. Con programar en inglés me refiero a declarar todos los nombres de las tablas, métodos y ciertas variables totalmente en inglés. A primera vista puede parecer una gran idea. Acostumbrarse a desarrollar en inglés puede facilitarnos a participar en proyectos de software libre que podemos ver en sourceforge, perfeccionar el inglés y quizá en un futuro nuestro proyecto pueda ser desarrollado en el extranjero.

Sin embargo, esas ventajas se volvieron totalmente en contra del proyecto por los siguientes motivos.
  • Empleo de términos incorrectos. Aunque sepamos inglés y hayamos estudiado bastantes años, nos podemos encontrar un término asociado a un tipo de negocio que no conozcamos. En ese caso, lo primero que haremos es utilizar un diccionario o utilizar un traductor. Lo más probable es que el término en concreto tenga varios significados y elijas el incorrecto.
  • Ampliación el grupo de trabajo. Un problema siempre ha sido la incorporación de personal en un proyecto. Si utilizas términos en ingles perjudicarás en su incorporación ya que puede que no todo el mundo tiene el mismo nivel de ingles. Lo que ocurrirá es que estas personas intentarán escribir en español y finalmente quedará un batiburrillo de conceptos en inglés y español.
  • Poca probabilidad de ser un proyecto internacional. Salvo que el proyecto tenga un enfoque internacional, pocas veces he visto que un programa se desarrolle mitad en España y mitad en extranjero. No digo que no haya pues si conozco algún caso, pero en general, los proyectos que tienen proyección de desarrollo en España no pasan fronteras (refiriendonos en el desarrollo)
  • Pocas personas hacen software libre. Quizás una de las ideas que tenias era practicar para familiarizarte en proyectos internacionales o participar en proyectos sourceforge. Sin embargo, existe un porcentaje muy pequeño que estén interesados en participar en este tipo de proyecto. Por ello, lo único que has hecho es hacer algo que te divertía pero al grupo quizá no.
Además de estos problemas, creo que tenemos una ventaja también al escribir en Español frente a desarrolladores en Inglés y es poder detectar en un momento que código es nuestro y que código pertenece a una librería externa. Por ejemplo, en algún tutorial escrito en inglés a veces he copiado una función que a su vez hacía referencia a otra pero como esta estaba en inglés no sabía que también la tenía que incluir y luego me daba fallos. Sin embargo, cuando leo un tutorial con funciones en español, al ver la llamada ya sé que eso no pertenece a la librería y debe estar en otro sitio o la debo crear.

Finalmente, también es perjudicial pensar solo en español pues gran parte de documentación técnica está en inglés. En mi opinión hay que saber inglés para entender la documentación técnica pero en el día a día, donde no todo es perfecto, hay que facilitar las cosas.

Página Anterior Página Siguiente