Todavía lo asusta desarrollar en Java?

Aunque no suelo escribir mucho sobre Java ya este es el segundo artículo que escribo en una misma semana. No es que esté apostando mi dinero a Java por encima de .Net sino que simplemente quiero ayudar a que los desarrolladores de .Net pierdan el miedo o el respeto por Java y todas las tecnologías y herramientas que lo rodean. Al fin y al cabo no abrir esa puerta puede implicar perder buenos proyectos e ingresos, e incluso no disfrutar de algunas buenas tecnologías.

Años atrás cuando surgió .Net la diferencia de productividad entre este y Java se hizo demasiado grande. Muchas miradas se voltearon a .Net y los seguidores de Microsoft tuvieron aún más razón que nunca para no voltear a mirar la puerta del vecino.

Pues bien, creo que esa brecha hace rato que ha desaparecido. Si comienza a mirar a Java con mejores ojos y mejor voluntad verá que hoy es tan simple hacer las cosas tanto en un lado como en el otro.

Con el desarrollo de Spring Framework las cosas están siendo tan sencillas como en .Net, incluso sorprendentemente sencillas. Creame, mírelo con buenos ojos, identifique una buena documentación como punto de partida y verá que también disfrutará de ampliar sus horizontes.

Por ejemplo, si cree que .Net MVC es sencillo dese una vueltecita por Spring MVC y verá que hoy por hoy es igual de simple. Para que no quede en palabras aqui va un ejemplo:

Para crear el controlador:

Para crear la vista que se muestra con el método “greeting” de este controlador:

Para hacer la aplicacion ejecutable:

Simple, no?

Si así lo cree pues aquí le dejo un buen punto de partida para estudiar Spring Framework. Solo le recomiendo que antes lea acerca de estos temas:

• Inversión de Control (Inversion of Control)

• Inyección de Dependencia (Dependency Injection - DI)
• Programación Orientada a Aspectos (Aspect Programing Oriented - APO).

No se asuste, nada que no haya usado ya en .Net, solo que lo hemos hecho sin siquiera darnos cuenta.

El código de ejemplo que aquí he expuesto lo pueden consultar y descargar completamente de la guía de inicio de Spring Framework:

http://spring.io/guides/gs/serving-web-content/

Es muy posible que tenga que lidiar con el hecho que la lista de dependencias en los tutoriales esta muchas veces desactualizada (Así es este mundo medio desordenado de Java). Aqui le dejo un fragmento de las dependencias funcionando 100% al momento de escribir este artículo (utilizando Gradle):

Guías completas de spring: http://spring.io/guides

Ant, Ivy, Maven, Gradle, what and why?

Developers coming from the .Net world often wield several arguments against Java, some of these with reason, and others simply by sheer laziness.

One of the most common arguments against Java is the number of technologies and libraries around it, too many of them to do the same thing, and when you want to start, you find yourself lost in a ocean of information, often disorganized, almost in a chaos.

But, is it good or bad to have several libraries to achieve our goals?

The positive aspects of this situation from the perspective of the native Java developers are:

- The variety of options to achieve a single goal.

- It is almost always Open Source code, so, you can fix it if you need it.

The negative aspects of this situation from the perspective of native .Net developers?

- You don't know where to start.

- You don't know which, of the many technologies, is the best. Take for example this list of Views Templates: JSP/JSTL, Thymeleaf, Tiles, Freemarker, Velocity. It means that even within the same Java world it may be high learning curve to include a new member to the team.

- Little centralized documentation.

- The shelf life of the technologies is relatively much shorter than in .Net.

- And finally, there is a tree of dependencies between libraries with many levels, many times becoming an endless story.

Are the .Net people wrong? - No, I think they are not.

I clearly remember that years ago I was working on a project to make a website for games. The project leader (one of the people with more knowledge of the Java world) wanted to use quite an advanced and complex library set. A couple of years later I asked him to mount the site on a test server to show it to a client and you know what?

1- He needed a huge time to install everything from scratch. In the end, we never installed the app again.

2- The main library that we used, the core of everything, was not developed further. It would be forever forgotten. Besides, the huge list of dependencies had run with the same luck.

Then, in the midst of all this chaos, something or someone should put order and simplify these processes. That's where tools for project and dependency management, automatic updates, packaging and distribution, appear.

Here is why the native .Net developer finds so complex to come into the Java world, because in all honesty, they never have had that chaos: they have always had a MSDN containing all the documentation centralized, either online or offline.

Then, in the Java world arises Ant, Ivy, Maven, Gradle, etc., and one problem was solved, but at the same time this keeps the other problem open; which one of the many availables project's managers is good to me?

It's really ironic because something created to organize the chaos collaborates to create even more chaos, ha ha.

Well, the most famous and used tool is Maven, I think, but lately Gradle is raising with much power. However, Gradle has "partnership" with Maven because it makes use of its repositories and all his knowledge accumulated over the years.

Gradle is now used by Android Studio. Gradle is now on par with Maven in the Spring Framework tutorials.

There you go a list of useful resources:

http://maven.apache.org/what-is-maven.html

http://maven.apache.org/maven-features.html

http://spring.io/guides/gs/maven/

https://gradle.org/

https://gradle.org/learn

http://spring.io/guides/gs/gradle/

Ant, Ivy, Maven, Gradle, ..., qué y por qué?

Los desarrolladores provenientes del mundo .Net suelen esgrimir varios argumentos en contra de Java, algunos con razón y otros simplemente por mera pereza.

Uno de los argumentos más comunes en contra de Java es la cantidad de tecnologías y bibliotecas que lo rodean, muchas para hacer lo mismo, y cuando deseas comenzar te encuentras a ti mismo perdido en un mar de información muchas veces bastante desorganizado, prácticamente en un caos.

Pero es bueno o malo tener tantas bibliotecas para hacer lo mismo?

Lo positivo desde la perspectiva de los nativos de Java:

- La diversidad de opciones para lograr un objetivo.
- Casi siempre es código Open Source, puedes corregirlo si lo necesitas.

Lo negativo desde la perspectiva de los nativos .Net?

- No sabes por donde comenzar.
- No sabes cual de las tantas es la mejor. Pongamos por ejemplo esta lista de Plantillas para Vistas MVC: JSP/JSTL, Thymeleaf, Tiles, Freemarker, Velocity. Quiere decir que incluso dentro del mismo mundo Java puede ser alta la curva de aprendizaje para incluir un nuevo miembro al equipo.
- Documentación poco centralizada.
- El tiempo de caducidad de las tecnologías es relativamente mucho más corto que en .Net.
- Y finalmente un árbol de dependencias entre bibliotecas con muchísimos niveles, una historia sin fin muchas veces.

Están equivocados los nativos .Net? - No, no lo creo.

Recuerdo perfectamente que años atras trabaje en un proyecto para hacer un sitio web de juegos. El líder del proyecto (una de las personas con más conocimiento de Java que existen) se decantó o por una sería de bibliotecas bastante avanzadas y complejas. Un par de años después le pedí montar el sitio en un server de pruebas para mostrarselo a un cliente y saben que?
1- Necesitaba de un tiempo enorme para poder instalar todo desde cero. Al final, nunca se instaló nuevamente.
2- La principal biblioteca que usabamos, el core de todo, ya no se desarrollaba más. Quedaría por siempre en el olvido. Además que la enorme lista de dependencias ya corrían la misma suerte.

Entonces, en medio de todo este caos se necesitaba algo o alguien que pusiera orden y simplificará todos estos procesos. Allí es donde surgen estas herramientas de manejo de proyectos, administración de dependencias, actualizaciones automáticas, empaquetado y distribución de las mismas.

He aqui por qué a los nativos .Net les resulta tan complejo entrar al mundo Java, porque en honor a la verdad nunca han tenido ese desorden: siempre han contado con MSDN con toda la documentación bien centralizada, lo mismo online que offline.

Entonces en el mundo Java surge Ant, Ivy, Maven, Gradle, etc., y queda solucionado uno de los problemas, pero volvemos a lo mismo: y cual de los tantos manejadores de proyectos uso?

Realmente es irónico pero aún lo que se creó para organizar el caos crea aún más caos, ja ja.

Bueno, el más famoso y utilizado es Maven, creo yo, pero se esta potenciando últimamente con mucha fuerza a Gradle. No obstante, Gradle es un partner de Maven porque hace uso de sus repositorios y de todo su conocimiento acumulado durante años.

Gradle es hoy utilizado por Android Studio. También Gradle está hoy a la par de Maven en los tutoriales de Spring Framework.

Aqui les dejo una lista de recursos para profundizar en el tema:

http://maven.apache.org/what-is-maven.html
http://maven.apache.org/maven-features.html
http://spring.io/guides/gs/maven/
https://gradle.org/
https://gradle.org/learn
http://spring.io/guides/gs/gradle/

Mientras más conozco de Java más quiero a Microsoft

Dicen las mujeres:
Mientras más conozco a los hombres más quiero a mi perro!.

Es un refrán que me viene a la mente pero extrapolándolo a Java yo diría:

Mientras más conozco de Java más quiero a Microsoft.

Es casi imposible enfrentar un proyecto de Java sin tener que estudiar una o varias bibliotecas de terceros siendo a veces un “desorden de tecnologías” que no hay quien siga. He trabajado en proyectos donde se han utilizado unas bibliotecas enormes y tan solo al pasar de 2 años ya no se continúan desarrollando por sus creadores. Ni hablar del esfuerzo de instalar y configurar dichas biblioteca!!!, mama mia!. Si hoy quisiéramos continuar desarrollando el proyecto no nos quedaría mas remedio que comenzar de cero con otra.

Tengo un amigo que cada vez que le encargaban hacer algún proyecto se las ingeniaban para encontrar una biblioteca de “San Juan de los Palotes” y pedirle que la estudiara y la usara: el pobre!: bueno, no tan pobre, jeje, que gracias a eso pasó a mejor vida, quiero decir: a mejores condiciones laborales, jaja.

No quisiera referirme demasiado al tema de las interfaces visuales: AWT, Swing, SWT, alguna de Eclipse más una larga lista de etcéteras, sumado 18 mil IDEs (o pluggins o asistentes visuales o como les llamen) creados sobre estas que al final son en extremo lentos, no son muy compatibles con el resto de sus “tecnologías hermanas” y que casi nunca llegan a dar soluciones a todas las necesidades. Cuando más contento estas se te desconfigura el formulario tan detalladamente habías creado y en el cual habías invertido varias horas de trabajo. De pronto descubres que el titulo es la barra de estado, que el botón Cerrar está en el Encabezado y que los controles fueros todos a parar a no sé dónde?.

Mención aparte, y para bien, merece el tema J2ME (Java para equipos Móviles: Micro Edition). Creo que es uno de los temas menos problemáticos de Java, mejor tratados y que mejor responde a las expectativas. Bueno al menos no recuerdo haber sido infeliz durante el poco tiempo en el cual tuve que vérmelas con esta versión.

Soy consciente que los fanáticos o amantes de Java quizás deseen matarme después de tan pocos amables comentarios pero, qué le voy a hacer? Sé que es mucha mi ignorancia aun en el mundo del Java, pero señores me quedo con Microsoft y sus adorados IDEs: TODO en UNO.

Me viene a recuerdo un amigo que de seguro lee este articulo y que para mí es todo un símbolo de lo que yo llamaría Homosexualismo Tecnológico (no puedo escribir aquí la verdadera palabra con la que lo califico, jeje) o Traición tecnológica. Mi buen amigo se ha tatuado la tasita símbolo de Java pero se gana la vida con Microsoft y sus tecnologías, jajajajaja, es para morirse de la risa.

Sé que el expondrá sus razones desde el punto de vista comercial, etc, etc, pero cuando se ama algo, no se traiciona y menos por dinero, jeje.

Bueno, hasta aquí mis palabras de desahogo por la ultima e infeliz semana que me ha hecho pasar Java.

Problemas con Jdbc para conectar a una BD en SqlServer 2005 Express (PROGRAMACION)

Crear aplicaciones de bases de datos en Java a través de Jdbc puede no ser siempre una experiencia alegre, sobre todo cuando se trata de conectarlas con SqlServer.

En nuestro caso trabajamos con el IDE Eclipse, usamos un driver de Microsoft y usamos SqlServer 2005 Express Edition.

Los primeros problemas vienen con el Driver que a decir de varias personas en Internet no es la mejor opción seleccionar el de Microsoft sino otros de terceros que incluso se pueden encontrar en CodeProjetc con licencia GNU.

En Microsoft encontramos varias versiones: “Microsoft SQL Server JDBC Driver 2.0” y “Microsoft SQL Server 2005 JDBC Driver” y aunque la lógica indica hacer uso de este ultimo pues en mi caso solo funcionó el primero.

Entonces, ya sabe, si tiene problemas con la supuesta versión 2005 del Driver pues utilice en su lugar la versión “Microsoft SQL Server JDBC Driver 2.0”.

Estructura de la Cadena de Conexión.

Lo primero es un curso de adivino, hasta que te convences y buscas la documentación. Normalmente en todas las cadenas de conexión el nombre del servidor es “NombreServidor\NombreInstancia” (recordemos que podemos tener varias instancias de SqlServer en la misma PC, incluso de la misma versión) pero no se por cual motivo nuestros amigos de Microsoft decidieron separar aquí estas dos propiedades: Supongo que de fondo sea por culpa de alguna limitación de Java, jajaja.

El formato es como sigue:

"jdbc:sqlserver://MOMBRE_SERVIDOR;instanceName=NOMBRE_INSTANCIA;user=USUARIO;password=PSW;databaseName=NOMBRE_BD";

Un ejemplo concreto sería:

"jdbc:sqlserver://miServidor;instanceName=SQLEXPRESS; user=sa;password=miPassword;databaseName=miDB";

Una vez que esto es correcto estaremos en condiciones de crear Conexiones en Java a través del java.sql.DriverManager: DriverManager.getConnection(connectionUrl);

A partir de este momento pueden generarse una serie de mensajes de error entre cuyas causas están las siguientes:

- No Suitable Driver.

Este es un error bastante común y que lo he visto bastante documentado salvo por el segundo punto que expondré.

Lo primero es verificar que incluimos la biblioteca del driver en el ClassPath del proyecto. En el caso de Eclipse basta con acceder a la propiedades del proyecto, opción “Java Build Path” en la lista de la izquierda, ficha Libraries, botón “Add External JARs…” y localizar el jar del driver correcto como explique anteriormente.

Pero esto me funciono en varias PC y de pronto en una no me funcionaba, error va y error viene y ni atrás ni adelante, hasta que verificando observe que estaba usando la versión 5 y necesite configurar el uso de la versión 6 del “JRE System Library (jre6)” .

En mi caso, usando Windows7, mas de un problema me vino por esta causa. Por ejemplo el programa iReport no se me abría, entre otros, por lo que le recomiendo descargar la ultima versión del JRE.

- El servicio SQLBrowser está detenido.

Hasta ahora jamás he tenido que iniciar este servicio (parte del SqlServer) para conectarme con SqlServer pero al parecer este Driver hace uso del mismo para detectar la instancia que solicitamos.

Esto lo podemos hacer desde varios lugares: el administrador de Servicios del PC, el “Sql Server Configuration Manager” localizado en el grupo de programas del menú Start de Windows con nombre “Microsoft Sql Server 2005/Configuration Tools”.

- El protocolo TPC/IP de Servidor para SQLEXPRESS está desabilitado.

Casi de seguro deberemos activar el uso de este protocolo pues por defecto no se activa con la instalación.

Desde el “Sql Server Configuration Manager” vaya al árbol de la izquierda a la opción
“SQL Server 2005 Network Configuration/Protocols for SQLEXPRESS” y en la derecha active el protocolo TCP/IP.

- No está activada la Autenticación mixta para Sql Server que nos permita autenticarnos con usuarios propios del mismo y no con los usuarios de Windows.

Desde el “Micorsoft SQL Server Management Studio” acceda al nombre de su Instancia en el árbol de la izquierda (una vez registrado y conectado claro), acceda a sus Propiedades (clic derecho encima y seleccione Properties), vaya a la ficha Security y active la opción “SQL Server and Windows Authentication mode” del grupo de opciones “Server authentication”.

- El usuario “sa”está desabilitado o posee una contraseña diferente a la que está utilizando.

Aunque no es correcto, en ambientes de producción solemos utilizar al mismísimo usuario “sa” (System Administrator) para trabajar pero por defecto la instalación deja la posibilidad de autenticarse a través de este usuario deshabilitada.

Para corregir este problema, desde el “Micorsoft SQL Server Management Studio” acceda al nombre de su Instancia en el árbol de la izquierda (una vez registrado y conectado claro), acceda a la opción Security/Login/sa, y una vez allí, a sus Propiedades (clic derecho encima y seleccione Properties). Vaya a la ficha Status y active la opción “Enabled” del grupo de opciones “Login”.

De paso vaya a la ficha General y verifique o modifique la contraseña para este usuario.

Bueno, son bastantes las causas de errores media mágicas a las que nos enfrentamos como pueden ver. Espero tengan suerte y no se enfrenten a ellas.