действительно — чем больше ограничений на подачу объявлений от одного лица (читайте — монетизация), тем больше объявлений становится с других площадок.
PS Сужу по своему доморощенному агрегатору объявлений.
А мне понравилось! Описательная классификация абонентов и (попытка) подбор тарифа под каждый класс. И есть вопрос — какая компания предложит вариант конвертации гигабайтов в минуты, а не только минут в гигабайт (как у одной компании на букву Т). Но может этого никогда не будет для 30% доли абонентов.
Список стран как бы… как бы не полон.
Интересны лидеры — США, Германия, Япония, Китай.
То что сделали в России можно считать системой заработка некоторым кругом лиц. Как минимум потому, что (о неожиданность!) купить устройство стало просто дороже, а кроме самого устройства потребуются ещё затраты… которые надо еще отбить. Это про сверхмалый бизнес (ИП и ЕНВД), а крупный… крупный создаёт свои ОФД, пример — Магнит.
Ложки дёгтя
Раз. Вместо WebView из нескольких версий мы получили меганабор разных версий System WebView, каждый со своими прибабахами. Т.е. заранее вообще трудно предагатать, какая версия Webview стоит у пользователя и можно только порекомендовать обновить его до текущей, которая присутствует в сторе.
Два. Webview это не бразуер. Т.е. весь функционал, который есть в браузере не работает. А значит снова привет решения аля плагины Кордова. А это камера, работа с файлами и другое взаимодействия с железом.
Три. Подобное решение имеет право на жизнь, можно даже написать свою версию с рюшечками и впнами. Но Кордова опять таки дает чуть больше — например выход сразу на две платформы — Андроид и iOS (а для любителей Windows Phone и туда тоже). Из одной кодовой базы.
Я не осилил Форт, хотя много раз пытался (привет eserv :), впрочем как и asm, C/C++, да и PureBasic не просто давался, но неожиданно для себя появился интерес к подобным проектам, не всё же на JS «лабать»
И еще — есть такая штука как PureBasic, надстройка над FASM, которая позволяет разрабатывать программы на высокоуровневом бейсик подобном (диалекте) языке. Производительность программинга увеличивается в разы, если не на порядки! Вот бы проекту такую штуку!
Столкнувшись с этой темой навязывания новых касс и сопустсвующих услуг в качестве лица, которому это всё навязали (да, мы сделали апгрейт ФР, по деньгам раза в 1.5 больше, чем «обещали обещалкины») — остаётся одно желание, чтобы больше ничего не трогали и работало как есть, ну может чтобы чуть быстрее. Ибо это всё не способствует бизнесу (ведению торговли), а только отвлекает на себя денежно-материальные ресурсы.
А все описываемые «фичи» могут быть и без онлайн-касс, может даже и лучше, ИМХО.
Теретически интерфейсную часть можно оставить на HTML5, а фоновые задачи реализовать нативно. Есть и готовые плагины для поддержки фоновых задач для Cordova. Но да, остаётся вопрос Native look UI для HTML5 части…
подходящий пример, только сразу писать промежуточный слой и делать бэкап базы себе куда-нибудь, потому что «завтра может не наступить никогда» в модных сервисах.
а куда стартапу податься? если с Firebase можно начать бесплатно или с 25 $/mo, то другие сервисы обходятся дороже за счет большей цены или за счёт требуемой поддержки (те же опен соурс решения для которых требуется хостинг — облачный и масштабируемый, читай те же грабли и зачастую специалист да за деньги — то же, но другие грабли).
Вот и привязываешь своё решение к Firebase. Решение же с proxy также требует серверных ресурсов/специалистов для развёртывания и поддержки. Т.е. появляется еще одно звено.
Отказ же вообще от серверной части (есть у меня один проект где я колеблюсь в использовании/не_использовании firebase в качестве proxy), то тогда нагрузка вся ложиться на клиентские устройства и получаем получаем проблему с разными версиями приложений — кто то обновился до актульной, кто то не обновился вообще, а кто то по середине.
Кстати, как я понял одна из претензий, что нельзя отследить используемый траффик (SSL или еще что нибудь) доступными для пользователя средствами Firebase — решение будет в продолжении или будет know how под dna?
насколько я помню из попыток парсинга авито id картинки привязано к объявлению через внутрение структуры системы, недоступные конечному пользователю. Т.е. из урла картинки получить само объявление у меня не получилось, хотя может только у меня.
пользователь не имеет прямого доступа к контейнеру, только приложение-прокладка, которая транслирует запрашиваемый id картинки к серверу -> к контейнеру (может быть несколько, на разных дисках) -> к блоку данных (сразу несколько картинок, для помещения их в кэш) -> конкретная_картинка
2. кэш диска оперирует с файлами? так нет же, с блоками самого диска. С файлами работает кэш приложения
1. перескоков не больше, если не меньше, чем при чтении из файловой системы. К тому же солид контейнер можно создать заранее (в том числе разместив как RAW) избежав проблемы дефрагментации полностью.
Конечно имплементация может изменить многое, если не всё :)
Интересная тема… раньше, когда требовалось хранить значительное количество бинарных данных, то использовали solid файл, где доступ к конкретной записи осуществлялся по смещению и размеру (можно закодировать хоть в имени файла). Конечно не было таких нагрузок, как у авито, но вопросы чтения, добавления (пишем в конец файла), бэкапа не стояли остро при полностью устраивающей нас производительности. Конечно, замена конкретного файла обходился дорого (или дырка в solid или пересборка всего файла), но эта операция (замена) была нужна чисто теоретически, так как «хранилось всё».
Спасибо, как раз подхожу к этому рубежу. Но смущается почему только коммандная строка? Неужели нет GUI решений, которые возьмут часть вопросов по сохранению данных по приложению между процессами подписания обновлений на себя??
А еще про демку nativescript, которая притормаживает на лоу енд устройстве с Андроид 5.1, впрочем где многие кордова приложения работают «влёт»
PS Сужу по своему доморощенному агрегатору объявлений.
А мне понравилось! Описательная классификация абонентов и (попытка) подбор тарифа под каждый класс. И есть вопрос — какая компания предложит вариант конвертации гигабайтов в минуты, а не только минут в гигабайт (как у одной компании на букву Т). Но может этого никогда не будет для 30% доли абонентов.
Интересны лидеры — США, Германия, Япония, Китай.
То что сделали в России можно считать системой заработка некоторым кругом лиц. Как минимум потому, что (о неожиданность!) купить устройство стало просто дороже, а кроме самого устройства потребуются ещё затраты… которые надо еще отбить. Это про сверхмалый бизнес (ИП и ЕНВД), а крупный… крупный создаёт свои ОФД, пример — Магнит.
Раз. Вместо WebView из нескольких версий мы получили меганабор разных версий System WebView, каждый со своими прибабахами. Т.е. заранее вообще трудно предагатать, какая версия Webview стоит у пользователя и можно только порекомендовать обновить его до текущей, которая присутствует в сторе.
Два. Webview это не бразуер. Т.е. весь функционал, который есть в браузере не работает. А значит снова привет решения аля плагины Кордова. А это камера, работа с файлами и другое взаимодействия с железом.
Три. Подобное решение имеет право на жизнь, можно даже написать свою версию с рюшечками и впнами. Но Кордова опять таки дает чуть больше — например выход сразу на две платформы — Андроид и iOS (а для любителей Windows Phone и туда тоже). Из одной кодовой базы.
И еще — есть такая штука как PureBasic, надстройка над FASM, которая позволяет разрабатывать программы на высокоуровневом бейсик подобном (диалекте) языке. Производительность программинга увеличивается в разы, если не на порядки! Вот бы проекту такую штуку!
А все описываемые «фичи» могут быть и без онлайн-касс, может даже и лучше, ИМХО.
Вот и привязываешь своё решение к Firebase. Решение же с proxy также требует серверных ресурсов/специалистов для развёртывания и поддержки. Т.е. появляется еще одно звено.
Отказ же вообще от серверной части (есть у меня один проект где я колеблюсь в использовании/не_использовании firebase в качестве proxy), то тогда нагрузка вся ложиться на клиентские устройства и получаем получаем проблему с разными версиями приложений — кто то обновился до актульной, кто то не обновился вообще, а кто то по середине.
Кстати, как я понял одна из претензий, что нельзя отследить используемый траффик (SSL или еще что нибудь) доступными для пользователя средствами Firebase — решение будет в продолжении или будет know how под dna?
1. перескоков не больше, если не меньше, чем при чтении из файловой системы. К тому же солид контейнер можно создать заранее (в том числе разместив как RAW) избежав проблемы дефрагментации полностью.
Конечно имплементация может изменить многое, если не всё :)