Es una configuración muy común para los servidores de correo saliente. Sirve, por ejemplo para cuando queremos que los correos que enviemos desde nuestro ordenador se hagan a través de otro servidor SMTP, cuando hemos contratado un servicio externo para enviar correo para nuestra empresa, hacer redirecciones temporales o tener un servidor intermedio a la hora de recibir correos (por ejemplo, si queremos aplicar filtros antes de enviar los correos).

Por eso en el título de la entrada está Gmail. Podemos configurar un pequeño servidor de pruebas, o incluso en nuestra máquina local, para que los correos que se envíen con sendmail, o que nos envíen a nuestra máquina, se hagan a través de nuestra cuenta de Gmail (debemos activar el acceso por SMTP, y tendremos que tener cuidado de escuchar solo en localhost o poner reglas de firewall para que no todo el mundo pueda acceder a nuestro puerto de envío de correo). También están los casos de sendgris y mailgun, servicios que podemos utilizar para enviar correos desde un dominio determinado. Estos servicios están bien si desde nuestro servidor se envía un gran volumen de correo (existen muchos más servicios similares).

La otra opción es enviar un correo a través de nuestro propio servidor. Esto puede ser útil en caso de tener varios servidores de envío. Podemos hacer que varios servidores reciban correo y lo envíen a un servidor central. Si uno de los servidores pequeños ve que el central está muy saturado, puede esperar y entregarlo dentro de un rato. También es muy útil la creación de filtros para una empresa, es decir, la empresa tiene contratado el servicio de envío de correo a través de un proveedor externo, pero nosotros queremos tener algo de control como aplicar filtros, revisar virus, o eliminación de metadatos, o que debamos saber si hablan mal de nosotros, que para eso somos administradores de sistemas, aunque no te diré cómo, pero no es muy difícil.

Iré explicando el proceso desde el principio, por lo que si ya has instalado postfix o tienes cierta experiencia con él, podrás saltarte algunas partes. No profundizaré mucho en la configuración de Postfix porque es un mundo, solo en lo que nos atañe para esta tarea.

Instalación de Postfix

Para estos ejemplos he utilizado un equipo con Ubuntu Server 16.04, por lo que vais a ver cosas como apt para instalar los programas. No será muy diferente a hacer todo esto en una Debian, o cualquier otra distribución basada en Ubuntu o Debian. Puede que para otras distribuciones difiera un poco, pero la idea básica es la misma. Lo primero, es instalar Postfix:

La siguiente pregunta del instalador, es el nombre del host. Éste debe ser un FQDN, vamos un nombre que identifique la máquina y que su DNS resuelva. De forma que si desde otra máquina hacemos ping o telnet, la máquina la encontremos y sea esta máquina a la que estamos accediendo:

El siguiente paso, será especificar el servidor a través del cual vamos a enviar los correos realmente:

En este punto debemos especificar el host y el puerto. Os pongo aquí varios hosts y puertos de algunos servicios comunes:

• Gmail. smtp.gmail.com:25
• Sendgrid. smtp.sendgrid.net:587
• Mandrill. smtp.mandrillapp.com:587
• Sparkpost. smtp.sparkpostmail.com:587
• Mailgun. smtp.mailgun.org:25

O incluso podemos utilizar cualquier otro servidor de correo de otro proveedor (que hay cientos de servicios gratuitos y de pago para esto). Puede que para algunos de los servicios haya que realizar una activación previa del servicio SMTP, o incluso configurar DNS para poder trabajar correctamente.

Por último, debemos revisar, en el fichero /etc/postfix/main.cf que la línea que menciona myhostname tiene nuestro nombre de host de correo (el FQDN que introdujimos en la segunda pantalla).

Configurar servidores SMTP, usuarios y contraseñas

Cualquier servidor hoy en día, debe tener activada la autentificación de usuarios, de modo que no permita que cualquiera envíe correos desde ese servidor. Era muy habitual en el pasado encontrar servidores abiertos desde los que poder enviar cualquier cosa y, tanto en el mundo fantástico y maravilloso de la piruleta, como en el diseño original del sistema de correo debía ser así. El problema es que mucha gente aprovechaba para hacer cosas malas.

El primer acceso que vamos a configurar es el que va desde el servidor de correo Postfix que estamos montando hasta el servidor de correo a través del cual vamos a enviar los mensajes. Para ello creamos el archivo /etc/postfix/sasl_passwd, en realidad, podemos llamarlo como queramos, aunque es una buena idea colocarlo dentro de /etc/postfix. Dentro del archivo incluimos lo siguiente (con los corchetes y todo):

En esta línea incluiremos el nombre del servidor desde el que realmente enviaremos los correos (Gmail, sendgrid, mailgun…), el puerto, y el nombre de usuario y contraseña desde el que enviaremos los correos. Si, por ejemplo, estamos utilizando nuestra dirección de Gmail para enviar correo, solo podremos utilizar como remitente nuestra propia dirección, aunque tienen por ahí una opción para poder utilizar más direcciones de correo de Google de esta forma. Otros servicios permiten, a través de una clave única enviar correos desde cualquier dirección de correo dentro de un dominio o subdominio, deberá ser nuestro Postfix el que determine qué un usuario no pueda enviar correo con el e-mail de otro.

Una vez tenemos /etc/postfix/sasl_passwd creado, vamos a crear una tabla de búsqueda (lookup-table) para Postfix de esta forma:

De esta forma creamos el archivo /etc/postfix/sasl_passwd.db . Lo siguiente será proteger los dos archivos de contraseñas, tanto el que no tiene extensión (que, si queremos lo podemos borrar y no pasa nada, o también custodiarlo en otra máquina o con otro usuario, ya como queramos). Para protegerlo, hacemos que solo root sea capaz de acceder a los archivos:

Aunque, si sois frikis como yo, y no queréis escribir mucho podéis hacer lo siguiente (más info aquí):

Por último, tenemos que configurar nuestro servidor relay editando el archivo /etc/postfix/main.cf , primero añadiendo (o verificando) que el relay host está configurado, es decir, el servidor a través del cual enviamos realmente los correos:

Podemos poner o buscar esta información cerca de myhostname, mydestination, mynetworks.

Ahora, en el mismo archivo, por ejemplo, al final del archivo, podemos poner un comentario y a continuación las siguientes líneas:

Configurar autentificación en nuestro servidor

Nuestro servidor debe identificarse cuando se conecta para mandar correos a través de otra máquina (como vimos, que puede ser Gmail, Sendgrid, Mailgun, etc). Pero claro, puede que queramos que nuestros usuarios también se identifiquen en nuestro servidor cuando se conecten. De esta forma, cualquier persona no podrá enviar e-mails. Es algo que no es fundamental, pero sí recomendado si no queremos que nuestro servidor se transforme en una máquina zombie que envíe correos sin piedad, lo que puede desembocar en que el servidor de envío a través del cual mandamos los mensajes nos termine desactivando el usuario y, si el dominio es nuestro, éste pierda reputación y nos resulte tremendamente difícil que el mundo no se crea que enviamos SPAM.

Para configurar esta seguridad, vamos a crear una pequeña base de datos local con los usuarios permitidos. Seguro que si tenemos miles de usuarios deberíamos tener métodos de autentificación más grandes y distribuidos, pero, por experiencia en la mayoría de los casos, utilizando SASL, como antes, va muy bien.

Instalaremos algunas utilidades, si no las tenemos ya:

Ahora, debemos asegurarnos de que el demonio saslauthd se ejecuta automáticamente al iniciar el sistema. Para ello, editaremos /etc/default/saslauthd y nos aseguremos de que la línea que comienza por START y por MECHANISM se mantiene así:

Tras ello, reiniciaremos el demonio:

Ahora debemos configurar de nuevo algunas cosas en /etc/postfix/main.cf:

Tras esto, debemos crear (o editar) el archivo /etc/postfix/sasl/smtpd.conf donde especificaremos el tipo de autentificación permitida a la hora de conectarnos e intentar enviar correo a través de Postfix. Dejaremos las siguientes líneas:

Por supuesto, podríamos (y deberíamos) eliminar PLAIN sobre todo, para que nadie pueda identificarse con contraseñas en texto plano. Aunque, la práctica me dice que a veces puede que necesitemos activarlo temporalmente. De hecho, es problema de los usuarios si utilizan PLAIN para identificarse, los clientes de correo siempre intentan identificarse con el método más seguro disponible.

Tras todo esto, reiniciamos Postfix:

Por último, podemos tener un pequeño problema a la hora de identificar usuarios, y es que, Postfix, muchas veces está configurado con un chroot o una jaula. Eso quiere decir que postfix será incapaz de ver archivos fuera de su jaula, como por ejemplo, el socket de identificación de saslauthd, por lo tanto, no podrá identificar correctamente a los usuarios. Para ello, solo tenemos que introducir el directorio /var/run/saslauthd dentro de la jaula, de esta forma:

Manejo de usuarios

Si queremos crear o cambiar la contraseña de los usuarios del sistema deberíamos hacer:

O también

Para eliminar un usuario podremos utilizar -d en lugar de -c y para listar todos los usuarios del sistema tenemos el comando:

Restringir dispositivos de red

Esto depende de dónde se van a enviar los mensajes. Por seguridad es una buena opción restringir los interfaces de red permitidos para cada servicio que instalamos en nuestros servidores, haciendo que los servicios solo escuchen en aquellos dispositivos para los que estén ofreciendo servicio. Así que, en Postfix también podemos decidir esto. En /etc/postfix/main.cf debemos configurar:

Con esta configuración estaremos escuchando en todos los dispositivos de red que tenga la máquina. Si lo hacemos así, debemos restringir el acceso a puertos (si queremos) a otros usuarios. Podríamos utilizar, en lugar de all, la opción loopback-only si solo escuchamos en localhost. Esto puede ser útil si tenemos un servicio web instalado en este servidor que necesite enviar correos. También podemos poner las direcciones IP o nombres de host desde los que escuchamos separados por comas (si son varios).

Si cambiamos algo aquí tendremos que reiniciar el servidor postfix.

Enviando un mensaje

Es momento de enviar un mensaje de prueba. Tenemos muchas opciones. Podemos utilizar sendmail de la siguiente forma:

Tras ello, podemos pulsar Control+D y terminaremos de escribir el mensaje. Supuestamente debe haberse enviado si todo está correcto.

También podemos tirar de funciones de varios lenguajes de programación como mail() para PHP. O de scripts como gemail.sh con el que se podrán enviar archivos adjuntos de forma fácil. Por supuesto, también podemos configurar nuestro cliente de correo favorito para enviarlos.

Logs y depuración

Y, como todo en este mundo informático puede fallar, es importante tener a mano los logs. En estos logs podremos ver mensajes que nos dirán qué está pasando en cada momento. Tendremos dos /var/log/mail.log que nos dirá qué está pasando con cada mensaje, IDs de correos, mensajes que entran en cola o no, errores al mandar un mensaje a otro servidor o al recibirlo, etc. También podemos encontrar errores en /var/log/mail.err sobre todo en lo relativo a fallos en el demonio, conexiones que no se han podido establecer o intentos de hacer cosas raras como por ejemplo poner muchas líneas de encabezados en un mensaje (podemos tener 20, 30 líneas, pero cuando alguien intenta meter 100 o 200 líneas, puede que esté intentando hacer algo malo, o que no esté enviando bien el mensaje).

Foto principal: Designed by Freepik

The post Configurar Postfix para enviar correo a través de otro servidor SMTP [Gmail, sendgrid, mailgun y más] appeared first on Poesía Binaria.

publicclass RedirectionTestController: Controller
{
public IActionResult Temporal() 
    {
// Returns HTTP 302 pointing to /redirectiontest/ok
return RedirectToAction("Ok"); 
    }

public IActionResult Ok()
    {
return Content("Ok!");
    }
}

• El método Redirect() permite generar redirecciones hacia URL arbitrarias.
• RedirectToAction() nos permitirá generar redirecciones hacia controladores/acciones de nuestra aplicación.
• RedirectToRoute() generará redirecciones partiendo de los parámetros de ruta especificados.
• RedirectToPage() genera redirecciones hacia páginas Razor.
• LocalRedirect() permite generar redirecciones hacia recursos locales, pertenecientes al mismo sitio web.

publicclass RedirectionTestController: Controller
{
    ...
public IActionResult Permanent() 
    {
// Returns a permanent redirection (HTTP 301) to /redirectiontest/ok
return RedirectToActionPermanent("Ok");
    }    
}

public IActionResult TemporalPreserve() 
{
// HTTP 307, temporal redirect preserving method
return RedirectToActionPreserveMethod("Ok");
}  
public IActionResult PermanentPreserve() 
{
// HTTP 308, permanent redirect preserving method
return RedirectToActionPermanentPreserveMethod("Ok"); // 
}  

Hey, ¿y los métodos y clases para generar redirecciones HTTP 303?

Con la clase Optional añadida en el JDK en la versión 8 del lenguaje Java se puede evitar una de las excepciones más comunes que se produce cuando se hace uso de una referencia nula a un objeto.

Una de las excepciones que más se producen en un programa hecho con el lenguaje Java es la conocida NullPointerExpcetion que ocurre cuando se hace uso de una variable que referencia a un objeto pero que el contenido de la variable es null, sin valor o sin contener una referencia a un objeto de modo que la llamada al método no es posible. La excepción NullPointerException extiende de RuntimeException por lo que es una unchecked exception y por ello no es necesario capturarla o lanzarla, cuando se produce hay un error en el programa.

Entre las novedades que Java 8 incluyó en el lenguaje y JDK está la inclusión de la clase Optional con la que haciendo uso de ella se pueden evitar los NullPointerException. Un objeto de tipo Optional contiene o no una referencia a otro tipo de objeto. Por ejemplo, una variable de tipo Optional<String> contiene una referencia a un objeto Optional que a su vez contiene o no una referencia a una cadena String. El uso de la variable Optional no producirá un NullPointerException y con sus métodos es posible saber si contiene o no una referencia al tipo usado en el genérico. Con el método isPresent() es posible saber si el Optional contiene una referencia, con orElse() y orElseGet() se obtiene la referencia que indiquemos en caso de que no tenga una referencia y con los métodos estáticos a modo de constructores of() y ofNullable() se obtiene respectivamente una instancia de Optional con la referencia indicada que no puede ser nula o un Optional que podría contener una referencia nula.

Usar un objeto Optional advierte al programador de que la referencia que contiene puede ser nula y usada correctamente evita los NullPointerException aunque usarla indiscriminadamente hace del código más incómodo de escribir y leer, en variables locales es prescindible su uso pero útil en algunos valores de retorno o parámetros de métodos.

Hay algunos métodos más en la clase Optional con algunas funcionalidades adicionales que hace uso de las nuevas capacidades funcionales del lenguaje como convertir un Optional a un Stream.

De todas formas no debería sorprendernos el uso de scrum en la manufactura industrial. Fue allí donde surgió ;-)

El símbolo de sistema o prompt de la terminal es el símbolo del sistema que precede al comando que introducimos en la terminal y por defecto indica el directorio de trabajo que utilizarán los comandos y el directorio que utilizarán las rutas relativas. El prompt del intérprete de comandos Bash se puede personalizar para por ejemplo modificar el color de su texto y la información que incluye con las preferencias del usuario.

El prompt se configura con la variable de entorno PS1 que en bash está en el directorio personal y el archivo .bashrc. Los colores se especifican con una secuencia de caracteres y números y la información a mostrar se especifica usando caracteres de escape seguidos de diferentes letras. Como conocer las secuencias de caracteres con los códigos de escape ANSI para los colores y letras para la información es complicado de escribir o conocer al detalle en la web Bash $PS1 Generator hay un asistente que facilita el crear un prompt a nuestro gusto correcto.

El siguiente es el que utilizo en mi sistema con colores, el nombre del usuario, el nombre sistema y el directorio de trabajo actual.

Prompt de la terminal personalizado

Según se edita el prompt el asistente previsualiza como queda en la sección Preview, una vez que el prompt es el que deseamos en la sección Result el asistente ofrece el contenido de la variable de entorno PS1 que hay que añadir o cambiar en el archivo ~/.bashrc.

Si quieres mostrar alguna información que sea el resultado de algún comando también se puede añadir al prompt. Por ejemplo, supón que se desea añadir la hora del sistema al prompt, esta información la devuelve el comando date. El siguiente script de bash usando el comando date proporciona la información a añadir.

Ahora hay que incluir esta información en el prompt de la siguiente forma.

Prompt de la terminal personalizado con el resultado de un comando

Una caso habitual es añadir la rama de git del directorio actual de trabajo y si esta tiene cambios como comento en Prompt de la terminal personalizado en carpetas de git con el intérprete Bash. El script necesario que proporciona Git no es más complejo que el caso anterior pero con la misma finalidad, el script está en git-prompt.sh y requiere modificar la variable de entorno PS1 o bien PROMPT_COMMAND.

Prompt de la terminal personalizado en carpeta de git

.NET / .NET Core

• C# Debug vs. Release Builds and Debugging in Visual Studio – from Novice to Expert in One Blog Article
  Ben Hall
• First steps with nullable reference types
  Jon Skeet
• Adding Resilience and Transient Fault handling to your .NET Core HttpClient with Polly
  Scott Hanselman
• Don’t Use Enumerables as Numbers
  Peter Vogel
• LINQ Part 4: A Deep Dive Into a Queryable Extension Method
  Eric Lynch
• Saber qué versiones de .NET Core y de SDK .NET Core tenemos instaladas
  Jorge Serrano
• Inferred tuple names in C# 7.1
  gunnar Peipman
• Setting up .NET Core Configuration Providers
  Randy Patterson

ASP.NET / ASP.NET Core

• HttpClientFactory for typed HttpClient instances in ASP.NET Core 2.1
  Scott Hanselman
• Comma-separated parameter values in WebAPI
  Damien Guard
• Optimising ASP.NET Core apps in Docker - avoiding manually copying csproj files (Part 2)
  Andrew Lock
• HttpClientFactory in ASP.NET Core 2.1 (Part 3)
  Steve Gordon
• BlazeDown: An Experiment with Markdown and Blazor
  Ed Charbeneau
• Blazor, Razor, WebAssembly, and Mono. How the pieces fit together
  Dave Glick
• ASP.NET Core Authorization – Using attributes for handlers and requirements
  Ibrahim Šuta
• API Versioning in .Net Core
  Neel Bhatt
• Using subdomain based pipeline branching for static files delivery optimization in ASP.NET Core
  Tomasz Pęczek
• Adding Cross-Cutting Memory Caching to an HttpClientFactory in ASP.NET Core with Polly
  Scott Hanselman

Azure / Cloud

• Utilizando Microsoft.Recognizers para reconocer y resolver números, unidades y fecha / hora; en múltiples idiomas
  Bruno Capuano
• Azure Container Instances now generally available
  Corey Sanders
• Cross-database query performance in Azure SQL Database
  Fikrat Azizov
• Azure Load Balancing Solutions: A guide to help you choose the correct option
  Fidelis Ekezue
• Azure SQL Database – scalability
  Jovan Popovic
• Cosmos DB Solves Common Data Challenges in App Development
  Jasmine Greenaway
• Por qué todo lo que subo a azure está mal
  Fernando Escolar

Conceptos / Patrones / Buenas prácticas

• How to break a Monolith into Microservices
  Zhamak Dehghani
• Should I Add Caching to my Web Application?
  Steve Smith

Data

• SQL: Does having more indexes always make data modifications slower?
  Greg Low
• SQL Server 2016 Service Pack 2 is now available
  SQL Server Team
• Lo mínimo a entender sobre transacciones
  Juan María Hernández

HTML / CSS / Javascript

• Native-Like Animations for Page Transitions on the Web
  Sarah Drasner
• Truly understanding Async/Await
  Rafael Vidaurre
• HTML5’s Global hidden Attribute
  Louis Lazaris
• How to Remove Elements From A JavaScript Array
  Chris Love
• Understanding React setState
  Kingsley Silas
• Anidación de selectores en Sass
  Miguel Ángel Álvarez
• Bootstrap 4: Layout Classes
  Dino Esposito
• Measuring Websites With Mobile-First Optimization Tools
  Jon Raasch

Visual Studio / Complementos / Herramientas

• Preventing Security Warning Dialog Box for Projects in Visual Studio
  Abhijit Jana
• Navigation improvements in ReSharper 2018.1
  Chris Woodruff
• Visual Studio extensibility samples
  Mads Kristensen
• Visual Studio 2017 roadmap now available
  John Montgomery
• Expand Selection command in Visual Studio 2017
  Abhijit Jana
• VS Code can do that?!
  Burke Holland & Sarah Drasner
• Introducing the Microsoft Edge DevTools Preview app
  Jacob Rossi
• Visual Studio Tip: Prompt before moving files to a new location in Solution Explorer
  Abhijit Jana ]

Otros

• 5 Ways to Increase Productivity in Cross-Functional Dev Teams
  Facundo Gauna
• Las 7 razones para aprender SQL que quizá nunca te habías parado a pensar
  CampusMVP

Cuántas veces has recordado haber escrito un documento y no recuerdas dónde lo pusiste. Tienes cientos de archivos de documentos en tu disco duro, o en un servidor y no sabes por dónde empezar a buscar. Con ficheros de texto, podemos utilizar find, grep, egrep, sed y algunos comandos más que, combinados podrán darnos los resultados que buscamos. Aunque los archivos de documentos son algo más complejos internamente.

Ficheros de documentos

Tanto los ficheros de OpenOffice/LibreOffice como los documentos de Microsoft Word Open XML (esos archivos docx que se crean a partir de Microsoft Office 2007. En este post no podremos buscar documentos generados con versiones más antiguas del programa) son en realidad archivos ZIP con muchos archivos XML en su interior en los que se definen contenido, estilos y metadatos. Para los archivos odt, de LibreOffice y OpenOffice, el archivos que contiene los contenidos del documento es content.xml y en Microsoft Word, el archivo está situado en word/document.xml, así que, vamos a intentar, buscar todos los archivos de documentos que haya en una ruta del disco y examinar su contenido para buscar las palabras que necesitamos encontrar. Para ello tendremos que descomprimir el documento y extraer el archivo del documento. Todo de forma automática.

Es cierto que actualmente tenemos programas de búsqueda en escritorio, que examinan periódicamente archivos en varios formatos, procesan dicha información y agilizan la muestra de resultados. Aunque en muchos casos, para acelerar el uso normal del ordenador, muchos los solemos tener desactivados. O, por ejemplo, si tienes los contenidos en un ordenador remoto, una Raspberry PI, o un VPS, puede resultar un poco más complicado hacer dichas búsquedas.

Afortunadamente GNU/Linux nos proporciona herramientas muy buenas para realizar nuestras tareas. Primero ejecutaremos find para obtener todos los archivos de documento a partir de la ruta actual. Aunque podríamos utilizar find con otros parámetros o incluso utilizar locate. Para ello, podemos utilizar estos scripts de una línea, también llamados one-liners.

Documentos de LibreOffice/OpenOffice

Empezaremos con los documentos odt de LibreOffice u OpenOffice. Para ello extraeremos el archivo word/document.xml del archivo de documento y a partir de ahí realizaremos una búsqueda.

De esta forma, find, va pasando archivos odt al resto de la línea. Podríamos hacer fácilmente que no sean todos los archivos, si nos acordamos de parte del nombre podríamos hacer ‘*informe*.odt’ para seleccionar todos los docuentos que contentan la palabra informe y tengan extensión odt; o incluso utilizar -iname en lugar de -name para indicar que busque nombres de archivo en mayúsculas y minúsculas indistintamente. También, con find podríamos seleccionar incluso los archivos por tamaño o por fecha.

En lugar de find -name ‘*.odt’ podríamos utilizar locate ‘*.odt’ para buscar en todo el disco, o en un patrón de directorios determinado. La ventaja de locate es su gran velocidad, aunque primero tendremos que crear una base de datos de archivos del disco (con updatedb) y eso puede tardar un poco.

Una vez tenemos los nombres de archivo que cumplen el patrón, cogemos cada nombre de archivo y ejecutamos unzip -p [archivo] content.xml. La opción -p sirve para extraer el contenido de los archivos directamente a la salida estándar de la aplicación. Si ejecutamos este comando individualmente, veríamos todos los contenidos del fichero en pantalla, vamos, extrae todo a pantalla, en lugar de crear un archivo llamado content.xml. La ventaja de esto es que no necesitamos archivos temporales y todo es mucho más rápido.

La salida de unzip, es decir, el contenido del fichero comprimido, se lo pasamos a grep. En este caso, grep -li “TEXTO” > /dev/null. Con -l, hacemos que grep muestre solo los nombres de archivo donde exista coincidencia, así sólo es necesario que el texto se encuentre una vez en el archivo para que grep finalice la ejecución y devuelva un positivo. Lo malo es que si el texto no está en el archivo tendrá que analizarlo completamente. El argumento -i hace que no importen las mayúsculas y minúsculas, por lo que, aunque en el documento encontremos “CaCaHueTe”, podremos decir que grep busque “cacahuete” y lo va a encontrar sin problema. Por último, la salida de grep la redirigimos a /dev/null para que realmente no muestre nada en pantalla. ¿Por qué?

Lo que en realidad analizaremos de grep será el estado de salida del programa. Es decir, internamente, si grep acaba y el archivo que ha analizado contiene el texto que buscamos, devolverá un 0 (normalmente, cuando un programa finaliza bien devuelve un 0 y cuando no, devuelve otra cosa). Entonces, sólo si grep devuelve 0 mostraremos el nombre del archivo en pantalla. Para eso if [ $? -eq 0 ]; then echo $file; fi;.

Documentos de Microsoft Word

Para hacer lo mismo con los documentos de Microsoft Word debemos cambiar el archivo que analizamos. En este caso, analizaremos word/document.xml. Y mantendremos todo el comando igual:

Mejorar la búsqueda

Los ficheros que estamos analizando, en realidad son XML, por lo que, junto con el contenido encontramos algunos datos que nos indicarán estilos, objetos empotrados, notas, y demás cosas. Todo esto puede hacer que cuando busquemos algún contenido concreto no lo encontremos. Para mejorar la búsqueda, aunque penalizaremos un poco el tiempo que tardará el script, sobre todo en archivos muy grandes. La clave está en eliminar las etiquetas XML que encontramos en el archivo de contenidos. Un claro ejemplo, podemos verlo si analizamos un fichero HTML. Cuando vemos:

Hola Mundo

En realidad, el código utilizado para el texto es este:

Y si realizamos una búsqueda en texto con grep, por ejemplo, buscando la palabra “Hola”. Grep no encontrará nada. Así que, pasaremos el texto por un filtro que eliminará estas etiquetas, con sed. Uno de los usos de este comando es reemplazar cadenas a través de expresiones regulares, pero aunque suene complicado, os la voy a dar preparada. Para ver un ejemplo rápido, vamos a hacer lo siguiente:

Creando el script completo

En definitiva, para buscar archivos de LibreOffice / OpenOffice, esos con extensión ODT:

Y para buscar archivos Office Open XML de Microsoft Word, esos con extensión DOCX:

Foto principal: Dmitry Ratushny

The post Píldora: Cómo buscar un texto dentro de documentos múltiples ODT de Libreoffice/Openoffice o docx de Microsoft Word appeared first on Poesía Binaria.

Y llegó un día diferente a cualquier otro, cuando los héroes más poderosos de la sociedad civil uruguaya se unieron contra una amenaza común. Ese día nació DATA. Para luchar contra los datos impuros y falta de transparencia que ningún ciudadano de a pié sólo podría combatir.

DATA es un grupo de rebeldes aglomerado bajo una organización de la sociedad civil fundada en abril de 2012 que trabaja en temas de gobierno abierto, datos abiertos, acceso a la información pública y participación a través del uso de tecnología cívica. Hoy 30 de abril de 2018 se cumplen nada menos que 6 años de su nacimiento. Pensar que hace poquitofestejábamos el primer año. ¡Feliz cumpleaños DATA!

Como parte de la celebración, DATA publicó una nueva edición de su boletín para ver en qué andan. Copio y pego la información a continuación:

DATA NOTICIAS
¿Qué hay de nuevo?

¡Hola! Les damos la bienvenida a nuestro boletín de noticias.

Para empezar queremos contarles que hoy lunes 30 de abril, Data Uruguay cumple 6 años , y nos pareció que era una buena oportunidad para retomar nuestros boletines.

El 2017 fue un año de mucho trabajo y de muchos proyectos. Un año para seguir conociendo gente increíble que comparte las mismas locuras en distintas partes del mundo y para seguir consolidando la organización.

Queremos compartir con ustedes esta publicación donde están algunos de los principales hitos del año pasado, los proyectos que lanzamos, los eventos que organizamos, acompañamos y asistimos y algunas noticias que nos alegraron, tanto propias como en colaboración con organizaciones amigas.
VER MÁS

¿EN QUÉ ANDAMOS?
Nuestros nuevos proyectos

4˚ Plan de Acción Nacional de Gobierno Abierto

2018 es el año de co-creación del 4º Plan de Acción Nacional de Gobierno Abierto y en el marco de ese proceso, por primera vez está disponible una herramienta web donde cualquier persona u organización puede hacer propuestas para el plan. En Data Uruguay trabajamos activamente en este proceso, como una de las organizaciones representantes de la Red de Gobierno Abierto.

Te invitamos a visitar la web, conocer las propuestas planteadas para el nuevo plan de acción y/o proponer las tuyas. Si te interesa esta temática, también podés mantenerte al tanto siguiendo a la RGA en facebook y twitter.

Trabajando en la promoción de derechos

Desde hace algunos meses estamos trabajando con la Dirección Nacional de Promoción Sociocultural (DNPSC) del MIDES para lanzar una herramienta que sirva para trabajar en los Centros Promotores de Derechos. Estos surgen con la intención de fortalecer y generar más y nuevas prácticas en promoción de derechos en centros educativos, abordando diferentes ejes temáticos: género, diversidad sexual, étnico-racial, salud adolescente, discapacidad, pertenencias, convivencia e itinerarios socioeducativos.

Esta plataforma, co-creada por MIDES y DATA Uruguay, permitirá contar con una herramienta virtual que incluya contenidos teóricos, videos para jóvenes y adultos/as, orientaciones metodológicas, dinámicas lúdicas y recursos  audiovisuales para la promoción de derechos.

Próximamente los/as estaremos invitando al lanzamiento

LO QUE SE VIENE
Próximas actividades y eventos

7 de MAYO.Compromisotón

En el marco de la Open Gov Week, desde la Red de Gobierno Abierto (red de la que DATA Uruguay forma parte) estamos organizando un “Compromisotón” para sumar insumos al proceso de de co-creación del 4º Plan de Acción Nacional de Gobierno Abierto.

Te esperamos el lunes 7 de mayo a las 18:30 hs. en Enlace (Av. Agraciada 2332).

¡Sumate al evento y al Meetup!

23 AGO.ABRE LATAM e IODC

El 27 y 28 de setiembre de 2018 se realizará en Buenos Aires la Conferencia Internacional de Datos Abiertos (IODC18 por sus siglas en inglés).

Este año Abrelatam, el ya clásico evento regional sobre Datos Abiertos, también será allí así que te invitamos a registrarte, hacer las valijas y acompañarnos

VER MÁS

EL MUNDO DE LOS DATOS ABIERTOS

Proyecto Educación

El año pasado recibimos la maravillosa noticia de que uno de nuestros proyectos había quedado seleccionado para formar parte de la primera generación Altec, un fondo de Omidyar Network y Avina.

Desde entonces estamos trabajando en el “Proyecto Educación” (este es nombre de trabajo, todavía no fue bautizado) junto a nuestros socios, el Centro de Educación Secundaria y Unicef.

La idea del proyecto es realizar un plataforma para visualizar datos de todos los liceos públicos del país. La herramienta será co-creada junto a los/as docentes, estudiantes y otros grupos de personas involucradas con la educación. ¡En los próximos meses se vienen novedades!

Novedades sobre ¿Dónde Reciclo?

¿Dónde Reciclo? fue una de las primeras herramientas que lanzamos desde Data Uruguay, allá por el 2013. El año pasado nos asociamos con Cempre y relanzamos la plataforma, mejorando el diseño, desarrollando app para iOS y Android y mejorando aspectos de los datos y la usabilidad.

Actualmente estamos empezando a trabajar en una nueva versión, con algunas mejoras, ¡así que estén atentos!

Por Mi Barrio en el interior

Desde que empezamos a trabajar con la plataforma Por Mi Barrio (PMB) había algo que queríamos hacer pero no habíamos tenido oportunidad: trabajar en todo el Uruguay, no sólo en la capital. Con ese foco estuvimos trabajando para replicar PMB en Rivera y felizmente la plataforma ya está en marcha (agradecemos a la Intendencia de Rivera, a Avina y a la CAF por todos los esfuerzos).

Hoy nos alegra mucho anunciar que gracias a un fondo de la ANII, PMB también estará funcionando en Río Negro, ya estamos trabajando con la Intendencia de ese Departamento para que suceda. En los próximos meses les estaremos contando novedades

¿Tenés ganas de ser voluntario? ¡SUMATE!
Escribinos

• DATA en Twitter
• DATA en Facebook
• DATA en Instagram
• DATA en YouTube
• DATA: Sitio oficial

Con frecuencia leo textos técnicos, mayoritariamente escritos por latinoamericanos que, quizás por la influencia del inglés son ciertamente incorrectos en ese contexto. Un poco como ya viéramos con Vectores, matrices, registros y otras hierbas, pero esta vez constatados sobre el DRAE (Diccionario de la Real Academia de la lengua Española). La importancia de usar las […]

Artículo publicado originalmente en Bitácora de Javier Gutiérrez Chamorro (Guti)

La entrada Remover, resumir y otros términos aparece primero en Bitácora de Javier Gutiérrez Chamorro (Guti).

Apache Tapestry es uno de los mejores frameworks web para Java que he usado, sin embargo, también tiene algún incordio o curiosidad. Una de ellas es que las plantillas han de ser XML bien formado y en este caso que comento en el que necesitaríamos una plantilla con etiquetas desbalanceadas nos obliga a buscar una solución, esta es la que uso.

Las plantillas en Apache Tapestry son XHTML, esto quere decir que al ser archivos xml han de estar bien formados con sus etiquetas bien balanceadas y anidadas. Esto tiene la ventaja de que Tapestry nos avisará cuando se intente generar código HTML mal formado con el contenido de plantilla, una especie de compilación que si no es correcta no pasará desapercibida como en otros frameworks y que puede generar otro tipo de errores. Sin embargo, también tiene una desventaja y es que si necesitamos generar una etiqueta de inicio dentro de un componente if la plantilla no será válida.

Supongamos que queremos generar un contenido a tres columnas de una serie de elementos, en cada tercer elemento de la fila tendremos que cerrar la fila anterior y abrir una nueva. El ejemplo de lo que no se puede hacer es el siguiente:

En este ejemplo las etiquetas div de apertura y cierre hacen que el XML de la plantilla no esté bien balanceado. No se si habrá otra forma mejor pero esta es el rodeo que uso para tener una plantilla bien balanceada y generar el contenido HTML necesario. En el código Java del componente creo un método que devuelve un mapa de trozos de HTML que no podría incluir en la propia plantilla, cada trozo de HTML tiene una clave asociada por la que identificarlo, en este caso open y close.

Usando estos métodos en la plantilla el código de la plantilla tml ya bien formado quedaría de la siguiente manera, usando el componente OutputRaw se emite el trozo HTML de apertura o cierre:

Esta pequeña «ñapa» que no es muy habitual en las plantillas pero que en algún caso puede ser necesario emplear es una forma de hacer las plantillas tml bien formadas en circunstancias donde incluyéndolo en la plantilla no lo sería.

Prefiero que Tapestry me valide que el XML de la plantilla esté bien formado evitando que se pudiera generar HTML con etiquetas no balanceadas y me obligue a hacer este rodeo que la posibilidad de generar HTML con etiquetas mal balanceadas que los navegadores aceptan pero que en algún caso podría provocar una desmaquetación, aunque en los casos que se aplique esta solución hay que tener especial cuidado ya que como no se realiza ninguna validación al emitir etiquetas de forma «cruda» el HTML generado podría estar mal balanceado.

Libro PlugIn Tapestry

Si te interesa Apache Tapestry descarga gratis el libro de más de 300 páginas que he escrito sobre este framework en el formato que prefieras, PlugIn Tapestry: Desarrollo de aplicaciones y páginas web con Apache Tapestry, y el código de ejemplo asociado. En el libro comento detalladamente muchos aspectos que son necesarios en una aplicación web como persistencia, pruebas unitarias y de integración, inicio rápido, seguridad, formularios, internacionalización (i18n) y localización (l10n), AJAX, ... y como abordarlos usando Apache Tapestry.

PDFEPUBMOBIHTML

Código fuente ejemplos

Sub Shuffle(Of T)(values As IList(Of T))
    Dim n = values.Count()
    Dim rnd = New Random()
    Dim i = n - 1
    While i > 0
        Dim j = rnd.Next(0, i)
        Dim temp = values(i)
        values(i) = values(j)
        values(j) = temp
        i -= 1
    End While
End Sub

' Usage:
Dim array = New Integer() {1, 2, 3, 4}
Shuffle(array)
' Content of array (example): { 2, 3, 4, 1 }

public static void Shuffle<T>(IList<T> values)
{
    var n = values.Count;
    var rnd = new Random();
    for (int i = n - 1; i > 0; i--)
    {
        var j = rnd.Next(0, i);
        var temp = values[i];
        values[i] = values[j];
        values[j] = temp;
    }
}

// Usage:
var array = new[] {"a", "b", "c", "d"};
Shuffle(array);
// content of array (example): { "b", "d", "a", "c" }

.NET / .NET Core

• Using Reflection to Identify Unwanted Dependencies
  John Reilly
• Announcing the .NET Framework 4.7.2
  Preeti Krishna
• Stop Writing Switch and If-Else Statements!
  Marc Clifton

ASP.NET / ASP.NET Core

• The Programmer’s Hindsight - Caching with HttpClientFactory and Polly Part 2& Eyes wide open - Correct Caching is always hard
  Scott Hanselman
• ASP.NET Core: killing a Kestrel session that refuses to die
  Iris Classon
• Separating concerns using Razor Pages
  Jon Hilton
• Using IConfigureOptions To Apply Changes to a Configuration
  Steve Collins
• Out of process hosting of ASP .NET Core with IIS, do AppPool resource limits apply?
  Gareth Emslie
• Announcing ASP.NET MVC 5.2.5, Web API 5.2.5, and Web Pages 3.2.5
  Daniel Roth
• Blazor 0.3.0 experimental release now available
  Daniel Roth
• ASP.NET Core Dependency Injection – Registering Multiple Implementations of an Interface
  Steve Gordon

Azure / Cloud

• Azure Functions Recipes
  Anthony Chu
• Error Handling with Durable Functions
  Mark Heath
• Azure Storage Explorer Generally Available
  Catherine Wang
• Create new Azure App Service using Cloud Explorer in Visual Studio
  Abhijit Jana

Conceptos / Patrones / Buenas prácticas

• The logical disaster of null
  Rob Conery
• Null Is Evil. What’s the Best Alternative? Null
  Carlos Schults
• Adding Salt to Hashing: A Better Way to Store Passwords
  Dan Arias
• Código limpio: usa nombres que revelen su intención
  Albert Capdevila

Data

• SQL Server Graph Databases – Part 5: Importing Relational Data into a Graph Database
  Robert Sheldon
• Defining a Defining Query in EF Core 2.1
  Julie Lerman

HTML / CSS / Javascript

• Pure CSS Francine Wow!
  Diana Smith
• Grid Level 2 and Subgrid
  Rachel Andrew
• Coding recipe: extracting loop functionality (via callbacks and generators)
  Axel Rauschmayer
• JavaScript Scope Can Be Tricky
  Dave Brock
• Getting Started With Redux: Why Redux?
  Manjunath M.
• What’s new in Microsoft Edge in the Windows 10 April 2018 Update
  Kyle Pflug
• 8 Free JavaScript Image Cropping Scripts & Plugins
  Jake Rocheleau
• Solved With CSS! Dropdown Menus
  Una Kravets
• Inspecting Animations in DevTools
  Robin Rendle
• On Leading and Trailing Spaces in HTML Attribute Values
  Louis Lazaris
• 3 Tips for Speeding Up Your Bootstrap Website
  Maria Antonietta Perna
• Version 6 of Angular Now Available
  Stephen Fluin
• What’s New in Angular 6
  Alyssa Nicoll
• Container-Adapting Tabs With “More” Button
  Osvaldas Valutis
• Finger-friendly numerical inputs with inputmode
  Oliie Williams
• CSS3: propiedades background-origin y background-clip
  José Manuel Alarcón

Visual Studio / Complementos / Herramientas

• Improving Rider and ReSharper code analysis using JetBrains Annotations& What are JetBrains Annotations – and how to get them?
  Maarten Balliauw
• Exploring Azure App Service – Introduction
  Andrew B. Hall

Otros

• Lecturas recomendadas · abril 2018
  Albert Capdevila
• Why Developers Should Install WSL Today
  Matt Hyon & August Banks
• Make the most of your time with the new Windows 10 update
  Yusuf Mehdi
• Introducing .app, a more secure home for apps on the web
  Ben Fried
• ¿Sabes quién es el culpable de que no tengamos claro cuál fue el primer ordenador personal de la historia? Steve Jobs, pero esta es toda la historia, Parte 1 y Parte 2
  Fran Ramírez

Tanto en mi uso personal, para este blog, documentación, etc; como en el trabajo, la realización de capturas de pantalla forma parte de mi día a día. Y con el paso de los años he ido puliendo mi script de captura de pantalla para poder realizar las tareas que necesito de la forma más rápida. Aunque, con el tiempo han ido saliendo programas comoShutter o Flameshot, en ocasiones he tenido problemas con ellas. Por un lado, necesito que sean muy rápidas, para realizar múltiples capturas sin esperas; y por otro que ocupen poca memoria y sean estables, para que no se quede el ordenador congelado y no sucedan cosas raras.

De todas formas, desde hace mucho tiempo mantengo mi propio script para realizar capturas de pantalla, ayudándome de pequeños programas libres disponibles en la red. Esta necesidad surgió cuando el propio software que venía con el entorno de escritorio (Gnome, KDE, XFCE…) eran muy lentos para realizar una captura de pantalla, o, si precisaba seleccionar un área de la pantalla tenía que acceder a un modo gráfico, elegir una opción y repetir la captura. Actualmente ya no es así, aunque esos programas siguen tardando bastante tiempo en iniciar y es algo que me incomoda. Y, bueno, la principal razón por la que me encanta el software libre es que podemos personalizar hasta el más mínimo detalle.

Quien realiza de verdad la captura

Las capturas, al principio las hacía con import (de ImageMagick), más tarde me pasé a scrot. Se portaba algo mejor, era más compatible con diversas configuraciones y recuerdo que en la época en que me cambié había un bug en ImageMagick que dificultaba un poco mi trabajo. Scrot también tenía algunos problemas y finalmente estoy utilizando maim. Éste último es parecido a scrot, pero sin muchos de los problemas que tiene, incluso permite utilizar slop para realizar la selección de la zona a capturar. Todo queda muy bien y es muy bonito.

Otras cosas que necesito cuando capturo pantalla

Me gusta tener varias teclas rápidas para realizar capturas de pantalla, ya sean de la pantalla completa o de una región. Además:

• Quiero guardar la captura automáticamente en disco.
• Quiero que ese archivo aparezca en mis documentos recientes. Para subirla directamente al blog.
• Quiero poder editarla con algún programa sencillo de retoque. O realizar acciones rápidas sobre las capturas.
• Me gusta tener notificaciones en pantalla para saber que todo está marchando bien.
• Necesito poder llamar scripts automáticamente cuando se realicen las capturas (eventos).
• Crear miniaturas automáticamente. Es algo de agradecer cuando vas con las prisas. Es algo que no se tarda nada, pero si ya las tienes hechas, mejor.
• A ser posible, que se puedan configurar y me lo pueda llevar a otro ordenador con pocos recursos

Además, para hacer el script lo más completo posible vamos a utilizar técnicas explicadas en otras publicaciones anteriores:

• Procesar argumentos de entrada en nuestros shell scripts.
• Leer ficheros de configuración INI desde nuestros scripts en BASH
• Script para realizar capturas de pantalla rápidas con las opciones que necesito (viejo script)
• Cómo insertar un elemento a la lista de documentos recientes en C

Dependencias

Aunque intento que solo requiera lo básico, maim para capturar, ImageMagick para el tratamiento, notify-send para recibir notificaciones de escritorio y poco más. Al final, utiliza zenity para mostrar interfaces gráficos con opciones (aunque cuando la cosa se complica, tiro de python y pygtk), recents para insertar la captura en documentos recientes y zbar (aunque no es requerido) para procesar códigos QR si es que la captura tiene alguno.

Para el entorno gráfico me gustaría probar con yad para ver si cumple mis requerimientos. Aunque también podría eliminar la dependencia de zenity y tirar de python para todo lo relacionado con el entorno gráfico.

Cosas por hacer

Tengo varias ideas como hacer un periodo de espera de unos segundos tras la captura en el que podemos pulsar una tecla para acceder a opciones sobre esa captura o la opción para tener una configuración temporal, que dure unos minutos, por si queremos cambiar el tiempo de disparo gráficamente. Querría organizar un poco más el código, poner las funciones un poco más ordenadas y documentar muchas de las cosas que vemos en el código. También estoy abierto a sugerencias, así que, si veis algo que os gustaría tener en el sistema de capturas de pantalla, podéis dejarlo en los comentarios.

¡Manos a la obra!

Sin más dilación, pongo aquí el código fuente. Aunque podréis encontrar versiones actualizadas en Github.

Configuración

El script require configuración. Y, para ello, he acudido a archivos tipo INI, y así evitar que alguien pueda tocar parte de la funcionalidad del script insertando código en el archivo de configuración (solo en los eventos podríamos). Normalmente, tocando solo el fichero de configuración podremos personalizar bastante el comportamiento del script. Dicho archivo podemos situarlo en (por orden de preferencia):

• $HOME/.gscreenshot
• $HOME/.local/etc/gscreenshot
• /etc/gscreenshot
• ./.gscreenshot

Uso

Aunque podemos utilizar varias opciones más, y el programa dispone de una pequeña ayuda para ello, las opciones más básicas son:

Verificar dependencias

Con esto, podemos saber si el programa va a funcionar bien, se comprueba que existan los programas que requiere para su correcto funcionamiento. Algunos serán requeridos y otros no.

Captura de pantalla

Lo más importante, capturar la pantalla. Las capturas pueden ser de tres tipos:

• screen: Captura la pantalla entera.
• window: Captura la ventana actual.
• user: Permite al usuario seleccionar la región a capturar.

Vista previa con programa externo

Previsualiza la última captura de pantalla con un programa externo. Yo uso geeqie para estas cosas que además me permite navegar un poco por las demás imágenes.

Trabajo de forma gráfica con las capturas

Esto nos permite ver miniaturas de las capturas y realizar acciones sobre ellas como editarlas con diversos programas, o mirar si tienen un código QR y analizar su contenido. Podremos añadir más opciones como subir la captura a un servidor externo o cualquier cosa que se nos ocurra hacer con ellas. Para este menú se crean más miniaturas (más pequeñas que las primeras que se crean con el programa, para que encajen, aunque en el futuro se podrá utilizar otro sistema para crear el menú). Las miniaturas generadas aquí se guardarán en un directorio de caché para evitar generarlas todo el rato cada vez que se muestra el menú.

Foto principal: Igor Miske

The post Script para realizar capturas de pantalla rápidas con las opciones que necesito appeared first on Poesía Binaria.

• Cómo generar código C# parseando una plantilla Razor, es decir, un archivo .cshtml.
• Cómo compilar el código C# obtenido y generar un ensamblado con Roslyn.
• Cómo cargar dinámicamente dicho ensamblado en memoria.
• Cómo ejecutar una vista presente en dicho ensamblado y obtener el resultado.

Nota: el objetivo de estos posts es puramente didáctico, y su única intención es aprender algo sobre las tripas de ASP.NET Core. No nos meteremos en optimizar estas operaciones o introducir mejoras como cacheado o similares, ni en ofrecer una solución funcionalmente completa. Por tanto, lo que veremos aquí no será production ready, pero sí un buen punto de partida para que podáis crear vuestras propias soluciones.

Cómo generar código fuente C# desde una plantilla Razor

publicclass Template : [BaseClass]
{
publicasyncoverride Task ExecuteAsync()
    {
        ...
    }
}

Multiplication table of @Model

@for (int i = 1; i <=10; i++)
{
    @:@Modelx @i = @(Model*i)
}

Observad que en este caso no es necesario utilizar la clásica directiva @model de Razor en ASP.NET Core, simplemente accedemos a la propiedad Model de la plantilla. Más adelante veremos de dónde sale esta propiedad.

publicasyncoverride Task ExecuteAsync()
{
    WriteLiteral("Multiplication table of ");
    Write(Model);
    WriteLiteral("\r\n\r\n");
for (int i = 1; i <= 10; i++)
    {
        WriteLiteral("");
        Write(Model);
        WriteLiteral(" * ");
        Write(i);
        WriteLiteral(" = ");
        Write(Model*i);
        WriteLiteral("\r\n");
    }
}

publicclass TemplateBase<TModel>
{
private TextWriter _output = Console.Out;
protected TModel Model { get; set; }

protectedvoidWriteLiteral(string literal) => _output.Write(literal);
protectedvoidWrite(object obj) => _output.Write(obj);

public Task ExecuteAsync(TModel model, TextWriter output = null)
    {
        Model = model;
        _output = output ?? _output;
returnthis.ExecuteAsync();
    }
// Will be overriden by the template class
publicvirtual Task ExecuteAsync() => Task.CompletedTask;
}

publicclass RazorGenerator
{
privatereadonlystring _templateRoot;

publicRazorGenerator(string templateRoot)
    {
        _templateRoot = templateRoot;
    }
publicstring GenerateCode<TModel>(string templateName)
    {
var engine = RazorEngine.Create(b =>
        {
// Define the namespace for the generated class
            b.SetNamespace($"{typeof(TemplateBase<>).Namespace}.Templates");
            b.ConfigureClass((razorCode, outputClass) =>
            {
// Define the generated class name
// TODO: Sanitize & ensure that templateName is a valid C# class name
                outputClass.ClassName = templateName;
// Define its base type
                outputClass.BaseType = 
                    $"{typeof(TemplateBase<>).Namespace}."
                    + nameof(TemplateBase<TModel>) 
                    + $"<{typeof(TModel).FullName}>";
            });
            b.Build();
        });

var project = RazorProject.Create(
            Path.Combine(Directory.GetCurrentDirectory(), _templateRoot)
        );

var templateEngine = new RazorTemplateEngine(engine, project);
        templateEngine.Options.ImportsFileName = "_ViewImports.cshtml";

var item = project.GetItem(templateName + ".cshtml");
var code = templateEngine.GenerateCode(item);
return code.GeneratedCode;
    }
}

// TODO: por simplificar, en este momento asumimos que el nombre de la plantilla siempre será un identificador de clase válido en C#, pero deberíamos comprobarlo y sanearlo antes de continuar.

var generator = new RazorGenerator("Templates");    // Folder "Templates"
var code = generator.GenerateCode<string>("Hello"); // Template "Hello.cshtml"
Console.WriteLine(code);

@* Templates/Hello.cshtml *@
Hello, @Model

namespace RazorRenderer
{
publicclass Test : TemplateBase<string>
    {
publicasyncoverride Task ExecuteAsync()
        {
            WriteLiteral("Hello, ");
            Write(Model);
        }
    }
}

Datos de 2014 de empresas de todo el mundo revelan que el 63% de los trabajadores no están motivados, y del 37% restante la mayoría son infelices. Es lo que afirma Ana Moreno en el vídeo incluido en este artículo⁽¹⁾, en el que señala que el problema afecta tanto a los trabajadores como a las empresas, porque implica una escasa capacidad para atraer y retener talento con competencias críticas.

En ese sentido, Frédéric Laloux, apunta que la principal causa del problema está en la organización tradicional de las empresas, basada en estructuras directivas piramidales, y objetivos diseñados con planes estratégicos. Un modelo que considera tóxico en sí mismo, y que produce organizaciones de vistosos edificios de mármol y vidrio, pero sin alma.

Como solución a estos problemas están surgiendo modelos de organización empresarial que, según sus defensores suponen un avance evolutivo que propone alternativas a las estructuras de gobernanza piramidal, a la planificación de estrategias predictivas (planes estratégicos), y al trabajo motivado por recompensas extrínsecas. Proponen como antítesis: autogestión frente a estructuras directivas piramidales, propósito evolutivo frente a visión planificada y autoplenitud en el trabajo frente a gestión de "recursos" humanos.

Los defensores de modelos basados en equipos autogestionados argumentan que en niveles de complejidad como los que manejamos actualmente, los sistemas de planificación, control y toma de decisiones por jerarquía no funcionan. Que los sistemas realmente complejos no tienen una planificación centralizada, y mencionan como ejemplos referentes los sistemas de la naturaleza basados en estructuras fractales, o los seres vivos.

Los detractores, que seguramente son mayoría en los niveles directivos de las empresas actuales, argumentan con similar vehemencia que no es ningún avance evolutivo, sino una moda más o menos peligrosa en la medida en la que resulta atractiva e ilusionante. Una de las críticas referentes, tanto por la solidez de la exposición, como por la relevancia de su autor: Steve Denning, es el artículo "Making Sense Of Zappos And Holocracy", que cuestiona las bondades del modelo Holacracy. Un modelo sociocrático desarrollado y registrado por el empresario Brian Roberston.

Posiblemente tenga razón Frédéric Laloux al afirmar "Si crees que se necesita una jerarquía, no lo vas a entender" ;-)

El blog: cómo fue el año

Hace unos días, los amigos de Startgo Connection, publicaron un post con 7 herramientas para trabajar en equipo de forma freelance. Si bien es cierto que las comunicaciones cada día son más robustas, la evolución de HTML5, Javascript y las tecnologías que los rodean, así como los lenguajes de servidor y el hardware han evolucionado notablemente. El trabajo desde casa se vuelve cada vez más normal.

Atrás quedaron los tiempos en los que se debía enviar todo por e-mail y la comunicación era en modo texto. O aquellos en los que se utilizaban solo videoconferencias para hacer una llamada cara a cara. Actualmente, se puede realizar una gran parte del trabajo en equipo estando cada miembro en diferentes sitios del globo. Pero, como siempre, uno de los grandes problemas que encontramos es la ausencia de control y la ausencia de libertad en las comunicaciones.

Ausencia de control

Con este término, me refiero al hecho de que las comunicaciones o el almacenamiento de los datos, las realice una tercera persona o empresa. El hecho de que todos nuestros mensajes, tickets, tareas o comunicaciones pasen por los servidores de una empresa antes de llegar a su destino. Al mismo tiempo, el almacenamiento de datos se podría realizar en servidores de terceros ajenos a nosotros. Y eso tiene algunos problemas:

• El servicio que nos ofrecen puede cambiar en cualquier momento.
• Los dueños de la información no somos nosotros.
• Nuestros datos están expuestos, ante cualquier problema en la empresa proveedora, podrían robar nuestros datos.
• Puede que por razones contractuales, no podamos utilizar cierta información, por la ubicación de los servidores.

Ausencia de libertad

No podremos saber cómo funcionan estas aplicaciones, o si realmente funcionan como dicen que funcionan y nada más. Es decir, la empresa proveedora no está extrayendo más información de la necesaria, ni quedándose con datos que no les corresponden, y que, cuando borramos un dato, realmente se borra de sus servidores. Son cuestiones que puede que no nos preocupen a priori, pero tarde o temprano deberían importarnos.
Por otro lado, derivado del punto anterior. El proveedor puede echar el cierre y dejarnos sin servicio. Como gesto de buena voluntad, muchos suelen dejarte descargar cosas o dejarte hacer una transición a otro servicio, pero no siempre será así. Nadie nos puede decir que una gran empresa como las que proporcionan los servicios mencionados va a durar mucho tiempo.

Del mismo modo, nadie nos garantiza que un software libre dure para siempre y sea mantenido siempre, puesto que el tiempo de vida de las tecnologías es limitado. Pero, nosotros tendremos los datos en un formato legible que, incluso podemos conocer nosotros y nos facilitará la transición. Además, como parte la magia del software libre, cuando un proyecto se abandona, si éste sigue siendo útil, no hay que esperar mucho tiempo antes de que alguien haga un fork y cree un proyecto derivado.

Un punto en contra

Aunque soy defensor del software libre, y de tener los servicios que utilizo en mis servidores, en mis máquinas y bajo mi control. Todo esto tiene también un precio. Cuando un software te gusta y lo utilizas, y no te ha costado dinero, es una buena idea y moralmente necesaria, gratificar a los desarrolladores de ese proyecto de alguna forma. No tiene por qué ser económica. Como desarrollador, el simple hecho de recomendar mis posts, mis programas o mis guías a otras personas me resulta muy satisfactorio. Es cierto que si alguien realiza una donación sí que me hace más feliz, aunque cuanta más gente conozca el proyecto, mayor porcentaje de personas habrá que hagan una donación.

Otro punto en contra es el mantenimiento. Al tener los servicios instalados en tus servidores, y bajo tu control. Tú te tienes que encargar de las actualizaciones, del mantenimiento y la responsabilidad del almacenamiento y los ficheros es tuya. Eso sí, los servicios no estarán limitados, el número de usuarios depende de la infraestructura que montemos y no de nuestra suscripción y el tamaño de archivos podrá ser mucho mayor, ya que nosotros somos los encargados de contratar el espacio. Es más, si no queremos contratar nada, podemos tener un pequeño ordenador en casa o en la oficina que controle estos servicios. Por ejemplo estos, dan un gran rendimiento en poco espacio y tienen un bajo consumo eléctrico:

Punto de vista económico

Desde el punto de vista económico, nos tocará hacer cuentas para ver si nos compensa. ¿Cuánto vale el tiempo que invertimos en mantenimiento? ¿Cuánto vale una suscripción a un servicio? ¿Cuánto vale nuestra información? Habrá sistemas en los que no nos importe que nuestra información vuele por la nube libremente, incluso que el servicio sea gratis. En otras ocasiones, necesitaremos tener nuestra información controlada y no hay vuelta atrás. Pero en otros muchos casos, puede que el número de usuarios sea determinante. Es decir, una suscripción para 10 usuarios cuesta 200€/año, pero yo puedo montar el servicio en un servidor pagando la mitad o, incluso tener varios servicios extra. Es cuestión de evaluarlo.

Las herramientas recomendadas

La mayoría de estas herramientas permitirán la instalación de las mismas en un servidor o en un ordenador de nuestra propiedad. En ocasiones, no tiene que ser todo trabajo remoto, incluso puedes tener las aplicaciones instaladas en una red interna y que nadie pueda acceder desde fuera. Otras veces, los propios desarrolladores ganan dinero ofreciendo sus servicios instalados y usables en una máquina, ofreciendo servicios de suscripción como siempre.

Gestión de tareas Kanban (como Trello)

Aunque Trello es muy completo. No es la única herramienta de su especie. Podemos utilizar como alternativas Wekan, un desarrollo muy activo que está tomando muy buena pinta últimamente.

Otras alternativas que merece la pena ver son Kanboard y Taskboard. Encontramos otro Kanban con muy buena pinta dentro de Gitlab para la gestión de incidencias, pero podemos utilizarlo como mejor nos venga. Aunque, si eres muy friki, tal vez te puedas defender bien con org-mode de Emacs con muchísimas opciones.

Almacenamiento compartido (como Google Drive, Dropbox, etc)

Una de las claves del trabajo en equipo es poder compartir archivos rápidamente. Así como poder tener una copia de seguridad de tus elementos importantes en varios dispositivos, incluso poder editar ciertos archivos en cualquier lugar. Google Drive o Dropbox ofrecen soluciones para ello, aunque estaremos hablando de opciones privativas y, por supuesto, la información quedará controlada por ellos.

Podemos utilizar aplicaciones como OwnCloud o NextCloud. Estos programas nos permitirán compartir archivos entre miembros del equipo, incluso personas fuera de la organización con contraseña y caducidad del enlace. Nos permitirán gestionar calendarios compartidos, contactos, notas, enlaces, documentos y mucho más. Aunque la guía es algo antigua podemos echar un ojo a Guía para instalar OwnCloud en 2015. Instalación básica (I). Tendremos control total sobre los archivos de nuestra organización.
Podremos instalar OwnCloud en nuestro ordenador, un NAS, miniPC, o Raspberry PI, tener todo el espacio que le queramos enchufar, compramos un disco duro de 1Tb, 2Tb, ponemos varios discos duros en RAID, o contratamos espacio en Amazon S3 u otro sistema de almacenamiento por bloques de acuerdo a nuestras necesidades.
Además, con la libertad que nos da NextCloud podemos dejar de utilizar los servicios de Google o de Apple para nuestra información personal de nuestro teléfono.

También se merece una mención especial Minio

Chat/Comunicaciones en grupo

En el mundo empresarial se escucha mucho Slack, como una forma fácil de tener una comunicación constante con nuestro equipo de trabajo (o clientes) en tiempo real. El sistema utiliza una interfaz web y podemos utilizarlo tanto desde un navegador como desde un cliente de escritorio (hecho con Electron). Bien, Slack no es la única opción, por un lado, todo se almacena en los servidores de Slack, además, aunque tienen una versión gratuita, está muy limitada y a poco que crezca tu equipo de trabajo los mensajes almacenados no serán suficientes, querrás buscar conversaciones antiguas y no encontrarás nada porque se van borrando automáticamente y encontrarás cosas que no puedes hacer con ella. Como alternativas encontramos Mattermost (tienen un plan de pago en sus servidores, pero te dan el software para que lo instales en tu propio servidor y no tengas límites). Mattermost también forma parte de Gitlab (software del que hablaremos más adelante).
También tenemos una gran alternativa llamada Rocket Chat con muchas opciones y por supuesto, como Slack y Mattermost clientes de escritorio y móviles para las plataformas más importantes.

Gestión de código

Si hablamos de la gestión de código fuente, control de versiones, incidencias, errores, bugs, etc. Y, sobre todo, en un entorno colaborativo. Lo que más se oye es GitHub. Utiliza git, sistema que sí es libre, creado por Linus Torvalds. Aunque los datos se encuentran en servidores que no controlamos y todo el sistema web y gestión de GitHub no es libre. Como alternativa tenemos Gitlab. Que nos da un sistema completísimo para gestionar nuestro código con gran cantidad de utilidades para llevar el trabajo en equipo a otro nivel. Además, tenemos sistemas de integración y despliegue continuos, sistema de creación de páginas como GitHub Pages, un sistema de chat con nuestro equipo y mucho más.

Gestión de incidencias

Si queremos registrar, controlar y realizar un seguimiento de las incidencias que reportan nuestros clientes. Una de las plataformas más famosas es OSTicket. Incluso, sale en la primera temporada de la serie Mr. Robot. Podemos utilizarlo tanto para tickets internos, dentro de la misma empresa, o entre departamentos; o tickets externos, directamente con los clientes. De esta forma podemos ver todas las incidencias que se han generado y buscarles solución lo más pronto posible. También tiene un pequeño sistema de base de conocimiento donde podemos ir registrando las respuestas o los métodos más preguntados y no tendremos que redactar los mensajes completos para dar solución a los problemas.
Otro software que podemos utilizar es Bugzilla. Uno de los clásicos, pero que a más de uno nos ha salvado la vida.

Servicio de correo

Actualmente, muchas empresas o particulares utilizan servicios como Gmail o Outlook para gestionar su correo electrónico. Aunque el software utilizado no es libre y los mensajes no se alojan físicamente bajo nuestro control. Como alternativa, podemos utilizar Cyrus para gestionar el correo entrante, Postfix para gestionar el correo saliente y Roundcube si queremos un entorno web para gestionarlo todo. Podemos seguir esta guía para configurarlo todo. Todo esto podremos tenerlo, sin ningún problema con nuestro dominio propio. El servidor de correo no se recomienda tenerlo en una IP dinámica, por lo que deberemos contratar un VPS o similar para alojarlo. Además, de esta forma, tendremos tanto espacio como hayamos contratado, podremos tener backups en nuestro ordenador y tantos usuarios, alias y listas como queramos, cosa que se agradece cuando nuestra organización va creciendo.

Sitios web rápidos

¿Quieres tener una página lista en cuestión de minutos? Puedes utilizar Gitlab Pages o incluso un WordPress.org. Así toda la información quedará alojada en tus propios servidores. Incluso tendrás la libertad para escribir scripts que aumenten las funcionalidades de las páginas eliminando las restricciones que nos darían Google Sites o WordPress.com

Monitorización del tiempo

Muchos hablan de Toggl o Wakatime. Si buscas una alternativa libre en la que los datos se queden bajo tu control y utilicemos software libre. Debes probar ActivityWatch. Este software nos permite conocer en qué se nos va el tiempo de nuestros proyectos. O si al final del día hemos pasado más tiempo en Facebook que trabajando.

Foto principal: rawpixel

The post Herramientas para trabajar en equipo sin perder el control ni la libertad appeared first on Poesía Binaria.

A lo largo del tiempo han surgido varias formas de gestionar las excepciones. En C hace muchos años eran con códigos de error, en Java se incorporaron en el lenguaje las excepciones checked o uncheked o la nueva clase Optional en Java cada una con sus ventajas y y algunas deficiencias. Más recientemente usando un tipo tal que Either son otra forma para el tratamiento de errores sobre las opciones anteriores.

Una parte importante para el correcto funcionamiento de un programa corresponde a la gestión de errores que pueden producirse en su ejecución. Si se trata de un programa que se comunica vía interfaz de red ha de estar preparado ante la situación que la conexión se pierda o se produzcan errores en la transmisión porque por ejemplo se ha desconectado el cable de red o la WiFi no es estable. Si se trata de un programa que guarda datos en el almacenamiento persistente también pueden producirse errores como que el archivo ya existe, el directorio no existe o el espacio del disco se ha agotado. Los posibles casos de error que pueden producirse en un programa son muchos y variados.

En épocas más antiguas una forma de gestionar los errores era y sigue siendo con códigos de error donde la función o el código de salida de un programa retorna un 0 si no se ha producido ningún error o un número distinto de cero si se ha producido algún error, con un código de salida diferente por cada error. Dado que no hay obligación de gestionar adecuadamente el código de salida a veces no se hace con el consiguiente posible mal funcionamiento del programa. Otra forma de código de error es retornar un valor null en un método o función pero que no tratado adecuadamente producirá una excepción de tipo NullPointerExcetion. Con la introducción de la clase Optional entre otras novedades de Java 8 los punteros nulos se gestionan más adecuadamente pero en los casos en los que se devuelve un puntero null no se proporciona información de cuál ha sido la condición de error que se ha producido.

Para obligar a gestionar adecuadamente las condiciones de error e informar de que posibles condiciones de error se pueden producir se incorporaron en algunos lenguajes las excepciones como en Java. Las excepciones checked, aquellas que son declaradas y de obligado tratamiento, garantizan que sean tratadas de alguna forma pero algo molestas con las sentencias try-catch-exception. Las excepciones unchecked, aquellas que no es necesario declararlas y no de obligado tratamiento, son arriesgadas ya que al igual que los códigos de error no obliga a darles un tratamiento además de que no se declaran que excepciones es posible que sean lanzadas.

En algunos lenguajes con capacidades funcionales se ha propuesto una nueva forma para la gestión de condiciones de error, en Java y con la librería Vavr se proporciona la clase Either que es un tipo con la definición de tipo genérico Either<L,R>. Que un método devuelva Either indica que puede devolver en el caso del ejemplo un Integer en el caso correcto o una excepción en el caso de error. Un potencial fallo de esta opción es que no hay obligación de usar un try-catch pero si se quiere usar el valor devuelto en caso correcto se ha de tener en cuenta el potencial caso de que lo haya es valor derecho. La clase Either proporciona métodos para tratar adecuadamente en caso de que esté presente el valor izquierdo o el valor derecho.

La clase Either tiene múltiples métodos para comprobar si el valor que tiene es un valor del tipo izquierdo, derecho, obtener el valor izquierdo, derecho y múltiples métodos que hereda de Value.

El código fuente completo del ejemplo puedes descargarlo del repositorio de ejemplos de Blog Bitix alojado en GitHub y probarlo en tu equipo ejecutando el comando ./gradlew run.

A lo largo del tiempo han surgido varias formas de gestionar las excepciones. En C hace muchos años eran con códigos de error, en Java se incorporaron en el lenguaje las excepciones checked o uncheked o la nueva clase Optional en Java cada una con sus ventajas y y algunas deficiencias. Más recientemente usando un tipo tal que Either son otra forma para el tratamiento de errores sobre las opciones anteriores.

Una parte importante para el correcto funcionamiento de un programa corresponde a la gestión de errores que pueden producirse en su ejecución. Si se trata de un programa que se comunica vía interfaz de red ha de estar preparado ante la situación que la conexión se pierda o se produzcan errores en la transmisión porque por ejemplo se ha desconectado el cable de red o la WiFi no es estable. Si se trata de un programa que guarda datos en el almacenamiento persistente también pueden producirse errores como que el archivo ya existe, el directorio no existe o el espacio del disco se ha agotado. Los posibles casos de error que pueden producirse en un programa son muchos y variados.

En épocas más antiguas una forma de gestionar los errores era y sigue siendo con códigos de error donde la función o el código de salida de un programa retorna un 0 si no se ha producido ningún error o un número distinto de cero si se ha producido algún error, con un código de salida diferente por cada error. Dado que no hay obligación de gestionar adecuadamente el código de salida a veces no se hace con el consiguiente posible mal funcionamiento del programa. Otra forma de código de error es retornar un valor null en un método o función pero que no tratado adecuadamente producirá una excepción de tipo NullPointerExcetion. Con la introducción de la clase Optional entre otras novedades de Java 8 los punteros nulos se gestionan más adecuadamente pero en los casos en los que se devuelve un puntero null no se proporciona información de cuál ha sido la condición de error que se ha producido.

Para obligar a gestionar adecuadamente las condiciones de error e informar de que posibles condiciones de error se pueden producir se incorporaron en algunos lenguajes las excepciones como en Java. Las excepciones checked, aquellas que son declaradas y de obligado tratamiento, garantizan que sean tratadas de alguna forma pero algo molestas con las sentencias try-catch-exception. Las excepciones unchecked, aquellas que no es necesario declararlas y no de obligado tratamiento, son arriesgadas ya que al igual que los códigos de error no obliga a darles un tratamiento además de que no se declaran que excepciones es posible que sean lanzadas.

En algunos lenguajes con capacidades funcionales se ha propuesto una nueva forma para la gestión de condiciones de error, en Java y con la librería Vavr se proporciona la clase Either que es un tipo con la definición de tipo genérico Either<L,R>. Que un método devuelva Either indica que puede devolver en el caso del ejemplo un Integer en el caso correcto o una excepción en el caso de error. Un potencial fallo de esta opción es que no hay obligación de usar un try-catch pero si se quiere usar el valor devuelto en caso correcto se ha de tener en cuenta el potencial caso de que lo haya es valor derecho. La clase Either proporciona métodos para tratar adecuadamente en caso de que esté presente el valor izquierdo o el valor derecho.

La clase Either tiene múltiples métodos para comprobar si el valor que tiene es un valor del tipo izquierdo, derecho, obtener el valor izquierdo, derecho y múltiples métodos que hereda de Value.

En vez de retornar un Either en un método usando Vavr se puede utilizar la clase Try como otra forma de gestionar las excepciones. Con Try el método no es necesario que devuelva un Either de modo que retorne el valor en el caso correcto y lance una exepción en caso de error. El Try puede convertirse a un Either.

El código fuente completo del ejemplo puedes descargarlo del repositorio de ejemplos de Blog Bitix alojado en GitHub y probarlo en tu equipo ejecutando el comando ./gradlew run.

No es un tema novedoso, más bien al contrario. Pero es un tema entretenido que últimamente me he cruzado en varias conversaciones en twitter y me parece una ocasión como otra cualquiera para escribir sobre él: ¿los desarrolladores de sofware somos ingenieros o artesanos?

Vaya por delante que no pretendo repartir ni títulos de ingeniero ni pegatinas de crafter-clean-coder. De hecho, si algo comparten ambas visiones es cierto elitismo que no me gusta. También quiero dejar claro (aunque ya lo hice en su día) que no considero necesario ningún título para ejercer esta actividad, así que cuando hablo de ingeniería no me refiero tanto a unos estudios reglados sino en una forma de hacer las cosas.

Soy ingeniero

ingeniería: conjunto de conocimientos orientados a la invención y utilización de técnicas para el aprovechamiento de los recursos naturales o para la actividad industrial.

Esa es la primera acepción de ingeniería que aparece en el DRAE (énfasis mío). Cuando terminé la carrera de Ingeniería Superior Informática en el año 2001 y me convertí en ingeniero (bueno, más bien me dieron un título que ponía eso), mi visión del desarrollo de software cuadraba bastante bien con esa definición.

Entendía que el desarrollo de software era una actividad industrial y, como tal, podían aplicarse diferentes técnicas para gestionarla, controlarla y dirigirla. Mis conocimientos eran bastante escasos, pero asignaturas como Ingeniería del Software me habían enseñado (es un decir) que existían metodologías que podían ser aplicadas al proceso de desarrollo que permitirían convertirlo en algo parecido a una cadena de montaje.

Se podía partir todo el proceso en distintas fases, perfectamente delimitadas, en cada de una de las cuales entrarían en juego los roles apropiados para producir el resultado esperado. Así, tendríamos una fase de análisis de requisitos en la que analistas funcionales generarían un documento de especificación de requisitos, una fase de diseño en la que arquitectos y diseñadores mapearían esos requisitos a componentes, una fase de implementación en las que se programarían los requisitos o una fase de pruebas en las que se verificaría que la implementación era correcta.

Al tener todas estas fases, roles y entregables tan bien definidos, era fácil establecer la analogía con cadenas de montaje (esa actividad industrial a la que hace referencia la definición de la DRAE) y subestimar el componente humano de cada una. A fin de cuentas, picar código es picar código y cambiar un programador por otro no debería ser problema, o incluso subiendo el nivel de abstracción, el mismo razonamiento podía ser aplicado a analistas, arquitectos o diseñadores.

Cuando empecé a trabajar en el Mundo Real™, con proyectos reales, mis convicciones emperazon a tambalearse. Por mucho que intentara aplicar lo que (creía que) sabía sobre Ingeniería del Software, la realidad se empeñaba en no hacerlo funcionar. Las fases no se podían marcar tanto, los requisitos nunca llegaban a estar completamente definidos, había que saltar hacia delante y hacia atrás entre fases continuamente y, por supuesto, las personas eran clave. Si alguien conocía una parte del código o del negocio, no era fácilmente reemplazable. No había ningún tipo de magia que permitiera coger la documentación de un proyecto (generalmente incompleta y desactualizada) y hacer que alguien siguiera con él como si nada hubiera pasado.

Parecía que todo aquello que había aprendido no fuera aplicable al mundo real, o al menos a mi mundo real, y que en equipos pequeños todo esto de los procedimientos establecidos, las metodologías, los entregables y demás, no eran más que una pérdida de tiempo que no servía para gran cosa ante clientes con requisitos cambiantes y plazos agobiantes que impedían ponerse a generar y mantener documentación.

Me he sentido artesano

En ese escenario es comprensible que, cuando conocí una cosa llamada manifiesto ágil me resultara atractiva. De repente había encontrado gente que asumía mi realidad de cada día y, en lugar de intentar luchar contra ella, intentaba trabajar lo mejor posible con (o a pesar de) ella.

Ideas como valorar más los individuos que los procesos, el software que la documentación, la colaboración con el cliente que discutir eternamente documentos de requisitos, o la capacidad de adaptación frente a seguir un plan preestablecido resultaban prometedoras.

Por aquella época surgió el movimiento de ALT.NET que me ayudó a conocer otras formas de trabajar. Hay que tener en cuenta que hasta ese momento mis referencias sobre cómo había que hacer las cosas eran guías de empresas como Microsoft o Sun, siempre enfocadas al desarrollo enterprise (en el peor de los sentidos) y al demoware. Aprender sobre DI, TDD, integración continua, programación extrema o refactorización me llevó a un mundo en el que me sentía más cómodo. Esas sí eran herramientas que podía utilizar en mi día a día y a las que sí que les sacaba partido, no a esas teorías antediluvianas de desarrollo en cascada que había aprendido en la universidad.

De ahí a empezar a sentirme más cercano al movimiento de software craftsmanship había un paso. Sí, seguía siendo un ingeniero (tenía mi título), pero cada vez me veía más como un artesano:

artesano: persona que ejercita un arte u oficio meramente mecánico. Usado modernamente para referirse a quien hace por su cuenta objetos de uso doméstico imprimiéndoles un sello personal, a diferencia del obrero fabril.

La segunda acepción de la DRAE (enfásis mío) cuadra muy bien con lo que pensaba. Desarrollar software no era como trabajar en una cadena de montaje. No éramos obreros reemplazables en una fábrica (siempre me espantó -y lo sigue haciendo- el concepto de software factory), sino que imprimíamos nuestro sello personal.

Aunque siempre he valorado mucho la formación teórica que recibí en la carrera, esto me hizo también cuestionarme cuánto de lo que había aprendido en lo referente a desarrollo de software me servía para algo y si no sería mejor seguir esa línea de formación de la que hablaban algunos con sus aprendices y maestros, transmitiendo y compartiendo conocimento mientras trabajan juntos programando por parejas.

Todo esto estaba muy bien, pero al cabo del tiempo empecé a ver cosas que me encajaban menos.

Casi todo acaba justificándose porque “el desarrollo de software es una actividad muy compleja, que no se puede comparar a otras áreas como al ingeniería civil”. Eso hacía que, si por ejemplo, estimar era difícil, la solución propuesta fuera no estimar, o que se infravalorase el conocimiento formal a la hora de optimizar el rendimiento, o que se llegara a ignorar las características de herramientas complejas y potentes pensando que con un poco de pair programming y unos tests se podían obtener resultados equivalentes.

Y ahora…

Ahora no sabría muy bien como clasificarme, pero creo que vuelvo a acercarme más a la idea de desarrollo como ingeniería que como artesanía.

Ya no creo, como me pasaba hace 20 años, que sea posible desarrollar software como el que construye casas (cuánto daño ha hecho ese símil), y seguramente la industrialización del desarrollo de software no pase por establecer procesos mecánicos que permitan convertir a las personas en recursos intercambiables supeditados a esos procesos. Creo que hay un componente de libertad en el desarrollo que requiere cierto arte, talento, o como prefieras llamarlo, que está más allá de reglas preestablecidas. O al menos, que no es fácil enmarcar dentro de unas cuantas reglas que podamos seguir al pie de la letra.

Hay una parte del desarrollo que tal vez no sea ingeniería y esté más relacionada con comunicación, exploración de soluciones y habilidades menos formales. No sé que porcentaje del desarrollo es esa, pero hay otra parte que sí es ingeniería y deberíamos ser “más ingenieros”. Puede que no seamos capaces de convertir el desarrollo de software en fabricación de sillas, pero hay aspectos concretos que podemos tratar con un rigor similar al que usaría un arquitecto para elegir sus materiales.

Tenemos a nuestra disposición teoremas sobre sistemas distribuidos, formas de tratar con fallos, leyes sobre optimización, análisis de complejidad de algoritmos y un sinfín de herramientas rigurosas que podemos utilizar.

Como escribía hace poco Gonzalo, debemos huir de ese relativismo al que nos agarramos con tanta frecuencia. Sí, el contexto importa, pero eso no hace que todo valga. Fijado un contexto, podemos encontrar técnicas objetivamente mejores, y eso es lo que debemos hacer: fijar contextos y trabajar sobre ellos. No se trata de buscar balas de plata, sino de saber qué tipos de balas son útiles en cada caso, y no, no todas las balas sirven para todo.

La cuestión real

La cuestión de fondo, y eso es mucho más entretenido que mis vaivenes a lo largo de los años, es hasta dónde se puede llegar a formalizar el desarrollo de software como disciplina.

La visión clásica que trataba de equiparar el desarrollo de software a otras ingenierías asumía que se podía formalizar mucho. Igual que con el tiempo se habían creado mecanismos estandarizados para construir distintos tipos de puentes, o edificios, o barcos, se podían crear mecanismos estandarizados, fiables, replicables y predecibles para desarrollar software.

La perspectiva más agile/craftsman/moderna (y sé que estoy mezclando cosas, pero creo que se entiende a dónde quiero llegar), parte de la idea de que no se puede formalizar tanto, y hace falta tener más flexibilidad. O al menos, que conceptos básicos de otras ingenierías (como estimación de tiempos y costes) no son trasladables al desarrollo de software por la propia naturaleza de la actividad.

Normalmente se suele argumentar que el desarrollo de software tiene muchos más grados de libertad que otras disciplinas en las que las restricciones impuestas por el mundo físico (los materiales para construir un puente son los que son, es fácil determinar la longitud o anchura necesaria, etc.) hacen que sea mucho más sencillo cerrar unos requisitos claros al principio de un proyecto y elegir la forma de llevarlo a cabo.

No tengo ni idea de si eso es así o no en la vida real, pero supongo que habrá casos en los que un arquitecto no tenga que pensar mucho para construir una casa y pueda replicar el mismo proyecto que hizo para la casa anterior, y habrá otros en los que le pidan el nuevo edificio de oficinas de MegaCorp y la parte de definición de requisitos y alcance del proyecto sea bastante más complicada.

En cualquier caso, al final se trata de ver si es una cuestión ontológica o epistemológica. Si realmente la naturaleza del desarrollo de software es tal que no es posible abordarlo mediante técnicas de ingeniería “clásica” y está más cerca del “arte” o de la “artesanía”, o si, en el fondo, estamos limitados por nuestro conocimiento actual.

No hay que olvidar que cuando comparamos el desarrollo de software con disciplinas como la arquitectura estamos comparando algo 100 años de historia con unos cuantos milenios. En los casi 5.000 años que han pasado desde las pirámides de Egipto hasta ahora, la arquitectura ha tenido tiempo de evolucionar. ¿Os imagináis cómo será el desarrollo, no dentro de 5.000 años, sino dentro de 500? ¿Realmente podemos estar tan seguros de que todas esas incertidumbres que vemos ahora no serán fácilmente decidibles entonces?

La verdad es que no tengo ni idea de lo que pasará, pero lo que “la naturaleza del desarrollo lo hace imposible de gestionar como otras ingenierías”, me parece que sólo podría tener sentido dentro del contexto de conocimiento actual y no es tanto “la naturaleza del desarrollo”, sino “con lo que nosotros sabemos hoy del desarrollo”.

No hay posts relacionados.