Выбор среди равных
Переезжая в новую страну перед иммигрантом встает много вопросов, которые требуют сравнения разных вариантов решения. На работе такие встречаются постоянно. Алгоритм принятия решения очень простой:
- Вы определяетесь с конкретным вопросом для которого ищете решение
- Формулируете список сравниваемых качественных и количественных критериев
- Собираете список вариантов и заполняете табличку с критериями
- Делаете ревью, вносите правки с учетом фидбека от остальных
- Наконец принимаете решение в пользу одной из опций (а иногда в принципе отказываетесь от предложенных вариантов в пользу собственного решения)
Вот несколько вопросов этого типа у типичного иммигранта (осознает он их или нет, но они есть):
Где жить? Где работать? Куда отдать учиться детей? Какой банк выбрать? Какого сотового оператора выбрать?
Допустим мы выписали варианты, сравниваем и есть несколько равных опций. Тут часто вступают в силу те факторы на которые изначально можно было закрыть глаза. Так например, когда я задаюсь вопросом: а какой из этих сервисов популярнее? В софтверном мире я открываю Github и смотрю на звезды, но если этот вариант не работает (а в обычном мире для обычной жизни он не работает никогда), то я иду в Google Trends и таким образом становится чуть очевиднее, какие банки/финансовые компании реально конкурируют и в каких эшелонах
Переезжая в новую страну перед иммигрантом встает много вопросов, которые требуют сравнения разных вариантов решения. На работе такие встречаются постоянно. Алгоритм принятия решения очень простой:
- Вы определяетесь с конкретным вопросом для которого ищете решение
- Формулируете список сравниваемых качественных и количественных критериев
- Собираете список вариантов и заполняете табличку с критериями
- Делаете ревью, вносите правки с учетом фидбека от остальных
- Наконец принимаете решение в пользу одной из опций (а иногда в принципе отказываетесь от предложенных вариантов в пользу собственного решения)
Вот несколько вопросов этого типа у типичного иммигранта (осознает он их или нет, но они есть):
Где жить? Где работать? Куда отдать учиться детей? Какой банк выбрать? Какого сотового оператора выбрать?
Допустим мы выписали варианты, сравниваем и есть несколько равных опций. Тут часто вступают в силу те факторы на которые изначально можно было закрыть глаза. Так например, когда я задаюсь вопросом: а какой из этих сервисов популярнее? В софтверном мире я открываю Github и смотрю на звезды, но если этот вариант не работает (а в обычном мире для обычной жизни он не работает никогда), то я иду в Google Trends и таким образом становится чуть очевиднее, какие банки/финансовые компании реально конкурируют и в каких эшелонах
LLM Applications глазами бекендера
Со стороны обывателя, AI сначала был чем-то непонятным и не имеющим значение, потом это понятие резко сузили до нейронок, а на сегодняшний день самая крепкая ассоциация с AI это ChatGPT. Large Language Models (LLM) действительно оказали значительное влияние на привлечение внимания к этой области и множество компаний начали вкладываться в это направление особенно усердно, вступили в гонку, где каждый гордится особенностями своей большой языковой модели и предлагает сценарии, в которых она показывает себя лучше остальных. Каждый вендор пишет гайды о том как правильно писать промпты (входной текст) к его конкретной модели, где явно уточняет, что например "модель лучше понимает xml, чем json". Понятие опенсорса начало включать не только исходный код, но и веса моделей, которые получаются в результате её обучения.
Для всего остального мира часто это было чем-то вторичным, а инфраструктура тем временем росла, практики зрели, начали появляться новые понятия, например, Prompt Engineering и, действительно, написать качественный промпт, который можно использовать в продакшене оказалось задачей не из лёгких. Начали появляться свои паттерны и технологии для решения разных проблем, в частности семантический поиск с помощью векторных хранилищ, графовые базы данных как источник знаний, более того даже понятия "агентов" и "онтологий", которые я не слышал в этом контексте уже лет 8, теперь обрели новую жизнь.
Во-первых, стало понятно что потенциал огромный, вот только несколько задач, которые вы сегодня можете решать просто вызвав HTTP API или локально развернув опен сорс модель, плюс написав несколько строчек кода: голос в текст и обратно, задавание вопросов с ответами в контексте вашей компании, ранжирование по семантике, перевод голоса, работа с текстом включая саммари и вытаскивание смысловых единиц, генерация картинок, описание картинок.
Во-вторых, стало понятно что инфраструктуры не хватает, а также нужно решать новые задачи в области безопасности, например, если вы работаете с моделью, которая может вызывать внешний поиск, то злоумышленник может сделать Prompt Injection и скачать из интернета что-то не то.
Если раньше мы думали, что нам нужно определиться с архитектурой, выбрать стек на котором будем писать бек и фронт, похоливарить про языки и кубернетисы, сделать мониторинг и т.д., то теперь задача усложняется и надо ответить на следующие вопросы:
- а как выглядит управление версиями промптов? Ведь их надо улучшать и обновлять при обновлении моделей
- а как запускать LLM? а что надо если сделать что-то более сложное чем один промпт?
- а как добавить моего контекста?
- а как упростить интеграцию с разными моделями?
- а где взять готовые мини-приложения под конкретные задачи?
- а как обеспечить безопасность?
- а как убедиться что результат в порядке? ведь его выдал не человек
- а как дебажить?
- а как мониторить?
Как вы видите, вопросов возникает много, а при появлении новых foundational моделей, при наращивании возможностей мультимодальности (текст, голос, видео, ...) вопросов будет еще больше. Точно также как бекенд разработчики в какой-то момент озадачились полнотекстовым поиском, пора принять факт, что есть +1 механизм обыденного наращивания функциональности.
Вишенка на торте, представьте что модель отвечает вам не в чате, что сегодня является самым распространенным демо-сценарием, а в виде json'а или вызывает ваше апи по OpenAPI 3 спеке. И это уже реальность в которой мы живем.
Со стороны обывателя, AI сначала был чем-то непонятным и не имеющим значение, потом это понятие резко сузили до нейронок, а на сегодняшний день самая крепкая ассоциация с AI это ChatGPT. Large Language Models (LLM) действительно оказали значительное влияние на привлечение внимания к этой области и множество компаний начали вкладываться в это направление особенно усердно, вступили в гонку, где каждый гордится особенностями своей большой языковой модели и предлагает сценарии, в которых она показывает себя лучше остальных. Каждый вендор пишет гайды о том как правильно писать промпты (входной текст) к его конкретной модели, где явно уточняет, что например "модель лучше понимает xml, чем json". Понятие опенсорса начало включать не только исходный код, но и веса моделей, которые получаются в результате её обучения.
Для всего остального мира часто это было чем-то вторичным, а инфраструктура тем временем росла, практики зрели, начали появляться новые понятия, например, Prompt Engineering и, действительно, написать качественный промпт, который можно использовать в продакшене оказалось задачей не из лёгких. Начали появляться свои паттерны и технологии для решения разных проблем, в частности семантический поиск с помощью векторных хранилищ, графовые базы данных как источник знаний, более того даже понятия "агентов" и "онтологий", которые я не слышал в этом контексте уже лет 8, теперь обрели новую жизнь.
Во-первых, стало понятно что потенциал огромный, вот только несколько задач, которые вы сегодня можете решать просто вызвав HTTP API или локально развернув опен сорс модель, плюс написав несколько строчек кода: голос в текст и обратно, задавание вопросов с ответами в контексте вашей компании, ранжирование по семантике, перевод голоса, работа с текстом включая саммари и вытаскивание смысловых единиц, генерация картинок, описание картинок.
Во-вторых, стало понятно что инфраструктуры не хватает, а также нужно решать новые задачи в области безопасности, например, если вы работаете с моделью, которая может вызывать внешний поиск, то злоумышленник может сделать Prompt Injection и скачать из интернета что-то не то.
Если раньше мы думали, что нам нужно определиться с архитектурой, выбрать стек на котором будем писать бек и фронт, похоливарить про языки и кубернетисы, сделать мониторинг и т.д., то теперь задача усложняется и надо ответить на следующие вопросы:
- а как выглядит управление версиями промптов? Ведь их надо улучшать и обновлять при обновлении моделей
- а как запускать LLM? а что надо если сделать что-то более сложное чем один промпт?
- а как добавить моего контекста?
- а как упростить интеграцию с разными моделями?
- а где взять готовые мини-приложения под конкретные задачи?
- а как обеспечить безопасность?
- а как убедиться что результат в порядке? ведь его выдал не человек
- а как дебажить?
- а как мониторить?
Как вы видите, вопросов возникает много, а при появлении новых foundational моделей, при наращивании возможностей мультимодальности (текст, голос, видео, ...) вопросов будет еще больше. Точно также как бекенд разработчики в какой-то момент озадачились полнотекстовым поиском, пора принять факт, что есть +1 механизм обыденного наращивания функциональности.
Вишенка на торте, представьте что модель отвечает вам не в чате, что сегодня является самым распространенным демо-сценарием, а в виде json'а или вызывает ваше апи по OpenAPI 3 спеке. И это уже реальность в которой мы живем.
Sankey Diagram
Один из не очень популярных, но определенно недооцененных видов диаграмм - Sankey. Задача Sankey Diagram отразить потоки данных, откуда они берутся, как и где мержатся, где и как расходятся. Когда я увидел как такой инструмент используют для планирования финансов организации, я был поражен на сколько это удобно! Тот же подход помогает мне готовиться к переезду, например, когда я захотел на одном счету аккумулировать средства из разных источников, снять выписки из банков о наличии "чистого капитала" для налоговой UK и спланировать на какие расходы мы будем тратить эти деньги после переезда, то ничего круче я так и не нашел.
Рекомендую взять на вооружение и внедрять как инструмент для личных и не только финансов, если у вас есть другие юзкейсы, то делитесь в комментариях 👇🏼
https://sankeymatic.com/build/
Один из не очень популярных, но определенно недооцененных видов диаграмм - Sankey. Задача Sankey Diagram отразить потоки данных, откуда они берутся, как и где мержатся, где и как расходятся. Когда я увидел как такой инструмент используют для планирования финансов организации, я был поражен на сколько это удобно! Тот же подход помогает мне готовиться к переезду, например, когда я захотел на одном счету аккумулировать средства из разных источников, снять выписки из банков о наличии "чистого капитала" для налоговой UK и спланировать на какие расходы мы будем тратить эти деньги после переезда, то ничего круче я так и не нашел.
Рекомендую взять на вооружение и внедрять как инструмент для личных и не только финансов, если у вас есть другие юзкейсы, то делитесь в комментариях 👇🏼
https://sankeymatic.com/build/
SankeyMATIC.com
SankeyMATIC: Build a Sankey Diagram
Make beautiful flow diagrams. Export them as images or SVG.
Получить Global Talent UK визу в паспорт за 4 месяца и 4 дня
В начале года я принял решение что буду делать визу о которой писал выше. Для меня это было, как в меме наших дней «не просто смело, а …». По дороге оказалось, что всё что нужно уже есть и надо только организовать процесс. Сейчас могу уверенно сказать, что это пожалуй один из самых личностно-трансформирующих этапов моей жизни, где приходит окончательное осознание, что при должном желании всё возможно.
Сегодня я забрал паспорта с вклеенными визами, которые открываются 24 мая, а это значит, что уже июнь мы с семьёй проведем в Англии в поисках жилья. Впереди еще несколько трудностей, включая переезд и временное жильё на чемоданах, но сейчас я на это больше смотрю как на интересный челендж.
Фраза «вера в себя» для меня плавно переходит из шаблона, которые используют все подряд в личные принципы, чего желаю каждому, кто читает эти строки. Спасибо всем кто поддерживал и следил ❤️
В начале года я принял решение что буду делать визу о которой писал выше. Для меня это было, как в меме наших дней «не просто смело, а …». По дороге оказалось, что всё что нужно уже есть и надо только организовать процесс. Сейчас могу уверенно сказать, что это пожалуй один из самых личностно-трансформирующих этапов моей жизни, где приходит окончательное осознание, что при должном желании всё возможно.
Сегодня я забрал паспорта с вклеенными визами, которые открываются 24 мая, а это значит, что уже июнь мы с семьёй проведем в Англии в поисках жилья. Впереди еще несколько трудностей, включая переезд и временное жильё на чемоданах, но сейчас я на это больше смотрю как на интересный челендж.
Фраза «вера в себя» для меня плавно переходит из шаблона, которые используют все подряд в личные принципы, чего желаю каждому, кто читает эти строки. Спасибо всем кто поддерживал и следил ❤️
Первые три дня в UK свалили на меня очень много инсайтов, часть из которых можно спроецировать и в рабочее пространство, я решил этим поделиться с вами.
1. Разнообразие меняет атмосферу. Я не понимаю как это работает, но разнообразие культур, рас, внешних черт и возможностей удивительным образом разряжает атмосферу и добавляет что-то легкое. Ты перестаешь думать о том что есть одни люди, а есть другие люди, ты начинаешь видеть людей целиком не различая по каким-либо чертам. Иммигранты в таком пространстве становятся частью общества, кто-то больше, а кто-то меньше, в том объеме в котором это комфортно.
2. За маской хороших людей иногда прячутся потрясающие люди. Первый опыт аренды в Грузии сначала заруинил мои ожидания от ленд лордов, но второй не просто вернул веру в людей, но и вывел её на новый уровень. Когда тебе встречаются люди, которые готовы жертвовать своим временем и силами ради тебя - незнакомца, то отношение к миру претерпевает изменение в лучшую сторону.
3. Комьюнити которое вы приобретаете в иммиграции имеет невероятную силу и сеть поддержки, которая естественным образом вас выталкивает наверх в любой ситуации.
4. Планы можно менять на ходу. Мне как контрол-фрику и перфекционисту всё еще это трудно дается осознать и как говорит мой психолог - наш мозг всегда ищет определенность, но чем больше ты видишь собственную озабоченность планами, тем легче их менять на ходу.
5. То что в контексте Х имеет смысл, в контексте Y его не просто может потерять, но и навредить. Владение чем бы-то ни было имеет ценность, но только в определенном контексте, если вы владеете право-рульной машиной в UK и платите за неё страховку, при этом уезжаете в другую страну, где нужна лево-рульная, то то что имело ценность в одном контексте, стало обременением в другом.
6. Оказывается можно лететь в страну в которой ты никогда в жизни не был и уже чувствовать что возвращаешься домой, невероятное ощущение счастья и наполненности, ловить это на каждом шагу и в каждом порыве ветра.
7. Нетворк строится годами, а не за один день. Отношения которые были актуально 5-10 лет назад могут обретать смысл снова (опять же благодаря смене контекста)
8. На практике чувство удовлетворенности иногда имеет больший смысл чем математически объективная удовлетворенность. Если вы не были финансово эффективны во всём, но обретенный комфорт и плавность оказали значительное позитивное влияние на полученный опыт, то это можно считать успехом.
9. Если 10 человек вам сказали что что-то что вам нужно - дорого, то это не повод отказываться от этого, а скорее повод осознать как вы нивелируете негативное влияние стоимости на то что вы хотите получить
1. Разнообразие меняет атмосферу. Я не понимаю как это работает, но разнообразие культур, рас, внешних черт и возможностей удивительным образом разряжает атмосферу и добавляет что-то легкое. Ты перестаешь думать о том что есть одни люди, а есть другие люди, ты начинаешь видеть людей целиком не различая по каким-либо чертам. Иммигранты в таком пространстве становятся частью общества, кто-то больше, а кто-то меньше, в том объеме в котором это комфортно.
2. За маской хороших людей иногда прячутся потрясающие люди. Первый опыт аренды в Грузии сначала заруинил мои ожидания от ленд лордов, но второй не просто вернул веру в людей, но и вывел её на новый уровень. Когда тебе встречаются люди, которые готовы жертвовать своим временем и силами ради тебя - незнакомца, то отношение к миру претерпевает изменение в лучшую сторону.
3. Комьюнити которое вы приобретаете в иммиграции имеет невероятную силу и сеть поддержки, которая естественным образом вас выталкивает наверх в любой ситуации.
4. Планы можно менять на ходу. Мне как контрол-фрику и перфекционисту всё еще это трудно дается осознать и как говорит мой психолог - наш мозг всегда ищет определенность, но чем больше ты видишь собственную озабоченность планами, тем легче их менять на ходу.
5. То что в контексте Х имеет смысл, в контексте Y его не просто может потерять, но и навредить. Владение чем бы-то ни было имеет ценность, но только в определенном контексте, если вы владеете право-рульной машиной в UK и платите за неё страховку, при этом уезжаете в другую страну, где нужна лево-рульная, то то что имело ценность в одном контексте, стало обременением в другом.
6. Оказывается можно лететь в страну в которой ты никогда в жизни не был и уже чувствовать что возвращаешься домой, невероятное ощущение счастья и наполненности, ловить это на каждом шагу и в каждом порыве ветра.
7. Нетворк строится годами, а не за один день. Отношения которые были актуально 5-10 лет назад могут обретать смысл снова (опять же благодаря смене контекста)
8. На практике чувство удовлетворенности иногда имеет больший смысл чем математически объективная удовлетворенность. Если вы не были финансово эффективны во всём, но обретенный комфорт и плавность оказали значительное позитивное влияние на полученный опыт, то это можно считать успехом.
9. Если 10 человек вам сказали что что-то что вам нужно - дорого, то это не повод отказываться от этого, а скорее повод осознать как вы нивелируете негативное влияние стоимости на то что вы хотите получить
Представьте, что вас нет
Что если вы выбыли из процесса работы на день? на неделю? на месяц? Ситуации бывают разные, но организована ли ваша работа так, что в ваше отсутствие всё нормально продолжит двигаться?
Я несколько раз в жизни встречал людей которые были искренне уверены, что на себе надо завязать всё, чтобы вы стали незаменимым сотрудником и вас больше никогда не уволили, потому что очень страшно. При этом так не просто "сложилось", это была осознанно выбранная стратегия построения карьеры. На мой взгляд это абсолютно непрофессионально и исключительно преследует шкурный интерес организотора ситуации. Мне с такими людьми не хотелось бы оказаться в одной лодке, потому что это не те кому ты будешь на 100% доверять.
На моем опыте руководителя разработки продукта возможности завязать на себе всё встречаются на каждом шагу. Последний месяц я нахожусь в состоянии переезда и на пару недель приходилось полностью отключаться. Хорошая новость, что процессы не встали, даже более хорошая новость со стороны команды появилась мотивация эти процессы улучшать.
На курсе для начинающих руководителей в практикуме нас как-то спросили, а если с вами что-то случится, то кто вас заменит? А если с ним что-то случится, то кто тогда? Это полезные вопросы, которые я время от времени задаю себе, потому что хочется, чтобы то что ты делаешь тебя пережило.
Если взять ваши ежедневные обязанности, то сколько человек в вашей команде действительно может вас заменить? Ответить можно в комментариях
Что если вы выбыли из процесса работы на день? на неделю? на месяц? Ситуации бывают разные, но организована ли ваша работа так, что в ваше отсутствие всё нормально продолжит двигаться?
Я несколько раз в жизни встречал людей которые были искренне уверены, что на себе надо завязать всё, чтобы вы стали незаменимым сотрудником и вас больше никогда не уволили, потому что очень страшно. При этом так не просто "сложилось", это была осознанно выбранная стратегия построения карьеры. На мой взгляд это абсолютно непрофессионально и исключительно преследует шкурный интерес организотора ситуации. Мне с такими людьми не хотелось бы оказаться в одной лодке, потому что это не те кому ты будешь на 100% доверять.
На моем опыте руководителя разработки продукта возможности завязать на себе всё встречаются на каждом шагу. Последний месяц я нахожусь в состоянии переезда и на пару недель приходилось полностью отключаться. Хорошая новость, что процессы не встали, даже более хорошая новость со стороны команды появилась мотивация эти процессы улучшать.
На курсе для начинающих руководителей в практикуме нас как-то спросили, а если с вами что-то случится, то кто вас заменит? А если с ним что-то случится, то кто тогда? Это полезные вопросы, которые я время от времени задаю себе, потому что хочется, чтобы то что ты делаешь тебя пережило.
Если взять ваши ежедневные обязанности, то сколько человек в вашей команде действительно может вас заменить? Ответить можно в комментариях
Komanda Dyatlov.wav
15.7 MB
5 копеек: "Команда Дятлов"
Попробуем еще один формат. В аудио разбираю какой-то конкретный вопрос. Поставьте реакцию, чтобы мне получить обратную связь
Сегодня: Что делать если команду не мотивирует стек, а работа в области поддерживающего других софта
Попробуем еще один формат. В аудио разбираю какой-то конкретный вопрос. Поставьте реакцию, чтобы мне получить обратную связь
Сегодня: Что делать если команду не мотивирует стек, а работа в области поддерживающего других софта
Сегодня я праздную десятилетие своей карьеры в разработке софта.
Написал в честь этого пост с главными инсайтами, которые я словил по дороге
https://devtower.io/p/21-i-celebrate-the-first-decade-of
Написал в честь этого пост с главными инсайтами, которые я словил по дороге
https://devtower.io/p/21-i-celebrate-the-first-decade-of
devtower.io
#22: I celebrate the first decade of my career. Here are 10 of the most impactful insights I've got.
I spent 10 years in software engineering and here are 10 important things I learned.
Сколько пройдет времени прежде чем телеграм скажет «Ваши ютуб видео можно будет опубликовать в каналы только с платной подпиской или встроим рекламу»?
Anonymous Poll
14%
Спринт (1-4w)
18%
Квартал
25%
Пол года и больше
43%
Никогда
На этой неделе у свидетелей notion случился праздник - подвезли charts
Где-то раз в пол года / год выходят какие-то существенные фичи, которые делают следующий большой сдвиг в этом продукте. На моей памяти их было четыре. Сначала все ждали API, чтобы с ноушеном можно было интегрироваться, потом появился Notion AI (хотя я ожидал немного другого от него), затем нормальные сеты иконок с кастомными цветами, чтобы можно было вводить язык навигации через цвет, теперь наконец-то долгожданные чарты, уверен, они будут расширяться.
С моей колокольни notion уже рвет confluence. Но главная проблема продукта сейчас - шаблонный UX который отталкивает пользователей.
Очевидно, ребята из notion слышат что от них хотят и уже работают над этим. Уже появились кнопки которые можно встраивать в таблички, дело за малым - довести этот конструктор до уровня гибкости, где пользователи финальных документов/страниц перестанут замечать разницу в UX с альтернативными продуктами. Таким образом Notion становится платформой на которой можно решить существенное количество проблем и не притаскивать еще 10 специальных инструментов в довесок
Конечно, часть проблем будет требовать специальных решений или большего времени, например, я как-то интегрировал курс монет с coingecko прямо в ноушен, сказать что финальная база тормозила - это ничего не сказать
Где-то раз в пол года / год выходят какие-то существенные фичи, которые делают следующий большой сдвиг в этом продукте. На моей памяти их было четыре. Сначала все ждали API, чтобы с ноушеном можно было интегрироваться, потом появился Notion AI (хотя я ожидал немного другого от него), затем нормальные сеты иконок с кастомными цветами, чтобы можно было вводить язык навигации через цвет, теперь наконец-то долгожданные чарты, уверен, они будут расширяться.
С моей колокольни notion уже рвет confluence. Но главная проблема продукта сейчас - шаблонный UX который отталкивает пользователей.
Очевидно, ребята из notion слышат что от них хотят и уже работают над этим. Уже появились кнопки которые можно встраивать в таблички, дело за малым - довести этот конструктор до уровня гибкости, где пользователи финальных документов/страниц перестанут замечать разницу в UX с альтернативными продуктами. Таким образом Notion становится платформой на которой можно решить существенное количество проблем и не притаскивать еще 10 специальных инструментов в довесок
Конечно, часть проблем будет требовать специальных решений или большего времени, например, я как-то интегрировал курс монет с coingecko прямо в ноушен, сказать что финальная база тормозила - это ничего не сказать
Requirements != Tickets
Недавно я столкнулся с реальностью и был шокирован. Мы пошли смотреть, что может Allure Test Ops и как можно встроить его в процесс разработки, чтобы этот инструмент вышел из категории "Колдовская книга тестировщиков" и попал в категорию "Еще один инструмент рядом с GitLab / Jira / etc, которым пользуются все на ежедневной основе"). Allure Test Ops (далее ATO) сам по себе мне очень нравится, я посмотрел много YT видео о том как можно переосмыслить разделение ручного и автоматического тестирования и сделать что-то более натуральное, а ATO этому способствует максимально. Так что же меня поразило?
Качество чего нас интересует на практике? Из того что я вижу на рынке следует очевидно одно - качество тикетов, все связи построены на том, что любая тестовая документация стремится быть связанной именно с тикетом в джире, словно это источник знания о продукте, хотя это не так. Если зайти в область высокий материй, что я люблю делать, работая над продуктом нас в первую очередь интересует качество удовлетворения требований к этому продукту. Именно требования фиксируют ожидания, а "success" это именно попадания в ожидания твоего клиента. Какая тогда роль у тикета?
На мой взгляд, фичи, баги и любые другие разновидности ишью которые можно встретить это diff между старым состоянием требований и новым состоянием требований (как в гите), либо обнаруженное несоответствие текущим требованиям, получается, что меняя или валидируюя требования мы заводим тикеты и более того поддерживая требования в актуальном состоянии, мы можем заводить тикеты - полу-автоматически как следствие изменения/валидации ожиданий. Даже при том что уже давно существуют Requirements Management инструменты (например, Requirement Yogi), я практически не вижу интеграций с ними (разве что из джиры).
Получается разработка обречена на "плохие требования" просто потому что процесс начинается с производной от них компоненты - с тикетов. Суммарные же требования мы осознаем, когда заново пишем спецификацию к продукту, что вообще говоря больше похоже на реверс-инжениринг того к разработке чего у тебя и так был доступ - абсолютное безумие.
Самое время поставить 🔥, если считаете что так больше нельзя жить
Недавно я столкнулся с реальностью и был шокирован. Мы пошли смотреть, что может Allure Test Ops и как можно встроить его в процесс разработки, чтобы этот инструмент вышел из категории "Колдовская книга тестировщиков" и попал в категорию "Еще один инструмент рядом с GitLab / Jira / etc, которым пользуются все на ежедневной основе"). Allure Test Ops (далее ATO) сам по себе мне очень нравится, я посмотрел много YT видео о том как можно переосмыслить разделение ручного и автоматического тестирования и сделать что-то более натуральное, а ATO этому способствует максимально. Так что же меня поразило?
Качество чего нас интересует на практике? Из того что я вижу на рынке следует очевидно одно - качество тикетов, все связи построены на том, что любая тестовая документация стремится быть связанной именно с тикетом в джире, словно это источник знания о продукте, хотя это не так. Если зайти в область высокий материй, что я люблю делать, работая над продуктом нас в первую очередь интересует качество удовлетворения требований к этому продукту. Именно требования фиксируют ожидания, а "success" это именно попадания в ожидания твоего клиента. Какая тогда роль у тикета?
На мой взгляд, фичи, баги и любые другие разновидности ишью которые можно встретить это diff между старым состоянием требований и новым состоянием требований (как в гите), либо обнаруженное несоответствие текущим требованиям, получается, что меняя или валидируюя требования мы заводим тикеты и более того поддерживая требования в актуальном состоянии, мы можем заводить тикеты - полу-автоматически как следствие изменения/валидации ожиданий. Даже при том что уже давно существуют Requirements Management инструменты (например, Requirement Yogi), я практически не вижу интеграций с ними (разве что из джиры).
Получается разработка обречена на "плохие требования" просто потому что процесс начинается с производной от них компоненты - с тикетов. Суммарные же требования мы осознаем, когда заново пишем спецификацию к продукту, что вообще говоря больше похоже на реверс-инжениринг того к разработке чего у тебя и так был доступ - абсолютное безумие.
Самое время поставить 🔥, если считаете что так больше нельзя жить
Сходил на подкаст javaswag
Поговорили про разработку нестандартного софта, graphql, kotlin и почему spring boot - единственное верное решение
Слушать можно тут
https://www.tgoop.com/javaswag/1210
Поговорили про разработку нестандартного софта, graphql, kotlin и почему spring boot - единственное верное решение
Слушать можно тут
https://www.tgoop.com/javaswag/1210
Telegram
javaswag
https://javaswag.github.io/episode/66/
В 66 выпуске подкаста Javaswag поговорили с Иваном Осиповым о современном стэке на Котлин, ГрафКуэль и Спринг-Буте
00:00 Начало. Электротранспорт в Arrival
12:23 Стэк
20:20 3D-сцены, Docker и Kubernetes
24:40 Проблемы…
В 66 выпуске подкаста Javaswag поговорили с Иваном Осиповым о современном стэке на Котлин, ГрафКуэль и Спринг-Буте
00:00 Начало. Электротранспорт в Arrival
12:23 Стэк
20:20 3D-сцены, Docker и Kubernetes
24:40 Проблемы…
Ноушен забанит если хоть раз за всю историю вы пользовались картой РФ
Абсолютно безумный способ сделать комплаенс. Если за всю историю существования вашего аккаунта у вас была хотя бы одна оплата с билингом из России - в бан. Я не знаю какой идиот это придумал, но, буквально, это игнорирование того что в обычном мире закон обратной силы не имеет, тут конечно частная компания и могут делать всё что хотят, но так подло поступать, это конечно апогей идиотизма
https://www.notion.so/help/restrictions-for-customers-based-in-russia
upd
проголосуйте, если считаете это несправедливым
https://www.reddit.com/r/Notion/comments/1f4rxmd/if_notion_bans_a_user_if_heshe_has_ever_used/
Абсолютно безумный способ сделать комплаенс. Если за всю историю существования вашего аккаунта у вас была хотя бы одна оплата с билингом из России - в бан. Я не знаю какой идиот это придумал, но, буквально, это игнорирование того что в обычном мире закон обратной силы не имеет, тут конечно частная компания и могут делать всё что хотят, но так подло поступать, это конечно апогей идиотизма
https://www.notion.so/help/restrictions-for-customers-based-in-russia
upd
проголосуйте, если считаете это несправедливым
https://www.reddit.com/r/Notion/comments/1f4rxmd/if_notion_bans_a_user_if_heshe_has_ever_used/
Notion
Restrictions for customers based in Russia – Notion Help Center
A new tool that blends your everyday work apps into one. It's the all-in-one workspace for you and your team.
The Emptiness Machine (Chester Bennington AI Cover)
Linkin Park
Linkin Park в новом составе не просто выпустили хит, но и похоже могут стать причиной ИИ тренда
Честно сказать меня до мурашек пробрало, когда я услышал знакомые тембры в голосе вокалистки, но совсем шифт в сознании случился, когда я услышал что сделали народные умельцы. Они сгенерировали новую песню голосом Честера. Уровень, как по мне, очень хороший и шикарная демонстрация того что люди живут, пока живет память о них. AI трек прикладываю, кому авторство принадлежит не знаю
Честно сказать меня до мурашек пробрало, когда я услышал знакомые тембры в голосе вокалистки, но совсем шифт в сознании случился, когда я услышал что сделали народные умельцы. Они сгенерировали новую песню голосом Честера. Уровень, как по мне, очень хороший и шикарная демонстрация того что люди живут, пока живет память о них. AI трек прикладываю, кому авторство принадлежит не знаю
Тук-тук. Доброе утро. Тут очередной AI прорыв
Итак, OpenAI выпустила O1 preview и mini, если коротко, то я в восторге. Модель «думает» прежде чем ответить и решает сложные задачи кратно лучше прежних моделей.
Этой ночью я решил проверить и написать с её помощью сервис на go, который собирает статистические метрики с гитлаба. У модели получилось. Если точнее, сначала она собрала структуру проекта, заполнила контентом файлики, которые предложила, в тех местах где писать она оставила плейсхолдеры. Далее я итеративно шел и просил её сделать каждую метрику в отдельности. Проблем ровно 0. Часть работы приходилось сделать руками (скопировать контент файликов), но это было элементарно.
Я специально взял Go в котором я мало что понимаю, чтобы не мешать модели своим опытом в том как надо писать и максимально сфокусироваться на том что «могу прочитать код на любом языке», а написать его должна она сама
Как это работает? Судя по документации, сначала OpenAI обучили внутреннюю модель для рассуждений с помощью обучения с подкреплением (это когда модель справляется/ошибается, получает обратную связь, корректирует веса). Внутренняя модель нужна чтобы на инпут токены выдавать токены ризонинга (грубо говоря, предварительный ответ модели в виде рассуждений о запросе, встроенный chain of thoughts), дальше из инпута + ризонинга получаются output токены. Токены предыдущего ризонинга в дальнейшей коммунникации не участвуют, чтобы не переусложнять её.
Уже доступно тем у кого подписка, очень рекомендую попробовать. Там есть лимиты, для написания кода должно хватить mini, там лимит 50 сообщений, в preview 30.
Для обычных людей
https://openai.com/index/introducing-openai-o1-preview/
Для технарей
https://platform.openai.com/docs/guides/reasoning
Итак, OpenAI выпустила O1 preview и mini, если коротко, то я в восторге. Модель «думает» прежде чем ответить и решает сложные задачи кратно лучше прежних моделей.
Этой ночью я решил проверить и написать с её помощью сервис на go, который собирает статистические метрики с гитлаба. У модели получилось. Если точнее, сначала она собрала структуру проекта, заполнила контентом файлики, которые предложила, в тех местах где писать она оставила плейсхолдеры. Далее я итеративно шел и просил её сделать каждую метрику в отдельности. Проблем ровно 0. Часть работы приходилось сделать руками (скопировать контент файликов), но это было элементарно.
Я специально взял Go в котором я мало что понимаю, чтобы не мешать модели своим опытом в том как надо писать и максимально сфокусироваться на том что «могу прочитать код на любом языке», а написать его должна она сама
Как это работает? Судя по документации, сначала OpenAI обучили внутреннюю модель для рассуждений с помощью обучения с подкреплением (это когда модель справляется/ошибается, получает обратную связь, корректирует веса). Внутренняя модель нужна чтобы на инпут токены выдавать токены ризонинга (грубо говоря, предварительный ответ модели в виде рассуждений о запросе, встроенный chain of thoughts), дальше из инпута + ризонинга получаются output токены. Токены предыдущего ризонинга в дальнейшей коммунникации не участвуют, чтобы не переусложнять её.
Уже доступно тем у кого подписка, очень рекомендую попробовать. Там есть лимиты, для написания кода должно хватить mini, там лимит 50 сообщений, в preview 30.
Для обычных людей
https://openai.com/index/introducing-openai-o1-preview/
Для технарей
https://platform.openai.com/docs/guides/reasoning
Я давно задаюсь вопросом, что такое "потенциал"? Похоже я нашел ответ
Конечно, я не про школьные уроки физики, а про то когда я слышу "главное чтобы у человека был потенциал, тогда он наверняка преуспеет, а то что он не владеет конкретными инструментами - это не страшно", то с одной стороны я на 150% с этим согласен, а с другой стороны задача усложняется.
Как проверить знания языка программирования или фреймворка? Можно позадавать вопросы с которыми люди сталкиваются только на практике и таким образом понять заученная это информация или сформировавшееся понимание в боевом опыте. Но как понять есть ли потенциал? Более того, рефлексируя и применяя это к себе вопрос становится еще интереснее "а почему я решил, что у меня самого есть и был какой-то потенциал?"
К ответу на этот вопрос меня подтолкнуло видео "How Billionaires Think: Decoding The Billionaire Mind" by Sam Ovens, которое я заслуженно поместил в свой Brilliant плейлист (есть у меня такая "полочка" на ютубе куда я складываю исключительные вещи с которыми сталкиваясь). Автор этого видео попытался "декодировать то как мыслят миллиардеры", но по факту он сформулировал 5 слоев мышления в виде стека, где нижние слои принципиально влияют на верхние так, что те что выше не имеют значения, пока не будет проведена работа в самом низу. Его рассказ привемляется в тему предпринимательства (на это указывают верхние слои), но если воспринимать слово business как дело в широком смысле, то всё также отлично вприсывается, даже если хочется преуспеть как разработчик и не более того.
Итак, что же это за слои в порядке от самых важных (самых нижних по стеку), которые влияют на всё, к менее важным (читая дальше, я думаю вы сами начнете понимать ответ на вопрос "что такое потенциал?")
Layer 1 Mental Awareness
- Self Awareness - осознание себя со стороны, не конкретные мысли, а понимание паттерны мышления, которые влияют на действия и поведение
- Identity - всё что вы думаете конкретно о себе (включая установки вроде "я плох в математике", "рисование это не моё" или "этот ваш интернет уже для меня слишком сложный")
- Belief System - система сформировавшихся верований о мире вокруг, например, "деньги это зло", "работа должна быть тяжелой"
Layer 2 Mental Cognition
- способность решать проблемы,
- анализировать входящий поток информации:
— думать критически
— приоритизировать
— взвешивать плюсы и минусы
— оценивать горизонт эффекта от действий
— распознавание паттернов
- предпринимать действия на основе входящего потока:
— делегирование
— декомпозиция
— планирование
— отказ от некоторых возможностей
Layer 3 Business Principles
- на чьих интересах фокус (интересах клиента или моих собственных)
- что считается успехом (профит сегодня или рост опережая остальных в будущем)
- взгляд на мир (следование трендам или научное погружение в глубь проблемы)
Layer 4 Business Disciplines
(университеты учат на этом уровне, но не ниже и это поразительно)
- T-shape оказывает решающую роль для быстрого достижения результата
Layer 5 Processes & Tools
- владение конкретными инструментами
Так что же такое потенциал? Теперь я могу говорить, что наличие потенциала это заполненность первых трех уровней правильными установками (в соответствии представлениями того кто оценивает). Тогда как отсутствие важных компонент на этих уровнях, а также вредные установки, просто удлиняют путь, так как даже если через обратную связь эти установки удастся скорректировать, то это произойдет не сразу. Фокусируясь на анализе этих уровней и минимально-достаточном наполнении уровней 4 и 5 мы находим того самого человека "с потенциалом"
Что думаете? Какие бы вы задавали вопросы для того чтобы проанализоровать нижние по стеку уровни?
Конечно, я не про школьные уроки физики, а про то когда я слышу "главное чтобы у человека был потенциал, тогда он наверняка преуспеет, а то что он не владеет конкретными инструментами - это не страшно", то с одной стороны я на 150% с этим согласен, а с другой стороны задача усложняется.
Как проверить знания языка программирования или фреймворка? Можно позадавать вопросы с которыми люди сталкиваются только на практике и таким образом понять заученная это информация или сформировавшееся понимание в боевом опыте. Но как понять есть ли потенциал? Более того, рефлексируя и применяя это к себе вопрос становится еще интереснее "а почему я решил, что у меня самого есть и был какой-то потенциал?"
К ответу на этот вопрос меня подтолкнуло видео "How Billionaires Think: Decoding The Billionaire Mind" by Sam Ovens, которое я заслуженно поместил в свой Brilliant плейлист (есть у меня такая "полочка" на ютубе куда я складываю исключительные вещи с которыми сталкиваясь). Автор этого видео попытался "декодировать то как мыслят миллиардеры", но по факту он сформулировал 5 слоев мышления в виде стека, где нижние слои принципиально влияют на верхние так, что те что выше не имеют значения, пока не будет проведена работа в самом низу. Его рассказ привемляется в тему предпринимательства (на это указывают верхние слои), но если воспринимать слово business как дело в широком смысле, то всё также отлично вприсывается, даже если хочется преуспеть как разработчик и не более того.
Итак, что же это за слои в порядке от самых важных (самых нижних по стеку), которые влияют на всё, к менее важным (читая дальше, я думаю вы сами начнете понимать ответ на вопрос "что такое потенциал?")
Layer 1 Mental Awareness
- Self Awareness - осознание себя со стороны, не конкретные мысли, а понимание паттерны мышления, которые влияют на действия и поведение
- Identity - всё что вы думаете конкретно о себе (включая установки вроде "я плох в математике", "рисование это не моё" или "этот ваш интернет уже для меня слишком сложный")
- Belief System - система сформировавшихся верований о мире вокруг, например, "деньги это зло", "работа должна быть тяжелой"
Layer 2 Mental Cognition
- способность решать проблемы,
- анализировать входящий поток информации:
— думать критически
— приоритизировать
— взвешивать плюсы и минусы
— оценивать горизонт эффекта от действий
— распознавание паттернов
- предпринимать действия на основе входящего потока:
— делегирование
— декомпозиция
— планирование
— отказ от некоторых возможностей
Layer 3 Business Principles
- на чьих интересах фокус (интересах клиента или моих собственных)
- что считается успехом (профит сегодня или рост опережая остальных в будущем)
- взгляд на мир (следование трендам или научное погружение в глубь проблемы)
Layer 4 Business Disciplines
(университеты учат на этом уровне, но не ниже и это поразительно)
- T-shape оказывает решающую роль для быстрого достижения результата
Layer 5 Processes & Tools
- владение конкретными инструментами
Так что же такое потенциал? Теперь я могу говорить, что наличие потенциала это заполненность первых трех уровней правильными установками (в соответствии представлениями того кто оценивает). Тогда как отсутствие важных компонент на этих уровнях, а также вредные установки, просто удлиняют путь, так как даже если через обратную связь эти установки удастся скорректировать, то это произойдет не сразу. Фокусируясь на анализе этих уровней и минимально-достаточном наполнении уровней 4 и 5 мы находим того самого человека "с потенциалом"
Что думаете? Какие бы вы задавали вопросы для того чтобы проанализоровать нижние по стеку уровни?
Для визуализации:
+------------------------------+
| Стек |
+------------------------------+
| Layer 5 Processes & Tools |
+------------------------------+
| Layer 4 Business Disciplines |
+------------------------------+
| Layer 3 Business Principles |
+------------------------------+
| Layer 2 Mental Cognition |
+------------------------------+
| Layer 1 Mental Awareness |
+------------------------------+
Первые 3 месяца в Англии. Подкаст
Записал нетехническое видео про наши первые 3 месяца в Англии.
По сути подкаст, когда дойдут руки - перевыложу аудио ряд на подкастовые платформы (если можете порекомендовать какой-то инструмент, который это автоматизирует - буду благодарен)
https://www.youtube.com/watch?v=Od1ncVwpkls&feature=youtu.be
Записал нетехническое видео про наши первые 3 месяца в Англии.
По сути подкаст, когда дойдут руки - перевыложу аудио ряд на подкастовые платформы (если можете порекомендовать какой-то инструмент, который это автоматизирует - буду благодарен)
https://www.youtube.com/watch?v=Od1ncVwpkls&feature=youtu.be
YouTube
Первые 3 месяца в Англии / Milton Keynes / Адаптация / Дети / Global Talent Visa / Авто | Подкаст
Подкаст о том как мы переехали в Англию и жили тут первые 3 месяца
Телеграм канал https://www.tgoop.com/from_junior_to_cto
00:00 Начало
02:02 Как мы попали в Англию
03:33 Дети в переезде
04:30 Как мы прилетели
05:44 План
07:21 Maidenhead
08:45 BRP в субботу
10:08…
Телеграм канал https://www.tgoop.com/from_junior_to_cto
00:00 Начало
02:02 Как мы попали в Англию
03:33 Дети в переезде
04:30 Как мы прилетели
05:44 План
07:21 Maidenhead
08:45 BRP в субботу
10:08…
Почини уже!
Есть такие проблемы, которые мешают решать другие проблемы. На первый взгляд они не несут функциональных улучшений, а значит не имеют значения для клиента. На самом деле, это класс проблем для которых нужно потрудиться, чтобы сформулировать ценность, а факт сложного формулирования ценности не означает её отсутствия или малой значимости.
В профессиональной среде это часто называют техническим долгом, а вот в быту это что? Шатающаяся розетка, в которую уже опасно вставлять зарядку от ноутбука, но вроде пока живёт; сломанный замок на двери, через которую то и дело кто-то заходит и отвлекает в моменты, когда только поймал поток; тусклый свет лампы, с которым глаза постепенно умирают, а усталость приходит быстрее, продолжать можно долго.
Как оценить важность проблемы того что у разрабочика нет ноутбука? Вообще, звучит довольно важно, он не может выполнять ту функцию, которую команда как человекообразное приложение по производству софтверных приложений должна в себе содержать.
А что насчет неудобного стула? Звучит не так очевидно. Но если плохой стул повлечет за собой раздражительность человека, ухудшит коммуникации, команда будет менее эффективна как единый организм, а клиент будет медленнее получать результат.
Тут сразу хочется сказать «Ну и тонкие материи, Вань, влияние этого ничтожно же, даже если приставить, что один разработчик теряет 0.05% своей производительности из-за плохого стула или замка на кабинете из которого он работает, то это НИЧТО, он кофе дольше пьет». На это хочется ответить, что во первых, эту цифру можно умножить на количество разработчиков, а во вторых еще и на среднее количество бытовых проблем. Так, из-за того что никто «розетки не чинит», страдают все остальные в объеме производительности нескольких разработчиков, в зависимости от масштаба компании.
Я определенно, не хочу чтобы этот пост закончился на нудном корпоративном языке, по этому небольшая история и затем action item.
Сегодня чинил замок в кабинете, его изначально до нас установили для галочки на место какого-то другого (видимо предыдущие жильцы). У нас от него не было ни то что ключей, но он в принципе не функционировал как положено. Я купил rim cylinder с ключами (штука в которую суют ключ и она поворачивает блокирующий механизм замка через отверстие в нем), мини-ножовку (hacksaw) по металу, долото (chisel) и всё это чтобы просто закрывать дверь при необходимости. Потратил, кажется часов 5-6 в сумме за несколько дней, но остался не только доволен резульатом, но и вдохновлен. Что не менее важно, теперь в тех местах где будет нужен фокус я скорее всего его получу.
Наверняка у тебя есть какое-то дело которое уже давно хотел(а) сделать и оно болтается в быту. Напиши что за дело такое и какую ценность (и кто) получит если ты с этим уже наконец-то разберешься
Есть такие проблемы, которые мешают решать другие проблемы. На первый взгляд они не несут функциональных улучшений, а значит не имеют значения для клиента. На самом деле, это класс проблем для которых нужно потрудиться, чтобы сформулировать ценность, а факт сложного формулирования ценности не означает её отсутствия или малой значимости.
В профессиональной среде это часто называют техническим долгом, а вот в быту это что? Шатающаяся розетка, в которую уже опасно вставлять зарядку от ноутбука, но вроде пока живёт; сломанный замок на двери, через которую то и дело кто-то заходит и отвлекает в моменты, когда только поймал поток; тусклый свет лампы, с которым глаза постепенно умирают, а усталость приходит быстрее, продолжать можно долго.
Как оценить важность проблемы того что у разрабочика нет ноутбука? Вообще, звучит довольно важно, он не может выполнять ту функцию, которую команда как человекообразное приложение по производству софтверных приложений должна в себе содержать.
А что насчет неудобного стула? Звучит не так очевидно. Но если плохой стул повлечет за собой раздражительность человека, ухудшит коммуникации, команда будет менее эффективна как единый организм, а клиент будет медленнее получать результат.
Тут сразу хочется сказать «Ну и тонкие материи, Вань, влияние этого ничтожно же, даже если приставить, что один разработчик теряет 0.05% своей производительности из-за плохого стула или замка на кабинете из которого он работает, то это НИЧТО, он кофе дольше пьет». На это хочется ответить, что во первых, эту цифру можно умножить на количество разработчиков, а во вторых еще и на среднее количество бытовых проблем. Так, из-за того что никто «розетки не чинит», страдают все остальные в объеме производительности нескольких разработчиков, в зависимости от масштаба компании.
Я определенно, не хочу чтобы этот пост закончился на нудном корпоративном языке, по этому небольшая история и затем action item.
Сегодня чинил замок в кабинете, его изначально до нас установили для галочки на место какого-то другого (видимо предыдущие жильцы). У нас от него не было ни то что ключей, но он в принципе не функционировал как положено. Я купил rim cylinder с ключами (штука в которую суют ключ и она поворачивает блокирующий механизм замка через отверстие в нем), мини-ножовку (hacksaw) по металу, долото (chisel) и всё это чтобы просто закрывать дверь при необходимости. Потратил, кажется часов 5-6 в сумме за несколько дней, но остался не только доволен резульатом, но и вдохновлен. Что не менее важно, теперь в тех местах где будет нужен фокус я скорее всего его получу.
Наверняка у тебя есть какое-то дело которое уже давно хотел(а) сделать и оно болтается в быту. Напиши что за дело такое и какую ценность (и кто) получит если ты с этим уже наконец-то разберешься