NOTA: este artículo es una traducción de "Ok.. let me explain: it's going to be Angular 4.0, or simply Angular" de Juri Strumpflohner.

Y a partir de ahora llamémosle solo Angular...

El pasado 8 y 9 de Diciembre de 2016 se celebró el NG-BE, la primera conferencia de Angular en Bélgica. Igor Minar (jefe de desarrollo de Angular) asistió como presentador e hizo algunos anuncios interesantes relacionados con el itinerario de lanzamientos de Angular. Intentad leer todo el artículo hasta el final, hay un par de cosas importantes.

Igor fue extremadamente abierto y transparente sobre las novedades, incluso en su forma de presentarlo. Creó la presentación de forma abierta el día antes de la conferencia:

I'll be conducting a major open source experiment at @ngbeconf tonight at 10pm downstairs in the main room. Come if you want to participate.

— Igor Minar (@IgorMinar) December 8, 2016

Bueno pues aquí va:

¿Por qué Angular 4? ¿Incluso por qué Angular? ¿Qué está pasando aquí?

Angular usa SEMVER

Allá por septiembre de 2016 cuando se lanzó la nueva versión de Angular, el equipo de Angular también anunció que iban a cambiar a Versionado Semántico (SEMVER).

Como su propio nombre indica, el Versionado Semántico consiste en añadir significado al número de las versiones. Esto permite a los desarrolladores no solo razonar ante cualquier subida de versión que se haga, sino incluso permitir que herramientas como NPM lo hagan de forma automática y segura por nosotros.

Una versión semántica incluye tres números:

Cada vez que arregles un bug y liberes, incrementas el último número, si se añade una nueva funcionalidad, se incrementa el segundo número, y cada vez que incorpores un cambio no compatible hacia atrás, que rompe con lo anterior, incrementas el primero.

"Un cambio incompatible sucede cuando como desarrollador y usuario de una biblioteca, tienes que ajustar tu código tras una nueva versión."

¿Y esto que implicaciones tiene para el equipo de Angular? Como con todo software que evoluciona, siempre podrá producir algún cambio incompatible hacia atrás. Por ejemplo, que se produzca un error de compilación debido a bugs existentes que pasaron inadvertidos con la anterior versión del compilador TypeScript, cualquier cosa que pueda romper una aplicación al subir de versión en Angular exige que el equipo de Angular pase al siguiente número de versión, cambiando el primer número.

Para ser claros, como también mencionó Igor en su presentación. Ahora mismo, incluso subiendo de versión de la dependencia de TypeScript de Angular, de v1.8 a v2.1 o v2.2 y compilar Angular con él, técnicamente causaría una incompatibilidad. Así que se están tomando SEMVER muy, muy en serio.

Nota de campusMVP: esto significa que, incluso aunque no haya nada nuevo, si cambian de compilador de TypeScript y esto puede producir algún problema que rompa la aplicación, deberían cambiar la versión. Por ello, por ejemplo, cambiar de una hipotética versión 5 a la 6 no significa necesariamente que haya cambio alguno, aunque a lo mejor sí... Eso significa que habrá que estar muy atentos a cada versión para estar seguros.

¡Los cambios incompatibles no tienen que ser dolorosos!

Las personas que han estado siguiendo a la comunidad de Angular desde hace un tiempo, definitivamente saben de lo que estoy hablando. Pasamos de Angular 1 a Angular 2, y fue un cambio total, con nuevas API's, nuevos patrones. Eso era obvio: al final Angular 2 se ha reprogramado desde cero (aunque hay opciones de migración disponibles).

Cambiar de la versión 2 a la versión 4 ó 5… no será como migrar de Angular 1. No será una re-programación completa, será un simple cambio en algunas de las bibliotecas del núcleo que exigen un cambio principal de versión SEMVER. Además, habrá las correspondientes fases de obsolescencia para permitir que los desarrolladores ajusten su código.

Internamente en Google, el equipo de Angular usa una herramienta para gestionar subidas de versión automáticas, incluso de cambios incompatibles. Esto es algo que todavía requiere una planificación más en detalle, pero el equipo está muy centrado en hacer que esta herramienta esté disponible de forma generalizada, muy probablemente durante este año 2017 justo a tiempo para Angular 5.

Solo "Angular"

Como ya has podido deducir, el término "Angular 2" habrá sido abandonado cuando lleguemos a la versión 4, 5 etc... Dicho esto, debemos empezar a llamarle simplemente "Angular" sin el sufijo de la versión.

Es simplemente Angular

Además, deberíamos empezar a evitar las bibliotecas, GitHub/NPM prefijadas con ng2- o angular2-.

Also, we should start avoiding GitHub/NPM libraries prefixed with ng2- or angular2-.

@toddmotto@manekinekko@jdfwarrior@schwarty but please don't call projects ng2- or angular2-, etc.

— Igor Minar (@IgorMinar) December 10, 2016

Directrices para la nomenclatura

El equipo de Angular ha lanzado directrices oficiales de cómo nombrar bibliotecas, libros y artículos.

Versión corta: usa el nombre "AngularJS" para cualquier versión 1.x , y simplemente "Angular" para cualquier versión 2 o posterior. El objetivo es ser lo más consistente posible, particularmente hacia el futuro, mientras se reduce la carga del mantenimiento causado por las inconsistencias de nomenclaturas del pasado.

Básicamente intenta usar el número de la versión, a no ser que sea totalmente necesario para evitar ambigüedades. Por ejemplo:

• Usa "Angular" para las versiones 2.0.0 y posteriores (por ejemplo, "Soy desarrollador de Angular", "Esto es un MeetUp de Angular", "El ecosistema de Angular crece rápidamente")
• Usa "AngularJS" para describir versiones 1.x o posteriores
• Usa el número de la versión "Angular 4.0" "Angular 2.4" cuando se necesite hacer referencia a una versión concreta (por ejemplo, al hacer referencia a una funcionalidad recién implementada- "Esta es una presentación de la funcionalidad x, introducida Angular 4", "Propongo este cambio para Angular 5"...)
• Usa el semver completo al informar de un bug (por ejemplo, "Este problema existe por ahora hasta Angular 2.3.1")

Además en artículos de blogs, cursos, libros o cuando te refieras a una versión muy en concreto de Angular, considera añadir una linea de cabecera indicando:

Este artículo usa Angular v2.3.1.

Eso te ayudará a evitar confusiones entre tus lectores, especialmente cuando estás escribiendo sobre API's concretas.

¿Por qué no la versión 3?

Las bibliotecas nucleares de Angular están en un único repositorio en github.com/angular/angular. Todas están versionadas de la misma manera, pero distribuidas como diferentes paquetes:

Debido al desajuste que existe en la versión del paquete del enrutador, el equipo decidió ir directamente a por Angular versión 4. De esta forma se vuelve a una situación en la que todos los paquetes del núcleo están alineados, haciendo que todo sea mucho más fácil de mantener y ayuda a evitar confusiones en el futuro.

¿Por qué estaba el enrutador alineado ya en la versión 3? Aquí está el anuncio oficial por parte del equipo de Angular cuando sacaron la versión del enrutador.

Nota de campusMVP: esto prueba una vez más lo mal que lo han hecho en los últimos años en lo que se refiere al versionamiento del producto :-S

También es importante entender cómo se está usando e integrando Angular dentro de Google (Igor habla de esto aquí en su presentación). Todas las aplicaciones de Google usan la versión de Angular correspondiente a la actual rama principal (master) de GitHub del repositorio de Angular. Cada vez que se introduce un nuevo commit en la rama master, se integra en el mono-repositorio gigantesco y único de Google, donde también conviven otros productos como Maps, Adsense, etc... Como consecuencia, todos los proyectos de Google que usan Angular hacen pruebas exhaustivas contra esta nueva versión. Esto hace que el equipo se sienta muy confiado a la hora de distribuir una nueva versión, ya que contiene una idéntica combinación de versiones de paquetes de Angular que ya han sido probados dentro de Google. Por ello, el haber alineado todas las versiones tiene muchísimo sentido y hace más fácil mantenerlas con el tiempo, que a cambio ayuda a que el equipo sea más productivo a la hora de sacar nuevas funcionalidades.

¿Cuándo saldrán nuevas versiones principales?

El calendario de lanzamientos de versiones se puede encontrar en el repo oficial de Angular en Github.

El hecho de que puedan ocurrir cambios incompatibles no quiere decir que ocurran cada dos por tres. El equipo de Angular se ha comprometido a actualizaciones con periodos que ocurren en tres ciclos:

• Parches y solución de bugs cada semana
• 3 versiones pequeñas al mes después de cada versión grande lanzada
• Una versión que cambia el número "grande", con un asistente para migración, cada 6 meses.

Nota de campusMVP: Angular 4 salió el 22 de marzo de 2017. Los cambios han sido mínimos, básicamente:

• A la directiva *If se le ha añadido también un else.
• Asignación de variables locales en las propias directivas

Y nada más. O sea, no hay "breaking changes".

Pero entonces, si no rompe la compatibilidad ¿por qué le han subido la versión? Pues porque Angular lo único que dice es que "de haber breaking changes el cambio sucederá en una versión major" pero puede no ser así. Y este ese uno de esos casos.

¿Entonces a qué se debe el cambio de versión si hay tan pocas novedades? Bueno, para nosotros puede que no haya ninguna novedad pero el nombre que le han dado, "invisible-makeover", lo dice todo: internamente el framework ha sufrido una reestructuración increíble y ha dado un salto importantísimo a nivel de rendimiento. Dependiendo de la aplicación, Angular menciona que el tamaño (en kb) de un componente se ha reducido un mínimo de un 60% y dependiendo de lo complejo que sea el componente aún mayor será la mejora, lo cual es una avance sustancial.

Después de Angular 4.0.0 el plan es:

Así que como puedes ver, cada 6 meses aproximadamente habrá versión nueva.

Vídeo: puedes ver la presentación también

[youtube:aJIMoLgqU_o]

Conclusión

Nuevamente, asegúrate de echarle un ojo a las directrices de nomenclatura del equipo de Angular.

Además, hay dos mensajes importantes aquí:

1. No te preocupes de los números de las versiones
2. No necesitamos evolucionar Angular para evitar otro cambio de Angular 1 a Angular 2, pero deberíamos hacerlo juntos como una comunidad de forma transparente, predecible y constructiva.

También me gustaría darle las gracias a Igor por ser tan abierto a la hora de presentar su información, particularmente sabiendo lo sensibles que son los temas de cambios innovadores que rompen con lo actual. Esto significa mucho y espero que la comunidad caiga en la cuenta por qué todos estos cambios son buenos para todos los implicados.

Gracias a Igor, Brad, Stephen y todo el equipo de Angular por revisar este artículo. Esto una vez más demuestra cuánto se preocupan por su comunidad.

Foto por: b10lm, retocada por campusMVP (CC BY 2.0)

Aunque estas palabras clave no tienen nada que ver entre sí, dado que se parecen mucho, a veces puede resultar complicado para los principiantes saber para qué sirve cada una.

Para evitar que esto te ocurra y que puedas tener estar referencia a mano por si la necesitas, a continuación te hacemos un resumen de su utilidad con un ejemplo de uso de cada una:

final

La palabra clave final se utiliza en programación orientada a objetos para aplicar restricciones a una clase, a un método o campo de una clase o a una variable.

En el caso de las clases "finales" no se pueden usar en herencia, por lo que no podrás crear clases derivadas de una clase marcada con final.

En el caso de métodos o campos de clase, éstos no podrán ser sobrescritos en clases derivadas.

En C#, por ejemplo, el equivalente para estos dos casos sería sealed.

Finalmente, si declaramos una variable como "final" solamente le podemos asignar un valor cuando la declaramos o en la primera asignación que le hagamos (es decir, es una manera de declarar constantes en Java).

En C# el equivalente sería const.

Ejemplo de clase "final":

public final class NoHeredable
{
    .....
}

//El intento de declarar esta clase produce un error, ya que no se puede heredar de la anterior
public class IntentoHeredar extends NoHeredable
{
    ....
}

Ejemplo de método "final":

public class Base
{
    public void metodo1() { ... }
    public final void metodo2() { ... }
}

public class Derivada extends Base
{
    public void metodo1() { .... } //Sin problema
    public void metodo2() { .... } //Produce un error!
}

finalize

Cuando el recolector de basura de Java determina que ya no hay más referencias a un objeto y se dispone a destruirlo, llama al método java.lang.Object.finalize de éste. Si la clase en cuestión ha declarado su propio método finalize sobrescribiendo al de la clase Object (todas las clases Java heredan de Object), entonces el recolector de basura llama a este método de la clase en el objeto que va a destruir.

Esto es útil si nuestra clase hace uso de algún tipo de recurso del sistema que necesita ser liberado cuando no vaya a utilizarse más. En el método finalize deberíamos encargarnos de liberar dichos recursos.

Es importante señalar que este método debe ser siempre de tipo "protegido" (protected) para que solo pueda ser utilizado por las clases derivadas de la actual.

Ejemplo:

public class MiClase
{
    protected void finalize()
    {
        ... //Liberamos los recursos

    }
}

En C# también existe Finalize, pero también ofrece el método Dispose y la interfaz IDisposable cuando queremos ceder el control de esto al programador.

finally

Cuando gestionamos excepciones en Java con la estructura try-catch ponemos el código a ejecutar en el bloque try, y si se produce una excepción o error lo gestionamos en el catch. Pero qué pasa si queremos ejecutar un código siempre, incluso aunque haya una excepción.

Esta es la labor de finally. En ese bloque colocamos el código común que siempre debe ejecutarse al final, y nos despreocupamos:

MiClase clase1 = new MiClase(); //Del ejemplo anterior
try
{
    //Hacemos algo con la clase
    ....
}
catch(Exception e)
{
    System.out.println(e);
}
finally
{
    //nos aseguramos de que pase lo que pase, la clase libera los recursos
    clase1.finalize();
}

Esta parte de la estructura try-catch-finally nos evita tener que repetir erl mismo código una y otra vez tanto en el try como en cada uno de los catch, que sería lo que deberíamos hacer si no existiera.

En C# existe exactamente la misma estructura.

¡Espero que te sea útil!

Dos veces al año, los analistas de tecnología de RedMonk estudian las tendencias de adopción de los lenguajes de programación basándose en datos de GitHub y Stack Overflow, y una vez al año nosotros nos hacemos eco de los resultados obtenidos.

En un post anterior ya os explicamos con qué propósito realizan este ranking de lenguajes y cómo llevan a cabo el análisis, por lo que no nos pararemos de nuevo a contarlo ahora. Tan solo aclarar que desde mediados de 2016 han tenido que ajustar la forma de acceder a los datos de GitHub (podéis encontrar todos los pormenores en su blog).

"El cambio principal es que la clasificación de lenguajes ahora se basa en pullrequest en lugar de repos en GitHub", afirman desde RedMonk. "Si bien esto significa que no podíamos replicar los rankings como antes, los resultados en general guardan correlación con los obtenidos anteriormente y son el mejor método disponible", añaden.

Teniendo esto en mente, veamos los resultados obtenidos este año 2017 (La figura que se muestra a continuación ha sido extraída de los datos publicados por RedMonk y por lo tanto es propiedad de RedMonk):

Si comparamos los lenguajes situados en las diez primeras posiciones con los que estaban hace seis meses (3Q2016) vemos que son los mismos simplemente intercambiando las posiciones 3ª y 4ª y además Ruby ha caído dos posiciones:

1. JavaScript
2. Java
3. Python
4. PHP
5. C#
5. C++
7. CSS
7. Ruby
9. C
10. Objective-C

Tras la actualización del proceso de clasificación JavaScript sigue imperturbablede número uno, y eso que había muchas voces que afirmaban que el antiguo proceso (tener en cuenta repos en GitHub en lugar de pull request) favorecía enormemente a JavaScript. El nuevo proceso ha hecho caer por primera vez en la historia a PHP, aunque obtiene un muy digno cuarto puesto.

Los movimientos más interesantes de la clasificación se han producido en los puestos alejados de la cabeza. Tal y como avanzábamos el pasado año, Swift podría revolucionar la clasificación y así ha ocurrido, pasando del decimoséptimo puesto al decimoprimero, el cual comparte con Scala y Shell, en solo seis meses. Los analistas de RedMonk afirman que Swift ha alcanzado el Top15 más rápido que ningún otro lenguaje desde que hacen esta clasificación.

El otro salto importante en la clasificación fue protagonizado por TypeScript. El año pasado TypeScript no estaba ni el Top20. De hecho, estaba en la posición 26, a la par que Erlang y cuatro puntos por detrás de CoffeeScript tal y como muestra la siguiente imagen extraída de la página de RedMonk:

Sin lugar a dudas, de entre los lenguajes considerados lenguajes importantes, TypeScript esel que ha dado un mayor salto en el ranking de GitHub. Imaginamos que el lanzamiento de la versión final de Angular en septiembre de 2016 (lo que muchos denominan Angular 2) le ha dado a TypeScript un buen empujón. 

¿Conseguirán Swfit o TypeScript meterse este año en el Top10? ¿Tú qué opinas?

Si estás pensando en obtener una certificación oficial de Microsoft, quizá te estés preguntando dónde debes examinarte.

Aunque Pearson-VUE, el partner de Microsoft para exámenes de certificación, cuenta con centros examinadores en las principales ciudades el mundo y puedes usar cualquiera de ellos para examinarte, muchas veces no son la mejor opción:

• Si vives en una localidad pequeña, tener que desplazarte a un centro examinador puede hacerte perder un día entero.
• Muchas veces es necesario reservar el sitio con semanas de antelación porque hay poca disponibilidad o mucha gente.
• Puede que el horario no te convenga.
• El centro examinador puede cobrarte una tarifa por el uso de las instalaciones, sumándose al precio del examen.
• Hacer el examen en un entorno que no conoces puede despistarte y disminuir tu probabilidad de aprobar.
• Las personas con movilidad reducida pueden tener problemas para desplazarse al centro y puede que éste no tenga accesos adaptados tampoco.

Por ello, ya hace tiempo, Microsoft lanzó la posibilidad de realizar el examen de certificación directamente desde tu casa. Sin tener que ir a un centro.

Ventajas

Esto te ofrece grandes ventajas que solucionan la mayor parte de los problemas anteriores:

• Da igual en qué parte del mundo vivas: mientras tengas una buena conexión a Internet puedes examinarte.
• La disponibilidad es casi inmediata, y tienes un amplio horario para hacer el examen. Podrás reservar tu examen de un día para otro o incluso en el mismo día, incluso en fines de semana (¡domingos incluidos!). Podrás hacerlo casi a cualquier hora del día o de la noche.
• No hay tarifas añadidas de ningún tipo.
• Estás en tu casa, en tu entorno que ya conoces y te permite tener más relajación.
• No importa que tengas movilidad reducida: solo necesitas poder usar una computadora.

Requisitos

Para poder realizar un examen de certificación online, desde tu propia casa o desde donde quieras, necesitarás:

• Tener una identificación válida a mano para demostrar quién eres: tu documento de identidad, el pasaporte... La foto debe ser parecida a tu aspecto actual. Lo tendrás que mostrar como en cualquier centro físico.
• Un teléfono a mano, preferiblemente un móvil con cámara (luego verás el motivo).
• Un entorno tranquilo y silencioso, cerrado (no puede haber más gente allí) en el que realizar el examen. Cualquier habitación con puerta de tu casa te servirá.
• Una buena conexión a Internet que sea estable y no sufra cortes continuos. Una conexión ADSL o por cable será mejor que una 3G o 4G, y si puedes pinchar un cable de red mejor que usar wifi.
• Debes disponer de una webcam y un micrófono.
• Un equipo con una versión reciente de Windows (7, 8 o 10), y con una cuenta de administrador del sistema (luego veremos por qué).
• Un dominio decente del idioma inglés. Y es que, sí, los supervisores del examen solamente hablan inglés.

La buena noticia es que, quitando el instante inicial, la interacción no tiene que ser de palabra, y puedes utilizar un chat para comunicarte con el supervisor del examen. Esto facilita las cosas si no hablas bien el idioma o no lo entiendes de palabra, pero lo lees bien y eres capaz de escribirlo con cierta agilidad, algo mucho más común.

Cómo me registro para el examen

Pues es muy sencillo: simplemente sigues el proceso normal de desde la página del examen en la web de Microsoft:

Los pasos son:

1. Pulsas sobre "Programar examen"
2. Te pide que te autentiques con una cuenta de Microsoft si no lo has hecho todavía.
3. Confirmas que tus datos están correctos. Revísalos bien pues se usarán para expedir tu diploma de certificación.
4. Se te dirige a una página de VUE-pearson para realizar el pago
5. Eliges el centro en el que te quieres examinar. En este paso elige "Supervisión Online" (o "Online Proctored Exam" si te sale en inglés) para el centro.
6. Elige la fecha y la hora entre las disponibles.

¡Listo!

Cómo se desarrolla el examen

El día del examen debes estar conectado en la dirección que te enviarán por email, a la hora a la que hayas quedado. Te dan un margen de cortesía de 15 minutos por si hubiese algún problema, pero procura no retrasarte o podrías perder el dinero del examen.

Deberás instalar una aplicación para Windows, para lo cual necesitarás permisos administrativos. Así que mucho ojo con esto. Si pensabas utilizar un equipo de la empresa y lo tienes "capado" para que no puedas administrarlo e instalar software, no vas a poder hacer el examen.

Esta aplicación hace unas comprobaciones de software y hardware (velocidad del procesador y memoria adecuadas, si tienes micro, webcam...) y te saca una foto.

La aplicación también te pedirá que muestres tu documento de identidad (DNI, pasaporte...) que debes poner delante de la webcam y que sea totalmente legible. Si no se lee bien te mandan un enlace para el móvil de modo que puedas hacer la foto del documento con el móvil (que siempre va mucho mejor que una webcam para estas cosas) y facilitársela desde éste. Después te pedirán que dejes el teléfono en el suelo, detrás de ti para que no sea accesible, pero de forma que esté a mano por si necesitan llamarte (¡no le quites el timbre!).

No puedes tener ninguna aplicación abierta (ninguna ventana de tipo alguno). Solo el sistema operativo y sus servicios básicos funcionando. La aplicación verificará eso.

Ahora toca esperar un rato. Pueden ser varios minutos, pero están grabando todo el tiempo. Al cabo de un rato te sale alguien hablando para poder iniciar el examen. La conversación se inicia con un chat, y luego ya de palabra. Recuerda, es en inglés. Si no hablas bien el idioma díselo ya en el chat para que toda la conversación vaya a través de ese medio y no de viva voz.

Te van a pedir que les enseñes toda la estancia y tú mismo con la webcam: paredes, suelo, techo, mesa, detrás del ordenador, la corbata si la llevas, gafas, bolsillos... Debes tener una puerta y debe estar cerrada. Es mejor no tener cuadros y otros elementos que se puedan retirar, porque quizá te piden que los levantes o que se los enseñes de cerca.

Ten en cuenta que no podrás tener nada encima de la mesa, ni siquiera un papel y un boli para apuntar cosas (algo que sí puedes tener en un centro examinador, aunque tiene que ser uno especial que te dan ellos). Si ven algo te pedirán que lo retires.

Una vez que comience el examen, aunque la persona que te ha hablado puede que no lo haga más, sigue estando ahí y se está grabando. Por ello:

• No puedes desaparecer de delante de la imagen en ningún momento.
• No se puede detectar ningún sonido, ni conversación. Ni siquiera se te permite leer las preguntas en voz alta (para evitar que las grabes). Así que si estás en casa o en la oficina con más gente, pon un cartel por fuera de la puerta indicando que no se te puede molestar. Si alguien entra a hablar contigo es probable que te echen del examen.

Por lo demás el examen se desarrolla como cualquier otro convencional, con el mismo aspecto y entorno que tendrías en un centro examinador oficial.

Si por cualquier causa, durante la realización del examen se quedase bloqueada la aplicación o se cortase la línea, te intentarán contactar por el chat, y en caso de no poder te llaman por teléfono (por eso no debes silenciarlo). Cuando contactan contigo verifican nuevamente (de forma más rápida y breve) que la estancia sigue cumpliendo los requisitos y de ser así te despliegan nuevamente el examen.

Al terminar el examen, al igual que en método tradicional, ya te dicen si has aprobado o no y la puntuación.

El transcript con las valoraciones por categorías de contenido y para poder imprimirlo lo tienes que bajar desde la página de MCP de Microsoft.

En conclusión

La realización de exámenes de certificación supervisados online tiene muchas ventajas sobre ir a un centro oficial para lo mismo, sobre todo para hacerlos más rápido, cuando tú quieras y sin tener que desplazarte. Además pueden ser algo muy conveniente para personas con movilidad reducida.

Tienen la pega de que debes hablar mínimamente inglés, aunque nosotros recomendamos en cualquier caso que siempre que puedas hagas los exámenes de certificación en inglés, aunque tengan traducción al español. Evitarás confusiones. Ahora bien, en este caso es más complicado pues la persona que te supervisa hablará solamente en este idioma.

El hecho de que lo hagas en tu casa o en tu oficina no quiere decir que tengan un nivel de exigencia menor. De hecho más bien al contrario, porque algunos centros a veces son un poco "laxos" con los requisitos y aquí no. Evitarán por todos los medios que puedas copiar o, peor aún, sacar las preguntas del examen (eso es pecado mortal y te no te dejarán certificarte más).

En la página de Exámenes Supervisados Online de Microsoft puedes encontrar más detalles generales, así como un listado de preguntas frecuentes.

Hace unos meses os hablábamos aquí mismo de los lenguajes esotéricos. Estos lenguajes se caracterizan por ser súper-crípticos, es decir, incluso teniendo el código delante es casi imposible saber qué hacen. Uno de los más famosos es BrainFuck, que se caracteriza por utilizar tan solo unos pocos símbolos como el mayor (>), menor (<) la suma (+), etc...

Por ejemplo, este sería el "Hola Mundo" en BrainFuck:

++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++
++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.

Ininteligible, vamos.

Inspirándose en BrainFuck, el programador alemán Martin Kleppe (un frikazo de todo y lomo, y si no me crees échale un vistazo a su página personal) ha creado el lenguaje JSFuck.

JSFuck utiliza tan solo 6 caracteres, a saber: []()!+, pero lo más alucinante es que con ellos puedes crear cualquier programa JavaScript que funcionará en cualquier navegador moderno😲

Por ejemplo, este fragmento aparentemente sin sentido:

[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+
[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]
[([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+
[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+
[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]
+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+
!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[
])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[
+[]]+([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[
]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[
]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(
[![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(
!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+
[])[+!+[]]]((![]+[])[+!+[]]+(![]+[])[!+[]+!+[]]+(!![]+[])[!+[]+
!+[]+!+[]]+(!![]+[])[+!+[]]+(!![]+[])[+[]]+(![]+[][(![]+[])[+[]
]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]
]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]]
+[+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(!
[]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![
]+[])[+!+[]]])[!+[]+!+[]+[+[]]])()

Produce una alerta por pantalla con el número 1, es decir, es equivalente a:

alert(1);

Vale, no es muy útil, y ocupa varias veces más que el código original, pero puedes convertir cualquier otro programa JavaScript a JSFuck y se ejecutará perfectamente, aunque la conversión es muuuy lenta.

Por cierto, en el transformador de pruebas que viene en la página no intentes poner nada más largo de unos pocos caracteres: te colgará el navegador.

Es decir, lo alucinante de esta tremenda "ida de olla" que es JSFuck es que no deja de ser código JavaScript que funciona en cualquier lado. No necesita un compilador especial: simplemente lo metes en una página y funciona.

Por ello, es posible utilizarlo para ofuscar de manera tremenda ciertos fragmentos de código JavaScript. Esto, que puede ser incluso útil en algunas aplicaciones lícitas, también es un problema si lo que se está insertando es código malicioso para hacer ataques de tipo XSS, por ejemplo, donde el código malicioso pasaría inadvertido para muchos analizadores que tratan de detectarlo.

¿Cómo funciona esto?

En cualquier caso es un experimento muy interesante. Las particularidades del lenguaje JavaScript hacen que expresiones sin sentido aparente como esta:

!+[]+!+[]

Realmente funcionen en cualquier compilador. ¿Sabes qué es ese fragmento?: pues nada menos que el número 2. La explicación viene de considerar por un lado las conversiones implícitas de tipos de datos que hace JavaScript al usar ciertos operadores matemáticos, y por otro la precedencia (orden de aplicación) de dichos operadores.

Así, por ejemplo, si intentamos sumar una matriz vacía a nada, o sea esto:

+[]

Obtendremos el número 0 ya que la matriz se convierte a un número para poder sumarla y al no tener un operando por la izquierda se considera que es 0. Así que lo anterior es equivalente a 0+0, que es 0.

Si además le añadimos un ! delante, es decir, lo negamos, entonces obtenemos un true (el contrario en booleano de un 0 (false) es true), y si repetimos la operación de la suma sin nada a la izquierda, lo convierte en el número equivalente (1) y por lo tanto obtenemos un 1, por lo que el 1 se escribe en JSFuck así:

+!+[]

Siguiendo esa lógica, para conseguir un 2 solo tenemos que sumarle otro 1, pero no tenemos que empezar de cero porque ya tenemos un 1 en la expresión anterior, así simplemente con conseguir otro 1 a la izquierda con !+[] ya es suficiente, y queda:

!+[]+!+[]

Que es lo que vimos antes, facilísimo ¿verdad? 😝

Para obtener las diferentes letras del abecedario de manera ofuscada utilizan conversiones que dan palabras clave como undefined o NaN y luego las extraen con la sintaxis de elementos de matrices (o sea, corchetes), que también funciona para cadenas. Por ejemplo, se puede obtener un undefined con esta expresión:

[][[]]

Y se puede convertir en una cadena simplemente intentando concatenarla (con +) con algo que no se aun número, así que esta expresión:

[][[]]+[]

Resulta en la cadena "undefined".

Por lo que si ahora la rodeamos con un paréntesis para obtener el resultado y cogemos su primera letra, obtenemos la "u", así:

([][[]]+[])[0]

Con la segunda letra (posición 1) tendríamos la "n" y así sucesivamente.

Hacen esto mismo con el resto de letras posibles y otras palabras clave.

Bueno, pues con esto y unos cuantos trucos más del estilo al final es posible crear un código totalmente indescifrable que ejecute casi cualquier cosa en JavaScript.

En la página de GitHub del proyecto puedes ver el código fuente completo, pero también tiene una buena explicación de cada uno de los trucos que usa.

Más allá de una simple curiosidad y de la frikada, se trata de un proyecto muy interesante que muestra la flexibilidad que posee JavaScript (que es un arma de doble filo y que hace que muchos lo odien). Y nunca se sabe para qué podrías necesitar algo como esto 😈

Chrome es uno de los navegadores más utilizados del mundo. En gran parte su popularidad se debe a lo fácil que es ampliar sus capacidades mediante el uso de extensiones. El problema muchas veces es encontrar la apropiada entre el enorme mar de opciones que tenemos, ya que existen miles de ellas.

En el caso de los desarrolladores existen unas cuantas extensiones que no debiéramos dejar de utilizar, sobre todo si somos programadores web. En este recopilatorio hemos reunido las 10 que más nos gustan, sin ningún orden en particular.

Si tienes alguna más en el radar que consideres indispensable, háznoslo saber en los comentarios.

¡Vamos allá!

1.- Chrome Dev Editor

Se trata de un buen editor de código que se ejecuta directamente en el navegador, creado por Google. Aunque su principal intención es que lo uses para desarrollar extensiones para Chrome, lo cierto es que funciona muy bien con cualquier desarrollo web Front-End en general, ya que soporta coloreado de código JavaScript y HTML, plantillas de Polymer, e incluso integración con Git para control de código fuente.

Ofrece multitud de "skins" para mostrar su interfaz de usuario con diferentes colores, y te permite cambiar las teclas rápidas para que coincidan con las de Vim o EMacs.

No va a sustituir a tu editor habitual pero puede venir bien para una urgencia. Además trabaja off-line por lo que se puede usar en un lugar sin cobertura. Si tienes un Chrome Book, sin duda debes instalarlo.

2.- Postman

Un clásico indispensable si estás desarrollando servicios. Esta aplicación permite probar y analizar de manera sencilla los servicios web REST (aunque tiene un soporte menor para servicios SOAP/XML). Te permite probar con facilidad cualquier método, analizar y manipular la respuesta, guardar un histórico, crear colecciones de llamadas... Tiene una versión de pago para trabajo en equipo y mejoras en la documentación, pero con la gratuita tendrás para cualquier necesidad si eres un desarrollador individual.

Aparte de la extensión para Chrome del enlace anterior ofrece su descarga como app independiente para Windows, Mac y Linux. Toda la información en su sitio web.

3.- Secure Shell

Un terminal compatible con XTerm directamente en Chrome. Lo puedes usar como un cliente SSH o emulación de terminal, por lo que te puedes conectar al servidor Linux que alberga tu sitio, y gestionarlo sin salir del navegador.

Para funcionar utiliza hterm, el emulador de terminal escrito enteramente en JavaScript, y un port a NativeClient (el sandbox de Chrome para ejecutar código C y C++) de OpenSSH.

Funciona incluso en Chrome Books, donde puede resultar más útil incluso.

Si te interesa el tema, en su FAQ encontrarás multitud de datos interesantes.

4.- Webmaker

¿Conoces Codepen? Pues WebMaker es como si tuvieras Codepen directamente en tu navegador, y con soporte off-line.

Te permite crear pequeños proyectos y pruebas en HTML, CSS y JavaScript y ver en tiempo real cómo responden a los cambios. Puedes añadir referencias a las bibliotecas más populares para trabajar con ellas en tu proyecto. Además soporta Markdown, Jade, SCSS (Sass), LESS, JSX, CofeeScript y TypeScript... y todo ello sin necesidad de estar conectado a Internet 😵

Es súper-útil para aprender y practicar, para prototipar de manera rápida algunas utilidades, o trabajar en tu equipo con calma antes de pasarlo a Codepen, web a la que por cierto puedes exportar los proyectos con un solo clic.

Ofrece varias distribuciones de elementos en pantalla, puedes guardar los proyectos en local para abrirlos de nuevo más tarde y sacar capturas de pantalla de lo que has creado.

Y es totalmente gratuito.

Más que recomendable.

5.- Python

¿Estás aprendiendo Python 2.x? ¿Te gusta el lenguaje y te interesa hacer pruebas rápidas sin abandonar tu navegador?

Pues esta extensión es para ti. Se trata de un REPL (Read-Eval-Print Loop) o intérprete interactivo de Python 2.7 que funciona directamente en Chrome gracias a la magia de NativeClient.

Se abre una consola que lanza Python y listo: ya puedes empezar escribir comandos, interpretar fragmentos de código, etc...

6.- Form Filler

Esta interesante extensión te ayuda a probar los formularios de tus aplicaciones web, rellenándolos automáticamente con datos inventados, pero con sentido según el tipo de dato. Para ello hace un emparejamiento según el nombre del campo o su tipo con ciertos tipos de información.

Por ejemplo, si el campo es de tipo email introduce una dirección de correo electrónico dentro de unos dominios determinados, o si su nombre es username se inventa un nombre de usuario.

Estos emparejamientos y muchas otras opciones se pueden especificar desde su configuración (botón derecho sobre su icono en Chrome).

En el resto de los campos introduce fragmentos de "lorem ipsum" por lo que requerirá de cierta configuración para afinarlo y adaptarlo a nuestras necesidades, pero una vez hecho nos resultará de bastante ayuda.

7.- Cookies

A través de las herramientas del desarrollador de Chrome tenemos la posibilidad de examinar todas las cookies de cada uno de los sitios web (uno a uno), pero no podemos gestionarlas. Desde la dirección chrome://settings/cookies podemos verlas todas juntas, filtrar por dominio e incluso eliminarlas. Pero en ambos casos el control que tenemos sobre ellas es más bien escaso, entre otras cosas porque a Google no le interesa demasiado que lo tengamos, puesto que vive de tenernos controlados a través de ellas.

Esta extensión nos permite ver todas las cookies de nuestro equipo, pudiendo editarlas, eliminarlas e incluso crearlas nuevas, obteniendo un control total sobre las "galletitas".

Una característica adicional interesante es la posibilidad de guardar conjuntos de cookies en un almacenamiento cifrado y protegido por clave de modo que podamos restaurarlas bajo demanda, solo cuando las necesitemos.

8.- Check My Links

El objetivo de esta útil extensión es muy simple: seguir todos los enlaces que hay en una determinada página para verificar si son correctos o no. A medida que las va comprobando va actualizando la gráfica que indica el estado de comprobación, y al final sabremos exactamente cuántos enlaces hay, cuántos son válidos y cuántos y cuáles están rotos.

En su configuración se pueden especificar qué dominios deberá dejar fuera de las comprobaciones (por ejemplo por defecto trae algunos de Google). Se echa de menos el poder introducir una cadencia para evitar ser bloqueado por cortafuegos de aplicación que pueden encontrar el tráfico que genera un tanto sospechoso. Si las pruebas las vas a realizar en local o contra tus propios dominios únicamente, entonces no hay problema.

Si haces sitios web debería estar en tus indispensables, pero en realidad puede resultar útil para muchas otras situaciones.

9.- DOMFlags

A este cuesta un poco pillarle la gracia, pero cuando se la encuentras, no puedes vivir sin él.

Si has tenido que ajustar el diseño de una página o aplicación web, tocando el CSS de ciertos elementos hasta dar con la combinación apropiada sabrás de qué hablamos: saltar continuamente entre 3 o 4 elementos para tocar alguna de sus propiedades CSS. A veces es un balance entre ajustes por lo que no te queda más remedio que estar saltando de unos a otros para ir probando.

Bein, DOMFlags permite crear "favoritos" dentro de los elementos de una página, y luego saltar de unos a otros con una combinación de teclas rápidas. Basta con marcar un elemento con el atributo domflags para que pase a formar parte de la lista de "bookmarks" de esa página.

Este atributo se le puede poner dinámicamente en las herramientas del desarrollador, a mano o usando un botón específico que te da la herramienta en cada elemento (o la combinación ALT+MAYs+D). O bien puedes ponérselo directamente en tu código fuente para que sean permanentes mientras haces los ajustes.

Una vez establecidos estos "favoritos" puedes cambiar entre ellos pulsándolos en la lista que se genera, o utilizando la combinación de teclas ALT+MAYs+1, 2, 3... dependiendo de si quieres ir al primero, segundo, etc...

Es una utilidad muy simple pero que te puede ahorrar mucho tiempo y mejorar tu productividad.

10.- Library Sniffer

Aunque un desarrollador experimentado puede analizar rápidamente el código de un sitio y las cabeceras de las peticiones para saber con gran grado de acierto qué tecnologías utiliza, siempre viene bien que te lo den hecho.

Y esto es precisamente lo que hace esta extensión: coloca una lupa en la barra del navegador que, cada vez que entras en un sitio web te dice qué tecnologías está utilizando tanto en el lado cliente como en el servidor.

Reconoce la mayor parte de las bibliotecas JavaScript conocidas (jQuery, Angular, React...), los sistemas de gestión de contenidos (estilo WordPress y similares), tecnologías de análisis de sitios (como Analytics) e incluso tecnologías de servidor (como ASP.NET, NodeJS, etc...) y servidores web (IIS, Apache, NGinx...) indicando además sus versiones.

Es útil para saber qué usa nuestra competencia o las aplicaciones que nos gustan.

Es Open Source y podemos ver su código fuente en GitHub.

Con estas extensiones lograrás tener una mayor productividad mientras trabajas o aprendes.

¿Conoces algunas extensiones para desarrolladores sin las que no puedas vivir? Déjanos una descripción y para qué las usas en los comentarios.

Este artículo es una traducción de esta entrada de Julia Silge en el blog de Stack Overflow, con su permiso.

Para mí los fines de semana son principalmente para pasar en familia, leer por placer, y para trabajar en los proyectos de código abierto en los que estoy implicada. Estos proyectos de fin de semana se solapan con mi trabajo aquí en Stack Overflow, pero no son exactamente lo mismo. Muchos desarrolladores trastean con proyectos personales para aprender o para medrar profesionalmente (¡o para pasarlo bien!) y en Stack Overflow damos apoyo a todo tipo de tecnologías, ya sea profesional o por afición. Cuando las personas están programando, estamos disponibles para responder a sus preguntas. Pero, ¿sobre qué lenguajes hay más preguntas los fines de semana en comparación con los días laborables?

Usemos nuestro conjunto de datos StackLite público en Kaggle para explorar las diferencias entre las preguntas que se publican de lunes a viernes y los fines de semana. Este conjunto de datos está a disposición de todo el mundo para poder ser analizado; puedes usar un Kernel de Kaggle para analizar cualquier duda sobre las preguntas y las etiquetas en Stack Overflow.

Comparando etiquetas

Para este análisis, usaremos preguntas que no hayan sido borradas y etiquetas reutilizadas en más de 10,000 preguntas. Hemos definido los fines de semana usando las fechas UTC, lo cual no abarcará el fin de semana de todos los usuarios. En total, esta segmentación incluye 10,451,274 preguntas entre semana y 2,132,073 preguntas los fines de semana. Aquí la gran diferencia en el número global se debe a que la mayoría de las personas usa Stack Overflow para su trabajo los días laborables, y observamos este patrón tanto en el número de preguntas publicadas como en el tráfico a nuestra web.

Debido a este patrón entre semana/ fin de semana, no nos interesa si las etiquetas se usaban más los fines de semana que entre semana; lo normal es que todas las etiquetas sean más utilizadas entre semana. Lo que sí nos interesa es conocer qué etiquetas tienen un ratio mayor en relación con las preguntas publicadas el fin de semana en comparación con las preguntas de entre semana, y viceversa.

¿Qué etiquetas de las preguntas tienen la mayor diferencia de frecuencia relativa?

Para explicar esto un poco mejor, veamos unos cuantos números. El lenguaje de programación Haskell supone un 0.365% de las preguntas del fin de semana en este conjunto de datos, pero solo un 0.21% de las preguntas entre semana, indicando que es extrañamente popular los fines de semana. Sin embargo SharePoint supone un 0.0683% de las preguntas del fin de semana, y un 0.188% de las preguntas de entre semana, demostrando que se usa más los días laborables.

Me produce una gran alegría que el lenguaje de programación funcional Haskell encabece las tecnologías de fin de semana, porque básicamente podemos decir que esta soy yo:

Yo no he aprendido Haskell, ¡pero mi reconocimiento a los que usáis los fines de semana para hacerlo! Y ahora aceptadme esta broma sobre Haskell, que es un lenguaje popular entre académicos y matemáticos pero no utilizado habitualmente en entornos empresariales.

¡Hagamos otras observaciones!

• Vemos que algunas tecnologías de bajo nivel son populares los fines de semana, tales como C, C++, punteros, y ensamblador, además de etiquetas relacionadas con matemáticas, tales como algoritmo, recursividad, y (por supuesto) matemáticas.
• Heroku y Meteor son plataformas de aplicaciones comúnmente utilizadas para prototipado rápido, lo cual puede sugerir que están siendo utilizadas para proyectos de aficionados los fines de semana.
• Muchas de las tecnologías de fin de semana están vinculadas con Microsoft, incluyendo etiquetas relacionadas con Excel, SQL Server, VBA, y T-SQL. Otras comprenden tecnologías de empresa como Oracle.

También podemos visualizar estas relaciones comparando el número total de preguntas con las frecuencias relativas:

Las etiquetas que están más a la derecha en este gráfico (JavaScript, Java, C#, PHP, etc.) tienen más preguntas realizadas, y la etiquetas más a la izquierda menos. Las etiquetas que aparecen cerca de la línea discontinua tienen más o menos la misma cantidad de preguntas los fines de semana que entre semana, y las etiquetas que están más alejadas de la línea discontinua muestran las mayores diferencias entre el fin de semana y entre semana.

Podemos observar de nuevo que la mayoría de las etiquetas populares que son desplazadas de entre la semana están vinculadas con Microsoft (C#, ASP.NET, SQL Server, Excel, VBA) y que muchas de las tecnologías desplazadas del fin de semana incluyen cosas como C y C++, y también lenguajes más noveles com Swift y Node.js.

Trabajando durante el fin de semana

También podemos usar este conjunto de datos para evaluar cómo los desarrolladores han cambiado la forma de usar estas tecnologías con el paso del tiempo. Podemos usar una simulación para encontrar etiquetas cuya proporción de fin de semana (el porcentaje de preguntas que se realizan durante el fin de semana) ha variado más con el tiempo. Para etiquetas con más de 20,000 preguntas, ¿sobre cuáles se está publicando menos los fines de semana en comparación con el pasado?:

Aquí vemos etiquetas como Ruby on Rails y Scala que los desarrolladores usaban con un ratio más alto los fines de semana hace varios años, pero que ahora usan a un ritmo menor los fines de semana y mayor en días laborables. Estas tecnologías estaban más orientadas al fin de semana antaño, pero hoy en día suponen proporcionalmente una parte mayor de la vida laboral de los desarrolladores. El sistema de control de versiones SVN también ha caído en su uso el fin de semana en estos años; probablemente la aparición de GitHub (lanzado en 2008) ha llevado a que menos personas usen SVN para gestionar el código de los proyectos personales de fin de semana.

Si buscamos las etiquetas que más han crecido los fines de semana, vemos el motor de vídeo-juegos Unity3D, y un gran número de etiquetas usadas para crear aplicaciones móviles. Parece que los desarrolladores están diseñando ahora cada vez más vídeo-juegos y apps los fines de semana que en los años anteriores. ¡Una gran manera de pasar el fin de semana!

Hemos usado datos totalmente accesibles para hacer este análisis, y esperamos ver qué encuentran otros desarrolladores de nuestra comunidad explorando los productos de datos que ofrecemos. Nosotros en el equipo de datos usamos conjuntos de datos como este para responder a diferentes dudas sobre cómo entender, contratar y conectar con desarrolladores. Para ver cómo podemos resolver tus dudas usando datos y análisis, aprende más sobre Developer Insights en Stack Overflow.

Si has instalado Java alguna vez habrás visto el siguiente banner:

en el que "sacan pecho" diciendo que más de 3 mil millones* de dispositivos ejecutan Java.

*: El billón estadounidense es diferente al nuestro. "billion" en inglés americano se refiere a "miles de millones", mientras que en España (y el resto del mundo, en realidad) se refiere a millones de millones, por lo que la cantidad correcta es la que indicamos.

¿Qué hay de cierto en esa afirmación?¿Son sus números realmente tan grandes?

Lo cierto es que esa estimación es muy conservadora y hace muchos años que deberían haber actualizado ese banner. En realidad existen muchos más dispositivos que usan Java por debajo. Java es intrínseco😜

Veamos algunas cifras proporcionadas por ellos mismos pero bastante realistas:

• 1.100 millones de sistemas de escritorio tienen Java instalado. A esto ayuda que se ejecute en cualquier sistema operativo de escritorio que se te ocurra: Windows, Linux, Mac, FreeBSD, Solaris... Piensa en uno cualquiera y seguro que tiene una máquina virtual de Java.
• 3.000 millones de móviles ejecutan Java. No solo es que sea la base en la que sustenta el sistema operativo más utilizado del mundo, Android, sino que la mayor parte de los teléfonos "tontos" desde el siglo pasado usaban (y usan) Java por debajo. Solo Nokia en sus tiempos lanzó más de 300 modelos basados en esta tecnología. De hecho Oracle dice que se venden cada año 31 veces más teléfonos con Java que móviles con Android o iOS.
• El 100% de los aparatos de Blu-Ray del mercado usan Java. El 100%. Todos. Esto se debe a que el estándar BD-J para contenidos extra está basado en Java ME (la "J" en el nombre es de Java) A pesar de su declive debido al vídeo en streaming, solo en 2010 había ya en el mercado más de 300 millones.
• Cada año se fabrican 1.400 millones de tarjetas inteligentes (smart cards o Java cards) (de crédito, de seguridad y de otros tipos) que ejecutan una pequeña máquina virtual Java. Hay miles de millones en el mercado. Es probable que tengas alguna encima y ni siquiera lo sepas.
• Java está debajo de todo tipo de aparatos: impresoras, webcams, televisiones inteligentes, equipamiento médico, sistemas de entretenimiento y navegación de coches, terminales de pago con monedas, máquinas de cobro en autopistas...
• Existen decenas de miles o quizá millones de aplicaciones de servidor escritas en Java. Solo por citar un par de ejemplos conocidos: Twitter gestiona más de 400 millones de tweets nuevos al día en una aplicación basada en Java, y Netflix sirve más de 2.000 millones de contenidos diarios con una arquitectura Java en su interior.

Total, que en realidad no solo esa cifra es cierta, sino que se queda muy corta y es probable que la otra cifra que dan en su sitio de 15.000 millones de dispositivos que ejecutan Java esté más cerca de la realidad.

O sea, que si aprendes Java aprendes el lenguaje más utilizado del mundo, con más ofertas de trabajo y con el mayor número de sitios en donde poder utilizarlo.

Desde siempre, en JavaScript las funciones han tenido una importancia primordial. Por un lado son el mecanismo para tener visibilidades y ámbitos, y además son "ciudadanos de primer orden". Eso significa que en JavaScript se puede, y de hecho se hace constantemente, pasar funciones como parámetros y devolver funciones como resultado.

En JavaScript podemos declarar una función anónima y colocarla en cualquier punto donde se espere un valor:

var value = function() { return 42};
value();        // 42

La variable value contiene un valor que es... una función. Es por ello que podemos usar el operador () sobre la variable y que su tipo, si lo consultamos con typeof, es function.

Observa que, una cosa es la variable value, y otra es el valor que hemos asignado a dicha variable: una función anónima. Dado que la función es anónima no hay manera de llamarla si no es a través de alguna variable que la contenga (como value).

Por supuesto también se pueden declarar en JavaScript funciones tradicionales, es decir con nombre, sin necesidad alguna de almacenarlas en una variable:

function value() { return 42;}

Al igual que antes, si ahora usas typeof para consultar el tipo de value obtendrás function, y al igual que antes puedes usar value(); para invocar a la función. Parece pues, que no hay ninguna diferencia, pero son dos cosas distintas: en el primer caso tienes una variable value cuyo valor es una función y en el segundo, value es directamente la función.

Puedes conocer las diferencias entre ambas formas de declarar las funciones en JavaScript en este artículo de nuestro tutor José Manuel Alarcón.

No deja de ser curioso que siendo JavaScript un lenguaje muy orientado a usar funciones anónimas, la sintaxis para declararlas sea un tanto "verbose", o por decirlo con palabras castellanas: tediosa, larga. Observa la sintaxis mínima necesaria para crear una función anónima que devuelva un valor:

function() {
    return 10
}

Visto así no parece tan tediosa esta sintaxis. El problema es que se usa constantemente y al final la legibilidad se ve afectada. Para solucionar esta situación en ECMAScript 2015 (también conocida como ECMAScript 6 o ES6) se introdujo el operador de "flecha" (arrow o fat arrow) que ofrece una sintaxis alternativa, mucho más clara y sencilla para declarar funciones.

En el siguiente vídeo vamos a ver su sintaxis básica y cómo utilizarlo.

[youtube:OIyd9tNMX18]

Es indudable que el mundo se mueve hacia los servicios de suscripción. Y ni siquiera los sectores más tradicionales se escapan de esta tendencia. Lo cual no quiere decir que siempre vaya a ser buena para todos los implicados.

Y sino que se lo pregunten a los dueños de tractores John Deere en el EEUU profundo.

Aquí quizá no es muy famosa, pero John Deere es una empresa-monstruo que factura 26.000 millones al año vendiendo máquinas para la agricultura y la construcción, y que es conocida sobre toda por sus enormes tractores. En EEUU son intrínsecos: todo el mundo los utiliza.

Desde hace una temporada los tractores vienen con un software de control instalado que entre otras cosas impide que ningún taller no autorizado pueda tocar en el tractor, incluyendo cambiar las piezas más básicas. Esto significa que si un granjero en plena temporada tiene una avería con el tractor, tiene que esperar lo que sea necesario (cualquiera remolca un bicho de estos hasta un taller autorizado a varias decenas de kilómetros) a que se presente un técnico de la marca para ver qué le pasa y repararlo. Esto puede suponer grandes pérdidas y estrés. Aunque, por ejemplo, tuviese un mecánico de confianza cerca que le pueda reparar una transmisión (¡mecánica!) y así poder estar trabajando en poco tiempo, no hay nada que puedan hacer. En cuanto tocas cualquier pieza, el tractor deja de funcionar hasta que la pieza en cuestión "se autoriza" por el software de la marca.

El problema no es solo la espera, y es que un "técnico cualificado" que llega y pincha un aparato por USB al tractor les cobra un fijo de 230$ (unos 212€) además de 130$ la hora (unos 120€) por el trabajo 😱

Otra de las preocupaciones de los propietarios es: ¿qué pasa si dentro de 15 o 20 años sigo usando el tractor pero la marca no quiere prestarme el servicio porque ya no tiene las piezas disponibles? ¿Tiro con el tractor? Y no es para menos...

Ante estas enormes implicaciones económicas para los propietarios, muchos de ellos están recurriendo a "hackear" sus tractores con software ucraniano, que deben comprar en foros privados para los que también hay que pagar por entrar.

La muy recomendable publicación americana Motherboard (en inglés) nos cuenta la historia completa y nos ofrece todo tipo de detalles sobre el software, el submundo que hay a su alrededor, lo que hay que hacer para acceder a esos foros, etc... Es una muy interesante lectura que te sugiero.

El problema no es solo que los propietarios de los tractores tengan que recurrir a algo tan extremo como reventar el firmware de sus vehículos. Es que además en realidad no tienen ni idea de qué están metiendo dentro. ¿Y si ese software tiene malware, como una bomba de tiempo lógica que dentro de unos años para la producción agrícola del país de golpe? ¿o si pide un recate para recuperar el control sobre el tractor?

Desde luego no parece que la estrategia comercial del fabricante de tractores esté haciendo un favor a nadie. Probablemente ni siquiera a ellos mismos, que verán como muchos clientes se van a otras empresas y como a la larga acaban perdiendo más de lo que ganan.

El equilibrio entre el derecho a ganar dinero y la libertad del consumidor

Aunque pienses que esto te queda muy lejos, algo así está ocurriendo ya con nuestros vehículos particulares aquí en Europa también, solo que quizá no seamos tan conscientes de ello. Eso sí, cuando dentro de unos años lleves tu coche, hoy nuevo, a un taller de confianza y te digan que no pueden ponerte piezas o que debes llevarlo al concesionario oficial y pagar un pastón porque lo conecten a una máquina... entonces lo verás claro. Y es que esa es la tendencia actual en casi todas las industrias. Está pasando ya hace tiempo en algunas marcas, y pronto pasará en todas.

Y es que se necesita una legislación que proteja al consumidor de estos abusos.

Por supuesto que es lícito que un fabricante quiera hacer negocio, lo que no es adecuado es que cobre verdaderas salvajadas por un supuesto trabajo especializado que en realidad es una limitación artificial para proteger un mercado. En la actualidad las marcas tienen que ofrecer recambios para sus modelos hasta 10 años después de su fabricación. ¿Pero qué pasa si dentro de 11 años un vehículo totalmente válido y en buenas condiciones se estropea y no hay piezas oficiales? ¿Se pueden negar a que las pongas porque el software no lo permite?

El problema no es tan grave para un particular y un coche utilitario como lo es para un agricultor y la herramienta con la que se gana el sustento. Pero no deja de ser (muy) importante.

No lo sé. Como casi siempre, estas cuestiones son complicadas y hay en juego mucho más de lo que parece. Pero una cosa está clara: siempre será mucho peor que tengas que comprar un software anónimamente en un foro ucraniano o chino para poder cambiarle los frenos a tu coche.

Habría que hacer algo para que no suceda, pero nuestras instituciones y legisladores han demostrado con creces en estos años que van muy (pero que muy) por detrás de la tecnología y de las necesidades de la sociedad.

Este artículo es una traducción de un post de Kitson Kelly, CTO de SitePen, en el blog de David Walsh.

Si estás metido en la comunidad JavaScript, junto con lo de left-pad, probablemente hayas oído hablar TypeScript. El hecho de que grandes frameworks como Angular o EmberJS lo hayan adoptado le ha proporcionado mucha atención. También me gustaría pensar que, al estar Dojo 2 hecho con TypeScript le da un punto más de calidad al tema, y me gustaría además explicar en parte por qué quizás tú también deberías invertir un poco de tiempo en aprender TypeScript.

Microsoft, ¡buahhh!

Recuerdo el momento en el que se anunció TypeScript por parte de Microsoft, e inmediatamente lo descarté. Normalmente lo hacía con cosas que venían de Microsoft. A mis ojos eran, como muchísimas otras empresas grandes de software, sitios ideales para cargarse la innovación y poner el foco tan solo en desarrollar marca y hacer marketing. En aquel momento era, a duras penas, un director senior de IT por el día, y un comprometido "a escondidas" de Dojo por la noche. Tenía un flujo interminable de empresas de software que aportaban soluciones para mis problemas, sin importar el problema, y superficialmente pensaba que TypeScript era otra forma de atar empresas a la hoja de ruta de Microsoft.

Estaba totalmente equivocado.

Momento fanboy

Un aspecto para entender por qué TypeScript es diferente, en mi opinión, es en base a un poco de ser "fanboy" de Anders Hejlsberg. Cuando empecé a meterme con TypeScript, me di cuenta de que el nombre de Anders Hejlsberg me era vagamente familiar. A finales de los 80 y principio de los 90, yo usaba Turbo Pascal y cuando salió Delphi, migré a él. Me encantaba y predicaba la religión de Delphi a cualquiera dispuesto a escuchar. La programación, en sentido estricto, empezaba a ser algo cada vez menos relevante en mi día a día en el trabajo, pero usaba Delphi como recurso cuando quería montar algo por mí mismo. Recuerdo el día que me enteré que el "malvado" Microsoft le había "robado" el "corazón" de Delphi a Borland para trabajar para Microsoft.

Obviamente, unos pocos años más tarde, empecé a oir hablar de C# y lo descarté al principio por ser una "falsificación de Delphi", pero poco a poco, parecía evolucionar e ir más allá de lo que Delphi aportaba para el mundo. Evidentemente, una gran parte C# debe su existencia a Anders.

Cuando até cabos de que la visión de Anders (y su código) eran partes importantes de Turbo Pascal, Delphi, C#, y ahora TypeScript, me entusiasmé.

No es bonito, pero es lo que hay

No creo que haya muchos desarrolladores (si es que hay alguno) de JavaScript que se levanten por la mañana y digan "qué feliz soy trabajando con JavaScript, es un lenguaje maravilloso". Brendan Eich a menudo se ve a sí mismo en el papel de apologista máximo de JavaScript. JavaScript es un ejemplo perfecto de la Ley de consecuencias no intencionadas. Pero ha explotado, por varias razones. Incluso teniendo grandes detractores y críticos, es una realidad que no se puede negar.

Quizás podemos hacer la comparación con el idioma inglés: es un idioma imperfecto, tiene muchas incoherencias, un montón de dialectos de los cuales solo un subconjunto se puede considerar "globalmente entendido", y muchísimas personas en verdad no lo usan bien. El idioma universal debió haberse pensado mejor, y debería haber sido mucho más racional y estructurado, pero yo no hablo esperanto, ¿y tú?. No nos vamos a librar del inglés jamás.

Imaginemos por un momento que pudiésemos añadir un poco de marcado al inglés, para organizar el idioma un poco mejor. Podríamos tomar el inglés y opcionalmente aplicarle unas normas. Quizás algo como marcado, que te permite meter encabezados y enlaces y bloques de código, todo sin romper el lenguaje subyacente. ¿Suena bien no? Eso es TypeScript.

No entiendo

La naturaleza flexible y no estructurada de JavaScript hizo que fuera "fácil" de programar, pero nunca fue fácil de escalar. Escalar grandes bases de código complejas y mantenibles, escalar para que los demás puedan entender tu código, escalar para que los demás puedan usar tu código. Hoy en día toda la web funciona mediante extensión e interacción, y la barrera más grande que tiene esto es entender la intención.

El primer paso fue parar de escribir código JavaScript inline en nuestro marcado HTML y descomponerlo en archivos separados, más fáciles de mantener, creando funciones:

function myGreatApi(options) {
    /* Con suerte nadie necesitará leer esto */
}

Vale, eso está genial pero aún tendría que crear algo de documentación, para que alguien pudiese usar mi código. Quizás podríamos acordar algo como JSdoc:

/**
  * Mi Gran API hace algo genial, solo úsala
  * @param   {Object} options Algunas opciones que necesito...
  * @returns {Object}         Los resultados de mi gran API
  */
function myGreatApi(options) {
  /* Con suerte nadie necesitará leer esto */
}

Genial, eso está mejor, pero ¿qué pasa si quisiera que el parámetro options fuera opcional? ¿Qué pasa si quiero expresar qué propiedades espero tener en las opciones? ¿Cómo puedo describir qué valor de retorno es mejor...? En teoría podría añadir todo esto a un JSdoc muy complejo, pero en verdad no es fácil de mantener y actualmente no es algo que se pueda forzar, solo documentar (aunque cosas tipo Closure Compiler me pueden dar pistas de que estoy abusando de ello).

¿Y si hubiera alguna manera de describir esto de forma que permitiese a un tercero consumirlo sin saber mucho sobre ello?:

interface MyGreatApiOptions {
  /**
  * La URL de destino para mi API
  */
  target: string;

  /**
  * Traducir de un idioma a otro
  */
  translate?: boolean;
}

interface MyGreatApiResult {
  /**
  * Los encabezados devueltos de la petición
  */
  headers: { [header: string]: string };

  /**
  * La respuesta
  */
  response: string;
}

/**
* Mi Gran API hace algo genial, solo úsala
* @param options Algunas opciones que necesito, quizás, si quieres
*/
function myGreatApi(options?: MyGreatApiOptions): MyGreatApiResult {
  /* ahora nadie tiene que leer esto */
}

Ahora, no solo es que tenga ya una API totalmente documentada, que es ejecutable en tiempo de compilación, sino que como en muchos IDEs está disponible la capacidad de finalización automática de código de modo que el programador pueda recibir información en tiempo real de cómo se consumen las APIs.

He llegado a la conclusión de que TypeScript no solo me permite explicar mis APIs a terceros, sino que me ayuda a estructurar mi código y no me obliga a tener que acordarme de memoria de tantas cosas sobre el código que he escrito. Así me centro más en escribir código productivo y perder menos tiempo revisando código que ya he escrito.

Apertura

Uno de los mejores aspectos de TypeScript es que es abierto y transparente. Es un proyecto de Código Abierto de primera categoría. Los responsables no solo han abierto el código del compilador TypeScript, sino que siguen subiendo el listón y presionan al resto de Microsoft para encontrar formas de abrir el código de las herramientas de las que dependen. Por ejemplo, la herramienta que construye las definiciones de la biblioteca de navegadores se ha hecho Open Source. Además, la inteligencia usada para crear el editor integrado en el navegador, se lanzó como parte del código abierto de Visual Studio Code.

El gancho

Los desarrolladores son un colectivo necesitado y TypeScript al estar desarrollado de forma abierta hace que las personas puedan expresar dichas necesidades.

Además, a veces los desarrolladores confunden código abierto con democracia. El Open Source va sobre ser abierto, permitiendo a los demás ver tu código y tus procesos de desarrollo, y ser transparente sobre las decisiones que tomas y por qué. No significa que porque "necesitas algo de verdad" se vaya a incluir. TypeScript ha expresado sus objetivos de diseño, que suponen un gran punto de referencia para la toma de decisiones concernientes a qué dirección va a tomar el lenguaje.

TypeScript (aún) no tiene el concepto de plugins de transformaciones, lo cual lo diferencia de cosas tipo Babel. Puedo ver cómo dicha funcionalidad podría saciar bien a los desarrolladores necesitados, incluso casi puedo ver cómo puede ser un tiro en el pie para un lenguaje que hace lo que puede para ayudar a los desarrolladores a no escribir "mal" código. Actualmente encontramos dentro de la comunidad de Babel transformaciones mal escritas y mal mantenidas que provocan todo tipo de problemas.

TypeScript es aún relativamente joven y está creciendo día a día, pero en mi opinión ha crecido bajo un gran proceso de gobierno y en la buena dirección. TypeScript 2.0 introdujo cambios sustanciales pero que seguían manteniendo la promesa de hacer escalar JavaScript. Dichos cambios incluyen que se ha rescrito la forma en la que se analizan los tipos en el flujo del código, y una funcionalidad opcional que empieza a tratar con los errores lógicos que se producen en torno a la flexibilidad que da JavaScript con las cosas que son undefined o null.

A pesar de su juventud, TypeScript sigue siendo maduro para su edad. Siendo un súper-conjunto de JavaScript, no está reinventado la rueda: está construyendo sobre un lenguaje que, para lo bueno y lo malo, potencia la web. Si unimos a esto que las partes implicadas tienen mucha experiencia en la construcción de lenguajes y tirando de la experiencia colectiva al ser abierto, ha acelerado mucho el hecho de que esté ya en producción ahora.

Finalmente...

Si no le has echado un vistazo a TypeScript, espero haberte convencido de que es algo que merece un poco de tu tiempo. Personalmente creo que forma parte de un gran cambio cultural en Microsoft, pero incluso si no es tan importante para ti, se puede evaluar en base a sus propios méritos. Tiene a algunas de las mejores mentes trabajando para hacer escalar a JavaScript y el equipo detrás está procediendo de una forma abierta y transparente. Al adoptar la realidad de JavaScript y construir sobre ella, en mi opinión TypeScript está transformando el lenguaje común de la web, para mejor.

Nota campusMVP: TypeScript es el lenguaje que se usa para desarrollar Angular, y el que se utiliza principalmente a la hora de desarrollar en este framework. En nuestro curso sobre Angular también se enseñan los fundamentos de este prometedor lenguaje.

(Crédito de la imagen: Anderson Mancini)

Este post recoge las quince respuestas que hemos considerado más interesantes de entre las decenas que podéis encontrar en el artículo original de Quora (en inglés). Nos han parecido que transmiten mucha sabiduría y que os pueden ayudar :-)

1. Tu ingenio es directamente proporcional a la sencillez de tus soluciones.

2. Ya puedes añadir todas las funcionalidades que quieras, en el lenguaje que te apetezca, siguiendo la tendencia que te plazca, que si vuestro equipo de ventas no encuentra a un comprador, todo dará igual.

3. El mundo del desarrollo es tribal. No esperes poder cambiar la mentalidad de los desarrolladores de otras tribus (Sistemas Operativos, lenguajes, frameworks, etc...).

4. En relación con lo anterior, es importante recordar que cualquier problema normalmente puede resolverse de muchas formas, no hay una "única forma mejor", así que es mejor ahorrarse las discusiones.

5. Las demás personas no pueden leer tu mente. Si eres un desarrollador reservado y pensativo, da la impresión de que no estás trabajando. Subsánalo comentando cosas de forma proactiva de vez en cuando.

6. Un bloque de código bastante grande sin una documentación que lo acompañe es como una caja negra. A pesar de lo que digan los demás, entender a fondo el código de terceros es difícil, jodidamente difícil.

7. Las personas normales son bastantes imprecisas con las palabras. Así que los programadores tenemos que hacer muchísimas preguntas para asegurarnos de saber realmente qué quiere el usuario.

8. Tus jefes/ clientes/... agradecen pequeños resúmenes explicados en un idioma que puedan entender.

9. Leyendo los puntos anteriores se evidencia la importancia de la comunicación en este trabajo. Así que empieza a mejorar tus aptitudes a la hora de escribir emails convincentes, de redactar actualizaciones de estado, de describir un bug, de hablar delante de 10 personas y de hablar delante de 100 personas. Sí, todas estas destrezas son muy diferentes entre sí. ¡Echemos abajo el mito de que los techies son malos comunicadores!

10. Recuerda que no eres Superman o Superwoman. Pasarse la noche en vela picando código suele traducirse en una semana de corrección de errores y rescritura del programa. ¿Crees que merece la pena? Olvídate de la largas noches, piensa en tu salud (física y mental) y de paso en el bien del proyecto.

11. Cualquier bloque de código grande tiene errores (¡asúmelo, aunque lo hayas escrito tú, también tiene errores!). Súmale los errores latentes (nadie sabe que están ahí). Y de repente a la hora de añadirle alguna funcionalidad o corregir un error existente conocido, es probable que actives uno de esos errores latentes y entonces tu vida se convierte en un infierno.

12. Se nos paga por los beneficios obtenidos en ventas. No tenemos derecho a tener un trabajo, tenemos que asegurarnos de que estamos programando algo digno de que alguien quiera pagar por ello. Proyectos financiados por Capital Riesgo/Business Angel y el sector público quizás ignoren esto en cierta medida.

13. Una persona realmente competente que haga bien las pruebas es casi tan raro como un unicornio. Si tienes a una trabajando contigo, date con un canto en los dientes. Tales perfiles pueden hacer trizas tu software, sacando a la luz muchos errores. Ayúdales a que te ayuden a descubrir tus bugs y localizarlos y arreglarlos antes de que los encuentren los clientes y te tengas que pasar noches en vela corrigiéndolos.

14. No importa cuánto creas que entiendes un problema, alguna remota y extraña combinación de sucesos improbable se dará después de que pienses que has terminado. A veces hará aparición como un error crítico dos noches antes de lanzarlo en producción.

15. Por último, recuerda que la mayoría de las dificultades se deben a que tienes que tratar con personas y también a procesos y decisiones del pasado.

Los filtros de excepciones son una característica de la gestión de errores de .NET que han estado disponibles en el framework desde siempre. Los programadores de VB.NET han tenido acceso a ellos también desde el origen de los tiempos, pero los "sufridos" programadores de C# se tenían que conformar con simularlos de manera chapucera. No fue hasta la aparición de C# 6.0, allá por el verano de 2015, que los programadores de C# le pudieron sacar partido a esta útil característica por primera vez.

Un filtro de excepciones lo que nos permite es establecer una cláusula catch específica no solo para un tipo de excepción concreta, sino también filtrando la excepción según algunas condiciones adicionales sobre la misma.

Vamos a verlo con un ejemplo concreto.

Imagínate que estás haciendo una pequeña rutina que llama a una página web para obtener su contenido. Si todo va bien devuelve el contenido de la página, pero si se produce algún fallo devuelve un texto corto descriptivo de lo que ha pasado. Cosas como, por ejemplo, "Página no encontrada" si no la encuentra y por lo tanto se devuelve un estatus HTTP 404, "Permisos de acceso denegado" si  se obtiene un 403, o "Se ha producido un error interno" en caso de un código de estado 500, etc...

En un código C# normal anterior a C# 6.0, lo que debería escribir es algo similar a esto (un poco más cuidado, pero así se "pilla" la idea):

public static string DescargaPagina(string url)
{
    try
    {
        WebClient wc = new WebClient();
        return wc.DownloadString(url);
    }
    catch(WebException wex)
    {
        if (wex.Message.Contains("(404)"))
            return "Página no encontrada";
        else if (wex.Message.Contains("(403)"))
            return "Permiso denegado";
        else if (wex.Message.Contains("(500)"))
            return "Se ha producido un error interno en la web solicitada";
        else
            return "Se ha producido un error: " + wex.Message;
    }
    catch(Exception ex)
    {
        return "Se ha producido un error: " + ex.Message;
    }
}

Fíjate en cómo puedo especificar un gestor de excepciones distinto según el tipo de excepción, pero que luego tengo que estar con un montón de condicionales para devolver un mensaje diferente según el código de error que viene en el mensaje. Por supuesto podría haber usado un switch y una expresión regular, o cualquier otra técnica un poco más elaborada para conseguir lo mismo, pero la idea es que tengo que hacerlo dentro del gestor de la excepción.

¿Cómo podría mejorarlo usando filtros de excepciones?

Pues gracias a la palabra clave when que me permite generar diferentes elementos catch con condiciones adicionales de filtro. Lo mejor es verlo en acción porque se entiende muy fácilmente.

El código equivalente al anterior, pero con filtros de excepciones sería el siguiente:

public static string DescargaPagina(string url)
{
    try
    {
        WebClient wc = new WebClient();
        return wc.DownloadString(url);
    }
    catch (WebException wex) when (wex.Message.Contains("(404)"))
    {
        return "Página no encontrada";
    }
    catch (WebException wex) when (wex.Message.Contains("(403)"))
    {
        return "Permiso denegado";
    }
    catch (WebException wex) when (wex.Message.Contains("(500)"))
    {
        return "Se ha producido un error interno en la web solicitada";
    }
    catch (Exception ex)
    {
        return ex.Message;
    }
}

Fíjate que ahora el código es mucho más claro y directo. Gracias a when podemos especificar condiciones más o menos complejas que nos interesen para filtrar cada excepción. Ahora para capturarla en un catch concreto no solo llega con que el tipo de excepción sea el que indicamos, sino que además debe cumplirse la condición que establezcamos en el when.

De este modo podemos tener código más claro y mejor gestionado. No deja de ser "azúcar sintáctico" pero la gente de VB.NET lleva disfrutándolo desde hace 3 lustros, e incluso los de F# lo tenían desde su versión 1.0. Ya era hora de que estuviese disponible en C# también :-)

Te puedes descargar el código de ejemplo para Visual Studio 2015 o posterior desde aquí (ZIP, 4KB)

¡Espero que te resulte útil!

Antes de nada debes tener claro que, a pesar de compartir el nombre, AngularJS y Angular no tienen nada que ver. El mal llamado "Angular 2", que se llama solamente Angular, no es una nueva versión de AngularJS (también denominado Angular 1.x). Es un nuevo framework, escrito desde cero y con conceptos y formas de trabajar completamente distintos.

Angular utiliza un sistema de inyección de dependencias jerárquicoimpulsando su rendimiento de forma brutal. También implementa la detección de cambios basados en árboles unidireccionales, que también incrementa el rendimiento. Según algunos datos oficiales, Angular puede llegar a ser 5 veces más rápido que AngularJS.

Angular tiene una curva de aprendizaje bastante empinada para los desarrolladores. Está todo escrito en Typescript y cumple con la especificación ES6. como ya apuntábamos al principio, no se puede decir que sea una actualización de Angular 1.x. Se ha reescrito por completo e incluye muchas innovaciones que rompen con su predecesor.

A continuación vamos a intentar hacer una pequeña comparación entre cómo se hacen las cosas entre ambos frameworks para que, si ya conoces AngularJS puedas ver cómo cambian algunas cosas en Angular.

Hay muchas más diferencias de las que te contamos aquí, claro está, pero esto esperamos que te sirva para empezar a hacerte una idea del tipo de cambios que se han producido.

¡Empecemos!

1. Angular está orientado a móviles y tiene mejor rendimiento

Angular 1.x no se hizo para soportar móviles, mientras que Angular está orientado desde el principio a dar buen rendimiento y funcionar bien en dispositivos móviles.

AngularJS se diseñó para crear apps Web de tipo SPA, con enlazado a datos bidireccional. No había soporte para móviles, aunque sí existen otras bibliotecas que hacen que Angular 1.x se ejecute en móviles.

Angular se ha creado teniendo en cuenta una arquitectura orientada a móviles. Hay bibliotecas, por ejemplo NativeScript, que ayudan al desarrollo rápido para móviles con Angular. Además, renderiza el mismo código de forma distinta en navegadores web que en apps móviles.

(Gráfico obtenido de la documentación de NativeScript)

2. Angular ofrece más opciones a la hora de elegir lenguajes

Angular ofrece la posibilidad de elegir entre varios lenguajes a la hora de programar. Para escribir código Angular puedes usar cualquiera de los lenguajes: ECMAScript 5 de toda la vida, ES6, TypeScript o incluso Dart (de Google). Mientras que con Angular 1.x puedes usar ES5, ES6 y Dart.

Poder usar TypeScript es un gran avance ya que es una forma genial de escribir JavaScript. TypeScript es el lenguaje por defecto para desarrollar en Angular, y el que sin duda vas a querer utilizar. La mayor parte la documentación que encontrarás por ahí estará creada con TypeScript, así que debes aprenderlo.

3. Los controladores y el $scope de Angular 1.x han desaparecido

Podemos decir que en Angular los controladores se substituyen por componentes. Angular se basa en componentes web, con las ventajas que ello supone al adoptar un estándar de futuro, que cuando esté bien soportado por todos los navegadores ofrecerá más rendimiento todavía.

Por ejemplo:

Controlador Angular 1.x

En JavaScript:

var myApp = angular
.module("miModulo", [])
.controller("productoController", function($scope) {
         var prods = { name: "Prod1", quantity: 5 };
         $scope.products = prods;
});

Controlador Angular

En TypeScript:

import { Component } from '@angular/core';

@Component({
    selector: 'prodsdata',
    template: '<h3>{{prods?.name}}</h3>'
})`

export class ProductoComponent {
    prods = {name: 'Prod1', quantity: 5 };
}

Fíjate en cómo, además, hemos usado una interrogación después de prods para indicar que el objeto podría ser nulo (es un "anulable"), en cuyo caso no se produciría un error y solo se mostraría el nombre en caso de que el producto tenga algún dato. Ventajas de usar TypeScript.

4. La sintaxis de las directivas estructurales ha cambiado

En Angular, la sintaxis de las directivas estructurales ha cambiado, ng-repeat se sustituye por *ngFor, por ejemplo.

Directivas estructurales Angular 1.x:

<ul><li ng-repeat="prod in productos">
     {{prod.name}}</li></ul>

Directivas estructurales Angular:

<ul><li *ngFor="prod of productos">
    {{prod.name}}</li></ul>

El signo Asterico(*) se usa como prefijo para directivas estructurales, in se sustituye por of y se usa la sintaxis camelCase. Hay muchos más detalles de esta nueva sintaxis, pero de momento quédate con esto.

5. Angular usa directamente las propiedades de los elementos y los eventos estándar del DOM

Uno de los mayores cambios en Angular es, que usa directamente las propiedades de los elementos y los eventos estándar del DOM.

Por ello, muchas de las directivas integradas disponibles en Angular 1.x ya no se necesitan, como por ejemplo: ng-href, ng-src, ng-show o ng-hide. Angular usa directamente href, src y propiedades hidden para obtener el mismo resultado.

Y lo mismo se puede decir de las directivas basadas en eventos como ng-click o ng-blur.

En AngularJS:

<button ng-click="doSomething()">

En Angular simplemente tomas el evento estándar y lo envuelves entre paréntesis:

<button (click)="doSomething()">

Nuevamente aquí hay muchos otros detalles a tener en cuenta, pero quédate con esta idea principal.

6. La directiva de datos enlazados en una sola dirección (one-way data binding) se sustituye por [property]

En Angular 1.x, ng-bind se usa para enlazar datos en una sola dirección (one-way data binding), lo que quiere decir que sólo se modifica el enlace desde el código hacia la vista, pero no al revés, lo que permite un mayor control de flujo dentro de la aplicación.

Con Angular esto se reemplaza por [property], siendo "property" una propiedad válida del elemento del DOM sobre el que actuamos.

Por ejemplo, en Angular 1.x escribíamos:

<input ng-bind="prod.name"></input>

En Angular se utilizan simplemente corchetes sobre la propiedad estándar:

<input [value]="prod.name"></input>

Aunque existen otras variantes para lograr lo mismo.

7. Enlaces de datos de doble dirección (two-way data binding): ng-model se sustituye por [(ngModel)]

Este es el enlazado que todo el mundo conoce y usa en AngularJS. En Angular se retira esta sintaxis para lograr mayor seguridad, control y mejora del rendimiento.

En Angular 1.x hacíamos esto para tener un enlazado en dos direcciones:

<input ng-model="prod.name"></input>

En Angular la sintaxis equivalente sería:

<input [(ngModel)]="prod.name"></input>

Este doble-binding ofrece ventajas relevantes en la gestión avanzada de formularios.

8. Ha cambiado la sintaxis de la inyección de dependencias

Una de las grandes ventajas de Angular es la inyección de dependencias. Con Angular hay una manera distinta de llevar a cabo esto. Como en Angular todo son "clases", la inyección de dependencias se consigue mediante constructores.

En Angular 1.x:

var myApp = angular
   .module("miModulo", [])
   .controller("productoController", function($scope, $http) {
        var prods = { name: "Queso", quantity: 5 };
        $scope.productos = prods;
    });

En Angular:

import { Injectable } from '@angular/core';
import { Http } from '@angular/http';
import { Producto } from 'app/shared/Producto.ts';

@Injectable()

export class ProductosService {
    constructor(private _http: Http) { }
    getProductos() {
        return [new Producto(1, 'Queso'),
            new Producto(2, 'Pan',
            new Producto(3, 'Verdura')
        ];
    }
}

@Injectable() es la anotación de Angular que permite definir clases como servicios, importándolos a posteriori dentro de los módulos de Angular. Esto tiene enormes beneficios en lo que respecta al rendimiento, ya que es el propio Angular quien maneja la carga de entidades a través del bootstrapping.

9. Ha cambiado la sintaxis para hacer routing

En Angular 1.x, usamos $routeProvider.when() para configurar el enrutamiento. Sin embargo, en Angular se usa @RouteConfig{(...}). El ng-view que está presente en Angular 1.x se susitituye por <router-outlet>.

En Angular 1.x y JavaScript:

var app = angular
        .module("miModulo", ["ngRoute"])
        .config(function ($routeProvider) {
            $routeProvider
            .when("/inicio", { templateUrl: "inicio.html", controller: "inicioController" })
            .when("/Productos", { templateUrl: "productos.html", controller: "productosController" })
        })
       .controller("inicioController", function ($scope) {
            $scope.message = "Página de inicio";
        })
       .controller("productosController", function ($scope) {
             $scope.prods = ["Queso", "Pan", "Verdura"];
       })

En Angular y TypeScript:

import { NgModule } from '@angular/core';
import { RouterModule, Routes } from '@angular/router';

import { InicioComponent } from './inicio/inicio.component';
import { ProductoComponent } from './productos/producto.component';

const appRoutes: Routes = [
    {
        path: 'inicio',
        component: InicioComponent,
    },
    {
        path: 'productos',
        component: ProductoComponent,
    },
];

@NgModule({
    imports: [
        RouterModule.forRoot(appRoutes)
    ]
})
export class AppRoutingModule { }

Y en la página HTML:

<ul><li><a routerLink="/inicio">Página de inicio</a></li><li><a routerLink="/productos">Productos</a></li></ul>

10. La forma de arrancar una Aplicación Angular ha cambiado:

Angular 1.x tiene dos formas de arrancar. Una usando el atributo ng-app y la otra vía código:

<script>
   angular.element(document).ready(function() {
       angular.bootstrap(document, ['myApp']);
   });</script>

En Angular la única forma de arrancar es vía código, en TypeScript:

import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';
import { AppModule } from './app/app.module';

platformBrowserDynamic().bootstrapModule(AppModule);

En resumen

Como vemos, aunque siempre hay cosas en común, AngularJS y Angular son muy diferentes tanto en lo que se refiere a la forma de trabajar como a los conceptos que subyacen a ambas tecnologías.

En los puntos anteriores solo hemos tocado la superficie, pero esperamos que te haya ayudado a ver la manera tan distinta de trabajar que tienen ambas plataformas JavaScript.

Por eso no se puede hablar de una nueva versión, sino de un nuevo framework, que es necesario aprender prácticamente desde cero.

En campusMVP tenemos un curso de Angular estupendo que te servirá tanto si ya conoces AngularJS y quieres actualizarte, como si partes de cero y quieres aprender a dominar el nuevo framework. Incluye el aprendizaje de TypeScript.

Lo que os vamos a contar hoy no lo supera ni la más rebuscada escena de película romántica de Hollywood...

Lo más normal si alguien le pide matrimonio a su pareja es que, como mucho, se arrodille en plan hortera y le ofrezca una cajita abierta con el anillo y un buen pedrusco, mientras hace la pregunta del millón. Luego el resto de comensales del restaurante gritan "vivan los novios" y suena una música empalagosa... Lo dicho, Hollywood total 😜

Sin embargo para David Hoskins, un desarrollador de UX de Reino Unido, algo tan convencional quedaba fuera de toda duda. Quería hacer algo mucho más espectacular, y sobre todo "friki". Así que estuvo preparando el gran momento durante casi un año y creó "The Box".

El dispositivo (creado usando Arduino como "cerebro") era una caja que, para que la prometida pudiera abrirla debía resolver una serie de desafíos y acertijos de diverso tipo: un puzle de imágenes, un acertijo con audio, una prueba de resistencia (con truco, aun encima) usando un bici conectada al chisme... incluso un juego de medir pesos utilizando jarras de agua que si eres fan de la saga "Jungla de Cristal" seguro que conoces.

El dispositivo hacía uso de una serie de tecnologías que usaban varios Arduino para conectar dispositivos físicos y detectores varios para guiar a la novia hasta la caja y poder abrirla al final, a medida que superaba cada una de las pruebas.

Aunque las pruebas eran rebuscadas, el "truco" estaba en que David estudiaba UX e interacción con el usuario en ese momento, por lo que se aseguró de que cada prueba estuviera "testeada" de cara al usuario antes de la proposición real, verificando que era usable, se entendía y se podía superar con un poco de habilidad.

En su blog de LinkedIn nos cuenta con todo lujo de detalles cómo llevó a cabo el proyecto, qué pruebas había, cómo montó todo el tinglado... Un friki de los de tomo y lomo, vamos. Asúmelo: nunca en tu vida vas a superar esto.

También es necesario decir que la buena de su prometida debe de ser alguien muy especial para no haberlo mandado a paseo, ya antes de llegar a la tercera prueba. Pero ya se sabe lo que dice el refranero popular: Dios los cría y ellos se juntan...😜

Simplificando mucho las cosas para poder dar una definición corta y comprensible, podríamos decir que la plataforma .NET es un amplio conjunto de bibliotecas de desarrollo que pueden ser utilizadas con el objetivo principal de acelerar el desarrollo de software y obtener de manera automática características avanzadas de seguridad, rendimiento, etc...

En realidad, .NET es mucho más que eso, ya que ofrece un entorno gestionado de ejecución de aplicaciones, lenguajes de programación y compiladores, y permite el desarrollo de todo tipo de funcionalidades: desde programas de consola o servicios Windows, hasta aplicaciones para dispositivos móviles pasando por desarrollos de escritorio o para Internet.

El diagrama siguiente muestra los bloques conceptuales en los que se divide la plataforma .NET:

Aunque se trata de un esquema muy simplificado, ya que hay muchos otros componentes que se construyen por encima de esta base y forman también parte de la plataforma, es un esquema igualmente útil para entender qué es la plataforma y en qué "piezas" se basa.

CLR - Common Language Runtime

El CLR o Common Language Runtime es la parte de .NET encargada de ejecutar las aplicaciones desarrolladas para la plataforma:

El funcionamiento del CLR no es trivial, trabaja encima del sistema operativo para aislar a la plataforma de éste. Su funcionamiento es muy parecido, para entendernos, al hipervisor de una máquina virtual. Esto le permite ejecutar aplicaciones .NET multiplataforma. Hoy en día es posible desarrollar aplicaciones .NET para diversas plataformas, como por ejemplo Windows, iOS, Android o Linux.

El CLR nos garantiza también la seguridad de los tipos de datos, avalando que no se producen errores en la conversión de tipos en la ejecución de una aplicación .NET. Este aspecto y algunos otros vienen regulados por lo que se conoce el Common Type System (CTS) o Sistema Común de Tipos de datos.

El CTS define los tipos de datos de .NET y las construcciones de programación de los lenguajes que el CLR puede utilizar de forma adecuada y correcta. En otras palabras, el CTS es lo más parecido a las reglas de juego que permiten el correcto entendimiento entre diferentes lenguajes de programación y el propio entorno de ejecución de .NET.

Otra característica del CLR es la posibilidad de reutilizar porciones de código escritos en diferentes lenguajes. Esto es posible gracias a que todo el código, esté escrito en el lenguaje que esté escrito, debe utilizar las mismas "reglas de juego" de las que hablábamos antes, marcadas por el CLR.

Adicionalmente, el CLR se encarga también de gestionar la vida de los objetos, declaraciones y recursos a lo largo de la ejecución de una aplicación .NET. Esto se lleva a cabo a través de lo que se conoce como recolector de basura o garbage collector. Por lo tanto, a la hora de programar no debemos preocuparnos de reservar espacio de memoria para ejecutar nuestra aplicación .NET. Ni tampoco de liberar los recursos del sistema una vez finaliza la ejecución de la aplicación. El CLR se encarga de ello y nos exime de esta responsabilidad, facilitando el desarrollo enormemente frente a otros lenguajes "tradicionales" como C/C++.

Hoy día es indispensable hablar de ejecución de aplicaciones multi-hilo y multi-subproceso. La posibilidad de ejecutar varios procesos simultáneos dentro de una aplicación .NET es una tarea de la que se encarga también el CLR.

Por último, comentar que el CLR es también el responsable de garantizar la seguridad de ejecución de nuestras aplicaciones .NET.

En definitiva, el CLR es el encargado de gestionar la ejecución de una aplicación .NET. Debido a esta responsabilidad, a las aplicaciones de .NET se las conoce como aplicaciones "manejadas" o aplicaciones de código gestionado.

CLS - Common Language Specification

Al contrario que otros entornos, la plataforma .NET no está atada a un determinado lenguaje de programación. Ni tampoco favorece a uno determinado frente a otros. En la actualidad existen implementaciones para gran cantidad de lenguajes de programación que permiten escribir aplicaciones para esta plataforma.

Entre estos lenguajes de programación destacan Visual Basic ó C#, pero existen implementaciones muy variadas, como por ejemplo Cobol (¡Guau!).

Lo mejor de todo es que, como decíamos en el apartado anterior, cualquier componente creado con uno de estos lenguajes puede ser utilizado de forma transparente desde cualquier otro lenguaje .NET. Además, como ya se ha comentado también, es posible ejecutar el código .NET en diferentes plataformas y sistemas operativos.

La especificación del lenguaje común o CLS está formada por un conjunto de reglas que deben ser seguidas por las definiciones de tipos de datos. Así, dichos datos pueden interactuar desde una aplicación escrita en un lenguaje determinado con otra aplicación escrita en otro lenguaje diferente.

Entre estas reglas se encuentran: la definición de nomenclatura, la forma de definir los miembros de los objetos, los metadatos de las aplicaciones, etc... Una de las partes más importantes del CLS es la que se refiere a los tipos de datos.

Si alguna vez has programado la API de Windows o has tratado de llamar a una DLL escrita en C++ desde Visual Basic 6 por ejemplo, habrás comprobado lo diferentes que son los tipos de datos de VB6 y de C++.

Para evitar este tipo de problemas y poder gestionar de forma eficiente y segura el acceso a la memoria, el CLS define un conjunto de tipos de datos comunes (Common Type System o CTS) que indica qué tipos de datos se pueden manejar, cómo se declaran y se utilizan éstos y de qué forma se deben gestionar durante la ejecución.

BCL - Base Class Library

La BCL está formada por bibliotecas o APIs especializadas que pueden ser utilizadas por todos los lenguajes de programación de la plataforma .NET.

Cada una de estas bibliotecas puede contener a su vez numerosas clases que aglutinan varios métodos y funciones con características concretas.

De esta manera, podemos encontrar bibliotecas con funcionalidades para casi cualquier cosa que necesitemos: enviar correos electrónicos, escribir archivos de texto, acceder a fuentes de datos, manejar información, criptografía, etc...

De hecho, lo más complicado al empezar con la plataforma .NET es navegar entre el mar de funcionalidad escondido en la BCL y aprender dónde se encuentran las principales utilidades.

En el esquema simplificado de la plataforma que hemos utilizado hasta ahora, estaría situado en la zona marcada en rojo a continuación:

En este diagrama tan simple solo vemos una parte mínima de la BCL. En un esquema un poco más amplio, podemos ver cómo, sobre la BCL, se han ido añadiendo nuevos grupos de funcionalidades en las diferentes versiones de .NET:

Dentro de la BCL, como se desprende de las imágenes anteriores, es posible encontrar numerosas clases diferentes, agrupadas organizativamente en lo que se denomina espacios de nombres o namespaces.

Un espacio de nombres no es más que un identificador que permite organizar, de modo estanco, las clases que estén contenidas en él, así como a su vez otros espacios de nombres.

Una (muy) pequeña muestra de éstos sería la siguiente:

Toda la funcionalidad que ofrece la plataforma .NET de serie, sin necesidad de instalar nada de terceras partes, es lo que se conoce como BCL. La BCL es el corazón funcional de .NET. Es lo que nos facilita enormemente el desarrollo puesto que ofrece miles de funcionalidades listas para ser utilizadas: ¿Quieres escribir un archivo a disco? Hecho. ¿Enviar un correo electrónico? Deseo concedido. ¿Acceder a una base de datos remota o a un servicio web? También puedes hacerlo sin dejar la base de la plataforma. Hay literalmente miles de funcionalidades disponibles.

En resumen

La plataforma .NET está formada por una serie de componentes que, en conjunto, permiten la creación de todo tipo de aplicaciones en todo tipo de sistemas operativos y utilizando todo tipo de lenguajes de programación.

Una de las principales dificultades a la hora de aprender .NET es saber por dónde empezar: ofrece tantas cosas que es complicado discernir qué es importante y qué no lo es tanto. Es muy tentador arrancar con unas cuantas "recetas" que te enseñan a hacer cuatro cosas. Pero eso es una receta para el desastre pues no se comprenderá bien qué se está haciendo ni qué hay por debajo.

Aprender .NET bien supone conocer primero una serie de fundamentos, comunes a toda la plataforma, y que te servirán para cualquier lenguaje que uses en el futuro. La curva de aprendizaje se parece a algo así:

Es decir, al principio se va lento, pero luego, de repente, se avanza muy rápido. El motivo es que son muchos conceptos y técnicas de base que es necesario dominar, pero una vez lo consigas, especializarse y aprender cualquiera de las múltiples bibliotecas especializadas (desarrollo web, para móviles, etc...) es mucho más fácil. Es tentador empezar la casa por el tejado y aprender antes alguna de éstas, pero a medio plazo es un error. Sin comprender bien antes los fundamentos, construiremos una casa sin cimientos, y ante la primera dificultad se puede caer.

¿Quieres empezar una casa bien cimentada? Y ¿qué tal ir un paso más allá?

Aviso: este post es una recopilación y adaptación de varias respuestas en Quora. Todo lo que vas a leer a continuación es una broma y está escrito sin ánimo de ofender a nadie.

Dado que este tipo de relaciones puede dar mucho juego vamos a poner dos versiones, y para eliminar cualquier suspicacia, ordenaremos los lenguajes alfabéticamente. Evidentemente, no están todos los que son, por ello, os invitamos a añadir cualquier otra que se os ocurra en la sección de comentarios :)

Versión A

• Awk: Corea del Norte. Se resiste al cambio de forma obstinada, y sus usuarios parecen estar encantados de forma poco natural por razones sobre las que solo podemos especular.
• Bash: Nueva Zelanda. Le encanta la improvisación.
• C: Noruega. Correoso y dinámico, pero no muy emocionante.
• C++: Reino Unido. Sólido y exigente, pero no muy bueno a la hora de rematar la tarea y tiende a ser adelantado por Java.
• C#: Suiza. Hermoso y bien reflexionado, pero tienes que pagar mucho dinero si quieres implicarte mucho.
• Cobol: Rusia. En otro tiempo poderoso y escrito pensando en los jefes; pero al final ha bajado en el escalafón.
• Forth: Australia. Todo va al revés en las antípodas :)
• Java: EE.UU. Optimista, poderoso, le gusta restarle importancia a los inconvenientes.
• JavaScript: Italia. De una influencia imponente y querido por todo el mundo, pero que se desmorona fácilmente.
• Lenguaje ensamblador: India. Masivo, profundo, de una importancia vital pero lleno de problemas.
• LISP: Islandia. Increíblemente astuto y bien organizado, pero gélido y remoto.
• Lua: Suecia. Parece acogedor e independiente, sin embargo, ¡es tan dependiente!
• Perl: China. Aparentemente capaz de hacer cualquier cosa, pero de forma oscura y misteriosa.
• PHP: Brasil. Brota mucha belleza de él y es muy coqueto, pero en el fondo es muy conservador.
• Python: Países Bajos. "¡Hola, no hay problema, hagamosh esto chavalesh!"
• R: Liechtenstein. Probablemente muy asombroso, sobretodo si te van las grandes cifras, pero nadie sabe en realidad qué hace.
• Ruby: Francia. Potente, elegante y convencido de su propia exactitud, pero más bien ignorado por todos los demás.
• Scala: Canadá. Por su cercanía a Java (Estados Unidos en esta clasificación) pero mucho más simple.
• SQL y PL/SQL: Alemania. Una caballo percherón para el trabajo, fiable y robusto.
• Swift: Japón. De repente no está, y al rato está por todas partes y tu teléfono móvil depende de él.

Versión B

• ActionScript: Taiwan. Si JavaScript en esta nueva clasificación es China, ActionScript es un pequeña, pequeña astilla de la misma que quiere apropiarse de todo pero que carece del apoyo de su hermano mayor y de muchos otros países. Sin embargo, es bastante notable por su producto visualmente tan irresistible (al menos en el pasado).
• APL: Mesopotamia. Escritura cuneiforme totalmente incomprensible que en tiempos era una maravilla en su área, pero cedió el paso a sus herederos más modernos.
• Bash: Suiza. No muy grande por sí mismo pero tira de los hilos del resto.
• Basic: Finlandia. Fácil de usar, pero no muy potente.
• C: Rusia. Todo se tiene que hacer del revés, pero todo es posible, su legado es enorme.
• C++: EE.UU. Poderoso, pero cada vez más y más complicado, ilegible y predispuesto a los errores. Tiende a dominar e influenciarlo todo.
• C#: Holanda. Influenciado por una gran mezcla de culturas, es muy flexible.
• Factor: Antártida. Tiene fácilmente representantes de todos los demás países, pero está muy despoblada y es difícil adaptarse a ella. Eso sí, tiene algunas características singulares y espectaculares.
• Forth: Maldivas. Lejano de cualquier tierra continental y predispuesta a desaparecer bajo el agua debido al cambio climático. Famoso por escribirse del revés.
• Haskell: Mónaco. No hay mucha gente pero son millonarios, así que no tiene que lidiar con los problemas de las clases bajas.
• Java: Suecia. Cómodo, pero tiene su propio rey y divisa.
• JavaScript: China. Crece muy rápido y puede hacer muchas cosas sorprendentes. Muchos usuarios.
• Lenguaje Ensamblador: Lesotho, que está totalmente rodeado por Sudáfrica. Raramente utilizado hoy en día para hacer un programa entero, normalmente se incluye como parte de un código más grande hecho en un lenguaje de nivel más alto.
• LISP: India. Cuna de muchas filosofías, derivadas que se han convertido más famosas que la original.
• Lua: San Marino. Minúsculo y totalmente encuadrado dentro de otro país, pero totalmente funcional y bastante rico e independiente.
• Pascal: Alemania. Normas estrictas, buen rendimiento. Y a muchísimas personas simplemente no les gusta el lenguaje.
• PHP: Bangladesh. Pobre, pero numeroso, y está por toda la Web.
• Perl: Grecia. Debes visitarlo al menos una vez en tu vida.
• Python: Países Bajos. Moderno, rico, fácilmente accesible, atrayente por varios motivos, pero no es un actor principal.
• R: Chequia. Su idioma suena tan raro que resulta difícil de aprender.
• Ruby: Singapore. Avanzado pero pequeño.
• Scala: Hungría. Técnicamente puro y correcto, pero padece una obsesión con la gramática impracticable que limita su progresión en el futuro.
• SQL: Arabia Saudita. Dependes de él para ir a coger las cosas que necesitas. Rico y poderoso, pero tienes que ser listo para poder optimizar tu interacción con él. Además, las diferentes implementaciones de SQL tienen sus peculiaridades, como los diferentes países árabes que rodean a Arabia Saudita.
• Swift: Japón. Técnicamente avanzado, pero aislado en las islas y usa caracteres ilegibles.

Habrás notado que en las clasificaciones no aparece ningún país de habla hispana. ¿Cuál crees tú que es el lenguaje que mejor representa tu país?

En este pequeño tutorial vamos a ver cómo crear el típico menú lateral vertical desplegable. Seguro que lo has visto en mil sitios. De entrada, el menú permanece oculto y, al mostrarse, empuja al div del contenido principal. Primero lo veremos usando JavaScript y luego solo con HTML y CSS. Que conste que hay muchas formas de hacerlo, estas dos solo son un par de ellas.

En este sencillo ejemplo (que puedes ver en directo aquí) tenemos simplemente dos divs. El que envuelve al menu (id="sidebar") y el del contenido principal.

Cuando el menú está abierto, el sidebar tiene un ancho fijo y está posicionado como fixed, por si hay que hacer scroll en el contenido. Así que, al div del contenido le damos un margin-left igual al ancho del sidebar.

La clave está en que, al hacer clic en "Abrir menu", hacemos 3 cosas a través de JavaScript:

• Al div lateral le asignamos un ancho fijo
• Al div del contenido le asignamos un margen por la izquierda igual al ancho de la columna lateral
• Ocultamos el link de "Abrir menú" y mostramos el de "Cerrar menú"

Las animaciones son CSS3, no hay JavaScript involucrado.

Y al hacer clic en cerrar, simplemente recorremos el camino inverso.

Este sería el html de los enlaces para abrir y cerrar:

<a id="abrir" class="abrir-cerrar" href="javascript:void(0)" onclick="mostrar()">
        Abrir menu</a><a id="cerrar" class="abrir-cerrar" href="javascript:void(0)" onclick="ocultar()">
        Cerrar menu</a>

Y estas las funciones de JavaScript que llamamos:

<script>
function mostrar() {
    document.getElementById("sidebar").style.width = "300px";
    document.getElementById("contenido").style.marginLeft = "300px";
    document.getElementById("abrir").style.display = "none";
    document.getElementById("cerrar").style.display = "inline";
}

function ocultar() {
    document.getElementById("sidebar").style.width = "0";
    document.getElementById("contenido").style.marginLeft = "0";
    document.getElementById("abrir").style.display = "inline";
    document.getElementById("cerrar").style.display = "none";
}
</script>

¿Y si pudiéramos hacer un menú muy parecido pero sin JavaScript?

Pues sí, se puede. El menú sin JavaScript se basa en lo mismo en lo que se refiere a las propiedades de los divs del menú y de los contenidos. Lo único que varía es la forma de controlar este comportamiento.

Descargo de responsabilidad y aviso a navegantes:

Lo que vamos a hacer con HTML y CSS en este ejemplo es una chapuza de proporciones bíblicas que se salta las buenas prácticas del marcado de HTML semántico y del desarrollo web front end en general. Es interesante hacerlo como ejercicio experimental para ser conscientes de que, conociendo bien CSS y echándole imaginación, se pueden hacer cosas muy interesantes, pero la capa de comportamiento se debería manejar siempre a través de JavaScript.

Bien, una vez dicho esto, ¿cómo controlaremos si el menú está abierto o cerrado? Pues usando un input del tipo checkbox, a través de la pseudoclase :checked, que comprueba si el campo está marcado o no. En la práctica es como si almacenásemos un valor booleano en una variable de JavaScript, pero en CSS.

<input id="abrir-cerrar" name="abrir-cerrar" type="checkbox" value="" /><label for="abrir-cerrar">&#9776; <span class="abrir">Abrir</span><span class="cerrar">Cerrar</span></label>

El input lo ocultaremos con CSS, porque es suficiente con tener visible el placeholder para hacer clic sobre él:

input#abrir-cerrar { visibility:hidden; position: absolute; top: -9999px; }

Podríamos ocultarlo también con display:none; pero recuerdo haber leído en algún lado (lo siento, no recuerdo dónde) que puede dar problemas en algunos móviles. Siendo sincero, nunca me he encontrado este caso pero más vale prevenir, así que lo he ocultado con visibility:hidden; y luego lo posiciono en absoluto para llevármelo bien lejos, así no me molesta ocupando sitio al renderizar en el navegador.

Dentro del placeholder he colocado dos <span> que me servirán para mostrar u ocultar la palabra "abrir" o "cerrar" a conveniencia.

Ahora, simplemente nos queda escribir los estilos en los que se mostrará el menú cuando el input esté activo:

    input#abrir-cerrar:checked ~ #sidebar {
        width:300px;
    }
    input#abrir-cerrar:checked + label[for="abrir-cerrar"], input#abrir-cerrar:checked ~ #contenido {
        margin-left:300px;
        transition: margin-left .4s;
    }
    input#abrir-cerrar:checked + label[for="abrir-cerrar"] .cerrar {
        display:inline;
    }
    input#abrir-cerrar:checked + label[for="abrir-cerrar"] .abrir {
        display:none;
    }

Si te estás preguntando qué hace el símbolo "~", pues bien, es un selector de CSS parecido a "+" pero con una sutil diferencia:

• El selector "+" selecciona el elemento que esté inmediatamente a continuación en el marcado html
• En cambio, el selector "~" selecciona el elemento que esté a continuación pero no es necesario que esté inmediatamente a continuación

Y esto es todo, ya tendríamos nuestro menú funcionando que puedes ver aquí. Por cierto, puedes descargarte los dos ejemplos juntos haciendo clic aquí (ZIP 6,7 KB).

¿A que es sencillo? Ahora ya sólo faltaría poner el resto del diseño de nuestra página a nuestro gusto, y quizá hacer algún ajuste menor del tamaño del menú para alguna resolución de móviles.

Pero eso ya te toca a ti. Pruébalo y me cuentas en los comentarios.

Imagen CC-AT-SA por Purpy Pupple en Wikimedia

Nota: este artículo es una traducción de un post de Parham Doustdar, un programador iraní ciego, con su permiso. El énfasis (negritas) es nuestro. Su historia nos ha apasionado y seguro que traducimos algún otro artículo de los suyos en el futuro.

Cuando publiqué la Autobiografía de un Programador Ciego, recibí muchas preguntas sobre cómo uso el ordenador, cómo escribo código, y sobre cómo comprendo conceptos abstractos.

Cuando empecé a escribir este post me iba por las ramas todo el rato. Empezaba a escribir sobre cosas de mi pasado que no tenían nada que ver con las herramientas que uso. Daba mi preferencias, y luego explicaba cómo llegué a formar dichas preferencias... pero ¿por qué os cuento esto?

Es para animaros a que le echéis un vistazo al enlace de la primera línea de este post, es decir a Autobiografía de un Programador Ciego. Si ahora aún no te apetece, al menos tenlo en cuenta si quieres saber más sobre mi pasado.

Habiendo dicho esto, dejémonos de marear la perdiz y vayamos al grano para explicar lo que dice el título de este post.

Herramientas para todos los días

Lectores de pantalla

Los usuarios de ordenador con discapacidad visual o baja visión usan lo que se denomina un lector de pantalla (adivina para qué) que les lee la pantalla. Estos programas tienen funcionalidades muy potentes. Por ejemplo, con él puedo controlar el ratón, ver los elementos en la pantalla jerárquicamente (como entrar en un menú, o desplazarme por los elementos dentro de una barra de herramientas, etc). Sin embargo, una de las funcionalidades más impresionantes de cualquier lector de pantalla en general es cómo maneja el contenido web. La funcionalidad más rudimentaria es que es capaz de desplazarse entre diferentes tipos de elementos como listas, títulos, botones, campos de texto, y así sucesivamente. El nivel más avanzado es la granularidad, como ser capaz de saltar a un título de primer nivel (un elemento h1) y demás. Por último, ser capaz de manejar WAI-ARIA es una de las funcionalidades que se ha vuelto más importante en los últimos tiempos, ya que cada vez más páginas web adoptan su uso (por ejemplo Google Docs, Twitter, Facebook y demás).

Los lectores de pantalla, al igual que otros programas, ofrecen diferentes funcionalidades en función del que estés utilizando. Por ejemplo, yo uso NVDA porque tiene una calidad altísima, está escrito por personas ciegas, y no tengo que estar buscando copias piratas porque es gratuito. Sin embargo, hay otros lectores de pantalla. Jaws (también conocido como Job Access With Speech) es muy popular, pero su uso va cayendo tras muchos años de hegemonía. También está Window-Eyes, que está creciendo en uso. Si quieres ver una encuesta de tendencias (navegador, lector de pantalla, y combinación de navegador/lector de pantalla), échale un vistazo a los resultados de la Encuesta de los Usuarios de Lectores de Pantalla #6 hecha por WebAIM. Es un recurso muy útil para conocer las tendencias a nivel estadístico entre una minoría de usuarios.

Lo malo es que todos estos son solo para Windows. En Mac e iOS hay un lector de pantalla incorporado llamado VoiceOver. En Linux, hay un lector de pantalla que viene con Gnome de escritorio llamado Orca. Para aquellas personas que no tienen un entorno de escritorio está el proyecto Speakup. Para los usuarios de Android, Google ofrece Google Talkback.

Para hacer la lista lo más completa posible, las personas que usan Chrome normalmente usan una extensión llamada ChromeVox, que es una forma de interactuar con Chrome, y que se diseñó para ser el lector de pantalla de Chrome OS.

Yo personalmente uso Windows y Android, así que mis lectores de pantalla son NVDA y Google Talkback.

Lenguajes de programación

Me encanta aprender lenguajes de programación, así que no tengo uno que use para todo. Sin embargo, cuando hablamos de lenguaje de programación con los que he trabajado, esta es la lista:

• PHP (lo uso en mi trabajo)
• Go (lo uso en mi trabajo, pero no tanto como PHP)
• Elixir (trasteo con este en casa)
• Scala (siempre he querido poder trastear con este en casa también, pero el gran número de funcionalidades de lenguaje me intimida y siempre lo dejo para otro momento)

Por supuesto, he experimentado con otros lenguajes, pero estos cuatro son los que más he usado.

IDEs

Primero, voy a definir lo que yo espero de un entorno de desarrollo integrado.

Un buen IDE tiene que ofrecer autocompletar, la capacidad de ir a la declaración de la función/clase/variable y ver la documentación de una funcionalidad (esto podría ser un DocBlock, o documentación para funcionalidades incluidas de serie). Por supuesto, el refactoring es fundamental: extraer variables locales y métodos, mover funciones de aquí para allá, renombrarlas y demás.

Cosas que están bien tener pero que no me preocupan mucho serían por ejemplo, obtener dependencias de proyectos (usando el gestor de paquetes de un lenguaje como composer, go get, npm y demás) desde el propio IDE, porque así puedo ejecutarlos desde una línea de comando. Obviamente, crear y ejecutar binarios directamente desde el IDE puede ser muy útil, pero como para mí la alternativa es simplemente hacer Alt+Tab para acceder a mi terminal, pulsar flecha arriba para obtener el último comando, y luego pulsar Intro para ejecutarlo de nuevo... me da igual si un IDE no incluye dicha funcionalidad.

La mayor parte del tiempo uso Eclipse e IDEs basados en Eclipse. Al estar en Irán, tengo que usar copias piratas de copias de pagos (como Zend Studio). Sin embargo, las funcionalidades de accesibilidad de Eclipse le ganan a aquellas ofrecidas por otros IDEs sin líneas de comando (sí, ya llegaremos al punto en el que explique por qué no uso la línea de comando).

Ya he publicado un análisis en profundidad sobre accesibilidad en herramientas PHP en mi artículo SitePoint llamado El Estado de la Accesibilidad en Herramientas PHP. De todos modos, aquí va un breve resumen:

• PHPStorm solía ser malísimo, pero los tiempos están cambiando. La plataforma IntelliJ, hasta hace muy poco, era muy inaccesible. Ahora Android Studio está cambiando eso, hasta el punto de que Android Studio se puede casi comparar con IDEs basados en Eclipse. Propuse una sugerencia sobre este tema y dado al gran número de votos recibidos, lo subieron en sus prioridades dentro de su lista de mejoras por hacer (su to-do list, gracias desarrolladores de IntelliJ) y empezaron a trabajar en algunos puntos.
• SublimeText es malísimo. Sus desarrolladores no responden a peticiones de mejora en accesibilidad, así que está fuera de mi atención.
• NetBeans ha empezado a trabajar con las personas que están detrás del Lenguaje de Programación Quorum. No lo he usado últimamente, pero he oído que las cosas están mucho mejor con Sodbeans, el IDE Quorum.
• Notepad++ simplemente funciona. Obviamente, funciones tipo autocompletar y demás no funcionan con lectores de pantalla, pero Notepad++ es muy ligero y compatible con finales de línea tipo Unix, así que lo uso encantado para cosas rápidas.

Sistemas Operativos

Uso Windows tanto en casa como en el trabajo. Tengo un viejo portátil con Linux, para trastear con Emacs y Emacspeak, para ver si soy capaz de dominar sus casi infinitos atajos. Sin embargo, dado que navegar en Linux no está tan bien como navegar con Windows en términos de accesibilidad, me quedo con Windows por el momento.

Actualmente no hay suficientes usuarios de ordenadores ciegos como para justificar una mejor accesibilidad en muchas aplicaciones. Imagina que solo un 1% de las personas con discapacidad visual usan el sistema operativo Linux. Al final los lectores de pantalla no son muy avanzados, los entornos de escritorio (como KDE) no son ni de lejos tan accesibles como sus homólogos en otros sistemas operativos, y el ritmo del cambio es muy, muy lento. A ver, se puede usar, pero es que la experiencia de usuario no es, a falta de una palabra mejor, tan limpia como la experiencia que obtienes con Mac OS X o Windows.

A priori, puedes pensar que Linux es más accesible para las personas con discapacidad visual que Windows, y esta creencia es básicamente verdad. ¿Por qué pensamos que Linux es más accesible? Pues porque cuando pensamos en Linux, nos viene a la cabeza una imagen de caracteres que van desplazándose rápidamente por la pantalla. "Si es todo texto", piensa la mayoría, "entonces tiene que ser un sistema operativo perfecto para que trabajen las personas con discapacidad visual". Y esto es verdad, pero hasta un punto.

El problema se pone de manifiesto cuando hablamos de Internet. Necesitas un navegador capaz de ejecutar JavaScript para navegar por Internet hoy en día, y esto implica que no puedes usar una línea de comando. Entonces tienes que empezar a gestionar temas de navegador, acceso a navegador, y cosas como Adobe Flash Player que es inaccesible en Linux y que no tiene una alternativa accesible en esa plataforma. Igual que lo expuesto en el post sobre PHP llamado PHP: un fractal de mal diseño, hay muchos pequeños problemas. Todo funciona más o menos, pero no encajan las piezas tan bien como en otras soluciones.

Nota: no me estoy metiendo con PHP aquí. Solo cito este post por su famoso ejemplo sobre la caja de herramientas que muchos desarrolladores conocen.

Todos sabemos que Linux es una parte indispensable de cualquier juego de herramientas de un desarrollador web. Yo he solucionado ese problema creando mis entornos de desarrollo con Vagrant, que me ofrece la ventaja de usar Windows para escribir código, y la línea de comandos en Linux para montar y ejecutar la aplicación. No estoy usando Docker porque han bloqueado la descarga de imágenes en Irán.

Con estas explicaciones, os estaréis preguntando por qué no uso Mac. Después de todo, su objetivo es ofrecer una interfaz gráfica de usuario amigable y fácil de usar, a la vez que mantiene la potencia de un terminal, a tu disposición. Esto también es verdad. Sin embargo mi problema con Mac OS X es algo mucho más sencillo, ya que VoiceOver es un lector de pantalla bastante bueno. Mi problema con OS X es que es cerrado. En Linux y Windows, puedes instalar cualquier lector de pantalla, con cualquier sintetizador de voz que quieras. Sin embargo, en OS X, solo puedes usar su lector de pantalla, su sintetizador, y nada más. Eso implica que no puedo usar eSpeak, que es un software texto-a-voz de código abierto en el que un par de amigos y yo contribuimos, para que pudiera soportar el idioma persa. Así que, sin este texto-a-voz disponible en esa plataforma, no tengo forma de comunicarme con muchas personas en mi propio idioma.

Herramientas de productividad

Muchas personas usan diferentes aplicaciones para visualizar cosas. Tienes los tablones Kanban, herramientas de mapas mentales, apps para gestionar las finanzas personales, y muchas más. En el mundo de la programación hay muchas tablas, gráficos y otros tipos de ilustración. ¿Las uso?

Normalmente no.

Cuando estaba en la universidad mis profesores usaban diagramas UML para trasladar conceptos de bases de datos. Usaban formas visuales de representar y calcular datos, como álgebra lineal. Esto suponía un sobre-esfuerzo por mi parte para entender los conceptos en esas asignaturas. Esa presión constante, junto con la poca voluntad que mostraban los profesores que simplemente querían dar su clase e irse a casa, me hizo caer en la cuenta de que no me merecía la pena padecer un sistema educativo con el que me tenía que pelear todo el rato. Ahí fue cuando lo dejé.

Este tipo de problemas no se circunscriben solo al ámbito universitario. Me he matriculado en un curso llamado Las Bases del MachineLearning: Un Enfoque desde un Supuesto Práctico. Hay partes del curso que se basan en técnicas similares, como la regresión lineal. Por supuesto, mi incapacidad de entender estos conceptos ha inspirado la ya famosa pregunta: ¿se puede hacer regresión lineal sin usar gráficas y álgebra lineal? No se trata de que necesite tocar las cosas para ser capaz de visualizarlas. Simplemente es que no entiendo por qué estos conceptos, que en principio no tienen nada que ver con líneas y gráficos, se solucionan de esa manera. Puedo entender que la visualización de los datos te permite ver cómo los puntos de los datos están diseminados, pero ¿tener una solución que resuelve un problema estadístico usando líneas con pendientes e intersecciones? Puf!.

En la actualidad estoy trabajando en un artículo intentando explicar el concepto de regresión lineal sin usar gráficos y, hasta que no esté finalizado, no puedo explicar de manera práctica lo que quiero decir. Sin embargo, muchos conceptos como este, que al parecer se hacen de manera más compleja de lo necesario normalmente me aturden y me confunden. Súmale el hecho de que las líneas y los gráficos y demás no son para nada intuitivos para mí, y ya entiendes el sentido general de lo que quiero decir.

Cuando amplías esto al mundo de las aplicaciones Web, muchas funcionalidades semejantes también pierden el sentido. Por ejemplo, no puedo usar Google Analytics de manera efectiva porque no hay ninguna manera sencilla de ver los datos en bruto en el interfaz, sin poner el ratón encima de varias cosas. Por esta razón he empezado a trabajar en una aplicación en JavaScript para extraer datos de mi Google Analytics y mostrarla en una tabla sencilla, para poder comparar datos, y luego fundirlos y emparejarlos en función de lo que necesite.

Al margen de toda esta negatividad, esto es lo que me funciona.

Uso Trello para crear listas de las cosas que tengo que hacer. La interfaz no es muy fácil de usar ya que no tiene estándares WAI-ARIA. Aunque puede ser usado con teclado, no te informa de muchas cosas. Por ejemplo, cuando navegas en el listado de tarjetas usando j y k, la navegación funciona. Sin embargo, no le deja saber a mi lector de pantalla qué tarjeta ha adquirido foco. Esto implica que aunque puedo usar el teclado para navegar a diferentes tarjetas, no puedo, porque no sé en qué tarea estoy. Google Mail tiene una mejor implementación de esto, donde j y k te desplazan a diferentes emails, pero también de permiten mover el foco a una nueva elección. Lo que esto quiere decir es que mi lector de pantalla te anuncia el nuevo foco, de hecho me permite saber si estoy en el email deseado.

Para redes sociales uso TWBlue para Twitter y Facebook. Voy a Quora a contestar preguntas aunque no forma parte de mi rutina diaria.

Mi proceso creativo es bastante diferente. Desafortunadamente no tengo acceso a personas buenas en cosas como la programación neuro-lingüística para averiguarlo por mis propios medios. El problema está en que el tipo de estimulación que ofrece un mapa mental para alguien que sí ve, no se me ofrece a mí cuando simplemente anoto cosas.

No estoy tan a gusto con las herramientas de productividad que he elegido como con mis herramientas de programación. Tengo que darle más vueltas ya sea para encontrar, probar o crear la solución perfecta para mí.

Conclusión

Hay unas cuantas cosas que me encantan de ser ciego. Una de ellas es que te obliga a labrar tu propio camino la mayor parte del tiempo. No puedes simplemente hacer las cosas como las hacen los demás, porque no te valen. Tienes que entender las cosas desde un nivel muy básico, y seguir experimentado hasta encontrar tu zona de confort. Por ejemplo, cuando alguien da diez razones para ser autónomo, muchas personas simplemente ven la lista, la contrastan con sus objetivos vitales o la visión del futuro y deciden si ser autónomo es lo que les pega más. Sin embargo, yo tengo que pensar todo el rato si tener una discapacidad visual supone ser más un activo o una debilidad si escojo ese camino. Para seguir con mi ejemplo anterior, cuando analizo la lista de las diez razones, barrunto, "¿tendré que crear una interfaz de usuario por mí mismo? La respuesta es, en este momento de la película, un "sí" rotundo. Por eso no soy autónomo.

Pero estoy en un nivel muy básico. Las personas a las que les va bien en la vida asumen estas situaciones y empiezan a ponerse a jugar con ellas en serio, le dan forma, las moldean hasta que están contentos con ellas. Así es como los programadores rediseñan su código hasta que alcanza la forma que habían imaginado. Así es como los canteros tallan una pieza de mármol y le dan forma en su mente hasta lo que tiene que ser en realidad.

Eso es lo que tengo que ser. Es lo que quiero ser.

Aprovechando que hoy es el día del orgullo frikiqueremos mostraros la infografía sobre el episodio IV de Star Wars del ilustrador suizo Martin Panchaud. ¡No te la pierdas!

Puede que te preguntes qué tiene de especial. Podría ser que le ha llevado más de un año hacerla (empezó en enero de 2015 y terminó en mayo de 2016), o que mide 123 metros de longitud, o que tiene 157 dibujos o quizás que incluye diálogos y detalles de diferentes escenas de la película original de forma que “en una sola infografía” puedes ver la peli entera :O

Entre en el enlace anterior, empieza a hacer scroll hacia abajo y alucina...

Como ves son muchas las razones que la hacen especial.

Bonus: Como hoy estamos muy frikis, busca al Maestro Yoda en los cursos de nuestro catálogo y te dará un descuento especial para ti.