Сделал себе мобильную версию блога, просто потому что надо — даже на андроиде с умным форматированием текста (который изобрела Опера) читать сайт не оптимизированный под мобильники неудобно. Для разработчиков это значит два варианта — либо сделать css файл который будет переделывать некоторые вещи и прятать ненужные блоки, либо же использовать отдельные шаблоны и в лучшем случае использовать параметр в том же контроллере что и основное приложение.

Устройство определяется через параметр user-agent в заголовке запроса - это можно использовать дальше в бизнес логике, например через php функцию. Знание устройства может влиять на то какую функциональность стоит подгружать, но это вовсе не обязательно потому что ..

Я вот уже больше месяца как делаю социальную сеть pling.ee, которая акцентируется на связи посредством мобильных телефонов (SMS/MMS) и позиционировании людей с их помощью. Достаточно перспективный проект (как твиттер на дрожжах) и популярный среди местной молодёжи тем что можно почти нахаляву общаться.

Но технически возникла небольшая получасовая техническая задачка с навигацией, и раз уж я давно не писал, то может вам тоже будет полезно. Дело в том что в поток сообщений показывается ajax-ом, подгружаясь по X-сообщений  за раз чистым html (для json просто пришлось бы больше писать). Задача - прятать кнопку "ещё" если сообщений больше нет. Очень просто, но как оказывается не всё так очевидно.

Вот возможные решения (от худшего к лучшему)

1. При первой загрузке страницы делать второй запрос и узнавать какой ID у последнего сообщения и потом детектить его показ с помощью js. Проблема в том что как правило SQL для запроса и так сложный, а тут надо его продублировать с изменением сортировки. Уже пахнет говнокодом.
   
2. Если число подгружаемых результатов меньше ожидаемых X элементов на странице то сразу прятать кнопку. Конечно с вероятностью 1/X она всё-таки будет показываться, зато
   
3. Сделать что-бы нажатие кнопки сразу показывало спрятанные закешированные результаты (и если их нет - то не показывать кнопку) + делать ajax-запрос и результаты прятать (а если их нет то тоже прятать кнопку). Тут много игры с js и к тому же подгружаются лишние данные (не факт что пользователь всегда нажимает на продолжение)
4. Использовать SQL_CALC_FOUND_ROWS что-бы расчитать число всех элементов и если их меньше чем offset + число на странице, то просто отметить последний элемент css-классом и через javascript проверить и спрятать кнопку если класс присутсвует
   

В Эстонии с 2000 года вступил в силу закон о цифровых подписях, которые стали юридически равноценны обычным рукописным. Вскоре была создана и техническая основа - компания SertifitseerimisKeskus (буквально - «центр сертификации») принадлежащая банкам и телекоммуникацонным операторам (а не государству, представляете себе!) и схема обмена данными по X.509 стандарту. Эта статья расчитана в большей мере на программистов.

Цифровая подпись?

Подпись как оказывается очень важна, а признаваемая государством - тем более. Снижаются затраты на распечатку и/или доставку счетов по оплате, договоров между работником и работодателем. Я уже не говорю про обычное подтверждение что документ прислан точно нужным человеком, а не хакером. Спасает положение то что у каждого гражданина Эстоини есть сертификат подписи, но его недостаточно. Проблема в том что одной подписи-закарючки в IT-мире недостаточно. Подпись в расширенном виде на самом деле включает в себя набор данные, в том числе не статичные.

1. Стороны подписывающие документ
2. Собственно документ или его отпечаток (говорящий о неизменном состоянии со времени подписания)
3. Свидетели (нотариус) и роль сторон
   
4. Время, место

Контейнер всей этой информации решили сделать на XML и назвать .ddoc расширением и связать с онлайн-сервисом создания и подтверждения подписей — Digidoc. За основу берутся основные свойства эстонской ID-карточки - авторизация, подпись и шифрование и в результате имеем:

• цифровая подпись файлов (DigiDoc клиент, портал или третья сторона через DigiDocService)
• шифрование и дешифрование файлов (DigiDoc клиент)
• подтверждение действительности (digidoccheck)
• подпись электронной почты
• подпись или авторизация с помощью мобильного телефона (Mobiil-ID)
  

Контейнер со времени создания претерпел некоторые изменения, сейчас есть версия 1.3 основана на стандарте XAdES-X-L расширенных электронных подписей.

Процесс создания подписи с DigiDocService

Теперь собственно о главном что может понадобится на любом сайте. Допустим вы продаёте рога и копыта и хотите всё юридически правильно оформить. По-старинке это было бы типичный checkbox мол «согласен с условиями». Теперь же можно получить юридически действительную подпись клиента под любым договором, распиской купли-продажи или договора предоставления услуги.

Недавно вышел HTML5, и хотя я надеялся что де-факто стандартом станет XHTML2, видимо этому не судьба. Следование веб-стандартам впринципе дело самодисциплины — кто-то пишет как умеет, а для кого-то это средство подчеркнуть свой проффесионализм.

Тэги

Основным нововведением стало внесение давно ожидаемых новых элементов, благодаря которым содержание выглядит чуть более семантичным, хотя только разве что в блогах. Хитрые дизайнерские сайты с плавающими блоками видимо лучше делать на более общих div'ах

Facebook - популярная социальная сеть где можно написать своё приложение. Не люблю толочь воду в ступе, поэтому сразу к делу. Встраивать можно двумя направлениями: внешнее приложение в Facebook или Facebook-данные во внешнее приложение (aka Facebook Connect). Тут я буду говорить о первом, что в принципе более трудоёмко и интересно. Как правило смысл facebook-приложение несёт две функциональности - взаимодействие с друзьями и информативное интегрирование в профиль пользователя.

Основы

Встраивать приложение можно в следующие места..

• Canvas - собственно страница с приложением. Доступна по ссылке http://apps.facebook.com/НАЗВАНИЕ_ПРОГРАММЫ/
• Profile box - маленький бокс внутри самого профиля пользователя
• Profile tab - новый таб в профиле
• Boxes tab - небольшой блок в табе boxes
• News feed - доступ к потоку обновлений
• Requests box - интерактивные сообщения другим пользователям

Интеграция производится смешанными возможностями..

• REST API (http://api.new.facebook.com/restserver.php) который даёт "тяжёлый" доступ для backend-а с возможностями загрузки фото, видео, получении списков друзей, событий, комментариев и тп.
• FQL - способ запрашивать данные по REST не просто через параметры метода, а уже через SQL-подобный синтаксис
• FBML - урезанный HTML + свои тэги которые Facebook интерпретирует в окне в своём стиле и дизайне и кэширует при инлайновом показе. Куча заморочек с встроенным валидатором тэгов
• xFBML - FBML-тэги используемые в своём приложении
• FBJS - урезанный JS

Два пути

Теперь когда основные термины понятны перейдём к самому приложению которое размещается в Canvas. После создания нового приложения через developer app, скачивания REST-библиотеки для php, выкладывании приложения на свой сайт и установки в настройках URL для Canvas становится видно что доступно два способа запуска - через iframe (+XFBML) либо чистый FBML который будет храниться на facebook. Понятное дело первый вариант самый простой. После создания программы и добавления/подтверждения в своём профиле, показ Canvas'а будет сопровождаться обычным iframe + GET-параметрами с префиксом fb_sig_, из которых самый важный это fb_sig_canvas_user. Второй вариант более муторный, но более тесно связан с FB.