Лучшие ресурсы для изучения программирования
Критически важно уметь выбирать правильные учебные материалы на нелёгком пути изучения программирования. Мало того что в нашей с вами сфере тонны отличных и классных книг, так ещё и каждый день разработчики со всеми мира публикуют десятки и сотни статей, посвященных решению специфичных проблем.
В таком хаосе очень тяжело найти самые нужные, фундаментальные знания, имея которые легко понять и усвоить любую другую технологию в кратчайший срок. В этой статье мы рассмотрим основные источники таких фундаментальных знаний: те ссылки, с которых нужно начинать изучение любой технологии. Но будь готов: предложенные ресурсы гораздо сложнее в применении, чем общепринятые. Зато если ты последуешь этому совету, то скорость изучения вырастет в разы ;-)
Документация
В первую очередь ты должен загуглить официальный сайт технологии и внимательно изучить всё, что там написано. Доки всегда должны быть твоей первой точкой контакта с любой библиотекой, языком программирования, фреймворком или любым другим инструментом. Не гугли “getting started with ruby on rails”, не ищи “как сделать todo лист на react.js” и забудь запросы в духе “установка elasticsearch”. Помни, что лучше всего технологию знают сами её разработчики, и если они молодцы, то они уже позаботились о хорошей документации.
Github Issues, Github Pull requests и прочие каналы связи с разработчиками
Ладно, вот ты открыл официальную документацию, сделал всё как в ней, но проклятый logstash всё никак не хочет запускаться. Тут ты спросишь – “ну что, пора пускаться во все тяжкие гугления чего попало?”.
Нет, не пора. Следующий твой шаг – посмотреть открытые и закрытые Issues на гитхабе, посмотреть там пулл реквесты. Если твоя проблема и правда не была следствием твоей невнимательности, то либо на неё уже есть тикет в репозитории проекта, либо ты его должен создать. Заодно получишь информацию о том, как решить проблему от самих разработчиков проблемы. У многих крупных технологий (типа того же Elasticsearch) есть даже отдельные форумы и чаты, в которых ты можешь задать свой вопрос. Ещё и попрактикуешься в английском лишний раз!
Прыгай в исходники!
Ну хорошо. Документация проекта ужасная, на GitHub нет никакой активности вот уже пару лет и/или авторы никак не реагируют на твои вопросы. Что тогда делать? Всё верно: открыть исходный код этой библиотеки (для языков программирования немного сложнее, но всё равно возможно) и самому дебажить найденный тобой баг.
Зачем? Затем, что тогда ты не только решишь свою проблему, но ещё и поймёшь как работает используемый тобой инструмент и резко перейдёшь из разряда “гуглю и копипащу” в “читаю исходники как матёрый сеньор программист”.
Многие разработчики, особенно начинающие, боятся смотреть в исходники проектов, не понимая, что таким образом упускают шанс не только сильно углубить свои знания, но и возможность сделать пару коммитов в open source. Полезно время от времени даже не имея конкретной проблемы на руках посмотреть как устроена та или иная фича в какой-нибудь технологии.
Например, когда мне было интересно как NewRelic собирает данные о Rails приложениях, я зарылся в “сорцы” и открыл для себя немало нового, о чём даже рассказал в статье Читаем исходники newrelic_rpm.
Ещё один бонус от чтения исходных кодов: у тебя быстро пропадут все иллюзии о том, что все эти библиотеки написаны сверх-гениальными программистами, которые выдают безупречный код. Скорее наоборот... Как бы это помягче… Скажем так, во многих гемах есть огромный простор для рефакторинга.
Гугли!
И вот наконец-то наступил момент, когда ты, изучив документацию, понял как работает новая технология. Ты знаешь как она устроена и как её применить для своей задачи. Ты столкнулся с багом, который судя по всему никто ещё не решил и который, судя по исходникам, не так то просто решить (ну или у тебя нет времени сейчас решать проблему самостоятельно).
Вот в этот самый момент ты можешь открыть любимый гугл и, уже точно зная что ищешь, броситься в исследование, бегать от одного топика на Stackoverflow к другому, читать везде комменты, твиты и т.п. В итоге, скорее всего, ты найдёшь решение своей проблемы. А если нет, то возвращайся к пункту про исходники и решай её самостоятельно.
А как же книги?
Я не особо поддерживаю погружение в чтение книг на начальных этапах изучения. Agile Web Development With Ruby on Rails и Rails Tutorial являются, безусловно, качественными произведениями, но читающий их человек вынужден следовать примерам из книги, вместо написания и осмысления кода самостоятельно. Поэтому если ты недавно начал изучать программирование, то пачка книг только замедлит твой прогресс. Лучше опирайся на документацию и практику, пробуй написать что-нибудь сам ну или запишись к нам на менторство, в конце-то концов.
Также читай, как правильно задавать вопросы ментору или старшему разработчику Читать
Другое дело, когда нужно получить по-настоящему глубокие знания по конкретной теме. В таком случае можно, например, почитать книгу про рефакторинг кода, или отдельную книжку про организацию кода в больших Rails приложениях.
Я, например, чтобы устранить некоторые пробелы в понимании индексов баз данных полгода назад вооружился книгой SQL Performance Explained. Отличное чтиво, всячески рекомендую.
Поэтому, повторяя уже написанное, обращайся к книгам за глубоким раскрытием определённых тем. Только убедись, что эта тема – действительно то, что тебе нужно изучить на данном этапе.
Исключение составляют небольшие электронные книги, нацеленные на быстрый и чёткий обзор какого-то инструмента, с последующими ссылками на ресурсы, которые нужно изучить чтобы полностью погрузиться в инструмент.
Идеальным примером из мира разработки является книжка Самообразование веб-разработчика – за 60 страниц человек узнаёт всё, что ему нужно будет выучить чтобы стать веб-разработчиком и получает десятки полезнейших ссылок на самые необходимые материалы. Ещё хороший пример – 7 reccuring revenue recipes for freelancers.
А как же статьи на mkdev? А как же railscasts?
Обучающим статьям и скринкастам в интернете в этом случае остаются только две задачи:
Пересказать документацию
Зачастую документация недостаточно понятно рассказывает о технологии или о том, как её применять. Типичный пример – всё ещё ужасная документация Angular.js. Не совсем ясно, как использовать Ангуляр в реальных проектах, какой структуры папок придерживаться и т.п. В таком случае качественная подробная статья или скринкаст помогут закрыть этот пробел. Один из таких пробелов по Ангуляру мы закрыли нашей серией статей про использование этого фреймворка.
Привести примеры из реальной жизни
Ещё бывает, что вроде бы технология и крутая, но куда её впихнуть – не совсем понятно. Поэтому примеры её использования для решения реальных задач всегда кстати. К этой же категории можно отнести руководства по разработке каких-то конкретных фич в реальном (или учебном) проекте.
Статьи на mkdev как раз стараются регулярно решать эти две задачи: более доступным языком рассказать читателю про конкретные технологии, и, по возможности, привести реальные примеры использования. Но несмотря на это, твой процесс поиска информации всё равно должен начинаться с офф. документации, переходить к github issues и потом к исходникам.
А на какие вопросы интернет всё ещё не даёт тебе чёткого ответа? Может, ты не понимаешь как реализовывать в Rails конкретную фичу? Или куда прикрутить React.js? Пиши в комментариях, мы будем рады написать для тебя подробную и не оторванную от реальности статью.