Когда деревья были только бинарными, а дешевая чашка кофе стоила дороже, чем час программиста, автор делал первые попытки программирования. Не существовало «айтишников», «дизайнеров», «js-ников», и даже «прогеров» — ты либо был на «ты» с железками, всем софтом и программированием, либо нет. Время ушло, пришла специализация, выросли оклады, потом еще раз, а потом помножились на два. И теперь мы охеревшие настолько специализированы, что…

Автор — из старой школы. По разным причинам. Мне нравится заниматься «всем», помогать себе и компании, и я рассчитываю на отдачу — не только, и не столько, на финансовую. Я постоянно учусь. Но не только своей «основной», узкой специальности (=программирование), за которую платят, и ниже объясню, почему…

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

Дальше я постараюсь обобщить личный и известный мне опыт по этой проблеме.

Это вторая часть лекции Дмитрия Свирихина — разработчика из команды мобильной Яндекс.Почты.

— Мы с вами продолжаем рассматривать типичные проблемы Android-разработчика и способы их решения. Мы уже рассмотрели, как решить проблему неконсистентности UI у нас в приложении, проблемы, которые могут возникнуть при взаимодействии с клавиатурой, и проблемы потери state, а также узнали, как мы можем эффективно применять кастомные view. Всю вторую часть мы посвятим ещё одной проблеме — она называется «недостаточная интерактивность». Посмотрим, как мы можем сделать наше приложение более интерактивным и понятным для пользователя.


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

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

---

Шутка, написанная гарнитурой Times, на 10 % смешнее той, что написана гарнитурой Arial. Почему? Чёрт знает. Лучшее объяснение, которое я видел: юмор ассоциируется с агрессией, с остротой, с остроумием — а Times выглядит более острым, чем Arial.

Ещё один любопытный эксперимент, в котором участвовало 45 тыс. человек. Заходишь на сайт, тебе показывают статью Дэвида Дойча, британского физика. В статье автор пишет, что сегодня очень трудно внезапно умереть. Например, от инфекционного заболевания или в уличной драке. Лет сто назад это случалось намного чаще. Главный вывод статьи — сейчас мир безопасен как никогда. В среднем, конечно, ведь где-то постоянно идут локальные военные конфликты.

Автор этой лекции — Константин Заикин kzaikin, руководитель группы разработки Яндекс.Браузера для Android в Санкт-Петербурге. Он рассказал об инструментах Android-разработчика и всей команды, а также о том, как справляться с legacy-кодом, публиковать большой проект вовремя и улучшать качество кода.


— Друзья, привет. Я очень рад, что вас так много сегодня пришло. Я приехал из Питера, в Яндексе работаю около шести лет. Успел засветиться в Картах, Такси, Метрике и Поиске. Уже два года я работаю над Яндекс.Браузером для Android.

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

Базы с индексами и районами городов тоже открыты. Бонусом я расскажу, как найти эти части адреса, если их не хватает.

Все справочники из этой статьи бесплатны и открыто лежат в интернете. Ни один не украли из ФСБ таинственные хакеры.

­­ 

На первый взгляд, Clean Architecture – довольно простой набор рекомендаций к построению приложений. Но и я, и многие мои коллеги, сильные разработчики, осознали эту архитектуру не сразу. А в последнее время в чатах и интернете я вижу всё больше ошибочных представлений, связанных с ней. Этой статьёй я хочу помочь сообществу лучше понять Clean Architecture и избавиться от распространенных заблуждений.

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

— Что, даже на том нечитаемом эзотерическом языке, где есть всего пара команд, которые едва-едва симулируют машину Тьюринга?
— Да, этот язык называется brainfuck. Я знаю brainfuck.

И это был не трюк — мы проверили. Я называл известный мне язык программирования, он тратил пару минут в Интернете на то, чтобы освежить свои знания по нему — и был способен писать на этом языке работающие алгоритмы. Я никак не мог понять этого. Ему, как и мне, было тогда около 18 лет — как он мог в этом возрасте знать все эти языки?


Интерпретатор brainfuck, написанный на brainfuck

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

Сегодня я советую своим студентам «постараться изучить все языки программирования». Подумайте сами — ведь эта идея лучше, чем все вот эти «В этом году я выучу Go! Ой, нет, теперь говорят что в моде Rust — выучу лучше Rust! Или Swift ...». Просто выучите все — не ошибётесь. А эта статья, возможно, вам в этом немного поможет.

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

Ниже будет показан пример использования Camera2 API, который пока довольно слабо задокументирован и изучен сообществом. Для его укрощения будет использована RxJava2. Вторая версия этой популярной библиотеки вышла сравнительно недавно, и примеров на ней тоже немного.

Для кого этот пост? Я рассчитываю, что читатель – умудрённый опытом, но всё ещё любознательный Android-разработчик. Очень желательны базовые знания о реактивном программировании (хорошее введение – здесь) и понимание Marble Diagrams. Пост будет полезен тем, кто хочет проникнуться реактивным подходом, а также тем, кто хочет использовать Camera2 API в своих проектах. Предупреждаю, будет много кода!

Исходники проекта можно найти на GitHub.

Сейчас набирает обороты библиотека Conductor, однако в сети не очень много информации по её использованию, а из официальных источников доступны только примеры. Эта статья призвана дать вводный курс по Conductor и убрать некоторые грабли с вашего пути. Статья рассчитана на тех кто уже имеет некоторый опыт в разработке Android.

Conductor позиционируется как замена стандартным фрагментам. Основная идея обернуть View и дать доступ к методам жизненного цикла. Conductor имеет свой жизненный цикл, который сильно проще чем у фрагметов, но и в нём есть свои хитрости (об этом дальше).

Основные преимущества, которые даёт Conductor:

• Упрощение кода
• Транзакции выполняются мгновенно
• Возможность построить приложение на одной Activity
• Не ограничивает в выборе архитектуры приложения
• Легко встраиваемые анимации
• Отсутствие необходимости сохранять состояния между изменениями конфигураций

Так же в коробке вы получите:

• Работа с бэкстеком
• Стандартные коллбеки активити легко доступны
• Несколько стандартных анимаций
• Привязка жизненного цикла к RxJava
• Быстрая интеграция с ViewPager

Далее мы с вами разберём несколько типовых кейсов использования, которые встречаются почти во всех приложения и попробуем разобраться в жизненном цикле контроллера.

Меня зовут Аркадий, я Android-разработчик в Badoo. В последнее время в нашем блоге много постов про Go, PHP, JS, QA, и я решил разбавить их темами по мобильной разработке. Как раз занимался портированием одного Android-проекта с RxJava 1 на RxJava 2 и читал всё, что можно найти на эту тему в интернете. В частности, доклад Джейка Вортона с конференции GOTO Copenhagen 2016. Мне показалось, что это достойный кандидат на перевод – думаю, многие Android-разработчики задумываются о переходе на RxJava 2, и им интересно, что изменилось по сравнению с первой версией.

Джейк сделал достаточно объёмное введение о реактивном программировании, так что знание RxJava 1 не требуется для понимания статьи. Доклад был подготовлен, когда RxJava2 ещё только готовилась к выпуску (на текущий момент уже выпущена версия 2.1.0).

Привет! Меня зовут Гавриил, я Android-лид Touch Instinct.

В марте Google выкатил релизное обновление ConstraintLayout. Презентовали его еще на прошлом Google I/O. С того момента прошел почти год, ConstraintLayout стал лучше, быстрее и оброс новыми возможностями. Например, приятно, что появилась возможность объединения элементов в цепи — это позволяет использовать ConstraintLayout вместо LinearLayout.

О всех новых и старых возможностях ConstraintLayout я и постараюсь рассказать в этой статье. Предупрежу сразу — статья будет длинная и других семи частей не будет. Про визуальный редактор ConstraintLayout в статье не будет ни слова — только XML-разметка (по старинке) и немного кода.

На Хабре уже написано достаточно много статьей по теме, в частности:

• 2 статьи о работе с Upwork (в прошлом известном как oDesk)
  • Легальный вывод денег из oDesk в РФ от 11 января 2013
  • Легальный вывод денег с oDesk на р/c ИП от 4 сентября 2012
• 4 статьи о работе с иностранными заказчиками
  • Практика работы «в белую» с иностранными заказчиками от 14 ноября 2011
  • Тонкости при работе с иностранным заказчиком от 10 ноября 2011
  • Почему ИТшнику стоит стать ИПшником и почему не стоит регистрировать ООО от 9 ноября 2011
  • ООО и ведение валютных операций от 18 февраля 2011
• 3 статьи о неочевидных налогах
  • НДС и фрилансеры, работающие с Upwork от 8 апреля 2017
  • Налоговый cуслик — 2. «Налог на Google» и агентский НДС от 15 января 2017
  • Налоговый суслик. Особенности УСН при работе по договорам с Apple, Google и другими от 16 июля 2015

В ответ на повторяющиеся просьбы написать статью, в которой:

• разбросанные по разным статьям крупицы будут собранны в единое целое
• всевозможные противоречия будут устранены
• все сведения будут иметь актуальный характер
• будут учтены пожелания такие как «а можно с картинками? :)»

родилось следующее руководство.

Всем привет! Наконец-то подоспела третья часть цикла статей о Dagger 2!

Перед дальнейшим прочтением настоятельно рекомендую ознакомиться с первой и второй частями.

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

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

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

Итак, хватит разглагольствовать, и вперед к новым знаниям!

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

Мы пригласили 126 студентов из 25 городов; 91 участник успешно завершил программу. Первый этап состоял из лекций, второй — из той самой командной работы. Обычно студента окружают люди той же специализации, что и он сам: менеджеры учатся вместе с менеджерами, дизайнеры — с дизайнерами и т. д. Но в реальности вам нужно хотя бы по одному представителю нескольких профессий. В каждую команду вошли студенты разных школ: дизайнер, менеджер и один-два разработчика.

Лекции студентам читали сотрудники Яндекса, которые каждый день сталкиваются с реальными задачами и делают приложения для миллионов пользователей. Специально для читателей Хабра мы собрали полную программу курса по мотивам лекций «Мобилизации».

В апреле в Москве прошла JPoint 2016 – крупнейшая Java-конференция в России. Напомню, что на конференции было 50 докладов, которые шли в 4 треках в течение двух дней. В сентябре мы открыли доступ к видео для наших читателей, однако руки всё никак не доходили до публикации топ-10 докладов на Хабре.

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

Конечно, какие-то доклады оказываются лучше, какие хуже. Но в этом посте речь пойдет о 10 жемчужинах, лучших докладах, оценка каждого из которых оказалась выше 4.6 по пятибалльной шкале. Ссылка на остальные доклады по катом, так что вам будет чем заняться до Нового Года:)

Вступление

Давно хотел написать статью про образование в Computer Science, но руки не доходили. Решил все-таки это наконец сделать. Итак, о чем пойдет речь? Речь о том, что из себя представляет диплом MSc Computer Science топовых университетов США (во всех подробностях, включая основные курсы, книги и проекты) и как ему соответствовать.

Почему именно MSc? Это — некая развилка: с одной стороны после MSc — вы уже готовый к жизни инженер (да, речь идет о инженерной подготовке, как мне кажется это самое больное место в нашей системе образования), с другой — можно спокойно идти по пути PhD. Как известно, в PhD программу можно попасть и не особо умея программировать — особенно это касается теоретического Computer Science. С другой стороны найти работу программиста тоже дело не очень сложное, и часто не требует мощного образования. Но достигнув уровня MSc — вы получаете возможность разбираться как во всех новый идеях в Computer Science, так и возможность их воплотить в практику. То есть с одной стороны круто разобраться в каком-нибудь deep learning и сделать в нем что-то новое, а также взять и написать свою операционную систему (кто так сделал?). Причем вы не зажаты в рамки узкой специализации (если конечно продолжаете учиться). То есть вы теперь — универсальный солдат, готовый на все.

Надеюсь что эта статья будет полезна:
1. Студентам, которые хотят соответствовать высоким стандартам топ вузов США, или собирающиеся туда в аспирантуру по Computer Science
2. Профессионалам, которые хотят закрыть «дыры» и пробелы
3. Может кто-то из преподавателей возьмет на заметку для своих курсов.
4. Студентам, аспирантам американских вузов — хотелось бы тоже получить фидбэк, особенно касается последних трендов в образовании

Что же здесь будет написано? Минимум философии и общих мыслей: конкретная программа undergraduate и graduate курсов, конечно из дисциплин наиболее мне близких. Все курсы были лично прочувствованы на собственной шкуре, по этому и пишу. (Я пытался записаться на все интересные курсы, которые были, но мой основной упор — системное программирование, базы данных и искусственный интеллект. Отсюда конечно некий bias, но пытаюсь предложить более-менее универсальную программу).

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

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

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

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

Для начала посмотрим на экран и разберёмся, что на нём происходит и что нам
предстоит реализовать.

Разработчик Дмитрий Лукьяненко, чью лекцию мы публикуем сегодня, не только является специалистом Яндекса, но и умеет проверять на прочность решения разработчиков других компаний. Это позволяет учиться на чужих ошибках — не исключая порой своих, конечно. В докладе Дмитрий поделится примерами Android-уязвимостей, в том числе найденных им собственноручно. Каждый пример сопровождается рекомендациями — как нужно и как не нужно писать приложения под Android.



Меня зовут Дмитрий, я работаю в компании Яндекс в минском офисе, занимаюсь разработкой аккаунт-менеджера. Это библиотека, которая отвечает за авторизацию пользователей. Поэтому мы поговорим о безопасности Android-приложений.

James Kyle как-то раз взял и написал пост про структуры данных, добавив их реализацию на JavaScript. А я взял и перевёл.

Дисклеймер: в посте много ascii-графики. Не стоит его читать с мобильного устройства — вас разочарует форматирование текста.