Just Code Monkey Things

I’ve been getting acquainted with my new job in Manchester, doing Dev Ops stuff. In reality what this means is I’m on a team that wants to expand its CI/CD capability, move from pets to cattle, have more infrastructure as code, etc. etc. As far as I can tell I was hired because they needed someone - anyone, and now that I’m here, it tends to be that I figure out some Dev Op capability, then share it with the team. They’ve also brought in some guys more experienced in Dev Ops to help speed the process. Of course, I’ve been doing a fair share of normal devving, since we’re still doing the transformation.

Speaking of which. Apache Camel has been the main framework I’ve used lately, and the bane of my life when it hasn’t worked how I expected it!

Console based messenger! In Java.

I decided to make a nicer looking console messenger, and to that end I used Lanterna. It's a cross-platform console based UI library which can either use a console provided, or start up a Swing based console. There's some funny behaviour it has, though, which I plan on mentioning in Lanterna's Google Group. For one, in Windows the Swing console uses massive amounts of memory, which appears to be a Swing problem. I wish they could have used JavaFX, to be completely honest. Windows' cmd.exe and Powershell are both incompatible with Lanterna's console functions, so it will always open a Swing console. On Linux, the messenger eats up a good third of the CPU time, and I haven't been able to find out why. There are a few threads with infinite loops going; I suspect at least one of them is why.

Still, I'm chugging along with Lanterna, and I'm overall pleased with the library, especially as it's all native Java. My next target is to encapsulate messages in a class that will include a Java ZonedDateTime and a String with the message sender's display name. I'll be using a bit of JSON for sending messages back and forth.

Console based messenger! In Java.

Well, I got it working on Friday! Determining a best-practice way to connect up the command objects, command factories, and chain of responsibility took up the majority of the time I spent last week. It turned out that I needed a higher level I/O class on top of all of these. It would hold a socket, open streams, and then depending on the state of the socket, route user input to a stream, or the chain of responsibility. The chain of responsibility contained factory classes that would generate commands, which the I/O class would run, in order to open connections and streams.

Java's console is a little inflexible, though. When a user sends a message, the input is moved up a line. For clarity's sake, the message also gets printed through System.out, preceded by "You: ". The problem is that it looks messy:

hello world You: hello world

I've looked and looked, but I can't find a way to hide or clear System.in after a user hits enter. My only idea at this point is to find a curses-like api to handle what the console should look like. It could be a fun way to learn a bit about GUI programming!

Console based messenger! In Java.

Last Friday and part of today was spent just learning Java sockets and using them in a thread to have a connection timeout. I got it working, but then realised sockets already have timeouts. That just about halved the lines of code necessary for my socket generation class. Overall, they’re rather easy to use.

Next up is to get my console based frontend to parse commands and create sockets depending on that. I have a chain of responsibility to parse commands from the strings generated by the user. Now it’s looking like those handlers that make up that chain need to be factories that make command objects. I heard you like design patterns so I put a design pattern…

Console based messenger! In Java.

Well. I’ve realised now that how I handle the initial commands, “listen [port]”, or “connect [url]:[port]” is complex. Mile long string dissecting if-else-ifs. I’m going to adopt a chain of responsibility design pattern, which means a fair bit of refactoring.

Console based messenger! In Java.

I’m going with TDD, since until now I’ve not done it so strictly. And hey! It’s doing what it should, by keeping me focused and down the right path. 

Initially I was trying to do unit tests where I faked console input via streams, and read System.out via another stream... Thinking about the tests (with a nudge from my trainer) made me realise I could make the whole thing way more extensible if did console input separately from the parsing. Bam. Way easier to test and write then. Just dealing with methods that return and take in strings now.

I've been signed off on my training, and have a WHOLE lot of time on my hands, so...

Console based messenger! In Java.

So far what I have in mind is a console-based app that listens on a port for a connection, and once another instance of the app connects to it, console input will be sent to the other instance! Simple, right? My trainer assures me overall it will be, with one difficult part to figure out.