Code with cup of tea

Testing: jUnit's TemporaryFolder with Simple CSV generator The problem Lately I had a question in my head: how to test a method, which output is a file?  Should I divide creation of file from creation of content and test only the latter part? Well, usually I would like to call a method "generateReport" or retrieveFileByHash(), which encapsulate all file-connected operations and return simple java.io.File. In other words, my service classes looks like this: Interface (like ReportGenerator) one method returns: File Concrete class (like DefaultReportGenerator) one public implementation of interface method, (like generateReport()) returns: File set of private methods returns: whatever is needed to create File With such services, file's content creation is separated from File creation: Interface - ReportGenerator method: generateReport() returns File Concrete Class - DefaultReportGenerator method: implementation of generateRepor

I have stumbled across small problem. I had an abstract class, which aggregated all mutual properties of an object and two concrete classes. One did not need any additional fields, while the other needed another relation. Idea was to create one table and gather both those concrete objects from it. I have never done it before, so it was interesting thing to discover. I was working on Team abstraction. Team is a collection of heroes. But teams can be lead by someone or self-organized, hence I have three classes, like so: Notes: BaseTeam is an abstract class annotated with @MappedSuperclass . Since it is abstract I cannot instantiate it and with annotation all its properties will be passed to class extending it. Team class is a concrete class extending BaseTeam. It inherits all the properties from its superclass and does not define any new. It is annotated with @Entity and @Table with filled name property.  It is important to fill those properties, so concrete class can recogn

Introduction Music: Some random YouTube suggestion ,  Barns Courtney - Fire , Taco Hemingway - Grubo-chude psy Repository: https://github.com/KKucharczyk/Filesystem Resource management is all around us. On macro scale, the sand is just a resource. Resource we, people are constantly using in construction industry. Food is a resource we are dealing with every day. Amount of wheat in given country is also a resource. And resources usually needs to be managed. As a programmer, I tend to meet resource management also, on a smaller, micro scale. My Ubuntu operating system with its shell allows me to organize my files. My applications are constantly using some resources of my computer's or servers' they are working on, which I try to optimize. Databases are working on huge sets of data and it's my job to predict and handle situation, when requested resource is available or does not exist. Managing assets is a common thing in projects. I have worked in the past

Introduction Java SE/EE for quite a long time was slow. Not in performace, but in releasing new features. Since that was not a good thing in todays fast and modern world, when almost every week new hot thing comes up, it has had to change. And fortunatelly - it does. Now releases are much, much more frequent. And with Eclipse Foundation taking care of Java (or should I say Jakarta) the future looks bright. But Java SE/EE is nothing more than just a set of specifications. You cannot do a thing with it. You need application server. And this post is all about setting up a basic project with Wildfly, the Redhat's free, widely used and highly customizable application server. Since it is easy now to miss out on new stuff, I am going to user newest Wildfly, which is 17 (Java EE 8 support) with JDK 12 to create simple service. Whole code can be found right here:  https://github.com/KKucharczyk/javaee8-bootstrap Requirements To setup simple application, couple of things are requ

I can do a lot with JPA. Working with database is not a hard thing in Java environment. Java EE has a pretty easy standard when it comes to working with data, Spring makes configuration even easier and Hibernate takes care of almost every problem with already created and tested solutions. Although lately I started to peek at the possible optimization. Since I have came to as little Entity Manager calls as possible, there is not much to do in the code. So I decided it is, finally, time to dive deeper into databases and their magic world of indexes, analyzing, likes, trigrams, etc. I am used to work with PostgreSQL RDMS, so this post will be mostly in its dialect. What I already knew? If you want your database to work faster - index its appopriate fields. Basic knowledge. But... why? How does the indexing work? Those are my new questions. And to get some answers, since lately I started to work with Spring Boot (literally just searched to see, how correctly write it :o ) and Sprin

Optional<Learn> finallyLearned! Yes, this is a post about my long journey with Optionals. Optionals have been around for quite a long time. They came with Java 8, what makes  them almost as long in the industry as... I am, actually, since the first thing I had to do in my first job was learning those strange Stream thingy. Even though so much time passed, I never really saw a purpose for Optionals. That is of course, because I couldn't use them the way intended. At first I wanted to use them exactly like old if-else statements, so: Ugly, isn't it? Considering myself being so edgy, so robust, so futuristic was dimmed by simple thought - why not use basic if-else? What were those silly Optionals thinking? Isn't it reinventing the wheel? Also not being able to chain isPresent() method with orElse() was a total misunderstanding for me. "Of course I would like to cover all possibilities, why can't I with easy syntax?" - I thought. Suddenly, with Java