gerb82
commented
6 years ago o/ so... gonna go over the points in order: "You're way past your specified timeline" there's a really funny story there. at the start i estimated that building working alpha, beta, and so on versions of the systems will actually fit with the way things will work out. but the more i worked on it and the more i kept planning ahead, i realized that something like 90% of the system will be an api (the package called utilities), split into a few areas (GBD (GreenBlitz Data), GBSockets (an easier way to work with sockets in java, more on that one later), GBDB (GreenBlitz DataBase access, since the jdbc driver is not really the most user friendly thing in the world), along with some more general utilities and maybe something i'm forgetting right now). so i realized that there would be no point in writing zombie alpha and beta versions relying on a constantly changing api, where the versions won't even then be adapted into the final version, because most of the change will be in the api, so it probably won't be worth the effort. because of that, the timeplanning, as well as the deadlines to cut off different features for the first release, are constantly changing. also, the reason the workflow seems chaotic, is that if it wasn't clear already, i have a pretty annoying case of adhd, so i become a lot less effective when i work on the same thing a lot of time in a row. this is why my workflow looks like a program running a few threads and constantly jumping between them.
so, about GBSockets: because of the way java sockets work, it's kind of a pain in the ass (and that's putting it lightly) to work with sockets. you need to define 2 mirrored sides for the communications, you get an object as the packet, you have no clue what object even is it, and it just becomes messy and unreadable at best. this is actually my second attempt at simplifying this process, the first one was scrapped because it was done overnight, had a bug somewhere, and i'm certain i know exactly where, and we didn't have enough time to fix it, because the deadline was the morning after that (it was for another project that was made to help the coach communicate with the "war room" in the national competition) the idea is that both sides will always be sending an object of type "packet". this packet will contain the actual content, as well as some information useful for dealing with it (the type of packet, be it a heartbeat or a specific form of sending data, as well as a code-name for the type of object in the "content" field, so that the right method will be able to process it with ease). this way, you put one socket like that on each side, and they do the rest. it also gives you a "packet manager" object, which will be the part processing the packets, sending their content and some other important data to the functions dedicated to dealing with the packets. the sockets also have a convenient way to automatically reconnect if they are disconnected, as well as a way to differentiate between different types of connections, so that when someone connects to the program, it can determine which type of connection he is (a scouter, the war room, a pit scouter, whatever), and deal with it accordingly.
the config system is actually a thing i'm doing mostly for fun, with the main intention being: a) giving a way to configure a program using it without changing any of the compiled code and b) giving an alternative to the seemingly complex, but actually rather simple, fxml format, which we currently use for loading a gui scene from a file. the main problem with fxml is that calculations inside of it are almost impossible, especially stuff like "screen size", making it quite annoying to use for when you want a system that can be more system-independent. it's probably one of the first features that i will cut for the current release if necessary, but for now i think i can make it support just primitive types pretty easily. the hard part is supporting custom objects defined inside the file, but it's gonna be a while before i even consider this for the first release.
oh yea. i keep mentioning the api, but i don't think i mentioned why i'm making it. obviously, making a system on the spot, without any api and anything like that, would be WAAAAAAAAAAAAY simpler. but i'm currently in 12th grade. currently the gui crew/team/your choice of words, is a mess. as the person who has been in charge of it at it first year (last year), and also who's in charge of it this year: it's a mess. we discover things on the go, we don't have much documentation on what we do, we barely have anything to rely on in terms of libraries, other than javafx, which is lacking at best, and it's just not a good way to leave things after this year, in case i can't be that available in the next few years. because of that, i'm making this GBUIlib, also known as the utilities package in this project, so that for the next years, the people in the gui team will have an easier time working with: databases, javafx, sockets, and more.
onto the next point: the point about TCP isn't really a point, because again, i'm using the java sockets, which use tcp. i'm simply sending the content through them in a much simpler way.
why not use existing config formats: this mainly relates to the editor, and two of it's features, so i'll touch on that in a bit.
oh wait. that's now. cool! soooooooooo... the editor. probably my favorite project i'm working on right now. the editor will support text editing. that's kinda obvious. but this is only the most basic of features it will support. it will also support two more features which i love, and which are the real reason i'm going to such lengths for this (ok, other than the fact that it's fun as hell). the first one is one i actually got from a game. ok, a lot of games. in many, many games, there's this feature, in one way or another, of what i like to call "block programming". instead of actually writing lines of code, your code looks more like a flow-chart. you have "blocks", and these blocks accept a certain input, give a certain output, and then you move to the next command in line. this way, it is extremely easy to write the code, to visualize it, and more. you can have blocks containing blocks, thus splitting your code into groups, and it's extremely easy to visualize the code this way. it's been kind of a fantasy of mine for years now, to have a way to program this way. so this is kind of the main feature of the editor, and the way the GBD format relates to it. the idea is to have a way for a compiled program to give it's user A LOT of freedom through said config file, to customize the program to their liking, with the editor being the tool to make it extremely convenient. there's also a similar feature of visualizing it in other formats as well, for example, a "settings window" for a program, and the idea is that those two features will be the main thing about the editor. a flow-chart like way to "program", and ways to create convenient config windows for your program, that then get saved into a convenient config file that you easily load. now. i do agree that this is actually a feature that should happen much later. but there's a "company" i "work" in (the terms are really weird, because the whole concept of how that company works is kinda weird), it's more of a group project with money involved to be honest. anyway, i have to at least invest some time there from time to time, and my current project on there is an editor exactly like that. so i agreed with them that i'll make a "generic" editor. and then one implementation will be a GBD editor, one will be an editor for their custom format that they need an editor for, with a test third implementation for something someone from greenblitz needs. and the idea is to then either release the code of the editor and it's framework for others to use, or maybe even make a more robust version and actually have it be a product on there (either way greenblitz will always have access to it, at least to the version i make here). so basically, the reason the editor is currently being worked on, is that i am actually mostly doing it for work, and for a while now, there's gonna be a lot of overlap between what i need for work for it and what i need for here for it, so i'm keeping it here for now. in fact, it's probably gonna use the gbui lib (as that library will probably be public after it's done, dunno)
not a single part of the program done: already touched on it, heavy adhd, as well as the fact that most of it is the gbui lib, and then i'll just have to implement those things for the different parts of the program.
about more manpower: i don't believe i can really have too many people working on this project. that being said, considering the fact that i'm not too good at explaining how most of the things are supposed to work in text, i'd be glad to explain it in person/in some sort of voice chat if you're on board. so in short: i'd be glad if you joined :P
i think this about sums it up, and i guess now is a good time to say thanks for taking an interest, as well as taking the time to write up all these things. i usually like it when people ask a lot of questions about what i do, because intuitively i know what i'm doing, but unless i'm questioned about it, it's pretty hard for me to put things into words. so thanks for everything, Oded
Dear gerb82,
You're a talented guy with an unexplainable deep love for Java. That love is so bright it blinds you to any other solution out there, no matter how simple and elegant it may be.
I admire your courage and ingenuity. But not everything has to be built with java.
Your priorities are misplaced. You're way past your specified timeline and still working on unnecessary angles like GBSockets (building your own implementation of a programmatic socket or a new protocol I'm assuming?), and a Turing complete interpreted configuration language (complete with primitives, nested objects, and events), as well as an editor to write in that language. (?!?!)
Why go through all this trouble? Isn't TCP a better alternative than writing raw packets over ethernet? How are you planning to route these packets if the endpoint is outside your subnet?
Why put in so much effort into creating an interpreted configuration language when an alternatives like YAML JSON or XML exist and are being used by so many different production ready projects all over the world.
Why put in the effort into creating an editor so there will be no syntax errors when writing in your untested half implemented interpreted language?
I don't get why you put so much effort into building everything yourself when actually you don't have a single page in the system done yet.
Work on the system itself first. Then maybe get into packet managers and editors for touring complete configuration languages.
You're a talented guy but your priorities are misguided and you're way out of your predefined schedule.
Take a breath and start working on what really matters.
If you need more man power to assist in the project, just ask I'll be more than happy to pitch in.
Best of luck, Daniel