Архив недели
Понедельник
Привет!
Меня зовут Дима, я тимлид платформенной Android команды Яндекс Музыки. А до этого разработчик в Музыке, а до этого тимлид и разработчик в RedMadRobot, а до этого ещё всякое
Я не веду соцсети, но если очень захочется – пишите в телегу hllbrnd
Или подписывайтесь на неактивный инстаграм dmitrtimosh, вдруг когда-то я начну туда постить (нет)
Я пока разбираюсь, куда в твиттере нажимать, но скоро начнём. Готовьтесь к порванным тредам, комментариям не туда и что тут ещё может случиться!
Писать я буду и про разработку, и на отвлечённые темы. Попробую чередовать: день потока сознания – день про мобилки – день чего-то ещё – день про мобилки, и так далее
Думаю (но не обещаю), что будет так:
Пн: как работают звук и музыка?
Вт: мобильные релизы
Ср: развитие технологий
Чт: стабильность мобильных приложений
Пт: кем стать, когда вырастешь?
Сб-вс: по обстоятельствам, в крайнем случае покидаю фотографии кошки
Сегодня говорим про музыку: что такое ноты (с точки зрения физики), почему что-то звучит хорошо, а что-то так себе, и как так получается, что мы можем слышать это из динамиков
Мне стало интересно в этом разобраться после видео @its_adamneely про полиритмы. Там было ещё про взаимосвязь звука и цвета, и я такой "чтоооо" и пошёл разбираться, а теперь вам расскажу. Видео вот, посмотрите, оно классное: youtu.be/JiNKlhspdKg
Для начала вспомним, что такое звук. На бытовом уровне – что-то двигается, двигает воздух, воздух начинает колебаться, и эти колебания улавливаются ушами
Формально колебаться может не воздух, а любой газ, жидкость или твёрдое тело, и не обязательно, чтобы чьи-то уши участвовали. Но для сегодняшней темы бытового представления достаточно
Колеблющийся воздух давит на органы слуха (от того, как сильно, зависит громкость) и делает это сколько-то раз в секунду (частота звука). Вот и всё, что нам нужно будет знать про звук
@mobileunderhood Ого, Дима, доброго утра, а можно вашу команду попросить прикрутить этот счётчик с браузерной версии я.музыки на приложение на андроиде...👉👈 https://t.co/kHvQQEUyMS
210, неплохо!
Ничего не обещаю, но запишу twitter.com/Koshelevaaaaaa…
А, да, и слышать человек может только тот звук, при котором воздух колеблется от 20 до 20000 раз в секунду. Примерно. Это нам тоже пригодится
Например, тут szynalski.com/tone-generator/ можно поиграться с частотами и послушать, как оно. Только аккуратно с громкостью, высокие частоты могут быть неприятными
Так вот, музыкальные звуки возникают, если достаточно длительное время существует звук с одной и той же частотой. Когда мы говорим, частоты меняются слишком быстро, чтобы это было музыкальным звуком. Но если сделать АААААААА, чудо произойдёт
Такие звуки обозначаются нотами. Например, если сделать такое АААААААА, что воздух начнёт двигаться 440 раз в секунду, получится нота Ля (или A в международной нотации)
Всего нот, как вы знаете, 7: до-ре-ми-фа-соль-ля-си, или, соответственно, CDEFGAB
Важно то, что в природе никаких нот не существует. Нет никакой особенности у звука с частотой в 440 Гц, чтобы именно его выделить, назвать его A, и от него рассчитывать всё остальное
Какие-то люди собрались и решили, что надо бы стандартизировать. Поспорили, повыбирали и остановились на таких значениях. И сделали это только в 1939 году, до этого никаких стандартов не было
Условно, если в одном городе построили орган, где на кнопку Ля издаётся звук с 430 Гц, то так в том городе и будут играть. И не важно, что написал музыку композитор в городе, где на ту же кнопку 445 Гц
Заодно это означает, что все произведения, написанные до 1939 года, мы слышим не в той тональности, в которой они были написаны. Моцарт, например, примерно на полтона отличается
Забавно то, что почти для любого человека это не важно: мы воспринимаем разницу в звуках, а не их абсолютные значения, так что на слух до-ре-ми остаётся до-ре-ми, от чего ни начинай расчёт
Почти для любого, потому что есть люди с абсолютным слухом. Я всегда думал, что это качественная характеристика типа "хорош, все косяки в музыке слышишь!"
Но на самом деле абсолютных слух – это когда запомнил, как звучит каждая из нот, и можешь их определить сами по себе, а не в сравнении. Сыграют тебе 430 Гц вместо 440, и ты слышишь, что звук не тот. Большинство людей не услышит, пока следом не сыграют другую ноту
Всем привет! Мы начинаем Айти Андерхуд и это большая честь быть первым автором! Пусть расцветают сто цветов! А теперь обо мне...
Ребята, тут рядом ещё интересное происходит, идите читать twitter.com/itunderhood/st…
@mobileunderhood На самом деле 12. 7 - это у определенной гаммы, например то что Вы написали - это до мажор
Да, спасибо!
Я пока про привычные названия. О том, на какие интервалы делится октава, чуть позже twitter.com/skiba_dmitry/s…
Ребята, я позавтракал
Надеюсь, вы уже послушали, как звучат звуки с разной частотой (выше была ссылка). И, может быть, обратили внимание, что звучат они не очень естественно – не как пианино, или гитара, или ещё что-то привычное
Дело в том, что музыкальные инструменты издают звук не одной частоты, а множества разных. В реплаях уже писали про обертоны
Колеблющаяся струна издаёт звук не только всем своим телом. Колеблются ещё и половинки струны, и её трети, и четверти и тд. Каждая из таких частей издаёт звук со своей частотой, кратно отличающейся от оригинального: 440 струна, 880 половины, 1320 трети и тд
Это актуально не только для струнных инструментов, но и, например, духовых, Там вместо струны колеблется трубка, но по тем же принципам
А ещё дополнительные звуки даёт корпус инструмента. Поэтому музыкальные инструменты производят не просто гуд на определённой высоте, а что-то интереснее
@mobileunderhood Ты работал с сырым миди-форматом в мобильной разработке, в частности на андроиде? Может есть ссылки на репозитарии с хорошими примерами?
Не, не работал, но тоже посмотрел бы. Кто знает – скидывайте, пожалуйста twitter.com/uniserpl/statu…
Ещё в реплаях писали о том, что нот не 7, а 12. Действительно, у нас есть 7 привычных названий (до-ре-ми-фа-соль-ля-си), но это не все существующие ноты. Между ними есть и другие. Например, между ля и си есть ля-диез (A#)
Итого полный набор выглядит так: C-C#-D-D#-E-F-F#-G-G#-A-A#-B-C. Да, в конце ещё раз C, круг замыкается. Это можно записать и по-другому, но не важно, просто помним, что у нас получилось 12 отрезков, которые называются "полутон"
А весь интервал называется октава. Частота нот на разных концах октавы отличается ровно в 2 раза. Например, от 261.626 Гц до 523.251 Гц (с небольшим округлением). Такие ноты, с разницей в частоте в 2 раза, ОЧЕНЬ похожи
Поэтому, во-первых, их одинаково называют (в предыдущем примере обе частоты – это нота до). Во-вторых, их заметили ещё в древности, и строили свою древнюю музыкальную теорию вокруг этого: Пифагор упражнялся в делении струны и поиске соотношений в 500х годах до нашей эры
Опустим историю этих делений, но к нашим дням в западной традиции это эволюционировало до деления октавы на 12 равных полутонов. Это значит, что частота ноты N+1 равна частоте ноты N, умноженной на корень 12 степени из 2
В октаве 12 таких нот, 12 раз умножаем X на корень 12 степени из 2, и получаем 2X. Частота ноты в конце октавы в 2 раза больше, чем в начале, сошлось
Я пока прервусь, а то всё закончится ещё до обеда и станет скучно. До встречи попозже!
Мы уже обсуждали, что кроме основной ноты музыкальный инструмент производит обертоны, звуки корпуса, всё это взаимодействует и получается лучше, чем просто отдельная нота
Но это не единственный случай, когда звуки взаимодействуют. Можно сыграть несколько нот на одном инструменте, или взять целый оркестр, или пошуметь, пока кто-то играет. Все эти звуки тоже будут влиять друг на друга, хорошо или плохо
Музыкальный звук можно представить как синусоиду – воздух колеблется то в одну, то в другую сторону, много раз в секунду, и так повторяется какое-то время
Когда есть несколько источников звука одновременно – синусоиды складываются
Проще всего складываются синусоиды нот, находящихся на расстоянии октавы друг от друга. Частоты различаются ровно в 2 раза, а значит в рамках одного периода первой ноты поместится ровно два периода второй
Соотношение частот соседних клавиш пианино примерно 17/18. При сложении их синусоид получится довольно сложный паттерн, который на слух воспринимается как какофония
Общее правило: чем проще соотношение, тем проще его воспринимать на слух. Слишком сложное кажется хаосом
Тут нет чёткой границы, когда ещё слишком просто и не интересно, когда норм, а когда уже хаос
Ещё можно представить (и даже создать) ситуацию, когда одновременно воспроизводятся звуки, находящиеся в противофазе. То есть, например, сыграть на двух инструментах ноту ля 440 Гц, но на втором на 1/880 секунды позже, чтобы был сдвиг на половину периода
Сумма синусоид таких звуков окажется прямой, а значит и никакого звука не будет!
По этому принципу может работать шумоподавление: определяем внешние звуки, производим свои такие же, но в противофазе, и они друг друга гасят
Осталось разобраться, как эти колебания воздуха, которые производят музыкальные инструменты, голосовые связки и что угодно ещё становятся звуком в наушниках
При звукозаписи используются (НЕОЖИДАННО) микрофоны, суть работы которых в том, что колебания воздуха воздействуют на мембрану (примерно как и на органы слуха), а изменения в мембране транслируются в электрический сигнал
Я работу микрофонов представляю только на таком общем уровне, но если кто-то из читателей разбирается в теме – расскажите, пожалуйста. Интересно
Значения отклонений мембраны записываются с некоторой частотой (например, 44100 раз в секунду). Эту частоту называют частотой семплирования. То есть за секунду записывается N семплов
Так аналоговый звук (колебания воздуха) становится цифровым (ряд значений, считанных с мембраны)
С числом 44100 вы наверняка сталкивались в контексте WAV файлов или ещё какого-нибудь цифрового звука, записанного без потерь
Частота в 44100 сэмплов в секунду используется не случайно. Мы уже говорили, что человек слышит звуки с частотой до 20 кГц. По теореме Котельникова, для дискретизации аналогового сигнала без потерь нужна частота дискретизации минимум в 2 раза больше максимальной кодируемой
То есть чтобы закодировать частоту до 20 кГц, нужно записывать сэмплы 40000 раз в секунду. Тогда из этой записи можно будет восстановить оригинальный сигнал. 4100 – это некоторый запас, который от чего-то защищает, но я не знаю, от чего. Если знаете – расскажите, пожалуйста
При такой записи мы получаем файл типа WAV: хэдер, а потом сэмплы-сэмплы-сэмплы, по 44100 (или какая там у нас частота дискретизации) в секунду для моно или 88100 для стерео. Очень просто, очень качественно, занимает очень много места
Поэтому следующий шаг – как-то это всё пожать. Самый известный подход – это mp3
Во-первых, люди слышат не всё, что там без потерь записали, так что часть информации можно удалить и никто особо не заметит. Такой набор эвристик, какие данные важны и слышны, а какие нет
Во-вторых, большинство использует не супер качественную аппаратуру для воспроизведения. Эта аппаратура всё равно не сможет воспроизвести все нюансы. Можно эти нюансы заранее выкинуть и сэкономить место
Это, конечно, кодирование звука с потерями, и полностью восстановить оригинал уже не получится. Структура тоже не такая простая и не сводится к последовательности самостоятельных сэмплов
Зато размер может быть меньше на порядок
В любом случае, дальше при воспроизведении оцифрованный звук каким-то образом (в зависимости от формата) преобразуется обратно в последовательность соответствующих электрических сигналов. Они, в свою очередь, определённым образом двигают мембрану динамика, а она – воздух
И вот они, наши колебания воздуха, которые воспринимают органы слуха
Почитать подробнее про физические основы музыки можно тут play.google.com/store/books/de…
или тут play.google.com/store/books/de…
Про дискретизацию звука я пока не нашёл один хороший источник и читал всякие статьи, уже не найду, какие именно
Это всё, что я хотел сегодня рассказать. Пишите ваши вопросы, комментарии, исправления и дополнения
Вот вам музыки на вечер, ребята youtu.be/GYLBjScgb7o
Вторник
День второй, говорим про релизы
Сегодня без большого треда. Немного расскажу, как у нас, и много поспрашиваю, как у вас. Не стесняйтесь набрасывать, говорить, что всё неправильно и нужно совсем по-другому
Я сталкивался с 3 подходами к графику релизов:
– регулярные (раз в неделю, месяц, etc)
– по требованию (когда фичи сделаны, тогда релизим)
– регулярные по требованию (хотим раз в неделю/месяц, но каждый раз ждём фичи)
А как у вас?
Регулярные релизы классные, если у вас продуктовая компания, а продукт уже достаточно взрослый, чтобы был смысл катить что есть, а не что-то одно ключевое важное
Чтобы регулярные релизы работали в аутсорсе, заказчик должен быть или очень в теме, или отстраниться и не участвовать. Обычно заказчики рады регулярным релизам (добавляет предсказуемости), но любят ещё и закоммититься на что-то перед своим руководством
В результате к регулярности добавляется ещё и требование на то, какие фичи точно должны в релиз попасть. И команда или начинает упарываться и разрываться между регулярностью и фичами, или регулярность заканчивается
Для стартапов, кажется, регулярность вообще лишняя: когда всё, что нужно для проверки очередной гипотезы, готово, тогда и релиз. Но я не пробовал, расскажите, если всё не так
У релизов по требованию много преимуществ. Главное – у ключевых фичей минимальный тайм ту маркет. Как только фича готова, можно катить в прод. Но ресурсы начинают уходить на дипломатию, какие же фичи считать ключевыми, не подождать ли ещё кого-то и тд
И есть шанс, что никто не будет достаточно настойчиво требовать релизы, и они вообще прекратятся на длительное время. Можно накопить кучу изменений, которые сложно стабилизировать и выкатить
Думаю, релизы по требованию – обязательный формат для стартапов и самый простой формат для аутсорса. Главное, чтобы там были люди, которые эти релизы хотят и драйвят
"Регулярные релизы по требованию" – скорее признак, что что-то идёт не так. Нормально, если в 1 релизе из 10 нужно что-то подождать, потому что рекламная кампания, непереносимый эвент или что-то такое. Если регулярные релизы и сдвигаются регулярно – может, хватит себя обманывать?
В опросе многие выбирают "регулярно по требованию". Расскажите, почему вы всё равно пытаетесь процесс с регулярностью релизов поддерживать? Или почему не получается по расписанию отрезать, что есть, а что не влезло – в следующий раз? Вам вообще ок?
Окей, а как часто у вас получается публиковать релизы? Не важно, по расписанию или в среднем
Напоминаю, речь про мобильные приложения. Понятно, что бэкенд/фронтенд можно перенакатывать на каждое изменение в мастере
Мы недавно перешли на релизы по расписанию каждую неделю (до этого было каждые две недели). Чаще релизы – меньше тайм ту маркет у фичей. С другой стороны, чаще релизы – больше времени на них тратится. Или нет?
Оказалось, что чем меньше изменений в релизе, тем проще его выкатить, тем меньше шансов, что что-то пойдёт не так. Так что дополнительные расходы, конечно, есть, но не в 2 раза. И чем больше рутинных операций автоматизировано, тем меньше этих дополнительных расходов
Примерно треть голосует за "раз в месяц" и "реже, чем раз в месяц". Вам чаще не хочется? Или не получается почему-то?
Давайте теперь по релизному процессу пройдёмся. Посмотрим, где что может не так пойти и где можно сделать лучше
Для начала нужно получить версию кодовой базы, которую попытаемся зарелизить. У нас это автоматизировано: запускаем билд на тимсити, и автоматически отводится релизная ветка, инкрементируется номер версии, подтягиваются переводы и пр
Знаю, что у некоторых релизы отводятся не по кнопке, а по таймеру. Типа "в 16:00 по мск каждую среду отвести релиз". А вы как делаете?
Дальше, конечно, делаем билд из релизной ветки. Не буду делать опрос, собирает ли кто-то релизы локально, не хочу знать
В этот момент у многих начинается тестирование, но не у нас, так что пойдём по другой ветке
Собранный apk/aab нужно отнести в Google Play, и вот тут начинаются проблемы:
– можно взять не тот файл или не из того билда или ещё как-то перепутать
– нужно нажимать кнопки в консоли Google Play, а там, конечно, ничего не понятно и вчера в очередной раз выкатился редизайн
Нам нужно сделать просто действие: собранный артефакт положить в закрытый альфа-канал. Но при этом в стольких местах что-то может пойти не так, что не понятно как мы вообще релизимся
Отдельное спасибо гуглу за очень удобный UI, в котором невозможно ошибиться и всегда всё понятно
Наверняка этот этап можно как-то автоматизировать: каждый раз, когда завершается релизный билд, брать правильный файл и относить его в консоль гугл плея через API. Но у нас такой автоматизации пока нет. А у вас? Может, ещё и готовые инструменты знаете для такого?
Уже целых 8 человек автоматизировали, но больше половины носит руками. Поднажмите, ребята!
В реплаях спрашиваю, а когда же тестирование. А вот теперь тестирование, когда сборку принесли в закрытый альфа-канал. Тут тестирование проверяет, что обновление с предыдущей версии корректно работает и такие базовые сценарии
Опережая вопросы: автотесты, конечно, тоже, но сегодня не о них
Тестирование даёт добро, и релиз из закрытой альфы едет в открытую бету. Да, опять руками нажимать кнопочки в гугловом UI, спасибо, очень приятно
В бете сборка проходит полноценное регрессионное тестирование и, в то же время, попадает к небольшому количеству смелых пользователей, на это подписавшихся. На выходе получаем результаты внутренних тестов и информацию по крешам, ANRам и прочим неприятностям у пользователей
Про стабильность приложения у нас будет отдельный разговор через пару дней. Но вообще открытая бета почти всегда позволяет заметить новые креши/ANRы и как-то на них среагировать до полноценной выкатки в прод – выключить какой-то фичетогл или отменить релиз
А вот не столь фатальные проблемы в ней хуже заметны. Крупные баги мы обычно видим сами ещё до беты, а что-нибудь поменьше пользователи не так быстро замечают и приносят в саппорт, чтобы мы на этом этапе успевали среагировать
Забыл спросить: а вы открытой бетой пользуетесь? Или сразу в прод?
Если при тестировании беты всё ок, и у пользователей в бете всё ок, релизные тестировщик и разработчик решают, что можно катить на процент в прод. Я тут не буду супер подробно расписывать
Катим на 5, 25, 50 и 99 процентов каждые сутки, есть всё в порядке. До 100% докатываем при начале раскатки следующего релиза. Выкаченный на 99% релиз проще выключить, если в нём всё-таки что-то найдётся, но не помню, чтобы эту возможность когда-то использовали
Весь процесс занимает примерно неделю, и релизы у нас раз в неделю, так что что-нибудь катим мы почти всегда
Нажимать что-нибудь в консоли гугл плея приходится довольно часто. Заливку apk/aab мы уже обсудили, но ещё есть перевод из альфы в бету, из беты в прод и изменение процентов. Кто-нибудь использует API настолько, чтобы вообще туда не заходить? Это возможно?
В общем-то, на этом тред заканчивается. Пишите свои вопросы, замечания. Объясняйте, что мы делаем не так. А завтра посмотрим на результаты опросов
Музыка на сегодняшний вечер youtu.be/6r7D6gNEWFs
Среда
Ребята, я сходил за наполнителем для кошачьего туалета и готов начинать сегодняшний тред
Сегодня ещё один день не про мобильную разработку. Расскажу про технологии, за которыми слежу, которые жду и в которые верю. Или не верю, но хотелось бы
Ключевое слово тут "верю" – за всем этим я наблюдаю со стороны и у меня нет доказательств, что оно всё правда находится в таком состоянии, как я думаю. Если меня читает кто-то из тех сфер, которые будут упоминаться, – обязательно рассказывайте, что там у вас на самом деле
Примерно все сферы, которые мне интересны, объединяет то, что они про автоматизацию – что-то сейчас делается людьми, а хотелось бы, чтобы само. Чтобы дальше быть на одной волне, давайте обозначим некоторые общие идеи
Когда за счёт технологий что-то начинает происходить "само" – оно может быть автоматизированным (automated) или автономным (autonomous). Не уверен, что правильно перевожу на русский, но в англоязычной литературе такая терминология используется
Что-то "автоматизировано", если человек всё ещё участвует в процессе, но выполняет меньше операций, чем в случае с ручным трудом. Что-то "автономное", если оно работает без участия человека
При этом это не дискретные понятия, а шкала, на одном конце которой ручной труд, на другом – автономность, а посередине – разные степени автоматизации
Помимо этого, уровень автоматизации может зависеть от того, какая именно операция автоматизирована. Например, у автомобиля может быть почти автономный климат-контроль (вы можете на него влиять, но основную часть времени он сам), но при этом автомобиль в целом управляется вручную
И третья градация – какое место занимает участвующий в процессе человек. Он может быть постоянным участником (man in the loop), способным вмешаться наблюдателем (man on the loop) или вообще не участвовать (man out of the loop)
Итого все технологии, связанные с автоматизацией, можно оценивать по этим трём критериям: насколько сильно убирается ручной труд, какие операции из общего набора автоматизируются и какое место занимает человек, если всё ещё участвует в процессе
С этой точки зрения будем сегодня смотреть на всяческие технологии
@mobileunderhood Без участия человека — автоматическое управление
Да, в университете нас тоже так учили, но мне не нравится, что эта терминология конфликтует с англоязычной twitter.com/shaykemelov/st…
Очень, конечно, хочется автономные автомобили. Теоретически, это может позволить избавиться от почти всех парковок в городах и вообще переоборудовать большую часть автомобильной инфраструктуры под что-то полезное
Проблема в том, что автономность пока относительно хорошо работает только в тех сферах, где человек физически не может участвовать. В высокочастотном трейдинге, например. Но и там периодически что-то выстреливает, а быстро остановить автономную систему не всегда возможно
В остальных случаях выигрывают системы с высокой степенью автоматизации, но всё-таки с человеком хотя бы в роли наблюдателя. Автопилоты самолётов, например, хоть и могут почти всё сами, но всё равно не оставили пилотов без работы
За американскими военными беспилотниками всё ещё следит оператор откуда-нибудь из Невады и санкционирует разные действия, особенно летальные воздействия
Видимо, проблема в том, что предусмотреть все корнер кейсы сложно/дорого/невозможно, цена ошибки слишком высокая (в том числе в плане репутации технологии), и проще платить зарплату оператору, чем биться за полную автономность
@mobileunderhood "но при этом автомобиль в целом управляется вручную" если ты едешь на запорожце. ABS, EBD, ESP, BAS, круиз контроль, усилители руля, коробка-автомат, помощь при трогании в горку. Современные атомобили обладают хотя бы парой из этих технологий. Даже Гранты
Конечно, управление автомобилем может быть в разной степени автоматизировано. Это был пример, что автономность одной части системы допускает ручной режим остальных частей twitter.com/ad1Dima/status…
Идея же автономных автомобилей как-то не очень стыкуется с наличием оператора, пусть не за рулём, а где-то там далеко. Вряд ли такой оператор сможет в реальном времени реагировать на внештатные ситуации на дороге и страховать автоматику
При этом внимание к любому происшествию с автономными автомобилями приковывается очень много. Одна авария – и вот уже Убер таскают по судам, а тестирование их технологии приостанавливается. Даже если статистически аварий с автономным транспортом гораздо меньше
И ещё один немаловажный момент – автономный транспорт должен лишить работы миллионы человек. Наверняка не сразу всех, наверняка не везде, но всё же. Даже замена одного вида работы на другой вызывает сопротивление (вспомним протесты против Убера в странах Европы)
А уж замена рабочих мест на автономную технологию и подавно не получит массовой поддержки. Не только со стороны людей, но и со стороны государств, примерно с конца XIX века взявших курс на социальные гарантии вместо прогресса и свободы
Такие глобальные изменения в структуре занятости скорее всего не обойдутся без введения того или иного вида безусловного дохода, что тоже процесс непростой и не быстрый
Итого против автономных автомобилей сложность перехода от автоматизации к настоящей автономности; завышенные требования к надёжности технологии; социальные риски, с ней связанные
Но очень, конечно, хочется, чтобы всё как-то решилось и запаркованные улицы переоборудовались в скверы, пешеходные зоны и прочее благоустройство, к которому людей подвозили бы автономные такси и уезжали куда-то с глаз долой
При этом очень высокая степень автоматизации отлично интегрируется. Самые заметные в этом, конечно, Тесла. Но и остальные начинают активно помогать вождению, автономно парковаться и пр
Замечу, что так как раз снимаются обозначенные выше проблемы: нет перехода к автономности или он очень ограниченный по сценариям использования; мало рисков (при парковке сложнее попасть в серьёзную аварию); человек не убирается из цикла, никто не теряет работу
Давайте теперь про доставку. Встречать курьеров в 2020 (особенно в 2020), серьёзно? Когда уже еда, и не только еда, будет просто появляться у меня в квартире?
А ещё у меня кошка боится звонков в дверь и бежит прятаться каждый раз, когда курьер приходит
Очень верю и жду доставку дронами. Тут примерно те же проблемы, что с автомобилями – нужна автономность, много людей потеряют работу, – но, кажется, стоят они не так остро
С другой стороны, тут всё гораздо хуже с инфраструктурой. Если автономные автомобили могут использовать дороги общего пользования и всё остальное, что там нужно, то как быть дронам? Лететь они, конечно, могут просто между домами, но нужно где-то сгрузить доставленное
Довозить товар до подъезда и там передавать клиенту – полумера. Так всё равно нужно будет встать с кресла и предпринять активные действия
В городах будущего должны быть контейнеры для дронов на окнах. Составляешь расписание, и 3 раза в день у тебя в контейнере появляется свежая еда. И ни один человек не поучаствовал
Сейчас в США, насколько я знаю, лицензия на доставку дронами есть у 3 компаний: Wing (Alphabet), Amazon и UPS. Но и они пока скорее тестируют частный сектор (где и так курьеры могут товар у двери оставить), а не многоквартирные дома. Вообще, новостей из этой сферы маловато
Вообще в сфере доставки напрашивается модель man on the loop вместо текущей in the loop. Не понятно, почему я могу включить "Плейлист дня" и минимально влиять на то, что слушаю (могу посмотреть и переключить, но если этого не сделаю – будет играть само)
...но не могу получать "Меню дня" – утром можешь посмотреть и подредактировать, но если ничего не сделать – оно просто приедет. Что-то похожее делает Grow Food, но это, конечно, не тот масштаб, как если бы блюда приезжали из любых заведений и на основе персональных рекомендаций
Представьте, как круто будет в будущем:
– оформил подписку на еду;
– выбрал несколько любимых и нелюбимых блюд;
– 3 раза в день (или сколько вам нужно) в контейнер на окно дрон приносит очередную свежую порцию;
– вы можете оценить доставленное и система дообучится;
– можно заранее посмотреть и поредактировать, но не обязательно;
– автоматически считаются бжу, калории, учитываются индивидуальные рекомендации врачей и пр
Очень ещё хочется максимум автоматизации в сельское хозяйство. И там много сейчас разного происходит
С одной стороны, автоматизируются традиционные процессы. Почитайте, например, что в @CognitivePilot делают, если пропустили habr.com/ru/company/cog…
И обратите внимание, как это на наши предыдущие рассуждения ложится: это не полная автономность и не забирает у людей работу полностью. Ещё и работает на существующем оборудовании, без необходимости всё новое покупать. Такое должно взлетать и взлетает
Но мне интереснее, как меняется формат сельского хозяйства. Вместо того, чтобы забирать территории у природы, часть с/х начинает забирать территорию города. Я про вертикальные фермы и сити-фермерство
Вообще пока не видно каких-то очень уж успешных игроков на этом рынке, чтобы была прямая ассоциация типа "электромобиль – это Тесла, музыкальный стриминг – это Яндекс Музыка". "Вертикальная ферма – это..." пока не понятно
Но уверен, что в следующие лет 10 появятся большие влиятельные игроки и на этом рынке
Из российских компаний этой сферы последнее время в новости периодически попадает iFarm (твиттера у них, похоже, нет)
Для развития вертикальных ферм несколько предпосылок.
Во-первых, население растёт, еды нужно всё больше. Вслед за населением растут города и занимают часть с/х угодий. С/х отбирает новые территории у природы, но там тоже не бесконечный ресурс
В итоге, по прогнозам, к 2050 году площадь с/х угодий из расчёта на одного человека существенно уменьшится
Во-вторых, вертикальные фермы лучше подходят для автоматического выращивания растений (проще в помещении создавать стабильный климат, чем в поле). А значит и результат получается предсказуемее, уменьшается зависимость от изменений климата и пр
В-третьих, технология соответствует тренду на экологичность. Еда выращивается где-то рядом с магазином, её не нужно далеко везти и засорять мир выхлопами
Одной экологичности для устойчивой бизнес-модели мало, но в сочетании с предыдущими пунктами норм
Ну и доставить свежий помидор с такой фермы можно дроном прямо в контейнер на окне ;)
Если бы мне нужно было вложиться в какую-то одну сферу на следующие 15-20 лет – я бы вкладывался в сити-фермерство
Забыл сказать, что на этом тред окончен. До завтра, ребята!
Четверг
Ребята, это не учебная тревога. У меня первый день после отпуска, миллион писем, пятьдесят встреч подряд. Сегодня пообщаемся ближе к вечеру
Сегодня четверг, и по плану у нас разговор про стабильность приложений
Это своего рода продолжение позавчерашней темы про релизы – там мы выстраивали процесс, чтобы при раскатке всё было ок, а сегодня обсудим, что это за "ок" и как на него смотреть
За скобками оставим баги, которые находит ручное тестирование. Сосредоточимся на том, что можно заметить с помощью систем мониторинга и подобных и измерить численно
Самые базовые метрики такого рода – crash-free и anr-free. Уж на них-то так или иначе наверняка все смотрят
Очень замечательные удобные великолепные метрики. Однозначно видишь самые частые проблемы (по крайней мере креши, с ANRами чуть хуже). Есть как минимум стектрейсы, а то и ещё что-нибудь. Чинишь – и метрики растут
Из-за такой их простоты, измеримости и однозначности очень просто упороться только по ним и не уделить внимание всему посложнее
Знаю о чём говорю, у нас в хороших релизах crash-free 99.97%, ANR-free – 99.94% ;)
По данным GP. Тут надо помнить, что разные системы показывают разное, смотря что они считают пользователем, устройством, сессией и что на самом деле считают
А вы где в первую очередь смотрите?
Мы часто смотрим в FireBase, смотрим в AppMetrica при разборе крешей (там есть события аналитики, можно что-нибудь из них вытащить про сценарий) и смотрим в Google Play (там ANRы, хоть как-то читабельные системные нативные креши, и на метрики отсюда ориентируемся)
Очень замечательные волшебные изменения в UI консоли гугл плея в этой части. Раньше можно было на любое место записи о креше нажать, чтобы к информации о нём перейти, теперь только на стрелочку. Раньше было хоть какое-то форматирование стектрейсов, теперь одинаковый шрифт везде
Интересно посмотреть на графики, как массово по всей индустрии стабильность падает в результате. Чуть менее удобный инструмент, чуть реже кто-то зайдёт посмотреть, что там с крешами, и вот уже у пользователей андроида не раз в неделю что-то падает, а два раза. Или три
И вот он уже айфон покупает, да-да. А всё потому что шрифт стектрейсов в гугл консоли хуже стал
Самое неудобное с крешами – у нас их так мало, что почти все оставшиеся в бете если и стреляют, то очень не понятно. Вот стрельнул он 1-2 раза, и угадывай, это пользователь особенный и больше таких не будет или по мере раскатки вырастет пропорционально
У нас тут нет каких-то жёстких границ, но общее правило – релиз не едет с новыми крешами, заметными на общем фоне. Релиз едет с новыми редкими крешами, но их планируем в работу и чиним
Иногда кажется, что вот этот новый креш слишком редкий, чтобы тратить на него время. Но срабатывает логика, что если оставить этот слишком редкий, а потом следующий и следующий, они накопятся и дадут значимое ухудшение стабильности
В какой-то мере мы тут заложники накопленного качества, на фоне которого всё видно и на всё обращаешь внимание
Но не crash- и ANR-free едиными. Когда научились хорошо контролировать эти метрики – стали смотреть, чего бы ещё полезного поконтролировать
Логичный следующий шаг (хотя не обязательно и следующий) – перфоманс
В Яндексе для контроля перфоманса используются внутренние инструменты. Их разрабатывает и поддерживает другая команда, так что я тут не буду вдаваться в детали, показывать скрины и пр, наверняка ребята сами где-нибудь рассказывали или ещё расскажут
Мы тут выступаем в роли потребителей
При работе с перфомансом есть два дополняющих друг друга подхода – перфтесты, чтобы узнавать заранее, и мониторинги, чтобы реагировать постфактум
Главный принцип – сначала учимся измерять, потом пытаемся улучшать. Иначе все улучшения нивелируются следующим же коммитом, автор которого даже не знает, что что-то ухудшил
Про это год назад на аппсконфе рассказывали youtube.com/watch?v=IOtCXz…
У нас уже довольно давно есть некоторое количество метрик для мониторинга – время запуска трека, открытия ключевых экранов и подобные. Но мы не то чтобы хорошо умели их интерпретировать, просто прокрасилась метрика – надо что-нибудь когда-нибудь посмотреть. Наверное
В этом году начали разбираться глубже и учиться с этими метриками нормально работать. До прям качественной и эффективной работы ещё далеко, но чему-то уже научились
Например, большим челенжем было корректное измерение времени запуска приложения. Решение в лоб – засечь время где-нибудь в начале Application.onCreate() и зафиксировать результат при отображении главного экрана – даёт очень много мусора
Например, приложение запустили не по иконке, а кнопкой на наушниках, из плеера в нотификашке или из виджета. Замер времени начался. Через пару часов запустили UI – главный экран отобразился. Время запуска приложения – 2 часа
У нас прям значимое количество таких замеров случалось, так что никак с пользой метрику не получалось применять: даже если что-то сломается и приложение станет запускаться значимо медленнее, на фоне мусора это ухудшение не будет заметно
Нам подошло решение с двумя метриками – одна от первого статика Application до завершения Application.onCreate(), другая – от первого статика главного экрана до завершения его отрисовки
После этого увидели, например, что у небольшого количества устройств с Android 10 приложение может сильно дольше обычного запускаться
С перфтестами мы пока не подружились. Довольно много факторов нужно учитывать, чтобы получить из них полезную информацию: запустил в немного других условиях, и вот уже метрика красится не из-за того, что что-то в коде изменилось, а потому что условия не те
И ещё они покрывают только известные сценарии. Если перфоманс проседает в каком-то непредусмотренном корнер кейсе – заметить это получится только в проде
Однажды в другом приложении неделю разбирался, почему у 10% худших по производительности девайсов на 10% просел fps при скролле
Вот до такого уровня мы пока не дошли, хотя чему-то уже научились
На этом тред заканчиваю. Успел рассказать не так много, как хотел, но пришлось ещё и поработать. Спасибо за внимание и до завтра!
Пятница
Сегодня о том, как люди решают, чем заниматься, с какими проблемами при этом сталкиваются и какие инструменты можно попробовать
В общем, тред с материалами, найденными на фоне личных переживаний, что столько всего хочется сделать, но из этого всего нужно что-то выбрать, а остальное не выбрать
Начну с зависти к главной героине The Queen's Gambit, которая точно и с детства знает, чем хочет заниматься
В реальной жизни такое если и бывает, то, скорее, не является нормой
Согласно исследованию LinkedIn, 75% людей в возрасте 25-33 лет сталкивались с кризисом четверти жизни, и у большинства из них он включал вопросы о том, чем же таким заняться. Треть в результате сменили сферу работы
Вот пруфы news.linkedin.com/2017/11/new-li…
Ладно кто-то там с линкедина. Чайковский, который Пётр Ильич, успел выучиться в училище правоведения, послужить в Министерстве юстиций, и потом только опомнился и ушёл учиться в консерваторию
Почти "войти в айти" XIX века
При таких решениях подстерегают всяческие когнитивные искажения. Главное – мы неправильно представляем, как это, быть тем, кем мы хотим быть
Условно, когда кто-то мечтает быть известным актёром, вряд ли он представляет себе преследование безумными фанатками и невозможность спокойно на улицу выйти. Есть какой-то образ результата, но не реальное знание о нём
Мне кажется интересным следующий подход, чтобы как-то эту проблему обойти. Нужно письменно сформулировать, как должен выглядеть твой обычный день, когда ты достигнешь намеченный результат. Не образ "ну я там известный влиятельный богатый и меня все любят", а вот проснулся – где?
...После этого делаешь – что? И не день, когда тебе Оскар вручают, а обычный, рядовой день
Уже на этом этапе становится непросто, я, например, уже несколько месяцев пытаюсь как следует это сформулировать, и хоть и продвинулся, но не до конца
Дальше можно собрать какую-то информацию и прикинуть, насколько получившийся образ реалистичен. Такой вполне продуктовый подход и дешёвая проверка гипотезы. Лучше тут заранее понять, что выбранное направление приведёт к двиганью вьюх и перекладыванию джейсонов
...а не прорывным технологиям и нахождению на острие. За месяц общения к теми, кто знает, а не через 4 года ВУЗа и пары лет работы
Важная фишечка всего этого – образ идеального дня не вечный. В течение жизни его наверняка придётся пересматривать
Во-первых, даже проведя предварительные исследования, ты точно не узнаешь, как оно там, после достижения цели. И в реальности наверняка окажется не совсем как думал
Во-вторых, среда меняется. Захочешь сейчас в разработку, получишь образование, начнёшь работать, а там уже квантовые компьютеры, нейроимпланты и программирование силой мысли
В-третьих, ты сам меняешься, меняются ожидания, стремления и всё такое
Так что может оказаться, что всё пора останавливать, придумывать заново и идти в другую сторону. Или, наоборот, раньше времени можно оказаться в тех самых условиях, которые были нужны, и идти больше никуда не нужно
Только всё равно это не насовсем, и через какое-то время опять что-то изменится и опять придётся выписывать, чего такого теперь хочется поделать
Итого:
– всем приходится решать, чем заниматься
– менять эти решения в течение жизни для большинства нормально
– это можно делать более осознанно и лучше готовиться
– важно формулировать честный образ, как оно будет
– образы придётся корректировать по мере получения опыта
Суббота
В начале недели давал ссылки на пару книг по теме. Сегодня соберу небольшой список, что можно почитать связанного с темами недели, около них и не около
В понедельник мы говорили о том, как работает музыка. Я читал про это тут play.google.com/store/books/de… и тут play.google.com/store/books/de…
Не могу сказать, что эти книги – восторг, но вместе дают неплохое представление о теме
Только сейчас заметил, что в названии второй упоминается Арнольд Шёнберг. Послушайте, как непривычно он звучит music.yandex.ru/album/9784328
А о том, почему так, из этих книг можно узнать
В том же духе, но про математику, а не музыку
Причём эту прям рекомендую. Ещё и про околоматематические идеи, например, как Аристотель стал базой для христианства
play.google.com/store/books/de…
Вчера упоминался Чайковский. Я читал вот эту биографию, но где взять её электронную и легально – не знаю
ozon.ru/context/detail…
Про развитие технологий, автоматизацию и автономность – очень отличная Army of None. Не смотрите, что она про оружие, идеи хорошо перекладываются на другие сферы
play.google.com/store/books/de…
А два года назад её рекомендовал Билл Гейтс, вот его ревью gatesnotes.com/Books/Army-of-…
Про вертикальные фермы – книга от автора самой идеи play.google.com/store/books/de…
Воскресенье
Ребята, я побегал
@mobileunderhood Кому интересно почитать с точки зрения физики — гуглите задачу Коши и формулу Даламбера. https://t.co/ScSYyomOUn
На этой неделе мы говорили о том, как работает музыка twitter.com/mobileunderhoo…, а @iamizzypizzy добавил подробностей про физику струны twitter.com/iamizzypizzy/s…
Сегодня четверг, и по плану у нас разговор про стабильность приложений Это своего рода продолжение позавчерашней темы про релизы – там мы выстраивали процесс, чтобы при раскатке всё было ок, а сегодня обсудим, что это за "ок" и как на него смотреть
Обсуждали релизный процесс twitter.com/mobileunderhoo… и стабильность twitter.com/mobileunderhoo… мобильных приложений
В том числе провели несколько опросов и посмотрели, какие подходы чаще используются
Сегодня ещё один день не про мобильную разработку. Расскажу про технологии, за которыми слежу, которые жду и в которые верю. Или не верю, но хотелось бы
Фантазировали о развитии технологий, не связанных с мобильной разработкой, и возможных проблемах с ними twitter.com/mobileunderhoo…
Сегодня о том, как люди решают, чем заниматься, с какими проблемами при этом сталкиваются и какие инструменты можно попробовать
И принимали решение, чем заниматься twitter.com/mobileunderhoo…
В начале недели давал ссылки на пару книг по теме. Сегодня соберу небольшой список, что можно почитать связанного с темами недели, около них и не около
В конце собрали немного дополнительной литературы по темам, если вдруг хочется разобраться подробнее twitter.com/mobileunderhoo…
Писать в твиттер оказалось проще, чем я думал, в плане формулирования текста и нажимания на кнопки
Но в плане поиска тем, в которые интересно и рассказывать, и читать, – совсем не проще
И уж совсем не представляю, что бы я тут успел написать, если бы не отпуск половину этой недели. Может это дело привычки, но пока и работать, и твиттить параллельно кажется невозможным
@aarexer ты как на прошлой неделе, много поработать успел?
