DEV Community: campusMVP

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: Los 5 mejores frameworks para desarrollo Web

campusMVP — Mon, 23 Dec 2019 08:00:00 +0000

Post original en campusMVP

Java es sin duda el lenguaje más demandado en el mercado laboral. Sirve para crear todo tipo de aplicaciones : desde el móvil hasta el servidor, pasando por el escritorio o la Web. Y es esto último precisamente lo que nos ocupa hoy: el desarrollo Web.

Aunque Java ofrece de serie todo lo necesario para crear aplicaciones para Internet, no sería muy inteligente ceñirse tan solo a eso, al igual que no lo haríamos así con ninguna otra plataforma. Simplemente sería demasiado complejo. Así que para abstraernos de la necesidad de bajar mucho de nivel, existe una amplia oferta de frameworks Java que nos ayudan con el desarrollo Web , ofreciéndonos ya hechas muchas de las funcionalidades que necesitamos: desde acceso a bases de datos, gestión de sesiones, creación de servicios, servir contenidos estáticos, crear vistas.... y por supuesto reutilizar código, probarlo, etc...

Para orientarte en el camino sobre qué aprender para desarrollar aplicaciones Web con Java hemos creado esta lista con los 5 frameworks más importantes , los cuales son todos gratuitos y Open Source :

1.- Spring MVC

El conocido framework Spring es seguramente el más popular y utilizado del mundo. Se trata de un framework de desarrollo de aplicaciones ligero para Java EE que en realidad se puede utilizar para todo tipo de aplicaciones, no sólo para la Web, pero que es especialmente útil para éstas.

Nos ayuda a crear cualquiera de las capas de la aplicación, cosa en la que otros frameworks son más limitados. Dispone de varios sub-frameworks como: Spring Core , que dota de funcionalidad a todo lo demás; SpringMVC , para la parte que UI que se devuelve al navegador; Spring ORM , para el acceso a datos; Spring Security , para autenticación y autorización de las aplicaciones; etc...

Aumenta la productividad, reduce los errores y hace que las aplicaciones sean más fáciles de mantener. Soporta la configuración de su comportamiento a partir de XML o mediante anotaciones en el código. Permite usar JDBC para el acceso a datos si lo preferimos. También facilita el testing del código web. Ofrece una documentación muy buena.

Lo utiliza... prácticamente todo el mundo, pero hay muchas empresas conocidas que desarrollan con Spring: Netflix , Amazon o eBay por poner algunos ejemplos.

2.- Hibernate

Vale, esto no es específico para desarrollo Web, sino para cualquier desarrollo con Java que utilice acceso a datos. Pero es el framework de datos más utilizado del mundo y en cualquier desarrollo web lo vas a acabar utilizando.

Hibernate es un ORM que nos permite crear la capa de acceso a datos de nuestra aplicación utilizando objetos en lugar de consultas, disminuyendo la fricción entre el mundo de las bases de datos relacionales y la Programación Orientada a Objetos. Vamos, como cualquier ORM. La diferencia con otros es que Hibernate es con diferencia el más utilizado y ello significa que hay mucho más soporte y comunidad que para cualquier otro y te resultará más fácil resolver cualquier problema y obtener nuevas funcionalidades.

Su mayor desventaja es seguramente su tamaño y que puede resultar complejo a veces. Pero es algo que, si programas en Java hay que conocer sí o sí.

Al igual que en el caso de Spring, Hibernate lo usa casi todo el mundo para desarrollar en Java: la propia Oracle , IBM , Accenture...

3.- Struts

Otro framework de desarrollo para Java lleno de características, mantenido en este caso por la Fundación Apache. Es bastante antiguo pero por el mismo motivo está muy probado y lo utiliza mucha gente, y sacan versiones constantemente. Es comparable en muchos sentidos con Spring, que mencionamos antes. Está basado en el patrón MVC y su enfoque es en crear aplicaciones de nivel empresarial de manera rápida y que sean fáciles de mantener.

Dispone de una arquitectura basada en plugins que permiten extenderlo fácilmente con cualquier funcionalidad que requieras y no tenga de serie. Trae muchos plugins de serie para hacer de todo (procesar JSON, crear servicios REST...) y existen muchos más creados por la comunidad.

Lo puedes combinar con otros frameworks para conseguir funcionalidad que no tenga. Por ejemplo, puedes usar inyección de dependencias a través de Spring, o Hibernate para el acceso a datos.

Su mayor pega quizá sea que es más complejo que otros y que te fuerza a seguir un determinado estilo de programación y ciertas reglas (lo cual, en muchas empresas es una ventaja).

4.- JavaServer Faces (JSF)

JavaServer Faces es en realidad una especificación "estándar" para la creación de interfaces de usuario para aplicaciones Web, aunque se puede usar también para crear aplicaciones nativas. La creó la propia Oracle y su primera versión data del año 2004, así que es algo muy estable y probado también. Al igual que otros, utiliza el patrón MVC, y está basado en componentes. El objetivo es que puedas construir componentes de interfaz de usuario que sean reutilizables, pudiendo gestionar su estado, conectarlos a orígenes de datos y atarlos a eventos para realizar acciones.

Tiene un sistema de plantillas para crear los componentes que se llama Facelets y que utilizan XML en lugar de Java para definirlas, aunque puedes usar otros métodos para lo mismo sin salirte de JSF (usando Java directamente si quieres).

Es bastante complejo y no es el más rápido, pero tiene dos ventajas fundamentales: está incluido con Java EE (y los principales IDEs dan soporte de serie para usarlo) y la documentación es muy buena ya que está creada y mantenida por Oracle.

5.- Grails

Grails es un framework de desarrollo Web que utiliza el lenguaje Groovy para la plataforma Java. Groovy es un lenguaje orientado a objetos que compila a Bytecode y que está enfocado a fondo en la productividad del desarrollador. Por ese motivo, Grails lo que te da es una productividad altísima y te permite estar produciendo código para tu aplicación de manera casi inmediata (en 1 hora puedes tener tu primera aplicación probada y en marcha).

Aunque programas con Groovy y no con Java directamente, la sintaxis es compatible con Java y además funciona de maravilla con otras tecnologías Java como Hibernate o incluso Spring. De hecho está basado en Spring Boot, por lo que incluye características como la inyección de dependencias. Sigue buenas prácticas y principios de desarrollo modernos como convención sobre configuración.

Escala bien y te servirá tanto para proyectos pequeños como muy grandes. El soporte de los diferentes IDEs es muy bueno. Tiene centenares de plugins para hacer casi cualquier cosa que se te ocurra.

La documentación de Grails es muy buena, y tiene también unas guías paso a paso de Grails muy buenas.

Post original en campusMVP

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!

Paquetes en Java: qué son, para qué se utilizan, y cómo se usan (con vídeo)

campusMVP — Wed, 14 Aug 2019 08:00:00 +0000

Post original escrito por Franciso Charte en campusMVP

Los paquetes son el mecanismo que usa Java para facilitar la modularidad del código. Un paquete puede contener una o más definiciones de interfaces y clases, distribuyéndose habitualmente como un archivo. Para utilizar los elementos de un paquete es necesario importar este en el módulo de código en curso, usando para ello la sentencia import.

La funcionalidad de una aplicación Java se implementa habitualmente en múltiples clases, entre las que suelen existir distintas relaciones. Las clases se agrupan en unidades de un nivel superior, los paquetes , que actúan como ámbitos de contención de tipos. Cada módulo de código establece, mediante la palabra clave package al inicio, a qué paquete pertenece. Como ya sabrás, con la cláusula import cualquier módulo de código puede hacer referencia a tipos definidos en otros paquetes.

Vamos a familiarizarnos con los procedimientos para construir paquetes, para referenciarlos desde otros puntos y también veremos la relación existente entre paquetes, clases y el sistema de archivos donde se almacena el proyecto.

Creación de paquetes

Un paquete Java se genera sencillamente incluyendo la palabra clave package al inicio de los módulos de código en los que se definen las clases que formarán parte del mismo. Trabajando en un proyecto con NetBeans, comprobaremos que en la ventana Projects los paquetes se representan con un icono específico y actúan como nodos contenedores, alojando los módulos .java con el código fuente. El menú contextual del proyecto nos ofrece la opción New>Java Package, que será el que usemos habitualmente para crear un nuevo paquete:

Nota : cada vez que se crea un nuevo proyecto con NetBeans se propone la definición de un nuevo paquete, cuyo nombre sería el mismo del proyecto, donde se alojarían los módulos de código. En proyectos complejos, no obstante, puede ser necesaria la creación de paquetes adicionales.

Un paquete puede contener, además de definiciones de tipos como las clases e interfaces, otros paquetes, dando lugar a estructuras jerárquicas de contenedores. La denominación de los subpaquetes, paquetes contenidos en otros , se compondrán del identificador del contenedor seguido de un punto y el nombre del subpaquete. De existir niveles adicionales se agregarían los distintos identificadores separados por puntos, formando así el nombre completo del paquete.

El diagrama siguiente representa el contenido de un paquete llamado campusmvp, teóricamente correspondiente a un proyecto de aplicación de contabilidad. En ese paquete de primer nivel tenemos un subpaquete con utilidades, llamado campusmvp.util, no directamente vinculadas con la aplicación de contabilidad. El subpaquete campusmvp.conta contendría todos los elementos asociados a dicha aplicación, distribuidos a su vez en un tercer nivel de paquetes que contienen las clases correspondientes al modelo, la vista, etc., siguiendo al patrón arquitectónico MVC. Cada uno de los módulos de definición de clase, denominados Cuenta.java, Movimiento.java, Vista.java, etc., comenzarían con una cláusula package indicando el nombre completo del paquete al que pertenecen :

Nota : todas las clases que pertenecen a un mismo paquete comparten un ámbito común, al que pertenecerán aquellos miembros que no especifiquen explícitamente otro tipo de visibilidad.

Importación de paquetes

Los paquetes Java son como cajas de herramientas , cada una de ellas con una colección distinta de instrumentos útiles para nuestro trabajo, a las que podemos necesitar acceder cada vez que abordamos el desarrollo de un nuevo proyecto. Es en este contexto donde recurriremos a la cláusula import , a fin de importar en el ámbito actual las definiciones de otro paquete y poder usarlas según el procedimiento habitual, creando objetos, accediendo a los servicios de las clases, etc.

La cláusula import puede utilizarse para importar un elemento concreto de un paquete, facilitando el nombre de este seguido de un punto y el identificador de dicho elemento. Por ejemplo, para importar la clase Math del paquete java.lang, pudiendo así acceder a la constante PI y las funciones matemáticas que aporta, bastaría con la siguiente línea:

import java.lang.Math;

Es habitual que al importar un paquete nos interesen muchas de las clases definidas en el mismo. En este caso podríamos importarlas individualmente, usando la sintaxis anterior, o bien podríamos recurrir a la siguiente alternativa. Esto nos permitiría usar la clase Math, así como la clase System, la clase Thread y muchas otras definidas en el paquete java.lang:

import java.lang.\*;

En ocasiones, como ocurre con la clase Math, importamos una clase para acceder directamente a sus miembros estáticos, constantes y métodos , no para crear objetos a partir de ellas, lo que nos fuerza a utilizar constantemente la sintaxis Clase.miembro, por ejemplo Math.PI o Math.sin(). Si tras importar la clase Math intentamos referirnos a estos miembros simplemente por su nombre, como se hace en la mitad superior de la siguiente imagen, obtendremos un error. En estos casos podemos recurrir a la sintaxis import static paquete.clase.* , cuya finalidad es incluir en el ámbito actual los miembros estáticos de la clase indicada. Es lo que se hace en la mitad inferior de la siguiente imagen:

Relación entre clases, paquetes y el sistema de archivos

En Java existe una estrecha relación entre las definiciones de paquetes y clases y el sistema de archivos local , en el que se almacenan los módulos conteniendo el código. Es un hecho que puede pasarnos totalmente inadvertido al trabajar con un IDE como el de NetBeans, ya que sus opciones se encargan de ocultar estos detalles. No obstante, es interesante que conozcamos dicha relación ya que esto nos permitirá, en caso de necesidad, trabajar directamente con el JDK.

Cada módulo de código de un proyecto Java únicamente puede contener una clase pública, cuyo nombre, respetando mayúsculas y minúsculas, debe coincidir con el del módulo. Es decir, existe una correspondencia directa entre los identificadores de clase y archivos en los que se alojan. Esto no afecta a las clases anidadas y otras clases no públicas que pudiesen definirse en el mismo módulo.

El nombre del paquete establece además el nombre de la carpeta donde se alojan los módulos de código contenidos en el paquete. Los nombres de paquete pueden ser compuestos, usándose el punto como separador de las diferentes porciones del identificador. Cada parte identificaría a un subdirectorio, según se muestra en el siguiente esquema:

Al trabajar desde la línea de comandos, usando directamente el JDK, hemos de tener en cuenta que tanto la compilación como la ejecución verificarán que se satisface la correspondencia entre el nombre de paquete y clase y la estructura de directorios y nombre de archivo. Si esta no se cumple en algún punto, como ocurre en la parte inferior de la siguiente imagen, se obtiene un error.

Nota : la estructura de directorios de un paquete puede almacenarse completa, una vez se compila el proyecto, en un archivo JAR. Este contendría asimismo los archivos de clase de cada módulo de código.

A continuación puedes ver un vídeo práctico explicativo de todo lo anterior, que está extraído directamente del curso de programación con Java de campusMVP:

Post original escrito por Franciso Charte en campusMVP

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.

5 motivos por los que utilizar Java para desarrollar tus aplicaciones

campusMVP — Wed, 10 Apr 2019 08:00:00 +0000

Post original: https://www.campusmvp.es/recursos/post/5-motivos-por-los-que-utilizar-java-para-desarrollar-tus-aplicaciones.aspx

Java es una plataforma de desarrollo de propósito general cuya principal oferta de valor siempre ha sido "Escribe una vez, ejecuta en todas partes". En la actualidad es prácticamente ubicua: puedes encontrar aplicaciones Java desde pequeños dispositivos conectados del "Internet de las Cosas" (IoT), hasta servidores, pasando por aplicaciones de gestión en escritorio, desarrollos para móviles, videojuegos...

Existen diversos motivos, técnicos y no técnicos, para la popularidad de Java, pero ¿cuáles son las principales propuestas de valor TÉCNICAS para desarrollar con Java?

Seguro que hay muchas más, y desde luego las siguientes no son exclusivas de Java en su mayor parte, pero la combinación de todas ellas, por lo que nos cuentan nuestros alumnos de Java, es lo que suelen valorar las empresas:

1.- Es multiplataforma

Aunque en la actualidad no es una ventaja tan grande como lo era cuando nació y hay muchas otras plataformas que ofrecen multiplataforma, lo cierto es que el hecho de que Java funcione en prácticamente cualquier dispositivo, servidor o sistema operativo, sigue siendo uno de sus principales atractivos para mucha gente.

Existe una implementación de la máquina virtual de Java para casi cualquier sistema que se nos ocurra.

Además no debemos olvidar que Java se diseñó inicialmente para ejecutarse en dispositivos embebidos, con muchas limitaciones de memoria y potencia, por lo que, dependiendo de dónde lo ejecutemos, puede resultar de gran ayuda apoyarse en el lenguaje.

2.- El código Java es robusto

Hay otros lenguajes como C++ que ofrecen más rendimiento y mayor control, pero que son mucho más difíciles de manejar sin meter la pata. Java es un lenguaje que ofrece manejo automático de la memoria y cuyos objetos no hacen referencia a datos fuera de sí mismos o de otros objetos de Java. Esto hace imposible que una instrucción de Java pueda corromper la memoria, ni "pisar" o comprometer los datos de otras aplicaciones o del propio sistema operativo. La máquina virtual realiza todo tipo de comprobaciones para asegurar la integridad que impiden que pueda romper el sistema operativo u otros programas.

También gestiona la liberación de memoria de manera automática, por lo que la usa eficientemente sin que el programador tenga que preocuparse de nada.

Nuevamente, esto no es exclusivo de Java, ya que otras plataformas, como .NET, disponen de las mismas protecciones, pero es una ventaja frente a plataformas más tradicionales.

3.- Es orientada a objetos

Otra cuestión que no llama la atención por especial en la actualidad, pero a mediados de los años 90, cuando se lanzó Java, no era algo tan frecuente como lo es ahora. Gracias a su orientación a objetos es más fácil crear aplicaciones modulares y reutilizar partes de las mismas, además de que permite implementar mejores patrones de diseño probados que contribuyen a la robustez que se comentaba en el apartado anterior.

También es uno de los motivos de que la propia plataforma sea tan extensible y disponga de tantas funcionalidades nativas o añadidas.

Lo cual nos lleva a...

4.- Funcionalidad de base y mucho código Open Source

Aparte de la enorme cantidad de funcionalidad base que ya incluye la propia plataforma listo para ser utilizado, con Java dispones de muchísimo código de terceros listo para ser utilizado.

Entre que lleva bastante más de dos décadas entre nosotros y que la comunidad es enorme, existen infinidad de bibliotecas y utilidades creadas para extender la funcionalidad y mejorar la plataforma Java.

Casi cualquier cosa que puedas necesitar seguro que la encuentras ya creada en algún proyecto de código abierto. No solo eso: mucha de las bibliotecas más conocidas y utilizadas las han creado y las mantienen grandes organizaciones como Google, Facebook o la fundación Apache, lo cual siempre es una garantía adicional.

Esto facilita mucho la vida de los programadores y no existen muchas otras plataformas que puedan aportar la misma exuberante variedad de código utilizable.

5.- Java es relativamente fácil de aprender

Comparado con lenguajes clásicos como C o C++, desde luego. En general se puede decir que Java no es un lenguaje más difícil de aprender que cualquier otro, especialmente otros modernos como C# o Swift, pero sí que es más fácil de aprender que muchos otros.

Gracias a herramientas especializadas (¡y gratuitas!) como NetBeans y otros editores o entornos de desarrollo, la compilación, depuración y despliegue es muy sencillo y comenzar con él muy fácil.

Como cualquier plataforma compleja y de propósito general como esta, tienes dos retos al aprenderla:

Hay tanta funcionalidad que es difícil saber por dónde empezar y cuáles de las, literalmente, miles de clases disponibles debes aprender.
A medida que aprendes y profundizas la cosa se vuelve más compleja y necesitas dominar mejor los fundamentos para poder salir adelante.

Ninguna de estas ventajas es exclusiva de Java y se puede aplicar a otras plataformas, especialmente a .NET y el lenguaje C#. Sin embargo, la combinación de lo que hemos dicho con el hecho de llevar tanto tiempo en el mercado, la enorme comunidad de desarrolladores que hay por todo el mundo y la gran demanda existente en empresas e instituciones, crea un "círculo virtuoso" que hace que Java sea desde hace muchos años la plataforma de desarrollo más importante.

Post original: https://www.campusmvp.es/recursos/post/5-motivos-por-los-que-utilizar-java-para-desarrollar-tus-aplicaciones.aspx

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

Contenedores: cómo es el ciclo de vida de una aplicación en Kubernetes

campusMVP — Thu, 21 Mar 2019 08:00:00 +0000

Post original escrito por Eduard Tomás en campusMVP

Hace poco os explicaba en un artículo qué es Kubernetes, cuál es su arquitectura y su funcionamiento básico. Léelo antes de continuar si no tienes claros estos conceptos.

En esta ocasión voy a continuar con aquella explicación analizando cómo es el ciclo de vida de una aplicación que está desplegada con Kubernetes.

Lo primero que debemos tener claro es que en Kubernetes nunca se ejecutan contenedores de forma directa. Es decir, no se puede desplegar un contenedor o parar un contenedor. En su lugar se opera con lo que se llaman pods.

Un pod es la unidad mínima de despliegue y operación en Kubernetes. Es decir, desplegamos pods, escalamos pods y son los pods los que se ejecutan en los distintos nodos.

La relación entre pod y contenedor no tiene por qué ser de uno a uno: es decir, en un único pod se pueden ejecutar varios contenedores. Solo recuerda que en este caso se escalarán y desplegarán de forma conjunta (ya que se escala o despliega todo el pod).

Aunque es posible, teóricamente, desplegar en un pod una web y su API en dos contenedores, eso no es lo que suele hacer. En la gran mayoría de casos las relaciones entre pod y contenedor son, efectivamente, de uno a uno. Pero que un pod pueda ejecutar varios contenedores habilita ciertos escenarios avanzados como p. ej. tener un contenedor que ofrezca servicios a otro contenedor (como podría ser hacer de proxy, de logger o similar).

Es importante tener presente que todos los contenedores que se ejecutan en un mismo pod comparten espacio de red. Es decir, se comunican entre ellos usando localhost y no pueden abrir los mismos puertos. También comparten el espacio IPC por lo que pueden usar cualquier técnica de IPC (como semáforos) para comunicarse entre ellos.

Los distintos estados de un pod

Un pod pasa por varias fases a lo largo de su ciclo de vida:

Pending : el pod ha sido creado, pero aún no se han creado sus contenedores ni se ha decidido qué nodo lo va a ejecutar.
Running : los contenedores del pod han sido creados y el pod ya se está ejecutando en un nodo. Al menos un contenedor del pod se está ejecutando o está en proceso de creación.

Esto es importante : que un pod esté en estado running no significa que sus contenedores estén ejecutándose. P. ej. se pueden estar iniciando o reiniciando.

Succeeded : los contenedores del pod han finalizado (todos) su ejecución de forma satisfactoria.
Failed : los contenedores del pod han finalizado (todos) su ejecución y al menos uno de ellos lo ha hecho con error.
Unknown : el estado del pod no se puede saber. Esto suele indicar un error de comunicación con el nodo minion que está ejecutando el pod.
CrashLoopBackOff : el pod está corriendo, pero uno de sus contenedores se está reiniciando debido a que ha terminado (generalmente de forma errónea).

Es importante separar el ciclo de vida del pod del ciclo de vida de sus contenedores. Un pod puede estar en la fase de running pero uno de sus contenedores puede no estar ejecutándose. Cuando un pod _está en fase de _CrashLoopBackOff eso significa que uno de los contenedores está en proceso de reinicio, pero otros contenedores del pod pueden estar ejecutándose.

Muchas veces se dice que Kubernetes reinicia un pod pero esa expresión no es estrictamente cierta: Kubernetes reinicia contenedores de un pod, pero el pod en sí mismo sigue ejecutándose durante todo este tiempo. Que Kubernetes decida reiniciar o no los contenedores de un pod (y en qué casos) depende de la configuración del pod. Es decir, para ciertos pods no hay posibilidad de que entren nunca en fase de Succeeded ya que su misión es estar ejecutándose permanentemente (p. ej. una API), por lo que si un contenedor termina será reiniciado por Kubernetes.

Los pods se consideran "objetos transitorios", en el sentido de que hay determinados eventos del clúster a los cuales no sobreviven. P. ej. si el nodo minion se cae, todos los pods que se estén ejecutándose en él se caen también. Los pods no se mueven de nodo ni se reinician (sí se reinician sus contenedores como se ha comentado antes).

En general no se suele crear nunca pods de forma directa , en su lugar usamos lo que llamamos un controlador. Un controlador es el responsable de garantizar que en todo momento se cumple una cierta condición al respecto de los pods que controla, como que en todo momento haya N instancias de este pod.

Hago aquí un inciso de nomenclatura: cuando digo "N instancias de un pod" me refiero a N pods _idénticos (ejecutando los mismos contenedores y con la misma configuración) pero son N _pods.

Si estamos usando un controlador y deseamos tener en todo momento 2 instancias de un determinado pod y uno de los dos pods se muere (porque se muere su nodo p. ej.), el controlador creará otro pod para asegurar de que siga habiendo dos instancias.

Cuando tenemos N instancias, los N pods se consideran todos "idénticos". Si por algún motivo (p. ej. debe desescalarse) debe eliminarse algún pod, el controlador eliminará uno cualquiera, sin preferencias. Eso encaja con el modelo stateless de aplicación en el que los contenedores encajan perfectamente. Es decir, como desarrollador debes asegurar que tus contenedores sean stateless, ya que en cualquier momento Kubernetes puede decidir eliminar el pod (y por lo tanto el contenedor) y recrearlo en otra parte.

Este modelo stateless no siempre aplica: a veces, si tenemos N instancias de un pod hay alguno que juega un rol especial y por lo tanto se requiere que estos tengan identidad. Un ejemplo es una configuración de base de datos en modo maestro/esclavo. Si uno de los pods se cae, el nuevo que se cree debe ser del mismo tipo, y no solo eso, sino que debe recibir el estado que tenía el pod caído. Kubernetes es capaz de gestionar estos casos mediante un controlador específico (llamado StatefulSet), pero lo ideal es que nuestras aplicaciones sean stateless.

Post original escrito por Eduard Tomás en campusMVP

10 Diferencias entre .NET Core y .NET Framework

campusMVP — Tue, 19 Mar 2019 08:00:00 +0000

Post original escrito por José María Aguilar en campusMVP

Seguro que todos los desarrolladores que trabajáis normalmente usando herramientas Microsoft habéis oído hablar bastante de .NET Core en los últimos tiempos. Incluso quizás muchos de vosotros habéis tenido oportunidad de trabajar con este nuevo framework y ya conocéis sus principales características y las bondades (e incluso algún que otro inconveniente) que ofrece sobre el ya clásico .NET Framework.

Pero probablemente sois muchos también los que sólo lo conocéis de oídas, pues vuestro día a día está más enfocado al mantenimiento de sistemas existentes, o quizás trabajáis sobre tecnologías que están ancladas a versiones determinadas del framework .NET, o simplemente el fragor de la batalla diaria no os deja tiempo para explorar nuevos horizontes.

Si este último es tu caso, lo mínimo que debes saber es que .NET Core es una implementación del estándar .NET que , al igual que otras implementaciones como .NET Framework o Mono, incluye todo lo necesario para crear y ejecutar aplicaciones : como los compiladores, las bibliotecas de clases básicas o la máquina virtual o runtime que proporciona el entorno donde se ejecutan las aplicaciones.

En otras palabras, con .NET Core puedes crear una aplicación con lenguajes como C# o VB.NET, utilizar en ella clases básicas como las habituales string, int o List<T>, compilarla a bytecode CIL y ejecutarla en tu ordenador.

Entonces, ¿qué diferencia a .NET Core de .NET Framework? Pues precisamente eso es lo que vamos a ver en este artículo 😉

1. NET Core es nuevo, y escrito prácticamente desde cero

.NET Core es, en muchos sentidos, un reboot de .NET Framework y ha tenido que ser reescrito desde cero. Obviamente se han aprovechado las APIs, ya estandarizadas y conocidas por todos los desarrolladores, pero internamente se han vuelto a implementar muchos componentes para poder lograr los ambiciosos objetivos que se plantearon en su diseño y que veremos en algunos puntos siguientes.

2. .NET Core es open source

Aunque determinados componentes del stack clásico, como ASP.NET MVC o Entity Framework, habían sido publicados bajo licencias open source, .NET Framework no era un marco de trabajo abierto en su totalidad y aún tiene piezas distribuidas bajo licencias propietarias.

.NET Core es un proyecto completamente open source desde sus orígenes. De hecho, aunque dirigido y soportado oficialmente por Microsoft, el proyecto pertenece a la .NET Foundation y en su desarrollo están involucrados activamente cientos de desarrolladores de todo el mundo, que pueden participar en su diseño y realizar contribuciones de cualquier tipo al framework.

3. .NET Core es multiplataforma

Sin duda, una de las características .NET Core que más lo diferencian respecto a sus predecesores es su capacidad real de funcionar en múltiples plataformas , incluyendo algunas impensables hace sólo algunos años, como Linux o macOS.

Los SDK y runtimes están disponibles para una gran variedad de sistemas operativos y distribuciones (Windows, macOS, Ubuntu, RHEL, Debian, Fedora, CentOS...), lo que hace que sea posible desarrollar aplicaciones sobre cualquiera de las plataformas soportadas y ejecutarlas también sobre cualquiera ellas. De esta forma, ahora sería totalmente posible, por ejemplo, programar una aplicación en Windows y ejecutarla en un Mac, o desarrollarla en Mac y ejecutarla en una distribución Debian de Linux.

De la misma forma, es compatible con distintas arquitecturas de procesador , como x64, x86 o ARM, lo que posibilita su uso en diversos tipos de dispositivo.

4. .NET Core es modular

.NET Framework es un bloque monolítico que ha ido creciendo con el tiempo hasta convertirse en algo difícil de manejar. Por ejemplo, las distintas versiones o revisiones actualizan el framework completo, muchas veces sobrescribiendo las versiones anteriormente instaladas (con los problemas que esto podría provocar). También, suelen estar bastante distanciadas en el tiempo, porque se trata de actualizaciones completas del marco de trabajo.

En cambio, .NET Core está formado por distintas piezas distribuidas a través de paquetes NuGet. De esta forma, las correcciones a bugs o mejoras en componentes concretos pueden distribuirse y actualizarse de forma independiente al resto, sólo actualizando el paquete correspondiente. Sin duda, un modelo mucho más ágil y eficiente que el anterior, y que permite un ritmo de evolución mucho más rápido.

5. Las operaciones principales de .NET Core se realizan desde línea de comandos

Para conseguir ser cross platform real, era absolutamente imprescindible que las herramientas de .NET Core estuviesen disponibles en Windows, Linux y Mac. ¿Y cómo conseguirlo de la forma más sencilla? Pues acudiendo al denominador común: la línea de comandos.

A diferencia de .NET Framework, donde a veces nos encontrábamos casi obligados a utilizar Visual Studio, para compilar, ejecutar, testear o publicar aplicaciones .NET Core basta con tener a mano la línea de comandos de cada sistema operativo y utilizar las órdenes de la CLI (Command Line Interface) proporcionada por el framework.

Aquí tienes algunos ejemplos de comandos en acción:

C:\Test>dotnet new console
Preparándose...
La plantilla "Console Application" se creó correctamente.

Procesando acciones posteriores...
Ejecutando "dotnet restore" en C:\Test\Test.csproj...
  Restaurando paquetes para C:\Test\Test.csproj...
  Generación de archivo MSBuild C:\Test\obj\Test.csproj.nuget.g.props.
  Generación de archivo MSBuild C:\Test\obj\Test.csproj.nuget.g.targets.
  Restauración realizada en 147,78 ms para C:\Test\Test.csproj.

Restauración correcta.

C:\Test>dotnet build
Microsoft (R) Build Engine versión 15.9.20+g88f5fadfbe para .NET Core
Copyright (C) Microsoft Corporation. Todos los derechos reservados.

  Restauración realizada en 23,44 ms para C:\Test\Test.csproj.
  Test -> C:\Test\bin\Debug\netcoreapp2.2\Test.dll

Compilación correcta.
    0 Advertencia(s)
    0 Errores

Tiempo transcurrido 00:00:00.52

C:\Test>dotnet run
Hello World!

C:\Test>_

6. .NET Core puede distribuirse de varias formas

Como seguramente sabes ya, .NET Framework se distribuye a través paquetes descargables que se instalan en el equipo de forma única, es decir, sólo puede existir una copia a nivel de equipo. Además, determinadas versiones (principalmente actualizaciones) sobrescriben la versión instalada anteriormente, por lo que puede dar lugar a problemas si tenemos aplicaciones que dependen de versiones específicas.

.NET Core es mucho más flexible en este sentido : el framework puede estar instalado a nivel de equipo, como .NET Framework, pero también podemos hacerlo a nivel de usuario o incluso a nivel de aplicación (es decir, que cada aplicación incluya su propia copia de .NET Core).

Además, distintas versiones y revisiones pueden convivir sin problemas en el mismo equipo. Por ejemplo, la siguiente traza de consola muestra el resultado de invocar el comando dotnet --info, donde aparecen las distintas versiones del SDK y runtimes instalados en mi equipo:

C:\>dotnet --info
SDK de .NET Core (reflejando cualquier global.json):
 Version: 2.2.102
 Commit: 96ff75a873

Entorno de tiempo de ejecución:
 OS Name: Windows
 OS Version: 10.0.17763
 OS Platform: Windows
 RID: win10-x64
 Base Path: C:\Program Files\dotnet\sdk\2.2.102\

Host (useful for support):
  Version: 2.2.1
  Commit: 878dd11e62

.NET Core SDKs installed:
  1.1.11 [C:\Program Files\dotnet\sdk]
  2.1.202 [C:\Program Files\dotnet\sdk]
  2.1.503 [C:\Program Files\dotnet\sdk]
  2.2.102 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 1.0.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.10 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

C:\>_

7. .NET Core no soporta todos los modelos de aplicación ni todos los frameworks

Lo más habitual es que a la hora de construir aplicaciones lo hagamos subidos a hombros de gigantes, es decir, utilizamos frameworks que nos ayudan a desarrollar más rápidamente y con menos errores. Por ejemplo, si vamos a crear una aplicación web, lo habitual es usar ASP.NET, si nuestra aplicación es de escritorio podríamos usar WinForms o WPF, o si vamos a acceder a datos, una opción razonable es Entity Framework.

Pues bien, muchos de estos frameworks sólo funcionan sobre las plataformas para las que han sido creados. Por ejemplo, SignalR, ASP.NET MVC o Entity Framework 6 sólo funcionarán sobre .NET Framework porque es el framework para el que han sido construidos.

Como consecuencia, a día de hoy, con .NET Core 2.x sólo podemos crear determinados tipos de aplicaciones : consola, web (ASP.NET Core) y Xamarin. Esto limita algo las posibilidades de uso de este framework, pero, afortunadamente, esto va a cambiar en un futuro próximo: previsto para 2019, .NET Core 3.0 incluirá soporte para WPF y Windows Forms , que se beneficiarán de algunas de las ventajas que aportan este nuevo marco de trabajo.

En definitiva, a la hora de desarrollar con .NET Core debemos utilizar marcos de trabajo específicos para esta plataforma , como ASP.NET Core, Entity Framework Core o SignalR Core.

8. En .NET Core el rendimiento es algo prioritario

Desde sus orígenes, en .NET Core el rendimiento ha sido siempre una prioridad , y esto se pone de manifiesto en los benchmarks que demuestran que este framework supera a su predecesor con creces en este aspecto.

Por dar algunas cifras, algo tan simple y recurrente como utilizar los métodos IndexOf() o StartsWith() sobre una cadena son un 200% más rápidos en .NET Core que en .NET Framework. Un ToString() sobre el elemento de un enum gana un 600% de rendimiento. LINQ es hasta un 300% más eficiente en determinados puntos. Lazy<T> es un 500% más rápido...

Beneficiarios directos de estas mejoras son los frameworks específicos como ASP.NET Core o Entity Framework Core. Por ejemplo, el primero de ellos se ha situado ya sólidamente en los top ten de los marcos de trabajo más rápidos para la web según las pruebas TechEmpower soportando más de 7 millones de peticiones por segundo , algo impensable en ASP.NET 4.x.

9. .NET Core ha sido creado pensando en los tiempos modernos

Cuando se creó .NET Framework, hace más de quince años, una nube era simplemente un agregado visible de minúsculas gotitas de agua, de cristales de hielo o de ambos, suspendido en la atmósfera y producido por la condensación de vapor de agua (RAE dixit), los contenedores se usaban exclusivamente para almacenar cosas diversas, como mercancías o residuos, y probablemente al hablar de microservicios sólo podíamos pensar en cuartos de baño pequeñitos 😆

Hoy en día, el cloud está presente en casi cualquier aspecto del desarrollo, sobre todo en aplicaciones que, de alguna u otra forma, hacen uso de Internet. Los contenedores se han consolidado como una forma simple, ágil y escalable para desplegar aplicaciones, y los microservicios se han demostrado como arquitecturas apropiadas en múltiples escenarios.

.NET Core y los frameworks construidos sobre él han sido creados teniendo en cuenta todos estos aspectos. Sus componentes están diseñados con el enfoque cloud-first en mente, por lo que se integran a la perfección en infraestructuras de nube. Se trata además de una tecnología especialmente recomendada para la construcción de microservicios, entre otros aspectos, por la facilidad con que pueden ser creados y distribuidos en contenedores.

10. Se pueden desarrollar aplicaciones .NET Core con cualquier editor o IDE

Ni a nuestros más acérrimos enemigos le desearíamos algo tan terrible como crear aplicaciones para .NET Framework sin Visual Studio. De hecho, aunque técnicamente era evitable, en muchos modelos de aplicación (por ejemplo, WinForms, WPF o ASP.NET) era prácticamente obligatorio utilizar el IDE de Microsoft.

Por el contrario, con .NET Core tenemos libertad completa a la hora de elegir el editor que utilizaremos en el desarrollo de nuestros proyectos. Si trabajamos sobre Windows, muchos preferimos seguir utilizando Visual Studio en el día a día (al fin y al cabo, es el mejor IDE 😜, pero hay quien prefiere trabajar con Visual Studio Code, o con editores alternativos como Atom, Brackets o Sublime Text. Y si trabajamos desde Linux o Mac, podemos utilizar cualquier editor disponible en dichos entornos.

Corolario: .NET Core es tu próximo framework

Lo queramos o no, .NET Core se convertirá en algún momento en la herramienta que usaremos en nuestro día a día. Aunque en principio .NET Framework seguirá existiendo y Microsoft continuará dándole soporte, la tendencia actual indica que todo está confluyendo en .NET Core : Xamarin, WPF, WinForms, Entity Framework, SignalR o MVC son sólo algunos ejemplos de frameworks que ya están o van a estar pronto basados en la nueva infraestructura.

Además, es lógico pensar que estos marcos de trabajo continuarán evolucionando exclusivamente sobre .NET Core. Sólo hay que mirar un poco hacia atrás y ver que en los últimos dos años han aparecido ya varias versiones completas de frameworks como Entity Framework Core o ASP.NET Core, mientras que EF o ASP.NET MVC "clásicos" apenas han lanzado pequeñas actualizaciones.

En nuestro curso de ASP.NET Core MVC se estudia a fondo la creación de aplicaciones Web con el nuevo framework de Microsoft. ¿A qué esperas para dar el salto?

Post original escrito por José María Aguilar en campusMVP: https://www.campusmvp.es/recursos/post/10-diferencias-entre-net-core-y-net-framework.aspx

DEV Community: campusMVP

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: Los 5 mejores frameworks para desarrollo Web

1.- Spring MVC

2.- Hibernate

3.- Struts

4.- JavaServer Faces (JSF)

5.- Grails

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

Paquetes en Java: qué son, para qué se utilizan, y cómo se usan (con vídeo)

Creación de paquetes

Importación de paquetes

Relación entre clases, paquetes y el sistema de archivos

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

5 motivos por los que utilizar Java para desarrollar tus aplicaciones

1.- Es multiplataforma

2.- El código Java es robusto

3.- Es orientada a objetos

4.- Funcionalidad de base y mucho código Open Source

5.- Java es relativamente fácil de aprender

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

Switch expressions

Shenandoah, un nuevo recolector de basura

Otras cosillas

Contenedores: cómo es el ciclo de vida de una aplicación en Kubernetes

Los distintos estados de un pod

10 Diferencias entre .NET Core y .NET Framework

1. NET Core es nuevo, y escrito prácticamente desde cero

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

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