1) я работаю в винде, и моя любимая программа — FAR. Из-под фара (из командной строки) я запускаю CLI-скрипты на PHP. До изучения PHP писал консольные приложения на паскале (Турбо-паскаль/Дельфи-Киликс/Фри-паскаль). На паскале легко написать интерактивное приложение (которое реагирует на нажатие клавиш и рисует нужный символ нужного цвета в нужном месте). На рнр у меня такого долго не получалось (библиотеку nCurses для винды так и не дождался). Вот и решил: А, не написать ли мне на рнр свой собственный терминальный сервер, к которому можно было бы подключатся через терминальный клиент (Telnet или Putty), который по своей сути являлся бы таким вот, воеобразным текстовым браузером типа links/linx/lynx. Мой терминальный сервер не управляет внешними приложениями, а просто предоставляет интерфейс для программистов на рнр, желающих разработать интерактивное приложение, и при этом не хочет использовать технологию AJAX в чистом виде.
Кстати, относительно MySQL у меня тоже есть мысль написать статью о концепции однофайловой CMS которая состоит из единственного файла index.php и использует базу данных MySQL для авторизации администратора. Но, это не совсем про оптимизацию (скорее даже наоборот).
А, вообще у меня была мысль «нетрадиционного» использования базы данных MySQL (вообще-то, если честно, не совсем MySQL, а, SQLite) для организации виртуальной файловой системы, а так же в качестве формата для файлового архива. И хотелось провести анализ издержек такого подхода, чтобы оценить как будет влиять формат базы на общую степень сжатия такого вот «архивчика».
И, идея была именно в быстром развертывании сайта путем прямой фтп-закачки таблицы на сервер.
Относительно надежности мобильной связи и радиоэфира вообще я не согласен.
Надежность ВСЕГДА можно наращивать, например за счет резервирования, мультиплексирования, дублирования и других техник.
Попробуйте самостоятельно просмотреть разные (не самые дешевые, но самые известные) платежные системы (хотя бы три: например, веб-мани, яндекс-деньги и ну, просто-так, до-кучи, смс-койн), и привести их сравнительный анализ (прямо тут). Уверен, что после Вашего анализа найдется кто-то, кто увидев лучший результат из Вашего списка с гордостью заявит, что-то типа того: «А, вот, в системе ХХХ-Мани комиссия еще меньше!»
В моем случае это звучит еще более дико:
Я «подсел» на рнр после паскаля когда нужно было писать консольные приложения для работы с сокетами в винде.
Основное преимущество — не нужно «таскать» за собой кучу файлов. Достаточно иметь лишь php5.exe и php5ts.dll (ну, и конечно же, php_manual_ru.chm) чтобы начать творить чудеса.
Весь подвох тут заключается что интервал времени начиная с момента завершения действия опции (примерно 17:56) до момента завершения указанной даты (23:59:59.99) как бы «выпадает», что и открывает простор для различного рода махинаций.
А, можно посмотреть какой-нибудь действующий сайт, построенный с учетом этого API? То есть, чтобы можно было посмотреть и сравнить как работает оригинальный сайт и проАПИшенный.
Технологически нет никаких проблем: первый раздел делается фат 16 — на нем 98 и XP а второй — НТФС — это для 7. при запуске 7 в меню выдается список системы для выбора: 7 / хр / неизвестная система.
Тут проблема лишь в лицензиях.
Я думаю что это больше принесло бы пользы, если бы наоборот сайт с джава-скриптом превращало бы во «многопалубную» WML-страницу для мобильника.
Но это функционал больше подходит именно браузеру, а не серверу. Хотя, на стороне сервера эта реализация позволила бы более удобно просматривать веб-сайты через вап-браузеры. То есть примерно так и работает прокси-сервер для опера-мини: он обычные сайты оптимизирует под мобильную раздачу (но, в отличие от предлагаемой схемы не реализует многопалубную закачку нескольких страниц). Многопалубность поможет мобильным пользователям, не использующим опера-мини открывать несколько последовательных веб-страниц загружая их одним файлом, и быстренько листать страницы (прыгать с одной палубы на другую) без отправки запросов на сервер.
По крайней мере именно так я (как мобильный пользователь) хотел бы загружать выдачу поисковиков, и просматривать веб-почту (а, так же, читать мобильные WAP-книги). Но мотивом для использования было бы вовсе не уменьшение трафика, а именно удобство листания (быстрота перескакивания между палубами).
Ну, а для кого-то может быть самое главное — это просто «потусоваться» вокруг какого-нибудь проекта, чтобы потом спустя N-лет после успешного запуска проекта, с гордостью написать в своем резюме строчку «участвовал в разработке известного проекта такого-то», плюс пруф-линки (с полным перечнем индивидуальных заслуг) для особо-недоверчивых потенциальных работодателей.
В этом-то как раз вся проблема и заключается: Разработать толковое API для одностраничного сервиса будет гораздо сложнее, чем разработать основной сайт (и, тем более, периодически вносить изменения в API параллельно с изменениями на основном сайте). Причем описанная проблема имеет целых два минуса:
Если разработкой плагинов к этому сервису для своего заставлять заниматься самих владельцев ресурсов, то для них это может быть ой-как напряжно (например я как разработчик могу отлично разбираться в рнр но ни-в-зуб-ногой джава-скрипт), и вряд ли будут оправданы затраты на разработку этого плагина. То есть изначально этот подход будет убыточным для владельцев ресурса, и у них не будет никакой мотивации для того чтобы разрабатывать плагины (поскольку это не принесет им никакого дополнительного дохода).
Более того, как «заставить» пользователя этого сайта начать заходить на этот сайт через сервис «одного окна»? то есть нужно будет как минимум на основном сайте сделать кнопку, или хотя бы ссылку (которую обычный пользователь может и не заметить), и еще, конечному пользователю может быть непривычно (и даже неудобно) пользоваться данным сервисом, особенно если API не будет полностью перекрывать весь функционал основного сайта (не говоря уж о том, что в самом API могут быть ошибки, а какое-то время они обязательно там будут). И у конечного пользователя не будет никакой мотивации для использования нового сервиса, поскольку он не даст ничего нового и полезного по сравнению со старым-проверенным способом.
Далее спускаемся на уровень ниже: Артигас
… облом…
Не отчаиваемся, идем на «инглиш-педию» Artigas, Uruguay
postal code: 55000
Area code(s): +598 477
И так далее, в том же духе
