Trisha Gee

Congratulations all of you!

Tim Holloway wrote:

But one of the neatest things of all is that the project metadata for Eclipse and IntelliJ is non-conflicting, so you can, if you like, define projects that can be supported equally well on either IDE.

Yep, I've seen this work well on several projects

Knute Snortum wrote:Thanks, I got it working.  I'll tell what I did, but first a clarification: the structure I posted was the one you see if you go into Project Settings and click on the Modules tab.  

Great, I'm glad I could help!

Campbell Ritchie wrote:I knew one of the authors' names was familiar; I have a copy of the 97 Things You Should Know book.

Yay! I hope it was helpful!

I've been asked a lot about the tool set for working on the book, particularly the asciidoctor stuff, so I might invest a bit more time in documenting/automating some of that.

We hope to work on a second edition at some point, so maybe then we'll get a chance to document the whole workflow a little more, or record some videos on us working on the book.

I have to admit, as an old-school enterprise Java developer, I'm not really the target audience for Fleet. However, it definitely has an important part to play in many developers' organisations, and I hope to see that in action in my new job at Gradle, as I'll be working with many more organisations with different types of problems.

Great question.  I haven't had any problems creating JAR files myself, although I appreciate it is a two-step process which might seem a bit complicated. This tutorial walks through the process:

https://www.jetbrains.com/help/idea/creating-and-running-your-first-java-application.html#package

Personally, though, I wouldn't use an IDE to create a JAR file, unless it's only a pet project.  You really want a reproducible, automatable process for this, i.e. by using a build tool like Maven or Gradle. This way, the JAR will be produced the same way whether you create it on your own machine, in the continuous integration environment, or some other system.

I can give you my personal opinion on this. I'd like to caveat this: I have struggled with this particular issue on more than one occasion, and I haven't found an "official" way to do this comfortably.

What you really need is a multi module project. The top level of your project won't have code, and you'll need two modules, a Kotlin one and a Python one. Given your existing structure, that actually means you'll have to move your kotlin stuff "down" a level into its own module (e.g. create a folder under Wordle called "Kotlin" and then under that one you'll have main/kotlin and test/kotlin). You'll need to make your top-level Kotlin folder a new IntelliJ IDEA module. Then you can create a new module (e.g. called Python) and put your python stuff in there.

This is a bit fiddly. I have struggled with moving a project with a single module (or effectively no modules) into multi modules. The best way to create a multi module project is to start with an "empty" project and then create each module individually, but that doesn't work well if you have existing code.

Another approach is not to introduce separate modules, but instead to use separate source folders.  E.g. you can create a "python" folder under the Wordle folder and "Mark directory as" a source root. I have not tried this for non-JVM languages, so this may not work for Python, it may have to be a separate module.

I appreciate this advice is not super clear, but I hope it helps!  More info in the docs:

https://www.jetbrains.com/help/idea/creating-and-managing-modules.html
https://www.jetbrains.com/help/idea/add-items-to-project.html#create-module
https://www.jetbrains.com/help/idea/content-roots.html#configure-folders

Eclipse and Netbeans offers free support for Java EE/Jakarta EE and Spring frameworks, whereas the full-featured support for enterprise frameworks like these is only in the paid (Ultimate) version of IntelliJ IDEA.  However, IntelliJ IDEA Community (the free one) supports all the "normal" stuff you want to do with Java development, e.g. refactoring, code completion, running and debugging code. You can also use it on projects that use Spring, for example (I did for many years), you just don't get all the magic (e.g. all the code suggestions) you would with Ultimate.

My recommendation is to use whichever IDE you're most comfortable with, or whichever one your team is using. If you're working with others who know their IDE pretty well, this is the best way to learn that IDE. I worked on a team where people used both Eclipse and IntelliJ IDEA, when I started there I didn't really care which one I used. By the end of my first few months there I was firmly in the IntelliJ IDEA camp (and we were using the free, Community, version). Code completion was quicker and more comprehensive, code generation was fast and covered many of the cases I needed, iterating through the TDD red-green-refactor cycle was fast and efficient. Now I use it for everything, even writing docs in markdown or asciidoc, because there's support for pretty much every language and format.

Migrating from one IDE to another will take some time, but if you take 10 minutes a day to try to learn a new shortcut or new feature, it pays off pretty quickly.

It can sometimes feel like IntelliJ IDEA uses a lot more of your computer's resources than other IDEs.  Usually, it's when you get started with a new project and IntelliJ IDEA has to index the code and its dependencies. The IDE should speed up once the indexes are generated, they're there to make the IDE work faster after all, also nowadays there's an option to download the commonly used indexes which should also be a bit faster.

However, I have also found that using IntelliJ IDEA with an SSD is significantly better performance than a spinning rust drive, I guess most laptops use SSDs now but I'm not sure if enterprise hardware has caught up.

The WSL2 support is constantly being updated, I remember recording a video on the introduction of its support back in about 2020. If you do have specific issues, I would raise them in the issue tracker, because the jetbrains developers aren't necessarily using the IDE the same way you are: https://youtrack.jetbrains.com/issues/IDEA

We don't cover the data science tools in the book, we focused on the fundamental functionality, like writing, reading, running and debugging code, with pointers on how to configure your IDE. The code samples are in Java, but they should still be relevant for other developers using other IntelliJ-based IDEs

It already does, it uses machine learning for some code suggestions.

In theory, they do the same thing. In practice, it's going to depend on your project. I often use the IntelliJ runner for running tests because it's often faster for individual test classes. However, Gradle has clever caching which sometimes makes it faster.

You do need to use the Gradle runner if Gradle sets up prerequisites, like code generation, or if the Gradle Build has plugins that you need to run your code (for example, I have some Javafx projects that only run with the Gradle  Build runner).

I love this question, it totally justifies why we wrote about this in the Getting to Know IntelliJ IDEA book!

Use shift cmd f8 (mac) or ctrl shift f8 (win/Linux) to bring up a list of all your breakpoints

I have two possibilities:

- postfix completion is not that well known, yet as soon as people see it they're blown away by how useful it can be. You do have to teach yourself to get into the habit of using it to really get the most from it
- the version control support is, in my opinion, extremely underused. Many developers claim to prefer the command line, yet the visual approach of intellij can make difficult vcs problems much easier to understand. I highly recommend all developers to give the GUI VCS support a try for a while before deciding which approach they prefer