Во время разработки игры мы столкнулись с необходимостью обеспечения максимального риалтайм обмена данных между пользователями, что повлекло за собой эксперименты с различными comet библиотеками.
Первый велосипед был построен на dklab realplexor, который, при очередной попытке его использования, как и ожидалось, нас подвел. Может у нас руки кривые, но добиться получения ивентов без задержек в 5-10-15 секунд у нас, к сожалению, не получилось.
Танцы с бубном продолжались долго, в результате чего мы решили остановиться на nginx_http_push_module, и потраченное время все же стоило того.

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



Тогда понадобился год, чтобы прочитать в десять раз больше бумаги и сделать выборку, которая оказалась неожиданно полезной многим. Вот результаты ещё одного года — ещё N+2 книги для бизнеса, которые реально помогают.

Этот пост воодушевлен и является логическим продолжением недавно размещенного здесь материала «Хабр vs TechCrunch». Сам я с его авторами никак не связан, но выражаю им большую благодарность за то, что поделились своим опытом.

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

После рассылки у меня на руках остался небольшой список изданий, которым я не могу не поделиться с Хабросообществом. Добро пожаловать под кат!

Доброго времени суток!

Наряду со статьей "iPhone: MiTM атака из кармана", родилась почти аналогичная статья про Android.

Мы уже знаем, на что способен iPhone. Уступает ли ему Android?

Было рассмотрено около 25 боевых приложений. Хочу предоставить вам результат маленького исследования. Многие приложения даже не запустились, некоторые подвесили телефон намертво, но некоторые даже работали!

Весь софт тестировался на телефоне LG Optimus, с версией Android 2.3.

Итак, краткий обзор боевого софта на Android:

Доброго всем хабрадня!

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

Как будем загружать?

Для загрузки изображений мы будем использовать QNetworkAccessManager и QEventLoop, а так же немного мета-объектов. Загружать будем по HTTP изображение в любом формате, из поддерживаемых Qt. Ну, ещё будем обрабатывать редиректы.

Как обрабатывать-то будем?

Есть замечательный класс QGraphicsEffect с подклассами. Но мы с ними работать в рамках данной статьи не будем, смиритесь! И я даже объясню почему. К примеру, в Qt 4.8.0 эти эффекты ведут к крашу приложения в Mac OS X 10.7.+, а в Qt 4.7.4 в той же системе они вообще не работают. Уж не знаю, как так вышло, но багу в багтрекере Qt я поставил.

Значит, будем создавать свой класс для обработки изображений. Он будет у нас уметь слудющее:

• Переводить изображение в оттенки серого
• Колоризировать (как это по русски-то сказать?)
• Добавлять тень
• Менять прозрачность
• Вращать вокруг центра
• Квадратизировать
• Квадратизировать со скруглением углов
• Как бонус, научимся считывать пользовательские цвета в формате #RRGGBBAA

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

Наверное, многие слышали про проект Adobe Air — весьма здравая инициатива от компании Adobe сделать так, чтобы приложение на флэше могло компилиться и запускаться на любых платформах — десктоп, iOS, Android, телевизоры,…

Долгое время ничего толкового на air'е сделать было нельзя. Но в последнее время технология набирает обороты, Adobe внесла ряд оптимизаций в код air'a и теперь вполне можно написать на нем весьма шустрое приложение. В данной статье я расскажу о нашем опыте разработки air-приложения под iOS.

Как мы дошли до жизни такой?...

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

Т.к. ни с unity, ни тем более с xcode никто из нас не знаком, зато со флэшом мы на «ты» — то пришла в голову мысль опробовать хваленую технологию Air для создания более-менее презентабельной и динамичной игры.

На данный момент use case'ов эира под iOS — пересчитать по пальцам. Да, Машинариум — неплох. Но, все-таки, — это не показатель. Нам было интересно, как air справится именно с динамичной игрушкой.

Итак, решение было принято. Примерный сроки (1 месяц) — поставлены. И мы сели копаться в новой для нас технологии…

Привожу перевод статьи Ника Карсона. В статье собраны вместе, как мне кажется, основные правила построения интерфейса для iOS приложений.

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

2. Ориентируйтесь на устройство при создании приложений: учтите не только размер экрана, но и где и когда устройство используется. Больше всего iPad используется для развлечений между 8-11 часами вечера, перед сном, тогда как iPhone — в очереди на автобус или в кофейне. Учтите различные сценарии использования при разработке приложений – включая и то, как далеко устройство расположено от лица пользователя.

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

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

5. При адаптации приложения к экранам различных размеров, помните, что при значительном его изменении – например, от iPhone к iPad – способ использования устройства также изменится. Если размеры ограничены, используйте основные функции приложения, при их увеличении – можно включить любые дополнительные функции, которые не вошли в более сжатую версию, так как у вас появляется возможность обыграть дополнительное пространство.

За остальными 45-ю — добро пожаловать подкат.

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

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

Сейчас о создании своего стартапа не думает разве что два типа IT-людей. Это те, кто нормально устроился в крутую IT-компанию в офис с видом на вулкан Гунунг Агунг и участвует в создании действительно крутых проектов, либо ну самые ленивые, для которых корпоративный обед и ДМС являются синонимами слова счастье.

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

Итак, давайте рассмотрим основные стадии развития проекта и соответствующие мероприятия (в Москве) по привлечению инвестиций.

Недавно дошли руки до превращения записи моего доклада на AgileKitchen в полноценный слайдкаст.

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

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

В данной статье мне бы хотелось поговорить не только о подготовке и проведении презентации, но и об организации мероприятий в целом. У многих из нас хоть раз в жизни возникает необходимость организовать мероприятие того или иного масштаба, будь то встреча, мастер-класс, семинар или презентация. В мою жизнь так называемый ивент-менеджмент прочно вошел с началом трудовой деятельности в ИТ-компании: организовывая мероприятия по 3-5 раз в год (от встреч проектировщиков интерфейсов до семинаров по электронным библиотекам), я составила чек-лист необходимых для этого дел. Хочу поделиться им с хабражителями и помочь нуждающимся не наступить на грабли, часто встречающиеся на этом непростом, но увлекательном поле деятельности.

В сжатом виде он выглядит так:

• Решить, кто наши докладчики и потенциальные участники, а также что, где и когда первые расскажут вторым
• Исчерпывающе и понятно написать о событии на своем сайте
• Анонсировать событие в СМИ и социальных сетях, пригласить клиентов и партнеров
• Заблаговременно открыть регистрацию участников
• Заранее получить презентации докладчиков и тезисы выступлений
• Обеспечить стабильно работающий интернет, звук, свет, ПО и другое оборудование
• Заснять доклады и дискуссии на видео
• Организовать досуг участников после мероприятия
• После события написать письмо с благодарностью участникам и докладчикам
• Ознакомить с материалами события тех, кто не смог принять в нем участие
• Составить детализированный отчет о событии
• Собрать фидбек и учесть все ошибки при организации следующего мероприятия

За подробностями, советами и примерами — под кат.

Заранее спасибо за дополнения! Самые актуальные добавлю в статью с указанием авторства — глядишь, так и составим универсальное пособие для организаторов событий.

Upd: дополнила статью советами из комментариев! Спасибо за помощь AndreiYemelianov, RGaifutdinov, mivanova, ollystar, Cancel, verbinka, mujaji.

Когда я в начале 2009 года приехал на выставку фототехники PMA 2009 в Лас-Вегас, то сам задался вопросом — почему мы, производитель электроники, еще не здесь? По разным причинам, у нас заняло 3 года, чтобы сюда попасть, но в конце концов я пишу этот пост из отеля почти на Стрипе, это центральная улица Вегаса (почти — потому, что на понты Стрипа денег жалко). А в зале PMA (который в этом году привязан к выставке CES) почти готов к показу наш стенд. Ниже пойдет речь о том, что надо сделать, чтобы сюда попасть, а также небольшая разбивка по ценам в долларах США.

Не так давно промелькнула ссылка на достаточно свежее (осень 2011) англоязычное голосование со скромным названием "самая впечатляющая книга, которую должен прочесть каждый разработчик программного обеспечения" и описанием:

Если бы вы могли вернуться в прошлое, к самому началу своей карьеры разработчика и сказать самому себе: «прочитай именно эту книгу», в самой начале своей карьеры разработчика, какую бы книгу вы рекомендовали?

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

Однако в данном небольшом посте я возьму на себя смелость перечислить ТОП-5 тех самых книг, победивших в голосовании, переведенных на русский язык. И дать небольшие комментарии, ведь книги действительно этого достойны. Да, лично я бы поменял некоторые места, однако положимся на «мнение зала» ресурса Stack Overflow.

Я 8 лет занимаюсь тестированием. Ручным и автоматизированным, в роли тестировщика и тест-менеджера, как сотрудник компании и как представитель аутсорса. И почти на всех проектах сталкиваюсь с одной и той же проблемой: руководители проектов не понимают, зачем им нужно тестирование.

Если задать среднестатистическому РМ'у простой вопрос: «Зачем на этом проекте тестирование?», то чаще всего ответом будет «Ты же тест-менеджер, ты и должна ответить на этот вопрос».

Но ведь приходя в парикмахерскую вы не говорите мастеру «вы сами знаете, что мне нужно»? И в продуктовом магазине вы не просите продавца накидать вам в корзину то, что вам нужно? Вы можете советоваться, вы можете узнавать «а как можно?», спрашивать варианты, но решение всегда за вами. В чём отличие тестирования? Может, в том, что слишком мало менеджеров проектов понимают, зачем оно им?

В этой статье я постараюсь выступить в роли продавца, который показывает клиенту: «а что вообще бывает?» Многие вещи будут описаны, возможно, слишком подробно, слишком просто… Не серчайте, мне просто очень хочется быть понятой :)

Не так давно совместно с компанией InNetMedia в рамках Хабра был опубликован перевод инфографики на тему "7 способов увеличения лояльной аудитории".

Сегодня вашему вниманию предлагаем инфографику "Психология социального шоппинга". Данная инфографика разошлась за бугром тиражом почти в 400 копий и мы не смогли пройти мимо такого материала ;)

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

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

Несколько раз натыкался за последнее время на публикацию данной инфографики, и всякий раз ссылка шла за бугор. Почти всегда (в таких случаях) народ незнающий английского и «не могущий» использовать словарь в коментах задают вопросы: а что? а как? Ответов на них хватило бы, что бы все перевести. Только не понятно почему не переводят )))

Итак, источник инфографики: www.blog.kissmetrics.com/fan-base/

Далее самое интересное:

Построение вашего онлайн сообщества «фанатов» невероятно важно. Ваше сообщество «фанатов» в социальных сетях может помочь поднять популярность вашего бренда и привести к увеличению трафика, вирусному распространению информации, и как следствие, увеличению прибыли. Но наращивание количества поклонников сообщества может быть заданием довольно трудным. Многие бренды и люди понятия не имеют, с чего начать. К счастью, сервис KISS Metrics, только что опубликовал фантастическую статью о важности поклонников и о методах увеличения их количества.

Инфографик сервиса KISS Metrics затронул не только лучших субъектов с точки зрения подписчиков Twitter и пользователей Facebook (в топ-рейтинг которых вошли: Lady Gaga, Facebook, Rihanna, Eminem и YouTube), и ведущих мировых брендов на Facebook (в топ-рейтинг которых вошли: Coca-Cola, Starbucks и Oreo), но и показал, как поклонники в социальных сетях могут быть использованы для развития бренда, в том числе тот факт, что 64% пользователей Twitter чаще всего отдают предпочтение брендам, подписчиками которых они являются.

Если кто помнит, в первой части своей статьи о гарантиях я упоминал о «подразумеваемых гарантиях» (Implied Warranties), которые автоматически являются частью контрактов на разработку ПО, т.к. они закреплены законодательно. В британском законодательстве эти гарантии закреплены в The Sale of Goods Act 1979 и The Supply of Goods and Services Act 1982. Напомню, что к «Implied Warranties» относятся: 1) Warranty of Title, 2) Infringement Warranty, 3) Warranty of Merchantability, 4) Warranty of fitness for а specific Purpose.Мы говорили о том, что если прямо не исключить действие этих гарантий, то они будут распространяться на правоотношения в рамках этого контракта. Теперь я предлагаю рассмотреть варианты исключения действия этих подразумеваемых гарантий.

В первую очередь стоит отметить, что если мы говорим о праве Великобритании, то все исключения «warranties» должны соответствовать требованиям, которые предъявляет UTCA (Unfair Contract Terms Act 1977). В соответствии с UTCA, некоторые «implied warranties» вообще не могут быть исключены (например, «Warranty of Title»), а некоторые, могут быть исключены только целесообразно — «only if reasonable» (например, «Warranty of fitness for а specific Purpose»). Если суд придет к выводу о том, что условие об исключении гарантии идет в разрез с требованиями этого нормативного акта, то это условие будет считаться недействительным. Во избежание рисков, связанных с нарушением UTCA, и в целях обеспечения исключения максимального числа гарантийных обязательств, разработчик может воспользоваться следующей конструкцией: «Other warranties are excluded to the maximum extent permitted by law».

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

Внутри — сам чеклист и примеры из нашей практики.

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

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

Сперва возникает желание дать все гарантии Заказчику, и тем самым сохранить хорошего клиента и дружеские отношения с менеджером. Наша команда работает качественно и в срок, и проблемы с Заказчиками возникают в основном по косметическим моментам. Но значит ли это, что мы готовы на неограниченные гарантии?

Уверен, что не готовы ни мы, ни любая иная отечественная компания-разработчик. И если основная задача юриста – это распознать и нивелировать правовые риски, то мне бы стоило задуматься над тем, какие гарантии мы можем предложить Заказчику, а какие оставить за бортом.
Проведя небольшое исследование, хочу поделиться своими выводами по этому поводу: