Diana
Shirley Sanchez Hernandez
Electiva
Profesional A3
FUSM
- Fundación Universitaria San Martin
Palmira-Colombia
preciosanchez@gmail.com
|
Resumen—Este ensayo nos dará una idea general acerca de las
plataformas utilizadas para crear y/o desarrollar aplicaciones web,
identificaremos los principales lenguajes de programación (o plataformas de desarrollo) para la implementación
aplicaciones web y los servidores (de aplicaciones) en los cuales se instalan
dichas aplicaciones (por lenguaje de programación).
I.
INTRODUCCIÓN
En la actualidad Internet es la mayor fuente de contenidos donde los
usuarios pueden buscar información sobre lo que necesitan. Los motores de
búsqueda Como Google son los encargados de esta actividad, que generalmente dan
como resultado un exagerado volumen de información, tan grande que encontrar la
que se ajuste a las necesidades personales podría consumir mucho tiempo del
cual no se dispone.
Los sistemas de búsqueda basan su proceso en
fórmulas matemáticas y las coincidencias de las palabras escritas por el
usuario en el texto de los documentos encontrados.
El objetivo de este trabajo es estudiar la
tecnología necesaria que propone una Solución a los problemas que hoy aquejan
nuestro sistema obsoleto a la hora de realizar cualquier actividad de la vida
diaria.
Este trabajo inicia con una pequeña introducción
sobre conceptos de Lenguajes de
programación,
Luego la unidad 2 muestra la implementación de las
diferentes aplicaciones web, y los servidores en los que se instalaran dichas aplicaciones.
CRITERIOS
PARA EVALUAR UNA PLATAFORMA DE DESARROLLO.
A continuación las 5 plataformas más populares de
lado servidor: Java, PHP, Microsoft .NET, Python y Ruby On
Rails. Las plataformas se
evaluaran en base a los siguientes Criterios:
–
Grado de madurez.
–
Tamaño y grado de actividad de la
comunidad.
–
Disponibilidad de librerías y
aplicaciones de terceros.
–
Disponibilidad y coste salarial de
los programadores.
–
Dificultad de la curva de
aprendizaje.
–
Compatibilidad con el resto del
ecosistema.
–
Rendimiento y escalabilidad.
La productividad como ya es sabido si se usan bien,
todas ellas ofrecen un grado de productividad equivalente, o, al menos no lo
bastante diferente como para que debiera ser relevante.
¿POR QUÉ?
LA MADUREZ
Hay
proyectos, como por ejemplo node.js que se crearon para resolver problemas
específicos. En el caso de node.js el tratamiento de peticiones AJAX desde las
nuevas aplicaciones HTML5. Node.js ofrece una modalidad de procesamiento
asíncrono junto con la propuesta de programar en JavaScript igualmente en el
lado cliente y en el servidor
Es más complicado de aprender y de codificar en Tomcat,
ciertamente, pero a cambio se tiene una plataforma mucho más madura, eficiente
y compatible que node.js. Más madura implica, por ejemplo, casi siempre mejor
documentada. Las carencias de la documentación, por cierto, son un mal endémico
en las librerías JavaScript cliente incluso en las más maduras como Dojo o YUI.
EL TAMAÑO
Es relevante porque cuanto mayor sea la comunidad
más probable es que hay alguien que se haya topado con el mismo problema que
nosotros y lo haya resuelto. Más probable que en Stack Overflow o en cualquier
otro sitio de preguntas y respuestas hallemos la solución a un problema que nos
mantiene atascados.
LA DISPONIBILIDAD
De aplicaciones y librerías de terceros. El
framework de desarrollo es sólo la herramienta base para construir una
aplicación. Justo a continuación de elegir la plataforma hay que elegir las
librerías. Por ejemplo, Java domina absolutamente el entorno financiero y
bancario porque su middleware es el mejor. Lo hay para todos los gustos desde
JBoss a TIBCO, pasando por Informatica UM. Los frameworks más modernos de todos
los lenguajes han ido incorporando librerías de serie. Java apareció en 1995 y,
más que un lenguaje para aplicaciones web estaba pensado con filosofía WORA
(Write Once Run Anywhere) y para tener la menor cantidad de dependencias
posible. Ruby On Rails apareció 10 años después e incorporaba en su
arquitectura el paradigma Modelo Vista Controlador (MVC) y mecanismos como
ActiveRecord que permiten que las clases tomen de la base de datos los nombres
de la columnas sin necesidad de definirlas explícitamente en el código. Para
conseguir con Java un framework funcionalmente similar a Ruby on Rails se necesita,
al menos, una librería MVC como Struts, una capa de persistencia como
Hibernate, soporte de servicios REST como Jersey, una librería de tags como
JSTL y JavaMail. La cantidad de librerías Java es tal que existen empresas como
Black Duck en EE.UU. Autentia en España especializadas en evaluarlas y dar
formación a los clientes corporativos.
DISPONIBILIDAD Y COSTE
Si se estima
que el proyecto requerirá 40 o 50 desarrolladores entonces encontrar y
contratar personas puede llegar a ser muy difícil y costoso. Si se estima que
el proyecto necesitará más de 50 desarrolladores, entonces es que se ha hecho
mal el plan y bien hay que partir el proyecto en trozos de menos de 50, bien
sería mejor cancelarlo y tirarlo todo a la basura antes de que se queme una
burrada de dinero en producir un monstruo.
DIFICULTAD DE LA CURVA DE APRENDIZAJE.
Todas las plataformas son igualmente buenas en
cuanto a productividad. Pero no todas son igualmente fáciles de aprender. Si se
tiene cuenta el tiempo que requiere un programador novato para aprender cómo
funciona el invento, entonces sí que existen diferencias entre unas y otras. El
orden de más fácil a más difícil es: PHP, Ruby On Rails, .NET, Python y Java.
COMPATIBILIDAD CON EL RESTO DEL ECOSISTEMA.
Rara vez las aplicaciones existen de forma aislada
e independiente unas de otras. En general, las diferentes plataformas no son
fácilmente interoperables unas con otras. Existen muchas herramientas de
integración y formatos de representación de datos independientes del lenguaje
como Protocol Buffers, pero lo más común, por fácil, es que las plataformas en dos
lenguajes diferentes se acaben integrando vía base de datos relacional, XML o
ficheros de texto delimitado.
RENDIMIENTO Y ESCALABILIDAD.
A grosso modo, si se tiene una base de datos con
tablas que no superan el millón de registros y un sitio web que no supera las
cien mil visitas al día, entonces la escalabilidad no será una cuestión
relevante se use lo que se use a menos que el programador sea realmente malo,
pues cualquier servidor quad-core medio moderno puede atender tal volumen de
trabajo sobre una base de datos relacional.
II.
LENGUAJES
JAVA
Java es la plataforma más extendida en el
entorno corporativo. Se trata de una tecnología muy madura y popular que cuenta
con innumerables herramientas de todo tipo y es bastante sencillo encontrar
programadores. Casi todo el mundo que desarrolla en Java usa Eclipse o Netbeans
como IDE. Ambos son bastante pesados y a mi personalmente me gusta más
JCreator, aunque en un portátil con 4Gb de RAM tanto Eclipse como Netbeans
corren perfectamente. La principal pega de Java para el desarrollo de
aplicaciones web es que la plataforma no se concibió originalmente para eso,
sino que fueron apareciendo proyectos como Tomcat en 1999. Las extensiones a la
plataforma se acuerdan mediante el Java Community Process (JCP) compuesto por
más de mil miembros que trabajan sobre más de 300 Java Specification Requests
(JSR) Estas especificaciones tienden a ser muy densas y a veces salen cosas
realmente retorcidas como JavaMail. Algunos presuntos gurús han difundido el
mito de que una startup no debería basar su tecnología en Java. Esto es
radicalmente falso pues Java es perfectamente compatible con el modelo lean en
boga. La curva de aprendizaje de Java no es suave.
PHP
También conocido popularmente como LAMP
(Linux+Apache+MySQL+PHP). PHP (acrónimo recursivo de Hypertext Pre-processor)
es coetáneo de Java. Apareció también en 1995, pero, a diferencia de Java,
estaba pensado desde el principio como un lenguaje que se pudiera incorporar en
documentos HTML. La gran ventaja de PHP es que resulta sencillo empezar con él
y existe mucha documentación online. Es más fácil aprender PHP que Java, y
todos los ISP proprocionan algún tipo de stack LAMP preconfigurado. Es por
consiguiente sencillo encontrar programadores PHP a precios asequibles. PHP no
proporciona un sistema MVC por defecto pero existen muchas opciones para ello.
A mi me gusta CakePHP mas se pueden contar las alternativas por decenas siendo
Zend probablemente la más popular. Hay muchas startups de éxito basadas en PHP,
incluídas algunas de las de mayor tráfico como Wikipedia, Yahoo o Facebook
entre ellas. El lenguage en sí mismo presenta algunas limitaciones importantes.
No se pueden crear de forma natural pools de conexiones, no hay sesiones, el
módulo mod_php para Apache permite mantener sesiones pero mucha gente lo
considera intrínsecamente inseguro. La propia facebook acabó desarrollando su
propio compilador just in time (JIT) HHVM para poder alcanzar el rendimiento
que necesitaban con PHP.
.NET
Si Sun no hubiese creado Java probablemente
.NET dominaría ahora mismo todo el panorama de software empresarial. El punto
fuerte de plataforma de Microsoft es el grado de integración entre el
escritorio y las aplicaciones web. Si yo tuviese que desarrollar una Intranet a
sabiendas de que los usuarios van a tener todos Windows no lo dudaría y la
desarrollaría sobre .NET. Mas para una startup yo nunca elegiría .NET no por
problema alguno con la tecnología sino simplemente porque el software de
Microsoft no es Open Source. .NET sólo puede correr en servidores distintos de
Microsoft Internet Information Server si se usa Mono y los servidores Windows
son más caros de alojar que los Linux. Además usar SQL Server (la elección
natural para .NET) también es bastante más caro que elegir PostgreSQL o MySQL.
PYTHON
Python para la web es sinónimo de Django.
Django apareció en 2005 como framework para la creación de sitios web de
contenidos dinámicos, y, si eso es lo que hay que hacer, puede ser una
excelente elección. Python es un lenguaje interpretado, no usa bytecodes como
Java, y aunque existen versiones de Python que pueden correr sobre JVM yo no
conozco a nadie que las use en producción. El tipado dinámico y los tipos de
alto nivel hacen que el código Python sea más corto que Java. Como RoR, Django
incluye un subsistema MVC (aunque algo ecléctico) y también mapeador
objeto-relacional, un sistema extensible de plantillas basado en etiquetas, un
despachador de URLs basado en expresiones regulares y middleware para cacheo, compresión
de la salida, normalización de URLs, protección Cross-Site Request Forgery
(CSRF) y soporte de sesiones. Lo normal es ejecutar Python con el mod_python de
Apache 2. Aunque gracias al soporte WSGI se puede correr también sobre
Lighttpd. En general es de esperar que el rendimiento de Python sea inferior al
de Java y, por consiguiente, ello puede ser un obstáculo si se pretende llevar
el tráfico hasta el límite. Algunos sitios web de alto tráfico como Instagram o
Pinterest están desarrollados con Django, aunque ellos mismos han reconocido
que tuvieron problemas con la escalabilidad debido a su vertiginoso
crecimiento, no sólo por Python sino también en gran parte por llegar al límite
de las tecnologías de almacenamiento de datos. My experiencia personal con
Python/Django es que es muy bueno como como “lenguaje pegamento”, es como un
“Perl con esteroides”, pero no es tan bueno como lenguaje para una plataforma,
porque permite programar muy sucio y porque es fácil embarullar la capa del
Controlador en el MVC de Django. Python es relativamente sencillo de aprender,
y a la mayoría de los programadores profesionales les gusta cuando llegan a
conocerlo, pero, debido a que existe menos demanda de programadores Python que
de Java, .NET o PHP estos son más difíciles de encontrar.
RUBY
ON RAILS
Ningún framework de los anteriores levanta
tantas pasiones a favor y en contra que Ruby On Rails. Como Django, RoR es un
framework que se pensó desde el principio para el diseño de aplicaciones web.
Es un framework de pila completa, lo que significa que trata de integrarlo todo
desde la base de datos hasta el código que corre en el navegador cliente. RoR
incorpora de serie el paradigma MVC, el mapeo objeto-relacional,
infraestructura para crear recursos REST y otras funcionalidades propias del
desarrollo web como un detector de inyección de JavaScript y SQL. RoR también
incorpora JQuery, y se pueden conseguir herramientas de terceros como Aptana
para el desarrollo de las páginas HTML5. Los críticos de RoR argumentan que es
lento y que no escala bien en webfarms. Es cierto que las sesiones sólo se
pueden compartir en Ruby a través de la base de datos. Pero es que yo soy
partidario de que las aplicaciones no deben mantener nada en una sesión de lado
servidor sino que se deben usar cookies para mantener las credenciales del
usuario y luego cachear el resto. El sitio web más grande basado en RoR
probablemente es Twitter. Otra crítica común es que, debido a la integración
transparente entre el lenguage y la base de datos, no se puede usar Ruby
fácilmente contra un modelo de datos que ya esté creado o siga unas normas de
programación del estilo de sólo poder acceder a la información vía
procedimientos almacenados, o, más bien, sí se puede, pero entonces se le mata
la magia de ActiveRecord al lenguaje. Ruby es relativamente fácil de aprender,
más o menos como PHP sólo que la documentación de Ruby no es tan extensa ni
detallada. Hay muchos menos programadores de Ruby que de Java o de PHP. Sus
defensores argumentan que los programadores de Ruby son pocos porque son todos
unos gurús, mas creo que leyendo este artículo ya se sabe lo que opino de los
gurús.
TECNOLOGÍAS
FRONT-END
La compatibilidad entre navegadores web ha
sido desde siempre una merienda de negros y con la llegada de HTML5 y CSS3 la
situación no ha mejorado para nada. La oveja negra es Internet Explorer sobre
todo las versiones anteriores a la 10. Es virtualmente imposible desarrollar
una aplicación HTML5 cross-browser sin una librería de compatibilidad como
Modernizr. CSS también tiene tantas sutiles diferencias que prácticamente nadie
desarrolla sin un paraguas como YUI. Y para el desarrollo en JavaScript es
totalmente común encontrar JQuery o Dojo. Existen decenas de otras librerías
como Bootstrap, Backbone, CoffeeScript, Datejs, RequireJS, PhantomJS, etc. O
frameworks como Ext.js. Incluso se puede desarrollar en Java Swing y
convertirlo a JavaScript con GWT o, aún más exótico, desarrollar en Dart y
compilarlo a JavaScript. Una herramienta muy útil para componer CSS es LESS aunque
hay que precompilar siempre los scripts puesto que a Rhino le puede costar 2
segundos compilar un archivo .less de ~30Kb lo cual es un tiempo muy
significativo en la carga de una página web.
CONCLUSIÓNES
–
Ninguna
plataforma es óptima para todas las necesidades. Para concluir con algunas
reglas sencillas, mi propuesta es la siguiente:
–
Si tienes
que desarrollar un sitio web para una multinacional, o hacer integraciones
complejas con otras plataformas o realmente vas a crecer mucho tanto en tráfico
como en número de desarrolladores, entonces elige Java sobre PostgreSQL.
–
Si
quieres tener presencia online eficaz y asequible, incluso e-commerce, pero tu
website no es el factor crítico exclusivo de tu negocio, entonces elige LAMP.
–
Si tienes
que desarrollar una intranet o un sitio web corporativo a sabiendas de que los
usuarios tendrán Internet Explorer y tecnologías Microsoft entonces elige .NET
sobre SQL Server
–
Si
necesitas una web con contenidos dinámicos mantenida por un equipo compacto y
eficiente de programadores entonces elige Django sobre PostgreSQL o RoR sobre
MySQL.
REFERENCIAS
–
MONTORO,
Sergio, “pastilla roja” octubre 2013.
–
GONZÁLEZ, Javier A, Presidente Rama IEEE Universidad
Pedagógica y Tecnológica de Colombia
2002
http://aulavirtual.tecnologicocomfenalcovirtual.edu.co/aulavirtual/mod/resource/view.php?id=31881
ELABORADO POR:
Shirley Sanchez
Ingeniera de
Sistemas (formación)
FUNDACION
UNIVERSITARIA SAN MARTIN
