Clumping all things missing in AB-3 as compared to AB-4 in one issue about addressbook-level25

[pyokagan]

@okkhoy

* Checkstyle: config file is not the repo

* Travis/Gradle: Present, but documentation is absent.

* Coverall/Appveyor/Codacy/Auto publishing: No additional files needed to add (except maybe appveyor.yml) as mostly is set up on their site, but documentation is absent. Also, travis.yml/build.gradle may be outdated with respect to these.

* Folder structure is different between AB-3 and AB-4 which causes a minor inconvenience while using reposense scripts.

These are known, but the same issues can be said of AB-1 and AB-2 as well. Is it because CS2113 is still using AB-3 for the project? Why not just use AB-4? A lot of effort has already been put into simplifying it already.

[okkhoy]

In CS2113 students have the option of starting the project from AB-3 or AB-4. Last time the students setup things themselves by trial and error.
I created the issue in the hope that it may be easier for the devs to make changes and make them available.

[damithc]

Given that the current CS2113 batches are completely new to Java, I guess some teams may not be comfortable working in AB-4 by week 6.

[pyokagan]

@okkhoy

In CS2113 students have the option of starting the project from AB-3 or AB-4.

OK, but the things that need to be done to bring AB-3 up to sync with AB-4 the manual way are non-negligible. It would be a win-win situation for everyone if we did not need to do it in the first place, or a more effective method is found. Basically, I wish for the requirements to be made clear before anyone proceeds.

I created the issue in the hope that it may be easier for the devs to make changes and make them available.

The fastest way for interested parties would be to submit PRs directly.

[pyokagan]

@damithc

Given that the current CS2113 batches are completely new to Java, I guess some teams may not be comfortable working in AB-4 by week 6.

So I'm coming off the lukewarm response of se-edu/addressbook-level4#955 which suggested that no one really knows why AB-3 is "easier" compared to AB-4 (it basically boiled down to me saying that SLOC is the problem, but I was just making that up, I have no hard evidence to back that up). If we knew exactly why, then the maintenance problem becomes much easier.

Students, who are not so confident with their abilities, may choose AB-3 because they believe that it would give them an easier time (assuming that things such as the above listed discrepancies between AB-3 and AB-4 were fixed). But does it really give them an easier time? If so, why? (e.g. Is it just a SLOC problem? Or is the GUI tests giving trouble?) It would be really great if the CS2113 teaching staff could provide this information so that we can properly work out the best solution which benefits everyone.

[pyokagan]

But does it really give them an easier time? If so, why? (e.g. Is it just a SLOC problem? Or is the GUI tests giving trouble?)

One of the side benefits of having this data is that we can also find ways in which AB-4 can be further simplified as well, thus benefiting both CS2103 and CS2113. I still have a hunch that AB-4 is unnecessarily overengineered in certain places, however most of the obvious low-hanging fruit have already been fixed. The rest are all harder issues (which are pretty subtle, and may or may not be actual issues), that is not worth spending time on unless we have actual hard data that it is a problem.

[pyokagan]

(it basically boiled down to me saying that SLOC is the problem, but I was just making that up, I have no hard evidence to back that up).

@okkhoy btw, if you would like to try that out with CS2113 this semester, I have an AddressBook 3.5 that is basically AB-4 that has the following changes:

• No GUI Testing
• No select command
• No Browser Panel
• No history command
• No undo/redo
• No use of invalidation listeners (event callbacks)

That way, you get all the goodies of AB-4 with a greatly reduced SLOC. Let me know if you would like to move forward with this and I'll have it done by the end of Monday 19 Feb.

[okkhoy]

why AB-3 is "easier" compared to AB-4

For students on CS2113 side, GUI programming itself is hard (not just the tests).

In the previous semester, except for a couple of teams, MOST teams did not touch the GUI code. It was quite painful to see (seemingly) half baked products.
E.g., Adding a new field to the person class (or it's equivalent) but showing the field information in the output panel rather than in the person card.

Even those who did any GUI programming only went to the extent of removing the browser panel.

The reason most of them started with AB-4 was that it was more complete in terms of infrastructure.

[okkhoy]

@pyokagan

btw, if you would like to try that out with CS2113 this semester, I have an AddressBook 3.5 ...

I guess I can advertise this to students and see how many pick it up.

@damithc any issues you can think of if we introduce AB3.5 now?

[0WN463]

Just my 2 cents, as okkhoy said, GUI programming is hard and of less importance for the module. Thus, either the students put meaningless effort to learning GUI of JavaFX, or they just ignore it all together to make a subpar product as compared to if everything was CLI
I disagree about the infrastructure being more complete though, AB4 is feels more complete only in the sense that it "looks better" with GUI properly done. I think the underlying infrastructure is pretty similar (barring the over-engineering of AB4)

[okkhoy]

@0WN463 I meant things like checkstyle etc., being there for AB-4 by default. Not the GUI/Product itself.

[okkhoy]

Even those who did any GUI programming only went to the extent of removing the browser panel.

Correction, mostly replacing browser with another list like person panel. A few teams did have a non(?) half-working grid/calendar sort of thing.

[pyokagan]

@okkhoy

I guess I can advertise this to students and see how many pick it up.

Do strongly recommend that they use it instead of AB-3 for maximum effectiveness :-P. If it succeeds, it would be extremely good for maintenance.

[damithc]

Do strongly recommend that they use it instead of AB-3 for maximum effectiveness :-P. If it succeeds, it would be extremely good for maintenance.

I'm OK with this direction. If not this semester, this can definitely the goal for the next semester. In addition, it would be nice if there is a path for students to ditch GUI entirely and fall back on a text UI if they wish.

[pyokagan]

@0WN463

I disagree about the infrastructure being more complete though, AB4 is feels more complete only in the sense that it "looks better" with GUI properly done. I think the underlying infrastructure is pretty similar (barring the over-engineering of AB4)

Even if we are talking about "architecture", I don't think that is true. Excluding the GUI portions, some of the things that are missing in AB-3 that are in AB-4 are:

• A "user preferences" system to store user preferences
• A separate model layer to hold pieces of data that are not part of the address book itself (used in AB-4 for the filtered persons list, user prefs, selected person)
• A separate storage layer to model having multiple storage files other than the address book storage. (used in AB-4 for user prefs)
• A parser that accept argument flags in any order (as opposed to the fixed order of regexps)
• A logging system for diagnostics
• Some Config... thingy.
• ...and maybe others, I didn't look thoroughly

Perhaps some of these are not needed in AB-3. It would be good to know which ones are needed/not needed and why.

[pyokagan]

AB-3 also doesn't have the clean parser/command split that AB-4 has. Commands do some parsing of their own as well, violating the single responsibility principle.

[pyokagan]

This repo has been replaced by https://github.com/se-edu/addressbook-level35/