As you can clearly see from the other posts on my page, I’ve made a lot of things in the last few years. And I’m proud of having accomplished all those things… but particularly, of making Enmap.

The idea behind Enmap was fairly simple: add persistent storage to a Map object, and add methods to it that were useful, pulled from Array methods. The idea for the additional methods came straight from Discord.js’ “Collections” structures, but the persistence was something new. So back in June last year, I released a first version of djs-collection-persistent, in an effort to bring those two awesome features, together, for anyone using node. After a few months I have to admit, typing in djs-collection-persistent just got really annoying so I started thinking about a new name… for Enhanced Maps. So naturally, this became Enmap because why not! But why did I even make Enmap? What was the thought behind it? I pay attention to the recurring questions and problems that appear on programming servers I’m part of on Discord and one thing that popped up often was how to store various key/value pairs. User points, Guild settings, Tags, etc. Because most of the users that were asking these questions had very little experience with JavaScript and had never even touched SQL - asking them to install and use a database module and make their own queries was a pretty big ask. On the other hand, with my experience making Guidebot, then Komada, then Guidebot again, and a few bots inbetween, I’d gathered some basic idea of the structure needed to store, retrieve, and cache data in a meaningful, simple way. I knew that for the best performance, I could retrieve all the data on bootup and only modify it when it changed, reducing the database overhead while retaining the beauty of the Collections I was basing myself on. I wanted people to simply load up a database by name then use common, simple methods to interact with it without worrying about what was happening with the database behind. At the same time, I realized that in some circumstances, the persistent database I was using at the time (leveldb, which is a very performant key/value pair storage) wasn’t appropriate for all situations: indeed, it did not support being opened from multiple processes so anything using sharding or child processes couldn’t use it. I went to work separating the actual Enmap layer (the cache itself) from the storage layer (which I call providers) so I could easily produce multiple providers that people could use to connect to existing database back-ends. And now we’re at the point where Enmap is fairly stable, solid, and has 5 different providers: LevelDB, SQLite, RethinkDB, PostgreSQL and MongoDB, with more on the way. Most of these (except of course LevelDB) support sharding and child processes, and they’ve been tested for stability and performance. And I’m proud. Very proud. For the first time I feel like I’ve accomplished something useful above “some bot stuff”, something that I myself have and will continue to use in different projects. To the contrary of Guidebot and Komada, I have no intention of giving this away for someone else to keep maintaining. It’ll be around for a while, lemme tell you!

When I first started using Discord last year, I have to admit I wasn’t very competent in node.js. Sure I knew JavaScript, in fact I’d been more or less using it since I was 14 years old. When I learned that Discord had an API for bots and that it was possible to do awesome things with it, I got hooked. I proposed to the leader of an Overwatch guild I was on that I could probably make a pretty interesting bot for them, given a few months. And boy did I!

OmnicBot (obviously taken from the Overwatch universe) ended up having a couple of great features. Notably, it would “hoist” you to the top of the user list when you were streaming the game on Twitch. It had a nice tag system that served as an FAQ, moderation commands and various things like user lists and new user tracking and stuff. That bot, built in Discord.js version 8, was rock solid for 8 months, and even extended to cover a Pokemon Go guild created by the same owner. I was proud. Eventually however, the guilds sort of died down, I was on to better things than updating the bot (you know, like my Komada Framework!) so after so many months of faithful (and almost unbroken) uptime, I finally retired it. It now sits in the archives of my Github account, collecting metaphorical dust and pondering its preciously short existence!

About, oh 6 years back, I had a bit of an issue. I had a nice little front-end website that was actually just documentation for software my employer had. I was asked to enhance it in some ways, one of them being adding interactive menus so a user could switch between languages, versions, and modules. And a nice little feedback form to top it all off.

But the problem was that I couldn’t do this processing on the same server,While I did have php installed, it did not have a database nor could I add anything else to it. But then, JavaScript doesn’t like doing AJAX requests to another server. It complains about cross-site security. And, to be honest, I was still somewhat of a newbie when it comes to web servers, and front-end javascript. Sure I knew how to code, but the networking was little alien to me. In reality, had I not been such a noob I would have had 2 actual solutions: first, learn how to properly do cross-site requests using callbacks which probably would have been the simplest. Second, I could have just created a reverse proxy to redirect queries to my back-end server… But my brain went in a completely different direction: I created a proxy of my own, using php, which took the request and forwarded it to the backend, then took the response and threw it back to my front-end. I can hear some pros laughing at so many things in this in this description. C’mon a simple CORS request fixed using a custom PHP proxy, that’s ludicrous! But, I had little guidance, and I couldn’t find the right words that would tell Google to give me the correct information. So I digressed. Now, I’m a pretty big proponent for free exchange of information which includes most of the code I write in my life. So I put that shitty proxy thingy the now defunct Google Code, later to move it to Github. And wouldn’t you know it, that damn thing is still the most popular repository I have, with the only exception being the Komada framework (Which is actually now under a github organization, actually). With 60 Stars and 56 Forks, it sits comfortably at the top of my Github profile page. And, while I don’t maintain it anymore, I’m sure one of those forks is being maintained somehow! Go check out php-transparent-proxy and have a laugh at my ridiculous solution to a simple problem <3

I still remember the exact moment where I decided to create my bot called no-mention-spam. I woke up one morning and on one server I was on, I had 4110 mentions, and they were still going up. Thankful that I wasn’t getting these notifications on my phone in the middle of the night, I opened the server to find that it was being spammed by a couple of user accounts, each sending messages as fast as they could, at about 95 mentions per message. There was no moderator online at the time - they came online an hour after I had, finally banning and purging the spammer and clearing out their messages. But that day, the server was simply swamped with people wondering why they had so many mentions. It was absolute chaos, and it had to be stopped.

I thought to myself that it couldn’t be _so_ difficult to detect and eliminate this spam, right? so I did just that : I created a bot from literally 14 lines of code, pushed it to my host, and within a day I was on over 20 servers. All the bot did was ban anyone that sent more than 25 mentions in a single message. And holy crap did it work. Dozens of spam accounts started getting immediately banned from the servers I was on, and word spread that the method was effective and simple. But of course, spammers aren’t completely stupid, they’re just assholes, right? So they reduced their spam to 20 mentions per message, thinking that would work. Yeaaaaaah, no. After my initial commit, I immediately started improving on the base code that I had, and slowly turned no-mention-spam into a lean, mean, anti-mention machine. After a few months I had a configurable, precise bot that would take action on mentions over many different messages and I was on almost 1500 servers, protecting the masses. I still remember having a conversation with one of the spam accounts, wondering what could possibly motivate someone to do this. Apparently, it was some gobbledygook about politics and freedom of speech or whatever the hell. I didn’t learn anything that day, except that these spammers were really, really pissed at me. I had reduced their 5700-mentions-per-minute capacity all the way down to “get banned after 10 mentions” and they were really mad that I wouldn’t just let them spread their crap all over my favourite servers. All good things must come to an end however, and after 6 months I realized that I was barely getting one ban every couple of weeks, and yet I kept getting emails, messages and issues sent to me by people who didn’t understand how the bot worked. Basically, I was getting almost no real action but had to do a lot of management. I then decided to simply delete the bot, because it had become useless and an annoyance to maintain. I’m still proud of my accomplishment which include creating a simple yet powerful antispam bot, as well as massively pissing off idiots who would use these tactics to further some weird-ass political agenda. Lemme pat myself on the back, here. Interested in the end result? It’s on Github! Oh and the latest version is built on the Komada framework, too ;)

Picture this: I’ve been helping people make their own bots for around 5 months. Helping them with code, learning new things, figuring out all the things that make bots tick. And to help me out in my task, I have this great little bot called “GuideBot” which had a couple helpful commands such as one pointing to my discord.js bot guide. But I started to realize that GuideBot wasn’t just a bot for a guide - the bot was the guide. I had coded it in a way that was easy to read and understand, so I pushed it to Github, started linking to it as a great example of a functional bot code.

Birth of a Framework

Since it was easy to follow, it was also easy to contribute to - people started sending their fixes and updates to the code, contributing to the wonderful thing that was about to be. But there was a problem: people started actually using the repository as a base for their own bots but since the code wasn’t built as a module, it was impossible to update easily. It was necessary to change GuideBot into something more… and to rename it. I’m not one to brag, but I feel “Komada” which means pieces in Croatian, is a pretty good name! And so, I figured out how to make it useable as a module, threw it on NPM, and this wonderful framework was born!

Contributors are Awesome

I am certainly not alone in my endeavour to make a great framework. In fact, the team of contributors that amassed over the last 7 months have done impressive work building upon the foundations that I layed out. And, while at the end of last year I devolved into a detached, depressive state, the team not only picked up the slack but went quite over the call of duty. At this point, it’s clear that I’m no longer in charge of the framework I started - which is a relief since I’m no longer able to work on it.

What is Komada?

Komada is a modular bot framework created for Discord.js bots. It’s completely “plug-n-play”, and doesn’t take much time to set up. Some features:

• Completely Async/Await w/ super fast load times.
• Fully-Customizable parts: Each part of the system can be overridden with your own code!
• Per-server extendable configuration system
• Customizable Command System with easy argument setup, reloading and downloading for live code changes
• Monitors that watch every message to react to them (swear filters, spam protection, etc)
• Inhibitors that prevents commands from running (such as permissions, blacklists, etc)
• Internal functions accessible anywhere in your code

Why use a framework instead of making your bot from scratch? Because you’re going to run into all of the problems that we did while writing it. How do you handle permissions? The help system? What’s the best way to create a command handler? How do you handle events, messages that aren’t commands, blacklists, whitelists, etc etc etc. These problems are solved for you in the most meaningful manner which lets you concentrate on why you really want to make a bot: To actually make a bot! We leave the commands to you while providing all the basic amenities you’ll be glad you don’t have to deal with.

How to get it and use it

Since my background is in technical support and technical writing, it would be logical that the documentation is probably one of the best parts of Komada. Indeed, you can visit Komada.js.org to get all the information you need in order to install, setup and extend Komada. So get going! Go forth and make awesome bots for Discord!

For someone who’s been using the :nauseated: emoji every time someone mentions “php”, and who’s been working with node.js exclusively for over a year, I’d turn towards node.js for a CMS or blogging platform… And you’d be wrong.

All the platforms I’ve seen lack the depth and power that Wordpress has achieved since it was created. And, for all the programming I do in my every day life and free time, I really can’t be bothered to take hours and days to setup a system that’s imperfect, and then another week trying to make a theme. Sure I hate PHP but I actually don’t really need to touch it here. So, here we are. Hi, Wordpress! Long time no see. Don’t piss me off, and we’ll get along fantastically!