I decided to ditch Hashnode and set up a WordPress blog on my own again. I may or may not use it more actively in the future.
I like the idea of ditching Twitter for my own blog again.
I decided to ditch Hashnode and set up a WordPress blog on my own again. I may or may not use it more actively in the future.
I like the idea of ditching Twitter for my own blog again.
Imported from Twitter
Imported from Twitter
Imported from Twitter
Imported from Twitter
Imported from Twitter
Imported from Twitter
If you know me, you might know that I have big sense of preservation. I’m a big fan of collecting video games for that reason, but it also applies to something else. I follow a lot of Twitch streamers and love watching their content, but one thing I really dislike about Twitch compared to YouTube, is that stream archives (“VODs”) are only stored for 60 days (for non-partners even less). This is a huge issue for someone like me who likes to go back to older content from time to time and re-watch older livestreams.
This is an issue I am currently trying to solve for myself and today I built a small tool that will probably help me a ton in the greater scheme of things.
My current solution to this was a small VPS I set up to download Twitch VODs and render them together with the chat using an open-source tool called TwitchDownloader. The developer of that tool kindly provided me with their own solution to rendering chat and video together, so I didn’t have to figure that out.
However recently I faced a new problem with this little make-shift solution: disk space. So far I had just downloaded the videos to the VPS and left them there because moving files this big around is a hassle. Now that the disk space is reaching it’s limit I was forced to come up with a quicker solution.
I have thought about setting up my own personal storage servers for this but that’s something that will take a bit longer to do properly, so I chose Google Drive for storage. I am on a Google Workspace (formerly G-Suite) plan which allows me to store a ton of files and not having to worry about disk space running out. Additionally, Google Drive processes video files so I can even watch these archived livestreams directly from their UI, without having to download them to my computer first.
Which is the reason I created my google-drive-upload-cli. A simple Kotlin-based CLI tool to upload large files to a Google Drive account. I had previously tried multiple existing CLI tools for Google Drive, but ran into issues with almost all of them and since Google doesn’t offer one themselves, I was forced to do it myself. The only alternative would’ve been downloading all of these files to my personal computer and then uploading them through the Google Drive UI, which would basically make my computer’s internet connection unusable for days.
I chose Kotlin since it’s a language I’m familiar with. I pretty much replaced Java with it entirely and it allows me to start a project quickly and get to programming. I had previously looked into how easily I can make something like this and found this StackOverflow answer. Seems I wasn’t the only one looking for quick and easy solutions to this problem. All I had to do was wrap all of that into a solution that refreshes OAuth tokens and I was almost done. For resumable uploads of bigger files, I borrowed an existing Java class that somebody had created a while back.
Now I added my little CLI to the existing scripts I had on my VPS and my solution is almost automatic. In the future I would like to upgrade this even more. I’ve had the idea of a web tool where I can just dump any link and it will automatically download and store the video for me for a while. Maybe I’ll get to that one day. For now, I can safely store and Twitch videos and not worry about them being lost.
It wasn’t a big project but it was fun to work on something open-source again, I haven’t done that in a while. I don’t know if I will continue working on this tool specifically, since it was just made as a quick solution to a simple problem. Maybe I’ll add something like support for uploading entire folders, who knows.
You can check out the source code on GitHub.
My name is Zeryther and I am the creator, developer and maintainer of the Yoshino Chat Bot. I have not given an update on this project in a long time and there seem to be many people wondering about the status of this project, so I have decided to write this blog post to give a final update on its status.
The Yoshino Chat Bot is a project I started back in December 2017 as a Twitch bot for my favorite streamer at the time. I soon realized I really enjoyed creating a chat bot of this sort and focused most of my time on it. In January 2018 I released a Discord version of the bot as well. I spent most of my time in 2018 developing this bot and managing it’s community which was a lot of fun. The bot started to grow a lot and even reached 5,000 joined Discord servers and 200 joined Twitch channels at a certain point, being one of my most successful projects at the time.
For a while a YouTube version was live as well, however managing this one was not nearly as much fun. YouTube’s live chat feature was very limited and I was unable to include any substantial features of the other versions. Additionally it was heavily rate-limited which gave me a lot of headaches. At some point in 2019 YouTube even shut down Yoshino’s API access entirely, without ever giving me a reason for it. This was one of the reasons the Discord version has always been the biggest focus.
Shortly after releasing version 1.7 in 2018 I decided a major revamp was necessary. I was dissatisfied with the code structure and performance, so I decided to re-create the bot from scratch in a version 2.0. In January 2019 I started my first full-time job which prevented me from working on this project too much. This and poor management of the project led to the version 2.0 update being cancelled eventually. I have not worked on Yoshino since then beyond small patches to the production version.
However those small patches were not enough either. The production version of Yoshino was suffering from a lot of crashes and bugs which were too hard to fix because I was missing the time and the code structure was too confusing and poor and an entire re-code would have taken even more time. Eventually the user numbers started decreasing and I stopped managing the bot too much altogether. Multiple Discord bot-lists have delisted the project by now as well.
There was a time where I considered selling the project to a company which I am not going to name here. This idea was shelved pretty quickly as my communication with that company was very poor and I never received quick nor concise answers. I don’t like the idea of transferring the project to simply anybody either. As I mentioned before it would be easier to re-create the bot.
I deeply regret this decision because I really liked my time with the project but the Yoshino Chat Bot will be shutdown permanently after the publication of this blog post. The project is stuck where it is now and there is no time for me to manage it anymore, nor do I think it is really worth it.
I am now self-employed with my own company Gigadrive and I would love to start a community management bot project at some point but right now it’s just too big of a project with too little resources available.
I would like to thank everybody who has been involved in this project over the years, as well as all of the people who were still supporting it to the end. I hope you understand why I had to make this decision.
The chat bot and web dashboard will be shutdown and are no longer available for usage. There are many other great Discord bots out there, I am sure you will be able to find a great alternative!
The support Discord server will stay available for now. It is largely unmoderated and unmanaged but it’s still the only way to connect to a lot of people I started calling my friends and deleting it would feel like removing all the history of the project.
For now, the software code will not be made public. While it is owned by myself only, I do not think it would serve much purpose. The only versions available are the messy version 1.7 and the unfinished version 2.0. I have seen some people ask me to make it open-source to help them with their own projects but I don’t think you would gain much from this.
If you want to keep up with me or my other projects I would be very happy if you follow me on Twitter. I am still working on a lot of stuff and maybe I will find the time to create a new chat bot at some point.
Thank you for reading this pretty long article and your continued support.
Zeryther
Creator of the Yoshino Chat Bot
Last week we released version 2.0.0 of qpost, our open-source social microblogging network. In this blog post I want to detail what we have planned for the future of qpost and what’s coming next.
Public API (#25)
With qpost’s re-release we have been working on a public API. This API is currently being utilized by the new front-end, however it uses session tokens for authorization. We want to add an alternative, which allows third-party developers to register their applications with us and authorize users without the need of them submitting their username and password.
I personally am really pushing for making the API public as I want to welcome more third-party developers on qpost and turn it into a platform. I used to be a very active Twitter user and always enjoyed working on bots, that post images from reddit or other platforms automatically, and so did a lot of other people. I think if we manage to bring bot developers to qpost and support them, this could help boost the amount of varying content on the platform by a lot.
Further backend improvements (#22)
Currently we use HTTP polling for automatic fetching of new posts and notifications on the front-end, a technique we have taken from the first version of qpost. In the future, this is supposed to be replaced by a socket server, that automatically notifies the clients of new events happening. This replacement will significantly reduce the strain on our servers and allow users to receive posts and notifications in real-time.
Messages (#23)
Messages are a basic feature, that has been planned for qpost ever since it’s first release version. We want to allow users to communicate in any way they want. If you want to send a quick message to someone, you should be able to do that within qpost. Messages have been on the backlog for a very long time, because they depend on the previously mentioned issue (socket server). We did not want to use HTTP polling for messages, since it would drastically impact the experience.
Smartphone applications
Apps for iOS and Android are something that has been planned for a long time as well. We want to release qpost on their respective platforms, to open it up for more users more easily. This issue in particular will take more time, until then you can use qpost as a progressive web app to use qpost on your smartphone.
We have many more things planned for qpost in the future. You can read more about it on our GitLab issue list.
Beyond our actual app features, we also want to spend more time marketing and growing qpost to have more users on the platform.