Como les va a la gente ? En esta ocasión me gustaría avanzar por encima de las herramientas que componen mi entorno de trabajo desde otro tópico. Las llamadas plataformas de desarrollo web es una frase amplia y divergente.
Y es amplia porque las alternativas para elegir en que trabajar es numerosa. No solo se trata del lenguaje que utilizas sino a su vez en como aplicaste ese lenguaje al producto final.
Hay tecnologías muy diversas por delante de un solo lenguaje en concreto. Y esta es la parte cosmologica del asunto, cada día hay mas alternativas y mas grupos de desarrolladores contribuyendo a su desarrollo y utilizándolas. Esto en ocasiones para el iniciado autodidacta suele ser un dolor de cabeza, porque en rigor lo que él necesita sencillez para llenar conceptos y luego propagar esos conceptos a lo que esta utilizando. Y esta diversidad provoca mucha confusion
Para ir mas adelantes necesito asegurarme que conozcan como funciona un sitio web. El concepto es bastante simple, una maquina se comunica con otra, es la base de Internet ¿no?.
Ok, para el caso de un sitio hay una maquina que se denomina servidor y otra que se denomina cliente. Son denominaciones, podría tratarse de la misma maquina física que estuviese cumpliendo ambos roles. Pero para que sea mas claro el ejemplo se las diagrama por separado:
El servidor, aloja el servicio (valga la redundancia) y el cliente es el que lo pide y lo consume, ..como en la vida misma. En este caso el sitio web alojado dentro del servidor hace el papel de servicio y comúnmente el navegador corriendo en la maquina hace de cliente.
Bien, en resumen y a grandes rasgos son 2 computadoras que se comunican, la pregunta que burbujea en tu mente es: - ¿y como se comunican? -
Bueno ... se comunican mediante protocolos, se les llama asi porque hay toda una serie de datos que se envían y se reciben que no aluden importancia a los datos que en verdad se intentan comunicar ¿soy claro?.
Paso a un ejemplo cotidiano, ahora no veo que no se acostumbra pero hace un tiempo atrás, cuando entrabas a algún lugar o te encontrabas con otra persona que ya se encontraba allí en el punto de encuentro... se saludaba. Si señor ... se saludaba y si ibas a la casa de un desconocido a pedirle algo, saludabas y te presentabas: Buenas tardes !! me llamo Cacho Paparulo y vengo a pedirle si me puede prestar la cortadora de césped. Lo que necesitaba Cacho era la maquina de cortar césped. El núcleo de todo eso era esa maquina, pero por una cuestión protocolar: saluda, se identifica, pide la maquina y posteriormente agradece cuando la recibe y se despide.
Como las maquinas no perdieron su educación con el paso de las generaciones, cuando se comunican pasa algo equivalente, se saludan, se identifican, solicitan lo que necesitan recibir o entregar, se les contesta si es posible entregar/recibir lo que solicitaron que de serlo se hace la entrega ahí mismo, y se despiden. En resumen los protocolos consiguen entablar un hilo de conversación entre 2 maquinas para transferirse los datos que desean.
Los protocolos tienen nombres y actúan en conjunto, debido a que cuando 2 maquinas se comunican no suelen hacerlo de forma 100% directa, sino mas bien los datos van del punto A al B pasando por varios puntos intermedio cual trenes en estaciones. De modo que para que estas 2 maquinas que se intentan comunicar consigan hacerlo necesitan iniciar (al menos) 2 protocolos: el protocolo TCP y el protocolo IP conforman el conjunto TCP/IP. Tambien podria tratarce del protocolo UDP pero este no viene al caso
Los protocolos TCP/IP
El primero, TCP Transmission Control Protocol: Como su nombre lo indica este protocolo vela porque los datos sean entregados a destino, en un orden determinado y a un puerto determinado y a su vez se encuentra a la escucha del éxito o el fracaso de esta operación. El otro que actúa en conjunto con este se llama IP
Internet Protocol que por su parte se encarga de determinar a donde y desde donde se intenta comunicar. El a donde es una dirección que se le llama dirección IP, que en su versión mas simple es un conjunto de 4 números enteros que van del 0 al 255 xxx.xxx.xxx.xxx y en su versión mas reciente es un conjunto de 4 números hexadecimales que van del 0 al FFFF.
Cuando estos 2 consiguen entablar una linea de comunicacion entra en rigor un protocolo que de seguro les suena bastante, es el protocolo que se encarga de transferir el documento que en el navegador se aprecia como una "pagina web" este protocolo se llama:
HTTPS (HyperText Transfer Protocol Sequre)
Si nos enfocamos en las cuatro primeras palabras se traduce Protocolo de transferencia de Hipertexto. Resalto a Sequre porque con el tiempo se le añadió a la conexión que establece el protocolo una capa de seguridad llamada SSL Sequre Socket Layer que es amplio de explicar pero para hacerla corta: Encripta los datos que se transmiten entre el servidor y el cliente para que nada que intervenga dicha transmisión sea capaz de interpretarlos.
Este protocolo se comunica por defecto y por estándar mediante el puerto 80 de modo que con solo poner la dirección ip del servidor este asumirá que intentas solicitar vía http una pagina que sirve desde el puerto 80. Pega esta dirección en tu navegador http://64.233.186.94/ y en efecto entras a google. - ¿Y como sabe mi navegador que google.com.ar es esa dirección ip ? - Bueno eso es posible gracias a los llamados nombres de dominio Hay un tipo particular de servidores llamados servidores DNS y en su interior se encuentran registrados todos los nombres de dominio y sus referentes ip's cuando ingresas taringa.net el navegador consigue comunicarse con uno de estos servidores y este le provee de la ip por la que podes acceder a los servidores de taringa.
Para este punto te debes estar tentando en comentar un NO LEÍ UN CARAJO preguntándote - ¿ y eso necesito saber para desarrollar un sitio web ? - Para tu desgracia si, y muchísimo mas. Es mas, las plataformas modernas de desarrollo asumen que ya sabes todo esto y te proveen de componentes para sacarle provecho al máximo. De modo que si no concebís como www.portaldechacho.com.ar consiguió convertirse en en un sitio frente a tus ojos. Esto te va a superar en grande.
Ahora si, entendido esto podemos pasar a algo que va mas a la realización del sitio, ya hablamos de que protocolos intervienen en la transmisión de un sitio ahora pasemos a grueso modo a que plataformas intervienen en la ejecución de uno. Podríamos afirmar que el sitio como aplicación tiene vida en 2 lugares que en la jerga de este oficio se los conoce como backend y frontend. Backend es la parte de la aplicación que esta corre en el servidor y Frontend es la parte de la aplicación que corre en el cliente.
Para que un servidor aloje un sitio es necesario que un conjunto de componentes este instalados y configurados:
El navegador le envía una solicitud http al servidor, pero alguien la tiene que escuchar del otro lado y ese quien la escucha es el sr. apache se encarga de recibir la solicitud y vincularla a un recurso de la aplicación como puede ser un archivo o una acción de un interprete. La historia corta es que sin algo como apache o similar no es posible correr de forma autónoma un servidor web. Si es posible correr un servidor web de forma delegada de varias maneras dependiendo del interprete pero eso lo vamos a ver mas adelante.
Hay un numero reducido de alternativas frente a apache y algunas son algo mas rápidas que este como lo es nginx (que cada día se vuelve mas popular). Pero apache es el mas peronista de todos y al ser así uno se ve obligado a trabajar con lo que es mas difundido en el mercado.
Las aplicaciones web modernas separan los datos del resto de la aplicación y lo consiguen mediante bases de datos, este termino es abreviado comúnmente como db o database, son servicios que de diferentes maneras alojan datos del sitio, esto lo puede hacer mediante diferentes plataformas, las mas conocidas son de la familia de:
SQL Structured Query Language
Ya llevan varias décadas con nosotros y son varias plataformas libres pero la mas popular en materia de desarrollo web es MySQL, actualmente también se puede encontrar como MariaDB y esto es porque a partir de la versión 5.1 de MySQL la empresa que lo desarrollo (oracle) decidió vender MySQL a Sun MicroSystem. Pero la persona que mas contribuyo al desarrollo de mysql decidió bifurcar una versión de mysql que continuase siendo open source ahora conocida como MariaDB. Les explico este cuento porque van a encontrarse con este contraste de nombres y merece la pena entender porque y que se diferencian.
Persisten excelentes alternativas a MySQL como lo son PostgreSQL y Firebird por mencionar algunas de las mas conocidas. Pero en definitiva lo importante a resaltar acá es que este tipo de herramientas están destinadas a guardar/recuperar los datos de un sistema de una manera muy precisa y pertinente.
NoSQL
Si bien existen, herramientas basadas en SQL, estas principalmente están destinadas al alojamiento de los datos en disco y eso es lo que hacen todo el tiempo: escriben y recuperan los datos del disco, un proceso que para un producto de gran escala es muy costoso en materia de desempeño.
En los sitios web de vanguardia los usuarios interactuán en "la nube", seguro lo escuchan todo el tiempo. Aplicaciones en tiempo real, los usuarios disparan un evento que se reflejan en la experiencia de otros usuarios que los siguen etc etc. Este tipo de características no se pueden estimar de manera satisfactoria si se derrocha tiempo escribiendo y luego recuperando nuevamente esos mismos los datos en disco. De ahí surgió la necesidad de crear bases de datos en memoria: el concepto radica en guardar los datos en estructuras simples, referenciabes y faciles de escalar ... en memoria. Existen muchas herramientas para trabajar bajo este nuevo paradigma (cada vez hay más, se cebaron mal con el tema). Las que mas se mencionan son: CouchDB, MongoDB, Redis y CodernityDB
Cabe destacar que este tipo de ideas están en constante brote por lo que no te tendria que desconcertar si mañana te encontras con otra alternativa a las anteriormente mencionadas.
Las 2 mas aclamadas hasta el momento resultan ser MongoDB y Redis y no es por casualidad Mongo representa muy bien los datos en un formato ampliamente utilizado llamado JSON y Redis aplica tipos de colecciones de datos sumamente simples como hashs y tuplas.
En fin, las aplicaciones que se le dan a esta nueva estirpe de bases de datos cada vez son mas interesantes.
Otra cosa a destacar es que es que es bastante probable que no necesites de este tipo de base de datos en el circulo de demanda actual de desarrollo de sitios por la simple razón de que muy pocos clientes te piden una plataforma interactiva que justifique su uso. Aun así no esta de mas que sepas de su existencia y vayas aprendiendo poco a poco sobre ellas.
Me costo titular esta sección, lenguaje de backend es lo que me pareció mas apropiado pero la realidad es que me cuesta catalogar a que me estoy refiriendo. Es tremendo, cuando uno inicia un post arranca con la arrogancia de querer explicarle algo a los demás y a mitad de camino cae en la cuenta que no sabe un choto de lo que esta utilizando. En fin, los lenguajes de backend son los lenguajes que se encargan de llevar a acabo las operaciones pertinentes a la aplicación web del lado del servidor algunos ni siquiera requieren una plataforma de web service como apache o bien se podría decir que son capaces de sostener su propio web servicie. Este tipo de variaciones son la que provocan la nebulosa de conceptos que confunden al iniciado y es por la gran cebolla de componentes que intervienen en el backend que dependiendo de la plataforma que uno utilice se puede encontrar con diferentes arquitecturas para soportar: la manipulación de una solicitud http, la interacción con la base de datos, generar el hipertexto de la respuesta y varias cosas mas se demandan "allá arriba". Pero en amplio modo el lenguaje de backend son lenguajes de alto nivel la mayoría de scripting (no compilados sino intepretados) que se emplean para desarrollar el núcleo del backend. Son en virtud lenguajes de procesamiento, algunos son mas populares y otros menos, algunos presentan ventajas en algunos aspectos y dificultades en otros. Pero reconozco una lista de los 5 mas recurridos en la actualidad:
PHP
En el mundo del software libre los acronismos recursivos son el sello friki de los ingeniosos: GNU (GNU is Not Unix) y acá lo tenemos a PHP (PHP Hypertext Pre-processor). En fin, un lenguaje procesador de hypertexto. Una historieta sintética al origen de este lenguaje fue que en las primera décadas de gestación del orden de tecnologías para el desarrollo de sitios web los sitios se programaban con lenguajes como C, Perl (y en la actualiza se sigue haciendo cuando la necesidad lo demanda). En su momento Perl dominaba el mercado y a un conjunto de desarrolladores se les ocurrió escribir un modulo en C que fuera compatible con perl para un manejo mas versátil del CGI y para hacerla corta ese modulo evoluciono paulatinamente con el correr de los años hasta convertirse en lo que hoy conocemos como PHP. Un lenguaje completamente robusto al que se lo destina a muchos propósitos mas que al simple proceso de hipertexto.
Su versión actual es la 5.5 y la mayoría de los servicios de hosting cuentan con este interprete en varias versiones a elección con el fin de ser compatibles con la aplicación que queres alojar en ellos. Se lo puede considerar como un estándar en el desarrollo web (si hay alguno xD) debido a su popularidad. Tiene una curva de aprendizaje suave, con muy pocos o ningún conocimiento de programación podes iniciarte en el desarrollo web con este lenguaje.
No recomiendo para nada tomar ninguna distancia de este lenguaje ya que tarde o temprano uno termina necesitando de él. Hace mucho que dejo de ser un lenguaje de mi preferencia y aun así, si me toca iniciar un proyecto tengo casi garantizado que el cliente ya quiso empezar el proyecto por su cuenta con wordpress, joomla o algún otro CMS que al estar hechos en PHP el cliente ya contratado un hosting que solo soporta PHP.
Ruby
A diferencia de PHP, ruby es un lenguaje que desde sus inicios apunto al multiproposito, es decir se lo diseño para poder llevar a cabo diversas tareas de programación no solamente desarrollo web y en efecto se usa exitosamente para muchas cosas.
Su estabilidad entre versiones de su interprete promovió su uso en diversas soluciones: Tuneles de red, kernels para el manejo de archivos y drivers por poner algunos ejemplos.
Su integración como herramienta para el desarrollo web fue cuando se implemento un tipo de arquitectura que se venia usando en otro lenguaje llamado Smalltak. Dicha arquitectura se llama MCV que hasta el momento no se conocía abiertamente como un medio para facilitar el desarrollo web. El producto final de unir MVC y Ruby fue un framework llamado Ruby On Rails. Esto revoluciono la industria de tal modo que de repente PHP, ASP y los demás lenguajes que en ese momento abarcaban el mercado espesaron a sacar frameworks que utilizaran esta arquitectura y ademas otros lenguajes que ni siquiera se encontraban en el mercado florecieron con su framework MVC particular.
Pero MVC no es la única razón por la que ruby se hizo popular, sucede que pertenece a una generación de plataformas mas humanistas (si quiere y vale el termino). Pasa que un programador pasa mas tiempo leyendo su código que escribiéndolo y es por eso que se pensó en ruby como un lenguaje mas simple de leer que promueva buenas practicas de programación y con una sintaxis minimalista y que facilite construir apps en distintos paradigmas. Tomando las virtudes de otros lenguajes como tipado dinámico, asignacion al vuelo, gran manejo de secuencias, crear subclases de objetos base y varias cosas mas. En resumen es una tremenda alternativa a PHP.
Java
Bueno es muy poco lo que puedo decir de java, en realidad no lo uso nunca, tengo 0 experiencia acumulada y la verdad no es uno de mis preferidos. Pero si hay un lenguaje que te enseña buenas costumbres es este podría decirse que al igual que C++ y C#, java cría buenos programadores.
No se como explicarlo bien, pero todas las app de java que he chusmiado están muy bien escaladas. Sus características son la que lo hacen capaz de un desarrollo plano. Su mayor virtud es su empaquetamiento multiplataforma: se compila y se comunica con el hardware mediante una maquina virtual. Y eso son 2 características que le provocaron una erección a los desarrolladores de software privativo: Producir algo que sea fácilmente transportable a distintas plataformas con un bajo costo de mantenimiento y que a su vez este compilado dificultando asi el acceso al código fuente. Y eso por eso que ves java hasta en las maquinas de cortar pasto.
Así mismo una plataforma con esta ventajas lo hacen muy útil también cuando el cliente quiere migrar de hosting, mientras el hosting tenga una maquina virtual de java. Todas las dependencias se van a encontrar empaquetadas en una sola aplicación. Ebay es uno de los grandes ejemplos del alcance de java.
Node.js
JavaScript del lado el servidor o.O Fui testigo del surgimiento de esta idea y mi primera reacción fue de asombro y desconcierto porque javascript era el lenguaje del frontend y no se suponia que fuese a terminar en el backend. Admito que fui uno de los escépticos que no creyó que una cosa asi pudiese funcionar pero claro, era un pendejo ignorante y corto de mente.
La realidad actual es que es una de las alternativas mas aclamadas por haber unificado el desarrollo web y no hablo de tener el mismo lenguaje de backend que de frontend sino de que todos los desarrolladores web manejan en menor o mayor medida javascript. Por lo que la interacción, las propuestas ... los proyectos que se desencadenaron fue uno mas extraordinario que el otro. La cuestión es que en su corto tiempo de vida, Node a promovido frameworks, gestores de paquetes y hasta editores.
Es una plataforma que emplea V8, un motor de javascript que desarrolló y mantiene google, que para tratarse de javascript es ... muy veloz. Como resultado, Node a posibilitado una interacción cliente/servidor mas diversa. Tal es así que no me encuentro capacitado para especificales con lujo de detalle cuales son ese tipo de interacciones. Pero se parlotea mucho en los foros de desencadenar eventos dentro del servidor, serializar objetos con jsonp via websockets o ajax, y varias cosas mas.
En conclusion, le dio un nuevo matiz a las posibilidades de desarrollo web y vino para quedarse.
Python
Anteriormente les hable de ruby un lenguaje con una sintaxis simple de leer que se parece a pseudocodigo, fuertemente tipado etc etc. Bueno, python es la misma historieta, se parecen mucho ruby y python ... presentan las mismas ventajas y todo. Se desarrollaron con los mismos propositos ... son como hermanitos.
Y por ahi se arma debate que si ruby que si python. Y en mi cabeza medito, ¿ si se parecen tanto que cuesta aprenderlos a los 2 ?. Sin lugar a dudas va a haber situaciones en la que nos encontremos con la necesidad de usar ruby y otras en las que sea necesario usar python.
En lo particular, conozco mucho mas python que ruby y por ende lo uso mas... - si, es un circulo vicioso -.
Conozco mas alternativas para el desarrollo web con python: django, web2py, flask, tornado, web.py, cherrypy, pyramid. Ese ultimo esta moooi piola quizá mas adelante hable mas sobre él.
En fin, es el lenguaje con el que disfruto mas programar, siempre que puedo me pongo a ver algún manual o a ver alguna charla de la pycon (una conferencia de python con cede en varios paises)
Eso a grandes rasgos concluye las alternativas de lenguajes de backend, existen algunas mas pero que a mi modo de ver no son "alternativas" es decir, no tienen mas pertinencia en la industria. Como es el caso de ASP, C++ o .Net . Es muy bajo el numero de empresas y freelancers que se aventuran a desarrollar el backend con estas herramientas y por ende las excluí del post. Pero existen y en el caso de C++ y .Net tienen mucho mas impacto en otro tipo de software y aplicaciones.
Ahora pasando al otro lado de la zona (... mi cabe-zo..no no da ) de trabajo el Frontend nos encontramos con un numero limitado o mas bien fijo herramientas con la cual trabajar.
HTML HyperText Markup Language
Mehh, si en algún momento de tu sus vidas les despertó un mínimo interés en desarrollo web, indudablemente ya están mas o menos enterados de que es html y para que se usa. Para su desgracia es necesario para el propósito del post que detalle minimamente de que se trata.
Jeje mas de una vez leí entre comentarios: html no es un lenguaje. Me apena leer esas cosas porque refleja la falta de criterio al determinar lo que es un lenguaje de programación, se entiende que para que cumpla con dicha definicion, tiene que ser texto en función de código que representa instrucciones de mediano/alto nivel para el hardware de una maquina. Y es eso precisamente lo que hace html, mas allá de pasar por una serie de interpretaciones por parte del navegador en ultima instancia este ultimo le solicita al hardware que lleve a cavo operaciones que se manifiestan en pantalla.
Los lenguajes de marcado como su categorizacion lo indica, se valen de marcas, palabras claves que facilitan el proceso o separación de los datos en conjuntos para ser destinados a operaciones especificas. De este modo html le dice al navegador si debe generar una casilla de texto, un párrafo, una letra resaltada o subrayada etc etc.
Una cosa que vale la pena destacar y que se cumple con el resto de componentes que al igual que html juegan un papel principal en el frontend es que no funcionan de la misma manera en todos los navegadores. Y es importante saber esto de entrada porque no es lo esperado para un iniciado.
La primera exclamacion cuando uno escribe su primer index.html es - uhh esto es facil, no puedo esperar a mostrarselo a Pepito - y despues Pepito cuando lo abre en su navegador preferido exclama - macho, el menú de arriba te sale todo choto - El iniciado indujo que se iba a ver igual en FireFox que Chrome así como Internet Explorer u Opera. Pero no es asi, cada navegador interpreta las etiquetas de la misma manera, un párrafo es un párrafo para todos los navegadores pero no generan un párrafo de la misma manera, algunos lo hacen con 4 px de interlineado otros con 3 px. Y mas aun, tratándose del mismo navegador puede variar los elementos html que es capaz de soportar dependiendo si una versión u otra del navegador. Un ejemplo claro es que en la actualidad un navegador soporta un selector de fechas con un calendario muy lindo, pero versiones mas viejas no lo hacen.
Este tipo de problemas o desafíos se los cataloga en el grupo de programación cross-browser. Que implica que tu sitio, tiene que tener parcheado la mayor cantidad de variaciones entre los navegadores que sea concebible. Por supuesto este tipo de cosas no se aplica a versiones muy viejas de navegadores.
Es completamente injustificado en el 2014 escribir html que soporte Internet Explorer 6. Hay que dejar el pasado en el pasado e ir desechando lo mas viejo y preparandose para integrarse a lo nuevo. Pero es todo un proceso paulatino, año a año una version vieja de un navegador va quedando mas afuera del segmento de compatibilidad tolerable.
Teniendo en cuenta lo dicho anteriormente, es muchísimo lo que se tiene que tener en cuenta al momento de desarrollar con html, es todo un desafió mantenerse actualizado y a la vez respetar un estándar de compatibilidad. Parece un caos y crease o no, hay un organismo que intenta mantener el orden que es la w3c un consorcio que define los estándar de compatibilidad que deben de respetar los navegadores al momento de sacar un motor que soporte html. Y esto es algo que les puede llegar a sorprender: muchos de los navegadores mas usados y mas aclamados, se pasan por el forro ese estándar en muchas ocasiones y sacan un chiche nuevo de la galera que no lo soporta ninguno de sus competidores o versiones anteriores de html. Pero bue, es como la pólvora que mueve montañas. Este tipo de comportamiento a promovido poco a poco el cambio.
CSS Cascade Style Sheet
Las hojas de estilo en cascada ... si señor. Como vengo contando la historia larga de las herramientas de desarrollo ya se harán una idea que tampoco voy a ser breve al momento de contarles sobre css.
Recuperando lo antes dicho sobre html, css también tiene sus inconvenientes al trabajar con diferentes navegadores o versiones de los mismos. Pero no se queda ahi, a su vez también presenta sus inconvenientes (al igual que html) al intentar ser escribir un código simple y fácil de mantener. Al inicio la implementacion de css parece sencilla pero luego de ampliarnos en detalles y empezar a elaborar sitios con un estilo mas complejo nos encontramos en toda una maraña repetitiva. En conclusion css es mas difícil de lo que parece.
Pasa que cuando se pensó en css no se lo hizo para el programador entusiasta e iniciado. Como muchas otras herramientas de desarrollo se pensó para que la usaran arquitectos de software e ingenieros, gente que de antemano sabe lo que esta haciendo. De modo que no es para desanimarse si a la mitad de tu trabajo caes en la cuenta que tus hojas de estilo son un quilombo monumental.
La realidad es que mas probable que te cruces con una ballena blanca que con un programador que sabe escribir hojas de estilo realmente eficientes. En particular, jamas quede satisfecho con ninguna de las hojas de estilo que he compuesto: siempre que las reviso después de mucho tiempo infiero que puede haberlas escrito de una manera mas sintética, menos redundante, mas escalables.
Afortunadamente hay solución. Hace muy poco tiempo paciando por la red di con un manual escrito por uno de los antiguos maquetadores de yahoo. La idea del señor es modular en 5 capas las hojas de estilo para que jamas ... jamas tengas problemas para modíficarlas o escalarlas. Naaa, no acostumbren a decir "jamas" y menos en el mundo de la informática. Aun así la propuesta es interesante. Acá esta el manual http://smacss.com/book/ si googlean un poco pueden conseguir la versión en pdf.
Les cuanto un poco como viene la mano, el tipo explora la posibilidad de iniciar con un conjunto de reglas base en un modulo, avanzar a otro con un conjunto de reglas de envoltura, a otro que se aplique a pequeños bloques llamado módulos, luego avanzar a los temas y los estados por separado. Es bastante interesante, les recomiendo que lo miren.
JavaScript
El sr. Js, uno de los muchos que nos enseño a exclamar: porque no anda esta v#$%= !!.
Y no es para menos, es un lenguaje con características muy particulares, robusto en su concepto pero que presenta problemas en la practica. Pero admitamoslo, su entorno no es el mas jovial, el pobre no sabe a donde va a ir a parar. Fue pensado para poder correr en cualquier navegador que lo soportara y la pucha que se las juega para cumplir con su cometido. Pero como explique antes, los conflictos de cross-browser salieron al acecho ocasionando un rechinar de dientes importante entre los desarrolladores.
La realidad es que javascript esta pensado para funcionar sea como sea y si el desarrollador lo sabe usar lo recompensa con altas cuotas de experiencia día a día. Pero claro, si intenta trabajar sin saber depurar con él, sin saber como manejar el log, si no se es consciente que diferencias habitan en diferentes navegadores. Es una receta para el desastre.
JS tiene un conjunto de tipos bien reducido, un árbol de objetos heredados, un novedoso paradigma de programación mediante prototipos y programación funcional. Se puede hacer un gran numero de cosas con los objetos. Tiene un manejo de argumentos que esta genial. Podes operar con objetos indefinidos. Un tremendo manejo de ámbito de nombres de variables. Y como toda buena herramienta un colmenar de librerías y frameworks para poder implementar respaldados a su vez por una comunidad muy numerosa.
Hay muchos manuales que enseñan a trabajar muy bien con js, algunos dedicados exclusivamente al lenguaje y otros dedicados al desarrollo web en general. A como manipular el DOM, a como normalizar los objetos mas utilizados, cuales son sus principales objetos y como se distribuyen. Entre ellos esta, Javascript Cookbook y también Javascript Enlightenment. El primero para explorar las características, con muchísimas recetas practicas y el otro para aprender como funciona en profundidad.
Luego de que uno se pone canchero ya con esos 2, gana un poco de experiencia trabajando en proyectos reales y se machaca a lo lindo puede pasar a 2 que son un tanto mas interesantes que ya no hablan de entender como funciona sino que exploran las buenas practicas: uno es Javascript The Good Parts y el otro es Learning Javascript Design Patterns. Confio ampliamente que no se van a arrepentir de leerlos son muy buenos.
Ok eso es todo por esta vez, como dije voy a hacer una tercera entrega y ahí voy a pasar revista de muchas librerías muy útiles para trabajar con estos lenguajes y plataformas y algunas otras pueeede ser que no se las hayan cruzado.
Y es amplia porque las alternativas para elegir en que trabajar es numerosa. No solo se trata del lenguaje que utilizas sino a su vez en como aplicaste ese lenguaje al producto final.
Hay tecnologías muy diversas por delante de un solo lenguaje en concreto. Y esta es la parte cosmologica del asunto, cada día hay mas alternativas y mas grupos de desarrolladores contribuyendo a su desarrollo y utilizándolas. Esto en ocasiones para el iniciado autodidacta suele ser un dolor de cabeza, porque en rigor lo que él necesita sencillez para llenar conceptos y luego propagar esos conceptos a lo que esta utilizando. Y esta diversidad provoca mucha confusion
Como funciona un sitio web
Para ir mas adelantes necesito asegurarme que conozcan como funciona un sitio web. El concepto es bastante simple, una maquina se comunica con otra, es la base de Internet ¿no?.
Ok, para el caso de un sitio hay una maquina que se denomina servidor y otra que se denomina cliente. Son denominaciones, podría tratarse de la misma maquina física que estuviese cumpliendo ambos roles. Pero para que sea mas claro el ejemplo se las diagrama por separado:
El servidor, aloja el servicio (valga la redundancia) y el cliente es el que lo pide y lo consume, ..como en la vida misma. En este caso el sitio web alojado dentro del servidor hace el papel de servicio y comúnmente el navegador corriendo en la maquina hace de cliente.
Bien, en resumen y a grandes rasgos son 2 computadoras que se comunican, la pregunta que burbujea en tu mente es: - ¿y como se comunican? -
Bueno ... se comunican mediante protocolos, se les llama asi porque hay toda una serie de datos que se envían y se reciben que no aluden importancia a los datos que en verdad se intentan comunicar ¿soy claro?.
Paso a un ejemplo cotidiano, ahora no veo que no se acostumbra pero hace un tiempo atrás, cuando entrabas a algún lugar o te encontrabas con otra persona que ya se encontraba allí en el punto de encuentro... se saludaba. Si señor ... se saludaba y si ibas a la casa de un desconocido a pedirle algo, saludabas y te presentabas: Buenas tardes !! me llamo Cacho Paparulo y vengo a pedirle si me puede prestar la cortadora de césped. Lo que necesitaba Cacho era la maquina de cortar césped. El núcleo de todo eso era esa maquina, pero por una cuestión protocolar: saluda, se identifica, pide la maquina y posteriormente agradece cuando la recibe y se despide.
Como las maquinas no perdieron su educación con el paso de las generaciones, cuando se comunican pasa algo equivalente, se saludan, se identifican, solicitan lo que necesitan recibir o entregar, se les contesta si es posible entregar/recibir lo que solicitaron que de serlo se hace la entrega ahí mismo, y se despiden. En resumen los protocolos consiguen entablar un hilo de conversación entre 2 maquinas para transferirse los datos que desean.
Los protocolos tienen nombres y actúan en conjunto, debido a que cuando 2 maquinas se comunican no suelen hacerlo de forma 100% directa, sino mas bien los datos van del punto A al B pasando por varios puntos intermedio cual trenes en estaciones. De modo que para que estas 2 maquinas que se intentan comunicar consigan hacerlo necesitan iniciar (al menos) 2 protocolos: el protocolo TCP y el protocolo IP conforman el conjunto TCP/IP. Tambien podria tratarce del protocolo UDP pero este no viene al caso
Los protocolos TCP/IP
El primero, TCP Transmission Control Protocol: Como su nombre lo indica este protocolo vela porque los datos sean entregados a destino, en un orden determinado y a un puerto determinado y a su vez se encuentra a la escucha del éxito o el fracaso de esta operación. El otro que actúa en conjunto con este se llama IP
Internet Protocol que por su parte se encarga de determinar a donde y desde donde se intenta comunicar. El a donde es una dirección que se le llama dirección IP, que en su versión mas simple es un conjunto de 4 números enteros que van del 0 al 255 xxx.xxx.xxx.xxx y en su versión mas reciente es un conjunto de 4 números hexadecimales que van del 0 al FFFF.
Cuando estos 2 consiguen entablar una linea de comunicacion entra en rigor un protocolo que de seguro les suena bastante, es el protocolo que se encarga de transferir el documento que en el navegador se aprecia como una "pagina web" este protocolo se llama:
HTTPS (HyperText Transfer Protocol Sequre)
Si nos enfocamos en las cuatro primeras palabras se traduce Protocolo de transferencia de Hipertexto. Resalto a Sequre porque con el tiempo se le añadió a la conexión que establece el protocolo una capa de seguridad llamada SSL Sequre Socket Layer que es amplio de explicar pero para hacerla corta: Encripta los datos que se transmiten entre el servidor y el cliente para que nada que intervenga dicha transmisión sea capaz de interpretarlos.
Este protocolo se comunica por defecto y por estándar mediante el puerto 80 de modo que con solo poner la dirección ip del servidor este asumirá que intentas solicitar vía http una pagina que sirve desde el puerto 80. Pega esta dirección en tu navegador http://64.233.186.94/ y en efecto entras a google. - ¿Y como sabe mi navegador que google.com.ar es esa dirección ip ? - Bueno eso es posible gracias a los llamados nombres de dominio Hay un tipo particular de servidores llamados servidores DNS y en su interior se encuentran registrados todos los nombres de dominio y sus referentes ip's cuando ingresas taringa.net el navegador consigue comunicarse con uno de estos servidores y este le provee de la ip por la que podes acceder a los servidores de taringa.
Para este punto te debes estar tentando en comentar un NO LEÍ UN CARAJO preguntándote - ¿ y eso necesito saber para desarrollar un sitio web ? - Para tu desgracia si, y muchísimo mas. Es mas, las plataformas modernas de desarrollo asumen que ya sabes todo esto y te proveen de componentes para sacarle provecho al máximo. De modo que si no concebís como www.portaldechacho.com.ar consiguió convertirse en en un sitio frente a tus ojos. Esto te va a superar en grande.
Ahora si, entendido esto podemos pasar a algo que va mas a la realización del sitio, ya hablamos de que protocolos intervienen en la transmisión de un sitio ahora pasemos a grueso modo a que plataformas intervienen en la ejecución de uno. Podríamos afirmar que el sitio como aplicación tiene vida en 2 lugares que en la jerga de este oficio se los conoce como backend y frontend. Backend es la parte de la aplicación que esta corre en el servidor y Frontend es la parte de la aplicación que corre en el cliente.
Para que un servidor aloje un sitio es necesario que un conjunto de componentes este instalados y configurados:
Apache
El navegador le envía una solicitud http al servidor, pero alguien la tiene que escuchar del otro lado y ese quien la escucha es el sr. apache se encarga de recibir la solicitud y vincularla a un recurso de la aplicación como puede ser un archivo o una acción de un interprete. La historia corta es que sin algo como apache o similar no es posible correr de forma autónoma un servidor web. Si es posible correr un servidor web de forma delegada de varias maneras dependiendo del interprete pero eso lo vamos a ver mas adelante.
Hay un numero reducido de alternativas frente a apache y algunas son algo mas rápidas que este como lo es nginx (que cada día se vuelve mas popular). Pero apache es el mas peronista de todos y al ser así uno se ve obligado a trabajar con lo que es mas difundido en el mercado.
Base de Datos
SQL Structured Query Language
Ya llevan varias décadas con nosotros y son varias plataformas libres pero la mas popular en materia de desarrollo web es MySQL, actualmente también se puede encontrar como MariaDB y esto es porque a partir de la versión 5.1 de MySQL la empresa que lo desarrollo (oracle) decidió vender MySQL a Sun MicroSystem. Pero la persona que mas contribuyo al desarrollo de mysql decidió bifurcar una versión de mysql que continuase siendo open source ahora conocida como MariaDB. Les explico este cuento porque van a encontrarse con este contraste de nombres y merece la pena entender porque y que se diferencian.
Persisten excelentes alternativas a MySQL como lo son PostgreSQL y Firebird por mencionar algunas de las mas conocidas. Pero en definitiva lo importante a resaltar acá es que este tipo de herramientas están destinadas a guardar/recuperar los datos de un sistema de una manera muy precisa y pertinente.
NoSQL
Si bien existen, herramientas basadas en SQL, estas principalmente están destinadas al alojamiento de los datos en disco y eso es lo que hacen todo el tiempo: escriben y recuperan los datos del disco, un proceso que para un producto de gran escala es muy costoso en materia de desempeño.
En los sitios web de vanguardia los usuarios interactuán en "la nube", seguro lo escuchan todo el tiempo. Aplicaciones en tiempo real, los usuarios disparan un evento que se reflejan en la experiencia de otros usuarios que los siguen etc etc. Este tipo de características no se pueden estimar de manera satisfactoria si se derrocha tiempo escribiendo y luego recuperando nuevamente esos mismos los datos en disco. De ahí surgió la necesidad de crear bases de datos en memoria: el concepto radica en guardar los datos en estructuras simples, referenciabes y faciles de escalar ... en memoria. Existen muchas herramientas para trabajar bajo este nuevo paradigma (cada vez hay más, se cebaron mal con el tema). Las que mas se mencionan son: CouchDB, MongoDB, Redis y CodernityDB
Cabe destacar que este tipo de ideas están en constante brote por lo que no te tendria que desconcertar si mañana te encontras con otra alternativa a las anteriormente mencionadas.
Las 2 mas aclamadas hasta el momento resultan ser MongoDB y Redis y no es por casualidad Mongo representa muy bien los datos en un formato ampliamente utilizado llamado JSON y Redis aplica tipos de colecciones de datos sumamente simples como hashs y tuplas.
En fin, las aplicaciones que se le dan a esta nueva estirpe de bases de datos cada vez son mas interesantes.
Otra cosa a destacar es que es que es bastante probable que no necesites de este tipo de base de datos en el circulo de demanda actual de desarrollo de sitios por la simple razón de que muy pocos clientes te piden una plataforma interactiva que justifique su uso. Aun así no esta de mas que sepas de su existencia y vayas aprendiendo poco a poco sobre ellas.
Lenguaje de Backend
Me costo titular esta sección, lenguaje de backend es lo que me pareció mas apropiado pero la realidad es que me cuesta catalogar a que me estoy refiriendo. Es tremendo, cuando uno inicia un post arranca con la arrogancia de querer explicarle algo a los demás y a mitad de camino cae en la cuenta que no sabe un choto de lo que esta utilizando. En fin, los lenguajes de backend son los lenguajes que se encargan de llevar a acabo las operaciones pertinentes a la aplicación web del lado del servidor algunos ni siquiera requieren una plataforma de web service como apache o bien se podría decir que son capaces de sostener su propio web servicie. Este tipo de variaciones son la que provocan la nebulosa de conceptos que confunden al iniciado y es por la gran cebolla de componentes que intervienen en el backend que dependiendo de la plataforma que uno utilice se puede encontrar con diferentes arquitecturas para soportar: la manipulación de una solicitud http, la interacción con la base de datos, generar el hipertexto de la respuesta y varias cosas mas se demandan "allá arriba". Pero en amplio modo el lenguaje de backend son lenguajes de alto nivel la mayoría de scripting (no compilados sino intepretados) que se emplean para desarrollar el núcleo del backend. Son en virtud lenguajes de procesamiento, algunos son mas populares y otros menos, algunos presentan ventajas en algunos aspectos y dificultades en otros. Pero reconozco una lista de los 5 mas recurridos en la actualidad:
PHP
Su versión actual es la 5.5 y la mayoría de los servicios de hosting cuentan con este interprete en varias versiones a elección con el fin de ser compatibles con la aplicación que queres alojar en ellos. Se lo puede considerar como un estándar en el desarrollo web (si hay alguno xD) debido a su popularidad. Tiene una curva de aprendizaje suave, con muy pocos o ningún conocimiento de programación podes iniciarte en el desarrollo web con este lenguaje.
No recomiendo para nada tomar ninguna distancia de este lenguaje ya que tarde o temprano uno termina necesitando de él. Hace mucho que dejo de ser un lenguaje de mi preferencia y aun así, si me toca iniciar un proyecto tengo casi garantizado que el cliente ya quiso empezar el proyecto por su cuenta con wordpress, joomla o algún otro CMS que al estar hechos en PHP el cliente ya contratado un hosting que solo soporta PHP.
Ruby
Su estabilidad entre versiones de su interprete promovió su uso en diversas soluciones: Tuneles de red, kernels para el manejo de archivos y drivers por poner algunos ejemplos.
Su integración como herramienta para el desarrollo web fue cuando se implemento un tipo de arquitectura que se venia usando en otro lenguaje llamado Smalltak. Dicha arquitectura se llama MCV que hasta el momento no se conocía abiertamente como un medio para facilitar el desarrollo web. El producto final de unir MVC y Ruby fue un framework llamado Ruby On Rails. Esto revoluciono la industria de tal modo que de repente PHP, ASP y los demás lenguajes que en ese momento abarcaban el mercado espesaron a sacar frameworks que utilizaran esta arquitectura y ademas otros lenguajes que ni siquiera se encontraban en el mercado florecieron con su framework MVC particular.
Pero MVC no es la única razón por la que ruby se hizo popular, sucede que pertenece a una generación de plataformas mas humanistas (si quiere y vale el termino). Pasa que un programador pasa mas tiempo leyendo su código que escribiéndolo y es por eso que se pensó en ruby como un lenguaje mas simple de leer que promueva buenas practicas de programación y con una sintaxis minimalista y que facilite construir apps en distintos paradigmas. Tomando las virtudes de otros lenguajes como tipado dinámico, asignacion al vuelo, gran manejo de secuencias, crear subclases de objetos base y varias cosas mas. En resumen es una tremenda alternativa a PHP.
Java
Bueno es muy poco lo que puedo decir de java, en realidad no lo uso nunca, tengo 0 experiencia acumulada y la verdad no es uno de mis preferidos. Pero si hay un lenguaje que te enseña buenas costumbres es este podría decirse que al igual que C++ y C#, java cría buenos programadores.
No se como explicarlo bien, pero todas las app de java que he chusmiado están muy bien escaladas. Sus características son la que lo hacen capaz de un desarrollo plano. Su mayor virtud es su empaquetamiento multiplataforma: se compila y se comunica con el hardware mediante una maquina virtual. Y eso son 2 características que le provocaron una erección a los desarrolladores de software privativo: Producir algo que sea fácilmente transportable a distintas plataformas con un bajo costo de mantenimiento y que a su vez este compilado dificultando asi el acceso al código fuente. Y eso por eso que ves java hasta en las maquinas de cortar pasto.
Así mismo una plataforma con esta ventajas lo hacen muy útil también cuando el cliente quiere migrar de hosting, mientras el hosting tenga una maquina virtual de java. Todas las dependencias se van a encontrar empaquetadas en una sola aplicación. Ebay es uno de los grandes ejemplos del alcance de java.
Node.js
La realidad actual es que es una de las alternativas mas aclamadas por haber unificado el desarrollo web y no hablo de tener el mismo lenguaje de backend que de frontend sino de que todos los desarrolladores web manejan en menor o mayor medida javascript. Por lo que la interacción, las propuestas ... los proyectos que se desencadenaron fue uno mas extraordinario que el otro. La cuestión es que en su corto tiempo de vida, Node a promovido frameworks, gestores de paquetes y hasta editores.
Es una plataforma que emplea V8, un motor de javascript que desarrolló y mantiene google, que para tratarse de javascript es ... muy veloz. Como resultado, Node a posibilitado una interacción cliente/servidor mas diversa. Tal es así que no me encuentro capacitado para especificales con lujo de detalle cuales son ese tipo de interacciones. Pero se parlotea mucho en los foros de desencadenar eventos dentro del servidor, serializar objetos con jsonp via websockets o ajax, y varias cosas mas.
En conclusion, le dio un nuevo matiz a las posibilidades de desarrollo web y vino para quedarse.
Python
Anteriormente les hable de ruby un lenguaje con una sintaxis simple de leer que se parece a pseudocodigo, fuertemente tipado etc etc. Bueno, python es la misma historieta, se parecen mucho ruby y python ... presentan las mismas ventajas y todo. Se desarrollaron con los mismos propositos ... son como hermanitos.
Y por ahi se arma debate que si ruby que si python. Y en mi cabeza medito, ¿ si se parecen tanto que cuesta aprenderlos a los 2 ?. Sin lugar a dudas va a haber situaciones en la que nos encontremos con la necesidad de usar ruby y otras en las que sea necesario usar python.
En lo particular, conozco mucho mas python que ruby y por ende lo uso mas... - si, es un circulo vicioso -.
Conozco mas alternativas para el desarrollo web con python: django, web2py, flask, tornado, web.py, cherrypy, pyramid. Ese ultimo esta moooi piola quizá mas adelante hable mas sobre él.
En fin, es el lenguaje con el que disfruto mas programar, siempre que puedo me pongo a ver algún manual o a ver alguna charla de la pycon (una conferencia de python con cede en varios paises)
Eso a grandes rasgos concluye las alternativas de lenguajes de backend, existen algunas mas pero que a mi modo de ver no son "alternativas" es decir, no tienen mas pertinencia en la industria. Como es el caso de ASP, C++ o .Net . Es muy bajo el numero de empresas y freelancers que se aventuran a desarrollar el backend con estas herramientas y por ende las excluí del post. Pero existen y en el caso de C++ y .Net tienen mucho mas impacto en otro tipo de software y aplicaciones.
Lenguajes de Frontend
Ahora pasando al otro lado de la zona (... mi cabe-zo..no no da ) de trabajo el Frontend nos encontramos con un numero limitado o mas bien fijo herramientas con la cual trabajar.
HTML HyperText Markup Language
Mehh, si en algún momento de tu sus vidas les despertó un mínimo interés en desarrollo web, indudablemente ya están mas o menos enterados de que es html y para que se usa. Para su desgracia es necesario para el propósito del post que detalle minimamente de que se trata.
Jeje mas de una vez leí entre comentarios: html no es un lenguaje. Me apena leer esas cosas porque refleja la falta de criterio al determinar lo que es un lenguaje de programación, se entiende que para que cumpla con dicha definicion, tiene que ser texto en función de código que representa instrucciones de mediano/alto nivel para el hardware de una maquina. Y es eso precisamente lo que hace html, mas allá de pasar por una serie de interpretaciones por parte del navegador en ultima instancia este ultimo le solicita al hardware que lleve a cavo operaciones que se manifiestan en pantalla.
Los lenguajes de marcado como su categorizacion lo indica, se valen de marcas, palabras claves que facilitan el proceso o separación de los datos en conjuntos para ser destinados a operaciones especificas. De este modo html le dice al navegador si debe generar una casilla de texto, un párrafo, una letra resaltada o subrayada etc etc.
Una cosa que vale la pena destacar y que se cumple con el resto de componentes que al igual que html juegan un papel principal en el frontend es que no funcionan de la misma manera en todos los navegadores. Y es importante saber esto de entrada porque no es lo esperado para un iniciado.
La primera exclamacion cuando uno escribe su primer index.html es - uhh esto es facil, no puedo esperar a mostrarselo a Pepito - y despues Pepito cuando lo abre en su navegador preferido exclama - macho, el menú de arriba te sale todo choto - El iniciado indujo que se iba a ver igual en FireFox que Chrome así como Internet Explorer u Opera. Pero no es asi, cada navegador interpreta las etiquetas de la misma manera, un párrafo es un párrafo para todos los navegadores pero no generan un párrafo de la misma manera, algunos lo hacen con 4 px de interlineado otros con 3 px. Y mas aun, tratándose del mismo navegador puede variar los elementos html que es capaz de soportar dependiendo si una versión u otra del navegador. Un ejemplo claro es que en la actualidad un navegador soporta un selector de fechas con un calendario muy lindo, pero versiones mas viejas no lo hacen.
Este tipo de problemas o desafíos se los cataloga en el grupo de programación cross-browser. Que implica que tu sitio, tiene que tener parcheado la mayor cantidad de variaciones entre los navegadores que sea concebible. Por supuesto este tipo de cosas no se aplica a versiones muy viejas de navegadores.
Es completamente injustificado en el 2014 escribir html que soporte Internet Explorer 6. Hay que dejar el pasado en el pasado e ir desechando lo mas viejo y preparandose para integrarse a lo nuevo. Pero es todo un proceso paulatino, año a año una version vieja de un navegador va quedando mas afuera del segmento de compatibilidad tolerable.
Teniendo en cuenta lo dicho anteriormente, es muchísimo lo que se tiene que tener en cuenta al momento de desarrollar con html, es todo un desafió mantenerse actualizado y a la vez respetar un estándar de compatibilidad. Parece un caos y crease o no, hay un organismo que intenta mantener el orden que es la w3c un consorcio que define los estándar de compatibilidad que deben de respetar los navegadores al momento de sacar un motor que soporte html. Y esto es algo que les puede llegar a sorprender: muchos de los navegadores mas usados y mas aclamados, se pasan por el forro ese estándar en muchas ocasiones y sacan un chiche nuevo de la galera que no lo soporta ninguno de sus competidores o versiones anteriores de html. Pero bue, es como la pólvora que mueve montañas. Este tipo de comportamiento a promovido poco a poco el cambio.
CSS Cascade Style Sheet
Las hojas de estilo en cascada ... si señor. Como vengo contando la historia larga de las herramientas de desarrollo ya se harán una idea que tampoco voy a ser breve al momento de contarles sobre css.
Recuperando lo antes dicho sobre html, css también tiene sus inconvenientes al trabajar con diferentes navegadores o versiones de los mismos. Pero no se queda ahi, a su vez también presenta sus inconvenientes (al igual que html) al intentar ser escribir un código simple y fácil de mantener. Al inicio la implementacion de css parece sencilla pero luego de ampliarnos en detalles y empezar a elaborar sitios con un estilo mas complejo nos encontramos en toda una maraña repetitiva. En conclusion css es mas difícil de lo que parece.
Pasa que cuando se pensó en css no se lo hizo para el programador entusiasta e iniciado. Como muchas otras herramientas de desarrollo se pensó para que la usaran arquitectos de software e ingenieros, gente que de antemano sabe lo que esta haciendo. De modo que no es para desanimarse si a la mitad de tu trabajo caes en la cuenta que tus hojas de estilo son un quilombo monumental.
La realidad es que mas probable que te cruces con una ballena blanca que con un programador que sabe escribir hojas de estilo realmente eficientes. En particular, jamas quede satisfecho con ninguna de las hojas de estilo que he compuesto: siempre que las reviso después de mucho tiempo infiero que puede haberlas escrito de una manera mas sintética, menos redundante, mas escalables.
Afortunadamente hay solución. Hace muy poco tiempo paciando por la red di con un manual escrito por uno de los antiguos maquetadores de yahoo. La idea del señor es modular en 5 capas las hojas de estilo para que jamas ... jamas tengas problemas para modíficarlas o escalarlas. Naaa, no acostumbren a decir "jamas" y menos en el mundo de la informática. Aun así la propuesta es interesante. Acá esta el manual http://smacss.com/book/ si googlean un poco pueden conseguir la versión en pdf.
Les cuanto un poco como viene la mano, el tipo explora la posibilidad de iniciar con un conjunto de reglas base en un modulo, avanzar a otro con un conjunto de reglas de envoltura, a otro que se aplique a pequeños bloques llamado módulos, luego avanzar a los temas y los estados por separado. Es bastante interesante, les recomiendo que lo miren.
JavaScript
El sr. Js, uno de los muchos que nos enseño a exclamar: porque no anda esta v#$%= !!.
Y no es para menos, es un lenguaje con características muy particulares, robusto en su concepto pero que presenta problemas en la practica. Pero admitamoslo, su entorno no es el mas jovial, el pobre no sabe a donde va a ir a parar. Fue pensado para poder correr en cualquier navegador que lo soportara y la pucha que se las juega para cumplir con su cometido. Pero como explique antes, los conflictos de cross-browser salieron al acecho ocasionando un rechinar de dientes importante entre los desarrolladores.
La realidad es que javascript esta pensado para funcionar sea como sea y si el desarrollador lo sabe usar lo recompensa con altas cuotas de experiencia día a día. Pero claro, si intenta trabajar sin saber depurar con él, sin saber como manejar el log, si no se es consciente que diferencias habitan en diferentes navegadores. Es una receta para el desastre.
JS tiene un conjunto de tipos bien reducido, un árbol de objetos heredados, un novedoso paradigma de programación mediante prototipos y programación funcional. Se puede hacer un gran numero de cosas con los objetos. Tiene un manejo de argumentos que esta genial. Podes operar con objetos indefinidos. Un tremendo manejo de ámbito de nombres de variables. Y como toda buena herramienta un colmenar de librerías y frameworks para poder implementar respaldados a su vez por una comunidad muy numerosa.
Hay muchos manuales que enseñan a trabajar muy bien con js, algunos dedicados exclusivamente al lenguaje y otros dedicados al desarrollo web en general. A como manipular el DOM, a como normalizar los objetos mas utilizados, cuales son sus principales objetos y como se distribuyen. Entre ellos esta, Javascript Cookbook y también Javascript Enlightenment. El primero para explorar las características, con muchísimas recetas practicas y el otro para aprender como funciona en profundidad.
Luego de que uno se pone canchero ya con esos 2, gana un poco de experiencia trabajando en proyectos reales y se machaca a lo lindo puede pasar a 2 que son un tanto mas interesantes que ya no hablan de entender como funciona sino que exploran las buenas practicas: uno es Javascript The Good Parts y el otro es Learning Javascript Design Patterns. Confio ampliamente que no se van a arrepentir de leerlos son muy buenos.
Ok eso es todo por esta vez, como dije voy a hacer una tercera entrega y ahí voy a pasar revista de muchas librerías muy útiles para trabajar con estos lenguajes y plataformas y algunas otras pueeede ser que no se las hayan cruzado.