My first body of work in which I was exploring the subject of bullying and photographing subjects or victims who have been victims of bullying.
seen from T1

seen from Malaysia
seen from Italy
seen from Poland
seen from China
seen from T1

seen from United States
seen from Estonia
seen from T1
seen from United Kingdom

seen from Italy
seen from United Kingdom
seen from Germany
seen from United Kingdom
seen from United States
seen from T1

seen from Philippines

seen from Türkiye

seen from Portugal
seen from Türkiye
My first body of work in which I was exploring the subject of bullying and photographing subjects or victims who have been victims of bullying.
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.
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.)
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.
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!
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...