I discovered Mavo and nothing will be the same now!
I discovered Mavo and nothing will be the same now!
This is not a complete analysis, but only a vision on IT services which I am responsible for my Company. So it cannot be taken as an analytical documentation, but only as an experience on my working field.
I am running many machines with MEAN stack (MongoDB+ExpressJS+AngularJS+NodeJs) on our corporate Amazon AWS cloud servers and some machines based on traditional LAMP stack (Linux+Apache+MySQL+Php). In the latest months the developing effort of the Company was basically phagocytized by NodeJS fixes, with only a very few activities made on Php. We have to consider that now the Company where I work has 6 main softwares and only 2 of them are made on Php.
Normalizing the effort-per-service and leveling their importance and complexity I could find the following differences.
Activities on Php required some hours/man or sometimes minutes to be performed; on the contrary, bugfixings and similar activities on Node required days or weeks/man to be completed.
Building new simple functionalities costed some hours/man on Php, and days/man on Node.
Comparing two very similar servers where I run services that should perform in the same way, I could find the following differences. NodeJS server compared with Php server (same type of machine and same amount of average requests per 5 minutes) with installed 2 similar softwares (in terms of activities: DB connections; data elaboration; size of outputs):
The Php machine stays always under 1% of CPU
The NodeJS machine has many peaks over the 5% and sometimes reaches 15% of CPU.
See the attached images
I can conclude only what I suspected for years now: Node is still a technology that is not optimized and is still CPU consuming (and “man” consuming!).
It still needs much more maintenance than monolithic stacks, and also the dispersion of packages (npm modules) and the sometimes useless complications make the work on it much more complicated than on Php.
But this is the direction the World is moving on now, so we need to accept this evil that would be completely unnecessary, but that is growing so fast that you cannot avoid using it. And I have to say: unfortunately!
This is a small tone selector with the ability to change the frequency by a potentiometer and to see the result on a 16×2 display. It also has an automatic testing mode at the beginning.
Continue reading “A Tone Generator with LCD Display!”
Bye Bye Flash… again? Yes, but this time seriously!
It was a long time ago when we heard about “the end of Flash” on our browsers.
But it simply never happened. Chrome and Firefox continued to support this technology.
Then Firefox stopped it last year (also if nobody cared about!).
Now it looks like the real end is finally arriving: the reason? It’s called “the power of Google Chrome“.
When they decide it, it’s gone.
So it is arrived, the so dreamt/feared end of native support for Flash on Chrome.
From version 55, Chrome starts to block Flash by default: if you want it, you need to enable it from the Chrome “flags” (chrome://flags/).
What does it mean for a common browser user that never opened the chrome flags? Simple: the death of Flash based technologies such as some video players or many web games or some (hopefully!) websites.
You were a good friend.
You are trying to solve a big issue with Amazon S3 Bucket Policies and click… StackOverFlow shows a “maintenance” page!! That’s the biggest nightmare of any programmer.
I have many reasons why to avoid the use of Node.JS for enterprise solutions (webservices, websites, etc.), but I think that the following one is definitive:
Let’s see the following example scenario:
Our Node.JS application (myapp) is a simple web app (it doesn’t matter which framework we use) that responds to the following 2 URIs: /myapp/test1/ and /myapp/test2/.
Those URIs are managed by two specific controllers: controller1.js and controller2.js.
Only controller2.js is bugged and so when /myapp/test2/ is requested by the browser it causes a fatal error.
Where’s the problem? Every web application works like that.
Yes, it is. But no other “old” application such as Php would crash within the single script error!
Let’s understand that also the other URL (/myapp/test1/) that contained the not bugged code will be unavailable within the node server crash. Unlike Php applications that will continue to correctly work if there is a single script with a fatal error.
I have many other reasons for thinking that Node.JS is just a toy, and not a professional tool, but I think this issue is one of the worst behaviours I could have ever found in a modern programming language.
Some interesting articles on the equivalence between node.JS and EVIL:
During the last two working days I spent much time trying to solve a very insidious and never-seen-before issue in WordPress. Continue reading “MySQL collation errors using WordPress”
I am exploring new frontend web frameworks to substitute the glorious BOOTSTRAP that I consider a bit old and lacking of innovative features for my purposes. In particular I am analyzing if FOUNDATION Continue reading “Foundation frontend web framework”
I am a lucky owner of a cheap but powerful Korg Pandora STOMP multieffect for guitar. This is an awesome one-footswitch with great effect chain modeling software. Continue reading “Korg Pandora STOMP MIDI reverse engineering”