Юрий Похилько

Я в 41 кардинально сменила род занятий, правда ушла не в разработчики, а в тестировщики. Подобных вопросов я не задавала, так как была уверена в своих силах и в том, что мне дико интересно тестировать. Зарплата была вторичной мотивацией.
Сначала я определилась что именно мне интересно (бэкенд, нагрузка/перфоманс и темт-дизайн) изучила под это дело все, сто смогла и устроилась на работу. Спустя год я стала тимлидом в своей группе (так как возраст это ещё и жизненный опыт, который помогает именно руководить и организовывать).
Мне кажется, что если программирование увлекает настолько, что хочется встать пораньше, чтоб покодить, или не пойти с друзьями в бар ради доделки кода, то шанс найти свое место очень большой. Взрослый человек умеет обучаться и концентрироваться, так что и развиваться может быстро.

jQuery "видит" весь DOM целиком. И манипулирует DOM-ом, доступ к которому предоставляет браузер. Но можно и по-другому.

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

Затем отделим состояние от поведения и представления. Состояние можно описать статической структурой данных, JSON-ом, например. А поведение - это чистая функция, из предыдущего состояния и некоего события (действия) делающая следующее состояние. Представление же "знает", как визуализировать состояние. Можно этот принцип воспроизвести от самых мелких компонент (не имеющих потомков) в нашем дереве и до корня. Тогда весь жизненный цикл приложения можно изобразить как цепочку состояний от некоего начального и до текущего, ведомую событиями (действиями).

Для того, чтобы это всё отобразить, не обязательно в ходе вычисления следующего состояния (или представления) сразу манипулировать DOM-ом. Можно построить из состояния и его представления фрагмент DOM-а, каким он должен получиться. А потом вычислить diff между этим построенным фрагментом (виртуальным DOM-ом) и реальным браузерным. И этот diff применить к реальному DOMу. Один раз. Получится быстро.

Насколько мне известно (поправьте, если это не так), Redux заимствован из Elm-а. Elm - это экосистема и функциональный язык, компилируемый в JS, сделанный для того, чтобы фронтэнд можно было разрабатывать удобно, быстро и без runtime-ошибок. По синтаксису - это адаптация Haskell-a. Ключевым элементом Elm-а является как раз вот эта самая архитектура. Советую подробнее почитать в первоисточнике. https://guide.elm-lang.org/architecture/

Кроме упомянутых особенностей эта архитектура также позволяет выполнять так называемую time-travelling отладку. Поскольку каждое состояние и каждое событие по пути от исходного до текущего можно залогировать и воспроизвести (ведь функция, вычисляющая следующее состояние у нас чистая).

С точки зрения функционального программирования, при таком подходе текущее состояние является результатом функции leftFold, применённой к исходному состоянию, последовательности событий (действий), приводящих к текущему и функции, умеющей вычислять следующее состояние.

Линукс GUI не имеет такой длинной истории как в Windows, и дело не в рабочем столе, иконках или табах. Дело в том, что windows API Для написания приложений один для всех версий винды, а у линукса графических библиотек может быть много, разных, и единый стандарт для всех дистрибутивов отсутствует.
В результате, многие приложения работают так, как в свое время под дос - ищут свой набор библиотек, с которыми идти в GUI.

Если у вас есть стабильный набор софта, который вы можете настроить и его вам хватает - идите в Линукс. Если нет - Винда нормальная система, стабильная.
Я Линукс люблю на сервере и виртуалке, а на десктопе да еще и под игрушки - возможно будет проще дождаться полноценного SteamOS (на базе Линукс).

Большинство сайтов используют cookie, так сказать косвенно. Вот на пример, вы ведёте свой личный блог. В нем нет никаких форм, комментариев, ничего. Пользователи просто зашли, почитали и ушли. Ваш сайт не использует cookie. Но стоит вам поставить аналитику — и уже аналитика будет добавлять для каждого посетителя cookie.

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

Вот вы когда приходите в магазин — там обязано быть уведомление о том, что ведётся видеозапись. То же самое и тут.

UPD
Недавно законы в этом отношении несколько ужесточились. Большие мешающие просмотру плашки с вопросом "А можно мы будем использовать cookie?" это на самом деле не такая серёзная проблема. Куда серёзнее:

1. Сайт не предлагает вам вариант НЕ разрешать слежение за собой. Он просто информирует. "Ты уже тут, и я уже всё о тебе знаю"
   
2. Сайт предлагает вариант "Не следить" но лишь формально. Не зависимо от вашего выбора, cookie всё равно будут собираться и обрабатываться.
   
3. При выборе варианта "Не следить" вас попросу не пускают на сайт. Потому что дешевле заблокировать вам просмотр, чем переделать сайт таким образом, чтобы он корректно работал без cookie.