Архив недели
Понедельник
Всем привет!
Меня зовут Александр Крылов. И эту неделю вместе с вами я выхожу за грани комфорта, а также транслирую мысли и темы, роящиеся в моей голове.
Попробуем пойти по такому расписанию:
Пн: Как я встретил работу своей мечты
Вт: Инфраструктура для мобильного проекта
Ср: Поговорим о ферме мобильных устройств.
Чт: Разработка и тимлидство
Пт: Музыка в жизни разработчика
Сб: Стереотипы и наши решения
Вс: Свободный слот
И раз уж сегодня понедельник, позвольте рассказать вам как я вообще пришёл в IT
Сейчас этим уже мало кого удивишь, но у меня нет образования программиста. Я окончил СибГУТИ по специальности МЭС и ОС. Меня готовили к прокладке оптоволокна в полях, городах и весях
Я знаком с действительно сильными разработчиками, которые по каким либо причинам не окончили или даже не начинали вышку.
Оказалось, что гораздо важнее мыслить в верном направлении и уметь доводить дело до конца.
И в связи с этим у меня возникает вопрос.
Дорогие читатели, рассажите, пожалуйста, насколько ваше образование соответствует тому, чем вы занимаетесь?
🤔
34.9% Полностью соответствует🤔
27.9% Смежная сфера🤔
37.2% Ничего общего🤔
0.0% Свой вариант (в комменте)А вы испытываете какие-либо трудности с тем что в нашей стране 11 часовых поясов?
Прошу прощения, но я начал раньше, чем планировалось. Поэтому небольшая пауза)
Продолжим в скором времени!
#реклама
В эту пятницу будет много интересного про SwiftUI и не только на онлайновом iOS-митапе cocoa.heads.club/december/
Ребята из Туту.ру расскажут, как обновлять экраны, не релизя новое приложение, с помощью Server Driven View
Также будут доклады про стейт-машины и работу со звуком в iOS. Стоит залететь на трансляцию - cocoa.heads.club/december/
Я вернулся и мы можем продолжить.
Большое спасибо за ваши голоса. Оказывается, немалая доля людей работает по своей профессии. Я уже не зря сюда пришел)
Итак, вернемся на пару десятилетий назад.
Я вырос в Амурской области, в небольшом посёлке, населением чуть больше двух сотен человек. Не тысяч, а просто двести человек.
Я заканчивал школу и встал вопрос куда идти дальше. Никакого понятия, чем мне заниматься в будущем.
Меня увлекали две вещи: музыка и компы. Ни по первому ни по второму пункту не было достаточных знаний, чтобы заниматься этим всерьёз.
Я решил ехать в Новосибирск. И честно говоря, не ради учёбы, а чтобы собрать музыкальную группу. Но об этом мы поговорим чуть позже.
Так или иначе, я поступил в колледж связи, а спустя 3 года вернулся в родной посёлок. Меня взяли учителем информатики в мою же школу.
Здесь начинается мой долгий путь в ИТ. На дворе был 2009 год.
Спустя 3 года я вернулся в Новосибирск и устроился на первую попавшуюся работу. Ремонтировал оборудования для гаражных ворот и шлагбаумов. Съемная квартира, неплаченный кредит, общение с приставами и откровенная нищета…
Удалось сменить несколько мест работ в этой сфере и значительно поправить своё финансовое состояние. Больше не приходилось брать деньги в долг чтобы хватило на проезд.
Время текло незаметно и в начале 2014 года пришла пора задуматься о профессиональных перспективах. За это время я успел поработать учителем, электромонтёром, и инженером сервиса автоматических гаражных ворот.
В руках моих был телефон под андроид, поэтому выбор пал на Java.
Думаю, этот вопрос здесь уже задавали несколько сотен раз, но я у руля, поэтому...
Какие фонемы вы используете произнося Java?
🤔
90.7% Джава🤔
9.3% Ява🤔
0.0% Свой вариант?Я нашел и приобрёл книгу "Изучаем Java" прекрасных авторов Кэти Сьерры и Берт Бэйтса. Книга впечатлила своей простотой. Всё объясняли на яблоках. И этот мир попросту начал меня поглащать.
Я читал главу за главой и с нетерпением ждал проверочных тестов в конце каждой из них.
Спустя какое-то время, я двинул в сторону мобилки. С английским было плохо, но божества книгопечати не оставили меня ни с чем. И мне попалась книга Алексея Голощапова. Возможно ничего интересного. Но это неплохой перевод официальной документации Android)
И вот я - полный знаний и теории - пытаюсь применить свои знания на практике. И сталкиваюсь с проблемой: а что же можно такого написать, чтобы было полезно и не очень сложно. Я порыскал по маркету и решил разработать небольшой текстовый редактор.
Что-то меня не туда уже понесло, простите.
Итак, работа)
Начал искать фриланс заказы. Мне опять же повезло, нашёлся заказчик и благодаря нему я познакомился с гитом и своими первыми факапами.
Я подрабатывал и набирался новых знаний по вечерам и ночам, т.к. с утра до вечера ремонтировал ворота)
Паралелльно я ходил на собесы, когда получалось отпроситься с основной работы.
А теперь немного поиграем)
Как вы думаете, сколько собеседований я посетил, прежде чем получил свою первую работу Андроид-разработчиком?
🤔
26.5% 12🤔
38.2% 18🤔
35.3% 24Спасибо за ваше мнение. Не смотря на то, что твиттер куда-то дел ещё один неправильный вариант, большинство оказалось право.
Это было 17 очень полезных, но неудачных собесов. И одно очень странное, благодаря которому я получил билет в ИТ
Что касается 17-ти неудачных. Первые отказы конечно же были болезненными, но спустя два-три я понял, что в большинстве своём я могу запомнить вопросы, на которые я не знал ответ.
Это стало моим источником знаний на следующие 4 месяца.
Я приходил на собесы с блокнотом и по ходу дела просто записывал всё, что я не знаю или что вызвало у меня сомнения. Потом возвращался домой и поэтапно восполнял пробелы в знаниях.
И вот в один прекрасный день я собирал рюкзак. Мы планировали с друзьями поехать на Белуху, походить по горам.
Мне звонит HR из местной компании и предлагает придти на собеседование. Завтра в 11.
Я отвечаю, что завтра в 14.00 я уезжаю в отпуск.
Меня заверили что мы всё успеем. Так и вышло. Помните, я сказал, что это было странно)
Меня собесил бэкендер(php). И все вопросы были в стиле: "а коллекции знаешь", "а с сетью работал", "а картинки сможешь для дизайна подрисовать". Я отвечал честно: да, нет, научусь)
Все закончилось за полчаса и я спокойно пошёл домой в предверии отпуска.
Кстати, на автовокзале не оказалось билетов на Алтай, зато были 4 билета в Киргизию😂🤣🤣
Выезжаем мы за границу области и мне звонит HR. С прекрасными новостями, что они будут рады видеть меня в своих рядах. Я изрядно опешил, и точно на пару секунд не знал что сказать. Опомнившись, я ответил, что меня не будет в стране две недели. Ребята согласились подождать.
Когда ты работаешь на воротах или грузчиком или ещё кем-то в этом духе тебя не ждут. Не вышел на работу - найдут другого. То, что работодатель готов ждать выхода сотрудника, для меня было неожиданной радостью.
Отпуск прошёл восхитительно! На каком-то из перевалов мне удалось дозвониться до текущей работы и предупредить об увольнении.
Вернувшись назад, я с огромной радостью принялся за дело. Приходил в 7.00 и уходил в 19.00, потому что мне безумно нравилось писать код.
Я забыл упомянуть одну очень важную вещь. ЗП на новом месте была 22к. После 80к на предыдущем месте, это был очень тяжелый, но осмысленный шаг.
Я хоть и подразобрался с фин.проблемами, но обязательства никто не отменял.
С какого по счёту собеседования вам удалось получить свою первую работу в ИТ?
🤔
54.9% С первого🤔
35.3% от 2х до 10ти🤔
5.9% от 10ти до 20т🤔
3.9% 20+Вторник
Очень хороший показатель) что тут скажешь.
Думаю, вы догадываетесь, что после этой работы были и следующие. И каждый раз это казалось работой мечты. Всё дело в том, что мы сравниваем новый опыт с предыдущим, и не так часто вспоминаем что было 3-4 года назад.
Природа человека чрезвычайно сложна и, как говаривал агент Смит, больше похожа на поведение вируса.
Я ничуть не осуждаю подобное поведение. Но, глядя на себя и окружающих, невольно задумываешься, сможем ли мы сознательно остановить погоду за благами.
Спасибо всем, кто по собственному желанию или по воле случая следил за тредом.
Я опустил немало подробностей своего пути, но старался не терять сути. Чем сложнее идти по тропе, тем краше окажется верхушка перевала.
А дальше, снова и снова с горы на гору.
Честно скажу, мне во многих вещах просто везло. Оказаться в нужное время в нужное место или просто наткнуться на правильную книгу.
Хотелось бы ещё сказать огромное спасибо друзьям и знакомым, за поддержку.
Это дорогого стоит)
И в завершение: никогда не поздно всё изменить...
Тред (Александр Крылов)
Всем доброго дня!
Сегодня озвучу несколько мыслей об мобильной инфраструктуре.
Первое, что приходит в голову, это конечно инструменты для сборки.
Чем пользуетесь вы на своих проектах?
Всего 4 варианта, постите( Пишите в коментах, если пользуетесь чем-то другим.
🤔
38.5% GitLab🤔
28.2% GitHub🤔
15.4% Jenkins🤔
17.9% TeamcityБольшое спасибо! На протяжении опроса фаворит менялся. Но как видно из результата, предпочтение идёт сервисам с возможостью хранения кода и автоматизации сбоки.
И я согласен. Очень удобно держать всё в одном месте.
Но, позвольте, поделиться. Вот что я считаю важным для прогонов на CI:
Проверка компиляции кода
Статический анализ кода
Проверка локализаций
Прогон Unit тестов
Публикация результатов прогона
Прогон UI тесты.
Всё вышесказанное должно проходить "быстро"
Думаю, что первым пунктом все согласны.
Третий опустим, т.к. он подходит для приложения с большим количество локалей.
Что на счёт первого, второго и четвертого?
🤔
0.0% Проверка компиляции🤔
0.0% 1 + Unit-тесты🤔
100.0% 1+2+ статический анализА про прогоны ui-тестов можно поговорить и поподробнее)
Впервые я столкнулся с UI-тестированием, когда меня попросили настроить monkey тест на мобилке.
Андроид в коробке имеет такой функционал. Сейчас не вспомню какой именно командой это делается, но команда одна.
И всё что от меня требовалось, это настроить регулярный прогон такого теста на CI.
Это был мой первый месяц работы. И проковырялся я месяц(!), чтобы всё это настроить. Всё получилось))
И сложности были не с запуском простейшей команды, а с настройкой CI-таски и самого телефона.
И всё заработало. Прогон шёл по ночам, а утром можно было посмотреть отчёты по прогону.
Прошло несколько месяцев и эти отчёты, откровенно, стали никому не нужны) Monkey тестирование на неходило никаких проблем с приложением. (Разаботка писала без багов)
Спустя какое-то время об этой сборке забыли и благополучно отключили.
Вместо этого отдел тестирования представил первые тесты на Appium.
Это были нелегкие дни) Но спустя пару недель мне удалось завести их на CI. Для этого потребовалось форкнуть проект управляющего android-приложение и внести небольшие правки, чтобы тесты могли получить доступ до вьюх на экране.
Тесты работали медленно, нестабильно и занимали очень много времени на поддежку.
Удалось добиться определённого успеха прогонов, после чего меня перекинули на другой проект.
Всё это время я занимался Android-разработкой, а все активности по CI просто совмещал с основными задачами.
На новый проект мы пришли с Teamcity на Jenkins.
Это вроде называется "культурный шок".
Сила привычки не даёт нам адекватно воспринимать что-то новое. Особенно, если оно выглядит не так как прежний инструмент.
Несмотря на все возможности и функциональность Jenkins мы решели поднять своё инстанс Teamcity.
Новая команда, новые взгляды. Отдел тестирования заинтересовался espresso. Данный фрэймворк работал в разы быстрее Appium. После нескольких тестовых прогонов мы приняли решение тащить их на CI.
Возможно, на просторах интернета, вы сразу наткнётесь на простую gradle-таску для запуска ui-тестов на подключенном телефоне(эмуляторе).
Но ребята сразу сказали, что тестов будет много и стоит задуматься об оркестрации прогонов.
Наш выбор пал на marathon.
В то время он был уже достаточно стабилен (2017) и отвечал основным требованиям, а именно:
Разделение общего количество тестов по эмуляторам.
Работа с flaky-тестами
Автоматический подхват новых девайсов и исключение отвалившихся
Выбор между реальными девайсами и эмуляторами особо не стоял. Девайсы были под рукой из числа тестовых, но на постоянную основу мы их взять не могли. Поэтому мы запускали эмуляторы. Прямо во время прогоно, один за одним и так в общей сложности поднимали 4 эмулятора на один прогон
При первых же попытках старта оказалось, что эмули не прогреты и приходится ждать приличное время.
Поэтому эмули были завернуты в докер.
Разумеется сейчас есть огромное количество эмуляторов, которые вы можете использовать в своих сборках.
Нам на тот момент было важно, чтобы они стартовали быстро. Тестов уже было больше двухсот и прогон занимал почти два часа
Чтобы эмуляторы стратовали быстро, мы собрали очень толстый образ в котором был полностью преднастроенный эмулятор(страна, язык, номер телефона). Дополнительно мы запускали эмулятор, ждали какое-то время, пока все закрузится, останавливали его, и делалит docker-commit
Образ выходил огромный) больше 10Гб, но ресурсы позволяли такую роскошь. А старт эмулятора занимал теперь 1-2 секунды. После этого он полностью был готов к работе.
О том, как развивалась судьба данной "фермы" я постараюсь рассказать завтра.
А по тестам, стоит отметить вот что. Это очень долгие прогоны и, думаю, каждый хочет гонять ui-тесты на каждый pull|merge-request.
Конечно, тут напрашивается несколько путей решения:
Ускорить проходение самих тестов(убрать задержки, стартовать преднастроенные сценарии).
Увеличить количество девайсов
Запускать только определённое количество тестов.
По первому пункту не получится делать улучшения бесконечно, рано или поздно, а скорее всего в самом начале, окажется, что ваши тесты уже написаны отлично и хорошо справляются со своей работой.
По второму вроде всё просто, но и сложно одновременно. Запуск большого количества эмуляторов ограничен ресурсами машины, и вы всё равно придёте к вопросу о ферме.
И третий вариант основан на простой концепции(но весьма в сложной в реализации). Можно запускать лишь те тесты, которые проверят затронутый код.
Звучит как сказка, но давайте об этом поговорим.
Насколько мне известно данный подход имеет название Impact Analysis. Задам вопрос и продолжу повествование)
Используете ли вы в своих проектах Impact Analysis?
🤔
50.0% Да🤔
50.0% Нет🤔
0.0% Что-то похожее.Когда мы только начинали, то вдохновились работой ребят из Avito. В частности вот этим докладом.
youtu.be/EBO2S9qcp0s
В теории всё очень просто. Кто-то создает pull|merge-request, а дальше по списку:
Смотрим на git diff между текущей веткой и основной
Находим соответствия между затронутыми файлами и классами, строковыми ресурсами и т.п.
Ищем зависимости в проекте
Доходим до фрагментов или активностей.
И тут возникает вопрос как найти зависящие ui-тесты.
В докладе раскрыта тема как найти затронутый модуль. И можно просто гнать все тесты в модуле.
Если у вас проект хорошо разбит на модули и тесты тоже разнесены по модулям, то этот вариант вам полностью подойдёт.
У нас на тот момент модуляризация только стартовала и ни о каких прогонах на модуль речи быть не могло. Поэтому мы взяли за "минимальную заафекченную единицу" тестовый класс.
Если вы знакомы с espresso в Android, то знаете, что нет прямой связи между фрагментом и ui-тестом.
Ребята из Avito добавили id для рутовых вьюх.
Мы добавили аннотации к тестовым PageObject'ам, где указывали файлы верстки.
Так мы получили связь между фрагментами и тестами
Первую версию тулзы для поиска затронутых тестов мы выкатили спустя 2 недели после начала работ.
Тулза умела находить только по затронутым классам. Ни строки ни стили пока не учитывались, это мы доделали позже.
Имея подобный инструмент вкупе с новым железом и достаточным количеством эмуляторов нам удалось запустить прогон ui-тестов на каждоый pullrequest.
К моменту запуска мы имели около 2к ui-тестов.
Прогон на 20 эмуляторах занимал почти два часа.
Благодаря Impact Analysis прогон ui-тестов в среднем занимал не более 15 минут.
Поправка, бывали случаи, когда нужно было гнать все тесты. К началу запуска полные прогоны занимали больше 80% от общего числа. CI встал колом)) Если анализ не выдавал результата, то мы гнали все тесты.
Тогда мы сделали маппинг файлов, и если оказывалось, что ничего "важного" затронуто не было, то ui-тесты не гнались совсем.
После этих нововведений полные прогоны занимали не больше одного процента от общего количества.
В неделю мы фиксировали 200-250 прогонов.
Таким простым решением мы сэкономили огромное количество человеко- и машино-часов
Разумеется по ходу построения инфраструктуры страдали обычные разработчики, если не работает CI или, что хуже, он плохо работает, то тратятся бесчётные часы человеческого времени.
В завершение треда хочу сказать: что бы вы не делали с инфраструктурой, не забывайте, для чего это всё задумывалось. Мы пишем скрипты для сборок и поднимаем CI, чтобы упростить жизнь разработчикам и ускорить поставку полезных фич нашим пользователям.
Иными словами, живи, не причиняя вреда, а тело дано, чтобы действовать...
©7Раса - Samskara
Тред (Александр Крылов)
Четверг
Говорят, что понедельник - день тяжёлый. А у меня - самый загруженный день - это среда. Настолько, что даже не было времени твит написать)
Если кто-то ждал треда о ферме андроид эмуляторов, лайкните, пожалуйста, перенесём на воскресенье.
Сегодня четверг и время рассказать о моём опыте тимлида.
Начнём с того, что на всех собеседованиях на вопрос: "Кем вы видите себя через 5 лет", я уверенно отвечал: "Тимлидом команды". Ох, Саша...
Но, когда я вышел на работу и погрузился в написание кода, то понял, что это и есть моя страсть. Разбираться в сложных багах, искать неординарные решения в сложных ситуациях. Это всецело захватывает тебя.
Поэтому, когда ко мне пришёл руководитель и сказал, что надо потимлидить небольшую команду, я отнёсся скептически.
Давайте будем честыми, мне было просто страшно, что я не справлюсь. В команде были люди, гораздо сильнее в техническом плане. Синдром самозванца и по сей день не отпускает меня в некоторых ситуациях, что говорить о пяти годах ранее.
Так или иначе, говорить "нет" я не умел (воспитание), поэтому принял на себя эту ношу.
Забегая вперёд, именно опыт тимлида научил меня говорить "нет". Как на работе, так и в жизни. И за это спасибо!!!
В команде было 4 человека. Все меня знали, до момента провозглашения тимлидом, и я не хотел гнуть свою линию и тыкать всех лицом в свою роль.
Амибиции амбициями, но цель всё та же, нужно поставлять "добро" пользователям.
По большей части я занимался scrum-активностями. Вёл встречи, обсуждал сроки и сам участвовал в разработке.
Спустя пару месяцев, как я пришел на проект, руководство приняло решение переписать его с нуля, т.к. продукт "стрельнул", а поддерживать старую версию было просто невозможно.
Была сформирована новая команда из 6 человек. Все ребята были матёрые и со своим видением, как и куда вести проект.
Я продолжал лидить команду в демократической манере. Ох, и аукнулось это потом. Наследники проекта годами выпиливали хайповые библиотеки, просто потому, что мы "совместно" решили их использовать.
Как бы вам не хотелось быть хорошим для всех и вся. Наступит момент, когда вы скажете: "Нет, так делать мы не будем, потому что ..."
Но для этого нужно иметь хорошую техническую экспертизу в этом вопросе.
Или иметь рядом человека с такой экспертизой, которому вы доверяете.
И я думаю, это важно. Важно в один момент важно принять решение и взять все риски за это решение на себя. Разумеется, если вдруг из-за этого решения произойдёт факап, найдите в себе силы и оградите команду от негатива.
Говорят, что признавать ошибки могут лишь сильные люди. Уж не знаю как на самом деле всё выглядит, но авторитет в глазах команды точно подрастёт. И при следующих решениях вам будет проще смотреть на текущую проблему через призму предыдущего опыта.
Шаг за шагом стало неплохо получаться. Я научился говорить "нет" внешним заказчикам и начал жить спокойно) Честно! Пропала тревога от того, что мы на что-то подписались, но не успеваем. Всё стало просто. Нужно сделать что-то срочное, давай выкинем что-то из спринта.
Очень важным моментов в своём становлении считаю тот день, когда у меня получилось отдать кому-то из команды техническую задачу. И знаете что? Парень сделал её гораздо лучше чем сделал бы я!
Оказалось, что отдавая задачи тем, кто больше в этом разбирается, ты экономишь время и все в выигрыше. Чудеса, не иначе.
Моей утопией была самоорганизующая команда. Когда не нужно никого пинать, а все сами делают свою работу.
Для этого нужно, чтобы каждый человек в команде попробовал себя в разных ролях. И поскрамить месяц, и на встречи походить, и на собес можно кого-то с собой взять.
Когда каждый хоть немного в курсе всего происходящего в команде, вы можете спокойно уходить в отпуск или ещё куда.
Наступил "золотой век", иначе не скажу))
Когда и в команде и со смежными подразделениями выстроены процессы и они работают. Команда наслаждалась работой и все были счасливы.
Но век счастья был, как водится, не долго...
Не для команды, а для меня лично. Я перестал развиваться технически и, постепенно, просто потерял интерес ко всему, что происходит.
А что вы можете сказать про тимлидство?
🤔
5.5% Зашло🤔
27.3% Стремлюсь🤔
21.8% Полное разочарование🤔
45.5% Не интересуюсьПолучились очень интересные результаты опроса. Спасибо вам большое!
Продолжим.
А дальше всё просто. Волей или не волей ты задумываешься как изменить текущую некомфортную ситуацию.
Самым очевидным кажется, что нужно просто уйти с этой позиции и вернуться к полноценной технической роли. Но тут не всё так просто.
Даже если вы сами эмоционально способны и настроены на такие изменения, окружающие вас коллеги не сразу, а кто-то вообще никогда не смирится с данной рокировкой.
На подсознании люди продолжат общаться с вами на том же уровне. Также будут спрашивать вашего мнения. И верить всему, что вы скажете.
И бесполезно говорить, что "я больше за это не отвечаю" или что-то подобное. Мы слишком тяжело воспринимаем перемены.
В моей ситуации оставалось либо полностью сменить подразделение и начать сначала, либо начать сначала в другой компании.
И, признаюсь, я до сих пор не полностью уверен, что это были единственные варианты.
Если у кого-то есть подобный опыт, поделитесь, пожалуйста.
Тред (Александр Крылов)
Суббота
Вчера я несколько раз садился писать тред. Смотрел на подготовленный материал, переписывал. Но что бы я не делал, в написании не было легкости. И я попросту стирал сохраненную ветку.
Ночь спустя, до меня стало доходить. В черновиках была ещё одна выписка из моего личного опыта, автобиография. Как музыка влияет на все стороны лично моей жизни, а не на жизнь мобильного разработчика.
В связи с этим, тред будет небольшой и ближе к вечеру мы перейдем к тебе дня. А пока...
Музыка - это не хобби, это жизнь!
В годы начальной школы мне было очень сложно сконцентрироваться на одном деле более 10-15 минут. Возможно, психологи для этого нашли бы какой-то диагноз и помогли, но, как вы помните, рос я в маленьком посёлке.
Поэтому выполнение домашнего задания растягивалось на весь день.
Да, нелегко пришлось родителям.
Но в какой-то момент я наткнулся на проигрыватель пластинок. Я часто слушал его в дошкольные годы. Огромное количество сказок на пластинках разных размеров хранились на радиальных дорожках винила.
И дошло дело до Бременских музыкантов. Разумеется, я слышал их раньше. Но новые страницы жизни меняют призму нашего восприятия.
И если раньше мне был интересен сюжет, то сейчас я погрузился в мелодику песен и прекрасный вокал.
Оказалось, что прослушивание музыки фоном давало чувство ритма в действиях и присваивало ощущение времени.
Таким образом, все письменные предметы выполнялись под одну-две стороны пластинки.
Остались сложности с устными предметами, т.к. читать по д музыку я не мог. Но и это исправилось со временем.
Разумеется, я пронёс привычку делать какие-то задачи под музыку.
В 10 классе я собрал свою группу. Мы репетировали в сельском клубе. Подремонтировали инструменты 70х годов и пытались сделать что-то вменяемое. Несколько раз выступали, но дальше посёлка ничего так и не ушло.
Я помню, что в то время мы порой собирались в гараже или у кого-то дома, просто чтобы послушать музыку.
А как вы слушаете музыку?
🤔
0.0% Не слушаю🤔
53.3% В основном фоном🤔
46.7% Специально уделяю времяПереходим к теме дня. Стереотипы и наши решения.
Отмечу, что я не претендую на какое-либо экспертное время. Хочу лишь поделиться своими заметками на эту тему.
Не смотря, на то, что музыка и разработка особо не связаны, я знаю, что многие находят в ней источник эмоций. А также, кому-то это помогает восстановиться после рабочего дня или справиться с выгоранием.
И везде, где я имел радость работать, находились творческие и музыкальные люди. Они собирают группы и выступают на корпоративах, и меня это искренне радует.
По этому треду всё) Как я и сказал выше, материал разошёлся с темой. А посему, позвольте перейти к теме сегодняшнего дня.
Для меня музыка имеет очень большое значение в жизни. Ибо окружает и поддерживает во всех начинаниях.
Тред (Александр Крылов)
Я буду рассказывать о тех, вещах, с которыми столкнулся в жизни с той или иной стороны.
На моей памяти, первый стереотип, который меня застал выглядел так. Моя мама - учитель начальных классов. Когда я был во 2-3 классе друзья нередко укоризненно говорили, что наша учительница ставит мне хорошие оценки лишь потому, что не хочет ссориться с моей мамой)
И, разумеется, переубедить их было невозможно) Отсюда я начал укореняться во мнении, что если человек что-то вбил себе в голову, то его практически невозможно переубедить. Мысли об этом развеялись, когда я пришёл в мир IT, где имея хорошие аргументы, можно многое изменить.
И ведь кто-то просто забивал на домашку, а меня заставляли её делать, хоть это и занимало почти весь день. Хочешь не хочешь, а в голове какие-то знания да отложатся.
По моему мнению подобный стереотип просто миф.
Но для объективности, скажите, считаете ли вы, что дети учителей всегда хорошо учатся?
🤔
3.2% Да🤔
83.9% Нет🤔
12.9% Отчасти, даСпасибо!
Забавно, но порой мы сами того не понимая поддаёмся каким-то стереотипам.
Так случилось и со мной. Где-то в 6-7 классе я подсел на мультсериал "Бил и Тед" (обмен VHS хорошо зашёл в нашем посёлке)
И, думаю, вы догадались, мне хотелось быть похожим на главных героев. Но я был уверен, что отличник не может играть в группе. Сейчас это смешно, но тогда я не видел другого выхода, и стал хуже учиться...
Мда... благо, родители объяснили мне, что это совершенно разные вещи.
И как я писал в предыдущем треде, в конечном счёте всё получилось)
Далее, к концу 7 класса, мне захотелось наладить общение со сверстниками, ну, и чего греха таить, хотелось быть популярным. По этой теме снято немало иноязычных фильмов.
И я пришёл к решению, что путь в любую дворовую компанию - это гитара. По своему опыту скажу, что для меня этот стереотип до сих пор работает в большинстве случаев. Окружающие более благосклонны к тебе, если ты можешь слабать пару их любимых песен.
Остались всего две вещи, о которых я бы хотел поговорить.
И первая из них, это жизненная пословица "Встречают по одёжке, а провожают по уму"
В какой-то момент моей жизни это стало моей манией, и я, откровенно, доводил свой внешний вид до абсурда, чтобы ещё раз удостовериться в правоте пословицы.
За более чему 15 лет этого эксперимента всего в нескольких компаниях людей на это не обращали внимания.
И это были неформальные тусовки, где всем откровенно всё равно как ты выглядишь.
В остальном же, люди выражали откровенное презрение, до тех пор пока не выяснялось, что я могу быть им чем-то полезен.
Когда я пришёл в IT, то испытал что-то похожее. Здесь неординарный внешний вид не только не порицается, но и порой встречается на ура. Быть может не везде, но пока я с таким не сталкивался)
Ну, и завершающая мысль.
Авторитет губит истину.
Может и не стереотип, но принцип работы такой же. Людям проще соглашаться с кем-то, если человек на слуху или имеет какой-то авторитет в компании людей.
И, к сожалению, это не всегда хорошо. Уж простите.
Людям свойственно ошибаться, и цена ошибки авторитетного человека в разы, а может и на порядок выше.
Несколько раз я наблюдал, как человек, откровенно не разбирается в вопросе, но боится утратить власть и даёт ответ наобум. Нередко давит на окружающих и принуждает к принятию его стороны.
Так же и с продуктами и большими компаниями. Имея запас авторитета корпорации способны не обращать внимания на качество продукта.
Порой мне кажется, что мы недалеко ушли от приматов. И, сродни павианам, прислушиваемся к тому, у кого попа краснее.
Я веду свою мысль к тому, что независимо от того, какого технического или социального уровня перед вами стоит человек, прислушайтесь к его мнению. Взвесте аргументы и принимайте правильное решение. Даже если оно окажется неверным, оно всё равно будет правильным.
Тред (Александр Крылов)
Воскресенье
Сегодня воскресенье. Подходит к концу моя неделя в этом аккаунте.
Как и обещал, расскажу о том, как мы собирали свою ферму андроид эмуляторов.
Начинали мы с простого запуска 4 или 6ти эмуляторов на одном из шагов прогона UI-тестов.
Эмуляторы были обёрнуты в докер-образ, поэтому не приходилось писать длинные команды вызовов.
Мы просто написали баш-скрипт, где шли по циклу, поднимали контейнер, ждали успешной загрузки и так N раз. Для полной уверенности мы ждали ещё какое-то время. Итого, запуск 6ти эмуляторов мог занимать около 10 минут. А перед этим собиралось приложение и тестовый apk
Занимало времени прилично. 200 тестов на 6ти эмуляторах шли около 2х часов.
QA озвучили свои ожидания в 1000 тестов к концу года.
Запускать больше эмуляторов мы не могли, т.к. упирались в ресурсы машин.
Но, на наше счастье оказалось, что android adb работает по обычному tcp/ip. И все сетевые просторы нам открыты, если только знаешь путь.
Проверили, сможет ли билдагент подключить эмуля на наших локальных машинах и прогнать тесты. Всё прошло успешно)
Мы заказали одну большую виртуалку (20 cpu и 64Gb RAM). Из расчёта 2cpu 4Gb на один эмулятор.
И сели писать обвязку для нашей фермы.
Нам виделись две задачи, которые нужно решить
Запускать эмули и следить за их жизнеспособностью. При необходимости перезапускать.
Подключать эмуляторы к билдагенту.
Спустя месяц началась интеграция.
Для каждой задачи мы создали отдельное java-приложение. Первое сделило за жизню эмулей на виртуалке. Второе запускалось вместе с билдагентом и следило за тем, чтобы определённые эмуляторы были подключены к текущему хосту.
Количество и адреса девайсов указывались в конфигах и заполнялись людьми.
Ферма оказалось очень стабильной. Эмуляторы дохли, если не проходили проверку на доступность, а им на смену поднимались новые.
Спустя время, мы дозаказали ещё две таких виртуалки. Конфигурации раскатывались через puppet, поэтому добавление новой машины особо не отнимало у нас время. Только конфиги заполнить.
Но, оказалось, что если поднять по 8-10 эмуляторов на одной такой машине, то начинались проблемы с производительностью, т.к. контейнеры дрались за ресурсы. Подвисание эмулей приводило к появлению красных тестов. Оптимальным оказалось число в 6 штук. Не самый экономный вариант.
Благодаря коллегами из отдела эксплуатации мы узнали, что есть кубер. И задумались о переезде агентов и эмуляторов в отдельное пространство.
Кубер полностью решал проблему с созданием контейнеров и проверкой их жизнеспособности.
Мы доработали приложение для подключения эмулей к хосту. Теперь оно просто ходило в Kubernetes-api и создавало столько эмуляторов сколько указано в конфигах.
А дальше всё по старому, подключаем девайсы и гоним тесты.
Т.к. в кубере работает ограничение ресурсов для контейнеров, то мы получили больше девайсов с приемлиемой производительностью.
Нам удалось организовать запуск 20 эмуляторов для прогонов UI-тестов на каждом pullrequest'е.
Новые ресурсы добавлялись в кластер и мы просто меняли количество девайсов и билдагентов на нашем CI.
Тред (Александр Крылов)
Дорогие читатели. На этом всё. Спасибо вам большое за внимание. Надеюсь, что хоть какие-то мысли и истории оказались для вас полезными!
До новых встреч!!!
