Web

Kotlin & KTOR

KTOR

When it comes to android development I really love working with the Kotlin language, I can see why Google changed from Java to Kotlin as the default language.

With web development I find PHP to be fine but it can fell like a chore to work with. Perhaps it's having to work with old projects for work with bad code along with the lack of strict data types but I find it to be quite unenjoyable to use these days. Perhaps it's also partially down to have experienced, in my opinion, a better language.

Over the last couple of weeks I've been learning about Kotlin for web development using KTOR. As a basic test I decided to recreate my site to see how easy or would be and I can happily say it's been a mostly great experience. The main down side has been a bit of a lack of documentation, especially with getting it set up on the server using Jetty9. I've managed to get it up and running but I'll probably have to write up the process so I have a reference in the future.

Southpaw 2.0

It's been the cards for a while but I've decided to finally move away from WordPress. That main issue with WordPress is that because it's such a popular platform, it will always be a prime target for attacks and exploits.

Another thing which is a bit of a minor annoyance to me is backing up, everything is stored in the database so the while thing has to be backed up and restored if needed. Also potential is is that of the database is corrupted then you could potentially lose everything.

Updating can also be a complete minefield, especially if you're using plugins. You need to make sure everything is kept up to date because of the aforementioned security issues and if there's any incompatability between the core files or the plugins, your whole site can break.

I've therefore decided to switch things up a bit and make my own platform to suit my own needs. The key factors being:

  • Fast
  • Easy to backup
  • Secure

Data

I've had the idea for a while now of using markdown for blog posts, it's nice to write and is perfect for source control add it's plain text. This would solve the backing up concerns of storing all the data in a database.

This did however bring up the consideration of whether to use a database at all. Because all the core blog data will be stored in external files, would a dedicated database be overkill? At this point I've decided to go ahead without one, purely because this site is quite small. If it reaches a larger size and the speed is impacted then perhaps I'll add a database to the setup. My current thinking would be that the values in the database would be completely built up from the markdown files so if the database was lost for whatever reason, it could be easily regenerated from the files. The database would also allow the usual benefits of easily filter and sort the data.

Structure

If no database is going to be used then an alternative method for storing structure data will be needed so I went with JSON.

The JSON will be used for the routes and the structure of each page:

routes.json

[
    {
        "url":"/",
        "page":"home"
    },
    {
        "url":"/blog.*?",
        "page":"blog"
    }
]

pages.json

{
    "global":{
        "template":"main.html",
        "templateVars":{
            "nav":"nav.html"
        }
    },
    "pages":{
        "home":{
            "templateVars":{
                "pageContent":"pages/home.html",
                "meep": "bah!",
                "test": "meh",
                "homeClass": "home"
            }
        },
        "blog":{
            "blog": {
                "base": "/blog/"
            },
            "templateVars":{
                "pageContent": "blog.html",
                "blogContent": "wheeeee"
            }
        }
    }
}

The routes JSON simply takes a regular expression of a URL and points it to an entry in the pages JSON. The pages JSON defines global and page based variable replacements which can be either plain text or HTML template files.

We'll also use JSON to automatically build up the structure of the categories and the posts. To do this we'll scan the markdown directory for any new files, scan their headers and update any structure JSON files where necessary.

Icon Pusher

I began looking into creating an icon pack again and found out there didn't seem to be any resources for getting the app details for creating it. If you use one of the template systems they have an email option where it emails the pack developer the request. I don't think this is great really, if your pack becomes popular then you could have to sift through lots of email.

Over the last month I've been putting together a new site with an Android app counterpart. It's called Icon Pusher and it's a utility for icon pack developers for getting app icons and their package/component names. So far the app sends all the app information to the server, but the idea is to be able to integrate it into icon pack templates to allow users send their requests directly to the site instead of sending email.

Icon Pusher App
Icon Pusher App

The idea is you install the app (from Google play) onto your phone and submit the apps you want to push to the site, this will send the package and component names needed for the icon pack then the site goes off to get the icon from Google.

Icon Pusher Website
Icon Pusher Website

The website simply displays all the submitted icons and provides the XML needed to copy into the android icon pack files. The ideal situation would be to integrate it into the icon packs themselves, so the icon requests would be direct without needing the app at all.

Southpaw

Well it's safe to say that a redesign (a design anyway) was way past due so I'm now pleased to announce southpaw.dev. The old site just used a basic skeleton theme but this time I've actually created something.

Projectily

Not much game development has occurred over the last month or two, this is mainly down to trying to get an ongoing site live.

Introducing Projectily, a project management site which has been in development (on & off) for the last year. It's still nowhere near finished but has been made live as an alpha release. This means you can create an account but there's a whole load of features yet to be added and quite possibly some bugs left to squish.

You may be wondering why a site would be made live in such an early stage, it's because this way there's reason to prioritize development on it as it's publically accessible. It also allows people to help shape the future of the site, if there's any features you'd like to see on the site you can send a suggestion and it will be considered.