I recently converted most of the server side code to use lenses and had bunch of naming conflicts all over, mostly relating to newtypes representing things like name of ship or star. I devised a naming scheme, that I’m going to follow from now on.

If you have ever wondered what kind of tests I write on the UI level, wondr no more. At the end of this post there’s enclosed a current version of a test script that I use for ship and vehicle designer. The script is written for Robot Framework and it in turn uses Selenium WebDriver to actually interact with a browser.

Days like these I’m really grateful that Elm compiler catches lots of type mistakes. I have been structuring the client side code to separate different states of the program (user has not logged in, user has logged in but doesn’t have an avatar and user has logged in and has an avatar) more clearly. As usual, I failed to see all the little details I need to take into account, but Elm compiler was nice enough to point them out to me.

When I originally started working on the Deep Sky, I had envisioned the user interface being just a plain HTML website. Pretty soon I started experimenting with Elm and switched over to it, mostly. Everything else is written in Elm on the client-side, except user account creation and login. Plan is to rewrite that portion on Elm too and hopefully clean up the code somewhat in the process.

Deep Sky is my little toy project, where I can experiment with various things and see how they work. Backend is written Haskell, while frontend is written in Elm. Premise of the game is simple: each player is a ruler of a faction and they try to make sure their dynasty survives as long as possible. If one thinks of Crusader Kings 2, but with Romans and set in space, they aren’t far off.