Mailtrap: Un servidor SMTP falso para pruebas.

Está Escrito:

La gracia del Señor Jesucristo, el amor de Dios, y la comunión del Espíritu Santo sean con todos vosotros. Amén.

(2 Corintios 13:14)

Tomado de: Code Tutsplus

Mailtrap proporciona un servidor SMTP falso para que su equipo de desarrollo pueda probar, ver y compartir correos electrónicos enviados desde los entornos de preproducción y probar con datos reales sin el riesgo de enviar spam a clientes reales. Ha sido creado por Railsware y para muchas tareas de desarrollo, el uso de Mailtrap será gratuito.

Esencialmente, se registra en Mailtrap y envía todo el correo electrónico del entorno de preproducción a través de su servidor SMTP Mailtrap falso.

Entonces, todos sus correos electronicos pertenecen a Mailtrap. Puede ver y depurar su correo electrónico dentro de la GUI amigable de Mailtrap.

Incluso puede utilizar Mailtrap para colocar vertederos de su base de datos de producción con correos electrónicos reales de usuario a través de pruebas en su servidor de ensayo. Sus pruebas automatizadas se pueden ejecutar contra el correo electrónico de envío de datos real a través de Mailtrap—eliminando el riesgo de que los correos electrónicos de prueba salgan a direcciones de correo electrónico de clientes reales.

¿Cuánto cuesta Mailtrap?

Para pequeños desarrolladores o pequeñas tareas, Mailtrap es gratuito. Para mayores esfuerzos, los costos varían entre $ 120 y $ 300 al año:

Introducción a Mailtrap

Registrarse es fácil. Incluso puedes usar tu cuenta de Google o GitHub:

Utilicé mi cuenta de GitHub y el proceso fue fácil:

Una vez confirmado, verás tu bandeja de entrada de demostración en la GUI de Mailtrap:

Configuración de Mailtrap

A continuación, voy a guiarlo a través de la configuración de Mailtrap dentro de su entorno de desarrollo.

Al hacer clic en el icono Configuración en la lista de Bandeja de entrada, verá que cada bandeja de entrada de Mailtrap tiene sus propias credenciales de servidor SMTP:

Puede restablecer estas credenciales cuando lo desee.

Mailtrap ofrece una variedad de ejemplos de configuración:

Para simplificar, utilizaré la aplicación Hello de nuestra serie programación con Yii2 para configurar Mailtrap. Si desea utilizar el código de allí para probar Mailtrap, clone el repositorio GitHub vinculado a este tutorial.

Con Yii, estoy actualizando la configuración SMTP de SwiftMailer en config/web.php. Aquí está lo predeterminado:

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18

'errorHandler' => [     'errorAction' => 'site/error', ], 'mailer' => [         'class' => 'yii\swiftmailer\Mailer',         'viewPath' => '@app/mailer',         'useFileTransport' => false,         'transport' => [             'class' => 'Swift_SmtpTransport',             'host' => 'your-smtp-host-domain',             'username' => 'your-email-or-username',             'password' => 'your-password',             'port' => '587',             'encryption' => 'tls',                         ],     ], 'log' => [     'traceLevel' => YII_DEBUG ? 3 : 0,

Lo que cambié con mi configuración de Mailtrap:

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18

'errorHandler' => [             'errorAction' => 'site/error',         ],         'mailer' => [                 'class' => 'yii\swiftmailer\Mailer',                 'viewPath' => '@app/mailer',                 'useFileTransport' => false,                 'transport' => [                     'class' => 'Swift_SmtpTransport',                     'host' => 'mailtrap.io',                     'username' => '294XXXXXXXXXXdd20',                     'password' => '403XXXXXXXXXX2f7',                     'port' => '25',                     'encryption' => 'tls',                                 ],             ],         'log' => [             'traceLevel' => YII_DEBUG ? 3 : 0,

Entonces, visité http://localhost:8888/hello/user/register para registrarme de nuevo:

Yii envía un correo electrónico de confirmación:

Al instante, el mensaje aparece en mi bandeja de entrada de Mailtrap.

Nota: Esto no debe confundirse con la confirmación de la cuenta de Mailtrap—es el correo electrónico de confirmación de la cuenta de la aplicación Yii Hello enviado por mi aplicación.

La pantalla predeterminada es la que puede ver en Gmail u otro cliente de correo:

Pero hay muchas pestañas para elegir para depurar el correo electrónico saliente de su aplicación. Esta es la fuente HTML:

Esta es una vista de la validación de HTML en tu correo electrónico:

Y aquí está un análisis de la puntuación de spam y la lista negra de su mensaje y servidor:

Mailtrap es una manera tan poderosa de depurar el contenido y el marcado de mensajes de correo electrónico salientes.

Cómo compartir buzones de entrada y mensajes con su equipo

Si su equipo es más grande, puede invitar a todos sus desarrolladores a acceder a cada buzón con vínculos:

O bien, puede reenviar automáticamente todos los mensajes a sus propias cuentas e invitarlos a través de sus propias cuentas de Mailtrap:

La API de Mailtrap

También puede escribir pruebas automatizadas contra el contenido del buzón de correo de Mailtrap utilizando su API, documentada en apiario. En otras palabras, podría ejecutar secuencias de comandos automatizadas contra una instantánea de su base de datos de producción en directo y verificar el contenido y el marcado de los mensajes que serían entregados por su base de código mediante la API de Mailtrap.

¿Quiere aprender más?

Las capacidades de Mailtrap y las funciones de depuración son obviamente muy útiles y asequibles. Si desea ver otra demostración, aquí hay una charla relámpago en Mailtrap de Yaroslav Lazor de Railsberry 2012:

Es un producto tan simple de usar y tan beneficioso que espero que lo pruebes por tu cuenta.

Envíe sus comentarios, correcciones o ideas adicionales a continuación. Puedes navegar por mis otros tutoriales de Tuts+ en mi página de instructor o seguirme en Twitter @reifman.

Principios básicos Solid

Está Escrito:

"Porque somos hechura suya, creados en Cristo Jesús para buenas obras, las cuales Dios preparó de antemano para que anduviésemos en ellas." (Efesios 2:10)

Tomado de: Wikipedia

Solid es un acrónimo inventado por Robert C.Martin para establecer los cinco principios básicos de la programación orientada a objetos y diseño. Este acrónimo tiene bastante relación con los patrones de diseño, en especial, con la alta cohesión y el bajo acoplamiento.

El objetivo de tener un buen diseño de programación es abarcar la fase de mantenimiento de una manera más legible y sencilla así como conseguir crear nuevas funcionalidades sin tener que modificar en gran medida código antiguo. Los costes de mantenimiento pueden abarcar el 80% de un proyecto de software por lo que hay que valorar un buen diseño.

Inicial	Acrónimo	Concepto
S	SRP	Principio de responsabilidad única (Single responsibility principle) la noción de que un objeto solo debería tener una única responsabilidad.
O	OCP	Principio de abierto/cerrado (Open/closed principle) la noción de que las “entidades de software … deben estar abiertas para su extensión, pero cerradas para su modificación”.
L	LSP	Principio de sustitución de Liskov (Liskov substitution principle) la noción de que los “objetos de un programa deberían ser reemplazables por instancias de sus subtipos sin alterar el correcto funcionamiento del programa”. Ver también diseño por contrato.
I	ISP	Principio de segregación de la interfaz (Interface segregation principle) la noción de que “muchas interfaces cliente específicas son mejores que una interfaz de propósito general”.5​
D	DIP	Principio de inversión de la dependencia (Dependency inversion principle) la noción de que se debe “depender de abstracciones, no depender de implementaciones”.5​ La Inyección de Dependencias es uno de los métodos que siguen este principio.

S-Responsabilidad simple (Single responsibility)

Este principio trata de destinar cada clase a una finalidad sencilla y concreta. En muchas ocasiones estamos tentados a poner un método reutilizable que no tienen nada que ver con la clase simplemente porque lo utiliza y nos pilla más a mano. En ese momento pensamos "Ya que estamos aquí, para que voy a crear una clase para realizar esto. Directamente lo pongo aquí".

El problema surge cuando tenemos la necesidad de utilizar ese mismo método desde otra clase. Si no se refactoriza en ese momento y se crea una clase destinada para la finalidad del método, nos toparemos a largo plazo con que las clases realizan tareas que no deberían ser de su responsabilidad.

Con la anterior mentalidad nos encontraremos, por ejemplo, con un algoritmo de formateo de números en una clase destinada a leer de la base de datos porque fue el primer sitio donde se empezó a utilizar. Esto conlleva a tener métodos difíciles de detectar y encontrar de manera que el código hay que tenerlo memorizado en la cabeza.

O-Abierto/Cerrado (Open/Closed)

Principio atribuido a Bertrand Meyer que habla de crear clases extensibles sin necesidad de entrar al código fuente a modificarlo. Es decir, el diseño debe ser abierto para poderse extender pero cerrado para poderse modificar. Aunque dicho parece fácil, lo complicado es predecir por donde se debe extender y que no tengamos que modificarlo. Para conseguir este principio hay que tener muy claro como va a funcionar la aplicación, por donde se puede extender y como van a interactuar las clases.

El uso más común de extensión es mediante la herencia y la reimplementación de métodos. Existe otra alternativa que consiste en utilizar métodos que acepten una interface de manera que podemos ejecutar cualquier clase que implemente ese interface. En todos los casos, el comportamiento de la clase cambia sin que hayamos tenido que tocar código interno.

Como ya he comentado llega un momento en que las necesidades pueden llegar a ser tan imprevisibles que nos topemos que con los métodos definidos en el interface o en los métodos extensibles, no sean suficientes para cubrir las necesidades. En este caso no habrá más remedio que romper este principio y refactorizar.

L-Sustitucion Liskov (Liskov substitution)

Este principio fue creado por Barbara Liskov y habla de la importancia de crear todas las clases derivadas para que también puedan ser tratadas como la propia clase base. Cuando creamos clases derivadas debemos asegurarnos de no reimplementar métodos que hagan que los métodos de la clase base no funcionases si se tratasen como un objeto de esa clase base.

I-Segregacion del interface (Interface segregation)

Este principio fue formulado por Robert C. Martin y trata de algo parecido al primer principio. Cuando se definen interfaces estos deben ser específicos a una finalidad concreta. Por ello, si tenemos que definir una serie de métodos abstractos que debe utilizar una clase a través de interfaces, es preferible tener muchos interfaces que definan pocos métodos que tener un interface con muchos métodos.

El objetivo de este principio es principalmente poder reaprovechar los interfaces en otras clases. Si tenemos un interface que compara y clona en el mismo interface, de manera más complicada se podrá utilizar en una clase que solo debe comparar o en otra que solo debe clonar.

D-Inversión de dependencias (Dependency inversion)

También fue definido por Robert C. Martin. El objetivo de este principio conseguir desacoplar las clases. En todo diseño siempre debe existir un acoplamiento pero hay que evitarlo en la medida de lo posible. Un sistema no acoplado no hace nada pero un sistema altamente acoplado es muy difícil de mantener.

El objetivo de este principio es el uso de abstracciones para conseguir que una clase interactue con otras clases sin que las conozca directamente. Es decir, las clases de nivel superior no deben conocer las clases de nivel inferior. Dicho de otro modo, no debe conocer los detalles. Existen diferentes patrones como la inyección de dependencias o service locator que nos permiten invertir el control.