К сожалению с одной кнопкой это уже не в первый раз, прошлый раз был в феврале-марте 2012 года, тогда был скрипт ok3.js, код которого при User-Agent ПК создавал кнопки соц. сетей, а при использовании мобильного User-Agent делал редикет со на Andoid/Symbian приложение, завязанное на платную смс подписку.
// с учетом отсутствия в задаче необходимости поддержки отрицательных чисел/пустых строк/etc:
<?php
# Короче у меня не получается =(
str_repeat(0,$b-strpos($a,'.')).$a // len = 34
# изврата ради, так как регулярок вроде бы еще не было =)
preg_replace('|^(\d+)|e',"str_pad(\$1,$b,0,0)",$a) // len = 50
Тут надо учитывать то, что выводимое время в таком случае — это время в тот момент когда «отрисовывался» prompt (нажат Enter/завершилась задача). А решение автора и tmux/screen пишут именно текущее время.
Простите, но как приложение поймет что ответ является только разницей, а не полным набором, если оно использует фреймворк для работы с сетью/http, а не само рулит кэшированием? Ведь в этом случае оно не знает какие были использованы заголовки, а исходя из статьи выходит что формат ответа будет идентичен, за исключением кол-ва элементов, что не может быть достоверным признаком для определения типа ответа (обновление или полные данные).
Я уточню вопрос — представим себе абстрактное клиентское приложение делающее запросы:
No cache version: запрос http://api.mynextfacebook.com/friends/ -> 200 OK -> 298 друзей
IF-MODIFIED-SINCE=10: запрос http://api.mynextfacebook.com/friends/ -> 304 Not Modified
... произошло добавление двух друзей ...
IF-MODIFIED-SINCE=20: запрос http://api.mynextfacebook.com/friends/ -> 200 OK -> 2 друга
IF-MODIFIED-SINCE=30: запрос http://api.mynextfacebook.com/friends/ -> 304 Not Modified
Цифры 10, 20, 30 — взяты для примера, думаю что всем понятно что там должен быть честный timestamp.
Получая такие ответы от сервера приложение должно merge имеющего кэша и нового ответа, результат этого merge оно должно закэшировать и именного его использовать. Но при этом отличить ответ — это полный объект или только обновление при кэшировании можно только по заголовкам.
Но при использовании какого-нибудь network framework'a приложение ожидая ответ от сервера на запрос списка друзей получает совершенно не то:
— приложение может и знать-не-знать про кэширование — так как эту задачу на себя берет framework, следовательно оно не обязано знать что до такого-то момента у пользователя было 298 друзей;
— network framework — совершенно не обязан делать merge кэша и результата нового запроса, так как его задача получить данные, а что они из себя представляют JSON/XML/XHTML — это не его головная боль, следовательно не его дело менять данные ответа от сервера.
Таким образом получается что для работы такого поведения сервера клиентское приложение должно хранить 2 версии кэша — network framework, для того чтобы работать по rfc2616, + приложение должно знать о том какое было состояние до запроса, чтобы вычислить текущее положение дел (сделать merge). А если добавить к этому то что приложение вынужденно знать использовался ли кэш или нет (чтобы понять как обрабатывать ответ — добавлять 2 друзей или список состоит из 2-х друзей) — возникает вопрос network framework получается нужен чтобы сокет открыть и пописать+почитать в/из него? Network framework используют как-раз с целью избавить приложение от необходимости работать с сетью. И как cherry-on-top вспомним то, что кэш — субстанция которая может быть удалена разными механизмами и далеко не все из них удосужатся сообщить приложению об удалении его кэша.
Таким образо либо я что-то не понял из статьи, либо что-то очень хитрое придумал, либо тут все-таки RESTful API собака зарыта.
P.S. под network framework — понимаются например MKNetworkKit или иной, которому для работы нужно лишь сказать куда класть кэш и можно начинать делать запросы.
Простите, я что-то не понял:
>Если запрос не вернет записей, отправляем 304 Not Modified. Таким образом, если у пользователя 300 друзей и только двое из них были добавлены недавно, то ответ будет содержать только две записи.
Насколько я понимаю, если есть изменения после IF-MODIFIED-SINCE — нужно прислать обновленный объект (список друзей), а не разницу. Так как решается вопрос инвалидации имеющегося у клиента кэша, таким образом, если объект на сервере изменен — это не проблемы клиента как именно он изменился, ему нужен актуальный объект. Или здесь какая-то хитрая RESTful API собака зарыта?
У меня было ровно тоже самое, начинал сначала несколько раз — тоже самое, но когда указал пароль типа «2ah6tcb8» вместо просто цифрового пароля — прокатило с первого раза.
Небольшой лайфхак — как попасть на секретный уровень ТП для технарей, где знают что такое arp- icmp- пакеты и не предполагают что во всем виноваты вирусы:
0. отключаем (если включен, конечно) pptp/l2tp
1. вываливаем в локальную сеть кучу arp- запросов на половину ipv4 (оставим в стороне юридическую сторону сего деяния)
2. ждем 10-15 минут
3. видим что линк погас (да, нас тут забанили напроч)
4. смело звоним в ТП «не работает интернет, не подключен сетевой кабель» — тут придется постараться, так как важно доказать что линка не сетевой карточке реально нет
5. выясняем что абонент заблокирован, получаем секретный «код заявки» и загрузку секретного уровня
6. придумываем объяснения на «автоматика отключила за флуд» и даем слово что «сделаем чтобы такого не повторилось», получаем прям сразу включенный порт
7. PROFIT
P.S. в моем случае торрент на сидбоксе продолжал работать при упавшем pptp и действительно флудил в локальную сеть в поисках своих пиров, пока соединение поднималось мой
P.P.S. default city
Ответственно заявляю, что именно так и работаю, при этом читаю хабр по вечерам или в перекурах — с мобильного. Но мимо такого опроса пройти просто не смог.
Попробовать-то можно, только что проверил с простым кольцом — не удобно, приходится ещё средним пальцем помогать (чтобы не сползало) и сильно зависит от влажности пальца под кольцом. Мой вердикт: кольцо управления — либо сильно большое (будет болтаться), либо двумя руками.
Старое, конечно, 2011 год всё-таки, но вот тетрис в бутлоадере для HD2 — https://www.xda-developers.com/magldr-1-13-for-hd2-released/
Цифры 10, 20, 30 — взяты для примера, думаю что всем понятно что там должен быть честный timestamp.
Получая такие ответы от сервера приложение должно merge имеющего кэша и нового ответа, результат этого merge оно должно закэшировать и именного его использовать. Но при этом отличить ответ — это полный объект или только обновление при кэшировании можно только по заголовкам.
Но при использовании какого-нибудь network framework'a приложение ожидая ответ от сервера на запрос списка друзей получает совершенно не то:
— приложение может и знать-не-знать про кэширование — так как эту задачу на себя берет framework, следовательно оно не обязано знать что до такого-то момента у пользователя было 298 друзей;
— network framework — совершенно не обязан делать merge кэша и результата нового запроса, так как его задача получить данные, а что они из себя представляют JSON/XML/XHTML — это не его головная боль, следовательно не его дело менять данные ответа от сервера.
Таким образом получается что для работы такого поведения сервера клиентское приложение должно хранить 2 версии кэша — network framework, для того чтобы работать по rfc2616, + приложение должно знать о том какое было состояние до запроса, чтобы вычислить текущее положение дел (сделать merge). А если добавить к этому то что приложение вынужденно знать использовался ли кэш или нет (чтобы понять как обрабатывать ответ — добавлять 2 друзей или список состоит из 2-х друзей) — возникает вопрос network framework получается нужен чтобы сокет открыть и пописать+почитать в/из него? Network framework используют как-раз с целью избавить приложение от необходимости работать с сетью. И как cherry-on-top вспомним то, что кэш — субстанция которая может быть удалена разными механизмами и далеко не все из них удосужатся сообщить приложению об удалении его кэша.
Таким образо либо я что-то не понял из статьи, либо что-то очень хитрое придумал, либо тут все-таки RESTful API собака зарыта.
P.S. под network framework — понимаются например MKNetworkKit или иной, которому для работы нужно лишь сказать куда класть кэш и можно начинать делать запросы.
>Если запрос не вернет записей, отправляем 304 Not Modified. Таким образом, если у пользователя 300 друзей и только двое из них были добавлены недавно, то ответ будет содержать только две записи.
Насколько я понимаю, если есть изменения после IF-MODIFIED-SINCE — нужно прислать обновленный объект (список друзей), а не разницу. Так как решается вопрос инвалидации имеющегося у клиента кэша, таким образом, если объект на сервере изменен — это не проблемы клиента как именно он изменился, ему нужен актуальный объект. Или здесь какая-то хитрая RESTful API собака зарыта?
0. отключаем (если включен, конечно) pptp/l2tp
1. вываливаем в локальную сеть кучу arp- запросов на половину ipv4 (оставим в стороне юридическую сторону сего деяния)
2. ждем 10-15 минут
3. видим что линк погас (да, нас тут забанили напроч)
4. смело звоним в ТП «не работает интернет, не подключен сетевой кабель» — тут придется постараться, так как важно доказать что линка не сетевой карточке реально нет
5. выясняем что абонент заблокирован, получаем секретный «код заявки» и загрузку секретного уровня
6. придумываем объяснения на «автоматика отключила за флуд» и даем слово что «сделаем чтобы такого не повторилось», получаем прям сразу включенный порт
7. PROFIT
P.S. в моем случае торрент на сидбоксе продолжал работать при упавшем pptp и действительно флудил в локальную сеть в поисках своих пиров, пока соединение поднималось мой
P.P.S. default city