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

Так же как киборги в свое время заполонили всю планету, сейчас мобильные девайсы заполоняют нашу жизнь. А что это означает для нас, гиков? Новые возможности даже обсуждать не стоит — это вкусные плоды с дерева под названием “гаджет”. А раз есть плоды и толпы страждущих, то почему бы не начать их выращивать (я про плоды, выращивать же страждущих умеет лишь Apple )? И тот вырастит больше и вкуснее, у кого инструмент лучше. Какие есть подходы в мобильном приложениеводстве? Как минимум можно использовать старую проверенную web-платформу и заняться написанием мобильных web-приложений, либо освоить молодую отрасль разработки под iOS и Android. Выбор, не простой, и чаши весов качались крайне долго в моей голове, пока на сторону разработки приложений под iOS (потенциально и под Android) не пал один весомый аргумент, о котором сегодня и пойдет речь. Но для начала краткий экскурс в технологии и их возможности.

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

• Скачать с Яндекса
• Скачать с Dropbox

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

Доброго времени суток, Хабровчане.

Может для большинства здешних обитателей моя статья покажется слишком скучной и «и так понятно», но думаю новичкам будет в чем-то полезной.
Стояла передо мной как-то задача сделать сортировку таблицы по разным колонкам. Данный брались из базы, каждый раз их вытаскивать — накладно, решил задействовать JavaScript.
Были небольшие трудности из-за использования различной стилистики строк в таблице, а именно был разный цвет фона, в зависимости от данных самой таблицы.
Стилистику нарушать было нельзя. Кого заинтересовало, прошу под кат.

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

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

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

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

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

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

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

Тем кому лень читать ценный текст. Маньяко теперь делает всякие работы для стартапов в кредит. Подробности лично и немного по ссылке.

Остальные велкам читать.

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

И все это в одной фразе, через запятую. (в одно слово, с маленькой буквы — слишком претенциозно было бы, да?)

Текст про инвесторов поди все помнят, кто не помнит — может сходить перечитать, для прозрачности мировоззрения ;-)

Смотрю я и вижу следующую картину:

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

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

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

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

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

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

Computer Scientist, Software Engineer и Coder заходят в бар.
— О, а вот и программисты! — окликает их бармен...

Я знаю людей, которые программируют уже не один десяток лет, но обижаются, когда их называют "программистами". А по запросу Coder vs Developer vs Software Engineer в гугле находится 113 000 000 ссылок: 1 2 3 4 5 6 7 8 9 … 113 000 000. Что интересно, можно найти совершенно противоположные мнения об одном и том же. С чем-то я согласен, а с чем-то в корне нет.

Последние же несколько лет так вообще постоянно подливают масло в огонь, появляются какие-то совсем странные программисты, которые называют себя Creative Technologist, Creative Coder и Interactive Developer.

Давайте же попробуем разобраться.

Вот смотрю как товарищ grokru выложил свое творчество и прямо вдохновляюсь. И поскольку мне было скучно, я решил тоже вспомнить былое и наштампить иконок. Заняло все это порядка 18-20 минут.



Попробовал себя в народном творчестве так сказать. Может совместно создадим habrapack?

Архив с .PSD и .PNG

Примечание переводчика: робот офигенно умный! Обязательно посмотрите видео под катом!

Первое небольшое введение смотрите тут — http://www.youtube.com/watch?v=OJiMUzJHYFk

Я начал с игрушки «Интерактивный ВаллИ». Текущая цена на toys'r'us составляет $34.99.

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

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

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

Чтобы изменять корпуса, я использую инструменты Dremel, а иногда и свой паяльник, чтобы расплавить пластмассу. При шлифовке, пожалуйста, имейте пылесос поблизости. Внимание: При плавке, держите открытым окно с вентилятором!

Вступление

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

На днях попробовал новый ZF2. Перечитал кучу материала, собрал по их туториалу простенький сайтик. И когда дошел до создания Action'а и View'хи то пределу моей радости не было границ. Передача переменных во view теперь осуществляется через return, и они стали локальными (никакого $this->param). Только ради этого усовершенствования я готов уже сейчас переходить на ZF2, несмотря на то что он в бете.

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

На всякий случай — это перевод (многие не замечают этого в интерефейсе ХабраХабра).
«Fat-Free» можно перевести с английского как «Обезжиренный» — фреймворк и в самом деле поражает своим размером (55 КБ) и скоростью работы.

Я наконец-то нашёл лёгкий и быстрый фреймворк. Он умещается в файл размером всего 55Кб и имеет множество возможностей, о которых вы можете узнать на его официальном сайте, поэтому не буду повторяться. Вместо этого я решил сделать небольшой учебник, из которого вы узнаете как сделать свой блог на этом фреймворке.
Вам понадобится PHP 5.3 на сервере. Я использовал Ubuntu 11.04 для написания этого учебника, на которую легко устанавливается эта версия. Если вы работаете на RHEL или Centos то я предлагаю заглянуть вам на IUS Community Project для получения последней версии PHP.

Знаете сколько в памяти занимает строка? Каких только я не слышал ответов на этот вопрос, начиная от «не знаю» до «2 байта * количество символов в строке». А сколько тогда занимает пустая строка? А знаете сколько занимает объект класса Integer? А сколько будет занимать Ваш собственный объект класса с тремя Integer полями? Забавно, но ни один мой знакомый Java программист не смог ответить на эти вопросы… Да, большинству из нас это вообще не нужно и никто в реальных java проектах не будет об этом думать. Но это, ведь, как не знать объем двигателя машины на которой Вы ездите. Вы можете быть прекрасным водителем и даже не подозревать о том, что значат цифры 2.4 или 1.6 на вашей машине. Но я уверен, что найдется мало людей, которые не знакомы со значением этих цифр. Так почему же java программисты так мало знают об этой части своего инструмента?

Integer vs int

Все мы знаем, что в java — everything is an object. Кроме, пожалуй, примитивов и ссылок на сами объекты. Давайте рассмотрим две типичных ситуации:

//первый случай
int a = 300;
//второй случай
Integer b = 301;

В этих простых строках разница просто огромна, как для JVM так и для ООП. В первом случае, все что у нас есть — это 4-х байтная переменная, которая содержит значение из стека. Во втором случае у нас есть ссылочная переменная и сам объект, на который эта переменная ссылается. Следовательно, если в первом случае мы определено знаем, что занимаемый размер равен:

sizeOf(int)

то во втором:

sizeOf(reference) + sizeOf(Integer)

Забегая вперед скажу — во втором случае количество потребляемой памяти приблизительно в 5 раз больше и зависит от JVM. А теперь давайте разберемся, почему разница настолько огромна.

Из чего же состоит объект?

Прежде чем определять объем потребляемой памяти, следует разобраться, что же JVM хранит для каждого объекта:

• Заголовок объекта;
• Память для примитивных типов;
• Память для ссылочных типов;
• Смещение/выравнивание — по сути, это несколько неиспользуемых байт, что размещаются после данных самого объекта. Это сделано для того, чтобы адрес в памяти всегда был кратным машинному слову, для ускорения чтения из памяти + уменьшения количества бит для указателя на объект + предположительно для уменьшения фрагментации памяти. Стоит также отметить, что в java размер любого объекта кратен 8 байтам!

Под впечатлениями от habrahabr.ru/blogs/java/134102.

Недавно мне приходилось немного поковыряться внутри JVM. Довольно интересный опыт. Текст в вышеупомянутом топике не совсем сходится с моим опытом, но я не считаю себя обладателем абсолютной истины. Ниже я поделюсь с читателями небольшой частью моих экспериментов, которые касаются непосредственно объектов Java.

Памятка начинающему экзорцисту.

Прежде, чем начать: я знаю, что такое phpDaemon и System_Daemon. Я читал статьи по этой тематике, и на хабре тоже.

Итак, предположим, что вы уже определились, что вам нужен именно демон. Что он должен уметь?

• Запускаться из консоли и отвязываться от неё
• Всю информацию писать в логи, ничего не выводить в консоль
• Уметь плодить дочерние процессы и контролировать их
• Выполнять поставленную задачу
• Корректно завершать работу

Отвязываемся от консоли

// Создаем дочерний процесс
// весь код после pcntl_fork() будет выполняться двумя процессами: родительским и дочерним
$child_pid = pcntl_fork();
if ($child_pid) {
    // Выходим из родительского, привязанного к консоли, процесса
    exit();
}
// Делаем основным процессом дочерний.
posix_setsid();

// Дальнейший код выполнится только дочерним процессом, который уже отвязан от консоли

В сети гуляет довольно много решений для эмуляции многопоточности в php. Чаще всего они основываются на форках, но есть и вариации на тему с использованием curl, proc_open и т.п.

Все встреченные варианты по тем или иным причинам меня не устроили и пришлось написать свое решение.
Набор требований у меня был следующий:

• Использование форков;
• Синхронный режим с сохранением интерфейса при отсутствии необходимых расширений;
• Многократное использование дочерних процессов;
• Полноценный обмен данными между процессами. Т.е. запуск с аргументами и получение результата по завершении;
• Возможность обмена событиями между дочерним процессом-«потоком» и основным процессом во время работы;
• Работа с пулом потоков с сохранением многократного использования, передачи аргументов и получения результатов;
• Обработка ошибок выполнения;
• Таймауты на выполнение работы, ожидание работы потоком, инициализацию;
• Максимум производительности;

В результате получилась библиотека AzaThread (старое название — CThread).

Введение

В данной статье рассматривается процесс написания программ при помощи SL4A на примере программы для синхронизации файлов по протоколу FTP на языке Python в операционной системе Ubuntu. Показаны настройка операционной системы для разработки SL4A-приложений, написание самого приложения, распространение приложения с помощью баркодов и упаковка приложения в .apk-файл.

Немного слов о том, что такое SL4A и с чем его едят

Проект SL4A (Scripting Layer for Android), появившийся на свет благодаря Деймону Кохлеру (Damon Kohler) и предоставляемыми Google'ом 20% свободного рабочего времени, дает возможность программировать под платформу Android на различных интерпретируемых языках программирования (на данный момент это Python, Perl, JRuby, Lua, BeanShell, JavaScript, Tcl и Shell).
На хабре уже писалось про SL4A. Например, здесь рассказывалось о том, как написать приложение на Python для проверки кармы на хабре, а здесь с помощью Lua создавался скрипт, отключающий коммуникации телефона на ночь.

SL4A хорошо подходит для обучения программированию, для написания прототипов программ, для решения задач автоматизации действий на платформе Android. Большие серьёзные программы на SL4A не пишутся, но для создания мини-программ он подходит хорошо. Проверить карму на хабре, отправить смс жене, чтобы попросить начать разогревать ужин за пару километров до дома; разбудить в электричке при приближении к нужной станции или даже управлять настоящей ракетой — все это может быть реализовано при помощи SL4A c минимальным количеством кода и затраченного времени.

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