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

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

Здравствуйте уважаемое Хабрахабр сообщество!
10 октября 2009 я опубликовал одну, не большую статью о своих ошибках. Сейчас 9 января 2011 года, я готов рассказать продолжение той истории и поделиться мыслями.
Как вы поняли, прошло достаточно много времени, на окончательное осознание своих ошибок, их осмысление и работы над ними.
Хотелось бы сразу сказать, что в ходе рассказа я буду несколько раз ссылаться на предыдущий.

Всем привет! В данной статье я хочу рассказать о том, как можно сделать из своего Adndroid смартфона игровой контроллер (в простонародье — джойстик) для обычного ПК, а именно руль.

Описание задачи

Поведение руля будет эмулироваться с помощью акселерометра. Для этого ведется непрерывное сканирование пространственных координат и эмпирическим путем подбираются границы для каждого направления движения. Исходя из этих данных в реальном времени генерируются сочетания игровых клавиш. Например: W — вперед, WA — вперед и влево и т. д.

Для доставки этих данных на ПК должен быть запущен сервер, который принимает входящие команды и эмулирует нажатия соответствующих клавиш. Сервер можно сделать однопоточным, чтобы подключался только один смартфон. Соединение будет осуществляться по Wi-Fi.

Добрый день! Меня зовут Антон Щастный.

Это моя очередная статья, посвящённая разработке веб приложений на Java. Хочу предложить вам сделать небольшую систему учёта клиентов, написанную с использованием фреймворка Spring и библиотеки Hibernate.

Что будет в приложении:

Будет простой менеджер контактов, позволяющий добавлять в базу новые записи, просматривать имеющиеся, удалять ненужные. Сведения будут храниться в базе данных. Доступ к приложению – через веб, с аутентификацией и авторизацией пользователей.

Что будем использовать:

• веб фреймворк Spring MVC,
• фреймворк Spring Security,
• ORM библиотеку Hibernate,
• MySQL в качестве СУБД.

Инфраструктура:

• редактор SpringSource Tool Suite,
• сборщик проектов Maven,
• система логгирования Log4j,
• постоянное подключение к интернету.

В моей предыдущей статье о Spring MVC был упущен ряд моментов по использованию аннотаций в Java-коде и применению Maven для сборки проекта. В данной статье я попытался исправить упущение.

Цель статьи – показать начинающим веб разработчикам совместное использование различных технологий платформы Java.

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

Перед тем, как мы обсудим, как учитывается память, сначала посмотрим, как эта память виртуальной машине выделяется, и что такое вообще «память виртуальной машины».

Реальная память виртуальных машин

Гипервизор Xen, являющийся основой XCP, являющийся основой облака Селектел, контролирует несколько аспектов работы виртуальных машин. Из интересующих нас с точки зрения учёта — процессор и память. Процессор мы обсудили, теперь очередь оперативной памяти.

С точки зрения Xen'а выделение памяти домену (виртуальной машине) означает, что домен имеет право писать в указанную страницу памяти. Попытка домена записать в запрещённую для него страницу памяти вызовет исключительную ситуацию и с большой вероятностью прекращение работы домена, так что ядро гостевой системы тщательно следит за тем, чтобы не выйти за пределы разрешённой памяти (ровно так же, если программа попытается обратиться к несуществующей странице памяти, то ядро программу аварийно завершит или вызовет обработчик ошибок). В любом случае, виртуальной машине разрешено использовать только ту память, которую ей разрешили использовать. Таким образом, Xen всегда точно знает, сколько страниц памяти выделено той или иной виртуальной машине. (Да, минимальная градация учёта памяти — это 4кб кусочек памяти, называющийся «страница»). Я опущу раздел, связанный с трансляциями адресов, поскольку это одна из самых… м… затруднительных областей. Если вкратце — пририсуйте к обычной схеме трансляции виртуальной памяти на i386 ещё две таблицы дескрипторов — получится примерно оно.

Когда домен создаётся (то есть виртуальная машина стартует), программа под названием domain_builder говорит Xen'у, сколько страниц нужно выделить домену. Эту же информацию сообщают ядру гостевой системы, чтобы оно знало, сколько ей памяти выделено.

Внутри виртуальной машины запущен modd (memory on demand dæmon), который посредством xenstore (специфичный для зена метод взаимодействия между доменами) сообщает управляющему сервису о том, в каком состоянии находится память домена. В реальности это просто запись содержимого /proc/meminfo, не более. Сервер смотрит на настройки виртуальной машины и решает, сколько памяти нужно добавить или убрать. И отдаёт команду на изменение памяти.

И вот тут начинается самое интересное. В Xen'е существует понятие передача страниц памяти. Это, в буквальном смысле, означает «взять страницу памяти от одного домена и передать другому». Соответственно, когда отдаётся команда на отдачу/приём памяти, Xen забирает у гостевой системы память, или отдаёт ей эту память. В силу общей (полезной) параноидальности Xen'а, все отдаваемые из домена страницы предварительно обнуляются (чтобы случайно не отдать ценные данные посторонним соседям по виртуализации).

Для меня jQuery ассоциируется с мощной и главное кросс-браузерной JavaScript библиотекой. Можно долго перечислять ее достоинства, холиварить по поводу и без, но думаю, никто не будет против посмотреть подборку интересных плагинов и уроков:
для удобства – каждая картинка ведет на демо

Hover Slide Effect

Демо | Урок

Галерея состоит из нескольких картинок, при наведении на одну из них она эффектно меняется на другую, а при клике на любую картинку — меняются все одновременно.

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

Из многих алгоритмов поиска кратчайших маршрутов на графе, на Хабре я нашел только описание алгоритма Флойда-Уоршалла. Этот алгоритм находит кратчайшие пути между всеми вершинами графа и их длину. В этой статье я опишу принцип работы алгоритма Дейкстры, который находит оптимальные маршруты и их длину между одной конкретной вершиной (источником) и всеми остальными вершинами графа. Недостаток данного алгоритма в том, что он будет некорректно работать если граф имеет дуги отрицательного веса.

Для примера возьмем такой ориентированный граф G:

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

Так что все пришлось пробовать на своем опыте. До этого был только опыт создания различных сайтов — от простых, до довольно сложных (базы знаний по играм — см. раздел «ссылки»), т.е. по сути, опыт ограничивался HTML/PHP/MySQL. Но мы из тех людей, которые не боятся нового.

Я расскажу о создании, затратах, подводных камнях и профите.

Но обо всем по порядку…

Предисловие

Цель данного поста — с одной стороны поделиться своим успешным опытом старта разработки приложений на платформе Android и с другой стороны поспособствовать развитию рынка софта для этой замечательной и бурно растущей платформы за счёт (без ложной скромности скажу) возможно Вас, прочитавших данный пост. В сети, конечно, можно найти материалы на тему разработки приложения «чуть сложнее, чем helloworld», но как правило они разрозненные и в них не описываются различные мелкие подводные камешки. В данном посте мы рассмотрим полный цикл разработки приложения, начиная с чистого компьютера до готового apk-файла. Под катом скрины.

Здравствуйте!

Мы рады представить FindPresent — уникальный сервис, с помощью которого вы можете провести на своем сайте увлекательную игру или оригинальную промоакцию.

Основная идея сервиса — размещение случайным образом на вашем сайте подарков и сюрпризов. Чтобы найти их, посетителям придется потрудиться и, конечно, внимательно просмотреть не один десяток страниц :) В результате проведения таких конкурсов активность аудитории сайта существенно возрастает. А пользователей по-настоящему захватывает розыск подарков по сайту, это действительно интересно.

Это шестая, заключительная часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Предыдущие части:

• «Переобучение для пользователей Subversion»
• «Основы Mercurial»
• «Привыкаем работать в команде»
• «Исправляем ошибки»
• «Процесс слияния»

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

Часть 6. Архитектура репозиториев

Наш рецепт становится все лучше:

В этом посте расскажу о собственном опыте создания и продвижения стартапа YesterdayMe.ru. Пост построю как перечисление наиболее значимых наблюдений и рекомендаций в ходе развития проекта, но намеренно не буду делать обширных выводов, чтобы уместиться в читаемый объем. Коротко, по делу, исходя из опыта первых семи месяцев работы сервиса.

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

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

Это четвертая часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Предыдущие части:

• «Переобучение для пользователей Subversion»
• «Основы Mercurial»
• «Привыкаем работать в команде»

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

Часть 4. Исправляем ошибки

Mercurial позволяет свободно экспериментировать. Представьте, что во время работы вы что-то не то сделали в редакторе, и случилось нечто ужасное:

Это третья часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Предыдущие части:

• «Переобучение для пользователей Subversion»
• «Основы Mercurial»

Одно из преимуществ использования Mercurial — возможность работать командой над одним кодом. Mercurial позволяет каждому работать независимо и помогает объединять сделанные изменения.

Часть 3. Привыкаем работать в команде

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

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

Глава 4. Куда сеем? В контент!

Многие спросили, как я набрал первоначальную массу пользователей, после набора которой сообщество, собственно, как-то задышало. Было дело так: когда я на одном из бесплатных LiveStreet'овском (CMS моего проекта) дизайне только-только открыл проект, сразу же встал вопрос о привлечении на него аудитории. Но на что придёт аудитория, не на голое же место?

Вступление

Привет!

В последнее время, спустя вот уже полтора года, как я с нуля, практически в одиночку, создал и развил неплохое с точки зрения пользующихся им людей, а также с точки зрения материального профицита, интернет-сообщество — Автотуристу.Рф, меня стали часто спрашивать, как мне удалось этого добиться и какие шаги я предпринимал на пути к этому. Пусть это и покажется не скромным, но я действительно добился результата (это – состоявшийся факт), об этапах достижения которого теперь и хотел бы поведать интересующимся. И пусть я не запустил Хабр v2.0 и не получаю со своего стартапа баснословных доходов, но, всё же, средний (и даже немножечко выше) московский ай-ти’шный оклад я с него имею, а это и было моей целью. Соответственно, ниже повествование о том, как я поставил себе цель и её добился!

Итак, писанина ниже – это некое Know-How на тему создания с нуля человеком, далёким от web-разработческих дел, интернет-стартапа и его дельнейшего продвижения и развития. Сразу оговорюсь, что всё, что будет изложено ниже, основывается лишь на моём собственном опыте и не претендует на какую бы то ни было научность или официальность. Дело в том, что полтора года назад загоревшись (да что там «загоревшись» — став одержимым!) идеей создания тематического интернет-сообщества, я самостоятельно, от и до, её реализовал. Ещё прошу заметить, что все свои «трепыхания» при создании своего собственного стартапа предпринимались мной, так сказать, «по наитию», то бишь я не читал мудрых книжек и не ходил на семинары или мастер классы. Хотя, с другой стороны, если бы не два замечательных человека, моих друга, то, скорее всего, не было бы и никакого стартапа, но об этом по ходу пьессы.
Важно! Я буду писать много и обстоятельно, вдаваясь в разные, на первый взгляд, казалось бы, ненужные детали, но, поверьте, именно детали порой играют решающую роль, имхо, конечно же.

Все мы прекрасно понимаем, что тестирование является неотъемлемой частью жизненного цикла разработки ПО. Чем чаще мы тестируем наш код, тем быстрее мы сможем обнаружить ошибку, вкравшуюся в него в ходе разработки, и быстрее её исправить. При этом стоит понимать, что тестирование крайне желательно проводить в окружении, максимально близком к боевому (ОС, ПО, Hardware, Нагрузка), что бы иметь возможность обнаружить ошибки, которые не проявляются на сервере разработки, но могут появиться в бою. Компануя два вышесказанных тезиса вместе мы получаем концепцию, называемую Continuous Integration.

Суть CI заключается в постоянной (например, после каждого commit'а) сборке и тестировании разрабатываемого ПО в максимально приближенной к боевой среде с целью как можно более раннего обнаружения ошибок и оповещения о них разработчиков. Сама идея CI принадлежит Martin Fowler, подробно описавшему её в своей статье.

Для автоматизации процесса непрерывной сборки существуют готовые решения (Hudson, CruiseControl), интеграцию одного из которых (Hudson) я и опишу в этой статье.

В этой статье я опишу принципиальные различия Apache и Nginx, архитектуру фронтэнд-бэкэнд, установку Apache в качестве бэкэнда и Nginx в качестве фронтэнда. А также опишу технологию, позволяющую ускорить работу веб-сервера: gzip_static+yuicompressor.

Node.js — вещь, вокруг которой сейчас много шума, восторженных отзывов и гневливых выкриков. При этом, по моим наблюдениям, в умах людей закрепилось следующее представление о том что же такое Node.js: «это штука, позволяющая писать на JavaScript на серверной стороне и использующая JavaScript-движок от Google Chrome». Поклонники языка восторженно вздохнули: «Ах! Сбылось!», противники же процедили сквозь зубы: «Ну вот только еще этой ерунды с прототипами и динамической типизацией нам на серверах не хватало!». И дружно побежали ломать копья в блоги и форумы.

При этом многие представители обоих лагерей придерживаются мнения, что Node.js — это эзотерическая игрушка, веселая задумка для переноса языка браузерных сценариев на «новые колеса». Дабы быть до конца честным, признаюсь, что я так же придерживался подобной точки зрения. В один прекрасный момент, я набрался духу и решил «копнуть поглубже». Выяснилось, что создатель Node.js Райан Дал далеко не фанатик, а человек, пытающийся решить реальную проблему. А его творение — не игрушка, а применимое на практике решение.