Привет, Хабр! Вот уже год как я работаю над онлайн-программой обучения Android-разработчиков в Академии e-Legion. Под катом рассказываю, как пришёл к идее стать преподом и с какими сложностями сталкиваюсь в процессе.
![](https://habrastorage.org/r/w1560/webt/hq/v5/8a/hqv58abtzr-h6xtlx9iwejprvma.png)
Полтора года назад мы с моим бывшим одногруппником, бывшим коллегой и другом — это всё один человек, привет, Геор! — потягивали пиво на азоте и думали о том, как планируем устраивать свои жизни. Была куча идей — от выбора места жительства и машины до имён детей и животных. В конце концов, пришли к такому печальному и неизбежному состоянию, как старость. Где будем стареть и чем будем заниматься?
![image](https://habrastorage.org/getpro/habr/post_images/a4d/b20/df2/a4db20df2e6e0ef16bc533368367bc63.gif)
Сидеть дома или на лавочке мне не хотелось, и я подумал что, наверное, стану учить молодёжь тому, что умею сам. Эта мысль нам понравилась, и мы вспомнили о наших учителях и преподавателях, на кого бы мы хотели равняться, а на кого — нет. Но вместе с преподавателями пришли и студенческие годы, и друзья, и диалог перетёк в другое русло. Тогда я думал, что преподавание во вторую треть моей жизни мне не грозит. Но я ошибался.
В какой-то момент e-Legion — компания, в которой я работаю, решила запустить онлайн-школу для подготовки iOS- и Android-разработчиков — Академию e-Legion. Курсы нужно было спроектировать с нуля, сделать информативными, актуальными и вот это вот всё. За подготовку и изложение материала отвечают сотрудники, то есть мы. Собственно говоря, образовательная программа — это своего рода проект, пусть специфика и отличается от основной деятельности e-Legion.
Недолго думая, я согласился поучаствовать. Честно говоря, я вообще не раздумывал, я хотел преподавать.
Этап планирования был относительно простым. Первые блоки программы — основы Android-платформы, середина — архитектура, тесты и библиотеки, последние 2 блока — дизайн, кастомные вью и сторонние сервисы типа Firebase. Ничего необычного, идём по нарастающей, постепенно повышая сложность.
После планирования стали готовить материал для записи лекций. В моей голове была мысль, которую я почему-то не мог чётко сформулировать. Так продолжалось некоторое время, и внезапно во время подготовки материала про контекст, я услышал в своей голове голос: «ТЕБЕ НЕЛЬЗЯ ЛАЖАТЬ!»
Мне нельзя лажать.
Это так меня впечатлило, что я оставил контекст в покое и решил подумать о том, не лажаю ли я. И додумался до следующего. Я готовлю материал и доношу его до большого количества людей. Эти люди по большей части не знакомы с платформой, и информация, полученная от меня, становится для них авторитетной. Как свежевылупившийся утёнок принимает за мать первое попавшееся в поле зрения и не съевшее его существо.
Это накладывает ответственность. Я не могу себе позволить говорить что-то, в чём не уверен сам и что не является совершенно точно правдой. А это значит, что перед подготовкой материала нужно самому изучить нюансы. Ведь в разговоре будут ссылаться на меня, и если тезис внезапно окажется ошибочным, то будет ой как неудобно.
Помимо самих курсов мы ведём чат со студентами, отвечаем на вопросы или подталкиваем к правильному решению заданий. Я вывел для себя правило: доносить только точную информацию. Даже если я точно знаю, что ответить, я всегда захожу на соответствующий онлайн-ресурс, убеждаюсь в ответе и только тогда отвечаю. Или кидаю ссылку. Это касается и видео-лекций — в них даю только то, что доподлинно известно. С лекциями, конечно, попроще — текст уже подготовлен, надо только прочитать. А вот над произвольной речью, над объяснениями материала во время live coding-сессий пришлось попотеть.
Раз за разом я повторяю одну и ту же ошибку — проецирую свой опыт на собеседника. Я забываю о том, что собеседник — не я, он не читал те книги, что читал я, не смотрел тех фильмов, что смотрел я, и не сталкиваться с тем кодом, с которым сталкивался я. С коллегами проще — я могу рассказать часть деталей, часть проблемы, и они, основываясь уже на своём опыте, остальную часть додумают сами. Это опасно, так как в конце концов понятия, ситуации и термины обрастают кличками — профессионализмами, вроде безобидного «вьюха» для View или «шестёрочных разрешений» для Runtime Permissions, и мы, разработчики, по большей части в речи используем уже их. Безусловно, мы в отделе друг друга понимаем, как и любая группа людей, занимающиеся общим делом продолжительное время.
Со студентами всё не так. Мне нельзя использовать сленг. Мне нужно называть вещи так, как они официально называются, чтобы у студентов не было проблем с поиском дополнительной информации. В первое время у меня были сложности с этим моментом. В итоге я сформулировал ещё одно правило: если это сугубо андроидная вещь, то я её не перевожу, а просто пользуюсь транслитерацией. Если дело касается письма, то чаще использую оригинальное, английское написание, например, Activity или LayoutInflater. Если же понятие более общее и распространённое, то использую и перевод, и оригинальное написание. Например, Button — кнопка, она и в Африке кнопка. Эти простые и понятные правила сделали мою речь чище. Возникает меньше желания обозвать что-либо «фиговиной», когда ты совершенно точно знаешь, как это что-то пишется, произносится и переводится. И даже представляется в голове.
Мне очень хочется задать вопрос кандидату на собеседовании: «Объясните человеку, который не занимается Android-разработкой, что такое context?» И ответа мне будет достаточно, чтобы решить, шарит он или не очень. И нет, тут правильного ответа не будет.
Когда я только начал готовить программу обучения, то понял, что довольно неплохо знаю, для чего нужен тот или иной компонент, класс, но совершенно не в курсе, как он устроен изнутри. Оно и понятно, зачем мне ковыряться в коде SDK или библиотек? «Я — потребитель (хоть и разработчик), мне это не нужно» — думал я. Но я был не прав.
В Android есть компонент — Service, он используется для операций, не связанных с интерфейсом напрямую. Например, проигрывание музыки. Отсутствие связи с интерфейсом порождает миф, будто Service работает в фоне. Но это не так. Service запускается в главном потоке, может блокировать его и, как следствие, вызвать ANR. А для фоновой работы в SDK есть IntentService, который обрабатывает входящие интенты друг за другом, по очереди. А после выполнения всех интентов завершает себя. Любой Android-разработчик должен это знать.
Когда я работал с IntentService, то представлял линию. Линия начинается со стартом сервиса и завершается с окончанием сервиса. Просто, понятно, удобно. Только вот эта уютная картина рушится, когда мне нужно было представить, как в запущенный сервис попадает новый интент. Как это представить? Куда приделать стрелочку? Там должен быть стек или что? Мне стало ясно, что так дальше нельзя. Линия — слишком размытая и не подходящая иллюстрация того, что из себя представляет IntentService.
Я полез в исходники и увидел простую картину — HandlerThread на пару с Handler. Обычный HandlerThread! И всё встало на свои места: интенты обрабатываются по очереди, потому что в MessageQueue они располагаются по очереди. Каждый новый Intent оборачивается в Message, причём ещё и с указанием номера запуска сервиса — startId. После обработки интента происходит вызов метода stopSelf() с передачей этого startId, и если он равен последнему вызову сервиса, то сервис завершается. В моей голове всё сложилось как пазл.
![image](https://habrastorage.org/r/w1560/webt/zs/eo/vi/zseovivy3sqjqk0ho_v2x4e07ai.png)
Это касается не только IntentService. Заглядывание под капот классов из SDK даёт кучу плюсов. Никаких абстрактных линий и стрелочек, только абсолютное понимание устройства механизма. Больше точности, меньше догадок. Меньше беспокойства, больше уверенности. Больше знаний, меньше лажи. А мне ведь нельзя лажать, помните?
Когда мы начинали работу над программой, нас спросили: «Для кого эти курсы? Кто придёт к нам учиться?» Над ответом долго думать не пришлось — это ребята, которые шарят немного в Java, в ООП, студенты профильных ВУЗов, которые только начинают свой путь разработчика, или программисты, которые хотят переквалифицироваться с другого направления. Поэтому, собственно, программа и включает в себя основы фреймворка.
Гораздо интереснее думать о том, кто в конце концов получится после прохождения курса. Какие знания студент будет хранить в своей голове. Или как он будет устраиваться на работу. Я представляю себе, как он достает телефон и говорит интервьюеру: «Вот, смотрите, это мое приложение, я его написал!» Интервьюер берёт телефон, тыкает кнопки, удивляется анимациям, задаёт вопросы о реализации той или иной фичи. Студент отвечает. У них приятная профессиональная беседа. А HR впечатлён, доволен и готов принять моего студента на работу. Это успех. Но чтобы воплотить в жизнь это собеседование и ещё сотню собеседований других студентов, нам нужно работать над материалом, делать его лучше, полнее, точнее.
Видение конечного результата — студента на собеседовании — помогает мне концентрироваться на работе и не оставлять пробелов. Хотя, если уж очень хочется, то всегда можно дать пару тем на самостоятельное изучение, тем самым мотивируя учащихся искать информацию. Всего в меру.
После прочитанного может появиться впечатление, что курсы по Android-разработке — целиком моя заслуга. Какая чепуха! Один я бы ни за что не потянул такой объём работы. Нас много, но отдельное спасибо моему коллеге по цеху Марату за титанический труд. Как приедешь в СПб — с меня азот.
А вообще, быть преподом — полезно. Когда я преподаю, я учусь сам. Студенты классные, они мотивированы не только тем, что заплатили денег за курс. Видно, что они действительно хотят освоить новую профессию — стать мобильным разработчиком. Процесс, конечно, не быстрый, но у них есть 9 месяцев, чтобы вникнуть в основы и запилить своё приложение. И не одно. Так что я рад, что могу помочь им в этом нелёгком деле.
Самым сложным в преподавании оказался подбор формулировок, чтобы быть точным и понятным, минимизировать вопросы и донести мысль студентам без каких-либо искажений. До сих пор учусь грамотно подбирать слова. А ещё учусь не лажать. Эти навыки за пару дней не получить, хоть тресни.
За время подготовки материалов я посмотрел разные программы, например, курс от Google на Udacity, изучил выступления классных спикеров. Перечитал столько документации и туториалов, что чувствую себя ходячей Википедией по Android-разработке.
Главное — делиться опытом и знаниями со студентами оказалось очень круто. Если раньше результат моей работы был связан только с релизами приложений и пофикшенными багами, то теперь я ещё и вижу, как благодаря нашим курсам развиваются другие люди.
Короче, подключайтесь!
![](https://habrastorage.org/webt/hq/v5/8a/hqv58abtzr-h6xtlx9iwejprvma.png)
О старости и пиве
Полтора года назад мы с моим бывшим одногруппником, бывшим коллегой и другом — это всё один человек, привет, Геор! — потягивали пиво на азоте и думали о том, как планируем устраивать свои жизни. Была куча идей — от выбора места жительства и машины до имён детей и животных. В конце концов, пришли к такому печальному и неизбежному состоянию, как старость. Где будем стареть и чем будем заниматься?
![image](https://habrastorage.org/getpro/habr/post_images/a4d/b20/df2/a4db20df2e6e0ef16bc533368367bc63.gif)
Сидеть дома или на лавочке мне не хотелось, и я подумал что, наверное, стану учить молодёжь тому, что умею сам. Эта мысль нам понравилась, и мы вспомнили о наших учителях и преподавателях, на кого бы мы хотели равняться, а на кого — нет. Но вместе с преподавателями пришли и студенческие годы, и друзья, и диалог перетёк в другое русло. Тогда я думал, что преподавание во вторую треть моей жизни мне не грозит. Но я ошибался.
О вербовке сотрудников
В какой-то момент e-Legion — компания, в которой я работаю, решила запустить онлайн-школу для подготовки iOS- и Android-разработчиков — Академию e-Legion. Курсы нужно было спроектировать с нуля, сделать информативными, актуальными и вот это вот всё. За подготовку и изложение материала отвечают сотрудники, то есть мы. Собственно говоря, образовательная программа — это своего рода проект, пусть специфика и отличается от основной деятельности e-Legion.
Недолго думая, я согласился поучаствовать. Честно говоря, я вообще не раздумывал, я хотел преподавать.
О голосах в голове
Этап планирования был относительно простым. Первые блоки программы — основы Android-платформы, середина — архитектура, тесты и библиотеки, последние 2 блока — дизайн, кастомные вью и сторонние сервисы типа Firebase. Ничего необычного, идём по нарастающей, постепенно повышая сложность.
После планирования стали готовить материал для записи лекций. В моей голове была мысль, которую я почему-то не мог чётко сформулировать. Так продолжалось некоторое время, и внезапно во время подготовки материала про контекст, я услышал в своей голове голос: «ТЕБЕ НЕЛЬЗЯ ЛАЖАТЬ!»
Об ответственности
Мне нельзя лажать.
Это так меня впечатлило, что я оставил контекст в покое и решил подумать о том, не лажаю ли я. И додумался до следующего. Я готовлю материал и доношу его до большого количества людей. Эти люди по большей части не знакомы с платформой, и информация, полученная от меня, становится для них авторитетной. Как свежевылупившийся утёнок принимает за мать первое попавшееся в поле зрения и не съевшее его существо.
Это накладывает ответственность. Я не могу себе позволить говорить что-то, в чём не уверен сам и что не является совершенно точно правдой. А это значит, что перед подготовкой материала нужно самому изучить нюансы. Ведь в разговоре будут ссылаться на меня, и если тезис внезапно окажется ошибочным, то будет ой как неудобно.
Помимо самих курсов мы ведём чат со студентами, отвечаем на вопросы или подталкиваем к правильному решению заданий. Я вывел для себя правило: доносить только точную информацию. Даже если я точно знаю, что ответить, я всегда захожу на соответствующий онлайн-ресурс, убеждаюсь в ответе и только тогда отвечаю. Или кидаю ссылку. Это касается и видео-лекций — в них даю только то, что доподлинно известно. С лекциями, конечно, попроще — текст уже подготовлен, надо только прочитать. А вот над произвольной речью, над объяснениями материала во время live coding-сессий пришлось попотеть.
О правильных названиях
Раз за разом я повторяю одну и ту же ошибку — проецирую свой опыт на собеседника. Я забываю о том, что собеседник — не я, он не читал те книги, что читал я, не смотрел тех фильмов, что смотрел я, и не сталкиваться с тем кодом, с которым сталкивался я. С коллегами проще — я могу рассказать часть деталей, часть проблемы, и они, основываясь уже на своём опыте, остальную часть додумают сами. Это опасно, так как в конце концов понятия, ситуации и термины обрастают кличками — профессионализмами, вроде безобидного «вьюха» для View или «шестёрочных разрешений» для Runtime Permissions, и мы, разработчики, по большей части в речи используем уже их. Безусловно, мы в отделе друг друга понимаем, как и любая группа людей, занимающиеся общим делом продолжительное время.
Со студентами всё не так. Мне нельзя использовать сленг. Мне нужно называть вещи так, как они официально называются, чтобы у студентов не было проблем с поиском дополнительной информации. В первое время у меня были сложности с этим моментом. В итоге я сформулировал ещё одно правило: если это сугубо андроидная вещь, то я её не перевожу, а просто пользуюсь транслитерацией. Если дело касается письма, то чаще использую оригинальное, английское написание, например, Activity или LayoutInflater. Если же понятие более общее и распространённое, то использую и перевод, и оригинальное написание. Например, Button — кнопка, она и в Африке кнопка. Эти простые и понятные правила сделали мою речь чище. Возникает меньше желания обозвать что-либо «фиговиной», когда ты совершенно точно знаешь, как это что-то пишется, произносится и переводится. И даже представляется в голове.
О картинках в голове
Мне очень хочется задать вопрос кандидату на собеседовании: «Объясните человеку, который не занимается Android-разработкой, что такое context?» И ответа мне будет достаточно, чтобы решить, шарит он или не очень. И нет, тут правильного ответа не будет.
Когда я только начал готовить программу обучения, то понял, что довольно неплохо знаю, для чего нужен тот или иной компонент, класс, но совершенно не в курсе, как он устроен изнутри. Оно и понятно, зачем мне ковыряться в коде SDK или библиотек? «Я — потребитель (хоть и разработчик), мне это не нужно» — думал я. Но я был не прав.
В Android есть компонент — Service, он используется для операций, не связанных с интерфейсом напрямую. Например, проигрывание музыки. Отсутствие связи с интерфейсом порождает миф, будто Service работает в фоне. Но это не так. Service запускается в главном потоке, может блокировать его и, как следствие, вызвать ANR. А для фоновой работы в SDK есть IntentService, который обрабатывает входящие интенты друг за другом, по очереди. А после выполнения всех интентов завершает себя. Любой Android-разработчик должен это знать.
Когда я работал с IntentService, то представлял линию. Линия начинается со стартом сервиса и завершается с окончанием сервиса. Просто, понятно, удобно. Только вот эта уютная картина рушится, когда мне нужно было представить, как в запущенный сервис попадает новый интент. Как это представить? Куда приделать стрелочку? Там должен быть стек или что? Мне стало ясно, что так дальше нельзя. Линия — слишком размытая и не подходящая иллюстрация того, что из себя представляет IntentService.
Я полез в исходники и увидел простую картину — HandlerThread на пару с Handler. Обычный HandlerThread! И всё встало на свои места: интенты обрабатываются по очереди, потому что в MessageQueue они располагаются по очереди. Каждый новый Intent оборачивается в Message, причём ещё и с указанием номера запуска сервиса — startId. После обработки интента происходит вызов метода stopSelf() с передачей этого startId, и если он равен последнему вызову сервиса, то сервис завершается. В моей голове всё сложилось как пазл.
![image](https://habrastorage.org/webt/zs/eo/vi/zseovivy3sqjqk0ho_v2x4e07ai.png)
Это касается не только IntentService. Заглядывание под капот классов из SDK даёт кучу плюсов. Никаких абстрактных линий и стрелочек, только абсолютное понимание устройства механизма. Больше точности, меньше догадок. Меньше беспокойства, больше уверенности. Больше знаний, меньше лажи. А мне ведь нельзя лажать, помните?
О студентах
Когда мы начинали работу над программой, нас спросили: «Для кого эти курсы? Кто придёт к нам учиться?» Над ответом долго думать не пришлось — это ребята, которые шарят немного в Java, в ООП, студенты профильных ВУЗов, которые только начинают свой путь разработчика, или программисты, которые хотят переквалифицироваться с другого направления. Поэтому, собственно, программа и включает в себя основы фреймворка.
Гораздо интереснее думать о том, кто в конце концов получится после прохождения курса. Какие знания студент будет хранить в своей голове. Или как он будет устраиваться на работу. Я представляю себе, как он достает телефон и говорит интервьюеру: «Вот, смотрите, это мое приложение, я его написал!» Интервьюер берёт телефон, тыкает кнопки, удивляется анимациям, задаёт вопросы о реализации той или иной фичи. Студент отвечает. У них приятная профессиональная беседа. А HR впечатлён, доволен и готов принять моего студента на работу. Это успех. Но чтобы воплотить в жизнь это собеседование и ещё сотню собеседований других студентов, нам нужно работать над материалом, делать его лучше, полнее, точнее.
Видение конечного результата — студента на собеседовании — помогает мне концентрироваться на работе и не оставлять пробелов. Хотя, если уж очень хочется, то всегда можно дать пару тем на самостоятельное изучение, тем самым мотивируя учащихся искать информацию. Всего в меру.
О том, что останется после меня
После прочитанного может появиться впечатление, что курсы по Android-разработке — целиком моя заслуга. Какая чепуха! Один я бы ни за что не потянул такой объём работы. Нас много, но отдельное спасибо моему коллеге по цеху Марату за титанический труд. Как приедешь в СПб — с меня азот.
А вообще, быть преподом — полезно. Когда я преподаю, я учусь сам. Студенты классные, они мотивированы не только тем, что заплатили денег за курс. Видно, что они действительно хотят освоить новую профессию — стать мобильным разработчиком. Процесс, конечно, не быстрый, но у них есть 9 месяцев, чтобы вникнуть в основы и запилить своё приложение. И не одно. Так что я рад, что могу помочь им в этом нелёгком деле.
Самым сложным в преподавании оказался подбор формулировок, чтобы быть точным и понятным, минимизировать вопросы и донести мысль студентам без каких-либо искажений. До сих пор учусь грамотно подбирать слова. А ещё учусь не лажать. Эти навыки за пару дней не получить, хоть тресни.
За время подготовки материалов я посмотрел разные программы, например, курс от Google на Udacity, изучил выступления классных спикеров. Перечитал столько документации и туториалов, что чувствую себя ходячей Википедией по Android-разработке.
Главное — делиться опытом и знаниями со студентами оказалось очень круто. Если раньше результат моей работы был связан только с релизами приложений и пофикшенными багами, то теперь я ещё и вижу, как благодаря нашим курсам развиваются другие люди.
Короче, подключайтесь!