Не так давно Яндекс.Метрика анонсировала открытый API, с помощью которого можно получить доступ практически ко всем функциям Метрики из собственной программы.
Сегодня я хочу немного рассказать об использовании этого API и о том, как на его основе создать простой widget для Android-устройств.

Пожалуй, один из определяющих вопросов в жизни очень многих стартапов, как привлечь деньги в свой проект. Об особенностях работы в данном направлении 9 сентября в Бизнес-инкубаторе «Ингрия» рассказал Александр Егоров, генеральный директор компании «Рексофт», бизнес-ангел. Ниже представлено несколько интересных наблюдений, советов и рекомендаций.

Нам в Эльбе довольно часто задают вопросы по типу «Я „упрощёнщик“, у меня есть электронный кошелёк в Яндекс.Деньгах, как его в доходах-расходах учитывать и перед налоговой отчитаться?».

Если погуглить, в Интернете можно найти массу информации и экспириенса в этой области. Однако мы хотим сэкономить ваше драгоценное время, и поэтому поделимся своими знаниями.

Одной из наиболее заметных тенденций современного интернета является ослабление роли «классических» десктопных мессенджеров, еще недавно безраздельно властвовавших на компьютерах пользователей, и возрастание роли мобильных и веб-клиентов. Последние приобрели особенную популярность благодаря почтовым сервисам нового поколения, а также социальным сетям.

Не осталась в стороне и компания Mail.Ru, в 2008 году запустившая первую версию Mail.Ru Агента для веба (далее – просто Агента).

Друзья, вот так, совершенно незаметно для нашей команды прошел год с момента основания Копини. Мы писали идеалистические посты про 600 тыс руб. на запуск, офис и команду, объем рынка и продажи. Многие нам предрекали провал, банкротство и армагедец. Но все оказалось не так уж плохо…



Под катом история нашей компании за год, от основания, первых продаж и привлечения бизнес ангела, до закрытия раунда в $500 тыс. от SoftLineVP. Ну и конечно отчет, ошибки и наш опыт.

Я являюсь разработчиком в компании, которая занимается рассылками СМС и мобильным маркетингом. В мои обязанности входит разрабатывать десктопные приложения на Adobe AIR. Но после появления в нашем офисе Ipad'а, с легкой подачи Arsenichev, захотелось портировать приложение под него. В виду того, что AIR вроде как и позволяет создавать мобильные приложения, но в процессе глубокого изучения особенностей, оказалось, что на портирование всего функционала на мобильные платформы уйдет уйма времени. Связано это с быстродействием платформы, а так же с огромной разницей интерфейса в Desktop и Touch-приложениях для мобильных платформ.
От мобильного приложения не требовалось соответствия функционалу "старшего брата", поэтому мы и решили его разрабатывать на HTML5.

О выборе языка разработки
Программа по-умолчанию не должна была быть нагружена огромным функционалом и должна работать как минимум на iOS и Android — было решено сделать её на HTML5. Из этого вытекают как свои плюсы, так и минусы.
Плюсы:
+ пишешь одно приложение — работает и на iOS, и на Android и на всем остальном, что поддерживает JS и HTML5 (хоть прямо из браузера отправляй);
+ высокая скорость разработки;
+ простота разработки;
+ наличие готовых фреймворков;
+ не требует никаких аккаунтов в appstore и android market.

Минусы:
- невысокая скорость работы на Android;
- невозможно использовать API платформ;
- нет доступа к адресной книге;
- невозможно полностью перевести приложение в оффлайн, используя для работы только непосредственно пересылку данных на наш сервер (об этом чуть ниже).
- непривычная установка приложения, в виду отсутствия его в appstore и android market. Приложение «устанавливается» путем добавления его на хоумскрин из адресной строки. Иконки присутствуют.

Под катом картинки и много текста.

Все началось с ...

Несколько лет назад я только начал знакомиться с web-программированием, и одним из моих первых «проектов» был каталожек сайтов. Разработка велась для себя, в целях повышения опыта. Но т.к. аналогичных сайтов тьма-тьмущая, хотелось сделать что-то особенное. Я решил, что каждый сайт в каталоге будет представлен со скриншотом. Как все это автоматизировать я не знал, потому первое время я делал все скриншоты руками и заливал их уже как готовые файлы.

Шло время, проект «покрылся пылью», времени заниматься ним не было, но примерно год назад накатила новая «волна креатива» и захотелось мне решить «задачку автоскриншотера».

Первое, что пришло на ум — это готовые сервисы по созданию скриншотов, предоставяющие API. Но, перебрав некоторые (сейчас уже названия не помню), понял, что это не для меня: возможности были довольно урезаны, иногда приходилось довольно долго ждать «очереди», иногда сайты на скринах выглядели довольно убого. А главной проблемой было то, что все это должно было работать асинхронно и из скрипта я бы не смог понять — то ли сервис отдал мне временную картинку-заглушку, то ли уже готовый скриншот сайта.

Итого, я решил сделать собственный «велосипед».

Привет хаброчеловек!

На днях я выпустил детское приложение-раскраску для iPad Colorific. Разработка затянулась на год, но теперь, когда основная работа завершена, я хочу поделиться некоторыми вынесенными из всей этой истории уроками.



«Баловаться» с Cocoa я начал примерно полгода спустя после того, как у меня появился белый iMac G5 20" в 2005 году. Тогда я потратил на него я почти всю свою месячную зарплату. После 4-х лет на Slackware и Debian Linux макось (на тот момент Tiger) была как глоток свежего воздуха. Дальше баловства дело не заходило. Написал пару утилит для себя на Cocoa, поэксперементировал с AppleScript и отложил это дело в долгий ящик.

В следующий раз я открыл XCode, когда Apple зарелизил свой SDK. Я был полон энтузиазма, ведь они пошли примерно тем путем, о котором я говорил друзьям. Мне всегда не нравилась «анархия» в J2ME разработке, и казалось, что Apple должен пойти по пути Brew от Qualcomm, только сделать это не так «топорно». Собственно всё — среда разработчика XCode, Instruments и App Store казались мне просто идеалом того, как дожен выглядеть мобильный SDK. У меня был совсем небольшой опыт на заре J2ME, и мы даже не могли мечтать о такой инфраструктуре.

Вы наверняка не раз видели javascript-реализации контекстных меню на базе популярных библиотек, таких как jQuery и prototype. А значит обязательно сталкивались с основными их недостатками: неудобностью API, большим количеством кода, требовательностью к ресурсам, любовью к генерации огромного количества html кода. В один прекрасный момент эти проблемы пересилили мою лень и я решил бороться с ними, поставив следующие задачи:

• Минимум html кода, генерируемого для меню (зачем нам засорять ДОМ)
• Лаконичность js кода для создания меню (API вызова без копипасты)
• Оптимум гибкости при работе (многоуровневые, динамически модифицируемые меню)
• Как можно меньше кода в реализации библиотеки (6302 байта в несжатом виде)
• Минимальное количество jQuery-вызовов (чтобы можно было легко от них отказаться тем, кто jQuery не использует)
• Inline-события где это возможно вместо биндов (меньше ресурсов сожрет)

UPD: разместил проект в google code, пользуйтесь, развивайте:
svn checkout js-cmenu.googlecode.com/svn/trunk js-cmenu-read-only

Мобильные устройства такие как сматрфоны или планшеты обычно имеют емкостный экран, чувствительный к прикосновениям для расширенного взаимодействия с пользователем.

С каждым днем мобильные приложения становятся все сложнее и сложнее. Веб-разработчикам тоже нужен API для использования всех возможностей тачскрина. Например, какой-нибудь аркаде или файтингу нужна необходимость нажатья нескольких кнопок, эту возможность может предоставить экран с поддержкой мультитач.

Apple ввел свое touch events API в iOS 2.0, вскоре устройства на Android тоже получили такую возможность и touch events API стал стандартом де-факто. Недавно была собрана рабочая группа W3C для работы над touch events specification.
В этой статье я рассмотрю touch events API, которое нам предоставляют устройства на iOS и Android, мы изучим какие приложения можно создавать, используя touch events API. В статье куча полезных примеров и техник, которые позволяют упростить написание приложений с touch events API.

Прочитав на хабре про открытие API Яндекс Метрики захотелось использовать это на своем блоге.

Буквально в тот момент, когда я отправил плагин на модерацию в wordpress.org, на хабре появился пост про похожий модуль для Drupal.

Главными отличиями являются:

• Использование amCharts.
• Получение токена простым вводом имени и пароля.
• Получение данных в формате XML.
• Виджет самых посещаемых страниц

Под катом описание плагина.

Стили

User Agent

Один из способов включения стилей для мобильного устройства — это использование User Agent, которую получает сервер от клиента.
Этому может помочь набор скриптов: code.google.com/p/mobileesp, а также сервис от яндекса api.yandex.ru/detector
При работе с User Agent только одна проблема — это постоянно появляющиеся новые User Agent.

Вчера была опубликована хорошая статья «Веб-дизайн. Каждому устройству свое представление». Несмотря на неплохие размышления, к сожалению, вывод в ней довольно глупый. А именно:

«Нужно определить, какими устройствами могут пользоваться ваши посетители, проработать и создать для этих устройств представление вашего сайта, определить устройство посредством проверки заголовков браузеров, и отправить наиболее подходящее представление.»

Почему это глупо

Во-первых, никто не сможет предугадать, какими устройствами будут пользоваться ваши посетители. Нужно ориентироваться не на устройства, а на разрешения.



Это скриншот из презентации «Beyond the mobile web by yiibu» (очень рекомендую).

Во-вторых, если вы не facebook или yandex, скорее всего, вы не потянете создание и поддержку разных версий сайта для каждого устройства. Да и это не имеет особого смысла. Потому что ситуация становится похожа на реалии пятнадцатилетней давности. Тогда делали сайт «под браузер», а сейчас автор предлагает делать сайт «под устройство».

Как сделать один сайт для всех устройств

Если вы планируете изменения в своей квартире, но CAD системы (ArchiCAD, AutoCAD) не то, с чем вы сталкиваетесь постоянно, то это сервис то что нужно.

Roomle позволяет создавать план квартиры или отдельных комнат, расставлять мебель, смотреть отрендеренную картинку и, конечно, делиться результатами.

Наша компания занимается подбором IT-персонала во многих крупных городах России и Европы. Два раза в год мы проводим исследования зарплат сотрудников IT компаний, чтобы быть в курсе малейших изменений рынка.



В этом посте была затронута малая часть проводимого исследования. В комментариях народ потребовал хлеба и зрелища более конкретных данных по многим позициям, и я пообещал, что мы будем стараться регулярно публиковать данные о зарплатах по различным специальностям в сфере IT.

Сказано — сделано! Первый пост посвящен детальному разбору зарплат специалистов в сфере мобильных разработок. Руководствоваться будем данными, полученными в ходе исследования в Москве, Санкт-Петербурге и Нижнем Новгороде.

Сегодня речь пойдёт об WaterSpout — веб сервере, способном обрабатывать websockets запросы, позволяя общаться в реальном времени между сервером и браузером используя websockets или long polling. Написан он на PHP.

В первую очередь идёт проверка поддерживаются ли websockets (это Chrome, Опера и FF, если включим), если нет, то ничего страшного, будет использоваться long polling.
Преимущества этой технологии: доставка сообщений мгновенна, высокая производительность. Тестировал в Chrome, FF, IE6+.
Демка.

На эту тему было уже много статей, но раскрыта далеко не вся правда. Для тех, кто пропустил — читайте Создание приложений реального времени с помощью Server-Sent Events .

Как же работает Server-Sent-Events?

Оригинал опубликовал Лео Бабаута на сайте Zen Habits. Я его вольно перевел и немножечко адаптировал. Сразу оговорюсь, я не претендую на точность перевода. Моей задачей было перевести не точно, а понятно. Приятного чтения и применения!

«Это про привычки и делание, а не про систему и инструменты»

Чтобы закрепить основы продуктивности и организованности, сохраняя всё настолько простым, насколько возможно, я разработал свою собственную систему продуктивности: Zen To Done (ZTD).

ZTD складывается из простоты, фокуса на действиях и делании здесь и сейчас, в противовес вечному планированию и системности.

Мониторинг memcached — дело далеко не последней важности. Как на этапе тестирования, так и на этапе сопровождения уже работающего нагруженного ресурса. Средств «из коробки» для этого не так уж и много, а если вы работает с PHP, то зачастую ограничиваетесь средствами memcache (или memcached), а именно

Memcache::getStats()

$memcache = new Memcache;
$memcache->connect('localhost',11211);
print_r($memcache->getStats());


что возвращает типичный набор данных

Array ( [pid] => 25722 [uptime] => 4487286 [time] => 1308323074 [version] => 1.2.2 [pointer_size] => 64 [rusage_user] => 2646.005365 [rusage_system] => 17108.873237 [curr_items] => 37761 [total_items] => 10764857 [bytes] => 140070186 [curr_connections] => 5 [total_connections] => 17360659 [connection_structures] => 31 [cmd_get] => 89154830 [cmd_set] => 10764857 [get_hits] => 83452021 [get_misses] => 5702809 [evictions] => 0 [bytes_read] => 3527860756618 [bytes_written] => 4234517241183 [limit_maxbytes] => 2147483648 [threads] => 1 )

Вроде всё хорошо.
Мы видим, что у нас занято 133,5 Mb из 2 Gb выделенных под memcached и около 37 тыс. ключей.
Hits к misses относиться как 83/5, что тоже не внушает опасений.

Компания Google решила сделать открытый протокол Jingle (XEP-166 и XEP-167) дефолтным сигнальным протоколом в GTalk. При этом в ближайшее время сохранится поддержка и старых протоколов для обратной совместимости. Однако, сторонним клиентам всё-таки рекомендуют тоже перейти на библиотеку libjingle, потому что поддержка SIP не сохранится вечно.

Сейчас звонки GTalk из GMail, iGoogle и Orkut уже осуществляются по протоколу Jingle, скоро выйдет соответствующий апдейт для Android-приложения. Планов обновлять десктопное приложение под Windows нет даже в будущем. Похоже, Windows-клиент вообще не будут развивать.

Jingle — расширение XMPP, позволяющее передавать между двумя клиентами аудио- и видеоданные. Разработан компанией Google совместно с XMPP Standards Foundation.