Ловушки обучения
Во время обучения бывают ситуации, когда ожидания не совпадают с реальностью, и вы не видите нужного результата. Причин может быть масса, но среди них выделяется группа, связанная с когнитивными искажениями. Об этой группе мы и поговорим.
Меня неправильно учат
Хотя такое встречается сплошь и рядом, часто ученик не осознает глубины происходящего процесса. Мозг привык к подходам, заложенными родителями, школой, секциями, и не находит ассоциаций. Учащегося пугает состояние неопределенности и непредсказуемости (с его точки зрения).
Я думаю, что все сталкивались с подобной ситуацией в школе. Когда нам казалось, что учитель — злодей, а спустя много лет мы отзывались о нем как о единственном, кто действительно нас чему-то научил. Тоже самое происходит и в институте.
Надо не забывать, что обучение новому происходит всегда в режиме дискомфорта — особенно в ситуациях, когда мозгу сложно, и он не знает, что ему делать. По этой же причине выполнение физических упражнений, требующих сложной координации тела, является очень эффективным способом нагружать организм. Посмотрите на распространенный в современном фитнесе функциональный тренинг.
Я все понял
> Все понятно, но как дело касается практики — прихожу в ступор (студент Хекслета)
Эффект «я все понял» проявляется невероятно часто у подавляющего большинства людей. Когда мы смотрим или читаем теорию, нам кажется, что мы все понимаем. Но как доходит до практики, выясняется, что ничего не получается. И на поверку оказывается, что «я ничего не понял».
Существует множество приемов, помогающих определить ваше реальное понимание изученного, например:
• Попробовать сделать это самостоятельно на практике
• Рассказать своими словами другому — так, чтобы он тоже понял (будучи автором курсов, я учусь сильнее, чем учатся мои студенты)
Пока вы не проверили «понимашку», считайте, что вы находитесь во власти эффекта «я все понял», которому доверять нельзя.
Кстати, по этой причине почти не работают большие теоретические курсы и книги в отрыве от производства. Вы можете пройти их до конца с ощущением понимания происходящего, но на практике это будет самообманом.
Я должен знать, как сделать правильно — до того, как начну делать
Вспомните школьные физику, алгебру, геометрию, химию. По этим предметам мы решали огромное количество задач, и никогда не наступал момент, чтобы можно было сказать «теперь я легко могу решить любую задачу» (в рамках известной теории). То есть, вы гарантированно знаете теорию, которая используется в задаче, но задача все равно не решается. И даже после десятков решенных задач, все равно находятся такие, которые не поддаются.
Любая задача в подобных областях — это больше, чем применение теории. Это включение многих видов мышления, помогающих разбить задачу на части, выделить в ней главное (абстрагироваться), найти закономерности, скомбинировать известные приемы. Я уже не говорю про то, что в процессе вы будете постоянно ошибаться и отбрасывать неверные варианты. Постепенно появляется «чутье», ошибок становится меньше, прямых попаданий больше.
Именно это и есть обучение. К сожалению или к счастью, другого пути нет. Важные выводы:
• Не существует единственно верного и тем более «правильного» пути. Всегда есть компромисс.
• Нельзя заранее знать «как правильно». Удачные решения — это фундаментальные знания + опыт предыдущих поколений + ваш собственный опыт (шишки).
• Попытка использовать существующее (возможно, подходящее решение) без глубокого понимания проблематики (самая частая ситуация) приводит к тому, что появляется ложное ощущение «я умею» (а не только «я знаю»). В своей практике постоянно наблюдаю подобную картину: программист с годами опыта попадает в ситуацию, где не работает привычный инструмент, теряется, и либо ничего не может делать, либо делает нечто совершенно непригодное к использованию.
Интересно, что чаще важнее знать «как делать не нужно» и «почему». И, хотя почти всегда можно об этом прочитать в интернете или книгах, но по-настоящему мозг осознает и понимает только свой собственный опыт.
Ссылки: Телеграм | Youtube | VK
Во время обучения бывают ситуации, когда ожидания не совпадают с реальностью, и вы не видите нужного результата. Причин может быть масса, но среди них выделяется группа, связанная с когнитивными искажениями. Об этой группе мы и поговорим.
Меня неправильно учат
Хотя такое встречается сплошь и рядом, часто ученик не осознает глубины происходящего процесса. Мозг привык к подходам, заложенными родителями, школой, секциями, и не находит ассоциаций. Учащегося пугает состояние неопределенности и непредсказуемости (с его точки зрения).
Я думаю, что все сталкивались с подобной ситуацией в школе. Когда нам казалось, что учитель — злодей, а спустя много лет мы отзывались о нем как о единственном, кто действительно нас чему-то научил. Тоже самое происходит и в институте.
Надо не забывать, что обучение новому происходит всегда в режиме дискомфорта — особенно в ситуациях, когда мозгу сложно, и он не знает, что ему делать. По этой же причине выполнение физических упражнений, требующих сложной координации тела, является очень эффективным способом нагружать организм. Посмотрите на распространенный в современном фитнесе функциональный тренинг.
Я все понял
> Все понятно, но как дело касается практики — прихожу в ступор (студент Хекслета)
Эффект «я все понял» проявляется невероятно часто у подавляющего большинства людей. Когда мы смотрим или читаем теорию, нам кажется, что мы все понимаем. Но как доходит до практики, выясняется, что ничего не получается. И на поверку оказывается, что «я ничего не понял».
Существует множество приемов, помогающих определить ваше реальное понимание изученного, например:
• Попробовать сделать это самостоятельно на практике
• Рассказать своими словами другому — так, чтобы он тоже понял (будучи автором курсов, я учусь сильнее, чем учатся мои студенты)
Пока вы не проверили «понимашку», считайте, что вы находитесь во власти эффекта «я все понял», которому доверять нельзя.
Кстати, по этой причине почти не работают большие теоретические курсы и книги в отрыве от производства. Вы можете пройти их до конца с ощущением понимания происходящего, но на практике это будет самообманом.
Я должен знать, как сделать правильно — до того, как начну делать
Вспомните школьные физику, алгебру, геометрию, химию. По этим предметам мы решали огромное количество задач, и никогда не наступал момент, чтобы можно было сказать «теперь я легко могу решить любую задачу» (в рамках известной теории). То есть, вы гарантированно знаете теорию, которая используется в задаче, но задача все равно не решается. И даже после десятков решенных задач, все равно находятся такие, которые не поддаются.
Любая задача в подобных областях — это больше, чем применение теории. Это включение многих видов мышления, помогающих разбить задачу на части, выделить в ней главное (абстрагироваться), найти закономерности, скомбинировать известные приемы. Я уже не говорю про то, что в процессе вы будете постоянно ошибаться и отбрасывать неверные варианты. Постепенно появляется «чутье», ошибок становится меньше, прямых попаданий больше.
Именно это и есть обучение. К сожалению или к счастью, другого пути нет. Важные выводы:
• Не существует единственно верного и тем более «правильного» пути. Всегда есть компромисс.
• Нельзя заранее знать «как правильно». Удачные решения — это фундаментальные знания + опыт предыдущих поколений + ваш собственный опыт (шишки).
• Попытка использовать существующее (возможно, подходящее решение) без глубокого понимания проблематики (самая частая ситуация) приводит к тому, что появляется ложное ощущение «я умею» (а не только «я знаю»). В своей практике постоянно наблюдаю подобную картину: программист с годами опыта попадает в ситуацию, где не работает привычный инструмент, теряется, и либо ничего не может делать, либо делает нечто совершенно непригодное к использованию.
Интересно, что чаще важнее знать «как делать не нужно» и «почему». И, хотя почти всегда можно об этом прочитать в интернете или книгах, но по-настоящему мозг осознает и понимает только свой собственный опыт.
Ссылки: Телеграм | Youtube | VK
Telegram
Организованное программирование | Кирилл Мокевнин
Как из джуниора дойти до мидла, а потом и до синьора
Ютуб https://youtube.com/@mokevnin
Связь для предложений: @kirillpublic
Ютуб https://youtube.com/@mokevnin
Связь для предложений: @kirillpublic
🔥73👍35❤16❤🔥3💯2👀1
Концепции в разных языках программирования, которые помогают лучше понять возможности кодинга как-такового. Многие из этих концепций сильно облегчают жизнь и кардинально меняют способы описания логики. Поехали =>
Uniform Function Call Syntax. Фича языков D и NiM, позволяющая вызывать функцию тремя разными способами: как метод, как функцию и как команду. Удобно для создания цепочек. Во всех случаях это всего лишь функция:
Actor Model. Основной язык Erlang/Elixir и куча либ в других языках. Способ организации кода в легковесные изолированные процессы, общающиеся друг с другом через сообщения. Нет шаред стейта, легко делать канкаренси. Настоящий ООП по Алану Кею.
Pipeline. В языках Elixir, F#, Clojure, Haskell да и пожалуй во всех фп. Позволяет заменять вложенные вызовы функций на плоскую цепочку. Древнейшая концепция, во всю используется в шеле. Мастхев для языков где функции правят балом.
Currying (и частичное применение туда же) Из популярных по умолчанию в ядре в Haskell, Ocaml-подобных, там функции сразу такие. В остальных языках ручками. Очень сильно повышает выразительность и упрощает многие конструкции. Реальное осознание только через haskell
Homoiconicity. Свойство языков, в которых код этого языка одновременно является валидной структурой данных на этом же языке. Относится ко всем лиспам. Дает нереально крутые макросы. Плюс легкую трансформацию кода кодом. Поэтому в лиспах почти все либы, а не часть языка
Pattern Matching (+ Destructuring). Фича ФП языков, которая адаптирована многими императивными. Позволяет полностью изменить принцип работы с условными конструкциями, они становятся не нужны, а сама обработка разных условий становится и проще и понятнее
Mixin (Trait). Фича Ruby, PHP, Лиспов. Имитируется в JS. Один из лучших способ обобщать какое-то поведение и добавлять его в существующие классы. Правильная альтернатива наследованию (в том числе множественному) и абстрактным классам
Открытые классы. Smalltalk, Ruby, Python, JS (прототипы), Kotlin (частично в extension methods). Возможность поменять любой существующий класс прямо в рантайме. Значительно упрощает, например, тестирование. Снижает зависимость от IoC. Проще фиксить либы. Опасная и мегамощная фича
Message Passing. Настоящий в Smaltalk, Ruby, Python, PHP. Это не просто выбор полиморной реализации, а возможность определить общую реакцию для всех явно не определенных сообщений. Открывать путь к динамическим методам, которые нигде не определены.
В JS такое делается только через Proxy, который позволяет перехватывать любой вызов. Правда только для свойств. Для методов придется сильно извращаться и все равно получится очень тяжелое решение. Поэтому там это делают только в учебных целях.
Multimethods. Clojure и остальные лиспы (через CLOS). Киллер фича, позволяющая делать мультидиспетчеризацию (не только по типу) при создании полиморфных реализаций. Значительно сокращает количество и сложность иерархий классов. Обобщает полиморфизм.
List Comprehension. Фича почти всех ФП языков + Python, Smalltalk. Удобный механизм адаптированный прямиком из математики, для описания преобразования коллекций. Заменяет мапы/фильтры/вотевер.
Monads. Тут все просто. Монада это моноид в категории эндофункторов 😄 В целом штука, позволяющая управлять потоком выполнения и делать с ним всякое интересное. Из крутого: Maybe, Either. Порекомендуйте крутую литературу для интересующихся плс!
Generator. Есть во многих языках. Позволяют создавать бесконечные коллекции благодаря тому, что они формируются не сразу, а генерируются в процессе обхода. Часто связаны с ключевиком yield. Значительно упрощают написание итераторов
Еще можно добавить про горячую замену кода. Смолтолк и Эрланг тут чемпионы. Код на эрланге может десятилетиями работать без остановки и постоянно обновляться
Ссылки: Телеграм | Youtube | VK
Uniform Function Call Syntax. Фича языков D и NiM, позволяющая вызывать функцию тремя разными способами: как метод, как функцию и как команду. Удобно для создания цепочек. Во всех случаях это всего лишь функция:
p.move(5, 7)
move(p, 5, 7)
p.move 5, 7
Actor Model. Основной язык Erlang/Elixir и куча либ в других языках. Способ организации кода в легковесные изолированные процессы, общающиеся друг с другом через сообщения. Нет шаред стейта, легко делать канкаренси. Настоящий ООП по Алану Кею.
Pipeline. В языках Elixir, F#, Clojure, Haskell да и пожалуй во всех фп. Позволяет заменять вложенные вызовы функций на плоскую цепочку. Древнейшая концепция, во всю используется в шеле. Мастхев для языков где функции правят балом.
promise
|> await
|> x => doubleSay(x, ', ')
|> capitalize
|> x => x + '!'
|> x => new User.Message(x)
|> x => stream.write(x)
|> await
|> console.log;
Currying (и частичное применение туда же) Из популярных по умолчанию в ядре в Haskell, Ocaml-подобных, там функции сразу такие. В остальных языках ручками. Очень сильно повышает выразительность и упрощает многие конструкции. Реальное осознание только через haskell
Homoiconicity. Свойство языков, в которых код этого языка одновременно является валидной структурой данных на этом же языке. Относится ко всем лиспам. Дает нереально крутые макросы. Плюс легкую трансформацию кода кодом. Поэтому в лиспах почти все либы, а не часть языка
Pattern Matching (+ Destructuring). Фича ФП языков, которая адаптирована многими императивными. Позволяет полностью изменить принцип работы с условными конструкциями, они становятся не нужны, а сама обработка разных условий становится и проще и понятнее
Mixin (Trait). Фича Ruby, PHP, Лиспов. Имитируется в JS. Один из лучших способ обобщать какое-то поведение и добавлять его в существующие классы. Правильная альтернатива наследованию (в том числе множественному) и абстрактным классам
Открытые классы. Smalltalk, Ruby, Python, JS (прототипы), Kotlin (частично в extension methods). Возможность поменять любой существующий класс прямо в рантайме. Значительно упрощает, например, тестирование. Снижает зависимость от IoC. Проще фиксить либы. Опасная и мегамощная фича
Message Passing. Настоящий в Smaltalk, Ruby, Python, PHP. Это не просто выбор полиморной реализации, а возможность определить общую реакцию для всех явно не определенных сообщений. Открывать путь к динамическим методам, которые нигде не определены.
В JS такое делается только через Proxy, который позволяет перехватывать любой вызов. Правда только для свойств. Для методов придется сильно извращаться и все равно получится очень тяжелое решение. Поэтому там это делают только в учебных целях.
Multimethods. Clojure и остальные лиспы (через CLOS). Киллер фича, позволяющая делать мультидиспетчеризацию (не только по типу) при создании полиморфных реализаций. Значительно сокращает количество и сложность иерархий классов. Обобщает полиморфизм.
List Comprehension. Фича почти всех ФП языков + Python, Smalltalk. Удобный механизм адаптированный прямиком из математики, для описания преобразования коллекций. Заменяет мапы/фильтры/вотевер.
Monads. Тут все просто. Монада это моноид в категории эндофункторов 😄 В целом штука, позволяющая управлять потоком выполнения и делать с ним всякое интересное. Из крутого: Maybe, Either. Порекомендуйте крутую литературу для интересующихся плс!
Generator. Есть во многих языках. Позволяют создавать бесконечные коллекции благодаря тому, что они формируются не сразу, а генерируются в процессе обхода. Часто связаны с ключевиком yield. Значительно упрощают написание итераторов
Еще можно добавить про горячую замену кода. Смолтолк и Эрланг тут чемпионы. Код на эрланге может десятилетиями работать без остановки и постоянно обновляться
Ссылки: Телеграм | Youtube | VK
Telegram
Организованное программирование | Кирилл Мокевнин
Как из джуниора дойти до мидла, а потом и до синьора
Ютуб https://youtube.com/@mokevnin
Связь для предложений: @kirillpublic
Ютуб https://youtube.com/@mokevnin
Связь для предложений: @kirillpublic
👍73🔥32❤26🤡4👎1👀1
Пост-знакомство
На днях канал перевалил за 7000 тысяч подписчиков, ура! В связи с этим предлагаю попробовать сделать пост знакомство, где каждый сможет рассказать про себя и попиарить свой телеграм/ютуб/вотевер. Нужны сотрудники - пишите, ищите работу - пишите. Начну с себя:
В разработке я с 2007 года. Начинал с php, потом ruby, clojure, js/ts (фронт/бек), java, erlang/elixir, python, увлечение функциональщиной (ocaml, haskell), тимлидство, управление людьми, стартапы, vim. Могу сказать что хорошо разбираюсь в бекенд фреймворках (в том числе писал свои и они в продакшене), orm, devops, тестировании, инженерной культуре за что меня приглашают в качестве консультанта или тренера в разные компании. В 2013 я присоединился к Рахиму делать Хекслет и вот уже 11 лет занимаюсь бизнесом, попутно прокачавшись в методологиях, преподавании и многих других страшных штуках. Теперь вещаю все это вам тут и на ютубе)
p.s. И исчо, у нас пока тут с вами нет чата, но я вижу желание общаться больше чем просто в постах. Поэтому предлагаю присоединиться, в наше Хекслет комьюнити, где уже 8000 человек. @hexletcommunity здесь можно поболтать и с опытными разработчиками и помочь новичкам, которые тоже тусуют в этом чате.
Ссылки: Телеграм | Youtube | VK
На днях канал перевалил за 7000 тысяч подписчиков, ура! В связи с этим предлагаю попробовать сделать пост знакомство, где каждый сможет рассказать про себя и попиарить свой телеграм/ютуб/вотевер. Нужны сотрудники - пишите, ищите работу - пишите. Начну с себя:
В разработке я с 2007 года. Начинал с php, потом ruby, clojure, js/ts (фронт/бек), java, erlang/elixir, python, увлечение функциональщиной (ocaml, haskell), тимлидство, управление людьми, стартапы, vim. Могу сказать что хорошо разбираюсь в бекенд фреймворках (в том числе писал свои и они в продакшене), orm, devops, тестировании, инженерной культуре за что меня приглашают в качестве консультанта или тренера в разные компании. В 2013 я присоединился к Рахиму делать Хекслет и вот уже 11 лет занимаюсь бизнесом, попутно прокачавшись в методологиях, преподавании и многих других страшных штуках. Теперь вещаю все это вам тут и на ютубе)
p.s. И исчо, у нас пока тут с вами нет чата, но я вижу желание общаться больше чем просто в постах. Поэтому предлагаю присоединиться, в наше Хекслет комьюнити, где уже 8000 человек. @hexletcommunity здесь можно поболтать и с опытными разработчиками и помочь новичкам, которые тоже тусуют в этом чате.
Ссылки: Телеграм | Youtube | VK
Telegram
Организованное программирование | Кирилл Мокевнин
Как из джуниора дойти до мидла, а потом и до синьора
Ютуб https://youtube.com/@mokevnin
Связь для предложений: @kirillpublic
Ютуб https://youtube.com/@mokevnin
Связь для предложений: @kirillpublic
❤60👍28🔥8🤔2🤮1
Долгожданный выпуск с
@VBragilevsky
где мы прошлись по системе образования https://youtube.com/watch?v=38N2c6SWnZE Показали все что скрыто изнутри и сравнили с европейским и американским
@VBragilevsky
где мы прошлись по системе образования https://youtube.com/watch?v=38N2c6SWnZE Показали все что скрыто изнутри и сравнили с европейским и американским
YouTube
Где учат лучше: в США, Европе или России? / Виталий Брагилевский #7
Всем ли программистам нужно высшее образование и чем оно отличается в разных странах? В этом видео вместе с Виталием Брагилевским (https://bravit.pro) разберём, когда высшее образование необходимо, а когда можно обойтись без него, обсудим важность математики…
👍35🔥14❤9👀1🙈1
Как понимать критичность разных кусков кода при разработке и ревью. Что от чего зависит, где можно и нужно забить, а где нет. (твиттер-тред)
Глобально и немного грубо весь прикладной код можно разделить на три уровня: Домен – то где бизнес логика + хранилища (бд), Управляющий код – то что оперирует доменом + инфраструктурный код и Представление – любые выходные данные типа binary, json, html и так далее.
Ошибки на этих уровнях имеют совсем разные последствия. Некоторые целиком влияют на архитектуру и дальнейшую поддержку всего проекта, другие же локальны и создают грязный код по месту. Важно четко разделять их, для того чтобы не создавать напряжение там где его нет
Самое простое – представление. Код формирующий вывод может быть грязным и будет грязным. Главное что нужно понимать – это неизбежно. С этим нужно смириться и не нужно пытаться доводить его до совершенства. От этого кода не зависят другие части системы, это конечная точка
Как пример код формирующий jsx в React. Если его много и он тяжелый, то его лучше разделять, но нет смысла пытаться делать его максимально компактным и красивым. Сегодня код один, завтра другой, потом вообще все поменяли и выкинули
Тоже самое касается переводов. Я знаю людей которые стремятся следить за ключами, убирают дубли, удаляют не используемые. Само по себе это неплохо, но есть черта после которой такая работа превращается в мышиную возню. Чистить можно бесконечно, но влияния на качество нет
Теперь обратная сторона – Домен. Сущности и связи между ними – буквально ключевая вещь. Абсолютно весь остальной код зависит от этого, то как вы разбиваете приложение тоже зависит от этого. Важно определить с чем мы имеем дело и какие кейсы нас ждут впереди
Например на Хекслете у урока может быть только одна практика (o2o). Почему не несколько? Если сделать несколько, то сложность системы возрастет многократно. Проще исходить из того, что если одной практики мало, то значит урок надо разбивать. Ключевое влияние на всю систему
Организация домена в свою очередь влияет на то как мы храним данные и здесь тоже все очень важно. Грязи в базе должно быть минимум. Изменения структуры, восстановление неконсистентных данных – все это очень дорого. Причем важна не только нормализация, но и денормализация
Если говорить про фронт, то аналогом будет структура состояния. Ее гораздо проще менять чем структуру базы данных, однако состояние это ключевая вещь. Нужно хорошо об этом думать и знать как, в принципе, грамотно организовывать стейт (привет автоматы). У меня аж целый курс есть
Дальше идем в инфраструктурный и управляющий код. Этого кода обычно много и он бывает очень разный. С ходу можно выделить API, то есть все что торчит наружу. Как только появляются реальные клиенты, то все, мы повязаны. Обновление API – одна из самых болезненных операций
Поэтому об API нужно думать много и до того, как код написан. При этом API так же зависит от Домена. API не обязательно HTTP, вполне возможно что вы проектируете библиотеку или какую-то подсистему
Помимо этого есть отдельная категория хорошо изолированных абстракций, типа математических или других чистых функций, интерфейс которых довольно стабилен. В таком случае качество внутренностей не важно вообще. Это фиксированный тех долг, который не влияет на систему
Простой пример – сортировка. Она может быть написана сколь угодно плохо, лишь бы работала. Переписать всегда успеем, если нас это устраивает по производительности. Кстати не могу не порекомендовать фантастический гайд https://optimization.guide/
Остальной код уже сложнее категоризировать. Здесь уже по ситуации. Если речь идет про извлечение данных, то код может быть достаточно грязным, если изменение – то требования к нему выше. Плюс важно разделение по слоям. Например применение ServiceLayer.
Все это помогает мне и при написании своего кода и при ревью. На вещи, которые мало влияют можно обращать меньше внимания, но когда речь идет про, например, Домен. Мы обязательно проговариваем это голосом. Это позволяет использовать асинхронный код ревью, то есть уже после мержа
Ссылки: Телеграм | Youtube | VK
Глобально и немного грубо весь прикладной код можно разделить на три уровня: Домен – то где бизнес логика + хранилища (бд), Управляющий код – то что оперирует доменом + инфраструктурный код и Представление – любые выходные данные типа binary, json, html и так далее.
Ошибки на этих уровнях имеют совсем разные последствия. Некоторые целиком влияют на архитектуру и дальнейшую поддержку всего проекта, другие же локальны и создают грязный код по месту. Важно четко разделять их, для того чтобы не создавать напряжение там где его нет
Самое простое – представление. Код формирующий вывод может быть грязным и будет грязным. Главное что нужно понимать – это неизбежно. С этим нужно смириться и не нужно пытаться доводить его до совершенства. От этого кода не зависят другие части системы, это конечная точка
Как пример код формирующий jsx в React. Если его много и он тяжелый, то его лучше разделять, но нет смысла пытаться делать его максимально компактным и красивым. Сегодня код один, завтра другой, потом вообще все поменяли и выкинули
Тоже самое касается переводов. Я знаю людей которые стремятся следить за ключами, убирают дубли, удаляют не используемые. Само по себе это неплохо, но есть черта после которой такая работа превращается в мышиную возню. Чистить можно бесконечно, но влияния на качество нет
Теперь обратная сторона – Домен. Сущности и связи между ними – буквально ключевая вещь. Абсолютно весь остальной код зависит от этого, то как вы разбиваете приложение тоже зависит от этого. Важно определить с чем мы имеем дело и какие кейсы нас ждут впереди
Например на Хекслете у урока может быть только одна практика (o2o). Почему не несколько? Если сделать несколько, то сложность системы возрастет многократно. Проще исходить из того, что если одной практики мало, то значит урок надо разбивать. Ключевое влияние на всю систему
Организация домена в свою очередь влияет на то как мы храним данные и здесь тоже все очень важно. Грязи в базе должно быть минимум. Изменения структуры, восстановление неконсистентных данных – все это очень дорого. Причем важна не только нормализация, но и денормализация
Если говорить про фронт, то аналогом будет структура состояния. Ее гораздо проще менять чем структуру базы данных, однако состояние это ключевая вещь. Нужно хорошо об этом думать и знать как, в принципе, грамотно организовывать стейт (привет автоматы). У меня аж целый курс есть
Дальше идем в инфраструктурный и управляющий код. Этого кода обычно много и он бывает очень разный. С ходу можно выделить API, то есть все что торчит наружу. Как только появляются реальные клиенты, то все, мы повязаны. Обновление API – одна из самых болезненных операций
Поэтому об API нужно думать много и до того, как код написан. При этом API так же зависит от Домена. API не обязательно HTTP, вполне возможно что вы проектируете библиотеку или какую-то подсистему
Помимо этого есть отдельная категория хорошо изолированных абстракций, типа математических или других чистых функций, интерфейс которых довольно стабилен. В таком случае качество внутренностей не важно вообще. Это фиксированный тех долг, который не влияет на систему
Простой пример – сортировка. Она может быть написана сколь угодно плохо, лишь бы работала. Переписать всегда успеем, если нас это устраивает по производительности. Кстати не могу не порекомендовать фантастический гайд https://optimization.guide/
Остальной код уже сложнее категоризировать. Здесь уже по ситуации. Если речь идет про извлечение данных, то код может быть достаточно грязным, если изменение – то требования к нему выше. Плюс важно разделение по слоям. Например применение ServiceLayer.
Все это помогает мне и при написании своего кода и при ревью. На вещи, которые мало влияют можно обращать меньше внимания, но когда речь идет про, например, Домен. Мы обязательно проговариваем это голосом. Это позволяет использовать асинхронный код ревью, то есть уже после мержа
Ссылки: Телеграм | Youtube | VK
optimization.guide
Продуманная оптимизация
Наконец появилась толковая бесплатная книга о серверной оптимизации на русском. Написано толково и с юмором. Рекомендую!
🔥44👍35❤12✍1🤮1👀1
Фиганул статью на хабр про монокультуру в программировании: https://habr.com/ru/articles/838682/ Где рассказываю про то, как монокультура (использование одной технологии повсеместно) мешает и вредит проектам
Ссылки: Телеграм | Youtube | VK
Ссылки: Телеграм | Youtube | VK
Хабр
Монокультура в программировании
Монокультура в программировании — это использование одного стека для решения всех возникающих задач. Она существует не только на уровне конкретного человека и его предпочтений, но также часто...
👍50🔥12👏4❤3👀1
Куда переезжать из ноушена? Спойлер: мы нашли замену
Морально мы были готовы к письму счастья, так как с 12 сентября вступал запрет на предоставление сервисов из США, но честно говоря надеялись, что они не будут вычислять по айпи и набивать. В итоге именно это они и собираются сделать независимо от того, где находится компания на которую все зарегано. Что ж, я сегодня плотно засел за сервисы, чтобы найти что-то подходящее. Я нашел таки сервис, который нас устроил, но сначала немного вводных.
https://vc.ru/u/14739-kirill-mokevnin/1429593-kuda-pereezzhat-iz-noushena-spoiler-my-nashli-zamenu
Морально мы были готовы к письму счастья, так как с 12 сентября вступал запрет на предоставление сервисов из США, но честно говоря надеялись, что они не будут вычислять по айпи и набивать. В итоге именно это они и собираются сделать независимо от того, где находится компания на которую все зарегано. Что ж, я сегодня плотно засел за сервисы, чтобы найти что-то подходящее. Я нашел таки сервис, который нас устроил, но сначала немного вводных.
https://vc.ru/u/14739-kirill-mokevnin/1429593-kuda-pereezzhat-iz-noushena-spoiler-my-nashli-zamenu
13👍47🔥6❤1👀1
Когда нужно внедрять микросервисы? Новый выпуск с кофаундером и техническим директором проекта Scentbird, который захватил американский рынок уже на канале: youtube.com/watch?v=cqKJD3ovxEc
В этом выпуске Андрей рассказывает про техническую составляющую проекта, который обслуживает сотни тысяч клиентов, предоставляя духи по подписке (и не только) по всем штатам. Какие технологии, принципы, организация, найм, совершенные ошибки. Показать все что скрыто.
В этом выпуске Андрей рассказывает про техническую составляющую проекта, который обслуживает сотни тысяч клиентов, предоставляя духи по подписке (и не только) по всем штатам. Какие технологии, принципы, организация, найм, совершенные ошибки. Показать все что скрыто.
4🔥19👍16⚡2👀1
Игры разума. Проект, который может вас затянуть!
Попробую ввести традицию пятничных постов, где я рассказываю что-то интересное, вокруг it или про it, но не код. Где-то в 2008 году, я наткнулся на сайт braingames.ru, на котором собраны всевозможные логические задачи. В то время меня от них знатно перло и я годами заходил на этот сайт и решал их. У проекта большое комьюнити и множество волонтеров помогающих с добавлением заданий, проверок решений и другими вещами, вплоть до разработки или юридического сопровождения.
Предлагаю решить одну задачку оттуда:
Мегамозг может выйти на свободу, если он справится с заданием: перед ним две двери, одна из них ведет на волю, другая — дорога к смерти. Здесь же сидят два стражника, причем один из них либо лжец, либо правдивец, а второй — хитрец, то есть человек, который говорит правду и ложь строго поочередно (либо на нечетные вопросы отвечает ложью, а на четные — правдой, либо наоборот). Оба стражника знают, какая из дорог ведет на волю, но Мегамозгу неизвестно, кто из стражников хитрец. Мегамозг имеет право задать два вопроса одному из стражников (вопросы должны быть простыми). Как ему определить дорогу, ведущую на свободу?
Источник: https://braingames.ru/?path=comments&puzzle=94
Ссылки: Телеграм | Youtube | VK
Попробую ввести традицию пятничных постов, где я рассказываю что-то интересное, вокруг it или про it, но не код. Где-то в 2008 году, я наткнулся на сайт braingames.ru, на котором собраны всевозможные логические задачи. В то время меня от них знатно перло и я годами заходил на этот сайт и решал их. У проекта большое комьюнити и множество волонтеров помогающих с добавлением заданий, проверок решений и другими вещами, вплоть до разработки или юридического сопровождения.
Предлагаю решить одну задачку оттуда:
Мегамозг может выйти на свободу, если он справится с заданием: перед ним две двери, одна из них ведет на волю, другая — дорога к смерти. Здесь же сидят два стражника, причем один из них либо лжец, либо правдивец, а второй — хитрец, то есть человек, который говорит правду и ложь строго поочередно (либо на нечетные вопросы отвечает ложью, а на четные — правдой, либо наоборот). Оба стражника знают, какая из дорог ведет на волю, но Мегамозгу неизвестно, кто из стражников хитрец. Мегамозг имеет право задать два вопроса одному из стражников (вопросы должны быть простыми). Как ему определить дорогу, ведущую на свободу?
Источник: https://braingames.ru/?path=comments&puzzle=94
Ссылки: Телеграм | Youtube | VK
braingames.ru
Логические задачи [Игры разума — Сообщество любителей головоломок]
Около 500 уникальных задач разного уровня сложности тщательно отобранных и обработанных
коллективом модераторов сайта. Основной идеей сайта является недоступность ответов до момента самостоятельного решения задачи, а также проверка ответов людьми, прошедшими…
коллективом модераторов сайта. Основной идеей сайта является недоступность ответов до момента самостоятельного решения задачи, а также проверка ответов людьми, прошедшими…
1👍33🤯9🔥7❤3
Любителям Go и им сочувствующим, крайне рекомендую канал Николая Тузова. Он ведет самый популярный русскоязычный youtube-канал посвященный Go где рассматривает все от собеседований до принципов написания кода. Вот что сам Коля говорит про него: “основная идея канала - сложные вещи простым языком. Стараюсь всегда копать максимально глубоко, но при этом максимально понятно. К примеру, если уж разбираем мапы, то спустимся вплоть до разбора их исходного кода и того, как конкретно там устроены бакеты)”
И естественно у него есть телеграм канал который мне еще предстоит обогнать!
Несколько интересных материалов:
Как на самом деле устроен тип Map в Golang?
JWT простым языком - краткий ликбез
Приятно, что студенты Хекслета доходят так далеко 🙂
И естественно у него есть телеграм канал который мне еще предстоит обогнать!
Несколько интересных материалов:
Как на самом деле устроен тип Map в Golang?
JWT простым языком - краткий ликбез
Приятно, что студенты Хекслета доходят так далеко 🙂
YouTube
Николай Тузов — Golang
Сложные вещи простым языком.
Меня зовут Николай. Я много лет занимаюсь разработкой, и много лет дружу с Go. Сейчас работаю в компании Different Technologies (мексиканский финтех), ранее работал в Lamoda и Gaijin Entertainment. Помимо Go и вообще бэкэнда…
Меня зовут Николай. Я много лет занимаюсь разработкой, и много лет дружу с Go. Сейчас работаю в компании Different Technologies (мексиканский финтех), ранее работал в Lamoda и Gaijin Entertainment. Помимо Go и вообще бэкэнда…
👍59❤19🔥13💯3❤🔥2👏1🤔1🤝1
Как значительно упростить интеграции между вашим проектом и сторонними системами (твиттер-тред)
Все что касается событий, рекламных кабинетов, crm, аналитик, слака и кучи других систем. Вы используете сервисы типа Zapier?
Сначала про задачу. В любом SaaS сервисе, помимо самого продукта и его фич, есть много всего вокруг. CRM для продаж, система сквозной аналитики, рекламные кабинеты, событийная анилитка, автоматизация маркетинга (email, боты), виджеты на сайте и так далее. Тонны систем
И все они работают в связке. Когда на сайте оставляют заявку, она должна попасть в CRM продавцам, должна попасть в рекламный кабинет и систему сквозной аналитики для анализа эффективности, а еще нужна нотификация в слак и тикет на работу с клиентов после того как сделка закрылась
Мы получаем взаимодействие не просто точка-точка, а целый пайплайн, в котором задействованы по 3-5, сервисов. Иногда взаимодействие идет без самого сервиса. Иногда наш сервис должен как генерировать события, так и уметь обрабатывать ответы от других систем
И, реклама, это всего лишь один из примеров. Нам так же нужно строить онбординг, а для этого есть свои сервисы, нужно запускать ботов, нужно выполнять продуктовую аналитику, нужно рассылать письма по событиям (и даже целые цепочки писем). Для всего этого есть свои решения
На вскидку то что мы используем чтобы было понятнее. Некоторые из них супер, другие не очень, но без них мы бы порвались: https://activecampaign.com, https://amplitude.com, https://rick.ai, https://trengo.com, https://sparkpost.com и т.п.
Во всех сервисах есть интеграции, но они не покрывают все. Всегда есть сервисы между которыми нет прямой связи. Плюс есть сайт, с которым нет связи вообще ни у кого если мы ее не сделаем сами. Как в таком случае строится логика работы?
Самый деревянный вариант – на каждое событие, например, регистрацию, делать в коде обработчик, который отправляет событие в нужную систему. Потом оказывается что регистрация нужна в 5 разных местах, поэтому обработчик резко вырастает в размерах. А событий надо много и везде
Вот тут все превращается в ад. В коде приходится прописывать абсолютно каждый сервис. Например появилась новая аналитика, которой нужно 5 событий. Нам придется пойти и в 5 местах на сайте добавить вызов api этого сервиса. И это в лучшем случае, если отправка событий изолирована
Достаточно давно появился сервис, который захватил эту нишу: Zapier. Он позволяет соединять между собой все что имеет апи. Это визуальный конструктор, в котором мы указываем откуда и какие взять данные и куда их отправить, причем выполнив нужные преобразования. Он сразу включает в себя интеграцию со всеми популярными сервисами, поэтому здесь не нужно программирование. Мы просто говорим чего хотим от одной системы и куда это надо послать.
Zapier вводит два понятия: действие и триггер. Триггер это событие, которое происходит внутри какого-то сервиса. Чтобы Zapier мог его получить, нужно внутри сервиса настроить отправку события на вебхук запира. Большая часть сервисов так делает из коробки
А действие это вызов апи какого-то сервиса, в которое мы хотим из запира отправить данные. Например заполнить таблицу в гугл доках, создать мессадж в слаке или отправить письмо.
То есть так мы интегрируем сервисы между собой. А как же события нашего проекта? Очень просто, внутри запира создаются эндпоинты для разных событий и дальше, наш сайт отправляет события вместе с данными именно на эти эндпоинты. Сайт знает только про запир
Теперь, если нам нужно отправлять событие регистрации в какую-то новую систему, мы просто идем в запир и делаем связку "регистрация" => "создание клиента в pipedrive" (как пример). Сайт не трогаем, нет деплоя, даже программистов нет. Это могут делать аналитики/маркетологи
Запир оч дорогой инструмент + он не работает в рф, поэтому часть задач мы решаем с помощью сервисов типа интегромата, но большая часть наших интеграций проходит через n8n.io, который имеет self-hosted версию (и вообще это open source). Если вы еще его не юзаете, то крайне рекомедную
Ссылки: Телеграм | Youtube | VK
Все что касается событий, рекламных кабинетов, crm, аналитик, слака и кучи других систем. Вы используете сервисы типа Zapier?
Сначала про задачу. В любом SaaS сервисе, помимо самого продукта и его фич, есть много всего вокруг. CRM для продаж, система сквозной аналитики, рекламные кабинеты, событийная анилитка, автоматизация маркетинга (email, боты), виджеты на сайте и так далее. Тонны систем
И все они работают в связке. Когда на сайте оставляют заявку, она должна попасть в CRM продавцам, должна попасть в рекламный кабинет и систему сквозной аналитики для анализа эффективности, а еще нужна нотификация в слак и тикет на работу с клиентов после того как сделка закрылась
Мы получаем взаимодействие не просто точка-точка, а целый пайплайн, в котором задействованы по 3-5, сервисов. Иногда взаимодействие идет без самого сервиса. Иногда наш сервис должен как генерировать события, так и уметь обрабатывать ответы от других систем
И, реклама, это всего лишь один из примеров. Нам так же нужно строить онбординг, а для этого есть свои сервисы, нужно запускать ботов, нужно выполнять продуктовую аналитику, нужно рассылать письма по событиям (и даже целые цепочки писем). Для всего этого есть свои решения
На вскидку то что мы используем чтобы было понятнее. Некоторые из них супер, другие не очень, но без них мы бы порвались: https://activecampaign.com, https://amplitude.com, https://rick.ai, https://trengo.com, https://sparkpost.com и т.п.
Во всех сервисах есть интеграции, но они не покрывают все. Всегда есть сервисы между которыми нет прямой связи. Плюс есть сайт, с которым нет связи вообще ни у кого если мы ее не сделаем сами. Как в таком случае строится логика работы?
Самый деревянный вариант – на каждое событие, например, регистрацию, делать в коде обработчик, который отправляет событие в нужную систему. Потом оказывается что регистрация нужна в 5 разных местах, поэтому обработчик резко вырастает в размерах. А событий надо много и везде
Вот тут все превращается в ад. В коде приходится прописывать абсолютно каждый сервис. Например появилась новая аналитика, которой нужно 5 событий. Нам придется пойти и в 5 местах на сайте добавить вызов api этого сервиса. И это в лучшем случае, если отправка событий изолирована
Достаточно давно появился сервис, который захватил эту нишу: Zapier. Он позволяет соединять между собой все что имеет апи. Это визуальный конструктор, в котором мы указываем откуда и какие взять данные и куда их отправить, причем выполнив нужные преобразования. Он сразу включает в себя интеграцию со всеми популярными сервисами, поэтому здесь не нужно программирование. Мы просто говорим чего хотим от одной системы и куда это надо послать.
Zapier вводит два понятия: действие и триггер. Триггер это событие, которое происходит внутри какого-то сервиса. Чтобы Zapier мог его получить, нужно внутри сервиса настроить отправку события на вебхук запира. Большая часть сервисов так делает из коробки
А действие это вызов апи какого-то сервиса, в которое мы хотим из запира отправить данные. Например заполнить таблицу в гугл доках, создать мессадж в слаке или отправить письмо.
То есть так мы интегрируем сервисы между собой. А как же события нашего проекта? Очень просто, внутри запира создаются эндпоинты для разных событий и дальше, наш сайт отправляет события вместе с данными именно на эти эндпоинты. Сайт знает только про запир
Теперь, если нам нужно отправлять событие регистрации в какую-то новую систему, мы просто идем в запир и делаем связку "регистрация" => "создание клиента в pipedrive" (как пример). Сайт не трогаем, нет деплоя, даже программистов нет. Это могут делать аналитики/маркетологи
Запир оч дорогой инструмент + он не работает в рф, поэтому часть задач мы решаем с помощью сервисов типа интегромата, но большая часть наших интеграций проходит через n8n.io, который имеет self-hosted версию (и вообще это open source). Если вы еще его не юзаете, то крайне рекомедную
Ссылки: Телеграм | Youtube | VK
2👍43🔥16🤔2
На ютубе вышло душевное видео с моим старым другом Антоном Плешивцевым, который прошел длинный путь от одного из первых разработчиков Aviasales в тайланде (у них там офис) до технического директора создавшему 8 лет назад с нуля проект Bravado на американском рынке, крупнейшему маркетплейсу продавцов.
Поговорили мы обо всем чем только можно. О том как изменился фронтенд за 14 лет, истории из тайской жизни, организация удаленной работы, создание собственной игры и попадание в Stream, рекрутинг в сша, преимущества go и куче других тем. Наслаждайтесь 🙂 https://www.youtube.com/watch?v=qhbXHlgE6Yo
Поговорили мы обо всем чем только можно. О том как изменился фронтенд за 14 лет, истории из тайской жизни, организация удаленной работы, создание собственной игры и попадание в Stream, рекрутинг в сша, преимущества go и куче других тем. Наслаждайтесь 🙂 https://www.youtube.com/watch?v=qhbXHlgE6Yo
YouTube
(Без)облачная жизнь и работа на Aviasales в Таиланде / Антон Плешивцев / #9
Помните период, когда во всех рекламах с ИТ были пальмы, пляж и преимущества удалённой работы? В этом выпуске обсуждаем, так ли классно работать в Таиланде, изменения в мире фронтенда, вспоминая о старых технологиях и появлении Angular.
В этом мне поможет…
В этом мне поможет…
2🔥35👍23❤6👻1
Что вы предпочитаете: обычные утверждения (asserts) или матчеры? Сначала немного терминов. Утверждения это когда мы пишем
Утверждения часто встроены прямо в сам язык и обычно их немного, буквально 3-5. Больше могут добавлять тестовые фреймворки, но без фанатизма. Их легко запомнить и легко пользоваться, но, как правило, они не информативны: "ожидали тру, пришло фолс", "ожидали 5 пришло 3"
С матчерами ситуация отличается. Обычно их много или очень много. Только базовых внутри тестовых фреймворках много десятков, плюс модификаторы, плюс экстеншены. Короче сотня другая легко. Использовать их уже целое искусство, за этим нужно следить и постоянно корректировать коллег
А в чем плюсы? Если вам нужна документация из тестов, то матчеры сделают ее понятнее. Обычно (но не всегда) вывод матчеров содержит больше полезной информации для отладки, что упрощает само тестирование. Ну и во многих языках тестовые фреймворки с матчерами являются стандартом
Есть еще всякие особые истории типа property-based тестирования или снепшот или скриншот тестирования, но это здесь мы про них не говорим. Больше вам на заметку, если не знаете про них, то обязательно почитайте.
В принципе на этом можно было бы и закончить, если бы не одна статья, которая в 2009 году значительно повлияла на проверки в тестах. Эта статья про Power Assert в Groovy https://dontmindthelanguage.wordpress.com/2009/12/11/groovy-1-7-power-assert/… Спойлер: лучшее от обоих миров: утверждений и матчеров с добавлением магии
Концепция такая, у нас есть ровно одно утверждение, внутри которого мы делаем любую проверку. Это утверждение, анализирует результат *каждого* подвыражения и выводит его для отладки. Так мы получаем максимум информации о том что пошло не так. Ниже реальный вывод
Концепция оказалась настолько удачной и удобной, что либу Power Assert портировали практически в каждый язык. Лучше всего пожалуй описано в JS, там в начале ридми есть хороший блок, с объяснением почему именно этот подход: https://github.com/power-assert-js/power-assert#description
Кто-нибудь уже использовал Power Assert? Или вы не знали про него?
Ссылки: Телеграм | Youtube | VK
p.s. Скиньте в комментариях порт power assert или аналогичную либу из вашего языка/экосистемы
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 или аналогичную либу из вашего языка/экосистемы
Don't mind the language
Groovy 1.7 Power Assert
I already mentioned this in my previous post, but I wanted to go a little bit deeper on this: the new Groovy Power Assert (and no, let’s not call is GPA). Groovy Power Assert makes assertions…
👍38❤12🔥5🥴2🐳1
Я устроился на мидла без опыта
Такую фразу все чаще встречаю на просторах сети. Хочется это зафиксировать. Быть реальным мидлом и находиться на позиции мидл в какой-то компании, где это определяется формальными признаками, типа прошел собес на мидла это не одно и тоже. Нет ничего плохого в том чтобы пройти чек и занять такую должность с соответствующей зарплатой, но важно не обманывать самого себя, иначе потом будет больно.
Формальные критерии вводят для того, чтобы хоть как-то понимать и контролировать процессы, когда в компании много людей. Без этого никак. Но никакая система не делает все однозначно определенным. Всегда есть ложнопозитивные и ложнонегативные срабатывания. В мелких компаниях с этим проще, если тебя берут на мидла, то и реальную работу ждут на мидла, поэтому если оно не соответствует, то будет разговор. В крупняке можно затеряться, но многое зависит от лида.
Если убрать всю эту шелуху, что бы хотел каждый работадатель от мидла?
- Опыт работы с технологиями. Человек знает как технически решить поставленную задачу по кодингу и может ее сделать в большинстве ситуаций
- Человек может оценить основные риски, потому что в этом заключается его мидловость. Он знает к чему может привести то или иное решение, знает о чем надо подумать, предупредить, организовать плавный переход, поддержку старой системы и так далее. Такой опыт набирается через боль и ошибки (не ронял прод, не мидл)
- Он способен задать вопросы при постановке задачи, чтобы доформулировать ее до нужного уровня.
При этом, все это специфично под каждую конкретную компанию. Мидл в одном месте, в другом может быть не мидл и скорее всего будет не мидл. Хотя конечно, есть и общие вещи, которые достаточно быстро добираются при хорошей базе. Умение задавать вопросы в одной области, достаточно легко прокачиваются в другой.
Кто-то может сказать, что я описал требования к синьору и если да, то поделитесь этим в комментах. В моем понимании синьор это другой уровень решения вопросов на уровне понимания того что надо делать и как надо делать. В технике он может быть такой же как мидл, но обычно круче.
Ссылки: Телеграм | Youtube | VK
Такую фразу все чаще встречаю на просторах сети. Хочется это зафиксировать. Быть реальным мидлом и находиться на позиции мидл в какой-то компании, где это определяется формальными признаками, типа прошел собес на мидла это не одно и тоже. Нет ничего плохого в том чтобы пройти чек и занять такую должность с соответствующей зарплатой, но важно не обманывать самого себя, иначе потом будет больно.
Формальные критерии вводят для того, чтобы хоть как-то понимать и контролировать процессы, когда в компании много людей. Без этого никак. Но никакая система не делает все однозначно определенным. Всегда есть ложнопозитивные и ложнонегативные срабатывания. В мелких компаниях с этим проще, если тебя берут на мидла, то и реальную работу ждут на мидла, поэтому если оно не соответствует, то будет разговор. В крупняке можно затеряться, но многое зависит от лида.
Если убрать всю эту шелуху, что бы хотел каждый работадатель от мидла?
- Опыт работы с технологиями. Человек знает как технически решить поставленную задачу по кодингу и может ее сделать в большинстве ситуаций
- Человек может оценить основные риски, потому что в этом заключается его мидловость. Он знает к чему может привести то или иное решение, знает о чем надо подумать, предупредить, организовать плавный переход, поддержку старой системы и так далее. Такой опыт набирается через боль и ошибки (не ронял прод, не мидл)
- Он способен задать вопросы при постановке задачи, чтобы доформулировать ее до нужного уровня.
При этом, все это специфично под каждую конкретную компанию. Мидл в одном месте, в другом может быть не мидл и скорее всего будет не мидл. Хотя конечно, есть и общие вещи, которые достаточно быстро добираются при хорошей базе. Умение задавать вопросы в одной области, достаточно легко прокачиваются в другой.
Кто-то может сказать, что я описал требования к синьору и если да, то поделитесь этим в комментах. В моем понимании синьор это другой уровень решения вопросов на уровне понимания того что надо делать и как надо делать. В технике он может быть такой же как мидл, но обычно круче.
Ссылки: Телеграм | Youtube | VK
Telegram
Организованное программирование | Кирилл Мокевнин
Как из джуниора дойти до мидла, а потом и до синьора
Ютуб https://youtube.com/@mokevnin
Связь для предложений: @kirillpublic
Ютуб https://youtube.com/@mokevnin
Связь для предложений: @kirillpublic
👍77❤19🔥12💯7🤡5👨💻2🤔1👌1
Сходил в подлодку поговорить про то как джунам действовать и находить работу. Прошлись по образованию, получению опыта, критериям готовности, софтскилам и многому другому. Кажется получилось бодро https://www.youtube.com/watch?v=qRWPp6sU6Vo
3🔥48👍27🤡5❤2👀1
Релиз! В этом выпуске мы с Кириллом Игнатьевым, Senior Software Engineer в компании Bloomberg, разговариваем о больших компаниях и больших зарплатах 🙂 Обсуждаем процесс найма в FAANG (Facebook, Amazon, Google) и систему грейдов. Как она устроена и как внутри нее расти. https://www.youtube.com/watch?v=zkrLgz7lwgI
YouTube
Какие программисты зарабатывают 1 000 000$ в FAANG? / Кирилл Игнатьев / #10
В этом выпуске мы с Кириллом Игнатьевым, Senior Software Engineer Bloomberg, разговариваем о больших компаниях и больших зарплатах 🙂 Обсудим рекрутинг в крупных IT-компаниях типа FAANG (Meta, Amazon, Google), что в них делают HR и как нанимают программистов…
👍27🔥16👀1
Стоят ли перед вами какие-то карьерные цели? Раскройте в комментах подробнее
Anonymous Poll
50%
Хочу повысить грейд
18%
Хочу поменять направление
21%
Хочу работать в другой стране
8%
Хочу перейти в менеджмент
15%
Хочу вкатиться в IT
9%
Все устраивает
26%
Хочу начать свое дело
👍20🤡7🔥6👾4👀2🐳1
В твиттере бурно обсуждают скриншот, на котором видно как на букинге описываются скрытые платежи в последний момент. С этими платежами конечная стоимость может легко увеличиваться в два и более раз. Естественно все это порождает праведный гнев и вопросы в стиле “зачем, прятать если конечная цена все равно такая же как если бы не прятали?”
Ответ такой: нам всем, включая тех кто это делает, такой подход не приятен, но он позволяет зарабатывать больше, поэтому его используют и будут использовать до внедрения каких-нибудь законодательных мер. И даже тогда, они придумают как их обойти. Так происходит всегда.
Как это работает?
#пробизнес
Процесс продажи билетов очень похож на продажи игр в сторах. Он состоит трех точек касания (как минимум):
1. Листинг (список чего-либо), на котором мы быстро принимаем решение что нам подходит
2. Страница товара, с более подробным и заманивающим описанием и картинками
3. Страница чекаута, где происходит оплата
Все это вместе называется воронкой. Идея в том, что мы ведем людей от начала воронки до ее конца людей, отслеживая и оптимизируя конверсия на каждом этапе. Начало воронки это много людей и небольшие конверсии, потому что ее видят все подряд, конец воронки это мало людей и высокая конверсия, потому что туда доходят самые заинтересованные. Эту воронку можно визуализировать и она действительно будет выглядеть как воронка.
Гипотетический пример. Поездку в майами смотрят 100 000 людей в день из которых, только 5% переходят на страницы конкретных отелей (эта метрика называется CTR, она есть во всех списках, будь то список курсов, приложений или выдача в поиске). Это 5000 человек. Из них только 10% доходят до чекаута, а это 500 человек. Ну и дальше покупает скажем 20%, а это 101 человек.
Имея на руках такую воронку, маркетологи думают как ее оптимизировать, но не целиком, а поэтапно. Каждый этап это свои подходы и свои конверсии. Очен удобно, так работают 100% бизнесов. За десятилетия работы с воронками на онлайн проектах, выработались подходы и техники, которые все знают независимо от индустрии. Одна из классических схем, делать предложение как можно более привлекательным снижая базовую цену и показывая ее только в самом конце или вообще перенеся продажи за пределы воронки, например, как в играх, где игры могут быть вообще бесплатными, а дальше с вас будут чаржить без перерыва уже внутри, зарабатывая в разы больше денег (если не на порядки).
Именно поэтому пишут про минимальный платеж, про “от 1000 рублей” за билет на концерт, в самой заднице стадиона, про стоимость перелета без учета багажа и так далее. Главная цель - подвинуть как можно больше людей (говорят трафика) на следующий этап воронки.
А дальше, срабатывает эффект, который делает все это выгодным. Человек прошедший по воронке дальше, более склонен к покупке, так как он заинтересован и уже предпринял какие-то действия. Ему не понравится, он будет плеваться, но в конце концов купит. Конверсия в покупку будет меньше, но количество людей дошедших до этого этапа воронки значительно больше, в итоге общая выручка значительно выше. Маркетолог получил премию, компания выполнила планы, набираем больше разработчиков чтобы развиваться дальше.
Можно ли так не делать? Ответ нет, потому что проблема не в одной компании, а в том, что так будут делать конкуренты, а значит у них будет больше денег, больше развития, в конце концов вас сметут. К - капитализм
Можно ли поправить законодательно? В теории да, но как правило, все обходится, поэтому эта задача очень сложная. Нужно последовательно выпускать патчи к законам постоянно наблюдая за ситуацией. Таким мало кто заморачивается серьезно и делается это не за один год. В конечном итоге мы покупаем молоко в пачках 900 грамм.
Ссылки: Телеграм | Youtube | VK
p.s. Домашнее задание: подумайте, какие воронки продаж используются в проектах где вы работаете и какие механики для повышения конверсий там используются. Напишите в комментариях.
Ответ такой: нам всем, включая тех кто это делает, такой подход не приятен, но он позволяет зарабатывать больше, поэтому его используют и будут использовать до внедрения каких-нибудь законодательных мер. И даже тогда, они придумают как их обойти. Так происходит всегда.
Как это работает?
#пробизнес
Процесс продажи билетов очень похож на продажи игр в сторах. Он состоит трех точек касания (как минимум):
1. Листинг (список чего-либо), на котором мы быстро принимаем решение что нам подходит
2. Страница товара, с более подробным и заманивающим описанием и картинками
3. Страница чекаута, где происходит оплата
Все это вместе называется воронкой. Идея в том, что мы ведем людей от начала воронки до ее конца людей, отслеживая и оптимизируя конверсия на каждом этапе. Начало воронки это много людей и небольшие конверсии, потому что ее видят все подряд, конец воронки это мало людей и высокая конверсия, потому что туда доходят самые заинтересованные. Эту воронку можно визуализировать и она действительно будет выглядеть как воронка.
Гипотетический пример. Поездку в майами смотрят 100 000 людей в день из которых, только 5% переходят на страницы конкретных отелей (эта метрика называется CTR, она есть во всех списках, будь то список курсов, приложений или выдача в поиске). Это 5000 человек. Из них только 10% доходят до чекаута, а это 500 человек. Ну и дальше покупает скажем 20%, а это 101 человек.
Имея на руках такую воронку, маркетологи думают как ее оптимизировать, но не целиком, а поэтапно. Каждый этап это свои подходы и свои конверсии. Очен удобно, так работают 100% бизнесов. За десятилетия работы с воронками на онлайн проектах, выработались подходы и техники, которые все знают независимо от индустрии. Одна из классических схем, делать предложение как можно более привлекательным снижая базовую цену и показывая ее только в самом конце или вообще перенеся продажи за пределы воронки, например, как в играх, где игры могут быть вообще бесплатными, а дальше с вас будут чаржить без перерыва уже внутри, зарабатывая в разы больше денег (если не на порядки).
Именно поэтому пишут про минимальный платеж, про “от 1000 рублей” за билет на концерт, в самой заднице стадиона, про стоимость перелета без учета багажа и так далее. Главная цель - подвинуть как можно больше людей (говорят трафика) на следующий этап воронки.
А дальше, срабатывает эффект, который делает все это выгодным. Человек прошедший по воронке дальше, более склонен к покупке, так как он заинтересован и уже предпринял какие-то действия. Ему не понравится, он будет плеваться, но в конце концов купит. Конверсия в покупку будет меньше, но количество людей дошедших до этого этапа воронки значительно больше, в итоге общая выручка значительно выше. Маркетолог получил премию, компания выполнила планы, набираем больше разработчиков чтобы развиваться дальше.
Можно ли так не делать? Ответ нет, потому что проблема не в одной компании, а в том, что так будут делать конкуренты, а значит у них будет больше денег, больше развития, в конце концов вас сметут. К - капитализм
Можно ли поправить законодательно? В теории да, но как правило, все обходится, поэтому эта задача очень сложная. Нужно последовательно выпускать патчи к законам постоянно наблюдая за ситуацией. Таким мало кто заморачивается серьезно и делается это не за один год. В конечном итоге мы покупаем молоко в пачках 900 грамм.
Ссылки: Телеграм | Youtube | VK
p.s. Домашнее задание: подумайте, какие воронки продаж используются в проектах где вы работаете и какие механики для повышения конверсий там используются. Напишите в комментариях.
👍62🔥17❤7🤯5💩4🤔2🤡2
Есть у меня список принципов, которых я придерживаюсь когда пишу код. Пришла пора ответить за слова. Лайк, тред, инфлюенс =>
"Язык — это инструмент" банально, но факт. Не прикипайте к языкам, язык для души и работы это разные вещи. Я не люблю го, но буду использовать там где он силен, я люблю кложу, но не буду использовать почти нигде (:D) PHP сила, TypeScript могила
"Написание кода — не цель" Задача самурая устранять боль, наиболее эффективным с точки зрения стоимость/затраты способом. Задачи могут решаться удалением кода или административным решением. Думайте о том как уменьшить количество состояний, а не запрограммировать их все
"Удаление кода лучше его написания" Я бы сказал нет кода нет проблем. Никому не нужно бесконечное число фич. Режьте все ненужное, постоянно осматривайтесь "а нахрен оно тут лежит?". Чувствуйте бизнес, будьте бизнесом, будьте
"Читаемый код важнее быстрого". С хорошей абстракцией, вы всегда успеете оптимизировать ваш код, особенно если она не протекает. Прочитайте хорошую книжку (очень тонкую)
"Любое решение имеет плюсы" Даже если вас съели, у вас есть два выхода. Хороший программист рассматривает любое решение, даже то, которое ему не нравится. Мы тут не фильмы на нетфликсе выбираем.
"Уровень мышления определяет уровень решений" Очень похожая мысль на парадокс блаба https://nestor.minsk.by/sr/2003/07/30710.html но для картины мира в голове. Изучайте разные подходы, парадигмы, экосистемы. После js изучение python это трата времени (для мышления), а изучение java мощь
"Изменяемое состояние — это необходимость и корень всех бед", а не преждевременная оптимизация. Если надо что-то менять, то приходит жопа в: историчности, порядке действий, канкаренси, сложности восприятия, сложности реализации отладке, восстановлении, скорости и дальше по списку
"Побочные эффекты требуют изоляции" пока тема побочных эффектов не понята, никакие паттерны и практики программирования не сделают код лучше. В основе всего и ключом к основному разделению лежат побочные эффекты. Функциональное ядро и императивная оболочка.
"Абстракция управляет сложностью" сложность прячется за абстракцией, но сама абстракция может стать сложностью. Как быть? Правильная работа с побочными эффектами, уровневое проектирование, грамотное разделение по областям знаний, не слишком много обобщений
"Однообразие лучше локальных оптимизаций" Это мега важный принцип. Моторная и ассоциативная памяти решают. Делайте одинаково, даже если местами кажется, что можно срезать. Например даже если состояния два, в базе все равно лучше строка: легко расширить, одинаковый код по проекту
"Тесты вселяют уверенность" Страх внесения изменения в проект заводит его в тупик. Юниты мешают изменениям. Интеграционные тесты решают. Не надо ничего мокать, стабы и нормальная инверсия всегда предпочтительнее. Работайте с базой по настоящему.
"Эксплуатация — это часть системы" Ответственность программистов довести фичу до прода, а не слить в main. Time To Market управляет проектами. Обязательно к прочтению: цель и проект феникс
"Код — это не продукт" хорошо понимаешь когда начинаешь делать бизнес, а там логистика, саппорт, продажи, сопровождение, аналитика, бухгалтерия, финансы. Из 80 сотрудников Хекслета только 5 человек работает над кодом платформы
"Хороший код не рождает хороший продукт" Как правило, успешный продукт соткан из ниток и изоленты. Скорость изменений решает, а дальше можно продать бизнес и не париться) Программисты склонны переоценивать значимость архитектуры. Уверен что этот твит засияет ночью
Ссылки: Телеграм | Youtube | VK
"Язык — это инструмент" банально, но факт. Не прикипайте к языкам, язык для души и работы это разные вещи. Я не люблю го, но буду использовать там где он силен, я люблю кложу, но не буду использовать почти нигде (:D) PHP сила, TypeScript могила
"Написание кода — не цель" Задача самурая устранять боль, наиболее эффективным с точки зрения стоимость/затраты способом. Задачи могут решаться удалением кода или административным решением. Думайте о том как уменьшить количество состояний, а не запрограммировать их все
"Удаление кода лучше его написания" Я бы сказал нет кода нет проблем. Никому не нужно бесконечное число фич. Режьте все ненужное, постоянно осматривайтесь "а нахрен оно тут лежит?". Чувствуйте бизнес, будьте бизнесом, будьте
"Читаемый код важнее быстрого". С хорошей абстракцией, вы всегда успеете оптимизировать ваш код, особенно если она не протекает. Прочитайте хорошую книжку (очень тонкую)
"Любое решение имеет плюсы" Даже если вас съели, у вас есть два выхода. Хороший программист рассматривает любое решение, даже то, которое ему не нравится. Мы тут не фильмы на нетфликсе выбираем.
"Уровень мышления определяет уровень решений" Очень похожая мысль на парадокс блаба https://nestor.minsk.by/sr/2003/07/30710.html но для картины мира в голове. Изучайте разные подходы, парадигмы, экосистемы. После js изучение python это трата времени (для мышления), а изучение java мощь
"Изменяемое состояние — это необходимость и корень всех бед", а не преждевременная оптимизация. Если надо что-то менять, то приходит жопа в: историчности, порядке действий, канкаренси, сложности восприятия, сложности реализации отладке, восстановлении, скорости и дальше по списку
"Побочные эффекты требуют изоляции" пока тема побочных эффектов не понята, никакие паттерны и практики программирования не сделают код лучше. В основе всего и ключом к основному разделению лежат побочные эффекты. Функциональное ядро и императивная оболочка.
"Абстракция управляет сложностью" сложность прячется за абстракцией, но сама абстракция может стать сложностью. Как быть? Правильная работа с побочными эффектами, уровневое проектирование, грамотное разделение по областям знаний, не слишком много обобщений
"Однообразие лучше локальных оптимизаций" Это мега важный принцип. Моторная и ассоциативная памяти решают. Делайте одинаково, даже если местами кажется, что можно срезать. Например даже если состояния два, в базе все равно лучше строка: легко расширить, одинаковый код по проекту
"Тесты вселяют уверенность" Страх внесения изменения в проект заводит его в тупик. Юниты мешают изменениям. Интеграционные тесты решают. Не надо ничего мокать, стабы и нормальная инверсия всегда предпочтительнее. Работайте с базой по настоящему.
"Эксплуатация — это часть системы" Ответственность программистов довести фичу до прода, а не слить в main. Time To Market управляет проектами. Обязательно к прочтению: цель и проект феникс
"Код — это не продукт" хорошо понимаешь когда начинаешь делать бизнес, а там логистика, саппорт, продажи, сопровождение, аналитика, бухгалтерия, финансы. Из 80 сотрудников Хекслета только 5 человек работает над кодом платформы
"Хороший код не рождает хороший продукт" Как правило, успешный продукт соткан из ниток и изоленты. Скорость изменений решает, а дальше можно продать бизнес и не париться) Программисты склонны переоценивать значимость архитектуры. Уверен что этот твит засияет ночью
Ссылки: Телеграм | Youtube | VK
👍145🔥57❤23✍7👀4💯2