I’m very good at building things, but every so often I get an interesting reminder that I’m not particularly great at deploying things. I am at least good at maintaining them once I have them formally deployed, but figuring out the right way to push out that project into the real world the first time tends to end up taking far longer than I’d like.
Today’s example on the subject was part 1 of my fight with figuring out how to make Java spit out something useful to deploy onto a server as a service, rather than running directly in Eclipse. I have it most of the way figured out, and hope to win that fight tomorrow and document the process, but it’s been a cavalcade of bad default configurations, silly unpatched “known issues” with projects, hyper-specific error messages, and my own lack of experience in the area.
I do vaguely wish that I had someone else running the server and just handing me the specs to follow, but on the other hand I’m learning a lot about the low level details of how the server is going to work, where I can configure it, industry best practices, and perhaps most importantly that it’s another thing that I can do in the stack.
That being said, I’ve also learned that given any viable options for an alternative, I’d use them over Java. It’s the pragmatic choice for this project, but it’s not my favorite tool.
Update on the morning after writing this:
As with many other technical tasks, time to reflect goes a long way. After several hours of hammering on the server steup to no avail yesterday and learning lots of interesting technical details, but nothing that fixed my problem, I put together a working solution in less than 30 minutes this morning.