Some useful links for JS coding

Few nice things to use in close future:


A fast, simple and self-hosted backend as a service for your (web) apps, Open Source and free. No need to write server-side code or database schemas. Makes building offline-capable software a breeze.


Get safety & consistency with real-time monitoring and automatic upates for npm dependencies.

Reduce CSS bundle size by cutting class names

This is pure awesomeness! Gajus Kuizinas went beyond asset minifiers which resulted from 140KB to 53KB CSS size decrease.

There is one thing a minifier cannot do – change the selector names. This is because a CSS minifier does not control the HTML output. Meanwhile, CSS names can get long.

All the details are in the post worth reading, if still think that webpack can only merge JS files in a bundle.

JSData as ember-data alternative

Weekends are normally for RnD time, so this weekend’s topic – standardization of front/backend communication. Considering backend as API-only and fully offloading the rendering part to JavaScript frameworks, EmberJS had a really nice concept of ember-data that acted in between rendering components and backend objects received via API. Another alternative can be considered as JSData:

SData is a framework-agnostic, datastore-agnostic ORM (Object-Relational Mapper) for Node.js and the Browser.

Adapters allow JSData to connect to various data sources such as Firebase, MySql, RethinkDB, MongoDB, localStorage, Redis, a REST API, etc. With JSData you can re-use your data modeling code between environments, keep your data layer intact when transitioning between app frameworks, and work with a unified data API on the server and the client. JSData employs conventions for rapid development but allows for endless customization in order to meet your particular needs.

Considering the use of JSData with JSON-API standards, there’re couple of adapters that transpile JSData to JSON-API.

CakePHP with NightwatchJS on Travis CI

After the release of Headless Chrome browser (v59+) most of the automation tools slowly started reducing the usage of Selenium, by replacing it with the combination of chromedriver + chrome/chromium pre-installed browser (like Travis CI does on their images).

As a replacement, I’ve tried playing around with the combination of Karma/Chai to test JavaScript functionality of certain projects we have in Qobo, which went well, but it only introduced the unit test approach towards the code base. What I wanted was user automation, emulating browsers Page Object Model (POM). The choice fell on NightwatchJS library that works with headless Chrome and needs only minor tweaking.

Setting up NightwatchJS

I’ve used a combination of NightwatchJS with Mocha test framework, but Nightwatch itself has a good support of assertion methods to do some basic checks on the browser requests, but first things first.

We start with package.json for Yarn/NPM.

  "devDependencies": {
    "chromedriver": "^2.31.0",
    "mocha": "^3.5.0",
    "nightwatch": "^0.9.16"
  "scripts": {
    "test": "./node_modules/nightwatch/bin/nightwatch"

yarn install and proceeding with nightwatch configurations:

const chromedriver = require('chromedriver');

module.exports = {
  before: function(done) {


  after: function(done) {


After we explained the library how to handle chromedriver, we set the configurations for nightwatch.json:

  "src_folders": ["tests/Frontend"], 
  "output_folder": "build/coverage/",
  "custom_commands_path": "",
  "custom_assertions_path": "",
  "page_objects_path": "",
  "globals_path": "globals.js",
  "selenium": {
    "start_process": false
  "test_runner": {
    "type": "mocha",
    "options": {
        "ui": "bdd",
        "reporter": "list"
  "test_settings": {
    "default": {
      "selenium_port": 9515,
      "selenium_host": "localhost",
      "default_path_prefix" : "",

      "desiredCapabilities": {
        "browserName": "chrome",
        "chromeOptions" : {
          "args" : ["--no-sandbox", "--headless", "--disable-gpu"]
        "acceptSslCerts": true

NightwatchJS still uses selenium_` naming options in the configurations (for backward compatibility reasons), so don’t get scared by the naming.

And the final touch, testing login action:

describe('Testing login UsersController::login() method', () => {
    var loginUrl = 'http://localhost:8000/login';

    before(function(browser, done) {

    after(function(browser, done) {
      browser.end(function() {

    afterEach(function(browser, done) {

    beforeEach(function(browser, done) {

    it('gets [login] page', (browser) => {


    it('trying to [login]', (browser) => {
            .waitForElementVisible('.login-box', 2000)
            .setValue('input#username', 'username')
            .setValue('input#password', 'password')

Running yarn test you should get something like this:

running nightwatchjs with yarn

NightwatchJS on Travis CI

Last but not the least – configuring Travis CI to run NightwatchJS on a PHP distro image. The config is partially pasted from project-template-cakephp , (pull request #340 with NightWatchJS).

sudo: true
dist: trusty

language: php

    - 5.6
    - 7.0
    - 7.1
    - nightly

#enabling NodeJS
  - "7"

#setting up stable Chrome, which has headless support 
#out of the box
  chrome: stable

#caching Yarn and its node_modules
  yarn: true
    - node_modules

# installing JS packages and starting up the server
    - yarn install
    - ./bin/phpserv >/dev/null 2>&1 &
    - sleep 5

# once you're done with PHPUnit/PHPCS,
# it's time to check the UI with `yarn test`
  - ./vendor/bin/phpunit --group example
  - ./vendor/bin/phpunit --exclude-group example
  - ./vendor/bin/phpcs
  - yarn test


ReactJS: BSD + Patents licensing model

The devil is in details, so people say. Few months ago, while working on prototype of cakephp-calendar, we had an interesting debate over front-end stack for Calendar component. At the same time, in parallel, WordPress community was buzzing about their text editor – Gutenberg whether to use ReactJS vs VueJS libraries. One of the reasons of choosing VueJS, was licensing agreement.

The license granted hereunder will terminate, automatically and without notice,
if you (or any of your subsidiaries, corporate affiliates or agents) initiate directly or indirectly, or take a direct financial interest in, any Patent Assertion…(c)

Investing man-hours into VueJS research and prototyping was right, especially after Raul Kripalani published an interesting article on the license review of ReactJS.

Updated: One more review of FB React JS licensing from WordPress Tavern.

VueJS watchers for MomentJS

It took me some time to figure out what’s been going wrong with the watchers working on datepicker integration for CakePHP-Calendar plugin.

Problem domain:

On loading modal window for creating calendar event, one of the dropdowns pass default start/end time for the event interval (start/end dates). This config object is passed to as a property into interval component that contains two child datepicker components.

Whenever the config property changes, it adjusts startMoment and endMoment objects and passes them into datepickers. The change is monitored via watch functionality of VueJS.


Vue.component('interval-holder', {
    template: `<div>
        <datepicker :date-moment="startMoment"></datepicker>
        <datepicker :date-moment="endMoment"></datepicker>
    props: ['config', 'initialMoment'],
    data: function() {
        return {
            startMoment: null,
            endMoment: null
    watch: {
        config: function() {
            this.startMoment = this.initialMoment;
            this.startMoment.set({'hour': this.config.start.hour, 'minute': this.config.start.min});
            this.endMoment = this.initialMoment; 
            this.endMoment.set({'hour': this.config.end.hour, 'minute': this.config.end.min});

Vue.component('datepicker', {
    // value var is useless here, as we use daterangepicker from jQuery 🙁
    template: `<div>
        <input type="text" :value="value"/>
    props: ['dateMoment'],
    mounted: function() {
        var self = this;
        //load jquery bootstrap-datepicker instance
        this.instance = $(this.$el).find('input').daterangepicker().data('daterangepicker');
        $(this.$el).find('input').on('apply.daterangepicker', function(ev, picker) {
            self.momentObject = picker.startDate;
            self.value = picker.startDate.format('YYYY-MM-DD HH:mm');
    data: function() {
        return {
            value: null,
            momentObject: null,
    watch: {
        dateMoment: function() {
            this.momentObject = this.dateMoment;
            this.value = this.momentObject.format('YYYY-MM-DD HH:mm');

If we set hours and minutes the following way as in the example above, dateMoment watcher won’t catch the change. According to the docs, it’s adviced to use deep param:

To also detect nested value changes inside Objects, you need to pass in deep: true in the options argument. Note that you don’t need to do so to listen for Array mutations.

watch: {
    dateMoment: {
        handler: function(val, old) {
            console.log('dateMoment changed');
        deep: true

Still no luck. Apparently, MomentJS object “too deep”. The only way to get it working ended up like this, change the parent component moment objects assignment, keeping the child-component watch function unchanged.

watch: {
    config: function() {
        var newStart = moment(this.startMoment);
        newStart.set({'hour': .., 'minute': ..});
        this.startMoment = newStart;
        //create a new instance of newEnd and assigning it to this.endMoment
        // get the dateMoment observe the change.
        // Ugly? Yes. Working? Yes..

If anyone has a better (more elegant) way to fix this issue – welcome in the comments section! 🙂


ES2015: Refresher on modern JavaScript

A quick lookup on modern JavaScript and whole Babel thing. This will be a start of a small research on splitting frontend and backend implementation for CakePHP framework and its plugin.

JavaScript – technological singularity & younglings effect

On March 2017, Eugene Gusev had an interesting talk (in Russian) at HolyJS regarding the technological singularity as whole in Front-End, and JavaScript ecosystem in particular. As a thesis taken, he noted an enormous number of 350k packages in NPM.

Few points being stated over the talk:

  • Quality of the packages (aka younglings publish low quality tools)
  • Hype over the ecosystem (frameworks and libs go up and down in popularity scale).
  • Business forces the choice, leaving minimum time on technical decision-making process.
  • Stop writing code, or “stop publishing your code”.
  • In order to program you should be a computer scientist.

All the points are quiet controversial. Though, accepting some of these statements as a potential problem, most of them have a reasonable explanation.


Back when the trees were tall and the grass was green, I graduated my BSc in Computer Science, I’ve started working as a Junior Web Developer. By that time, a programmer who knew only JavaScript, or solely was coding on Perl/PHP/Python was considered lazy/unemployed/unicorn. The time flew by and the industry started splitting technological stack, so from Programmer/SysAdmin we forked into Front/Backend developers, SysAdmins to DevOps etc.

University, really?

We still have certain professions that require an educational degree. By paying for your education, you’re prompted to access research laboratories, expensive equipment that’s required for your research. Think of physicists or chemists. Stating that diploma (for Computer Science) somehow justifies your profile, or what you should be doing for living left behind with the era of industrial revolution. “The spice must flow” – that’s where we get into the almighty Internet for self-education. Udemy, Coursera – it’s right there, most of it is free, just read it, learn it.

Technological Singularity

Technological singularity is a hypothesis that the invention of artificial superintelligence will abruptly trigger runaway technological growth, resulting in unfathomable changes to human civilization.

Are we there yet? Yes, we are. It just arrived silently. Clustering professions to narrow the specialization is one of the countermeasures to prevent the informational noise that we get once diving into IT-sector. That’s where we step into Hype effect.

Hype Effect

Hype Cycle diagram
Hype Cycle by Ember in the Real World

350 thousand package in NPM. That’s massive, but hold on a minute! CPAN didn’t have the same issue in Perl community? PEAR and Pecl repositories stacked by repetitive packages, written by people just because they could. And they did! Every year, some big player like Google, Facebook, name a few, presents a new approach towards a common problem. Angular, React, EmberJS, VueJS. It automatically triggers a hype.

Architects in the companies start massively migrating to trendy frameworks, as it’s backed up by one of the above companies, which promises stable development, stable versioning and ongoing support. We get a drastic shift of packages developed for these frameworks. And the story continues until something new arrives on the market.

As companies do not operate in vacuum, all these transitions correlate with business decisions. Packages appear in almost-ready-to-us state, and remain loosely maintained just to get your npm/phake/rake running smoothly during the deploy process.

Packages & Plugins flood

Slowly the picture of 350k packages come into place. Each of the packages is a reflection of a person behind it and the problem he or she was trying to solve. Good solutions become trendsetters itself, become community defacto standards. What happens with others? – Well, it’s a pure darwinism, which triggers professional boost among the developers.

To sum things up

Your knowledge derives from those who dared, and published something. If you cannot choose out of a hundred packages one or two that might fit in your application, maybe you should question yourself what exactly you trying to solve? Diversity of approaches in IT and its openness is our strength. You found something wrong, write a bugreport, or send a pull request. The rest is just excuses in most of the occasions!

Office 365 – test trial is over, back to Google

I’ve been using Office 365 for office correspondence for about 7 months, since I moved to Qobo. Today I say enough to Office365 corporate lookalike email client. Everything is back to Google.

UX experience

One of the things I couldn’t get used to is the right-click bindings. I guess the assumption was to enrich the functionality of the interface by letting you move/delete assets on your sidebar (aka folder management). As the result – half of the browser daily routine is cut off. Most of the time my main working tool (apart of the vim) is the browser (webdev happy days!).

When someone screws up the shortcuts that I use gazillion times per day, it kind of annoys me. Who would have thought to replace Ctrl-R to “reply” shortcut for “refresh“. Ah, bollocks, moving on!

Focused/Other/Pinned emails. Pinned email go to the top of the list. Focused follow right after. Others – somewhere at the end. 6 emails fit into my laptop screen height, so you can get an idea, that the number of pinned or focused emails is quiet limited. I guess, I’m too old school to get these things right!

Search & Filter. Google Email search and filtering is unbeatable. Period.


CakePHP: Interview with Larry E. Masters

Interesting interview with one of the core members of CakePHP community – Larry E. Masters.

Throughout the interview Larry covers CakePHP Framework history, as well as covering major milestones of CakePHP 3.x version. If you’re still into 2.x – it’s time to upgrade, as it brings some nice perks, more flexible code, and massive performance boost.