Рекурсивные CTE в Postgresql
Рекурсивные CTE нужны для работы с хитросвязанными между собой строками, например, для работы с деревьями
К примеру, у вас есть записи ( id, parent_id, name ), и вам надо построить поддерево для определенного id.
Как это всё работает.
На самоме деле, название "рекурсивные CTE" не совсем удачное, больше подошло бы "итеративное CTE".
Пример:
WITH RECURSIVE r AS (
SELECT id, parent_id, name
FROM geo
WHERE parent_id = 4
UNION
SELECT geo.id, geo.parent_id, geo.name
FROM geo
JOIN r
ON geo.parent_id = r.id
)
SELECT * FROM r;
Рекурсивный подзапрос должен состоять из двух частей, объединенных UNION
Первая часть (та что до UNION) - это так называемый anchor, он выполняется в начале, это первая итерация.
Далее в цикле выполняется вторая часть. Это очередная итерация, которая работает в связке с предыдущей (джойнится на результат предыдущей итерации).
Это всё работает до тех пор, пока очередная итерация не вернёт 0 строк результата.
Т.е. получается, что мы в первом запросе нашли все элементы где parent_id = 4, потом нашли элементы, где parent_id - это id из первого запроса, и т.д., пока не кончится.
В случае, если в таблице граф с циклическими связями, то эти итерации не кончатся никогда )
Для того, чтобы бороться с этой проблемой в postgres 14 будут сделаны дополнительные ключевые слова. Но об этом позже )
Рекурсивные CTE нужны для работы с хитросвязанными между собой строками, например, для работы с деревьями
К примеру, у вас есть записи ( id, parent_id, name ), и вам надо построить поддерево для определенного id.
Как это всё работает.
На самоме деле, название "рекурсивные CTE" не совсем удачное, больше подошло бы "итеративное CTE".
Пример:
WITH RECURSIVE r AS (
SELECT id, parent_id, name
FROM geo
WHERE parent_id = 4
UNION
SELECT geo.id, geo.parent_id, geo.name
FROM geo
JOIN r
ON geo.parent_id = r.id
)
SELECT * FROM r;
Рекурсивный подзапрос должен состоять из двух частей, объединенных UNION
Первая часть (та что до UNION) - это так называемый anchor, он выполняется в начале, это первая итерация.
Далее в цикле выполняется вторая часть. Это очередная итерация, которая работает в связке с предыдущей (джойнится на результат предыдущей итерации).
Это всё работает до тех пор, пока очередная итерация не вернёт 0 строк результата.
Т.е. получается, что мы в первом запросе нашли все элементы где parent_id = 4, потом нашли элементы, где parent_id - это id из первого запроса, и т.д., пока не кончится.
В случае, если в таблице граф с циклическими связями, то эти итерации не кончатся никогда )
Для того, чтобы бороться с этой проблемой в postgres 14 будут сделаны дополнительные ключевые слова. Но об этом позже )
Многое новое - это хорошо закомментированное старое
(из чатика SPb Reliability Meetup https://news.1rj.ru/str/spb_reliability )
(из чатика SPb Reliability Meetup https://news.1rj.ru/str/spb_reliability )
👀1
Forwarded from Технологический Болт Генона
Сегодня okmeter.io погорел вместе с дата-центром (https://habr.com/ru/news/t/546264/). Коллега пишет о DRP (https://news.1rj.ru/str/DOFH_ru/2411), а я вспомнил статью на Хабре про это
Готовим DRP — не забудьте учесть метеорит
https://habr.com/ru/company/ruvds/blog/523570/
ЗЫ Скрин не мой, скинули в личку
Готовим DRP — не забудьте учесть метеорит
https://habr.com/ru/company/ruvds/blog/523570/
ЗЫ Скрин не мой, скинули в личку
👀1
Записали выпуск "Цинкового прода" про рекурсивные CTE, выгорание, trunk-based dev и много чего еще
00:00 Приветствие
2:00 В PostgreSQL упал новый комит для рекурсивных CTE
20:17 Сгорел дата-центр OVHCloud
25:56 План сохранения онлайн бизнеса при пожаре в дата-центре
29:42 Про замедление работы Twitter Роскомнадзором
36:11 Выгорание - норма?
49:06 О мотивации к программированию
1:04:57 Налог на блогеров
1:08:10 Про Trunk Based и мертвый код
1:26:38 Как часто нужно менять работу/проекты, чтобы не впадать в стагнацию?
1:36:19 Red Hat и Google представили сервис для криптографической верификации кода
1:38:23 Любой ли команде нужен ресурсный менеджер?
https://www.youtube.com/watch?v=iQiCA7SUi2Y
00:00 Приветствие
2:00 В PostgreSQL упал новый комит для рекурсивных CTE
20:17 Сгорел дата-центр OVHCloud
25:56 План сохранения онлайн бизнеса при пожаре в дата-центре
29:42 Про замедление работы Twitter Роскомнадзором
36:11 Выгорание - норма?
49:06 О мотивации к программированию
1:04:57 Налог на блогеров
1:08:10 Про Trunk Based и мертвый код
1:26:38 Как часто нужно менять работу/проекты, чтобы не впадать в стагнацию?
1:36:19 Red Hat и Google представили сервис для криптографической верификации кода
1:38:23 Любой ли команде нужен ресурсный менеджер?
https://www.youtube.com/watch?v=iQiCA7SUi2Y
YouTube
#103 Рекурсивные CTE, выгорание, замедление твиттера
00:00 Приветствие
2:00 В PostgreSQL упал новый комит для рекурсивных CTE
20:17 Сгорел дата-центр OVHCloud
25:56 План сохранения онлайн бизнеса при пожаре в дата-центре
29:42 Про замедление работы Twitter Роскомнадзором
36:11 Выгорание - норма?
49:06 О…
2:00 В PostgreSQL упал новый комит для рекурсивных CTE
20:17 Сгорел дата-центр OVHCloud
25:56 План сохранения онлайн бизнеса при пожаре в дата-центре
29:42 Про замедление работы Twitter Роскомнадзором
36:11 Выгорание - норма?
49:06 О…
👀1
"Знание некоторых закономерностей освобождает от необходимости знать некоторые факты"
Как я уже написал, "схватывать суть" значит "отделять главное от второстепенного". Всех этому учили классе в пятом, на уроках литературы. Дают прочитать текст, а потом говорят написать по нему краткое изложение, обозначив основную суть. Когда ты маленький - это тебе кажется полной чушью, но с возрастом понимаешь важность таких упражнений. Теперь вам 25...40 и вы открываете документацию по какому-то неизвестному ранее фреймворку. Если вы - плохой разработчик, то вы бездумно копипастите примерчики и встаиваете в свой код. Но если вы ухватываете суть и понимаете зачем этот фреймворк, какую задачу он решает и как примерно это делает - то вам ни к чему держать открытой документацию. Вы уже знаете что "где-то тут должна быть вот такая вот функция" и можете предположить как она называется. В крайнем случае - вы лучше формулируете запрос в гугл. Потому что если вы не умеете видеть главное, видеть суть - то любая библиотека для вас это набор слабосвязанных функций. Половину рабочего времени вы будете проводить в гугле, хотя могли бы выдавать результат.
Коль скоро вы можете схватить суть кода и фреймворка, который вы используете - вы можете схватить суть и своего проекта. На практике это поможет осознать что, скажем, в данном конкретном случае можно обойтись одним php-файликом, а не городить конфиг вебпака на 50 экранов и поднимать кубокластер.
Вообще схватывание сути и работа именно на саму суть избавляет от кучи лишних телодвижений. Понимание сути во многом - есть правильное понимание цели чего бы вы там ни делали. А если вы хорошо представляете к чему вы идёте - у вас появляется знатно больше степеней свободы.
Как-то так.
(С) Pavel Novikov ( https://twitter.com/reinforced_sc )
Как я уже написал, "схватывать суть" значит "отделять главное от второстепенного". Всех этому учили классе в пятом, на уроках литературы. Дают прочитать текст, а потом говорят написать по нему краткое изложение, обозначив основную суть. Когда ты маленький - это тебе кажется полной чушью, но с возрастом понимаешь важность таких упражнений. Теперь вам 25...40 и вы открываете документацию по какому-то неизвестному ранее фреймворку. Если вы - плохой разработчик, то вы бездумно копипастите примерчики и встаиваете в свой код. Но если вы ухватываете суть и понимаете зачем этот фреймворк, какую задачу он решает и как примерно это делает - то вам ни к чему держать открытой документацию. Вы уже знаете что "где-то тут должна быть вот такая вот функция" и можете предположить как она называется. В крайнем случае - вы лучше формулируете запрос в гугл. Потому что если вы не умеете видеть главное, видеть суть - то любая библиотека для вас это набор слабосвязанных функций. Половину рабочего времени вы будете проводить в гугле, хотя могли бы выдавать результат.
Коль скоро вы можете схватить суть кода и фреймворка, который вы используете - вы можете схватить суть и своего проекта. На практике это поможет осознать что, скажем, в данном конкретном случае можно обойтись одним php-файликом, а не городить конфиг вебпака на 50 экранов и поднимать кубокластер.
Вообще схватывание сути и работа именно на саму суть избавляет от кучи лишних телодвижений. Понимание сути во многом - есть правильное понимание цели чего бы вы там ни делали. А если вы хорошо представляете к чему вы идёте - у вас появляется знатно больше степеней свободы.
Как-то так.
(С) Pavel Novikov ( https://twitter.com/reinforced_sc )
Мой друг-бизнесмен все время, сколько я его знаю, пытается улучшить работу отдела продаж с помощью кнута и пряника. Строит хитрожопые графики каждого показателя работы, штрафует за нарушение тех или иных процессов, премирует за превышение плана продаж и т.д.
На мой взгляд это вообще не может работать. Я, конечно, не продажник, я управляю программистами, но весь мой опыт говорит, что люди или сами работают нормально, или нет. Вот так просто. Внешняя мотивация в виде премий и штрафов делает только хуже.
Успеть к дедлайну и получить за это премию - это ок 1 раз. Но постоянно работать в режиме сверхусилий невозможно. А ведь еще надо "точить пилу", иначе погрязнешь в техдолге.
Самый плохой эффект, который я видел - это эффект "срезания" премий. Т.е. если ты получил премию в этом месяце, и не получил в следующем, то это воспринимается ровно как штраф. Штраф выбивает из колеи и демотивирует так, что дальше некуда.
Всякие там звания "сотрудник месяца" - это вообще смешно в 99% случаев. Не видел, чтобы это работало.
Единственное, что можно сделать, чтобы сотрудник начал хорошо работать - это поработать с внутренней мотивацией. Убрать режим концлагеря: бессмысленные требования, премии/штрафы, навязанные сверху технологии (например, "пишем только на php и не ебёт"), жесткий график работы, токсичных коллег, говнокод.
Надо прислушиваться к мнению, относиться с уважением, дать максимальное количество полномочий (доступ к проду, принятие более менее ключевых решений без особого апрува), короче, чтобы проект воспринимался, как что-то личное.
Программисты идут в программирование, потому что им нравится программировать. Да блин, невозможно изучить (и продолжать изучать) СТОЛЬКО информации из под палки. А значит, надо лишь не мешать, убрать всё плохое. Построить процесс без стрессов.
Если воздействие на внутреннюю мотивацию не сработало, ну тогда остается увольнять. Штрафы, премии, подпинывания - потребуют очень много времени на управление и не помогут. А скорее только сделают хуже
На мой взгляд это вообще не может работать. Я, конечно, не продажник, я управляю программистами, но весь мой опыт говорит, что люди или сами работают нормально, или нет. Вот так просто. Внешняя мотивация в виде премий и штрафов делает только хуже.
Успеть к дедлайну и получить за это премию - это ок 1 раз. Но постоянно работать в режиме сверхусилий невозможно. А ведь еще надо "точить пилу", иначе погрязнешь в техдолге.
Самый плохой эффект, который я видел - это эффект "срезания" премий. Т.е. если ты получил премию в этом месяце, и не получил в следующем, то это воспринимается ровно как штраф. Штраф выбивает из колеи и демотивирует так, что дальше некуда.
Всякие там звания "сотрудник месяца" - это вообще смешно в 99% случаев. Не видел, чтобы это работало.
Единственное, что можно сделать, чтобы сотрудник начал хорошо работать - это поработать с внутренней мотивацией. Убрать режим концлагеря: бессмысленные требования, премии/штрафы, навязанные сверху технологии (например, "пишем только на php и не ебёт"), жесткий график работы, токсичных коллег, говнокод.
Надо прислушиваться к мнению, относиться с уважением, дать максимальное количество полномочий (доступ к проду, принятие более менее ключевых решений без особого апрува), короче, чтобы проект воспринимался, как что-то личное.
Программисты идут в программирование, потому что им нравится программировать. Да блин, невозможно изучить (и продолжать изучать) СТОЛЬКО информации из под палки. А значит, надо лишь не мешать, убрать всё плохое. Построить процесс без стрессов.
Если воздействие на внутреннюю мотивацию не сработало, ну тогда остается увольнять. Штрафы, премии, подпинывания - потребуют очень много времени на управление и не помогут. А скорее только сделают хуже
👀1
В Chrome 90, который выйдет уже вот-вот, сделают автоматическое добавление https к адресу сайта, если не был указан протокол (при ручном вводе в строке браузера).
Это приведет к тому, что куча сайтов покажет 404 страницу. По разным оценкам больше 15% сайтов не настраивали себе https и не собирались.
Для простого сайта, например, состоящего из одной публичной статики, нет особого смысла шифровать трафик, однако Гугл методично пытается заставить всех перейти на https насильно.
А благодаря фактически монополии Chrome на рынке, вариантов у владельцев сайтов уже не остается.
Т.е. понятно, что letsencrypt настроить не так уж сложно, однако насильственные действия корпорации напрягают.
Это приведет к тому, что куча сайтов покажет 404 страницу. По разным оценкам больше 15% сайтов не настраивали себе https и не собирались.
Для простого сайта, например, состоящего из одной публичной статики, нет особого смысла шифровать трафик, однако Гугл методично пытается заставить всех перейти на https насильно.
А благодаря фактически монополии Chrome на рынке, вариантов у владельцев сайтов уже не остается.
Т.е. понятно, что letsencrypt настроить не так уж сложно, однако насильственные действия корпорации напрягают.
👀1
Прикольный сайт. Рассмотрены категории проблемных людей в разработке софта (там и разработчики, и qa, и менеджмент), и описано как с ними взаимодействовать.
Полезно примерить некоторые роли на себя и сделать выводы
https://www.howtodeal.dev/
Полезно примерить некоторые роли на себя и сделать выводы
https://www.howtodeal.dev/
www.howtodeal.dev
How to Deal with Difficult People on Software Projects
Software is easy. People are hard.
Есть один канал, называется "Тимлид Очевидность", его ведет Женя Антонов (известная личность в узких тимлидских кругах). Там рассказывается о вещах, которые по идее должны быть очевидны любому тимлиду, но в этом и есть свообразная хитрость. Очевидное становится невероятным, когда его четче вырисовываешь в мозгу и обдумываешь.
К примеру, его пост про прозрачность и доверие: https://news.1rj.ru/str/general_it_talks/78
Интуитивно вроде бы всё и так понятно, но если по-настоящему обдумать, как прозрачность может повлиять на твое будущее, то захочется предпринять для этого конкретные шаги, улучшить процессы. Поэтому я на него и подписан: всё, что я делаю, должно быть максимально осмысленно. Иначе никак.
В общем, всем тимлидам и интересущимся крайне рекомендую канал. И надеюсь, что Женя еще раз придет к нам в подкаст, и расскажет что-нибудь интересное )
К примеру, его пост про прозрачность и доверие: https://news.1rj.ru/str/general_it_talks/78
Интуитивно вроде бы всё и так понятно, но если по-настоящему обдумать, как прозрачность может повлиять на твое будущее, то захочется предпринять для этого конкретные шаги, улучшить процессы. Поэтому я на него и подписан: всё, что я делаю, должно быть максимально осмысленно. Иначе никак.
В общем, всем тимлидам и интересущимся крайне рекомендую канал. И надеюсь, что Женя еще раз придет к нам в подкаст, и расскажет что-нибудь интересное )
Telegram
Тимлид Очевидность | Евгений Антонов
Матрица доверия и прозрачности
Установить доверие с заказчиком, руководством, командой – очень важно, если вы планируете работать вдолгую.
Один из хороших способов как это сделать, можно почерпнуть из матрицы доверия и прозрачности.
Довольно развернуто…
Установить доверие с заказчиком, руководством, командой – очень важно, если вы планируете работать вдолгую.
Один из хороших способов как это сделать, можно почерпнуть из матрицы доверия и прозрачности.
Довольно развернуто…
👀1
Обещал когда-то написать про системный подход.
Ну так вот, давайте поговорим про kpi рядового программиста. Ооочень часто пытаются определить работоспособность сотрудника по каким-то показателям типа "Петя закрыл 20 задач в месяц, а Вася 10", значит Петя хороший, а Вася плохой. Или интуитивно: "Петя херачит как не в себя, а Вася, по-моему, последнюю неделю хуи пинал".
Это происходит прям сплошь и рядом. И дело даже не в том, что сами метрики ущербные: и интуиция, и количество задач (или строк кода) в день.
А дело в том, что производительность команды - это то, какую ценность она принесла бизнесу.
Допустим у бизнеса есть суперважная задача1 и неважная задача2. Если суперинтенсивно работать над задачей2, то системе возможно станет только хуже. Потому что человек, интенсивно работающий над этой ерундой, с некоторой вероятностью будет дергать других людей: тимлида, админов, тестировщиков, дизайнеров и т.д. (зависит от проекта). Тем самым отвлекая их от важной, прибыльной задачи, перегружая всем мозг, забивая календарь ненужными митингами.
А еще возможно будут ненужные код ревью и споры по ним, конфликты при мерже ветки, баги на проде и т.д. и т.п. Чем быстрее человек "перформит" говнозадачу, тем больше проблем он создает.
Поэтому иногда лучше было бы, чтобы Петя работал над важным и хорошо перформил, а Вася помогал бы советом, не отвлекаясь на программирование совсем. Ну или делал бы неважную ерунду вяло, фоном, с приоритетом на отдых. Пинг-понг и плейстешн есть почти в каждом офисе, в конце концов.
И вот только если Вася взял суперважную задачу, понимает её важность и при этом нихрена не делает, только тогда Вася мудак, не раньше. Скорее всего такого надо тупо увольнять.
Всё это настолько контринтуитивно (что ничегонеделание может помогать приносить ценность), что почти никогда не принимается в расчет. Да и сложно это нормально оценить. Один совет в курилке может быть более ценным, чем неделя программирования - как ты это увидишь на перформанс ревью?
На мой взгляд, гораздо перспективнее следить за следованием приоритетам и качеством выполнения приоритеных задач (в общем, за процессами), чем педалировать каждого конкретного Васю отдельно.
Ну так вот, давайте поговорим про kpi рядового программиста. Ооочень часто пытаются определить работоспособность сотрудника по каким-то показателям типа "Петя закрыл 20 задач в месяц, а Вася 10", значит Петя хороший, а Вася плохой. Или интуитивно: "Петя херачит как не в себя, а Вася, по-моему, последнюю неделю хуи пинал".
Это происходит прям сплошь и рядом. И дело даже не в том, что сами метрики ущербные: и интуиция, и количество задач (или строк кода) в день.
А дело в том, что производительность команды - это то, какую ценность она принесла бизнесу.
Допустим у бизнеса есть суперважная задача1 и неважная задача2. Если суперинтенсивно работать над задачей2, то системе возможно станет только хуже. Потому что человек, интенсивно работающий над этой ерундой, с некоторой вероятностью будет дергать других людей: тимлида, админов, тестировщиков, дизайнеров и т.д. (зависит от проекта). Тем самым отвлекая их от важной, прибыльной задачи, перегружая всем мозг, забивая календарь ненужными митингами.
А еще возможно будут ненужные код ревью и споры по ним, конфликты при мерже ветки, баги на проде и т.д. и т.п. Чем быстрее человек "перформит" говнозадачу, тем больше проблем он создает.
Поэтому иногда лучше было бы, чтобы Петя работал над важным и хорошо перформил, а Вася помогал бы советом, не отвлекаясь на программирование совсем. Ну или делал бы неважную ерунду вяло, фоном, с приоритетом на отдых. Пинг-понг и плейстешн есть почти в каждом офисе, в конце концов.
И вот только если Вася взял суперважную задачу, понимает её важность и при этом нихрена не делает, только тогда Вася мудак, не раньше. Скорее всего такого надо тупо увольнять.
Всё это настолько контринтуитивно (что ничегонеделание может помогать приносить ценность), что почти никогда не принимается в расчет. Да и сложно это нормально оценить. Один совет в курилке может быть более ценным, чем неделя программирования - как ты это увидишь на перформанс ревью?
На мой взгляд, гораздо перспективнее следить за следованием приоритетам и качеством выполнения приоритеных задач (в общем, за процессами), чем педалировать каждого конкретного Васю отдельно.
👀1
Вчера в репозиторий php попало сразу 2 бекдора, причем от имени создателя PHP Расмуса Лердорфа и небезызвестного core-разработчика Никиты Попова.
Подозревают, что сервер git.php.net скомпроментирован.
В итоге решили отказаться от собственного гит-репозитория, и перейти полностью на Github (раньше гитхаб был лишь зеркалом)
Подозревают, что сервер git.php.net скомпроментирован.
В итоге решили отказаться от собственного гит-репозитория, и перейти полностью на Github (раньше гитхаб был лишь зеркалом)
👀1
Самый большой список источников для изучения языка Rust (книги, статьи, видео, подкасты, блоги, стримы, упражнения и тд)
https://loige.co/where-to-go-to-learn-rust-in-2021/
https://loige.co/where-to-go-to-learn-rust-in-2021/
loige.co
Where to go to learn Rust in 2021
This article provides a list of free and paid resources to learn Rust in 2021 including books, blogs, videos, newsletters, podcasts, communities, exercises, workshops, and open source projects.
👀1
Forwarded from null NaN undefined
У меня есть одни слова от автора @ZeroBias эффектора на тему почему появился effector и какие его плюсы.
Децентрализованность, декларативность, эффективность. Требовался инструмент, позволяющий управлять данными в сложных приложениях без опасности раздуть монолитный центральный стор, с явным control flow, нормальной типизацией и емким апи.
Сторы для приложения должны быть лёгкими, насколько это возможно — не должна пугать мысль о том, что нужно добавить ещё один стор для конкретных нужд.
Сторы должны свободно совмещаться — идея в том, что данные, которые потребуются приложению, можно распределить статически, заранее показав как данные будут преобразоваться во время работы приложения.
Принцип работы должен by design исключать необходимость в reselect, оповещая об изменениях только тех, кому они необходимы. Это позволяет не задумываться о том, что у тебя будет триггериться всё приложение если ты захочешь вынести стейт модалки из реакта. По совместительству это означает что приложения избавлены от проблем с перфомансом, возникшим у react-redux при переходе на контекст.
Возможность, место, и способ вынести любую требуемую бизнес-логику из view, максимально упрощая компоненты.
Независимость от спорных концепций — никаких декораторов, никаких зависимостей от реакта/rxjs либо необходимости юзать классы или прокси — ничего из этого не требуется для управления состоянием приложения и поэтому api библиотеки использует только функции и простые js объекты.
Предсказуемость api. Небольшое число базовых принципов переиспользуются в различных кейсах, снижая нагрузку на юзера и повышая узнаваемость. Зная как работает .watch в событиях, можно догадаться, что делает функция .watch у стора.
Приложение строится из комбинации базовых элементов и возможности строить новые.
Нет никакого смысла стремиться выдать всё за стрим, за редьюсер или за обсервабл, в приложении требуются они все, и библиотека предлагает решение чтобы управлять структурой данных, а не скрывать её.
Децентрализованность, декларативность, эффективность. Требовался инструмент, позволяющий управлять данными в сложных приложениях без опасности раздуть монолитный центральный стор, с явным control flow, нормальной типизацией и емким апи.
Сторы для приложения должны быть лёгкими, насколько это возможно — не должна пугать мысль о том, что нужно добавить ещё один стор для конкретных нужд.
Сторы должны свободно совмещаться — идея в том, что данные, которые потребуются приложению, можно распределить статически, заранее показав как данные будут преобразоваться во время работы приложения.
Принцип работы должен by design исключать необходимость в reselect, оповещая об изменениях только тех, кому они необходимы. Это позволяет не задумываться о том, что у тебя будет триггериться всё приложение если ты захочешь вынести стейт модалки из реакта. По совместительству это означает что приложения избавлены от проблем с перфомансом, возникшим у react-redux при переходе на контекст.
Возможность, место, и способ вынести любую требуемую бизнес-логику из view, максимально упрощая компоненты.
Независимость от спорных концепций — никаких декораторов, никаких зависимостей от реакта/rxjs либо необходимости юзать классы или прокси — ничего из этого не требуется для управления состоянием приложения и поэтому api библиотеки использует только функции и простые js объекты.
Предсказуемость api. Небольшое число базовых принципов переиспользуются в различных кейсах, снижая нагрузку на юзера и повышая узнаваемость. Зная как работает .watch в событиях, можно догадаться, что делает функция .watch у стора.
Приложение строится из комбинации базовых элементов и возможности строить новые.
Нет никакого смысла стремиться выдать всё за стрим, за редьюсер или за обсервабл, в приложении требуются они все, и библиотека предлагает решение чтобы управлять структурой данных, а не скрывать её.
👀1
Говорят, что гугл проводил исследование, что умение в алгоритмы хорошо коррелирует со способностями к обычным рутинным задачам программиста. Нет ли у кого-нибудь ссылки на это исследование? Ибо это многое меняет.
👀1
Благодаря дженерикам в Go наконец-то можно будет написать универсальную для всех типов (ну, почти) функцию поиска элемента в списке. Что-то типа такого:
Мелочь, а приятно
func find[T comparable](s []T, w T) int {
for i, v := range s {
if v == w {
return i
}
}
return -1
}Мелочь, а приятно
👀1