FRIKADAS: Tu corazón será tu nuevo sistema de autenticación

20/10/2017
Artículo original

Investigadores de la Universidad de Búfalo han descubierto un método de seguridad que usa las medidas del corazón para identificar y autenticar al usuario. Según la nota de prensa que ha publicado la propia universidad, el método se basa en un radar Doppler de bajo nivel para determinar las dimensiones del corazón.

La exploración inicial dura aproximadamente ocho segundos, pero después de eso el sistema puede monitorear continuamente el corazón del usuario para asegurarse de que otro usuario no ha puesto en marcha el aparato. Además de facilitar el acceso y el cierre de sesión, el sistema mejora la seguridad, ya que el corazón de cada usuario tiene un conjunto único de dimensiones.

El profesor adjunto Wenyao Xu de la universidad de Búfalo afirma en la nota de presa: "No se han encontrado dos personas con corazones idénticos."

El escáner de corazón sería, junto con la huella dactilar, el escáner del iris, o el reconocimiento facial, un tipo más de seguridad biométrica tan en auge hoy en día. Sin embargo, según el profesor Xu, el nuevo sistema presenta ciertas ventajas frente a las herramientas biométricas actuales. En primer lugar, no requiere contacto, es decir, se trata de un dispositivo pasivo con el que los usuarios no se tienen que molestar en autenticarse cuando se conectan. Y en segundo lugar, monitorea a los usuarios constantemente. Esto significa que el aparato que esté controlando dejará de funcionar si una persona diferente se pone delante de él. Por lo tanto, las personas no tienen que acordarse de cerrar la sesión cuando estén lejos de sus equipos.

Para aquellos que pueden estar preocupados por los posibles efectos en la salud de los escaneos, Xu mencionó en el comunicado en prensa que la fuerza de la señal "es inferior a la de cualquier dispositivo Wi-Fi. Su lector tiene una potencia de 5 miliVatios, lo cual supone menos del 1% de la radiación de nuestros smartphones”, Por lo tanto se puede concluir que no plantea problemas de salud.

El próximo reto para el profesor Xu y su equipo consiste en miniaturizar su invento. Su intención es fabricar un dispositivo muy pequeño que pueda colocarse sobre la esquina de un teclado.

Resumiendo, las tres ideas principal son:

  1. Se trata de un nuevo sistema de autenticación biométrica que utiliza la geometría del corazón del usuario para identificarlo y autenticarlo para usar la máquina.
  2. El sistema tarda ocho segundos en escanear un corazón y, a continuación, puede monitorizar al usuario constantemente para determinar si otro usuario intenta acceder a la máquina.
  3. El escáner puede monitorizar un corazón a 30 metros de distancia y no presenta riesgos para la salud, han afirmado los investigadores.

Multiples vulnerabilidades en RubyGems

19/10/2017
Artículo original

Existen múltiples vulnerabilidades en la version de RubyGem que incluye Ruby. Ha sido reportado en el blog oficial de Rubygems.

Detalles

Fueron reportadas las siguientes vulnerabilidades:

  • una vulnerabilidad de secuestro de peticiones DNS. (CVE-2017-0902)
  • una vulnerabilidad en secuencia de escape ANSI. (CVE-2017-0899)
  • una vulnerabilidad del tipo DoS en el comando query. (CVE-2017-0900)
  • una vulnerabilidad en el instalador de gemas, la cual permite a una gema maliciosa el sobreescribir archivos arbitrariamente. (CVE-2017-0901)

Se recomienda a los usuarios de Ruby a actualizar o tomar alguna de las siguientes opciones tan pronto como sea posible.

Versiones afectadas

  • Ruby 2.2: 2.2.7 y anteriores
  • Ruby 2.3: 2.3.4 y anteriores
  • Ruby 2.4: 2.4.1 y anteriores
  • antes de trunk revision 59672

Soluciones alternativas

Si no puede actualizar Ruby, actualice RubyGems a la última versión. RubyGems 2.6.13 y posteriores incluye la corrección para éstas vulnerabilidades.

gem update --system

Si no puede actualizar RubyGems, puede aplicar el parche correspondiente como una solución alternativa.

En el caso de trunk, actualice a la última revisión.

Créditos

Este reporte está basado en el blog oficial de RubyGems.

Historial

  • Publicado originalmente: 2017-08-29 12:00:00 UTC
  • Agregado el número CVE: 2017-08-31 2:00:00 UTC
  • Mención de la actualización de Rubies: 2017-09-15 12:00:00 UTC

Publicado por usa el 2017-08-29
Traducción de Espartaco Palma

Chuleta de comandos para Org-Mode

18/10/2017
Artículo original

Este artículo es una referencia rápida de los comandos más útiles de org-mode, es una versión de una página del manual oficial, pero ya que lo visitaba una y otra vez, decidí crear este post que recopile los comandos que más uso.

Org mode quick reference
Org mode quick reference

Para empezar, con <TAB>, ciclas sobre las distintas secciones, expandiendo/contrayendo.

Secciones

* Top level headline
** Second level
*** 3rd level
    some text
*** 3rd level
    more text

* Another top level headline

Ciclar

Para ciclar sobre las secciones:

  • <TAB> Cicla el sub-árbol.
  • S-<TAB> o C-u <TAB> Cicla globalmente todas las secciones.
  • C-u C-u C-u <TAB> Expande todas las secciones.

Moverse entre secciones

  • C-c C-n Siguiente sección.
  • C-c C-p Sección anterior.
  • C-c C-f Siguiente sección del mismo nivel.
  • C-c C-b Sección anterior del mismo nivel.
  • C-c C-u Ir subiendo a secciones superiores.

Insertar/modificar secciones

  • M-<RET> Insertar una nueva sección, del mismo nivel que el actual. Si el cursor está a mitad del párrafo, divide el párrafo en dos secciones.
  • M-S-<RET> Inserta un elemento TODO en el mismo nivel.
  • <TAB> En una sección vacía, ciclar sobre los niveles.
  • M-<left>/<right> Incrementar/decrementar un nivel.
  • M-S-<left>/<right> Incrementar/decrementar un nivel el sub-árbol actual.
  • M-S-<up>/<down> Mover el sub-árbol arriba o abajo.
  • C-c C-w Mover la sección o región a otro lugar.
  • C-x n s/w Reducir/ampliar el bufer al sub-árbol actual.

Árboles dispersos

Útil para ocultar partes del documento en las que no estamos trabajando actualmente.

  • C-c <barra inclinada> Pregunta cómo crear el árbol.
  • C-c <barra inclinada> r Crea el árbol disperso en base a una expresión regular, para desmarcar el resaltado pulsar C-c C-c.

Listas

  • No ordenadas: -, + o *.
  • Ordenadas: 1. o 1)
  • Descripción: Usa :: para separar el término de la descripción.
  • <TAB> Ocultar los elementos.
  • M-<RET> Insertar nuevo elemento al mismo nivel.
  • M-S-<RET> Insertar elemento con checkbox.
  • M-S-<up>/<down> Mover elementos arriba/abajo, incluyendo sub elementos.
  • M-<left>/M-<right> Incrementar/decrementar nivel.
  • M-S-<left>/<right> Incrementar/decrementar nivel incluyendo sub elementos.
  • C-c C-c Si hay un checkbox, cambiar el estado.
  • C-c - Ciclar sobre los distintos tipos de listas.

Notas al pie

  • C-c C-x f Cuando el cursor está en una referencia, ir a la definición (o vice versa), de lo contrario crea una nueva nota al pie.
  • C-c C-c Saltar entre definición y referencia.

Un ejemplo de una nota al pie 1. El código que la genera es:

Un ejemplo de una nota al pie[fn:1].

[fn:1] Click en return para volver a la referencia

Enlaces

Sintáxis: [[enlace][descripción]] o solo [[enlace]], una vez creado, se puede editar con C-c C-l.

Si no hay una URL, el enlace se considera interno al documento:

[[#custom-id]]
[[My Target][Find my target]]

El último ejemplo, busca en el documento actual <<My Target>> y enlaza a él.

  • C-c l Almacena un enlace a la posición actual.
  • C-c C-l Inserta el enlace, pregunta por la url y descipción, si se llama con el prefijo C-u, se usa autocompletado.
  • C-c C-l Con el cursor en un enlace, lo edita.
  • C-c C-o o mouse-1 o mouse-2 abre el enlace.

TODO items

Toda sección comenzando con TODO es un elemento TODO (lista de tareas).

  • C-c C-t Cicla entre los distintos estados (unmarked) -> TODO -> DONE -> (unmarked).
  • S-<right>/<left> Igual que arriba, pero solo para el elemento actual.
  • C-c / t Ver la lista como un árbol disperso.
  • C-c a t Muestra la lista de tareas global.
  • S-M-<RET> Inserta una nueva tarea.
  • C-c , Establecer prioridad de la tarea (Entre A,B,C).
  • S-<up>/<dwn> Ciclar entre prioridades.

TODO checkboxes

Se pueden crear listas de tareas compuestas de varios elementos, y con C-c C-c se marcan como completadas, para crear una tarea nueva M-S-<RET>.

* TODO Organize party [0/3]
  - [ ] call people [0/2]
    - [ ] Peter
    - [ ] Sarah
  - [ ] order food

TODO Items checkboxes
TODO Items checkboxes

Markup

  • *negrita* => negrita.
  • /Cursiva/ => Cursiva.
  • =code= y ~verbatim~ -> code, verbatim.
  • +tachar+ -> tachar.
  • _subrayar_ -> subrayar

Imágenes y tablas

Sintáxis de las tablas:

| HEADER1  | header2  |
|----------+----------|
| content1 | contend2 |

Creating tables in org-mode
Creating tables in org-mode

Las imágenes son enlaces: [[./img/a-image.jpg]]

Código fuente

Para incluir código fuente:

 #+BEGIN_SRC emacs-lisp
     (defun org-xor (a b)
        "Exclusive or."
        (if a (not b) b))
 #+END_SRC

generará lo siguiente:

(defun org-xor (a b)
  "Exclusive or."
  (if a (not b) b))

Para editar el código en un buffer que soporte dicho lenguaje, C-c '

Fuente


  1. Click en return para volver a la referencia. [return]

Historia del lenguaje C#: pasado, presente y evolución

18/10/2017
Artículo original

Evolución del lenguaje C#

Aún recuerdo la primera vez que le eché un vistazo a C# a principios de los 2000. Microsoft había liberado la primera gran versión del lenguaje. En aquel momento pensé que era como Java, pero hecha por Microsoft, que le habían dado otro nombre y lo habían metido dentro de Visual Studio. Y no era el único que había pensado esto. En una antigua entrevista, el padre de Java, James Gosling, lo había llamado una imitación. "Es un tipo de Java con fiabilidad, productividad y seguridad nula," había dicho. ¡Buff!

Ha habido muchísimos cambios en los últimos 15 años. Dudo de que nadie haga hoy en día una valoración similar. En este tiempo, Java ha liberado 4 grandes versiones, mientras que C# ha liberado 6. Los lenguajes han tomado caminos diferentes, y C# ha experimentado muchísima innovación. Hoy me gustaría echar la vista atrás a la historia de C# y destacar algunas de las claves en su evolución.

¿Cómo era el lenguaje en sus versiones más tempranas? ¿Cómo ha evolucionado hasta la fecha?

C# Versión 1

Cuando echas la vista atrás, la primera versión de C# sí que se parecía un montón a Java. Como parte de sus objetivos de diseño escritos para ECMA, buscaba ser un "lenguaje orientado a objetos de uso general moderno y sencillo". En aquel momento, podría haber hecho algo peor que mirar hacia Java para alcanzar dichos fines.

Pero si analizases la versión 1.0 de C# 1.0 hoy, te marearías. Carecía de capacidades asíncronas sólidas y de muchas de las "pulidas" funcionalidades relacionadas con los genéricos que hoy en día damos por sentadas. En realidad, carecía de genéricos en general. ¿Y LINQ? Nada. Eso tardaría aún unos cuantos años en salir.

La versión 1 de C# parecía estar bastante desprovista de funcionalidad, comparado con hoy. Al final te veías escribiendo código pesado. Pero bueno, como con cualquier versión 1.0: por algún lado hay que empezar...

C# Versión 2

Aquí las cosas se empiezan a poner interesantes. Repasemos algunas de las principales características de C# 2.0, lanzado en 2005, junto con Visual Studio 2005 (no te olvides de echarle un vistazo al libro escrito por el creador de NDepend, Patrick Smacchia, sobre .NET 2.0, disponible en inglés y francés).

Aunque Microsoft puede que haya empezado con un lenguaje orientado a objetos bastante genérico, la versión 2 de C# lo cambió todo enseguida. Se pusieron a la tarea tras la salida de la versión inicial y fueron a por varias de las frustraciones que causaba. Y lo hicieron muy en serio.

Con genéricos, tienes tipos y métodos que pueden operar sobre un tipo arbitrario mientras que aún conservan seguridad de tipos. Así, por ejemplo, tener una List<T> te permite tener una List<string> o una List<int> y realizar operaciones seguras de tipo en esas cadenas de caracteres o ints mientras iteras por ellas. Esto es mucho mejor que crear clases derivadas de listas (ListInt?) o convertir a un Objeto para cada operación.

¡Ah!, y hablando de iteradores, la versión 2 de C# los presentó. Para resumir, esto te permite iterar por los ítems de una Lista (u otros tipos Enumerable) con un bucle foreach. Tener esto como un elemento de primera clase del lenguaje mejoró ostensiblemente la legibilidad del código y la capacidad para poder entenderlo.

Y aún así, Microsoft seguía intentando ponerse a la altura de Java. Java ya había liberado versiones que incluían genéricos e iteradores. Pero eso cambiaría pronto a medida que los lenguajes seguían una evolución diferente.

C# Versión 3

La versión 3 de C# apareció a finales de 2007, junto con Visual Studio 2008, aunque la funcionalidad completa aparecería con la versión 3.5 de C#. ¡Y menuda actualización resultó ser!. Yo me atrevería a afirmar que ese momento consolidó a C# como un lenguaje de programación realmente formidable. Veamos algunas de sus características principales en esta versión:

Con mirada retrospectiva, muchas de estas características parecen tanto inevitables como inseparables. De hecho, no es fácil destacar una sobre otra ya que todas encajan estratégicamente muy bien juntas.

Otros haciendo este mismo análisis no tendrán ese problema, y dirán que, de largo, la novedad más importante de la versión 3 de C# fue las expresiones de consulta, también conocidas como LINQ (Language INtegrated Query).

Yo creo que hay más matices y sutilezas puesto que, desde mi punto de vista, los árboles de expresión, las expresiones lambda y los tipos anónimos fueron los cimientos sobre los que se creó LINQ. Disertaciones aparte, lo cierto es que nos encontramos con un concepto realmente revolucionario. Microsoft había empezado a allanar el terreno para hacer de C# un lenguaje funcional orientado a objetos híbrido.

En concreto, con esta versión ya se podían programar búsquedas declarativas tipo SQL para llevar a cabo operaciones en colecciones, entre otras cosas. En vez de tener que crear un bucle para computar la media de una lista de enteros, ahora se podía hacer con algo tan fácil como list.Average(). La combinación de expresiones de búsqueda y métodos de extensión hizo parecer que las listas de enteros se habían hecho más inteligentes.

Llevó un tiempo hasta que los programadores realmente entendieron cómo integrar el concepto, pero a la larga lo lograron. Y ahora, unos años más tarde, el código es mucho más conciso, sencillo y funcional.

C# Versión 4

La versión 4 de C# nació con el estigma de no suponer una innovación rompedora como sí lo había sido su antecesora versión 3. Y es que con la versión 3, Microsoft hizo que el lenguaje dejase de estar a la sombra de Java y empezó a destacar. Rápidamente el lenguaje se estaba convirtiendo en una opción elegante.

De todos modos, la versión 4 de C# sí introdujo alguna cosas chulas.

Los tipos interop embebidos aliviaron problemas a la hora del despliegue. La covarianza y contravarianza genéricas te dan mucha potencia, pero son demasiado académicas y probablemente sean más valoradas entre los creadores de frameworks y bibliotecas. Los argumentos opcionales y con nombre te permiten eliminar muchas sobrecargas de método y ofrecen comodidad. Pero ninguna de estas cosas altera el paradigma propiamente dicho.

Esa distinción sí se la llevan los tipo dinámico. Con esta característica, Microsoft introdujo en la versión 4 de C# la capacidad de anular el compilador al tiparlo en tiempo de compilación. Es decir, al usar el tipo de referencia dinámico, te puedes llegar a pegar un tiro en el pie como en los lenguajes de tipado dinámico como JavaScript. Puedes crear una "x = cadena de caracteres" dinámica y luego añadirle 6, dejando al tiempo de ejecución determinar qué diablos tiene que pasar después.

Esto lo digo un poco de broma obviamente. Está claro que cabe la posibilidad de cometer errores, pero también otorga mucha potencia dentro del lenguaje.

C# Versión 5

Con la versión 5 de C#, Microsoft liberó una versión con el foco muy puesto en la innovación del lenguaje. Esta es la lista de las características más importantes:

No quiero que se me malinterprete. El atributo caller info está muy bien. Te permite recuperar información sobre el contexto en el que estás sin tener que recurrir a un montón de código reflejo repetitivo. Me encanta esta funcionalidad en realidad.

Pero async y await son las verdaderas estrellas de esta versión. Cuando esto salió en 2012, Microsoft cambió las reglas del juego nuevamente al meter la asincronía en el lenguaje como un participante de primera clase. Si ya has gestionado operaciones largas y la implementación de páginas web con retro-llamadas, probablemente adores esta funcionalidad.

C# Versión 6

Con las versiones 3 y 5, Microsoft había hecho algunas cosas bastante impresionantes en un lenguaje orientado a objetos (la versión 2 también, pero estaban copiando conceptos de Java con esas funciones que introdujeron). Con la versión 6 se alejaron de la idea de sacar una novedad dominante estrella y, en vez de eso, liberaron muchas características para hacer felices a los usuarios del lenguaje de programación. Aquí enumero unas cuantas:

Si las vemos de forma individual, todas estas características del lenguaje son muy interesantes. Pero si las valoramos en conjunto, observamos un patrón que nos llama la atención. En esta versión, Microsoft se ha esforzado en eliminar repeticiones en el lenguaje y hacer que el código sea más ligero y legible. Así que para los aficionados del código escueto y limpio, esta versión del lenguaje fue una gran victoria.

¡Ah!, e hicieron otra cosa con esta versión, aunque no se puede considerar como una función tradicional del lenguaje, per se. Liberaron Roslyn, el compilador, como servicio. Microsoft ahora usa C# para hacer C#, y te dejan usar el compilador como parte de tus esfuerzos de programación.

C# Versión 7

Finalmente hemos llegado ya a la versión 7 de C#. Es la versión actual en la fecha que se ha escrito este artículo. Tiene cosas muy chulas y revolucionarias que ya estaban en el ADN de la versión 6, pero sin el compilador como servicio. Aquí van las novedades de esta versión:

Todas ofrecen nuevas capacidades para que los desarrolladores puedan escribir código más limpio que nunca. En concreto, creo que Microsoft ha dado solución a problemas que venían desde muy lejos al condensar la declaración de variables que se pueden a usar con la palabra clave out y al permitir valores de devolución múltiples vía tuplas.

Además, Microsoft le está dando un uso más amplio al lenguaje. .NET ahora va dirigido a cualquier sistema operativo y tiene la vista puesta de forma firme en la nube y en la portabilidad. Esto es lo que más ocupa la mente y el tiempo de los diseñadores del lenguaje, además de pensar en nuevas características.

Conozco C# desde hace 15 años, y el lenguaje ha estado bajo desarrollo más tiempo que eso. Será emocionante ver qué funcionalidades y características deparará el futuro.

Este artículo es una traducción del original en inglés escrito por Erik Dietrich en el blog de NDepend, con permiso de Erik y de esta empresa. Fotografía de la portada por Homar - CC0, adaptada para este post por campusMVP.

TRUCO: Auto-montar un disco virtual en una tarjeta SD al iniciar Windows 10

13/10/2017
Artículo original

Este es un truco genérico que, de hecho, puede servirte para muchas otras cosas...

Si tienes un tablet o un ordenador convertible barato con Windows 10, lo habitual será que no vayan muy sobrados de almacenamiento. Muchos de estos dispositivos vienen con tan solo 32GB de almacenamiento, ya que esto suele ser lo más caro del aparato. Windows 10 de hecho, se suele "comer" al menos 8 o 10 de estos GB por lo que no solemos andar muy sobrados de espacio. Todos estos aparatos suelen tener almacenamiento expandible mediante tarjetas MicroSD. En la actualidad este tipo de almacenamiento externo es muy barato. Puedes comprar una de 64GB de clase 10 y 100MB/s por menos de 30€, por lo que la verdad es que la opción de utilizarlas en este tipo de dispositivos no está nada mal.

El caso es que, te compras la estupenda y rapidísima tarjeta microSD pero, oh sorpresa, no puedes instalar nada en ella porque al ser extraíble el sistema no te lo permite, e incluso algunos programas no te permiten usarla tampoco para almacenamiento. ¡Qué contrariedad! Cosas de Windows...

Un ejemplo muy claro de esta molestia es OneDrive. Si intentas decirle a OneDrive que quieres usar una carpeta en la tarjeta microSD para almacenar los archivos que sincronizas te dice que no es posible usar un medio extraíble.

Y es que, una de las cosas que solemos hacer muchos para tener nuestros archivos siempre a mano es sacarle partido a algún almacenamiento en la nube estilo Dropbox, Google Drive, OneDrive o pCloud (uno de mis grandes descubrimientos recientes, con interesantes características y además son europeos). El caso es que estos servicios (menos pCloud) requieren mucho espacio en disco para almacenar los archivos que tengas en la nube. Y aunque ahora la moda es incluir una funcionalidad para que solo se sincronicen los archivos que quieras, en el caso de OneDrive aunque fueron los pioneros retiraron esta capacidad al lanzar Windows 10 (vergüenza debiera darles, cuando ahora todos les copian) y Dropbox solo lo incluye en las versiones para empresas (ni siquiera si les pagas la versión Plus, ya les vale). GDrive es el único que lo tiene, con el nuevo Google Drive Stream que están lanzando estos días, pero a medida que accedes a las carpetas o si sincronizas muchas cosas te acaba ocupando mucho espacio también ya que la caché de los archivos la hace en tu perfil de usuario, o sea, en C: y no deja cambiar esta ubicación. El único amistoso en este sentido es pCloud, que no lo necesita al ser una carpeta en la nube directamente, y la pequeña caché local que utiliza, no obstante, te deja colocarla donde quieras.

Debido a ellos, este tipo de aplicaciones son muy avariciosas con el espacio en disco, y no se llevan bien con el hecho de usar una tarjeta externa que puedes retirar en cualquier momento...

Además de este tipo de aplicaciones, el caso es que para muchos programas almacenar en la tarjeta microSD no es una opción. Ahora te voy a contar cómo deshacerte de esta limitación.

Discos virtuales

Desde hace mucho tiempo, desde Windows 7 si no me equivoco, el sistema operativo Windows tiene la capacidad de gestionar discos duros virtuales nativamente. Se trata de archivos con la extensión .vhd (Virtual Hard Drive) o .vdhx (un formato ma´s moderno y extensible) que son los mismos que usa Hyper-V, el producto de virtualización de Microsoft, también incluido de serie con Windows (aunque no instalado por defecto).

Gracias a esta capacidad es muy sencillo crear un disco virtual, que se verá como un disco real a todos los efectos, y podremos utilizarlo como si se tratase de una unidad física existente. Esto incluye archivos de disco virtual guardados en un medio de almacenamiento externo como una tarjeta microSD.

Lo único que tenemos que hacer para crear un nuevo disco virtual en Windows 10 es pulsar con el botón derecho en el botón de inicio y elegir la opción "Gestión de disco" (yo tengo el sistema en inglés, pero debe de ser aproximadamente eso):

Otra opción es buscar "Computer management" en el inicio y asegurarnos de arrancarlo con permisos de administrador (opción el pulsarlo con el botón derecho), ya que sin ellos no podremos hacer nada en este caso:

Esto nos abre una nueva ventana en la que tenemos todos los discos del sistema para gestionar. En el menú "Acciones" tenemos dos opciones relacionadas con la gestión de discos virtuales: crearlos y adjuntarlos:

Si escoges crear un nuevo disco virtual te aparece una pantalla como la siguiente:

En ella deberás introducir la ruta donde quieres crear el VHD, que en este caso sería la tarjeta SD, y el tamaño del disco en MB o GB. Escoge bien el tamaño adecuándolo a tus necesidades.

Luego te da a elegir dos cosas más muy importanes:

  • El formato del disco virtual: el VHD debería ser suficiente ya que no necesitas tener un tamaño mayor de 2TB, pero por otro lado yo te recomendaría que elijas el VHDX porque es más resistente a fallos (como que retires la tarjeta de golpe sin avisar, aunque jamás debieras hacerlo). Eso sí, si escoges VHDX no podrás leerlo en Windows 7 si te levas la tarjeta a este sistema en algún momento.
  • El tipo de disco: si escoges el tamaño fijo el disco ocupará ese espacio máximo desde el primer minuto, aunque no le metas información dentro. Aunque está recomendado el de tamaño fijo yo suelo elegir el de tamaño dinámico porque le puedes poner el tamaño que quieras y solo te ocupará lo que realmente sea necesario para la información que contiene. De este modo podrías tener una tarjeta SD pequeña de 16GB pero decirle que el disco sea de 128GB, y funcionaría bien. Solo debes tener cuidado de no pasarte de 16Gb. En el futuro cuando necesites más espacio, simplemente copias el archivo .vhdx a una nueva tarjeta más grande y listo.

Listo. Una vez creado puedes adjuntarlo a tu sistema usando la otra opción de menú. Se le asignará una letra y podrás acceder a él como una unidad de disco física normal, solo que en realidad estarás usando el almacenamiento extraíble. OneDrive te dejará poner su carpeta en la nueva unidad, y podrás crear enlaces simbólicos o juntions para redirigir carpetas a dicha unidad 8de esto, si me lo pedís, hablaré otro día pues es un tema muy interesante).

Pero no nos llega solo con esto...

Adjuntarlo automáticamente

Lo anterior está bien pero no nos sirve de mucho si en cuanto arranca el sistema no tenemos de nuevo la unidad adjunta. Y es que adjuntar manualmente una unidad como acabamos de hacer no es una operación persistente. Es decir, cuando el sistema operativo se reinicie por una actualización o cualquier otro motivo, la unidad no estará ahí. Ouch!

Para lograr que siempre esté disponible lo que tenemos que hacer es adjuntarla automáticamente con un script antes siquiera de que el usuario se loguee en el sistema. Para ello abrimos una línea de comandos con permisos de administrador, y escribimos gpedit para lanzar el gestor de políticas del sistema, y nos vamos al nodo Configuración de la computadora·Ajustes de Windows·Scripts (inicio/cierre):

Al editar esta política nos sale la ventana en primer plano de la figura anterior que nos permite asignar ciertos scripts para ser ejecutados cuando arranca el equipo, antes de que ningún usuario se loguee siquiera.

Lo que tenemos que hacer es escribir un pequeño script a ejecutar que haga lo que queremos: adjuntar el VHDX como una unidad, antes de nada.

Vete a la carpeta del SD en el que has creado el disco virtual, y en el mismo sitio crea un archivo de texto (por ejemplo adjunta-VHDX.txt) con el siguiente contenido:

select vdisk file="D:\Discos\OneDrive.vhdx"
attach vdisk

siendo lo que va entre comillas dobles la ruta a tu unidad de disco virtual.

Este archivo de texto lo usaremos como argumento del comando diskpart que gestiona los discos desde la línea de comandos. Así que crea otro archivo de texto con el mismo nombre pero con extensión .bat y dentro pon lo siguiente:

diskpart /s "D:\Discos\adjunta-VHDX.txt"

siendo lo que va entre comillas la ruta al archivo de texto anterior.

Ahora en el diálogo que tenías abierto en el gestor de políticas, asigna ese script pulsando sobre "Añadir" y poniendo la ruta al .bat que acabas de crear.

¡Listo! Ahora, cada vez que arranque el equipo se adjuntará una unidad de disco, a todos los efectos como otra cualquiera, solo que estará sustentada en un disco virtual guardado en tu tarjeta microSD, y podrás utilizarla como verdadero almacenamiento adicional, como si le hubieras colocado un disco duro interno nuevo al ordenador.

Esto además de lo que he contado tiene otras ventajas como por ejemplo que puedes mover de golpe miles de archivos que estén dentro de la unidad virtual copiando un único archivo (el .vhdx), por lo que copiarlo a cualquier lado es mucho más rápido (se copia mucho más rápido un archivo que miles de ellos aunque el espacio que ocupen sea el mismo). 

Solo un consejo: ahora sí, antes de retirar la tarjeta microSD asegúrate de desvincular el disco o podrías tener problemas. De hecho si es un tablet, lo mejor es que si necesitas quitar la tarjeta antes lo apagues, y luego la pongas de nuevo antes de encenderlo.

¡Espero que te sea útil!

Principios de una arquitectura limpia: mantenible y testeable

13/10/2017
Artículo original

Arquitectura

Estoy seguro de que si te dedicas a programar, conoces a Robert "Uncle" Martin. Su libro Clean Code es uno de los más recomendados en la lista de libros que todo desarrollador debería leer. Martin, con sus cosas buenas y malas, es uno de los desarrolladores más influyentes del panorama ingenieril. Fuerte defensor de TDD, de la cobertura de tests y otras buenas prácticas, y además cuenta con muchas personas que siguen sus enseñanzas a rajatabla.

Recientemente, Bob Martin, ha publicado un nuevo libro llamado Clean Architecture. ¿Pero qué se entiende por arquitectura limpia?

Clean Code

Como comentaba antes, Clean Code es un libro muy recomendable, que desgrana algunas ideas importantes para poder escribir código limpio.

El código limpio es aquel código que está estructurado de forma compresible, que es claro en sus intenciones, fácil de leer, que es fácilmente mantenible y que está testeado. En el libro se van dando algunas ideas para conseguir escribir código limpio, hablando de principios SOLID, de la importancia de dar nombres a variables y clases etc. En GenbetaDev ya hemos hablado del libro y de sus ideas en alguna ocasión

Principios de una arquitectura limpia

Aunque seamos capaces de escribir código limpio, podemos encontrarnos que al crecer nuestro sistema, la arquitectura del mismo sea un lastre. Y es que no es lo mismo escribir código limpio para un proyecto sencillo, que para un proyecto complejo compuesto de varios componentes obligados a cooperar. A veces las arquitecturas son demasiado complejas, nos obligan a repetir código, o nos hacen tener demasiadas dependencias entre componentes, causándonos muchos problemas.

Los conceptos de cohesión y acoplamiento, también pueden aplicarse a nivel de arquitectura.

Si utilizáis programación orientada a objetos, seguro que conocéis los conceptos de cohesión y acoplamiento. Esos conceptos también pueden aplicarse de forma parecida a los componentes de un sistema, ya sean dlls o archivos jar, estos tienen que cooperar unos con otros. Y la manera en la que cooperen, pueden hacer un sistema fracasar. Pero si seguimos una serie de principios para controlar estas dos variables, nuestra arquitectura será más limpia y manejable.

Cohesión

  • The Reuse/Release Equivalence Principle: que nos dice que los componentes deben poder ser desplegados de forma independiente sin afectar a los demás. Las clases, o código que van en ese componente, deben tener una relación, y por tanto deben poderse desplegar de forma conjunta.

  • The common closure principle: se podría decir que hablamos del principio de responsabilidad única (SRP) aplicado a componentes. La idea es agrupar clases que puedan cambiar por la misma razón en un solo componente. Si tenemos que hacer un cambio, y hay que tocar varios componentes, esto supondrá tener que desplegarlos todos, en lugar de sólo uno.

  • The common reuse principle: este principio nos habla de evitar a aquellos que utilizan un componente depender de cosas que no necesitan. Si un componente depende de otro, hay que intentar que sea porque necesita todas las clases que lo componen. Lo contrario nos obligará a trabajar más cuando nos toque hacer el despliegue. De esta manera será más fácil reutilizar componentes.

Conseguir cumplir estos tres principios a la vez es algo bastante difícil, por lo que a veces hay que aceptar compromisos. Por ejemplo es común sacrificar un poco la reusabilidad, para conseguir que los componentes sean fáciles de desplegar.

Acoplamiento

  • The Acyclic Dependencies Principle: si trazamos líneas entre los componentes para representar las dependencias entre ellos, tenemos que intentar que no existan ciclos. Es decir, que el cambio en un componente, no acabe desencadenando en la necesidad de hacer cambios en cadena en los demás componentes, que obliguen a volver a modificar el componente inicial. Cuando eso sucede, es difícil conseguir una versión estable del sistema, ya que hay que hacer multitud de cambios en los distintos componentes hasta que todo vuelve a funcionar.

  • The stable dependencies Principle: todo sistema tiende a cambiar y evolucionar, pero no todos los componentes cambian con la misma frecuencia, ni es igual de fácil modificarlos. Este principio nos dice que un componente que cambia a menudo no debería depender de otro que es difícil modificar, ya que entonces será también difícil de modificar.

  • The stable Abstractions Principle: este principio nos dice que si un componente de nuestro sistema va a cambiar poco ya que es difícil modificarlo, debe estar compuesto mayoritariamente por interfaces y clases abstractas. De esta manera el componente será fácilmente extensible, y no afectará tanto al resto de la arquitectura.

Características de una arquitectura limpia

Además de cumplir los principios anteriormente descritos, una arquitectura limpia se caracteriza por:

  • Independiente de los frameworks. Los frameworks deberían ser herramientas, y no obligarnos a actuar de una determinada manera debido a sus restricciones.

  • Testable. Debemos poder probar nuestras reglas de negocio sin pensar en base de datos, interface gráfica u otros componentes no esenciales de nuestro sistema.

  • Independiente de la UI. Si la UI cambia a menudo esto no puede afectar al resto de nuestro sistema, que tiene que ser independiente.

  • Independiente de la base de datos. Deberíamos poder cambiar de Oracle, a SQL Server, a MongoDB, a Casandra o a cualquier otra base de datos sin que afectara demasiado a nuestro sistema.

  • Independiente de cualquier entidad externa. No deberíamos saber nada de entidades externas, por lo que no deberemos depender de ellas.

Todas estas características, según Bob Martin, se agrupan en el siguiente gráfico:

Clean arquitecture

Partes de una arquitectura limpia

Entidades

Las entidades son las que incluyen las reglas de negocio críticas para el sistema. Estas entidades pueden ser utilizadas por distintos componentes de la arquitectura, por lo que son independientes, y no deben cambiar a consecuencia de otros elementos externos.

Una entidad deberá englobar un concepto crítico para el negocio, y nosotros tendremos que separarlo lo más posible del resto de conceptos. Esa entidad recibirá los datos necesarios, y realizará operaciones sobre ellos para conseguir el objetivo deseado.

Casos de uso

En este caso nos encontramos con las reglas de negocio aplicables a una aplicación concreta. Estos casos de uso siguen un flujo para conseguir que las reglas definidas por las entidades se cumplan. Los casos de uso, solo definen como se comporta nuestro sistema, definiendo los datos de entrada necesarios, y cual será su salida. Los cambios en esta capa no deberían afectar a las entidades, al igual que los cambios en otras capas externas no deberían afectar a los casos de uso.

Es importante que no pensemos en como los datos que genera un caso de uso serán presentados al usuario. No deberemos pensar en HTML, o en SQL. Un caso de uso recibe datos estructurados y devuelve más datos estructurados.

Adaptadores de interfaz

Los datos generados por los casos de uso y las entidades, tienen que transformarse en algo entendible por la siguiente capa que los va a utilizar y de eso se encarga esta capa. Pensando en MVC por ejemplo, los controladores y las vistas, pertenecerían a esta capa, y el modelo, serían los datos que se pasan entre los casos de uso y los controladores para luego poder presentar las vistas.

Lo mismo aplicaría para por ejemplo, presentar información a un servicio externo, ya que en esta capa definiríamos la manera en la que los datos de las capas internas se presenta al exterior.

Frameworks y drivers

En la capa más externa es, como dice Bob Martin, donde van los detalles. Y la base de datos es un detalle, nuestro framework web, es un detalle etc.

Fronteras o límites

Una frontera (o como dicen los aglosajones, boundaries) es una separación que definimos en nuestra arquitectura para dividir componentes y definir dependencias. Estas fronteras tenemos que decidir dónde ponerlas, y cuándo ponerlas. Esta decisión es importante ya que puede condicionar el buen desempeño del proyecto. Una mala decisión sobre los límites puede complicar el desarrollo de nuestra aplicación o su mantenimiento futuro.

Una mala decisión sobre los límites entre componentes puede complicar el desarrollo de nuestra aplicación o su mantenimiento futuro

Por ejemplo, podemos sentirnos tentados de pensar que las reglas de negocio deben poder guardar información directamente en la base de datos. Como ya hemos visto antes, la base de datos es un detalle, así que esto deberíamos evitarlo. En ese punto deberíamos trazar una frontera. Nuestras reglas de negocio, se comunicarían siempre con una interface, sin saber nada sobre la base de datos. La base de datos en cambio, si sabrá cosas sobre las reglas de negocio, ya que tiene que transformar los datos en sentencias SQL que puedan almacenar la información.

Otra ventaja adicional de este enfoque, es que podemos retrasar ciertas decisiones. Podemos empezar a desarrollar todas nuestras reglas de negocio, sin tener en cuenta su persistencia, ya que esa parte se realiza a través de una interface. Primero podemos utilizar objetos en memoria, y según avancemos, ir añadiendo sistemas más sofisticados. Al final podremos elegir entre usar una base de datos relacional, NoSQL, o incluso guardar la información en archivos.

En definitiva, debemos pensar en nuestro sistema, como un sistema de plugins, de forma que los componentes estén aislados y podamos sustituir unos por otros sin demasiados problemas.

Las fronteras de una arquitectura limpia

En el esquema de arquitectura limpia que hemos visto anteriormente, podemos ver dónde se han trazado las fronteras o límites. Entre entidades y casos de uso, hay una frontera. Lo mismo con los adaptadores de interface, o los frameworks y drivers. Las fronteras son importantes, porque añadirlas cuando no las necesitamos pude crearnos muchos problemas, pero no añadirlas cuando las necesitamos pude generar otros tantos (añadirlas después, es siempre es mucho más costoso).

La separación en fronteras es importante, pero mucho más importante es la gestión que hagamos de las dependencias entre estas capas. Para ello siempre hay que seguir la regla de las dependencias.

La regla de las dependencias

Esta regla es muy importante, ya que sin ella, nuestra arquitectura no sería más que un bonito diagrama. Las capas interiores de una arquitectura limpia, no deben saber nada de las capas exteriores. Por ejemplo la capa de entidades, no puede saber de la existencia de los casos de uso, y los casos de uso no deben saber nada de la existencia de los adaptadores de interface. Así las dependencias están controladas y van siempre en un solo sentido.

Estructuras de datos simples

A la hora de traspasar una frontera, deberemos utilizar estructuras de datos simples, evitando utilizar conceptos como DatabaseRows o similares. Pensando en los casos de uso, estos deben recibir estructuras de datos como datos de entradas, y deben devolver estructuras de datos como salida. Como decía antes, no nos interesa que un caso de uso tenga conocimientos sobre HTML o SQL. Lo contrario nos lleva a una falta de independencia, con todo lo que eso conlleva (despliegue, actualización, tests etc.)

Las capas interiores de una arquitectura limpia, no deben saber nada de las capas exteriores

En ocasiones al pasar datos a los casos de uso, podemos pensar que es buena idea utilizar las entidades como datos de entrada o salida. Al fin y al cabo comparten mucha información. Pero esto no deja de ser un error, ya que aunque al principio la información parezca similar, en el futuro los casos de uso y las entidades cambiarán de muy diferentes maneras, obligándonos a tratar con la dependencia que hemos creado.

Fronteras parciales

A veces, por motivos de organización y mantenimiento, nos interesa crear fronteras parciales. Este tipo de fronteras las tenemos que planificar de forma similar a una frontera real, pero en lugar de empaquetarla en un componente aislado, la dejamos que forme parte de otro componente. Así nos ahorramos parte del esfuerzo de crear un componente nuevo, que no estamos seguros de que vaya a necesitarse. Obtenemos algunas de sus ventajas, dejando todo preparado por si es necesario dar ese último paso.

Conclusión

Aunque puede que no sea la parte más importante de un proyecto de software, la arquitectura juega siempre un papel importante. Ignorar esta fase pude traernos muchos problemas en el futuro, por lo que nunca está de más prestarle un poco de atención. Cuando diseñamos una arquitectura hay que tener muchas cosas en cuenta, como la separación de componentes, las dependencias entre ellos y la manera en la que cruzaremos las fronteras entre los mismos.

Como desarrolladores de software, queremos conseguir desarrollar programas que funcionen y que sean útiles para sus usuarios, pero también que sean fácilmente mantenibles y rápidamente extensibles. Y sin duda para esto no viene nada mal tener algunos conceptos de como debe construirse una arquitectura limpia.

Libro | Clean Code Gráfico | Clean Architecture: A Craftsman's Guide to Software Structure and Design Imagen | acavoulacos

También te recomendamos

Aprender de la arquitectura del mejor software Open Source

Usando MVP e inversión de dependencias para abstraernos del framework en Android

Esto es lo que puedes ahorrar al comprar un vehículo eléctrico

-
La noticia Principios de una arquitectura limpia: mantenible y testeable fue publicada originalmente en Genbeta Dev por rubenfa .

Webpack: qué es, para qué sirve y sus ventajas e inconvenientes

10/10/2017
Artículo original

Logo de Webpack

Webpack nació a finales de 2012 de la mano de un solo desarrollador (Tobias Koppers, alemán), y en la actualidad es utilizado por miles de proyectos de desarrollo web Front-End: desde frameworks como React o Angular hasta en el desarrollo de aplicaciones tan conocidas como Twitter, Instagram, PayPal o la versión web de Whatsapp.

Webpack se define como un empaquetador de módulos (un bundler en la jerga habitual) pero que hace muchísimas cosas más:

  • Gestión de dependencias
  • Ejecución de tareas
  • Conversión de formatos
  • Servidor de desarrollo
  • Carga y uso de módulos de todo tipo (AMD, CommonJS o ES2015)
  • ...

Y esto esto último lo que hace que destaque en especial. Es una herramienta extremadamente útil cuando desarrollas aplicaciones web diseñadas con filosofía modular, es decir, separando el código en módulos que luego se utilizan como dependencias en otros módulos. Una de las cosas que hace realmente bien Webpack es la gestión de esos módulos y de sus dependencias, pero también puede usarse para cuestiones como concatenación de código, minimización y ofuscación, verificación de buenas prácticas (linting), carga bajo demanda de módulos, etc...

Una de las muchas cosas interesantes de Webpack es que no solo el código JavaScript se considera un módulo. Las hojas de estilo, las páginas HTML e incluso las imágenes se pueden utilizar también como tales, lo cual da un extra de potencia muy interesante.

Webpack es una herramienta de compilación (una build tool en la jerga) que coloca en un grafo de dependencias a todos los elementos que forman parte de tu proyecto de desarrollo: código JavaScript, HTML, CSS, plantillas, imágenes, fuentes... Esta idea central es la que lo convierte en una herramienta tan poderosa.

Webpack se puede considerar como un Task Runner muy especializado en el procesamiento de unos archivos de entrada para convertirlos en otros archivos de salida, para lo cual utiliza unos componentes que se denominan loaders.

Imagen conceptual de Webpack obtenida de la portada de su web

Lo habitual es utilizar un archivo de código especial llamado webpack.config.js que está en la raíz de tu proyecto de desarrollo y que define mediante código JavaScript las operaciones que quieres realizar. En este archivo defines toda la información necesaria para poder utilizar Webpack para tus propósitos.

Generalmente las herramientas como Webpack (la más conocida: Browserify) se han utilizado en combinación con gestores de dependencias y task runners. Pero Webpack es tan potente que ya puede efectuar de serie, sin necesidad de nada más, casi cualquier tarea que puedas necesitar para tu desarrollo. En la actualidad está desplazando poco a poco el uso de otras herramientas.

Por ejemplo, no solo tiene soporte de serie para minimizar o combinar archivos, generar mapas de depuración o copiar recursos, sino que incluso ofrece un servidor web integrado con la capacidad de recarga automática cuando algo cambia o reemplazo en caliente de módulos. Las pocas cosas para las que no tiene soporte directo o a través de loaders o plugins se pueden conseguir con el uso de scripts npm, al fin y al cabo la herramienta está basada en Node.js y necesita npm para instalarse.

El mayor problema que ha tenido Webpack desde siempre es que la configuración es un tanto complicada, al menos al principio, lo que hace que tardes un poco en tenerlo funcionando para tu proyecto. Aunque en los últimos tiempos están haciendo lo posible para mejorar esto gracias a añadir funcionalidad en la interfaz de línea de comandos para partir de plantillas ya pre-configuradas.

Ventajas e inconvenientes de usar Webpack

El concepto del grafo de dependencias de Webpack es muy poderoso y ofrece muchísimos beneficios, como por ejemplo:

  • Eliminación de recursos no utilizados: permite de manera sencilla obtener para producción únicamente aquellos recursos que son necesarios, dejando de lado los que no se utilizan. Esto incluye, por ejemplo, las reglas CSS que de verdad se están utilizando, dejando fuera las demás, lo cual es una utilidad muy potente.
  • Control absoluto sobre cómo procesas los recursos: para tomar decisiones avanzadas como que lleven un hash al final de su nombre en cada despliegue para que no queden "atrapados" en ninguna caché o que las imágenes pequeñas se incluyan codificadas en Base64 en la página en lugar de descargarse (ahorrando peticiones al servidor). Cosas por el estilo.
  • Te permite utilizar cualquier tipo de sistema de modularización para JavaScript, sea AMD, CommonJS, ES2015 o Angular, sin preocuparte de que el navegador tenga que soportarlo (Browserify, por ejemplo, solo soporta CommonJS, que es el de Node.js).
  • Tienes casi cualquier cosa que puedas necesitar sin recurrir a otras herramientas, por lo que no necesitarás un task runner como Gulp o un gestor de dependencias como Bower.
  • Es muy rápido.
  • Despliegues confiables: utilizando correctamente los conceptos de Webpack no puede darse el caso de que te dejes cosas fuera a la hora de desplegar. Esto en aplicaciones grandes es mucho decir.
  • Aunque al principio te puede costar arrancar con Webpack en el proyecto, una vez que lo hagas ganarás mucha velocidad de desarrollo.

Pero Webpack también tiene inconvenientes:

  • La configuración es bastante compleja y cuesta, sobre todo al principio, aunque están intentando mejorarlo ofreciendo plantillas y validadores intergados.
  • Todo lo que utilices debe ser modular. No solo deberás escribir los archivos JavaScript como módulos, sino que las dependencias de otras bibliotecas de JavaScript de terceros que utilices deben ser modulares también (aunque hoy en día eso no es muy problemático).
  • En proyectos grandes tocar la configuración puede ser complejo.
  • Algunas sintaxis pueden ser algo confusas.
  • La documentación ha sido tradicionalmente mala, difícil de entender y poco clara en algunas cosas, aunque la van mejorando.
  • Si algo falla es difícil de saber qué está pasando, ya que no da mucha información sobre el evento.
  • El código fuente es muy complejo. Esto está relacionado con lo anterior. No es que tengas que ir mucho a ver el código fuente, pero si alguna vez lo necesitas para ver por qué algo falla o cómo funciona una determinada característica, no es lo más fácil de seguir del mundo.

El uso de Webpack puede llegar a ser complejo y, al igual que otras herramientas típicas de desarrollo web Front-End,como gestores de dependencias o task runners, para un proyecto pequeño quizá no tenga mucho sentido usarlo o quizá no aporte grandes beneficios de entrada. Sin embargo, en proyectos de tamaño mediano o grande los beneficios se ven inmediatamente.

Si vas a programar con React es casi obligatorio que utilices Webpack, pues es la herramienta que han adoptado para su desarrollo y la que usa todo el mundo en su comunidad.

Si trabajas en desarrollo web es casi seguro que más pronto que tarde te vayas a encontrar Webpack. Gracias a su potencia y a la enorme comunidad de usuarios que tiene detrás se ha convertido en "la herramienta". Su desarrollo se ha acelerado gracias al apoyo económico de algunas empresas importantes y muchas empresas pequeñas y desarrolladores individuales.

No deberías perderlo de vista...

Plantillas de correo en Gmail – Herramienta / Extensión

08/10/2017
Artículo original

Espero y este post sea de tu agrado, no olvides compartirlo en su redes sociales y sobre todo.. Gracias por seguirnos!

¿Sueles enviar decenas de correos al día? ¿Muchos de esos correos son muy parecidos? No te preocupes! Hoy vamos a analizar una herramienta / extensión para Chrome, que nos permite crear plantillas de correo en Gmail con textos predefinidos por nosotros para posteriormente elegir la plantilla que necesitemos sin tener que perder tiempo en redactarlas, ¿Genial no? Muchas veces en el día suelo mandar varios correos con la misma información, a diferentes personas y en diferentes tiempos obviamente, pero el problema es el mismo: pierdo tiempo redactando el mismo correo! Hoy me levante pensando sería genial que existiera esta herramienta

Compartir en Facebook

Comparte en Google Plus

Compartir en Twitter

El post Plantillas de correo en Gmail – Herramienta / Extensión aparece en el Blog de Jonathan Melgoza

21 Libros Que Debes Leer Para Ser Un Data Scientist O Data Engineer

06/10/2017
Artículo original

Tras mucho buscar, al fin he conseguido recopilar una lista de libros que todo Científico de Datos o Ingeniero de Datos debería tener en su biblioteca personal. Sin más dilaciones, he aquí la lista (La descrición de los libros ha sido cogida de Amazon)

Para Data Scientist

Deep Learning

Deep Learning Book

An introduction to a broad range of topics in deep learning, covering mathematical and conceptual background, deep learning techniques used in industry, and research perspectives."Written by three experts in the field, Deep Learning is the only comprehensive book on the subject." -- Elon Musk

Python Machine Learning

Python Machine Learning book

Unlock deeper insights into Machine Leaning with this vital guide to cutting-edge predictive analytics. Leverage Python's most powerful open-source libraries for deep learning, data wrangling, and data visualization

Learning From Data

Learning From Data by Yaser S. Abu-Mostafa

Este es uno de los libros principales que hemos usado en mi facultad en la asignatura “Aprendizaje Automático”, está bastante bien, muy teórico pero bien explicado y con ejemplos sencillos de entender.

Data Science from Scratch

Data Science from Scratch

In this book, you’ll learn how many of the most fundamental data science tools and algorithms work by implementing them from scratch.

R Cookbook

R Cookbook (O'Reilly Cookbooks)

With more than 200 practical recipes, this book helps you perform data analysis with R quickly and efficiently.

Machine Learning for Hackers

Machine Learning for Hackers

If you’re an experienced programmer interested in crunching data, this book will get you started with machine learning—a toolkit of algorithms that enables computers to train themselves to automate useful tasks.

Python for Data Analysis

Python for Data Analysis

Python for Data Analysis is concerned with the nuts and bolts of manipulating, processing, cleaning, and crunching data in Python. It is also a practical, modern introduction to scientific computing in Python, tailored for data-intensive applications.

Agile Data Science

Agile Data Science

With this hands-on book, you’ll learn a flexible toolset and methodology for building effective analytics applications with Hadoop.

Para Data Engineer

Test-Driven Machine Learning

Test-Driven Machine Learning

Este libro trata el testeo de software desde otra perspectiva, además de enseñarte qué es el TDD (Test-Driven Development), te enseña a aplicarlo enfocándolo a problemas de Machine Learning. Enfocar los problemas de Machine Learning desde este punto de vista te ayudará a crear modelos más robustos y comparar distinas técnicas de una forma sencilla y modular.

The Second Machine Age

The Second Machine Age

A fundamentally optimistic book, The Second Machine Age will alter how we think about issues of technological, societal, and economic progress.

The Human Face of Big Data

The Human Face of Big Data

The images and stories captured in The Human Face of Big Data are the result of an extraordinary artistic, technical and logistical juggling act aimed at capturing the human face of the Big Data Revolution. Big Data is defined as the real time collection, analyses and visualisation of vast amounts of the information.

Data Smart: Using Data Science to Transform Information into Insight

Data Smart: Using Data Science to Transform Information into Insight

Data Science gets thrown around in the press like it's magic. Major retailers are predicting everything from when their customers are pregnant to when they want a new pair of Chuck Taylors.

Dataclysm: Who We Are (When We Think No One's Looking)

Dataclysm: Who We Are (When We Think No One's Looking)

Our personal data has been used to spy on us, hire and fire us, and sell us stuff we don’t need. In Dataclysm, Christian Rudder uses it to show us who we truly are.

Sobre Big Data

Hadoop For Dummies

Hadoop For Dummies

Let Hadoop For Dummies help harness the power of your data and rein in the information overload Big data has become big business, and companies and organizations of all sizes are struggling to find ways to retrieve valuable information from their massive data sets with becoming overwhelmed.

Hadoop: The Definitive Guide

Hadoop: The Definitive Guide

Ready to unlock the power of your data? With this comprehensive guide, you’ll learn how to build and maintain reliable, scalable, distributed systems with Apache Hadoop.

Hadoop Operations

Hadoop Operations

If you've been asked to maintain large and complex Hadoop clusters, this book is a must. Demand for operations-specific material has skyrocketed now that Hadoop is becoming the de facto standard for truly large-scale data processing in the data center.

Professional Hadoop Solutions

Professional Hadoop Solutions

Today's enterprise architects need to understand how the Hadoop frameworks and APIs fit together, and how they can be integrated to deliver real-world solutions. This book is a practical, detailed guide to building and implementing those solutions, with code-level instruction in the popular Wrox tradition.

MapReduce Design Patterns: Building Effective Algorithms and Analytics for Hadoop and Other Systems

MapReduce Design Patterns: Building Effective Algorithms and Analytics for Hadoop and Other Systems

Until now, design patterns for the MapReduce framework have been scattered among various research papers, blogs, and books. This handy guide brings together a unique collection of valuable MapReduce patterns that will save you time and effort regardless of the domain, language, or development framework you're using.

Learning Spark: Lightning-Fast Big Data Analysis

Learning Spark: Lightning-Fast Big Data Analysis

Data in all domains is getting bigger. How can you work with it efficiently? Recently updated for Spark 1.3, this book introduces Apache Spark, the open source cluster computing system that makes data analytics fast to write and fast to run.

Advanced Analytics with Spark: Patterns for Learning from Data at Scale

Advanced Analytics with Spark: Patterns for Learning from Data at Scale

In this practical book, four Cloudera data scientists present a set of self-contained patterns for performing large-scale data analysis with Spark. The authors bring Spark, statistical methods, and real-world data sets together to teach you how to approach analytics problems by example.

Más libros

Si te interesan los libros geek, visita nuestra recopilación 16 Libros de No-Ficción que todo Geek debería leer

Referencias

¿Qué es Webpack y para qué podemos utilizarlo?

06/10/2017
Artículo original

Logo de Webpack

Webpack nació a finales de 2012 de la mano de un solo desarrollador (Tobias Koppers, alemán), y en la actualidad es utilizado por miles de proyectos de desarrollo web Front-End: desde frameworks como React o Angular hasta en el desarrollo de aplicaciones tan conocidas como Twitter, Instagram, PayPal o la versión web de Whatsapp.

Webpack se define como un empaquetador de módulos (un bundler en la jerga habitual) pero que hace muchísimas cosas más:

  • Gestión de dependencias
  • Ejecución de tareas
  • Conversión de formatos
  • Servidor de desarrollo
  • Carga y uso de módulos de todo tipo (AMD, CommonJS o ES2015)
  • ...

Y esto esto último lo que hace que destaque en especial. Es una herramienta extremadamente útil cuando desarrollas aplicaciones web diseñadas con filosofía modular, es decir, separando el código en módulos que luego se utilizan como dependencias en otros módulos. Una de las cosas que hace realmente bien Webpack es la gestión de esos módulos y de sus dependencias, pero también puede usarse para cuestiones como concatenación de código, minimización y ofuscación, verificación de buenas prácticas (linting), carga bajo demanda de módulos, etc...

Una de las muchas cosas interesantes de Webpack es que no solo el código JavaScript se considera un módulo. Las hojas de estilo, las páginas HTML e incluso las imágenes se pueden utilizar también como tales, lo cual da un extra de potencia muy interesante.

Webpack es una herramienta de compilación (una build tool en la jerga) que coloca en un grafo de dependencias a todos los elementos que forman parte de tu proyecto de desarrollo: código JavaScript, HTML, CSS, plantillas, imágenes, fuentes... Esta idea central es la que lo convierte en una herramienta tan poderosa.

Webpack se puede considerar como un Task Runner muy especializado en el procesamiento de unos archivos de entrada para convertirlos en otros archivos de salida, para lo cual utiliza unos componentes que se denominan loaders.

Imagen conceptual de Webpack obtenida de la portada de su web

Lo habitual es utilizar un archivo de código especial llamado webpack.config.js que está en la raíz de tu proyecto de desarrollo y que define mediante código JavaScript las operaciones que quieres realizar. En este archivo defines toda la información necesaria para poder utilizar Webpack para tus propósitos.

Generalmente las herramientas como Webpack (la más conocida: Browserify) se han utilizado en combinación con gestores de dependencias y task runners. Pero Webpack es tan potente que ya puede efectuar de serie, sin necesidad de nada más, casi cualquier tarea que puedas necesitar para tu desarrollo. En la actualidad está desplazando poco a poco el uso de otras herramientas.

Por ejemplo, no solo tiene soporte de serie para minimizar o combinar archivos, generar mapas de depuración o copiar recursos, sino que incluso ofrece un servidor web integrado con la capacidad de recarga automática cuando algo cambia o reemplazo en caliente de módulos. Las pocas cosas para las que no tiene soporte directo o a través de loaders o plugins se pueden conseguir con el uso de scripts npm, al fin y al cabo la herramienta está basada en Node.js y necesita npm para instalarse.

El mayor problema que ha tenido Webpack desde siempre es que la configuración es un tanto complicada, al menos al principio, lo que hace que tardes un poco en tenerlo funcionando para tu proyecto. Aunque en los últimos tiempos están haciendo lo posible para mejorar esto gracias a añadir funcionalidad en la interfaz de línea de comandos para partir de plantillas ya pre-configuradas.

Ventajas e inconvenientes de usar Webpack

El concepto del grafo de dependencias de Webpack es muy poderoso y ofrece muchísimos beneficios, como por ejemplo:

  • Eliminación de recursos no utilizados: permite de manera sencilla obtener para producción únicamente aquellos recursos que son necesarios, dejando de lado los que no se utilizan. Esto incluye, por ejemplo, las reglas CSS que de verdad se están utilizando, dejando fuera las demás, lo cual es una utilidad muy potente.
  • Control absoluto sobre cómo procesas los recursos: para tomar decisiones avanzadas como que lleven un hash al final de su nombre en cada despliegue para que no queden "atrapados" en ninguna caché o que las imágenes pequeñas se incluyan codificadas en Base64 en la página en lugar de descargarse (ahorrando peticiones al servidor). Cosas por el estilo.
  • Te permite utilizar cualquier tipo de sistema de modularización para JavaScript, sea AMD, CommonJS, ES2015 o Angular, sin preocuparte de que el navegador tenga que soportarlo (Browserify, por ejemplo, solo soporta CommonJS, que es el de Node.js).
  • Tienes casi cualquier cosa que puedas necesitar sin recurrir a otras herramientas, por lo que no necesitarás un task runner como Gulp o un gestor de dependencias como Bower.
  • Es muy rápido.
  • Despliegues confiables: utilizando correctamente los conceptos de Webpack no puede darse el caso de que te dejes cosas fuera a la hora de desplegar. Esto en aplicaciones grandes es mucho decir.
  • Aunque al principio te puede costar arrancar con Webpack en el proyecto, una vez que lo hagas ganarás mucha velocidad de desarrollo.

Pero Webpack también tiene inconvenientes:

  • La configuración es bastante compleja y cuesta, sobre todo al principio, aunque están intentando mejorarlo ofreciendo plantillas y validadores intergados.
  • Todo lo que utilices debe ser modular. No solo deberás escribir los archivos JavaScript como módulos, sino que las dependencias de otras bibliotecas de JavaScript de terceros que utilices deben ser modulares también (aunque hoy en día eso no es muy problemático).
  • En proyectos grandes tocar la configuración puede ser complejo.
  • Algunas sintaxis pueden ser algo confusas.
  • La documentación ha sido tradicionalmente mala, difícil de entender y poco clara en algunas cosas, aunque la van mejorando.
  • Si algo falla es difícil de saber qué está pasando, ya que no da mucha información sobre el evento.
  • El código fuente es muy complejo. Esto está relacionado con lo anterior. No es que tengas que ir mucho a ver el código fuente, pero si alguna vez lo necesitas para ver por qué algo falla o cómo funciona una determinada característica, no es lo más fácil de seguir del mundo.

El uso de Webpack puede llegar a ser complejo y, al igual que otras herramientas típicas de desarrollo web Front-End,como gestores de dependencias o task runners, para un proyecto pequeño quizá no tenga mucho sentido usarlo o quizá no aporte grandes beneficios de entrada. Sin embargo, en proyectos de tamaño mediano o grande los beneficios se ven inmediatamente.

Si vas a programar con React es casi obligatorio que utilices Webpack, pues es la herramienta que han adoptado para su desarrollo y la que usa todo el mundo en su comunidad.

Si trabajas en desarrollo web es casi seguro que más pronto que tarde te vayas a encontrar Webpack. Gracias a su potencia y a la enorme comunidad de usuarios que tiene detrás se ha convertido en "la herramienta". Su desarrollo se ha acelerado gracias al apoyo económico de algunas empresas importantes y muchas empresas pequeñas y desarrolladores individuales.

No deberías perderlo de vista y espero que este artículo te ayuda a saber, al menos, de qué va.

Página Siguiente