Фиганул статью на хабр про монокультуру в программировании: https://habr.com/ru/articles/838682/ Где рассказываю про то, как монокультура (использование одной технологии повсеместно) мешает и вредит проектам

Ссылки: Телеграм | Youtube | VK

Куда переезжать из ноушена? Спойлер: мы нашли замену
Морально мы были готовы к письму счастья, так как с 12 сентября вступал запрет на предоставление сервисов из США, но честно говоря надеялись, что они не будут вычислять по айпи и набивать. В итоге именно это они и собираются сделать независимо от того, где находится компания на которую все зарегано. Что ж, я сегодня плотно засел за сервисы, чтобы найти что-то подходящее. Я нашел таки сервис, который нас устроил, но сначала немного вводных.

https://vc.ru/u/14739-kirill-mokevnin/1429593-kuda-pereezzhat-iz-noushena-spoiler-my-nashli-zamenu

Когда нужно внедрять микросервисы? Новый выпуск с кофаундером и техническим директором проекта Scentbird, который захватил американский рынок уже на канале: youtube.com/watch?v=cqKJD3ovxEc

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

Игры разума. Проект, который может вас затянуть!

Попробую ввести традицию пятничных постов, где я рассказываю что-то интересное, вокруг it или про it, но не код. Где-то в 2008 году, я наткнулся на сайт braingames.ru, на котором собраны всевозможные логические задачи. В то время меня от них знатно перло и я годами заходил на этот сайт и решал их. У проекта большое комьюнити и множество волонтеров помогающих с добавлением заданий, проверок решений и другими вещами, вплоть до разработки или юридического сопровождения.

Предлагаю решить одну задачку оттуда:

Мегамозг может выйти на свободу, если он справится с заданием: перед ним две двери, одна из них ведет на волю, другая — дорога к смерти. Здесь же сидят два стражника, причем один из них либо лжец, либо правдивец, а второй — хитрец, то есть человек, который говорит правду и ложь строго поочередно (либо на нечетные вопросы отвечает ложью, а на четные — правдой, либо наоборот). Оба стражника знают, какая из дорог ведет на волю, но Мегамозгу неизвестно, кто из стражников хитрец. Мегамозг имеет право задать два вопроса одному из стражников (вопросы должны быть простыми). Как ему определить дорогу, ведущую на свободу?

Источник: https://braingames.ru/?path=comments&puzzle=94

Ссылки: Телеграм | Youtube | VK

Любителям Go и им сочувствующим, крайне рекомендую канал Николая Тузова. Он ведет самый популярный русскоязычный youtube-канал посвященный Go где рассматривает все от собеседований до принципов написания кода. Вот что сам Коля говорит про него: “основная идея канала - сложные вещи простым языком. Стараюсь всегда копать максимально глубоко, но при этом максимально понятно. К примеру, если уж разбираем мапы, то спустимся вплоть до разбора их исходного кода и того, как конкретно там устроены бакеты)”

И естественно у него есть телеграм канал который мне еще предстоит обогнать!

Несколько интересных материалов:

Как на самом деле устроен тип Map в Golang?
JWT простым языком - краткий ликбез

Приятно, что студенты Хекслета доходят так далеко 🙂

Как значительно упростить интеграции между вашим проектом и сторонними системами (твиттер-тред)

Все что касается событий, рекламных кабинетов, crm, аналитик, слака и кучи других систем. Вы используете сервисы типа Zapier?

Сначала про задачу. В любом SaaS сервисе, помимо самого продукта и его фич, есть много всего вокруг. CRM для продаж, система сквозной аналитики, рекламные кабинеты, событийная анилитка, автоматизация маркетинга (email, боты), виджеты на сайте и так далее. Тонны систем

И все они работают в связке. Когда на сайте оставляют заявку, она должна попасть в CRM продавцам, должна попасть в рекламный кабинет и систему сквозной аналитики для анализа эффективности, а еще нужна нотификация в слак и тикет на работу с клиентов после того как сделка закрылась

Мы получаем взаимодействие не просто точка-точка, а целый пайплайн, в котором задействованы по 3-5, сервисов. Иногда взаимодействие идет без самого сервиса. Иногда наш сервис должен как генерировать события, так и уметь обрабатывать ответы от других систем

И, реклама, это всего лишь один из примеров. Нам так же нужно строить онбординг, а для этого есть свои сервисы, нужно запускать ботов, нужно выполнять продуктовую аналитику, нужно рассылать письма по событиям (и даже целые цепочки писем). Для всего этого есть свои решения

На вскидку то что мы используем чтобы было понятнее. Некоторые из них супер, другие не очень, но без них мы бы порвались: http://activecampaign.com, http://amplitude.com, http://rick.ai, http://trengo.com, http://sparkpost.com и т.п.

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

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

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

Достаточно давно появился сервис, который захватил эту нишу: Zapier. Он позволяет соединять между собой все что имеет апи. Это визуальный конструктор, в котором мы указываем откуда и какие взять данные и куда их отправить, причем выполнив нужные преобразования. Он сразу включает в себя интеграцию со всеми популярными сервисами, поэтому здесь не нужно программирование. Мы просто говорим чего хотим от одной системы и куда это надо послать.

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

А действие это вызов апи какого-то сервиса, в которое мы хотим из запира отправить данные. Например заполнить таблицу в гугл доках, создать мессадж в слаке или отправить письмо.

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

Теперь, если нам нужно отправлять событие регистрации в какую-то новую систему, мы просто идем в запир и делаем связку "регистрация" => "создание клиента в pipedrive" (как пример). Сайт не трогаем, нет деплоя, даже программистов нет. Это могут делать аналитики/маркетологи

Запир оч дорогой инструмент + он не работает в рф, поэтому часть задач мы решаем с помощью сервисов типа интегромата, но большая часть наших интеграций проходит через n8n.io, который имеет self-hosted версию (и вообще это open source). Если вы еще его не юзаете, то крайне рекомедную

Ссылки: Телеграм | Youtube | VK

На ютубе вышло душевное видео с моим старым другом Антоном Плешивцевым, который прошел длинный путь от одного из первых разработчиков Aviasales в тайланде (у них там офис) до технического директора создавшему 8 лет назад с нуля проект Bravado на американском рынке, крупнейшему маркетплейсу продавцов.

Поговорили мы обо всем чем только можно. О том как изменился фронтенд за 14 лет, истории из тайской жизни, организация удаленной работы, создание собственной игры и попадание в Stream, рекрутинг в сша, преимущества go и куче других тем. Наслаждайтесь 🙂 https://www.youtube.com/watch?v=qhbXHlgE6Yo

Что вы предпочитаете: обычные утверждения (asserts) или матчеры? Сначала немного терминов. Утверждения это когда мы пишем assert lala.isJopa() или assert_equal lala, "jopa". Матчеры это expect(lala.isJopa()).isTrue() expect(lala).toBe("jopa"). В чем реальная разница между этими подходами и есть ли другие варианты?

Утверждения часто встроены прямо в сам язык и обычно их немного, буквально 3-5. Больше могут добавлять тестовые фреймворки, но без фанатизма. Их легко запомнить и легко пользоваться, но, как правило, они не информативны: "ожидали тру, пришло фолс", "ожидали 5 пришло 3"

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

А в чем плюсы? Если вам нужна документация из тестов, то матчеры сделают ее понятнее. Обычно (но не всегда) вывод матчеров содержит больше полезной информации для отладки, что упрощает само тестирование. Ну и во многих языках тестовые фреймворки с матчерами являются стандартом

Есть еще всякие особые истории типа property-based тестирования или снепшот или скриншот тестирования, но это здесь мы про них не говорим. Больше вам на заметку, если не знаете про них, то обязательно почитайте.

В принципе на этом можно было бы и закончить, если бы не одна статья, которая в 2009 году значительно повлияла на проверки в тестах. Эта статья про Power Assert в Groovy https://dontmindthelanguage.wordpress.com/2009/12/11/groovy-1-7-power-assert/… Спойлер: лучшее от обоих миров: утверждений и матчеров с добавлением магии

Концепция такая, у нас есть ровно одно утверждение, внутри которого мы делаем любую проверку. Это утверждение, анализирует результат *каждого* подвыражения и выводит его для отладки. Так мы получаем максимум информации о том что пошло не так. Ниже реальный вывод

    assert(types[index].name === bob.name)
           |    ||      |    |   |   |
           |    ||      |    |   |   "bob"
           |    ||      |    |   Person{name:"bob",age:5}
           |    ||      |    false
           |    |11     "alice"
           |    Person{name:"alice",age:3}
           ["string",98.6,true,false,null,undefined,#Array#,#Object#,NaN,Infinity,/^not/,#Person#]
  
    --- [string] bob.name
    +++ [string] types[index].name
    @@ -1,3 +1,5 @@
    -bob
    +alice

Концепция оказалась настолько удачной и удобной, что либу Power Assert портировали практически в каждый язык. Лучше всего пожалуй описано в JS, там в начале ридми есть хороший блок, с объяснением почему именно этот подход: https://github.com/power-assert-js/power-assert#description

Кто-нибудь уже использовал Power Assert? Или вы не знали про него?

Ссылки: Телеграм | Youtube | VK

p.s. Скиньте в комментариях порт power assert или аналогичную либу из вашего языка/экосистемы

Давайте поиграем в игру. Я вам список фамилий, а вы в ответ свой. Поехали: Сурдин, Дробышевский, Семихатов, bushwacker (не знаю фамилию), Дубынин, Климов, Соколовский.

Я устроился на мидла без опыта

Такую фразу все чаще встречаю на просторах сети. Хочется это зафиксировать. Быть реальным мидлом и находиться на позиции мидл в какой-то компании, где это определяется формальными признаками, типа прошел собес на мидла это не одно и тоже. Нет ничего плохого в том чтобы пройти чек и занять такую должность с соответствующей зарплатой, но важно не обманывать самого себя, иначе потом будет больно.

Формальные критерии вводят для того, чтобы хоть как-то понимать и контролировать процессы, когда в компании много людей. Без этого никак. Но никакая система не делает все однозначно определенным. Всегда есть ложнопозитивные и ложнонегативные срабатывания. В мелких компаниях с этим проще, если тебя берут на мидла, то и реальную работу ждут на мидла, поэтому если оно не соответствует, то будет разговор. В крупняке можно затеряться, но многое зависит от лида.

Если убрать всю эту шелуху, что бы хотел каждый работадатель от мидла?

- Опыт работы с технологиями. Человек знает как технически решить поставленную задачу по кодингу и может ее сделать в большинстве ситуаций
- Человек может оценить основные риски, потому что в этом заключается его мидловость. Он знает к чему может привести то или иное решение, знает о чем надо подумать, предупредить, организовать плавный переход, поддержку старой системы и так далее. Такой опыт набирается через боль и ошибки (не ронял прод, не мидл)
- Он способен задать вопросы при постановке задачи, чтобы доформулировать ее до нужного уровня.

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

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

Ссылки: Телеграм | Youtube | VK

Сходил в подлодку поговорить про то как джунам действовать и находить работу. Прошлись по образованию, получению опыта, критериям готовности, софтскилам и многому другому. Кажется получилось бодро https://www.youtube.com/watch?v=qRWPp6sU6Vo

Релиз! В этом выпуске мы с Кириллом Игнатьевым, Senior Software Engineer в компании Bloomberg, разговариваем о больших компаниях и больших зарплатах 🙂 Обсуждаем процесс найма в FAANG (Facebook, Amazon, Google) и систему грейдов. Как она устроена и как внутри нее расти. https://www.youtube.com/watch?v=zkrLgz7lwgI

В твиттере бурно обсуждают скриншот, на котором видно как на букинге описываются скрытые платежи в последний момент. С этими платежами конечная стоимость может легко увеличиваться в два и более раз. Естественно все это порождает праведный гнев и вопросы в стиле “зачем, прятать если конечная цена все равно такая же как если бы не прятали?”

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

Как это работает?

#пробизнес

Процесс продажи билетов очень похож на продажи игр в сторах. Он состоит трех точек касания (как минимум):

1. Листинг (список чего-либо), на котором мы быстро принимаем решение что нам подходит
2. Страница товара, с более подробным и заманивающим описанием и картинками
3. Страница чекаута, где происходит оплата

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

Гипотетический пример. Поездку в майами смотрят 100 000 людей в день из которых, только 5% переходят на страницы конкретных отелей (эта метрика называется CTR, она есть во всех списках, будь то список курсов, приложений или выдача в поиске). Это 5000 человек. Из них только 10% доходят до чекаута, а это 500 человек. Ну и дальше покупает скажем 20%, а это 101 человек.

Имея на руках такую воронку, маркетологи думают как ее оптимизировать, но не целиком, а поэтапно. Каждый этап это свои подходы и свои конверсии. Очен удобно, так работают 100% бизнесов. За десятилетия работы с воронками на онлайн проектах, выработались подходы и техники, которые все знают независимо от индустрии. Одна из классических схем, делать предложение как можно более привлекательным снижая базовую цену и показывая ее только в самом конце или вообще перенеся продажи за пределы воронки, например, как в играх, где игры могут быть вообще бесплатными, а дальше с вас будут чаржить без перерыва уже внутри, зарабатывая в разы больше денег (если не на порядки).

Именно поэтому пишут про минимальный платеж, про “от 1000 рублей” за билет на концерт, в самой заднице стадиона, про стоимость перелета без учета багажа и так далее. Главная цель - подвинуть как можно больше людей (говорят трафика) на следующий этап воронки.

А дальше, срабатывает эффект, который делает все это выгодным. Человек прошедший по воронке дальше, более склонен к покупке, так как он заинтересован и уже предпринял какие-то действия. Ему не понравится, он будет плеваться, но в конце концов купит. Конверсия в покупку будет меньше, но количество людей дошедших до этого этапа воронки значительно больше, в итоге общая выручка значительно выше. Маркетолог получил премию, компания выполнила планы, набираем больше разработчиков чтобы развиваться дальше.

Можно ли так не делать? Ответ нет, потому что проблема не в одной компании, а в том, что так будут делать конкуренты, а значит у них будет больше денег, больше развития, в конце концов вас сметут. К - капитализм

Можно ли поправить законодательно? В теории да, но как правило, все обходится, поэтому эта задача очень сложная. Нужно последовательно выпускать патчи к законам постоянно наблюдая за ситуацией. Таким мало кто заморачивается серьезно и делается это не за один год. В конечном итоге мы покупаем молоко в пачках 900 грамм.

Ссылки: Телеграм | Youtube | VK

p.s. Домашнее задание: подумайте, какие воронки продаж используются в проектах где вы работаете и какие механики для повышения конверсий там используются. Напишите в комментариях.

Есть у меня список принципов, которых я придерживаюсь когда пишу код. Пришла пора ответить за слова. Лайк, тред, инфлюенс =>

"Язык — это инструмент" банально, но факт. Не прикипайте к языкам, язык для души и работы это разные вещи. Я не люблю го, но буду использовать там где он силен, я люблю кложу, но не буду использовать почти нигде (:D) PHP сила, TypeScript могила

"Написание кода — не цель" Задача самурая устранять боль, наиболее эффективным с точки зрения стоимость/затраты способом. Задачи могут решаться удалением кода или административным решением. Думайте о том как уменьшить количество состояний, а не запрограммировать их все

"Удаление кода лучше его написания" Я бы сказал нет кода нет проблем. Никому не нужно бесконечное число фич. Режьте все ненужное, постоянно осматривайтесь "а нахрен оно тут лежит?". Чувствуйте бизнес, будьте бизнесом, будьте

"Читаемый код важнее быстрого". С хорошей абстракцией, вы всегда успеете оптимизировать ваш код, особенно если она не протекает. Прочитайте хорошую книжку (очень тонкую)

"Любое решение имеет плюсы" Даже если вас съели, у вас есть два выхода. Хороший программист рассматривает любое решение, даже то, которое ему не нравится. Мы тут не фильмы на нетфликсе выбираем.

"Уровень мышления определяет уровень решений" Очень похожая мысль на парадокс блаба https://nestor.minsk.by/sr/2003/07/30710.html но для картины мира в голове. Изучайте разные подходы, парадигмы, экосистемы. После js изучение python это трата времени (для мышления), а изучение java мощь

"Изменяемое состояние — это необходимость и корень всех бед", а не преждевременная оптимизация. Если надо что-то менять, то приходит жопа в: историчности, порядке действий, канкаренси, сложности восприятия, сложности реализации отладке, восстановлении, скорости и дальше по списку

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

"Абстракция управляет сложностью" сложность прячется за абстракцией, но сама абстракция может стать сложностью. Как быть? Правильная работа с побочными эффектами, уровневое проектирование, грамотное разделение по областям знаний, не слишком много обобщений

"Однообразие лучше локальных оптимизаций" Это мега важный принцип. Моторная и ассоциативная памяти решают. Делайте одинаково, даже если местами кажется, что можно срезать. Например даже если состояния два, в базе все равно лучше строка: легко расширить, одинаковый код по проекту

"Тесты вселяют уверенность" Страх внесения изменения в проект заводит его в тупик. Юниты мешают изменениям. Интеграционные тесты решают. Не надо ничего мокать, стабы и нормальная инверсия всегда предпочтительнее. Работайте с базой по настоящему.

"Эксплуатация — это часть системы" Ответственность программистов довести фичу до прода, а не слить в main. Time To Market управляет проектами. Обязательно к прочтению: цель и проект феникс

"Код — это не продукт" хорошо понимаешь когда начинаешь делать бизнес, а там логистика, саппорт, продажи, сопровождение, аналитика, бухгалтерия, финансы. Из 80 сотрудников Хекслета только 5 человек работает над кодом платформы

"Хороший код не рождает хороший продукт" Как правило, успешный продукт соткан из ниток и изоленты. Скорость изменений решает, а дальше можно продать бизнес и не париться) Программисты склонны переоценивать значимость архитектуры. Уверен что этот твит засияет ночью

Ссылки: Телеграм | Youtube | VK

Картинка для привлечения внимания. Я последние недели разрабатываю курс по REST API. Ух получается огонь, буду постепенно рассказывать про всякие штуки, которые я откопал и настроил в процессе. Про TypeSpec для описания спек с генерацией в openapi, про воронку валидации, про тестирование такого api и многое другое. Когда сделаем его для js/ts, то будем переносить на другие языки. Концепции там не поменяются, только некоторые либы и фреймворки, но общая история идентичная

Ссылки: Телеграм | Youtube | VK

Сегодня чуть с запозданием, но таки вышел выпуск про ATS https://www.youtube.com/watch?v=XDFxYkPty5g

Около 15 лет я работаю (программирую и пишу все тексты) в виме на 13 дюймовом мониторе моего ноутбука. Те кто не видел меня за работой говорят "это же не удобно", те кто видел - "можно медленнее, а то я не успеваю". Давно хотел про это рассказать, тред об эффективности =>

Сразу дисклеймер. Мне действительно бывает неудобно на 13 дюймах, когда я занимаюсь отладкой чего-либо в браузере, но в остальном это вопрос организации пространства. Я много работаю в пути и у меня нет одного места, поэтому изначально все это была вынужденная мера. В какой-то момент удалось придумать систему, которая за годы особо не меняется несмотря на развитие технологий, так как она довольно универсальна. Она базируется на некоторых особенностях, которые далеко не все смогут себе адаптировать, но по крайней мере появится представление

Начнем издалека. Один из базовых навыков это слепая печать. Дело не только в том, что не смотришь на клавиатуру, а в том, что правильная постановка рук очень помогает эффективно нажимать всякие комбинации. Например использовать оба шифта. Подробнее https://guides.hexlet.io/ru/typing/.

Мне как-то повезло, что в 12 лет, когда у меня появился компьютер, я сразу наткнулся на "соло на клавиатуре" и уперся в него по полной. Сначала научился печатать на русском и почти сразу уже сам догнал английский, так как руки знали правильную механику работы. Даже учил дворак

Следующим шагом было понимание, что надо владеть комбо. Это еще началось даже до программирования, когда я рубил в старкрафт. Потом уже во всех редакторах кода я постоянно тратил время на статьи, раскладки и заучивание комбинаций. В то время, кстати, был на коне netbeans

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

Во всех операционках есть примерно один базовый набор комбинаций перемещения и выделения через стрелки + вариации с shift и ctrl. Это минимум который работает везде (в любых полях для ввода, не обязательно код) и который полезно научиться использовать.

Так как ctrl используется в комбо достаточно часто, то его лучше переместить на capslock, туда где он и был изначально. Это спасает от постоянного выламывания рук. Вимерам так вообще обязательно.

Еще одна важная кнопка - command, тут повезло маководам. Она лежит под большим пальцем и снимает опять же нагрузку с мизинца, значительно упрощая нажатие многих комбинаций. Сначала не привычно, потом уже страшно возвращаться обратно. Кстати, в крутых клавах все на больших пальцах

Дальше еще больше специфики маков. Так как у маков все унифицировано, то переключение вкладок во всех программах это: shift + command + []. Все доводится до автоматизма моментально. Дальше нам это пригодиться, когда я буду говорить про терминалы

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

В моей работе, в подавляющем большинстве случаев нужно работать с двумя программами: браузером и редактором. Они обе развернуты на весь экран и переключение по ним я делаю быстрым нажатием cmd + tab и обратно тем же самым нажатием. 100% автоматично для мозга и всегда одинаково

Так мы получаем первую ось переключения, я ее называю "в глубину". Очень важно чтобы программы было две, иначе трюк с cmd + tab не пройдет и придется думать о переключении. А вот внутри программ переключение идет "в ширину" по вкладкам и в браузере и в редакторе. Каким образом? Продолжение в первом комменте

Ссылки: Телеграм | Youtube | VK

Насколько хорошо вы понимаете как работает транзакционность в базе данных? Ниже список из 10 заблуждений относительно работы транзакций:

- Транзакция всегда завершится успешно.
- Транзакция блокирует данные, пока не завершится.
- Транзакции всегда атомарны.
- Если операция завершилась успешно, то все данные были обновлены.
- Атомарность всегда гарантирует отсутствие конфликтов.
- Операции записи в кэши или файловые системы также атомарны.
- Откат (rollback) всегда возможен.
- Атомарные операции всегда производятся быстро.
- Сетевые запросы в рамках транзакции всегда атомарны.
- Все системы одинаково поддерживают атомарные операции.

Давайте в комментариях разберем каждый пункт, почему такое может произойти

Ссылки: Телеграм | Youtube | VK

Вы когда нибудь слышали про A,B и C игроков? Если нет, то попробуйте примерить это на себя или своих подчиненных если они у вас есть

💡 Обычно, оценивая сотрудников, мы используем классификации junior, middle и senior. Но это не всегда работает, как ожидается. Иногда синьор может не давать ожидаемых результатов, а джуниор, наоборот, быстро растёт и показывает высокую эффективность, значительно превышая ожидания.

Вот почему важно не просто смотреть на уровень, а использовать другую классификацию — A, B и C-игроков. Одним из главных преимуществ этой системы является её простота: всего 4 вопроса, которые позволяют быстро и эффективно оценить каждого сотрудника без сложных систем проверки навыков.

* A-игроки — лидеры. Они берут ответственность, быстро учатся новому и всегда решают задачи на 100%.
* B-игроки — добросовестные исполнители, но им иногда нужна поддержка и руководство.
* C-игроки — те, кто тормозит процесс. Им нужно всё объяснять, и даже тогда они не всегда справляются.

🎯 Как понять, кто есть кто? Вот те самые вопросы, которые помогают это определить:

* Что происходит, когда вы делегируете им задачу?
* Как они справляются, когда нужно делать что-то новое?
* Что они делают, когда сталкиваются с преградами?
* Хотели бы вы снова нанять сотрудника с такими качествами?

Теперь разберёмся, как действуют A, B и C-игроки в этих ситуациях:

- A-игроки:
    * Делегируешь задачу — уверен, что она будет выполнена лучше, чем если бы делал ее сам.
    * Когда нужно сделать что-то новое, они учатся сами.
    * Столкнулись с проблемой — сразу просят помощь.
    * Нанимая новых сотрудников, хочешь найти таких же, как они.
- B-игроки:
    * Делегируешь задачу — они справляются, но им нужна поддержка.
    * Нужно новое задание — им потребуется помощь в обучении.
    * Столкнулись с проблемой — тратят время, пытаясь разобраться сами.
    * При найме стремишься найти кого-то лучше.
- C-игроки:
    * Делегируешь задачу — сомневаешься, что она будет выполнена качественно.
    * Нужно новое задание — им нужно объяснять всё по шагам, и результат под вопросом.
    * Столкнулись с проблемой — молчат и затягивают процесс.
    * Нанимая, стараешься найти кого-то совершенно другого.

✅ Самое важное — избавляйтесь от C-игроков. Они замедляют развитие команды.
🔥 А вот B-игроков можно развить в A-игроков с помощью наставничества.

Ссылки: Телеграм | Youtube | VK

Этой теме посвящены целые книги: https://www.amazon.com/Player-Definitive-Playbook-Employees-Leaders/dp/1630479926