Алексей Алексеев

https://gist.github.com/
https://jsfiddle.net/

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

Уберите либо аргумент name из функции, либо переменную name из ее тела. Обе одновременно - не нужны.

Или так:

>>> def my_func():
	        name = input('What is your name?: ')
	        print(name)

>>> my_func()
What is your name?: Alex
Alex
>>> my_func()
What is your name?: Bob
Bob

Или так:

>>> def my_func(name):
	        print(name)

>>> my_func('Alex')
Alex
>>> my_func('Bob')
Bob

my_func(name)
Лучше будет так:
my_func( "spidespidespide" )

А вы чего ожидали?

def my_func( name ):
  name = input('What is your name?: ')
  print( name )

my_func( "xxx" )

[olej@dell own.WORK]$ python3 draft.py 
What is your name?: aaa
aaa

WebStorm используйте, Notepad++ это явно не для быстрой верстки, кофе не поможет, это когда однажды нужно сделать срочную работу, сдать ее, и пойти пить совсем другой напиток, с обратным эффектом, а долговременно кофе не поднимет производительность, зато привыкание вызовет.

Мне известно четыре основных способа заработка, напрямую связанных со свободными программами:

— Первый, самый прямой, но от того почему-то всем не менее неочевидный — брать и продавать копии свободных программ. Аудитория: любые конечные пользователи. Примеры: Parted Magic, ряд программок для «Андроида», ну например, «Conversations». Высокоморальность: в полном порядке.

— Второй — это уже известная вами продажа поддержки. А фактически иногда и просто своего имени, когда какая-то реальная поддержка начинается с сумм несколько больших, чем базовый контракт. Аудитория: те, для кого ваша программа есть орудие производства, то есть компании и предприниматели. Пример: уже озвученный вами Canonical. Высокоморальность: в полном порядке.

— Третий — это продажа исключений из авторского лева. Аудиторией будут разработчики несвободных программ, а программа ваша должна быть библиотекой под (как нетрудно догадаться) авторским левом, причем чаще сильным. Суть в том, что для добрых людей ваш продукт свободен на условиях, скажем, GNU GPL или GNU AGPL, а проприетарщики пусть платят за возможность использовать его в своих шкурных интересах. Примеры: GhostScript, MySQL. Высокоморльность: прихрамывает маленько.

— Четвертый — это то, о чем помянул тов. CityCat4 — т. н. free crippleware, то есть полноценная ваша программа несвободна и платна, но у нее есть свободный урезанный вариант. Причем урезано может быть как что-то существенное, так и сущая ерунда. Аудитория: кто угодно. Примеры: Odoo, GitLab, ProcessMaker. Высокоморальность: от невысокой до никакой, смотря сколько отрезано.

И разумеется, все вышеперечисленно можно комбинировать: Qt, к примеру, и поддержку (обучение) предоставляет, и исключения из авторского лева (причем слабого!) продает, и совсем ерундовую несвободную часть имеет. А упомянутый вами Red Hat — продает копии и предоставляет поддержку. А иногда и такое бывает: программка для «Андроида» под названием OsmAnd полностью свободна, но поставляется в Гуглоплэе в двух вариантах: полном за копеечку и урезанном бесплатно. Еще раз: обе версии свободны, то есть никакой моральной проблемы здесь нет.

――

P. S. Я перечислил только способы заработка на программах как таковых, полагая, что схемы, где свободные программы участвуют косвенно, и без того очевидны, но в комментариях только о них и говорят, так что надо, наверное, упомянуть, что да, конечно, свободная программа также может быть:
— Частью продаваемой услуги — чаще всего услуги специфического хостинга, как ставимый здесь в пример Openshift или (если ближе к народу) Feedly.
— Частью продаваемого устройства, причем само устройство может быть как свободным, так и нет. Тысячи их.
— И наконец, просто частью приносящего прибыль техпроцесса. То есть компания пишет (заказывает) программу себе для внутреннего использования и могла бы ее вообще не распространять, но, не считая ее своим «ноу-хау», ведет себя благородно и просто свободно делится ею со всеми. Известнейший пример — Reddit (хотя в последнее время они подскурвились).

――

И не могу все-таки не отметить, что unix-way отношение к свободе имеет такое же, как мелкое к горячему.

https://github.com/zualex/devmap
images.vfl.ru/ii/1466366676/e324255d/13079149.png
www.webdesigndegreecenter.org/learn-to-code

В PHP отсутствует Double Dispatching и перегрузка методов

Double Dispatch в PHP:

class Foo {
    // ...
    public function makeSomeStuff(Bar $bar)
    {
         $bar->doStuff($this->someData); // double dispatch!
    }
}

Перегрузка методов:

class Foo {
    public function foo() {}
}

class Bar extends Foo {
    public function foo() {} // перегружен!
}

и в ответ на отличающуюся от базового класса/интерфейса сигнатуру он вывалится с ошибкой

то что вы хотели сделать называется ad-hoc полиморфизм, и он есть из коробки в любом языке программирования с динамической типизацией. Достаточно просто не указывать явно сигнатуру, все довольно просто) Ну и да, минус этого то что это не явно и в рантайме. Для языков со статической типизацией явная "перегрузка" нужна только для того что бы компилятор мог построить таблицы диспетчеризации вызовов.

Но решить проблему как-то нужно

Перегрузка методов в наследниках с изменением сигнатуры это как раз таки нарушение принципа подстановки барбары лисков (LSP для сокращения).

> Сервисы должны имплементировать какие-то общие методы, но помимо этого у них есть и специфичные методы.

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

p.s. венгерская нотация - это ужас. Все эти префиксы и суффиксы которые показывают кто есть тип (интерфейс, абстрактный класс) это вещи которые ломают всю красоту идеи полиморфизма и абстракции. Если хотите можем об этом пообщаться отдельно.

Однако каждый из хендлеров может не работать с конкретной реализацией сервиса.

Значит полиморфизм в нашем случае пошел погулять. Есть куча решений данной проблемы, в частности Chain of responsibility.

> Visitor. Предполагает наличие в каждом из хендлеров методов типа handleService1(Service1 $service) и handleService2(Service2 $service), при этом один из методов остается пустым

зачем так усложнять то? У вас должен быть снаружи только один публичный метод а внутри уже реализация сама разберется. Ну то есть если хотите - можете внутри сделать два приватных метода но это так же странно.

> Массив маппинга, который говорит, какой хендлер может обрабатывать какой из сервисов.

Опять же излишнее усложнение.

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

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

ruhighload.com

https://dzone.com
https://www.sitepoint.com

Добрый день.
Читать документацию, смотреть проекты на github, пытаться написать своё решение для какой-либо задачи....
Вот несколько ссылок, которые Вам помогут:
1) rmcreative.ru (блог одного из разработчиков yii2)
2) https://github.com/samdark/yii2-cookbook (рецепты от того же разработчика)
3) www.elisdn.ru/blog/tag/Yii2 (один из блогов, где можно учиться работать с yii2)
4) https://github.com/yiisoft/yii2/tree/master/docs/g... (документация на русском от разработчиков yii2)

по фронтенду:
https://frontendfront.com/ - агрегатор статей из разных источников.
css-live.ru - в основном, переводы.
https://www.smashingmagazine.com/ - фронтенд, вордпресс, красивые обои :-)

На русском frontender.info
На английском
https://css-tricks.com/
Публикации вроде єтих
https://habrahabr.ru/company/zfort/blog/308190/