Bueno, esta es la tercera y última parte de la saga "El camino a la web en Java con Play!"...Después de esto tengo planeado hacer algo más interesante (una aplicación de blogging o alguna sugerencia que hagan), que intentaré de subir a GitHub o algún medio de distribución de código, para que hagan mejoras y sugerencias con el fin de aprender cada vez más.

En esta ocasión les hablaré de la tercer parte más importante del framework y de cierta manera la más interesante; éstas son las vistas y configuraciones.

A lo que te truje chencha

Cómo ya hemos explicado antes, Play! maneja el patrón MVC, si no lo sabes con Play! aprenderlo es ridículamente simple (de hecho, gracias a Rails fue que yo lo aprendí; y cómo Play! sigue una filosofía similar, creo que es posible que lo aprendas desde Play!).
Ahora una vista al directorio de nuestro proyecto:
 

Para más de uno nos hemos planteado el uso de Java cómo tecnología de desarrollo principal. Típico llegamos vemos un foro, vemos tutoriales, vemos la tendencia en cuanto a herramientas, usamos lo más popular, en caso de ser novato lo más nuevo y terminamos con frustraciones muy grandes y proyectos inconclusos, todo por falta de búsqueda de información e incluso a veces por flojera.

Primero, cuando empezamos a programar entramos a un foro cómo este, preguntamos "¿qué es lo in para programar en web?". Obviamente que quien responda de manera honesta y que te deja de: "Ah, pues eso que dice es lo mejor", son las personas experimentadas que hacen macro-proyectos o proyectos muy interesantes que uno cómo principiante (o incluso cómo experimentado, está lejos de hacer algo así). Y obtenemos respuestas cómo Tapestry, Spring, Struts y JSF (digamos, son los más populares por acá) y claro terminamos en una decepción por diversos factores: Curva de aprendizaje, poco conocimiento base, viniendo de otro lenguaje -poco dominio de Java-, etc.

Bueno, continuemos con la siguiente entrega de esta saga. Cómo en el post pasado ya los he aburrido pasamos rápido a la (que al parecer llamaré) la sección "a lo que te truje chencha".

A lo que te truje chencha

Demos una vista de vuelta a los directorios en nuestro proyecto:
 

Se fijan cómo en el directorio de la aplicación existe el directorio controllers, cómo les dije en el post pasado este nos sirve para poner los controladores aquí. Ahora, antes de esto, sería chido tener en el IDE de nuestra preferencia pues bien para hacer esto vámonos a una terminal (línea de comandos), dirijámonos al directorio de nuestra aplicación y tecleemos:
Para Eclipse:
 
Para Netbeans:
 
Para IntelliJ IDEA:
 
Y listo, con esto estamos listos para abrir nuestro proyecto con nuestro IDE de preferencia.

Introducción:

Hace tiempo (cerca de unos 3 años) me encontraba estudiando el grado TSU. Siempre interesado en la carrera (TI, programación en específico) me llamó mucho la atención (desde hace cómo 8 años) la programación y creación de sitios y aplicaciones en la web.

¿Porqué me llamaba la atención?
La razón es porqué siempre me ha gustado la comodidad (no me lo tomen a mal), y creía que para las personas era más cómodo memorizar "mipaginita.com"; y desde cualquier punto (y dispositivo) con acceso al servidor (por medio de la red) poder hacer uso de tus recursos de la oficina sin la necesidad de estar presencialmente.

La elección del framework y el comienzo de una migraña:

Bueno, cómo es por todos los desarrolladores Java conocido que los problemas se hacen ver a simple vista (gente importante de Sun -ahora Oracle- renunciando, problemas con demandas que si con Google o cualquier otra VM Java-like, con un JCP moribundo, etc.) y muchos desarrolladores cómo yo estamos en el dilema de: "Continúo o no en Java a futuro", es decir, a día de hoy estamos básicamente en dos posiciones.
La primer posición es la de las personas pro-open source que dicen que Oracle terminará el legado de Java y ésta dejará de ser la herramienta por excelencia de los desarrolladores promedio y pasará a ser utilizado únicamente por empresas multinacionales (casi cómo lo maneja ahora con Oracle DB).
La segunda es de personas muy entusiastas que ven esta situación cómo una gran ventaja, el grande de las bases de datos con el grande en programación y sus agregados, lo cual (en teoría) nos permitirá hacer cosas muy robustas e interesantes.

Bueno, esta es la segunda entrega de 'Cosas simples que ayudan mucho' de mi blog. Y si bien gracias a @OscarRyz por explicar singleton en la entrada anterior no fue necesario hacer una entrega de esta nano-sección sobre singleton. A esto @OscarRyz ha propuesto algunos temas, uno de ellos es abordabo en esta entrada.

Comencemos con que es la refactorizacón de código. Seguro que cómo yo muchos de ustedes han llevado la materia de cálculo integral y diferencial (seguro a más de uno le dan pesadillas hoy XD), en donde existe algo que llamamos refactorización que es una manera más ¿simple? de expresar un resultado después de integrar o derivar.
Pues bien en programación es algo similar, expresar de una manera más simple y entendible el código que picamos.

Refactor en las propiedades

Si bien algo a lo que le hachaca a Java es lo verborreico que es. Si a esto le agregamos que los programadores puristas hacen algo cómo:
 

Bueno pues hace rato que alguien me ha preguntado qué es Lazy Load y cómo la podemos utilizar. La contesto hasta ahora (3 días después de cuanto tenía que entregar su tarea XD).

Lazy Load es un patrón de diseño muy simple que nos ayuda a optimizar la carga de datos cuando éstos son obtenidos de alguna fuente de datos (un archivo, una base de datos, un servicio web, etc.).

Ahora a picar código:
 

Bueno, algo de las cosas que ya he comentado que me fastidian de las comunidades Java (o cualquier otra), es que cómo dice ezamudio: "En JavaMexico hay muchos: 'Háganme la tarea' ". Incluso he visto casos en donde ponen la hora a la que la tienen que entregar.

He encontrado un viejo (pero muy buen) material sobre cómo realizar preguntas en algún foro. Algunos supongo ya lo conocen es el manual: "How to ask questions? (The smart way)" escrito (o atribuido) al señor Eric Steven Raymond. Les dejo un extracto (en el caso de este manual dice Hackers, pero lo puedes cambiar por programadores o cualquier otro especialista):

Lo primero que tienes que entender es que a los hackers les gustan los problemas realmente complejos y las buenas preguntas que les hagan pensar en ellos. De no ser así no estaríamos aquí. Si nos proporcionas una cuestión interesante te estaremos agradecidos; las buenas preguntas suponen un estímulo y un regalo. Las buenas preguntas nos ayudan a desarrollar nuestra comprensión, y a menudo revelan problemas que podíamos no haber percibido o en los que de otra manera no habríamos reparado. Entre los hackers, "¡Buena pregunta!" debe entenderse como un sincero cumplido.

A pesar de esto, los hackers tienen la reputación de enfrentarse a las preguntas sencillas con hostilidad o arrogancia. A veces parece como si resultásemos hostiles a los principiantes o a los ignorantes. Pero eso realmente no es cierto.

Lo que somos, de una manera no apologética, es hostiles con la gente que parece no querer pensar o hacer sus deberes {véase tareas} antes de plantear las preguntas. La gente de ese tipo son sumideros de tiempo -- toman sin dar a cambio, desperdician el tiempo que podríamos haber dedicado a otra cuestión más interesante y con otra persona más merecedora de una respuesta. A las personas de este tipo las llamamos "perdedores" (y por razones históricas a veces escribimos "lusers").

Somos, de largo, voluntarios. Robamos el tiempo de vidas ocupadas para responder preguntas, y a veces nos sobrecargan. Así que filtramos sin tregua. En particular, desechamos las preguntas de quienes parecen ser perdedores para ocupar el tiempo que dedicamos a responder preguntas de una manera más eficiente, con los ganadores.

Les dejo las ligas del manual completo:
Inglés
Español

Saludos.

He encontrado por JavaMéxico lo que parece un error (o me han crackeado X'D). Pude ver por acá que "estoy autenticado por partida doble", literalmente (click en la imagen):

Bueno, en un proyecto que estaba usando ArrayList y me encuentro que al hacer uso de nuestro querido y bien ponderado foreach (lo pongo en código):
 
¿Qué pasa?. Esto nos arroja una desagradable y nada querida ConcurrentModificationException. Existe la forma de usar la clase Iterator para evitarlo, pero: "A mi me gusta foreach, ¿tengo que usar Iterator nomás por esto?", si bien eres de los míos podemos usar en lugar de la clase ArrayList, la clase CopyOnWriteArrayList, dejando:

¡Y PIMBA!, nos quitamos de esa desagradable excepción. Saludos y espero que les sirva.
Les dejo esta liga de un artículo donde encontré esto pero en inglés.

Saludos.