Side effect of struggling

I had a struggle with QList.add method - I extended the method so much I actually duplicated some ways of handling passed data. I was wondering how to describe it in the best way, so I created a yet another document for this very purpose.

During documentation I noticed I was wondering about how it will actually handle same scenarios and my solution was to create a small script, which will answer this.

It didn't take me long before realizing this was actually inventing a wheel, because this is probably what unit testing (and ultimately TDD, Test-Driven Development) is all about.

Unit testing is for testing many small pieces of software, like methods, from different sides, in different scenarios. You call the tested code with many different input values (in different states, when present), even - or better especially - wrong ones. You may have dozens tests for a single method. Then you compare code output with expected result and if it matches, the test passed. For wrong input you set try-catch block and in the catch part you check the exception for correct one.

Because of the vast number of tests, the process is often automatized and launched after build, before commit, after server/platform software update or something like that.

My example of an unit test (in pseudo-language):

// Tested method, defined somewhere else in the app:
bool isNumericString(string value) { ... }






// Test suite for the method isNumericString:

Array testResults = [];

testResults.push("Test 1: " + !isNumericString("test") ? "Passed" : "Failed"); // Unit Test 1testResults.push("Test 2: " + isNumericString("123") ? "Passed" : "Failed"); // Unit Test 2
try { isNumericString(null); } catch (ex) { // Unit Test 3
    testResults.push("Test 3: " + ex.Type == NullException ? "Passed" : "Failed");
}

// and do something with testResults, like check what test failed and do nothing if all tests passed.


In TDD you start not by coding the method, but with writing such unit tests. Of course they all initially fail, because the method is blank. You define expected results for all different inputs and then you start making insides of the method to pass all tests you initially created.

So I created a test suite, defined some test cases and made it compatible with QList, so it would be possible to visualize the output in a QetriX way. I also introduced com.qetrix.tests namespace.

Testing QList

I may finally get what it takes to do nice unit tests, which was probably the last big aspect of development I was still quite missing.

Cross Platform Satisfaction

I switched from PHP to Java after few months to add new features to Jetrix (Java QetriX :-) Those switches always hurt: different environment, different editor, different coding habit requirements, different debugging. But this time it was... different.

Even after quite a long time with PHP I didn't have much struggle, because core parts of QetriX has been already made and my current task was mostly to update converters, datastores and modules. And the only difference between QetriX in Java and PHP were in variable types - hints and "arrays".

This was my main goal with QetriX, to unify programming. I know QetriX isn't optimal and it even may take worse parts of each language, but ultimately it saves me time otherwise spend on Stack Overflow and it works quite well actually.

I know I mostly make rather simple CRUD stuff nowadays, but even than it's wonderful to see, that QetriX is capable to make it work smoothly only with general QView, QList and QForm components.

I've always tried to do the most optimal solution, but sometimes it's obviously pointless. On the other hand, QetriX is for me a nice way how to teach myself new languages in the futures. Perl? Python? Ruby? Well, probably all of them, one at a time.

Qules, Unite!

I've always wanted to make a computer game. I got my two cents by Ants (Mravenci), but I had many other ideas.

In my early programmer years I had a bunch of games in my head and after some time some of them started to be quite thinked out. Unfortunately I didn't have the skills to bring it to life, I tried and failed many times in many programming languages.

When a decade passed by with no signs of completing any of them, I decided to take good parts from all of them and put them into a single game, which I will finish. I thought about a perfect main character and decided to go with a simple sphere. It will be easy to make, with lower polygon count than person or creature (although a nice sphere is often quite hi-poly) and it can roll really fast, which can alter as a car ride.

In 2013 I attended MS Fest in Prague and saw Tomáš Slavíček's lecture about MonoGame (follow-up of dead XNA), so I gave it a try. It was OK, but still... making 3D game was beyond my skills. I kept it in 2D, but wanted 3D inside. MonoGame was exactly what I wanted and I started to see how complicated making of a 3D game is. Keeping the code small is absolutely impossible. The same problem I had with WebGL, which was a hot topic at that time.

I didn't want to use some pre-made 3D engine or game makers, because I saw some of them and they felt overcomplicated, with many features I probably won't use or need and will run slowly on some machines.

During that time I thought about a name for the game. I somehow decided all stuff I do will start with "Q" and I many, many years ago I felt in love with a name of an old Czech game "Koules" (for UNIX, OS/2 and Linux). It's plural of "koule", which means "sphere" in Czech. I like the fusion of a Czech word with English grammar. After many variations I ended up with "Quly" (and "Qule" for the spheres).

About two years after my tries with XNA my younger brother showed Unity. It was quite funny, when I described my idea of the game to him and he put the RollerBall Character into the scene, which was pretty much it :-) My first tries were OK, but I was quite lost and didn't really know how to do stuff. I was otherwise engaged at that time, so I decided to continue when Unity 5 is out.

The release happened few months later. I really appreciated YouTube tutorials, especially those from Unity team itself. Unfortunately, some of them still used legacy features, which has been often replaced by newer approaches in Unity 5. Later I often followed the tutorial and spend few hours of fiddling and tweaking, but ultimately (and often accidentally) found out it's legacy and therefore not recommended for a new game. Damn!

My brother gave me a nice jump-start and I started to build a learning version of Quly. I always do it this way, so I'm not affraid to mess it up, because for the real thing I'll start again from scratch.

Thanks to great capabilities of Unity I was able to concentrate on gameplay and features only. Many things are already made, like collisions, physics, vector maths and tons and tons of other stuff, so I didn't need to bother with them (for example in XNA I had to deal with all of them).

I realized how foolish I was for rejecting pre-made 3D engines. I'll never be good enough to make an optimized game engine by myself! There's such vast amount of things it needs to be done and of course done properly.

In Unity I simply make a short script, attach it to a GameObject and test it. It's really fast, straight forward and I love it! Also, C# is my favorite programming language and the system of scripts and stuff in Unity really suits me. And cooperation with my favorite 3D software of all times, Trimble SketchUp Make, puts me on cloud nine! :-)

Converters

I suspect converters to be my second greatest idea for QetriX after Particles. In the past, QetriX used Renderers for output in desired format (HTML, JSON...). You simply handed over an object, like QList, to a Renderer of chosen kind and you got the output. It was simple as that.

But I faced the opposite situation - I have a string in some format and I need to convert it to an object. Imagine FileSystem DataStore, the data could be XML, JSON, flat file etc. I don't want to have FileSystemXml DataStore, not to mention Xml is for Soap DataStore as well. And I don't want to duplicate the code either.

I tried to create "coders", with encode and decode method. Therefore I was able to call a DataStore, the output process thru a coder.decode, then create an object and render it. Maybe it sounds complicated but in fact it was quite simple. Just few steps to make.

Well... no. It didn't work as well as I expected and I didn't like the name - coders. So back to a drawing board. I was working on a HTML coder, when the obvious came. I was dealing with conversion of a HTML code to an object and back, which in many aspects duplicates what Renderers are for. But Renderers are one-way only and I need two ways.

Even Renderers were in QetriX from the beginning, the new idea was beyond that. I renamed coders to converters (convs for short) and created few basic ones, like QForm to HTML (qform-html), Wiki to HTML (wiki-html). I was particularly happy about the second one, because before that it was as an add-on library. This way it makes much more sense.

I'm even able to make converters like PNG to JPEG, XML to QList, Image to Thumbnail or Integer to String.

To be honest, I can see the concept (or architecture, if you will) of Converters may be fundamentally wrong, because most functions are in fact converters, like "Math.add" converts two numbers into one number (sum total), and input/output types are not consistent, which is difficult to manage and impossible to unite into e.g. Interface. I may think of some boundaries in the future though.