С ума сойти, это не статья, это титанический труд, который тянет на целую книгу Теперь понятны боли и как их решали, но "вишенкой" будет посмотреть какой получился чек-лист, чтобы стянуть его себе
Спасибо за статью, сохранил в закладки, правильно понимаю, что я могу использовать #Preview, по сути только для просмотра превью элементов UIKit, как в SUI?
Спасибо за статью, было интересно узнать как вы выбирали между двумя инструментами и будет интересно узнать подробнее о том как вы у себя настраивали и собирали метрики)
Хотя, такое большое количество комментариев с критикой мне бы отбило желание что-то еще писать, но автор - держись, понимаю на сколько не просто писать статьи
Писать статьи не очень просто, а комменатриев тут очень много и большая часть с критикой. Понимаю, что есть вероятность, что автор мог не донести мысль из-за чего его аргументы могли быть не в лучшем свете. Но я, все же, думаю, за статьей есть большой смысл и буду ждать новую статью с более подробным разбором, чтобы она могла обьяснить каждому причины отказа от технологии
И правда интересно было посмотреть результаты опроса. Наверное, каждый голосовал за свой язык, на котором он пишет, плюс еще те, кто работал с несколькими. Поэтому, может быть, опрос показывает сколько зашло в опрос Swift / Dart / Kotlin разработчиков)
Кажется, в примере копирования логики для проверки значений, стоит поправить: XCTAssertEqual(result, "(stringA)(stringB)") // неправильно, на " \(stringA)\(stringB)")?
Наконец-то кто-то сравнил Чарльз и Проксимен, спасибо! Но все равно прокимен остается в сердечке)
Единственно, что не удобно с проксименом - это ограничение в 4 map local и примерно в 10 url для просмотра трафика (SSL proxying List) для бесплатной лицензии.
Понятно, чт это лечится банальной покупкой лицензии, но, кажется, в Чарльз этих ограничений нет? Если ошибаюсь - поправьте, пожалуйста)
Спасибо, что подметили. Тут так и задумано, но бесконечной рекурсии не получится, потому что наблюдатели свойств (didSet{}) начинают работать только после установки значения через init().
Да так и есть, он намного лучше справится с разработкой, чем с менеджментом
Поинт еще в том, что лидом команды становятся по желанию, а еще самый опытный разработчик может лучше продумать новую задачу для менее опытных в команде, чем менее опытные для самих себя.
А на одного из разработчиков из команды навесили еще административные и контролирующие функции к основной работе и назвали его Лидом. И теперь он программировать вынужден в свободное от работы время, потому как все рабочее время будет тратить на планерки, отчеты, проверки и планы.
Да, так и есть. Один из стрима часть рабочего времени тратит на менеджерскую работу. Это на постоянной основе и, кажется, так работают тимлиды в командах, верно?
> И теперь он программировать вынужден в свободное от работы время Обычно лид стрима не все рабочее время тратит на стендапы, но за своим лидом замечал, что он как-то фантастически все успевает. Возможно, этого не избежать, потому что стримы - это та же самая небольшая отдельная команда разработки, в которой тимлид занимается теми же самыми вопросами команды: планирование задач, загрузки разработчиков и т.п.
> Называется план: Как уменьшить кол-во разработчиков и снять работу с менеджмента. Менеджмент никуда не ушел, он на стороне вертикалей. И продуктовыми задачами занимаются именно они, а лид стрима организовывает работу самих разработчиков, как это делают тимлиды в обычных командах
Все так, чем больше человек, чем больше начальников, тем больше появляется бюрократии
Из планерок/стендапов: - Ежедневный release sync. На момент написания статьи он был ежедневным, но сейчас проводится только в понедельник и вторник на 5-10 минут - Ежедневный Lead Sync, проводится так же ежедневно на 30 минут - тут ничего не поделаешь, без него будет тяжело - Разные планерки с вертикалями обычно проводятся по 10-15 минут, проводятся раз-два в неделю. Они занимают время, но это способ планировать задачи
Лид стрима остался той же самой входной точкой, какой был лид всех разработчиков в самом начале. Кажется также работает в любой другой команде, где тимлид вникает в задачи, верно?
> + у разраба типа два начальника: лид и тимлид... Да, так и есть, лид стрима - формальный руководитель, а тимлид разработчиков уже официальный. Почти все время разработчик по рабочим вопросам общается с лидом стрима
С ума сойти, это не статья, это титанический труд, который тянет на целую книгу
Теперь понятны боли и как их решали, но "вишенкой" будет посмотреть какой получился чек-лист, чтобы стянуть его себе
Спасибо за статью, сохранил в закладки, правильно понимаю, что я могу использовать #Preview, по сути только для просмотра превью элементов UIKit, как в SUI?
15 мисок риса от товарищей разработчиков этому господину и -15 социального рейтинга от господ менеджеров
Спасибо за еще одну познавательную статью, как всегда круто
В свое время не успел разобрать dev-mod, теперь сохраню статью в закладки как инструкцию
Отличная статья, спасибо, сохранил в закладки)
Буду использовать как мануал ?
Спасибо за статью, было интересно узнать как вы выбирали между двумя инструментами и будет интересно узнать подробнее о том как вы у себя настраивали и собирали метрики)
Спасибо за описание возможностей НТ, теперь задумываюсь поработать с ним
Хотя, такое большое количество комментариев с критикой мне бы отбило желание что-то еще писать, но автор - держись, понимаю на сколько не просто писать статьи
Писать статьи не очень просто, а комменатриев тут очень много и большая часть с критикой. Понимаю, что есть вероятность, что автор мог не донести мысль из-за чего его аргументы могли быть не в лучшем свете. Но я, все же, думаю, за статьей есть большой смысл и буду ждать новую статью с более подробным разбором, чтобы она могла обьяснить каждому причины отказа от технологии
И правда интересно было посмотреть результаты опроса. Наверное, каждый голосовал за свой язык, на котором он пишет, плюс еще те, кто работал с несколькими. Поэтому, может быть, опрос показывает сколько зашло в опрос Swift / Dart / Kotlin разработчиков)
Но все равно интересно посмотреть распределение
Наконец-то тайна почему в Озоне ушел флаттер - теперь раскрыта. Спасибо за статью)
Было интересно почитать, отличная статья)
Но это мелочь, спасибо за интересную статью)
Кажется, в примере копирования логики для проверки значений, стоит поправить:
XCTAssertEqual(result, "(stringA)(stringB)") // неправильно, на" \(stringA)\(stringB)")?Наконец-то кто-то сравнил Чарльз и Проксимен, спасибо! Но все равно прокимен остается в сердечке)
Единственно, что не удобно с проксименом - это ограничение в 4 map local и примерно в 10 url для просмотра трафика (SSL proxying List) для бесплатной лицензии.
Понятно, чт это лечится банальной покупкой лицензии, но, кажется, в Чарльз этих ограничений нет? Если ошибаюсь - поправьте, пожалуйста)
Подметили, что тут может быть бесконечная рекурсия.
На самом деле блок didSet{} не вызывает повторного вызова самого себя. Можете проверить это в проекте или в playground.
Спасибо, что подметили. Тут так и задумано, но бесконечной рекурсии не получится, потому что наблюдатели свойств (didSet{}) начинают работать только после установки значения через init().
Да так и есть, он намного лучше справится с разработкой, чем с менеджментом
Поинт еще в том, что лидом команды становятся по желанию, а еще самый опытный разработчик может лучше продумать новую задачу для менее опытных в команде, чем менее опытные для самих себя.
Получается обычная команда со своим тимлидом
Да, так и есть. Один из стрима часть рабочего времени тратит на менеджерскую работу. Это на постоянной основе и, кажется, так работают тимлиды в командах, верно?
> И теперь он программировать вынужден в свободное от работы время
Обычно лид стрима не все рабочее время тратит на стендапы, но за своим лидом замечал, что он как-то фантастически все успевает. Возможно, этого не избежать, потому что стримы - это та же самая небольшая отдельная команда разработки, в которой тимлид занимается теми же самыми вопросами команды: планирование задач, загрузки разработчиков и т.п.
> Называется план: Как уменьшить кол-во разработчиков и снять работу с менеджмента.
Менеджмент никуда не ушел, он на стороне вертикалей. И продуктовыми задачами занимаются именно они, а лид стрима организовывает работу самих разработчиков, как это делают тимлиды в обычных командах
Все так, чем больше человек, чем больше начальников, тем больше появляется бюрократии
Из планерок/стендапов:
- Ежедневный release sync. На момент написания статьи он был ежедневным, но сейчас проводится только в понедельник и вторник на 5-10 минут
- Ежедневный Lead Sync, проводится так же ежедневно на 30 минут - тут ничего не поделаешь, без него будет тяжело
- Разные планерки с вертикалями обычно проводятся по 10-15 минут, проводятся раз-два в неделю. Они занимают время, но это способ планировать задачи
Лид стрима остался той же самой входной точкой, какой был лид всех разработчиков в самом начале. Кажется также работает в любой другой команде, где тимлид вникает в задачи, верно?
> + у разраба типа два начальника: лид и тимлид...
Да, так и есть, лид стрима - формальный руководитель, а тимлид разработчиков уже официальный. Почти все время разработчик по рабочим вопросам общается с лидом стрима