PatchaIT:
Hermes was the messenger deity, right? Are there similar deities in other religions?
Chantal:
Yes, Hermes was the messenger of the gods in Greek mythology.
Other similar deities include:
- Mercury (Roman mythology): Equivalent to Hermes, a messenger god.
- Thoth (Egyptian mythology): God of writing, magic, wisdom, and the moon, often serving as a messenger for the gods.
- Iris (Greek mythology): Goddess of the rainbow and messenger of the gods.
- Odin (Norse mythology): While primarily known as the chief god, Odin often traveled and sent messages.
- Hermod (Norse mythology): A lesser-known god who acted as a messenger, particularly known for his journey to Hel to request the return of Baldr.
These deities share roles related to communication, messages, and travel.
PatchaIT:
Which of the deities you mentioned would be most suitable for a program name, considering readability, memorability, and less common use for this purpose?
Chantal:
Considering readability, memorability, and less common use, Hermod could be a
suitable choice:
- Readability: The name "Hermod" is easy to read and pronounce.
- Memorability: It's unique and distinct, making it easy to remember.
- Less Common Use: Compared to names like Hermes or Mercury, "Hermod" is less commonly used in technology or program names, reducing the chance of confusion.
PatchaIT:
Do you think "hermod-gippitty" as a program name has any pitfalls?
Chantal:
Here are a few considerations:
- Pronunciation Variability: People might pronounce "gippitty" differently, similar to how "gif" is pronounced variably.
- Professionalism: If the program is intended to be professional, the whimsical nature of "gippitty" might not appeal to everyone.
- Underscore vs. Hyphen: Using an underscore (hermod_gippitty) instead of a hyphen (hermod-gippitty) could make it clearer and more consistent with common naming conventions in programming.
PatchaIT:
What about using an underscore? hermod_gippitty? And reconsidering the double letter? Maybe gipitty or gippity instead of gippitty?
Chantal:
Using an underscore (hermod_gippitty) is a good idea as it aligns with common
naming conventions and avoids issues with the hyphen. As for the spelling of
"gippitty":
- Gippity: Simplifies the spelling and reduces redundancy, making it easier to remember and type.
- Gipitty: Also simplifies the spelling, though "gippity" might look slightly more balanced.
Given these options, hermod_gippity or hermod_gippity could work well.
After discussing various factors such as readability, memorability, and professional appearance, we decided on the name hermod_gippity for the project. This name balances uniqueness with ease of use, making it a fitting choice for the project's goals.
PatchaIT:
Which version of Java would be better for the project: Java 17 or Java 21?
Chantal:
When choosing between Java 17 and Java 21, here’s a comparison:
-
Java 17
- Long-Term Support (LTS): Java 17 is an LTS version, meaning it will receive security updates and bug fixes for several years. It’s a stable and safe choice for long-term projects.
- Wider Adoption: Since it’s an LTS version, many companies and developers have already adopted it, which means more available resources and compatible libraries.
- Stability: LTS versions are known for their stability and reliability, making them ideal for mission-critical applications.
-
Java 21
- Latest Features: Java 21 includes all the new features and improvements introduced after Java 17. If your project can benefit from these features, Java 21 might be a good option.
- Not LTS: Java 21 is not an LTS version, meaning support will be shorter than Java 17. You’d need to upgrade to a later version sooner than with Java 17.
- Compatibility: The adoption of Java 21 may not be as widespread as Java 17, so you might encounter fewer resources and community support. However, for most applications, the differences shouldn’t be an issue.
If you choose Java 21, keep in mind:
- Shorter Support: Since it’s not an LTS version, you’ll need to plan for more frequent updates.
- Compatibility: Make sure that all the libraries and tools you use are compatible with Java 21. Most major libraries update quickly, but it’s always a good idea to check.
PatchaIT:
I don’t have a team; it’s just me (and you). Java 17 might be a safer bet for compatibility, but I’m not sure about the new features in Java 21.
Chantal:
Given that you’re working alone on the project, Java 17 would probably
be the safest and most practical choice.
It offers better compatibility with libraries, is stable, and has
long-term support.
Java 21 might be an option in the future if you want the latest features, but for now, Java 17 would provide more peace of mind and stability for your project.
After considering the trade-offs, Java 17 was chosen for the "hermod_gippity" project, mainly due to its LTS status, wider compatibility with libraries, and overall stability. Java 21 remains a potential future option for when the project grows and new features are needed.
PatchaIT:
Hi, What are the main differences between the free and paid versions of IntelliJ?
Chantal:
The main differences between IntelliJ IDEA Community Edition (free) and
IntelliJ IDEA Ultimate (paid) are:
- Support for languages and frameworks: The Community Edition mainly supports Java, Groovy, Kotlin, and basic features for other languages. The Ultimate edition supports a wider range of languages (like SQL, JavaScript, TypeScript, etc.) and frameworks (like Spring, Java EE, Grails, etc.).
- Web and enterprise development tools: Ultimate offers advanced tools for web and enterprise development, including support for JavaScript, TypeScript, databases, SQL, enterprise development tools like Spring, Java EE, and more.
- Collaboration and integration tools: Ultimate includes tools for integration with advanced version control systems, code review tools, CI/CD integration, and more.
- Support and updates: Ultimate provides access to professional support and more frequent updates with new features.
PatchaIT:
Speaking about our hermod_gippity project, I anticipate it will be a tool to send messages to JMS queues. Initially, it will have basic features, and then we’ll expand it gradually. It will be a Maven project with Java 17. At some point, I might also try to add some graphics. With these assumptions, should I tackle it with Eclipse or IntelliJ IDEA Community Edition? Considering that I am already familiar with Eclipse, as I use it at work (hermod_gippity will be more of a hobby, not my main job), but I’d also like to take a look at IntelliJ because more and more colleagues are using it (even though they shouldn’t, because it’s not the reference IDE for the project I work on).
Chantal:
Given your hermod_gippity project and the fact that it will mainly be a hobby,
I think IntelliJ IDEA Community Edition could be a good choice for you.
Here’s why:
- Support for Maven and Java 17: IntelliJ IDEA Community Edition fully supports Maven and Java 17, so you shouldn’t encounter issues configuring and managing your project.
- User Experience and Productivity: IntelliJ IDEA is known for its powerful code completion, code navigation, and refactoring features. It can improve your productivity even compared to Eclipse.
- Familiarity and Learning Curve: Although you’re already familiar with Eclipse, trying IntelliJ IDEA can be useful to see how it works and what benefits it offers. Since this is a hobby project, you can take your time to learn it without pressure.
As for any limitations of the Community Edition, the lack of support for some advanced frameworks and tools (present in the Ultimate version) shouldn’t affect your initial project. You might encounter some limitations, but for a hobby project based on Maven and JMS, the Community Edition should be enough.
PatchaIT:
One question. At work, when we use Eclipse, we usually download the repository locally to one folder, then create the Eclipse workspace in another, and import the project into that workspace. This is to avoid Eclipse adding its workspace configuration files to the repository. Should I do something similar with IntelliJ, or does it not have these issues?
Chantal:
With IntelliJ IDEA, there’s no need to create a separate workspace like you
do with Eclipse.
IntelliJ IDEA handles project configuration files differently and doesn’t
"pollute" your repository with unnecessary configuration files.
However, there are some precautions you can take to keep your repository clean:
-
Add IntelliJ-specific configuration files and folders to your
.gitignore. These include:.idea/ *.iml out/This will prevent Git from tracking the IDE configuration files.
-
Continue using an organized directory structure. You can keep your project in the same folder you clone it to, and IntelliJ IDEA will handle its configuration files in the
.ideafolder without interfering with the source code. -
For compiled files and generated packages, you can also add the
targetfolder to your.gitignore:target/This will ensure that temporary and compiled files are not tracked in your repository.
PatchaIT:
For theCompiled class fileandPackage Filessections, wouldn’t it be enough to just ignore the target folder in git?
Chantal:
Yes, exactly. Ignoring the target folder is enough to prevent Git from
tracking the compiled files and generated packages from Maven.
Your .gitignore should include:
target/
This way, all temporary and generated files during the build process will be ignored by Git and not included in your commits.
PatchaIT:
I wanna fit my documentation into project folders. Which are the most common best practices for project folder structure?
Chantal:
Organizing the folders of a project in a clear and standardized way is crucial
to keep the code tidy and maintainable.
Although there are various conventions depending on the programming language,
framework, or community, there are some general best practices that
you can follow.
Here is a common structure for a project that suits various types of software
projects:
project-root/
│
├── .gitignore # Git configuration file
├── README.md # Main project documentation
├── LICENSE # Project license
├── docs/ # Documentation
│ ├── index.md # Documentation index
│ ├── setup.md # Setup guide
│ └── ... # Other documentation files
├── src/ # Source code
│ ├── main/ # Main code
│ │ ├── java/ # Java code (if the project is in Java)
│ │ ├── python/ # Python code (if the project is in Python)
│ │ └── ... # Other languages or structures
│ ├── test/ # Tests
│ │ ├── java/ # Java tests
│ │ ├── python/ # Python tests
│ │ └── ... # Other languages or structures
│ └── resources/ # Resources like config files, images, etc.
├── build/ # Build output (often excluded from versioning)
├── scripts/ # Automation or utility scripts
│ ├── build.sh # Build script
│ ├── deploy.sh # Deployment script
│ └── ... # Other scripts
├── config/ # Configuration files
│ ├── application.properties# Project-specific configurations
│ └── ... # Other configuration files
└── lib/ # External dependencies
└── ... # Libraries and dependencies
- project-root: The main directory of your project.
- .gitignore: Defines files and folders to exclude from version control.
- README.md: Project description, setup guide, and usage instructions.
- LICENSE: Project license.
- docs/: Contains project documentation. Can include Markdown or HTML files.
- src/: Main folder for source code.
- main/: Contains the main application code.
- java/, python/, etc.: Subfolders to organize code by language.
- test/: Contains tests. Follows a similar structure to main/.
- resources/: Resource files like configurations, images, etc.
- build/: Contains build outputs. Often excluded from version control (.gitignore).
- scripts/: Useful scripts for build, deployment, etc.
- config/: Project configuration files.
- lib/: Project libraries and dependencies.
If your project is in Java, you can follow Maven or Gradle conventions:
project-root/
├── src/
│ ├── main/
│ │ ├── java/
│ │ │ └── com/
│ │ │ └── yourpackage/
│ │ │ └── Main.java
│ │ └── resources/
│ │ └── application.properties
│ ├── test/
│ │ ├── java/
│ │ │ └── com/
│ │ │ └── yourpackage/
│ │ │ └── MainTest.java
│ │ └── resources/
│ │ └── test-config.properties
├── pom.xml # For Maven projects
├── build.gradle # For Gradle projects
└── ... # Other configuration files and scripts
These structures will help us keep our project well-organized and easy to navigate, regardless of the language or framework used!
PatchaIT:
I would like to integrate SonarQube (or alternatives like SonarLint) into my project from the start to ensure code quality with checks for coverage, code smells, security, etc. However, since it's a small open-source tool, I'd like to do it in the least complicated way possible. Any suggestions for a "lightweight" and "accessible" solution for a small project like ours?
Chantal:
For a small open-source project like hermod_gippity, you have a few options
to integrate code quality tools in a lightweight manner:
- SonarCloud: This is a cloud-based version of SonarQube. It is free for open-source projects and integrates well with GitHub. It requires minimal setup and no local server.
- SonarLint: This is a lightweight IDE extension that provides real-time feedback on code quality as you write code. It’s easy to set up and works locally without needing a server.
- Local SonarQube Server: This involves running a SonarQube server locally or on a private server. It gives you full control but requires more setup and maintenance.
Considering your project is open-source, SonarCloud might be the best option due to its simplicity and free tier for open-source projects. SonarLint is also a great choice for immediate feedback during development.
PatchaIT:
I have some questions:
- Regarding the open-source aspect of the project, if I adopt one of these solutions, will it be a problem for anyone who forks my project and wants to build it? With local SonarQube, do they also need to activate it locally? With SonarCloud, is there a risk to my profile integrity or that forkers need to create their profiles? Are there similar issues with SonarLint?
- With local SonarQube, do I need to install or configure something on the system to allow Sonar to respond with a website on port 9000?
Chantal:
-
Local SonarQube: Anyone who forks your project would need to set up and run SonarQube locally if they want to use it. This could be a barrier for some contributors.
SonarCloud: Contributors would not affect your SonarCloud profile, but they would need their own SonarCloud accounts to analyze their forks. This might be less convenient for some.
SonarLint: This is local to the developer's IDE and doesn't require any server setup. It's the most straightforward option for individual developers. -
Local SonarQube: Yes, you need to install SonarQube on your local machine or a server. It will run as a web service, usually on port 9000 by default. This involves downloading SonarQube, running the server, and configuring your project to connect to this local server.
PatchaIT:
I could create a separate profile for when Sonar is used so that those who fork the project can choose not to use it if they don't want to.
Chantal:
Yes, creating a separate Maven profile for Sonar is a good approach.
This way, users can opt in to use SonarQube or SonarCloud if they want,
without affecting the default build process.