1.1. How creative is the project? (0: I've seen this on Youtube, 1:
not creative 2: average, 3: creative, 4: very creative, 5: wow!)
3. creative : It has an attractive design that I haven't seen in other hotel apps.
1.2. How difficult was it to implement the project? (0: no
challenge, 1: very easy, 2: easy, 3: fair, 4: complex, 5: insane)
4. It should have been complex handling such graphic and connect the back end, in my opinion. Than there are also some part hard to read so I can figure it out it must have been complex.
1.3. List 3 positive aspects of the project. Motivate your
selection.
1.4. List 3 negative aspects of the project. Motivate your
selection.
1. resize button that is intended to move the window and not to resize it. I had to understand it alone after having analized the code and was not written in the documentation.
2. some repetition of code and static object inizialization
3. Not well compatible with macbook ( as I tested before using my macbook but something was not rendered as it should be, so I had to change computer and tested using windows). Examples : arrows are displayed as three points; when I booked a room as I client I cannot see the details right after.
Programming techniques
2.1. Evaluate how well 5 programming techniques we learned
throughout the course were adopted in the project. Assign a mark
from 0 to 5 to each technique, where 0 means completely incorrect
usage and 5 means perfect usage.
mark : 5. They have correctly specified the name of the exception catched, handling them correctly.
Test hooks: they covered various methods, but could have covered also checkInDate > checkOutDate. mark : 4.
Regular expression:
example (In Objects/Users):
public static boolean passwordValid(String pass1, String pass2) throws Exception {
if (pass1 == null || pass2 == null)
return false;
// Password must contain at least one digit [0-9].
// Password must contain at least one lowercase Latin character [a-z].
// Password must contain at least one uppercase Latin character [A-Z].
// Password must contain at least one special character like ! @ # & ( ).
// Password must contain a length of at least 8 characters and a maximum of 20
// characters.
String pattern = "^(?=.*[0-9])(?=.*[a-z])(?=.*[A-Z])(?=.*[!@#&()\u2013[{}]:;',?/*~$^+=<>]).{8,20}$";
...
}
MARK : 5. The GUI works correctly due to such regex.
Serialization: (In Objects/Review):
// Write the updated array back to the JSON file
try (FileWriter writer = new FileWriter("src/main/resources/json/reviews.json")) {
Gson gson = new GsonBuilder().setPrettyPrinting().create();
gson.toJson(jsonArray, writer);
}
well done but there could be a check of the existence of the file in this way:
// Check if the file exists
File file = new File(filePath);
if (!file.exists()) {
throw new FileNotFoundException("The JSON file does not exist: " + filePath);
}
Deserialization: (In Objects/Review) :
// to remove the review from reviews.json
public void removeFromJson() {
try {
// Read existing reviews from the JSON file
JsonParser parser = new JsonParser();
JsonArray jsonArray = parser.parse(new FileReader("src/main/resources/json/reviews.json")).getAsJsonArray();
// Find and remove the review from the array
int index = findIndexOfJson(jsonArray, "GuestName", GeneralController.getUser(userId).getName());
if (index != -1) {
JsonObject reviewObject = jsonArray.get(index).getAsJsonObject();
String storedReview = reviewObject.get("Review").getAsString();
if (storedReview.equals(review)) {
jsonArray.remove(index);
}
} ...
well done but there could be a check of the existence of the file too.
so mark = 4 .
Git repository
3.1. How appropriate is the .gitignore file of the project? (0:
missing, 1: very bad, 2: bad 3: average, 4: good, 5: very good)
3: average: Well structured, but there could have been comments explaining what is each element being ignored. Moreover I would have also ignored operative systems file like this :
Ignore macOS system files
.DS_Store
Ignore Windows thumbnail cache
Thumbs.db
Ignore temporary files created by text editors
*~
3.2. How appropriate is the README.md file of the project? (0:
missing, 1: very bad, 2: bad 3: average, 4: good, 5: very good)
4: good. I could understand the structure of the project. But I put 4 since there are missing instructions on how to generate javadoc and because, in my opinion, there should have been specified about moving the page using the resize button of the GUI.
Maven
4.1. Can you compile the project via Maven? (0: no, 1: yes, but...,
2: yes)
2: yes if I run ./mvnw compile. If I run ./mvn package I have some warnings about 'localRepository' that is deprecated core expression.
4.2. Can you clean the project via Maven? (0: no, 1: yes, but..., 2:
yes)
1: yes, but on macbook , I had a problem of permission connected to the file .mvn. I had to fix it alone changing permissions using chmod command. On windows it worked without any problems.
4.3. Can you run the project via Maven? Check README.md on how to
run the project. (0: no, 1: yes, but..., 2: yes)
1: yes but with one warning about localRepository that is a deprecated core expression
4.4. Are the project's dependencies appropriately configured in
pom.xml? (0: no, 1: some, 2: yes)
2: yes
4.5. Are all Maven plugins appropriately configured in pom.xml? (0:
no, 1: some, 2: yes)
2: yes
4.6. Does the project adopt Maven's standard directory layout? (0:
no, 1: yes, but..., 2: yes)
2: yes
Testing
5.1. Are all tests passing? Run mvn test. (0: no, 1: yes, but..., 2:
yes)
1: yes, but with some warnings.
5.2. How well do the tests cover the code? (0: no tests, 1: no
important method, 2: some important methods, 3: most important
methods, 4: all important methods, 5: 100% test coverage)
most importants: anyway in the BookingTests they forgot testing about checkInDate after checkOutDate for the client side, indeed it is possible also to book for negative time with negative price.
5.3. Do the tests actually verify the expected behavior of the
program? (0: no tests, 1: useless tests, 2: most don't, 3: some do,
some don't, 4: most do, 5: awesome tests)
5: awesome tests
5.4. How well can you understand what the tests are supposed to
verify? (0: no tests, 1: what is going on?, 2: most are not
understandable, 3: some are understandable, some aren't, 4: most are
understandable, 5: all test are understandable)
5: all tests are understandable
Documentation
6.1. How understandable is the Javadoc written for classes, fields
and methods of the program? (0: no documentation, 1: very poor, 2:
poor, 3: average, 4: good, 5: awesome)
4. good, well structured, but there could have been in more methods. Like in the package "DesignObject" in the class "ShadowRenderer" this method :
public BufferedImage createShadow(final BufferedImage image) {
int shadowSize = size * 2;
int srcWidth = image.getWidth();
int srcHeight = image.getHeight();
int dstWidth = srcWidth + shadowSize;
int dstHeight = srcHeight + shadowSize; .... continue ...
could have been documented and also the parameter as well the decision of the paramether type.
6.2. How useful is the Javadoc written for classes, fields and
methods of the program? (0: no documentation, 1: irrelevant, 2:
little utility, 3: average, 4: useful, 5: very useful)
4. useful. It is well written.
6.3. Can you generate documentation files for this project? Run mvn
javadoc:javadoc. (0: no, 1: yes, but..., 2: yes)
1. Yes but, there are some warnings, obviously for lines not commented and for non describing some parameters of methods, indicating not a 100% coverage. But there is one error in displaying the author of the class in many classes , that's the major problem. This is because the tag @Author is not recognized in javadoc. Indeed if you open the class in the web the author isn't shown. If you modify the tag into @author (using lower case "a") the author will be displayed correctly, I tested it out.
6.4. How adequate are the non-javadoc comments written throughout
the code? (0: mostly inadequate, 1: average, 2: mostly adequate, 3:
awesome)
mostly adeguate. The explaination is clear. Sometimes there are 2 or 3 lines with single comments that had better to be multi line comments.
Code quality
7.1. Is the code style adopted throughout the project consistent?
Consider how whitespace is represented (spaces or tabs), tab size,
naming conventions for classes, methods and variables, indentation,
braces usage, line width. See Google Java Style Guide as an example
of code style guidelines. (0: no, 1: yes, but..., 2: yes)
2: yes
7.2. How would you rate the project in terms of code duplication?
(0: a lot of duplication, 1: some duplication, 2: barely any
duplication, 3: no code duplication / only justifiable duplication)
1: some duplication. Examples:
* In class "RoomsPanel.java" located in package "AdminGUI":
This inizialization:
Date checkInDate = jDateOfCheckInChooser.getDate();
Date checkOutDate = jDateOfCheckOutChooser.getDate();
has been performed in two different methods. I think they could have been also global variable, avoiding waste of memory.
In package “WelcomeGUI”, in class “GalleryPanel” there is some repetition in the code in terms of handling different URLs, radio button selections, and descriptions (from line 87 to line 123) I would have used data structures like “Map” to handle the URL-to-UI-component and URL-to-description mappings in this way :
private Map<String, JRadioButton> imageRadioMap = new HashMap<>();
private Map<String, String> imageDescriptionMap = new HashMap<>();
Generally, repetition of code also found with this code that is in more that one class:
// Make the table content uneditable
roomTable.setDefaultEditor(Object.class, null);
roomTable.setModel(model);
We could make a method to be called in more classes in another class. Like so:
public class TableUtils {
public static void setupUneditableTable(JTable roomTable, TableModel model) {
table.setDefaultEditor(Object.class, null);
table.setModel(model);
}
}
7.3. How easy it is to understand how the program works by looking
at the source code? (0: mostly hard to understand, 1: some fragments
are hard to follow, 2: not hard, but not easy, 3: easy to
understand)
1: some fragments are hard to follow. Examples :
In class "BookingsPanel" of package "AdminGUI" we have inefficiency due to static object inizialization, causing waste of memory. Here is the piece of code I am referring to:
bookingTable.setModel(new javax.swing.table.DefaultTableModel(
new Object[][] {
{ null, null, null, null, null, null },
{ null, null, null, null, null, null },
// and so far …
In class BookingsPanel , from line 340 to line 714 the code is repeated and hard to follow. It had been better using helping methods and configure components associating action of such helper methods for each component, anyway it is well indented, and I could have gone through it.
7.4. Is the program excessively inefficient? (0: most methods, 1:
many methods, 2: few methods, 3: almost no method)
complexively in the back end most of the things have been handled efficiently. Inefficiency was found rarely.
7.5. Does the program crash unexpectedly (e.g. by an uncaught
exception)? (0: all the time, 1: rarely, 2: it happened once, 3:
never)
Review form
1.1. How creative is the project? (0: I've seen this on Youtube, 1: not creative 2: average, 3: creative, 4: very creative, 5: wow!)
1.2. How difficult was it to implement the project? (0: no challenge, 1: very easy, 2: easy, 3: fair, 4: complex, 5: insane)
1.3. List 3 positive aspects of the project. Motivate your selection.
1.4. List 3 negative aspects of the project. Motivate your selection.
2.1. Evaluate how well 5 programming techniques we learned throughout the course were adopted in the project. Assign a mark from 0 to 5 to each technique, where 0 means completely incorrect usage and 5 means perfect usage.
try-catch: used very well. Example :
try { ... } catch (ClassNotFoundException ex) { java.util.logging.Logger.getLogger(LoginFrame.class.getName()).log( java.util.logging.Level.SEVERE, null, ex); } catch (InstantiationException ex) { java.util.logging.Logger.getLogger(LoginFrame.class.getName()).log( java.util.logging.Level.SEVERE, null, ex); } catch (IllegalAccessException ex) { java.util.logging.Logger.getLogger(LoginFrame.class.getName()).log( java.util.logging.Level.SEVERE, null, ex); } catch (javax.swing.UnsupportedLookAndFeelException ex) { java.util.logging.Logger.getLogger(LoginFrame.class.getName()).log( java.util.logging.Level.SEVERE, null, ex); }
mark : 5. They have correctly specified the name of the exception catched, handling them correctly.
Test hooks: they covered various methods, but could have covered also checkInDate > checkOutDate. mark : 4.
Regular expression:
example (In Objects/Users):
public static boolean passwordValid(String pass1, String pass2) throws Exception { if (pass1 == null || pass2 == null) return false;
// Write the updated array back to the JSON file try (FileWriter writer = new FileWriter("src/main/resources/json/reviews.json")) { Gson gson = new GsonBuilder().setPrettyPrinting().create(); gson.toJson(jsonArray, writer); }
well done but there could be a check of the existence of the file in this way:
File file = new File(filePath); if (!file.exists()) { throw new FileNotFoundException("The JSON file does not exist: " + filePath); }
Deserialization: (In Objects/Review) :
// to remove the review from reviews.json public void removeFromJson() { try { // Read existing reviews from the JSON file JsonParser parser = new JsonParser(); JsonArray jsonArray = parser.parse(new FileReader("src/main/resources/json/reviews.json")).getAsJsonArray();
well done but there could be a check of the existence of the file too.
so mark = 4 .
3.1. How appropriate is the .gitignore file of the project? (0: missing, 1: very bad, 2: bad 3: average, 4: good, 5: very good)
Ignore macOS system files
Ignore Windows thumbnail cache
Ignore temporary files created by text editors
3.2. How appropriate is the README.md file of the project? (0: missing, 1: very bad, 2: bad 3: average, 4: good, 5: very good)
4: good. I could understand the structure of the project. But I put 4 since there are missing instructions on how to generate javadoc and because, in my opinion, there should have been specified about moving the page using the resize button of the GUI.
4.1. Can you compile the project via Maven? (0: no, 1: yes, but..., 2: yes)
2: yes if I run ./mvnw compile. If I run ./mvn package I have some warnings about 'localRepository' that is deprecated core expression.
4.2. Can you clean the project via Maven? (0: no, 1: yes, but..., 2: yes)
4.3. Can you run the project via Maven? Check README.md on how to run the project. (0: no, 1: yes, but..., 2: yes)
1: yes but with one warning about localRepository that is a deprecated core expression
4.4. Are the project's dependencies appropriately configured in pom.xml? (0: no, 1: some, 2: yes) 2: yes
4.5. Are all Maven plugins appropriately configured in pom.xml? (0: no, 1: some, 2: yes) 2: yes
4.6. Does the project adopt Maven's standard directory layout? (0: no, 1: yes, but..., 2: yes) 2: yes
Testing 5.1. Are all tests passing? Run mvn test. (0: no, 1: yes, but..., 2: yes)
1: yes, but with some warnings.
5.2. How well do the tests cover the code? (0: no tests, 1: no important method, 2: some important methods, 3: most important methods, 4: all important methods, 5: 100% test coverage)
5.3. Do the tests actually verify the expected behavior of the program? (0: no tests, 1: useless tests, 2: most don't, 3: some do, some don't, 4: most do, 5: awesome tests)
5: awesome tests
5.4. How well can you understand what the tests are supposed to verify? (0: no tests, 1: what is going on?, 2: most are not understandable, 3: some are understandable, some aren't, 4: most are understandable, 5: all test are understandable)
5: all tests are understandable
6.1. How understandable is the Javadoc written for classes, fields and methods of the program? (0: no documentation, 1: very poor, 2: poor, 3: average, 4: good, 5: awesome)
could have been documented and also the parameter as well the decision of the paramether type.
6.2. How useful is the Javadoc written for classes, fields and methods of the program? (0: no documentation, 1: irrelevant, 2: little utility, 3: average, 4: useful, 5: very useful)
6.3. Can you generate documentation files for this project? Run mvn javadoc:javadoc. (0: no, 1: yes, but..., 2: yes)
6.4. How adequate are the non-javadoc comments written throughout the code? (0: mostly inadequate, 1: average, 2: mostly adequate, 3: awesome)
7.1. Is the code style adopted throughout the project consistent? Consider how whitespace is represented (spaces or tabs), tab size, naming conventions for classes, methods and variables, indentation, braces usage, line width. See Google Java Style Guide as an example of code style guidelines. (0: no, 1: yes, but..., 2: yes)
2: yes
7.2. How would you rate the project in terms of code duplication? (0: a lot of duplication, 1: some duplication, 2: barely any duplication, 3: no code duplication / only justifiable duplication)
1: some duplication. Examples:
This inizialization:
has been performed in two different methods. I think they could have been also global variable, avoiding waste of memory.
In package “WelcomeGUI”, in class “GalleryPanel” there is some repetition in the code in terms of handling different URLs, radio button selections, and descriptions (from line 87 to line 123) I would have used data structures like “Map” to handle the URL-to-UI-component and URL-to-description mappings in this way :
Generally, repetition of code also found with this code that is in more that one class:
We could make a method to be called in more classes in another class. Like so:
public class TableUtils { public static void setupUneditableTable(JTable roomTable, TableModel model) { table.setDefaultEditor(Object.class, null); table.setModel(model); } }
And in each class "X" that u need it you make :
7.3. How easy it is to understand how the program works by looking at the source code? (0: mostly hard to understand, 1: some fragments are hard to follow, 2: not hard, but not easy, 3: easy to understand)
In class "BookingsPanel" of package "AdminGUI" we have inefficiency due to static object inizialization, causing waste of memory. Here is the piece of code I am referring to:
7.4. Is the program excessively inefficient? (0: most methods, 1: many methods, 2: few methods, 3: almost no method)
7.5. Does the program crash unexpectedly (e.g. by an uncaught exception)? (0: all the time, 1: rarely, 2: it happened once, 3: never)