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

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

Давайте начнем. Сначала о процессах.

Добрый день, уважаемые хабровчане. В прошлой статье мы с вами разработали простую USB-видеокарту на базе STM32F103 и китайского дисплейного модуля на контроллере ILI9325.
Проверяли мы его из юзерспейса, при помощи LibUSB. Ну что ж, пришло время нам написать свой собственный драйвер, который позволит делать все то же самое, но из-под Linux и без дополнительных библиотек. Этот драйвер мы внесем в дерево исходников OpenWRT и он поселится там наравне со всеми остальными.
Начнем.

Всем привет!

В топике Java собеседование. Коллекции подробно изложен вопрос работы с Set & Map в Java. Но у меня ещё есть парочка любимых вопросов из этой области:

1. Может ли null использоваться в качестве ключа в Map?
2. Может ли Set содержать null?

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

Сегодня в очередной раз задумался над темой плохого приема GPS сигнала на моем китайском смартфоне Jiayu G2. Но, неожиданно для меня, проблема решилась буквально за пару минут — «китаец» находит спутники в течение 20 секунд. А теперь обо всем по-порядку.

В рамках работы над большим количеством android приложений появилось желание создать свой Android Market на локальном сервере (с шахматами и поэтессами).
Свой маркет должен решать две простые задачи:

• Распространение и обновление корпоративных приложений. У нас есть набор внутри корпоративных приложений, которые нельзя публиковать на Google Play. Сейчас пользователи оповещаются о новых версиях по емайлу, что не удобно.
• Бета тестирование заказных приложений на большой группе коллег, с обратной связью.

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

Узнав, что я занимаюсь разработкой мобильных приложений, мои знакомые время от времени, спрашивают: «сколько стоит разработать приложение?». И я честно отвечаю: «от 200 долларов». Приложение будет писать на экране HELLO WORLD, его не пропустят в магазин из-за «bad user experience», но работать-то приложение будет!

Самое удивительное, что огромное количество разработчиков и вправду создает что-то за 3000 долларов и даже выкладывает это в App Store.

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

Так и хочется, заглянуть им в глаза и проникновенно спросить:

— Ребят, а вы из какой сказки?

А то в моей суровой реальности разработка качественного, пусть и не большого приложения для Appstore – это долго, непросто и дорого.

Основные статьи расходов при создании проекта:

Статья	Расход
Дизайн приложения	$ 13 000
Создание уникальности	$ 10 000
Производство графики	$ 35 000
Программирование	$ 45 000
Текстовый контент	$ 5 000
Локализация	$ 3 000
Музыка и звук	$ 1 000
Полировка	$ 17 000
Маркетинг	$ 30 000
Управление	$ 30 000
Итого:	$ 189 000

Вся раскладка будет сделана на примере нашего приложения "МоиЭмоции". Приложение бесплатное, весь функционал можно посмотреть.

Проблема создания качественного пользовательского интерфейса (UX-интерфейса) действительно существует. Конкретно — она проявляется, когда компания-разработчик использует гибкие методологи. Собственно причина того есть совокупность двух моментов:

• Итеративность работы программистов. В Agile разработчики предпочитают создавать проект «по частям», отдельными итерациями. И таким же образом «передавать» получающийся продукт заказчику.
• «Целостность» работы дизайнеров. UX-дизайнеры предпочитают продумывать и разрабатывать концепцию целиком. Соответственно, по готовности цельной концепции — они передают ее в разработку. Такой подход заставляет дизайнеров выбиваться из общего ритма, что порождает проблемы с распределением рабочего времени.

Намечается два пути: оставить дизайнеров в покое или попытаться вовлечь их в Agile (притом стараясь никого не покалечить). В первом случае придется жертвовать темпом, во втором — качеством конечного продукта. Или есть третий путь?

Сначала пример с большой красной машиной

Недавно открыл для себя StrictMode, прочитав статью на Android Developers Blog. Ниже представляю Вам ее перевод.

За сценой

Одна из клевых вещей в Google — это «20% времени»: 20% от своего рабочего времени вы имеете право заниматься проектами, не имеющими никакого отношения к вашему основному проекту. Когда я пришел в Google, я постоянно переключался с проекта на проект и часто шутил по этому поводу, что у меня 7 таких 20%-ных проектов. Один из проектов, к которому я постоянно возвращался, был Android. Мне нравилась открытость платформы, которая давала мне возможность делать все, что я хотел, в том числе открывать двери моего гаража, когда я подъезжал к своему дому на мотоцикле. Я действительно хотел, чтобы этот проект был успешным, но я беспокоился об одном: Android никогда не был быстрым. Подтормаживающие анимации и элементы пользовательского интерфейса, которые не всегда сразу реагируют на ввод данных. Было очевидно, что причина этого — задачи, выполняющиеся не в том потоке.

Я являюсь активным пользователем SMS и одним из моих 20%-ных проектов в ходе подготовки релиза Cupcake (Android 1.5) стала оптимизация приложения обмена сообщениями. Я оптимизировал его и сделал более плавным, а затем продолжил метаться между другими своими 20%-ными проектами. После выхода релиза Donut (Android 1.6), я заметил, что некоторые из моих оптимизаций случайно оказались сломанными. Мне было немного обидно, но затем я понял, что Android действительно всегда не хватало, так это готового к использованию, встроенного, всепроникающего средства мониторинга производительности.

Я присоединился к команде разработчиков Android на полный рабочий день чуть более года назад и провел много времени за исследованиями проблем производительности во Froyo. В частности посвятил много времени борьбе с ANR-диалогами (вы видите эти раздражающие диалоги, когда приложение выполняет длительные операции внутри основного UI потока). Отладка этих диалогов, с помощью имеющихся инструментов, была трудной и утомительной. Их было не достаточно чтобы найти причину, особенно, при взаимодействии нескольких процессов (например, обращения из Binder'ов или ContentResolver'ов к Service'ам или ContentProvider'ам в других процессах). Необходим был более совершенный инструмент для отслеживания притормаживаний интерфейса или ANR-диалогов.

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

Итак, представим себе, что есть два программиста. Один из них умный, прочёл кучу статей на Хабре, знает каталог GoF наизусть, а Фаулера — в лицо. Другой же делает всё просто. Первого будут звать, например, Борис Н., а второго — Маркус П. Само собой, имена вымышленные, и все совпадения с реальными людьми и программистами случайны.

Итак, к ним обоим приходит проектный менеджер (если в вашей вселенной PM не ходит сам к программистам, назовите его как-то иначе, например BA или lead, сути это не изменит) и говорит:
— Ребята, нам нужно, чтобы делался хлеб.

Именно так, «делался», без уточнения способа производства.

Как же поступят наши программисты?

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

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

Ни для кого не секрет, что TextView в Android поддерживает HTML-теги. Среди них поддерживается и тег , а для его обработки используется класс ImageGetter. И если с отображением локальных графических файлов никаких проблем не возникает, то при попытке программно подгрузить удаленный рисунок в TextView мы получаем NetworkOnMainThreadException на Android версии 3.0 и выше. Как выяснилось, в поисковиках информации для решения этой проблемы находится мало, да и далеко не все из предлагаемых решений работоспособны. Тем не менее, рабочее решение существует.

О чем эта статья

В двух предыдущих статьях я рассказывал как отлаживать приложения для Android без исходного кода на Java и о некоторых особенностях установки breakpoints. Если уважаемый читатель ещё не ознакомился с этими статьями — я настоятельно рекомендую начать с них, а уже потом читать эту статью.

Так уж вышло что до сих пор я рассказывал исключительно об отладке байткода Dalvik и ни словом не обмолвился об отладке native методов. А ведь именно в native методах часто скрывается самое вкусное — хитрые защиты, интересные malware фичи, уязвимости нулевого дня. Поэтому сегодня я сжато, без «воды», расскажу как отлаживать native методы без исходного кода на C/C++ (ну или на чем, уважаемый читатель, они у вас там написаны).

Комманда git up (аналог svn up) добавляется так:

git config --global alias.up '!(git add . && git stash && git pull --rebase >&2) | grep -v "No local changes to save" && git stash pop'

git up при надобности ныкает все ещё незакоммиченные изменения в stash, обновляет локальную ветку до свежайшей и восстанавливает локальные изменения назад. В том числе переносит ещё неотправленные локальные коммиты в самый конец, делая историю линейной как в Subversion, т.е. избегая лишних веток и merge-коммитов.

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

Основные рекомендации и ввод данных

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

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

Проблема

Стандартный механизм отображения списков из базы данных в Android выглядит примерно так:

• Activity содержит ListView
• ListView обращается к экземпляру CursorAdapter
• CursorAdapter получает данные из объекта, реализующего интерфейс Cursor
• Cursor получен либо из ContentProvider, либо сразу из SQLiteDatabase

Всё работает нормально ровно да тех пор, пока количество строк в Cursor сравнительно небольшое. Но если в нём 50 тысяч, 100 тысяч и более строк (хотя дело не только в количестве строк, но об этом чуть позже), время от времени список будет притормаживать. Особенно это заметно при «быстрой прокрутке», если у ListView установлено в true свойство fastScrollEnabled.

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

1) Росправосудие – крупнейший в России каталог юристов, адвокатов, судей и база судейских решений. Более 16 миллионов записей, аггрегированных с сайтов с открытыми данными. Сооснователь проекта Глеб Суворов рассказывает о том, чего можно достичь за первые 100 дней существования проекта в Сети. [Читать интервью, смотреть видео]

2) «Непофигизм» – сообщество, оказывающее бесплатные юридические услуги в Сети. Приоритет проекта – адресная помощь конкретному человеку с конкретной юридической проблемой. Руководитель «Непофигизма» Владимир Беляев рассказал о том, почему его проект никогда не будет коммерческим. [Читать интервью]

3) Генеральный директор NextGIS Максим Дубинин рассказал о том, чем геоинформационные системы могут быть полезны бизнесу, некоммерческим организациям и рядовым пользователям; как реализовывались проекты «Избирательная карта Москвы» и «Леснадзор», а также о том, что мешает развитию виртуальной картографии в России. [Читать интервью]

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

Добрый день, хаброжители!
Сейчас все мобильные приложения(за очень редким исключением) используют сеть: для авторизации, получения/отправки данных и т.д.
Свой опыт на эту тему я решил собрать в статье.
Работа с сетью в стандартном приложении сводится к решению нескольких задач:

• авторизация
• запрос и отправка данных
• хранение данных
• работа с картинками

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

Данный пост посвящен прекрасному инструменту Google Forms, как за 10 минут сделать форму обратной связи на сайте или более полезные вещи.

Сегодня в условиях дефицита технических специалистов компании готовы применять любые способы для их привлечения и удержания. Какие же перспективы роста может предложить работодатель будущему работнику?

В некоторых компаниях для каждого ИТ-специалиста разрабатывается индивидуальный план развития в течение определенного периода времени. Составляется он HR’ами или руководителем совместно с сотрудником. В нём отражены все необходимые факторы, чтобы повысить эффективность работника IT-службы для дальнейшего перехода на новую, более высокую позицию. В основном такие действия и методы находят отражение в достаточно крупных IT-компаниях, которые заинтересованы во внутреннем росте специалистов, обеспечивая таким образом внутренний кадровый резерв. Более мелкие компании ориентируются на опыт IT-специалиста и амбиции, учитывая его собственное стремление развиваться и расти.

Рассмотрим возможный карьерный путь на примере роли программиста

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