I'm sure you know what Wordle is. The game got a lot of traction a couple of months ago when The New York Times bought it. I was playing it too, so I decided to create my version in my native language (Bulgarian). This is how duma.fun was born (in Bulgarian duma means word). And as usually happens with my "little" experiments, I didn't stop at just implementing the basics. I managed to translate the initial ~300 lines of code into a three months-long project. Here's why, what, and how.

I really like Redux. I Love its ideas. The reducers for example - small pure functions that apply changes without side effects are nice way to model the mutations in the state. Redux also teaches us to use the one-direction data flow which makes our apps more predictable and stable. These two things fits well for what we are doing on the front-end - building user interfaces.

Of course there is nothing perfect and Redux as every other library has its own problems. In this article I want to explore some ideas for new APIs that will help solving the problems that I encounter. I’ll be happy to see your comments below.

I like reading code of other developers. It’s a nice way to learn patterns, techniques and small tricks. Recently I found something about Array.prototype.length which caught my attention.

When CommonJS was announced we all thought “Finally something that will organize our code”. However, there are some cons that we should be aware of. It’s not only unicorns and rainbows. In this article we will see how a simple require line makes our code difficult to test.

I don’t think that we have to discuss the importance of having tests. That’s not something that we add to the project in addition. That’s something that the project is based on. And because testing is so important we have bunch of tools in our disposal. We all know (I hope) how to test our back-end code. However, once we move to the front-end is a bit different. At the moment we are working on a big single page application and testing is one of our main focuses. In this article you will see how to unit test our client-side JavaScript.

Us JavaScript programmers like to use words like, "event-loop", "non-blocking", "callback", "asynchronous", "single-threaded" and "concurrency". We say things like "don't block the event loop", "make sure your code runs at 60 frames-per-second", "well of course, it won't work, that function is an asynchronous callback!".

The replace method in JavaScript is pretty much the same as in the other languages. Replace part/s of a string with something else. However, there are some tricky moments and I wanted to write this article, because I met this problem several times in the past. Actually, very often I use my blog as a documentation for myself and this is one of those cases. Probably I'll be in the same situation after week or so and I'll just check here for the proper solution.

Maybe one of the best explanations of the prototype in the context of JavaScript language.http://javascriptweblog.wordpress.com/2010/06/07/understanding-javascript-prototypes/

The .htaccess file is actually a possible solution for this purpose. The problem with this approach is that the value of AuthUserFile should contain an absolute path. It also works with relative paths, but it is relative based on ServerRoot, which in most of the cases is different from DocumentRoot. I also didn't want to deal with sessions or cookies and after a short research I found the answer.