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

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

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

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

• Android Annotations
• Groundy
• Retrofit
• AnnotatedSQL
• Android db-commons

Если заинтересованны прошу под кат.

Многие разработчики, используют в своих проектах библиотеку Retrofit, которая позволяет превратить HTTP API в java-интерфейс. Это очень удобно, так как позволяет избавиться от лишнего кода и использовать ее очень легко. Нужно лишь создать интерфейс и навесить несколько аннотаций.

Недавно я занимался разработкой приложения для Android, которому необходимо было делать запросы к базе данных через JDBC- драйвер. Тогда мне пришла идея создать нечто подобное Retrofit только для запросов к базе данных. Так появился RetroBase, о котором я Вам сейчас и расскажу.

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

Общие сведения
Паттерн Singleton гарантирует, что у класса есть только один экземпляр, и предоставляет к нему глобальную точку доступа.

В мире Android разработки существует множество интересных библиотек, и сегодня мы рассмотрим детище компании Square — Retrofit. Что же это за зверь такой? Retrofit (согласно официальному сайту) — типобезопасный HTTP-клиент для Android и Java. Он является незаменимым инструментом для работы с API в клиент-серверных приложениях. Каких-то лет 5 назад Android-разработчикам для работы с сетью приходилось воротить горы кода с обратными вызовами, AsyncTask'ами и прочими «низкоуровневыми» вещами. И компания Square выпустила такую замечательную библиотеку — Retrofit.

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

Продолжаем публикацию наших свежих образовательных курсов. За 14 лекций Технотрека вы получите необходимые навыки и опыт в области разработки на Java, узнаете синтаксис и основные библиотеки языка, начнете понимать объектно-ориентированный подход, сможете декомпозировать сложные задачи.

Курс ведут Рустам Кильдиев, Java/Scala-разработчик мобильного ПО, и Дмитрий Архангельский, инженер-разработчик в Одноклассниках.

Лекция 1. «Знакомство с платформой Java»

Вводное занятие, на котором кратко дается описание всего курса. Основная задача курса — не просто научить синтаксису, а дать практические навыки и понимание основ. Курс выстроен так, чтобы, выполняя небольшие задачи, написать проект «Бэкенд к мессенджеру».

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

Основное различие, разумеется, в том, что Integer — это полнофункциональный объект, который занимает место в куче, а в коде вы пользуетесь ссылками на него, которые неявно преобразуются в значения:

int a = 1000; // a - число
Integer b = 1000; // b - ссылка на объект

При присваивании значения переменной типа Integer обычно выделяется память в куче под новый объект, как будто вы написали new Integer(1000) (так называемый autoboxing). Однако иногда переиспользуются старые объекты. Это иллюстрирует следующий код (JDK 1.6):

Integer a1 = 50;
Integer a2 = 50;
Integer b1 = 500;
Integer b2 = 500;
System.out.println(a1==a2);
System.out.println(b1==b2);

Результатом выполнения будет:

true
false

На недавнем DroidCon Moscow 2016 был доклад о MVVM c Databinding Library и доклад о библиотеке Moxy, помогающей работать с MVP. Дело в том, что за последние полгода мы успели опробовать оба подхода на живых проектах. И я хочу рассказать о своём пути от освоения Databinding Library и выпуска в продакшн проекта на MVVM до осознания, почему я больше не хочу использовать этот паттерн.

От переводчика:
Уже опубликовано много материалов по MVC и его производным паттернам, но каждый понимает их по-своему. На этой почве возникают разногласия и холивары. Даже опытные разработчики спорят о том, в чем отличие между MVP, MVVM и Presentation Model и что должен делать тот или иной компонент в каждом паттерне. Ситуация усугубляется еще и тем, что многие не знают истинную роль контроллера в классическом варианте MVC. Предлагаю вашему вниманию перевод хорошей обзорной статьи, которая многое проясняет и расставляет всё по своим местам.

Не буду сильно углубляться в теорию. Что такое частичное применение легко найти в интернете. В том числе на Википедии.

Если кратко, то это механизм, позволяющий зафиксировать k аргументов функции от n аргументов, сделав из неё функцию от (n - k) аргументов.

// Пусть имеется функция f от четырёх аргументов:
int f (int a, int b, int c, int d)
{
    return a + b + c + d;
}

// Фиксируем первые два аргумента:
auto g = part(f, 1, 2); // 1 + 2 + ...

// Добрасываем оставшиеся два:
assert(g(3, 4) == 10); // ... + 3 + 4 = 10

На эту тему уже существует масса публикаций, в том числе и на Хабре:

1. C++ Variadic templates. Каррирование и частичное применение
2. Частичное применение и каррирование в C++
3. Каррируем на C++

А ветка "How should I make function curry?" на stackoverflow — просто кладезь для тех, кто впервые сталкивается с этой темой.

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

Замечательный факт №1. В упомянутых статьях присутствуют все техники, которые нужны для реализации правильного (по моему мнению) частичного применения.

Надо только всё внимательно проанализировать и сложить кубики в правильном порядке. Именно этим я и собираюсь заняться в данной статье.

Есть внутренняя система, которая крутится на Weblogic, есть готовый шаблон почты, есть программист и есть баг. Вот вы знали, что почтовые клиенты с большОй вероятностью не смогут показать картинку, которая вставлена в разметку письма, источник которой начинается на data:image/gif;base64?

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

Это будет рассказик про процесс нахождения одного решения. Теперь обо всем по порядку.

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

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

Всем привет!

Мы, Денис Бесков (beskov) и Илья Поляк (ilyap1) начинаем публикацию цикла статей, посвящённых процессу проектирования веб-сервисов. Цикл построен вокруг 3-хуровневого процесса, в котором явным образом выделяются уровни анализа и проектирования:

1. Бизнеса
2. Продукта
3. Технологий

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

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

1. Какими способами можно описывать требования к ПО?
2. Какие из требований к системе обязательно необходимо включать в ТЗ, а без каких можно обойтись?
3. Какие могут быть варианты при выборе форматов описания требований?
4. Как зависит выбор вида описания требований от параметров (продолжительности, рисков и др.) проекта?
5. Какого рода решения помогают принять соответствующие виды требований?

В цикле не рассматриваются аспекты заказной разработки ПО. Статья рассчитана на пользователей, которые работают в некорпортивной среде, т.е. не привязаны к каким-либо регламентам.

The distinguishing characteristic of industrial-strength software is that it is intensely difficult… the complexity of such systems exceeds the human intellectual capacity… we may master this complexity, but we can never make it go away.

Grady Booch

Давайте вернемся на несколько десятилетий назад и взглянем на то, как выглядели типовые программы тех лет. Тогда доминировал Императивный подход. Напомню, что название он получил благодаря тотальному контролю программы над процессом вычислений: в программе четко указывается, что и когда должно быть выполнено. Словно набор приказов Императора. Большинство операционных систем предлагали для написания исполняемых программ именно этот подход. Он широко используется и по сей день, например при написании различного рода утилит. Более того, с данного подхода начинается изучение программирования в школе. В чем же причина его популярности? Дело в том, что Императивный стиль очень прост и понятен человеку. Освоить его не сложно.

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

Тогда я написал пост «Заблуждения программистов относительно „времени“», в котором указал 34 ошибочных представления и заблуждения, относящихся как к календарному, так и к системному времени. С большинством из них я столкнулся сам, занимаясь дебаггингом программ (как рабочих, так и тестовых).

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

Открытие

Как всегда, слова благодарности тем, кто нам помогал — друзьям и компаниям. Друзьям за то, что продолжают приходить и поддерживать нас. А компаниям за то, что доверяют умы своих разработчиков, не боясь получить на следующий день неожиданно большую коммит историю. И, конечно же, напутственные слова на предстоящий день. Главным посылом которых было то, что конференция, безусловно, это труд, большое вложение, но нужно не забывать об удовольствии новых встреч, новых идей и новых целей!

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

1. Consistent, Thin and Dumb

Hector Zarate, Spotify

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

При работе с естественным языком и лингвистическом анализе текстов нам часто приходится оперировать огромным количеством уникальных коротких строк. Счёт идёт на десятки и сотни миллионов — именно столько в языке существует, к примеру, осмысленных сочетаний из двух слов. Основной платформой для нас является Java и мы не понаслышке знаем о её прожорливости при работе с таким большим количеством мелких объектов.

Чтобы оценить масштаб бедствия, мы решили провести простой эксперимент — создать 100 миллионов пустых строк в Яве и посмотреть, сколько придётся заплатить за них оперативной памяти.

Всем привет!

Эта статья про реализацию одного конкретного DSL (domain specific language, предметно-ориентированный язык) для регулярных выражений средствами Kotlin, но при этом она вполне может дать общее представление, о том, как написать свой DSL на Kotlin и что обычно будет делать "под капотом" любой другой DSL, использующий те же возможности языка.

Многие уже используют Kotlin или хотя бы пробовали это делать, да и остальные вполне могли слышать о том, что Kotlin располагает к написанию изящных DSL, чему есть блестящие примеры — Anko и kotlinx.html.

Конечно же, для регулярных выражений подобное уже делали (и ещё: на Java, на Scala, на C# — реализаций много, похоже, это распространённое развлечение). Но если хочется попрактиковаться или попробовать DSL-ориентированные языковые возможности Kotlin, то добро пожаловать под кат.