Nayanika Development Journey: Minimum Viable Productjava javafx nayanika open-source
Dear readers, I would like to share some great news. Nayanika Minimun Viable Product (MVP) is done!!
I thought I won’t make it. My day job and taking care baby are taking a lot of my time. But, I keep trying to find one or two hours during my weekday for developing Nayanika. And, I proudly share with all of you the very first milestone release of Nayanika. This milestone theme is a MVP.
So, what I’ve done till I reach this milestone?
Preparing an open-source project is not different from making your side project. The only difference is whether the project is friendly for collaboration or not. That means, the preparation starts even before I write the code.
Source Control Management
I’m choosing Git as the source-control management (SCM) and Github for the hosting repository. I know that many developers are already familiar with Git and Github. This will make collaboration will be easy.
So, the very first step I took in creating a repository for Nayanika on Github. Psstt the repository could be accessed here: https://github.com/swardana/nayanika
Picking a license from the beginning is necessary. Without telling what license my project is, it will fall under All Right Reserved. I could assert my copyright and demand that you do not use my project in the future. Good intention alone is not enough. I need to explicitly declare that Nayanika since the beginning is an open-source project.
As for the license, I’m choosing GNU GPL v3 or later. Why? Because I see many popular open-source desktop projects using it. I don’t see any harm for Nayanika. Thus, the decision is made that Nayanika will be under GNU GPL v3 or later.
Change is inevitable. Growth is optional.
Did you know what is an awful thing about changes? When there are no records about it.
No, I don’t see Git commit history as a changes record. I mean, when was the last time you write an explanatory commit message?
Sometimes, we need to paraphrase the words for better clarity. The change records are intended for non-tech people as well.
I create a Changelog document from the very beginning. So, I could note down every change. I pick Keep a Changelog style for my document. It’s simple and no-hassle when start to update the changes.
Nowadays, readme document is a norm. Project information will be available in this document. I intended for the readme document to be short. I will create separate documents if necessary. But, for now, the readme document should be enough. Even I need still need to update it gradually.
Since beginning, Java is already choosen as the programming language. While, JavaFX is for the Graphical User Interface (GUI) framework. Nayanika using latest Long-Term Support (LTS) Java version 17. If possible, I will use the new API introduce till Java 17.
Meanwhile for the JavaFX, my policy is to stick with available latest release version. Since Java 11, JavaFX is decoupled from Java Development Kit (JDK). Now, JavaFX could be included as dependencies on the Java project. It’s simple as updating the release version for JavaFX dependencies on the build tools.
In Java worlds, there is the big three of build tools. Apache Maven, Apache Ant, and Gradle. But, today’s only Apache Maven and Gradle that widely used. Apache Ant mostly used by older project.
Between Apache Maven and Gradle, I choose Apache Maven.
There is a time when using Apache Maven for JavaFX project is need a lot of setup. Compared with Gradle which already supporting JavaFX, Apache Maven is not favorable.
But, it’s not true anymore! Both Apache Maven and Gradle already support JavaFX project. In terms of setup and plugins intended for JavaFX development, both offer the same quality.
The reason why I’m choosing Apache Maven is because the ability to upgrade my Java version. With Gradle, often time you need to upgrade the Gradle as well to support the latest Java release. Usually, Gradle release that support new release version will take some times. This will hinder you to upgrade your Java version immediatelly.
With Apache Maven 3.3.x you could use Java 17, even you could use Java 18.
Other things is, even though Apache Maven xml is claimed too verbose, but I still like it. I rather write the Apache Maven xml setup than batling my way with the Gradle builds configuration. Which there are a lot of way for doing one thing, even with adding Kotlin alongside with Groovy is not helping.
Being an open-source project, anyone is welcome to contribute. It will attract people from any background and experience.
The problem with this situation is quality of the project is at risk. Code style could differ between each contributor. Less experienced programmers may write buggy code.
So, what I could do is set up a gatekeeper. I need to enforce some rules for the project. This is to make sure that the contribution will homogenous.
The very first gatekeepr is Maven Enforcer Plugin. This will be used to make sure that the used Java version is not lower than Java 17. I also make sure that the Apache Maven version used starts from 3.8.4.
The next step is to set up the code style. Having a homogenous code style will make code review easier. Not only that, debugging and tracing errors is easier.
I choose Checkstyle for the code style checker.
Test Code Coverage
The last gatekeeper is test coverage. I want the project have active and updated unit & integration test.
But, sometimes code coverage is not adding value to the project. I only put 40% coverage to pass the test code coverage rule. I also exclude classes that in fact can’t be tested or testing will not add any value at all.
All the rules are checked using JaCoCo.
Some people may find this irritating. Especially, when the rules are violated the build will fail. To be honest, I’m not that strict about all this setup. If there is a good reason to take out some of the rules, I’m willing to do it.
Function Wishlist Roadmap
During the introduction post, I have listed several wishlist. With the release of v1.0-M1, all the high priority is done. So, why the theme of this release is an MVP. You can use Nayanika right of the bat for this release.
But, it’s not mean the journey is almost done. It’s the opposite in fact. During development, I encounter a performance issue with the current release. So, I will focus on this performance issue on the next milestone release. If possible I will include the Medium priority as well.
Processing user local directory which pictures stored. The first picture found will be displayed.
Processing picture file from user local directory. The picture will be displayed.
Navigate next, previous, last, and beginning within the pictures.
Zoom and Pan displayed picture.
Applied sorting on pictures.
Support CBZ / CBR file.
When opening 200 pictures or more with a size ~1-2MB the performance is degraded.
This is the end of the Nayanika journey for the release of Milestone 1. See you in the next update!
If you have any comments or corrections please feel free to email them to me. Also, if you found any of the content on this website useful consider buy me a coffee ;)
- Previous: Slackware Installer