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



Буквально вчера мы в Surfingbird обновили дизайн приложения и сегодня, по свежим следам, хотелось бы поделиться впечатлениями от перехода на material design.

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

StringBuilder sb = new StringBuilder();
for (Iterator<String> i = debtors.iterator(); i.hasNext();) {
  if (sb.length() != 0) {
    sb.append(", ");
  }
  sb.append(i.next());
}
out.println("Debtors: " + sb.toString());

Понятно, что этот код мог бы быть более прямолинейным, например, в Java 8 можно написать так:

out.println("Debtors: " + String.join(", ", debtors));

Вот так сразу гораздо понятнее, что происходит. Google Guava – это набор open-source библиотек для Java, помогающий избавиться от подобных часто встречающихся шаблонов кода. Поскольку Guava появилась задолго до Java 8, в Guava тоже есть способ конкатенации строк: Joiner.on(", ").join(debtors).

Уже было несколько попыток строительства любительского дельта 3D-принтера. И вот наконец создан достойный работающий прототип, чертежи и софт которого, к тому же, доступны для повторения.

Наткнулся на довольно занятное приложение, Wikiweb — показывает смысловые связи между статьями Вики.

Сделано это примерно так же, как и в аддоне к Firefox, который отслеживал рекламные баннеры.

Доступно пока только для i-девайсов. Стоит программка 5 баксов.

Как заявляют разработчики, часть средств от продажи приложения они жертвуют Wikimedia Foundation.

Сайт проекта
Страница на iTunes

Навеяно вот этим.

Цены на нефть и бензин вместе с ней бьют рекорды, а в определенных кругах продолжается истерия вокруг так называемого «пика нефти», который якобы, подобно залетевшему дятлу, должен разрушить всю нашу цивилизацию. Вот, например, один русскоязычный калифорниец пытается вопросить на ответы утомляющих его американцев: «Когда подешевеет нефть?» — и вопросит их так, что они больше не отвечают. Другой русскоязычный во времена, когда аудитория была шокирована крахом доткомов и событиями 9/11, попытался окончательно ее добить опусом в стиле хоррор «Проблема-2033» (я бы скорее назвал это «диагнозом») — и создал питательную среду для всяческих анастасийщиков и прочего мракобесия.

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

Как я выиграл суд с EMS.
Итак, как было обещано в вопросе habrahabr.ru/qa/19545, я публикую свой опыт по подаче иска к «EMS – Почта России», который завершился положительно для меня. Впрочем, обо всем по порядку.
Big Update — сегодня, 6.03.2013 получил деньги. Кафкианский процесс завершен. Ура!

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



На этой почве возникает интерес, а иногда и необходимость (если заказчик просит) реализовать увиденное. Я не стал исключением и при проектировании нового приложения, дизайн которого был набросан на черновике, присутствовал очень схожий дизайн, хотя и имел всего несколько вкладок. Казалось бы, что сложного? Сейчас откроем официальную документацию, просмотрим необходимые разделы и приступим к делу. Но, изучив документацию, не смог обнаружить соответствующих примеров — и тут же возник новый вопрос. Почему Android разработчики из компании Google по умолчанию не предоставляют примеров с необходимой функциональностью, чтобы сделать это довольно просто, ведь это реализовано в каждом их приложении? Также, погуглив, нашлись аналогичные вопросы на Stack Overflow. Исходя из этого, оказалось, что существует проблема или, по крайней мере, нераскрытый вопрос, в котором следует разобраться.

Ниже хочу рассказать о том, как всё же можно реализовать паттерн Navigation Drawer вместе с вкладками, как в популярных приложениях от Google.

Предыстория

Чтобы начать работу хотя бы в 12:00, я должна встать в 5:00. Нет, я не стою в пробках и не хожу утром в спортзал. Дорога до работы составляет два шага. Причем в буквальном смысле – два шага от кровати до компьютера. Просто я живу в Бразилии, а работаю в России, в собственном интернет-магазине элитного белья и аксессуаров для дома. С Москвой 7 часов разницы, и я вынуждена вставать на рассвете. И чтобы просыпаться бодрой, энергичной и через 3-4 часа не валиться в постель, я опробовала множество способов пробуждения. И сейчас поделюсь ими с вами.

Red and Blue Chair by Gerrit Rietveld (1918)

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

Одним из негативных последствий такой ситуации является bus factor, который стремится к единице. Для решения этой и других проблем было решено в порядке эксперимента внедрить систему ревизии кода (англ. code review): назначить одного разработчика ревизором у другого и таким образом познакомить его с кодом, а заодно и повысить качество последнего.

grep

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

Мне, как любителю посидеть в консоли Windows очень мешало отсутствие грепа, по этому мои скрипты под Win всегда были не так хороши, как могли бы быть. Но мои скрипты должны работать на любой (ну, или почти на любой) Windows, так как же быть?

Всем привет! В этом топике мне хотелось бы обсудить одну из самых интересных и в тоже время загадочных тем для большинства, как мне кажется, инди-разработчиков – это продвижение своих собственных приложений. Скажу пару слов о себе: я примерно 2 года занимаюсь Android-разработкой (исключительно в качестве хобби, правда). У меня есть десяток приложений в Play Store, с совокупным количеством загрузок более 5 млн. Ни то что бы очень много, да и большая часть загрузок приходится на одно приложение, но какие-то выводы касательно маркетинга я для себя сделал. Здесь я хочу поделиться своим опытом, наблюдениями, а так же призываю Вас рассказывать о своих результатах в комментариях. Обмен опытом в этом вопросе был бы полезен всем, я думаю.

Топик основан на информации сайта SlashGear, указанный ниже как [Источник]. Обозреватели SlashGear связались с Nokia и получили опровержение, и, таким образом, нынешнее состояние дел, указанное в заголовке, не соответствует действительности. Топик останется опубликованным из-за большого числа людей оставивших комментарии и оценивших его положительно. Прошу прощения за возникшую ситуацию.

Несколько дней назад стало известно, что ряд бывших сотрудников Nokia основали новый стартап Jolla по разработке, поддержке и выводу на рынок мобильной платформы MeeGo. На момент анонса стартапа упоминалось о том, что Jolla никак не аффилирована с Nokia и официально поддержкой ни N9, ни N950 заниматься не будет.

Как оказалось, финская компания не захотела остаться в стороне от разработки своего бывшего продукта. Сотрудники Jolla получили от своего бывшего работодателя — главой стартапа является проработавший в Nokia 11 лет Марк Диллон (Marc Dillon), непосредственно занимавшийся MeeGo с января 2006 года — не только этап финансирования, но и ряд патентов на различные технологии в MeeGo из портфолио финского вендора.

Сооснователь Jolla Юсси Хурмола (Jussi Hurmola) высказался прямо и честно: "Я бы хотел сказать Nokia спасибо".

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

От переводчика: The Codeless Code — сборник побасенок о философии программирования. Побасенки в сборнике разные — некоторые весьма кровожадные, некоторые достаточно хардкорные с технической точки зрения (родной язык автора — Java), но встречаются очень емкие. Представляю вам перевод семи наиболее полюбившихся мне историй, остальные 30+ (новые добавляются каждую неделю) можно найти на сайте.

Пустяк

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

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

Мастер ответил: «Здесь есть изъян, и я размышляю, как лучше его исправить.»

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

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

Часто подобные тесты могут занимать много времени, даже если использовать in-memory базу данных (я, кстати проверял почему — у нас много JPA entities с множеством свойств в каждом и инициализация Hibernate, имено она, занимает десятки секунд!)

Значит нам надо сделать так, чтобы по умолчанию эти тесты, в отличие от обычных юнит тестов, не исполнялись во время билда.

Так что план такой:
1. Пишем сервисы, разбитые на два слоя приложения
2. Соединим их Спрингом
3. Напишем тест пользуясь JUnit для взаимодействия этих сервисов (настоящих, без всяких mock)
4. Делаем так, чтобы этот тест не бежал по умолчанию во время билда
5. Profit!

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

Этой статьёй я открываю цикл, посвящённый разработке Android-приложений. Но не типичных для Google Play, написанных, очевидно, задней левой mНогой, а приложений корректных и элегантных. В этом деле нам поможет DroidParts — швейцарский нож Android-библиотек с 8 лезвиями:

1. Dependency Injection: инициализация системных и собственных зависимостей;
2. Object-Relational Mapping для SQLite: CRUD-операции «из коробки»;
3. Поддержка Fragments, ActionBarSherlock;
4. Простая (де-)сериализация JSON;
5. AsyncTasks, IntentService с обработкой Exсeptions;
6. RESTful HTTP client с поддержкой JSON;
7. L.og без указания тега, конфигурируемый через AndroidManifest;
8. Утилиты типа асинхронного http-загрузчика с кешированием, View- и Intent-помощников.

Буквально час назад* увидела свет первая версия библиотеки, но сначала…

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

Множество постов призывает вас сделать это. Я расскажу как я собрал и облетал (буквально вчера) свой первый в жизни квадракоптер. С какими проблемами столкнулся и как их решил. Что важно я хотел бы написать данный рассказ именно с позиции новичка в радиоуправляемой авиации.

Статья является частью цикла:
1. Часть первая, описание и выбор деталей
2. Часть вторая, сбор рамы


коптер на картинке не мой

Добрый день, хабр. Сегодня я хотел бы поделиться некоторым опытом, касающимся подключения цветных LCD-индикаторов к микроконтроллеру. Эта тема уже поднималась на хабре (http://habrahabr.ru/post/139384/), поэтому данный пост может рассматриваться как дополнение к уже написанному моими уважаемыми коллегами.

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

Зачем нам консоль в МК?

Текстовый консольный интерфейс обладает рядом преимуществ для встраиваемых систем, при всей своей мощи и простоте (ведь текст, в отличие от светодиода, говорит сам за себя!):

• Требует относительно мало ресурсов МК, и минимум аппаратных затрат — последовательный интерфейс типа UART или любой другой имеющийся в МК, это может быть встроенный USB или внешний USB-Com адаптер или даже TCP если ваше микроконтроллер достаточно серьезный.
• Удобно подключаться — достаточно терминала поддерживающего Com-port (putty для Windows или minicom для linux).
• Удобно использовать — цветной вывод в терминал, поддержка авто-дополнений, горячих клавиш и истории ввода.

Здравствуйте. Данная статья описывает одну из возможных реализаций паттерна Handler для FreeRTOS, предназначенного для обмена сообщениями между потоками. Статья предназначена в первую очередь для людей, использующих операционные системы в проектах для микроконтроллеров, энтузиастов DIY и людей изучающий ОСРВ и микроконтроллеры.
Предполагается, что читатель знаком с основными терминами, относящимися к ОСРВ, такими как очередь и поток. Более подробно ознакомиться с FreeRTOS можно в постах qdx FreeRTOS: введение и FreeRTOS: межпроцессное взаимодействие.
Те, кто участвовал а проектах для микроконтроллеров, используя FreeRTOS, возможно, сталкивался с тем, что стандартный API достаточно скуден, что приводит к необходимости написания дополнительного кода, который во многом повторяется. В моем случае ощущался недостаток инструментов для взаимодействия между потоками, а именно отсутствие унифицированной системы обмена сообщениями. Обычно для обмена инфомацией между потоками и синхронизации используются те или иные формы очередей. При этом тип информации, содержащейся в очереди, каждый раз разный, что снижает возможность повторного использования кода.
Использование унифицированной формы сообщения часто позволяет объединить несколько потоков в один Worker Thread, который обрабатывает полученные сообщения в порядке очереди.