Hola a todos!
Hoy voy a contar cómo la tarea de prueba para la entrevista de trabajo se convirtió en la
comparación de imágenes de la biblioteca. Es una biblioteca de código abierto, que aloja en GitHub.
Antes de comenzar, permítanme presentarme. Mi nombre es romano Soy esposo y padre. Soy ingeniero de software en Epam Systems con 4 años de experiencia en TI.
La idea principal de este tema es decir que crear un producto de código abierto no es perder el tiempo, ¡no! Es una experiencia increíble, que proviene de toda la comunidad de código abierto. Es un momento en el que eres un desarrollador, gerente de proyecto, gerente de producto en una cabeza.
Mientras esta biblioteca está creciendo, he estado trabajando con personas de más de 10 (!!) países, como Estados Unidos, Alemania, China, India, Rusia, Ucrania, etc.
Sigamos desde el comienzo de esta historia ...
Prueba de tarea para la entrevista de trabajo. Agosto de 2017.
A principios de agosto de 2017, tuve una entrevista en una empresa de TI, donde el primer paso fue hacer la tarea de prueba.
La tarea consistía en crear el programa en Java que compare 2 imágenes con los mismos tamaños y muestre la diferencia visualmente dibujando rectángulos. Un requisito detallado se puede encontrar
aquí .
Decidí que quiero hacerlo lo mejor posible. Para este propósito, decidí alojar mi tarea de prueba en GitHub. Quería matar dos pájaros de un tiro: proporcionar la solución, que como código abierto e investigar cómo funciona GitHub.
Después de un tiempo, encontré Marketplace en GitHub, que tiene muchos servicios para usar con los repositorios de GitHub. Para proyectos de código abierto todo gratis. Es la primera vez que entiendo que el código abierto es la mejor comunidad.
He agregado los siguientes servicios:
- Codacy - es un servicio de calidad de código.
- Travis CI - Herramienta de integración continua.
- Overoles: historial y estadísticas de cobertura de prueba
- BetterCodeHub: servicio de calidad de código.
Los resultados de estos servicios se pueden agregar a README como una barcaza. En mi opinión, es más interesante leer README.
Cuando se realizó la tarea de prueba, la envié y esperé a recibir comentarios. Tengo varios problemas, que fueron importantes y se agregaron a la sección PROBLEMA del repositorio.
Uno de ellos: rectángulos superpuestos ...
Los rectángulos pueden superponerse e incluirse uno a uno. Este comportamiento lleva a algo de basura en la imagen resultante. Efecto deseado: fusionar rectángulos que incluían un rectángulo uno a uno.Prueba de tarea como una biblioteca. Julio 2018
Después de un tiempo, exploré que muchas personas visitan mi biblioteca en GitHub. Realmente, no pensé que alguien estuviera interesado en mi proyecto de prueba.
Logotipo
Luego, descubrí que alguien propuso un logotipo. Era un diseñador gráfico, en verdad. No estaba en la comunidad de código abierto antes y esta propuesta fue realmente extraña para mí. Por qué alguien quiere hacerlo gratis. Pero me dijo que le encantaba contribuir a proyectos de código abierto. Una especie de objetivos de vida. Es realmente asombroso.
Logotipo para el proyecto: es una idea genial y la acepté. Había muchas opciones.
De
A
Final
Era la primera vez que me comunicaba en la comunidad de código abierto. La nueva experiencia, un nuevo conocido.
El primer error de la comunidad.
Después de algún tiempo encontré un problema abierto de GitHub con el error. Fue un desarrollador de China.
El error fue sobre el problema con las imágenes grandes. Utilizó imágenes grandes y tiene StackOverflowError. Me sorprendió que alguien usara mi código y encontrara el error, además, el desarrollador creó un problema.
Fue mi primer desafío. Desafío para entender cómo resolver este error.
Después de un tiempo, el ingeniero de automatización de control de calidad de Rusia propuso una solución a este error, pero lo rechacé porque la solicitud de extracción no estaba preparada como debía. Fue mi culpa, necesitaba ver y tratar de entender la solución. Me podría ayudar a resolverlo mucho más rápido.
En ese momento había tenido dos problemas principales, que eran críticos.
Uso de la línea de comando. Otoño de 2018
La siguiente etapa del desarrollo fue trabajar con Renato Athaydes, un desarrollador de software de Estocolmo, Suecia.
Propuso cambios al permitir el uso de la comparación de imágenes como una CLI tradicional. Fue tan emocionante escuchar que alguien quiere extender el uso de la comparación de imágenes y abrir un nuevo nicho en el desarrollo.
Renato resolvió todos los comentarios, que creé y agregué una nueva versión: v2.0. Comencé a crear lanzamientos en el repositorio de GitHub. Esto es realmente útil, debido a la razón, porque puedo obtener rápidamente todos los cambios, que estaban en un lanzamiento específico, toda la descripción del lanzamiento, quién lo está contribuyendo, etc.
Luego, Renato me pidió que agregara una comparación de imágenes a Maven Central. No tengo ninguna experiencia con la publicación de bibliotecas en Maven Central y Renato se complace en agregar todos los cambios necesarios al proyecto para su publicación. Publicar en Maven Central permite agregar la biblioteca como una dependencia sin ningún problema. Un gran problema fue publicarlo.
Pero antes de publicar, tuve que corregir dos errores importantes en el sistema. Pasé mucho tiempo para solucionarlos y en abril de 2019 agregué una nueva versión: v.2.0.2.
Publicación en Maven Central. Abril 2019
Para publicar correctamente la biblioteca, debe lidiar con el control de versiones. Después de investigar este problema, comencé a adherirme al siguiente esquema: MAJOR.MINOR.PATCH
donde:
MAYOR - versión cuando hace cambios de API incompatibles
MENOR - versión cuando agrega funcionalidad de una manera compatible con versiones anteriores
PATCH - versión cuando hace correcciones de errores compatibles con versiones anteriores.
El siguiente paso es comprender cómo configurar correctamente artifactId y groupId.
Actualicé todos mis paquetes:
de ua.comparison.image
a com.github.romankh3.image.comparison
Se hace más comprensible para la búsqueda donde está la base de código.
Y el resultado fue el lanzamiento - v2.1.0.
Nuevo colaborador de Suecia. Mayo 2019
Recibí un correo electrónico, donde un consultor independiente y el contratista me pidieron ver una nueva contribución de Mika. Es un desarrollador de Suecia.
Dijo que las personas con mala vista tienen problemas para ver los rectángulos de diferencia si son demasiado delgadas. Me gustó esta idea y la agregué al proyecto.
Con estos cambios, un amigo mío me ha agregado una contribución que quería practicar usando el flujo de GitHub.
Como resultado, lancé una nueva versión v2.2.0.
El nuevo paso de la biblioteca. Mayo 2019
Tengo un problema de TobseF de Karlsruhe, Alemania. Quería usar la comparación de imágenes como una biblioteca para las pruebas. Pero él quería más funcionalidad.
En ese momento, la biblioteca tenía el método principal compareImages () que, como resultado, devolvía nuevas imágenes.
TobseF propuso actualizar el valor de retorno del método compareImages () para devolver el objeto ComparisonResult con imágenes en comparación, ComparisonState (match, missmatch, sizemissmatch). Ayudará a usar en las pruebas.
Además, propuso agregar algunas opciones de configuración, lo que lo ayudaría.
Me gustaron estas propuestas, pero los cambios no eran compatibles con versiones anteriores y eliminaron parte de la base de código, que quería mantener como estaba. Por eso rechacé los cambios.
Sin embargo, decidí implementarlo por mí mismo. Fue una gran idea para mejorar la comparación de imágenes.
Además, Mika propuso nuevos cambios: agregar áreas, que pueden ignorarse en la comparación. También es útil para las pruebas. Por eso también se agregaron estos cambios.
Como resultado, se lanzó v3.0.0.
La versión 3.0.0 se convirtió en una biblioteca real, que puede ser útil para los desarrolladores. Fui tan genial que la comparación de imágenes crece.
Utilizando en producción. Junio 2019
A principios de junio, recibí un correo electrónico de un ingeniero de control de calidad de automatización, que tenía varias preguntas sobre la comparación de imágenes. Dijo que quería usarlo en pruebas de control de calidad de automatización para producción.
Pruebas de producción! Estaba tan emocionado de escucharlo. No fue un proyecto favorito en GitHub, fue una producción real. Genial Describí todo lo que pude.
Dijo que esa comparación de imágenes era la única biblioteca que encontró, que podía comparar dos imágenes con áreas excluidas. Pero la funcionalidad de las áreas excluidas no funcionó como él quería.
Hemos estado trabajando juntos durante dos meses para mejorar la comparación de imágenes.
Como resultado, fue la versión v3.1.1.
Nicho de búsqueda. Julio 2019
Comprendí que la comparación de imágenes puede ser útil para que un ingeniero de control de calidad de automatización la use en las pruebas.
Es por eso que encontré aqa-forum, donde publiqué un artículo sobre comparación de imágenes. Tengo comentarios útiles y lancé v3.2.0 y v3.3.0.
Por favor, si conoce otro foro, donde se puede mostrar la comparación de imágenes, escríbalo en los comentarios. Ayudará a que la comparación de imágenes sea mejor de lo que es.
A continuación, encontré los repositorios de GitHub, que contienen enlaces útiles a las bibliotecas y les agregué una comparación de imágenes.
Ahora Noviembre 2019
La comparación de imágenes tiene 60 inicios, 33 bifurcaciones, 10 usos en Github como dependencia.
Creo que este es un gran resultado de la comunidad de código abierto que me ayuda a traer una nueva biblioteca.
Es un largo camino y creo que esto es solo el comienzo.
Me gustaría dar las gracias a todos los contribuyentes, que están construyendo una comparación de imágenes conmigo.
Gracias por leer
Saludos cordiales
Romana