artemave

I write javascript code. I use CLI for everything I can and Chrome debug tools for everything else. I write code in cli vim, under tmux session.

I normally have tmux sessions (one per project) so I can quickly switch between them without closing/opening new terminal windows, cd'ing, etc.

I also have some automation that allows me to run particular tests from within vim such that it runs in a separate (designated to tests) tmux window.

I really love my setup (even though, at this point, it's probably more out of habit than anything else) and I don't want anything else.

But. The other day I've been pairing with my mate Josh and he kept doing this one thing over and over again and it was such a basic thing, yet such powerful thing at the same time, that I could feel my perfect cli world shaking.

artemave

set nocompatible

call plug#begin()

Plug 'Shougo/deoplete.nvim', { 'do': ':UpdateRemotePlugins' }
let g:deoplete#enable_at_startup = 1

Plug 'github/copilot.vim'

call plug#end()

artemave

# config/initializers/carrierwave.rb

require 'mini_magick'

module CarrierWave
  module MiniMagick
    # round _square_ image
    def round
      manipulate! do |img|
        img.format 'png'

artemave

#!/usr/bin/env python3
import os

from i3ipc import Connection
from i3ipc import Event

i3 = Connection()

os.system('touch ~/.config/i3/.auto_floating_windows')

artemave

RD = RD or {}

function RD.join(tbl, sep)
  local ret = ''
  for i, v in pairs(tbl) do
    ret = ret .. v .. sep
  end
  return ret:sub(1, -#sep - 1)
end

artemave

Dropping this into lib/tasks/test_wip.rake will add rails test:diff command. This runs certain tests that relate to your changes. In particular, the following tests are picked:

• modified^* test files
• test files for modified model/controller/job/mailer/helper files (e.g. if app/models/user.rb has changed, test/models/user_test.rb is picked)
• test files for controllers/mailers whose views have been modified

^*modified file is a file that is either git modifed or appears in git diff master

The quality of the result relies on how well you stick to the rails conventions. E.g., changes in app/models/user.rb won't trigger app/models/account_test.rb, if that's where your user models tests happens to reside.

artemave

Everybody knows React. But what is Hyperdom?

Hyperdom is a virtual dom based framework. It's been first released around 5 years ago and back then was known as Plastiq.

Hyperdom was set out to fix some of the react shortcomings (more on that later) and it has succeeded to do so. The ultimate goal however was to make a tool that we could use to build websites for our clients faster and easier. As a consequence Hyperdom remained in the dark as no attempts to market it were made.

Back then the SPA framework scene was fluctuating without a clear leader. And so we were able to get away with using Hyperdom. That seems to have changed in recent years with React emerging a defacto standard. At least according to what our clients demand (fun fact: 5 years ago they were insisting on Angular 1).

Over the years a strong community built up around React. There is plethora of solid complimentary projects that solve all sorts of problems. To be fair, that alone is a good reason to stick to React.

artemave

Everybody knows React. But what is Hyperdom?

Hyperdom is a virtual dom based framework. It's been first released around 5 years ago and back then was known as Plastiq.

Hyperdom was set out to fix some of the react shortcomings (more on that later) and it has succeeded to do so. The ultimate goal however was to make a tool that we could use to build websites for our clients faster and easier. As a consequence Hyperdom remained in the dark as no attempts to market it were made.

Back then the SPA framework scene was fluctuating without a clear leader. And so we were able to get away with using Hyperdom. That seems to have changed in recent years with React emerging a defacto standard. At least according to what our clients demand (fun fact: 5 years ago they were insisting on Angular 1).

Over the years a strong community built up around React. There is plethora of solid complimentary projects that solve all sorts of problems. To be fair, that alone is a good reason to stick to React.

artemave

Mithril vs Hyperdom

Mithril is a "A modern client-side Javascript framework for building Single Page Applications". So are many other frameworks out there. So is my personal favorite - Hyperdom. What sets Mithril apart from the some other frameworks that I looked into is just how similar it is to Hyperdom in terms of development experience.

This is because they both operate under these two fundamental assumptions: "component instances are not recreated on each render" and "automatically redraw everything on some common events". In practice, that means that there is no reason for the framework to manage application state. State can be simply stored in plain javascript objects that have nothing to do with the framework. If you're familiar with React, imagine you could write state.foo = 'bar' (state being a regular javascript object) instead of this.setState({foo: 'bar'}) and bar will still show up in the DOM. Even if state.foo is referenced

artemave

const vdomToHtml = require('vdom-to-html')
const path = require('path')
const fs = require('fs')

module.exports = function (viewPath, options = {}) {
  let vdom

  let view = require(viewPath)
  if (typeof view == 'function') {
    view = view(options)