Page 2 of 28

Docker: access host database from container on Mac

With things like homebrew you kind of forget that you’re not on Linux, and some things might actually work differently. Trying to connect to a host database server from the container using didn’t work out.

After few hours, figuring out that everything’s setup right, you’re not going crazy, you stumble upon this note:

The host has a changing IP address (or none if you have no network access). From 18.03 onwards our recommendation is to connect to the special DNS name host.docker.internal, which resolves to the internal IP address used by the host. This is for development purpose and will not work in a production environment outside of Docker Desktop for Mac.

The gateway is also reachable as gateway.docker.internal.

And everything works like charm:

[root@e70e59cdb3c3 /]# ping host.docker.internal
PING host.docker.internal ( 56(84) bytes of data.
64 bytes from ( icmp_seq=1 ttl=37 time=0.951 ms

[root@e70e59cdb3c3 /]# mysql -u root -h host.docker.internal -p
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 350

SVG libraries worth checking

VueJS Plugins: developing with HRM

I’ve never being a fan of keeping backend and frontend codebase together, though some of the well known project achieve it quiet well like Discourse.

Keeping JavaScript aside for backend solutions, as part of standalone UI elements seemed as decent solution. But when you have to develop Vue components as plugins and keep the project running – testing becomes messy.

I spent half a day trying to figure out the ways how you can use symlinks to pick local packages to work in dummy VueJS app, but no luck. Both for yarn and npm. There’ve been a long story of resolving these issues for numerous packages like here, or here.

Simple solution with mocking an App behaviour with a sprinkle of chokidar package solves this problem. Well, at least to some extend:

  • You can independently develop Vue Components as plugins
  • From the box testing
  • Once e2e and unit tests are done, you can publish and integrate these plugins in to your application.

Hot Reload for Development environment

First things first – tools being used:

  • vue: 2.9.6
  • node: v10.16.0 (LTS)
  • yarn|npm: whatever make you happy!
  • webpack-dev-server: ^3.7.2

Build instructions are split in 3 parts (base, dev, prod). I’m using webpack-merge to overwrite base with required instructions, depending on the yarn command:

//package.json part with live reload instructions
"scripts": {
     "serve": "webpack-dev-server --config ./build/ --hot --progress -d",
     "test": "jest"

Going further – HRM specs, to make things run:

const merge = require('webpack-merge')
const chokidar = require('chokidar')
const HtmlWebpackPlugin = require('html-webpack-plugin')
const base = require('./webpack.base.config.js')

module.exports = merge(base, {
  entry: './dev/dev.js',
  plugins: [
      new HtmlWebpackPlugin({
        template: './dev/index.html',
        inject: true,
  optimization: {
   noEmitOnErrors: true,
  mode: 'development',
  devtool: '#eval-source-map',
  devServer: {
    hot: true,
    hotOnly: true,
    open: true,
    inline: true,
    stats: {
      children: false,
      modules: false,
      chunks: false,
    port: 8080,
    before (app, server) {[
      ]).on('all', function () {
        server.sockWrite(server.sockets, 'content-changed');

Whenever we run yarn serve script, it will load a node server, and open a ./dev/index.html file template which solely has a <div id="app"></div> container.

Example of Dev structure

Now we simply add a wrapper component Dev.vue that will contain whatever we want to test:

import Vue from 'vue'
import Dev from './Dev.vue'

Vue.config.productionTip = false

new Vue({
  render: h => h(Dev)

Let’s say we have a simple Calendar.vue component we need to load when running serve script:

  <div id="app">
import Calendar from '@/components/Calendar.vue'

export default {
  components: {
</script> for Vue: No more custom scripts

Few years, ago, I had to dance around library to get it working nicely in VueJS framework. Some wrappers, custom components and lots of external jQuery code to make it work.

No more of it! Now, cakephp-calendar can be re-written using fullcalendar-vue package. And it sound like a perfect weekend task:

  • Getting rid of custom event treating
  • RFC all the way with Recurrences
  • Clean State Management and stand-alone JS npm package (instead of all-in-one solution)

Congratulations to developers from fullcalendar community, who did a great job moving away to TypeScript, and making the codebase more incorporating with modern frameworks like Vue/React/Angular.

PHP RFC: Comprehensions

Another interesting RFC recently landed to PHP community. So far the easiest way of explaining comprehensions for me comes from Python world:

Comprehensions are constructs that allow sequences to be built from other sequences.

Here’re some examples from List comprehensions in Python:

def palindromes(strings):
    return [s + s[::-1] for s in strings]

def starting_with(letter, names):
    return [name for name in names if name[0].lower() == letter.lower()]

JavaScript, however, decided to remove its support from standard in favour of filter/arrow/map functions.

The array comprehensions syntax is non-standard and removed starting with Firefox 58. For future-facing usages, consider using Array.prototype.mapArray.prototype.filterarrow functions, and spread syntax.


Speaking of PHP RFC, that’s what we might get if RFC gets approved:

$gen = [for $list as $x if $x % 2 yield $x*2];

//equivalent to:

$gen = (function() use ($list) {
  foreach ($list as $x) {
    If ($x % 2) {
     yield $x * 2;

Personally, I would vote in favour of this. Maybe, it’s nostalgia about Perl one-liners and how elegant you can solve some basic stuff. I think PHP needs this syntactic sugar, giving people choice of using closure calls and comprehensions.