artem avetisyan 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.

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.

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.

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

This title is so 2009 - I couldn't resist it. And even back then everybody already knew that all it takes is git push heroku master. And an occasional heroku run rails db:migrate. The latter was a bit manual, so eventually heroku introduced a release task.

So... What is there to write about?

The problem is that migrating database in the release task seems to leave a small opportunity for things to go wrong. Only a teensy one, but when you're in charge of deploying changes to the real production system, this might be enough to keep you uneasy.

Release task is designed to keep serving the previous deployment until the release command finished. On the surface this is good enough, but consider what happens from the time migration is finished (and the changes are committed) and the switcheroo to the new deployment. It's only a few seconds gap, but during that time new db schema powers the old code. Now what if there is more than one migration? Suddenly the gap is wider. It's also not uncommon to run data

	#!/usr/bin/env python3
	import os

	from i3ipc import Connection
	from i3ipc import Event

	i3 = Connection()

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

	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

	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()

	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)

	scope :latest_prices, lambda {
	joins('
	LEFT JOIN client_products filter
	ON filter.product_id = "client_products"."product_id"
	AND "client_products"."created_at" < filter.created_at')
	.where('filter.id IS NULL')
	.where('"client_products"."price_per_pack" > 0')
	}

	has_many :client_products, -> { merge Client.latest_prices }