Согласен с вами. Вот на всё это и ушло время, сэкономленное от возни с технической подготовкой релизов :). У нас просто еще приложение с NDK + различные данные надо подготавливать, поэтому без сборки на CI/CD сходу сделать всё правильно может быть трудно.
Странно, что у вас сборки beta и release отличаются. Бета это ведь и есть будущий релиз (ну, с некоторой вероятностью)?
Отличаются другим application id чтобы можно было бы поставить в параллель. Также в beta есть crashlytics, а в продакшене нет (это особенность проекта).
Вопрос - подписывать ли сборки для различных магазинов одинаковыми ключами или разными, неоднозначный и кажется не имеющий однозначного ответа.
Всё так. Но с bundle в конечном итоге подписывать будет магазин. Здесь скорее вопрос надо ли использовать разные application id чтобы при необходимости можно было бы установить два приложения в параллель и как-то перенести данные. Хотя кажется, шаринг данных через id тоже уже прикрылся с каких-то версий. Только какой-нибудь application-specific импорт-экспорт.
Добавлю, что api магазина App Gallery кривое, как и сам магазин. Сталкивался с ситуацией, когда после обрыва загрузки файла консоль перешла в неработоспособное состояние и пришлось руками удалять последний загруженный файл (ттт, получилось) :)
Оно примерно везде одинаково кривое, в том числе в Apple AppStore. Всё равно периодически что-то отваливается...
Также лично мне кажется, что 30 страниц описания деплоя версии - это овербюрократия, но тут конечно дело личное, кому что нравится.
Да не бюрократия, просто тестировали не на программистах и писали всё, что было непонятно.
Приложение уникально идентифицируется по Application ID (com.example.xxx). Данный ID можно видеть в веб-версии при клике на любое из приложений (https://play.google.com/store/apps/details?id=XXXX).
Если ID совпадает, то вы будете видеть приложение в различных сторах, только обновить не получится из-за различия сигнатур. Мы сейчас имеет Google, Huawei, F-Droid и просто Web версию - все с различными сигнатурами...
Никакого секрета - основатели проекта оплачивают :). Уровень расходов весьма приемлемый и в таком режиме можно жить вечно. Никаких иных инвестиционных и/или корпоративных денег не задействовано. В ближайшее время собираемся добавить донейшены, чтобы можно было бы помочь проекту финансово.
>у Tarantool есть режим hot standby, когда резервный сервер прямо на той же машине догоняется логами основного
Ценой 2x по памяти?
Да, именно так. Поэтому вариант с репликой мне нравится гораздо больше.
В таких задачах хочется гибкости, а не писать руками join/avg и прочее на каждый чих.
Для этого и хотим сделать SQL.
>Скажу лишь что в Tarantool можно добавлять и удалять таблички и индексы на лету.
А как выглядит добавление индекса на лету в однопоточном сервере?
У нас же файберы, кооперативная многозадачность и всё такое, никто не мешает перестраивать индекс в фоне.
Но должен признаться, далеко не все операции ALTER у нас сейчас могут быть сделаны в таком режиме. У нас есть наработки для фоновой перестройки индексов, но пока нет клиентов на данную фичу.
1. Можно использовать репликацию, тогда простой будет минимальный. Также у Tarantool есть режим hot standby, когда резервный сервер прямо на той же машине догоняется логами основного и, в случае проблем, занимает его место. Используется для апгрейда без простоя. Думаю автор поста расскажет подробнее.
2. Снапшот уже давно на основе MVCC в памяти без fork() и COW. Дополнительная память так или иначе требуется, объем зависит от характера нагрузки. Результаты MVCC при реальном использовании существенно лучше, чем на fork()'е.
3. Забудьте про JOIN в любой более-менее загруженном проекте. Тем более через SQL с планировщиком запросов.
Точно также как любая конференция по Java всегда начинается с рассказа о новых способах тюнинга garbage collector через настройку пяти десятков опций, так и любая конференция по той же PostgreSQL или MySQL (хорошие базы, привожу в качестве понятного примера) всегда включает в себя рассказ о «секретных» методах передачи подсказок несчастному планировщику для повышения его предсказуемости. USING INDEX и прочий не совсем SQL растёт оттуда же. SELECT… FROM… JOIN… WHERE на кластере так и вообще что-то из области ненаучной фантастики. Также хотел бы заметить, что хранить данные в нормализованном виде не всегда оправдано. В реальных задачах очень часто дешевле допустить некоторую избыточность, но при этом полностью избавиться от JOIN.
Так или иначе, мы планируем добавить SQL для задач, когда удобство использование важнее скорости и затрат на железо.
4. Изменение схемы данных в рабочем проекте — это тема для отдельной докторской диссертации статьи. Скажу лишь что в Tarantool можно добавлять и удалять таблички и индексы на лету.
Но факт остается фактом сотрудники Mail.ru в своем блоге выдают желаемое за действительное, т.к. вклад Mail.ru никак не соответствует заявлению, что «Наверное, кого-то это удивит, но мы тоже активно развиваем множество opensource-проектов.»
Фраза про несоответствует желаемого действительному не соответствует действительному.
Mail.ru в своем блоге выдают желаемое за действительное, т.к. вклад Mail.ru никак не соответствует заявлению, что «мы тоже активно развиваем множество opensource-проектов».
Давайте разберемся детальнее.
мы тоже активно развиваем множество opensource-проектов
Как минимум в Maps.Me, Sophia и Tarantool коммиты идут постоянно, в том числе в выходные и праздники. У некоторых вон даже по 14к коммитов и миллионы строчек кода. Соответствует определению активно?
Новые фичи появляются? Пешеходную навигацию пробовали в Maps.Me? А мастер-мастер в Тарантуле? Развитие есть?
Десяток проектов соответствует определению множества проектов?
Код опубликован под OSI-approved open-source лицензиями на всеми любимом GitHub?
Вообщем, усомниться можно только в слове «тоже».
Т.е. вклад Mail.ru не сравним ни по количеству, ни по качеству с теми организациями которые действительно развивают множество open-source проектов: Mozilla Foundation, Apache Software Foundation, Canonical и т.д.
Разработка open-source продуктов у Mozilla, Apache, Canonical и прочих RedHat является их core business. У Mail.Ru Group немного другой бизнес (см. выше). Глупо сравнивать яблоки и апельсины, не так ведь?
Если сравнить команду Rust'а то количество разработчиков закомитивших 10К+ кода будет где-то 30 человек, а у вас в проекте таких коммитеров около 10 человек.
FYI, в Тарантуле гораздо больше 10к+ кода и меньше 10 человек.
Что там за новую веху в программировании открыл Rust прокомментировать никак не могу, т.к. узнал об данном событие буквально только что из комментариев.
За любыми серьезными open-source проектами в большинстве своем стоит какая-то организация, а то и не одна.
Все указанные проекты в том или ином виде поддерживаются Mail.Ru, как именно — это уже малоинтересные юридические тонкости.
Некоторые вещи были куплены за квазиллиарды денег и выложены в открытый доступ (Maps.Me), некоторые — написаны полностью внутри компании (tarantool.org).
Согласен с вами. Вот на всё это и ушло время, сэкономленное от возни с технической подготовкой релизов :). У нас просто еще приложение с NDK + различные данные надо подготавливать, поэтому без сборки на CI/CD сходу сделать всё правильно может быть трудно.
Отличаются другим application id чтобы можно было бы поставить в параллель. Также в beta есть crashlytics, а в продакшене нет (это особенность проекта).
Всё так. Но с bundle в конечном итоге подписывать будет магазин. Здесь скорее вопрос надо ли использовать разные application id чтобы при необходимости можно было бы установить два приложения в параллель и как-то перенести данные. Хотя кажется, шаринг данных через id тоже уже прикрылся с каких-то версий. Только какой-нибудь application-specific импорт-экспорт.
Оно примерно везде одинаково кривое, в том числе в Apple AppStore. Всё равно периодически что-то отваливается...
Да не бюрократия, просто тестировали не на программистах и писали всё, что было непонятно.
Уточните, что имеете ввиду под приоритетом?
Приложение уникально идентифицируется по Application ID (com.example.xxx). Данный ID можно видеть в веб-версии при клике на любое из приложений (https://play.google.com/store/apps/details?id=XXXX).
Если ID совпадает, то вы будете видеть приложение в различных сторах, только обновить не получится из-за различия сигнатур. Мы сейчас имеет Google, Huawei, F-Droid и просто Web версию - все с различными сигнатурами...
Никакого секрета - основатели проекта оплачивают :). Уровень расходов весьма приемлемый и в таком режиме можно жить вечно. Никаких иных инвестиционных и/или корпоративных денег не задействовано. В ближайшее время собираемся добавить донейшены, чтобы можно было бы помочь проекту финансово.
Кстати, в Tarantool можно писать хранимки на C, а также уже есть прототип хранимок на Swift.
github.com/tarantool/tarantool-php/issues/48
2) Есть пакет github.com/tarantool/expirationd, который позволяет использовать какое-то из полей тапла под TTL
3) В 1.6 есть асинхиронный мастер-мастер, можно писать в любую ноду, но конфликты надо разруливать на клиенте (либо разбивать диапазоны). В 1.7 делаем дополнительный полный синхрон.
Да, именно так. Поэтому вариант с репликой мне нравится гораздо больше.
Для этого и хотим сделать SQL.
У нас же файберы, кооперативная многозадачность и всё такое, никто не мешает перестраивать индекс в фоне.
Но должен признаться, далеко не все операции ALTER у нас сейчас могут быть сделаны в таком режиме. У нас есть наработки для фоновой перестройки индексов, но пока нет клиентов на данную фичу.
Хотя и fsync тоже толком ничего не гарантирует.
2. Снапшот уже давно на основе MVCC в памяти без fork() и COW. Дополнительная память так или иначе требуется, объем зависит от характера нагрузки. Результаты MVCC при реальном использовании существенно лучше, чем на fork()'е.
3. Забудьте про JOIN в любой более-менее загруженном проекте. Тем более через SQL с планировщиком запросов.
Точно также как любая конференция по Java всегда начинается с рассказа о новых способах тюнинга garbage collector через настройку пяти десятков опций, так и любая конференция по той же PostgreSQL или MySQL (хорошие базы, привожу в качестве понятного примера) всегда включает в себя рассказ о «секретных» методах передачи подсказок несчастному планировщику для повышения его предсказуемости. USING INDEX и прочий не совсем SQL растёт оттуда же. SELECT… FROM… JOIN… WHERE на кластере так и вообще что-то из области ненаучной фантастики. Также хотел бы заметить, что хранить данные в нормализованном виде не всегда оправдано. В реальных задачах очень часто дешевле допустить некоторую избыточность, но при этом полностью избавиться от JOIN.
Так или иначе, мы планируем добавить SQL для задач, когда удобство использование важнее скорости и затрат на железо.
4. Изменение схемы данных в рабочем проекте — это тема для отдельной
докторской диссертациистатьи. Скажу лишь что в Tarantool можно добавлять и удалять таблички и индексы на лету.Можем помочь с протоколом, у нас все очень тупо (нужна лишь либа для MsgPack).
Фраза про несоответствует желаемого действительному не соответствует действительному.
При общении с гос.структурами меня очень часто выручает фраза: «Прошу ответить по существу вопроса» ;)
Давайте разберемся детальнее.
Как минимум в Maps.Me, Sophia и Tarantool коммиты идут постоянно, в том числе в выходные и праздники. У некоторых вон даже по 14к коммитов и миллионы строчек кода. Соответствует определению активно?
Новые фичи появляются? Пешеходную навигацию пробовали в Maps.Me? А мастер-мастер в Тарантуле? Развитие есть?
Десяток проектов соответствует определению множества проектов?
Код опубликован под OSI-approved open-source лицензиями на всеми любимом GitHub?
Вообщем, усомниться можно только в слове «тоже».
Разработка open-source продуктов у Mozilla, Apache, Canonical и прочих RedHat является их core business. У Mail.Ru Group немного другой бизнес (см. выше). Глупо сравнивать яблоки и апельсины, не так ведь?
FYI, в Тарантуле гораздо больше 10к+ кода и меньше 10 человек.
Что там за новую веху в программировании открыл Rust прокомментировать никак не могу, т.к. узнал об данном событие буквально только что из комментариев.
Все указанные проекты в том или ином виде поддерживаются Mail.Ru, как именно — это уже малоинтересные юридические тонкости.
Некоторые вещи были куплены за квазиллиарды денег и выложены в открытый доступ (Maps.Me), некоторые — написаны полностью внутри компании (tarantool.org).