Крутые лекции по Android для начинающих
Наткнулся недавно на плейлист с лекциями от Android Academy. Посмотрел несколько видосов - крутые лекции от крутых ребят, доступно, понятно и на русском языке, в общем всё как мы любим. Для начинающих зайдет.
А на гитхабе можно посмотреть крутой Android Roadmap
Наткнулся недавно на плейлист с лекциями от Android Academy. Посмотрел несколько видосов - крутые лекции от крутых ребят, доступно, понятно и на русском языке, в общем всё как мы любим. Для начинающих зайдет.
А на гитхабе можно посмотреть крутой Android Roadmap
Пять худших практик написания кода, которые помогут испортить отношения с коллегами
Интересная статейка на хабре про худшие практики написания кода.
Интересная статейка на хабре про худшие практики написания кода.
Вам знакомо такое понятие как "Технический долг"?
Технический долг – это некие накопленные, проблемные участки кода, которые нужно отрефакторить, переделать, исправить и т.д.. Обычно технический долг копится например при быстрой разработке продукта или каких-то точечных фичей. А в будущем соответственно выделяется время на исправление.
Так вот, есть интересная статистика от Stepsiz, согласно которой, средний разработчик тратит 6 часов в неделю (~ 1 рабочий день) на работу с техническим долгом.
Среднее время, затрачиваемое на работы по поддержанию работы legacy систем составляет 33%, из этого времени более 50% тратится исключительно на технический долг. Это время, когда инженер не работает над достижением своих основных целей.
Технический долг – это некие накопленные, проблемные участки кода, которые нужно отрефакторить, переделать, исправить и т.д.. Обычно технический долг копится например при быстрой разработке продукта или каких-то точечных фичей. А в будущем соответственно выделяется время на исправление.
Так вот, есть интересная статистика от Stepsiz, согласно которой, средний разработчик тратит 6 часов в неделю (~ 1 рабочий день) на работу с техническим долгом.
Среднее время, затрачиваемое на работы по поддержанию работы legacy систем составляет 33%, из этого времени более 50% тратится исключительно на технический долг. Это время, когда инженер не работает над достижением своих основных целей.
Основные понятия Scrum. Sprint (Спринт)
Продолжаем серию постов по теме "Основные понятия Scrum". Сегодня у нас речь пойдет про спринты. 👇
Sprint (Спринт) – это фиксированный, как правило, короткий промежуток времени, за который команда должна выполнить поставленные цели в начале спринта. Иногда спринты называют итерациями.
Длина спринта обычно составляет от 1 до 4 недель. В компаниях, где я работал были двухнедельные спринты и этого было вполне достаточно, хватало времени на все активности, коммуникации и на разработку фичей соответственно. Спринты выполняются в бесконечном цикле и идут один за другим без перерыва.
Важно отметить, что по завершению каждого спринта команда должна представить готовую версию разрабатываемой фичи, ценность для продукта/бизнеса/заказчика, одним словом полезный инкремент.
Это пожалуй основные моменты, которые нужно знать о спринтах. Для тех, кто пропустил, предыдущая часть "Backlog (Бэклог)". Включайте уведомления, в следующем посте интересная тема "Grooming (Груминг)".
Продолжаем серию постов по теме "Основные понятия Scrum". Сегодня у нас речь пойдет про спринты. 👇
Sprint (Спринт) – это фиксированный, как правило, короткий промежуток времени, за который команда должна выполнить поставленные цели в начале спринта. Иногда спринты называют итерациями.
Длина спринта обычно составляет от 1 до 4 недель. В компаниях, где я работал были двухнедельные спринты и этого было вполне достаточно, хватало времени на все активности, коммуникации и на разработку фичей соответственно. Спринты выполняются в бесконечном цикле и идут один за другим без перерыва.
Важно отметить, что по завершению каждого спринта команда должна представить готовую версию разрабатываемой фичи, ценность для продукта/бизнеса/заказчика, одним словом полезный инкремент.
Это пожалуй основные моменты, которые нужно знать о спринтах. Для тех, кто пропустил, предыдущая часть "Backlog (Бэклог)". Включайте уведомления, в следующем посте интересная тема "Grooming (Груминг)".
10 практик «ответственного» тимлида
Интересная статья, в которой собраны 10 практик "ответственного" тимлида. Осторожно, в статье присутствует сарказм 😉
Интересная статья, в которой собраны 10 практик "ответственного" тимлида. Осторожно, в статье присутствует сарказм 😉
Основные понятия Scrum. Grooming (Груминг)
Grooming на мой взгляд одно из важных мероприятий в скраме, т.к. от эффективности груминга в дальнейшем зависят многие процессы. И так, погнали.
Grooming (Груминг) – это встреча, на которой собираются члены скрам команд, обсуждают истории из бэклога продукта и оценивают сложность выполнения. В дальнейшем прогрумленные истории будут взяты в спринт на планировании.
До груминга, как правило, нет четко сформулированных критериев и требований к историям, на груминге самое время задать все уточняющие вопросы к представителям бизнеса, обсудить все нюансы. По окончанию груминга у каждого должно сложиться понимание того, как истории будут реализовываться.
Каких-то четких регламентов по проведению грумингов нет, обычно скрам команды исходя из опыта вырабатывают какие-то практики, тем самым совершенствуют процессы.
Несколько советов по личному опыту
1. Длительность груминга. Для себя определил оптимальное время 1 час, если груминг длится больше 1 часа – как минимум нужно сделать перерыв 15-20 минут, а лучше и во все закончить, иначе эффективность будет снижаться.
2. В какое время проводить груминги? По мне груминги лучше проводить за несколько дней до окончания спринта, т.к. на планировании, в начале спринта у вас еще останется контекст обсуждения историй и не возникнет особых трудностей вспомнить, что вы там грумили.
3. Активное участие. На груминге может участвовать любой желающий, лучше, когда на груминге будут присутствовать представители всех направлений (fron-end, back-end, moble, qa, аналитики, безопасники), таким образом вы закроете вопросы со всех сторон. Ходите на груминги и принимайте активное участие, на планировании вам это зачтется.
Таким образом, основная задача груминга – сформулировать четкие критерии и требования к историям и оценить сложность выполнения.
И важно понимать, в скраме истории оценивают не в обычных часах, днях, а в неких условных величинах, которые называются Story Points, про них и напишу в следующем посте, не переключайтесь. Scrum план тут.
Grooming на мой взгляд одно из важных мероприятий в скраме, т.к. от эффективности груминга в дальнейшем зависят многие процессы. И так, погнали.
Grooming (Груминг) – это встреча, на которой собираются члены скрам команд, обсуждают истории из бэклога продукта и оценивают сложность выполнения. В дальнейшем прогрумленные истории будут взяты в спринт на планировании.
До груминга, как правило, нет четко сформулированных критериев и требований к историям, на груминге самое время задать все уточняющие вопросы к представителям бизнеса, обсудить все нюансы. По окончанию груминга у каждого должно сложиться понимание того, как истории будут реализовываться.
Каких-то четких регламентов по проведению грумингов нет, обычно скрам команды исходя из опыта вырабатывают какие-то практики, тем самым совершенствуют процессы.
Несколько советов по личному опыту
1. Длительность груминга. Для себя определил оптимальное время 1 час, если груминг длится больше 1 часа – как минимум нужно сделать перерыв 15-20 минут, а лучше и во все закончить, иначе эффективность будет снижаться.
2. В какое время проводить груминги? По мне груминги лучше проводить за несколько дней до окончания спринта, т.к. на планировании, в начале спринта у вас еще останется контекст обсуждения историй и не возникнет особых трудностей вспомнить, что вы там грумили.
3. Активное участие. На груминге может участвовать любой желающий, лучше, когда на груминге будут присутствовать представители всех направлений (fron-end, back-end, moble, qa, аналитики, безопасники), таким образом вы закроете вопросы со всех сторон. Ходите на груминги и принимайте активное участие, на планировании вам это зачтется.
Таким образом, основная задача груминга – сформулировать четкие критерии и требования к историям и оценить сложность выполнения.
И важно понимать, в скраме истории оценивают не в обычных часах, днях, а в неких условных величинах, которые называются Story Points, про них и напишу в следующем посте, не переключайтесь. Scrum план тут.
Слышали что-нибудь про требования ACID?
ACID – это набор требований к транзакционной системе, которые обеспечивают сохранность ваших данных. Расшифровывается аббревиатура ACID как Atomicity (Атомарность), Consistency (Согласованность), Isolation (Изолированность), Durability (Надёжность).
На хабре есть статья, в которой детально описывают каждое из этих требований и на примерах рассказывают для чего это нужно и как работает. А если лень читать, на Youtube канале Listen IT можно послушать аудио версию статьи.
ACID – это набор требований к транзакционной системе, которые обеспечивают сохранность ваших данных. Расшифровывается аббревиатура ACID как Atomicity (Атомарность), Consistency (Согласованность), Isolation (Изолированность), Durability (Надёжность).
На хабре есть статья, в которой детально описывают каждое из этих требований и на примерах рассказывают для чего это нужно и как работает. А если лень читать, на Youtube канале Listen IT можно послушать аудио версию статьи.
Наткнулся на интересный сервис, зацените 👇
DevDocs – сайт с документациями по множеству популярных языков для разработчиков Angular, Django, Go, Git, Kotlin... Так же есть разделы с популярными фреймворками и еще куча всего.
DevDocs – сайт с документациями по множеству популярных языков для разработчиков Angular, Django, Go, Git, Kotlin... Так же есть разделы с популярными фреймворками и еще куча всего.
This media is not supported in your browser
VIEW IN TELEGRAM
Яндекс показал свою нейросеть, которая может переводить текст видосов в реалтайме.
Основные понятия Scrum. Story Points (Стори поинты)
Вот мы и добрались до 5-ой части нашего мини-курса, в которой рассмотрит понятие Story Points. Напомню, в предыдущей части мы говорили про Grooming.
Story Points – это условная величина, с помощью которой оценивается сложность выполнения истории. Story points не должны привязываться к физическому времени: часам, дням и т.д. Для значений story points, как правило, используются числа Фибоначчи (1, 2, 3, 5, 8, 13 и т.д.), либо похожие на Фибоначчи (...13, 20, 40, 80, 100), чем выше значение, тем сложнее реализации фичи.
По окончанию груминга конкретной истории, соответственно нужно оценить сложность ее выполнения. Как это происходит, есть такое понятие Planning Poker – техника оценки. В чем суть, всей команде раздаются карточки с story points (1, 2, 3, 5...) и каждый член команды должен проголосовать, выбрав нужную карточку. Важно понимать, голосуют в закрытую, то есть, на этапе голосования я знаю только свою оценку и никому ее не показываю, пока все не проголосуют. Когда все проголосовали/выбрали оценку – карточки открываются и таким образом смотрят, каких оценок больше.
И тут есть несколько вариантов
1. Простой. Достаточно редкий кейс, когда звёзды сложились, и каким-то чудом все оценки получились одинаковыми. На этом всё, историю оценили единогласно, идем дальше.
2. Спорный. Это наверное один из частых кейсов. К примеру, по итогам голосования мы получаем приблизительно одинаковое количество нескольких оценок. В таком случае, путем обсуждений, нужно убедить других членов команд согласиться на вашу оценку, либо вы должны согласиться на оценку ваших коллег. Таким образом добивается оценка.
3. Разброс/Хаос. Это пожалуй тоже редкий кейс. Когда у всех совершенно разные оценки. Это значит, что не все члены команд понимают требования истории. В таком случае можно повторно обсудить узкие места и повторно проголосовать.
Если вы только начали или начинаете работать по Scrum, planning poker может показаться чем-то не понятными и сложными, но на самом деле сложного в нем ничего нет, просто нужно время, чтобы понять как правильно сопоставить эти величины с реальной сложностью выполнения. Все это приходит с опытом.
Надеюсь мне удалось в понятном виде донести основную мысль. Согласно нашего плана, в следюущей части рассмотрим Sprint Planning.
Вот мы и добрались до 5-ой части нашего мини-курса, в которой рассмотрит понятие Story Points. Напомню, в предыдущей части мы говорили про Grooming.
Story Points – это условная величина, с помощью которой оценивается сложность выполнения истории. Story points не должны привязываться к физическому времени: часам, дням и т.д. Для значений story points, как правило, используются числа Фибоначчи (1, 2, 3, 5, 8, 13 и т.д.), либо похожие на Фибоначчи (...13, 20, 40, 80, 100), чем выше значение, тем сложнее реализации фичи.
По окончанию груминга конкретной истории, соответственно нужно оценить сложность ее выполнения. Как это происходит, есть такое понятие Planning Poker – техника оценки. В чем суть, всей команде раздаются карточки с story points (1, 2, 3, 5...) и каждый член команды должен проголосовать, выбрав нужную карточку. Важно понимать, голосуют в закрытую, то есть, на этапе голосования я знаю только свою оценку и никому ее не показываю, пока все не проголосуют. Когда все проголосовали/выбрали оценку – карточки открываются и таким образом смотрят, каких оценок больше.
И тут есть несколько вариантов
1. Простой. Достаточно редкий кейс, когда звёзды сложились, и каким-то чудом все оценки получились одинаковыми. На этом всё, историю оценили единогласно, идем дальше.
2. Спорный. Это наверное один из частых кейсов. К примеру, по итогам голосования мы получаем приблизительно одинаковое количество нескольких оценок. В таком случае, путем обсуждений, нужно убедить других членов команд согласиться на вашу оценку, либо вы должны согласиться на оценку ваших коллег. Таким образом добивается оценка.
3. Разброс/Хаос. Это пожалуй тоже редкий кейс. Когда у всех совершенно разные оценки. Это значит, что не все члены команд понимают требования истории. В таком случае можно повторно обсудить узкие места и повторно проголосовать.
Если вы только начали или начинаете работать по Scrum, planning poker может показаться чем-то не понятными и сложными, но на самом деле сложного в нем ничего нет, просто нужно время, чтобы понять как правильно сопоставить эти величины с реальной сложностью выполнения. Все это приходит с опытом.
Надеюсь мне удалось в понятном виде донести основную мысль. Согласно нашего плана, в следюущей части рассмотрим Sprint Planning.
Дизайн-система одна из хайповых штук в последнее время. Основные цели ДС – переиспользование готовых компонентов, выстроить четкое взаимодействие между разработчиками и дизайнерами, ну и сэкономить время дизайнеров и разработчиков.
Собрал несколько интересных материалов, почитать на выходные.
– Митап про опыт развития и масштабирования ДС Альфа-Банка
– О дизайн-системе замолвите слово. Статья от HH, в которой ребята делятся своим опытом внедрения дизайн-системы.
– Дизайн-система: что это, для чего и как создать. В статье рассматриваются общие моменты: что такое ДС, для чего она нужна и как её создать.
Полезно будет для всех, кто хоть как-то связан с разработкой клиентских приложений.
Собрал несколько интересных материалов, почитать на выходные.
– Митап про опыт развития и масштабирования ДС Альфа-Банка
– О дизайн-системе замолвите слово. Статья от HH, в которой ребята делятся своим опытом внедрения дизайн-системы.
– Дизайн-система: что это, для чего и как создать. В статье рассматриваются общие моменты: что такое ДС, для чего она нужна и как её создать.
Полезно будет для всех, кто хоть как-то связан с разработкой клиентских приложений.
Лучшие практики написания комментариев к коду
Еще одна статья про комментарии к коду, в которой на примере показывают, как с помощью комментариев сделать код более понятным.
Еще одна статья про комментарии к коду, в которой на примере показывают, как с помощью комментариев сделать код более понятным.
Самые важные уроки, которые я получил от Senior-разработчиков
Полезная статья, про то, как взаимодействовать с Senior разработчиками и получить максимально полезный опыт.
Полезная статья, про то, как взаимодействовать с Senior разработчиками и получить максимально полезный опыт.
Лучшие языки программирования для изучения в 2021 году
В статье собрано 5 лучших языков программирования для изучения в 2021 году, с кратким описанием языка, ожидаемой зп и платформами для обучение по каждому языку.
В статье собрано 5 лучших языков программирования для изучения в 2021 году, с кратким описанием языка, ожидаемой зп и платформами для обучение по каждому языку.
Основные понятия Scrum. Sprint Planning (Планирование спринта)
Наконец-то добрался до написания 6-ой части нашего мини-курса, в которой разберем что такое Sprint Planning, когда и как проводится и т.д. Погнали.
Sprint Planning – это мероприятие, на котором Scrum команда накидывает себе задачи/истории на текущий Sprint. Планирование принято проводить в первый день нового спринта, то есть спринт начинается с планирования, с этим должно быть все понятно.
Как происходит сам процесс? Основная идея планирования – максимально четко разобрать задачи и максимально точно их оценить. От этого зависит то, насколько удачно завершится спринт. Поэтому, нужно по максимуму уточнять все кейсы дизайна, поведения интерфейса и т.д., чтоб в процессе реализации было меньше вопросов.
Бывают ситуации, когда команда не успела допилить какие-то фичи в прошлом спринте и в таком случае, первым делом переносятся незавершенные задачи с прошлого спринта, а после этого, забивается оставшееся свободное время, другими задачами. В идеале, все взятые задачи в спринт должны быть выполнены, но иногда так не получается =))
Интересный момент. Во многих книгах, гайдах говорится о том, что фича должна быть реализована от и до, в процессе спринта. Если допустим у вас клиент-серверное приложение (а сейчас почти все такими являются), вы должны за спринт: нарисовать дизайн, сделать back-end, сделать front-end (web, mobile, desktop), написать тесты, протестировать и выпустить релиз. На практике же, бывают ситуации когда за спринт все это не успеть и в таком случае, идем по старинке: заранее рисуется дизайн или делается back-end, а в спринте по этим направлениям ведутся только доработки – это считается не верным решением.
На этом пожалуй всё, основное вроде как обозначил. Если кто пропустил, прошлый пост был про Груминг. В следующей части рассмотрим Daily Stand Up. И по традиции, оставьте плиз обратную связь.
Наконец-то добрался до написания 6-ой части нашего мини-курса, в которой разберем что такое Sprint Planning, когда и как проводится и т.д. Погнали.
Sprint Planning – это мероприятие, на котором Scrum команда накидывает себе задачи/истории на текущий Sprint. Планирование принято проводить в первый день нового спринта, то есть спринт начинается с планирования, с этим должно быть все понятно.
Как происходит сам процесс? Основная идея планирования – максимально четко разобрать задачи и максимально точно их оценить. От этого зависит то, насколько удачно завершится спринт. Поэтому, нужно по максимуму уточнять все кейсы дизайна, поведения интерфейса и т.д., чтоб в процессе реализации было меньше вопросов.
Бывают ситуации, когда команда не успела допилить какие-то фичи в прошлом спринте и в таком случае, первым делом переносятся незавершенные задачи с прошлого спринта, а после этого, забивается оставшееся свободное время, другими задачами. В идеале, все взятые задачи в спринт должны быть выполнены, но иногда так не получается =))
Интересный момент. Во многих книгах, гайдах говорится о том, что фича должна быть реализована от и до, в процессе спринта. Если допустим у вас клиент-серверное приложение (а сейчас почти все такими являются), вы должны за спринт: нарисовать дизайн, сделать back-end, сделать front-end (web, mobile, desktop), написать тесты, протестировать и выпустить релиз. На практике же, бывают ситуации когда за спринт все это не успеть и в таком случае, идем по старинке: заранее рисуется дизайн или делается back-end, а в спринте по этим направлениям ведутся только доработки – это считается не верным решением.
На этом пожалуй всё, основное вроде как обозначил. Если кто пропустил, прошлый пост был про Груминг. В следующей части рассмотрим Daily Stand Up. И по традиции, оставьте плиз обратную связь.
Базы данных: большой обзор типов и подходов
Базы данных – одна из главный состовляющих как back-end, так и любого продукта в целом. Наткнулся на крутой доклад от Яндекса, в котором рассказывают какие бывают базы данных, какие их особенности важно помнить, как в работе с данными учитывать характеристики системы и планы масштабирования, в какую из тем нужно углубиться для решения конкретной задачи.
Рекомендую к прочтению.
Базы данных – одна из главный состовляющих как back-end, так и любого продукта в целом. Наткнулся на крутой доклад от Яндекса, в котором рассказывают какие бывают базы данных, какие их особенности важно помнить, как в работе с данными учитывать характеристики системы и планы масштабирования, в какую из тем нужно углубиться для решения конкретной задачи.
Рекомендую к прочтению.
Приложения Яндекс и Яндекс.Браузер на Android научились автоматически и бесшовно переводить текст на картинках.
Если вы листаете в них зарубежные сайты, то теперь по клику можете перевести полностью всю страницу, в том числе и картинки.
Это особенно удобно, когда листаешь ленту 9GAG или Reddit.
Если вы листаете в них зарубежные сайты, то теперь по клику можете перевести полностью всю страницу, в том числе и картинки.
Это особенно удобно, когда листаешь ленту 9GAG или Reddit.
Mail•ru Group открывает набор на бесплатные курсы по мобильной разработке
Mail•ru Group запускает два бесплатных курса по Android- и iOS-разработке для студентов вузов Москвы и Санкт-Петербурга. За один семестр вы освоите базовые навыки мобильной разработки, научитесь работать в команде и сможете с нуля создать собственное приложение.
Лучшие выпускники получат возможность присоединиться к командам Юлы, AliExpress России, Одноклассников и другим проектам экосистемы VK.
Заявки на обучение принимаются на сайтах курсов: iOS-разработка, Android-разработка до 6 сентября включительно.
Mail•ru Group запускает два бесплатных курса по Android- и iOS-разработке для студентов вузов Москвы и Санкт-Петербурга. За один семестр вы освоите базовые навыки мобильной разработки, научитесь работать в команде и сможете с нуля создать собственное приложение.
Лучшие выпускники получат возможность присоединиться к командам Юлы, AliExpress России, Одноклассников и другим проектам экосистемы VK.
Заявки на обучение принимаются на сайтах курсов: iOS-разработка, Android-разработка до 6 сентября включительно.
Основные понятия Scrum. Daily Stand Up (Стендап)
7-ая часть нашего мини-курса, в которой мы разберем такое мероприятие, как Daily Stand Up.
Daily Stand Up – это ежедневные встречи, направлены на синхронизацию всей команды. Одна из важных активностей в скраме. Стендап, как правило, проходит утром, в одно и то же время, длится +/- 15-20 минут.
Что это значит? Каждый день, вся команда собирается и коротко обсуждает процесс выполнения задач. На таких митингах, самое время обозначать проблемы, которые вас тормозят/блокируют, это может быть все что угодно: не готов дизайн, не работает back-end, не продумали поведение интерфейса и т.д. Это нужно для того, чтобы своевременно проинфомировать команду и совместно, оперативно решить возникшие проблемы, тем самым успешно закрыв спринт.
Интересный момент. По скраму, во время стендапа, участники должны стоять, отсюда и нейминг мероприятия Stand Up, это нужно для того, чтобы встречи были короткими, т.к. долго стоять дискомфортно.
Еще раз подчеркну 2 основных момента
Время. Стендап должен проходить в одно и то же время, лучше утром.
Длительность. Короткий формат – +/- 15-20 минут.
Коротенький пост получился, надеюсь основную мысль получилось донести. Предыдущая часть про Sprint Planning тут. В следующей части рассмотрим Demo / Sprint Review.
7-ая часть нашего мини-курса, в которой мы разберем такое мероприятие, как Daily Stand Up.
Daily Stand Up – это ежедневные встречи, направлены на синхронизацию всей команды. Одна из важных активностей в скраме. Стендап, как правило, проходит утром, в одно и то же время, длится +/- 15-20 минут.
Что это значит? Каждый день, вся команда собирается и коротко обсуждает процесс выполнения задач. На таких митингах, самое время обозначать проблемы, которые вас тормозят/блокируют, это может быть все что угодно: не готов дизайн, не работает back-end, не продумали поведение интерфейса и т.д. Это нужно для того, чтобы своевременно проинфомировать команду и совместно, оперативно решить возникшие проблемы, тем самым успешно закрыв спринт.
Интересный момент. По скраму, во время стендапа, участники должны стоять, отсюда и нейминг мероприятия Stand Up, это нужно для того, чтобы встречи были короткими, т.к. долго стоять дискомфортно.
Еще раз подчеркну 2 основных момента
Время. Стендап должен проходить в одно и то же время, лучше утром.
Длительность. Короткий формат – +/- 15-20 минут.
Коротенький пост получился, надеюсь основную мысль получилось донести. Предыдущая часть про Sprint Planning тут. В следующей части рассмотрим Demo / Sprint Review.
10 GitHub Repositories for the Self-Taught Developer
Наткнулся на интересную статейку, в которой собраны 10 GitHub репозиториев для самообучения. Там и developer-roadmap и бесплатные книги по многим направлениям и открытые/публичные API, в общем много полезного. Рекомендую закинуть в избранное.
Наткнулся на интересную статейку, в которой собраны 10 GitHub репозиториев для самообучения. Там и developer-roadmap и бесплатные книги по многим направлениям и открытые/публичные API, в общем много полезного. Рекомендую закинуть в избранное.