Why I dislike REST

From time to time "PR" words come to live and suddenly they become the "must use" by every developers. We got AJAX, we got Web 2.0, we got MVC and now lately we got REST. Maybe the order is not exactly as I gave it in this list, still those are the "keywords" people used a lot in the web development world. Doesn't matter which language / platform / framework used, if your soft wasn't using those keyword then it wouldn't be considered.

Here I'm already against those words, why? Because at the end of the day what counts is the functionalities your soft offer, not how it's implemented. It is more important that your software do what it is expected to do instead of "looking good on paper".

Let's concentrate on the REST word. REST is nothing else as an "idea" of having simple data access via HTTP. Think about a database, select would be done via GET, update will be done via POST, delete via DELETE, and insert via PUT. So basically we are all covered, we can do all the CRUD operations via HTTP! Great! Yet do you really want to offer full DB access via web? Well, for most the answer is no! At least we should authenticate the request, and already here there is no "standard". Sure you can send the auth via cookie or via a token passed on the URL. But what if I would like to add a "where" clause to my "select"? Oddly enough again there is no "standard" and it's actually not well considered too beside if you want to grab a single item based on the id. Come on, what if my interface offer more than a single id selection? Well out of luck either you develop your own solution or... you do the selection on the GUI side while transferring the whole answer. Now don't pick me wrong some REST frameworks do offer solutions for all those problems but there is no "standard" even if REST is not a standard.

But didn't we had before things like XML-RPC which offered ways to call functions with whatever parameters we would like? Or SOAP which would offer even a self describing API? Don't tell me those are complex to use, or verbose (due to XML), honestly in most case it's not an issue. For the complexity most frameworks do offer pre-prepared SOAP solutions (Java, C#, PHP, etc...) and the verbosity is a non-issue for most.

Where I do agree is that to call SOAP API via Javascript is not really all that fun, and for that REST is much easier. So why not try to combine the flexibility of SOAP and the easy to use of REST? That's what I did, let's call it a JSON / SOAP interface which let me develop simple C# classes with functions which can directly be called from JQuery.

Of course it is not "standard" as it's a self written solution, but don't come with this and try to sell me REST as it's not standard either, and even more you need to describe your API manually, while my own solution produce the documentation automatically with even test pages.

At the end, for me, it's more important to think about your goal, and what would be the best solution in the medium / long term instead of running after the last PR word which may very well end up with a useless tech.

Bug in chrome? Quite certainly

Again I fought against CSS, oddly enough this time it was Chrome which reacted oddly and the other 2 big did what I was expecting. I'm talking about the menu bar of my soft. When I was painting on a canvas within the page the menu items disappeared. Odd.

Yet I tried to create a small test set:
https://jsfiddle.net/9g11usuu/

And I must admit I failed. My test work as expected but not my page.

At the end I changed the positioning of the elements, and with a little of fiddling around I managed to get it working. Those things can be incredibly time consuming.

Again whoever say that CSS is easy is either under-estimating it or simply he/she didn't reached the point to see where things starts to be difficult.

Menu bar has been added

When you need many different actions and pack all them in a short space I still didn't found a better option than having a menu bar. Sure a menu bar within a web page is not what you usually see, yet when you design a single page application it tends to be a good compromise.

This shall allows to add nearly as many tools as we may need later on, while still not wasting too much space on the page.

The framework already can handle multiple "pages" and will load the content for it once needed. That should open the door to the next tool which will be the map maker.

Of course I still have a long road ahead, and don't plan to have a fully working product before a year time but it's slowly progressing.

Bad comments in a bug report? I got them too!

Today I got an "interesting" bug report from a guy here at work. He said that one part of my soft doesn't display values in the first row of the table:


The soft updates the cells in real time when the variables changes on the servers. As you may notice some cells don't have any values, and therefore for those like me not knowing the meaning of the variables it is not easy to debug the content of those tables. There is well over 700'000 variables overall in this system and clearly nobody knows them all.

I don't say there is no bugs in my soft but as always (sadly) any software will contain bugs. It's just a question of math, the bigger the soft is the higher the number of bugs you will have. To fix them you will need to check the soft. In my case I can't test all, because first I don't have the time for it, and second as said I don't have the knowledge and therefore I expect to get bug reports from the different experts.

The bug report I got however contained a little sentence which I could simply not accept: "Work without engagement". Sorry but such sentence is not something you want to hear for a guy like me which work like mad to bring all the wishes live.

My answer to his bug was: with such attitude you can find somebody else to fix the bug for you.

However I was curious and I checked what produced the bug. At the end it was a stupid mistake: checking if a value exists with a "if ( value )" is ok in Javascript however it will be false even if the value is 0 not only if it's null or undefined. So a bad if of my side.

Math formula which are more than useful

There are a few formula which can be quite useful and this in many different usage, from a brush shape to a "gain" function.

Let's start with something called "Sigmoid". It's a "S" shape like function which has the advantage to flat in / out. The formula for it is 1/(1+POWER(EXP(1),-X)) and look likes:



The next one which I use pretty often too is a "Gaussian" curve which can also be called "bell" curve. The formula for it is 1/EXP(X*X)



You have of course the well known one like X*X

X*X*X


SIN(X)


SQRT(ABS(X))


You may wonder when I use formulas like that, well, for example to reproduce movements, to make a movement more life like or to create more interesting transitions. For a programmer not knowing even a bit of math is simply not acceptable as at a some point he/she will need it.

Color chooser and brush settings

The tile painter is progressing and I finally went through a first implementation of a color chooser and the brush settings. It's certainly not the most user friendly interface but it does its job for a first release.

The brush is previewed with the current color (while a bit zoomed for clarity). On the side of the brush preview 2 sliders allows to change the size and the "smoothness" of the brush. The smoothness of the brush is still far from being perfect but somehow works.

Still a lot needs to be done before I can consider it as the tool for the first release but slowly it's going there.

I also need to think how I want to save the images, either in the database with the advantage of having all in the database (for backups for example), or keep the images out of the DB, or having images in the DB with a static copy outside for speed.

I also wonder if I want to implement layers inside my tile maker or not. Layers are not so hard to implement and would have the advantage of offering per layer effects, however saving the image would require to keep the layer info somehow.

When bugs are not bugs

Being a dev-op is by no mean an easy task, and if you do user support then at the same time you can't do development. Of course somebody need to support users, and of course a developer should know his/her product. However it doesn't mean it's the best choice for the company to have "one man shows".

Yesterday somebody called to report that he wasn't able to do some action. Sadly the action is not a simple "click and see what happens", so to reproduce and check what's going on it took me more than 1 hour. At the end it was because the data itself prevented (correctly) to do the action that the software wasn't doing it. I had to call back the user and say, sorry but it's the correct behavior and explain why. We then had like 20 min discussion about why it's like that and why it's not a good idea to change it.

That just stack up to the stress, take you away from your main job which in my case is developer, and overall frustrate me.

I wish companies would understand that dev-ops should not be the solution.