* от переводчика: я долго думал над тем, как перевести на русский язык глагол «to grok». С одной стороны, это слово переводится как «понять» или «осознать», а с другой стороны, при переводе романа Роберта Хайнлайна «Чужак в чужой стране» (в котором это слово впервые и появилось на свет), переводчики сделали из него русское «грокать». Роман я не читал, поэтому счёл, что есть у этого слова какие-то смысловые оттенки, которые русскими аналогами не передавались, а посему в своём переводе использовал ту же самую кальку с английского.

RxJava — это, сейчас, одна из самых горячих тем для обсуждения у Android-программистов. Единственная проблема состоит в том, что понять самые её основы, если вы не сталкивались ни с чем подобным, может быть довольно затруднительно. Функциональное реактивное программирование довольно сложно понять, если вы пришли из императивного мира, но, как только вы разберётесь с ним, вы поймёте, насколько же это круто!
Я постараюсь дать вам некое общее представление об RxJava. Задача этого цикла статей состоит не в том, чтобы объяснить всё вплоть до последней запятой (вряд ли я смог бы это сделать), но, скорее в том, чтобы заинтересовать вас RxJava, и тем, как она работает.

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

Что такое MVP

MVP – это способ разделения ответственности в коде приложения. Model предоставляет данные для Presenter. View выполняет две функции: реагирует на команды от пользователя(или от элементов UI), передавая эти события в Presenter и изменяет gui по требованию Presenter. Presenter выступает как связующее звено между View и Model. Presenter получает события из View, обрабатывает их(используя или не используя Model), и командует View о том, как она должна себя изменить.

У такого подхода к разделению ответственности есть ряд плюсов:

1. Сильно упрощается написание тестов к коду
2. Легко менять какую-то часть, не ломая при этом другую
3. Код разбивается на мелкие кусочки, за счёт чего он становится более понятным и читабельным

В то же время, конечно, есть и минусы:

1. Кода становится больше
2. К этому подходу нужно привыкать
3. На данный момент не сильно распространённый(но известный) подход, поэтому приходится всем рассказывать о нём

Привет, Хабр! Меня зовут Владимир, мне 28 лет и я наркоман наркоман. Мой наркотик – простота. На простоту я подсел из-за своего перфекционизма, которым меня наградили при рождении.

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

Мир вокруг не идеален, сложную вещь сделать простой – невероятно сложно, поэтому всё чрезмерно усложнено. Людям нравится чувствовать себя профессионалами, поэтому они оперируют сложными терминами, когда в этом нет необходимости, так они ощущают свою значимость и заполняют пустоту, которая образовалась из-за страха потерянного времени.

Примечание переводчика: при переводе старался максимально пользоваться терминологией, которую предлагает сам Google в русскоязычной версии документации по Android, таким образом «service» стал «службой», «content provider» стал «поставщиком контента», и так далее. А вот «activity» стать «операцией» так и не смог — не пересилил я себя. Извините.

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

Привет. Из названия темы вы могли заметить, что речь пойдет о том, как устроены Tasks и Back Stack в Android. Эта статья будет являться свободным переводом официального источника. Тема больше ориентирована на новичков, но я думаю, что и опытный разработчик сможет узнать что-то новое, т.к. тема специфична и не часто приходится кастомизировать поведение наших Activity.

В этой статье мы поговорим о проектировании архитектуры и создании мобильного приложения на основе паттерна MVP с использованием RxJava и Retrofit. Тема получилась довольно большой, поэтому подаваться будет отдельными порциями: в первой мы проектируем и создаем приложение, во второй занимаемся DI с помощью Dagger 2 и пишем тесты unit тесты, в третьей дописываем интеграционные и функциональные тесты, а также размышляем о TDD в реалиях Android разработки.

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

Ранее мы рассматривали различные нюансы собеседования ИТ-специалистов и управленческие кейсы, связанные с работой технологических компаний. Сегодня мы поговорим о том, как правильно критиковать своих сотрудников.

Пользователь: это невозможно, GPS съест батарейку
Джуниор: это возможно, используй Geofences
Сеньор: есть варианты и получше

На картинке сначала в одну, а потом в другую сторону одновременно с одним человеком «прогулялись» 6 одинаковых телефонов. Но какой разный результат!

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

Год подходит к концу, впереди длинные каникулы. Для многих каникулы — это отличная возможность посидеть и посмотреть вокруг, что же у нас нового и интересного происходит нынче в профессиональном джавовском мире.

В апреле в Москве мы провели в Москве большую Java-конференцию — JPoint 2015. Конференция собрала более тысячи разработчиков на площадке, еще несколько сотен — смотрели конференцию онлайн. Мы экспериментировали и с открытием (лекция Дмитрия Галкина о современном искусстве и программировании действительно шокировала многих) и с новыми форматами (круглые столы и экспертные дискуссии). Но ключевой темой конференции были и остаются доклады.

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

---

10 место

Сергей Walrus Куксенко, Oracle — Железные счётчики на страже производительности
Средняя оценка: 4.28



Этот доклад получил специальный приз жюри в номинации «аццкий хардкор». Общая идея доклада сводится к следующему: представьте, что вы уже наоптимизировали в своем приложении все, что можно — посмотрели на сеть, ОС, JVM и т.д. и поняли, что все уперлось в процессор. После этого мы попрофилировали, работать стало быстрее, но все равно процессор загружен на 100%. Что делать?

Оказывается, внутри процессора есть разные счетчики событий. Называется этот механизм Hardware Performance Counters. Архитектура современных процессоров очень сложна, в них может происходить очень много разного. Фокус в том, что мы можем включить некоторые счетчики внутри процессора, которые будут считать количество произошедших событий. То есть, некоторый железный профилировщик внутри процессора.

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



В этом году Сергей снова прилетит к нам в Москву — правда уже не из Питера, а из Калифорнии. С темой он определится в январе. Скорее всего это будет снова что-то про оптимизацию производительности.

Всё хорошо

Twisted — асинхронный (событийно-ориентированный) фреймворк, написанный на Python. Мощное средство для быстрой разработки сетевых (и не только) сервисов. Он разработан с использованием паттерна проектирования Reactor. Сервисы созданные с использованием Twisted быстры и надежны, фреймворк позволяет не писать макаронный код, насыщенный непонятными коллбэками, имеет внутри себя красивые хелперы (Deferred, Transport, Protocol etc). Другими словами, делает нашу жизнь бекенд разработчиков лучше.

Но есть и проблемы

Основная проблема в том, что многочисленные, надежные, оттестированные, удобные библиотеки, использующие в своей основе синхронные модули Python (socket, os, ssl, time, select, thread, subprocess, sys, signal etc), просто возьмут и заблокируют нам основной процесс, цикл реактора и наступит беда. Такими библиотеками, к примеру, являются psycopg2, request, mysql и другие. В частности, psycopg2 используется в Django ORM как один из бекендов баз данных.

Что же делать?

Есть три пути. Сложный, приемлемый и хороший. Сложный — реализовать аналог библиотеки на Twisted. Приемлемый — использовать deferToThread и запускать синхронный код в отдельных потоках (используя пул потоков реализованный в Twisted). О хорошем пути (по моему мнению) и пойдет речь в заметке.

Мы в «Латере» занимаемся созданием биллинга для операторов связи и рассказываем на Хабре о разработке своего продукта, а также публикуем интересные технические переводные материалы. И сегодня мы представляем вашему вниманию адаптированный перевод одной из глав книги «Архитектура open-source-приложений», в которой описываются предпосылки появления, архитектура и организация работы популярного веб-сервера nginx.

Предлагаю вашему вниманию статью, основанную на публикации Laurent Luce о реализации работы со списками в CPython. Она может быть полезна начинающим программистам на Python, либо готовящимся к собеседованию. Функции C показаны в сокращенном варианте и с моими комментариями. Полный текст функций можно найти в исходниках CPython 2.7.

Эта статья описывает реализацию объекта списка в CPython, наиболее популярной реализации Python. Списки в Python — это мощный инструмент, и интересно узнать, как они устроены внутри. Взгляните на простой скрипт, который добавляет несколько целых значений в список и выводит их:

>>> l = []
>>> l.append(1)
>>> l.append(2)
>>> l.append(3)
>>> l
[1, 2, 3]
>>> for e in l:
...   print e
...
1
2
3

Как вы можете видеть, список является итерируемым объектом.

C-структура объекта списка

Объект списка в CPython представлен нижеследующей структурой в C. ob_item — это список указателей на элементы списка, allocated — количество выделенной памяти.

typedef struct {
    PyObject_VAR_HEAD
    PyObject **ob_item;
    Py_ssize_t allocated;
} PyListObject;

Этот пост написан по мотивам мастер-класса Бориса Вольфсона (директора по развитию HeadHunter), посвященного (сюрприз!) основам Agile. Материал будет полезен всем, кто либо совсем не знаком с данной методологией разработки сложного ПО, либо имеет о ней смутное представление.

Скажем прямо, русскому человеку планировать тяжело. Люди в России сильны импровизацией и умением собираться в критический момент, выдавая поразительные результаты. Но жизнь показывает, что команда программистов на подобной идеологии далеко не уедет. Героические усилия в одно время не смогут компенсировать пофигизм в другое.


Что общего у зомби-апокалипсиса и разработки ПО? Простые правила помогают пережить и то, и другое

Около двух месяцев назад мы анонсировали конкурс по Material Design. Вот и подходит к концу последняя неделя конкурса (напомним, работы принимаются до 15 ноября), поэтому самое время для последнего рывка. Пока не поздно подать заявку. :)


^{Вы думали, обои для Android 6.0 делают в фотошопе? А вот и нет.}

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

Для кого эта статья?

В основном статья для технических лидеров команд разработчиков ПО и тех, кто стремится ими стать. И, конечно, для остальных, кого заинтересовала тема.  Для тех, кому интересно мнение относительно роли технического лидера, и для тех, кто готов делиться собственными соображениями на этот счет.

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

Мне повезло стать Google Developer Expert Android в России, и поэтому я вдвойне переживаю, что не все из вас подготовились к релизу заранее. Сейчас мы с вами постараемся запрыгнуть на уплывающий пароход с зефирками.

Вы можете не читать, а просто посмотреть мой доклад на прошедшем DroidCon.

Но специально для тех, кто любит читать хабр больше чем смотреть youtube — добро пожаловать под кат. Там мы пройдемся по чеклисту действий, которые каждый обязательно должен сделать в своем приложении, а потом посмотрим на новые возможности для разработчиков в sdk 23.