Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Как научиться не пайтону, а программированию

Как научиться не пайтону, а программированию

Никита Соболев (wemake.services) @ Python Junior Meetup № 2

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

Moscow Python Meetup
PRO

April 13, 2017
Tweet

More Decks by Moscow Python Meetup

Other Decks in Education

Transcript

  1. Как научиться не
    пайтону, а
    программированию
    Никита Соболев

    View Slide

  2. View Slide

  3. View Slide

  4. View Slide

  5. О чем доклад?
    • Ожидание vs реальность
    • Построение системы знаний
    • Пути получения полезного опыта
    • Не нужно бояться
    Доклад для новичков

    View Slide

  6. View Slide

  7. –Иван Арсентьев
    «Не знать - наше нормальное
    состояние».

    View Slide

  8. – Знающие люди
    «Учиться - единственно
    правильный выход».

    View Slide

  9. Какие ожидания у тех, кто
    хочет выучить Python?
    • Язык подходит для новичков, и синтаксис очень
    простой
    • Выучить язык - довольно быстро
    • Я смогу, выучив язык, работать разработчиком

    View Slide

  10. Как на самом деле?
    • Язык подходит для новичков, но дело не только в
    синтаксисе
    • Выучить язык - довольно быстро. Но на каком
    уровне?
    • Чтобы работать в нашей профессии нужно иметь
    много других знаний

    View Slide

  11. View Slide

  12. View Slide

  13. View Slide

  14. А большие системы
    строятся вообще по-
    другому
    https://github.com/donnemartin/system-design-primer

    View Slide

  15. А есть еще
    традиционный CS
    https://github.com/jwasham/coding-interview-university

    View Slide

  16. А в чем вообще разница
    между "выучить python" и
    "научиться программировать"?

    View Slide

  17. Разница всего в двух
    вопросах
    Зачем?
    Почему?

    View Slide

  18. View Slide

  19. Разработчик всегда может
    ответить на два главных вопроса
    • Использование tuple или list
    • Использование virtualenv
    • NoSQL (а не SQL)

    View Slide

  20. Тут есть подвох
    https://github.com/faif/python-patterns

    View Slide

  21. Вопросы
    Причинно-следственная связь
    Система

    View Slide

  22. Познать язык vs познать
    программирование
    На примере известной фразы

    View Slide

  23. –Чехов
    «Проезжая мимо станции, у
    меня слетела шляпа».

    View Slide

  24. –Стыдоба-то какая
    «I feel myself bad today».

    View Slide

  25. Кодим Программируем
    Делаем всякое, но не понимаем, что
    же мы на самом деле делаем
    Делаем всякое, хотя бы примерно
    понимая, что же происходит
    Не можем объяснить, зачем мы
    используем такой или иной подход
    Можем, и даже назвать
    альтернативы
    Низкое качество Среднее и выше

    View Slide

  26. Задача: "скопировать
    файл"
    Казалось бы просто, да?

    View Slide

  27. Кандидат: Что конкретно Вы имеете в виду, говоря «скопировать»?
    Интервьюер: Ну… создать новый файл, содержимое которого является копией содержимого исходного файла.
    К: Нужно ли скопировать также и метаданные о времени создания и модификации оригинального файла?
    И: Нет, не нужно.
    К: Должен ли файл-копия иметь то же имя, что и исходный файл?
    И: Нет.
    К: Может ли файл-копия иметь то же имя, что и исходный файл?
    И: Хммм… нет.
    К: Должен ли я предусмотреть защиту от атаки через подмену букв со сходными начертаниями (например, турецкой I)?
    И: Не беспокойтесь об этом.
    К: Должен ли файл-копия находиться в том же каталоге, что и исходный файл? Хочу отметить, что если да — то он, вероятно, не может иметь то же самое имя. Если только речь не идёт о копировании файла самого в себя (это тоже интересный вопрос...)
    И: Да.
    К: Как насчёт атрибутов файла?
    И: Скопируйте их тоже.
    К: Должен ли я модифицировать атрибуты исходного файла? Если функция копирования, которую Вы просите меня написать, является частью операции резервного копирования или архивирования, то я должен сбросить архивный атрибут у исходного файла.
    И: Нет, оставьте их в покое.
    К: Вы сказали, что я должен тупо скопировать атрибуты исходного файла на файл-копию. Но если архивный атрибут у исходного файла сброшен, а я его «тупо скопирую» на файл назначения, то это может ввести в заблуждение программы резервного копирования, которые могут использоваться на этом компьютере.
    И: Просто скопируйте атрибуты. Меня не волнует, как там у пользователя организовано резервное копирование.
    К: Ну, мне кажется, что это не самый разумный подход при разработке программного обеспечения, которым всё-таки будут люди пользоваться, но раз Вы так настаиваете…
    И:…
    К: Как насчёт атрибута «сжатый»? Ведь может оказаться, что файловая система, на которой находится каталог назначения, не поддерживает сжатие.
    И: Делайте копию несжатой.
    К: Даже если исходный файл — сжатый, а в каталоге назначения поддерживается сжатие?
    И: ДА.
    К: А как насчёт атрибута «зашифрованный»? Что, если исходный файл зашифрован, а в каталоге назначения не поддерживается шифрование?
    И: В этом случае не шифруйте копию.
    К: Не хочу отклоняться от темы, но мне кажется, что такое поведение создаст серьёзную дырку в безопасности. Особенно в случае если файловая система, на которую мы копируем файл, поддерживает произвольные атрибуты (прямо или косвенно).
    И: Послушайте, просто скопируйте чёртов файл!
    К: Как насчёт информации о создателе файла?
    И: Плевать!
    К: Как насчёт информации о владельце файла?
    И: Плевать!
    К: А как насчёт прав доступа? Должен ли я по-разному обрабатывать унаследованные и назначенные права?
    И: К чёрту права!
    К: На какой ОС должна работать моя функция?
    И: Windows XP.
    К: Home, Pro, Media Center, или какой-то их комбинации?
    И: Pro.
    К: На какой пакет обновлений я могу рассчитывать?
    И: Service Pack 2.
    К: То есть я могу не поддерживать предыдущие уровни обновлений?
    И: Верно.
    К: Каким образом мне будет передано имя исходного файла?
    И: Как параметр.
    К: Будет ли оно передано как строка, завершённая нулевым байтом, строка с длиной, или как объект?
    И: Строка, завершённая нулевым байтом.
    К: Предусматривать ли ситуацию с передачей мне пустого указателя?
    И: Нет.
    К: Предусматривать ли ситуацию с передачей мне пустой строки?
    И: Нет.
    К: Предусматривать ли ситуацию с передачей мне неправильно сформированной строки (например, без завершающего нулевого байта)?
    И: Нет.
    К: В какой кодировке будет переданное мне имя?
    И: Unicode.
    К: Простите, но Unicode — это вообще-то не кодировка. Unicode-данные должны быть в какой-то конкретной кодировке — например, UTF-8, UCS-2, UTF-16…
    И: Ладно, пусть будет UTF-8.
    К: Хорошо, но смею заметить, что тогда для передачи в вызов Windows API мне придётся перекодировать в UTF-16, а это несколько геморройно…
    И: Тогда UTF-16!
    К: С каким порядком байтов?
    И: Ррррр… с каким хотите!
    К: Предусматривать ли обработку относительных путей, или только абсолютных?
    И: Только абсолютных.
    К: Есть ли какие-то особенности у передаваемых мне путей, по которыми я должен их фильтровать?
    И: Нет. Считайте, что вызывающая программа это уже сделала.
    К: Как будет формироваться (или передаваться) имя файла назначения?
    [… текли минуты, превращаясь в часы...]
    К: Должен ли я поддерживать (или допускать) асинхронное копирование?
    И: Нет.
    К: Как я должен сообщать об аварийных ситуациях — исключением или кодом возврата?
    И: Без разницы.
    К: Должен ли я обрабатывать исключения, приходящие из вызываемых мною функций, или просто пропускать их к вызвавшему меня коду?
    И: Пропускайте.
    К: Что, если файл назначения уже существует?
    И: Мамой клянусь, что нет.
    К: То есть вызывающая программа это гарантирует?
    И: Вот именно.
    К: То есть если всё-таки окажется, что он уже существует, то это значит, что гарантии нарушены, и мне следовало бы обрушить программу — что-то явно пошло не так, и мало ли что ещё она там сейчас наделает?
    И: Как хотите.
    К: А как насчёт вторичных потоков данных у файла?
    И: Да делаёте что хотите, чёрт бы Вас побрал!
    К: Послушайте, Вам может показаться, что я на Вас давлю, и мне очень жаль — но мне крайне важно уяснить все детали Вашего задания. Очевидно, раз Вы хотите, чтобы я написал Вам новую функцию копирования файла, — вместо того, чтобы воспользоваться одной из множества уже реализованных во
    всевозможных библиотеках и фреймворках — то у Вас имеются какие-то очень-очень специфические требования, которым библиотечные функции не удовлетворяют, и я намереваюсь эти требования из Вас вытянуть. Конечно, я уже могу быстренько набросать что-нибудь подходящее, но должен отметить, что у нас
    ещё целая куча не до конца выясненных деталей…
    И: ААААААААААААААААААААААААААААААААААААААААААА!!!
    https://habrahabr.ru/post/301924/

    View Slide

  28. –Немой вопрос
    «А откуда знают знающие?».

    View Slide

  29. View Slide

  30. Но такой опыт приходит
    не "один раз и навсегда"

    View Slide

  31. Есть сферы, изучить
    которые полностью -
    невозможно

    View Slide

  32. Такие как:
    • Астрономия
    • Физика
    • Отношения
    • Программирование

    View Slide

  33. Но почему?
    • Новая дисциплина
    • Но сфера знаний уже очень обширна: от
    драйверов до новых js-фреймворков
    • Постоянно появляются новые области знаний и
    кардинально меняются старые

    View Slide

  34. Что делать?

    View Slide

  35. Работать
    • Работа должна быть интересной
    • Плохую работу лучше менять

    View Slide

  36. –Моя любимая цитата
    «Когда пожарный приходит
    домой - он смотрит телевизор
    или читает книгу. Когда
    программист приходит домой -
    он программирует».

    View Slide

  37. Еще больше работать
    • После работы - GitHub нуждается в твоей
    помощи!
    • И до работы тоже
    • Не знаешь над чем работать? Возьми любой
    популярный фреймворк или библиотеку, правь
    документацию и баги

    View Slide

  38. Заменить плохие привычки
    хорошими
    • Листаешь ленту ВК? - Листай /r/python вместо нее
    • Читаешь всякую ерунду? - Читай лучше
    habrahabr.ru
    • Смотришь видосы на youtube? - Смотри доклады с
    конференций
    • Следишь за новинками? - Следи за github/trending
    • Отключи лишние мессенджеры

    View Slide

  39. Open source moves
    fast. Keep up.
    https://changelog.com/

    View Slide

  40. Ходите на митапы!
    MoscowPython и ElixirLangMoscow
    http://elixir-lang.moscow/

    View Slide

  41. View Slide

  42. Не бойтесь "не знать"
    Бойтесь "не узнать"

    View Slide

  43. JPMEETUP10
    http://tceh.com/edu/python/

    View Slide

  44. Полезные ссылки
    • https://github.com/kamranahmedse/developer-
    roadmap
    • https://github.com/donnemartin/system-design-primer
    • https://github.com/faif/python-patterns
    • https://github.com/jwasham/coding-interview-university
    • https://github.com/trending
    • https://changelog.com/

    View Slide

  45. Вопросы?
    Добавляйте меня, будем творить вместе:
    https://github.com/sobolevn

    View Slide