Михаил Р.

1. https://github.com/D4koon/WhatsappTray/releases
   UPD. По состоянию на 06.01.2019 последняя рабочая версия, в которой нет проблем — 1.4.3
   
2. https://www.anvir.net/ — при сворачивании с нажатым SHIFT — сворачивается в трей

var input2 = document.getElementById("input2");
input2.addEventListener("focus", focusInput2);
function focusInput2() {
    alert("Focus2");
}

const input = document.getElementById('input2');
input.addEventListener('focus', function() {
  console.log('focus 2');
});

array.ToList().ForEach(x => Console.Write(@"{0} ", x));

полный доступ

/system scheduler add interval=20s name=unreg_inactive_wifi_clients on-event="/interface wireless registration-table remove  [ find  last-activity > 150 ]"  start-date=jun/01/1970 start-time=00:00:00

Фундаментальное практическое правило гласит: то, что изменяется одновременно, лучше хранить в одном месте.

Мы структурируем программы, чтобы облегчить внесение в них изменений;

Планируя изменение, мы хотим иметь возможность перейти в определенную точку программы и внести изменения именно в ней.

Когда я сталкиваюсь с кодом, который имеет дело с двумя разными задачами, я ищу способ разделить его на отдельные модули. Я стараюсь выполнить такое разделение, поскольку, если мне нужно будет вносить изменения в программу, мне придется иметь дело с каждой задачей в отдельности и не потребуется держать их обе в голове. Если мне повезет, то, возможно, будет достаточно внести изменения только в один модуль без необходимости запоминать детали другого.

модульность, которая обеспечивает возможность вносить множество изменений в программу, в то же время понимая лишь небольшую ее часть. Чтобы добиться этой модульности, я должен убедиться, что связанные программные элементы сгруппированы и связи между ними легко найти и понять.

Если у меня хороший набор структур данных, соответствующих поставленной задаче, то реализующий поведение код прост и понятен. Плохие структуры данных приводят к большому количеству кода, работа которого заключается просто в обработке плохих данных. И это не просто сложный код, который трудно понять; это также означает, что структуры данных скрывают то, что делает программа.

программная сущность (класс, модуль, метод) должна по возможности решать лишь одну задачу, но делать это хорошо.

Чем меньше у метода, класса или модуля вспомогательных задач, тем ниже вероятность случайных изменений.

не приведут ли меня принципы и паттерны в мир ненужной сложности (overengineering): стал ли мой дизайн после внесения изменений проще? Не решаю ли я проблему, которой на самом деле не существует?
Не попал ли я в сети преждевременного обобщения (premature generalization)?