WebAuthn — тоже такое себе… пользуюсь. юзерам оччень нравится (да и мне тоже): ткнул в иконку, приложил палец, работаешь… или в винде: открыл сайт, ввёл пин-код своей же собственной винды, работаешь…
но! мне актитвно не нравятся несколько моментов:
а) подключение к проекту — не самая тривиальная штука, даже при уже готовых библиотеках. там и бэк, и фронт, и БД — джун за полчасика побыстрячку не прикрутит, миддла давай что ли, ну это ещё ладно;
б) производится аутентификация не юзера, а устройства: хорошо если телефона, а можно и десктоп (общий?) так же завести, сервер и не заметит разницы.
т.е. сервер видит только устройство (телефон), а сколько разных людей авторизуют это устройство своим отпечатком — ему уже иррелевантно;
в) когда просишь приложить пальчик, ты уже должен знать, какого именно юзера ты пускаешь. хотелось бы что-то типа «сначала палец, а там уже посмотрим кто ты, и куда тебя пускать», но нет — работает только «юзер Ваше Величество… чо, правда? а ну, докажи!»
а через ATTACH DATABASE разве нельзя было решить задачу?
в смысле, подкачать дополнительную базу с переводами, соединить с основной, а при выборке данных просто JOIN-ить с таблицей из присоединённой базы.
делал подобное в базе на 8-10К записей, и производительность (чтения) была очень приемлемой для мобильного устройства. подключение же дополнительных данных вообще было мгновенным.
осталось лишь добавить, что трафик между приложением и сервером разработчика тоже нужно каким-то образом защищать.
не забываем, что весь трафик идёт через DNS «плохих ребят», которые вполне легко могут начать делать поддержку вот таких «типа защищённых» покупок для особо популярных приложений.
ну и решение не использовать свой сервер, думаю, чаще всего принимают не из-за лени или глупости, а из банальной бедности (ну, или жадности): мелкому разработчику совсем не хочется поддерживать неубиваемый сервер, способный выдерживать серьёзные нагрузки.
package lesscss;
use File::stat;
use nginx;
sub handler
{
my $r = shift;
$r->send_http_header("text/css");
return OK if $r->header_only;
if(-f $r->filename)
{
$less = $r->filename;
$less =~ s/\"//g;
$css = $less;
$css =~ s/\.less$/.css/gi;
if(!stat($css) || stat($less)->mtime > stat($css)->mtime)
{
system("PATH=/opt/local/bin lessc \"".$r->filename."\" > \"".$css."\"");
}
if(-e $css)
{
$r->sendfile($css);
$r->rflush;
}
}
return OK;
}
1;
__END__
etc/nginx/vhost/???
location ~* ^.+\.less$ { perl lesscss::handler; }
в итоге nginx сам смотрит за изменениями в .less-файле, и незаметно обновляет .css, лежащий тут же рядом.
решение не идеально, но для домашнего сервера пойдёт.
сидишь ты, значит, в своей машине в пробке рядом с таким автобусом, или даже медленно едешь, притёршись к его левому борту, и горько материшься, потому что эта гадина каждые N минут снимает с твоей карточки M денег…
спасибо, погуглил. наверное долго придётся ждать появления таких батареек в магазинах, особенно учитывая текущую всеобщую истерию с фукусимой.
… и всё равно интересно, почему же тогда робо-собака у них ходит либо с толстым кабелем за спиной, либо мощно фыркает дизель-генератором, а в прошумевшем не столь давно экзо-скелете сейчас думают, куда бы засунуть баки для того же генератора.
круто! мега-супер-робот взлетает со всей этой фигнёй на борту, и работает вдоль границы целых 15 минут, пока держится его батарейка!
… или наша цивилизация таки уже совершила технологический скачок в области портативных источников питания?
чтобы у кого-то всегда были под рукой готовые велосипеды, их должен кто-то изобретать, неправда ли?
ну, и что для одного является "изобретением целого велосипеда", для другого ясное и очевидное решение.
нет уж, давайте всё-таки вернёмся к "программистскому складу ума"...
данная задача "состоит ли элемент в массиве данных" решится значительно быстрее, если данные изначально организовывать по-другому: for($i=0; $i < $mass; $i++) $test_array[$i] = true;
в таком случае время поиска элемента isset($test_array[$i]) Вас приятно удивит.
если работать не с целыми числами, а строками, то, предполагаю, такой поиск удивит Вас ещё сильнее и приятнее. =)
заставьте своего флэшера решить эту проблему.
флэш прекрасно "тянется".
если я правильно помню (пусть меня поправят, если таки не), нужно почитать про класс Stage и его события.
всё дело в бесконечности: для любой длины резинки существует номер шага улитки, на котором она проходит это расстояние.
точно так же доказывается, что если на каждом шаге в коробку класть 10 шариков и при этом доставать лишь 1, то, повторяя эти шаги бесконечно, получим пустую коробку.
но! мне актитвно не нравятся несколько моментов:
а) подключение к проекту — не самая тривиальная штука, даже при уже готовых библиотеках. там и бэк, и фронт, и БД — джун за полчасика побыстрячку не прикрутит, миддла давай что ли, ну это ещё ладно;
б) производится аутентификация не юзера, а устройства: хорошо если телефона, а можно и десктоп (общий?) так же завести, сервер и не заметит разницы.
т.е. сервер видит только устройство (телефон), а сколько разных людей авторизуют это устройство своим отпечатком — ему уже иррелевантно;
в) когда просишь приложить пальчик, ты уже должен знать, какого именно юзера ты пускаешь. хотелось бы что-то типа «сначала палец, а там уже посмотрим кто ты, и куда тебя пускать», но нет — работает только «юзер Ваше Величество… чо, правда? а ну, докажи!»
в смысле, подкачать дополнительную базу с переводами, соединить с основной, а при выборке данных просто JOIN-ить с таблицей из присоединённой базы.
делал подобное в базе на 8-10К записей, и производительность (чтения) была очень приемлемой для мобильного устройства. подключение же дополнительных данных вообще было мгновенным.
теперь осталось только собрать урожай гмейл-пейпэл-и-т.п. экаунтов и хорошенько монетизировать всю идею. =)
не забываем, что весь трафик идёт через DNS «плохих ребят», которые вполне легко могут начать делать поддержку вот таких «типа защищённых» покупок для особо популярных приложений.
ну и решение не использовать свой сервер, думаю, чаще всего принимают не из-за лени или глупости, а из банальной бедности (ну, или жадности): мелкому разработчику совсем не хочется поддерживать неубиваемый сервер, способный выдерживать серьёзные нагрузки.
etc/nginx/nginx.conf
etc/nginx/perl/lesscss.pm
etc/nginx/vhost/???
в итоге nginx сам смотрит за изменениями в .less-файле, и незаметно обновляет .css, лежащий тут же рядом.
решение не идеально, но для домашнего сервера пойдёт.
… и всё равно интересно, почему же тогда робо-собака у них ходит либо с толстым кабелем за спиной, либо мощно фыркает дизель-генератором, а в прошумевшем не столь давно экзо-скелете сейчас думают, куда бы засунуть баки для того же генератора.
… или наша цивилизация таки уже совершила технологический скачок в области портативных источников питания?
я пользовался вот этой статьёй — www.mobileorchard.com/code-sharing-via-static-libraries-and-cross-project-references/ — кажется, там немного другой подход.
по-крайней мере, не нужно самому следить за зависимостями: при смене платформы XCode сам пересобирает все «связанные» проекты библиотек.
ну, и что для одного является "изобретением целого велосипеда", для другого ясное и очевидное решение.
данная задача "состоит ли элемент в массиве данных" решится значительно быстрее, если данные изначально организовывать по-другому: for($i=0; $i < $mass; $i++) $test_array[$i] = true;
в таком случае время поиска элемента isset($test_array[$i]) Вас приятно удивит.
если работать не с целыми числами, а строками, то, предполагаю, такой поиск удивит Вас ещё сильнее и приятнее. =)
пока не особо много новой инфы.
народ изо всех сил ищет изменения в мелочах.
просто апдейт вышел где-то чуть ли не около часа назад.
флэш прекрасно "тянется".
если я правильно помню (пусть меня поправят, если таки не), нужно почитать про класс Stage и его события.
для каждого шарика номер N в бесконечности существует шаг M, на котором этот шарик изымут из коробки.
точно так же доказывается, что если на каждом шаге в коробку класть 10 шариков и при этом доставать лишь 1, то, повторяя эти шаги бесконечно, получим пустую коробку.