Forem: George Sokianos

Get RSS feed for your Ko-Fi account

George Sokianos — Thu, 17 Aug 2023 19:20:56 +0000

Almost two years ago, I created my Ko-Fi page where I could blog about my work on personal projects I am working on in my free time. Most of them cover topics about the Amiga community and operating systems like AmigaOS and MorphOS. Ko-Fi.com is a nice platform, easy to use and express yourself.

One of the things I have been missing all these years is a way for anyone to follow my posts, even if they are not registered on that platform. The best way to do it is using RSS, but unfortunately, Ko-Fi.com doesn't provide them. I get it. They prefer people to register just to follow someone and potentially become their customers, but platforms like Ko-Fi.com are for people to communicate what they love to do. In my opinion, every website should have RSS available because it is convenient for people to get informed about the latest blog posts using the applications of their choice.

So, I had to do something about it. I was looking for a tool that could be useful to me. Different online apps grab content from websites that do not provide any RSS and create one. Some didn't work with Ko-Fi.com at all and others were quite expensive, requiring a monthly fee just to have an RSS feed.

In the end, I found an exceptional project called RSS-Bridge, which does exactly what I need. I just had to write some code. Not a big deal. We are developers, after all, right?

RSS-Bridge will generate feeds based on “bridges” that are developed for any site. Those bridges will collect data and extract all necessary information which is then converted into various feed formats like Atom or RSS.

RSS-Bridge is based on PHP and uses simplehtmldom to parse a website DOM to an object. What I needed to do was to write a bridge for Ko-Fi.com and parse the content. It sounds easier than it is. You see the content appears using JavaScript XHR requests, while it is broken into different URL paths.

But before that, I had to create a development environment where I could do the coding. I used Docker and created a docker-compose.yml file on my local system to build a container. At first, I did that on an Arm based computer and the first problem appeared. Although RSS-Bridge was working fine, I couldn't get any data, and the reason was that Ko-Fi.com uses Cloudflare CDN. This is something that a lot of people had issues with in the past. RSS-Bridge solves that problem by using a special build of curl that can impersonate the four major browsers: Chrome, Edge, Safari & Firefox. But unfortunately, that library doesn't work well on Arm-based systems, so I had to move to my trusty Intel-based Linux computer.

version: '3'
services:
  rss-bridge:
    container_name: "rssbridge_server"
    image: rssbridge/rss-bridge:latest

I used VS Code and the Docker plugins to get inside the container and do the coding I needed, so that they are reflected instantly on the browser, without the need to rebuild the container. I started reading the RSS-Bridge documentation and creating the first lines of the new bridge. All done pretty easily and sooner than later I had the basic code working. So now I had to parse the pages, which worked fine, having the DOM data available for me. But the main Ko-Fi.com page doesn't have all the posts I needed. I had to look deeper on the website and the HTTP requests it uses. Gladly found one that returns the latest blog posts, a few words from the intro and the main image. That's a good start, and after a few minutes fighting with the DOM I had the first RSS working. But there were some issues.

Firstly, the intro text was tiny, just a few words. And secondly, the post dates were all relative, in a way that after a few months in the past they were all the same, without being able to distinguish when exactly the articles were posted. Every post had a date like "3 months ago". Unfortunately, that information isn't available anywhere than the main article page. I decided to try and parse that one as well, and get a more accurate date and the first paragraph of the whole text. That worked great but made the parser a little bit slower because instead of parsing one page, it had to parse 30. So, I limited it to the last 10 posts to keep the parsing fast, and now it was ready for production.

I set up a Docker container on one of my servers. But how would I push that bridge inside the container? I checked the documentation and the official RSS_Bridge dockerfile and I discovered that there is an entrypoint script that checks the /config folder and gets any configuration and bridge file that it finds, copying them to the proper place. And that happens when the container is created. So I created a volume and put those files in a config folder in the host system. And since I use Traefik for reverse proxy, I added its labels at the end. I do not care for that to work with SSL, so I skipped those labels.

I rebuilt the container and everything worked flawlessly.

version: '3'
services:
  rss-bridge:
    container_name: "rssbridge_server"
    image: rssbridge/rss-bridge:latest
    volumes:
      - ./config:/config
    restart: unless-stopped
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.rssbridge_nginx.rule=Host(`rssbridge.walkero.gr`)"

But I couldn't stop there. Some kind of caching should be set so that it won't scan the Ko-Fi.com website on every RSS request and risk of getting my server IP banned. RSS-Bridge supports different ways of caching and I choose to use memcache which I set up in the docker-compose.yml file.

  memcached:
    container_name: "rssbridge_memcached"
    image: wodby/memcached
    restart: unless-stopped

Since everything worked as intended, I created a pull request to the RSS-Bridge repository and after a few hours my code was merged and now every public server will have a new Ko-Fi bridge for everyone to use. And since this is something I will use for myself, I will make sure to maintain it as long as possible.

RSS-Bridge is a great tool that anyone can use, self-host, expand and give back to the community so that we will help our online entity to be more free and expressive, reaching as much people as possible, without the need to be tied into a registration system.

If you have any ideas or proposals on how to make it even better, please contact me and I will do my best to make that happen. And if my work is useful to you, I'd love to hear about.

Oh, I forgot. My blogs' RSS feeds are:

This article was first posted at:
https://walkero.gr/blog/get-rss-feed-for-your-ko-fi-account

How to pick up a trusted Docker image

George Sokianos — Fri, 14 Aug 2020 18:16:25 +0000

You start a brand new project and you want to use Docker, but you don't know which images you should use? How to choose which image is the best one? Is it enough just to check the stars and the downloads on Docker Hub? If not, what else do you need to check?

Flexibility

Have in mind that you can use different images for your development environment and different ones for your production environment. Actually that's the recommended way to use Docker. Most of the times on development you need tools that do not need to exist on production, like the PHPUnit and Composer for your PHP projects, or the linters and Jest for your NodeJS projects. So you have to decide first the environment you need to support with that image.

For my local development environment I like to choose images that are flexible enough to change container's behaviour, with no need to edit configuration files in the container itself. For example, if I need to change the XDebug port or even totally disable it, I prefer to do it changing the docker-compose yaml file ENV variables. Also, I need to have root access in case I want to install a package and experiment with it.

For production of course, root access is prohibited and XDebug should not even exist. It is good to have the benefit to configure the containers, but this is not one of my decision points or a reason to not use a specific image. I prefer the containers to be more secure than flexible.

Security

Security on online applications, especially in SaaS systems, is really crucial and something you should take care from day one. For the containers I am going to use on production, I always check multiple factors before I choose the best image for the project, or decide to build my own.

First of all, I check if one of the official images, which are available on Docker Hub, can cover my needs. I tend to choose the lightest ones, with as less available software installed as possible, because more software means more possible insecure points. If this doesn't cover my needs I will try bigger images of the same organization until I find the one that works for me.

After that, I check how often this organization updates and applies fixes at their image. Is it often or once per year? Of course you wouldn't like to base you application on an old setup, rarely updated. After all, one of the benefits that you have using Docker is that you can pull the latest images whenever you want. You can even set it up to happen on every time you deploy. So why staying back with the OS or the tools you use?

You might think now that it is better to choose a light version of an official image and add what you need on top of that. And this might be the best solution, depending on the project and how many things you need to add. It is easy at the end to have a fat image with a lot of software as well.

Also, have in mind that you have to maintain your own image and create your a development process for this as well. At the end it becomes one more project you have to worry about. If you can automate the builds of your custom image, this is great. But when the newer version of the OS is released, are you sure that you are going to have the availability to update your own image? And what will happen if you have multiple images for multiple projects?

Non official images

Depending on the project you might need to use non official images. I use some of them especially for my development environment, and before I choose one of them to trust, I check the number of stars and downloads on Docker Hub, when was the last update and how often this is updated.

After that, I check the actual dockerfile on github wherever this is available, to see what exactly they do inside that image, and if I can trust it. Checking which image it is based on is also one of the necessary things to look for. If it is based on an official image this means that you can trust it more than any other. And while I am on github, I check the opened and the closed issues, to understand if the maintainer of the image actually maintains it or not, and what kind of problems people have.

These images are great for creating a Proof Of Concept or experiment on an idea, but they might not be the best choice for production. A check about the person or organization behind that image is necessary so to understand if they are trustful or not. I trust more an organization that has an expertise on Docker containerisation, providing solutions based on this technology and being available to support those images.

Lastly, using tools tools to check periodically the images for vulnarabilities is a very good idea. There are plenty of these tools out there. Lately I use Snyk, which I find really helpful.

Community

Docker has a big community right now and is used by so many developers every day. So, try to listen the community, read what developers write about the problems they solved and the solutions they followed. Discuss with them about the images they are using or even request their feedback on the ones you create. You are going to be surprised about how interesting things you will find from this process.

After all, developers adore Docker and love to discuss about.

This article was posted first at
https://walkero.gr/blog/how-to-pick-up-a-trusted-docker-image

Moved my blog away from Tumblr and here is why

George Sokianos — Fri, 17 Jul 2020 14:38:59 +0000

I started my blog site back in 2011, because I needed a place to write about my interests, my findings and the things that I love to use and do. When I created it I choose Tumblr to host it because it is something different, with a a few nice features, like the social character of the product, having your own domain free of charge (almost), being able to create multiple blogs under the same account, a selection of multiple themes and of' course didn't need coding to have it up and running.

But I am a software engineer, and as such I always wanted to make changes at theme's code, changing it a lot. After all these years Tumblr benefits didn't seems so attractive any more. A couple of weeks ago decided to move away from it and rebuild my blog from the scratch.

The framework I choose to build my blog is Grav, which is a flat-fle CMS based on Symfony and it doesn't even need any database to work. Everything is based on files, the configuration, the articles and of' course the theme and the assets. But I will talk more about Grav in a latter article, because this one is more about the reasons I decided to move away from Tumblr.

I don't like ads

What I first thought about the free features of Tumblr proved to not be so true. I hate ads on Internet, I really do. There are sites out there that have more ads than content. You visit a website and after you give your permission on 2-3 popups about I don't know how many cookies, like signing a contract to read an article, you end up hunting were exactly is the text you want to read and you afraid that if you click on a title might lead you to a totally different website.

So, after all this rumbling, you see clearly that I don't want my blog to have any ads. Unfortunately, this is something that Tumblr does add at your pages. Don't get me wrong, they were not so many, but I didn't want a single ad showing on my articles. And of' course not a single line of code that would track visitors. I think this is enough reason to move away of "free" platforms like Tumblr.

Socializing or not socializing?

The social character of Tumblr, were people are able to follow you or re share your articles didn't benefit me at all. Actually, I experienced the quiet opposite of it. My account was full of spam messages that I had to go through all the time. Until I decided to totally ignore them. So if there was any message of my interest, I surely lost it. I decided that I don't need that kind of socializing in my life. I have the accounts I need at the social networks I want to be, and if I need to attract more followers based on my content I prefer to share it on my own, with no platform to manage it.

Bad editors

Tumblr's editors are a big pain. There is no way to add your content other than the editors they provide. They have three different editors, one for markdown, one for plain text and one for HTML. The editors are really plain and through the years they changed them in a way that older articles were not compatible any more. Remember that my blog is 9 years old and when I tried to change something on an old article, most of the time I was losing a part of it. Even when I wanted to add an image in the middle, and I was using the markdown editor, I had to switch to html to add it. Adding code sources was also a pain and there were many times were I lost my code because of editor switching.

Maybe they are fine for simple articles, but for a technical blog this editing experience was not the best one.

Freedom

As a software engineer I need freedom to do whatever I want. On Tumblr I couldn't even add more social networks in my account, like the Mastodon one, because Tumblr doesn't support it. I had to hardcode it and also add an extra font icon, just to put a link in my blog, because theme's font icon didn't include it. Moving to an other framework would give me the freedom I was looking for.

I created a Git repo for the blog to host any changes in the code and the articles. Everything is there now, and because it doesn't need any database to work, makes the repo a full backup of my blog. I can even build a CI/CD process with Drone if I want to.

It took me less than 30 hours to create the new blog site with Grav, doing everything as it should be done. Created a child theme that was based on the default one, inheriting all the features, with no risk to lose my changes because of future updates. Added all the necessary configuration fields in the theme or in plugins, as Grav's documentation proposes to do and adapted the old design to the new framework, doing some extra changes I always wanted.

I am quite happy with the result and now my blog is as I wanted it to be. Free and awesome.

This article was posted first at
https://walkero.gr/blog/moved-my-blog-away-from-tumblr

Don’t treat Docker containers like Virtual Machines…

George Sokianos — Mon, 22 Jun 2020 12:44:03 +0000

I know, I know. It is hard to resist some times on treating Docker images like VMs. I totally get it, but I prefer to not do that. You see, there is no sense to put everything in a custom image, every server and every product you develop, with all their necessary libraries. And I will explain myself.

From a size point, you will end up with a huge image, probably more than a GB of size on your system, which will reserve a lot of space. And if this is the only setup, that’s somehow OK. But what will happen if you need to replicate that just to experiment with a new library or a new version of a crucial component? You end up with more setups and a lot of space reserved.

From a security point, huge images tend to have obsolete or unused code and libraries that no one updates because of the fear to break something. It is hard to experiment on updates, hard to rollback and maintain. Even the dockerfiles of these images tend to have hundreds of lines.

From a flexibility point of view, it is difficult to reuse the same images on multiple projects. As a result different projects have different images, strongly tied with them, containing different libraries and scripts. Also, it is hard to change one crucial component, i.e. PHP 5 to PHP 7, in a fast and easy way, without building the whole image from the scratch.

The solution of ‘course to all the above, and this monolithic image, is to use single service containers, based on images that do only one thing, and do it the best way they can.

So, if you are a PHP developer and most of your projects use PHP, Nginx, MariaDB, Redis, Elastic Search, Kibana, the next time you want to create a setup on docker prefer to use different containers for each of the above servers. Separate, i.e. PHP from Nginx and put the containers on the same network. This will give you the necessary flexibility to change, if you need, PHP or Nginx versions really easy, just by changing the image of the specific containers. All the other containers will be untouched, continue to work just fine.

And if you have multiple projects, that use the same technology, use exactly the same images on all of them. And in case you have to maintain those images, I am sure that even the dockerfiles will have much less code, and will be much easier to maintain, than the previous monolithic dockerfile.