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

От переводчика: перевод делался сходу, за один присест, так что в некоторых местах может быть немного топорным. В любом случае, вы знаете, куда писать об ошибках.
В комментариях к оригинальной статье есть несколько здравых мыслей, как, например, не использовать библиотеки с мира «большой» джавы, так как они слишком объемные, или использовать всякие Glide-ы вместо Picasso (с чем я, впрочем, согласен). Можете посмотреть, если интересно.
И еще, я не придумал, как заставить отображаться сниппеты с гитхаба, так что я просто скопировал код.

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

Далее следует список вещей, которые надо понимать во время разработки вашего первого приложения под Android. Эти уроки были извлечены из реальных ошибок, которые я делал в исходном коде моей первой программы, — ошибкок, которые я буду приводить ниже. Понимание этих вещей поможет вам написать приложение, которым вы будете гордиться чуть больше.

Конечно, если вы пишете что-то по ходу изучения Android-разработки, скорее всего, позже вы все равно возненавидите свое творение. Как сказал @codestandards:

If the code you wrote a year ago doesn't seem bad to you, you're probably not learning enough.— Code Standards ( @codestandards) 21 мая 2015

(Если код, который вы написали год назад, не кажется вам плохим, вы, наверное, недостаточно учились)

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

В Яндексе тестировщику невозможно без автоматизации. Мы даже развиваем экспериментального робота, который способен брать на себя функциональное тестирование. В какой-то момент мы поняли, что не так много людей осознают, сколько сейчас есть возможностей работать не 12 часов, а головой. Собрав весь свой опыт в тестировании и деплое, мы открыли в питерском офисе Яндекса Школу автоматизации процессов разработки. У нас получилась школа, где каждый, кто пишет код, может получить базовый набор знаний о том, как собрать, запустить и поддерживать сервис в продакшене так, чтобы это стоило недорого.



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

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

На конференции Solve for X, которую устраивает Google для сотрудничества в решении глобальных задач, выступил Чарльз Чейз (Charles Chase) с сенсационным заявлением, что в компании Lockheed разработана технология достижения устойчивой термоядерной реакции. По его словам, данная технология позволит в течении 5 лет создать прототип компактной термоядерной электростанции, а уже через 10 лет построить промышленный образец. Если дела пойдут в гору, то к 2050 эта технология позволит покрыть всю потребность в энергетике человечества.

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



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

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

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

Похоже на то, что пользователям нужно не так и много. Дело в том, что на днях приложение «Yo», отсылающее соответствующий возглас/сообщение своим контактам, вошло в топ-10 самых популярных приложений в App Store (США). Плюс ко всему, нашелся инвестор, вложивший в это приложение 1 миллион долларов США.

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

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

Если коротко, схема такая. Атакующий внедряется в сеть сигнализации SS7, в каналах которой отправляет служебное сообщение Send Routing Info For SM (SRI4SM), указывая в качестве параметра телефонный номер атакуемого абонента А. В ответ домашняя сеть абонента А посылает атакующему некоторую техническую информацию: IMSI (международный идентификатор абонента) и адрес коммутатора MSC, который в настоящий момент обслуживает абонента.



Далее атакующий с помощью сообщения Insert Subscriber Data (ISD) внедряет в базу данных VLR обновленный профиль абонента, изменяя в нем адрес биллинговой системы на адрес своей, псевдобиллинговой системы.

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

Каждый программист — проектировщик API. Хорошие программы состоят из модулей, а протокол взаимодействия модулей — это тоже API. Хорошие модули используются повторно.

API — это большая сила и большая ответственность. У хорошего API будут благодарные пользователи; поддержка плохого превратится в кошмар.

Публичный API — не воробей, опубликуешь — не уберешь. Есть только одна попытка сделать все правильно, поэтому постарайся.

API должно быть легко использовать, но сложно использовать неправильно. Сделать что-то простое с помощью такого API должно быть просто; сложное — возможно; сделать что-то неправильно должно быть невозможно, или, по крайней мере, трудно.

API должен описывать сам себя. Изучение кода на таком API не вызывает желания читать комментарии. Вообще, комментарии редко нужны.

Перед разработкой API собери требования с долей здорового скептицизма. Осознай общие задачи и реши их.

Оформляй требования как шаблоны использования API. Сверяйся с ними в процессе проектирования.

Этот пост был написан спустя год после запуска Google+, и пролежал в черновиках с тех пор ещё два года. Периодически я вспоминал про него, вздрагивая: а вдруг G+ взлетел и пост будет уже не актуален? Но время шло, Google+ всё никак не взлетал, и три года после запуска его соцсети, жизнь кипит в Фейсбуке, Твиттере и Вконтакте. Жизнь кипит и на Ютубе, где без G+ теперь ни лайк не поставишь, ни коммент не оставишь. И только в самом G+ жизни нет. А выводы поста не просто остаются актуальными, а подтверждены практикой. Поэтому просто выкладываю написанный два года текст как есть.

Конечно, понятие неуспеха относительно. В Google+ есть большое количество пользователей, бренды считают обязательным в свой «соцпакет» к представительствам в Фейсбуке и Вконтакте добавлять и G+. И тем не менее Google+ — это провал.

Как-то раз коллеги из отдела HR i-Free обратились ко мне с просьбой написать небольшую статью для молодых специалистов, которые стремятся устроиться в IT-компанию. Причины, побудившие их это сделать в целом понятны, в компании основным нанимателем молодых специалистов является отдел под моим управлением, мы берем только что закончивших вуз ребят (а иногда и студентов последних курсов), и у нас они проходят некий курс «молодого бойца».
Естественно, я не претендую на объективность, а лишь хочу дать несколько советов для тех, кто хочет начать свой путь с работы в IT-компании. Статья выражает сугубо моё мнение о том, как нанимать молодого специалиста, и очень надеюсь, что кому-то из студентов старших курсов сей краткий опус поможет в будущей карьере.
В общем, тех, кому интересно, прошу под кат.

Пока программисты (и не только) постсоветсткого пространства празднуют майские праздники Google без особой шумихи подключили возможность продавать приложения в Google Play в следующих странах: Греция, Люксембург, Румыния, Саудовская Аравия, Словакия, Турция, Украина, Вьетнам. Ура, товарищи!

Каждый, кто посвятил себя работе с компьютерами, хоть раз, но сталкивался с распространёнными высказываниями вроде: «Помоги мне сделать %work%, ты ведь всё равно без дела за компом сидишь». Особенно часто в эту ситуацию попадаёшь, когда работаешь непосредственно в окружении коллег проделывающих ручную работу. Для этих людей ты зачастую представляешься воплощением безделия и главным пользователем youtube.
Сейчас я покажу вам один из приёмов, как превратиться в глазах сотрудников из лодыря в волшебника.

В последнее время, набирает популярность мысль, что комментарии в коде — дело не обязательное, и даже вредное. Буквально вчера вечером, общаясь со знакомым молодым программистом, попросившим посмотреть его код, я обнаружил, что комменты отсутствовали вовсе, даже привычные описания методов. На мой удивленный смайлик, был ответ: “Комментарии — первый признак плохого кода”. И черт бы с ним, с начинающим программистом, но я периодически читаю что-то похожее в блогах, и слышу от коллег. Может программирование в очередной раз сделало шаг вперед, а я, среди отстающих? Под катом, немного размышлений, о том, когда и почему стоит или не стоит комментировать свой код.

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


Интерфейсы на Windows Phone 8 и Apple ios 7

Рекомендации геймдизайнеру от программиста (архитектора).

Вступление

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

Все слышали про pre poduction, но мало кто знает как именно это происходит. И если про стадию разработки написано много, а про стадию издания — еще больше, то про стадию планирования известно очень мало. В лучшем случае вам посчастливится ознакомится с результатами планирования. А вот как были достигнуты эти результаты? — загадка во тьме.

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

Я намеренно оставил за кадром другие документы: концепцию, экономическое обоснование и ТЗ для других исполнителей. Это позволило сфокусироваться на одной теме и осветить ее и только ее достаточно подробно.