Проблема с аннотациями в том, что их нужно где-то писать) И у аннотации гораздо менее выразительный синтаксис.
Мы взяли за основу синтаксис от proguard. Сделали мы это по нескольким причинам: 1. Он и так знаком большинству разработчиков под андроид. 2. По сути это уже готовый синтаксис для указания того, где и какие манипуляции с байткодом нужно делать. То есть он буквально задизайнен под наши задачи) То есть всё что нам нужно было сделать, это дополнить его парой своих команд)
Ну и никто не мешает пользоваться аннотациями. Более того, это даже поощряется) Возьмем пример из статьи. Ты можешь написать правило для аннотации @AutoTraceCompat и по нему будет применено преобразование для всех методов помеченных этой аннотацией. Что очень удобно и наглядно. Но не всегда возможно, если твой метод находится в теле библиотеки и тебе туда со своей аннотацией не подлезть. Ну или если ты хочешь разметить все вызовы onCreate к примеру. Расставлять руками 1к+ аннотаций такое себе.
Самый ближайший шаг, написать нормальную доку к библиотеке на гитхабе :)
Если говорить про конкретные шаги по развитию библиотеки, то её автор, Саша Асанов их подсветил в своём докладе на мобиусе https://youtu.be/KPRPJLwdf8Y?t=2527 По сути это её обогащение несколькими приятными фичами.
Саму библиотеку мы планируем так же поддерживать и развивать на основании фидбека от комьюнити. Главное, мы не хотим, чтобы она превращалась "в монстра" способного делать всё) По нашему мнению, воткнуть код в начало или конец метода, или заменить вызов метода целиком достаточно для 95% задач. И хочется, чтобы разработчики смогли делать такие манипуляции просто и быстро.
Имхо, так можно практически про любой продукт или библиотеку сказать :) "Лень было разбираться с даггером, поэтому написали toothpick" и т.д.
С вашего позволения часть про в "100+ раз больше времени" оставлю без комментариев :)
Это есть в статье, но я ещё раз подчеркну. При написании библиотеки мы ориентировались в первую очередь на скорость работы. На наших сценариях в нашем аппе aspectJ работал на порядки(!) дольше.
Во вторых, по нашему мнению, для большинства прикладных задач связанных с манипуляцией байткодом на Андроиде aspectJ избыточен. Как в силу своего общего функционала так и порогом входа. В нашей библиотеке за основу взят синтаксис полгода с котором сталкивалось подавляющее большинство андроид разработчиков.
Насильно библиотеку никто использовать не заставляет разумеется. Если вам для ваших задач подходит aspectJ - супер. Но не вижу причин, почему наличие альтернатив это плохо)
Привет. У нас сегодня или завтра выйдет статья на хабре с разбором фичей и как-раз отличиями трейсера от крешлитики. Если в двух словах, то это продвинутый поиск, инструменты для анализа крешй, поиск утечек памяти, профилирование в продакшене и т.д.
Tracer это сервис техничкской аналитики. Поэтому ему персональные данные просто не нужны для работы. Но, вы можете сами, если хотите, аттачить userid к крешам или его зашифрованную версию. Все как и у Crashlytics в общем.
Более того, сейчас имеется возможность обрывать другие сессии этой учетной записи. Поэтому мне минут 10 понадобилось, чтобы увидеть как выглядит панель установки расширений. Постоянно кто-то сбрасывал сессию. Шутники блин.
Под бюджетными расходами я понимаю необходимость инвестировать в различную инфраструктуру, которая покрывает 1/7 часть обитаемой суши(а не размещена компактно на территории сопоставимой с МО), поддержку дотационных регионов, и т.д.
Не поймите меня не правильно. Я ничего не имею против Хорватии и других не больших стран, которые направляют большую часть своих доходы на улучшение материального положения своих граждан. Но мне слабо верится, что такой уровень социальной поддержки когда-нибудь будет в крупных/густонаселенных странах.
P.S. Так же считаю, что лучше выделять денежные средства населению по программам, наподобие той, которою описывает автор статьи, чем давать их на приобретение, к примеру, машины. Т.к. с точки зрения пользы для государства и общества эффект не сопоставим.
Проблема с аннотациями в том, что их нужно где-то писать) И у аннотации гораздо менее выразительный синтаксис.
Мы взяли за основу синтаксис от proguard. Сделали мы это по нескольким причинам:
1. Он и так знаком большинству разработчиков под андроид.
2. По сути это уже готовый синтаксис для указания того, где и какие манипуляции с байткодом нужно делать. То есть он буквально задизайнен под наши задачи) То есть всё что нам нужно было сделать, это дополнить его парой своих команд)
Ну и никто не мешает пользоваться аннотациями. Более того, это даже поощряется)
Возьмем пример из статьи. Ты можешь написать правило для аннотации
@AutoTraceCompatи по нему будет применено преобразование для всех методов помеченных этой аннотацией. Что очень удобно и наглядно. Но не всегда возможно, если твой метод находится в теле библиотеки и тебе туда со своей аннотацией не подлезть. Ну или если ты хочешь разметить все вызовы onCreate к примеру. Расставлять руками 1к+ аннотаций такое себе.Поверх asm.
Самый ближайший шаг, написать нормальную доку к библиотеке на гитхабе :)
Если говорить про конкретные шаги по развитию библиотеки, то её автор, Саша Асанов их подсветил в своём докладе на мобиусе https://youtu.be/KPRPJLwdf8Y?t=2527 По сути это её обогащение несколькими приятными фичами.
Саму библиотеку мы планируем так же поддерживать и развивать на основании фидбека от комьюнити. Главное, мы не хотим, чтобы она превращалась "в монстра" способного делать всё) По нашему мнению, воткнуть код в начало или конец метода, или заменить вызов метода целиком достаточно для 95% задач. И хочется, чтобы разработчики смогли делать такие манипуляции просто и быстро.
Имхо, так можно практически про любой продукт или библиотеку сказать :) "Лень было разбираться с даггером, поэтому написали toothpick" и т.д.
С вашего позволения часть про в "100+ раз больше времени" оставлю без комментариев :)
Это есть в статье, но я ещё раз подчеркну. При написании библиотеки мы ориентировались в первую очередь на скорость работы. На наших сценариях в нашем аппе aspectJ работал на порядки(!) дольше.
Во вторых, по нашему мнению, для большинства прикладных задач связанных с манипуляцией байткодом на Андроиде aspectJ избыточен. Как в силу своего общего функционала так и порогом входа. В нашей библиотеке за основу взят синтаксис полгода с котором сталкивалось подавляющее большинство андроид разработчиков.
Насильно библиотеку никто использовать не заставляет разумеется. Если вам для ваших задач подходит aspectJ - супер. Но не вижу причин, почему наличие альтернатив это плохо)
Фул тайм не больше одного =)
Но надо понимать, что часть фичей берет своё начало ещё примерно с 2017 года.
К примеру, вот доклад от 2020 года с рассказом про то, как и почему у нас появился секционный профайлер https://www.youtube.com/watch?v=D1J2udG43Fw
Добавление и удаление пользователей сейчас происходит в ручном режиме.
У нас планируется внедрение отдельной фичи для корпоративных аккаунтов, но, к сожалению, пока не могу раскрыть подробности.
https://habr.com/ru/companies/vk/articles/757416/ собственно вот :)
Привет. У нас сегодня или завтра выйдет статья на хабре с разбором фичей и как-раз отличиями трейсера от крешлитики.
Если в двух словах, то это продвинутый поиск, инструменты для анализа крешй, поиск утечек памяти, профилирование в продакшене и т.д.
Tracer это сервис техничкской аналитики. Поэтому ему персональные данные просто не нужны для работы. Но, вы можете сами, если хотите, аттачить userid к крешам или его зашифрованную версию. Все как и у Crashlytics в общем.
P.S. Про профилирование в продакшене можно мой доклад с Mobius 2020 вот тут посмотреть. https://www.youtube.com/watch?v=D1J2udG43Fw
Оставлять для тестового аккаунта возможность смены пароля — очень «здравая» идея.
В AS3 нет ключевого слова IF и указателей.
В C#, с точки зрения синтаксиса не верна конструкция var name:type.
Сам по себе код — сборная солянка из разных языков программирования.
Не поймите меня не правильно. Я ничего не имею против Хорватии и других не больших стран, которые направляют большую часть своих доходы на улучшение материального положения своих граждан. Но мне слабо верится, что такой уровень социальной поддержки когда-нибудь будет в крупных/густонаселенных странах.
P.S. Так же считаю, что лучше выделять денежные средства населению по программам, наподобие той, которою описывает автор статьи, чем давать их на приобретение, к примеру, машины. Т.к. с точки зрения пользы для государства и общества эффект не сопоставим.