Привет коллеги! С вами Денис Кириллов. Руковожу iOS разработкой в Mamba. Суммарно проработал в IT 15 лет. Успел покодить на множестве мобильных платформ: Symbian, WP, Android, Tizen и Bada. Остановился на iOS. Плавно перетекаю в менеджмент.

Mamba крупнейший dating серивс на территории СНГ. Основан в 2004-ом. Доступен на iOS, Android и Web. Первое мобильное приложение вышло 2009-ом. Сейчас более 40 мил. пользователей. Тех. департамент - 70 сотрудников. Мобильный отдел iOS/Android - 12 человек.

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

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

Первый раз о том как делать оценку я всерьез задумался когда искал работу на lead позицию. Поводом стал вопрос на финальном этапе собеса в успешной отечественной компании. К тому времени я прошел несколько кругов ада и оставался последний, - встреча с CEO.

На собесе СEO задал вопрос: «Представь, надо сделать Instagram, есть два iOS-ника и готовый backend. Сможешь за 4 месяца сделать готовый продукт?». Замечу, что это происходило примерно лет 7 назад и инста еще не была такой навороченной как сейчас.

Поёрзав на стуле я осознал, что не могу дать однозначный ответ. Сказать «да» и получить офер на проект с которым придется ночевать предстоящие 4 месяца или сказать «нет» и уйти с позором?… Оба варианта были "такое себе" и я решил ответить честно - «Не знаю».

После был ожидаемый вопрос: «Сколько времени нужно?». Терять уже было нечего и я решил импровизировать, ответ был примерно такой: «6 мес. с вероятностью больше 60%, 12 мес. с вероятностью до 90%». Через пару дней мне неожиданно пришел офер.

От создания альтернативы Instagram’а я тогда отказался и офер не принял, но сама история оказалась ценнее и стала уроком на всю жизнь. Если не знаешь как оценить, а отвечать нужно сейчас - говори вилку и указывай вероятность.

Нельзя давать оценку «с потолка». Ваша оценка это обещание от выполнения которого зависит ваша репутация, если не хотите чтобы вашу репутацию тоже оценивали «с потолка» относитесь к оценке серьезно.

Для оценки проекта или killer-фичи с бюджетом в пару-тройку годовых окладов разработчика, привычные методы как Scrum-покер, карточки с размером футболок или dot-point’ы не применимы. Понадобятся более скучные, но весьма эффективные методы.

Лучшим источником информации по методам оценки для меня стала книга С.Макконнелла «Сколько стоит программный проект». В ней подробно описано 9 методов для проектов разного масштаба и разных по кол-ву сотрудников команд. Есть из чего выбрать.

Оптимальным считаю метод «Сводной оценки». Он более других подходит под реалии мобильной действительности, учитывает объемы задач и размеры команд. О нем можно прочитать в 10-ой главе. Если вам интересна тема читайте всю книгу целиком, не пожалеете.

Первый раз, эксперимента ради, я применил «Сводную оценку» когда участвовал в проекте разработки оф-ого iOS приложении для Олимпийских игр в Сочи. Получилось ~2500ч/ч с вероятностью 80%. По факту вышло чуть более +10%. Повезло подумал я и решил продолжить.

В Mamba мы применили «Сводную оценку» для проектов: Anonymous dating, GreetUp, Luster и Wamba. Брали оценку с вероятностью 75% и по факту получили: +27%, +30%, +37%, +14%, т.е. в среднем +27%. Оценивалось и считалось только время разработчиков нашего отдела.

По многочисленным просьбам ссылка на оригинальное издание amazon.com/Software-Estim…

Хорошо это или плохо когда оценка дает +30% по факту? Ответ: "Хорошая оценка должна в 75% случаях отличатся от фактического результата не более чем на 25%." (Conte, Densmore, Shen - Software engineering metrics and models).

Оригинальное издание Software engineering metrics and models amazon.com/Software-Engin…

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

Отправляйтесь в магазин с суммой не превышающей оценку. Повторите несколько раз. Узнаете какой из вас оценщик и сможете почувствовать себя на месте owner’а вашего проекта. Эмоции гарантированы.😀

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

Защитное программирование, тесты, remote toggling и stage-релизы повышают стабильность приложения, но не дают 100% гарантии его работоспособности в руках у пользователя. Мониторинг - последний рубеж обеспечения стабильности.

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

Пример эпичного факапа: Релиз приложения успешно прошедшего тесты без кнопки Войти на онбординге. Как @@@ть?! Просто. Белый экран, белый шрифт и неудачный merge с конфликтом в названии файла текстуры для фона кнопки. Тест кнопку видит, пользователь нет. Такие случаи не редкость.

Ситуации когда что-то пошло не так, но не крешится можно обнаружить собирая статистику по завершению user-stories и сравнивая их с ожидаемыми значениями. Причем собирать стату лучше не только с клиента, но и с сервера трекая вызовы API.

Хочется обратить внимание, что к аналитике нужно подходит с умом и заботой о пользователе. Когда 90% трафика - это аналитические события, то это стрёмно. Как минимум на плохой сети или роуминге. Так что откладывать каждую кнопочку десятком событий не надо. twitter.com/mobileunderhoo…

Плюсы в сборе статистики на стороне API: экономия трафика, не падающая производительность клиента, экономия времени мобильных разработчиков, возможность мониторить события не зависящие от клиента.

Основной минус сбора статистики на стороне API: не возможность покрыть все существующие user-stories клиента.

Must-have для мониторинга мобильного проекта, события не зависящие от клиента: валидация платежных транзакций в AppStore/GooglePlay, доставка push-сообщений, рассылка SMS-кодов для подтверждения аккаунтов по телефону.

Если хотите мониторить свой API сервак, обратите внимание на готовые решения. Писать самому скорей всего будет уныло.
Мы юзаем Prometheus для сбора данных и Alertmanager для конфигурации предупрежедний. prometheus.io

Данные собранные Prometheus вкуснейшим образом визуализируются в Grafana. Куча настроек и очень красивые графики. Ясен пень что не бесплатно. grafana.com/grafana/

Альтернатива open-source проект Kapacitor. Овер-навороченный. Имеет механизм выявления аномальной активности который обнаружит проблемы которых вы не ожидали. influxdata.com/time-series-pl…

На стенах офиса висят ЖК панели с ротацией графиков текущих показателей. Если что-то ломается это замечают все. На критических порогах начинается SMS рассылка тех. лидам.

Сегодня среда и сегодня будет подгорать🔥. Тема дня: «Деструктивные кадры». Обсудим поведение людей (не)осознанно наносящих урон проекту. Все описания приведеные далее вымышленны, а совпадения с реальными людьми совершенно случайно.

№1 «Человек с флагом». Сотрудник отчаянно несущий свет истинной архитектуры в темные души доверчивых коллег. Наносит значительный урон коду который усиливается с каждым пройденным ревью. Будучи побежденным сливается с проекта нанося максимальный урон оставшимся legacy.

Эффективно противостоять «Человеку с флагом» может только закаленный в архитектурных боях team-lead или группа синьеров по предварительному сговору.

№2 «Астронавт архитектуры», некогда получивший классификацию в культовой статье Джоэла Спольски "Don't Let Architecture Astronauts Scare You" joelonsoftware.com/2001/04/21/don…

«Астронавт архитектуры» не наносит прямой урон по коду, но распространяет вокруг себя чары призывающие истинную архитектуру, нанося тем самым урон по всей области отдела. Часто выступает в качестве саппорта для «Человека с флагом».

Слабое место «Астронавта архитектуры» отсутствующий или перманентно не работающий код. На дух не переносит упреки о затягивании сроков. Может быть побежден предложением вначале реализовать задуманную архитектуру в собственном pet-project’е.

№3 «Случайный пассажир», не заинтересован в проекте, задаче и вообще ни в чем. Наносит средний урон кодом работающим на костылях и только до первого изменения. Использует защитное заклинание «ну я это пофикшу сейчас». Уходит на больничный получив серию реджектов на ревью.

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

№4 «Диверсант», действует скрыто не привлекая внимания. Особо опасен. Наносит точечный урон пряча прямые обращения по индексу к элементу массива в хорошо замаскированных частях кода. Не будучи обнаруженным может наносить критический урон в релизах.

«Диверсант» не может противостоять адептами защитного программирования. Обнаруживается статическим анализатором и внимательным ревьюиром. Исцеляется регулярным чтением книг типа «Совершенный код» С.Макконнелла или «Чистый код» Р.Мартина.

№5 «Домохозяйка». Заглянув в код незнакомого класса наводит идеальный порядок, растравляя переменные и функции в нужном порядке, попутно их переименовав. Вызывает панические атаки на ревью и часовые merge-посиделки. Лечится отключением key-биндов на функции рефакторинга в IDE.

№6 «Стрелочник». Является при нахождения кем-то его бага в релизе. В упор не признает существование проблемы и как следствие причин для ее устранения. Отправив коллег отлаживать глючный компилятор в тихую фиксит свой баг. Встает на путь исправления узнав о команде "git blame".

Заметив кого-то из «Деструктивных кадров» помните, что большинство действует несознательно. Позитивный подход, взаимовыручка и душевная беседа часто решают подобные проблемы в команде.

Страшилка на ночь: В темном, дремучем backend’е, работал хмурый разраб. Каждую ночь он оставался в офисе и искал баги. Но не заводил на них тикеты, а отправлял их в Bug Bounty чтобы получать за них бабло. А когда баги кончались, он садился и делал новые... 👻

Вчера было весело, спасибо всем за позитивные отзывы! Кто-то даже прислал свои «Дестркутивные кадры», я их чуть позже кину в тред. Сегодня хочу продолжит в конструктивном ключе и обсудить возможные причины того почему люди начинают хейтить свои проекты.

В начале опрос. Какой из факторов заставит вас хейтить проект раньше (свои варианты кидайте в коменты):

Однажды на вопрос почему увольняешься, я услышал ответ: «Крыша потекла». Ирония судьбы заключалась в том, что топ-мега-синьеру который проработал несколько лет и залатал в проекте множество дыр, действительно с потолка капала вода на стол.

Многообразие внешних проблем бесконечно, а в контексте IT, это уже бесконечность в квадрате. Нет способа решить все, но есть способ изменить свое отношение к происходящему.

Сейчас на каждом углу говорят про эпидемию проф.выгорания в IT среде, компании покрупней нанимают «Директоров по счастью» и отправляют сотрудников на недельные тренинги. Все это гуд, но охренеть как сложно.

Стоит прочитать каноническое определение синдрома проф.выгорания и сразу становиться не по себе. Всего 14 стр, очень страшно, можно даже не уснуть потом. Эмоциональное выгорание с позиции экзистенциального анализа. А. Ленгле. laengle.info/userfile/doc/B…

Эйнштейн как-то сказал: - Вы думаете, все так просто? Да, просто. Но совсем не так.

Что-то заставило нас разобраться с глюкам XCode, лагающим AutoLayout, костылям для UICollectionView и жизненным циклом Activity. Полагаю это была цель, своя для каждого, но решающая одни проблемы.

Найти цель, поверь в нее и остальное уйдет на второй план. И возможно когда в следующий раз «потечет крыша» проблему удастся решить просто подвинув стол.

№7 «Ходоки». Паразитируют умением манипулировать сознаем жертвы. Согласившись однажды помочь «Ходоку» жертва невольно попадает в ловушку ответственности и начинает выполнять чужие задачи. При попытке бегства активируется чувство вины заставляющее жертву вернуться к хозяину.

Защититься от «Ходока» можно ритуалами персонального тайм-менеджмента или заклинанием вроде «я помогу тебе когда освобожусь» и «я должен завершить текущую задачу чтобы обдумать твой вопрос».

№8 «Копирайтер». Свято верит что ценность кода измеряется кол-ом строк и созданных классов. На каждый атом логики создает свой Interactor, а все флаги раскладывает по отдельным Storage’ам. Непобедим, по причине того что его код всегда работает. Останавливается когда устает.

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

Набрав за воскресение 1% апдейтов на 1-ом stage’е и проверив метрики утром в понедельник мы имеем бодрую команду в полной боеготовности и возможность переиграть планы по недельному спринту не дергая людей на хот-фиксы.

Роль релиз-менеджера мы заменили самодельной системой Deploy. Она позволяет в пару кликов собрать релиз из готовых задач и отправить его в Firebase Beta, AppStore или Google Play.

Deploy предупреждает о merge-конфликтах, автоматически детектит и отправляет на перевод ресурсы для локализации на 34 языка. Работает сразу для front/back(end) и mobile.

Когда мы начинали адаптировать комплекс Deploy для мобильных проектов, я не верил, что это вообще возможно. Теперь не представляю как без этого жить и знаю почему DevOps’ы получают дохрена бабла, а некоторые потом становятся CTO.

Если не знаете как скоротать вечер, можно послушать доклад о чудесах реализации системы Deploy от нашего CTO с FanCorp DevOps Meetup. Под винишко норм заходит. youtu.be/mnLWnFvNqy4

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

На кону три мягких и уютных полотенчика с логотипом Mamba.ru. Оставляйте свою шутку о mobile-индустрии в коментах к этому посту. Завтра в 12:00 жюри Мамбы выберет трех самых шутников, которым мы отправим новый полотенчик по почте. Топ-шутки выйдут на репост. pic.twitter.com/QsHf5ir8xr

@mobileunderhood Моя девушка: Вау, ты мобильный разработчик? А напиши что нибудь крутое для меня.
Я: Пишу приложение, которое трекает геолокацию и вызывает такси через 2 часа после того, как она приехала ко мне
Моя девушка: pic.twitter.com/KWgzn5rhrv

@mobileunderhood Когда собирался стать мобильным разработчиком.

Ожидания: мне понадобятся алгоритмы, глубокие знания языка и платформы, понимание БД, различные фреймворки, постоянно что-то новое.

Реальность: парсишь json'ы и отображаешь данные в списках.

@mobileunderhood Заказчик: мы тут ключи для подписи приложения посеяли. Вот предыдущий подписанный apk файл. Сможешь ключи по подписи восстановить?
Я: 😳(один мой глаз вываливается и катится по полу)
Заказчик: я уверен, ты справишься 😉

@ufa_iskhakov @mobileunderhood Я: сожалею, но это технически невозможно. Заказчик: а нам вас рекомендовали как хорошего специалиста.

@v1sarRU @mobileunderhood Apps are just pretty pictures of JSON (c)

@mobileunderhood pic.twitter.com/GovLShDnDY

Друзья, спасибо всем кто принял участие в конкурсе, было весело! 🥳 По решению жюри и кол-ву ваших лайков, обладателями уютных полотенчиков от Мамбы становятся:
Dmitriy M. /@v1sarRUU, Tim Ruslanov /@alectogeekk,
Ruslan Iskhakov /@ufa_iskhakovv

Сегодня мой заключительный день на канале и я предлагаю всем напоследок оторвать взгляды от созерцания JSON в обертке UICollectionView/GridLayout и окунуться в размышления о светлом будущем мобильной индустрии. Тема дня: «Что дальше Илон?»

Моб. gamedev всех порвет и станет более лакомой специализацией для моб.разработчиков чем прикладной. Произойдет это за счет развития игровых движков, снижения порога сложности на входе и очередных рекордов игроделов с миллиардами прибыли.

Когда я зашел в gamedev в 2009-ом, получив заказ на 2D аркаду. С движками под iOS было туго, Cocos2D rc_0.98 и Unity с одним тутором в доке, лицензией за 1500$ и глючным Mono под капотом. Сделав пару проектов я понял, что далеко с этим не уехать и свалил в прикладную разработку.

Сейчас спустя 10 лет на Unity выходят такие монстры как Hearthstone и Call Of Duty: Mobile. Последние сегодня отчитались о 35 мил. загрузок на iOS за 72 часа после запуска, без учета китайской аудитории. COD: Mobile выглядит невероятно навороченной и она на Unity черт побери!

Сравнивая прошлое с настоящим, уверен, что на мобильных gamedev разработчиков будет расти спрос. Даже у нас в РФ, где такие вакансии большая редкость. Удачи вам и терпения любители мобильного gamedev'а!Пока не пейте пиво вместо лекций по линейной алгебре, вдруг еще пригодится 😀

Модульная архитектура станет стандартом. Сложность растет и дешевле всего решать связанные с ней проблемы принципом «Разделяй и властвуй». Плюс модульность дает: оптимизацию на сборке, возможность шерить фичи и разбивать команды на специализированные и более эффективные unit’ы.

Декларативный UI и Unidirectional DF переживут еще не мало холиваров. Они точно будут, но сложно сказать какими в точности. Вечный спор между «обещающим новым» и «проверенным старым» в большинстве заканчивается где-то между. Как говорит мой друг @gnuman23 «Запасаемся попкорном!».

P.S. По случаю решил реанимировать свой старый twitter: @mrcryf0x, веллкам. iOS-ники приходите на мой доклад «Темные уголки iOS Auto-Renewable Subscription» на Mobius Winter 2019, поделюсь опытом создания механизма платных подписок и расскажу о том, что не дописали в доке.

Всем привет, меня зовут Роман и я Android разработчик из компании Redmadrobot, или как ее иногда называют RMR. Для тех, кто с нами не знаком, мы занимаемся разработкой современных цифровых решений на заказ.

При разработке мобильных приложений, мы делаем всё, от бизнес-анализа и проработки UI/UX до полноценного QA. В топе мобильных команд мы обычно в топ-3/топ-5. Еще у нас есть штуки на основе ИИ, полноценная дизайн-студия, back-end практика и много чего ещё.

Вообще в RMR уже 600 роботов, работающих в 8 офисах в РФ и за рубежом. Так уж получилось, что я не считаю себя специалистом в какой то конкретной области, поэтому будем пытаться вести диалог на разные темы;)

Ну и так как это твиттер канал мобильной, а не Android, разработки, я не буду глубоко уходить в темы касающиеся конкретной платформы.

Расписание недели:

Как вы заметили, расписание только на 6 дней. По воскресеньям я обычно стараюсь не заниматься какими либо внешними активностями, поэтому давайте на него оставим открытую тему.

Ну что же, давайте начнем. Сегодня я буду рассказывать вам кто такие "Роботы" и как мы функционируем. Кстати, если у вас вдруг будут возникать вопросы на которые вы хотели бы получить ответы, то смело пишите.

Ну что, давайте немного про разработку :). У нас в московском Redmadrobot многим более чем один проект и это позволяет нам экспериментировать с различными новыми фишками платформ и индустрии не на прототипах, а на реальных боевых проектах.

Почти каждый раз после Google IO или WWDC мы берем что нибудь в ресерч и смотрим на сколько мы можем затащить это в новые проекты.

Так после Google IO 2017, в течении года мы полностью переехали на стек из Android Architecture Components и все новые проекты мы делаем на нем. Так же затащили в несколько боевых проектов новую навигацию.

Как уже говорил, мы очень любим экспериментировать со всем новым(а иногда даже старым), и в какой то момент, когда статьи и доклады о кросплатформенной разработке стали литься из каждого утюга, мы решили не оставаться в стороне и тоже разобраться в этом вопросе.

Был взят самый популярный на тот момент ReactNative, и пройдя через все стадии принятия, в конечном итоге положили в копилку уже несколько приложений на RN.

А после DevFest Kaliningrad 2018 на котором @ZviadKardava и @ShuregDenisov направо и налево расхваливали Flutter, я не смог устоять и посвятил свои новогодние каникулы ковырянию в нем. И таки шо бы вы думали? Мне зашло.

Да, на тот момент это был первый релиз, со своими косяками и проблемами, но в целом концепция мне понравилась. Хоть мы и не взяли пока Flutter в "большую игру", но мне лично кажется у него интересное будущее.

Кстати вопрос. Используете ли вы что нибудь, из того что сейчас популярно, для кросплатформенной разработки?

У нас в Redmadrobot, как во многих современных IT компаниях, выделяется время на развитие. Каждый может спокойно использовать это время на чтение или написание статей, исследовательскую деятельность или же какие то активности внутри отдела.

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

Наша самая большая активность связанная с образованием, это традиционная стажировка разработчиков, которую мы проводим обычно в начале года. Обычно она длится около 2х месяцев и чтобы ее организовать, многим приходится сильно попотеть 😄

Но не только же писать приложения и принимать очередную конву. Мы стараемся по возможности заниматься и другими активностями. Так мы порой участвовали в алгоритмических контестах, решали Kotlin coding puzzles и играли в CS 1.6.

Еще одна наша активности не связанная с написанием кода, подкаст от разработчиков Redmadrobot . Мы запустили его несколько месяцев назад и теперь после различных экспериментов будем выпускать выпуски более стабильно. dry.redmadrobot.dev

Сегодня поговорим о менторстве. Не могу сказать что я достиг в этом каких-либо высот, но почему бы не поговорить с умными людьми на интересующую тебя тему 😉.

И начнем день с небольшого опроса. Есть ли у вас в командах практика менторства?

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

Не стоит думать что ментор нужен только начинающему разработчику, хороший наставник не помешает на любом из уровней.

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

Сегодня тяжелый день, и сложно найти время что бы писать и сюда, но я все же еще попробую 🙂

Мне нравится заниматься менторством. Мне нравится все что связанно с процессами обучения. Да, это конечно отбирает время и силы, но в замен дает классный опыт. Важно понимать, что процесс обучения не односторонний и на самом деле учится не один, а оба человека.

На тему обучения есть много разной литературы, но не вся она хорошая. Буду благодарен, если в комментариях вы поделитесь хорошими ссылками по этой теме. Это могут быть книги, статьи или доклады. К примеру от себя могу назвать "Искуство обучать". Простая и довольно понятная книга

Небольшая история, которую я недавно вспомнил. Когда я только начинал свое путешествие в мир единичек и ноликов, я не планировал идти в мобильную разработку. Я самостоятельно изучал Java и планировал заниматься разработкой backend.

Естественно я не понимал и половины терминов, несколько раз бросал, но все таки собрал силы и за год просвятился на столько, что написал свой первый servlet. Только проблема в том, что этой технологией уже давно не пользуются.

И это естественно никак не приблизило меня к первой работе. Как такое произошло? Все просто, я изучал язык и стек технологий по книгам написанным, на тот момент, 10 лет назад.

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

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

Всем привет, сегодня поговорим о стартапах. Мне лично сильно импонирует формат стартапов. Сам до конца не понимаю почему. Вроде и впахиваешь больше, и процессы там часто налажены хуже, но есть в них что-то хулиганское, что раз за разом притягивает мое внимание.

Я, как разработчик, успел поучаствовать в двух стартап проектах, и не смотря на то что так и не стал миллионером, но за это время получил отличный опыт, сильно прокачался, и понял как делать не стоит.

Вообще как мне кажется стартап это неплохой вариант для первой серьезной работы, особенно с хорошим лидом. У меня такого не было 😄.

В то время я почти не спал, и все свободное время находился в поисках решений для проектов, за это время я неплохо разобрался в работе мультимедиа, и научился работать с UI так, что не хватаюсь теперь за голову видя какое то новое, нестандартное решение от дизайнеров.

Отношение к стартапам в России весьма не однозначное, поэтому хотелось бы узнать, какое мнение в целом у комьюнити. Как вы относитесь к стартапам?

Опрос показал что большинство опрошенных хотели бы работать в стартапе. А 19% имели негативный опыт работы. Я не могу назвать свой опыт совсем негативным, но сейчас я понимаю, что многие вещи мы делали совсем не так. В треде я попробую накидать что именно.

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

Мы не использовали никаких таск менеджеров. Это тоже казалось излишней, ненужной фигней. Мы же стартап, какие нафиг еще таск менеджеры? Но со временем мы начали путаться в задачах, факапить сроки и не понимали кто чем вообще сейчас занимается.

Как мне кажется ещё, не было четкого понимания для чего, а главное для кого мы делали продукт. Мы просто воодушевленно что то пилили, и думали что это будет крутая штука которая зайдет всем.

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

Зачастую стартап только на этой цели и держится, и даже не представляет, что дальше с этими инвестициями делать.

Еще не были четко распределены роли на проекте, а соответственно и зоны ответственности. Никто толком ни за что не отвечал, и все держалось в прямом смысле на честном слове.

У некоторых есть мнение, что стартап, это нечто что пилится на коленках, и сразу из говна и палок. Я с этим не совсем согласен. В первую очередь это зависит от людей которые его создают. В успехе стартапа, хорошая команда играет не меньшую роль чем хорошая и интересная идея.

А если люди привыкли лепить из говна и палок, то будут это делать и в стартапе, и на аутсорсе, и в продукте.

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

Завершая сегодняшний день, могу сказать, за время работы над стартап проектами, мне кажется я получил несколько нервных тиков и убил множество нервных клеток. Но есть и плюсы. Напроч отбило страх пробовать что новое и делать ошибки. Хотя может это вовсе и не плюс😉

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

Он будет писать на том ЯП который сможет лучше всего решить его прикладную задачу. Поэтому я считаю, что программист должен знать несколько ЯП. А что думаете вы?

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

Требования к разработчикам сейчас выше чем 5-6 лет назад. Если раньше, тому же junior разработчику достаточно было знать синтаксис языка и какие то базовые понятия программировани, то сейчас уже сложно с этим уровнем куда то устроится.

Большая проблема для меня это систематизация знаний. Держать все в голове нереально, хранить огромное количество закладок в браузере не удобно. Я пробовал разные инструменты пока где-то год назад не остановился на Notion. Пока он кажется мне самым удобным из опробованных.

Последний год, я стал составлять свой план развития на следующиие полгода. Это позволило не держать постоянно в голове цепочку статей/докладов/книг которые нужно прочитать/посмотреть. Пытался сделать из этого ещё и какую то базу знаний, но пока не вышло.

Вообще выписывать куда-нибудь все планы, идеи размышления, отличный способ разгрузить голову. Если мне приходит какая то идея, я записываю ее в специальную табличку, чтобы не думать о ней в фоне, и возвращаюсь к ней когда появляется время.

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

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

В качестве такого проекта, я какое то время пилил модуль для работы с камерой(в Android это еще то удовольствие) и потом использовал на паре проектов. На то время уже было пара популярных библиотек, но все они работали почему-то только с фото.

Потом увлекся работой с видео и начал эксперементы в этой области и это оказалось весьма увлекательно. Так как обработка видео до сих пор почти никак не реализована на уровне Android framework, это направление выглядит отличным простором для реализации.

Когда начал работать с видео на Android, понял что никак нельзя не погрузиться в NDK. Я, как и многие, поглядывал на эту штуку с опаской, но со временем понял что не так все страшно. Особенно по с сравнению с тем что было лет 6 назад.

Меня всегда привлекала backend разработка, и несколько лет назад, у меня появилась странная традиция. На новогодних выходных, я разворачиваю какой нибудь маленький backend сервис на каком то новом для себя языке, или framework'е и делаю небольшой REST API сервис с БД.

Пока быстрее всего получилось развернуться на Go. В целом язык выглядит крайне привлекательным.

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

Например я раньше, в свободное от работы время, плотно занимался всякого рода творческой деятельностью. Играл в группах, писал музыку и умудрился целый год поиграть в театре и поучаствовать в нескольких спектаклях 😁.

И все это дало прекрасный опыт общения с абсолютно разным типом людей, что часто помогает в работе.

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

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

Начал анализировать: зачем я курю, что испытываю при этом, и попутно изучал влияние курения на организм. Через достаточно быстрое время желание отпало само.

Есть пара хороших привычек которые я смог себе привить так же проводя разъяснительные работы со своим сознанием.

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

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

Сейчас я эксперементирую с кофе. Просто стало интересно как буду себя чувствовать если исключить из привычек пить его. Спустя месяц с лишним, НЕ могу сказать что все стало лучше, но просыпаться без кофе я в конце концов научился.

Моя неделя подошла к концу. Спасибо всем кто читал, и писал свои комментарии. Для меня это был интересный опыт. Напоследок оставлю пару ссылок по которым меня можно найти. Всем пока. 🤟
Twitter -@RomanChoryevv
Telegram - Roman_Zest
Наш подкаст -dry.redmadrobot.devP

В этот солнечный (в Москве) понедельник у нас замечательная новость – ЕЩЕ ОДИН КОЛЛЕКТИВНЫЙ ТВИТТЕР. Тоже для мобильщиков, но уже интернешнл. Ведется на английском, авторов будем искать по всему миру. Подписывайтесь!
@mobileclassify

Всем привет, меня зовут Екатерина Батеева и я iOS разработчик из Райффайзенбанка. Я много лет работала в автоматизации мобильного тестирования и подробно расскажу о ней на этой неделе.

План на неделю
1) UI тестирование
2) Архитектура мобильных автотестов
3) Рефакторинг приложения
4) Unit тесты
5) Немного расскажу о разработке в Райффайзенбанке и поговорим на свободные темы
6) Нестандартное тестирование

Пока день плавно приближается к обеду, начнем с небольшого опроса. UI автотесты "зверь" специфический - то они есть, то их нет. Расскажите есть ли они у вас в проектах

Часто замечала, что команды пишут UI тесты , используя живой бэк. По сути они пишут Е2Е тесты. Мой опыт показал, что стабильность у таких тестов низкая, а профит стремится к нулю. С тех пор я адепт мокирования. Но возможно у кого-то был позитивный опыт?

Поскольку в мобильном тестировании нет какого-то определённого фреймворка, которой можно выделить в стандарт, интересно узнать, какойфреймворк вы используете в ваших проектах

Всем привет. Сегодня вторник, поговорим об архитектурных аспектах автотестов. Начнем с паттерна Page Object. Я не большой его фанат для мобильного тестирования, но тем не менее он очень популярен. Статья для незнакомых с этим паттерном qa42.ru/ru/articles/11…

Для фанатов и хейтеров Page Object, а так же для всех, кто в поисках чего-то нового, предлагаю вам познакомиться с паттерном Screenplay. Он активно используется командами с BDD практиками, но это не обязательно, для его внедрения. habr.com/ru/company/arc…

Начиная с Xcode 9 появилась сущность XCTActivity, которая позволяет группировать шаги в тестах и оборачивать их в более читабельные описания. Сначала казалось, что это будет инструмент для BDD, но нет. Однако есть инструмент XCFit, реализующий этот подход github.com/XCTEQ/XCFit

И еще про один интересный инструмент, который только появился в последней версии Xcode → ХСTestPlan. Он позволяет удобно конфигурировать и собирать тесты вместе. Подробнее можно почитать здесь habr.com/ru/company/tin…

Сегодня поговорим про рефакторинг. Рефакторинг, как ремонт, нельзя закончить, можно только приостановить. При этом менеджеры часто не дают на рефакторинг времени и не видят в нем необходимости. Но и без него нельзя. Так когда и как начинать рефакторинг и когда приостановить?

@mobileunderhood Рефаторинг != Ремонт

Working Effectively with Legacy Code pic.twitter.com/XgGfV0OK2n

Однажды чуть не поссорились с подругой .net'чиком, из-за того, на какой строке писать else - на той же, что и скобка или на другой. На одном проекте удивилась отступами в два пробела. Насколько вам важен code style и используете ли вы официальный? Или другой? pic.twitter.com/qfyDrwD5FM

Отдельная боль разработчика — неиспользуемый код. Для swift есть очень интересный инструмент Periphery. Ссылка на него и подробный туториал link.medium.com/YaZXVjVXP0

Всем привет. Сегодня четверг, до выходных осталось совсем чуть-чуть. Начнем сегодня с небольшого опроса. Есть ли в вашем проекте Unit-тесты?

Однажды я была на митапе лидов, где каждый второй говорил о том, что Unit-тесты - пустая трата денег. Меня это очень возмутило и я решила найти материал показывающий пользу Unit-тестов. Относительно недавно вышла статья, в которой все грамотно расписано habr.com/ru/post/457632/

Ну и вопрос на ночь глядя. Многие считают, что Unit-test’в надо писать до написания кода. Правда есть теория, что хорошо бы писать unit-test, когда фиксишь багу — чтобы не повторилась. У кого-нибудь так получалось?

Простите, что бросила вас на день, релизы сами не пилятся. Исправляюсь. Давайте проведем вечер в формате вопрос-ответ. Сегодня готова рассказать про процессы, подходы, технологии и прочее в Райффайзен банке. Спрашивайте, что интересно, постараюсь всем ответить)

Если описать кратко, я работаю в проекте, который разрабатывает приложение для iOS для малого бизнеса. В моей команде ios-, android-, back- разработчик, два тестировщика, скрам мастер, техлид и продукт оунер. Работает по scrum с двухнедельными спринтами

В Москва невероятно теплый субботний день и мы поговорим о совсем нестандартном, странном и даже экстремальном тестировании. Начнем с доклада от Николая Козлова и Александра Хози про тестирование геолокации. youtube.com/watch?v=AiRGHj…

Еще один интересный доклад про необычное тестирование - тестирование подписок в iOS youtube.com/watch?v=NB-elB…

Ну и пришло время чего-то более хардкорного. Как-то я готовилась к лекции по ручному тестированию мобильного приложения и, когда читала про имитацию слабого сигнала, то увидела на stackoverflow потрясающую картинку pic.twitter.com/wMxMr1Wu5r

Всем доброе утро. Меня зовут Никита, android инженер из Авито. На этой неделе с Вами буду я и буду обсуждать те вещи о которых не так часто говорят, но часто задумываются.

И так друзья - примерное расписание:
Понедельник - токсичность
Вторник - Мудаки и как с ними работать
Среда - Взаимоотношения на работе
Четверг - Статистика и теория вероятности в жизни и карьере
Пятница - Собеседования
Суббота - Немного холиваров
Вск - work-life-balance

Ближайшие два дня я буду на appsconf, что в Питере, но я честно постараюсь не отставать от плана. Много кого сейчас тут? Отписывайтесь - возможно на большом кофебрейке пересечемся подписчиками @mobileunderhood . Лайк, шейр, репост

Поехали. Тема первого дня - токсичность.☢

Как сказал один мой добрый коллега - "Токсичности не существует, ее придумали мудаки что бы на х*й не ходить"

Я на самом деле лишь частично согласен с этим выражением. Однако хотел бы мудаков в нашей жизни и рассмотреть чуть позднее и отдельно. Лично я с токсичностью сталкиваюсь достаточно редко, однако судя по всему эта проблема существует. Когда последний раз с ней сталкивались?

Как сообщил в комментариях к предыдущему твиту @neikist - токсичность последнее время очень сильно форсится - как в статьях на медийных платформах, так и на конференциях. Я даже где то видел курс/тренинг связанный с токсичность. Не зря это слово стало топ-тренд в прошлом году!

@mobileunderhood То есть весь вторник про себя будешь рассказывать?

Наблюдал мнение о том что токсичный человек - тот что неуместно шутит, иронизирует или подкалывает Вас/коллегу публично. У меня на этот счет двоякое мнение - с одной стороны стоит радоваться - ведь Вы в дружная семье и коллективе, который можно даже назвать "друзьями".

С другой стороны, при отрицательной обратной связи, при отсутствии реакции (то есть отказа от своего тончайшего юмора) - это есть маркер того что в вашей команде завелся мудак. Ну о них мы поговорим завтра.

Может кто то еще добавит что то что *лично* он считает проявлением токсичности?

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

Смею предположить, что большая часть читающих наш твиттер представители it профессий. Однако на it инженерия не заканчивается. Кто нибудь когда нибудь работал в НИИ, на заводе или любом другом месте где есть похожая атмосфера?

@mobileunderhood Вот у нас есть токсичный дед-инженер. Он все время говорит что все кто не понимает его гениальности его изобретений - идиоты. Не принимает чужого мнения, а если начальство его заставляет советоваться с коллегами, то делает вид что слушает, а в конце просто говорит что совет говно

Воспользуюсь предоставленной мне властью.
Твиттер, коллеги, друзья и токсики. Не могу выбрать на какой доклад идти на аппсконфе. Я не буду знать сна пока не прослушаю обе эти животрепещущие темы, которые обязан прослушать просто каждый погромист, но в живую что то одно.

По рассказам моих бывших одногруппников (должен был работать с ним ЦНИИМАШ или Энергии) там все с этим отлично. Токсичности как таковой нет, есть строгая иерархия, никакого смузихлебства и ребячества. Все. Очень. Серьезно

Пошел на доклад про деньги. Было интересно и полезно. Думаю многим будет не лишним некоторым моим знакомым (хотя считать чужие деньги - такое себе).

Друзья, сегодня был насыщенный день, как ирл как и тут. За всего лишь день опроса выяснили что примерно половина либо не помнит либо не сталкивается с проявлениями токсиков (я с вами ребята!), остальные же с той или иной регулярностью таки сталкивается.

Мы так и ни хера не выяснили кто такие эти самые токсики, однако подсветили множество "маркеров" присущих этой группе. Добро пожаловать в тред ниже, лайк, шейр, репост.

Завтра я бы хотел рассказать и поделиться своими мыслями на счет мудаков, порой окружающих нас, кто они, что с ними делать и как быть. И замечание от меня - не каждый мудак токсик, но каждый токсик в той или иной степени - мудак.

Хотел бы сделать некий вывод и ремарку от себя той группе что страдает, хотя я и признаю что советы нонейма с интернетов врятле чем то помогут - друзья, будьте проще, живите с радостью и не имейте себе (!) мозги.

Я заметил что некоторые ведущие создают тред в формате вопрос-ответ. У меня есть сомнения в надобности этой штуки сегодня, однако пусть будет сегодня, в качестве эксперимента.

Всем доброе утро. Сегодня вторник - а значит время мудаков.

Мудаков можно разделить на два типа - временных и постоянных. Как вы понимаете практически все из нас порой бывают временными.

Кто узнал эту простенькую книжку - лайк. Ближайший день я буду делится моими наблюдениями на этот счет с частичным цитированием из нее.

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

Однако если проблемы возникают регулярно и общество от человека страдает, то это повод задуматься. Скорее всего перед нами "постоянный" или "сертифицированный" мудак.

Вдаваться в подробности не буду так как в кейсах ваше под понятиями "накосячить" и "проблемы", "страдает" - не вижу смысла, но вчера было множество предложений в которых фигурировали отличные примеры

Позволю себе цитирование из той самой книги:
//1. "Кто заслуживает называться мудаком? Многие используют это слово неизбирательно, применяя его к любому человеку, который раздражает, мешает или в данный момент добивается большего, чем они, успеха.

//2. Нам так же полезно уточнить смысл данного термина, отделив коллег и клиентов, которые вам просто не нравятся, от тех, кто действительно заслуживает такого определения.

//3. Это поможет различать людей, у которых не задался день («временных мудаков»), от постоянно недоброжелательных и вредных негодяев («сертифицированных мудаков»)

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

Саботировать процессы, мешать окружающим, заставлять себя чувствовать неловко или не приятно в окружении такого человека - все это можно делать с каменным лицом и без капельки токсичности

Одно из проявлений которые я бы выделил, то с чем я сталкивался - это ментальные свиньи. Те самые мудаки что срут окружающим им людям прямо в душу, не убирая за собой.

При чем каждый из нас порой так делает, сам того не замечая. Сильно повезет если мы заметим недовольство нами пострадавшим и постараемся прибрать за собой - тем или иным способом. Но не стоит забывать что есть те самые мифические интроверты все таки иногда существуют.

Что еще добавлю в это весомое слово - мудак? Тот самый перец что недавно разнес тебя на ревью - вряд ли можно назвать мудаком, без весовых на то причин. А вот коллегу что третий день подряд в микроволновке греет рыбу - определенно можно. Или все так и нет?

В одной маленькой и никому не известной компании когда на то на первом месте ценностей, на сколько я помню, было следующее - `don't be evil`.

И в этом что то есть на мой взгляд. Быть мудаком в такой компании будет просто сложно - тебе просто этого не позволят окружающие тебя люди. Возможно вы сломаете 1001 копье борясь с субъективщиной той или иной интерпретации добра и зла, но скорее всего оно будет того стоить.

Грустно, что принцип основанный еще в 2000 году, если верить гуглу (забавно вышло) Полом Бакхейтом недавно был смещен/заменен на более толерантный и проще модифицируемый в нужную, в случае возникновения проблем, сторону выгодную компании. Делайте правильные вещи, собственно.

В вашей компании есть какие либо похожие принципы, которые не позволяют клиническим мудакам комфортно себя чувствовать с вами?

@mobileunderhood Поэтому для этого существутет диалог - вот и все
Диалог описывающий правила игры, что позволительно в коллективе нашем, а что нет
И вот мудак - это тот, кто не играет по правилам

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

Слышал где то интересное явление/мнение, которое помогает "вжиться" в любой коллектив. Думаю многие об этом знают или слышали, или неосознанно использовали.
"Презумпция ума"

Надеюсь на ваши комментарии и фидбек на эту тему. Настало время уже выезжать на второй день конференции и продолжать развивать тему

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

В качестве идеи заключается следующее предположение - люди, наблюдающие порицательное поведение стараются так не поступать, зная что не хотят быть или ассоциироваться с таким человеком.

Если вкратце - исследователь наблюдал за поведением людей в двух разных ситуациях. Суть эксперимента - есть парковка, на которой сотрудники компании оставляют автомобили. Экспериментатор оставлял на лобовом стекле бумажку, от которой в большинстве случаев люди избавляются.

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

Во втором же случае, с чистой парковкой люди могли наблюдать именно то самое асоциальное поведение - в чистом месте сорить, насколько это отвратительно! Собственно как вы поняли на возникающем контрасте и явном проявлении "мудачества" люди значительно меньше сорили.

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

Тут можно пошутить на тему

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

Если я верно помню то вроде бы именно в компании Intel совершенно любой сотрудник мог вести спор с CEO/CTO. Отнесемся к этому просто как к кулстори в которой есть доля правды. За счет чего они смогли себе такое позволить?

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

"Спорьте так, как будто вы правы, но слушайте так, как будто вы не правы" © я не помню авторства, так что пусть будет Стейтем

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

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

Однако я очень хотел бы перечислить (читай - скопипастить) 10 принципов/правил которым стоит следовать дабы в вашем коллективе не появились проблемы, связанные с мудаками. Не со всеми согласен, однако на мой взгляд они стоят упоминания

1. Банальщина. Провозгласите правило, запишите его и действуйте согласно ему. Но если вы не сможете или не захотите следовать данному правилу, лучше вообще ничего не говорить. «Забыть» фальшивые декларации — меньшее из двух зол. Ведь вы не хотите прослыть лицемером

2. Мудаки будут нанимать других мудаков. Держите своих местных козлов подальше от процесса найма или, если это невозможно, вовлеките как можно больше адекватных людей в процессы собеседования и принятия решений, чтобы компенсировать пристрастие нанимать придурков похожих на себя

3. Крайние меры. Быстро избавляйтесь от мудаков. Организации обычно терпят слишком долго перед тем, как избавиться от сертифицированных и неисправимых мудаков. А когда наконец решаются на увольнение, реакция обычно звучит так: «Почему мы ждали так долго?»

4. Справедливость. Относитесь к сертефицированным мудакам как к некомпетентным сотрудникам. Даже если эти люди великолепно справляются со своими другими обязанностями, но постоянно унижают окружающих, нужно относиться к ним как к профессионально непригодным.

5. Испорченный добродетель. Власть порождает самодурство. Имейте в виду, что наделение людей, кажущихся приятными и доброжелательными, даже небольшими властными полномочиями может превратить их в крупных мерзавцев. Будьте с этим осторожнее.

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

Тут я добавлю от себя замечание - это тот самый момент где прозрачная иерархия и свободное конструктивное вертикальное общение - позволяют решать проблемы эффективней. В такой системе просто негде затесаться мудаку-начальнику/мудаку-подчиненному.

7. Управляйте моментом, здесь и сейчас, а не только процедурами, стратегией и системами. Эффективное управление мудаками означает сосредоточение усилий на изменении даже незначительных аспектов вашей и ваших сотрудников деятельности — вслед за этим последуют и крупные перемены.

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

Подождите, еще чуть чуть непонятной духоты - список нужно закончить

8. Моделируйте конструктивные конфронтации и учите людей правильно вести себя. Сформируйте организационную культуру, в которой каждый понимает, когда спорить, когда следует остановиться, собрать информацию, выслушать чужое мнение.

А когда надо перестать ныть и реализовать принятое решение (даже если с вами согласны не все).

9. Очень спорное, но достойное упоминания. Примените исключение из правила для одного мудака. Люди охотнее следуют правилам и нормам, когда существуют редкие или случайные примеры девиантного поведения.

Возможно кто то не согласится, однако все это дело работает в организациях, принимающих одного-двух придурков в демонстрационных целях. Эти обратные ролевые модели напоминают остальным о неправильном поведении.

Думаю на этом можно остановится. Выхожу из формата. Были ли когда нибудь похожие советы или подходы использованы вами жизни? Может наблюдали это в своей команде/компании? Расскажите о своем опыте

Всем доброе утро. Сегодня день взаимоотношений на работе.

По этому хотел провести сразу опрос. Очень странный и субъективный, но пусть каждый ответит как можно честнее.
Есть ли у вас среди коллег (в т.ч. бывших) друзья и если есть то сколько

Почему я не добавил значение больше 25? Да по тому что твиттер не позволяет и человек, даже самый общительный человек, который 24/7 общается с людьми, все равно не способен поддерживать, имхо, дружеские отношения с таким количеством людей

Дружеские отношения складываются, как я заметил, из следующих двух видов взаимодействий:

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

Что здорово во всем этом - с коллегами мы постоянно взаимодействуем согласно первому пункту.
Второе уже более индивидуально и требует особого подхода.

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

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

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

Так же интересный момент. Заметил что большое количество дружеских или же просто хороших долгосрочных отношений завязывается в местах скопления людей, позволяющим свободно группироваться по тому или иному признаку. Конференции, чаты, форумы - наше все.

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

Человек - социальное животное. Больше общайтесь, делайте добрых или не очень дел. Однако не всем это удается так просто.

Однако тема рассуждений психологических граней нас как индивидов крайне сложная. Откровенно говоря пока я готовился к этой неделе она мне показалось самой сложной и интересной.

Расскажите - какую литературу вы читали и могли бы посоветовать для нашей аудитории в контексте заведения хороших и долгосрочных отношений?

P.S. Про Карнеги думаю упоминать не стоит, иначе быть вам баянистом до скончания времен

Всем доброе утро. Сегодня четверг - по этому время статистики и теории вероятности в нашей жизни и карьеры.

Спойлер. Вся наша жизнь в словах Джигурды: youtube.com/watch?v=gj64tx…

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

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

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

Раз пошла тема советов той или иной литературы по данной теме - очень советую Голая статистика Чарльза Уилана. Автор с интересом подошел к объяснению тех или иных вещей происходящих в нашей жизни, в том числе рассмотрена тема лжи и манипуляции за счет статистики.

Так же порекомендую не менее интересную книгу "Антихрупкость" Талеба Нассима. Она возможно поможет обрести некий баланс в жизни при тех или иных выборах с которыми мы сталкиваемся каждый день. Ну и просто понаблюдать за мыслями интересного человека

Всем доброго времени суток. Сегодня пятница - значит время нашей любимой темы. Собеседования.

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

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

Всем Привет. Меня зовут Егор, я iOS инженер, на данный момент работаю в стартапе Prisma labs inc. На этой неделе поговорим про опыт работы над приложениями в различных сферах. Конечно, расскажу про нашу команду в призме и за тем немного задумаемся о будущем и настоящем мобилок :)

И так расписание на неделю:
ПН - Чем мы занимаемся в Prisma и какие технологии у себя используем
ВТ - Рассказ с полей работы над финтех проектом
СР - Почему в дейтинге так важен UI и как мы над ним запаривались
ЧТ - Какие проблемы в мобильной разработке существуют сейчас

ПТ - Есть ли в мобильной разработке инженерной будущее или так и будем таскать вьюшки по экрану до скончания времен
СБ - Конфы, есть ли в них смысл, почему так дорого?
ВС - Поговорим за жизнь, как переехал из Питера в нелюбимую Москву или думайте перед переездом

И так, начнём :) Как я уже сказал я работаю в некогда нашумевшем стартапе Prisma Labs inc. Мы создаём приложения для обработки фотографий на основе нейросетей. Первым как раз было приложение Prisma, как ни странно, оно превращало с помощью магии нейросетей ваши фоточки в картины

Но тогда меня не было на проекте и это тайна и история под завесой тьмы. Я же попал в Призму уже на другой проект «Lensa», являющийся сейчас нашим флагманом. Этот проект амбициозен как со стороны кейсов, так и со стороны технологий, применяемых в разработке.

Также меня затянуло и сильно подкупило то, что это стартап, на тот момент я работал в большой фирме. Где команда бэкэнд разработчиков была больше в 2 раза чем вся наша фирма вместе взятая.

Сейчас в нашей компании ~35 человек. И из мобильных команд:
Андройд 3 человека
iOS 4 человека

Под капотом из технологий у нас, не считая Swift/Kotlin, работают Metal/OpenGL, C++, ARMNeon, CoreML, Computer vision. Что даёт нам, наверно, возможность говорить что мы относимся к малому проценту мобильных приложений с таким количеством технологий🤘

Такой стек технологий породил в каждой мобильной команде породил необходимость разделения на под-команды: Core&Product. Что позволяет нам искать кандидатов под конкретные задачи, цели и технологии

Про команды:
Core-часть занимается разработкой алгоритмов на Metal/OpenGL, интеграцией нейросетей. А также ускоряют уже созданные алгоритмы, при помощи ARMNeon и C++

Product-часть встраивает эти самые алгоритмы, пишет обертки и UI. Тут у нас по-технологиям все максимально просто: CocoaPods$Swift 5.1❤️
Что там у Андройд не знаю :)

Забавный факт: 90% кандидатов думают чтобы к нам попасть нужно знать абсолютно весь стек, применяемый core-частью команды. Но это не так, никто в команде не заставляет насильно учить Metal и вот это все.

Но при этом это огромный пласт знаний, которые можно постичь. Например, сейчас мы всей iOS командой проходим курс по Computer Vision от FastAI. Это всем нам помогает вникнуть в специфику того как работает наш проект.

А ещё мы мечтаем, наконец, избавиться от границ между Core и Product, сделав каждого участника команды универсальным солдатом, который сможет полностью сам закрыть процесс написания алгоритма, его интеграцию и UI😃

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

Тоесть получив задачу далее разработчик сам общается с Аналитиками, Дизайнерами и, при необходимости, даже с СЕО. С одной стороны возникает проблема того, что разработчик не выполняет своих прямых обязанностей «писать код».

Но с другой за время обсуждения задача может 10 раз изменится и, возможно, что написано будет совершенно отличное от того, что планировалось в начале. Таким образом получается, что сэкономлено время на написание лишнего кода и, после обсуждений, имеется чёткая картина задачи

Это позволяет каждому участнику команды влиять на проект и не быть «винтиком», пишущем код. Для меня, например, это очень важно, поскольку это даёт ощущение, что это и твоё детище тоже. Осознавая это, начинаешь чаще задумываться над каждым своим шагом

Также у нас есть практика, что в любой день, любой участник команды может придти и рассказать как можно зарефакторить код и его идея подвергается максимальному питчу. И, если идея выдерживает процесс питчинга, то далее идёт уже процесс встраивания нового решения.

К техдолгу у нас особое отношение. Мы стартап, а в стартапе без него никуда. Но! Максимально стараемся его избегать и бороться с ним, к счастью, вся команда имеет понимание влияния тех-долга на стоимость разработки. Поэтому у нас всегда есть время порефакторить👨‍💻

Сегодня поговорим про финтех приложения pic.twitter.com/pEGZnbGRRM

Когда я шёл работать на проект, практически ничего не знал чем конкретно занимается фирма и только потом узнал, что это Форекс-брокер, мое лицо было примерно таким: pic.twitter.com/d2VfnX59Rh

На тот момент для меня это был моральный удар, потому что для меня «Форекс-брокер» было что-то вроде развода на вокзале

Но, после общения с коллегами и пары вопросов начальству, узнал об этом рынке очень многое:
1) Рынок очень жесткий, каждый брокер пытается очернить другого
2) Огромные репутационные риски, потому что много разводил

Так о чем это я, после общения моя совесть более менее успокоился и я стал спокойно работать, вникая в суть дела.

Самым интересным для меня стало то, что в разработке, связанной с биржей, самым важным является время с момента изменения котировки и до момента отображения на экране. И количество информации, зависящей от этого самого изменения

Так, вчера я продолбался и не успел рассказать все, что хотел. Постараюсь сегодня исправиться

Завершим истории про Финтех. Из-за такого ключевого параметра как время мы, например, юзали Protobuff со стримами, что за собой вело использование RxSwift. И в это время мы познали главную мантру «Everything is stream».

А также бизнес доверил нам очень многие расчеты на клиенте такие как например, Profit от стоимости покупки/продажи лота. Такая необходимость вызвана стоимостью отправки данных, в плане скорости.

А, да, чтобы предотвратить фразы типа «Сейчас 4G в каждом доме, о чем вы?». Наша фирма работала в Азиатских странах типа Индонезии, где связь сильно отличается от России

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

Ещё из интересных кейсов в какой-то момент мы стали думать о том, чтобы пинговать с телефона различные дата-центры, где будут располагаться наши сервера и подключаться к наиболее быстрому.

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

Кхм, всем привет, с Вами снова ваш покорный слуга. Итак: небольшие итоги финтеха. В моём опыте было много чисел и очень мало разработки UI, тоесть дизайн был очень грустным и бедным, из разряда «собери сам» и в общем-то всем плевать.

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

Что подводит к теме UI в дейтинг-приложениях, ух

Накидайте пока лайков те, кто работает над дейтинг приложениями. А заодно расскажите сильно ли Вас бьют дизайнеры палками за неправильные отступы

В моём случае это был один из российских сервисов, с довольно интересной историей. И, в отличие от финтеха, там был важнее UI нежели сами данные, надеюсь не надо объяснять почему😘

Но зато тут был другой момент: каждое UI изменение даже несчастный отступ обсуждалось столько раз, что уже невозможно было слушать

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

Это был единственный проект, где у наС Реально сидели UX дизайнеры, изучающие тонны информации поведенческих паттернов, реакции на те или иные цвета. Даже такие вещи, как радиус скругления кнопочек

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

В какой-то момент к этому прилагается огромное количество дейтинг сервисов на просторах сети.

Признаюсь, нас готовы были ушатать за каждый сломанный экранчик и кнопочку. Как-то раз один чувак сломал отступ кнопок на 20 поинтов и никто не заметил, конечно это был не я. И конверсия экрана упала процентов на 10% сразу после обновления

Сначала дизайнеры готовы были рвать и метать, но, буквально через день, выросла конверсия пользователей с девайсами версии Plus

Так, например, в приложении прошла череда A/B тестов на каждом экране, где замерялись положения и размеры каждой кнопки и какие действия они за собой вели

Я не берусь утверждать являются ли данные тесты на 100% верными, но сам масштаб на тот момент поражал

Всем Гуд Морнинг! Сегодня поговорим про проблемы в мобильной разработки с инженерной стороны. Расскажите чего вам не хватает в разработке, каких задач? Или красить кнопки ок?

Конкретно меня беспокоит то, что сейчас мобильная разработка стагнирует и что-то новое из подходов появляется очень редко☹️

За последние 1.5, наверно, года не появлялось ни одной новой крышесносной либы, фреймворка или подхода. Поправьте меня, если я неправ

Если повернуть немного в сторону голову, то мы видим бэкенды с их высокими нагрузками и зоопарком технологий, 70% которых в open source. Лично от такого у меня текут слюни

Всем привет! Меня зовут Дмитрий и сейчас я являюсь Android разработчиком в ABBYY. На этой неделе я поделюсь с вами своим опытом в мобильной разработке, но не забудем поговорить на свободные темы.

Немного о себе: в прошлом я 3.5 года отработал в продуктовке и 5.5 лет в аутсорсе, получал копеечку за собственное приложение в Google Play, отметился докладами на митапах и конференциях в НН.

План на неделю:
ПН - О продуктовке, аутсорсе и сторонних проектах
ВТ - Немного об архитектуре
СР - Всё, что нужно знать о RxJava
ЧТ - Android Graphics API
ПТ - Менторство
СБ - Есть ли жизнь в Нижнем Новгороде
ВС - Свободный день

Начнём с софт скиллов: учитесь дружить с заказчиком и принимать его решения, даже если они вам сейчас не нравятся. Со временем вы сможете отстаивать интересы друг друга в своих структурах, что пойдёт конечному продукту на пользу.

Бизнес-аналитика решает многое. Как наемный разработчик, вы не всегда можете разбираться в тонкостях бизнес-процесса заказчика и хорошо, если у заказчика есть люди, которые подробно описывают, а затем согласовывают требования. Нам остаётся только написать код.

Есть только одна причина написать код не по требованиям: когда тот же функционал в iOS приложении был написан до подготовки аналитики и его успели увидеть топ-менеджеры. В Android приложении должно работать точно также, даже если это неправильно ¯\_(ツ)_/¯

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

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

Чем старше становлюсь, тем больше ценю свободное время. Поэтому вопрос о подработке решается просто: хочу ли я попробовать что-то новое или могу это сделать на основной работе. Прошлая подработка закончилась тем, что я подсадил коллегу iOS-ника на реактивщину. Удачно вышло🙂

Что считать хорошей архитектурой? Года 4 назад я использовал связку Loader + ContentProvider + Service + MVC. Сейчас использую Clean + Rx + MVI. Изменились инструменты, но остался принцип наблюдения за данными, вокруг которого всё строится.

В Clean нам приходится связывать слои между собой. Имхо, LiveData слишком примитивный инструмент. Coroutines Flows стремится догнать RxJava, но становится таким же сложным инструментом. Где правда?

Продолжаем про Clean: для меня Repository является источником данных (получение событий изменения, снапшот данных на текущий момент, запросы на изменение), а Interactor - бизнес-логикой, связывающей источники данных. Но не все задачи имеют очевидное решение. Например, кроп.

Пусть у нас есть внешняя библиотека для обрезки изображений. Первая мысль - раз внешняя, значит переносим в Repo/Gateway и пишем однострочный Interactor. Но библиотека не запрашивает данные. Мы передаём в нее Bitmap и границы обрезки, и получаем Bitmap. Значит это Interactor?

Согласен со всеми, что внешняя библиотека - это фреймворк. Запутать Вас не просто🙂 А много в Ваших проектах однострочных интеракторов?

Уже пару лет использую Model-View-Intent в разработке. Комбинирование различных потоков данных позволяет полностью контролировать стейт. Ошибок при работе с данными и view стало намного меньше, чем было при использовании MVP. Бонусом идут подробные модели событий.

Внезапно полезным оказалось делать глобальную навигацию на стейтах. Передаем в интерактор навигации события background/foreground, диплинки, результаты экранов. Интерактор это обрабатывает, сохраняет свой стейт и опционально выдает свой эвент презентеру глобальной навигации.

Кроме навигации стейты полезны для замены стандартных классов Android SDK. Например, стейт с выбранными элементами для ActionMode легко реализуется на sealed classes с реализациями None, Single и Multiple. На view-слое пишем простой рендерер. Ещё и тестировать можно unit-ами.

Логика и reduce в отдельном потоке и продуманный рендеринг вью стейта избавляют от фризов в UI. Но платим мы бОльшим потреблением памяти на реактивщину и неизменяемые стейты, временем на переключение потоков. Старые девайсы легко с этим справляются.

Если разработчик говорит, что знает RxJava, спросите его как отобразить на вьюхе статус загрузки данных без операторов doOn(Subscribe|Next|Complete|Error). И что делать, если пользователь нажимает на кнопку Retry в процессе ранее начатой загрузки.

Давайте разбираться, что я считаю корректной реализацией. Начнем с модели статуса. Нам нужно знать, когда загрузки началась и чем она закончилась. Sealed class отлично подойдет для этих целей. pic.twitter.com/JiEpuDArfQ

Далее разберемся, как добавить статусы к Single, который возвращает данные. Это делается через маппинг. Добавляем маппинг ошибки в нашу обёртку. А весь процесс получения данных начинаем статусом Loading. pic.twitter.com/bJPtIjhAma

Для простых кейсов этого уже достаточно, но мы можем начинать новую загрузку при поступлении любого события. Оператор switchMap поможет отписаться от ранее запущенной цепочки при поступлении нового event. pic.twitter.com/odtkkVNdRy

Схема универсальная. Repository может отдавать свои события, Interactor может принимать их, обрабатывать и выдавать свои события. Presenter - слушать события от Interactor, преобразовывать в partial states, через reduce формировать ViewState и отправлять его на View для отрисовки

Делюсь личным списком наиболее часто используемых операторов RxJava. Остальные использую намного-намного реже. pic.twitter.com/R6eLBVMoFT

У нас есть возможность строить реактивный потоков данных иерархически. Получив событие, промеряем его через when в flat/switch/concatMap и возвращаем поток событий, связанный с ранее полученным. Глубина вложенности - на Ваше усмотрение.

Например, работа с Bluetooth. Сначала получаем BluetoothAdapter. Если его нет, ничего не делаем. Если есть, подписываемся на статус подключения. Если не подключены, запускаем подключение. Если подключены, запускаем сканер.

При получении устройства, добавляем в список И открываем сокет на нем. Если устройство отключено, удаляем его из списка. Сокет будет закрыт при отмене предыдущей подписки в switchMap.

Большая часть этого решается операторами switchMap и merge. Ну и частичными стейтами

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

2. Для поиска BLE устройств, нам нужен доступ к геолокация. Дожидаемся, чтобы наше приложение было в foreground и запрашиваем runtime permissions (через запуск отдельной активити). Foreground приложения ждём, т.к. с Android 10 нельзя запускать активити в фоне* pic.twitter.com/tCqCCxnsuC

3. Теперь у нас есть и разрешения и BluetoothAdapter. Включаем Bluetooth и одновременно начинаем слушать соединения с устройствами. pic.twitter.com/FkMHYDKpUa

4. Включать Bluetooth следует только если он выключен, иначе ничего не делаем. Тут в extension спрятан вызов активити с intent.action = BluetoothAdapter.ACTION_REQUEST_ENABLE pic.twitter.com/NoKobqred2

5. При появлении нового подключения решаем, что с ним делать и проваливаемся ещё на уровень глубже. pic.twitter.com/bUpzaRyZj8

Существуют ситуации, когда логика связана с неким системным UI.
Например, включение Bluetooth (Intent с action=BluetoothAdapter.ACTION_REQUEST_ENABLE) или геолокации (помните ResolvableApiExeption из play services при проверке LocationRequest?)
Попробуем встроить такое в rx поток

Задача описывается просто: запустить наш Intent или PendingIntent, в onActivityResult поймать ответ и передать его в реактивный поток. Но Repository ничего не знает про наши активити. Как быть?
Запустим прозрачную активити и в ней вызовем startActivityForResult для нашего Intent.

Несмотря на нелюбовь некоторых разработчиков запускать активити, пока все не так страшно.
Но как репозиторию получить ответ из прозрачной активити?
На помощь приходит android.os.ResultReceiver - хитрая штука, которая умеет в Parcelable и шлёт данные через IPC.

В create реактивного потока создаём экземпляр ResultReceiver и в onReceiveResult эмитим в поток события. В прозрачную активити передаем целевой Intent и наш экземпляр ResultReceiver. Вот пример: pic.twitter.com/w7skEdSdxP

Прозрачная активити будет выглядеть совсем просто. Запускаем интент, получаем результат, отправляем его через ResultReceiver и закрываем активити.
Домашнее задание: подумайте, как закрыть такую активити, когда мы отписываемся от реактивного потока. pic.twitter.com/IR8eBK0KUG

Для runtime permissions можно использовать аналогичный подход. Запускаем активити, запрашиваем разрешения с показом rationale (если требуется) и возвращаем результат через ResultReceiver.
Удобно, но есть и подводные камни при смерти процесса.

Хочешь на View вырезать многоугольник, а остальное залить полупрозрачным, идёшь в документацию и видишь Path#op, Path.FillType, Canvas#drawPath, Canvas#clipPath. Что-то не работает с hardware acceleration на старых версиях, что-то deprecated на новых. Развлекаешься.

Приятно открывать новые сценарии использования привычных классов. Возьмём, например, android.graphics.Matrix. Перемещения, повороты, масштаб - все понятно. Но почему раньше никто не сказал, что setPolyToPoly неплохо исправляет перспективу на изображениях!?

Не все задачи на графику требуют расчета координат точек для Path или подготовку Matrix. Как быстро нарисовать что-то похожее на градусник? Напряги дизайнера для нарезки слоев, а затем нарисуй эти Drawable на View в правильном порядке. pic.twitter.com/V72nOXBRVp

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

Особенности организации школы разработчиков в НН. Записываются 20 человек, на первое занятие приходят 12, договор оформляют 6, на занятия ходят 4, один опаздывает. ДЗ делают двое. Но радостно, что у ребят потом получается найти хорошее место.

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

Как-то жил и работал в Москве три месяца. Да - чисто, да - метро и удобный транспорт. Но добираться 12 км до работы за час... А у кто-то это занимает ещё больше времени. Спасибо, но в Нижнем я могу посвятить сэкономленное время более интересным занятиям.

В Нижнем довольно много IT-компаний: больших и маленьких, ауторсеров и продуктовых. И многие поддерживают и проводят митапы и фесты. В последние пару лет замечаю, что количество новых лиц на мероприятиях (причем много студентов) только растет. Жизнь продолжается.

Географически город расположен в красивом месте на слиянии Оки и Волги. Если тебе плохо, выходишь на наб. Федоровского, спускаешься на Рождественскую и идёшь в бар общаться с айтишниками. Если тебе хорошо - делаешь тоже самое. pic.twitter.com/yF2NTowkF8

Сидячий образ работы совсем не способствует здоровью. Приходится компенсировать. Я, например, предпочитаю футбол. Получается так себе, но доставляет удовольствие.
А чем занимаетесь вы? pic.twitter.com/svIWWmy275

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

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

План на неделю:

ПН – Rx в iOS
ВТ – Кодогегерация
Ср - :DD, или различные виды driven development
ЧТ – Архитектурные стили и абстракции
ПТ – Костыли, рефакторинг и эффект второй системы
СБ – Best & bad practices, паттерны и антипаттерны
ВС – Вопросы, опросы и ответы

Многие любят Rx, многие его ненавидят, но есть один неоспоримый факт – Apple выпустила фреймворк Combine, а вакансий со словами «RxSwift» и «Reactive Cocoa» становится всё больше.

Некоторые люди боятся того, чего не знают. Другим сложно перестраиваться на что-то новое и отказываться от старых и привычных принципов и приёмов.

Попробую сегодня дать ещё один взгляд на реактивку сквозь призму своего опыта. C Rx я знаком около 2 лет. Опыт этот исключительно положительный, этим я и хочу с вами поделиться. В нашем проекте мы используем RxSwift.

Существует мысль, что Rx увеличивает порог вхождения в проект. Эта мысль правильная, порог входа действительно растёт. Однако это временное явление. Лично у меня есть ощущение, что через лет 5 подавляющее большинство мобильных разработчиков будут знакомы с этой парадигмой.

ООП, к слову, тоже существовало не всегда и мейнстримом стало не сразу.
Приведу цитату об ООП с википедии: «…в 1967 году в нём были предложены революционные идеи: объекты, классы, виртуальные методы и др., однако это всё не было воспринято современниками как нечто грандиозное»

В мире Андроид Rx является более частым явлением, чем в iOS. Насколько я понял со слов Андроид разработчиков, у них есть некоторые сложности при работе с потоками. И Rx – это отличная абстракция для работы с ними.

На iOS ситуация несколько иная. Для работы с потоками есть много инструментов. И это тоже проблема, но немного другая. Есть и Thread’ы, и очереди, и GCD и много чего ещё. В данном случае Rx выступает единым интерфейсом, и вся работа с асинхронностью становится единообразной.

К слову, сам Rx не делает код асинхронным. По умолчанию, код как раз таки синхронный. Плюс реактивки в том, что и синхронный и асинхронный код выглядят практически одинаково. А синхронный код можно превратить в асинхронный всего одним оператором.

У меня есть опыт наблюдения за тем, как 3 разных команды впервые начинали использовать Rx. Могу сказать, что его освоение не такое уж и сложное. Уровень разработчиков был всегда разный, от джуниоров до сеньоров.

Однако, тут важно учитывать, что в команде всегда был минимум 1 человек, который хорошо знал реактивку. Именно хорошо, а не давно. Можно предположить, что я намекаю на себя:) И да и нет.

В самом начале с Rx хорошо был знаком только наш коллега по Андроид. Поэтому нам было не так страшно начинать. Через некоторое время он ушёл, однако имеющегося опыта было уже достаточно чтобы дальше изучать различные тонкости самостоятельно.

Помню, как первые несколько недель реактивный подход ломал мне мозг. Такое ощущение, буд-то нужно всё делать наоборот, в обратном порядке. Мои ощущения, как выяснилось позже, меня не обманывали. Оказывается, есть push поход, а есть pull.

Бывает так, что разработчик давно знаком с Rx, но использует его неправильно. Например, некоторые люди с большим трудом приходят к пониманию, что в теле замыканий rx операторов нельзя делать какие-либо side эффекты.

Другие не хотят учить все операторы, и пытаются решить любую задачу 3-мя известными.
Моему брату, например, достался проект, в котором мало кто правильно понимал концепцию Rx. Долго описывать не буду, тут важен результат – кодовая база находится в аварийном состоянии.

Прочитав эти строки, вы наверянка могли подумать: опять куча слов, а ответа на главный вопрос по-прежнему нет. Вопрос этот звучит так: «Так Rx это хорошо или плохо?». Ответ на него я не дам, однако поделюсь личным опытом.

В нашем проекте мы преимущественно используем Rx только для общения Ineteractor’a, Presenter’a и View, а так же для реализации их внутренностей.
Сетевой слой у нас не реактивный от слова совсем, мы используем обычные call-back’и.

В остальных классах мы используем Rx настолько мало, насколько это возможно. На самом деле – почти никогда.

У нас есть некоторые обёртки над UIKit, которые упрощают нам жизнь. При этом мы сделали их таким образом, чтоб в любой момент их можно было заменить на нативные инструменты. Просто кода станет больше, и он будет не такой компактный и удобный.

Есть несколько других классов, которые используют Rx, однако их можно пересчитать по пальцам. В качестве примера могу привести менеджер геопозиции и фассад для аналитики. Да и то, во втором случае Rx используется внутри и не виден в публичном интерфейсе класса.

Такой подход позволяет нам сделать использование Rx локальным и инкапсулированным. На нашей практике это решает проблему, когда реактивка насквозь пронизывает все слои приложения. Это также даёт нам гибкость. Мы оставляем за собой возможность использовать стандартные походы.

В данный момент времени далеко не все экраны используют Rx. И это прекрасно, я считаю.

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

В один из дней я расскажу про архитектурные стили, и тогда мы немного вернёмся к этой теме. Я поделюсь своим соображениями на тему того, почему Rx очень хорошо подходит для реализации экранов.

А пока что поговорим о сетевых запросах.

Как я писал ранее, сетевой слой у нас не реактивный. Попробую раскрыть ответ на вопрос «Почему?».

Во-первых, чаще всего стандартного подхода с call-back’ами более чем достаточно. Я несколько раз слышал аргумент вроде «Мы ведь можем использовать Rx, это здорово». Однако вопрос «Зачем?» и «Чем такой подход лучше чем стандартный?» заставляет людей задуматься.

Что делать, если стандартного подхода не достаточно? Объясню на примере из наших реалий. У нас есть частая задача: отправить 3-5 сетевых запросов параллельно, а потом собрать результат воедино.

Для этой задачи я написал простое как тапок периспользуемое решение с использованием DispatchGroup (если нужно, могу выложить код на гитхаб). Теперь отправлять запросы параллельно может любой джуниор без опыта работы.

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

Во-вторых, реактивных сетевой слой как раз таки приводит к тому, что Rx как спрут начинает захватывать своими щупальцами весь проект.

В-третьих, даже если нам когда-либо и понадобится мощь реактивки в сетевых запросах, мы всегда можем обернуть методы с с call-back’ами в реактивные варианты. Для этого есть метод fromAsync(_:) в библиотеке RxSwiftExt.

Тащить всю библиотечку в проект не обязательно, можно скопировать в проект только этот метод.
Одной из задач, где Rx может быть удобен, является retry запросов. Как правило, это какие-то единичные запросы. В этому случае такие методы можно точечно обернуть в реактивный вариант.

Поговорим об освоении этой парадигмы.
Изучение реактивки я начинал с книги Raywenderlich. У меня от неё осталось двойственное ощущение: и хорошее и плохое одновременно.

Не понравился мне только один момент: примеры и куски кода, которые приведены в книге, очень часто нельзя использовать в продакшн коде. А люди именно так часто и делают – копируют и вставляют.

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

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

Обилие demo приложений и playground’ов, и примеры эти весьма интересные. Весь процесс обучения проходит весело и играючи.

Однако некоторые мои коллеги изучали Rx в процессе чтения чужого реактивного кода, а так же методом проб и ошибок. Такое имеет место быть, но стоит принимать во внимание, что в команде были и другие люди, знающие Rx.

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

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

Если у вас начались проблемы, странное поведение программы или вы в очередной раз дебажите код, пытаясь понять почему что-то не работает – скорее всего есть недопонимание какого-то базового принципа. Могу порекомендовать снова открыть книгу, и повторить материал.

Если вы не делали практические занятия - неприятности точно возникнут. Например, когда изучал 12 главу, то знания из первых 4-х уже начали забываться. Я снова прочитал эти 4 главы, и возникло ощущение что при первом прочтении я смотрел в какую-то другую книгу.

Время проходит, знания в голове укладываются и подкрепляются практическим опытом из заданий, а вместе с этим и приходит понимание.

Мораль это истории такова: Rx это очень мощный инструмент. Однако его использование требует понимания фундаментальных концепций и примитивов, а также опыта и здравого смысла.

Есть одна ловушка, в которую попадают многие: в какой-то момент вам начинает нравиться, и вы хотите начать всё делать на реактивке. Это может превратиться в сладкий яд, который медленно убивает ваш проект.

Однако умеренное и разумное использование позволяет экономить время и писать чистый, изящный и очень понятный код.

Если у вас есть вопросы по этой теме – дайте мне знать, я постараюсь ответить.

Есть много материалов по Rx на официальном сайте: reactivex.io/tutorials.html
Заранее предупрежу, что большинство примеров не на Swift. По этой причине для начинающих своетую книгу Raywnderlich.
После её освоения могу порекомендовать следующие материалы:

Reactive Manifesto: reactivemanifesto.org
Rx Design Guidelines: go.microsoft.com/fwlink/?LinkID…
Pulling vs. Pushing Data: docs.microsoft.com/en-us/previous…
101 Rx Samples Wiki: rxwiki.wikidot.com/101samples

2. Для очень многих прикладных приложений, лично на мой взгляд, да. ООП позволяет прекрасно моделировать объекты реального мира, а Rx позволяет очень гибко и лаконично моделировать события. Эти 2 парадигмы отлично сочетаются.

Очень важно тщательно проектировать стыки, где две парадигмы соприкасаются друг с другом:

@tim_plotnikov Любая задача, где есть работа со временем, задержками, отслеживанием наступления нескольких событий (логических и физических) очень просто решается в этой парадигме.
Голосуйте лайками, если интересно увидеть такие примеры. Потом попробуйте решить это без Rx

@b1indsp0t Думаю тут лучше 1 раз увидеть, чем 100 раз услышать. В вс я приведу парочку примеров, где будут сравниваться решения одинаковых задач в разных парадигмах. А что из этого лучше – решайте сами

@mobileunderhood Да,с side-effects в операторах, одна из самых частых ошибок, которые я наблюдаю у новичков. Вытекает из незнания основ трединга и rx-шедулинга. "Сохраню-ка я результат, пришедший в map, в поле этого класса". А на каком треде оператор выполняется и на каком поле будет читаться...

Всем доброго утра. Сегодня тема чуть попроще, а твитов будет поменьше:) Поговорим о кодогенерации.
Из сторонних утилит в нашем проекте используются Sourcery и Swiftgen. Также мы сделали свои шаблоны для XCode.

Начнём с Sourcery. Этой утилите долгое время применения не находилось. Обычно в течение недели после выхода новой версии Swift мы на неё переезжаем. По этой причине генерация всяких equality & hashing нам не интересна.

Однако, у нас в проекте оооочень много XIB’ов и StoryBoard’ов. И с ними нечасто, но с некоторой регулярностью происходила неприятная вещь – они крашат приложение.

Например забыли переназначить класс в InerfaceBulder’е, или пропала связь между Outlet’ом в коде и сториборде. Об ошибке можно узнать только в рантайме:(

Так и напрашивалась автоматизация нахождения таких ошибок. Идея проста: находим все View / ViewController’ы, и по очереди создаём их экземпляры. Если кран при инициализации – тесты покажут ошибку.

Я решил исследовать вопрос. Шаблоны для Sourcery написаны на Stencil. С этой разметкой я не был знаком, однако изучив 2 стандартных шаблона, стало понятно как можно сделать свой.

Для автоматизации проверки всех имеющихся в проекте View они все должны должны быть одного типа. Однако, UIView нам не подходит, потому что есть программно созданные View, у которых нет XIB файла.

К счастью, мы уже использовали протоколы NibLoadable и StoryboardInstantiatable. Любая View, которая грузились из XIB, конформила этот протокол. Аналогично и с ViewController’ами.

Чуть больше чем полдня ушло на то, чтобы ознакомиться с документацией, написать шаблон и наступить на пру граблей. В итоге, кодогенерация завелась, и началась генерация тестов. Выглядят они вот так:

pic.twitter.com/53v28iMlbZ

pic.twitter.com/9tLHaMPSRc

На скриншотах лишь маленькая часть файла. На самом деле деле они очень большие.

Если вам хочется узнать больше о каком-либо вопросе, пишите такие вопросы в телеграмм канал MobileUnderHoodiDm. На следующей неделе, по мере появления свободного времени, я напишу пару статей и создам Playground с примерами. Когда материал будет готов, я напишу об этом в группе

@VasiliyZukanov @mobileunderhood @tim_plotnikov Imho, "чище и проще" вариант с Rx: pic.twitter.com/EGKLafpiUe

@dimarious Прошу прощения, забыл сделать группу публичной) Ссылка: t.me/MobileUnderHoo…

When junior programmer asked how to deploy the project, and you are showing this again. twitter.com/SumLare/status…

Перед уходом на обед расскажу о нашем опыте со Swiftgen. Он интересен тем, что позволяет делать генерацию ресурсов. Конкретно нам он нужен по 3 причинам: генерация картинок, строк и json файлов для Lottie. Стоит сказать, что все базовые шаблоны по разным причинам меня не устроили

Swiftgen: генерация картинок. Базовый шаблон работает, однако есть ряд неприятных моментов.
Во-первых, если есть 2 картинки с одинаковым названием, то в рантайме будет неожиданный сюрприз

Во-вторых, доступ к изображениям не совсем удобен:
wiFiBlackAsset.image
internetAccessAsset.image

Суффикс Asset.image напрашивается на удаление.

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

Начнем с коллизии изображений. В Asset’ах можно создавать папки. В двух таких папках могут быть картинки с одинаковым именем. После компиляции случается так, что остаётся какая-то одна из них. Проблема хоть и не частая, но неприятная.

Сейчас мы находимся в процессе её решения. Цель простая: при нахождении дублей вызывать ошибку компиляции.

Суффикс Asset.image убирается очень легко, нужно всего лишь добавить 1 строчку в исходный шаблон. Теперь обращение к картинке выглядит так:
Icons.wiFiBlack
Icons.internetAccess

Большую свалку мы решили разделить на 2 группы, которые назвали Icons и Illustrations. Для это мы создали в проекте ещё один Asset. Для каждого Asset’а генерируя свой namespace.

Swiftgen: генерация строк. Решение из коробки даёт приемлемый результат. Код становится чище, т.к исчезают вкрапления строковых литералов.
Однако, как вы догадались, нам хотелось чуть больше чем он умеет по дефолту.

Таких хотелок было 2:

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

Помимо этого, коллекции Set и Dictionary в Swift’e обладают высокой производительностью, а алгоритм поиска дубликатов получается простым как 2х2.
Ну и в третьих было интересно сделать это на родном для нас языке.

Через bash можно запустить выполнение кода, написанного в .swift файле. Запуск этого файла можно добавить в Build Phases проекта.

Работа над этим почти закончена. Ждём пока Никита погоняет perfomance тесты и сделает pull request.

Swiftgen: генерация файлов. Решение из коробки для json файлов просто есть. Больше тут добавить нечего. То что получается на выходе – не намного лучше чем получить [String: Any]. Для наших задач это не подходило. Вот как это выглядит: pic.twitter.com/suruN4ZVg9

Путём правки шаблонов мы добавили 2 новых проперти:
let fileName: String
let fileUrl: URL

На основе этого уже можно сделать провайдеры для разных типов файлов. Эти провайдеры можно так же генерировать. Если делать руками, то все равно просто. Так как fileUrl создаётся и проверяется на этапе компиляции, мы можем не бояться force-unwrap’ить внутри провайдера.

В нашем случае этого не требовалось. Сейчас работа с файлами стала намного проще и приятнее, пропали опционалы и куча boilerplate кода. Лучше всего посмотреть на код. Вот так сейчас создаются анимации Lottie: pic.twitter.com/NjnxbVYmqA

Одно из недавних нововведений Swift 5.1 – Property Wrappers. Фича настолько интересная и привлекательная, что хочется начать её использовать чуть ли не в каждой второй структуре или классе.

Я провёл один из выходных, играя с этой фичей в Playground’e. Вывод, который я сделал, довольно прост: спешить не стоит, иначе можно наделать делов.

В команде мы договорились, что каждый с этим поиграется в Playground, наступит на как можно большее число граблей и набьёт шишек. Через месяца полтора-два мы соберёмся все вместе, а там уже решим, какую пользу мы можем от этого извлечь, а где следует воздержаться.

Рассмотрим на примере. В оригинальном proposal есть пример с Clamping. Выглядит этот вот так: pic.twitter.com/wGa6IWI4j2

Выглядит довольно удобно и логично. Значение уровня ph возможно в диапазоне от 0 до 14. Если мы попытаемся записать число 15, оно будет попросту заменено на 14.
И в этом кроется опасность. Число молча будет обрезано.

Здесь можно очень легко получить неконсистентность данных между UI и данными в модели. В UI пользователь видит число 17, а по факту на уровне данных мы храним число 14.

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

В общем, призываю вас быть аккуратными. Мы все работаем над продакшн кодом. Цена ошибки может стоить очень дорого, а за содеянное может быть очень стыдно. Не поддавайтесь желанию использовать фичу лишь потому, что она выглядит многообещающе и интересно. Будьте рассудительны 😌

@mobileunderhood Был на днях еще issue про то, что PropertyWrappers убивают CoW
forums.swift.org/t/property-wra…

@mobileunderhood Наверное, самое правильное - почитать докцию котлина, там хорошо описано что это и зачем нужно: kotlinlang.org/docs/reference…

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

Начнем с известных методик разработки:
Test Driven Development
Feature driven development
Behavior Driven Development
Puzzle Driven Development

К сожалению, на своём опыте я с ними мало знаком. Поэтому расскажу о том, что знаю хорошо:
Panic Driven development
StackOverflow driven development
Hype Driven Development

PS: всё написанное далее сделано исключительно в юмористических целях. Не пытайтесь повторить это самостоятельно. Все трюки были выполнены профессионалами)

Panic Driven development

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

Фокус на предоставлении ценности для клиента требует, чтобы команда заботилась о новых фичах.

Любой процесс разработки, тестирования и выпуска программного обеспечения - это просто набор соглашений и правил, которые не высечены на камне. Меняйте процессы и адаптируйте правила на лету, чтобы выполнить задачу максимально быстро.

Проектная документация – это излишнаяя бюрократия. Мир быстро меняется, а рынок динамично развивается. Документация устаревает чуть ли не сразу после её написания. А вот код – это то, что работает на проде и приносит реальные деньги. Именно его нужно писать в первую очередь.

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

Все знают что тесты полезны, но они не являются приоритетными. Ручного тестирования должно быть достаточно.

Менеджеры имеют право вмешиваться в процесс разработки.
Рефакторинг, техдолг или best practices могут быть выброшены из спринта в угоду потребностей бизнеса.

Инженеры могут высказать свое мнение, но в конечном счёте они, в первую очередь, должны выполнять задачи, которые приходят сверху. В конце концов, кто платит, тот и музыку заказывает :)

PDD - это методология, который может обеспечить значительное улучшение производительности за короткий период времени :)) Глядя на реалии разработки большинства компаний, можно сказать, что они работают на пике своей производительности)

StackOverflow driven development

Любое решение можно найти в интетенте. Все задачи уже давным давно решены умными людьми. Достаточно просто открыть любимый поисковик и написать правильный запрос.

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

Если не удаётся найти готовое решение, то нужно найти несколько ближайших по смыслу о соединить в одно целое. При необходимости можно внести некоторые исправления.

Разбираться в написанном коде вовсе не обязательно. Доверьтесь своим чувствам и интуиции, делайте то, что кажется вам правильным. Меняйте и модифицируйте код до тех пор, пока не получится приемлемый результат.

Главный критерий выполнения задачи – это видимый результат, который очень близко похож на правду. Никому не дела до того, как это работает внутри.

Документация, которую предоставляют вендоры, нужна только для них самих. Нет смысла её читать и пытаться осмыслить. Её пишут гики, которые создают нативный SDK. Для нормальных людей всё это можно найти в интернетах, причём написаное человеческими словами.

@EvgenySavelov Шутки. Я об это писал в одном из ранних твитов.

Hype Driven Development

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

Если вам нужен фреймворк - зайдите на Guthub и выберете тот, у которого наибольшее кол-во звёзд. Нет никакого смысла сравнивать разные решения.

У фреймворка с наибольшим кол-вом звёзд больше всего контрибьюторов, он был обкатан на наибольшем кол-ве проектов и в нем исправлено наибольшее кол-во ошибок. Всё логично и закономерно.

Добавляйте в проект новые, известные и проверенные фреймворки, если вам не нравятся старые. Старые при этом удалять из проекта не обязательно. Новый фреймворк со временем заменит старый.

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

Бизнес будет вам благодарен за внедрение передовых технологий, а вы прокачаете свои навыки. Все в плюсе :)

В завершение дня поговорим о парном программировании. Теперь уже без шуток.

Парное программирование – это то, что по началу кажется контрпродуктивным. Особенно глазами менеджеров: 2 разработчика делают 1 задачу🤔 Можно ведь второму из них тоже дать 1 задачу, и тога одновременно будут делаться целых 2 задачи. Однако не всё так просто)

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

Пишешь код, и попутно объясняешь что и как делаешь.
Есть так же бонус в виде real-time code review: коллега сидит рядом, и сразу задаёт вопросы, если на его взгляд что-то пошло не так. Так же предлагает варианты, если они кажутся ему лучше.

Есть старая поговорка – одна голова хорошо, а две лучше. Здесь это очень хорошо проявляется.
В целом, процесс чем похож на парную игру, например бадминтон или тенис. Вы заняты одним и тем же, общаетесь, обмениваетесь мыслями. А еще можете вместе ходить на перерывы.

Ещё было открытием видеть ход чужого мыслительного коридора. Сидишь рядом, наблюдаешь, и диву даешься: один человек так мыслит, а другой иначе. Третий вообще подошел к решению задачи со стороны, о которой я даже и не подумал бы.

Это постепенно и понемногу расширяет наши границы восприятия, как мне кажется. Строки кода, при виде которых раньше возникала лишь мысль wtf что тут происходит, теперь кажутся просто странными, но тем не менее, понятными.

Начинаешь лучше угадывать намерения и мотивы человека при виде кода. Так же в процессе парного программирования узнается много интересных «фишечек», о которых в иных ситуациях говорить вроде как не совсем к месту.

Могу сказать, что попробовать однозначно стоит. Перед этим следует прочесть несколько статей. Есть разные подходы к тому, как это делать, как делиться на пары и другие нюансы.

Совет, который дал мне мой один архитектор: никогда не допиливать проект вечером накануне презентации.
Любопытно, что он давал мне его дважды, но урок я так и не усвоил. Буквально через 3 недели нам посчастливилось показывать прототип нового приложения высокому руководству.

В последний день перед презентацией мы активно латали бэк, фиксили баги и в спешке допиливали фичи.

Наступил день Х, собралось много людей и все пристально уставились на большой экран. И, если вы сейчас подумали, что приложение крашилось и работало неадекватно, то будете абсолютно правы:) В тот момент мне было очень стыдно.

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

Вместо этого, мы могли довести до блеска основной функционал, и показать хорошую работу приложения. А то, что две мелкие финтифлюшки мы сделаем через 2 дня, при таком раскладе никого не расстроит. Ну, может быть, кроме дизайнеров, которые хотят с этой финтифлюшкой поиграть)

@mobileunderhood Личное наблюдение: из всех областей, в которых доводилось работать, по iOS какая-то запредельная концентрация дичи в ответах на SO. Точнее, хватает то её везде, но обычно она имеет отрицательный рейтинг, а в iOS нередко висит первым ответом.

Сегодня будет душещипательная и холиварная тема: поговорим об архитектуре. Это самый насыщенный день в плане материала. Многое из написанного я почерпнул из книги.

Называется она «Объектно ориентированное моделлирование и разработка», авторы : Джеймс Рамбо, М. Блаха. Иногда буду вставлять цитаты из неё, дабы не искажать исходный смысл.

Начнём с распространённых архитектурных стилей:

Моя цель – не просто накопипастить текста, чтоб было побольше твитов, а рассказать ключевые моменты, которые могут заинтересовать людей (и которые когда-то заинтересовали меня). Надеюсь, многим после этого захочется более детально изучить приёмы моделирования и проектирования.

На мой взгляд, в сфере мобильной разработки не хватает фундаментальный знаний.

Пакетное преобразование (batch transformation) cостоит из нескольких вычислительных процессов. Приложение получает входные данные и должно вычислить результат. Никакого взаимодействия с внешним миром в промежутке не предполагается.

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

Модель классов достаточно важна: она описывает ввод, вывод и промежуточные стадии вычислений.
Модель взаимодействия документирует вычисления и связывает между собой модели классов.
Наиболее важным аспектом решения задачи является определение четкой последовательности этапов.

Непрерывное преобразование (continuous transformation) — это характеристика системы, выходной сигнал которой зависит от изменяющихся сигналов на входах.

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

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

В качестве типичных примеров приложений этого класса можно привести: обработчики сигналов, оконные системы, инкрементные компиляторы и системы контроля производственных процессов.

Для этих систем модели классов, состояний и взаимодействия должны быть примерно такими же, как и для пакетных прeобразований.

Динамическое моделирование (dynamic sinmulation) — это моделирование, или отслеживание, объектов реального мира. В качестве примеров можно привести моделирование траекторий движения молекул, расчет траекторий космических кораблей, экономические модели и видеоигры.

Моделирование проще всего проектировать с использованием объектно-ориентированных технологий.
Объекты и операции берутся непосредственно из модели приложения.

Управление может быть реализовано двумя способами: внешний управляющий объект может имитировать конечный автомат, либо же объекты могут обмениваться сообщениями между собой, как и происходит в реальном мире.

В отличие от интерактивной системы, внутренние объекты при динамическом моделировании соответствуют объектам реального мира, поэтому модель классов в таких задачах имеет существенное значение и часто получается достаточно сложной.
Модели состояний и взаимодействия также важны.

Система реального времени (real-time system) — это интерактивная система с жесткими временными ограничениями на время отклика. Системы реального времени бывают жесткими и гибкими.
Жесткие это жизненно важные приложения, требующие гарантированного отклика в заданное время.

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

Администратор транзакций (transaction manager) — это система, основное назначение которой состоит в хранении и выдаче данных. Большинство администраторов транзакций имеют дело с множеством пользователей, которые одновременно считывают и записывают данные.

Администратор должен обеспечивать защиту данных от неавторизованного доступа и от случайных сбоев.

Администраторы транзакций часто реализуются в виде надстройки над системой управления базами данных (СУБД). СУБД предоставляет универсальную функциональность для управления данными, которая может быть использована повторно.

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

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

@mobileunderhood @reeve_nn @50megatonn Ок. Когда я писал первое приложения, я был знаком с концепцией MVC и с проблемой что ее понимают все по разному (спасибо @habrahabr_ru и куче холиварных статей на эту тему). Прочел совершенный код. Видел эволюцию php фреймворков. Тогда как раз стал популярным laravel

Интерактивный интерфейс. На этой теме остановимся чуть подробнее. Мобильная разработка в большинстве своём сопряжена с этим архитектурным стилем. Следующий трэд будет про моделлирование состояний, это даст больше понимания о практическом применении.

Итак, интерактивный интерфейс (interactive interface) – это система, в которой доминируют взаимодействия с внешними агентами (людьми или устройствами). Внешние агенты не зависят от системы, поэтому она не может их контролировать, а может лишь запрашивать у них ввод данных.

Интерактивный интерфейс обычно составляет лишь часть некоторого приложения, которая часто может рассматриваться независимо от вычислений.

В качестве примера интерактивной системы можно привести: интерфейс запросов, основанный на формах, оконный менеджер рабочей станции или панель управления моделированием.

@mobileunderhood А можно ссылку на источник данных стилей? Книга/статья

Диаграммы состояний

Вот уже полтора года я проектирую экраны, рисуя диаграммы состояний. Однажды для меня это стало открытием. Я долго задавался вопросом, почему я не усвоил материал в институте. Было бы ещё лучше, если мне рассказали об этом в школе или даже детском саду:)

Суть в том, что диаграмма состояний позволяет наглядно и как на ладони вертеть очень сложные экраны.

Есть у меня опыт исправления экранов, которые не могли заставить работать адекватно несколько поколений разработчиков.

Сначала это вызвало у меня восторг. Я сделал то, что не удавалось многим. Чуть позже ко мне пришло осознание, что так могут делать все разработчики, если их научить. Еще чуть позже что, на самом деле, не все. Но многие всё же могли бы:)

Почему-то бытует мнение, что UML это бюрократия и устаревшие методики. «У нас же тут Agile, мы сейчас 10 минут посовещаемся, и начнём сразу код писать. К чему эти формальности в виде детального оформления требований и рисования квадратиков на бумаге?»

Зачастую, так утверждают люди, которые подобные диаграммы последний раз видели в институте, но на практике с ними не работали.

Лично мой опыт таков, что в интституте я этим как-то не проникся.

Было не ясно зачем это вообще нужно и как может мне помочь. Однако начав работать и сделав некоторое количество коммерческих задач, вы наверное сейчас подумаете, что я вспомнил про диаграммы и начал их использовать, верно? Как бы не так:)

Дигаммы я, конечно, использовать начал. Однако произошло это после того, как мне порекомендовали прочесть ту самую книгу.

К тому времени я уже познал боль программистского бытия и вкусил плод MassiveViewController’a. И мне страсть как хотелось начать жить без боли. Вот тут то мне и попались на глаза нужные строки из книги.

У диаграмм есть ряд очень серьёзных преимущества. Говоря о преимуществах мы автоматически подразумеваем, что будем что-то с чем-то сравнивать. Сравнивать мы будем со всем известной методикой «Подумал – покодил - подумал - покодил …»

1. Рисовать диаграмму намного проще, чем писать код. Её можно перерисовывать хоть 15 раз, это всё равно не займёт много времени. Выкидывая очечной вариант в корзину, нет сожаления. А вот удалять или переписывать код бывает неприятно.

2. Диаграмма помещается на один листок А4. В сравнении с этим, кода могут быть написаны тысячи строк, если реализовать этот же экран.

3. Имея диаграмму, вы можете прикинуть несколько разных вариантов реализации. Здесь к месту вспомнить 5-й принцип SOLID: «Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций». Диаграмма, это абстракция. Реализовать её можно по разному.

Однако если мы сразу начинаем писать код, а идею дорабатывать на ходу, то мы очень сильно сужаем коридор мысли и полёт фантазии, и как следствие ограничиваем реализацию.

Конкретно этот момент крайне сложно передать словами. Это нужно прочувствовать. Нарисовать пару диаграмм, сделать их реализации. Ощутить радость детского восторга от того, как здорово всё получилось. Сухие слова мало что дадут.

Всем снова привет, прошу прощения за паузу. У меня осталось несколько часов, вернёмся к нетронутым темам

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

Вот ссылка на гитхаб. В репозитории лежит swift файл и playground с примером. Сделано через DispatchGroup.
github.com/iDmitriyy/Para…

Часто разработчики боятся менять итак сложный и код. В конце концов, дописать ещё один if-else проще, чем переписывать тысячу строк запутанного кода.
Поэтому важно понимать требования.

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

Был у меня случай, когда я удалил 1800 строк кода, а написал около 350. Код стал несоизмеримо понятнее, а вместе с этим устранились давнишние баги. Довольно часто баги решаются удалением кода, а не добавлением нового.

В настоящее время есть много проектов, которые либо полностью на Obj-C, либо большая часть. Часто миграция проекта на Swift оказывается не такой простой задачей, либо не понятно с какой стороны подходить к объятию необъятного.

В прошлом на одном из проектов мы решили взяться за перевод на Swift. Размер проекта был около 110 тыс строк кода, завершили перевод примерно на 85% за полтора года.

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

Через год мы оглянулись назад, и увидели что около 60% проекта написано на новом языке.

Очень часто перевод на Swift просто рутина. Для рутины я использовал плагин Swiftfy for XCode. Безусловно, она не сотворит чудес и не перепишет код таким образом, чтобы задействовать возможности, которые в Objc-C попросту отсутствуют.

Однако она позволяет наращивать % кода, который написан на  Swift. Дале с течением времени код начинает улучшаться и становиться более Swift’овым. Тут главное начать.

Захардкожнные массивы enum’ов заменяются на CaseIterable, классы заменяются на структуры, множество свободных функций становятся методами структур и enum’ов, различные [AnyHashable: Any] становится строго типизированными.

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

Также очень часто нас выручал известный паттерн «адаптер». Были куски логики, которые написаны когда-то давно, разбираться в них долго и некогда, но они мешают переписать на Swift какой-то большой пласт.

В этом случае мы переписывали на Swift всё что могли, а для возможности работы с легаси писали адаптер.
Если есть вопросы по этой теме, пишите их, постараюсь ответить.

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

Интересно узнать, какое у вас отношение к оставлению комментариев в коде:

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

Есть люди, которые никогда не позволяют себе выбросить мусор на землю, они обязательно дойдут до урны. Но множество людей ведут себя по разному в разных условиях. Если вокруг валятся мусор, они могут выбросить окурок или фантик на землю.

Если вокруг чисто, то они себе такого не позволяют. А есть люди, которые почти всегда бросают мусор на землю.

Похожую картину я наблюдал при работе с кодом.

Если кодовая база в ужасном состоянии, далеко не все будут стараться привести этот код в порядок. Проще побыстрому и какое как закрыть задачу, нежели ковыряться в коде, работать с которым сложно и неприятно.

Лично мне работать намного приятнее, если код в хорошем состоянии. И наоборот, выполнение задачи становится не очень интересным, если приходится лезть в код с запашком. С появлением Swiftlint, к счастью, делать это стало легче.

Однако литер проверяет только конструкции языка. Адекватный нейминг и структурированность обретаются договоренностями команде и Codereview. И договориться, как раз таки, бывает непростой задачей:)
А вы как решали этот вопрос?

Насколько для вас важен нейминг, хорошая структурированность и аккуратное оформление:

Собеседуя людей, заметил одну интересную особенность – у многих разработчиков абстрактное представление об абстракциях. Вроде бы все знают это слово, но объяснить его смысл могут далеко не все.
Итак, трэд про абстракции.

Здесь стоит обратить внимание на одну деталь: абстракции в реальной жизни мы встречаем не так часто. Я бы даже сказал что очень редко. Их нельзя отнести к тем вещам, которые мы трогали руками ещё в раннем детстве. Такой незначительный опыт образует смутное представление.

PS: Говоря здесь «мы», я в первую очередь подразумеваю себя. Возможно есть люди, у которых абстракции лежали в доме рядом с детскими игрушками:)

Мне очень нравятся примеры из книги. Лучше чем авторы я не напишу, поэтому приведу цитаты. По традиции, начну немного издалека.

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

Модели уменьшают сложность реальных систем, выделяя ограниченный набор важнейших свойств.»

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

Ещё под абстракцией подразумевают интерфейсы. В Swift это протоколы.

Абстрагирование – это одно из важнейших человеческих умений, которое дает нам возможность работать со сложными вещами.

Чтобы создать сложную систему, разработчик должен абстрагировать разные ее представления, построить модели, используя четкую систему обозначений, проверить, что модели удовлетворяют требованиям, предъявленным к системе, и постепенно добавлять детали, превращая модели в реализацию

Абстрагирование – это выборочное изучение некоторых аспектов проблемы.

Цель абстрагирования состоит в том, чтобы изолировать аспекты, важные для некоторой цели, и избавиться от всех остальных. Абстрагирование всегда должно иметь цель, поскольку именно она определяет, что является важным, а что нет.

«Одна и та же сущность может иметь множество разных абстракций, отличающихся друг от друга назначением.»

Говоря о целях абстрагирования, предлагаю рассмотреть пару примеров.
В качестве примера будем делать модели паспортов.

Предположим, нам нужно сделать простое ПО для регистрации входящих в здание посетителей. Указывать нужно только ФИО и номер паспорта. Другими словами, для решения этой задачи будет достаточно модели с двумя полями.

Рассмотрим другой пример. Нам нужно сделать ПО для организации, которая занимается созданием паспортов. Им необходимо хранить реестр всех когда-либо выданных паспортов

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

Задачи разные, и модели тоже разные.

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

Разработчик добавляет это поле с мыслью «В тех задачах, которые уже используют данный класс, новое поле просто не будет использоваться». Время идёт, разработчики меняются.

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

Разбиение исходного класса на несколько других может решить проблему. Тут важно помнить, что при создании любой модели важно чётко понимать, с какой целью она создаётся. Для этого нужно выписать все цели и задачи, после чего начинать моделирование.

Кого эта тема цепляет и хочется узнать ещё больше – ваш выбор это «Глава 2: Моделирование как методика проектирования»

Часто на собеседованиях говорят про паттерны и SOLID. Однако во время трудовых будней людей частенько об этом забывают. Мне по этому случаю вспомнилась студенческая шутка: «Я человек простой – сдал экзамен, забыл предмет»

Про паттерны писать не хочу, поэтому трэд про Анти паттерны.

Преждевременная оптимизация

Очень часто приводит к неоправданному усложнению кода и увеличению сроков решения задачи. Нередко оказывается так, что на самом деле в оптимизации нет потребности.

Разработчику просто хочется сделать код оптимальным по тем критериям, которые он сам себе придумал

Магические числа

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

Мы эту проблему решили так: pic.twitter.com/WDfl6g11PL

Ненужная сложность

Когда простая задача решается сложными конструкциями. Причины бывают разные: недостаток самовыражения, потребность блеснуть умом, непонимание как сделать проще. Лечится CodeReview и рефакторингом.

Бездумное комментирование

Когда комментарием много, а толку мало. Пример таких комментариев:
// перебираем элементы массива по очереди
for tariff in tariffs { … }

Однострочное решение

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

Copy-Paste

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

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

Golden hammer

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

Например для задачи хранения данных один разработчик всегда делает выбор в пользу CoreData, а другой всегда в пользу Realm, без анализа того, что лучше подойдёт для конкретного проекта или задачи.

God Object

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

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

Ну и напоследок небольшой список-напоминалка хороших практик: github.com/thomasdavis/be…

@mobileunderhood Насчет игрушек не знаю, но человечество функционирует за счет абстракций.
Карта это абстракция местности, руль в машине это абстракция сложной системы управления, рассказ это абстракция информации, память это абстракция событий и т.д.

Если у вас есть вопросы - пишите в телегу. Так же я создал группу t.me/MobileUnderHoo… . Туда добавились люди но никто почему-то не пишет вопросы)

Какая тема была для вас наиболее интересна?

Благодарю всех за внимание и конструктивные комментарии. Ваши ответы помогли мне переосмыслить известные вещи. До новых встреч🙏🏻😌

pic.twitter.com/LMD4jYGhrj

Всем привет! Меня зовут Софья и я инженер по тестированию в шведской компании Majority. На этой неделе я веду коллективный твиттер и я расскажу вам о нелегкой жизни тестировщика, автотестировании и Швеции

Расписание:
1-день с тестером
2-автоматизация
3-почему ваш тестер плачет в туалете
4-релизы здорового человека и релизы курильщика
5-если теща захочет стать тестером-с чего начать
6-как без регистрации и смс я переехала в Швецию
7-общение

1 день. День с тестером. Буду рассказывать о своём типичном рабочем дне(читай как день и как дно). И с какими проблемами встречаюсь ежедневно.

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

Наше тестирование перед релизом выглядит примерно так: когда все основные фичи релиза протестированы и больше не ожидается-мы делаем регрессионное тестирование. То есть, проверяем все приложение по написанным нами тест-кейсам.

Регрессионное тестирование мы делаем на специальном билде, который обфусцироован, но с доступом ко всем прелестям дебаг билда. Мы проверяем, что при мерже нет конфликта фичей, что нет крашей, каких-то логический ошибок и что фичи не сломали рабочий функционал

У нас есть аутсорс тестеры из Латвии, которые и занимаются регрессом. Я же запускаю свои e2e тесты, загружаю результат и репорчу о багах, найденных автотестами. Я батенька по андроид тестам. Поэтому андроид разработчики не особо рада меня видеть по утрам.

В идеальном мире, параллельно с регрессией менеджер по локализации(у нас 14 языков) проверяет переводы. Но ей нужна помощь с билдами и как дойти до нужного экрана. Так что каждый релиз я трачу порядка 4 часов на помощь и тестирование переводов.

Когда регресс закончен, переводы проверены и борда в Jira чистая, мы делаем релиз билд и делаем smoke тестирование. На билде, который поедет в стор и который будет у пользователей. Это обычно занимает час, просто проверяем, что нет крашей, логин/звонок работает.

Сегодня у нас лежит тестовый бекенд и поэтому тестирование мобильных приложений сейчас на паузе. У нас есть 3 варианта бэка: дев, стейдж и лайв. Тестирование у нас всегда на стейдже, так как это мы считает зеркалом продакшена(лайв).

Вообще роль тестера иногда очень печальна. Бэк говорит, что это ошибка клиента, клиент говорит, что ошибка бэка. А ты просто хочешь, что бы все нормально работало. Поэтому ходишь по всем кругам ада в поисках истины.

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

На вопрос, когда именно запрашивать permission и добавлять, а что делать если мы апдейтим апп, а не ставим по новой и тд - продакт добавил в задачу коммент “permissions” и перешёл к следующей. Кайф. Это очень нам помогло.

Спринт у нас 6 недель. По сути-один спринт = один релиз. Да, мы ещё не так хороши, как компании с быстрыми релизами раз в 2 недели, но есть хотя бы календарь с релизами. Знаешь, когда ждать панику в глазах продакта и нарастающее напряжение на стендапах.

Расскажу немного о компании. Мы делаем 2 продукта: приложение для звонков по всему миру за небольшую стоимость и банк для мигрантов. Сначала основным продуктом были звонки, сейчас банк. Почему банк именно для мигрантов? Не нужно много документов для открытия счета.

Вся наша компания помогает мигрантам в адаптации в новой стране. Звони домой не дорого, открой свой счёт в банке без проблем с документами, отправляй деньги родным без комиссии. Нам достаточно водительских прав или паспорта. Основной наш рынок - США.

Решила побыть тестером здорового человека, и пошла смотреть таски на следующий релиз на предмет адекватности и наполненности. Это тестирование спецификации. Очень полезная вещь. Особенно, если задача ещё не взята в разработку.

Пример кейса: нужно дать возможность удалять пользователям карточку последнего звонка. Но помимо карточки звонка у нас есть карточка с транзакцией( сколько стоил звонок, длительность и тд). Вопрос: удаляем от мы транзакцию?

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

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

О тестировании спецификации: этим может заниматься не только тестер. В идеале на грумминге или планировани спринта разработчики тоже добавляли свои кейсы и вопросы. У меня был разработчик, который спрашивал много вопросов, а делал как ему ретроградный Меркурий велел.

Только не подумайте что я разработчиков и продуктов не люблю. Есть ещё и дизайнеры) думаю все сталкивались с тем,что дизайн в основном делается под iOS, а андроид идёт лесом обычно и делайте по дизайну iOS. *Здесь картинка с Коллином Фареллом.*

Почему макеты только под iOS это не очень? Навигация работает иначе, не по гайдам. И когда разработчик адаптирует под андроид - возможно фича будет выглядеть иначе. А значит будет этап согласования норм/не норм. Ещё один круг в копилочку.

Расскажу о багах. Я чертовски не люблю баги. Нет, нахождение бага не поднимает мне самооценку. Что бы оформить баг нужно снять логи, если это краш. Видео и скриншоты. Точные шаги, все возможные условия. Это очень утомительно. Оформить все красиво. Баги отстой.

Помнится когда только начала свой путь тестера - правда радовалась багам, которые находила. Потом радовалась багам, которые находили автотесты. Сейчас радуюсь зелёным тестам и хорошо сделанной задаче. Это ли не счастье?)

Об аутсорсе. У нас 2 постоянных тестара и один, который постоянно меняется. Очень крутые ребята. Но из-за того, что они в Латвии иногда коммуникация страдает. Если мы можем подойти к разрабу и быстро решить вопрос, то им нужно ждать, когда он ответит в слаке.

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

О тестировании фичи. У нас фичи живут в своих ветках до тех пор, пока тестер не проверит фичу. Перед тестированием - code review. Если все ок - тестировщик мержит ветку с фичей. Так мы имеем стабильный мастер, который может релизить в любой момент(нет).

Когда code review пройдено успешно - разработчик ставить лейбл в gitlab(это не реклама), что код проверен и все ок. Но тут интересный кейс есть-во время тестирование найдены баги и сделаны правки. И их никто по новой не ревьюит. Лейбл то есть.

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

Если есть баги в фиче и они критичны-делаем саб-таски и фиксим в этой же ветке. Если не критичны - делаем отдельный таск, линкуем к задаче и мержим ветку.

День 2. Автоматизация. Я не эксперт в этом, сражу сразу. Я построила автоматизацию в своей компании с нуля, но это не spaceX. Расскажу о том, как у нас она построена, как продавала автотесты и с чем сталкивалась. Буду рада советам и вашему опыту)

Я пишу тесты под андроид. Выбор мой пал на espresso. Брала голый espresso и подстраивала под себя. Были уже готовые варианты типа Барриста или авитовского фреймворка, но тогда мы были бы зависимы от апдейтов этих библиотек.

Поэтому было принято решение адаптировать под себя espresso. Что я понимаю под адаптацией? Свои матчеры, свои ассерты. Например, при работе со свичерами - эспрессо не работал с нашими свитчерами. Или например, оценка звонка. Где нужно выбрать рейт из 5 звёздочек.

У меня был опыт работы с автовским фреймворком, и он мне настолько нравился, что я пытаюсь посмотреть похожий фреймворк у себя. Но так как автотестами занималась только я - построила, что построила) не авито, но сойдёт)

До меня было много старых тестов на UIAutomator написанных. Они были не актуальны, их не запускали годами и их никто не удалял и не обновлял. Я их тоже не трогала, так как меня они не аффектили, плюс было подушкой для компании, если мои тесты будут «не очень».

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

И это было моей ошибкой, так как количество тестов росло очень быстро, и когда было покрыто порядка 60% мне поставили задачу-красивые репорты. А это значит, что в каждом тесте нужно добавлять шаги. Я приуныла. Но потом они захотели свою ферму. И забили на отчеты.

С фермой это отдельная история. Наш CTO грезит своей фермой. Я правда не знаю почему, но он с таким огнём в глазах говорит о шкафе с девайсами и тесты бегут, бегут, бегут. Я так на торт на диете не смотрю, как он, когда говорит о ферме.

С точки зрения опыта - построить свою ферму было бы интересно. С точки зрения саппорта этой фермы - нет, спасибо. Поэтому я активно продавала FirebaseTestLab. И продала таки! Но тут на сцену вышли наши fraud checks.

У нас есть проверки на подозрительную активность. Например, один айпи заходит слишком часто и у него нет других приложений, кроме нашего. Там много проверок на самом деле. Все не упомнить. И собственно, мы баним этот айпишник.

Так как тестовый бек все ещё лежит(со вчерашнего дня), сейчас пойду к нашим бекендерам за разрешением этой ситуации. Если к кого была такая ситуация - расскажите, как вы ее разрулили.

Наши бекендеры такие милаши. Да конечно, найди мне хоть один userId, мы найдём ip и добавим, что бы не блочилось. Все сделаем, не грусти. Кайф) но тестовый бэк все ещё лежит и тесты запустить не могу.

Если кто не юзал firebase test lab расскажу про свой опыт. Подключается она легко. Есть 2 варианта запуска тестов-вручную через консоль и с помощью скрипта на ci. Собираете 2 апк - тестовый и приложения, загружаете и он запускает все тесты, что у вас есть.

Как я уже писала ранее, у меня были мертвые тесты на uiautomator. Я из саппортила при миграции на AndroidX. Но после первого запуска тестов через консоль - я поставила всех в известность, что старые тесты сношу. Так как через консоль запускались все тесты. Старые тоже.

Я запускаю свои тесты не эмуляторах. Есть варианты ещё на реальных деапйсах запускать, но я пока играюсь с эмуляторами. Когда все будет работать исправно и без блока-сделаю микс из реальных/эмулятора. Ферма так знатная, есть вариант шардирования тестов.

Кстати о шардировании. Когда ты запускаешь через консоль-и выбираешь количество шардов-он делит твой сьют тестов на это количество и запускает параллельно на образе твоего девайса. И если у тебя 20 тестов и 4 шарда-в каждом образе будут гоняться по 5 тестов. Очень удобно.

Но в силу своего незнания или опыта или не высокого интеллекта, когда я прописывала в скрипт на ci все те же команды, что указаны в гайде-шарды у меня не создавались. Пример: ‘—environment-variables numShards=4,shardIndex=0’

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

Я перечитала столько блогов на медиуме, и везде было copy/paste из гайда и типа: вот так вставляете и все у вас работает: 4 шарда и усе параллельно. Я тогда знатно кризис словила: у всех работает, а я тупая.

Ещё возможности test lab - видеозапись вашего прогона тестов. Удобно смотреть, что пошло не так. Не удобно, что нет разбивки по тестам, то есть одно видео=один тест. Увы нет, одно видео=один сьют. А это значит, что нужно смотреть весь прогон, что бы найти нужное видео.

Я искренне не знаю, что у нас с тестами под ios. Парень написал самописную штуку, которая вроде как и кликает по элементам, но и меняет что-то в ответе бэка, сравнивает результат и делает скриншот. Я эти тесты не видела, на ci они не идут. Темный лес.

О CI. Мы юзаем teamcity. И из всех задач, что стояли передо мной-конфигурации в tc были самыми простыми и любимыми. Но с уходом одного разработчика, который саппортил tc и агентов - вся эта красота перешла в мое владение. У нас 3 линуксовых агента, и один windows агент для тестов

Главный вопрос: почему мне, ведь я ничего не понимаю в этом? Ответ простой: потому что другие абсолютно забывают и не работаю с этим. Билды не собираются-ну ок, кто то посмотрит. Возможно это особенность моей компании. Но я теперь поднимаю агентов, если что-то идёт не так.

Нас часто пересаживают по офису, так как формируют тимы для более эффективной работы. А значит я со всем своим хардом пересаживаюсь каждый раз, переподключаю и настраиваю все тоже каждый раз) недавно ещё и Jenkins поднимала после переезда. Jenkins юзаем для iOS.

Я, как тестер, росла в очень тепличных условиях авито и всеми сложными вопросами типа железа или ci занимались крутые инженеры. Я только посматривала за их работой и восхищалась. Сейчас самой приходится заниматься этим, и мое восхищение ими растёт с каждым днём все больше.

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

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

Для нового приложения мы планируем запуск на каждый пр в мастер. Так как мерж ветки у нас только после тестирования-мы не будем сильно страдать, если все тесты будут идти час или около того. В идеале-открыли пр-запустили тесты-тестер смотрит результат и проверяет фичу - мержит.

О моих тестах и разработчиках. Вообще разработчики мои тесты не трогают. Такое же отношение, как к чужому коду по сути дела. Но они иногда их запускают, когда меняют что-то в готовом функционале. Запускают локально. Если видят падения-правят фичу. Это мило. Но делают так не все.

Когда была миграция на AndroidX я была в отпуске. Разработчик встретил меня грустным взглядом и сказал, что возможно тесты сломались. Когда переделывали работу с permissionManager - разработчик сам менял все в тестах.

Но в большинстве это моя зона отвественности и я прихожу только с результатами. Но они иногда посматривают мои пр и в баре говорят, что мой код вполне себе хорош)

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

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

Когда задача переходит в тестирование, я переключаюсь на саппорт таску и меняю свои тесты. Если новый функционал - мержу ветку с фичей к себе и там пишу тесты. После того, как с фичей ветка вмержена-я мержу свои тесты. И делаю прогон.

Задачи по типу рефтакторинг мы проверяем автотестами на андроид. Но все равно иногда я могу быть сильно занята и не поддержать вовремя фичу. И приходится судорожно перед релизом править тесты. Так себе практика. Все очень нервные перед релизом.

День 3. Почему ваш тестер иногда плачет в туалете и как ему помочь. Есть вещи, с которыми мы сталкиваемся если не каждый день, то один раз за всю карьеру точно было. Начну наверно с описания задач.

Если это задача на создание новой фичи, в ней точно должны быть критерии приёма фичи. Даже такие тупые, как «при клике на кнопку назад мы возвращаемся на предыдущий экран». Могу сказать точно, что фича в голове продакта, разработчика, дизайнера и тестера выглядит по разному.

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

От того, что в задаче описано куча вводного материала нам не легче. Я понимаю, что во многих книжках об успешном продакте написано, что задачи нужно создавать со стороны того, кому нужна эта фича. Например: я как продакт менеджер хочу видеть статистику открытия экрана.

А дальше долгое обоснование этой задачи: статистка поможет нам увидеть, как много пользователей доходят до этого и бла бла бла. А по сути нужно добавить трекинг и один ивент. Но сначала ты читаешь всю это бороду. Долго, очень долго читаешь.

Но есть и другая крайность: задача на одну строчку при создании фичи: сделать пуш-уведомление о получении сообщения. И все. А какой текст? А куда должен вести линк? И ещё тысячи вопросов. Но самое забавное в таких задачах-они делаются без уточняющих вопросов в комментариях.

Или вопросы задаются, но лично. Разработчик подошёл, спросил, сделал. А тестировщик проучил всю ту же голую задачу и начинает собирать требования уже на этапе тестирования.

Другой тип задач-технические задачи от разработчика. И они чаще всего делятся на 2 типа: нужно проверить все или да там проверять не нужно, я только вервию библиотеки обновил. Ничего сломаться не должно.

И чаще всего они описаны как кусок кода, или линка на документацию, или просто ‘com.facebook.stetho:stetho:1.5.1’. . Ммм, кайф. Ну и на вопрос, как тестировать - либо все, либо ничего. И чаще всего, когда тестировать «не нужно» - мы огребаем потом много багов

Меня очень расстраивает, когда разработчик не проверяет хотя бы зелёный сценарий задачи. Да, есть и такие и они были в моей жизни. Задачу сделал, проверил, внёс правки, не проверил, запушил. Фича не работает с самого первого экрана. Прям вот совсем не работает.

Любимый пример: есть экран и две кнопки: сохранить и отменить. Разработчик внёс небольшие изменения относительно кнопки отменить. Запушил без проверки основного зелёного сценария. Итог: когда тапаешь по кнопке Сохранить - ничего не происходит. А должен переходить на другой экран

Ещё никогда задача про два стула не была такой актуальной, как в тот момент. Хотя бы один переход сделать - и этого будет в большинстве своём достаточно. Один зелёный сценарий.

Другой момент, когда оценка задач состоит только из оценки на разработку фичи. Пример: в релиз идут 2 задачи. В неделю разработчик делает 16 сторипоинтов. Разработчик оценил их по 8 сторипоинтов. Продакт увидел, что ну за неделю мы все сделаем и зарелизим.

На тестирование никто не заложился. И тут снова картинка с Коллином Фареллом. Ну да, ну да, пошёл я нахер. В итоге, задача возвращается тк есть баги, продакт нервничает так как закоммитился на релиз в конце недели. Все нервничают, а тестер мог бы работать и побыстрее.

Когда ломается старый код - никто его чинить не хочет. Например, разработчик уже ушёл из компании, его фунционал сломался, приходишь к новому разработчику, а тебе в ответ: это не мой код, я не знаю что там произошло. И как бы ты опять идёшь нахер.

Я знаю что это не твой код. Я все понимаю.Но у нас один продукт( мы же команда и все такое. Я же не могу вернуть предыдущего разработчика, что бы он чинил свой код.

Не любовь к старым и маленьким девайсам) их никто не любит. В каждой команде есть один тупой девайс, на котором куча багов. Он один такой зашкварыш, который мелькает в 70% багов. И баги с ним кочуют из релиза в релиз.

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

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

Нам не особо рады) вот честно. Когда я подхожу к разработчику, первый вопрос - что случилось? Я словно предвестник смерти,болезни, голода и войны в одном лице. Тестировщик на горизонте - жди беды и багов. Особо это было заметно, когда была релиз инженером

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

Мы очень ответственные. Во всех командах, где я работала(кроме релиз команды) мы выходили работать в выходные, так как не хотели подводить команду. На тестирование не заложились, важный релиз, все очень грустные - мы выходим иногда работать в выходные. Или работает до победного.

Обычно все приходит в тестирование непосредственно перед релизом. Огромный скоуп задач. И тут начинается ещё гонка приоритетов)

День 4. Релизы здорового человека и курильщика. Я была релиз инженером в авито, а до того, как мы придумали эту должность-занималась тестированием перед релизом. Расскажу какой путь компания прошла, и как мы релизим в majority.

Изначально у нас была команда из 4-5 человек-тестеров, которая перед релизом делала регресс. Нужно понимать масштаб всего этого процесса-вся компания генерит фичи в течение месяца/двух - и потом 2 человека с 4 девайсами проверяют порядка 300 кейсов.

Автотесты либо падали, либо были не стабильны, либо их не было вообще. Регресс перед релизом занимал около недели., тк каждый кейс мы проверяли на всех 4 девайсах. Масштаб уныния был запредельным. Именно в эту команду я и попала.

Так как во время регресса находились баги, итерация тестирования было несколько. После правки багов мы собирали новый билд, проверяли фикс и смежный функционал. Вообщем неделя на тестирование уходила спокойно.

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

Потом мы начали привлекать тестировщиков из фича тим. Не все были этому рады. Например на одну фича тиму - один тестировщик. И он выпадает на неделю - мало кому это понравится. К тому моменту мы уже начали сформировывать нашу релизную команду.

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

Так как фичи генерились, кейсы добавлялись, а автотесты писали ещё не все команды/тестировщики. И тогда мы сделали ход конем и начали применять импакт анализ для ручных кейсов, которые не покрыты автотестами

Суть в том, что разработчик и тестировщик вместе смотрят свои задачи, что пойдут в этот релиз и проверяют только те области приложения, которые могли быть задеты этой фичей. Например: если вы меняли логин, вам незачем проверять настройки приложения.

Большую часть критикл кейсов ребята покрыли автотестами. И новые фичи тоже покрывались автотестами уже к регрессу. И очень многие ждали и насчитывались на результат этими тестов, так как объём тестирования значительно сокращался.

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

У нас был календарь релизов, где было по датам и часам прописано, когда срез ветки, когда начало регресса, когда релиз. После каждого этапа мы отписывались в чат, например: срезали ветку на Андроид. Или: сборки готовы, результаты автотестов загружены. Да начнётся регресс!

Но до тех пор, пока срез ветки делался инженером, а не скриптом - были попытки «запрыгнуть в уходящий поезд»(с). То есть, писали в личку/чат - очень нужно вмержить фичу, подождите пять/десять минут. У нашей команды было право вето на мерж фичей после времени среза ветки

С большой силой приходит и большая ответственность. Было сложно отказывать, скажу сразу. Во-первых, я понимаю, что ребята потратили много времени на эту фичу. Что я выгляжу как бабка в паспортном столе, которая уходит на обед и шлёт всех нахер.

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

Яркий пример: одна команда очень хотела свою фичу именно в этом релизе, они вмержили ее, мы запустили автотесты на ночь, ушли домой, а с утра у нас все тесты красные. Фича была: тултип при запуске приложения. Ни одни тесты не были поправлены и не ожидали тултипа вообще

Релиз сдвигается, нам нужно время либо на игнорирование тултипа либо на саппорт его в автотестах. И вся компания ждёт фикса. Это очень не круто. Все нервничают, так как многие в планировании закладывались на регресс.

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

Но все изменилось, когда срез ветки был запрограммирован на определённое время. С Роберто(бот для среза ветки) не договоришься, на него не обидишься. Плюс человеческий фактор уходит.

Очень полезным инструментом стали фича тоглы. Каждая фича закрывалась фича тоглом, и если мы понимали что фича сырая и пускать ее в продашн нельзя-мы отключали тогл. Тебе не нужно ревертить изменения, просто ставишь значение флагу false и словно фичи и не было)

Как мы планировали регресс: на тестирование первой итерации у нас был 1 рабочий день. Следующий день до 5 вечера - правка багов, тестирование/принятие решения, что отключаем фичу. Следующий день - 4 часа на вторую итерацию и отправка приложения в сторы.

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

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

Сейчас в авито наверно уже космолёт построен, но когда я уходила мы релизили каждую платформу раз в 2 недели. Процесс среза ветки, запуска тестов, сбора тест сьюта и загрузка результатов автотестов был автоматизирован полностью.

Так же был автоматизирован процесс загрузки билдов в сторы и сбор what’s new. Мы лишь следили за тем, что бы ребята завершали тестирование вовремя и за багами, которые были блокерами для релиза.

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

Был случай, когда хотели сделать хот фикс в поддержку бэкенда, который выкатил новую фичу. Вроде как тестируем одну задачу и катим фикс. Но неожиданно попросили протестировать все что успеем. И тогда покатим. Это было посередине спринта. Для меня это стихийность после авито.

День 5 - расскажу как я вообще пришла в профессию, как готовилась и с чего начинала. Может кому-то это поможет. Скажу сразу, я абсолютно не знаю что происходит на рынке курсов. То есть их содержание, полезность и вообще какие курсы есть.

У меня не техническое образование, и до тестирования я была медиа-пленером в рекламной компании. Было только уверенное знание excel и невероятное желание попробовать что-то новое. И по воле случая я попала в маленький стартап. Мы делали новую соц.сеть.

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

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

Вопросы были однотипны в основном: виды/типы тестирования, особенности тестирования моб. приложений, что такое тест кейсы/сьют. Каждый вопрос, на который я не знала ответ я выписывала и старалась применять. Например: создать баг по всем канонам.

Чем больше читала и изучала - тем больше понимала, что в стартапе я делала очень тупую работу и можно делать все иначе. Например, перед релизом - сделать небольшой smoke тест, проверить основные сценарии и тд. Или баги создавать подробнее.

Потом моего мч позвали в авито и мы решили вместе уйти из стартапа: он в авито, а я куда возьмут) после наверно первой или второй недели Фил приходил и рассказывал, как тестируют в авито, какие тулзы юзают. И тут я пошла осваивать чарльз, андроид студию, xcode и postman

Я ставила эти программы, открывала все приложения, которые были у меня и смотрела что отдаёт мне чарльз. Это был какой-то дивный новый мир для меня. Собрав всю возможную инфу - я составила своё первое резюме. В основном там было так: это знаю, но не работала на прямую.

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

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

Я помню только 3 компании, куда собеседовалась и проходила дальше первого этапа: это была мамба, mail и собственно авито. Для мейла я не подошла тк им нужен был тестер с возможностью автоматизации в будущем. А я тогда была вообще далека от этого. И собственно авитушка)

Благо сейчас процесс изменился и всех собеседуют иначе. Меня побеседовали 3 человека сразу: тестировщик мобилок, тестировщик веба и хед тестировщиков. Перед собесом я всю ночь повторяла все свои записи, Фил меня собесил дома, по дороге на Лесную - повторяла.

Из того, что мой разнервничавшийся мозг запомнил было: вот тебе форма подачи объявления о продаже машины - как будешь тестировать и вот тебе два числа(условно 179 и 59) раздели их. И собственно на втором я залажала. Я шикарно считаю в уме,это блин мое хобби. И столбиком не смогла

Деление столбиком и в уме мне не особо пригодилось в работе и я все же прошла собес. Одним из условий прохождения испыталки было получить сертификат ISTQB. Это вроде как показывает, что ты не хер с горы, а тестировщик со знаниями стандартов тестирования.

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

На столько ужасно переведённого и составленного текста я ещё не читала. Я засыпала на середине предложения. Я честно сделала 2 попытки прочитать его, потом послала все нахер и решила, что здравый смысл мне поможет.

Вопросы были не сложные, но то, как они сформулированы - это был вынос мозга. Но здравый смысл победил, я сдала экзамен без подготовки, регистрации и смс. Кстати, экзамен платный. Одну попытку оплачивал авито, если не сдаёшь с первого раза - дальше платишь сам.

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

Я оставалась после работы, что бы читать документацию, смотреть доклады, читать тест кейсы и тд. Ехала домой - изучала приложение. Ехала на работу читала гайды к приложениям и как элементы называются. Пыталась даже книжки по тестированию читать(не зашло)

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

И это был ещё один сильный скачок, так как ты наблюдаешь за ходом мысли других людей, понимаешь стандарты и ожидания. Плюс у этих людей был опыт 3-4+ лет. Быстро учишься в мощной команде. Ну и личный перфекционизм конечно. Хотела быть лучшей)

Когда был набор в новую команду и встал выбор: идти в неизвестность(мы тогда имели только идею, что хотим делать) или идти в продуктовую команду - я выбрала неизвестность) в продукте я знаю многое, а вот с релизами не работала. Люблю все новое и неизвестное.

Тогда примерно мой мч уезжает в Швецию и мы понимаем, что ручным тестировщиком найти работу будет очень сложно. Реально, но сложно. Тогда я знатно шлепнулась со своих грёз о том, что я вся такая крутая. В автотестировании и программировании я была 0

Мою печаль заметил Дима Воронин, успокоил меня и сказал, что бы не расстраивалась и он поможет мне с java и автотестами. Если честно, это был один из поворотных моментов. Мы сидели после работы и разбирали из чего состоит андроид приложение и как пишутся тесты

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

Потом меня подпустили уже к проекту авито и я написала свой первый тест и сдела первый пр. Господи, как я боялась залажать. Дома я продолжала разбираться уже с нашим проектом, писала тесты в своё удовольствие,читала документацию гугла, смотрела чужие проекты на гите с тестами

Помимо ежедневной практики с тестами - я изучала джаву. Опять тетрадочка, опять вопросы к собеседованию и выписывала все что не понимала или не могла запомнить. Для меня это очень рабочий вариант. Плюс изучала наш проект. Как вообще работает приложение.

Потом писала тесты под ios. Нет так много, как под андроид, но это тоже было интересным опытом и расширило мой кругозор круто. Дома изучала по фану другие фреймворки и языки. Но упор и фокус был Java/Android.

Вообще весь мой путь идёт под девизом « я нихера не понимаю в этом, нужно пробовать». Но одних горящих глаз все же недостаточно сейчас, что бы получить свою первую работу. Хотя бы минимальные знания должны быть. Хотя бы теория. Как вариант - почитать блоги на хабре уже отлично.

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

Многие идут в тестирование так как считают, что это трамплин в разработчики, сейчас вот чутка посижу, пойму и пойду разработчиком. Я не осуждаю этот подход, но смысл тратить своё время на работу тестировщиком, если хочешь быть разрабом? Имхо опять таки.

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

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

Это отличная практика баг репортов. Гуглите шаблон баг репорта-пишите по шаблону-уже +10 очков Гриффиндора. Да, возможно о баге знают. А возможно нет. И где-то тестировщик, который будет разбирать этот запрос от саппорта пошлёт вам лучики добра)

Хорошей практикой для меня было просто просмотр вакансий. Смотришь требования к скиллам, инструментам, практикам. Понимаешь, что не знаешь - выискиваешь в интернете и изучаешь. Заодно изучишь рынок и поймёшь что в среднем знает тестировщик. Если это не вакансия «будь классным»

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

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

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

Собственно мой тогда мч переехал в Швецию. Мы рассматривали 2 варианта моего переезда: по воссоединению семьи и я ищу работу. В идеале было что я найду работу конечно, но сначала подавали документы на воссоединение семья. И нам отказали.

Мы не были женаты, у нас не было совместных детей, кредитов, недвижимости, бизнеса и других доказательств того, что мы вместе. Только совместные поездки, фотки, и посылки, которые я оформляла на его адрес за пять лет. И этого было недостаточно. Поэтому основной целью стала работа

Я отвратительно знала английский. Поэтому начала учится в языковой школе. Потом ещё дополнительно взяла авитовский курс английского. Все занятия у меня были примерно 4 дня в неделю. Плюс домашка. Ну и фильмы/сериалы/документация на английском.

Я дико заморочилась по резюме. Оплатила доступ к шаблонам, правила, отсылала Филу, снова правила, он ревьюил его у своей коллеги QA. И так до тех пор, пока оно не было сносным. Основные пункты - писать результат своей работы, а не просто процессы

Например: писала автотесты и тем самым сократила время на регрессионное тестирование. Это очень утрировано, но посыл понятен) потом отдельно заготовила шаблон для сопроводительного письма. Тоже очень важная штука.

Там в основном была вода про желание работать в этой компании и меняла только название компании и причину. Например: Я очень хочу работать в вашей компании так как очень верю в проект и то что вы помогаете людям общаться с родными свободно после переезда в другую страну.

Я изучала каждую компанию на вакансию которой откликалась. Читала про их публичную деятельность и тд, что бы на интервью, как бы случайно упомянуть это, типа: это очень круто, что вы являетесь спонсором параолимпийских игр и тд. Это обычно цепляет)

Для того, что бы не портятся во всех отправленных мною откликов я завела себе трелло борду со столбцами типа: откликнулась - ответ да-ответ нет-техническое задание-следующее интервью. Помогает не откликаться повторно и следить/управлять процессом.

Для начала я откликалась на вакансии из Германии/Нидерландов и тд, что бы потренироваться в прохождение собеседований. Простите меня компании. Когда ты 2 года не проходил собесы - это жесть как волнительно и ты ссышь на каждом вопросе. К тому же на английском.

Мое первое собеседование было по телефону с чуваком из Германии и тогда я поняла, что не понимаю «не русский английский». Я залажала на собеседовании так как нихера не понимала. Даже то что знала - не могла ответить. Ну и связь была херня.

Фил предложил пройти собес в его бывшую компанию. Я была не готова, но без практики ты и не будешь готов - так что я согласилась. Сначала были переписки с рекрутером, потом техническое задание: написать приложение на андроид на 3 экрана и тесты к нему.

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

Я готовилась к каждому собесу: прогоняла стандартные вопросы рекрутеров, зубрила о себе, каждые 3-4 дня созванивалась с Филом и он меня собесил. По дороге на работу повторяла вопросы, дома подтягивала английский.

Где-то раз 10 у меня опускались руки. Когда отклоняли на стадии резюме, когда отклоняли на junior позиции. Это вообще было очень обидно. Там просто нужно было быть коммуникабельной. Даже без опыта блин. А я с опытом и коммуникабельная, че за херня?

За время собесов я перепробовала 4 новых фреймворка и 2 языка. Писала тесты для веба и бэка. Написала 1 стратегию развития тестирования в компании и порядка 30 багов. Ну и одно маленькое приложение на андроид на 3 экрана)

После очередного отказа, я понимаю что уже все,я не вывожу это все. Я читаю письмо с отказом, пишу Филу что я тупая и больше не могу и спустя 5 минут мне приходит приглашение от моей нынешней компании. А у меня уже руки опустились. Но шаблона на отказ у меня не было-согласилась

По стандарту - вот вам приложение наше - автоматизируй, пиши тест кейсы, опиши как будешь запускать это все на ci и тд. Делаю задание, отправляю. Расписала даже что на firebase test lab запускать нужно.

За 3-4 дня до технического собеса мы расстались с мч. И мне приходит приглашение на собес. Так как мне было почему-то неловко им отказывать - я согласилась на собес с четким осознанием, что это мой последний собес в Швецию. Тип если нет - пошло все нахер.

Поскольку я правда не видела больше смысла в собеседовании - я была спокойна. Мне было так ровно, что мне откажут. Меня собеседовал head of mobile и единственный мобильный тестировщик. И она была из России. Head во время собесования вышел и мы начали говорить по русски)

И тогда я вот абсолютно расслабилась. Словно просто созвонилась с кем-то поболтать про тесты. Ну и техническое собеседование я прошла. Потом было собеседование с CTO. Тогда у меня зародилась надежда в сердце снова. И я опять начала нервничать.

Но он опоздал на собес) я готовилась к вопросам на решение проблем, коммуникацию, стрессоустойчивость и тд. А он меня спросил: Почему Швеция. Я настолько растерялась,что сказала что у вас люди на улице улыбаются. И каким то хером мы начали говорить про Сталина.

То ли мое знание Сталинской эпохи его покорило, то ли еще что-то, но я прошла все этапы собеса и мне дали оффер. Дальше началось оформление документов. В Швеции это все занимает 3 месяца. Подготовка визы, уплата налогов работодателем и тд.

В Швеции кстати сначала вакансия месяц или 3 должна повисеть только в Швеции, что бы была возможность шведам сначала на неё откликнуться. Если не нашли нужного по скиллам в Швеции - тогда можно и из других стран искать.

Основные ресурсы для поисков были LinkedIn(привет VPN) и Glassdoor. На Glassdoor вакансий больше даже. Плюс можно посмотреть отзывы о компании, что реально очень полезно.

Мне повезло с компанией очень сильно: мне оплатил квартиру на 3 месяца, взяли все заботы по налогам и документам на себя. От меня нужно было только приехать, забрать ключи и заселиться. Плюс мне дали ещё одну неделю перед работой просто привыкнуть к Швеции.

Основной документ тут - IDCard. Без неё ты не можешь оформить банковскую карту, оплатить налоги, да и вообще ничего не можешь. Считайте это как паспорт в России. Для приезжих ещё оформляется рабочая виза.первые 2 раза на 2 года - потом вроде бессрочная.

После 5 лет проживания и работы в стране ты подаёшься на постоянную визу и уже будешь гражданином Швеции. Собственно рабочая виза мне даёт возможность путешествовать по ЕС без виз, штампов и прочих прелестей. Исключение - Англия. Ну и США так то.

В компании все понимают, что английский не твой родной язык, поэтому спокойно относятся к ошибкам в грамматике и тд. На самом деле основное - что бы ты мог донести свою мысль. Если делаешь ошибки типа предлогов и времени - на это не особо смотрят и не осуждают)

Переезжать одному сложно. Все твои друзья и родные далеко. У вас есть только скайп и мессенджеры. По началу очень сложно без друзей. Нужно быть к этому готовым. И расчитывать в каких-то моментах вы будете только на себя. Это правда очень важно.

О, я перевезла сюда собаку. За месяц до переезда нужно сделать ей прививки. Обязательно наличие паспорта и чипа. Собаку тут нельзя оставлять одну более чем на 8 часов вроде. Поэтому тут есть сады для собак. За 25к рублей в месяц. Отводишь с утра, забираешь после работы.

Если есть возможность - то можешь просто в обед приходить и гулять с ней. Тогда в сад сдавать не нужно. В метро есть отдельные вагоны, где ты можешь ехать с собакой. Но собаку все же тут дорого иметь. Страховка, дет сад и все такое. Плюс нужно ее девать куда то во время отпуска

Поэтому тут есть услуга, что ты за плату отдать животное на неделю/две ситтеру. Где-то 2100 р. за одну ночь. Так же есть услуга по выгулу собак, если не сдаёшь в сад и сам не гуляешь. Около 1000 р за прогулку. Короче: животное тут показатель что ты состоятельный господин.

В Швеции дорого. Я каталась в Барселону, Амстердам и Ригу и цены после Швеции были низкими. Я по 3 раза проверяла, что нет лишнего 0 на ценнике. Так что со шведской зп кататься в Европу очень комфортно) ну и билеты из Швеции дешевые по Европе.

Про жильё: с животными и детьми сложно найти квартиру. Без них тут очень много вариантов. Цены в самом Стокгольме идут от 70к рублей и выше. Есть варианта дешевле и не в самом Стокгольме. И ты не проигрываешь при этом. Так как общественный транспорт тут офигенен.

Мне от двери дома до работы 20 минут. Я еду 3 остановки на автобусе и 5 на метро. И это все 20 минут. Если снимать квартиру в Solna(это не совсем Стокгольм, но близко) до центра будет примерно так же, так как ходят оттуда специальное метро.

Ипотека тут кайфовая. Около 2% годовых в среднем. Но нужно иметь 10% от стоимости квартиры что бы взять ее в ипотеку. И цены на недвижимость тут конские. Так что если захотите купить квартиру - порядка 2,5 млн рублей нужно иметь свободными, что бы оплатит первый взнос

По компаниям: в Стокгольме сидит Spotify , AWS, EA и их студия Frostbite, Rovio, Voi( которые электросамокаты) и ещё куча крутых небольших и больших компаний. Так что вариантов куда устроиться тут очень много.

Для шведских компаний вроде как норма выделять бюджет на сотрудника для всяких ништяков. Например у меня в компании у каждого есть 10к крон в год, которые ты можешь потратить на спорт, учебу, велик купить, поехать в ежегодный трип на лыжах и тд.

10к крон это 1000$/€ в среднем. Накожно на эти деньги купить абонемент в зал, или пойти на курсы вокала. Или оплатить себе брикеты. Или билеты оплатить и отель. Или уроки шведского. Если не тратишь их они в конце года добавляются к зп, но тогда вычищаются налоги

Я например взяла себе абонемент в зал за 500$, оплатила билеты в Ригу и ещё 300 нужно потрать до конца года. Мед страховку и отчисления в пенсионный фонд оплачивает работодатель.

Некоторые компании как моя и спотифай раз в год вывозят всех сотрудников куда-нибудь в другую страну на тусовки и тип апдейт стратегии компании, цели на год и все такое. В прошлом году была Польша, в этом Барселона. Компания платит за все. Очень приятно)

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

С момента определение цели и страны и до оффера прошёл год. За этот год я научилась нужным мне скиллам, подтянула английский и перестала мандражировать перед собесами. Я не звездный тестировщик за которого компании борются и вроде как смогла переехать.

Так что если кто задумал менять страну - не алеюсь немного вам помогла и показала, что это не сложно и главное начать)

День 7-расскажу сегодня о самом крутом баге, ещё немного про Швецию и о хваленом work-life balance или как я в 26 лет поняла, что абсолютно не умею жить после работы. Возможно, сегодня будет самый скучный тред)

Начну с бага.это реально было очень эпично. Это был последний релиз года в авито, дальше уже нг и праздники, а мы и так шли на большой риск с этим релизом. Стоит сказать, что для регресса у нас были особые сборки,которые мы могли с помощью чарльза снифать трафик.

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

И как только я пишу в чат, что мы на 100% - в эту же секунду пишет саппорт и говорит, что на андроид 5 не работает приложение, тупо белый экран. Откатить я уже не могу, нужен фикс. Мы по всему офису искали андроид 5, Дима по коду и по гиту смотрел, что произошло.

Где-то в 9 вечера мы понимаем, что есть зависимость не только в версии андроид, и что баг не воспроизводится с вай-фаем. Нужен телефон с симкой. Мы воспроизвели баг, но отдебажить не можем, так как это релизка.

В офисе остались только я и Егор, и от нас вообще пользы никакой в этом деле. Тут пишет Дима из дома, тип давай искать. И просто спасает всех нас и релиз. Время было около 11 вечера, я приехала домой и Дима запушил фикс. Я проверяю на единственном девайсе - исправлено.

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

Мне советовали не рассказывать эту историю на собесах, потому что как тестер я тут была диким отстоем. Но это баг был самый эпичный. А мы с Димой были самые помятые в офисе на следующий день) я в 5 утра встала, что бы посмотреть саппорт и метрики. А Дима в 6, что узнать как релиз

Ещё про Швецию. Первые месяцы в Швеции я ощущала себя как диснеевская принцесса, только меня отрисовали плохо. Ты выходишь на балкон - а у тебя перед домом тусят косули. Или лось, или кролики. Если бы я начала петь уверена - они бы помогли мне собраться на работу.

Это жесть как странно. Ты выходишь покурить, а мимо тебя две косули шагают и переходят дорогу. Но самая крутая история была(не со мной), когда лось съел забродившие яблоки и пьяный залез на балкон к чувакам. Бухой лось на балконе. Типичная Швеция.

В Швеции народ не перерабатывает. То есть ровно в 5 мб 5:30 вместе идут домой. К 6 вечера офис пустой. И тут я поняла, что я не знаю как проводить вечера дома. В Москве у тебя час занимает дорога до дома. Пока приготовишь еду - уже 9 вечера. Немного почитал и спать.

А тут я в 5:30 дома и такая: а чем люди то занимаются по вечерам. У меня как мне казалось было много увлечений, и на них всегда не было времени и сил. То в игры поиграть, каллиграфия, вязание, курсы, книги, фотография. И когда у тебя нет времени на это - ты считаешь это хобби.

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

Тут меня знатно накрыло с этого. Я поняла что последний год вообще не отдыхала в выходные, что я не умею это делать. Я умею лежать, смотреть сериалы и тупить в телефон. Так себе перспектива. Я стала скучной сама себе.

И тут меня понесло. Я записалась на кучу курсов, пошла на танцы, начала рисовать, фоткать, заниматься йогой. И от такой своей бурной деятельности я быстро устала. И снова на все забила. У меня было ощущение, что только работу я могу делать хорошо. Остальное так себе.

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

И это мне правда помогло. Когда я уже устала смотреть сериалы я решила разобраться с каждым своим увлечением. Мне не нравится рисовать много. Я устаю от вязания. Но я чертовски люблю новые знания и навыки. И к 27 годам я поняла что мое хобби это обучение.

Я начала разгребать все курсы, на которые записалась. Их 28. А поскольку я чертовски люблю умничать и говорить всякие неинтересные никому факты просто так - я решила закрыть их все. И что бы опять не слиться - завела себе цель дневник. pic.twitter.com/d0KSQwUhZI

У меня есть невероятное желание узнавать что то новое, но нет дисциплины в учебе. И с этим дневник правда помогает. Во время прохождения курсов я отписываюсь там о каких то интересных фактах и это ещё помогает структурировать новые знания.

И да, я всегда с завистью смотрела на людей, у которых есть хобби и они им занимаются в любую свободна минуту. Что ж, мое хобби-козырять тупыми фактами типа: а вы знали что свои мысли мозг воспринимает так же, как и информацию извне? Вообщем тосты мне лучше не говорить.

И на этой прекрасной ноте я закончу своё повествование. Я надеюсь что было не так сильно паршиво. Мне было с вами очень классно, спасибо за помощь, поддержку и советы. Пишите, если есть вопросы) и ещё раз спасибо. И по классике: Егор, не пиши мне больше.

Привет, друзья! Меня зовут Петя, и я только что вернулся с прогулки с собакой. Ближайшую неделю буду обитать здесь, но обычно я тут — @petertretyakov. Работаю в петербургском офисе @REDMADROBOT, отбираю доклады на @MobiusConf. Также я бывший журналист, поэтому букв будет много.

Традиционно будем как всё и пойдём по плану. В понедельник, в день начала всех свершений и перенесённого на неделю спортзала, обсудим iOS13 SDK. Поговорим про новые фреймворки, новые API к старым, и что надо изучить сейчас, чтобы не кричать «Свободная касса!» через два года.

Во вторник не будем опускать Deployment Target и обсудим Catalyst. Я порвал 16 бубнов, запуская своё iPad-приложение под macOS. Ощущения ни с чем не сравнимые: когда костылями крутишь педали и едешь на велосипеде по солнечной Индии. Как будто «Шантарам» перечитал. Расскажу о нём.

В среду я расскажу вам о том, как делаются новости. 10 лет я был журналистом, из них четыре года в ежедневной газете @Vedomosti. А ежедневная газета — это дедлайн каждый день. И попробуйте только заговорить потом про выгорание! Бонусом расскажу как в 30 лет ушел из медиа в IT.

Ах, да, еще мы будем всю неделю слушать северный соул и мотаун. Потому что северный соул — это красиво. Не так красиво как «Люби меня, люби» Отпетых Мошенников, конечно, но тоже ничего. И открывает нашу музыкальную программу Dusty Springfield — Live It Up. music.apple.com/ru/album/live-…

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

С тех пор SwiftUI я так всерьёз и не пощупал, потому что каждый раз чувствую себя читателем книги «iOS-разработка для самых маленьких», когда трачу час на то, чтобы добиться от SwiftUI того, что в UIKit сделал бы за две минуты. А как у вас? Есть ли те, кто успел там освоиться?

Пока курил летом SwiftUI, выделил себе несколько правил работы с модификаторами.
Во-первых, важен порядок модификаторов, например установка shadow после и перед background выдаст вам разные результаты. Вроде, очевидно, ведь каждый модификатор возвращает View, но часто забываешь.

Во-вторых, модификатором стало всё: не только UI-составляющие, но в том числе анимация и gesture recognizer. Это превращает ваш код в бесконечный список модификаторов, а на первый план выходит декомпозиция UI-слоя.

В-третьих, модификаторы влияют все на всё. Т.е. если у вас есть модификатор с анимацией, то он будет срабатывать на все изменения. Если хотите position менять со spring-анимацией, а background — с easeInOut, доставайте костыли.

Но ладно, SwiftUI хоть и интересен, но в продакшене мы его ещё долго не увидим. Однако есть вещи из iOS13 SDK, которые уже начали внедрять. И самое крупное из таких нововведений — это Sign In with Apple. Давайте его и обсудим в ближайшие несколько часов.

Sign In with Apple я успел изучить достаточно хорошо, хотя в продакшен выкатить так и не успел. На последнем CocoaHeads в Петербурге я выступал с этой темой, получилось как-то скомкано, постараюсь здесь рассказать более четко и подробно.

Почему это важно? Ещё на WWDC говорили, что Sign In with Apple (👋🍎) станет обязательным для всех приложений с third-party авторизацией. И вот у нас есть срок: до 4 апреля 2020 года, если у вас есть авторизация через Google и иже с ним, и вы не внедрите 👋🍎, то реджект.

Начнём с очевидного: с кнопки. Это простой UIControl, даже не UIButton, чтобы вы свои несанкционированные тайтлы туда не пихали. Всё, что Apple даёт настраивать: стиль (чёрный, белый, белый с обводкой) и corner radius. Локализация в кнопку встроена. pic.twitter.com/09L22e1XNn

В кнопке нет никакой магии: стандартный target-selector, поэтому кнопку, в принципе, можно сделать и свою, но Apple само собой рекомендует использовать системную.

@mobileunderhood Кстати, оффтоп. кто делал "login with apple"? Вы что-то делали для андроида или клиентов с 12 осью и старее?

Всего есть два варианта тайтла для кнопки: Sign In и Continue, а в зависимости от размера кнопки будет либо только яблоко, либо яблоко с текстом. Просто «Вход» или «Продолжить» с яблоком Apple делать не стала. pic.twitter.com/pOYBFoHxQs

Флоу авторизации через Apple несложный, если вы делаете это из iOS-приложения. Я не буду приводить тут куски кода, проще посмотреть WWDC developer.apple.com/videos/play/ww… или покопаться в тестовом проекте, который я собрал для доклада github.com/petertretyakov…

Расскажу немного об iOS-части Sign In with Apple, чего не сказали на WWDC, а потом перейдём к серверной.
Раз. Эта штука не работает в симуляторе. Точнее авторизоваться-то вы сможете, но потом на проверку того, что пользователь авторизовался система всегда будет отвечать ошибкой.

Два. После первой авторизации, пока пользователь вручную сам не деавторизуется, iOS Вам больше не отдаст ни его имя-фамилию, ни адрес почты (даже фейковый), только ID и токен. Из токена почту можно вытащить, но имя будет потеряно, поэтому как только получили данные, сохраняйте.

Три. Основным идентификатором пользователя в системе должен быть User ID, который вам отдаст iOS, а не email. Потому что пользователь может выйти и снова авторизоваться с фэйковым email-ом, а ID не изменится. Более того ID будет одним для всех приложений в рамках одной DevTeam.

Знаете, о чем я забыл с вашим программированием? Archie Bell & the Drells — Here I go again. music.apple.com/ru/album/here-…

Давайте теперь быстренько о серверной части Sign In with Apple поговорим. В принципе, она вам пока не нужна, потому что ее основная задача, как и у любой OAuth авторизации — получить Access и Refresh токены. Проблема в том, что эти токены вам ничего не дают.

В документации так и написано: Access token reserved for future use. Серверная часть авторизации нужна, если вы хотите авторизовать пользователя на сайте или в Android-приложении, используя JS-фреймворк или REST API. pic.twitter.com/vJEnkgUdhb

Единственное, что я придумал в качестве «future use» — это доступ к Private Database пользователя вашего CloudKit-контейнера. Потому что сейчас основное ограничение CloudKit — это отсутствие кроссплатформенности. Только Public Database доступна вне приложения.

Но давайте к делу. Из приложения вы получите помимо User ID, email, имени еще и Authorization Code (это Data, в которой лежит строка). Он живет 5 минут, за это время ваш сервер должен успеть обменять его на Access и Refresh токены.

Кроме кода вам понадобится еще и Client Secret — это приватный код, которым вы подпишите JSON Web Token и отправите его в реквесте на сервера Apple. Вот в этой статье подробно описан этот процесс developer.okta.com/blog/2019/06/0… Я лишь перескажу некоторые его части.

На лучшем в мире языке Ruby (сервера я пишу на Ruby on Rails, а не на Vapor на Swift, поэтому извините), создание реквест-ключа выглядит так. Вы можете создать его один раз, установить expiration time на полгода (больше нельзя) и использовать, потом надо будет перегенерировать. pic.twitter.com/4TwNZvLCuD

Сорян, отвлекся на прогон доклада для ближайшего @MobiusConf, заодно вам его прорекламирую. Илья Лобанов из Яндекса расскажет очень крутой и достаточно хардкорный доклад про то, как они делали кастомный ScrollView для Яндекс.Метро и это просто пушка пушечная, а не доклад!

Потом вы делаете POST-запрос на appleid.apple.com/auth/token с вашим сгенерированным ключом и в ответ получаете Access Token. А как использовать Access Token вы уже знаете — пока НИКАК :) Раз в сутки вы можете обновлять Access-токен с помощью Refresh-токена, но опять же, зачем? :)

Вообще, я один из тех, кто был настолько впечатлен новым API iOS13, что поднял Deployment Target у себя в pet-проекте до iOS13 и тут я понял, что Support Library нам в iOS-разработке очень не хватает, потому что использовать плюшки нового API — это блаженство.

Пару слов про то, что вы получите из коробки с Deployment Target iOS13, не используя суперновые штуки типа SwiftUI или Combine. Потому что изменения в остальные фреймворки в этот раз тоже фурами подвозили.

Я сразу перевел проект с иконок в Assets на SF Symbols. Кто не знает, в iOS13 есть около 1500 новых иконок, они как и шрифт San Francisco есть во всех начертаниях (от Ultrathin до Black) и чудесно позиционируются по бэйзлайну с UILabel. Бинарь похудел в три раза после этого.

Я даже создал кастомный SF Symbol для одной иконки в Sketch, нарисовал все начертания. Дизайнерам будет больше работы для кастомных иконок, но не обязательно рисовать все варианты, можно ограничиться только Regular. В итоге в Assets три иконки и AppIcon.

Темная тема в iOS13 полетела как новенький боинг, потому что теперь есть куча системных цветов, типа UIColor.systemBackground, UIColor.label, которые подстраиваются под цветовую схему. И даже UIColor.systemBlue — это разный синий в темной и светлой теме.

В iOS13 прокачали UISearchController API, который был валенок. Теперь есть доступ к тестовому полю (УРА!) и более прикольная плюшка — теги в тестовом поле, например, как в системном приложении Mail. Подробности есть тут andyibanez.com/posts/ios13-ne…

Еще в моём топе изменений в iOS13 Dependency Injection в инициализатор UIViewController из сториборда! Если Бога нет, то скажите мне, кто придумал этот инициализатор? developer.apple.com/documentation/…

@mobileunderhood Между support library и поддержкой новой оси устройствами 2015 года + высокий процент устройств на последней ОС я бы выбрал последнее

DiffableDataSource для списков мне тоже невероятно зашел, но внедрить его я пока не успел. Кажется, это что-то типа DiffUtil в Android. Наш разработчик в @REDMADROBOT Петя Козлов рассказывал про DiffUtil на AppsConf. Заменшеним его, а то он не читает этот аккаунт, враг! @xd720p

Ладно, пора и честь знать. Вот вам очередной северный соул под завязку дня music.apple.com/ru/album/seven…, а я пойду гулять с собакой. Завтра поговорим про еще одну штуку из iOS13, которую я сегодня сознательно обходил — про Catalyst, мы ж теперь не просто так, а macOS-разработчики.

Hello, World!

Второй день нашего плавания, и сегодня обсудим Catalyst. Я уже давно хотел сделать macOS-версию своего приложения, но все никак руки не доходили. А когда в 2018 году рассказали про Марципан, который потом стал Каталистом, я решил, что просто подожду ещё год до релиза.

Первым ограничением для запуска моего приложения на macOS были зависимости. Перед WWDC2019 я думал, что вот только первая бета Xcode выйдет, я в тот же день в Mac AppStore релизнусь :) Я ещё никогда так не ошибался.

У меня в проекте была пара UI-зависимостей, Realm и Firebase, всё это было подключено через Carthage. От мелких зависимостей удалось избавиться быстро, но вот Realm на CoreData менять не хотелось. Тогда Realm объявил, что они начинают работу над поддержкой Catalyst, я стал ждать.

Realm уже давно, в принципе, поддерживал macOS, но добавить два фреймворка (iOS и macOS) с одним названием в проект не получалось, можно было бы закостылить, наверное, но я не стал. А потом Realm добавил поддержку Swift Package Manager и это заработало.

SPM, в принципе, ничего космического не делает, просто качает исходники, а при сборке проекта, фреймворк собирается под текущую архитектуру и линкуется в приложение. Но есть несколько проблем.

1. Фреймворк будет собираться очень часто, а мак улетает от этого на обоих своих вентиляторах. Xcode Clean — и очищается не только кэш, но и все собранные фреймворки. Как с Carthage — собрать всё в Build папку, и все время использовать потом — не получится.

2. Мой любимый баг. Если у вас конфигурации называются не Debug/Release, то проект у вас не соберётся, Xcode не сможет найти папку, в которой лежит собранный фреймворк. Потому что соберёт его в папку с названием конфигурации, а искать будет в папке Debug/Release.

Официальный сайт индийских разработчиков StackOverflow рекомендует вот такой, хм, воркэраунд. Но это настолько бешеный костыль, что я просто вернулся к Debug/Release названиям конфигураций. stackoverflow.com/questions/5716… pic.twitter.com/tFU4FxLMMF

Ещё одна проблема Swift Package Manager, что он не поддерживает бинарные фреймворки, только исходники. Это мешает многим начать использовать SPM, например, Firebase пишут, что добавят поддержку SPM, когда появится поддержка бинарников. Но, вроде, над этим уже работают.

Скорее всего у вас будут фреймворки, которые должны работать только в iOS или только в macOS, поэтому в таргете теперь можно настраивать, в какую архитектуру линковать фреймворк. А все import’ы таких фреймворков закрывать директивами if !targetEnvironment(macCatalyst)

Есть и еще одна проблема, в Run Script билд фазе нет директивы targetEnvironment, а, например, Fabric запускается через Run Script. Тут я нашёл одну полезную переменную окружения EFFECTIVE_PLATFORM_NAME, чтобы не запускать Fabric в Каталисте. pic.twitter.com/NqSfQIww5j

На этом подготовка к тому, чтобы проект у вас запустился на маке заканчивается и начинается работа с UIKit на маке, об этом в следующем треде.

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

Потом замечаешь различия. Например, можно менять размер окна, и если на iPad контент блёрится в Split-View при ресайзе, то в Catalyst — нет, а значит постоянно layoutSubviews.

Есть и нативное macOS-поведение: переход фокуса на следующий элемент по нажатию Tab, синяя рамка вокруг элемента, который в фокусе, скролл нативный десктопный. Но на этом схожесть заканчивается и начинаешь замечать насколько тач UI отличается от десктопного.

Например, свайп по ячейке UITableView для получения доступа к контекстным кнопкам, который на iOS уже стал дефолтным, на macOS абсолютно не в тему. Дефолтный TabBar тоже не очень смотрится, надо делать меню в списке слева или кнопки в верхней строке окна.

Сделать подобные меню в Catalyst можно, потому что не только UIKit-компоненты доступны, но и часть UI-элементов из AppKit. Apple нас потихоньку двигает к единым приложениям для обеих платформ, общим компонентам интерфейса и, видимо, объединению iOS и macOS.

Но если эти UIKit-практики хоть и выглядят не в тему, но хотя бы работают, то есть и то, что просто не работает в Catalyst, и самый факап с модальными окнами, их не закрыть.

В iOS13 модалки теперь можно закрыть жестами, поэтому кнопки закрытия я с них убрал, хотя потом почитал, что Human Interface Guidelines рекомендует их оставить для Accessibility. И если на iPad модалку можно тоже смахнуть, то на Catalyst она останется висеть посреди экрана.

Apple предлагает решать это через новое API UIScene. В iOS13 появился SceneDelegate наряду с AppDelegate. Казалось бы он нужен только для одновременного запуска нескольких UI-инстансов в одном сэндбоксе, но более актуальным он оказывается как раз для Catalyst.

Смысл UIScene в том, что для каждой сцены создаётся свой UIWindow, а вот у UIWindow на macOS уже есть дефолтные светофорные кнопки управления окном. Но тут надо будет опять через if available смотреть на окружение и открывать либо модально на iOS, либо в новой UIScene на macOS.

Немного про интерфейсы. Корень интерфейсов — UIWindow, который создается в AppDelegate iOS-приложения уходит корнями в исследовательский центр компании Xerox, который назывался Xerox PARC. Кто смотрел фильм «Пираты Кремниевой долины», наверное, в курсе. Для остальных, расскажу.

Window — один из четырех компонентов WIMP. А WIMP — это одна из парадигм создания GUI. Остальные три — Icons, Menus и Pointer.

В общем, все, к чему мы привыкли придумал Xerox, и знатно обосрался, когда позволил Джобсу и компании скопировать свои разработки. А Джобс повторил их подвиг, когда позволил сделать то же самое Гейтсу и компании. Именно поэтому Windows так называется :)

Кстати, интефейс macOS мог бы строиться вокруг другой парадигмы GUI, если бы Джобс не уволил Джефа Раскина из Apple на заре создания первого Macintosh.

Раскин топил за то, что называется ZUI (zooming user interface), т.е. бесконечный канвас, как в Miro, где можно по любой логике располагать контент. Как такового открытия файлов там нет, ты просто зумишь канвас, чтобы контент файла был на весь экран, правишь его и оставляешь.

Раскин был против модальности интерфейсов, когда какой-либо элемент закрывает возможность оперировать с другими элементами. На этой концепции Раскин сделал компьютер Canon Cat, а потом проект Archy.

Одна из составляющих ZUI (где нет поинтера, т.е. мышки) называется Leaping. Ты просто печатаешь текст, к которому хочешь «прыгнуть» и шорткатами прыгаешь по подходящим элементам на экране. Похожую концепцию реализует плагин AceJump для @intellijidea, попробуйте, может вам зайдет?

Привет, друзья! Сегодня в мобильном разработчике день без мобильной разработки! Я освежу в памяти дела пятилетней давности и расскажу про то, как работают печатные СМИ, откуда берутся новости и как их правильно читать. Ещё будет много оффтопа про то, как работают разные отрасли.

До перехода в IT я получил экономическое образование. Однако, ни дня не работал по специальности, потому что на третьем курсе занялся журналистикой. Потом переехал в Питер, тут получил образование журналистское и устроился в местную редакцию газеты «Ведомости».

В «Ведомости» меня взяли во многом за счёт экономического образования, потому что проще экономиста научить писать, чем журналиста врубаться в экономику и бизнес. В Питере я писал про производство, а через три года переехал в федеральную редакцию в Москву, где писал про нефтянку.

В Москве я проработал около года как раз во время одного из самых громких событий российской нефтянки последних лет, когда «Башнефть» превращалась из частной компании в государственную, посетил все суды по этому делу и ушёл сначала в PR, а потом в IT. Об этом позже расскажу.

Давайте сначала разберёмся с терминами. Мы будем говорить только про «печатные» СМИ, хотя их впору уже называть текстовыми, ведь от печати многие из них уже отказались, а у некоторых ее никогда и не было. До интернет-эпохи они хорошо делились по формату выхода на 4 вида.

ИНФОРМАЦИОННЫЕ АГЕНТСТВА. Associated Press, Reuters, Bloomberg, Синьхуа, в России Интерфакс, ТАСС, РИА «Новости» etc. Это поставщики новостей: их зовут на официальные мероприятия, они приходят и передают короткий текст о том, что произошло, сопровождая комментарием участников.

Информагентства часто называют лентами, это пошло из телеграфной эпохи, когда подписчики на них получали новости по телеграфу из аппарата, который просто печатал бесконечную ленту с текстом в одну строку.

Старейшие информагентства появились ещё до изобретения телеграфа. Например, Reuters передавал биржевую информацию из Лондона в Париж с помощью почтовых голубей и так получил статус самого оперативного новостного агентства.

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

ГАЗЕТЫ. Это ежедневная пресса, и их основная задача создать картину дня: т.е. взять всё самое важное, что произошло за день и выдать читателю в определенном порядке, чтобы он мог за 20-30 минут понять, что важного случилось вчера по темам, которые его интересуют.

Нынешние газеты, которые уже все перешли в парадигму online-first работают в том числе и как ленты, т.е. ведут на сайте бесконечную ленту новостей. Этим обычно занимается отдельная команда в редакции, а основная редакция всё так же работает на газетный выпуск.

Казалось бы, зачем, вообще, газетная редакция? Всё равно весь потребитель сегодня в онлайне и получает информацию там сразу, а не из газеты на следующий день. Но у газетной редакции задачи несколько другие, чем у редакции сайта.

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

Тексты, которые выходят в газете строятся иначе. Для газетной статьи сообщение из ленты является лишь инфоповодом, т.е. ответом на вопрос «Что произошло?», задача журналиста ответить на вопрос «Как это повлияет на рынок?».

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

Священный Грааль газет — это эксклюзивы, крутость журналиста определяется во многом тем, сколько и какие эксклюзивы он приносит газете. Эксклюзив — это материал, который вышел только в одной газете на основе информации, которую журналист сам нашёл и обработал.

О том как и где доставать эксклюзивы мы ещё поговорим, а пока третий тип.
ЕЖЕНЕДЕЛЬНЫЕ ЖУРНАЛЫ. Их почти не осталось, потому что интернет всё сожрал. Изначальная задача таких СМИ, взять то, что вышло в газетах и более тщательно проанализировать.

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

ЕЖЕМЕСЯЧНЫЕ ЖУРНАЛЫ. Они и до сих пор себя неплохо чувствуют, потому что почти не привязаны к новостям, а пишут лонг-риды по самым разным темам. Чтение таких журналов как чтение книг, интернет разве что поменял формат их доставки до потребителя, но не формат работы таких СМИ.

Давайте рассмотрим несколько статей из «Ведомостей», а я расскажу о том, что там написано между строк.

Начнем с простого. Такие новости присылает сама компания во все СМИ — это просто отчет за период. Там, где должна быть написана фамилия автора написано просто «Ведомости», потому что ничего авторского тут нет, просто пересказ сообщения.
vedomosti.ru/business/news/…

Вот эта история пришла из информагентства — из Интерфакса. В середине там есть ссылка на эксклюзив «Коммерсанта» про встречу Путина и Зеленского. В Интерфаксе утром прочитали про встречу, а потом попытались это подтвердить официально.
vedomosti.ru/politics/news/…

Официальная информация ценится больше, чем неофициальная (на основе неназванных источников). Заметка Коммерсанта написана на основе данных источников kommersant.ru/doc/4172046, и это круто, но следующий важный шаг — подтвердить это официально. И вот Интерфакс это делает.

Но Ушаков в тексте не сказал, что встреча точно будет, потому что он на себя такую ответственность брать не будет, а просто сказал, что, возможно, она состоится. Формулировки всегда очень важны в таких новостях, и есть куча способов передать информацию с нужным акцентом.

Заметьте, что опять же фамилии автора наверху материала нет, а значит написала редакция сайта, которая не добавляет новой информации, а просто компонует и ретранслирует.

А вот уже заметка с фамилией автора, а значит в тексте скорее всего есть либо новые данные о сделке, которые журналист сам нашел, либо комментарии участников сделки или аналитиков/экспертов, которые журналист сам собрал.
vedomosti.ru/business/artic…

Если в тексте нет ссылки на источник информации — другое СМИ — а просто фамилии и должности людей с цитатами, значит журналист или его коллеги из редакции взял эти комментарии лично при встрече или по телефону.

Обязанность журналиста — дать возможность высказаться каждой стороне сделки/конфликта. В этой заметке есть комментарий исполнительного директора «Нафтогаза» из Facebook и отказ от комментариев представителя «Газпрома» (PR-служба «Газпрома»). vedomosti.ru/business/artic…

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

Обратите внимание, что ни в одной из этих заметок нет оценки ситуации от самого журналиста, он не имеет права это делать в газетах, он собирает данные и комментарии других людей, объединяет их в текст и выдает читателю. У любой оценки должна быть фамилия и имя.

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

Тред про работу с источниками. Это самая важная часть в работе новостного журналиста. Потому что, как я уже говорил, все гонятся за эксклюзивами, а получить их можно только из собственных источников.

Тут всё строится на личных связях. У всех есть свои интересы, которые журналист должен понимать и уметь их правильно использовать. Находить таких людей и выстраивать с ними отношения — это целое искусство. Я так и не освоил это, отчасти поэтому ушел в IT.

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

Если в тексте есть цитата от «источника, близкого к компании» и он говорит то, что выставляет компанию в выгодном свете, то есть большая вероятность, что это пиарщик компании. Это согласовано с менеджментом, но менеджмент не хочет, чтобы это исходило от компании официально.

Следующий уровень — это сотрудники компании. У них стимулы могут быть разными: у кого-то ЧСВ и он не ведает, что творит, у кого-то личный интерес протолкнуть то, что он делает в компании, кого-то просто не научили работать со СМИ и он может слить что-то не очень хорошее.

Такие источники находятся на официальных мероприятиях, которые проводит компания. Но в крупных компаниях на официальные мероприятия обычно приглашаются только те, кто знает, что не надо ничего лишнего говорить в кулуарах.

Если вам удалось заручиться связями в одной компании среди менеджмента, и вам доверяют (понимают, что вы не будете на них ссылаться, если они этого не хотят), то от них вы можете узнать много интересного о конкурентах, но написать это будет сложно, потому что надо подтверждать.

Вообще, есть стандарты работы СМИ. Один из них — любая неофициальная информация должна быть подтверждена минимум двумя источниками, причем разными (это не должны быть сотрудники одной компании или одной стороны конфликта). Это бывает становится препятствием для написания текста.

Если есть ссылка на какой-нибудь внутренний документ компании, то журналист просит прислать документ и желательно еще подтвердить его контент у другого человека, который его видел.

У нас вновь созвон по @MobiusConf, продолжим после него. И конечно приезжайте все на Mobius, там будет интересно!

Хорошим источником могут стать чиновники. Потому что любой закон, как правило, требует новых денег или ограничений от компаний, поэтому чиновники часто готовы неофициально объяснять, почему они готовят те или иные законы. Заодно это для них хороший способ получить фидбек.

На обсуждение планируемого закона всегда приглашаются представители компаний с рынка, на который этот закон ориентирован. И компании всегда против любых новых ограничений. Но одно дело —позиция на этих обсуждениях, и другое дело — официальная позиция компаний в СМИ.

Хорошим источником могут стать руководители небольших компаний, которые работают с крупными компаниями. Они заинтересованы в хороших отношениях со СМИ и на нейтральные темы готовы говорить официально, а для хороших отношений со СМИ готовы сливать что-то интересное неофициально.

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

Итак, рабочий день журналиста. Начинается он в районе 12:00 потому что прошлый день закончился в районе 20:00-21:00. Бывает, что до 12:00 проходят встречи с источниками, потому что у них тоже работа же есть. Редакция сайта приходит раньше, но и уходит тоже.

Первый час уходит на то, чтобы почитать свежий номер своей газеты и газет конкурентов. В бизнес-журналистике — это «Ведомости», «Коммерсантъ» и РБК. Обязательно читаешь то, что касается твоей темы, потом какие-то интересные для тебя лично заметки, просто, чтобы быть в курсе.

Если в газетах конкурентов есть эксклюзивы по твоей теме, то такие заметки на жаргоне называются «прососом», а ты, соответственно, тему прососал. Скажете слово «просос» любому журналисту-новостнику и он сразу поймет, о чем речь. Предлагаю баги в коде тоже называть прососами.

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

У всех СМИ есть платный доступ к лентам информагентств, это отдельный интерфейс, в котором новости обновляются сразу. Ты можешь настроить там себе отдельные ленты по ключевым словам или смотреть ленту только по своей тематике, например. Всю ленту тоже можно смотреть, но там ад.

Информагентства в этих платных лентах не правят новости, которые уже выпустили. Если там была какая-то ошибка, то выпускается другое сообщение с корректировками или опровержением прошлой информации.

В общем, большинство инфоповодов — фактов, на основе которых потом пишутся заметки в газету — приходят из лент. Но твоя задача еще и искать эксклюзивы. Тут есть несколько вариантов.

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

Во-вторых, ты можешь прокачать тему, которую написали вчера-позавчера и уточнить какие-то детали. Любая новая информация по новости, которая уже вышла может стать источником новой новости.

Если у тебя хорошие отношения с пиарщиками, то ты можешь получить информацию до ее объявления, но под эмбарго (т.е. договоришься, что напишешь ее в определенный заранее согласованный день, но раньше других). Компании периодически дают такие эксклюзивы для поддержания отношений.

Если что-то появилось в лентах и это важная новость, то редакция сайта попросит тебя написать заметку на сайт, сопроводив ее бэкграундом (прошлой информацией, связанной с этой же новостью) и комментариями аналитиков/экспертов. Если не важная новость — то они сами ее напишут.

Если к 16:00 у тебя уже есть новость, которую ты напишешь в следующий номер — то хорошо. Если это эксклюзив — отлично! Если нет, начинаются вопросы от редактора. Вот представьте, к вам подходит PM и говорит: «Какой фичей ты порадуешь наших пользователей завтра?», а фич-листа нет.

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

Редакторы повыше статусом решают какие заметки поставить на обложки — на открытии газеты и внутренние «обложки», полосы, на которых собираются наиболее важные новости по разным тематикам. Они забирают у редакторов полос заметки, а редакторам полос надо снова заполнить место.

Нередкая ситуация, что новостей нет. Такое часто бывает перед крупными событиями, например все компании планируют объявить о сделках на Петербургском Экономическом Форуме и за неделю до него НИЧЕГО НЕ ПРОИСХОДИТ. Это проблема, потому что газета пустой выйти не может.

Новости, конечно не придумываются в таком случае, но бывает, что в газету попадают мелкие неважные события, которые в обычное время туда бы не попали.

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

Тут же может идти цитата от участников событий, официальная информация, короче, но без воды и повторений. Если заметка основана на информации от источников, то в начале надо показать, что источников несколько и дать их цитаты.

Дальше идет бэк — прошлая уже известная информация о факте. Например, идет суд, прошло новое заседание, в бэке кратко пишут, что было на прошлых заседаниях, потом с чего, вообще, этот конфликт начался и т.д. Короче, кратко пересказываешь предыдущие серии.

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

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

Вторая когорта экспертов — это юристы. Это в случае, если тема касается суда или какого-нибудь законопроекта. Они дают мнение о том, какие перспективы дела, комментируют решение судьи или дают правовую оценку законопроекта.

Экспертам ты всегда звонишь напрямую, их телефоны есть у всех и со временем у тебя скапливается большой файл с телефонами источников и экспертов, потому что хранить контакты только на телефоне небезопасно. Обычно для новости в газету делаешь до 10 звонков, а то и больше.

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

Хорошо, если в 18:00 ты закоммитил текст и перевёл его в следующий статус. Дальше его читает редактор полосы, он его правит, а попутно просит тебя собрать ещё комментариев, если они нужны для полноты картины. Часто это происходит уже в районе 20:00 и ты снова всем звонишь.

Если твою заметку забрали с полосы на обложку, то тебя читают другие редакторы, но смысл тот же, задают вопросы, если что-то не понятно и просят ещё комментариев, если их не хватает.

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

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

У редакторов могут возникнуть самые неожиданные вопросы. Есть хорошая история про это: журналист писал текст про убийство какого-то бизнесмена в 90-е, его убили на улице пока он гулял с собакой. Журналист все написал: про бизнес, про него самого, про то, как обнаружили тело...

Редактор долго читал, что-то менял, правил, задавал уточняющие вопросы, а потом повернулся к журналисту и такой: «А что стало с собакой?». Пришлось выяснять уже поздним вечером, что стало с собакой. Вроде незначимая деталь, но сторителлинг тоже имеет значение.

После редактуры идёт корректура. Там филологи устраняют все опечатки, ошибки, но не правят сами формулировки. Как только прошла корректура и вопросов больше нет, твоя работа окончена и можно идти домой.

После этого верстальщики ещё доделывают всякие мелочи по верстке и в районе 21:00-22:00 газета готова и уходит в печать. Ночью печатается и рано утром курьеры доставляют ее подписчикам.

Дедлайн в ежедневной газете каждый день, не помню точно время, в районе 20:00, вроде. Т.е. каждый день у вас полный производственный процесс: от «а, ещё дохера времени», до «ааааа, я нихера не успеваю», с матом, криками, постоянными поторапливаниями и релизом в конце.

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

Привет, всем! Сегодня у нас будет не очень насыщенный день, потому что тема будет не очень большая — Accessibility, а я наконец-то смогу сделать несколько задач в текущем спринте :)

А чтобы переход со вчерашней темы про журналистику обратно в IT был более мягким, расскажу вам про термин «boilerplate code», который пришёл в IT как раз из периодической печати.

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

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

Сами эти пластины (plate) были сделаны из прокатной стали из такой же, как и водонагреватели (boiler), поэтому их стали называть boilerplate, а контент на них boilerplate text.

Крупные медиа-компании продавали эти заготовки всем подписчикам, поэтому один и тот же текст без изменений выходил во многих газетах. Один в один код, который вы тянете из проекта в проект, да?

Моя история с Accessibility началась, когда я решил автоматизировать создание скриншотов в AppStore через fastlane, после того как в очередной раз перекроил весь интерфейс приложения. Для этого надо использовать UI-тесты, а они в Xcode работаю на Accessibility.

Основной инструмент, который используют незрячие люди в iOS — VoiceOver. Он при одиночном тапе произносит название элемента интерфейса, а при двойном активизирует нажатие на этот элемент. Если вы не используете сильно кастомные UI-компоненты, то VoiceOver работает из коробки.

Обычно VoiceOver проговаривает через паузу accessibilityLabel (тайтл кнопки), accessibilityValue (дополнительная строка, которую вы можете задать элементу), accessibilityTraits (тип элемента: кнопка, поле поиска и т.д., а также состояние: Active, Disabled и т.д.)

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

После того как я обновил приложение на iOS13 и перешел с UISearchBar во вьюхе на UISeachController в навбаре, Accessibility у меня сломалось. Для fastlane я просто закостылил — вместо нажатия на текстовое поле симулировал нажатие в точке с координатами на экране.

Проблема в том, что в UISearchController строка поиска — это вся вьюха контроллера, включая кнопку Cancel и что самое неприятное SegmentedControl с кнопками, которые у меня скоупы поиска (словарь, история, избранное). Приложение у меня — англо-русский словарь.

Проблема в том, что если один UI-элемент объявлен как Accessibility-элемент, то все, что внутри него «не видно» для пользователей: т.е. если у вас вьюха с тестом и кнопкой, то надо у View выставить isAccessibilityElement в false, чтобы VoiceOver видел отдельно текст и кнопку.

Мне после апдейта написал незрячий пользователь моего приложения и рассказал о том, как стало неудобно пользоваться. Часть элементов интерфейса просто пропала для VoiceOver, потому что даже в системных компонентах iOS Accessibility не везде настроен правильно.

После этого я стал смотреть на свое приложение по-другому. Это был инсайт. Мы тратим время на красивости: тени, градиентные заливки, шрифты, анимации, но забываем о людях, для которых интерфейс — это просто правильно проставленные строки, которые читает синтезированный голос.

Это не rocket science — проставить несколько флагов и строк UI-элементам, большего-то не требуется, но этого почти никто не делает. Для тестирования в Xcode есть Accessibility Inspector, который подсветит и покажет элементы так, как это «видят» незрячие пользователи.

Не забывайте, что стандартная кнопка «Добавить в избранное» со звездочкой без текста обычно работает и в обратную сторону. Мы это показываем заливкой, но в Accessibility она не видна, надо и текст для VoiceOver менять.

Я пришёл к тому, что везде меняю текст на кастомный. Например, кнопка смены языка с текстом EN RU, раньше произносила этот текст, и это звучало ужасно, теперь произносит «Сменить язык Английский». У меня словарь работает только с русским языком, поэтому второй язык я опускаю.

В общем, описание действия, которое сделает нажатие на элемент в общем случае лучше, чем просто текст на кнопке. Но тут тоже не надо перестараться. Основной флоу лучше не перегружать, а вот вспомогательные действия можно описать подробнее.

Некоторые элементы лучше, вообще, убрать для VoiceOver. У меня в словаре есть кнопки для произношения слов, они, очевидно, не нужны в этом случае. Незрячие люди пользуются девайсами с маленькими экранами, типа iPhone SE, это удобнее, поэтому не перегружайте интерфейс.

Привет, человек! Сегодня пятница, а значит в некоторых компаниях настали те 20% времени, которые можно тратить на второстепенные проекты. Вот о таких проектах сегодня и поговорим. В моём случае именно с pet-проектов и началось увлечение IT и разработкой мобильных приложений.

Я ещё в среду обещал рассказать о том, как я ушёл из журналистики в IT, поэтому начну с этого. Компьютера у меня не было до первого курса университета, зато сразу появился довольно мощный: с 256Мб оперативки и таким же объемом видеопамяти. NFS Underground летал на максималках.

С появление компьютера я увлёкся сначала графическим дизайном в PS и AI, даже искал работу дизайнером на втором курсе университета, а к третьему курсу ушёл из графики в текст.

Текст оказался той формой творчества, которая у меня получалась. Ещё я пробовал себя в музыке, видеомонтаже, сценарном деле, но там не удалось, разве что написал сценарий рекламного ролика для компании-производителя пластиковых окон, но даже не знаю, вышел ли он где-нибудь.

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

Однако, обнаружил я его для себя только в 2011 году, когда переехал в Питер и сделал себе сайт-портфолио на Drupal. Так себе программирование, конечно, но для начала сойдет. Тогда я работал в PR-службе одной юридической компании и мучал нашего вебмастера вопросами про Drupal.

В CMS я довольно быстро разочаровался, потому что CMS — это как кофе 3-в-1, а хотелось самому выбирать, сколько будет кофе, сливок и сахара в чашке. На хайпе в web тогда был Ruby on Rails, которым я потом и занимался следующие 4 года, попутно работая журналистом.

Моя до сих пор нереализованная мечта — сделать систему учета личных финансов на основе управления денежным потоком, а не упрощенного аналога бухгалтерского учета, что до сих пор никто не сделал. Сейчас я делаю это на SwiftUI, заодно изучаю все эти новые API iOS13.

Много времени на красивости. А есть вот такие мы, для которых главное - доступность. Приятно знать, что нас слышат. twitter.com/mobileunderhoo…

С появлением Swift я решил заняться iOS-разработкой, за окном шел 2014 год. Я пару раз пробовал подойти к iOS, когда там был Objective-C, но так как мне не хватало фундаментальных знаний по программированию и я сидел на Ruby-игле с динамической типизацией, ObjC казался мне адом.

Это сейчас после нескольких лет в IT и более глубокого понимания языков программирования, я знаю, что у Objective-C больше общего с Ruby, чем у Swift, но тогда казалось, что синтаксис решает, а у Swift он сильно проще.

В общем, после появления Swift я сделал себе приложение для конвертации разных нефтегазовых единиц, которым пользовался, когда в «Ведомостях» писал про нефтянку, потому что все компании отчитываются в разных показателях, а надо было все приводить в единый формат.

Я выложил его в AppStore по цене в $1 и на следующий день планировал проснуться миллионером. Проснулся. Продаж — 0. Тем не менее, мне настолько понравилось ощущение, что я могу сделать себе нужный хелпер, который будет тут же в мобильном телефоне, что я продолжил.

Следующий хелпер, который я себе сделал — это англо-русский словарь Мультитран. У него до сих пор есть только сайт, а приложение для Android появилось только в этом году. А мне нужно было приложение для iOS. Я его сделал и оказалось, что нужно оно не только мне.

Тогда даже у Хабра не было официального клиента под iOS, но был хороший неофициальный. В общем, это было время, когда мобильные разработчики могли делать неофициальные клиенты для разных веб-проектов, mobile-first тогда только набирал обороты.

В общем, моим приложением до сих пор пользуются люди, изучающие или профессионально занимающиеся иностранными языками. Для большинства запросов оно использует мою базу переводов. Я поменял иконку и название. Проект вырос. А Мультитран всё ещё готовит собственное приложение.

В 30 лет, когда я уже ушел из журналистики и работал в PR-службе одной из дочек «Газпром нефти», я решил, что пора уходить в мобильную разработку. У меня уже был опыт на собственном проекте, но не было профильного резюме с портфолио проектов.

На HeadHunter я нашел вакансию iOS-разработчика с желательным знанием Ruby on Rails (двойное попадание в мой стек) в компании Roxosoft. Их основной стек был на Windows, но у них появился проект с мобильными приложениями и бэком на Rails, и меня взяли.

Это был фуллстечный фуллстек: я делал iOS-приложение, допиливал бэк под мои нужды, а потом эту же функциональность делал еще и в Android-приложении. Там еще был фронт на Angular, но этим занимались другие люди. Через полгода проект попытался выйти на IPO, не смог и закрылся.

Я начал искать новую работу, где я мог бы работать в команде, а не один, прошёл шесть собеседований за месяц и оказался в @REDMADROBOT. Там я быстро прокачал хард-скиллы, а с софт-скиллами после 10 лет в журналистике и так было все в порядке :)

Давайте тут сделаем тред, где вы расскажете о своих pet-проектах и что вас сподвигло их начать. Возможно, кто-то из подписчиков начнет ими пользоваться.

У меня это словарь иностранных языков MT. apps.apple.com/ru/app/id10904… Им я занялся потому что мне нужен был удобный мобильный интерфейс для Мультитрана, а сейчас играю в нём в iOS13, изучаю новые API и прокачиваюсь заодно в Ruby on Rails в серверной части приложения.

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

Если у вас есть собственное мобильное приложение, то вам будет полезно знать, как их продвигать. Я не большой эксперт в этом, но несколько советов дать могу.

В AppStore есть несколько полей, которые попадают в индекс и по которым вас можно найти. Это заголовок, подзаголовок и ключевые слова. Описание приложения НЕ ИНДЕКСИРУЕТСЯ AppStore'ом, но описание индексируют web-поисковики. Тем не менее искать вас будут больше в AppStore.

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

Еще мне рассказывали такую историю, что AppStore некоторые регионы склеивает в индексе, но я нигде не вижу подтверждения этого. Но кажется логичным, что ключевые слова в US, GB и AU сторах могут индексироваться вместе, так как там везде английский, а слова могут быть разными.

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

Если у пользователя стоит английский язык системы, но российский стор, то он будет видеть страницу приложения из американского стора, а найти приложение можно будет как по названию из российского, так и из американского сторов.

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

Отзывы, оценки и средняя оценка имеют значение. Думаю, что для места в поиске тоже, но для желания установить — точно. Не гнушайтесь системным алертом iOS с оценкой. Но выбирайте время, Apple не даст вам показать этот алерт больше 3 раз в год пользователю.

Я в своем приложении показываю его один раз для пользователя. За два года у меня было 400 оценок со средней 3.9, за неделю после начала показа оценок стало 800, а средняя выросла до 4.7. Сейчас оценок больше 13 000, средняя 4.8.

Один раз я попал в фичеринг. Это было во время ЕГЭ, мое приложение было последним в списке приложений для подготовки к экзамену по иностранным языкам. Т.е. надо было открыть список на главной в AppStore и домотать до конца, но и это увеличило загрузки в три раза.

Для того, чтобы попасть в фичеринг можно написать прямо редакторам AppStore, у Apple есть форма для этого. Кроме того, редакторы могут сами отобрать ваше приложение, шансы увеличиваются, если у вас все хорошо с Accessibility или вы используете новые API, типа Sign In with Apple.

Есть и куча кейсов, когда версию могут реджектнуть из-за нарушений правил публикации. У меня были реджекты, но это быстро решалось. Через неделю на @MobiusConf Марина Плешкова из @mailru расскажет очень много полезного про реджекты и как работать в этом случае с техподдержкой.

Завтра буду весь день постить в аккаунте Мобильного разработчика. Несмотря на то, что я не очень-то мобильный, и совсем не разработчик. Но, видимо, после того как меня зафоловил @_bravit это уже не имеет значения! Так что подписывайтесь, если интересно. twitter.com/mobileunderhoo…

PT: Шалом, пацаны и девчонки! Сегодня будем про инвестиции говорить. Соавтором будет Павел Комаровский @Rational_Answer, который рассказывал про инвестиции на прошлой AppsConf. Мнения у нас могут не совпадать, но тем лучше. В твитах будем подписываться RA и PT, соответственно.

PT. Я начал вкладывать свободные средства в акции где-то три года назад, весной всё снял, чтобы взять ипотеку и теперь снова начинаю откладывать часть денег на инвестиции, хотя гасить ипотеку выгоднее. Но диверсификация, знаете ли.

PT. Среди всех инструментов фондового рынка акции мне нравятся больше, хотя это более рискованный актив. В облигациях меньше риска, но и доходность ниже. Есть ещё индексные фонды, про них лучше расскажет @Rational_Answer, он держит деньги там, насколько я знаю.

RA/1. Всем привет! Меня зовут Павел Комаровский, я веду блог @Rational_Answer про разумные ответы на жизненные вопросы. Не шарю в мобильной разработке, зато разбираюсь во всём, что касается денег (но это не точно). В этом треде расскажу о своих взглядах на инвестирование. pic.twitter.com/oOPVNY1hHM

RA/2. Сначала немного о себе. В универе изучал экономику, потом 7 лет работал финансовым аудитором. З/п была хорошей (для региона), получалось много откладывать. Всё клал на банковские вклады + купил квартиру (аудиторам по требованиям независимости нельзя покупать ценные бумаги).

RA/3. Потом переехал в Москву, сменил работу на ещё более доходную, вопрос разумного управления капиталом стал даже более актуальным. Думал, спрошу у коллег - там все умные и богатые, поди давно нашли все правильные ответы.

RA/4. Но оказалось, что почти у всех деньги "просто лежат в долларах на счёте", или люди всё так же вкладываются в недвижимость. Стало понятно, что придётся глубже вникать в тему самостоятельно - начал смотреть и читать, кто что думает. Выводы оказались печальными.

RA/5. В интернете полно персонажей, которые грозятся "рассказать вам всю правду об управлении деньгами", но доля тех, кто говорит правильные и разумные вещи уверенно стремится к 0,1%. В финансовой индустрии ситуация ничуть не лучше.

RA/6. Причём, чем активнее вас в чём-то убеждают, тем больше вероятность, что вас пытаются обуть. Большинство финансовых блогеров и гуру что-то вам продают: свои услуги, свои продукты, чужие продукты (за комиссии) и т.д. Этот конфликт интересов сводит на нет полезность их советов

RA/7. Поэтому я решил сделать свой блог про инвестиции, который будет давать абсолютно независимую точку зрения. Это единственная причина, почему стоит прислушиваться к моим словам - в остальном у меня нет никаких заслуг (в том числе каких-то крутых успехов на фондовом рынке).

RA/8. Вообще, здоровый скептицизм и неприятие авторитетов - это самый главный залог принятия правильных решений в инвестировании. Причём этот подход должен распространяться не только на чужие мнения, но и на ваши собственные. Обманывать себя легче, чем кого бы то ни было.

RA/9. В треде будет много текста. Если вам удобнее посмотреть всё то же самое про инвестиции, но в живом виде и с картинками - то можете глянуть видео моего выступления на ~40 минут с AppsConf: youtube.com/watch?v=ZMvhEX… pic.twitter.com/BFlYDm6bid

PT. Два года подряд на акциях мне удавалось делать порядка 20% годовых, это в принципе адекватная доходность с приемлемым уровнем риска, но каждый год было несколько драйверов, которые и обеспечивали весь рост. Остальные тянулись в хвосте, а то и, вообще, в минусе были.

Если бы таких драйверов не было, рост был бы сильно меньше, а то и не было бы, вообще. Но в этом и смысл диверсификации. Важно раскидывать инвестиции не только по эмитентам, но и по отраслям. Не более 10% в одного эмитента, не более 30% в одну отрасль, так я формирую портфель.

PT. Сегодня хороший день для вопросов, потому что инвестиции — слишком большая тема, чтобы два хипстера рассказали про неё за один день. Задавайте вопросы. У Паши много знаний не только своих, но и от людей, с которыми он интервью проводит у себя в блоге.

PT. Хороший вопрос. Технически можно с любой, конечно. По 1000 в месяц на счёт класть и через год будет 12000 инвестиций и предположим 2000 процентов. Это очень хороший результат, ведь инвестировали-то вы не всю сумму сразу, но получите ли вы удовлетворение от 2000 за год? t.co/s0dHVkH0Nd

PT. В инвестициях самое главное — это регулярность. Поэтому лучше начинать не с крупной суммы, а с процента от дохода, хотя бы с 5-10%, и каждый месяц этот процент класть на брокерский счёт.

RA/10. Первое, о чем вам надо задуматься, это зачем вообще откладывать деньги. Во-первых, надо всегда иметь в доступе какую-то заначку, которая покроет ваши расходы минимум месяцев на 4-6. Это позволит вам чувствовать себя комфортно и не беспокоиться о завтрашнем дне.

RA/11. А что еще важнее - это развяжет вам руки, чтобы принимать более рискованные решения в отношении своей карьеры. Чем вы моложе, тем важнее инвестировать именно в себя и свои знания - потому что отдача от таких вложений будет гарантированно выше любых финансовых инвестиций.

RA/12. Мне нравится концепция человеческого капитала - это сумма всех ваших будущих заработков. Если вы в 25 лет получаете 100 тыс./мес., то до 65 лет вы сможете заработать 48 млн руб. Это, грубо, ваш текущий человеческий капитал.

RA/13. Можно его наращивать, повышая свою зарплату. Но в целом, рано или поздно он начнет падать - просто потому, что "рабочих лет жизни" будет оставаться меньше. Всё просто: сейчас вы богаты и у вас капитала на 48 млн руб., а через 40 лет от него ничего не останется.

RA/14. С этим можно бороться, только откладывая часть зарабатываемых денег и увеличивая свой финансовый капитал. В идеале, хорошо было бы дойти до точки полной финансовой независимости - когда пассивные доходы с капитала полностью покрывают все потребности.

RA/15. Сколько для этого надо денег, можно прикинуть обратным счетом. Обычно считается, что ежегодно в течение долгого времени можно тратить не больше 4% от накопленного капитала. Так что для пассивного дохода в 100 тыс. в месяц нужно 100 000x12/0,04 = 30 млн руб.

RA/16. Это большая сумма! Чтобы накопить ее, придется 30 лет откладывать ежемесячно по 40 тыс. руб. (предполагая реальную доходность на инвестиции за вычетом инфляции в 5%).

RA/17. На самом деле, в России полная финансовая независимость для 95% людей - это скорее недостижимая утопия. Но для людей с зарплатой существенно выше среднего - это вполне достижимая цель. К счастью, девелоперы относятся как раз к такой категории.

RA/18. Нужно ли это вам - это отдельный большой вопрос. Но я считаю, что сберегать хотя бы 20% своей зарплаты лучше каждому из нас - хотя бы потому, что это сильно повышает круг возможностей, которые можно использовать в жизни.

PT. Про ИИС. У мен есть один большой вопрос к ИИС, поэтому, если вы знаете, что это такое, то все равно почитайте этот тред, и если вы скажете мне, что я не прав, я буду рад :) Потому что, вопрос как раз про пресловутые 13% годовых.

Индивидуальный инвестиционный счёт — это обычный брокерский счёт, но с рядом бонусов и ограничений.

Основной бонус — вы можете получить 13% от суммы ВЗНОСОВ на этот счёт в течение года, но не больше 52 000₽, соответственно максимум 400 000₽ взносов за год, можно больше, но 13% от превышения вы не получите.

Основное ограничение — после открытия ИИС деньги с него нельзя снимать три года. Т.е. можно класть, можно покупать-продавать ценные бумаги, но снимать только через три года. Иначе бонус теряется, и если вы им воспользовались, придётся вернуть.

Придумана эта штука для того, чтобы сподвигнуть людей к инвестициям на фондовом рынке. Для государства это выгодно, потому что оно может занимать у населения через гособлигации, а не на внешнем рынке, а компании могут занимать у населения, минуя банки.

А теперь про 13%. Как работают 13% ГОДОВЫХ здорового человека. Я положил 400К, через год получил 52К процентов, не стал забирать 400К, но и добавлять ничего не стал, и через год снова получил 52К. Именно поэтому 13% ГОДОВЫХ, они приходят КАЖДЫЙ ГОД.

Как работает 13% индивидуального инвестиционного курильщика. Я положил 400К, через год вернул 52К, но дальше эти 400К мне не приносят доход следующие два года. Чтобы получить ещё 52К, мне надо вложить ещё 400К, и через год сделать то же самое.

Снимать деньги мне нельзя три года. Получается, я получил с первых 400К 13% за три года, со вторых 400К 13% за два года, с третьих 400К 13% за год и только потом могу вернуть свои 1.2М.

Нехитрая математика показывает, что 13% годовых есть только у 400К, инвестированных на третий год, у вторых 400К — 13/2 = 6.5% годовых, и у первых 400К — 13/3 = 4.33% годовых. По сути в итоге вы получите 156К с инвестиций в 1.2М — это 13% за три года, но не годовых.

Вот скажите мне, я правильно все понимаю, или путаю педали? Потому что я не понимаю, почему везде поют песни про 13% годовых, которых нет.

RA/19. Если вы всё же готовы формировать финансовый капитал, то вам надо решить, с помощью каких инструментов (активов) вы будете это делать. Здесь людей обычно подстерегает две ошибки:

RA/20. Во-первых, люди смотрят только номинальную доходность. Которая абсолютно ничего не значит! Имеет значение только реальная доходность, за вычетом инфляции. Депозит, которые приносит 5% в год, при инфляции в 10% на самом деле является убыточным активом.

RA/21. Во-вторых, люди думают в категориях "куда вложить выгодно на год вперед". А лучше бы думать в масштабах всей своей жизни, на долгосрочном горизонте - тогда все правильные ответы получаются совершенно другие.

RA/22. Например, сберегать деньги и вкладывать их в наличность (хоть рубли, хоть доллары, хоть евро) - это полная глупость. За год с деньгами ничего не станет, а вот через 20-30 лет инфляция сделает из этого "капитала" бесполезные фантики.

RA/23. Депозиты не сильно лучше. В самом оптимистичном развитии событий вы отобьете инфляцию, но ничего не заработаете сверх. 30 миллионов так не скопить!

RA/24. Недвижимость - уже вариант получше, но динамика цен на нее не очень предсказуема, а хлопоты по сдаче квартир можешь сильно попортить жизнь. Если аккуратно посчитать реальную доходность вложений в недвижимость, то результат вполне может сильно разочаровать.

RA/25. Поэтому если анализировать длинные промежутки времени (20-30 лет), то самым доходным вариантом без вопросов оказываются акции (со средней реальной доходностью ~5%). Только вложения в бизнесы, которые постоянно генерируют ценность, показывают лучшие результаты на долгосроке

RA/26. В акции вкладываться страшно, потому что через год их цена может как увеличиться на 50%, так и упасть в два раза. Ощущать это своим кошельком очень неприятно. Но если брать промежутки лет в 20, то акции практически всегда сильно обгоняют все остальные варианты.

RA/27. Вот так ограниченность горизонта несколькими годами вперед заставляет вас принимать неправильные решения. "Просто положить на депозит" кажется безопасным решением на год вперед, но для 20 лет - это попытка выиграть, делая ставку на дохлую лошадь.

RA/28. Помните, мы считали, что можно накопить 30 млн, откладывая по 40 тыс. руб. в месяц с реальной доходностью 5% 30 лет? Так вот, это работает только с инвестициями в акции. Если вы кладете деньги на депозит с реальной доходностью 0%, то вам понадобится > 60 лет. Удачи, лол!

RA/29. Но даже если вы полны решимости инвестировать в акции, легче от этого не становится. Возникает масса вопросов, от которых пухнет голова. Что покупать конкретно? На какой бирже, через какого брокера? Как следить за всем этим? Omg, this stuff is hard

RA/30. Возникает вполне понятное желание переложить ответственность за все эти сложные вопросы на кого-нибудь умного. И это не так сложно! В любом банке или брокере найдется чувак в галстуке, который с радостью вам поможет - с вашей стороны потребуется только бабло подтаскивать.

RA/31. Только вот решения, которые он будет вам предлагать, будут выгодными для него, а не для вас. А у вас, если вы совсем не в теме, не хватит знаний и здравого смысла, чтобы распознать, в чем подвох.

RA/32. В России, например, очень популярны ПИФы (паевые инвестиционные фонды). Типичный ПИФ активного управления заряжает комиссию около 5% в год. Какая там долгосрочная реальная доходность рынка акций? Правильно, 5%. Just do the math.

RA/33. Не лучше разные виды страхования (инвестиционное страхование жизни, unit linked для более обеспеченных слоёв), разные структурные ноты "с защитой капитала", и прочая ерунда. Напоминаю: чем активнее вам что-то предлагают, тем сильнее нужно напрягаться.

RA/34. Кто-то думает: ну ок, эти ребята возьмут небольшой процентик себе, но зато они умные - выберут САМЫЕ ЛУЧШИЕ акции и вложат в них. И доходность будет выше, чем эти жалкие 5% в год. Спойлер: этого не произойдет.

RA/35. Огромная куча накопленной статистики и исследований показывают: все эти активные управляющие за вычетом своих комиссий показывают результат хуже среднего. На горизонте 3-5 лет 80-90% активных фондов отстают от среднерыночного результата.

RA/36. То есть, ваша доходность будет лучше, если вы просто бездумно купите все подряд акции, которые продаются на рынке, чем если доверите выбор акций "профессионалу" в дорогом галстуке.

RA/37. Если же вы наивно думаете, что сможете выбрать тот самый фонд, который войдет в 10% обогнавших рынок, то расслабьтесь: все так думают. Только вот способов надежно понять, кто будет в дамках, нет.

RA/38. Особенно бесполезен любимый всеми вокруг метод "я просто посмотрю, у кого был хороший результат за последние ХХ лет, и вложусь туда". Но статистика показывает, что результаты фондов в прошлом вообще никак не помогают предсказать их будущую доходность.

RA/39. Короче, не надейтесь просто заплатить кому-то другому и полностью снять проблему управления капиталом со своих плеч. Люди с радостью возьмут с вас деньги за эту услугу - ведь все риски остаются на вас!

RA/40. Но и самостоятельно начать правильно управлять своим капиталом непросто. Надо же еще решить, как это делать. На запрос наподобие "хочу научиться инвестировать" на вас вылетит ворох предложений в стиле "стань трейдером на Форекс за 2 часа!"

RA/41. Obviously, it's a trap! Форекс-трейдинг - это ужасающая помойка, на которой можно только со свистом проиграть все деньги (и приобрести ценный опыт бытия лохом).

RA/42. Ежедневный трейдинг ценными бумагами с использованием технического анализа (которому вас будет рад бесплатно научить любой брокер) не сильно лучше. Это большая трата времени с крайне сомнительной по итогу доходностью.

RA/43. По некоторым исследованиям, где-то не более 1% ежедневных трейдеров создают для себя какую-то ценность, вместо получения убытков или той самой среднерыночной доходности.

RA/44. Чуть лучше фундаментальный анализ - это когда вы придирчиво изучаете отчетности компаний, выбираете самые недооцененные акции, и надолго инвестируете в них. Как Баффет. Баффет умный - фигни не посоветует!

RA/45. Ой, подождите, почему-то сам Баффет говорит, что подавляющее большинство частных инвесторов получит гораздо лучший результат, если будет не выпендриваться с выбором "самых лучших акций". И дед, на мой взгляд, абсолютно прав!

RA/46. Помните исследования чуть выше про то, что почти все профессиональные активные управляющие в итоге проигрывают среднерыночному результату? Так вот, вы в ещё более худшей ситуации, чем они. У них есть профильное образование и возможность full-time думать только про акции.

RA/47. И вот появляетесь вы - не сильно-то уж подкованные в корпоративных финансах и бухгалтерском учете, и с возможностью потратить на выбор акций пару часов на выходных. Кто покажет лучше результат? А чёрт его знает, но в любом случае, ваши шансы обогнать рынок вряд ли выше.

RA/48. Зачем тогда тратить своё драгоценное время на эти попытки заработать сверх-доходность? Если практика показывает, что это чаще всего недостижимо, то самое логичное - согласиться на получение среднерыночной доходности.

RA/49. Тем более, что она не такая уж плохая (по сравнению с депозитами с нулевой доходностью). Ваш капитал скажет вам спасибо, если вы основные усилия будете направлять на развитие своей карьеры и повышение зарплаты, а инвестировать будете пассивно - в весь рынок сразу.

RA/50. Итак, пассивное инвестирование. Сначала выбираем распределение капитала по классам активов. Если молодой - то логично брать больше акций; старый и пугливый - больше облигаций. Совсем новичкам на рынке лучше начинать с чего-то вроде 50% акций/50% облигаций, чтобы освоиться.

RA/51. Затем, внутри классов активов стараемся обеспечить максимальную диверсификацию (раскладываем яйца по многим корзинам). Диверсификация нужна для снижения рисков (без снижения ожидаемой доходности). Поэтому не берем 5 акций, берем 500 акций.

RA/52. Покупать сотни ценных бумаг муторно и трудноосуществимо - но можно купить на бирже фонд, который внутри себя всё делает за вас. Нас интересуют индексные фонды - ETF. Выбираем подходящий, смотрим чтобы ежегодные издержки были небольшими.

RA/53. Диверсификации мало не бывает. 500 акций лучше 5 акций. Рынки нескольких стран - лучше, чем рынок одной страны. На западных биржах есть ETF на любой вкус - вплоть до того, что можно купить акции всего мира за сотню баксов (с годовыми издержками меньше 0,1%).

RA/54. На отечественной бирже выбор поскуднее - наиболее адекватную линейку ETF предлагает FinEx (но издержки получатся повыше зарубежных - до 0,9%).

RA/55. В снижении издержек - самое главное дао пассивного инвестирования. Управлять своей доходностью особо не получится (она зависит от рынка, а не от ваших действий - ну, помимо выбора пропорций классов активов). А вот снижать свои издержки - это вы можете.

RA/56. Поэтому все усилия должны быть направлены на то, чтобы поменьше платить кому бы то ни было - брокеру, посредникам, фондам, и т.д. И про налоги не забывайте! Российская ставка в 13% является вполне божеской (по сравнению с западными), но даже она может подъесть доходность.

RA/57. Снижать налоги можно разными способами. В России есть льгота на трехлетнее владение ценными бумагами, обращающимися на российской бирже. То есть, если не мельтешить продажами туда-сюда, можно налогов вообще почти не платить. Из облигаций ОФЗ не облагается налогом.

RA/58. Выше по течению ленты Петя писал про ИИС - это очень крутая штука. Мне кажется, иметь ИИС и получать вычет по 52 тыс. руб. ежегодно должен каждый разумный российский гуманоид.

RA/59. На выступлениях иногда рассказываю про ИИС так: представьте, что у вас из кармана выпали 52 тыс. руб. - вы нагнетесь, чтобы их поднять? То же происходит с вами каждый год: государство забирает у вас налоги, а вы можете часть вернуть простыми действиями.

RA/60. Не могу придумать причин, почему кто-то не захочет забрать у государства свои собственные 52 тысячи в год (если, конечно, вы вообще платите НДФЛ 13%). А у вас есть ИИС? Если нет - напишите, пожалуйста, почему

RA/61. Всякие технические мелочи, вроде "где лучше открыть брокерский счет", обсуждать особо не хочется. Это, если честно, наименее важная часть инвестиций.

RA/62. Пару слов всё же скажу: если открываете у российского брокера, то он все налоговые вопросы возьмет на себя, это удобно. Но на зарубежные биржи вас в этом случае пустят, только если вы подтвердите статус квал. инвестора (например, шестью миллионами рублей в кармане).

RA/63. Можно открыть счет сразу у зарубежного брокера и покупать что хочешь. Из зарубежных очень хорош Interactive Brokers. Но тогда придётся подавать налоговую декларацию ежегодно самостоятельно. И с суммами меньше ~20 тыс. долларов лезть зарубеж нет большого резона.

RA/64. Давайте еще немного поговорим о риске. Если вы вдохновились всем, написанным выше, и готовы стать долгосрочным инвестором в акции, то вы должны быть готовы неоднократно потерять минимум 50% капитала.

RA/65. То есть, не то чтобы нужно готовиться к этому как к теоретической возможности - нет, долгосрочный инвестор в акции обязательно несколько раз испытает это на своей шкуре несколько раз за жизнь. Если бы не было такого риска - то и нормальной доходности не получилось бы.

RA/66. После таких просадок придётся ждать несколько лет (в особо печальных случаях - лет 5-10, например), когда капитал восстановится. В это время вы будете чувствовать себя самым глупым человеком в мире, который за каким-то чёртом зря полез на этот грёбаный фондовый рынок.

RA/67. Я это пишу затем, чтобы вы не думали, что всё настолько просто и безоблачно - знай, закидывай себе бабло в индексные фонды и не парься. Да, сама идея простая. Но психологически это делать будет очень сложно. Именно поэтому так мало людей занимаются инвестированием.

RA/68. Если такие перспективы вас пугают, то это нормально. Главное при этом еще и понимать, что альтернатива не менее печальная: не инвестируя в акции, вы на протяжении своей жизни гарантированно получите убыток значительно больше.

RA/69. Просто он носит скрытый характер и поэтому воспринимается психологически проще. Ну, подумаешь, инфляция всё съела - но это было так медленно и незаметно, и деньги-то сами никуда не делись...

RA/70. Подумаешь, недополучил гигантскую доходность в течение 20 лет - но её же тебе нигде не начисляют и не расчитывают, так что на это можно просто не обращать внимание. Главное, денежки в безопасности лежали!

RA/71. Мне кажется, если бы люди по умолчанию ожидали получать реальную доходность на капитал в размере 5% годовых, а всё что ниже воспринимали бы как убыток - то все эти идеи "класть только на депозит, держать в долларах на счёте" умерли бы очень быстро.

RA/72. Поэтому главный успех инвестирования - он в голове: нужен правильный образ мышления, правильный долгосрочный горизонт, правильный фрейминг. При этом такой образ мышления - он на самом деле несвойственен человеку, биологически мы на другое настроены.

RA/73. Напоследок подолью ещё противоречивости. Я, как вы понимаете, топлю за то, что нужно закупиться индексными фондами акций и сидеть с ними 20 лет подряд, не дергаясь. Типа, все исследования показывают, что это самый разумный подход.

RA/74. Но при этом у меня сейчас относительно внушительный капитал, в котором акций нет совершенно. Я такой делаю вид, что я самый умный, и ожидаю большую коррекцию на рынке акций в ближайшие 2-3 года. А как она произойдёт - я так и закуплюсь сразу надолго.

RA/75. Нетрудно увидеть здесь некоторое (мягко говоря) противоречие. По сути я пытаюсь заработать доходность выше среднерыночной, на основе своих туманных предсказаний. Я что, дурак? Пожалуй, что нет - я просто обычный человек, подверженный тем же заблуждениям, что и все.

RA/76. Ну, или гениальный инвестор, который прозорливо предвидел будущее. Один из вариантов вы сможете выбрать через несколько лет, когда станет понятно, куда дунул ветер. (Спойлер: даже тогда ничего будет не понятно, потому что всё может совпасть абсолютно случайно)

RA/77. Пару слов, почему я включил консерватизм на максималки: есть такой показатель CAPE, который рассчитывается для рынков разных стран. Берешь текущую цену всех акций на рынке, делишь на среднюю их прибыль за последние 10 лет - вот тебе и индикатор.

RA/78. Большой CAPE исторически соответствовал посредственным будущим доходностям, маленький CAPE - отличным доходностям. Сейчас в Америке CAPE просто зашкаливает, выше был только в 1929-м и 1999-м годах (кончилось всё это pretty bad). Делайте, как говорится, выводы.

RA/79. А вот у российских акций сейчас CAPE очень маленький, что как бы намекает, что надо брать. Но если в США всё зашатается, то у нас уж и подавно от страха начнут всё подряд продавать. Так что ситуация неоднозначная.

RA/80. Ну и главное во всём этом: нет никакой гарантии, что этот самый CAPE в будущем будет работать так же, как работал раньше. И даже если будет большая коррекция, никто не знает точно когда - и не вырастет ли перед этим рынок ещё раза в два.

RA/81. А вот сидение "на обочине" в страхе коррекции без ценных бумаг в долгосрочном периоде выглядит очень плохой идеей. Так что я свой выбор сделал, но оцениваю вероятность того, что я сам делаю глупость весьма высоко (ну эдак на 40%). И вас повторять за мной не призываю.

RA/82. На этом пока пожалуй всё. Если есть вопросы - задавайте, буду рад ответить!

RA/85. Также, если было интересно, можете подписаться на мой Телеграм-канал. Там по большей части про инвестиции, но периодически пишу/снимаю видео и про рациональный подход к жизни в целом:
t-do.ru/RationalAnswer

Привет! Похоже вчера был лучший тред за всю историю мобильного разработчика :) Если у вас ещё остались вопросы про инвестиции, пишите Паше @Rational_Answer, а лучше подписывайтесь на него в Twitter и YouTube! А сегодня последний день моей вахты тут. music.apple.com/ru/album/seven…

Я не успел рассказать в пятницу про то, как получать доходы со своих pet-проектов легально на ИП. Там может быть много подводных камней, если у вас есть хорошие примеры граблей, на которые не стоит наступать, пишите!

Через ИП работать выгоднее, государство от вас потребует только 6% от дохода, а без ИП — 13%. Но есть и обязательные платежи, порядка 32 000₽ в год, однако, если у вас нет сотрудников, то можно уменьшить налог на всю эту сумму; если сотрудники есть, то на 50% от неё.

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

Самое главное: как получать деньги на счёт ИП и как по ним отчитываться. Я рассмотрю два контракта, которые у меня есть: с Google (доходы за рекламу от AdMob) и с Apple (доходы от in-app‘ов).

По правилам AdMob деньги вы можете получить только на валютный счёт, поэтому надо будет его дополнительно открыть в дополнение к рублёвому. При этом счёта будет два: сначала деньги будут падать на транзитный счёт, а после проверки валютным контролем на основной счёт.

Как только вы получите первый платёж от Google, валютный контроль попросит вам предоставить контракт и обосновать полученную сумму. Но что такое контракт с Google? Не то, чтобы Ларри Пэйдж с вами что-то подписывал и синюю печать на договоре ставил.

В этом случае контракт — это оферта с AdSence, которую можно найти на сайте. А вот дата начала контракта доказывается скриншотом письма от AdMob, где вас поздравляют с открытием нового аккаунта. У меня с этим возникла одна проблема при первом платеже.

Я не стал заморачиваться и просто в своём текущем аккаунте AdMob поставил новый счёт для оплаты, который был счетом ИП. Но когда валютный контроль попросил у меня письмо с датой создания аккаунта, оказалось, что аккаунт у меня создан до момента организации ИП.

Такой контракт они завести не могли и мне пришлось писать заявление в банк, в котором я просил вернуть $700 обратно отправителю, как ошибочно полученную. Потом я завёл новый аккаунт в AdMob и следующий платёж получал уже на него.

Эти $700 вернулись на старый аккаунт только три месяца спустя, я уже и забил на них, потому что с техподдержкой у AdMob всё очень плохо. Но всё-таки они вернулись, и на следующий месяц я их вывел просто на счёт физлица.

У контрактов, которые вы отправляете валютному контролю, есть ещё одна особенность. Для экспортных контрактов (когда вы получаете деньги из-за рубежа за оказанные услуги) есть ключевая цифра в 6 млн руб. Для импортных (когда услуги оказывают вам) — 3 млн руб.

Пока вы не превысили эту сумму за весь срок действия контракта, контракт можно не ставить на учёт в банке. После неё надо будет поставить на учёт и контракту присвоят уникальный номер. Если после этого вы будете менять банк, то контракт тоже надо будет переводить.

Если кто-то уже проходил процедуру присвоения уникального номера контрактам с Apple, Google и т.д., расскажите, есть ли там какие-то особенности, о которых нужно знать?

При получении следующих сумм, валютному контролю надо предоставлять только обоснование суммы. Для AdMob — это документ на каждую транзакцию с суммой перевода, который можно найти в личном кабинете, для Apple — скриншот из AppStore Connect с детализацией продаж.

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

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

Деньги ИП — это ваши деньги, в отличие от ООО, их вы можете использовать как угодно и не обосновывать эти затраты. Некоторые банки оформляют карту, привязанную к счету ИП. Переводить со счета ИП другим людям не рекомендуется, но оплачивать что-либо картой — без проблем.

Да, обоснование может потребоваться, если налоги вы платите с прибыли, а не с выручки. Но я выбрал 6% с выручки, с этим нет проблем, покупай, что хочешь.

Ставь лайк, если тоже сидишь работаешь! Я за эту неделю, вообще, ничего не успел с этим аккаунтом, сижу закрываю задачи теперь, но хотя бы еще неделя до конца спринта :)

А есть ли кто из мобильных разработчиков, кто смотрит Формулу-1? Я только одного такого встретил за всю свою карьеру.

Есть три шортката, которыми я в Твиттере пользуюсь постоянно.

Option+Shift+минус — длинное тире (—)
Option+Shift+плюс — открывающая кавычка-ёлочка («)
Option+плюс — закрывающая кавычка-ёлочка (»)

Пишите, как петербуржцы.

Вот и подошла к концу моя неделя мобильного разработчика. Надеюсь, вам было интересно! Мне точно было, снова спасибо Паше @Rational_Answer за вчерашний тред про инвестиции. С завтрашнего дня я вернусь к себе в аккаунт @petertretyakov, а тут будет новый мобильный разработчик.

Собака мобильного разработчика ждет нового мобильного разработчика. А я пойду досматривать доклады на @MobiusConf, увидимся в выходные на конференции в Москве! Хорошей недели! pic.twitter.com/7EUrEnwTiO