Идея для стартапа как долгий процесс, а не внезапный инсайт

90% стартапов терпят неудачу. Частая проблема – не нашли подходящую аудиторию.
Можно ли избежать этого в своем стартапе?

Рассмотрим два подхода по созданию продукта:
1. product/market fit – “Создать продукт, найти под него рынок, разместить”
2. market/product fill – “найти рынок с нерешенной проблемой, заполнить его соответствующим продуктом”

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

Составьте гипотезу, соберите людей и проведите интервью. Выявили боль? Создавайте MVP. Не надо решать надуманные проблемы.

Не лишним будет знать про TAM-SAM-SOM, CustDev-интервью, Lean Startup.
Более подробно про market/product fill можно прочитать в блоге Аркадия Морейниса.

Потоки в организации – потоки в коде

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

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

К чему все это?

Цифровизация организации необходима для улучшения потоков в отдельных подсистемах. Чем выше семантическая связь между оригинальной системой и и ее цифровым двойником, тем бо́льший эффект от синергии мы получим. Разработчик, понимающий концепции реактивного программирования, неявно гораздо более ценен для компании — подобно руководителю организации, он настраивает свою систему не на генерацию шумов, а на наблюдение за внешними изменениями, что полностью отражает суть физического оригинала.
Хотите улучшать? Освойте реактивную парадигму.

#программирование
#реактивное_программирование
#бизнес_процессы
#потоки_информации

Нужно ли учить алгоритмы для современной разработки?

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

Я и сам придерживался такого мнения, пока не начал проводить собеседования в подобной компании – теперь считаю, что понимание алгоритмов нужно любому специалисту, работающему с кодом. Так что я для себя понял?

Вот мой список:

1. Понимание структур данных
Это основа основ. Все программирование строится вокруг данных и их хранения – не знать структуры, все равно, что не знать синтаксис вашего ЯП. 95% коммерческого кода состоит из списков и словарей, но это не позволяет вам быть разработчиком на 95%, компания же платит 100% зарплаты, верно? И реальность такова, что только нарешав штук 50 задач, вы сможете полноценно понять каждую структуру на практике и писать те самые 5% эффективно.
2. Обучаемость
Здесь можно сказать и про инвестиции личного времени кандидата, и про желание развиваться вширь, но наверное, самое важное – это процесс мышления, который приобретает человек во время обучения, а также умение думать над задачей конкретно, а не абстрактно. Алгосы поддерживают ваши мозги в тонусе, и, как мне кажется, это уже достаточная причина их учить.
3. Умение писать код без IDE
Где это может пригодиться? Да практически нигде) Но довольно странно наблюдать, как специалист с 5-летним опытом работы теряется в простых языковых конструкциях. Если человек не пишет, а перебирает подсказки студии, то думается, что он и не до конца понимает, что делает.
4. Умение реально читать код
Видеть потоки данных сквозь полотно кода – это важный навык для программиста. И самый быстрый способ его развить – решать задачи в блокноте. Прочитать строку на английском сможет и дурак, но чтобы поддерживать контекст функции, нужен компилятор в своей голове, который не так-то просто настроить.

Рекомендации

1. Решайте задачи на ЯП, с которым постоянно работаете. Звучит странно, но многие просто берут Python, теряя эффект от синергии знаний.
2. Не применяйте встроенные функции, если не знаете, как они работают, и не можете написать их самостоятельно.
3. Решайте хотя бы по одной задаче в неделю. Это всего 20-30 минут, но за год сможете попробовать большинство структур и популярных алгоритмов.

Ресурсов с задачами много, но если вы просто хотите подтянуть знания, то LeetCode хватает с головой.

#алгоритмы #структуры_данных #программирование #leetcode

Многопоточность – не сложно

Как мне кажется, наиболее оптимальной стратегией при написании многопоточного кода является перенос работы с разными потоками на как можно более высокий уровень абстракции. Отдельные функции должны писаться в “чистой” парадигме, а ответственность за параллельные изменения должна быть в едином месте, примерно рядом с созданием этих потоков.
Самой большой проблемой в многопоточке является доступ к единой переменной, и чем сильнее раскидано обращение к этой переменной по классу, тем менее читаемый и масштабируемый код мы получаем в итоге. Старайтесь как можно реже изменять общие мутабельные объекты в разных функциях класса – прокидывайте их через аргументы и возвращайте измененные как результат функции.
При написании целого класса проверьте, что все публичные методы готовы к вызовам на разных потоках извне – потребитель класса не должен задумываться о том, как правильно с ним работать, если явно не указано иное.

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

class SomeBadService {
    private var number: Int = 0

    fun changeNumber(): Int {
        change1()
        change2()
        change3()
        return number
    }

    private fun change1() {
        number++
    }

    private fun change2() {
        number--
    }

    private fun change3() {
        number += 2
    }
}

class SomeBetterService {
    private var number: Int = 0

    fun changeNumber(): Int {
        val firstChange = change1(number)
        val secondChange = change2(firstChange)
        val thirdChange = change3(secondChange)
        number = thirdChange
        return number
    }

    private fun change1(num: Int): Int {
        return num + 1
    }

    private fun change2(num: Int): Int {
        return num - 1
    }

    private fun change3(num: Int): Int {
        return num + 2
    }
}

Пример дурацкий, но надеюсь, удалось передать основную мысль.

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

#программирование #многопоточность

Перестаём душнить на code review

Подключили на проекте Danger.
Эта утилита позволяет автоматизировать проверку кода на CI через написание скриптов. Теперь душнить вместо вас будет бот.

В рамках скрипт-файла вам предоставляется доступ к сущности git, откуда вы можете достать такую информацию, как профиль автора, название PR, коммиты, диффы отдельных файлов и т.д.
Оригинальный Danger понимает Ruby-синтаксис, но есть отдельная версия под JS. Если вы хотите писать скрипт на другом языке, то нужно проверять наличие утилиты на официальном сайте, но это уже костыльные обёртки над оригиналами и часть функционала может отсутствовать.

Как подключить?
1. Создаёте access token на git-платформе.
2. Создаёте ci-таску из докер-образа на основе нужной вам утилиты (в моём случае это danger-kotlin).
3. Прописываете в переменную окружения таски access token.
4. Создаёте скрипт-файл по инструкции вашей утилиты.
5. Делаете PR. По итогу выполнения таски бот сам напишет комментарии в соответствии с вашим скриптом.

Утилита поддерживает плагины. Есть куча готовых по интеграции с линтерами, детектами и прочим, но также можно писать свои.

Мы в проекте подключили такие проверки:
1. Проверка названия и описания MR.
2. Если к модулю app был подключён дочерний модуль, то проверяем наличие тестов в дочернем.
3. Если были изменения строк, связанных с классами отправки аналитики, то просим провести регресс аналитики конкретных модулей.

На Хабре вышла статья под моим авторством, буду рад вашим визитам
https://habr.com/ru/companies/wildberries/articles/905238/

#habr #android

На днях попробовал сделать аналог стекломорфизма из iOS 26 для Android Compose.

Мои попытки вылились в небольшую библиотеку, которая добавляет настраиваемый стеклянный контейнер для вьюшек.

Подробнее можно посмотреть в репозитории https://github.com/Mortd3kay/liquid-glass-compose

Из интересного в разработке:
0. Compose не умеет вычитывать пиксели не из дочерних вьюх – пришлось идти на ухищрение и оборачивать всю конструкцию в контейнер.
1. Стекло хотелось сделать настраиваемым – референсы брал с этих проектов раз два три.
2. Настраиваемость стекла сильно ограничивает в использовании displacement-карт, поэтому решил преломлять цвет алгоритмически.
3. Моделировать реальную линзу неэффективно и не нужно, поэтому была разработана хитрая имитация – здесь очень помогал Cursor.
4. Отражение соседних элементов требовало написания RayMarching'а – как по мне, это дорого, поэтому для блика стекла просто берется цвет пикселей на небольшом расстоянии от границы.

Месяц назад я решил принять участие в контесте Telegram – нужно было переработать экран профиля, добавив кнопки и анимацию подарков, как это сделано на iOS.
Сегодня объявили результаты и я вошел в число тех, кто занял 2 место – очень приятно, учитывая, что это мой первый опыт в подобных соревнованиях. Не успел осилить размытие под кнопками и эффект прилипания аватарки при сворачивании, но все равно вышло неплохо. Даже порефачил немного код:)

Ниже представлен результат моей работы: