Activa el historial del portapapeles en Windows 10 (y de paso en Office aunque no tengas Windows 10)

08/03/2019
Artículo original

Hoy un truco rápido...

Una de las cosas que más utilizo en el sistema operativo es el portapapeles. Para mi es básico, y supongo que para la mayoría de los usuarios también. Poder copiar/cortar algo y duplicarlo en cualquier otro lado es uno de los inventos más útiles que se han dado en la informática moderna, pero como lo tenemos tan interiorizado ni siquiera le prestamos atención. Aprovecho para reivindicarlo.

El caso es que, para mi, una de las mayores limitaciones que ha tenido el portapapeles de Windows es que solo recuerda lo último que has copiado, pero nada de lo anterior. Y lleva siendo así desde Windows 1.0. No me explico cómo no han solucionado el tema antes.

Ha habido intentos... Por ejemplo, mucha gente no lo sabe, pero Microsoft Office integra un histórico del portapapeles desde hace varios lustros (no recuerdo la versión exacta). Para sacarlo basta con ir a la sección Portapapeles del "ribbon" de cualquiera de las aplicaciones, y pulsar en el iconito que es como una flecha:

Animación que muestra cómo sacar el portapapeles especial de Office

Verás que ahí tienes un historial de hasta las 20 últimas cosas que hayas copiado. Además puedes especificar otras opciones como por ejemplo que salga solo cuando copias algo o cuanod pulses dos veces seguidas CTRL+C para copiar.

Nota: El histórico que aparece ahí sobrevive al cierre de las aplicaciones, así que ¡mucho cuidado si copias cosas en un ordenador compartido!

Es interesante, pero limitado porque solo funciona en Office. Lo que a mi me gustaría y llevo deseando décadas es tener algo así en el propio sistema operativo. Ahora por fin ya lo tenemos disponible.

Desde la última actualización de Windows (la versión 1809 que apareció el mes pasado), existe la posibilidad de activar un portapapeles con histórico. Esto iba a salir en la actualización de octubre de 2018 pero al final lo pospusieron por problemas de última hora con la funcionalidad. Ahora por fin está disponible. Asegúrate de que tienes Windows 10 actualizado a lo más reciente.

Por defecto no viene activado, así que deberás activarlo expresamente para poder sacarle partido.

Para activarlo debemos acudir a la configuración del sistema (Windows + I) y buscar "Portapapeles" o ir a la sección Sistema·Portapapeles:

Una vez en la sección correspondiente podremos activar dos cosas como se ve en la figura anterior (está en inglés porque todos mis sistemas están en este idioma):

  1. Histórico del portapapeles: que permitirá guardar en dicho histórico las cosas que hayamos ido copiando y pegando recientemente.
  2. Sincronizar entre equipos: si tienes una cuenta de Microsoft asociada a la cuenta del equipo (muy habitual en equipos del hogar, no tanto en empresas) podrás hacer que ese histórico se sincronice entre todos tus equipos e incluso con tu móvil Android. Personalmente no lo necesito, no me gusta y me parece peligroso, pero entiendo que pueda ser útil para muchos.

A partir del momento en el que lo actives podrás copiar y cortar normalmente y a la hora de pegar, en lugar de pulsar el tradicional CTRL+V para pegar lo último, podrás pulsar también Windows+V para que aparezca el visor del historial del portapapeles:

Una vez que aparece esta ventanita puedes ver todo lo que tienes en la historia y pulsar sobre cualquiera para pegarlo. Además, el que pulses te lo pondrá arriba del todo de la lista, listo para utilizar con CTRL+V. También puedes borrar el historial completo pulsando el enlace arriba a la derecha.

 

Un último detalle interesante: puedes anclar algunas cosas de las que hayas copiado para evitar que se borren, de modo que siempre las tengas disponibles para reutilizar, incluso si reinicias el equipo:

Anclar una imagen en el portapapeles

 

Nada más. En mi opinión esta "tontería" es lo mejor que le han metido a Windows en mucho tiempo de cara a los usuarios. Aprende a sacarle partido.

¡Espero que te resulte útil!

Ironhack y Jobandtalent ofrecen 300.000 euros en becas para aprender desarrollo web, diseño UX y análitica de datos

06/03/2019
Artículo original

Ironhack y Jobandtalent ofrecen 300.000 euros en becas para aprender desarrollo web, diseño UX y análitica de datos

Hace unos meses contábamos cómo Ironhack y Cabify se unían para ofrecer 100 becas en cursos de la plataforma, dotadas con 7.500 euros en su modalidad completa, o parciales de entre 1.500 y 2.500 euros. Ahora se repite la jugada, pero Jobandtalent sustituye a la plataforma de transporte como actor que promueve las becas.

No es lo único que cambia. La cuantía total a repartir baja de 350.000 a 300.000 euros en esta ocasión, pero se siguen ofertando becas ‘Full Scholarship’, en concreto 6, valoradas en 7.500 euros, y las restantes hasta completar el presupuesto con becas ‘Partial Scholarship’ de 1.500€.

Como en la ocasión anterior, para solicitar la beca de Ironhack y Jobandtalent no hace falta contar con experiencia previa en el sector, sólo ser mayor de 18 años de edad. Eso sí, hablamos de cursos presenciales, por lo que tendrás que tener disponibilidad para estar en esas ciudades.

El proceso de solicitud ya se ha abierto, y acaba el día 12 de marzo

Job En estas empresas trabajan antiguos alumnos del bootcamp de Ironhack.

Los participantes del proceso pueden solicitar becas desde ayer día seis de marzo hasta el 12 de marzo. A partir del 13 se te comunicará si pasas a la siguiente fase. En caso afirmativo, los solicitantes recibirán materiales para trabajar en la siguiente fase, que implicará realizar entrevistas presenciales en Madrid, entre el 20 y 26 de marzo.

Antes ya tendrás que haber elegido campus, curso a realizar y fecha de realización. Todo ello, teniendo en cuenta que sólo pueden realizarse en las dos grandes ciudades del país. En el proceso habrá dos entrevistas. Una técnica, donde se evaluará la capacidad de trabajo y aprendizaje en una prueba técnica de Web, diseño UX y UI y analítica de datos, y una entrevista personal, donde convenzas de por qué mereces la beca.

Sobre los criterios, aseguran que se encargan de formarte, y que lo que importa es el potencial y la capacidad de aprender. Para solicitar una plaza, solamente tiene que iniciar el proceso aquí.

Microsoft comienza a pagar el 95% de los ingresos por aplicaciones a los desarrolladores que las suben a la Tienda

06/03/2019
Artículo original

Microsoft comienza a pagar el 95% de los ingresos por aplicaciones a los desarrolladores que las suben a la Tienda

La economía de las tiendas de aplicaciones para sistemas operativos móviles y de escritorio siempre ha sido muy dependiente de las decisiones tomadas por la primera empresa que se las tomó en serio, Apple. La compañía de Cupertino estableció que del total de ingresos obtenidos por ventas en ellas, los desarrolladores obtendrían el 70% y Apple se quedaría con el 30%. A día de hoy continúa siendo así, salvo en pagos por suscripciones, donde se ha relajado y "sólo" se quedan con el 15% tras el primer año.

La Tienda de Microsoft nunca ha sido un éxito, y se encoge en lugar de crecer. No lo fue en Windows Phone y Windows 10 Mobile y no lo ha sido en Windows 8 ni Windows 10. Por ello, el pasado Microsoft Build 2018, los de Redmond anunciaron que del 30% que perseguían á lá Apple, se quedarían solo con un 5%. Es decir, que los desarrolladores ingresarían el 95% del total, sumando un 25%. Ahora, por fin, ese cambio de política entra en vigor, según MSPoweruser.

Probablemente el 5% no le sepa demasiado a Microsoft, pero la Tienda está desértica y es una manera de llamar la atención de los desarrolladores, a los que recientemente se abrió la posibilidad de subir aplicaciones web progresivas, lo que ya de por sí facilitaba contar con una aplicación. Con el 5% que pierden los desarrolladores respecto a la comercialización en sus sitios web, se puede ganar cierta visibilidad y ahorrar los costes de hosting.

Microsoft retendrá algo más a los afiliados, y los juegos seguirán igual

Epic Games La Epic Games Store puede jugar un gran papel en el futuro de la mano del éxito de Fortnite.

En el comunicado donde Microsoft explicó los cambios, además de repasar la cuota 95% / 5%, se detalló que las aplicaciones cuyos pagos procedieran de colecciones en la Tienda o de enlaces brindados por la compañía, el desarrollador obtendría solo un 85%. Así, Microsoft se queda un 15% en esos casos, por "ayudar" al desarrollador.

La Tienda necesita un golpe de efecto, pero quizá ni el 95% de ingresos para el desarrollador sea suficiente.

Donde nada cambiará, al menos de acuerdo a lo anunciado, es en juegos, área donde la Tienda sí tiene cierto éxito y Microsoft obtiene más ingresos. Aun así, es un apartado donde es previsible que también acaben dando pasos hacia una reducción de los ingresos, pues la competencia viene muy fuerte. Aunque de momento cuenta con pocos títulos en catálogo, la recién lanzada Epic Games Store "sólo" se lleva el 12% de los ingresos de cada venta, frente al 30% de Valve en Steam.

Durante años los altos porcentajes han sido justificables por falta de competencia y la gran visibilidad ofrecida, pero el mercado comienza a cambiar, y más lo haría si la App Store y el Play Store tuvieran competencia legal y bien establecida en iOS y en Android.

Visual Studio Code + Angular: cómo montar un entorno de desarrollo productivo para este framework

06/03/2019
Artículo original

Un motivo por el que se selecciona un framework frente a hacerlo todo a mano desde cero es el tiempo que te ahorras. El tiempo de un desarrollador es tremendamente importante (y caro) por eso existen herramientas como Angular, que proporcionan técnicas para optimizar el tiempo de desarrollo.

Aparte de escoger correctamente qué framework usar según nuestras necesidades, es muy importante aprender a trabajar de manera productiva con él, y esto implica aprender a configurar nuestro entorno de trabajo para facilitar el día a día. El entorno de trabajo puede que sea el punto más crítico de la productividad, y en lo que más tiempo se puede perder si no le dedicas la atención que merece. En este artículo te mostraré la configuración que yo utilizo al trabajar con Angular, aunque la mayoría de puntos que comento son aplicables a cualquier otro  framework JavaScript como React o VUE.js, ¡vamos a ello!

La interfaz de desarrollo o IDE

Éste puede que sea el punto más importante ya que a partir de aquí se definirá el resto de tu configuración. A día de hoy si trabajas en desarrollo web, en general, sólo existen dos opciones que merezcan la pena:

WebStorm (producto de JetBrains) es lo que se conoce como un "IDE de toda la vida". Un programa extremadamente completo y con múltiples plugins preinstalados y con soporte para múltiples tecnologías.

Webstorm editando un componente de Angular. Imagen obtenida de JetBrains

En el extremo opuesto está Visual Studio Code (cliente de Microsoft, a partir de ahora lo llamaré VSC para abreviar), un editor de texto ligero y rápido, más que un IDE propiamente dicho, pero con un potencial que compite con el mítico Sublime.

Visual Studio Code editando un archivo de Angular de la aplicación de ejemplo de nuestro curso online

Las dos principales diferencias que encuentro entre ambos son:

  • WebStorm viene por defecto con una configuración más completa para empezar a trabajar aunque, con la configuración correcta en VSC, sus funcionalidades son parejas.
  • WebStorm es de pago mientras que VSC es un cliente Open Source y gratuito, con una comunidad asombrosa detrás y mantenido por uno de los mejores equipos de desarrollo en Microsoft.

Yo profesionalmente me he encontrado usando cada vez más VSC y a día de hoy es lo que uso mayoritariamente en mi día a día. Es por este motivo que en el artículo de hoy me centraré en mostrarte la configuración que tengo para desarrollar principalmente en Angular pero que gran parte es extensible a cualquier framework.

Conoce Visual Studio Code y tu flujo de trabajo

Mi recomendación es que antes de hacer cualquier configuración le dediques un tiempo a repasar los siguientes puntos:

Los atajos de teclado es algo que nunca está de más conocer, te ahorran muchísimo tiempo y con que te sepas los 10 más comunes verás la productividad que obtienes. Algunos de los atajos que uso más a menudo son:

  • Ir a un archivo: Ctrl+P, Cmd+P, Ctrl+P
  • Seleccionar todos los elementos que coincidan con la búsqueda: Alt+Enter, Opt+Enter, Alt+Enter
  • Seleccionar cada elemento de la búsqueda uno a uno: Ctrl+D, Cmd+D, Ctrl+D
  • Añadir un cursor nuevo: Alt+Clic, Alt+Clic, Alt+Clic
  • Comentar/Descomentar una línea: Ctrl+/, Cmd+/, Ctrl+/
  • Mover una línea hacia arriba/abajo: Alt+Key Up/Key Down, Alt+Key Up/Key Down, Alt+Key Up/Key Down
  • Formatear documento: Ctrl+Shift+I, Alt+Shift+F, Alt+Shift+F
  • Seleccionar una línea: Ctrl+I, Cmd+I, Ctrl+I
  • Abrir visualizador de Markdown: Ctrl+Shift+V, Cmd+Shift+V, Ctrl+Shift+V

Estos son sólo uno de los pocos que uso en mi día a día, pero cuántos más te aprendas mejor.

Otro de los puntos que es recomendable repasar siempre es la de las Chrome DevTools, las herramientas para desarrolladores que incorpora Google en el navegador Chrome. Aunque no forma parte de VSC (en principio, ya que por debajo usa Chrome para funcionar), sí que es una parte imprescindible de tu flujo de trabajo y que debes conocer.

Además de toda esta información, suelo dejar la configuración por defecto del editor, a excepción de una opción que siempre me gusta tener activa. Si pulsas Cmd+, abrirás la configuración del cliente:

Ajuste del editor llamado Recortar Espacios en Blanco

Esta propiedad de configuración te limpiará el archivo de espacios en blanco innecesarios cada vez que lo guardes, lo que te evitará bastantes problemas en un futuro, sobre todo trabajando con Git (y siempre es bueno tener los archivos limpios).

Extensiones

Y llegamos posiblemente al punto que esperabas con más interés. Las extensiones son plugins que enriquecen a VSC con mejoras que no tiene de "serie", y que te ayudan tremendamente en el proceso de desarrollo. Cada proyecto es diferente y requerirá de una configuración propia en algunos casos, pero en general suelo usar en la mayoría de proyectos las siguientes extensiones:

Por suerte Angular no requiere de muchas extensiones de VSC para poder ser productivo. La única extensión que debes tener instalada casi obligatoriamente si trabajas con Angular es "Angular vX Snippets" (la X depende de la versión actual de Angular). Esta extensión te añade atajos al editor para generar estructuras de código de forma muy rápida con los principales patrones de trabajo y que tú sólo tengas que rellenar los huecos.

Si tuviera que escoger una única extensión que instalar en VSC sería esta sin duda alguna. Esta extensión te pinta en diferentes colores los paréntesis, corchetes y llaves según el nivel de identación facilitándote encontrar las parejas:

Es una extensión muy sencillita pero que te facilita mucho la vida. Permite ciertos niveles de configuración, aunque yo la uso con la configuración por defecto.

Otra de las extensiones más útiles que puedes instalar, ya que te permite conectar VSC con el propio Chrome y testear directamente desde VSC como si estuvieras con las DevTools del navegador.

Yo la he estado usando cada vez más por el simple hecho de no tener que estar cambiando de contexto y poder ejecutar todo el flujo desde VSC. Pero también es cierto que no te aporta nada nuevo si ya tienes costumbre de utilizar las herramientas de desarrollo de Chrome.

Estas extensiones las he descubierto hace poco, pero la combinación de ambas es un tándem muy útil. La primera te permite resaltar palabras claves como TODO y FIXME en el código para que sean visualmente más fáciles de encontrar:

Extensión en funcionamiento con un TODO resaltado

Mientras que la segunda te crea un árbol con todos los TODO encontrados en tu proyecto:

La combinación de ambas te crea una herramienta de trabajo muy útil típica en los IDEs más completos para destacar tareas que han quedado por hacer en medio del proceso de desarrollo y no se pudieron atender.

Esta extensión me resulta muy útil porque, aunque VSC implementa un visualizador de Markdown estupendo, con esta extensión puedo ver exactamente cómo quedaría el Markdown en GitHub, que es la plataforma con la que normalmente trabajo.

Los cambios son mínimos realmente pero siempre intento ser lo más fiel posible a producción y no encontrar sorpresas.

Otra buena combinación de extensiones que te pueden ser de gran ayuda en momentos muy concretos. No son extensiones que use en mi día a día pero son de esas cosas que cuando menos te lo esperas agradeces tenerlas a mano.

Si trabajas con Docker esta extensión es obligatoria instalarla. Aparte de añadir a VSC autocompletado para trabajar con los archivos de configuración de Docker también te habilita una pequeña ventana para gestionar tus imágenes/contenedores:

Esta extensión es muy (¡muy!) interesante ya que pocos clientes tan buenos he encontrado para generar diagramas de tipo UML.

UML (lenguaje unificado de modelado) es un lenguaje con el que generar todo tipo de diagramas. Yo lo suelo usar para crear los diagramas que representan el flujo de la aplicación y así compartirlos a modo de documentación con el equipo. Si no lo conocías hasta ahora te animo a que le eches un ojo:

Bienvenido a la mejor herramienta de pair programming que existe a día de hoy. Si VSC aún no te había convencido estas dos herramientas te convencerán de instalarlo.

La primera extensión te permite compartir un espacio de trabajo de VSC con otra persona a través de un enlace. Lo bueno es que no sólo le da acceso sin más a la otra persona, sino que incluso puedes definir si quieres que pueda hacer modificaciones o simplemente estar en un modo de sólo lectura, visualizar fácilmente qué es lo que hace etc.

La segunda extensión no es más que un complemento, pero aún así muy interesante, pues permite realizar una llamada directamente desde VSC sin necesidad de otras aplicaciones.

Conclusión

Como habrás podido ver Visual Studio Code (y sobre todo su comunidad) no tiene nada que envidiar a los IDEs más conocidos. Es cierto que cada proyecto y cada persona es un mundo, pero con estas pequeñas extensiones y algún que otro consejo espero puedas encontrarte a gusto trabajando con esta herramienta.

Éstas son sólo algunas de las extensiones que yo uso pero hay multitud de ellas, ¿hay alguna de las que tú usas que no he comentado? Anímate a dejar un comentario.

Este informe nos muestra cuales son los puestos de trabajo para desarrolladores con más demanda y que mejor pagan

05/03/2019
Artículo original

Este informe nos muestra cuales son los puestos de trabajo para desarrolladores con más demanda y que mejor pagan

Uno de cada cinco ingenieros de software aprende por su cuenta, la demanda global de especialistas en blockchain aumentó más de 500% en 2018, los ingenieros en búsquedas son los que más dinero ganan, Python es el lenguaje de programación más apreciado, y el 43% de los desarrolladores prefieren trabajar para empresas que contribuyen a proyectos open source.

Todos son datos obtenidos de un informe publicado por la gente de Hired, una plataforma que hace de intermediario entre empresas de tecnología en busca de talento y aquellos ingenieros de software que buscan puestos de trabajos competitivos.

El informe, que incluye una enorme cantidad de datos obtenidos a través de más de 170.000 entrevistas de trabajo realizadas entre 10.000 empresas participantes y 98.000 personas en busca de trabajo, nos deja números muy interesantes sobre el estado actual del mercado laboral para los programadores.

Blockchain, seguridad y sistemas integrados

Los datos del mercado de empleos en Hired apuntaron a que la demanda de especialistas en blockchain se fue a las nubes durante el 2018, algo que tiene mucho sentido, teniendo en cuenta la fiebre de las criptomonedas que se vivió. En comparación con el año anterior, estos ingenieros fueron solicitados un 517% más.

El rol que más de cerca le llega en comparación, es el de ingeniero de seguridad, cuya demanda aumentó un 132% en 2018. A este le siguen los especialistas en sistemas integrados, los ingenieros de datos, los desarrolladores backend, y los especialistas en machine learning (aprendizaje automático).

En Hired también analizaron los salarios en algunas de las ciudades donde más se concentran los trabajos en tecnología, como Nueva York, San Francisco, Toronto, Londres y París. El salario más gordo lo tienen los ingenieros de búsquedas en San Francisco, con ingresos promedio de 157.000 dólares al año.

En París, el mismo puesto de trabajo paga en promedio 53.000 euros al año, y en Londres llegan hasta las 68.000 libras. En general, los puestos mejores pagados son casi los mismos en la mayoría de los sitios, con algunas variaciones.

Captura De Pantalla 2019 03 05 A Las 15 03 55 Salarios para ingenieros de software en Londres según la especialidad - Fuente: Hired

Los especialistas en blockchain, ingenieros de seguridad, ingenieros de búsquedas, desarrolladores frontend y backend están al tope, junto a la ingeniería de datos, el desarrollo móvil, los sistemas integrados, full- stack, y procesamiento natural del lenguaje.

Del lado de los lenguajes de programación más demandados por las empresas a la hora de entrevistar a un ingeniero, tenemos a Go a la cabeza, seguido en orden descendiente por Scala, Ruby, TypeScript, Kotlin, JavaScript, Objective-C, PHP, Java, HTML, Swift, Python, C++, C, C#, y R.

Dato curioso aquí, es que de los encuestados, solo el 7% de los desarrolladores usa Go, pero cuando un candidato tiene experiencia con ese lenguaje, tiene más posibilidades de ganarse una entrevista de trabajo.

Los desarrolladores por su parte siguen amando Python, JavaScript, Java, HTML y C++. Datos consistentes con los de otras encuestas que ponen a estos mismos como los que los programadores más desean aprender.

El mercado laboral para los programadores es uno que no para de crecer, la demanda de trabajo es cada vez mayor y en ciertos campos hay tanto déficit de talento que los sueldos alcanzan cifras de locura, nada más basta mirar lo que pasa en el mundo de la inteligencia artificial.

Visual Studio Code: cómo preparar un entorno de trabajo para .NET Core

04/03/2019
Artículo original

Portada ornamental

Una de las grandes ventajas de .NET Core, es su ejecución multiplataforma, lo que nos permite trabajar en entornos que no sean Windows. Es por eso que Microsoft lanzó al mercado su IDE (Entorno de Desarrollo Integrado, en inglés: Integrated Development Environment) gratuito y multiplataforma Visual Studio Code.

En principio, programar para .NET Core con Visual Studio Code puede parecer algo confuso, ya que todo funciona por comandos, hacen falta algunos ficheros JSON que no son necesarios en Visual Studio y aparentemente tiene las herramientas limitadas. Sin embargo, en realidad es muy fácil de configurar y no vas a notar grandes carencias respecto a su hermano mayor, por lo que puede convertirse en una gran opción, más ágil y que además podrás usar en Mac o Linux.

Instalando Visual Studio Code

Lo primero que debes hacer es instalar Visual Studio Code. Para ello basta con que entremos a su página de descargas y nos descarguemos e instalemos la versión apropiada para nuestro sistema operativo.

La imagen muestra el menú de opciones que nos presenta la página de descargas de Visual Studio Code

Instalando .NET Core

Visual Studio Code en sí mismo es un editor de ficheros "vitaminado". Esto quiere decir que es como el bloc de notas de toda la vida, pero con mejoras (muchas mejoras). Por eso, lo primero que tenemos que hacer para poder usar .NET Core con Visual Studio Code, es instalar .NET Core para nuestra plataforma. Para ello descargaremos desde su página de descargas los binarios del SDK (Kit de Desarrollo de Software, en inglés: Software Development Kit) para nuestro sistema operativo.

OJO, tiene que ser el SDK y no solo el runtime

La imagen muestra el menú de opciones que nos muestra la página de descargas de .NET Core, señalando cuál de las dos descargas es la correcta: "Download .NET Core SDK"

Instalando las extensiones necesarias

Para poder desarrollar todo su potencial, Visual Studio Code utiliza un sistema de extensiones que nos permiten ampliar su funcionalidad. Estas extensiones se pueden descargar desde el propio entorno o desde el Extension Marketplace (aunque esto realmente, lo que va a hacer es abrir el IDE y llevarnos a la extensión).

Para empezar a preparar nuestro entorno, vamos a utilizar la extensión para el lenguaje C#.

Para instalar esta extensión, desde la web, basta con que pulsemos sobre Install:

La imagen señala el botón "Install" de la web de la extensión

Nos va a pedir como requisito tener instalado Visual Studio Code, y como nosotros ya lo tenemos, en la ventana emergente pulsamos sobre el botón Abrir Visual Studio Code:

La imagen señala el botón "Abrir Visual Studio Code" de la ventana emergente

Esto nos abre Visual Studio Code, y nos muestra directamente la extensión, aquí basta con pulsar sobre el botón Install para que se inicie el proceso:

La imagen señala el botón para instalar la extensión dentro de Visual Studio Code

Una vez que termine tenemos que recargar el IDE. Para eso basta con pulsar en el botón de recargar:

La imagen señala el botón recargar Visual Studio Code

Con esto, ya tenemos nuestro entorno de trabajo Visual Studio Code para trabajar con el lenguaje C# y con .NET Core.

Podríamos haberlo buscado directamente desde el entorno e instalarlo desde allí más fácilmente, ahorrándonos un par de pasos.

Vamos a ver cómo poder ejecutar un proyecto con nuestro nuevo entorno.

Creando una aplicación de consola .NET Core en Visual Studio Code

Lo primero que vamos a necesitar es crear una carpeta en la que queramos que esté el proyecto. Una vez que la tengamos vamos a abrir en Visual Studio Code la carpeta que acabamos de crear, utilizando el menú File·Open Folder o con el acceso directo Ctrl+K,Ctrl+O (son dos combinaciones de teclas, una después de la otra):

La imagen muestra la opción de menú "Open Folder" dentro de Visual Studio Code

Una vez que tengamos la carpeta, vamos a necesitar sacar una ventana de terminal para lanzar comandos de compilación y similares. Para eso, dentro del menú View, pulsamos sobre el botón Terminal o con el acceso directo Ctrl+ñ:

La imagen señala el botón "Terminal" dentro de Visual Studio Code

Ahora dentro de esa terminal vamos a ejecutar el comando dotnet new console para crear nuestro proyecto (éste tomará el nombre de la carpeta en la que estamos). Cuando acabe la ejecución, podemos ver que han aparecido los ficheros del proyecto en el explorador:

La imagen muestra los ficheros que se han creado en el explorador de ficheros de Visual Studio Code

Con esto, si ejecutamos desde el terminal el comando dotnet run, podemos ver como la aplicación se ejecuta sin ningún problema:

La imagen muestra la salida de la consola del proyecto .NET Core

Con lo que hemos hecho podríamos modificar el código y ejecutarlo con los cambios, pero aún nos falta una parte importante: poder depurarlo, como lo haríamos en Visual Studio. Para eso tenemos que añadir algunos ficheros JSON mediante el asistente para que así se configuren correctamente también. Vete al menú View·Command Palette o usa el acceso directo Ctrl+Shift+P:

La imagen muestra el botón para abrir la paleta de comandos

Y dentro del desplegable que aparece debemos buscar la opción .NET: Generate Assets for Build and Debug:

La imagen muestra el botón para añadir los ficheros JSON necesarios

Esto nos generará los ficheros JSON necesarios para poder compilar, ejecutar y depurar el proyecto desde Visual Studio Code.

La imagen muestra los dos ficheros JSON generados

Una vez que tenemos todo esto, ya solo nos queda probar que funciona, para ello, vamos a poner un punto de interrupción situándonos sobre la línea:

Console.WriteLine("Hello World!");

y pulsando la tecla F9.

Si ahora ejecutamos el proyecto (pulsando F5) podemos ver que, efectivamente, el punto de interrupción se aplica y la ejecución se detiene ahí, permitiéndonos depurar el proyecto:

La imagen muestra como el depurador se para en la línea en la que hemos puesto el punto de interrupción

Vamos a ver el proceso con un vídeo:

[youtube:sioXaIjpAsM]

En resumen

Con los pasos anteriores hemos conseguido un entorno de trabajo básico pero totalmente funcional para .NET Core con Visual Studio Code. Estaremos en condiciones de trabajar con .NET Core sin problemas y sacarle partido a todas sus características, apoyados por Visual Studio Code y todas sus potentes funcionalidades:

  • IntelliSense con sugerencias mientras escribimos código
  • "Snippets" o fragmentos de código ya hecho para acelerar la escritura
  • Localización y navegación rápida por el código
  • CodeLens para obtener información sobre referencias y relaciones entre el código
  • Refactorización
  • Etc...

Además podríamos instalar más extensiones específicas para ayudarnos con el desarrollo de aplicaciones .NET Core, pero esto será objeto de otro artículo en breve.

Mientras tanto no dejes de ver esta documentación (en inglés) para sacarle todo el partido al entorno:

SAP construye su propia distribución de Java

02/03/2019
Artículo original

SAP ha lanzado un "fork amistoso" de OpenJDK, la versión de código abierto de Java, llamado SapMachine.

El proyecto, que comenzó a fraguarse en diciembre de 2017, sirve como una variante de OpenJDK pero mantenida por SAP. SAP asegura que su intención no es dividir a la comunidad de Java ni competir con la propia oferta de Java de Oracle (o la de otras empresas como IBM o RedHat). La idea es que los clientes y partners de SAP lo utilicen para ejecutar las aplicaciones de la casa, pudiendo acceder a todas las últimas tecnologías de la plataforma Java y obteniendo un soporte mayor que el que obtendrían con el OpenJDK o con el propio SDK de Java, especialmente a raíz de los cambios desde la versión 11.

Los lanzamientos de SapMachine se van a alinear con los lanzamientos del propio OpenJDK. La versión de producción actual es SapMachine 11 LTS (Long Term Support). Enseguida se lanzará SapMachine 12, una implementación del JDK 12 (Java Development Kit), que en teoría sale el próximo 19 de marzo. Acto seguido se pondrán ya a trabajar en SapMachine 13.

SapMachine ha pasado las pruebas del Kit de compatibilidad de Java, para certificar su plena compatibilidad con OpenJDK. A partir del JDK 12, SAP mantendrá ramas activas de SapMachine para varias versiones de Java al mismo tiempo.

En este documento puedes encontrar las diferencias entre OpenJDK y SapMachine. Se pueden utilizar también a partir de contenedores Docker especialmente construidos, de modo que puedas usarlo en producción pero también probarlo sin riesgos.

En la página oficial de SapMachine puedes encontrar más información, las descargas para las diferentes plataformas (Windows, Linux y macOS).

¿Te consideras un programador frontend o backend?

01/03/2019
Artículo original

¿Te consideras un programador frontend o backend?

En la industria del software históricamente hemos utilizado los términos frontend y backend para dividir dos mundos de la programación. La tecnología cambia a pasos agigantados y la realidad de un desarrollador de hace 10 años es muy distinta a la actualidad. Aún así, seguimos usando esta frontera entre backend-frontend para dividir equipos, proyectos o, incluso, una misma aplicación a través de una barrera en muchos casos de forma artificial.

Vamos a repasar ambos términos, qué implicaciones tienen y, sobre todo, el uso en torno a ellos según evoluciona la industria del software con una mentalidad más fullstack.

La primera división entre ambos términos: frontend vs backend

Si nos fijamos en la definición estricta: un programador frontend tiene como principales responsabilidades la capa de UI del proyecto. Remontándonos a unos años atrás recordamos como HTML, CSS, los principales frameworks JavaScript como Ext JS, Dojo o el incipiente jQuery dominaban el mercado. Básicamente la persona encargada del frontend no era más que un maquetador (hablando en plata) “poner bonita la interfaz web y dar ciertas interacciones Ajax”, mientras que el desarrollador backend era el encargado de procesar y devolver los datos, en el mejor de los casos, en un template del MVC o en una pseudo API.

Por otro lado, el desarrollador backend, debía ocuparse de la lógica de negocio, delegando en muchos casos a un CRUD de aplicación para leer y escribir datos en SQL. Por ese entonces, frameworks empresariales de Java o C# ocupaban los primeros puestos, junto algunos intentos de frameworks de PHP o Ruby on Rails para facilitar el uso MVC de las aplicaciones web.

Hasta aquí parecía coherente tener en una cueva a desarrolladores frontend y otra a los de backend. Esto se llevaba tanto a la definición de las tareas como en la división de equipos. Apenas había interacción entre ellos, quizás mínima para ponerse de acuerdo en optimizar ciertas cosas como la caché, el rendimiento, pero aún seguía siendo escasa esa comunicación.

¿Sigue siendo tan clara esa separación frontend-backend?

Mismos problemas que son resueltos, incluso con las mismas herramientas y, por supuesto, identicos conceptos de ingeniería del software

Salvo las empresas más grises y anticuadas, donde el desarrollo software continúa siendo una horrible cascada de tareas con Project Managers presionando, sin apenas interrelación entre equipos o desarrolladores. La cosa ha cambiado mucho, al igual que volvemos a repetir la tecnología y la forma de trabajar.

El sentimiento generalizado históricamente ha sido que la parte más seria de la programación se hace en el lado backend: el diseño de la API, la persistencia, la gestión de la caché, la sincronización de los datos, los tests unitarios, la integración continua, etc…

La realidad en estos últimos años ha cambiado bastante, cada vez nos encontramos con frameworks más complejos para desarrollar aplicaciones cliente como Angular, React o Vue. O la irrupción de node.js que ha impulsado poder desarrollar con JavaScript como un lenguaje de servidor más. Firebase o AWS han apostado con sus cloud functions, por ejemplo.

Sin contar las plataformas móviles como Android o iOS con un amplísimo ecosistema, donde no me atrevería a llamarlos front-end sin más. Los problemas actualmente van más allá de que un UI se va bonita y tenga ciertos toques AJAX. A día de hoy, son aplicaciones complejas con similares problemas como la sincronización de datos, la persistencia, la escalabilidad de código.

No me puedo imaginar un desarrollador, sea backend o frontend que no tenga similares preocupaciones acerca del diseño de una API, de la persistencia, de la testabilidad del código, de cómo escalar funcionalidades, del cómo aplicar Domain Driven Design, TDD o la integración continua.

Ddd

Trabajamos sobre los mismos problemas que son resueltos, incluso con las mismas herramientas y, por supuesto, idénticos conceptos de ingeniería del software. Los lenguajes han pasado a ser más transversales que nunca, ya lo demuestra JavaScript estando más presente que nunca, los lenguajes modernos Kotlin o Swift, Go, Rust o Elixir, y el uso de frameworks cada vez más funcionales para resolver, volvemos a repetir, los similares casos de uso.

Claramente, hay ciertos aspectos que siguen estando en los extremos de ambos mundos. Como puede ser el despliegue de aplicaciones, la seguridad, sus escalabilidad en entornos en la nube como AWS o Google Cloud. Aunque cada vez son menos abstractos para los programadores frontend con el uso de instancia Docker o el uso de serverless para dotar de un componente backend a sus apps.

La mentalidad full-stack

Obviamente cada uno de nosotros tiramos más hacia uno de los lados. Pero existe una tendencia, sobre todo en las empresas de producto, dícese de gran parte de las Startups tecnológicas que conocemos, donde tener una mentalidad fullstack empieza a ser cada vez más importante.

Conocer ambos mundos y ser capaz de tener una visión global del problema es uno de los mayores propulsores de cualquier proyecto.

Esa mentalidad full-stack permite trabajar en cualquier faceta de una funcionalidad end-to-end. Es decir, ser capaz de programar tanto en el lado cliente como servidor, conociendo cómo se comportan cada parte en conjunto. Arreglar y solucionar cualquier reto, y no solamente la mitad de él.

Tanto los lenguajes más modernos y frameworks han ido adoptando esa filosofía multipropósito, homogenizando paradigmas de programación que todos conocemos y manejamos. Esto ha facilitado mucho la primera toma de contacto y su uso en cualquier plataforma.

No estamos diciendo que haya que ser un experto en todo. Eso es imposible. Lo importante es buscar el equilibrio y cómo usar de la mejor forma la tecnología. Saber y entender cómo consumen nuestros usuarios las aplicaciones, ya sea a través de una UI o una API es fundamental. A parte de saber cómo se almacena o se despliega nuestras aplicaciones en lado servidor, por supuesto.

Un desarrollador que entiende cómo funciona una aplicación completamente será mucho más valioso que un desarrollador que sólo entiende la mitad

Un desarrollador que entiende cómo funciona una aplicación completamente será mucho más valioso que un desarrollador que sólo entiende la mitad. Un programador que es capaz de escribir código en cualquier parte de un proyecto será mucho más versátil. Al igual que los equipos multidisciplinares sin una frontera fuerte entre backend y frontend.

Por ello, siempre recomiendo a los desarrolladores más juniors que empiecen a interesarse desde el principio en lo que hacen sus compañeros del “otro lado”. Y que empiecen a tener una mentalidad fullstack de cada proyecto. Será inevitable especializarse en una parte, pero esa curiosidad les ayudará el resto de su carrera profesional.

Es necesario pensar primero en nosotros mismos como desarrolladores e invertir tiempo en investigar sobre tecnologías frontend y backend. Evangelizar a nuestros compañeros, empezando por nuestro propio equipo y nuestra propia empresa.

Foto | Flickr

Aquí tienes más de 500 cursos de programación gratis que puedes comenzar en marzo

01/03/2019
Artículo original

Aquí tienes más de 500 cursos de programación gratis que puedes comenzar en marzo

Para arrancar el mes de marzo y como ya es costumbre, en Genbeta buscamos compartir con ustedes cualquier buena oferta de educación gratuita en línea, y esta vez, gracias a la gente de freeCodeCamp tenemos una buena lista con cientos de cursos.

De entre la enorme base de datos de Class Central, Dhawal Shah, fundador de la plataforma, ha recopilado solo los relacionados con programación y ciencias de la computación y armado esta enorme lista 550 cursos online gratuitos que puedes empezar en marzo.

550 cursos que puedes tomar en algún momento de marzo o llevar a tu propio ritmo, en múltiples idiomas, incluyendo varios en español

Aunque muchos de los cursos comienzan en algún momento durante marzo de 2019, otros son completamente libres y puedes realizarlos a tu propio ritmo y comenzar cuando puedas.

Esta lista incluye cursos para principiantes, para estudiantes con conocimientos intermedios, y también para estudiantes avanzados o profesionales que buscan expandir sus conocimientos.

Los cursos, además, están puntuados de una a cinco estrellas por estudiantes que ya los han tomado para que te hagas una idea de qué les ha parecido a otras personas antes. Aunque la gran mayoría se encuentran en inglés, también hay varios cursos en español y en otros idiomas.

Destacamos algunos en nuestro idioma:

¿Te consideras un programador frontend o backend?

01/03/2019
Artículo original

¿Te consideras un programador frontend o backend?

En la industria del software históricamente hemos utilizado los términos frontend y backend para dividir dos mundos de la programación. La tecnología cambia a pasos agigantados y la realidad de un desarrollador de hace 10 años es muy distinta a la actualidad. Aún así, seguimos usando esta frontera entre backend-frontend para dividir equipos, proyectos o, incluso, una misma aplicación a través de una barrera en muchos casos de forma artificial.

Vamos a repasar ambos términos, qué implicaciones tienen y, sobre todo, el uso en torno a ellos según evoluciona la industria del software con una mentalidad más fullstack.

La primera división entre ambos términos: frontend vs backend

Si nos fijamos en la definición estricta: un programador frontend tiene como principales responsabilidades la capa de UI del proyecto. Remontándonos a unos años atrás recordamos como HTML, CSS, los principales frameworks JavaScript como Ext JS, Dojo o el incipiente jQuery dominaban el mercado. Básicamente la persona encargada del frontend no era más que un maquetador (hablando en plata) “poner bonita la interfaz web y dar ciertas interacciones Ajax”, mientras que el desarrollador backend era el encargado de procesar y devolver los datos, en el mejor de los casos, en un template del MVC o en una pseudo API.

Por otro lado, el desarrollador backend, debía ocuparse de la lógica de negocio, delegando en muchos casos a un CRUD de aplicación para leer y escribir datos en SQL. Por ese entonces, frameworks empresariales de Java o C# ocupaban los primeros puestos, junto algunos intentos de frameworks de PHP o Ruby on Rails para facilitar el uso MVC de las aplicaciones web.

Hasta aquí parecía coherente tener en una cueva a desarrolladores frontend y otra a los de backend. Esto se llevaba tanto a la definición de las tareas como en la división de equipos. Apenas había interacción entre ellos, quizás mínima para ponerse de acuerdo en optimizar ciertas cosas como la caché, el rendimiento, pero aún seguía siendo escasa esa comunicación.

¿Sigue siendo tan clara esa separación frontend-backend?

Mismos problemas que son resueltos, incluso con las mismas herramientas y, por supuesto, identicos conceptos de ingeniería del software

Salvo las empresas más grises y anticuadas, donde el desarrollo software continúa siendo una horrible cascada de tareas con Project Managers presionando, sin apenas interrelación entre equipos o desarrolladores. La cosa ha cambiado mucho, al igual que volvemos a repetir la tecnología y la forma de trabajar.

El sentimiento generalizado históricamente ha sido que la parte más seria de la programación se hace en el lado backend: el diseño de la API, la persistencia, la gestión de la caché, la sincronización de los datos, los tests unitarios, la integración continua, etc…

La realidad en estos últimos años ha cambiado bastante, cada vez nos encontramos con frameworks más complejos para desarrollar aplicaciones cliente como Angular, React o Vue. O la irrupción de node.js que ha impulsado poder desarrollar con JavaScript como un lenguaje de servidor más. Firebase o AWS han apostado con sus cloud functions, por ejemplo.

Sin contar las plataformas móviles como Android o iOS con un amplísimo ecosistema, donde no me atrevería a llamarlos front-end sin más. Los problemas actualmente van más allá de que un UI se va bonita y tenga ciertos toques AJAX. A día de hoy, son aplicaciones complejas con similares problemas como la sincronización de datos, la persistencia, la escalabilidad de código.

No me puedo imaginar un desarrollador, sea backend o frontend que no tenga similares preocupaciones acerca del diseño de una API, de la persistencia, de la testabilidad del código, de cómo escalar funcionalidades, del cómo aplicar Domain Driven Design, TDD o la integración continua.

Ddd

Trabajamos sobre los mismos problemas que son resueltos, incluso con las mismas herramientas y, por supuesto, idénticos conceptos de ingeniería del software. Los lenguajes han pasado a ser más transversales que nunca, ya lo demuestra JavaScript estando más presente que nunca, los lenguajes modernos Kotlin o Swift, Go, Rust o Elixir, y el uso de frameworks cada vez más funcionales para resolver, volvemos a repetir, los similares casos de uso.

Claramente, hay ciertos aspectos que siguen estando en los extremos de ambos mundos. Como puede ser el despliegue de aplicaciones, la seguridad, sus escalabilidad en entornos en la nube como AWS o Google Cloud. Aunque cada vez son menos abstractos para los programadores frontend con el uso de instancia Docker o el uso de serverless para dotar de un componente backend a sus apps.

La mentalidad full-stack

Obviamente cada uno de nosotros tiramos más hacia uno de los lados. Pero existe una tendencia, sobre todo en las empresas de producto, dícese de gran parte de las Startups tecnológicas que conocemos, donde tener una mentalidad fullstack empieza a ser cada vez más importante.

Conocer ambos mundos y ser capaz de tener una visión global del problema es uno de los mayores propulsores de cualquier proyecto.

Esa mentalidad full-stack permite trabajar en cualquier faceta de una funcionalidad end-to-end. Es decir, ser capaz de programar tanto en el lado cliente como servidor, conociendo cómo se comportan cada parte en conjunto. Arreglar y solucionar cualquier reto, y no solamente la mitad de él.

Tanto los lenguajes más modernos y frameworks han ido adoptando esa filosofía multipropósito, homogenizando paradigmas de programación que todos conocemos y manejamos. Esto ha facilitado mucho la primera toma de contacto y su uso en cualquier plataforma.

No estamos diciendo que haya que ser un experto en todo. Eso es imposible. Lo importante es buscar el equilibrio y cómo usar de la mejor forma la tecnología. Saber y entender cómo consumen nuestros usuarios las aplicaciones, ya sea a través de una UI o una API es fundamental. A parte de saber cómo se almacena o se despliega nuestras aplicaciones en lado servidor, por supuesto.

Un desarrollador que entiende cómo funciona una aplicación completamente será mucho más valioso que un desarrollador que sólo entiende la mitad

Un desarrollador que entiende cómo funciona una aplicación completamente será mucho más valioso que un desarrollador que sólo entiende la mitad. Un programador que es capaz de escribir código en cualquier parte de un proyecto será mucho más versátil. Al igual que los equipos multidisciplinares sin una frontera fuerte entre backend y frontend.

Por ello, siempre recomiendo a los desarrolladores más juniors que empiecen a interesarse desde el principio en lo que hacen sus compañeros del “otro lado”. Y que empiecen a tener una mentalidad fullstack de cada proyecto. Será inevitable especializarse en una parte, pero esa curiosidad les ayudará el resto de su carrera profesional.

Es necesario pensar primero en nosotros mismos como desarrolladores e invertir tiempo en investigar sobre tecnologías frontend y backend. Evangelizar a nuestros compañeros, empezando por nuestro propio equipo y nuestra propia empresa.

Foto | Flickr

Página Anterior Página Siguiente