¡Hola a todos, comunidad JavaRush! Un poco sobre mí: trabajo como ingeniero de software Java desde la primavera de 2016. Me encanta venir aquí y resolver problemas que no resolví durante mis estudios. Hoy les hablaré sobre la biblioteca: Comparación de imágenes . Esta es una biblioteca de código abierto que está disponible públicamente en GitHub . El propósito de este artículo es transmitir que crear un producto de código abierto no es sólo una pérdida de tiempo, ¡no! Esta es una experiencia rica que se obtiene desde diferentes lados, cuando tienes control sobre todo el proceso de desarrollo, cuando necesitas profundizar en cada detalle. El código abierto es el mundo que te rodea. No bromeo, durante la existencia de esta biblioteca me comuniqué con personas de diferentes países, como Estados Unidos, India, China, Egipto, Rusia, Alemania, Ucrania, Suecia, Nueva Zelanda, Noruega. Es decir, se trata de una experiencia real en el desarrollo conjunto, la búsqueda de compromisos, la comprobación del código, etc. Esa fue la introducción, ahora comencemos en orden:
Prueba. Principios de agosto de 2017
Todo empezó cuando tuve una entrevista con una de las empresas, donde el primer paso fue redactar una tarea de prueba. La tarea consistía en escribir un código que comparara dos imágenes del mismo tamaño, encontrara las diferencias entre ellas, las agrupara y dibujara un rectángulo alrededor de ellas. Ahí está la primera foto:
Hay una segunda imagen:
Fue necesario encontrar las diferencias y rodearlas como se muestra a continuación:
Como puedes ver, hay una diferencia en el campo Nombre de usuario , que está rodeado por un triángulo rojo. Descripción más detallada de la tarea . Decidí que quería hacerlo no solo correctamente desde un punto de vista funcional, sino también hermoso, para que no fuera embarazoso. Para hacer esto, decidí publicar esto como un proyecto en GitHub . Hace tiempo que quería estudiar GitHub y adquirir experiencia trabajando con él. Después de una mirada rápida, descubrí que sería bueno agregar servicios de terceros para analizar la calidad del código, generar cobertura de código con pruebas, etc. Se agregaron las siguientes herramientas:
Codacy : calidad del código. Realmente vale la pena prestarle atención.
Travis CI es una herramienta de CI (integración continua) que crea un proyecto, ejecuta pruebas e indica si el proyecto se creó correctamente. Por ejemplo, si una de las pruebas no pasó como resultado de los nuevos cambios, dirá que la compilación del proyecto no tuvo éxito y lo coloreará de rojo.
Coveralls es una herramienta que muestra qué porcentaje de su código está cubierto por las pruebas.
BetterCode Hub es otra herramienta para analizar la calidad del código. Algo muy útil que no sólo le dirá qué es malo, sino que también le describirá por qué y le dará un enlace a un libro donde podrá adquirir conocimientos al respecto.
Cada uno de estos servicios tiene su propia insignia con resultados de datos, como un proyecto de cobertura de código. Y esta insignia se puede agregar en la descripción principal del proyecto: archivo README. La tarea estaba lista; la envié para revisión. Después de la revisión, inmediatamente, desde la memoria nueva, creé un problema de Github para cada comentario , que luego me ayudaría a mejorar este proyecto. No hubo ninguna tarea de mejora por parte del empleador, así que me olvidé del proyecto por un tiempo...
Camino de la biblioteca. julio 2018
Logo
En un momento, descubrí que la gente visita mi proyecto con frecuencia y esto sucede todos los días. Me sorprendió esto, y aún más me sorprendió el hecho de que aproximadamente un año después se creó un NÚMERO, en el que estaba escrito que cierto diseñador gráfico me ofrecía crear un logotipo para mi proyecto. Dicen que le encanta hacer esto para productos Opensource y que lo hará absolutamente gratis. Empezamos a colaborar. Se propusieron varias opciones, pero finalmente nos decidimos por esta:
Entonces todavía era joven y no estaba familiarizado con la comunidad de código abierto, y el hecho mismo de tal oferta me pareció una locura y le pregunté, ¿por qué está haciendo esto? A lo que él respondió: "Lolz oh, sólo porque me encanta contribuir a proyectos de código abierto. Algo así como objetivos de vida..." ( el tema en sí está aquí ). ¡Fue entonces cuando sentí por primera vez lo maravilloso que es cuando diferentes personas te encuentran a través de proyectos de código abierto y te ofrecen cosas tan interesantes!
Primer defecto lateral
Me di cuenta de que cierto desarrollador de China me creó un problema , en el que describía que había encontrado un defecto en el funcionamiento de la biblioteca, que si usas imágenes grandes, obtienes un StackOverflowError . El hombre decidió aprovechar y encontró un error. Y no solo lo encontré. y también escribió sobre ella. Este es un nuevo paso en el desarrollo de la biblioteca. Es más, realmente no tenía una solución. En cierto momento, uno de los evaluadores de Rusia propuso una solución. Pero estaba crudo y no hecho adecuadamente y no lo acepté. Y cuando llegó el momento de publicar la biblioteca en Maven Central, fue necesario solucionar algo con este defecto; no quería publicarlo junto con él. Además hubo otro defecto que nunca solucioné y también trajo muchos inconvenientes.
Uso de la línea de comando. Otoño 2018
La siguiente etapa en el desarrollo fue la comunicación con un sueco (Renato Athaydes), que quería utilizar la biblioteca a través de la línea de comando y para ello fue necesario realizar algunos cambios y adiciones. De nuevo me quedé asombrado y sorprendido por esto. Después de que el diseñador gráfico me escribió, mi sorpresa fue algo menor, pero aún así muy grande. La idea de que alguien realmente necesitara mi código me llenó de sentimientos increíbles. Hizo los cambios necesarios y preparó el código. Realicé una revisión del código, es decir, miré los cambios, había comentarios que fueron cambiados y los cambios ya estaban en la biblioteca. Designé estos cambios como versión v2.0. El siguiente paso fue agregar la biblioteca a Maven Central, un repositorio central desde donde puede descargarla para cualquier proyecto y usarla como una dependencia. En ese momento, no tenía idea de cómo hacer esto, ni siquiera remotamente, así que dije que estaba ocupado y le pedí que realizara todos los pasos necesarios para configurar el proyecto. Pero esto resultó no ser suficiente y lo más interesante fue establecer una conexión con Maven Central. Esto es un dolor tremendo, que no pude hacer la primera vez, y no fue hasta el 15 de abril que pude publicar el proyecto en Maven Central. No fue fácil, pero como a otros les gusta decir, "todo el que quiere publicar su código Java pasa por esto". Antes de publicar la biblioteca, finalmente encontré qué y cómo hacer con los defectos que habían estado ocurriendo durante mucho tiempo y lancé una nueva versión v2.0.2 , en la que agradecí a todos los que me ayudaron, describí qué y cómo lo hice. .
Publicación en Maven Central. Primavera 2019
Para publicar una biblioteca correctamente, es necesario tener un buen conocimiento del control de versiones y de cómo configurar las versiones correctamente. Me atengo a este esquema:
XX.YY.BBBB , donde XX es una actualización importante de la versión que implica cambios incompatibles con la anterior (por ejemplo, cambiar el resultado devuelto en los métodos);
YY es una actualización menor, un cambio interno o una expansión que no cambia lo que es BBBB ; estos son defectos que se han solucionado.
Por ejemplo, la versión 2.0.2 significa que la versión principal es la 2, no hubo actualizaciones menores y hay dos actualizaciones por defectos.
A continuación, era importante descubrir cómo configurar correctamente groupId y artefactoId . Había que seleccionarlos una vez y utilizarlos más. Y forman el paquete en el que se almacena el código. Antes: ua.comparison.image Ahora: com.github.romankh3.image.comparison Y esto es claramente mejor, ya que todos saben que este es un proyecto de GitHub y se puede encontrar a través de una persona con el sobrenombre de romankh3. Cuando hice todo esto, lancé una nueva versión v2.1.0 .
Comunicación con los suecos. mayo 2019
Después de publicar la biblioteca, otro sueco (Mika Kytöläinen) me envió un correo electrónico y le pidió a su amigo que hiciera cambios en mi biblioteca. Dice que realmente necesita esto y que estará muy feliz si lo hacemos y lo hacemos rápidamente. Por supuesto, no estaba en contra de los cambios que eran necesarios. Sugirió agregar una configuración de grosor de línea que dibuje un rectángulo. Para aquellos que tienen mala visión, este será un cambio útil. Preparó el código . Después de agregar algunos cambios más, lancé la versión v2.2.0.
Comunicación con un alemán. mayo 2019
Después de esto, un alemán creó un problema en el que dice que quiere usarlo para realizar pruebas, pero le falta funcionalidad. Hizo muchas propuestas que fueron muy interesantes, sugirió que en lugar de devolver solo la imagen resultante con el resultado de la comparación, devolver un conjunto de datos: lo que se comparó, el resultado (si es necesario) y el estado en el que se encuentra. será COINCIDIR, MISMATCH, TAMAÑO_MISMATCH. Incluso hizo los cambios. Pero no tuvieron en cuenta en absoluto el código anterior y se hicieron apresuradamente. Los rechacé y me ofrecí a realizarlos como mejor me pareciera. A pesar de esto, respondió más y decidí hacerlo yo mismo y lanzar una nueva versión. Al mismo tiempo, Mika Kytöläinen propuso otra funcionalidad interesante: añadir zonas que no se incluirían en la comparación. Este es un caso real. Y todo esto fue lanzado en la v3.0.0.
Usar en un proyecto real
A finales de mayo me escribió un evaluador de automatización de Kiev, que se interesó en la biblioteca y quiere utilizarla en un proyecto real que genere ingresos. ¡Fue un gran avance! Usarlo en algún lugar de un proyecto favorito es una cosa, pero usarlo en un proyecto real es una cuestión completamente diferente. Discutimos qué y cómo funciona. La aplicación es muy interesante: en su aplicación tienen cheques que se imprimen y era necesario comprobar que los cheques se crean según una determinada plantilla y no cambia. Pero había el problema de que secciones como la fecha y la hora siempre cambiaban y debían ignorarse. Ya habíamos agregado funcionalidad para ignorar algunas áreas, pero resultó que todavía estaba muy crudo para uso real y todavía trabajamos juntos fructíferamente durante varias semanas en esto. El resultado fue el lanzamiento de la versión v3.1.1.
Encontrar un nicho
Después de eso, me di cuenta de que el verdadero nicho de mi biblioteca era usarla en las pruebas. Para hacer esto, decidí buscar algún tipo de foro para evaluadores y escribirles al respecto para obtener comentarios y aumentar la fama. Encontré un foro en ruso y publiqué un artículo allí: Organización de imágenes de prueba: comparación de dos similares . En él recibí comentarios reales sobre el código y la funcionalidad, que apliqué y lancé una nueva versión v3.2.0 y luego v.3.3.0 .
Ahora
La biblioteca tiene actualmente 60 estrellas en Github y 33 bifurcaciones. Creo que esto es genial, considerando que no lo promocioné de ninguna manera excepto por un artículo en el foro de automatizadores. Gracias a todos los que leyeron hasta el final. De hecho, resultó ser un artículo mucho más largo de lo que esperaba. Un artículo sobre cómo publicar una biblioteca en Maven Central. Si tienes algo que añadir, ¡escribe! Si tienes algo que sugerir para mejorar la biblioteca, ¡escribe! Leeré todo y le dedicaré el tiempo adecuado. Cualquiera a quien le haya gustado el artículo y lo haya encontrado útil, califíquelo y escriba en los comentarios. Además, suscríbete a mi cuenta de github romankh3. Consulta también mis otros artículos:
GO TO FULL VERSION