В этой статье мы поговорим про анонс коммерческой доступности мобильных сервисов Windows Azure для разработчиков Windows, iOS, Windows Phone, Android и мобильных HTML5-приложений.



Windows Azure Mobile Services — это часть облачной платформы Windows Azure, облачный сервис, который предназначен для обеспечения мобильных приложений на платформах Windows, iOS, Windows Phone, Android, а так же мобильных приложений на HTML5/JS готовым серверным бэкендом, используя всего пару строк кода.

Мобильные разработчики применяющие Windows Azure Mobile Services получают единую, готовую за 2 минуты, инфраструктуру для всех своих приложений:

• реляционное хранилище, хранилище табличных данных и файлов;
• готовая возможность аутентификации пользователей через популярные социальные сети;
• готовая инфраструктура и настроенный функционал для отправки пуш-уведомлений на все платформы с помощью одного API;
• функционал серверного кода на базе JavaScript и Node.js для тонкой настройки поведения мобильного сервиса, выполнения кода по расписанию через встроенный планировщик, обработки событий при сохранении данных в таблицах, хранения и выполнения собственного JS-кода (и вскоре .NET-кода) с интеграцией с системой управления версиями Git.

Мобильные сервисы Windows Azure Mobile Services предлагают разработчикам быстрый старт с бесплатного тарифа и гибкое масштабирование вверх и вниз в облаке по требованию.

По данным, любезно предоставленным аналитическим порталом CMS Magazine, «на радарах» видно 286 живых русскоязычных веб-студий размером 1—3 человека, 626 — размером 4—7 человек, и 556 — размером 8—15 человек. «Живые» — это те, кто опубликовал на портале хотя бы одну работу в 2012—2013 годах.

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

Последние годы рынок всё чаще говорит о необходимости позиционирования, маркетинга и PR для веб-студий, причём если раньше это относилось к Top-10 компаний, сегодня об этих чуждых интернет-специалистам материях приходится задумываться той самой тысяче с численностью сотрудников 4—15. К счастью, и на Хабре появляются хорошие статьи на эту тему. Мы хотим дать взгляд на проблему позиционирования ещё с одной стороны.

Как вы могли догадаться по картинке справа, речь пойдёт об автоматизированном тестировании. Точнее о такой технологии, как матчеры. Они помогают серьёзно сократить дублирование кода и упростить код тестов для восприятия, а создавать и использовать матчеры достаточно просто.

Сама по себе технология матчеров не новая — в текущем виде она была залита в репозиторий в июле 2012 года, а появилась и того раньше. Но, несмотря на это, многие о ней до сих пор не слышали или по каким-то причинам избегают. Мы хотим рассказать, как легко получать преимущества от её использования, и поделиться с вами нашей библиотекой матчеров.

Это вторая часть доклада, который я прочитал на Dribbble Meetup 2013 в Москве. В первой части я подробно описал свой процесс интеграции дизайна под платформу Android. Эта часть — про интеграцию дизайна под iOS и Windows Phone, а также я вскользь упомяну про Samsung Bada 2.0. Дальше — много картинок.

Добрый вечер!

Всё началось с того, что необходим был более или менее удобный инструмент для работы с API социальной сети ВКонтакте под iOS. Однако Google меня достаточно быстро расстроил результатами поиска:

• StonewHawk — GitHub
• maiorov/VKAPI — GitHub

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

Под катом я расскажу, как работает новая версия ВКонтакте iOS SDK, с чего всё начиналось и к чему в итоге пришли.

Привет!

Я хочу показать, как, не используя приватных API ( = не используя приватных фреймворков/классов/функций) можно собирать разнообразные данные о использовании устройства.

Вот описание информации, которую можно получить:

• Мощность сигнала сотовой сети: RSSI в дБм и относительную мощность в «палках»
• Качество сигнала WiFi (0 — плохо, 4 — хорошо)
• Состояние регистрации в сотовой сети: наличие SIM, поиск сети
• Тип сети передачи данных: 2G, 3G, WiFi
• Заряд аккумулятора с точностью до процента (стандартные средства дают точность в 5%)
• Включен ли «режим самолёта» («airplane mode»)
• Включены ли различные сервисы: будильник, Airplay, VPN, перенаправление звонков, Nike+

Привет, Хабр. В этой статье я расскажу о HTML Notification API.

Какие возможности предоставляет Notification API

API позволяем отправлять уведомления через браузер. Вы можете задавать иконку для каждого уведомления, группировать уведомления, указывать заголовок и текст уведомления.

Поддержка в браузерах

• Safari 6
• Chrome 27
• Firefox 22

Opera 15 beta не работает с Notifications API, несмотря на наличие конструктора Notification.
На мобильных платформах технология не работает.
В движке webkit есть старая нотация в виде webkitNotifications.

Как это работает

Цикл работы следующий:

1. Получить разрешение на отправку;
2. Правило фиксируется для сайта;
3. Отправить уведомление.

Хабр, привет!

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

Что вам кажется привлекательней: сталкиваться с новыми интересными задачами и разрабатывать нетривиальные алгоритмы или переписывать с одного языка на другой уже существующую логику и воевать со странными особенностями конкретных API? Я занимаюсь мобильной разработкой уже лет 8, и, не раздумывая, выбираю первый вариант, но и повоевать с API тоже люблю. Тем, кто со мной согласен, но еще не знает, как заниматься первым и сводить к минимуму второе, будет интересно заглянуть под кат.

Здравствуйте, дорогие читатели Хабра!

Уже довольно давно работаю фрилансером и иногда беру пару-тройку простеньких проектов за $100-200 для разгрузки мозга. В этот раз клиент попросил использовать внешние кнопки регулировки громкости в iPhone. Проблема состояла в том, что встроенного API для внешних кнопок в iOS не существует: до недавних пор использование хардверных элементов устройства, отличное от системного поведения, было запрещено. Поэтому различные приложения типа «Camera+» и «Camera Pro» никак не могли донести подобный функционал до пользователя. Однако, по счастливой случайности, в iOS 5 разработчики Apple сами начали использовать подобный подход к интерфейсу: сделать фотографию в системном приложении камеры теперь можно, нажав на клавишу увеличения громкости.

Как реализовать подобное поведение внешних клавиш в своем приложении, смотрите под катом. Исходники прилагаются в конце статьи.

В этом посте будут рассмотрены вопросы верстки при создании нативных приложений для android. Той верстки, которая описывается в xml файлах из директории res/layout/ Итак начнем:
Существует пять стандартных типов верстки:

• AbsoluteLayout
• FrameLayout
• LinearLayout
• RelativeLayout
• TableLayout

Доброго времени суток, уважаемые хабражители. Я работаю в большой IT компании Android-разработчиком.

Все началось примерно год назад. Тогда, я решил начать свой первый проект. Идея приложения пришла мне практически сразу. Ее первоначальная версия звучала примерно так — «Я хочу, чтобы каждый мог узнать независимое мнение людей всего мира, по интересующему вопросу».

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

В статье присутствуют цены на те или иные услуги сайтов с которыми мне удалось связаться.

Это статья является логическим продолжением недавней статьи: Серьезное проектирование серьезных сайтов. Мы опять делимся опытом о проектировании больших сайтов. На этот раз я хочу рассказать о принципах построения самого процесса проектирования, ведь от самого процесса тоже очень многое зависит.

Есть ряд принципов, которые нужно обязательно использовать при проектировании сайтов.

1. Оригинальные идеи. Именно идеи будут основой проектирования. Это самое важное, старт всего проекта. Очень важно не делать копии уже существующих проектов, почти всегда стоит задача сделать лучше, чем любой прямой или косвенный конкурент. Причем лучше на несколько порядков, иначе не получится переманить целевую аудиторию с тех сайтов, где она уже обитает. Идеи должен генерировать как проектировщик, так и инициатор проекта, тот самый носитель главной идеи.
   
   
2. Переносим оффлаин опыт. Один из важнейших принципов успешного проектирования – переносить опыт из оффлайна в онлайн. Нужно представить себя на месте представителя целевой аудитории, подумать, как он удовлетворяет свои потребности, связанные с тематикой проекта в оффлайне, и сделать то же самое, только лучше, в онлайне. Для иллюстрации принципа представим, что мы проектируем социальную сеть автолюбителей, где типичный представитель целевой аудитории имеет автомобиль, покупает автозапчасти в магазине возле дома, общается с приятелем Васей из соседнего гаража. Понимая поведение нашего потенциального пользователя в оффлайне, мы сразу можем предложить ему: привязать автомобиль к профилю по VIN-номеру с подробным справочником о нем; сделать некий аналог авторынка с разными продавцами, возможностью сравнивать цены, отзывами о работе; сообщество владельцев таких же автомобилей, с каждым из которых можно будет пообщаться и т.д. Это маленькие идеи, которые мне пришли в голову буквально на ходу, просто я представил себя на месте потенциального пользователя. Всего за пару минут можно сформировать несколько десятков неплохих, а самое главное полезных идей.
   
   

Доброго времени суток, уважаемые! Так случилось, что вопросом программирования более-менее адекватного ИИ для игры «морской бой» я озадачился где-то в конце 2004 года. Быть может я, не имея должных руководств под рукой, изобретал тогда велосипед, но и в последствии, мне попадались потрясающие своей честностью алгоритмы: стрелять наобум, время от времени подглядывая у игрока расположение кораблей, для выравнивания баланса. В последствии я несколько раз улучшал алгоритм. По последним статьям на Хабре можно судить, что тема актуальна, к тому же — мне есть что добавить к написанному другими пользователями.
Итак, цель моей заметки: реализация оптимальной одной из стратегий атаки на корабли соперника, причём не только первое попадание, но и последующее «сопровождение ко дну». Отмечу, что корабли в моей реализации — почти (об этом ниже) произвольной формы.

Или сказ о том, как разработка JSON валидатора превратилась в очередной JSON binding

Пока нормальные разработчики пишут приложения я изобретаю велосипеды.

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

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

Я постараюсь донести основные идеи, показать как эта VCS помогает разрабатывать проект. Надеюсь, что после прочтения вы сможете ответить на вопросы:

• можно ли git «подстроить» под тот процесс разработки, который мне нужен?
• будет ли менеджер и заказчик удовлетворён этим процессом?
• будет ли легко работать разработчикам?
• смогут ли новички быстро включиться в процесс?
• можно ли процесс относительно легко и быстро изменить?

Конечно, я попытаюсь рассказать обо всём по-порядку, начиная с основ. Поэтому, эта статья будет крайне полезна тем, кто только начинает или хочет разобраться с git. Более опытные читатели, возможно, найдут для себя что-то новое, укажут на ошибки или поделятся советом.

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

Кроме того — мы применяем аджайл. Мелкие итерации. И наши риски, и риски клиентов — ничтожно малы! А еще у нас есть типовые и четко очерченные в договорных отношениях этапы (не путать с agile-итерациями ;). Каждый раз, когда мы сталкиваемся с неопределенностью — мы разбиваем задачу на несколько мелких этапов и наши риски снижаются. Это же просто! Да? А теперь плохая новость:

Снижая риски добавлением этапов, мы снижаем рентабельность* всего проекта.

Свою рентабельность, в смысле. Когда я обнаружил это с помощью простой excel-таблицы, и посчитал, во что обходится добавление еще одного этапа — я присвистнул.

Итак, у нас есть абсолютно типовые этапы:

В нашей работе мы проходим все стадии жизненного цикла создания мобильного приложения, и я бы хотел поделиться нашим опытом в этой сфере. Под катом — рассказ об основах мобильной разработки: от выбора платформы до создания, размещения в магазине и последующего мониторинга.

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

Еще один мотив — разложить для себя все по полочкам. Все же история достаточно объемная и пока не систематизируешь все на бумаге, осознать все свои ошибки весьма сложно. Постоянно будешь думать о том, что ты все сделал правильно, и будет казаться, что во всем виноваты нерадивые пользователи, которым жалко доллара. А свои просчеты мозг отодвинет на дальнюю полку. Ну и какие-то менее очевидные вещи, возможно, подскажет хабрааудитория.

Не мне судить о том, можно ли считать эту историю success-story. Наверное все же нет. Этот проект — мой успех как программиста и менеджера проекта в одном лице и одновременно это мой провал как маркетолога и человека, который не против заработать немного денег.
Ну и, конечно, однозначный успех для моей жены Александры и ее брата — дизайн приложения, о котором идет речь, это их первый дизайн мобильного приложения, давший дорогу к дальнейшей интересной работе.

Также для любителей цифр скажу — все цифры в статье будут. Расскажу сколько скачиваний, сколько заработано, сколько инаппов куплено и сколько раз их пытались сломать.

Несмотря на то, что HTML5 всё ещё находится в процессе разработки, он уже появляется в веб-интерфейсах. Одним из основных нововведений этой версии HTML стал элемент Canvas, который используется для отрисовки двухмерной графики. Например, всё, что вы видите и с чем взаимодействуете в игре MMORPG от компании Mozilla или старом-добром Command and Conquer, отрисовывается и обрабатывается с помощью Canvas. Самые изощрённые умы даже реализуют полноценные формы на Canvas. Или интерактивную модель солнечной системы.

Фреймворки для работы с этим элементом растут как грибы после дождя; про то, как начать программировать, используя Canvas, написано огромное количество статей. Но есть один пункт, о котором, по-видимому, из-за узкой специфики говорят редко и мало. Речь идёт о тестировании приложений на Canvas. В каком-то смысле оно становится проблемой для инженера по тестированию, который привык обращаться к элементам на странице по их css или xpath селекторам, а затем выполнять с объектом какие-то действия. С Canvas такой подход не работает, ведь DOM элемент один, а объектов в нём — много.



Под катом на примере автоматизации тестирования API Яндекс.Карт я расскажу вам о том, как мы решили эту проблему в Яндексе.