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

Существует мнение, что программирование само по себе напоминает процесс изучения иностранного языка. Технически здесь есть общие моменты, но фактически для мозга все выглядит не совсем одинаково. Чтобы выяснить, какие же части мозга отвечают за кодинг, ученые из MIT просканировали мозг разработчиков-добровольцев в процессе работы. Молодые люди работали с применением текстового языка Python и графического языка ScratchJr.

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

С математическими задачами все не так просто: согласно последним исследованиям при решении задач на логику и математику активнее работает левое полушарие. А во время поиска ответов на задачи пространственной навигации больше задействовано правое полушарие.


Так вот, кодирование активирует сразу оба полушария. Получается, что несмотря на то, что кодирование больше похоже на математику, в реальности все не совсем так.

Как еще программирование влияет на мозг

Программисты известны специфическим мышлением. Ученые давно изучают влияние программирования на мышление. Вот три интересных вывода.

1. Программирование формирует наш образ мышления и закладывает ментальные модели.

Как это происходит? Важным оказывается тот язык, с которого вы начали знакомство с программированием. Это мог быть любой язык, включая морально устаревший Basic или Pascal.

Но, в любом случае, идиомы первого языка программирования сильно влияют на видение структур, построение логического дерева, выстраивание алгоритмом и прочее.

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

2. Написание кода влияет на наше здоровье, укрепляя его.

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

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

3. Программирование это еще и речь.

Как и говорилось выше, когда разработчик кодит, области мозга, отвечающие за языковые функции, бездействуют. Иная ситуация когда программист читает чужой код. В ходе изучения программистами фрагментов исходного кода авторы проекта провели сканирование фМРТ их головного мозга. Как оказалось, в процессе анализа кода у разработчиков задействованы области мозга, которые обычно связаны с обработкой речи, памятью и вниманием:

• средняя лобная извилина отвечает за внимание, язык, оперативную память;
• средняя височная извилина связана с поиском семантической памяти;
• нижняя теменная доля задействована для кратковременной памяти;
• нижняя лобная извилина связана с оперативной памятью и языком.

Познакомьтесь с Бобом

Боб чрезвычайно амбициозный и активный разработчик.

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

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

Другими словами, ему придётся делать меньше того, что он любит в обмен на то, чем он заниматься не умеет управлять другими.

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

Проходят месяцы, и становится очевидным, что он неудовлетворительно проявляет себя на новой должности. Он достиг нового уровня некомпетентности. Его благодушие и отсутствие навыков руководства, способствовавшие предыдущей работе, теперь привели к провалу. Из-за его некомпетентности продуктивность команды упала, а сама компания дала трещину.

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

Печально то, что эти бедняги, вероятно, раньше работали великолепно. Но их протолкнули на должность, для успеха на которой у них просто нет нужных навыков.

Это явление называется принципом Питера:

В иерархической системе каждый индивидуум имеет тенденцию подняться до уровня своей некомпетентности. [] Сливки поднимаются кверху, пока не прокиснут.

Хотя Лоуренс Питер сформулировал эту идею в своём бестселлере как сатиру, она оказалась безусловно истинной: человека будут повышать до тех пор, пока он не достигнет своего уровня некомпетентности. Для разработчика эта ступенька может быть мидлом, сениором, техлидом, директором и так вплоть до CTO.

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

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

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

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

Как ни парадоксально, ваши собственные амбиции становятся ключом к вашей посредственности.

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

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

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

Творческая некомпетентность: способ быть профессионалом

Синдром самозванца часто считается чем-то плохим. Разумеется, менталитет, при котором вы считаете менее компетентным, чем требования к вашей должности, может нанести вам урон. Он может привести к недооценке себя. Когда в глубине души вы верите, что ничего не умеете, это часто проявляется в реальности.

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

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

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

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

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

Если вы думаете, что знаете всё, то ничего не знаете. Если вы думаете, что не знаете ничего, то кое-что знаете. Джейс О'Нил

Поэтому будьте творчески некомпетентным. Верьте в то, что не знаете ничего. Воспринимайте себя как некомпетентного.

Привыкните к этому образу мышления как к способу лучше подготовиться и мотивировать себя изучать больше, чем требует ваша повседневная работа и будущие должности, которые вам нужно будет занять. Будьте разработчиком в идеализированном смысле. Это позволит вам постоянно делать важный вклад и совершенствоваться, не достигая потолка, ограничивающего ваш рост.

---

На правах рекламы

Закажите сервер и сразу начинайте работать! Создание VDS любой конфигурации в течение минуты, в том числе серверов для хранения большого объёма данных до 4000 ГБ. Эпичненько :)

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

Для кого предназначена эта статья?

Вам когда-нибудь передавали код или программу, дерево зависимостей которой напоминает запутанную монтажную плату?


Как выглядит управление зависимостями

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

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

В частности, мы рассмотрим скрипты, которые должны работать как фоновый процесс.

Репозитории Github и Docker

Если вам более удобна наглядность, то изучите репозитории Github и Docker, где будет хоститься этот код.

Но почему Docker?

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

Контейнеризация приложений на самом деле является золотым стандартом портируемости.


Общая схема Docker/контейнеризации

Контейнеризация (особенно при помощи docker) открывает перед вашим программным приложением огромные возможности. Правильно контейнеризированное (например, докеризированное) приложение можно развёртывать с возможностью масштабирования через Kubernetes или Scale Sets любого поставщика облачных услуг. И да, об этом мы тоже поговорим в следующей статье.

Наше приложение

В нём не будет ничего особо сложного мы снова работаем с простым скриптом, отслеживающим изменения в каталоге (так как я работаю в Linux, это /tmp). Логи будут передаваться на stdout, и это важно, если мы хотим, чтобы они отображались в логах docker (подробнее об этом позже).


main.py: простое приложение мониторинга файлов

Эта программа будет выполняться бесконечно.

Как обычно, у нас есть файл requirements.txt с зависимостями, на этот раз только с одной:


requirements.txt

Создаём Dockerfile

В моей предыдущей статье мы создали скрипт процесса установки в Makefile, благодаря чему им очень легко делиться. На этот раз мы сделаем нечто подобное, но уже в Docker.


Dockerfile

Нам необязательно вдаваться в подробности устройства и работы Dockerfile, об этом есть более подробные туториалы.

Краткое описание Dockerfile мы начинаем с базового образа, содержащего полный интерпретатор Python и его пакеты, после чего устанавливаем зависимости (строка 6), создаём новый минималистичный образ (строка 9), копируем зависимости и код в новый образ (строки 1314; это называется многоэтапной сборкой, в нашем случае это снизило размер готового образа с 1 ГБ до 200 МБ), задаём переменную окружения (строка 17) и команду исполнения (строка 20), на чём и завершаем.

Сборка образа

Завершив с Dockerfile, мы просто выполняем из каталога нашего проекта следующую команду:

sudo docker build -t directory-monitor .


Собираем образ

Запуск образа

После завершения сборки можно начинать творить магию.

Один из самых замечательных аспектов Docker заключается в том, что он предоставляет стандартизованный интерфейс. Так что если вы правильно спроектируете свою программу, то передавая её кому-то другому, достаточно будет сказать, что нужно изучить docker (если человек ещё его не знает), а не обучать его тонкостям устройства вашей программы.

Хотите увидеть, что я имею в виду?

Команда для запуска программы выглядит примерно так:


Здесь многое нужно объяснить, поэтому разобьём на части:

-d запуск образа в detached mode, а не в foreground mode

--restart=always при сбое контейнера docker он перезапустится. Мы можем восстанавливаться после аварий, ура!

--e DIRECTORY='/tmp/test' мы передаём при помощи переменных окружения каталог, который нужно отслеживать. (Также мы можем спроектировать нашу программу на python так, чтобы она считывала аргументы, и передавать отслеживаемый каталог таким способом.)

-v /tmp/:/tmp/ монтируем каталог /tmp в каталог /tmp контейнера Docker. Это важно: любой каталог, который мы хотим отслеживать, ДОЛЖЕН быть видимым нашим процессам в контейнере docker, и именно так это реализуется.

directory-monitor имя запускаемого образа

После запуска образа его состояние можно проверять с помощью команды docker ps:


Вывод docker ps

Docker создаёт crazy-имена для запущенных контейнеров, потому что люди не очень хорошо запоминают значения хэшей. В данном случае имя crazy_wozniak относится к нашему контейнеру.

Теперь, поскольку мы отслеживаем /tmp/test на моей локальной машине, если я создам в этом каталоге новый файл, то это должно отразиться в логах контейнера:


Логи Docker демонстрируют, что приложение работает правильно

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

Делимся программой

Ваша докеризированная программа может пригодиться вашим коллегам, друзьям, вам в будущем, да и кому угодно в мире, поэтому нам нужно упростить её распространение. Идеальным решением для этого является Docker hub.

Если у вас ещё нет аккаунта, зарегистрируйтесь, а затем выполните логин из cli:


Логинимся в Dockerhub

Далее пометим и запушим только что созданный образ в свой аккаунт.


Добавляем метку и пушим образ


Теперь образ находится в вашем аккаунте docker hub

Чтобы убедиться, что всё работает, попробуем выполнить pull этого образа и использовать в сквозном тестировании всей проделанной нами работы:


Сквозное тестирование нашего образа docker

Весь этот процесс занял всего 30 секунд.

Что дальше?

Надеюсь, мне удалось убедить вас в потрясающей практичности контейнеризации. Docker останется с нами надолго, и чем раньше вы его освоите, тем больше получите преимуществ.

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

Источники

• https://runnable.com/docker/python/dockerize-your-python-application
• https://www.docker.com/
• https://kubernetes.io/
• https://stackoverflow.com/questions/30449313/how-do-i-make-a-docker-container-start-automatically-on-system-boot
• https://docs.docker.com/docker-hub/repos/

---

На правах рекламы

Вдсина предлагает виртуальные серверы на Linux или Windows. Используем исключительно брендовое оборудование, лучшую в своём роде панель управления серверами собственной разработки и одни из лучших дата-центров в России и ЕС. Поспешите заказать!