A possible side-project

[Flint1b]

After a longer battle against various converters, pdf extractors, pdf image extractors, I have managed to convert the designer's guide into an acceptable state and added it to my "make docs diffable" PR.

But oh boy it will still need a lot of fixing..
- the headings are still there but not marked as such so the whole document structure is gone, the headings will need to be manually found and marked as headings again
- there are 280 (!) embedded images, but many of them are unnecessary, e.g. there are a lot of <hr> lines which are embedded images, a seperate image for every <hr> line, there are little grey blocks that are embedded images as well, it looks like probably half of these 280 can be kicked out
- it's probably too big for a single document but I think asciidoc will make it easy to split it up by chapter

But overall it looks pretty good as a first step towards maintainability, considering that it's a huge document and it was only available in PDF format for many years. Have a look: https://github.com/yanlyub/vassal/blob/ ... guide.adoc

[Tim M]

this "side project" sounds a lot like what my wife's job is...Hey Honey..

[Cattlesquat]

Ooh that's fantastic, Yan! That will be so much easier to get fixy fixy on. There's a LOT of stuff in there that we'll be able to update based on my current pass through the online documentation. Other stuff will require additional hands-on work of course ... to the extent we decide we actually want a separate Designer's Guide (do we think this is where people go right now? I feel like the "real" knowledge is mostly elsewhere). To Be Discussed.

I may also get interested in doing a more comprehensible-to-programmers-but-that-aren't-Java-or-Vassal-experts "Coding Tutorial" at some point, although that will partially depend on my gut check at the time for what I think Java Vassal's future looks like, time frame and otherwise. But anyway at the moment I have lots of energy & time so we'll just see where things go.

[Cattlesquat]

this "side project" sounds a lot like what my wife's job is...Hey Honey..

Haha I'm sure your wife would LOVE to spend hours cleaning up the docs for Our Favorite Wargame Engine

[Flint1b]

this "side project" sounds a lot like what my wife's job is...Hey Honey..

Haha I'm sure your wife would LOVE to spend hours cleaning up the docs for Our Favorite Wargame Engine

I have the feeling that people generally love to have hobbies where they can do things they can't do at work.

No one in an enterprise setting would ever allow me to hunt down formatting issues, refactor without having unit tests, and generally move mountains of code without checking back with management, clients, a lengthy testing process, and meetings meetings meetings

I like to play truck simulator too, there's probably many truck drivers who play hacker games and Game Dev Tycoon.

[uckelman]

Thus spake Flint1b:
> No one in an enterprise setting would ever allow me to hunt down
> formatting issues, refactor without having unit tests, and generally

Go ahead and write unit tests. We need unit tests.

--
J.

[Flint1b]

Thus spake Flint1b:
> No one in an enterprise setting would ever allow me to hunt down
> formatting issues, refactor without having unit tests, and generally

Go ahead and write unit tests. We need unit tests.

--
J.

Well, the code needs to be testable in the first place. I am generally against writing unit tests for 400 LOC methods and 1000 LOC classes, they make the necessary refactoring more tedious. Having able developers perform the refactoring and the code review is worth much more than dumb unit tests.

Let's add an IoC container, remove all the static stuff, all these GameModule.getGameModule() static instances and the like, all the public static methods, have the IoC container inject the objects where needed, then let's refactor the classes into clean code with max. 20 lines per method and max. 4-5 methods per class, and THEN we can write neat unit tests.

[Flint1b]

No, seriously.

Can I make a PR where I add the Spring framework, and have it's IoC container inject a (global/singleton) GameModule instance where it's needed? This would at once have the effect of making all classes that depend on GameModule testable by supplying them with a mocked GameModule.

[uckelman]

Thus spake Flint1b:
> We should do what everyone else does and start collecting data about
> users, find out how many use which version, which OS, their family
> names, passwords, addresses, shoe size, occupation, religion, photos of
> their kids, then feed all this into a data mining process and have an AI
> decide which OS is most representative and which bugs should be fixed
> next in order to make the most users happy.
> I'm exaggerating of course but collecting "a little bit" of user data
> would surely be useful, somehow.

We do have recent download statistics:

https://somsubhra.com/github-release-st ... ory=vassal

(Note that the 3.2.17 statistics from GH aren't representative. Virtually
all of the downloads of that will have been at SourceForge.)

--
J.

[Flint1b]

Go ahead and write unit tests. We need unit tests.

OTOH: if we want to move further and further away from any kind of unit-testability, let's add more public static methods and singletons

And I tried adding a DI/IoC container. It choked and made the whole application unusable, I haven't investigated further but my guess is that killing off the main thread right at the start of the application lifetime is not a good idea at all when there's an application context. It's hopeless.