Благодаря старанию мобильного сообщества сейчас есть много классных источников информации про то, как писать код, или про то, как устроена мобильная ОС. Намного меньше источников, из которых можно узнать, как выстраивать процессы поставки в командах и как связывать это с процессом разработки. А это тоже по-своему важно. Прозрачность и общее понимание процесса релиза и доставки позитивно влияет на эффективность команды - помогает каждому лучше планировать деятельность.
Всем привет! Я на Мосбирже занимаюсь мобильной разработкой под Android. Осенью этого года мы начали разрабатывать приложение для платформы личных финансов Финуслуги и воспользовались возможностью делать UI сразу на Jetpack Compose. Как и всегда, сразу встал вопрос выбора архитектуры многомодульности и механизма навигации. Решение должно быть, с одной стороны, достаточно лаконичным и понятным для новых разработчиков. С другой стороны, оно должно быть масштабируемым, чтобы рост числа и размера модулей не создавал неприятностей, таких как раздражающее времени сборки или частые merge-конфликты.
Давным-давно в Kotlin были представлены корутины, одной из особенностей которых является легковесность (создание корутин дешевле, чем с запуск новых Threads). Мы можем запускать несколько корутин, и нам нужен способ взаимодействия между ними избегая “mutable shared state”
Я — инженер. Во-первых, по образу мышления, во-вторых, после выпуска из МГТУ им. Н.Э.Баумана, эта фраза стала мантрой. Я живу с постоянной потребностью изобретать и творить. Плюс в том, что работа в удовольствие и это плодотворно. Минус — из-за этого когнитивного смещения инженер в вакууме рискует вложить много ресурсов в продукт, который оказывается нужен только в его фантазиях.
Здесь я поделюсь своим путем, выводами, а главное, ошибками, которые я приобрел запуская стартап. Часть из них могут повторять много раз описанные рекомендации и быть банальными для опытной аудитории. Но я думаю их полезно держать в голове при старте своего проекта, особенно человеку с восприятием мира, смещенным в сторону технологий.
Блокчейн-протоколы должны обеспечивать консенсус среди нод децентрализованной системы. Пожалуй, самым известным алгоритмом консенсуса можно считать «тормозунутый, но надежный, потому что тормознутый» алгоритм Proof-of-Work: каждая нода, имея набор новых транзакций перебирает некоторое число nonce, являющееся полем блока. Блок считается валидным, если валидны все транзакции внутри него и хэш-функция от заголовка блока имеет некоторую общепринятую особенность (например, количество нулей в начале, как в Bitcoin):
Hash( Block{transaction,nonce,…} ) = 000001001...
Как известно, блокчейн — это цепочка блоков. Цепочкой он является потому, что внутри каждого блока записан id (как правило хэш от заголовка) предыдущего блока. Для последующих рассуждений блокчейн в упрощенном виде можно представить так:
Эта статья в первую очередь пригодится тем, кто пишет ТЗ для программистов, и программистам, которые решили разрабатывать прототип самостоятельно.
Многие относятся к созданию визуального прототипа, написанию ТЗ, как к некоему творческому, порой спонтанному процессу. И во многом они правы. В этой статье приводятся полезные для практики правила (о большинстве из которых мы знаем, но часто забываем воспользоваться), принятие которых поможет повысить качество результата и снизить временные затраты.
