Just Code Monkey Things

The adventures of one primate in front of a keyboard.

[dperrocco]

I’m still here!

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!

As a Camel noob, I’m curious. Does its use case overlap with what you might do in a functional programming language? The whole stateless business where you just alter a message coming through? And then that would lead me to wonder when you might prefer a functional language over an OO framework such as Camel?

[dperrocco]

Short(ish) Personal Project 1.1

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.

Currently, the app works as intended using Lanterna. I ended up abstracting out the socket/stream management from the console IO class, as well as the view logic. Now the console IO routes Strings to other bits of the application, like the socketIO class, the view updater class, and to the command handlers if necessary.

[dperrocco]

Short Personal Project 1

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!

On the other hand, I could continue on my Snake clone that I've been working on with JavaFX. The problem is that I started it during my first week of Java training. The code is messy, to say the ABSOLUTE least, and I dread opening it up. It was itself an experiment in learning to code with a GUI involved, so if I continued with the messenger, I would probably be learning the same things, only with a cleaner codebase to work on. Time to do some thinking.

[dperrocco]

Short Personal Project 1

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…

I’ve really hit that stage where I want a code review, but I have an interview tomorrow to prepare for! Maybe Wednesday. If anyone has comments, I’d love to hear them, but the code itself is proprietary. (It may be personal, but I'm working on it at work while I don't have other things to do.)

[dperrocco]

Short Personal Project 1

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.

This feels like an annoying artifact of TDD, and my trainer pointed me towards a nice blog post on the subject. The gist is that you save time and effort if you write tests for a single entry point class into your problem. From there, write integration tests, and tests for other classes and units you forsee needing, then write the code. Red and Refactor, then Green, I suppose.

[dperrocco]

Short Personal Project 1

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.

With the parsing done for connecting and listening, it’s on to the actual socket logic that will accompany the console input/output!

[dperrocco]

Short Personal Project 1

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.

Will post updates later...