DEV Community: José M. Alarcón 🌐

Compartir código en Visual Studio: proyectos compartidos o librerías

José M. Alarcón 🌐 — Fri, 02 Oct 2020 07:44:18 +0000

La manera tradicional de compartir código entre proyectos en Visual Studio siempre ha sido la creación de bibliotecas de código , es decir, ensamblados en forma de DLL que permiten la reutilización de clases entre proyectos.

Nota : el término original en inglés es "library" y se suele traducir al español erróneamente como "librería". En realidad la traducción y el término correcto en español es "biblioteca", en todas sus acepciones. Se trata del típico "false friend" inglés/español. En el título he puesto "librería" porque seguramente será lo que busquéis la mayoría.

Este es el camino a seguir en la mayor parte de las ocasiones ya que creamos una DLL con la funcionalidad requerida a compartir entre varias aplicaciones, y simplemente añadiendo una referencia a dicha DLL (o el proyecto, si está en una misma solución) a otro de nuestros proyectos en Visual Studio ya tenemos la funcionalidad que necesitábamos:

La verdad es que esto es muy cómodo, pero no siempre es lo que queremos. En ocasiones lo que nos interesa es compartir funcionalidad entre proyectos compartiendo directamente el código fuente. A lo mejor no nos interesa distribuir otra DLL con el producto final, o tal vez queremos ir tocando al código original en función de las necesidades y que éste evoluciones por igual en todos los proyectos que lo usan. También puede ser muy útil cuando quieres usar el mismo código genérico en varios proyectos que se enfocan y compilan para plataformas diferentes.

Para solucionar este tipo de problemas, en Visual Studio 2013 update 2 (en abril de 2014) se introdujo un nuevo tipo de proyectos: los proyectos compartidos.

El archivo de un proyecto compartido tiene la extensión .shproj y al contrario que en el caso de una biblioteca, lo que se utiliza es directamente el código fuente, no la DLL resultante.

Por lo tanto, el código fuente de ese proyecto compartido es como si formase parte de nuestro proyecto actual , no de un proyecto aparte, de modo que se compila como cualquier otro archivo de nuestro proyecto y forma parte del ensamblado final de la aplicación. Para entendernos, es como si tuviésemos una subcarpeta con esos archivos de código dentro de nuestro proyecto. Al final obtenemos una sola DLL. Pero es un proyecto independiente que podemos usar en varios sitios a la vez.

Por ejemplo, en mi proyecto Open Source MIIS, un CMS basado en archivos, quería compartir algún código entre éste y otro side-project comercial que tengo, IISMailer, pero no quería tener una biblioteca común que distribuir y además al mismo tiempo me interesaba poder tocarle al código en cualquiera de los dos proyectos y que ambos se beneficiaran de los añadidos. La solución: usar un proyecto compartido.

En este caso le llamé IISHelpers, y aquí podemos verlo en el código fuente de MIIS abierto en Visual Studio:

El recuadro de arriba es el proyecto compartido en sí, que se ve como un proyecto aparte (porque lo es) pero se comporta como si el código estuviese dentro del proyecto principal, desde el cual se hace referencia. Esto último podemos verlo si desplegamos las referencias del proyecto principal, en donde se ve con el mismo icono de proyecto compartido que arriba. La forma de añadirla es la habitual, simplemente lo elegimos desde la pestaña "Proyectos".

Cómo crear un proyecto compartido en Visual Studio

Crear uno de estos proyectos es de lo más sencillo desde VS2015 (antes no lo era tanto), y consiste simplemente en elegirlo en la lista de plantillas de proyecto que tiene Visual Studio al añadir un nuevo proyecto desde una solución, así:

Ahora solo resta añadir la referencia en otro proyecto para que forme parte de éste.

Por regla general es fácil y directo (ahora te cuento cuándo no). Basta con ir a agregar una referencia y elegir el proyecto compartido dentro de la pestaña de "Proyectos compartidos", así:

En esta animación primero añado a la solución un proyecto compartido existente, y luego añado una referencia a éste desde el proyecto principal.

No aparecen referencias a proyectos compartidos en proyectos web en VS2017

Visual Studio 2017 añadió un bug a la hora de manejar proyectos compartidos desde aplicaciones Web. Simplemente no aparece la pestaña de "Proyectos compartidos" al agregar una referencia y por lo tanto no podemos agregarla visualmente tal y como se observa en la animación anterior.

En Visual Studio 2019 lo han solucionado y funciona perfectamente también proyectos web. Esperemos que dure.

Por suerte solucionarlo es relativamente sencillo, pero engorroso. Lo que tenemos que hacer es editar manualmente el archivo del proyecto al que queremos añadir el proyecto compartido. Partiendo de la base de que ya has añadido el proyecto compartido a la solución, ahora debes abrir con un editor de texto (el mismo bloc de notas nos vale) el archivo .csproj que tiene la definición de tu proyecto de C# (.vbproj en el caso de Visual Basic .NET). Dentro de este archivo XML debes localizar los nodos <import> y debes añadir entre éstos un nuevo nodo import que apunte al archivo .projitems de tu proyecto compartido, usando rutas relativas o absolutas para ello, así:

<Import Project="..\..\MiProyCompartido\MiProyCompartido.projitems" Label="Shared" />

Esto le indica a Visual Studio que debe cargar ese proyecto compartido como referencia. El archivo .projitems contiene una lista con todos los archivos de código del proyecto compartido y la manera en la que debe actuar el compilador con ellos (puedes abrirlo para comprobarlo).

Si ahora abres la solución en Visual Studio verás que el proyecto de código compartido está ahí, al igual que su referencia y todo funciona como cabría esperar.

Muy importante : como a los proyectos compartidos se accede a través de su ruta, es importante que si los movemos de sitio lo tengamos en cuenta y los cambiemos tanto en los archivos .sln o como en los .csproj que hagan referencia a los mismos, o Visual Studio no podrá cargarlos. Por eso son mejores las rutas relativas que las absolutas, pero de todos modos puede ser un engorro. De hecho esta es una de las mayores "pegas" del uso de este tipo de proyectos. Ahora bien, si tenemos un entorno de desarrollo estable y los archivos de proyecto los tenemos siempre en los mismos sitios, no debería haber problema. Pero debes tenerlo en cuenta, sobre todo si compartes proyectos con más miembros de un equipo.

Referencias a archivos individuales

Un último detalle para terminar. Si lo único que necesitas compartir de esta manera son uno o dos archivos, quizá lo del proyecto compartido sea un poco "matar moscas a cañonazos". Desde las primeras versiones de Visual Studio existe una manera de compartir archivos individuales de manera parecida, para reutilizarlos como si fueran parte del proyecto actual aunque estén en otro lado. Se trata de la opción Añadir como vínculo que se ofrece al agregar un archivo existente:

De esta manera el archivo se utiliza directamente desde donde esté, fuera del proyecto, pero se compila como un archivo de código fuente más. O sea, consigue lo mismo que los proyectos compartidos pero archivo a archivo, lo cual está bien si solo son como mucho un par de ellos (más se hace inmanejable y es mejor recurrir a los proyectos compartidos).

¡Espero que te resulte útil!

Cómo solucionar el error "java.lang.NoClassDefFoundError" en Java

José M. Alarcón 🌐 — Fri, 02 Oct 2020 07:40:33 +0000

La excepción en el hilo "main" del tipo java.lang.NoClassDefFoundError es uno de los errores más comunes que te puedes encontrar al programar en Java. Y también una de las que más quebraderos de cabeza te pueden ocasionar dependiendo de la circunstancia que la cause.

Exception in thread "main" java.lang.NoClassDefFoundError

Dependiendo del tamaño de tu aplicación, resolver este error puede ser más o menos difícil (cuanto más grande más complicado, lógicamente).

Vamos a ver a continuación las causas más comunes de que se produzca este error y cómo podemos intentar resolverlo.

¿Qué significa este error y por qué se produce?

Antes de nada es necesario que sepamos a qué se debe la aparición de este error. Como su propio nombre indica, este error se produce cuando la máquina virtual de Java no es capaz de encontrar la definición de una clase de la que depende el programa para su funcionamiento. Es decir, cuando su ClassLoader no es capaz de encontrar la clase en su árbol de carga actual.

Si el programa compiló sin problema, quiere decir que la clase se encontró a la hora de compilar, pero luego, en ejecución, no aparece por ningún lado, lo cual puede parecer una cosa muy extraña, pero existen diversos motivos para que pueda ocurrir.

Para empezar, tiene mucho que ver el funcionamiento del ClassLoader. Sin profundizar ni entrar en mucho detalle (info detallada aquí), este objeto funciona de manera jerárquica, de modo que hay varios ObjectLoader a diferentes niveles que localizan y cargan clases. Por ello, por ejemplo, incluso aunque una clase se encuentre, dependiendo del nivel en el que aparezca, si la estamos usando en un nivel inferior es posible que se produzca el temido error que nos ocupa. O puede que si hay dos versiones diferentes del mismo paquete instaladas en el sistema, que se produzca también (generando lo que se conoce como el JAR Hell)

Hay muchas posibilidades. Para solucionar el problema, primero hay que determinar el motivo por el que está ocurriendo, y luego actuar en consecuencia.

Es interesante notar que la excepción java.lang.ClassNotFoundException, que se parece mucho a la que estamos tratando, solo se produce cuando intentamos cargar en tiempo de ejecución una clase utilizando su nombre. Son excepciones distintas aunque conceptualmente parecidas. Esta última es menos frecuente. La que nos ocupa tiene una ventaja y es que sabemos que durante la compilación la clase estaba presente.

Principales motivos para que se produzca la excepción `NoClassDefFoundError`

Por orden de importancia, los principales motivos de la excepción son:

1.- El paquete no está disponible en el Classpath

Esta es quizá la más común de las situaciones y se produce porque la JVM no es capaz de encontrar el paquete correspondiente en el Classpath de Java.

Si falta el archivo .jar o se ha renombrado (por ejemplo, se cambia de miPaquete.jar a miPaquete-v2.jar), la JVM no es capaz de encontrarlo. En estos casos lo más sencillo es simplemente localizar el paquete y copiarlo a donde debería estar (o dejarle el nombre antiguo).

Si tienes dudas sobre dónde está ubicado el Classpath puedes mostrar por pantalla la ruta usando:

System.getproperty("java.classpath")

Otra opción de emergencia para salir de dudas sobre si estamos yendo al sitio adecuado es lanzar el programa especificando manualmente la ruta desde la que se van a cargar los paquetes locales, usando la opción -classpath (o -cp, abreviada) al ejecutar el programa:

java -cp C:\java\MisClases miPrograma

De este modo estaremos seguros de que, a pesar de estar usando la ruta correcta y tener en ella el paquete apropiado, el programa no es capaz de cargar la clase, así que debemos ver otras posibilidades.

Nota : La opción -cp también puede hacer referencia a archivos .jar directamente, uno o varios nombres separados por comas. Es habitual cuando una aplicación depende de código Java compilado (bibliotecas externas) que el classpath se mantenga apuntando al JRE de Java y luego se agregue con -cp la referencia a los archivos .jar de esas bibliotecas de terceros, que no forman parte del JRE sino que se distribuyen conjuntamente con la aplicación.

2.- Faltan permisos suficientes

Algún problema de permisos puede estar impidiendo que se puedan cargar las clases de un archivo .jar y que se produzca la excepción NoClassDefFoundError.

Debes asegurarte de que el usuario actual tiene permisos suficientes para acceder a los archivos. Esto es especialmente importante en el caso de que algún paquete sea compartido y por lo tanto pueda tener unos permisos establecidos por otro usuario, sin haber creado permisos que aseguren el acceso por parte de todos los usuarios.

3.- Falta alguna dependencia de terceros

Alguna dependencia del programa, por ejemplo una biblioteca nativa, no está disponible en el equipo actual, pero sí lo estaba en el equipo en el que se compiló.

Determina cuál es mirando el log de errores e instálala en el equipo actual.

4.- Falta de visibilidad entre niveles de la jerarquía del ClassLoader

En J2EE, como hemos explicado antes, la falta de visibilidad de la clase entre los diferentes niveles de la jerarquía en el proceso de carga puede provocar esta situación.

Esta es una situación compleja y puede dar bastante trabajo solucionarla, así que en lugar de escribir una larguísima explicación aquí te remito al excelente artículo de Pierre-Hugues Charbonneau en el blog de Java EE Support Partners, que lo explica detalladamente y con un ejemplo real paso a paso.

5.- Un script de inicialización sobrescribe a ClassPath

Una posibilidad menos frecuente, pero que puede darse es cuando un script de inicialización del programa está sobrescribiendo la variable de entorno Classpath, lo cual hace que el resto del programa no pueda encontrar los archivos .jar apropiados.

Prueba con lo comentado en el punto 1 para ver si se está usando la ruta correcta.

6.- Errores en un bloque de inicialización estática

Si el programa utiliza un bloque de inicialización estática (por ejemplo, es típico con clases de tipo Singleton, que no permiten más que una instancia), es posible que no se encuentre alguna referencia que se use desde ahí.

Puedes saberlo si en el archivo de log del error aparece referenciada la clase ExceptionInInitializerError.

Por ejemplo, si en un bloque estático de inicialización se declara una clase de tipo Singleton que se inicializa a sí misma en dicho bloque, y se produce un error, al querer utilizar la clase posteriormente desde el programa se produce un error de tipo NoClassDefFoundError, y en el log aparecerá la mencionada ExceptionInInitializerError.

7.- JDK desconfigurado o mal instalado

Si alguna de las variables ClassPath, JAVA_HOME o PATH está mal establecida debido a algún problema de la instalación de Java, vamos a obtener errores de tipo NoClassDefFoundError, por supuesto. En este caso habría que reinstalar el runtime de Java para solucionarlo.

No están todos los que son pero sí son todos los que están

En este artículo hemos procurado repasar las causas y las soluciones más comunes para este error habitual a la hora de programar en Java. Dependiendo de lo que lo esté causando puede ser muy fácil o muy complicado de arreglar.

Los puntos que hemos comentado son los más comunes, pero existen todavía algunas situaciones más que lo pueden producir, si bien son menos habituales.

Una buena recomendación, no solo para este caso, sería que procures utilizar siempre algún entorno integrado de desarrollo como NetBeans o Eclipse, ya que con sus ayudas integradas minimizan mucho las situaciones difíciles y los posibles errores. Aún así, va a ser inevitable que ocurran cosas como esta de vez en cuando. Si es tu caso, espero que al menos este artículo te ayude y proporcione alguna pista para solucionarlo.

TypeScript contra JavaScript: ¿cuál deberías utilizar?

José M. Alarcón 🌐 — Fri, 11 Sep 2020 08:00:00 +0000

Post publicado originalmente en campusMVP

Salvo que hayas vivido debajo de una piedra durante los últimos años, si te dedicas a algo relacionado con el desarrollo web Front-End, seguro que has escuchado hablar de TypeScript.

TypeScript es un lenguaje de programación construido por encima de JavaScript. Este superconjunto de JavaScript dota al lenguaje de varias características adicionales que hacen que podamos escribir código con menos errores, más sencillo, coherente y fácil de probar.

Desde su creación por parte de Microsoft en 2012, la adopción de TypeScript no ha hecho más que crecer. En especial desde que Google decidió adoptarlo como lenguaje por defecto para desarrollar con Angular.

Esta es la evolución del interés por TypeScript en los últimos años en España:

Su subida es imparable (el pico hacia abajo del final, son las navidades de 2019, época en la que todas las búsquedas que no sean regalos bajan mucho 😉). Según The State of JavaScript para el año 2019, el 58,5% de los desarrolladores Web Front-End lo ha utilizado ya en alguna ocasión y tiene interés en usarlo en su día a día en el futuro:

Y desde que se puede utilizar con Node.js también está subiendo mucho en el servidor.

Pero ¿qué es TypeScript exactamente?

ECMASCript 6 o posterior añadió muchas características al JavaScript clásico (ECMAScript 5), como una sintaxis mucho más clara para programación orientada a objetos y muchas nuevas funcionalidades que no existían antes: promesas, programación asíncrona, símbolos, etc. Aún así, presenta limitaciones y dificultades. TypeScript va un paso más allá y añade más funcionalidad a ES, como tipado fuerte, anotaciones o módulos.

Como TypeScript es un superconjunto de JavaScript, todo el código escrito en JavaScript es válido para TypeScript. Pero lo contrario no es cierto. Es decir, como los navegadores no entienden TypeScript, es necesario compilarlo (la palabra correcta es "transpilarlo") a JavaScript antes de usarlo en un navegador.

El siguiente esquema ilustra muy bien el concepto:

TypeScript se puede transpirlar a cualquier variante de JavaScript/ECMAScript que deseemos. Por ejemplo, si sabemos que nuestro proyecto va a trabajar en navegadores antiguos podemos forzar que se compile a ECMAScript 5 (el JavaScript clásico, soportado por todos los navegadores, incluso Internet Explorer). Sin embargo, si tenemos claro que los usuarios van a emplear navegadores relativamente recientes, podemos generar un código final más sencillo apoyado en ECMAScript 6 o posterior.

Nota : por si te lo estabas preguntando ¿eso no lo hace también Babel, que nos ayuda a usar características nuevas de ES en JS clásico? En efecto, así es. Pero Babel no tiene verificación de tipos ni otras de las características avanzadas que ofrece TypeScript (ahora las veremos), y además son 100% compatibles. De hecho TypeScript tiene un plugin pensado específicamente para trabajar con Babel. Así que si usas Babel puedes seguir haciéndolo con TypeScript.

Características de JavaScript comparadas con las de TypeScript

Para ofrecerte un resumen fácil de ver de las características en las que TypeScript mejora a las de JavaScript/ECMAScript, te dejo la siguiente tabla comparativa:

Característica	JavaScript	TypeScript
Tipado estático	No existe: las variables se pueden cambiar de tipo al vuelo, en cualquier momento	Es un lenguaje fuertemente tipado por lo que debemos indicar en todos los casos el tipo de dato a manejar y se producen errores si lo cambiamos. También soporta inferencia de tipos en las declaraciones, fijándolos a partir de ahí.
Tipos genéricos	No existen.	Permite crear código reutilizable basado en tipos genéricos (no confundir con la ausencia de tipado fuerte o estático en JavaScript).
Tipado estructural	No existe.	Permite crear estructuras en base a interfaces de modo que podamos trabajar con una estructura de datos predefinida que no se salga de ciertos parámetros, pero al mismo tiempo permite la flexibilidad de usar estructuras equivalentes con tipos diferentes. Más info.
Tipos enumerados	Se pueden simular con clases sencillas, pero no dan, ni de lejos, la misma robustez.	TypeScript permite definir enumeraciones y mantener la robustez al utilizarlas de modo que no nos podamos salir de ellas.
Tuplas	Sin soporte	Soporta Tuplas como tipo básico de datos
Modularización	Soporta módulos a partir de ECMAScript 6, pero el soporte de módulos en los navegadores es todavía reciente.	Ofrece soporte para módulos directamente en el lenguaje.
Programación orientada a Objetos	Basada en prototipos, con sintaxis compleja en ES5, y sintaxis simplificada en ES6+.	Ofrece una sintaxis muy similar a la de otros lenguajes como C# o Java, y además añade capacidades inéditas en ECMAScript, como las clases abstractas, modificadores de acceso, tipos enumerados...
Interfaces	No hay soporte	En TypeScript las interfaces son esenciales y permiten crear multitud de escenarios avanzados.
Espacios de nombres	Se pueden simular de manera básica	Soporte total integrado en el lenguaje, nos ayuda a organizar mejor el código y evitar conflictos.
Decoradores	No hay soporte	Ofrece un soporte integrado para esta característica lo que facilita enormemente la escritura de código basada en aspectos y la inyección de dependencias.

Tooling

Todo esto está muy bien, pero quedarse sólo en ello sería dejar fuera casi lo más importante: el gran soporte de herramientas en tiempo de desarrollo que tiene TypeScript, es decir, lo que se conoce popularmente como tooling.

Lo principal que hay que saber es que TypeScript integra un componente llamado tsserver y un protocolo del mismo nombre que encapsula al compilador y otros servicios del lenguaje y los expone como un servicio para los editores de código. Esto proporciona una gran capacidad para validar el código a medida que se escribe y ofrecer ayuda contextual (conocida como Intellisense ) al programador mientras programa.

Ello nos proporciona una capacidad enorme para crear código con menos errores y para recibir ayuda durante todo el proceso de desarrollo.

Todos los principales editores de código, como Atom , Sublime , EMacs , NeoVim... y por supuesto Visual Studio Code, incluyen soporte para esta característica.

Si te interesa saber más, el programador alemán Felix Becker dio una charla muy interesante sobre el tema en el FOSDEM de 2019: Advanced TypeScript Tooling at Scale (en inglés, obviously).

¿En JavaScript se puede conseguir algo similar? Pues sí, pero implica documentar absolutamente todo lo que escribas con JSDoc y que tu editor te dé soporte para ello (la mayoría lo hace). Es decir, no es directo ni mucho menos automático.

De hecho, ¿sabes cómo obtener en Visual Studio Code un mejor Intellisense para JavaScript? Pues poniendo el comentario //@ts-check en la primera línea de tus archivos .js. Si partimos del hecho de que el código JavaScript es código TypeScript válido, lo puede compilar como TypeScript y usar tsserver por detrás 😉

Ventajas de TypeScript

Podemos resumir las principales ventajas de TypeScript en esta lista:

Es fácil de aprender , y todo el equipo puedo ponerse al día con él en poco tiempo. Aunque antes se debe conocer a fondo JavaScript, o sea, que no es para principiantes.
Convierte a JavaScript en un lenguaje "adulto" , equiparable en muchos aspectos con Java o C#. De hecho, puedes empezar poco a poco: escribiendo JavaScript y añadiendo paulatinamente TypeScript mezclado con el anterior, ya que es 100% compatible con JS.
Permite desarrollar sin preocuparse por el soporte de ciertas características nuevas que se incorporan a las diferentes versiones de ECMAScript, ya que luego se traduce el código para que funcione con versiones más antiguas.
Mejora la ayuda contextual mientras escribes código, ya que es más rico en información que JavaScript. En editores que lo soportan (y hay muchos), notarás una gran diferencia y disminuirá los errores que cometas tú y tu equipo.
Permite crear código estandarizado en todo el equipo de trabajo, dejando mucho menos margen para los problemas y para hacerlo crecer en el futuro a medida que haya mejor soporte nativo en los navegadores para ciertas características.
Funciona bien con las librerías y frameworks de Front-End que estés utilizando. Algunas, como Angular, Ember o Aurelia le sacan especial partido, e incluso el uso combinado de TypeScript + React se está convirtiendo en norma.

Desventajas de TypeScript

No todo iba a ser maravilloso (aunque la mayoría sí). Veamos las principales "pegas":

La curva de aprendizaje es mayor que la de JavaScript. No es que sea especialmente complejo, pero desde luego no es como un lenguaje de scripting normal. Para empezar necesitas conocer bien JavaScript, pues en el fondo está basado en éste. Pero además implementa muchos otros conceptos avanzados propios de otros lenguajes como C# o Java, por lo que algunas cosas pueden llegar a costar a los que vienen tan solo de un background en Web. De todos modos se puede aprender rápido.
Sistema de tipos algo complicado. Precisamente su principal ventaja, el tipado fuerte, es también fuente de frustración puesto que si quieres sacarle todo el partido te obliga a anotar los tipos en todas partes (puede resultar tedioso) y resta de la innegable flexibilidad que tienen los tipos débiles de JavaScript. Obviamente cada enfoque tiene sus ventajas e inconvenientes, y encontrar el equilibrio entre ambos puede ser complicado.
Se debe compilar. TypeScript, como ya he dicho antes, no es un lenguaje soportado directamente por los navegadores y por lo tanto se debe transpilar a JavaScript/ECMAScript convencional antes de desplegarlo. Eso añade un paso más al trabajo normal, aunque por supuesto se automatiza en todas las ocasiones, bien directamente el compilador nativo del lenguaje (`tsc --watch), o bien mediante el tooling normal: npm, Grunt o Webpack entre otras herramientas. De esta manera es casi transparente para nosotros.
Archivos .d.ts : para trabajar de la mejor forma posible con bibliotecas/módulos de terceros es necesario disponer archivos de "definición de ambiente" (con extensión .d.ts) y no todas los tienen o no son de la calidad que cabría esperar.
Falsa sensación de seguridad. Como TypeScript te da comprobación de tipos en tiempo de compilación y detecta muchos posibles errores antes de que ocurran, alguno programadores llegan a pensar que el código TypeScript es seguro al 100% y no les va a dar problemas al desplegarlo si ha compilado bien. Pero se olvidan de que por debajo sigue estando JavaScript, así que puede pasar de todo. Desde luego la seguridad del código va a mejorar, pero no es infalible.

Entonces ¿uso JavaScript o TypeScript?

A ver, como en tantas otras cosas, no se puede afirmar nada con total rotundidad, pero una buena regla aproximativa sería que para proyectos pequeños usar TypeScript es un poco "matar moscas a cañonazos", por lo que quizá no merezca la pena.

Ahora bien, en proyectos medianos o grandes , y sobre todo si están involucradas varias personas, escribir el código en TypeScript ofrece grandes ventajas (ver más arriba) que se van a notar a corto y a largo plazo.

Si trabajas con Angular y otros frameworks similares , usar TypeScript es casi una obligación. De hecho, en el caso de Angular, estás escrito en este lenguaje y la documentación promueve claramente su uso. Además casi toda la literatura, posts y ejemplos están escritos con TypeScript.

Por eso mi consejo sería que aprendieses TypeScript para ver qué valor le puedes sacar. La mayor parte de los que empiezan a programar con el lenguaje enseguida se vuelven "dependientes" y acaban por usarlo para casi todo.

¡Espero que te resulte útil!

Java: ¿Por qué no me funciona la comparación de cadenas? Literales, clases y el repositorio de cadenas

José M. Alarcón 🌐 — Wed, 13 Nov 2019 08:00:00 +0000

Una pregunta habitual de los que comienzan con Java (e incluso en entrevistas de trabajo para puestos que usan este lenguaje) tiene que ver con las comparaciones entre cadenas de texto. Si vienes de otros lenguajes puedes estar acostumbrado a comparar cadenas con el operador igualdad == o, simplemente, te puede parecer la forma más evidente y obvia de hacerlo.

Sin embargo, consideremos un código como este:

String s1 = new String("campusMVP");
String s2 = new String("campusMVP");
System.out.println(s1 == s2); //Devuelve false

Aunque las cadenas son idénticas y obtienes dos objetos String idénticos, la comparación devuelve false 🤔

En este otro ejemplo similar:

String s1 = "campusMVP";
String s2 = new String("campusMVP");
System.out.println(s1 == s2); //Devuelve false

devuelve false también.

Sin embargo esto:

String s1 = "campusMVP";
String s2 = "campusMVP";
System.out.println(s1 == s2); //Devuelve true

devuelve true.

Es más, un caso más común sería el de comparar el resultado de una función que devuelve una cadena, con otra cadena cualquiera. Algo así:

String s1 = "OK";
if (s1 == FuncionQueDevuelveCadena()) {
    System.out.println("¡Coinciden!");
}
else {
    System.out.println("No coinciden"));
}

Bien, lo curioso del fragmento anterior es que, dependiendo de lo que haga la función y aunque la cadena devuelta sea exactamente la misma en ambos casos, el resultado puede ser true o false.

¿A qué es debido esto?

El funcionamiento de las cadenas en Java - Repositorio o `Pool` de cadenas

Las cadenas en Java son una especie aparte. Tienen muchos detalles que es preciso conocer para entenderlas (por ejemplo, que son inmutables, o Final en Java, o que internamente se pueden codificar en memoria de varias formas). Conocerlas bien es un paso indispensable para dominar el lenguaje.

Un concepto sencillo una vez que lo entiendes, pero que no todo el mundo tiene claro es la forma de instanciarlas dependiendo de cómo se declaren.

Básicamente tenemos dos maneras de declarar una cadena: con un literal o instanciando una clase:

String literal = "campusMVP";
String clase = new String("campusMVP");

En ambos casos lo que obtenemos es lo mismo: una clase String con una cadena dentro (que no es más que una matriz de caracteres en memoria). Sin embargo, hay una gran diferencia entre hacerlo de una forma o la otra.

Cuando se declara una cadena de manera literal por primera vez, la JVM la coloca en un espacio especial denominado repositorio de cadenas ( string pool en inglés). Este repositorio contiene una copia única de las diferentes cadenas declaradas como literales en el código. Aquí la palabra importante es "única". Como las cadenas son inmutables, si declaras más de una vez la misma cadena no tiene sentido tenerla varias veces en memoria, así que la siguiente vez que la declares lo que hace la JVM es ir al repositorio de cadenas y localizarla, devolviendo una referencia al mismo objeto String que en la primera declaración. OJO: es el mismo objeto, no una copia. Por eso al escribir esto:

String s1 = "campusMVP";
String s2 = "campusMVP";
String s3 = new String(s1);
System.out.println(s1 == s2); //true
System.out.println(s1 == "campusMVP"); //true

En todos los casos la comparación se realiza con éxito. Lo que ocurre es que en todos los casos se usa el mismo objeto String exactamente. En la línea 1, en la primera declaración, se almacena en el repositorio de cadenas. En la línea 2, la segunda declaración del literal, la JVM va al repositorio y mira si ya existe la misma cadena de antes. Como en este caso sí que existe, lo que hace es devolver una referencia a la misma cadena que en la línea 1. ¡Por eso son iguales! Porque no solo representan los mismos caracteres, sino que son de hecho la misma clase (y apuntan a la misma matriz en memoria). En la línea 4, cuando se hace la comparación en s1 y el mismo literal, vuelve a pasar lo mismo: la JVM localiza el literal en el repositorio de cadenas y devuelve la misma referencia, por eso es true de nuevo.

Se puede ver visualmente mejor en esta figura, que trata de representar la situación:

Esto funciona incluso con la combinación de varios literales. La JVM es lo suficientemente inteligente como para hacer que estas dos cadenas sean la misma:

String s1 = "campusMVP";
String s2 = "campus" + "MVP";
System.out.println(s1 == s2); //true

A pesar de que podría parecer que hay 3 cadenas en el repositorio de cadenas, y que devolvería dos objetos diferentes.

Declaración de cadenas como clases

Sin embargo, cuando declaramos una cadena usando una clase (con new String()), la operación es diferente. Lo que se hace es asignar en memoria el espacio necesario para la cadena y devolver la clase que permite manejarla. No se pasa por el repositorio de cadenas para nada.

Por ello este fragmento:

String s1 = new String("campusMVP");
String s2 = new String("campusMVP");
System.out.println(s1 == s2); //Devuelve false

devuelve false en la comparación. Se trata de dos cadenas diferentes, aunque internamente representen los mismos caracteres:

Nota : lo sé, es absurdo declarar cadenas de esta manera envolviendo un literal con una clase String. Y de hecho, raramente lo verás hecho por ahí. Pero es que hay infinidad de maneras de obtener clases String en una variable: desde transformar un literal hasta sacarlas de una base de datos. Solo pongo el ejemplo de esta manera para que se entienda lo que quiero explicar, no para indicar que esta es una manera recomendada de declarar las cadenas.

¿Qué ocurre si tenemos dos cadenas literales y queremos compararlas con == sin considerar mayúsculas y minúsculas?

Podríamos hacer esto:

String s1 = "campusMVP";
String s2 = "campusMVP";
System.out.println(s1.toLowerCase() == s2.toLowerCase()); //false!

En este caso la comparación devuelve false, ya que lo que obtenemos son dos cadenas idénticas pero representadas por dos objetos diferentes. El operador == compara referencias a objetos y en este caso, aunque los datos que contienen son los mismos, no se trata del mismo objeto. Incluso siendo s1 y s2 el mismo objeto String,la operación toLowerCase() lo que hace es generar una nueva cadena a partir de la misma cadena original, pero se trata de dos objetos String diferentes en memoria. Es como el caso anterior. Al no ser literales, no se obtienen desde el repositorio de cadenas aunque ya existan allí.

Por eso es tan peligroso comparar cadenas con ==. Aunque las cadenas sean idénticas, como lo que se comparan son referencias a objetos String y no el valor subyacente, solo devuelven true para cadenas iguales cuando se refieren al mismo literal.

Conclusión : no utilices nunca el operador == para comparar cadenas si quieres hacerlo bien en Java.

Y entonces ¿cómo comparo cadenas con seguridad?

Pues con el método equals() que tienen todos los objetos. De hecho, es heredado de Object, la clase base "raíz" de todas las existentes. Este método lo que hace es comparar el estado interno de dos objetos para ver si son iguales, mientras que == lo que hace es comparar las referencias.

En el caso de las cadenas, lo que hace es comparar que las dos matrices de caracteres que contienen los objetos String que comparamos sean iguales, que es realmente lo que nos interesa por regla general.

Así, para comparar dos cadenas cualquiera con seguridad debes usar este método:

String s1 = new String("campusMVP");
String s2 = new String("campusMVP");
System.out.println(s1.equals(s2)); //Devuelve true
System.out.println(s1.equals("campusMVP")); //Devuelve true
System.out.println("campusMVP".equals(s1)); //Devuelve true

Pero es que da igual cómo obtengamos la cadena final : siempre devuelve true si las cadenas que representan los dos objetos son iguales, por ejemplo:

String s1 = new String("campusMVP");
String s2 = new String("CAMPUSMVP");
System.out.println(s1.equals("campus" + "MVP")); //Devuelve true
System.out.println(s1.toLowerCase().equals(
            s2.toLowerCase()
        )); //Devuelve true

En este caso sí que podemos comparar las dos cadenas en minúsculas para ver si son iguales.

Conclusión 2 : las comparaciones de cadenas en Java hazlas siempre con equals().

"Internalizando" objetos de tipo cadena

Esto es ya casi una curiosidad más que otra cosa. Pero es que, aunque no es algo que se use muy habitualmente, existe la posibilidad de hacer que los objetos de tipo String que tengamos se "internalicen" de modo que pasen a formar parte del pool de cadenas de texto, como si los hubiésemos declarado como literales.

Esto se consigue gracias al método intern() que tienen las cadenas. Lo que hace este método es lo mismo que ocurre cuando se declara una cadena literal: va al repositorio de cadenas y mira si ya existe la misma cadena ahí (en caso negativo la crea), y devuelve como resultado una referencia a la cadena preexistente, en lugar de crear una nueva.

Si llamamos a intern(), así, por ejemplo esto:

String s1 = new String("campusMVP");
String s2 = new String("campusMVP");
System.out.println(s1.intern() == s2.intern()); //Devuelve true

Devolverá true ya que intern() devuelve como resultado de la llamada la misma referencia a la misma cadena del pool de cadenas.

Es decir, intern() lo que hace es desligar el objeto de los datos originales y asignarle el mismo dato que hay en el repositorio de cadenas. Visualmente sería algo así (fíjate en la cadena s3):

¿Para qué vale esto de intern()? Bueno, como decía, realmente pocas veces lo vas a utilizar, pero esto podría ayudarte a ahorrar mucha memoria en los casos en los que vas a generar muchas cadenas y un gran número de las cuales van a ser iguales.

Por ejemplo, imagínate que vas a obtener desde una base de datos muchos miles de registros de pedidos de clientes, y que tienes un número bastante limitado de clientes y de productos, lo que pasa que hacen muchos pedidos de lo mismo. "Internalizando" las cadenas evitarías tener los mismos nombres de cliente y de pedidos duplicados miles de veces en memoria, dejando tan solo unas pocas copias de los mismos dentro del repositorio de cadenas y ahorrando potencialmente mucha memoria, sobre todo si los nombres son largos.

Como nota técnica adicional sobre esto decir que, hasta Java 7, ya hace muchos años (se lanzó en 2011), el espacio disponible para almacenar las cadenas en el pool era limitado y además no entraba dentro de la recolección de basura. Eso significaba que si abusabas mucho del "interning" podrías acabar con una excepción de tipo OutOfMemory, lo cual podría provocar un desastre en tu aplicación. Es por esto que en muchos artículos que encontrarás por ahí sobre este tema, y que están anticuados, te recomiendan no usar intern(). La realidad es que, a partir de Java 7, y por lo tanto en la práctica totalidad de las aplicaciones Java que vas a encontrar por ahí, el repositorio de cadenas se guarda ya en el "montón" (o heap) (es decir, en memoria dinámica), por lo que no hay problemas de límites y además puede ser reclamada por el recolector de basura. Además en Java 13 (de septiembre de 2019) se permite también la devolución al sistema operativo de memoria dinámica no utilizada, con lo que incluso está más optimizado.

En resumen

Las cadenas de texto son "bichos raros" en casi todos los lenguajes, pero en Java especialmente, al poder actuar a la vez como literales y como objetos, pero al mismo tiempo presentan diferencias a la hora de utilizarlas y en especial de compararlas.

Por ello las comparaciones de cadenas deben evitar el uso del operador == (que compara referencias de objetos y no sus datos) y emplear en cambio el método equals(). Además es importante conocer el funcionamiento interno de las cadenas, las implicaciones que tiene y cómo podemos optimizar el uso de memoria cuando manejamos cadenas de gran tamaño (o muchas) con valores idénticos.

Te de dejado un pequeño patio de juegos para que puedas comprobar el funcionamiento de todo lo explicado y probar a realizar cambios y ver cómo funcionan.

¡Espero que te resulte útil!

Intl: la API de localización nativa de JavaScript

José M. Alarcón 🌐 — Tue, 30 Jul 2019 22:54:00 +0000

Artículo publicado originalmente en JASoft.org

Como seguramente ya tengas claro, la traducción y la localización son conceptos relacionados pero muy distintos.

Para traducir tu aplicación basada en Web mucho me temo que no te queda más remedio que usar archivos de lenguaje de algún tipo y alguna biblioteca especializada. Sin embargo para la localización , es decir, la adaptación de la aplicación a las particularidades de cada idioma, todo lo que necesitas viene incluido con tu navegador.

El objeto Intl

Mucha gente no lo sabe, pero JavaScript dispone de un objeto global específico para ayudarnos con la localización de aplicaciones a otros idiomas y culturas: Intl :

Podemos usar sus diferentes objetos asociados, mostrados en la figura anterior, para averiguar mucha información sobre localización en cualquier idioma.

Vamos a verlos...

Intl.Collator: para comparar cadenas de texto

El objeto Collator sirve para hacer comparaciones de cadenas teniendo en cuenta las particularidades locales.

Raramente se utiliza ya que no suele ser necesario, gracias a que la clase string tiene un método específico para llevar a cabo este tipo de comparaciones: localeCompare().

Solo lo utilizaremos si tenemos que realizar muchísimas comparaciones en un bucle o algo así (algo muy poco habitual), ya que nos daría más rendimiento. En el resto de los casos puedes hacer caso omiso de él.

Intl.DateTimeFormat: para dar formato a fechas y horas

Como su propio nombre sugiere, nos ayuda a dar formato a las fechas y las horas según las particularidades de cada país.

Como todos los objetos de Intl se instancia pasándole como argumento una cadena de texto en formato IETF BCP 47, que suena muy complicado pero en general no es más que el nombre abreviado internacional del idioma (es, en, it...) para idiomas genéricos, o lo anterior seguido de un guión y la abreviatura del país/cultura en mayúscula (es-ES, es-AR, en-US, en-UK...). Como ves, muy fácil.

Así que, por ejemplo, para obtener una fecha bien formateada en varios idiomas sólo tenemos que hacer esto:

var fecha = new Date(2019, 6, 30, 16, 30, 0);
var dtfEs = new Intl.DateTimeFormat('es-ES');
var dtfEnUs = new Intl.DateTimeFormat('en-US');
var dtfArMa = new Intl.DateTimeFormat('ar-MA');
console.log(dtfEs.format(fecha));
console.log(dtfEnUs.format(fecha));
console.log(dtfArMa.format(fecha));

que nos devolverá por consola esa fecha (29 de julio de 2019, fíjate en que los meses se numeran desde el 0) en español, inglés americano y árabe de Marruecos (que tienen un formato bien complicado):

Fíjate en que no nos devuelve la hora, ni tampoco hemos podido controlar el formato exacto de cada componente que queremos obtener. Eso lo controlaremos gracias a las opciones del constructor , que he omitido en el fragmento anterior.

Todos los objetos de Intl tienen un segundo argumento opcional para las opciones (valga la redundancia). En el caso de DateTimeFormat tiene un montón de propiedades posibles que no voy a detallar porque las tienes en la MDN. Pero vamos a ver un ejemplo de cómo usarlos:

var fecha = new Date(2019, 6, 30, 16, 30, 0);
var opciones = {
        weekday: 'long',
        month: 'long',
        year: 'numeric',
        hour: '2-digit',
        minute: '2-digit',
        second: '2-digit',
        timeZoneName: 'long'
    };
var dtfEs = new Intl.DateTimeFormat('es-ES', opciones);
var dtfEnUs = new Intl.DateTimeFormat('en-US', opciones);
var dtfArMa = new Intl.DateTimeFormat('ar-MA', opciones);
console.log(dtfEs.format(fecha));
console.log(dtfEnUs.format(fecha));
console.log(dtfArMa.format(fecha));

con el resultado siguiente:

Fíjate en que este código es exactamente igual al anterior solo que le hemos pasado como segundo argumento del constructor un objeto con las opciones pertinentes. Al haber especificado el formato en el que nos interesaba cada componente de la fecha, incluyendo las horas (para que las muestre), lo ha transformado adecuadamente y con las palabras apropiadas en cada idioma, e incluso escrito de derecha a izquierda en el caso del árabe de Marruecos.

Si queremos podemos utilizar el método formatToParts() para obtener cada una de las partes de la fecha, de modo que podamos utilizarlas en cualquier formato personalizado si lo necesitásemos (aunque no te lo recomiendo, pues para eso tienes las facilidades que da el objeto, sin recurrir a formatos propios):

y podemos, en cada idioma, obtener exactamente cada parte de la cadena final, en función de las opciones que hayamos elegido.

Intl.RelativeTimeFormat: para facilitar la lectura de intervalos de tiempo relativos

Otra necesidad muy común en la mayor parte de las aplicaciones es la de expresar intervalos de tiempo relativos a la fecha actual. Por ejemplo, si tenemos un listado de tareas, en la columna de la fecha de vencimiento podemos poner tal cual la fecha o bien ser mucho más amigables para el usuario y escribir cosas como "Vence en 3 días" o "Caducada hace 5 horas"...

Esto es mucho más complicado de hacer de lo que parece de una manera consistente, y si además debemos hacerlo en varios idiomas no te quiero ni contar. Por suerte Intl nos ofrece también funcionalidad apropiada para lograrlo de manera sencilla.

Al igual que antes, lo único que tenemos que hacer es instanciar la clase pasándole el identificador del idioma a utilizar para la localización:

var rtf = new Intl.RelativeTimeFormat('es-ES');

Ahora podemos obtener los intervalos apropiados en ese idioma llamando al método format(), y pasándole el número de intervalos y el tipo de intervalo, que es una cadena en ingles. Por ejemplo:

rtf.format(1, 'day') //dentro de 1 día
rtf.format(-3, 'day') //hace 3 días
rtf.format(0, 'day') //dentro de 0 días
rtf.format(5, 'hour') //dentro de 5 horas

Esto es genial y ahorra muchas KB de bibliotecas JavaScript que ya no tendremos que descargarnos.

Ademñas, en el constructor podemos establecer algunas opciones para especificar cómo queremos que generen esos intervalos. Por ejemplo, a mi no me gusta el estilo por defecto que tienen, usando siempre números, así que lo puedo cambiar estableciendo la propiedad numeric como 'auto':

var rtf = new Intl.RelativeTimeFormat('es-ES', { numeric: 'auto' });

y así conseguir que, por ejemplo, si es algo de hace un día ponga "ayer" y si es en un día obtenga "mañana", haciéndolo aún más natural:

Como vemos, de gran utilidad.

Como antes, también existe el método formatToParts() para obtener una matriz con cada uno de los fragmentos del formato por separado.

Intl.NumberFormat: para dar formato a números y dinero

Seguimos con necesidades habituales de localización, en este caso con los números. Como sabes, cada idioma tiene formatos diferentes para muchas cosas con los números y las cantidades monetarias. Por ejemplo, en España los separadores de mil son puntos y el decimal es una coma, y la moneda se pone trás la cantidad. Sin embargo en EEUU es justo al revés: los miles se separan con comas, los decimales con puntos y la moneda va delante de la cantidad.

¿Cómo gestionamos esto de manera sencilla para cualquier idioma del planeta? Antes era complicadísimo. Ahora es muy sencillo gracias a Intl.NumberFormat.

Como todos los anteriores se instancia pasándole una cadena con el idioma (si no ponemos nada se usará el idioma del sistema operativo):

var nfEs = new Intl.NumberFormat('es-ES');
var nfEn = new Intl.NumberFormat('en-EU');
var nfFr = new Intl.NumberFormat('fr');
console.log(nfEs.format(123456.78));
console.log(nfEn.format(123456.78));
console.log(nfFr.format(123456.78));

y como podemos comprobar genera los separadores en el formato adecuado a cada caso:

Fíjate en cómo los franceses utilizan com separador de miles un espacio, por ejemplo.

En cuanto a las opciones podemos establecer incluso el sistema de numeración que no tiene por qué sel arábigo, el tipo de moneda si va a ser una cantidad de dinero, y también la forma de nombrar las monedas, entre otras muchas opciones. La más importante es style que nos permite seleccionar si queremos mostrar decimales ('decimal', valor por defecto), monedas ('currency') o porcentajes ('percent').

Por ejemplo, para mostrar una cantidad en euros o dólares escribiríamos:

var nfEs = new Intl.NumberFormat('es-ES', {style: 'currency', currency: 'EUR'});
var nfEn = new Intl.NumberFormat('en-EU', {style: 'currency', currency: 'USD'});
var nfFr = new Intl.NumberFormat('fr', {style: 'currency', currency: 'EUR', currencyDisplay: 'name'});
console.log(nfEs.format(123456.78));
console.log(nfEn.format(123456.78));
console.log(nfFr.format(123456.78));

Fíjate en cómo adapta perfectamente el formato a cada idioma y cómo además usa el símbolo o el nombre según las opciones indicadas:

Intl.ListFormat: par dar formato a listas

Otra necesidad clásica en las aplicaicones: partir de una lista o array de elementos y generar una lista legible para cada idioma.

Por ejemplo, si tenemos esta matriz, que generalmente en una aplicación la habremos obtenido de un servicio remoto:

var beatles = ['John', 'Paul', 'George', 'Ringo'];

y queremos meterlos en una lista amigable para el usuario para formar la frase: 'Los Beatles eran John, Paul, George y Ringo'. Algo tan simple como esto requiere bastante trabajo si queremos adaptarlo a diversos idiomas. No todos usan las comas para separar y desde luego el último elemento no tiene que ser un "y" tampoco.

Con Intl.ListFormat la cosa es muy sencilla:

var beatles = ['John', 'Paul', 'George', 'Ringo'];
var lfEs = new Intl.ListFormat('es-ES');
var lfDe = new Intl.ListFormat('de-DE');
console.log(lfEs.format(beatles));
console.log(lfDe.format(beatles));

Como vemos nos devuelve la lista formateada para cada localización, incluyendo en este caso la palabra "y" en el idioma correspondiente:

Por supuesto no siempre querremos que la lista sea inclusiva, sino que a veces podemos necesitar que sea una lista de opciones y que ese "y" se convierta en un "o", por ejemplo. Para cambiar este comportamiento en las opciones del constructor tenemos la propiedad type que puede tomar los valores:

'conjunction', para listas de tipo "y"
'disjunction' para listas de tipo "o"
'unit' si la lista es de unidades de medida, que se suelen poner en forma de lista de modo diferente.

Así, con la lista anterior podemos poner esto:

var beatles = ['John', 'Paul', 'George', 'Ringo'];
var lfEs = new Intl.ListFormat('es-ES', {type:'disjunction'});
var lfDe = new Intl.ListFormat('de-DE', {type:'disjunction'});
console.log(lfEs.format(beatles));
console.log(lfDe.format(beatles));

para tenerla de tipo "o":

Si fuesen unidades, por ejemplo la longitud de una viga en una aplicación de construcción pondríamos:

var medidas = ['3 metros', '12 centímetros'];
var lfEs = new Intl.ListFormat('es-ES', {type:'unit'});
var lfDe = new Intl.ListFormat('de-DE', {type:'unit'});
console.log(lfEs.format(medidas));
console.log(lfDe.format(medidas));

Fíjate en un detalle importante: aunque la localización ha funcionado perfectamente porque las listas tienen el formato adecuado para cada idioma, la traducción está mal ya que en alemán sigue poniendo las medidas en español. Obviamente esto no es responsabilidad de Intl ya que se trata de traducción y es responsabilidad de la aplicación. Antes de crear la lista de cadenas deberemos asegurarnos de que las medidas están en el idioma apropiado.

Hay algunos parámetros más para las opciones del constructor, pero lo importante es lo que hemos visto.

Intl.PluralRules: para pluralización

Esta ya es una característica avanzada. Al contrario que las otras claes que hemos visto no está pensada para pasarle una cadena y que nos las devuelva en plural, sino que es a más bajo nivel. Lo que hace es facilitarnos la forma de plural que corresponde a cada número que se le pase a su método select().

Por ejemplo, en español, inglés u otros idiomas occidentales una viga mide 1 metro (singular), 3 metros (plural) o, curiosamente, 0 metros (plural aunque sea cero). Sin embargo en árabe tiene otras acepciones para ciertos números.

Si lo probamos con la clase PluralRules:

var prEs = new Intl.PluralRules('es-ES');
var prMa = new Intl.PluralRules('ar-MA');
console.log('ESPAÑOL:');
console.log(prEs.select(0));
console.log(prEs.select(1));
console.log(prEs.select(3));
console.log(prEs.select(0.5));
console.log('ÁRABE:');
console.log(prMa.select(0));
console.log(prMa.select(1));
console.log(prMa.select(3));
console.log(prMa.select(0.5));

veremos lo siguiente:

Como puedes observar, para los idiomas occidentales generalmente hay dos posibilidades: 'one' (singular) o 'other' (plural), y con eso podemos decidir si se le pone una "s" al final o no.

Nota : lo anterior es una simplificación enorme ya que en español es mucho más complicado que eso. A veces el plural lleva "s" (gato, gatos), otras veces lleva "es" (flor, flores) y otras veces no lleva nada (¿cuál es el plural de "virus" en español? Pues "virus" también porque es invariable en plural, al contrario que en inglés, que es "viruses"). En ese sentido otros idiomas como el inglés son mucho más sencillos.

Pero en otros idiomas la cosa es mucho más complicada, como puedes comprobar con el árabe.

Por lo tanto, aunque está bien disponer de esta funcionalidad para algunas aplicaciones muy concretas, no nos va a servir de gran ayuda a la hora de generar plurales "serios", así que generalmente no lo vas a utilizar.

Soporte

El soporte actual de navegadores es ya universal desde hace años, por lo que no deberías tener problemas para usarla. La excepción, como casi siempre, es Internet Explorer, pero incluso éste tiene soporte para la mayor parte de las clases en su versión 11. En esta tabla de MDN tienes un buen resumen detallado del soporte específico por clase y navegador.

También tienes un polyfill que puedes utilizar si fuese necesario en estos navegadores antiguos, aunque no es tan potente.

En resumen

Para casi todas las tareas comunes relacionadas con la localización de aplicaciones, JavaScript nos proporciona ayuda integrada y no vamos a necesitar utilizar bibliotecas externas que añaden complejidad, peso y que además con toda seguridad no serán tan buenas como el sistema operativo para estos menesteres. Dado que la API de internacionalización de JavaScript, a través del objeto global Intl, utiliza por debajo los servicios del sistema operativo para conseguirlo, podemos garantizar resultados rápidos y correctos.

Deberíamos acostumbrarnos a usa esta API ya que nos ayudará a conectar mejor con nuestros usuarios y a hacer las aplicaciones más amigables.

Por cierto, si te ha gustado este artículo, te encantará lo que puedes aprender con mi curso de JavaScript avanzado en campusMVP. Anímate a aprender JavaScript en serio y dejar de "tocar de oído" 😊 Además tendrás vídeos prácticos, prácticas sugeridas, evaluaciones, referencias cruzadas, hitos de aprendizaje.... y tendrás contacto directo conmigo y con el fenómeno Eduard Tomàs para contestar todas tus dudas y seguir tu progreso.

¡Espero que te sea útil!

Artículo publicado originalmente en JASoft.org

Los mejores editores gratuitos de HTML, CSS y JavaScript (2019)

José M. Alarcón 🌐 — Tue, 28 May 2019 10:00:00 +0000

Hace 5 años, en mayo de 2014, escribí un artículo que enseguida se convirtió en uno de los más populares de nuestro blog en campusMVP y de los más populares sobre el tema en Internet. Se titulaba "Los 10 mejores editores gratuitos (o casi) de HTML, CSS y JavaScript" y, como su propio nombre indica, nos mostraba una selección de editores de código para la Web que podíamos utilizar gratuitamente.

Desde entonces las cosas han cambiado mucho. Ya en 2013 la revista Mashable sentenció que era el año del Responsive Web Design, aunque en España empezó a explotar en 2014, más o menos cuando escribí ese artículo. La realidad actual es que el RWD es inherente al diseño web y hoy en día es inimaginable diseñar una web sin usarlo.

¿Y qué tiene esto que ver con los editores? Pues que hace 5 años, sobre todo si eras un principiante, podías permitirte el lujo de utilizar algún tipo de diseñador visual para crear tus páginas o aplicaciones web. Hoy en día es inviable. Vamos, puedes hacerlo, y de hecho la mayor parte de los editores que puse en aquel artículo siguen funcionando, pero no te van a servir de mucho.

Adiós al diseño visual

Los diseños web actuales se realizan de manera que los elementos se distribuyen de forma totalmente diferente según el ancho del viewport del dispositivo en el que se estén visualizando. Ello implica que no podemos hacer un diseño "visual" distribuyendo los elementos y dejándolos en una posición fija, sino que el diseño parte normalmente de los tamaños de pantalla más pequeños (móviles) y se van variando a medida que crecen éstos:

El diseño web responsivo (y el diseño web adaptativo) requiere escribir el código en el editor, tanto el HTML como el CSS y las media queries correspondientes, y luego ir comprobando en un navegador real el efecto de cada cambio. Gran parte de las veces lo que haces es retocar en tiempo real propiedades CSS usando las herramientas del desarrollador del navegador para afinarlo (por suerte hoy en día los navegadores te dejan enlazar estas herramientas con los archivos originales, y que esos cambios se vean al mismo tiempo en aquéllos también, y por lo tanto en el editor).

Hoy, más que nunca, el diseño/desarrollo web es una disciplina técnica que requiere escribir código, y no arrastrar y soltar o ver en tiempo real cómo quedan las cosas.

Este es el principal motivo de que aquella lista hoy en día sea obsoleta y sobren la mitad de las opciones que proponía por aquel entonces, especialmente los que hacían hincapié en el diseño visual como Kompozer (cuya página ya ni funciona) o BlueGriffon (que se ha convertido en una herramienta para crear eBooks y ya no es gratuito).

Además, algunos que en aquella época eran lo máximo han ido cayendo un poco en desgracia por la aparición de nuevos productos que se han hecho con el interés de los desarrolladores. En mi opinión, el gran ganador en ese sentido ha sido Visual Studio Code , y los perdedores Sublime Text y Atom.

Con todo esto en mente os voy a dejar a continuación una lista, más corta, de mis editores de código gratuitos preferidos para HTML/CSS y JavaScript según tres categorías (uso general, aprendizaje y cloud). En mi humilde opinión son los mejores en cada caso, dentro de los editores gratuitos. Existen algunos de pago, fundamentalmente WebStorm de Jetbrains y quizá Dreamweaver de Adobe solo para diseño web, que son buenísimos pero se salen de esta premisa de la gratuidad.

Nota : antes de que me digas que este o aquel editor que te gusta tanto no está en la lista ten en cuenta una cosa: es mi lista, la de mis editores favoritos por diversos motivos, y puede que no los conozca todos o quizá no veo las cosas de la misma manera que tú, pero no es por mala intención o dejadez, sino que es mi lista personal e intransferible. Ahora bien, estaré encantado de que dejes un comentario en la parte de abajo hablando de tu editor favorito que no está en la lista y por qué consideras que debería estar. ¡Gracias!

¡Allá vamos!

Uso general: Visual Studio Code - El mejor para el día a día y para hacer de todo

He de confesar que cuando salió no hubiera apostado casi nada por él y pensé que iba a ser otro de tantos productos fallidos de Microsoft intentando ser "cool". No podía estar más equivocado. Con el tiempo VSCode se ha convertido en el editor , y ya es el más utilizado por desarrolladores de todo tipo.

Es gratuito, de código abierto, multiplataforma (Windows, Linux, macOS, ARM y ahora también Web), ágil, rápido y súper-potente. Además tiene infinitas extensiones para poder ampliar su funcionalidad sin que pierda la ligereza que lo caracteriza, e integra soporte para las herramientas más habituales (desde Git o la línea de comandos integrada, hasta Docker).

No solo se puede usar para programar HTML, CSS y JavaScript, sino que tiene un gran soporte (nativo o con extensiones) para infinidad de lenguajes: plataforma .NET y C#, Node.js, PHP, Java, Python, C++, Go... además de buen soporte para bibliotecas JavaScript como Angular, Vue.js o React, y no solo para programación. Por ejemplo, este artículo lo estoy escribiendo en Markdown usando Visual Studio Code. Prácticamente lo uso para todo en la actualidad, y además lo sincronizo entre todos mis equipos. Su soporte para Live Share incluso te permite trabajar con otros desarolladores en tiempo real en el mismo código.

En lo que se refiere a HTML, CSS y JavaScript en concreto ofrece grandes características como, por supuesto, la completitud automática de código, soporte para emmet/zencoding, ayuda contextual a medida que escribes, selectores de colores, refactorización de código, depuración sin salir de la herramienta, soporte para Live Server (servir y recargar automáticamente las páginas mientras las editas, con una extensión) y mil cosas más. Demasiadas para enumerarlas.

Por todo ello, hoy por hoy, Visual Studio Code es mi editor principal y el que recomendaría en casi todos los casos a cualquiera.

Aprender: Brackets - Ideal para principiantes

Aunque este editor creado por Adobe no es tan conocido como otros, se lo suelo recomendar a mis alumnos que están empezando con HTML y CSS porque es un editor muy enfocado en estos lenguajes, además de en JavaScript y con algunas facilidades especialmente interesantes para enfocarte mientras comienzas.

Aparte de las características habituales (ayuda contextual a la escritura, auto-cierre de etiquetas, etc...) posee tres características que lo hacen especialmente interesante para este perfil de iniciación:

Live preview : integra una combinación de teclas, CTRL+E, que si la pulsas cuando estás sobre una clase CSS en una etiqueta o sobre una función JavaScript, te muestra directamente en línea, sin cambiar de editor, la definición de la misma permitiéndote además editarla:

Fueron unos de los pioneros en esto y, aunque pueda parecer algo menor, el hecho de que lo traiga integrado resulta muy cómodo y ayuda mucho cuando estás empezando (en VScode lo puedes conseguir también con la extensión CSS Peek aunque no está tan logrado, y es nativo en el caso de JavaScript).

Vista previa de los cambios en tiempo real. Basta pulsar un botón para que se abra el navegador y se empiece a servir la página, quedando ésta enlazada con el editor. De este modo, cada vez que hagas cualquier cambio (aún sin grabarlo), se verá reflejado en tiempo real en el navegador, sin necesidad de refrescar. Esto se puede hacer también con otros editores como VSCode, pero necesitas una extensión y es más complicado. Nuevamente un "win" para los principiantes.
Soporte de serie para preprocesadores CSS (SASS y Less): si además de CSS estás aprendiendo a sacarle partido a estas potentes herramientas, te vendrá muy bien, y nuevamente sin necesidad de extensiones o herramientas externas.

Tiene también posibilidades de refactorización de código JavaScript, y bastantes extensiones (aunque ni de lejos las de VScode) pero quitando dos o tres (Emmet, Git o Beautify, por ejemplo) no merece la pena instalarlas ya que su virtud está precisamente en lo que trae de serie para principiantes.

Cloud: JSBin - Editor online para pruebas, experimentos y compartir ejemplos

En la actualidad es casi tan importante escribir código como compartirlo. Por eso, los editores "en la nube" se usan cada vez más. No los usarás para crear proyectos completos (aunque en teoría podrías) sino más bien para usarlos desde cualquier lugar para pruebas rápidas, experimentos y compartir código con otros desarrolladores. Esto último es especialmente útil si estás comenzando.

Aunque mi favorito en general es repl.it porque además soporta muchos lenguajes diferentes, en este caso debo centrarme en alguno especialmente pensado para código Front-End con HTML, CSS y JavaScript. Dentro de esta categoría existen muchos, siendo quizá los más conocidos JSFiddle y Codepen. Sin embargo el que te recomiendo hoy, JSBin, es uno mucho menos conocido y con un aspecto más espartano. Sin embargo, aunque los tres son buenos, creo que es el que seguramente ofrece las mejores características en conjunto:

Permite utilizar multitud de preprocesadores, HTML (Markdown, Jade), CSS (Sass, Less, Myth, Stylus), JavaScript (TypeScript, Babel, LiveScript, Cofeescript).
Puedes añadir simplemente seleccionándolas de una lista decenas bibliotecas JavaScript populares, como jQuery, Bootstrap, QUnit, Angular, React, Vue.js... más que en el caso de los otros (aunque siempre puedes añadir más manualmente).
Puedes crear plantillas de las que partir en lugar de unos documentos en blanco. También arrastrar archivos directamente desde tu disco.
Compartir es muy fácil gracias a sus URLs "pronunciables"
Tiene la posibilidad de hacer "Code Casting", es decir, empezar a "emitir" todo lo que haces en el editor mientras escribes tu código y que otra gente se suscriba y lo vea en tiempo real para aprender o para ayudarte mientras habláis a través de Skype o similar.
Lo puedes descargar e instalar localmente si no quieres usarlo (sólo) online.

Tal vez JSFiddle es más conocido y más bonito y tiene algunas características muy chulas, pero JSBin me ha conquistado por su sencillez y porque tiene algunas características que lo hacen único. Cualquiera de los dos que elijas será una gran decisión.

En esta era de la abundancia, menos es más. Así que esta es mi pequeña lista de preferencias en editores gratuitos de HTML, CSS y JavaScript. Pocos, pero buenos y sobre todo siendo realistas en cuanto a cómo debes desarrollar para la Web hoy. Nada de arrastrar y soltar y mucho de entender bien lo que haces, usar frameworks o técnicas modernas de maquetación web.

¿Conoces algún editor que creas que se deba mencionar o que te guste más en alguna de las categorías? Pues dame argumentos (no solo nombres) en los comentarios de debajo 😉

¡Espero que te resulten útiles!

Guía: Cuándo usar TypeScript en tus desarrollos web

José M. Alarcón 🌐 — Tue, 14 May 2019 08:00:00 +0000

Artículo original publicado en el blog de campusMVP

Abróchate el cinturón. En esta guía, comparamos cuándo es absolutamente vital utilizar TypeScript, el lenguaje de programación de tipado estricto, y cuándo tiene sentido atenerse a JavaScript "puro".

Nota : este artículo es una traducción del artículo When To Use TypeScript - A Detailed Guide Through Common Scenarios de Khalil Stemmler traducido con su permiso expreso. Puedes seguir las discusiones que se generaron sobre el mismo en Hackernews y en Reddit.

¿Has oído hablar de ese pequeño lenguaje de programación llamado TypeScript? Ya sabes, el que hizo Microsoft... ¿El que está explotando en popularidad?

Tal vez seas como yo, un verdadero purista de JavaScript. Me iba bien con React y Node sin tipos. Los Prop Types y la validación Joi me han tratado muy bien, gracias.

Tal vez cediste ante TypeScript y le diste una oportunidad. Empezaste a trastear con él. Tal vez lo llegaste a odiar porque te recordaba a Java. Tal vez te irritaste por no poder lograr mucha productividad desde el primer momento.

Estas fueron algunas de mis sensaciones iniciales cuando empecé con TypeScript.

En realidad no le vi las ventajas... hasta que empecé a sufrir cosas muy molestas. Cosas como que los "builds" no fallaban cuando debían, código con errores y faltas tipográficas que se abrían paso de alguna manera en el código de producción y que empezaron a afectarme. Además, a medida que las exigencias de mi proyecto comenzaban a hacerse más complejas, me resultaba cada vez más difícil plasmar mis diseños de una manera realmente orientada a objetos limpia y clara.

9 meses después de usar TypeScript, he creado nuevas funcionalidades en aplicaciones Angular para mis clientes, he comenzado a compilar el Front-End React/Redux de Univjobs con TypeScript, y he portado todos los servicios de backend de Univjobs a TypeScript desde Node.js con JavaScript "puro", refactorizando de paso enormes cantidades de código durante el proceso.

En este artículo, echaremos un vistazo a algunos de los escenarios más comunes e identificaremos cuándo podría ser vital usar TypeScript , y cuándo probablemente podríamos prescindir de él y seguir con JavaScript puro.

Por qué este debate es hoy más importante que nunca

He llegado a la trascendental conclusión de que, dependiendo de tu situación, contexto, proyecto, nivel de habilidad y otros factores, resulta extremadamente arriesgado que tu proyecto NO esté programado con TypeScript hoy en día.

El espacio del Front-End, por mencionar uno de los posibles, se está volviendo cada vez más complejo. Ciertas características que antes se consideraban de vanguardia, ahora los usuarios las esperan como algo estándar.

Por ejemplo, casi siempre es de esperar que tu aplicación siga funcionando sin conexión en alguna medida; y cuando los usuarios ESTÁN conectados, también suelen tener la expectativa de recibir notificaciones en tiempo real sin tener que actualizar la página.

Estas son algunas de las exigencias más importantes (y definitivamente no poco realistas) en 2019.

Antes de sumergirnos en diferentes escenarios, deberíamos hablar de las tres categorías de problemas de software realmente complejos que debemos resolver.

3 Categorías de problemas difíciles de resolver en software

En términos generales, hay 3:

El Problema del Sistema de Alto Rendimiento.
El Problema del Sistema Embebido.
El Problema del Dominio Complejo.

1. El Problema del Sistema de Alto Rendimiento

Hablemos de Twitter.

Twitter es en realidad un concepto muy simple.

Te registras, escribes tuits, te gustan los tuits de otras personas y eso es prácticamente todo.

Si Twitter es tan sencillito, ¿por qué no podría haberlo hecho otra persona?

Es evidente que el verdadero reto para Twitter no es tanto "lo que hace", sino "cómo consigue hacer lo que hace".

Twitter tiene el desafío único de servir las peticiones de aproximadamente 500 millones de usuarios cada día.

La dificultad que soluciona Twitter es en realidad un problema de rendimiento.

Cuando el reto es el rendimiento, el hecho de que utilicemos o no un lenguaje fuertemente tipado es menos importante.

2. El Problema del Sistema Embebido

Un sistema embebido es una combinación de hardware y software informático, con el fin de permitir el control de los aspectos mecánicos o eléctricos de un sistema.

La mayoría de los sistemas que utilizamos hoy en día están construidos sobre una capa de código muy compleja que, si no está programada inicialmente en C o C++, suele compilar a estos lenguajes.

La programación en estos lenguajes no es para "flojos".

En C, no existen los objetos; y a nosotros como humanos nos gustan los objetos porque podemos entenderlos fácilmente. C es procedimental y esto hace que el código que tenemos que desarrollar en este lenguaje sea más difícil de mantener de forma limpia. Estos problemas también exigen tener conocimiento de detalles de bajo nivel.

C++ hace que la vida sea mucho mejor ya que está orientado a objetos, pero el reto sigue siendo la interacción fundamental con los detalles de hardware de bajo nivel.

Debido a que realmente no tenemos demasiada elección sobre los lenguajes que usamos para estos problemas, es irrelevante discutir aquí sobre TypeScript.

3. El Problema de Dominio Complejo

En el caso de algunos problemas, el desafío consiste no tanto en escalar en términos de manejar más peticiones, sino en escalar en términos del tamaño de la base de código.

Las empresas tienen problemas complejos para resolver en la vida real. En estas empresas, los mayores retos de ingeniería del software suelen ser:

Ser capaz de separar lógicamente (a través de dominios) partes de ese monolito en aplicaciones más pequeñas. Y luego, físicamente (a través de microservicios para contextos vinculados), dividirlos para que se puedan asignar equipos de trabajo para mantenerlos.
Gestionar la integración y sincronización entre estas aplicaciones
Modelar los conceptos de dominio y resolver realmente los problemas del dominio
Creación de un lenguaje ubicuo (que abarque todos los aspectos) para que sea compartido por desarrolladores y los expertos en los dominios.
No perderse en las cantidades masivas de código escrito y ralentizarse hasta el punto en que se hace imposible añadir nuevas funciones sin romper las existentes.

He descrito esencialmente los tipos de problemas que resuelve el diseño orientado por dominio (Domain Driven Design). Para este tipo de proyectos, ni siquiera pensarías en no usar un lenguaje fuertemente tipado como TypeScript.

JavaScript orientado a objetos

En el caso de problemas con dominios complejos , si no se escoge TypeScript y, en su lugar, se escoge JavaScript, se requerirá un esfuerzo adicional para que los resultados sean satisfactorios. No sólo tendrás que estar más que cómodo con tus habilidades de modelado de objetos en JavaScript puro, sino que también tendrás que saber cómo utilizar los 4 principios de la programación orientada a objetos (encapsulación, abstracción, herencia y polimorfismo).

Esto puede ser difícil de hacer. JavaScript no tiene de forma nativa conceptos como interfaces y clases abstractas, y la herencia por prototipos puede resultar complicada a veces.

La "segregación de interfaces" de los principios de diseño de SOLID no es fácil de conseguir con JavaScript puro.

El uso de JavaScript por sí solo también requeriría un cierto nivel de disciplina como desarrollador para mantener el código limpio, y esto es vital una vez que la base de código sea lo suficientemente grande. Y también es importante asegurarse de que todo el equipo de programación comparte la misma disciplina, la misma experiencia y el mismo nivel de conocimientos sobre cómo implementar patrones de diseño comunes en JavaScript. Si no, es necesario orientarlos.

En proyectos orientados a dominios como este, el gran beneficio de usar un lenguaje fuertemente tipado no consiste tanto en expresar lo que se puede hacer , sino más bien en usar encapsulación y ocultación de información para reducir la posibilidad de errores limitando lo que los objetos del dominio realmente pueden hacer.

Se puede prescindir de esto en la parte Front-End, pero en mi opinión es un requisito de lenguaje indispensable para el backend. También es la razón por la que cambié mis servicios de backend de Node.js a TypeScript.

Hay una razón por la que a TypeScript se le llama "JavaScript que escala".

De entre las tres categorías de problemas de software difíciles, sólo el problema del dominio complejo es aquel en el que TypeScript es absolutamente imprescindible.

Además de esto, existen otros factores que pueden determinar cuándo es mejor utilizar TypeScript para los proyectos JavaScript.

Tamaño del código

El tamaño del código generalmente se relaciona con el problema del dominio complejo, donde una base de código grande significa un dominio complejo, pero no siempre es así.

Cuando la cantidad de código que tiene un proyecto alcanza un cierto tamaño, se hace más difícil llevar un registro de todo lo que existe, y es más fácil terminar reimplementando algo ya programado.

La duplicación es el enemigo de un software bien diseñado y estable.

Esto se acentúa especialmente cuando los nuevos desarrolladores comienzan a programar sobre una base de código ya de por sí grande.

El auto-completado de Visual Studio Code e Intellisense ayudan a navegar a través de grandes proyectos. Funciona muy bien con TypeScript, pero es algo más limitado con JavaScript.

Para proyectos que permanecerán simples y pequeños , o si se sabe que con el tiempo serán desechados, estaría menos inclinado en recomendar TypeScript como requisito.

Software de producción frente a proyectos personales

El software que está en producción es el código que importa , o el código por el que se puede tener problemas si no funciona. También es un código para el que has hecho pruebas. Por regla general, si a uno le preocupa el código, necesita que le hagan pruebas unitarias.

Pero si no te importa, no hagas testing.

Los proyectos personales se explican por sí solos. Se puede hacer lo que se quiera. No hay ningún compromiso profesional para mantener estándares de calidad.

Es bueno atreverse a hacer cosas. Hacer cosas pequeñas, hacer cosas grandes.

Tal vez algún día se te haga fastidioso si un proyecto personal se convierte en un proyecto profesional y que algún día se convertirá en software de producción, ya que tendrá errores debido a que no se le hicieron pruebas... 🙃 no es como si me hubiera pasado a mí ni nada de eso....

Ausencia de pruebas unitarias

No siempre es posible hacer pruebas para todo, porque, bueno, la vida es así...

En este caso, diría que, si no se realizan pruebas unitarias, lo mejor que se puede hacer es una comprobación en tiempo de compilación con TypeScript. Después de eso, si se está usando React, lo mejor es usar la comprobación en tiempo de ejecución con Prop Types.

Sin embargo, la inspección en tiempo de compilación no es una alternativa a las pruebas unitarias. Lo bueno es que las pruebas unitarias se pueden escribir en cualquier lenguaje, por lo que el argumento para TypeScript aquí es irrelevante. Lo importante es que las pruebas estén programadas y que tengamos confianza en nuestro código.

Startups

Sin duda, lo mejor es usar lo que ayude a ser más productivo.

En este momento, el lenguaje que se elija importa mucho menos.

Lo más importante que se debe hacer es validar el producto.

Elegir un lenguaje (Java, por ejemplo) o una herramienta (como Kubernetes) que pueda ayudar a escalar en el futuro, sin estar totalmente familiarizado con ella y con la necesidad de pasar tiempo aprendiendo, puede o no ser la mejor opción en el caso de un startup.

Dependiendo de en qué fase se encuentre la empresa, lo más importante que se debe hacer es intentar ser productivo.

En el famoso artículo de Paul Graham , The Python Paradox, la idea principal es que los programadores novatos sólo deben utilizar una tecnología que maximice su productividad.

En general, en este caso, se puede usar cualquier cosa con la que uno esté más cómodo: tipado o no tipado. Siempre se puede refactorizar hacia un mejor diseño una vez que se sabe que se ha creado algo que las personas realmente quieren.

Trabajo en equipo

Dependiendo del tamaño de los equipos y de los frameworks que se utilicen, utilizar TypeScript puede salir muy bien o fatal.

Equipos grandes

Cuando los equipos son lo suficientemente grandes (porque los problemas son lo suficientemente grandes), es una buena razón para usar un framework que nos deje poca libertad de opciones, como Angular para el front-end y TypeScript para el backend.

La razón por la cual el uso de un framework "con opiniones" es beneficioso es porque se limita el número de formas posibles en que las personas pueden llegar a hacer algo. En Angular, hay casi una manera principal de añadir un Route Guard, usar inyección de dependencias, conectar rutas, hacer Lazy-Loading y crear formularios reactivos.

La gran ventaja es que la API está bien especificada.

Con TypeScript, se ahorra mucho tiempo y se hace más eficiente la comunicación.

La capacidad de determinar rápidamente los argumentos necesarios y su tipo de retorno para cualquier método, o la capacidad de describir explícitamente la intención del programa a través de variables públicas, privadas y protegidas es increíblemente útil.

Sí, algo de todo esto también es posible con JavaScript, pero es un lío.

Comunicar patrones e implementar principios de diseño

No sólo eso, sino que los patrones de diseño , las soluciones a los problemas más comunes que ocurren en el software, se comunican más fácilmente a través de lenguajes explícitos fuertemente tipados.

A continuación se muestra un ejemplo de un patrón común en JavaScript. Fíjate a ver si puedes identificar qué es:

class AudioDevice {
  constructor () {
    this.isPlaying = false;
    this.currentTrack = null;
  }

  play (track) {
    this.currentTrack = track;
    this.isPlaying = true;
    this.handlePlayCurrentAudioTrack();
  }

  handlePlayCurrentAudioTrack () {
    throw new Error(`Subclasss responsibility error`)
  }
}

class Boombox extends AudioDevice {
  constructor () {
    super()
  }

  handlePlayCurrentAudioTrack () {
    // Play through the boombox speakers
  }
}

class IPod extends AudioDevice {
  constructor () {
    super()
  }

  handlePlayCurrentAudioTrack () {
    // Ensure headphones are plugged in
    // Play through the ipod
  }
}

const AudioDeviceType = {
  Boombox: 'Boombox',
  IPod: 'Ipod'
}

const AudioDeviceFactory = {
  create: (deviceType) => {
    switch (deviceType) {
      case AudioDeviceType.Boombox:
        return new Boombox();
      case AudioDeviceType.IPod:
        return new IPod();
      default:
        return null;
    }
  }
}

const boombox = AudioDeviceFactory
  .create(AudioDeviceType.Boombox);

const ipod = AudioDeviceFactory
  .create(AudioDeviceType.IPod);

Si adivinaste el Patrón "Factoría Abstracta" , estás en lo cierto. Dependiendo de tu familiaridad con el patrón, podría no haber sido tan obvio.

Veámoslo ahora implementado en TypeScript. Observa cuánta más intención podemos significar sobre AudioDevice en este lenguaje:

abstract class AudioDevice {
  protected isPlaying: boolean = false;
  protected currentTrack: ITrack = null;

  constructor () {
  }

  play (track: ITrack) : void {
    this.currentTrack = track;
    this.isPlaying = true;
    this.handlePlayCurrentAudioTrack();
  }

  abstract handlePlayCurrentAudioTrack () : void;
}

Mejoras inmediatas

Sabemos que la clase es abstracta de inmediato. En el ejemplo de JavaScript era necesario investigar un poco.
AudioDevice puede ser instanciado en el ejemplo de JavaScript. Esto es malo, queríamos que AudioDevice fuera una clase abstracta. Y las clases abstractas no deberían poder ser instanciadas, sólo están destinadas a ser subclasificadas e implementadas por clases concretas. Esta limitación se establece correctamente en el ejemplo de TypeScript.
Hemos señalado el ámbito de las variables.
En este ejemplo, currentTrack se refiere a una interfaz. Según el principio de diseño de la inversión de la dependencia, siempre debemos depender de las abstracciones, no de las concreciones. Esto no es posible en la implementación con JavaScript.
También hemos señalado que cualquier subclase de AudioDevice necesitará implementar el handlePlayCurrentAudioTrack. En el ejemplo de JavaScript, expusimos la posibilidad de que alguien introdujera errores de ejecución intentando ejecutar el método desde la clase abstracta ilegal o desde la implementación de la clase concreta no completa.

Conclusión : si se trabaja en un equipo grande y se necesita minimizar las posibles formas en las que alguien podría hacer un mal uso del código, TypeScript es una buena forma de ayudar a corregirlo.

Equipos más pequeños y estilos de programación

Los equipos más pequeños son mucho más fáciles de manejar en lo que respecta a estilos de programación y comunicación. Junto con las herramientas de comprobación de reglas (linting), las discusiones frecuentes sobre cómo se harán las cosas y los pre-commit hooks, creo que los equipos pequeños pueden tener mucho éxito sin TypeScript.

Creo que el éxito es una ecuación que incluye el tamaño de la base de código y el tamaño del equipo.

A medida que crece la base de código, el equipo puede encontrar que necesita contar con algo de ayuda del propio lenguaje para recordar dónde están las cosas y cómo deberían estar.

A medida que el equipo crece, pueden encontrar que necesitan más reglas y restricciones para asegurar la coherencia del estilo y evitar la duplicación de código.

Frameworks

React y Angular

Mucho de lo que me atrae a mí y a otros desarrolladores de React es la capacidad de escribir código como quieras y de forma elegante/inteligente.

Es cierto que React te hace mejor programador de JavaScript porque te obliga a enfocar los problemas de forma diferente, te obliga a ser consciente de cómo funciona este vínculo en JavaScript y te permite crear componentes grandes a partir de otros pequeños.

React también te permite tener un poco de estilo propio. Y debido a la cantidad de formas en que se puede implementar cualquier tarea, lo más frecuente es que se programen aplicaciones en React.js "puro" cuando:

La base de código es pequeña
Sólo lo programa una persona

Pero yo lo compilaría con TypeScript cuando:

Lo estén programando más de 3 personas, o
se espera que la base de código llegue a ser muy grande

También opcionalmente usaría Angular por la misma razón por la que compilaría React con TypeScript.

Conclusión

En conclusión, estas son mis opiniones personales sobre cuándo TypeScript es absolutamente necesario y os invito a estar en desacuerdo con cualquiera de ellas.

Esto es lo que me ha funcionado en el pasado a la hora de decidir si utilizo TypeScript. Sin embargo, hoy en día, como he visto la luz, no es mucho más difícil para mí usar TypeScript que JavaScript puro, ya que me siento igual de cómodo con ambos y preferiría la seguridad del tipado.

Lo último que quiero decir es lo siguiente:

Siempre se puede empezar a utilizar TypeScript gradualmente

Empieza gradualmente añadiendo TypeScript y ts-node a tu package.json y utilizando la opción allowjs: true, en tu archivo tsconfig.

Así es cómo, con el paso del tiempo, migré todas mis aplicaciones Node.js a TypeScript.

Los errores de tiempo de compilación son mejores que los de tiempo de ejecución

Eso no admite discusión. Si la detección de errores en el código de producción es especialmente importante para ti, TypeScript te ayudará a minimizar muchos de ellos.

Si estás en disposición de aprenderlo, apréndelo: hace maravillas con tus habilidades de diseño de software

Dependiendo de dónde estés en tu vida y en tu trayectoria profesional, es posible que no tengas tiempo para aprender y formarte. Si tienes tiempo, te recomiendo que empieces por aprender sobre los principios de diseño SOLID y los patrones de diseño de software. Esta es la manera más rápida de subir de nivel como desarrollador junior, en mi sincera opinión.

Java 12 lanzado: versión descafeinada sin soporte a largo plazo

José M. Alarcón 🌐 — Mon, 25 Mar 2019 08:00:00 +0000

Dentro de la (en mi opinión bastante absurda) metodología de lanzamiento de versiones "mayores" de la plataforma Java cada 6 meses, el pasado día 19 de marzo apareció la versión 12 de Java.

Esta versión llega tan solo 6 meses después de la versión 11, y no se considera una versión con soporte a largo plazo (LTS) por lo que solo se le dará soporte durante 6 meses por parte de Oracle.

Entre las cuestiones destacables de esta versión solamente hay dos, y encima se consideran experimentales.

Veámoslas rápidamente:

Switch expressions

Las "Expresiones de conmutación" o Switch Expressions, son una nueva función de lenguaje que se basa en la instrucción switch existente en el lenguaje desde siempre. Esta nueva variante nos permite crear una manera más concisa de expresar lo mismo que un condicional que tiene varias ramas. Su aspecto este:

int numDias = switch(mes) { 
    case 1, 3, 5, 7, 8, 10, 12 -> 31; 
    case 4, 6, 9, 11 -> 30; 
    case 2 -> esBisiesto(anio) ? 29 : 28; 
    default: throw new IllegalArgumentException("Número de mes no válido");}

En este caso asignamos en una variable el número de días del mes del año que nos interese usando esta nueva sintaxis. Fíjate en que se utiliza un operador flecha (->) en lugar de los típicos dos puntos (:), y que no hace falta meter instrucciones break en cada uno de los casos, por lo que la sintaxis es muy compacta. Fíjate también en cómo se puede utilizar cualquier tipo de instrucción en cada rama (como en el caso de los años bisiestos para febrero), y cómo todos los posibles valores que se le pasen al switch deben tener una rama que los gestione, incluso si generan un error, como es el caso final en el que no se pasa un mes válido.

La única opción de no tener que poner una rama default es si usamos una enumeración como argumento para el switch. Si metemos todos los posibles valores de la enumeración dentro de las ramas, podemos omitir default, lógicamente.

Es importante señalar que, si bien esto se ha incluido en Java 12, se considera todavía una característica experimental , por lo que no te funcionará por defecto. Para que te funcione y poder usarla en tus programas debes utilizar el modificador --enable-preview con javac, el compilador de Java. Así que tenlo en cuenta.

Shenandoah, un nuevo recolector de basura

La principal novedad de Java 12 es su nuevo sistema de recolección de basura, que se llama Shenandoah. Su principal ventaja frente al GC existente es que reduce los tiempos de pausa de las aplicaciones mientras se realiza la limpieza de memoria (evacuación, marcado, compactación...) ya que realiza más trabajo de este tipo en paralelo a la ejecución del propio programa, lo que implica también que las pausas de los programas para limpieza ya no estarán directamente relacionadas con el tamaño de la pila. Todavía quedan trabajos de limpieza que se deben hacer por separado, pero son mucho menores y por lo tanto las pausas son muy pequeñas.

Shenandoah se considera también una tecnología experimental en Java 12, por lo que para que tu programa la utilice deberás habilitarla explícitamente usando las opciones -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC al ejecutar el comando java.

En la página oficial del OpenJDK para este nuevo recolector de basura puedes encontrar todos los detalles de funcionamiento y una lista con los modificadores de su comportamiento.

Además de Shenandoah, el recolector de basura convencional, G1 , tiene algunas mejoras, en concreto ahora si detecta que falla varias veces seguidas a la hora de determinar el tiempo máximo de pausa necesario para la limpieza, y ajusta la heurística para mejorar la predicción y detener el proceso si es necesario. También mejora el uso de memoria devolviendo al sistema operativo durante los periodos de inactividad la memoria de pila que está sin usar. Esto último es una gran mejora puesto que hasta ahora no devolvía al sistema la memoria de pila sin usar a no ser que se realizase una "limpieza de basura" completa (y por tanto costosa).

Otras cosillas

Aparte de lo anterior, esta versión tiene otras 4 pequeñas mejoras que enlazo a continuación con su nombre oficial, por si tienes interés:

Ya están disponibles las versiones de Java 12 para el OpenJDK y para el build oficial de Oracle.

Post original: https://www.campusmvp.es/recursos/post/java-12-lanzado-version-descafeinada-sin-soporte-a-largo-plazo.aspx

Java: cómo listar, filtrar y obtener información de carpetas y archivos

José M. Alarcón 🌐 — Thu, 21 Feb 2019 08:00:00 +0000

Post original: https://www.campusmvp.es/recursos/post/java-como-listar-filtrar-y-obtener-informacion-de-carpetas-y-archivos.aspx

Una tarea común y básica que necesitamos hacer en cualquier programa es acceder a la información de los archivos y carpetas del sistema de archivos local. Desde algo tan básico como ver el nombre y el tamaño de un archivo hasta listar los contenidos de cualquier carpeta.

En Java esto es muy fácil de conseguir gracias a la clase java.io.File. Esta clase nos permite obtener información sobre cualquier elemento del sistema de archivos.

Para utilizarla solo tenemos que importarla en la cabecera de nuestro programa:

import java.io.File;

Y podremos utilizarla en nuestra aplicación.

Para obtener información sobre un archivo o carpeta basta con usar su constructor pasándole la ruta de éste. Así:

String sCarpAct = System.getProperty("user.dir");File carpeta = new File(sCarpAct);

En la primera línea obtenemos la carpeta actual desde la que se está ejecutando el código, y utilizamos la clase File para obtener información sobre la misma. A este constructor le podemos pasar una ruta absoluta o relativa en el sistema de archivos.

La clase File sirve para representar a un archivo o carpeta y ofrece propiedades y métodos que nos permiten acceder a sus datos y realizar operaciones sobre ellos, como renombrar, eliminar, crear carpetas, listar sus contenidos, etc... Lo que podamos hacer con ella dependerá de los permisos que tengamos sobre el archivo o carpeta en cuestión.

Algunos de estos métodos son:

canExecute(): devuelve un true o false en función de si el archivo es ejecutable o no.
canRead(): si tienes acceso de lectura o no
canWrite(): si puedes escribir en él o no
createNewFile(): crea un nuevo archivo vacío con el nombre que se le indique.
delete(): borra el archivo o directorio
exists(): determina si el archivo representado por File en la ruta que le hayamos pasado existe o no.
getName(): el nombre del archivo o carpeta
getParent(): devuelve una cadena con la ruta de la carpeta "madre" del archivo o carpeta actuales.
isDirectory(): indica si el objeto actual representa a una carpeta o no
isFile(): indica si el objeto actual representa a un archivo
isHidden(): si es un elemento oculto en el sistema de archivos
length(): el tamaño del archivo en bytes. Si no existe o no tienes permiso devuelve un 0. En el caso de carpetas en Linux/Mac con sistema de archivos ext3/ext4 siempre devuelve 4096 ya que este es el tamaño de un bloque en Linux y es el mínimo que puede ocupar cualquier enlace en disco, como una carpeta (4KB).
list(): los nombres de los archivos y carpetas hijos de una carpeta.
listFiles(): como el anterior pero devolviendo objetos File para cada archivo o carpeta.
mkdir(): crea una carpeta
renameTo(): renombra el archivo o carpeta

Con todo esto se pueden hacer muchas cosas. Consúltalos todos en la documentación con el enlace anterior.

Vamos a ver un ejemplo de cómo listar todos los archivos de una carpeta usando varios de estos métodos:

File carpeta = new File(sCarpAct);String[] listado = carpeta.list();if (listado == null || listado.length == 0) { System.out.println("No hay elementos dentro de la carpeta actual"); return;}else { for (int i=0; i< listado.length; i++) { System.out.println(listado[i]); }}

Lo que se hace en este fragmento es:

Se crea un nuevo objeto File para representar la carpeta que nos interesa.
Con el método list() obtenemos los nombres de todos sus hijos
Si no devuelve nada o la longitud es 0 mostramos un mensaje de que no hay elementos en la carpeta actual (también podríamos haber comprobado si es una carpeta o no con isDirectory())
En la otra rama del condicional recorremos en un bucle sencillo todos los nombres de elementos hijo mostrando sus nombres cada uno en una línea en la consola.

Veríamos algo como esto:

Está bien para replicar el comando ls (Linux, Mac) o dir (Windows) básico de la línea de comandos, pero si queremos más información no nos va a servir de mucho.

Podemos mejorarlo utilizando el método listFiles() que nos devuelve objetos File y por lo tanto podemos mostrar más información de cada uno sin tener que crearlos explícitamente, así:

File[] archivos = carpeta.listFiles();if (archivos == null || archivos.length == 0) { System.out.println("No hay elementos dentro de la carpeta actual"); return;}else { SimpleDateFormat sdf = new SimpleDateFormat("dd/MM/yyyy HH:mm:ss"); for (int i=0; i< archivos.length; i++) { File archivo = archivos[i]; System.out.println(String.format("%s (%s) - %d - %s", archivo.getName(), archivo.isDirectory() ? "Carpeta" : "Archivo", archivo.length(), sdf.format(archivo.lastModified()) )); }}

En este caso el código es parecido, pero podemos utilizar los métodos que hemos visto para mostrar más información sobre cada elemento. En este caso mostramos su nombre, si es un directorio o un archivo, su tamaño y la fecha de última modificación. Para mostrar la fecha en un formato adecuado utilizo la clase SimpleDateFormater del paquete java.text.SimpleDateFormat.

Bien. Pero, ¿qué pasa si no queremos mostrar todos los archivos, sino sólo los que cumplan con ciertas condiciones?

Para eso podemos utilizar un filtro. Los filtros son clases que implementan la interfaz FilenameFilter (si solo queremos filtrar por el nombre) o FileFilter (si queremos usar objetos File para el filtrado). Esta interfaz lo único que define es un método accept() que, en su sobrecarga más simple, toma como parámetro el archivo a filtrar y debe devolver true o false en función de si el archivo pasa el filtro o no.

Por ejemplo, vamos a filtrar los elementos de nuestra carpeta para que devuelve únicamente archivos, pero no carpetas. Es una condición sencilla, pero lógicamente podríamos aplicar cualquier regla compleja que nos interesase en función de las propiedades disponibles de cada elemento (su nombre, tamaño, permisos... o una combinación de varios de ellos).

Veamos cómo hacerlo.

En primer lugar vamos a definir el filtro:

FileFilter filtro = new FileFilter() {
 @Override
 public boolean accept(File arch) {
   return arch.isFile();
 }
};

En este caso, por brevedad, he usado un literal con el constructor para crear el objeto e implementar el método accept(), pero podría haber creado la clase de la manera más convencional usando implements para implementar la interfaz, etc.. La forma es lo de menos. Lo único que hace es llamar al método isFIle() de cada archivo o carpeta para devolver true solo en caso de que sean archivos. De este modo solamente se obtendrán archivos y ninguna carpeta tras realizar el filtrado.

Ahora utilizarlo es tan sencillo como pasar el nuevo objeto de filtro al método listFiles(), así:

archivos = carpeta.listFiles(filtro);

if (archivos == null || archivos.length == 0) {
 System.out.println("No hay elementos dentro de la carpeta actual");
 return;
}
else {
 SimpleDateFormat sdf = new SimpleDateFormat("dd/MM/yyyy HH:mm:ss");
 for (int i=0; i< archivos.length; i++) {
   File archivo = archivos[i];
   System.out.println(String.format("%s (%s) - %d - %s", 
                       archivo.getName(), 
                       archivo.isDirectory() ? "Carpeta" : "Archivo",
                       archivo.length(),
                       sdf.format(archivo.lastModified())
                      ));
 }
}

Tan solo cambia la primera línea. El resto es como en el ejemplo anterior, solo que en este caso veremos en la consola únicamente los archivos y no los directorios gracias al filtro que hemos aplicado.

Como ves el uso de esta clase es extremadamente sencillo.

Te dejo todo el código de ejemplo en este repl.it, embebido a continuación. Pulsa el triángulo de la parte de arriba para ejecutarlo directamente en el navegador y ver sus resultados:

Nota : si te preguntas cómo hago lo de mostrar colores en la consola, lee este otro artículo.

¡Espero que te resulte útil!

Post original: https://www.campusmvp.es/recursos/post/java-como-listar-filtrar-y-obtener-informacion-de-carpetas-y-archivos.aspx

TRUCO - Depuración con Chrome: convertir archivos JavaScript en "cajas negras" para evitar depurarlos

José M. Alarcón 🌐 — Tue, 19 Feb 2019 18:12:21 +0000

Publicado originalmente en mi blog técnico: https://www.jasoft.org/Blog/post/truco-depuracion-con-chrome-convertir-archivos-javascript-en-cajas-negras-para-evitar-depurarlos.aspx

Por regla general, cuando estamos depurando una aplicación web hay ciertas cosas en las que podemos confiar. Por ejemplo en el hecho de que si se produce una excepción casi seguro que la culpa es de nuestro código y no de alguna biblioteca JavaScript conocida de las que estamos utilizando. Es decir, la excepción puede saltar en una línea de jQuery o de Angular, pero eso no significa que el error esté ahí, sino que se ha producido por una llamada previa hecha por nuestro código.

Por ello, cuando estamos depurando paso a paso, poniendo puntos de interrupción en ciertas líneas para luego ir ejecutando el código función a función, introduciéndonos en ellas con F11 o saltándolas con F10, no tiene mucho sentido que, de repente, se nos abra el código fuente de alguna de estas bibliotecas, pues no vamos a depurarlo. Y mucho menos si lo estamos usando ya minimizado y listo para producción, puesto que encima no veremos gran cosa tampoco:

¡Estupendo que me pare el depurador en esta línea tan interesante! ¿no?

Por suerte los desarrolladores de Chrome ya han tenido en cuenta esta situación y nos permiten evitar que ocurra, permitiéndonos meter en una "caja negra" los scripts que nos interesen. La acción se denomina "blackboxing" y lo que hace es que el script se ejecuta normalmente pero, en lo que respecta a la depuración, actúa como una caja negra de modo que se saben los parámetros que entran y los que salen, pero jamás se accede a su interior.

En la práctica esto significa que el depurador jamás se parará en ningún código de su interior , agilizando nuestra depuración.

Vamos a ver cómo funciona...

Activando la capacidad de "blackboxing"

Por defecto esta característica está deshabilitada, por lo que no podremos utilizarla. Para activarla tenemos que ir a los ajustes de las herramientas del desarrollador y acceder al apartado correspondiente que se llama "Blackboxing", activándola desde allí, como se muestra en esta pequeña animación:

Añadir scrips a la caja negra

Una vez activada la funcionalidad, tenemos dos opciones para añadir scripts a las caja negra:

1.- Añadir rutas y/o nombres genéricos

Por ejemplo, generalmente no querremos que el depurador se pare en ninguna biblioteca minimizada, de producción. Como los archivos de estas bibliotecas suelen terminar con el nombre .min.js, podemos agregar un patrón como este al nombre de archivo usando el botón que tenemos debajo del check que acabamos activar:

Fíjate en un par de cosas importantes:

El patrón es una expresión regular. Por lo tanto puedes usar toda la potencia que te dan éstas (que es mucha) para localizar todo tipo de archivos, Además, como se ve en la animación, en una expresión regular un punto representa cualquier carácter, por lo que si queremos indicar un punto de verdad hay que "escapearlo" poniéndole una barra inclinada delante, como se ve en la animación. Tenlo en cuenta. Gracias a esto podemos añadir muchos archivos de golpe. En la animación todos los que estén minimizados.
Estos patrones no solo nos permiten convertir archivos en cajas negras, sino lo contrario: deshabilitar la caja negra para ciertos archivos que estuviesen incluidos en alguno de los patrones que hayamos añadido. Así que vale para las dos cosas.

2.- Convertir individualmente cada archivo en una caja negra

Si además (o en lugar) de usar patrones queremos convertir en cajas negras archivos concretos, al cerrar el diálogo anterior y haber habilitado la funcionalidad, tendremos una nueva opción en los menús contextuales de los archivos en la pestaña de código fuente, Sources. Basta con que abramos cualquier archivo y pulsemos con el botón derecho en cualquier parte del archivo abierto para ver una nueva opción Blackbox Script que nos permite hace precisamente eso:

A partir de ese momento el depurador no se detendrá en ese archivo, que es lo que queríamos.

Fíjate en como en la animación anterior, una vez convertido el archivo en una caja negra, podemos volver a habilitarlo para depuración con el mismo menú contextual, que ahora pone Stop blackboxing. ¡Súper-fácil!

En resumen

El "blackboxing" de scripts puede ser muy útil para ir más rápido a la hora de depurar y ser más productivo ya que raramente nos interesa entrar en el detalle del código de una biblioteca de terceros o que esté muy probada (salvo quizá con objetivos didácticos), y haciendo que actúen como cajas negras lo evitaremos. Además es muy fácil de deshabilitar si lo necesitásemos en un momento determinado.

Mi consejo sería que deshabilitases directamente la depuración de bibliotecas para producción (.min.js) y quizá las que. aunque no estén minimizadas, estén ampliamente utilizadas y probadas por miles de desarrolladores (frameworks y cosas así). Ahorrarás tiempo y te despistarás menos, fijándote tan solo en la información que trasiega tu programa y las acciones que se gestionan con éste, considerando tan solo los efectos que producen las otras bibliotecas de terceros.

¡Espero que te resulte útil!

Post original: https://www.jasoft.org/Blog/post/truco-depuracion-con-chrome-convertir-archivos-javascript-en-cajas-negras-para-evitar-depurarlos.aspx

Java y JavaScript ¿son lo mismo?

José M. Alarcón 🌐 — Wed, 13 Feb 2019 10:00:17 +0000

Esta pregunta puede parecerle obvia a muchos, pero todavía hay cantidad de gente que no lo tiene claro...

Dado que comparten una palabra al principio de su nombre, muchas personas piensan que Java y JavaScript están relacionados, o que JavaScript es un subconjunto de Java y cosas parecidas... Nada más lejos de la realidad.

Java nació en el año 1991 en la empresa Sun Microsystems, de la mano de James Gosling. Su objetivo inicial era crear aplicaciones para receptores de televisión y dispositivos embebidos, aunque al final haya terminado funcionando en casi todas partes. Inicialmente iba a llamarse Oak, y luego Green, pero finalmente el nombre elegido es el que todos conocemos. La Wikipedia tiene información muy interesante sobre su historia y su nombre que te recomiendo que te leas.

JavaScript es un lenguaje de programación posterior, creado a mediados de los años '90 por Brendan Eich, de la empresa Netscape. Su objetivo era dotar de interactividad a las páginas web visualizadas con su navegador de Internet, Netscape Navigator, el líder del mercado por aquella época. Su nombre en código durante el desarrollo del lenguaje era Mocha, y pensaban lanzarlo finalmente como LiveScript, aunque al final se acabó denominando JavaScript por la gran influencia en su sintaxis por parte del lenguaje Java, aunque las similitudes son únicamente estéticas. En la actualidad, además de ser el lenguaje utilizado casi en exclusiva para añadir interactividad a las páginas Web, JavaScript se encuentra integrado en otras muchas aplicaciones además de los navegadores: servidores, lenguajes de programación de propósito específico como Node.js o sistemas operativos como Windows.

Bien es cierto que la gente de Netscape intentó aprovechar el tirón de marketing que ofrecía Java en aquel momento, y usando la palabra "Java" en el nombre del nuevo lenguaje pretendían darle un halo de seriedad. Me imagino que, dada la confusión que generaron, se arrepintieron pronto de su decisión y de no haberle dejado el nombre de LiveScript.

Aparte de esa raíz común en el nombre, Java y JavaScript son lenguajes totalmente diferentes. He aquí algunos ejemplos importantes de sus muchas diferencias:

JavaScript es un lenguaje interpretado, y Java es compilado. Para entendernos, y dicho muy básicamente, los programas JavaScript son archivos de texto que pueden leer tanto los ordenadores como las personas, mientras que los de Java se compilan a un archivo especial optimizado para que lo lea un ordenador y lo ejecute. Podríamos entrar en detalles de que Java se compila a un lenguaje intermedio llamado bytecode que es interpretado por un ejecutar JIT que facilita que sea multiplataforma, pero no es el objeto de este artículo y quiero mantenerlo intencionadamente simple.
Java se depura en dos fases y JavaScript en una. Como con todos los lenguajes interpretados, en JavaScript solamente sabes si has cometido inadvertidamente un error de sintaxis cuando vas a ejecutar el programa (salvo que uses herramientas especializadas como Visual Studio o WebStorm, que interpretan el código en segundo plano). En Java sin embargo, primero se realiza la fase de compilación, en la que el compilador ya indica los posibles errores de sintaxis que existan. Luego al ejecutar podrían surgir errores de lógica o de otra índole. En JavaScript todos ellos se depuran al mismo tiempo, haciéndolo más complicado.
Java es un lenguaje orientado a objetos puro, pero JavaScript está basado en prototipos. En realidad JavaScript debe simular muchas de las características de orientación a objetos que se dan en la mayoría de los lenguajes. A cambio proporciona diversos paradigmas de programación (funcional, imperativo, dinámico y orientado a objetos) lo que lo convierte en un lenguaje tremendamente versátil. De hecho en JavaScript es posible cambiar la "base" de la que hereda una clase en cualquier momento, afectando a todas, cosa imposible en la mayoría de los lenguajes orientados a objetos.
Java es fuertemente tipado, y JavaScript es débilmente tipado. En Java todas las variables tienen un tipo determinado y una vez definidas no se pueden cambiar. En JavaScript una misma variable puede contener primero un texto, luego un número, luego una fecha o un objeto, etc... Esto es un arma de doble filo pues permite una gran flexibilidad a cambio de muchos posibles errores si no tenemos cuidado.
Java tiene ámbito por bloque y JavaScript lo tiene por función: el acceso a las variables depende de dónde las hayamos definido. JavaScript tiene algunas reglas que pueden despistar bastante a los programadores de otros lenguajes.
JavaScript tiene clausuras, Java las acaba de incorporar. Uno de los conceptos más importantes en la programación con JavaScript (y en otros lenguajes) son las clausuras. Java no las tuvo hasta la versión 8 aparecida hace muy poco tiempo, que añadió también las funciones lambda, para dar soporte al paradigma de programación funcional.
Las funciones en JavaScript son multi-argumento siempre. En Java es necesario indicarlo.
JavaScript es estándar, Java no. El control del lenguaje JavaScript lo lleva la organización sin ánimo de lucro European Computer Manufacturers Association (ECMA). De hecho su nombre oficial es ECMAScript, y está estandarizado. Por el contrario el control sobre Java lo tiene Oracle, una empresa privada que decide a su antojo lo que se hace con él.

En resumen, y para dejar bien clara la diferencia sin palabras técnicas, desmiento a continuación algunos falsos mitos:

JavaScript NO es lo mismo que Java.
JavaScript NO es un subconjunto de Java.
JavaScript NO es una versión de Java para programar páginas web.
JavaScript NO comparte prácticamente nada con Java. Si acaso la misma sintaxis que comparte con otros lenguajes como C, C++ o C#, y algún detalle más como algunos nombres de clases (Math o Date, por ejemplo), pero nada más.
JavaScript NO es más fácil que Java. De hecho en algunas áreas concretas es más difícil de dominar.
Si sabes programar en Java NO sabes programar en JavaScript. Y viceversa.
JavaScript NO es solo un lenguaje para páginas web, al igual que Java no es un lenguaje solo para servidor.

Espero que esto sirva para aclararlo de una vez por todas :-)

Post original: https://www.campusmvp.es/recursos/post/Comparando-valores-y-referencias-en-varios-lenguajes-de-programacion.aspx

Cómo cambiar los colores de la consola con Java y System.out.println

José M. Alarcón 🌐 — Wed, 13 Feb 2019 08:00:00 +0000

Hoy toca un truco sencillo pero útil.

Cuando programamos en Java estamos acostumbrados a enviar mensajes por la consola para informar a los usuarios de lo que va a ocurriendo. Para ello la manera por defecto de conseguirlo es mediante el uso del método System.out.println.

Este método, en principio, no permite cambiar el color de lo que se emite por pantalla. Todo se ve con el color predeterminado que tengamos, generalmente blanco (o gris claro) sobre fondo negro, algo así:

Sin embargo, cuando estamos creando una herramienta de línea de comandos nos puede resultar muy útil emplear otros colores para destacar cosas. Por ejemplo, usar el color rojo cuando se produzca una excepción y queramos avisar de ello tras haberla controlado, o el verde para cuando se lleve a cabo una tarea con éxito.

Nota : este tipo de usos del color para marcar significados no es accesible y por tanto no son apropiados si queremos que los puedan usar usuarios con problemas de visión, como por ejemplo los daltónicos que no distinguen entre rojo y verde. Asegúrate de que además de los colores utilizas algo más en el propio texto (mayúsculas, símbolos...) para indicar que se trata de un evento especial.

La buena noticia es que existen una serie de códigos de escape ANSI que nos permiten controlar ciertos aspectos de la consola, entre ellos los colores utilizados.

Si definimos las siguientes constantes en nuestro código:

public static final String ANSI\_BLACK = "\u001B[30m";
public static final String ANSI\_RED = "\u001B[31m";
public static final String ANSI\_GREEN = "\u001B[32m";
public static final String ANSI\_YELLOW = "\u001B[33m";
public static final String ANSI\_BLUE = "\u001B[34m";
public static final String ANSI\_PURPLE = "\u001B[35m";
public static final String ANSI\_CYAN = "\u001B[36m";
public static final String ANSI\_WHITE = "\u001B[37m";

Podremos utilizarlas para controlar el color que queremos mostrar con System.out.println.

Además podemos definir esta constante:

public static final String ANSI_RESET = "\u001B[0m";

que nos permitirá dejarlo todo como estaba y volver a los colores por defecto.

Así, podemos escribir lo siguiente:

System.out.println(ANSI_RED + "Texto de color rojo" + ANSI_RESET);

y veremos el color rojo como esperábamos:

dejando además la consola en su estado predeterminado, justo a continuación.

Del mismo modo podemos definir una serie de constantes para establecer el color de fondo que queremos usar con el texto, así:

public static final String ANSI_BLACK_BACKGROUND = "\u001B[40m";public static final String ANSI_RED_BACKGROUND = "\u001B[41m";public static final String ANSI_GREEN_BACKGROUND = "\u001B[42m";public static final String ANSI_YELLOW_BACKGROUND = "\u001B[43m";public static final String ANSI_BLUE_BACKGROUND = "\u001B[44m";public static final String ANSI_PURPLE_BACKGROUND = "\u001B[45m";public static final String ANSI_CYAN_BACKGROUND = "\u001B[46m";public static final String ANSI_WHITE_BACKGROUND = "\u001B[47m"

Con ellas podemos establecer también el color de fondo y combinarlas con las anteriores para el color del texto, así:

System.out.println(ANSI_GREEN_BACKGROUND + ANSI_BLUE + "Texto de color azul sobre fondo verde");System.out.println("Como no lo he resetado sigue igual.");System.out.println("¡Reseteo ahora!" + ANSI_RESET);System.out.println("FIN");

obteniendo esto por pantalla:

Si te fijas, mientras no le mandes el código de control de "reset" no se vuelve a establecer el color por defecto, por lo que podrías ir enviando comandos no visibles para cambio de color sin necesidad de escribir nada, y usarlos simplemente para ir controlando el cambio de colores.

Te dejo estos ejemplos (con las constantes, que es lo que te interesa) funcionando dentro de este repl.it. Pulsa sobre el botón verde del triángulo para ejecutarlo y ver los resultados.

Una pega: no funciona en Windows... Por defecto.

Esto que te acabo de enseñar funciona perfectamente en Mac y en Linux. Pero si lo intentas usar con Java en una consola de Windows verás que no te funciona.

Por suerte existe una biblioteca Open Source llamada JANSI que utiliza la Java Native Interface (JNI) para obtener los mismos resultados de manera coherente en todos los sistemas operativos, incluido Windows.

Solo tienes que descargarla, agregarla a tu proyecto y usar sus métodos específicos en vez de las constantes anteriores. Te funcionará también en el sistema de las ventanas. Mira la documentación en Github y verás que es muy sencillo.

¡Espero que te resulte útil!

Post original: https://www.campusmvp.es/recursos/post/como-cambiar-los-colores-de-la-consola-con-java-y-system-out-println.aspx

DEV Community: José M. Alarcón 🌐

Compartir código en Visual Studio: proyectos compartidos o librerías

Cómo crear un proyecto compartido en Visual Studio

No aparecen referencias a proyectos compartidos en proyectos web en VS2017

Referencias a archivos individuales

Cómo solucionar el error "java.lang.NoClassDefFoundError" en Java

¿Qué significa este error y por qué se produce?

Principales motivos para que se produzca la excepción NoClassDefFoundError

1.- El paquete no está disponible en el Classpath

2.- Faltan permisos suficientes

3.- Falta alguna dependencia de terceros

4.- Falta de visibilidad entre niveles de la jerarquía del ClassLoader

5.- Un script de inicialización sobrescribe a ClassPath

6.- Errores en un bloque de inicialización estática

7.- JDK desconfigurado o mal instalado

No están todos los que son pero sí son todos los que están

TypeScript contra JavaScript: ¿cuál deberías utilizar?

Pero ¿qué es TypeScript exactamente?

Características de JavaScript comparadas con las de TypeScript

Tooling

Ventajas de TypeScript

Desventajas de TypeScript

Entonces ¿uso JavaScript o TypeScript?

Java: ¿Por qué no me funciona la comparación de cadenas? Literales, clases y el repositorio de cadenas

El funcionamiento de las cadenas en Java - Repositorio o Pool de cadenas

Declaración de cadenas como clases

Y entonces ¿cómo comparo cadenas con seguridad?

"Internalizando" objetos de tipo cadena

En resumen

Intl: la API de localización nativa de JavaScript

El objeto Intl

Intl.Collator: para comparar cadenas de texto

Intl.DateTimeFormat: para dar formato a fechas y horas

Intl.RelativeTimeFormat: para facilitar la lectura de intervalos de tiempo relativos

Intl.NumberFormat: para dar formato a números y dinero

Intl.ListFormat: par dar formato a listas

Intl.PluralRules: para pluralización

Soporte

En resumen

Los mejores editores gratuitos de HTML, CSS y JavaScript (2019)

Adiós al diseño visual

Uso general: Visual Studio Code - El mejor para el día a día y para hacer de todo

Aprender: Brackets - Ideal para principiantes

Cloud: JSBin - Editor online para pruebas, experimentos y compartir ejemplos

Guía: Cuándo usar TypeScript en tus desarrollos web

Por qué este debate es hoy más importante que nunca

3 Categorías de problemas difíciles de resolver en software

1. El Problema del Sistema de Alto Rendimiento

2. El Problema del Sistema Embebido

3. El Problema de Dominio Complejo

JavaScript orientado a objetos

Tamaño del código

Software de producción frente a proyectos personales

Ausencia de pruebas unitarias

Startups

Trabajo en equipo

Equipos grandes

Comunicar patrones e implementar principios de diseño

Mejoras inmediatas

Equipos más pequeños y estilos de programación

Frameworks

React y Angular

Conclusión

Siempre se puede empezar a utilizar TypeScript gradualmente

Los errores de tiempo de compilación son mejores que los de tiempo de ejecución

Si estás en disposición de aprenderlo, apréndelo: hace maravillas con tus habilidades de diseño de software

Java 12 lanzado: versión descafeinada sin soporte a largo plazo

Switch expressions

Shenandoah, un nuevo recolector de basura

Otras cosillas

Java: cómo listar, filtrar y obtener información de carpetas y archivos

TRUCO - Depuración con Chrome: convertir archivos JavaScript en "cajas negras" para evitar depurarlos

Activando la capacidad de "blackboxing"

Añadir scrips a la caja negra

1.- Añadir rutas y/o nombres genéricos

2.- Convertir individualmente cada archivo en una caja negra

En resumen

Java y JavaScript ¿son lo mismo?

Cómo cambiar los colores de la consola con Java y System.out.println

Una pega: no funciona en Windows... Por defecto.

Principales motivos para que se produzca la excepción `NoClassDefFoundError`

El funcionamiento de las cadenas en Java - Repositorio o `Pool` de cadenas